Man-in-the-Middle
在 Diffie-Hellman 中,所有內容都可以以明文形式發送嗎?
我認為我對 DH 的有限理解可能會搞砸——這種情況有什麼問題?
- C 想連接到 S。
- C 有一個它相信屬於 S 的 ECDSA 公鑰。
這是發生的事情:
- C 連接到 S。
- S 發送它的 DH 密鑰交換部分,簽名以防止篡改*。
- C 以明文且不帶簽名的方式發送它的 DH 密鑰交換部分。
- C 和 S 現在計算共享密鑰。
- 共享密鑰用於所有進一步的通信。
*添加填充等,以防止偽造和重複使用。
一個中間人不能對 C 撒謊,因為它不能偽造簽名,如果它對 S 撒謊,它就不會真正獲得任何東西,因為如果它可以有效地假裝是 C 而無需通過 C 將所有內容路由回,它首先不必進行中間人攻擊。
TLDR:
- Diffie-Hellman 密鑰交換的工作方式不同
- 是的,DH 容易受到 MitM 的攻擊。
長答案:
Diffie-Hellman 密鑰交換不是發送帶有某種簽名的公鑰,而是協商密鑰。
快速 DH 解釋(注意:這些值非常不安全):
愛麗絲和鮑勃公開同意兩個價值觀:
- 生成器 -
g
。假設這是3。- 素數模數(顯然是素數) -
p
。假設這是17。Alice 和 Bob 都想到了一個秘密值,我們稱之為
x
- Alice 的秘密值為
15
- Bob 的秘密值為
13
他們使用以下公式計算另一個值:
g^x mod p
- 愛麗絲:
3^15 mod 17
= 6- 鮑勃:
3^13 mod 17
= 12Alice 將結果發送給 Bob,反之亦然
他們都這樣計算最終值:
- 愛麗絲:
12^15 mod 17
= 10- 鮑勃:
6^13 mod 17
= 10他們已經協商了一個密鑰,而 Eve 不知道這個密鑰的值是什麼(協商需要交換很多值,因此只是傾聽但不參與交換不會讓您看到已建立的密鑰)
中間人範例:
想像一下這個“電路”:
Alice -- Eve -- Bob
Eve 在交換值時更改了值,用她與 Alice 交換的密鑰解密來自 Alice 的所有內容,然後用她與 Bob 交換的密鑰對其進行加密,反之亦然。
結論:
DH 需要某種“預先共享的秘密”。DH 本身不是 MitM-proof。對於作為證書頒發機構的 SSL/TLS。即時通訊經常使用OTR(其中涉及一個只有實際對方才能回答的問題 - 預共享秘密)。