2023-06-10

国密IPSec之V1.1协商过程

密码算法和密钥种类

密码算法

IPSec VPN使用国家密码管理局批准的非对称密码算法、对称密码算法、密码杂凑算法和随机数生成算法。算法及使用方法如下：

非对称密码算法使用 1024 比特 RSA 算法或 256 比特 SM2 椭圆曲线密码算法，用于
实体验证、数字签名和数字信封等。
对称密码算法使用 128 比特分组的 SM1 分组密码算法，用于密钥协商数据的加密保
护和报文数据的加密保护。算法的工作模式使用 CBC 模式。
密码杂凑算法使用 SHA-1 算法或 SM3 密码杂凑算法，用于对称密钥生成和完整性校
验。其中，SM3 算法的输出为 256 比特。
随机数生成算法生成的随机数应能通过《随机数检测规范》规定的检测。

密钥种类

IPSec VPN使用下列密钥：

设备密钥：非对称算法使用的公私钥对，用于实体验证、数字签名和数字信封等。
工作密钥：在密钥协商第一阶段得到的密钥，用于会话密钥协商过程的保护。
会话密钥：在密钥协商第二阶段得到的密钥，用于数据报文的加密和完整性保护。

IKEv1.1协商流程

第一阶段-主模式

主模式的交换过程如下

消息序列      发起方            方向        响应方
  1         HDR, SA           ---->
  2                           <----       HDR, SA, CERT_sig_r, CERT_enc_r
  3         HDR, XCHi, SIGi   ---->
  4                           <----       HDR, XCHr, SIGr
  5         HDR*, HASHi       ---->
  6                           <----       HDR*, HASHr

消息1 发起方向响应方发送一个封装有建议载荷的安全联盟载荷，而建议载荷中又封装有变换载荷。
消息2 响应方发送一个安全联盟载荷，该载荷表明它所接受的发起方发送的SA提议。
消息3和4 发起方和响应方交换数据，交换的数据内容包括nonce、身份标识（ID）、可选的证书等载荷。
- Nonce是生成加密密钥和认证密钥所必需的参数；ID是发起方或响应方的标识。这些数据使用临时密钥Sk进行加密保护，Sk用数字信封保护，最后，双方各自对数据进行数字签名后再加密。
- 发起方交换的数据如下：
  1
  2
  XCHi = Asymmetric_Encrypt(Ski, pub_r) | Symmetric_Encrypt(Ni,Ski) | Symmetric_Encrypt(IDiSki) | CERT_sig_i | CERT_enc_i
  SIGi_b = Asymmetric_Sign(Ski_b | Ni_b | IDi_b | CERT_enc_i_b, priv_i)
- 响应方交换的数据如下：
  1
  2
  3
  XCHr = Asymmetric_Encrypt(Skr, pub_i) | Symmetric_Encrypt(Nr,Skr) |
  Symmetric_Encrypt(IDr,Skr)
  SIGr_b = Asymmetric_Sign(Skr_b | Nr_b | IDr_b | CERT_enc_r_b, priv_r)
- 上述过程中使用的非对称密码算法、对称密码算法和密码杂凑算法均由消息1和消息2确定。
- 临时密钥Sk由发起方和响应方各自随机生成，其长度应符合对称密码算法对密钥长度的要求。
- 对称密码运算使用CBC模式，第一个载荷的IV值为0；后续的IV使用前面载荷的最后一组密文。
- 加密前的交换数据应进行填充，使其长度等于对称密码算法分组长度的整数倍。
- 所有的填充字节的值除最后一个字节外都是0，最后一个填充字节的值为不包括它自己的填充字节数。
- 当使用证书进行身份验证时，Idi和Idr的类型应使用ID_DER_ASN1_DN。
- 如果对方证书已经在撤销列表中，系统应发送INVALID_CERTIFICATE通知消息。
- 消息3和消息4交互完成后，参与通信的双方生成基本密钥参数SKEYID，以生成后续密钥SKEYID_d、SKEYID_a、SKEYID_e，计算方法分别如下：
  1
  2
  3
  4
  SKEYID = PRF(Hash(Ni_b | Nr_b), CKY-I | CKY-R)
  SKEYID_d = PRF(SKEYID, CKY-I | CKY-R | 0)
  SKEYID_a = PRF(SKEYID, SKEYID_d | CKY-I | CKY-R | 1)
  SKEYID_e = PRF(SKEYID, SKEYID_a | CKY-I | CKY-R | 2)
