IPsec入门篇讲解(第二篇)
作者:互联网
安全联盟(SA)
IPSec通过在IPSec对等体间建立双向安全联盟(SA),形成一个安全互通的IPSec隧道,来实现Internet上数据的安全传输
SA由一个三元组来唯一标识,这个三元组包括安全参数索引SPI(Security Parameter Index)、目的IP地址和使用的安全协议号(AH或ESP)。其中,SPI是为唯一标识SA而生成的一个32位比特的数值,它在AH和ESP头中传输。在手工配置SA时,需要手工指定SPI的取值。使用IKE协商产生SA时,SPI将随机生成
SA是单向的逻辑连接,因此两个IPSec对等体之间的双向通信,最少需要建立两个SA来分别对两个方向的数据流进行安全保护。如图1所示,为了在对等体A和对等体B之间建立IPSec隧道,需要建立两个安全联盟,其中,SA1规定了从对等体A发送到对等体B的数据采取的保护方式,SA2规定了从对等体B发送到对等体A的数据采取的保护方式
另外,SA的个数还与安全协议相关。如果只使用AH或ESP来保护两个对等体之间的流量,则对等体之间就有两个SA,每个方向上一个。如果对等体同时使用了AH和ESP,那么对等体之间就需要四个SA,每个方向上两个,分别对应AH和ESP
有两种方式建立IPSec安全联盟:手工方式和IKE自动协商方式。二者的主要区别为
密钥生成方式不同
手工方式下,建立SA所需的全部参数,包括加密、验证密钥,都需要用户手工配置,也只能手工刷新,在中大型网络中,这种方式的密钥管理成本很高;IKE方式下,建立SA需要的加密、验证密钥是通过DH算法生成的,可以动态刷新,因而密钥管理成本低,且安全性较高
生存周期不同
手工方式建立的SA,一经建立永久存在;IKE方式建立的SA,其生存周期由双方配置的生存周期参数控制
因此,手工方式适用于对等体设备数量较少时,或是在小型网络中。对于中大型网络,推荐使用IKE自动协商建立SA
IKE协议
因特网密钥交换IKE(Internet Key Exchange)协议建立在Internet安全联盟和密钥管理协议ISAKMP定义的框架上,是基于UDP(User Datagram Protocol)的应用层协议。它为IPSec提供了自动协商密钥、建立IPSec安全联盟的服务,能够简化IPSec的使用和管理,大大简化IPSec的配置和维护工作
IKE负责自动建立和维护IKE SA(也称为ISAKMP SA)和 IPSec SA。功能主要体现在如下几个方面:
对双方进行认证
交换公共密钥,产生密钥资源,管理密钥
协商协议参数(封装,加密,验证….)
IKE协议版本分为IKEv1和IKEv2 是公有协议 IKEv1 在RFC2409 IKEv2 在RFC 5996
IKE的三大组件
SKEME:定义如何通过公共密钥技术(DH算法)实现密钥交换
Oakley:提供了IPSec对各种技术的支持,例如对新的加密与散列技术。并没有具体的定义使用什么样的技术
ISAKMP:定义了消息交换的体系结构,包括两个IPSEC对等体间分组形式和状态转变(定义封装格式和协商包交换的方式)下层由UDP协议承载 源目端口号为500
IKEV1版本
IKE的三个模式
IKEv1建立IKE SA的过程定义了主模式(Main Mode)和野蛮模式(Aggressive Mode)两种交换模式
主模式包含三次双向交换,用到了六条信息 野蛮模式只用到三条信息
主模式过程
消息①和②用于策略交换,发起方发送一个或多个IKE安全提议,响应方查找最先匹配的IKE安全提议,并将这个IKE安全提议回应给发起方
消息③和④用于密钥信息交换,双方交换Diffie-Hellman公共值和nonce值,IKE SA的认证/加密密钥在这个阶段产生
消息⑤和⑥用于身份和认证信息交换(双方使用生成的密钥发送信息),双方进行身份认证和对整个主模式交换内容的认证
主模式详细报文过程
1 2报文过程
1-2消息用于参数的协商(明文) 协商内容:(加密算法 验证算法 验证方式 DH组 有效期)
Initiator(发起者) Responder(响应方)
============================================================================================
HDR, SA -->
<-- HDR, SA
Ci SA
Ci Cr SA
HDR ISAKMP头部
Ci Cr 代表发起方和响应方的SPI
所对应的命令行如下
ike proposal 10
encryption-algorithm aes-192 ---加密算法
authentication-algorithm md5 ---认证算法
integrity-algorithm hmac-sha2-256 ---完整性算法
检查:
[FW1]display ike proposal verbose
11:42:46 2019/08/04
IKE Proposal Priority 10:
------------------------------------------------------------------
Authentication Method : PRE_SHARED ---身份验证方法
Authentication Algorithm : MD5 ---认证算法
Encryption Algorithm : 192-AES ---加密算法
Diffie-Hellman Group : DH-Group2 ---DH算法
Sa Duration(Seconds) : 86400 ---SA持续时间
Integrity Algorithm : HMAC-SHA2-256 ---完整性算法
------------------------------------------------------------------
注意:安全提议是有默认配置,可以修改
DH算法组可以修改
[FW1-ike-proposal-10]dh ?
group1 Indicate the 768-bit Diffie-Hellman group
group14 Indicate the 2048-bit Diffie-Hellman group
group15 Indicate the 3072-bit Diffie-Hellman group
group16 Indicate the 4096-bit Diffie-Hellman group
group2 Indicate the 1024-bit Diffie-Hellman group,default
group5 Indicate the 1536-bit Diffie-Hellman group
3 4报文过程
3-4消息用于密钥素材的交换及产生密钥 如果1 2两个消息不协商出DH组的3 4消息中的KE也不会有
Ci Cr , KE, Ni -->
<-- Ci Cr , KE, Nr
KE key exchange 密钥交换
Ni Nr 随机数
通过前面1 2的DH算法算出公共的K值
通过K值推导SKEYID(种子密钥)
SKEYID分为两种情况 预共享密钥方式(PSK)和采用数字证书方式(在1 2两个报文中进行协商)
在预共享密钥认证中,认证字作为一个输入来产生密钥,通信双方采用共享的密钥对报文进行Hash计算,判断双方的计算结果是否相同。如果相同,则认证通过;否则认证失败
在数字证书认证中,通信双方使用CA证书进行数字证书合法性验证,双方各有自己的公钥(网络上传输)和私钥(自己持有)。发送方对原始报文进行Hash计算,并用自己的私钥对报文计算结果进行加密,生成数字签名。接收方使用发送方的公钥对数字签名进行解密,并对报文进行Hash计算,判断计算结果与解密后的结果是否相同。如果相同,则认证通过;否则认证失败
在数字信封认证中,发送方首先随机产生一个对称密钥,使用接收方的公钥对此对称密钥进行加密(被公钥加密的对称密钥称为数字信封),发送方用对称密钥加密报文,同时用自己的私钥生成数字签名。接收方用自己的私钥解密数字信封得到对称密钥,再用对称密钥解密报文,同时根据发送方的公钥对数字签名进行解密,验证发送方的数字签名是否正确。如果正确,则认证通过;否则认证失败
采用预共享密钥的方式(1-2消息中已经协商)
SKEYID = prf(pre-shared-key, Ni_b | Nr_b)
采用数字证书 (1-2消息中已经协商)
SKEYID = prf(K,Ni_b | Nr_b)
DH(DIFFIE-HELLMAN)密钥交换算法
网关A和B利用ISAKMP消息的Key Exchange和nonce载荷交换彼此的密钥材料
Key Exchange用于交换DH公开值
nonce用于传送临时随机数
由于DH算法中IKE Peer双方只交换密钥材料,并不交换真正的共享密钥,所以即使***窃取了DH值和临时值也无法计算出共享密钥,这一点正是DH算法的精髓所在 从抓包中可以看到IKE Peer双方交换密钥材料
Diffie-Hellman算法是一种公开密钥算法。通信双方在不传送密钥的情况下通过交换一些数据,计算出共享的密钥。即使第三方(如***)截获了双方用于计算密钥的所有交换数据,也不足以计算出真正的密钥。DH保证了IKE不在网络上直接传输密钥,而是通过一系列数据的交换,最终计算出双方共享的密钥
但DH没有提供双方身份的任何信息,不能确定交换的数据是否发送给合法方,第三方可以通过截获的数据与通信双方都协商密钥、共享通信,从而获取和传递信息,所以IKE还需要身份认证来对对等体身份进行认证
密钥材料交换完成后,IKE Peer双方结合自身配置的身份验证方法各自开始复杂的密钥计算过程(预共享密钥或数字证书都会参与到密钥计算过程中),最终会产生三个密钥:
SKEYID_d:用于衍生出IPSec报文加密和验证密钥——最终是由这个密钥保证IPSec封装的数据报文的安全性!
SKEYID_d = prf(SKEYID, K | Ci | Cr | 0)
推导因子
prf(伪随机函数)
SKEYID_a:ISAKMP消息完整性验证密钥——谁也别想篡改ISAKMP消息了,只要消息稍有改动,响应端完整性检查就会发现!
SKEYID_a = prf(SKEYID, SKEYID_d | K | Ci | Cr | 1)
用于验证的密钥
SKEYID_e:ISAKMP消息加密密钥——再也别想窃取ISAKMP消息了,窃取了也看不懂!
SKEYID_e = prf(SKEYID, SKEYID_a | K | Ci | Cr | 2)
用于加密的密钥, 用于后续5-6消息的加密以及快速模式的加密
整个密钥交换和计算过程在IKE SA超时时间的控制下以一定的周期进行自动刷新,避免了密钥长期不变带来的安全隐患
DH(Diffie-Hellman)密钥交换算法
5 6报文过程
5-6消息用于身份认证
预共享密钥方式身份认证
HDR*, IDii, HASH_I -->
<-- HDR*, IDir, HASH_R
HDR *------代表加密
ID 身份标识,一般使用IP地址
HASH_I = prf(SKEYID, K | Ci | Cr | SAi | IDii_b )
HASH_R = prf(SKEYID, K| Ci | SAi | IDir_b )
数字证书方式的身份认证
HDR*, IDii, [ CERT, ] SIG_I -->
<-- HDR*, IDir, [ CERT, ] SIG_R
标签:DH,认证,入门篇,密钥,IKE,SKEYID,SA,第二篇,IPsec 来源: https://blog.51cto.com/13817711/2479118