IPSec | IKE密钥交换原理

会员服务 ·

IPSec | IKE密钥交换原理

2018 年 12 月 23 日 计算机与网络安全

一次性进群，长期免费索取教程，没有付费教程。

教程列表见微信公众号底部菜单

进微信群回复公众号：微信群；QQ群：460500587

微信公众号：计算机与网络安全

ID：Computer-network

在采用IKE动态协商方式建立IPSec隧道时，SA有两种：一种IKE SA，另一种是IPSec SA。建立IKE SA目的是为了协商用于保护IPSec隧道的一组安全参数，建立IPSec SA的目的是为了协商用于保护用户数据的安全参数，但在IKE动态协商方式中，IKE SA是IPSec SA的基础，因为IPSec SA的建立需要用到IKE SA建立后的一系列密钥。本文介绍在IKE动态协商方式建立IPSec隧道时的基本工作原理。

一、IKE动态协商综述

手工方式建立SA存在配置复杂、不支持发起方地址动态变化、建立的SA永不老化、不利于安全性等缺点。下面介绍动态协商方式的好处，以及IKE与IPSec的关系。

1、IKE动态协商方式的好处

采用IKE协议为IPSec自动协商建立SA，可以得到以下好处。

（1）降低了配置的复杂度

在IKE动态协商方式下，SPI、认证密钥和加密密钥等参数将自动生成，而手工方式中需根据SA出方向和入方向分别指定。

（2）提供抗重放功能

IPSec使用AH或ESP报头中的序列号实现抗重放（不接受序列号相同的数据包）。当AH或ESP报头中的序列号溢出（也是达到了最大值，不能再继续往下编号，要开始新一轮的重新编号了）后，为实现抗重放，SA需要重新建立，这个过程需要IKE协议的配合，所以手工方式下不支持抗重放功能。

重放攻击是指再次发送已发送过（数据包序列号与原来一样）的数据包，攻击者可采用这种方式对目的主机进行攻击，使目的主机不断接收本已接收、解析重复的数据包而大量消耗资源，甚至崩溃。抗重放就是抵抗这种重放攻击。

（3）支持协商发起方地址动态变化情况下（如采用PPPo E拨号方式接入Internet）的身份认证，手工方式不支持，只能适用于在两端都采用专线连接方式接入Internet情形。

（4）支持认证中心CA（Certificate Authority）在线对对等体身份的认证和集中管理，有利于IPSec的大规模部署，手工方式不支持在线认证方式。

（5）通过IKE协商建立的SA具有生存周期，可以实时更新，降低了SA被破解的风险，提高了安全性。

生存周期到达指定的时间或指定的流量，SA就会失效。在SA快要失效前，IKE将为对等体协商新的SA。在新的SA协商好之后，对等体立即采用新的SA保护通信。生存周期有两种定义方式：

基于时间的生存周期，定义了一个SA从建立到失效的时间。

基流量的生存周期，定义了一个SA允许处理的最大流量。

2、IKE与IPSec的关系

IKE 协议建立在 ISAKMP（Internet Security Association and Key Management Protocol，Internet安全联盟和密钥管理协议）定义的框架上，是基于UDP的应用层协议（对应UDP 500端口）。它为IPSec提供了自动协商交换密钥、建立SA的服务，能够简化IPSec的使用和管理。

其实IKE也不是一个单独的协议，它包括三大协议：ISAKMP（Internet Security Association and Key Management Protocol，因特网安全联盟和密钥管理协议）、Oakley （Oakley Key Determination Protocol，奥利克密钥确定协议）和SKEME（Secure Key Exchange Mechanism for Internet，因特网安全密钥交换机制）。ISAKMP主要定义了IKE对等体（IKE Peer）之间合作关系，建立IKE SA。Oakley协议是一个产生和交换IPSec密钥材料并协调IPSec参数的框架（包括支持哪些安全协议）；SKEME协议决定了IKE密钥交换的方式，主要采用DH（Diffie-Hellman）算法。

IKE与IPSec（包括AH和ESP协议）的关系如图1所示，IKE是UDP之上的一个应用层协议（AH和ESP是网络层协议），是IPSec的信令协议；IKE为IPSec协商建立SA，并把建立的参数及生成的密钥交给IPSec；IPSec使用IKE建立的SA对IP报文加密或认证处理。

图1 IKE与IPSec的关系示意

