你问了一个很好的问题。这个问题看起来很简单，但实际上答案要复杂一些。我会尽量简明扼要地回答。另外，既然你提到了 ISAKMP，我假设你对 IKEv1 感兴趣。IKEv2 的情况略有变化（好吧，很多），但我确实想提到下面的答案仅与 IKEv1 相关。

第一阶段可以在两种不同的模式中完成：主模式和积极模式。在任一模式下，第一条消息由发起方发送，第二条消息由响应方发送。这两个消息都包含在密码学世界中称为Nonce 的内容。Nonce 只是一个随机生成的数字，用于生成密钥。 （术语 Nonce 来自 _N_umber used _Once_）。所以，在消息 1 和消息 2 之后，双方都知道彼此的 Nonce。

Nonce's 与 Pre-Shared-Key 结合以创建用于生成密钥的 Seed 值。IKE RFC的相关部分在这里：

 For pre-shared keys:       SKEYID = prf(pre-shared-key, Ni_b | Nr_b)

SKEYID 是种子值，稍后将用于生成其他密钥。Pre-Shared-Key 和两个 Nonce 值（Ni_b 是发起者的 Nonce，Nr_B 是响应者的 Nonce）通过使用 PRF 或伪随机函数组合。PRF 类似于散列算法，不同之处在于结果可以是您需要的任意位数。

现在，如果您最初使用主模式，则消息 3 和 4 共享发起方和响应方（分别）的 Diffie-Hellman 公钥。他们都使用这些值来生成 Diffie-Hellman共享密钥。如果您使用的是 Aggressive 模式，则这些 DH 公共值也包含在消息 1 和消息 2 中（与 Nonce 一起）。

然后将种子值与 DH 共享密钥（和一些其他值）组合以创建三个会话密钥：派生密钥、身份验证密钥和加密密钥。RFC 声明如下：

Main Mode 或 Aggressive Mode 的结果是三组经过身份验证的密钥材料：

 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、_a、_e就是上面提到的三个Session key。 SKEYID是种子值。 g^xy是 DH 共享秘密。CKY-I并且CKI-R是发起者和响应者 Cookie，这些只是额外的随机生成的值，稍后用于识别此特定的 ISAKMP 交换和安全关联。 0 1 2是文字数字 0、1 和 2。管道符号|表示串联。

在任何情况下，所有这些值都使用创建三个会话密钥的 PRF 组合在一起：

• 派生密钥——ISAKMP不使用此密钥，而是将其交给 IPsec，以便 IPsec 可以创建自己的密钥
• 身份验证密钥——ISAKMP 在其 HMAC 中使用此密钥（又名，使用密钥保护的散列算法）
• 加密密钥——ISAKMP 使用此密钥对 ISAKMP 想要安全地向其他对等方加密的任何内容进行对称加密。因此，如果为 Phase1 选择的加密算法是 AES，则 AES 将使用此密钥对数据进行对称加密——AES 不会生成自己的密钥材料。

认证密钥和加密密钥用于保护/加密随后的 Phase2 协商。在主模式下，Phase1 的消息 5 和 6 也受这些密钥保护。此外，任何未来的 ISAKMP 信息交换（DPD、Rekey 事件、删除消息等）也受这两个密钥的保护。

派生密钥交给 IPsec，IPsec 从此密钥生成自己的密钥材料。如果您还记得，IPsec 本身并不包含密钥交换机制，因此它获取密钥的唯一方法是手动设置它们（这是过时的，而且再也没有真正做过），或者依赖外部服务来提供密钥材料，如 ISAKMP。

RFC 是这样说的：

SKEYID_e 是 ISAKMP SA 用来保护其消息机密性的密钥材料。

SKEYID_a 是 ISAKMP SA 用来验证其消息的密钥材料。

SKEYID_d 是用于为非 ISAKMP 安全关联派生密钥的密钥材料。

说了这么多，我们可以回到你的问题：什么密钥用于保护预共享密钥？

在主模式下，预共享密钥 (PSK) 在消息 5 和 6 中得到验证。消息 5 和 6 由 ISAKMP 生成的会话密钥保护，如上所述。

在主动模式下，协商中的消息都没有加密。并且在消息 2 和 3 中验证了 PSK。注意，我在这两种情况下都说过 PSK 已验证，我从未说过 PSK 是交换的。显然，如果在积极模式下没有任何东西是加密的，而你只是通过未加密的线路发送预共享密钥，就会有一个巨大的安全漏洞。

幸运的是，ISAKMP 的作者已经想到了这一点。结果，他们创建了一种特殊的方法来验证每一方是否具有正确的 PSK，而无需实际通过网络共享它。有两个项目用于向每个 Peer 验证它们都具有相同的 PSK：Identity Method和Identity Hash。

VPN Peer 可以选择通过多种方式来识别自己；最常见的是，对等点将简单地使用其源 IP 地址。但他们可以选择使用 FQDN 或主机名。这些中的每一个，连同所选方法的相关值，构成了身份方法。例如，如果我有 IP 5.5.5.5，并且我想使用我的 IP 地址来识别我自己，那么我的ID 方法实际上是[IP 地址，5.5.5.5]。 （注意：BOTH 值构成了整个 ID 方法）

然后将 ID 方法与我们之前讨论的种子值 (SKEYID) 以及一些其他值组合（使用 PRF）以创建身份哈希。回想一下，首先创建 SKEYID 的是预共享密钥。

然后通过线路发送 ID 方法和 ID 哈希，另一方尝试使用相同的公式重新创建 ID 哈希。如果接收方能够重新创建相同的 ID 哈希，则它向接收方证明发送方必须拥有正确的预共享密钥。

这在此处的 RFC 中进行了描述：

为了验证任一交换，协议发起方生成 HASH_I，响应方生成 HASH_R，其中：

HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b )
HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )

IDii 和 IDir 是 ID 方法。HASH_I 和 HASH_R 是发起者和响应者的哈希值。这两者在 Phase1 中共享。来自 RFC：

在进行预共享密钥认证时，Main Mode 定义如下：

         Initiator                        Responder
        ----------                       -----------
         HDR, SA             -->
                             <--    HDR, SA
         HDR, KE, Ni         -->
                             <--    HDR, KE, Nr
         HDR*, IDii, HASH_I  -->
                             <--    HDR*, IDir, HASH_R

具有预共享密钥的主动模式描述如下：

       Initiator                        Responder
      -----------                      -----------
       HDR, SA, KE, Ni, IDii -->
                             <--    HDR, SA, KE, Nr, IDir, HASH_R
       HDR, HASH_I           -->

现在，我们终于可以完全回答您的问题了：

Pre-Shared-Key 使用带有 Nonce 的 PRF 和一堆其他人在协商中知道的其他值组合在一起。结果是只有当双方以相同的值开始时，双方才能相互获得的值 - 也就是相同的预共享密钥。结果值是在线共享的值，允许两方验证他们是否具有匹配的预共享密钥，而无需实际暴露有关预共享密钥本身的任何信息。

通过对上述“结果值”的交换进行加密，主模式更安全，这使得提取有关预共享密钥是什么的任何有用信息变得更加困难。

（我好像没能简洁地回答这个问题）

您的答案就在您的问题中：Diffie-Hellman 交换用于生成公共密钥以安全地交换公共密钥（即预共享）。

请参阅：https : //security.stackexchange.com/questions/67953/understanding-diffie-hellman-key-exchange