现在我们有了两个密钥：
一个将通过AES加密生成
一个将由Diffie-Hellman组生成
哪个密钥用于加密预共享密钥？
#1 楼
你问了一个好问题。这个问题似乎很简单，但实际上答案却有些复杂。我会尽力简洁地回答。另外，由于您提到了ISAKMP，因此我假设您对IKEv1感兴趣。 IKEv2的情况发生了一些变化（嗯，很多），但是我确实想提一下下面的答案仅与IKEv1相关。阶段1可以通过两种不同的模式完成：主模式和积极模式。在任何一种模式下，第一条消息都是由发起方发送的，第二条消息是由响应方发送的。这两个消息都包含在密码学世界中称为Nonce的信息。随机数只是用于密钥生成的随机生成的数字。 （名词Nonce来自_N_umber用过的_Once_）。因此，在消息1和消息2之后，双方都知道彼此的随机数。
Nonce与Pre-Shared-Key组合在一起以创建用于生成秘密密钥的Seed值。 IKE RFC的相对部分在此处：
For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b)
SKEYID是种子值，以后将用于生成其他秘密密钥。通过使用PRF或伪随机函数将预共享密钥和两个Nonce值（Ni_b是发起方的Nonce，Nr_B是响应方的Nonce）组合在一起。 PRF类似于哈希算法，不同之处在于结果可以是所需数量的位。
现在，如果您最初是在进入主模式，则消息3和消息4将共享发起者和响应者（分别）的Diffie-Hellman公钥。他们都使用这些值来生成Diffie-Hellman共享机密。如果您使用的是积极模式，则这些DH Public值也将包含在消息1和消息2中（以及随机数）。
然后将Seed值与DH共享机密结合在一起（还有一些其他值）以创建三个会话密钥：Derevative密钥，Authentication密钥和Encryption密钥。 RFC这样声明：
“主模式”或“积极模式”的结果是三组经过身份验证的密钥材料：
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是上面提到的三个会话密钥。
SKEYID是种子值。 g^xy是DH共享密钥。 CKY-I和CKI-R是发起者和响应者Cookie，它们只是其他随机生成的值，这些值稍后将用于标识此特定的ISAKMP交换和安全关联。 0 1 2是文字数字0、1和2。管道符号|表示串联。无论如何，所有这些值都使用创建三个会话密钥的PRF组合在一起：
衍生密钥-ISAKMP不使用此密钥，而是将其交给IPsec，以便IPsec可以创建自己的秘密密钥。
身份验证密钥- -ISAKMP在其HMAC中使用此密钥（又名，由密钥保护的哈希算法）
加密密钥-ISAKMP使用此密钥对ISAKMP想要安全地加密的任何事物对称地加密同行。因此，如果为阶段1选择的加密算法是AES，则AES将使用此密钥对称地加密数据-AES不会生成自己的密钥材料。
身份验证密钥和加密密钥用于保护/加密随后的Phase2协商。在主模式下，阶段1的消息5和消息6也受这些键保护。此外，任何将来的ISAKMP信息交换（DPD，密钥更新事件，删除消息等）也将受到这两个密钥的保护。
派生密钥已交给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，而无需实际在线共享。有两个项目可用于验证每个对等方是否具有相同的PSK：身份方法和身份哈希。
VPN对等方可以选择通过多种方法来标识自己。通常，对等方将仅使用其源IP地址。但是他们可以选择使用FQDN或主机名。这些中的每一个，以及所选方法的相关值，都构成了身份方法。因此，例如，如果我拥有IP 5.5.5.5，并且我想使用自己的IP地址来标识自己，那么我的ID方法实际上就是[IP地址，5.5.5.5]。 （注意：这两个值构成了整个ID方法）
然后将ID方法（使用PRF）与我们之前讨论的Seed值（SKEYID）和其他一些值结合起来，以创建身份哈希。回想一下，首先要创建SKEYID的是Pre-Shared-Key。
然后通过电线发送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是发起方和响应方哈希值。这两个都是在阶段1中共享的。来自RFC：
执行预共享密钥身份验证时，主模式定义为
：
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 -->
现在，我们终于可以完全回答您的问题：
使用带有随机数的PRF和在协商中其他任何人都知道的其他值组合来组合预共享密钥。结果是，如果双方以相同的值（也就是相同的预共享密钥）开头，则只有双方才能相互获得一个值。结果值是在线上共享的值，允许两方验证他们是否具有匹配的预共享密钥，而无需实际公开有关预共享密钥本身的任何信息。
主模式进入通过对上述“结果值”的交换进行加密，从而更安全了一步，这使得提取关于Pre-Shared-Key是什么的任何有用信息变得更加困难。
#2 楼
您的答案就在您的问题中：Diffie-Hellman交换用于生成公共密钥以安全地交换公共密钥（即预共享）。请参阅：https：//security.stackexchange .com / questions / 67953 / understanding-diffie-hellman-key-exchange
评论
最后一件事。aes加密如何不生成任何密钥，我正在学习ccnp vpn书，并且这本书中写有对称密钥算法生成并使用单个密钥的敌人加密，对称密钥算法的示例是aes，des
–user3347934
2014年12月7日下午14:21
如果AES随机生成密钥，则仍然存在通过网络安全地将该密钥传递给另一方的问题。这就是为什么您需要某种密钥交换方法的原因。 AES本身不是密钥交换算法，它只是对称加密算法。通常，AES使用其他协议（例如ISAKMP）提供给它的密钥。至于AES的工作方式，我最喜欢这个Flash动画来解释它。 PS：如果我的回答回答了您的问题，请将其标记为已接受的答案。
–艾迪
2014年12月7日15:19
非常感谢，它真的帮助我了解了vpn如何与预共享密钥一起工作
–user3347934
2014年12月7日下午16:50
我也有一个问题，请也看一下networkengineering.stackexchange.com/questions/13484/…
–user3347934
2014年12月7日在16:51
其实我不明白使用什么密钥来创建diffi-helmen共享秘密密钥
–user3347934
2014-12-7 17:52