对等体之间建立一个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协商过程中所要用到的。

二、IKE的安全机制

IPSec应用方案之所以能在公网（如Internet）上安全地进行网络通信，其重要原因是可在对等体间的整个隧道建立和数据传输过程中均有各种安全机制来做保障，这方面如果采用的是IKE来进行自动的密钥交换和协商同样可以做到，因为IKE本身就具有一整套自我保护机制，可以在不安全的网络上安全地认证身份、分发密钥。具体体现在以下几种安全保护方面。

1、身份认证机制

当使用IKE在对等体间进行信息交换时，首先要识别对方的合法性，也就是身份认证问题。在IKE中可用于确定对等体身份（对等体的IP地址或名称）的机制比较全面，包括预共享密钥PSK（pre-shared key）认证、RSA数字证书（rsa-signature，或称RSA数字签名）认证和RSA数字信封认证。

（1）预共享密钥认证

在预共享密钥认证中，共享密钥是作为密钥生成材料的，通信双方采用共享的密钥用相同的哈希算法（也称杂凑算法，或单向散列算法）对报文进行哈希运算，根据运算的结果是否与发送方发来的哈希一致来判断所接收的数据是否被篡改，消息来源是否可靠。如果相同，则认证通过；否则认证失败。

在大多数IPSec应用中都是采用配置比较简单的预共享密钥认证方法。

（2）数字证书认证

在数字证书认证中，通信双方使用CA证书进行数字证书合法性验证。在CA证书中，双方有各自的公钥（网络上传输）和私钥（自己持有）。发送方对原始报文进行哈希运算，并用自己的私钥对报文计算结果进行加密，生成数字签名。接收方使用发送方的公钥对数字签名进行解密，然后采用相同的哈希算法对解密后的报文进行哈希算，看运算的结果与解密发送方发来的哈希值是否相同。如果相同，则认证通过；否则认证失败。

（3）数字信封认证

数字信封认证的基本原理是将对称密钥通过非对称加密（即有公钥和私钥两个）的结果向对方分发对称密钥的方法，类似于现实生活中的信件。我们知道，现实生活中的信件在法律的约束下可保证只有收信人才能阅读信的内容。数字信封则采用密码技术保证了只有规定的接收人才能阅读被保密的内容。

在数字信封中，发送方采用对称密钥（需要发送方事先随机产生一个对称密钥）来对要发送的报文进行数字签名，然后将此对称密钥用接收方的公钥来加密（这部分称数字信封）之后，再将加密后的对称密钥连同经过数字签名的报文一起发送给接收方。接收方在收到后，首先用自己的私钥打开数字信封，即可得到发送方的对称密钥，然后再用该对称密钥解密原来被数字签名的报文，验证发送方的数字签名是否正确。如果正确，则认证通过；否则认证失败。

对于预共享密钥认证方法，当有一个对等体对应多个对等体时，需要为每个对等体配置预共享的密钥，工作量大，所以该方法在小型网络中容易建立，但安全性较低。使用数字证书安全性高，但需要CA来颁发数字证书，适合在大型网络中使用。而数字信封认证用于设备需要符合国家密码管理局要求时使用（需要使用国家密码管理局要求的哈希算法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使用128位密钥。它们之间的安全性由高到低顺序是：SM3>SHA2-512>SHA2-384>SHA2-256>SHA1>MD5。对于普通的安全要求，认证算法推荐使用SHA2-256、SHA2-384和SHA2-512，不推荐使用MD5和SHA1，对于安全性要求特别高的地方，可采用SM3算法。

以上所涉及的身份认证密钥（包括预共享密钥、公/私钥）、证书都是作为发送方的“验证数据”要通过对应方式发给对方予以验证的。

2、数据加密机制

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均使用128位密钥。这些加密算法的安全级别由高到低的顺序是：SM4 > SM1 > AES-256 > AES-192 > AES-128 > 3DES > DES，推荐使用AES-256、AES-192和AES-128，不推荐使用3DES和DES算法，SM1和SM4仅建议在保密及安全性要求非常高的地方采用，因为它们的运算速度比较慢。非对称密钥体系中通常使用的是RSA或DSA（Digital Signature Algorithm，数字签名算法）加密算法。

3、DH（Diffie-Hellman）密钥交换算法

