赞
踩
IKE是要建立一个Security Association (SA)用于IPsec,也就是传后面的AH、ESP包。
IKE使用了一种很独特的设计,他先建立第一个ISAKMP SA安全通道,这是阶段一,然后阶段二在这个已经建立的安全通道下,协商用于IPsec的SA。这种设计理念我目前还不能完全理解。
网上找的这个图很形象
第一个SA里面包含了一系列的参数,例如认证算法、加密算法、密钥等等。用来保护IKE本身的通信。
下面看看过程
主要分为三个步骤,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的密钥交换了,而且接收方在第二条也发送了认证消息,这样第三条发送方发的认证消息就是最后一条了。
这样,一阶段就结束了。
二阶段就是要在刚才建立的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需要的信息。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。