通过 MITM 攻击安全地导出 IV（Nonce）
我知道一个好的随机数对于大多数密码来说非常重要。我正在使用 AES-GCM，并使用 96 位随机数和 256 位 AES 密钥。我之前在这里问过一些关于如何通过不安全通道协商随机数的问题。
我正在使用 ECDH 派生共享密钥，并计划使用 X9.63 标准方法从中派生密钥材料。我知道在协商密钥时可以将随机生成的 96 位附加到盐的末尾。然后我可以像异或一样将两者结合起来（这是一个点对点系统），并获得一个随机的、良好的随机数。
当然，这并不能阻止 MITM 攻击，例如通过 ARP 欺骗进行的攻击。公钥本身由中央服务器认证，该服务器的公钥与应用程序一起分发。因此，认证不能因为使用GCM而被篡改。然而，随机数当然没有经过认证，因此人们可能会MITM对等点，保持它们的密钥相同，但用可预测或静态的东西（或全零或其他什么）替换IV，这将导致所选（已知？）明文攻击。
这是我正在谈论的事情的一个场景，以防令人困惑。 Alice (A) 和 Bob (B) 都生成良好的随机 96 位随机数材料（Am 和 Bm），并将它们附加到他们的 x.509 证书中。为了便于说明，我将使用小数字 Am=1234 和 Bm=4321。当没有 MITMed 时，每个人都会计算 Am⊕Bm = 5171。这将用作随机数。伊芙决定对他们进行中间人攻击以击败四号。她确保他们最终会得到恒定的 IV“6666”。当 A 向 B 发送 Am“1234”时，Eve ARP 会欺骗 Bm 并将其替换为“2795”。当 B 向 A 发送 Bm“4321”时，Eve 将其替换为“7896”。 1234⊕7896==4312⊕2795==6666。
这是我的想法/想法：
使用签名密钥（ECDSA）签署随机数材料：此时我有没有用于验证 GCM 本身之外的任何内容的设施（即我不使用 ECDSA 密钥或管理它们）。我想严格遵守 Suite B 算法。我知道我可以使用 GCM 验证明文（AEAD 的“AD”部分——带有关联数据的验证加密），但当然我还没有建立 IV...所以我无法用它来验证 IV 材料，可以我？对我来说，我似乎应该能够仅使用 GCM 的对称密钥（我已经通过 ECDH 建立）来验证这一点，因为它无论如何都不需要加密，所以没有秘密——只有明文和 GCM MAC -- 但我无法弄清楚如何在 BC 中没有 IV 的情况下初始化 AEADBlockCipher。首先用全零 IV（正确的密钥）初始化密码，然后将 Nonce 处理为“关联数据”（未加密），最终确定缓冲区（以附加 MAC），发送，“欺骗”密码会不会很愚蠢？将此信息传递给对等方，然后使用真实的 IV 和相同的密钥重新初始化密码？或者，我很确定我可以使用 ECDSA 签署随机数（如果我愿意的话，也许可以与 ECDH 公钥一起签名），但这需要分发也经过服务器认证的 ECDSA 公钥，这增加了我认为的复杂性而是避免（因此是我的第一个签名想法）
记录并禁止重复使用相同的 IV/密钥组合：IV 的重要之处在于它仅与给定密钥一起使用一次。因此，如果有人反复进行上述 MITM 攻击，用人为的攻击替换 IV，这个想法就会注意到并关闭连接。如果他们用派生出未使用的 IV 的工作替代对替换它，攻击者将无法获得任何优势（对吗？）。在我的设计中，ECDH 对的私钥实际上从未到达磁盘，因此在程序调用之间我将拥有所有新的对称密钥，因此这组密钥 + IV 对可以轻松保存在内存中，所以我真的很喜欢这种方法：- )
使用来自 ECDH 的秘密材料作为“掩码”来制作秘密 IV：获取已建立的 ECDH 秘密材料（尚未传递给 X9.63 密钥生成器（BC 中的 ECDHKEKGenerator））。以某种方式从中获取 96 位 (Km)，例如材料本身的前 96 位或材料的 SHA-1 摘要的前 96 位。 Alice 和 Bob 生成随机 96 位随机数材料（Am 和 Bm）。 A和B分别计算Am⊕Km和Bm⊕Km，然后将它们的值发送给对方。一旦A有Bm⊕Km并且B有Am⊕Km，A执行Km⊕(Bm⊕Km)得到Bm，B执行Km⊕(Am⊕Km)得到Am。然后A和B都执行Am⊕Bm，最终得到IV。如果它被篡改，A和B将会有不同的IV，因为Eve不知道Km，所以她不能精确地操纵它，对吧？这将导致 GCM 在交换第一条消息时检测到篡改，因此不会造成任何损害。这种方法有什么问题吗？
很抱歉问了这么长的问题，请不要告诉我不要实现我自己的协议，因为我这样做是为了了解作为一名计算机科学学生的实现细节，而不是如何忽略它们。
I understand that a good nonce is very important with most ciphers. I am using AES-GCM, and am using a 96-bit nonce with a 256-bit AES key. I have asked a few questions on here before about how to negotiate the nonce over an insecure channel.
I am using ECDH to derive a shared secret and plan on using a X9.63 standard method to derive the keying material from such. I know that it would be possible to just append a randomly generated 96 bits to the end for the salt when negotiating the key. Then I could combine the two somehow (this is a peer to peer system) like XOR, and have a random, good nonce.
Of course this doesn't stop MITM attacks, say via ARP spoofing. The public keys themselves are certified by a central server whose public key is distributed with the application. Therefore, certification can't be tampered with because of the use of GCM. However, the nonces are not certified of course, so one could potentially MITM the peers, keeping their keys identical but replacing the IV with something predictable or static (or all zeroes or whatever) which would result in vulnerabilities to a chosen (known?) plaintext attack.
Here's a scenario of the thing I'm talking about in case it's confusing. Alice (A) and Bob (B) both generate good, random 96 bit nonce material (Am and Bm) and append them to their x.509 certificates. For illustration I'll use the small numbers Am=1234 and Bm=4321. When not MITMed, each would calculate Am⊕Bm = 5171. That will be used as the nonce. Eve decides to MITM them to defeat the IV. She makes sure that they will end up with the constant IV "6666." When A sends Am "1234" to B, Eve ARP spoofs Bm and replaces this with "2795." When B sends Bm "4321" to A, Eve replaces this with "7896." 1234⊕7896 == 4312⊕2795 == 6666.
Here are my ideas/thoughts:
Sign the nonce material with a signing key (ECDSA): At this point I have no facility for authenticating anything outside of GCM itself (i.e. I'm not using ECDSA keys or managing them). I'd like to strictly stick with Suite B algorithms. I know that I can authenticate plaintext with GCM (the "AD" part of AEAD -- Authenticated Encryption with Associated Data) but of course I have no established IV yet... so I can't authenticate the IV material with this, can I? To me it seems like I should be able to authenticate this using only a symmetrical key with GCM (which I have established already via ECDH) because it doesn't need to be encrypted anyway so there's no secret -- just plaintext and the GCM MAC -- but I can't figure out how to initialize the AEADBlockCipher without an IV in BC. Would it be stupid to "fool" the cipher by first initializing it with an all-zero IV, the correct key, then process the Nonce as "associated data" (not encrypted), finalize the buffer (to append the MAC), send this to the peer, then reinitialize the cipher with the real IV and the same key? Alternatively, I'm pretty sure that I could sign the nonce (perhaps along with the ECDH public key if I wanted) using ECDSA, but that would require distributing ECDSA public keys that are also certified by the server which adds complexity that I'd rather avoid (thus my first signing idea)
Record and disallow repeated uses of same IV/Key combo: The important thing with an IV is that it is only used once with a given key. So, if someone does the MITM attack above to replace the IV with a contrived one repeatedly, this idea would just notice and close the connection. If they replace it with a working substitute pair that derives an unused IV, the attacker would gain no advantage (right?). The private key of the ECDH pair in my design never actually hits the disk, so between program invocations I would have all new symmetric keys, so this set of key+IV pairs could easily be kept in memory so I really like this approach :-)
Use the secret material from ECDH as a "mask" to make a secret IV: Take the established ECDH secret material (not yet passed to the X9.63 key generator (ECDHKEKGenerator in BC)). Somehow get 96 bits from it (Km), such as the first 96 of the material itself or the first 96 of the SHA-1 digest of the material. Alice and Bob generate random 96 bit nonce material (Am and Bm). A and B calculate Am⊕Km and Bm⊕Km respectively, then send their values to the other person. Once A has Bm⊕Km and B has Am⊕Km, A performs Km⊕(Bm⊕Km) to get Bm and B performs Km⊕(Am⊕Km) to get Am. Then both A and B perform Am⊕Bm and we have our IV finally. If it's tampered with, A and B will have different IVs because Eve does not know Km so she can't manipulate it precisely, right? That would cause GCM to detect tampering when the first message is exchanged so no harm done. What's wrong with this approach?
Sorry for the long question, and please do not tell me not to implement my own protocol because I'm doing this to learn about implementation details as a CS student -- not how to ignore them.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
要回答这个问题，你必须首先查看底层的 GHASH，它用于完整性检查。 GHASH 是一种通用哈希函数。取决于一些秘密参数。
GHASH 的安全性取决于你能否对这些秘密参数保密。
由于 GHASH 是线性函数，因此攻击者永远无法得知 GHASH 的结果，这一点非常重要。即，仅知道几个 GHASH 输出就可以让攻击者导出秘密 GHASH 参数。
GCM 通过加密来保护 GHASH 的输出，即将其与 AES(Counter0) 进行异或。
计数器永远不会重复，这一点非常重要。
例如，假设您加密两条消息，两条消息都使用相同的 Counter0 值。
然后攻击者得知
和
攻击者可以从中得出
向攻击者提供一个线性方程。知道两个方程可以求解秘密参数。但即使知道一个方程也应该可以简化对 GCM 的攻击。
这表明伽罗瓦计数器模式必须非常小心地使用。也就是说，如果您在 CTR 模式下重复 IV，那么您可能会泄漏明文。如果你在 GCM 中重复 IV，那么你就会泄露密钥，这当然更糟糕。
我并不是说这次攻击破坏了你的提议。对我来说，你的提案的描述有点太短了，我不确定我是否完全理解它。但我认为上面的描述确实描述了使用 GCM 时的潜在陷阱，我希望它可以帮助您自己分析您的提案。
To answer this question you have to first look at the underlying GHASH, which is used for the integrity check. GHASH is a universal hash function. depends on some secret parameters.
The security of GHASH depends on whether you can keep those secret parameters secret.
Since GHASH is linear function it is very important that the attacker never learns the result of GHASH. I.e. knowing only a couple of GHASH outputs allows the attacker to derive the secret GHASH parameters.
GCM protects the output of GHASH by encrypting it, that is XORing it with AES(Counter0).
It is very important that the Counter never repeats.
Assume for example that you encrypt two messages, both using the same value for Counter0.
Then the attacker learns
and
from which the attacker can derive
which gives one linear equation to the attacker. Knowing two equations allows to solve for the secret parameters. But even knowing one equtions should allow to simplify attacks against GCM.
This shows that the Galois Counter Mode must be used very very carefully. I.e. if you repeat IVs in CTR mode then you potentially leak plaintext. If you repeat IVs in GCM then you leak keys, which is of course worse.
I do not claim that this attack breaks your proposal. For me the description of your proposal is a little too short and I'm not sure I've fully understood it. But I think the description above does describe a potential pitfall when using GCM and I hope it helps you to analyze your proposal yourself.