Diffie-Hellman算法是一种公开密钥算法。通信双方可在不传送密钥的情况下，仅通过交换一些数据，即可计算出双方共享的密钥。而且可以做到，即使第三方截获了双方用于计算密钥的所有交换数据，也不足以计算出真正的密钥。

DH主要用于IKE动态协商时重新生成新的IPSec SA所用的密钥，因为它可以通过一系列数据的交换，最终计算出双方共享的密钥，而不依赖于在前期生成的密钥生成材料。但DH没有提供双方身份的任何信息，不能确定交换的数据是否发送给合法方，第三方可以通过截获的数据与通信双方都协商密钥、共享通信，从而获取和传递信息，所以IKE还需要身份认证来对对等体身份进行认证。

4、PFS机制

PFS（Perfect Forward Secrecy，完善的前向安全性）是一种安全特性，指一个密钥被破解后并不影响其他密钥的安全性，因为这些密钥间没有派生关系。

IPSec SA的密钥是从IKE SA的密钥导出的。由于一个IKE SA协商可生成一对或多对有一定派生关系的IPSec SA，所以当IKE的密钥被窃取后，攻击者很可能通过收集到足够的信息来非法导出IPSec SA的密钥，这样就不安全了。如果在生成IPSec阶段启用了PFS，即可通过执行一次额外的DH交换，生成新的、独立的IPSec SA，这样就可以保证IPSec SA密钥的安全了。

三、IKEv1密钥交换和协商：第一阶段

上文已提到，IKEv1版本产生最终的IPSec SA是需要经过两个阶段，分别用来建立IKE SA和IPSec SA。下面先介绍第一阶段。

IKEv1的第一阶段的最终目的是在对等体之间创建了一条安全通道，建立对等体的IKE SA。在这个阶段中，IKE对等体间彼此验证对方，并确定共同的会话密钥。这个阶段需要用到Diffie-Hellman（简称DH）算法进行密钥交换，完成IKE SA建立，使后面的第二阶段过程的协商过程受到安全保护。

在IKEv1版本中，建立IKE SA的过程有主模式（Main Mode）和野蛮模式（Aggressive Mode，也称“积极模式”）两种交换模式。下面分别予以介绍。

1、主模式

在IKEv1的主模式的IKE SA建立过程中，包含三次双向消息交换，用到了六条信息，交换过程如图2-所示。

图2 主模式的密钥交换和协商过程示意

这6条消息其实总体上是三个步骤，各包含两条相邻编号的消息。

第一个步骤对应的是消息①和②，是隧道两端对等体间通过交换彼此配置的IKE策略协商好要共同采用的IKE安全策略，因为只有双方都采用相同的安全策略才能相互识别对方加密的数据，并对对方身份进行正确认证。

第二个步骤对应的是消息③和④，是对等体间通过DH算法交换彼此的密钥生成所需的参数信息（DH公开值和随机数nonce等），建立两端相同的一系列共享密钥，主要包括用于在第二阶段协商的身份认证密钥和协商数据的加密密钥。

第三步对应的是消息⑤和⑥，用前面已创建好的加密密钥彼此相互发送各自的身份（如对等体的IP地址或名称）和验证数据（所采用的身份认证方式中的密钥，或证书数据等），采用前面介绍的相应认证方法在对等体间进行身份认证。最终完成IKE SA的建立。

在正式进行消息交换前，发起方和接收方必须先计算出各自的cookie（在ISKMP报头中，可以防重放和DoS攻击），这些cookie用于标识每个单独的协商交换消息。RFC建议将源/目IP地址、源/目端口号、本地生成的随机数、日期和时间进行散列操作生成cookie。cookie成为在IKE协商中交换信息的唯一标识, 在IKEv1版本中为Cookie，在IKEv2版本中的Cookie即为IKE的SPI（安全参数索引）。

下面再具体介绍以上所提到的这6条消息。

（1）消息①和②用于IKE策略交换，是一个协商确认双方IKE安全策略的过程，但这个交换过程的框架是由ISAKMP定义的，为SA的属性和协商、修改、删除SA的方法提供了一个通用的框架，并没有定义具体的SA格式。

在这个过程中，发起方发送一个或多个IKE安全提议［包括5元组：认证方法（数字证书认证、预共享密钥认证或数字信封认证）、加密算法（AES、DES或3DES等）、哈希算法（MD5或SHA等）、DH组、IKE SA的生存期］，响应方在本地查找最先与收到的安全提议匹配的IKE安全提议，并将这个确定的IKE安全提议回应给发起方，使发起方获知双方共同确定的IKE策略。这是为后面能在一个安全的环境之下协商IPSec SA打下基础，因为这些IKE策略会直接提供对第二阶段的IPSec SA协商的加密保护。

