緩解 DH 密鑰交換的中間人攻擊的方法
普通 DH 密鑰交換協議容易受到中間人攻擊。我檢查了 SRP (RFC 2945)，但不完全理解為什麼它可以提供幫助。我想到了通過使用預共享密鑰來緩解 MitM 問題的解決方法：
- Alice 和 Bob 通過安全通道（面對面、離線等）創建了一個共享密鑰，我們稱之為“psk”（預共享密鑰的縮寫）。
- 他們使用 DH 協議來設置一個
session key.- 它們都計算
final_key = HMAC(psk, session-key)，然後用於final_key加密通信。由於中間人不知道
psk，他無法猜測實際使用的密鑰。所以 MITM 不起作用。我的問題是：
- 上述“預共享密鑰”的想法真的有效嗎？如果是，原則上是否與任何已知的標准或建議相同？如果不是，缺陷是什麼？
- 是否可以在沒有任何預共享密鑰的情況下防禦 MitM？
- 是的，它會起作用，但它有一些嚴重的缺陷：
首先，DH 通常在沒有機會預共享密鑰的情況下使用，例如當使用者首次訪問網站時，或者當攻擊者可能竊取了預共享密鑰時。
其次，如果您有一個預共享密鑰，您可以將其用作對稱密鑰棘輪中密鑰派生函式的輸入密鑰材料。他們的 Double Ratchet 上的 Signal 文章對此有很好的解釋（第 2.1 和 2.2 節）。這將比 DH 交換更快。
第三，它需要在每對可能進行通信的實體之間使用唯一的預共享密鑰。周圍有數十億台電腦。這將意味著數十億個階乘，這意味著儲存這些密鑰將佔用比可觀測宇宙中的原子更多的空間來儲存數據。
- 是的，在某種程度上。完成此操作的常用方法是使用簽名和公鑰基礎設施。
有一些非對稱算法，如 ECDSA 和 EdDSA，允許某人公開共享密鑰（並保持第二個相應的密鑰私有）並用他們的私鑰“簽署”消息。任何擁有公鑰的人都可以驗證使用私鑰簽名的消息。
與預先共享所有公鑰不同，一小組證書頒發機構 (CA) 被賦予了受信任的狀態。這些“根”CA 的公鑰與作業系統和 Web 瀏覽器捆綁在一起。根 CA 依次簽署包含他們信任的其他一些 CA（中間 CA）的公鑰的特殊消息，以僅簽署合法創建的消息。網站所有者（和其他人）向這些中間 CA 註冊他們的公鑰。
簡化一點：當使用者嘗試連接到網站時，使用者會向網站發送挑戰（實際上是 DH 交換）以進行簽名。然後，該站點對其進行簽名，並將簽名、其公鑰、公鑰鍊和通向根 CA 的密鑰簽名發送回根 CA。使用者的瀏覽器檢查根 CA 密鑰是否是他們信任的密鑰之一，然後驗證中間 CA 密鑰是否由該根 CA 簽名，等等，直到他們驗證來自質詢的簽名是正確的。此頁面對這部分的工作方式進行了更準確（和更詳細）的描述。
因此，只有少數“根”CA 公鑰需要被廣泛共享，而不是為每對想要通信的實體擁有一個唯一的預共享密鑰。這是一個巨大的空間節省，並且使創建一個新實體變得更加容易（想像一下，如果網站必鬚髮送一條消息，將它們的密鑰預先共享給世界上每一個連接網際網路的設備才能開始工作！）