当前位置:   article > 正文

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

ipsec ike

一、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需要的信息。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/知新_RL/article/detail/765150
推荐阅读
相关标签
  

闽ICP备14008679号