（2）消息③和④用于密钥信息交换，是一个产生各种所需密钥的过程。

首先双方交换通过Diffie-Hellman算法计算出的公钥和nonce值（一个随机数），然后利用自己的公/私钥、对方的公钥、nonce值、配置的预共享密钥（采用预共享密钥认证方法时）等最终生成一系列用于第二阶段的共享密钥（两端产生的密钥是相同的）。例如，认证密钥（称之为skey ID_a）、加密密钥（称之为skey ID_e）以及可用于生成IPSec SA密钥的密钥材料（称之为skey ID_d）。认证密钥用于在IKE第二阶段协商中为信道中传输的协商数据（非用户数据）进行认证；加密密钥用于在IKE第二阶段协商中为信道中传输的协商数据进行加密。

如果采用预共享密钥认证方法，为了正确生成以上各密钥，每一个对等体必须找到与对方相对应的预共享密钥，当有多个对等体连接时，每一对对等体的两端都需要配置一个相同的共享密钥。

（3）消息⑤和⑥用于对等体间的身份信息（如对等体的IP地址或名称）和验证数据（所采用的身份认证方式中的密钥，或证书数据等），双方进行身份认证。这个过程的信息交换是受前面生成的加密密钥（skey ID_e）进行加密保护的。当相互认证通过后，对等间的IKE SA建立就完成了，第二个阶段协商IPSec SA所需的安全通道就会立即建立，两端的VPN设备就可用第一个阶段协商的安全策略对第二阶段协商IPSec SA进行安全加密和认证。

2、野蛮模式

如图3所示，野蛮模式只用到三条信息，消息①和②用于在对等体间协商IKE安全策略，交换DH公钥、必需的辅助信息和身份信息（通常不以IP地址进行标识，而是以主机名进行标识的）。

图3 野蛮模式的密钥交换和协商过程示意

（1）消息①中包括了发起方提供给响应方的IKE安全策略、本端密钥生成信息（本端的DH公钥）和身份信息（主要是对等体名称），响应方在收到这些信息后，首先也是要在本地查找与发起方发来的IKE安全策略匹配的策略，如果找到即确定作为共同的IKE策略。然后利用确定的IKE安全策略、发起方发来的密钥生成信息，以及本端的DH公/私钥，一个nonce随机数生成认证密钥和加密密钥，并根据发起方发来的身份信息对发起方的身份进行初步的验证。

（2）消息②中仅包括响应方的密钥生成信息、身份信息，以及响应方用于身份验证的验证数据（包括所采用的身份认证机制中的密钥、证书等）发给发起方，发起方在收到后获知最终采用的IKE策略，并利用响应方的公钥、本端的公/私钥，以及一个nonce随机数生成一系列密钥（正确情况下，与响应方生成的密钥是相同的），并根据响应方发来的身份信息和验证数据对响应方进行最终的身份验证。

（3）消息③是发起方根据已确定的IKE策略，把自己的验证数据（包括所采用的身份认证机制中的密钥、证书等）发给响应方，让响应方最终完成对发起方的身份验证。至此整个信息交换过程就完成了，进入第二阶段IPSec SA建立了。

由图2和图3的对比可以发现，与主模式相比，野蛮模式减少了交换信息的数目，提高了协商的速度，但是没有对身份信息和验证数据进行加密保护，因为双方在发送身份信息时（对应第①和第②条消息）是不加密的（但主模式中发送的身份信息和验证数据是加密的，对应第⑤和第⑥条消息）。但虽然野蛮模式不提供身份保护，它仍可以满足某些特定的网络环境需求。

当IPSec隧道中存在NAT设备时，需要启用NAT穿越功能，而NAT转换会改变对等体的IP地址，由于野蛮模式不依赖于IP地址标识身份，使得如果采用预共享密钥验证方法时，NAT穿越只能在野蛮模式中实现。

如果发起方的IP地址不固定或者无法预知，而双方都希望采用预共享密钥验证方法来创建IKE SA，则只能采用野蛮模式。

