IKE密钥交换原理
手工建立SA存在配置复杂、不支持发起方地址动态变化、永不老化、不利于安全等缺点。本节介绍动态协商的好处以及IKE和IPSec之间的关系。
(1)降低了配置的复杂度。在IKE动态协商模式下，SPI、认证密钥、加密密钥等参数会自动生成，而在手动模式下，需要根据SA出方向和入方向分别指定。
(2)提供防重放功能。IPSec使用AH或ESP报头中的序列号来实现防重放(不接受具有相同序列号的数据包)。当AH或ESP头中的序列号溢出时(已经达到最大值，不能再向下编号，需要新一轮的重新编号)，为了实现防重放，需要重新建立SA，这个过程需要IKE协议的配合，所以手动模式下不支持防重放功能。
(3)支持协商发起方(如PPP)地址的动态变化。E-dial接入互联网)，手动模式不支持，只能应用于两端都通过专线接入互联网的情况。
(4)支持在线认证和认证中心(CA)对对等体身份的集中管理，有利于IPSec的大规模部署，但手动模式不支持在线认证。
(5)通过IKE协商建立的s a具有生命周期，可以实时更新，降低了SA被破解的风险，提高了安全性。
当生命周期到达指定时间或指定流程时，SA将失效。在SA过期之前，IKE将为对等方协商一个新的SA。在新的SA被协商之后，对等体立即采用新的SA来保护通信。有两种方法来定义生命周期:
IKE协议基于isakmp(互联网安全协会和密钥管理协议)定义的框架。它是基于UDP(对应UDP500端口)的应用层协议。它为IPSec提供了自动协商和交换密钥并建立SA的服务，可以简化IPSec的使用和管理。
其实IKE并不是一个单独的协议，它包括三个协议:isakmp(互联网安全协会和密钥管理协议)、oakley (oakley密钥确定协议，Aulick密钥确定协议)和skeme(互联网安全密钥交换机制)。ISAKMP主要定义IKE对等体之间的合作关系，建立IKE SA。OakLey协议是生成和交换IPSec密钥材料以及协调IPSec参数(包括支持哪些安全协议)的框架；SKEM E协议确定了IKE密钥交换的方式，主要采用DH (Diffie-Hellman)算法。
IKE和IPSec(包括AH和ESP协议)的关系如下图所示。IKE是UDP之上的应用层协议(AH和ESP是网络层协议)，是IPSec的信令协议。IKE协商为IPSec建立SA，并将建立的参数和生成的密钥交给IPSec；IPSec使用IKE建立的SA来加密或验证IP消息。
对等体之间建立IKE SA后，在IKE SA保护IPSec隧道的情况下，根据AH、ESP安全协议等配置参数协商一对IPSec SA，用于IPSec隧道中对等体之间的数据安全传输。
IKE协议目前有两个版本:IKEv1和IKEv2。IKEv1版本使用两个阶段来为IPSec协商密钥并最终建立IPSec SA。第一阶段，通信双方协商建立IKE自身使用的安全通道(隧道)，即建立一对IKE SA。在第二阶段，建立一对IPSec SA，利用这个通过认证和安全保护的安全通道来保护数据在隧道中的安全传输。IKEv2版本简化了协商过程，可以在一次协商中直接生成IPSec密钥和生成IPSec SA。
我们先来了解一下IKE在生成SA的过程中使用的一些安全机制(包括IKE SA和IPSec SA)，后面会用到具体的IKE协商过程。
IPSec应用方案之所以能在公网(如互联网)上安全通信，重要原因是在隧道建立和对等体间数据传输的整个过程中，它能得到各种安全机制的保障。在这方面，如果使用IKE进行自动密钥交换和协商也可以做到，因为IKE本身有一套自我保护机制，可以在不安全的网络上安全地进行身份认证和密钥分发。具体体现在以下几个方面的安全防护。
在使用IKE进行对等体之间的信息交换时，首先要识别对方的合法性，也就是身份认证问题。在IKE中，可用于确定对等体身份(对等体的IP地址或名称)的机制相对全面，包括预共享密钥PSK(预共享密钥)认证、rsa数字证书(rsa-signature，或RSA数字签名)认证和RSA数字信封认证。
在数字信封中，发送方使用一个对称密钥(发送方需要事先随机生成一个对称密钥)对要发送的消息进行数字签名，然后用接收方的公钥对这个对称密钥进行加密(这部分称为数字信封)，再将加密后的对称密钥和数字签名的消息一起发送给接收方。接收方收到后，首先用自己的私钥打开数字信封，得到发送方的对称密钥，然后用对称密钥解密原来经过数字签名的消息，验证发送方的数字签名是否正确。如果正确，则认证通过；否则，身份验证失败。
对于预共享密钥认证方法，当一个对等点对应多个对等点时，需要为每个对等点配置预共享密钥，工作量较大，因此这种方法在小型网络中容易建立，但安全性较低。使用数字证书安全性高，但需要CA颁发数字证书，适合在大型网络中使用。当设备需要满足国家密码管理局的要求时使用数字信封认证(需要使用国家密码管理局要求的hash算法SM3)，这种认证方式只能在IKEv1的主模式协商过程中支持。
上面提到的用于认证的密钥都属于IKE认证密钥，支持的算法有:MD5，SHA1，SHA2-256，SHA2-384，SHA2-512，SM3。MD5算法使用128位的密钥，SHA-1算法使用160位的密钥，SHA2-256、SHA2-384、SHA2-512分别使用256位、384位和512位的密钥，SM3使用12位的密钥。它们之间的安全性从高到低的顺序是:sm3 >；SHA2-512 & gt；SHA2-384 & gt；SHA2-256 & gt；sha 1 & gt；MD5 .对于一般的安全要求，建议将SHA2-256、SHA2-384和SHA2-512用于身份验证算法，而不建议使用MD5和SHA1。对于安全性要求特别高的地方，可以采用SM3算法。
上述认证密钥(包括预共享密钥和公/私钥)和证书都作为发送方的“验证数据”以相应的方式发送给对方进行验证。
IPSec的数据加密机制主要用于两个方面:一是保护传输的用于身份认证的数据信息(如* * *共享密钥、证书、认证密钥等。)在IKE协商阶段，另一个是在IPSec隧道建立后，保护在隧道中传输的用户数据。但是这里所说的数据加密机制使用的是对称密钥机制，即加密和解密使用同一个密钥，而不是前面介绍的数字证书认证和数字签名应用中使用的非对称密钥体系。
IKE支持的加密算法包括DES、3DES、AES-128、AES-192、AES-256、SM1和SM4。DES算法使用56位密钥，3DES使用168位密钥，AES-128，AES-192，AES-256分别使用128，192和256位密钥，SM1和SM4都使用65442。这些加密算法的安全级别从高到低的顺序是:sm4 >；SMI 1 & gt；AES-256 & gt；AES-192 >AES-128 >3DES & gt推荐DES、AES-256、AES-192和AES-128，但不推荐3DES和DES算法，SM1和SM4由于运算速度慢，只推荐在保密性和安全性要求非常高的地方使用。非对称密钥系统通常采用RSA或DSA(数字签名算法)加密算法。
Diffie-HeLlman算法是一种公钥算法。通信双方仅通过交换一些数据就可以计算出双方共享的密钥，而不需要传输密钥。而且可以做到，即使第三方截获了双方用来计算密钥的所有交换数据，也不足以计算出真正的密钥。
DH主要用于在IKE动态协商时重新生成新IPSec SA使用的密钥，因为它可以通过一系列的数据交换最终计算出双方共享的密钥，而不依赖于前期生成的密钥生成材料。但是DH并没有提供任何关于双方身份的信息，所以无法确定交换的数据是否会发送给合法方。第三方可以通过截获的数据与双方协商密钥，从而享受通信，从而获取和传输信息。因此，IKE还需要身份认证来认证对等体的身份。
PFS(完美前向保密)是一种安全特性，也就是说一个密钥被破解后，不会影响其他密钥的安全性，因为这些密钥之间没有衍生关系。
从本章后面的介绍中可以看出，IPSec SA的密钥是从IKE SA的密钥中派生出来的。由于一个IKE SA协商可以生成一对或多对具有一定派生的IPSec SA，当IKE的密钥被窃取时，攻击者可能通过收集足够的信息非法导出IPSec SA的密钥，这是不安全的。如果在IPSec生成阶段启用PFS，则可以通过执行额外的DH交换来生成新的独立IPSec SA，从而确保IPSec SA密钥的安全性。
如上所述，生成IKEvl版本的最终IPSecSA需要两个阶段，分别用于建立IKESA和IPSecSA。本节首先介绍第一阶段。
IKEvl第一阶段的最终目标是在对等体之间创建安全通道，建立对等体的IKESA。在此阶段，IKE对等方相互验证身份，并确定相同的会话密钥。该阶段需要Diffie-Hellman(简称DH)算法进行密钥交换，完成IKE SA的建立，使第二阶段的协商过程得到安全保护。
在IKEvl版本中，IKE SA的建立过程有两种交换模式:主模式和聚集模式。下面分别介绍。
在IKEv1主模式下建立IKE SA的过程中，有三次双向消息交换，使用了六条信息。交换过程如图所示。
这六条消息实际上一般是三个步骤，每个步骤包含两条编号相邻的消息。
第一步对应消息①和②，是指隧道两端的对等体通过交换彼此配置的IKE策略，约定彼此要采用的IKE安全策略，因为只有双方采用相同的安全策略，才能识别对方的加密数据，正确认证对方的身份。
第二步对应于消息③和④，即对等体交换参数信息(DH public value和nonce等。)通过DH算法，建立一系列两端相同的* * *共享密钥，主要包括用于第二阶段协商的身份认证密钥和协商数据的加密密钥。
第三步对应于消息⑤和⑤，使用之前创建的加密密钥将自己的身份(如IP地址或对等体名称)和认证数据(如采用的认证方法中的密钥或证书数据)发送给对方，并采用相应的认证方法在对等体之间进行身份认证。最后，IKE SA的建立完成。
在正式的消息交换之前，发起方和接收方必须首先计算自己的cookie(在ISKMP头中，可以防止重放和DoS攻击)，这些cookie用于标识每个单独的协商交换消息。RFC建议对源/目标IP地址、源/目标端口号、本地生成的随机数、日期和时间进行哈希处理，以生成cookie。cookie成为IKE协商中交换信息的唯一标识，IKEv1版本中的Cookie，IKEv2版本中的Cookie是IKE的SPI(安全参数索引)。
下面详细介绍一下上面提到的六条消息。
如图所示，savage模式仅使用三条信息。消息①和②用于对等体之间协商IKE安全策略，交换DH公钥、必要的辅助信息和身份信息(通常不是用IP地址标识，而是用主机名标识)。
与主模式相比，可以发现savage模式减少了交换信息的数量，提高了协商速度，但是它并没有对身份信息和认证数据进行加密，因为双方在发送身份信息时都没有加密(对应于消息①和②)(但是主模式下发送的身份信息和认证数据是加密的，对应于消息⑤和⑤)。虽然野人模式不提供身份保护，但还是可以满足一些特定的网络环境需求。
当IPSec隧道中有NAT设备时，需要开启NAT穿越功能，NAT转换会改变对端的IP地址。由于savage模式不依赖于IP地址识别，所以只有采用预共享密钥认证方式，才能在savage模式下实现NAT穿越。如果发起方的P地址不固定或者不可预测，双方都想用预* *密钥认证方式创建IKE SA，那就只能用野蛮模式了。
如果发起方知道响应方的策略，或者对响应方的策略有全面的了解，使用野蛮模式可以更快地创建IKE SA。
ikev1的第二阶段是在第一阶段的基础上最终建立一对sa，第一阶段只有一种模式，即快速模式。快速模式协商受SA保护，整个协商过程如图所示。
在快速模式的协商过程中，主要确定以下IPSec安全策略:
在上述方面达成一致后，将建立两个PSec SA，分别用于入站和出站通信。
消息①和②中的IPSec安全建议包括安全协议、spi、IPSec封装模式、PfS(可选)、IPSec SA生存期等。这两条消息还包括双方的身份信息(如IP地址和传输层端口)、验证数据(包括所采用的认证机制中的密钥和证书)等。)，以及nonce(一个用于防重放的随机数，也用作密码生成的材料，仅在PFS启用时使用)。接收者将使用接收到的对方数据来生成加密密钥，并且消息③是确认消息。通过确认发送方在这个阶段已经收到消息②，应答方就知道可以正式沟通了。
IKEv1需要经过两个阶段，至少要交换6条消息才能最终建立一对PSec SA。在保证安全的前提下，IKEv2减少了传输和交换的消息数量，更易于实现。
IKEv2保留了IKEv1的大部分特性，IKEv1的一些扩展特性(如NAT穿越)作为IKEv2协议的一部分引入了IKEv2框架。与IKEV1不同的是，IKEv2中的所有消息都是以“请求-响应”的形式成对出现的，响应方要确认发起方发出的消息。如果在指定时间内没有收到确认消息，发起方需要重新传输消息，这样可以提高安全性。
IKEv2还可以防御拒绝服务攻击。在IKEv1中，当网络中的攻击者不断重放消息时，响应者需要经过计算后才能响应，这就消耗了设备资源，造成了对响应者的DoS攻击。而在KEv2中，响应方收到请求后并不急于计算，而是先向发起方发送一个cookie类型的Notify载荷(即一个特定值)，两者之间的通信必须保持Fcookie与发起方的对应关系，有效防御DoS攻击。
IKEv2定义了三种类型的交换:初始交换、创建子服务协议交换(Create _Child _SA交换)和信息交换。IKEv2可以通过初始交换完成IKE SA和第一对IPSec SA的协商和建立。如果需要建立一对以上的IPSec SA，那么每对IPSec SA值只需要添加一次就可以创建一个子SA交换(而如果采用IKEv1，那么子SA的创建还需要经历两个阶段)。
IKEv2的初始交换对应于IKEv1的第一阶段。初始交换包括两次交换的四条消息，如图所示。消息①和②属于第一次交换，以明文形式协商IKE SA的参数，主要是协商加密算法，交换nonce值，完成一次DH交换，从而生成加密的密钥材料，验证后续的交换。消息③和④属于第二次交换，身份认证(通过交换身份信息和验证数据)、前两次消息的认证和IPSec SA的参数协商都是通过加密完成的。
初始交换完成后，任何一方都可以发起创建子SA交换，并且该交换中的发起者和初始交换中的发起者可以不同。交换必须在初始交换完成后进行，交换消息受初始交换中协商的密钥保护。
创建子SA的交换包含两个消息，用于重新协商由一个IKE SA创建多个IPSec SA或IKE，对应于IKEv1的第二阶段。如果需要支持PFS，可以创建一个子SA交换来进行额外的DH交换，建立一个敢于建立IPSEC SA的新密钥。
在通信双方的密钥协商过程中，一方可能希望向另一方发送控制信息，通知某些错误或事件的发生，这需要通过“通知交换过程”来完成。
如图2-15所示，通知交换用于在对等体之间传递一些控制信息，如错误信息、删除消息或通知信息。接收信息消息的一方必须响应，并且响应消息可以不包含任何有效载荷。通知交换只能发生在初始交换之后，其控制信息可以是IKE SA(交换受IKES A保护)或sub-SA(交换受sub-SA保护)。