路径: 主页 > MISC > 第117页 > GM/T 0022-2023
标准搜索结果: 'GM/T 0022-2023'
| 标准编号 | GM/T 0022-2023 (GM/T0022-2023) | | 中文名称 | IPSec VPN技术规范 | | 英文名称 | IPSec VPN technical specification | | 行业 | Chinese Industry Standard (推荐) | | 中标分类 | L80 | | 字数估计 | 54,586 | | 发布日期 | 2023-12-04 | | 实施日期 | 2024-06-01 | | 发布机构 | 国家密码管理局 |
GM/T 0022-2023: IPSec VPN技术规范
ICS 35.030
CCSL80
中华人民共和国密码行业标准
代替GM/T 0022-2014
IPSecVPN技术规范
2023-12-04发布
2024-06-01实施
国家密码管理局 发 布
目次
前言 Ⅲ
1 范围 1
2 规范性引用文件 1
3 术语和定义 1
4 符号和缩略语 2
4.1 符号 2
4.2 缩略语 3
5 密码算法和密钥类别 3
5.1 密码算法 3
5.2 密钥类别 4
6 协议 4
6.1 密钥交换协议 4
6.2 安全报文协议 29
7IPSecVPN产品要求 38
7.1 产品功能要求 38
7.2 产品性能参数 39
7.3 安全管理要求 40
8IPSecVPN产品检测 42
8.1 产品功能检测 42
8.2 产品性能检测 43
8.3 安全管理检测 43
9 判定规则 44
附录A(资料性) IPSecVPN简要介绍 45
参考文献 49
前言
本文件按照GB/T 1.1-2020《标准化工作导则 第1部分:标准化文件的结构和起草规则》的规定
起草。
本文件代替GM/T 0022-2014《IPSecVPN技术规范》,与GM/T 0022-2014相比,除结构调整
和编辑性改动外,主要技术变化如下:
a) 删除了术语和定义:“密码算法”(见2014年版的3.1.1)、“密码杂凑算法”(见2014年版的
3.1.2)、“非对称密码算法/公钥密码算法”(见2014年版的3.1.3)、“对称密码算法”(见2014年
版的3.1.4)、“分组密码算法”(见2014年版的3.1.5)、“密码分组链接工作模式”(见2014年版
的3.1.6)、“初始化向量/值”(见2014年版的3.1.7)、“数字证书”(见2014年版的3.1.9)、“鉴
别”(见2014年版的3.1.14)、“加密”(见2014年版的3.1.15)、“SM1算法”(见2014年版的
3.1.20)、“SM2算法”(见2014年版的3.1.21)、“SM3算法”(见2014年版的3.1.22)、“SM4算
法”(见2014年版的3.1.23);
b) 增加了术语和定义“可鉴别的加密机制”(见3.6);
c) 增加了“缩略语”GCM和PRF(见4.2);
d) 增加了与GCM加密模式相关的加密密钥选取说明(见6.1.3.3);
e) 更改了与GCM 加密模式相关的快速模式中消息1的数据包格式(见6.1.6.8,2014年版的
5.1.5.7)、快速模式中消息2的数据包格式(见6.1.6.9,2014年版的5.1.5.8)、快速模式中消息3
的数据包格式(见6.1.6.10,2014年版的5.1.5.9);
f) 更改了“封装安全载荷ESP头格式”中与GCM相关的数据包封装和解封操作的详细说明(见
6.2.2.2,2014年版的5.2.2.2)、“封装安全载荷ESP的处理”中与GCM相关的数据包封装和解
封操作的详细说明(见6.2.2.3,2014年版的5.2.2.3);
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。
本文件由密码行业标准化技术委员会提出并归口。
本文件起草单位:深信服科技股份有限公司、无锡江南计算技术研究所、格尔软件股份有限公司、迈
普通信技术股份有限公司、北京数字认证股份有限公司、华为技术有限公司、中电科网络安全科技股份
有限公司、西安交大捷普网络科技有限公司、山东得安信息技术有限公司、国家密码管理局商用密码检
测中心、深圳奥联信息安全技术有限公司、中国科学院信息工程研究所、鼎铉商用密码测评技术(深圳)
有限公司、北京天融信网络安全技术有限公司、奇安信网神信息技术(北京)股份有限公司、武汉三江航
天网络通信有限公司、中国电子技术标准化研究院、深圳市网安计算机安全检测技术有限公司、杭州奕
锐电子有限公司、智巡密码(上海)检测技术有限公司。
本文件主要起草人:刘平、叶润国、罗俊、郑强、付夏冰、范恒英、朱志强、董浩、雷建、刘建锋、李小京、
邱钢、向明、孔凡玉、李述胜、谭武征、王振、张勇、潘利民、罗鹏、李渝川、徐明翼、马洪富、凌杭、周欣、
王雨晨、何建锋、李琳、龙军、刘松、但波、雷晓锋、刘玉岭、燕爽、王银平、吴安然、安高峰、刘晨、赵松、
曹金、李露、樊俊诚、黄敏、吴俊雄、顾伟平、杨柳、匡云。
本文件及其所代替文件的历次版本发布情况为:
---2014年首次发布为GM/T 0022-2014;
---本次为第一次修订。
IPSecVPN技术规范
1 范围
本文件规定了IPSecVPN的技术协议和产品功能,包括密钥交换协议和安全报文协议,以及产品
功能要求和安全管理要求。
本文件适用于IPSecVPN产品的研制、检测、使用和管理。
2 规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中,注日期的引用文
件,仅该日期对应的版本适用于本文件;不注日期的引用文件,其最新版本(包括所有的修改单)适用于
本文件。
GB/T 20518-2018 信息安全技术 公钥基础设施 数字证书格式
GB/T 32905-2016 信息安全技术 SM3密码杂凑算法
GB/T 32907-2016 信息安全技术 SM4分组密码算法
GB/T 35276-2017 信息安全技术 SM2密码算法使用规范
GB/T 36624-2018 信息技术 安全技术 可鉴别的加密机制
GM/T 0005-2021 随机性检测规范
GM/T 0016 智能密码钥匙密码应用接口规范
GM/T 0062-2018 密码产品随机数检测要求
GM/T 0092-2020 基于SM2算法的证书申请语法规范
GM/Z4001 密码术语
protocol)
RFC3947 密钥交换过程中NAT穿越协商(NegotiationofNAT-traversalintheIKE)
ISAKMP]
3 术语和定义
GM/Z4001界定的以及下列术语和定义适用于本文件。
3.1
安全联盟 securityassociation
两个通信实体经协商建立起来的一种协定。
注1:它描述了实体如何利用安全服务来进行安全的通信。
注2:安全联盟包括了执行各种网络安全服务所要求的所有信息,例如:IP层服务(如头鉴别和载荷封装)、传输层
和应用层服务或者协商通信的自我保护。
3.2
载荷 payload
ISAKMP通信双方交换消息的数据格式。
注:载荷是构造ISAKMP消息的基本单位。
3.3
鉴别头 authenticationheader
用于提供IP数据包的数据完整性、数据源鉴别以及抗重放攻击的功能,但不提供数据机密性的功
能的IPSec协议。
3.4
用于提供IP数据包的机密性、数据完整性以及对数据源鉴别以及抗重放攻击的功能的IPSec
协议。
3.5
一种确认接收到的数据的来源是所声称的机制。
3.6
用于实现数据机密性保护并提供数据完整性和数据源鉴别的密码技术。
注:包括加密和解密两个处理过程。
[来源:GB/T 36624-2018,3.2,有修改]
3.7
使用密码技术在通信网络中构建安全通道。
3.8
IPSec实现 IPSecimplementation
具体实现IPSecVPN协议的软硬件产品。
注:IPSec实现包括软硬一体形态的硬件产品,以及纯软件实现的IPsecVPN产品(比如虚拟机或容器形态IP-
SecVPN产品)。
4 符号和缩略语
4.1 符号
下列符号适用于本文件。
HDR:一个ISAKMP头。
HDR*:表示ISAKMP头后面的载荷是加密的。
SA:带有一个或多个建议载荷的安全联盟载荷。
IDi:发起方的标识载荷。
IDr:响应方的标识载荷。
HASHi:发起方的杂凑载荷。
HASHr:响应方的杂凑载荷。
HASH_< n >:双方进行协商交互时的中间Hash数据。
SIGi:发起方的签名载荷。
SIGr:响应方的签名载荷。
CERT_sig_r:签名证书载荷。
CERT_enc_r:加密证书载荷。
Ni:发起方的nonce载荷。
Nr:响应方的nonce载荷。
< p >_b:载荷1)< p >的主体。
1) 包括没有ISAKMP通用头的载荷。
pub_i:发起方公钥。
pub_r:响应方公钥。
prv_i:发起方私钥。
prv_r:响应方私钥。
CKY-I:ISAKMP头中的发起方cookie。
CKY-R:ISAKMP头中的响应方cookie。
x|y:x与y串接。
[x]:x为可选。
4.2 缩略语
下列缩略语适用于本文件。
GCM:Galois计数器模式(GaloisCounterMode)
5 密码算法和密钥类别
5.1 密码算法
IPSecVPN使用的非对称密码算法、对称密码算法、密码杂凑算法和随机数生成算法应当符合密
码国家标准、行业标准的相关要求。各算法及使用要求如下。
a) 非对称密码算法应支持SM2椭圆曲线密码算法,用于实体鉴别、数字签名和数字信封。
b) 对称密码算法应支持SM4分组密码算法,用于密钥交换数据的加密保护和报文数据的加密保
护;算法的工作模式应支持CBC或GCM模式。SM4算法的使用应遵循GB/T 32907-2016。
GCM模式的使用应遵循GB/T 36624-2018的机制5。
c) 密码杂凑算法应支持SM3密码杂凑算法,用于完整性校验。SM3算法的使用应遵循
GB/T 32905-2016。
d) 随机数生成算法生成的随机数应符合GM/T 0005-2021的要求,以及GM/T 0062-2018对
E类产品的规定。
5.2 密钥类别
IPSecVPN使用下列类别的密钥。
a) 设备密钥:非对称算法使用的公私钥对,包括签名密钥对和加密密钥对,用于实体验证、数字签
名和数字信封。
注:设备包括硬件实现的产品(如软硬一体硬件产品),也包括纯软件实现的产品(如虚拟机形态产品)。
b) 工作密钥:在密钥交换第一阶段得到的密钥,用于会话密钥交换过程的保护。
c) 会话密钥:在密钥交换第二阶段得到的密钥,用于数据报文的加密和完整性校验。
6 协议
6.1 密钥交换协议
6.1.1 相关函数定义
Asymmetric_Encrypt(msg,pub_key):使用非对称算法Asymmetric,pub_key作为密钥对输入信
息msg_b进行加密,其输出为msg的通用载荷头和密文串接。如SM2_Encrypt(Ski,pub_key)表示使
用SM2算法,使用公钥pub_key对Ski_b进行加密,其输出为Ski的通用载荷头和密文串接。
Asymmetric_Sign(msg,priv_key):使用非对称算法Asymmetric,priv_key作为密钥对msg进行
数字签名。
Symmetric_Encrypt(msg,key):使用对称加密算法Symmetric,key作为密钥对输入信息 msg_b
进行加密,其输出为 msg的通用载荷头和密文串接。如SM4_Encrypt(Ni,key)表示使用SM4算
法,使用key作为密钥对Ni_b进行加密,其输出为Ni的通用载荷头和密文串接。
HASH(msg):使用密码杂凑算法对msg进行数据摘要运算,HASH函数计算出的结果为定长值。
如使用SM3密码杂凑算法对msg进行数据摘要计算,则计算出256位的杂凑值。
PRF(key,msg):使用密钥key,对消息msg进行数据摘要运算,计算结果为定长值。PRF的计算
方法如下:
PRF(key,msg)=HMAC(key,msg)。其中,HMAC基于SM3实现。
6.1.2 交换阶段及模式
6.1.2.1 交换阶段
密钥交换协议定义了协商、建立、修改、删除安全联盟的过程和报文格式。协议报文应使用 UDP
协议500或4500端口进行传输。
密钥交换协议包括第一阶段和第二阶段。
在第一阶段交换中,通信双方建立了一个ISAKMP安全联盟。该安全联盟是协商双方为保护它们
之间的通信而使用的共享策略和密钥。用这个安全联盟来保护IPSec安全联盟的协商过程。一个
ISAKMP安全联盟可以用于建立多个IPSec安全联盟。
在第二阶段交换中,通信双方使用第一阶段ISAKMP安全联盟协商建立IPSec安全联盟,IPSec安
全联盟是为保护它们之间的数据通信而使用的共享策略和密钥。
6.1.2.2 交换模式
本文件定义的密钥交换协议包括两种交换模式:主模式和快速模式,其中:主模式用于第一阶段交
换,实现通信双方的身份鉴别和密钥交换,得到工作密钥,该工作密钥用于保护第二阶段的协商过程;快
速模式用于第二阶段交换,实现通信双方IPSec安全联盟的协商,确定通信双方的IPSec安全策略及会
话密钥。
6.1.3 交换
6.1.3.1 概述
交换使用标准ISAKMP载荷语法、属性编码、消息的超时和重传以及通知消息。
SA载荷采用的载荷封装形式为变换载荷封装在建议载荷中,建议载荷封装在SA载荷中。本文件
不限制发起方可以发给响应方的提议数量,如果第一阶段交换中有多个变换载荷,将多个变换载荷封装
在一个建议载荷中,然后再将它们封装在一个SA载荷中。安全联盟的定义参见附录A的A.21,有关
变换载荷、建议载荷、SA载荷的具体定义见6.1.5。在安全联盟的协商期间,响应方不能修改发起方发
送的任何提议的属性。否则,交换的发起方需终止协商。
6.1.3.2 第一阶段---主模式
主模式的交换过程由6个消息组成。双方身份的鉴别采用数字证书的方式。
本阶段涉及的消息头及载荷的具体内容见6.1.5。
主模式的交换过程见图1。
图1 主模式的交换过程
消息1:发起方向响应方发送一个封装有建议载荷的SA载荷,而建议载荷中又封装有变换载荷。
消息2:响应方发送一个SA载荷以及响应方的签名证书和加密证书,该载荷表明它所接受的发起
方发送的SA提议。SA载荷的具体内容见6.1.5.3。
消息3和消息4:发起方和响应方交换数据,交换的数据内容包括nonce、身份标识(ID)载荷。
Nonce是生成加密密钥和认证密钥所必需的参数;ID是发起方或响应方的标识。这些数据使用临时密
钥Sk进行加密保护,Sk用对方加密证书中的公钥加密保护,并且双方各自对数据进行数字签名。
当使用SM2算法进行加密和数字签名时,应遵循GB/T 35276-2017的要求。
发起方交换的数据如下:
XCHi=Asymmetric_Encrypt(Ski,pub_r)|Symmetric_Encrypt(Ni,Ski)|Symmetric_Encrypt
(IDi,Ski)|CERT_sig_i|CERT_enc_i
SIGi_b= Asymmetric_Sign(Ski_b|Ni_b|IDi_b|CERT_enc_i_b,priv_i)
响应方交换的数据如下:
XCHr= Asymmetric_Encrypt(Skr,pub_i)|Symmetric_Encrypt(Nr,Skr)|Symmetric_
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,计算方法分别如下(下述计算公式中的值0,1,2是单个字节的数
值):
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)
SKEYID_e是ISAKMPSA用来保护其消息机密性所使用的工作密钥。SKEYID_a是ISAKMP
SA用来验证其消息完整性以及数据源身份所使用的工作密钥。SKEYID_d用于会话密钥的产生。
所有SKEYID的长度都由PRF函数的输出长度决定。如果PRF函数的输出长度太短,不能作为
一个密钥来使用,则SKEYID_e应进行扩展。例如,HMAC的一个PRF可产生128位的输出,但密码
算法要求用到大于128位的密钥的时候,SKEYID_e应利用反馈及连接方法加以扩展,直到满足对密钥
长度的要求为止。反馈及连接方法如下:
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运算得到的:
IV= HASH(Ski_b|Skr_b)
HASH算法由消息1和消息2确定。
加密前的消息应进行填充,使其长度等于对称密码算法分组长度的整数倍。所有的填充字节的值
都是0。报头中的消息长度应包括填充字节的长度,因为这反映了密文的长度。
为了鉴别交换,发起方产生HASHi,响应方产生HASHr,计算公式如下:
HASHi=PRF(SKEYID,CKY-I|CKY-R|SAi_b|IDi_b)
HASHr=PRF(SKEYID,CKY-R|CKY-I|SAr_b|IDr_b)
6.1.3.3 第二阶段---快速模式
快速模式交换依赖于第一阶段主模式交换,作为IPSecSA协商过程的一部分协商IPSecSA的安
全策略并衍生会话密钥。快速模式交换的信息由ISAKMPSA来保护,即除了ISAKMP头外,所有的
载荷都要加密。在快速模式中,一个HASH载荷应紧跟在ISAKMP头之后,这个 HASH用于消息的
完整性校验以及数据源身份验证。
在第二阶段,载荷的加密使用对称密码算法的CBC工作模式,第1个消息的IV是第一阶段的最后
一组密文和第二阶段的 MsgID进行HASH运算所得到的:
IV=HASH(第一阶段的最后一组密文|MsgID)
后续的IV是前一个消息的最后一组密文。消息的填充和第一阶段中的填充方式一样。
在ISAKMP头中的 MsgID唯一标识了一个正在进行中的快速模式,而该ISAKMPSA本身又由
ISAKMP头中的cookie来标识。因为快速模式的每个实例使用一个唯一的MsgID,这就有可能基于一
个ISAKMPSA的多个快速模式在任一时间内同时进行。
在快速模式协商中,身份标识ID缺省定义为ISAKMP双方的IP地址,并且没有强制规定允许的
协议或端口号。如果协商双方应指定ID,则双方的身份应作为IDi和IDr被依次传递。响应方的本地
安全策略将决定是否接受对方的身份标识ID。如果发起方的身份标识ID由于安全策略或其他原因没
有被响应方所接受,则响应方应发送一个通知消息类型为INVALID_ID_INFORMATION(18)的通知
载荷。
在通信双方之间有多条隧道同时存在的情况下,身份标识ID为对应的IPSecSA标识并规定通信
数据流进入对应的隧道。本阶段涉及的消息头及载荷的具体内容见6.1.5。
快速模式的交换过程见图2。
图2 快速模式的交换过程
消息1:发起方向响应方发送一个杂凑载荷、一个SA载荷(其中封装了一个或多个建议载荷,而每
个建议载荷中又封装一个或多个变换载荷)、一个nonce载荷和标识载荷。
杂凑载荷中消息摘要的计算方法如下:
HASH_1=PRF(SKEYID_a,MsgID|Ni_b|SA[|IDi|IDr])
消息2:响应方向发起方发送一个杂凑载荷、一个SA载荷、一个nonce载荷和标识载荷。
杂凑载荷中消息摘要的计算方法如下:
HASH_2=PRF(SKEYID_a,MsgID|Ni_b|SA|Nr_b[|IDi|IDr])
消息3:发起方向响应方发送一个杂凑载荷,用于对前面的交换进行鉴别。
杂凑载荷中消息摘要的计算方法如下:
HASH_3=PRF(SKEYID_a,0|MsgID|Ni_b|Nr_b)
最后,会话密钥素材定义为KEYMA......
|