如果发起方已知响应方的策略，或者对响应者的策略有全面的了解，采用野蛮模式能够更快地创建IKE SA。

主模式和野蛮模式在确定预共享密钥的方式不同。主模式只能基于IP地址来确定预共享密钥。而野蛮模式是基于ID信息（主机名或IP地址）来确定预共享密钥。当对等体两端都是以主机名方式标识的时候，就一定要用野蛮模式来协商，如果用主模式的话，就会出现根据源IP地址找不到预共享密钥的情况，以至于不能生成密钥，因为主模式在交换完第③、④条消息以后，需要使用预共享密钥来计算密钥，但是由于双方的身份信息要在第⑤、⑥条消息中才会被发送。而在野蛮模式中，主机ID信息（IP地址或者主机名）在消息①、②中就已经发送了，对方可以根据ID信息查找到对应的预共享密钥，从而计算出密钥。

四、IKEv1密钥交换和协商：第二阶段

IKEv1版本的第二阶段就是要在第一阶段基础上最终建立一对IPSec SA，它只有一种模式，即快速模式（Quick Mode）。快速模式的协商是受IKE SA保护的，整个协商过程如图4所示。

图4 快速模式协商过程示意

在快速模式的协商过程中主要是完成以下IPSec SA安全策略的确定：

使用哪种IPSec安全协议：AH或ESP。

使用哪种HASH算法（认证算法）：MD5或SHA。

使用哪种IPSec工作模式：隧道模式或传输模式。

是否要求加密，若是，选择加密算法：3DES或DES。

可选支持PFS（Perfect Forward Secrecy，完善的前向安全性）。

在上述几方面达成一致后，将建立起两个IPSec SA，分别用于入站和出站通信。

在消息①和②中的IPSec安全提议包括了安全协议、SPI、IPSec封装模式、PFS（可选）、IPSec SA生存周期等。这两条消息中还包括双方的身份信息（如IP地址、传输层端口），验证数据（包括所采用的身份认证机制中的密钥、证书等），以及nonce（一个随机数，用于抗重放，还被用作密码生成的材料，仅当启用PFS时用到）。接收方会利用所收到的对方数据生成加密密钥，消息③为确认消息，通过确认发送方收到该阶段的消息②，使响应方获知可以正式通信了。

五、IKEv2密钥协商和交换

通过以上的学习我们了解到，IKEv1需要经历两个阶段，至少交换6条消息才能最终建立一对IPSec SA，而IKEv2在保证安全性的前提下，减少了传递的信息和交换的次数，实现起来更简单。

1、IKEv2概述

IKEv2保留了IKEv1的大部分特性，而且IKEv1的一部分扩展特性（如NAT穿越）作为IKEv2协议的组成部分被引入到IKEv2框架中。与IKEv1不同，IKEv2中所有消息都以“请求-响应”的形式成对出现，响应方都要对发起方发送的消息进行确认，如果在规定的时间内没有收到确认报文，发起方需要对报文进行重传处理，提高了安全性。

IKEv2还可以防御DoS攻击。在IKEv1中，当网络中的攻击方一直重放消息，响应方需要通过计算后，对其进行响应而消耗设备资源，造成对响应方的DoS攻击。而在IKEv2中，响应方收到请求后，并不急于计算，而是先向发起方发送一个cookie类型的Notify载荷（即一个特定的数值），两者之后的通信必须保持cookie与发起方之间的对应关系，有效防御了DoS攻击。

IKEv2定义了三种交换类型：初始交换（Initial Exchanges）、创建子SA交换（Create_Child_SA Exchange）以及通知交换（Informational Exchange）。IKEv2通过初始交换就可以完成一个IKE SA和第一对IPSec SA的协商建立。如果要求建立的IPSec SA大于一对时，每一对IPSec SA值只需要额外增加一次创建子SA交换（而如果采用IKEv1，则子IPSec SA的创建仍然需要经历两个阶段）。

2、IKEv2初始交换

IKEv2初始交换对应IKEv1的第一阶段，初始交换包含两次交换四条消息，如图5所示。消息①和②属于第一次交换，以明文方式完成IKE SA的参数协商，主要是协商加密算法、交换nonce值、完成一次DH交换，从而生成用于加密，并验证后续交换的密钥材料。消息③和④属于第二次交换，以加密方式完成身份认证（通过交换身份信息和验证数据）、对前两条信息的认证和IPSec SA的参数协商。