ISAKMP“主密鑰”PFS（第一階段）與 Ipsec 會話密鑰 PFS（第二階段）
加密專家的一個問題是幫助一個有點困惑的人：為什麼 PFS（完美前向保密）也存在於第二階段和第一階段？
理由：在第一階段 ISAKMP 中，主模式的結果是以下密鑰材料：
SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
SKEYID_d 在階段 II 中用於生成會話密鑰。g^xy 是 DH (Diffie-Hellman) 共享密鑰。
因此，在第一階段設計中已經存在 PFS。每次有人建立新的 IPsec VPN 隧道時，都會使用一個新的 DH 共享密鑰 g^xy 來計算 SKEYID_d，對吧？因此，階段 II 中的會話密鑰也將是唯一的。這是PFS嗎？
那麼如果我們在第二階段也做 DH，我們有雙倍的 PFS？重點是什麼？
因此，在第一階段設計中已經存在 PFS。每次有人建立新的 IPsec VPN 隧道時，都會使用一個新的 DH 共享密鑰 g^xy 來計算 SKEYID_d，對吧？因此，階段 II 中的會話密鑰也將是唯一的。這是PFS嗎？
不，您不會為每個快速模式重新計算新的 SKEYID_d；相反，SKEYID_d 的值是在創建 IKE 安全關聯時分配的（就像所有其他 SKEYID 值一樣），此後在 SA 期間保持不變。
因此，這不符合完美前向保密的定義；其背後的想法是，如果對手擷取了設備（並學習了它所知道的一切），他將不會學習任何以前的密鑰（當然，他會學習任何目前的密鑰）。
在這種情況下，攻擊者將獲知 SKEYID_d 的值；IPsec 密鑰在 IKEv1 中派生自
prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b). 如果攻擊者擷取了設備（因此獲知 SKEYID_e 值，因此能夠解密 IKE 流量），他會獲知協議、SPI、Ni_b 和 Nr_b 的值（因為它們都是通過加密會話發送的）。因此，如果不使用 PFS 選項，攻擊者可以學習 IPsec 密鑰材料，並讀取所有流量。如果（正確）使用 PFS 選項，則攻擊者無法學習
g(qm)^xy，因此無法獲得密鑰材料。我在 IKEv1 的背景下發表了這些評論；類似的推理適用於 IKEv2（目前版本的 IKE）
顯然我（TS）不允許發表評論，所以我不得不輸入我的回復作為答案。@Poncho 感謝您清除它。因此，將我新發現的知識應用到真實的現場場景中，PFS 對在第二階段永遠不會重新生成密鑰的 vpn 會話沒有任何好處。如果您在 PH II 更新密鑰之前受到威脅，則攻擊者可以獲得目前的 SKEYID_d，而不管 PFS。
我知道，為了完全滿足 PFS 標準，第一階段密鑰材料不應依賴於第二階段密鑰材料。如果第二階段沒有啟動 PFS，則顯然不符合該標準。
為未來的讀者總結（如有錯誤請更正）：
- 如果攻擊者可以在一開始就破壞（= 解密第一階段）你，那麼你就完了：再多的 PFS 都不會幫助你。我假設他還能夠計算在每次快速模式重新設置密鑰時生成的所有後續 KEYMAT。如果我是對的，更新密鑰交換資訊仍會流經受損的第一階段（控制）通道，因此計算 KEYMAT 的必要參數對於攻擊者來說是明文形式。
- WITH pfs：如果攻擊者可以在（比方說）10 次快速模式（第二階段）重新生成密鑰後對您造成威脅，那麼直到並包括第 9 次重新生成密鑰的所有流量都是安全的……因為目前的 KEYMAT 在每次重新生成密鑰時都會被丟棄。目前 KEYMAT 下的流量也可以保存，因為攻擊者不知道用於重新計算目前 KEYMAT 的參數（假設他無法從設備中獲取它們）。不過，在下一次重新生成密鑰時，遊戲就結束了。
- 沒有 pfs：如果攻擊者在 vpn 會話期間的任何給定時間點都可以明文訪問 KEYMAT，他將只能解密您目前 vpn 會話的所有過去流量**=** > 如果您在啟動下一個 VPN 之前不再受到威脅會話，您將獲得安全收益。假設您的會話將在 PH II 更新密鑰之前結束，則安全量等於 PFS 方案，即使在嚴格意義上這不符合 PFS 的定義。