- 上述计算公式中的值0，1，2是单个字节的数值。
- SKEYID_e 是ISAKMP SA用来保护其消息机密性所使用的工作密钥。SKEYID_a 是ISAKMPSA用来验证其消息完整性以及数据源身份所使用的工作密钥。SKEYID_d 用于会话密钥的产生。
- 所有SKEYID的长度都由PRF函数的输出长度决定。如果PRF函数的输出长度太短，不能作为一个密钥来使用，则SKEYID_e应进行扩展。例如，HMAC hash的一个PRF可产生128比特的输出，但密码算法要求用到320比特的密钥。那么，SKEYID_e就需要利用反馈及连接方法加以扩展，直到满足对密钥长度的要求为止。反馈及连接方法如下：
  1
  2
  3
  4
  5
  K = K1 | K2 | K3 | ...
  K1 = PRF(SKEYID_e, 0)
  K2 = PRF(SKEYID_e, K1)
  K3 = PRF(SKEYID_e, K2)
  ...
- 最后从K的起始位置开始取密码算法的密钥所需要的位数。
消息5和6发起方和响应方认证前面的交换过程。这两个消息中传递的信息使用对称密码算法加密。
- 对称密码算法由消息1和消息2确定，密钥使用SKEYID_e。
- 对称密码运算使用CBC模式，初始化向量IV是消息3中的Ski和消息4中的Skr串连起来经过hash运算得到的，即：
  1
  IV= Hash(Ski | Skr)
- Hash算法由消息1和消息2确定。
- 加密前的消息应进行填充，使其长度等于对称密码算法分组长度的整数倍。所有的填充字节的值都是0。报头中的消息长度应包括填充字节的长度，因为这反映了密文的长度。
- 为了认证交换，发起方产生HASH_I，响应方产生HASH_R，计算公式如下：
  1
  2
  HASH_I = PRF(SKEYID, CKY-I | CKY-R | SAi_b | IDi_b )
  HASH_R = PRF(SKEYID, CKY-R | CKY-I | SAr_b | IDr_b )

第二阶段-快速模式

快速模式交换依赖于第一阶段主模式交换，作为IPSec SA协商过程的一部分协商IPSecSA的安全策略并衍生会话密钥。快速模式交换的信息由ISAKMP SA来保护，即除了ISAKMP头外所有的载荷都要加密。在快速模式中，一个HASH载荷应紧跟在ISAKMP头之后，这个HASH用于消息的完整性校验以及数据源身份验证。

在第二阶段，载荷的加密使用对称密码算法的CBC工作模式，第1个消息的IV是第一阶段的最后一组密文和第二阶段的MsgID进行hash运算所得到的，即：
1
IV= Hash(第一阶段的最后一组密文 | MsgID)
后续的IV是前一个消息的最后一组密文。消息的填充和第一阶段中的填充方式一样。
在ISAKMP头中的MsgID唯一标识了一个正在进行中的快速模式，而该ISAKMP SA本身又由ISAKMP头中的cookies来标识。因为快速模式的每个实例使用一个唯一的IV，这就有可能基于一个ISAKMP SA的多个快速模式在任一时间内同时进行。
在快速模式协商中，身份标识ID缺省定义为ISAKMP双方的IP地址，并且没有强制规定允许的协议或端口号。如果协商双方需要指定ID，则双方的身份应作为IDi和IDr被依次传递。响应方的本地安全策略将决定是否接受对方的身份标识ID。如果发起方的身份标识ID由于安全策略或其它原因没有被响应方所接受，则响应方应该发送一个通知消息类型为INVALID_ID_INFORMATION (18)的通知载荷。
在通信双方之间有多条隧道同时存在的情况下，身份标识ID为对应的IPSec SA标识并规定通信数据流进入对应的隧道。

快速模式的交换过程如下:

消息序列      发起方                                  方向        响应方
  1       HDR*, HASH(1), SA, Ni [, IDci, IDcr ]     ---->
  2                                                 <----     HDR*, HASH(2), SA, Nr [, IDci, IDcr ]
  3       HDR*, HASH(3)                             ---->

