【网络安全技术】IPsec——IKE (Internet Key Exchange)

最新推荐文章于 2024-09-19 19:42:14 发布

TheSysy

最新推荐文章于 2024-09-19 19:42:14 发布

阅读量1.5k

点赞数 1

分类专栏：网络安全技术笔记文章标签： web安全安全

本文链接：https://blog.csdn.net/TheSysy/article/details/134812339

版权

网络安全技术笔记专栏收录该内容

11 篇文章 0 订阅

订阅专栏

一、IKE简介

IKE是要建立一个Security Association （SA）用于IPsec，也就是传后面的AH、ESP包。

IKE使用了一种很独特的设计，他先建立第一个ISAKMP SA安全通道，这是阶段一，然后阶段二在这个已经建立的安全通道下，协商用于IPsec的SA。这种设计理念我目前还不能完全理解。

网上找的这个图很形象

第一个SA里面包含了一系列的参数，例如认证算法、加密算法、密钥等等。用来保护IKE本身的通信。

二、IKE过程

下面看看过程

1.Phase 1

主要分为三个步骤，1协商SA，2交换密钥，3认证

分两种模式，主模式和激进模式，主模式每个步骤双方各发一条消息，共6条消息，激进模式有将信息合并，一共三条消息。

分四种认证方法

a.Authenticated With Signatures

b.Authenticated With Public Key Encryption

c.Authenticated With a Revised Mode of Public Key Encryption

d.Authenticated With a Pre-Shared Key

还有几个其他的模式不看了，用的时候再去查RFC2409

下面梳理下一阶段的过程

1.发送者发送一个协商请求，附上自己的SPI(Security Parameter Index)，SPI是单向的，就类似于自己的安全通信策略数据库的一个索引，通过SPI来在自己的数据库里索引唯一的一组参数，认证算法、加密算法、密钥等等。

这个消息里还会有DOI（Domain of interpretation），这个字段指明了一个规则，表明接下里的参数协商使用什么样的规则。比如这个字段可能是1，代表是下面的参数协商使用IPsec的规则。

接下来他会一个或多个Transform Payload，每个Transform载荷是一组安全参数，发送过去供接收方选择。

这是一个例子，里面的参数有加密算法：AEC-CBC，密钥长度128位，哈希算法SHA，Group-Description指定了某一个DH组，里面有DH的两个参数，大素数和本原根，下一个是认证方式，预共享密钥，这个也可能是数字证书PKI，后面两个参数规定了这次协商出来的SA的时间。

2.接收方收到之后，会附上自己的SPI，选一个transform组，回回去。

3.这样参数都有了，三四步就可以开始交换密钥了。

这里看文档（RFC 2409），我理解的是，先用基本的DH来交换以获得一个共同秘密，这里并没有做认证，所以面临中间人攻击，但是他在后续做了认证。在获得这个共享秘密（g^xy）之后，用这个共享秘密和双方的其他认证信息来生辰一个密钥SKEYID，数字签名、公钥算法、提前分享的密钥三种认证方式生成密钥的方式不同，如下所示：

For signatures:            SKEYID = prf(Ni_b | Nr_b, g^xy)
For public key encryption: SKEYID = prf(hash(Ni_b | Nr_b), CKY-I | CKY-R)
For pre-shared keys:       SKEYID = prf(pre-shared-key, Ni_b | Nr_b)

有了这个SKEYID之后，在根据这个和共享秘密等在生成真正的三组加密不同信息的密钥：

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)

这三组密钥用来加密不同的信息，e用来加密正常消息，a用来认证，d用来处理非ISAKMP的SA。

4.最后两条消息是双方验证身份，这里就是用刚才生成的密钥加密的通信了

这里看一个使用签名的例子，如果是要用签名来认证，那么一开始的两条就需要交换公钥，比如通过证书。

 Initiator                          Responder
 -----------                        -----------
 HDR, SA                     -->
                             <--    HDR, SA
 HDR, KE, Ni                 -->
                             <--    HDR, KE, Nr
 HDR*, IDii, [ CERT, ] SIG_I -->
                             <--    HDR*, IDir, [ CERT, ] SIG_R

前两条就是协商SA，第三四条交换密钥，KE就是要交换的DH公钥，两个N就是随机数，这两个随机数看上面有用于计算接下来的密钥。

最后两条认证，ID就是身份信息，CERT证书可选，SIG是用以下算出来的HASH，对他签名，这个hash的计算包含了双方的DH公私钥，以及刚用DH公共秘密算出来的SKEYID，以及双方的cookie，SAi是整个SA载荷的body，ID就是身份。他们分别会对这些做hash，然后用自己的私钥签名，然后发给对方。

  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 )

现在设想有个中间人，他可以劫持前两条消息，获得两边的cookie，然后劫持第三四条消息，使用典型的中间人攻击，自己生成两个公私钥对，分别用他们和A和B交换秘密，也自己生成两个随机数，发给a和b，以计算接下来的那一串SKEYID。算出来两对密钥，那他们分别在第五六条和A和B做认证。身份信息可以伪造，签名是用私钥签名的哈希，中间人没法生成这个，对面比如A拿到后，用B的公钥解不开，那就发现不对了，那么中间人攻击就失败了。

上面说的是主模式，还有一种是激进模式，还是看个例子，使用签名的激进模式。

        Initiator                          Responder
       -----------                        -----------
        HDR, SA, KE, Ni, IDii       -->
                                    <--    HDR, SA, KE, Nr, IDir,
                                                [ CERT, ] SIG_R
        HDR, [ CERT, ] SIG_I        -->

直接在前两条消息就把DH的密钥交换了，而且接收方在第二条也发送了认证消息，这样第三条发送方发的认证消息就是最后一条了。

这样，一阶段就结束了。

2.phase 2

二阶段就是要在刚才建立的SA里建一条用于接下来传真正的ip包的SA

        Initiator                        Responder
       -----------                      -----------
        HDR*, HASH(1), SA, Ni
          [, KE ] [, IDci, IDcr ] -->
                                  <--    HDR*, HASH(2), SA, Nr
                                               [, KE ] [, IDci, IDcr ]
        HDR*, HASH(3)             -->

   HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr )
   HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci |
   IDcr )
   HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)

首先发起者要发协商消息，第一个hash就是用之前协商好的SKEYID_a，和（这条消息的头里的message id和包里剩下所有内容的连接），做的HMAC，然后SA就是发起者提出的很多Transform，一个Transform就是一套规则，Ni是随机数，剩下两个KE是可选的，可以再进行一次密钥协商，后面那个没看懂，也是可选的。

响应者同样会回一个选好SA的包，只有一个Transform，这个包很类似，hash2里面还包含了刚才发来的随机数。

最后，发起者收到之后，会回一个类似ACK的东西，里面就是哈希过的message id和两个随机数。

注意这些消息都是加密的，除了ISAKMP的头不加密，剩下的内容都是用刚才的SKEYID_e来加密的。所以这些协商都提供了完整性和机密性保护。

这个SA里协商了之后AH和ESP需要的信息。