消息1 发起方向响应方发送一个杂凑载荷、一个安全联盟载荷（其中封装了一个或多个建议载荷，而每个建议载荷中又封装一个或多个变换载荷）、一个nonce载荷和标识载荷。
- 杂凑载荷中消息摘要的计算方法如下：
  1
  HASH(1) = PRF(SKEYID_a, MsgID | Ni_b | SA [ | IDi | IDr])
消息2 响应方向发起方发送一个杂凑载荷、一个安全联盟载荷、一个nonce载荷和标识载荷。
- 杂凑载荷中消息摘要的计算方法如下：
  1
  HASH(2) = PRF(SKEYID_a, MsgID | Ni_b | SA | Nr_b [ | IDi | IDr])
消息3 发起方向响应方发送一个杂凑载荷，用于对前面的交换进行认证。
- 杂凑载荷中消息摘要的计算方法如下：
  1
  HASH(3) = PRF(SKEYID_a, 0 | MsgID | Ni_b | Nr_b)
- 最后，会话密钥素材定义为：
  1
  KEYMAT = PRF(SKEYID_d, protocol | SPI | Ni_b | Nr_b)
- 其中，protocol和SPI从协商得到的ISAKMP建议载荷中选取。用于加密的会话密钥和用于完整性校验的会话密钥按照算法要求的长度从KEYMAT中依次选取。先选取用于加密的会话密钥，后选取用于完整性校验的会话密钥。
- 当PRF函数的输出长度小于KEYMAT需要的密钥素材长度时，需要利用反馈及连接方法加以扩展，直到满足对密钥长度的要求为止。即：
  1
  2
  3
  4
  5
  6
  KEYMAT = K1 | K2 | K3 | ...
  其中：
  K1 = PRF(SKEYID_d, protocol | SPI | Ni_b | Nr_b)
  K2 = PRF(SKEYID_d, K1 | protocol | SPI | Ni_b | Nr_b)
  K3 = PRF(SKEYID_d, K2 | protocol | SPI | Ni_b | Nr_b)
  ...
单个SA协商产生两个安全联盟—— 一个入，一个出。每个SA（一个由发起方选择，另一个由响应方选择）的不同的SPI保证了每个方向都有一个不同的KEYMAT。由SA的目的地选择的SPI，被用于衍生该SA的KEYMAT。

ISAKMP 信息交换

如果ISAKMP安全联盟已经建立，则ISAKMP信息交换过程如下所示：

1 2	发起方方向响应方 HDR*, HASH(1), N/D ---->

其中N/D是一个ISAKMP通知载荷，或是一个ISAKMP删除载荷。HASH(1)的计算方法为：

1	HASH(1) = PRF(SKEYID_a, MsgID \| N/D)

其中，MsgID不能与同一个ISAKMP SA保护的其他第二阶段交换的MsgID相同。

这个消息的加密使用对称密码算法的CBC工作模式，其密钥使用SKEYID_e，初始化向量IV是第一阶段的最后一组密文和MsgID进行hash运算所得到的，即：

1	IV= Hash(第一阶段的最后一组密文 \| MsgID)

消息的填充和第一阶段中的填充方式一样。

如果ISAKMP安全关联在信息交换时还没有建立，则消息以明文发送，即：

1 2	发起方方向响应方 HDR, N ---->

NAT穿越

IPSec穿越NAT特性让IPSec数据流能够穿越网络中的NAT设备。NAT穿越由3个部分组成：首先判断通信的双方是否支持NAT穿越，其次检测双方之间的路径上是否存在NAT，最后决定如何使用UDP封装来处理NAT穿越。

实现NAT穿越的NAT_D载荷分别添加在第一阶段交换过程中消息3和消息4的载荷之后，这些载荷是独立的，不参与交换过程的所有密码运算。支持NAT穿越的第一阶段交换过程如下：

消息序列              发起方                方向          响应方
  1               HDR,SA, VID             ---->
  2                                       <----     HDR, SA, VID
  3       HDR, XCHi, SIGi, NAT_D, NAT_D   ---->
  4                                       <----     HDR, XCHr, SIGr, NAT_D, NAT_D
  5       HDR*#，HASHi                    ---->
  6                                       <----     HDR*#，HASHr

#标志说明如果NAT存在，这些包将被发送到修改后的端口。
如果需要，NAT_OA载荷分别添加在第二阶段交换过程中消息1和消息2的载荷之后，同第二阶段的消息载荷一起参与密码运算。
实现NAT穿越的处理过程和消息格式按RFC3947的规定执行。

Skippor's Blog