CN110995414A

CN110995414A - 基于国密算法在tls1_3协议中建立通道的方法

Info

Publication number: CN110995414A
Application number: CN201911334828.XA
Authority: CN
Inventors: 林峰; 杨晓宇; 颜海龙; 任新海
Original assignee: China Financial Certification Authority Co ltd
Current assignee: China Financial Certification Authority Co ltd
Priority date: 2019-12-23
Filing date: 2019-12-23
Publication date: 2020-04-10
Anticipated expiration: 2039-12-23
Also published as: CN110995414B

Abstract

本发明公开了一种基于国密算法在TLS1_3协议中建立通道的方法，该方法包括：密钥交换阶段、服务器参数阶段、身份认证阶段。在密钥交换阶段，引入SM2密钥交换算法协商共享密钥，其相对ECDH、ECDSA等国际算法，采用了更安全的机制，在身份认证阶段，SM2相对于RSA算法，SM2算法密钥长度为256位时的加密强度与3072位RSA算法安全性能相近，SM3算法的压缩函数每一轮都使用2个消息字，比现有SHA256算法具有更高的字全性。在对称加密算法中，引入了SM4算法，其采用了32轮非线性迭代结构，计算轮数远远大于AES算法，安全性更强。本发明通过提升作为数据传输安全核心的加密算法，避免了传输过程中密钥的泄露，在很大程度上提高了建立TLS1_3通道的安全性。

Description

基于国密算法在TLS1_3协议中建立通道的方法

技术领域

本发明涉及网络安全技术领域，尤其涉及基于国密算法在TLS1_3协议中建立通道的方法。

背景技术

安全传输层协议(TLS)是互联网上一种应用广泛的安全协议，用于在两个通信应用程序之间提供保密性和数据完整性，是传输层安全的标准。在多年的应用过程中，不断出现针对协议的攻击。因此，提升协议安全性对于协议的普及发展具有重要的意义，而加密算法是数据传输安全与否的核心。

在现有技术中，基于不同的加解密思想出现了多种不同的密码算法，每套密码算法有其独特的处理方式，相互之间往往并不兼容，这导致了基于不同算法的技术或产品无法通用；尤其是，部分密码算法由于安全强度有限，未经有效性认证或严格的安全性检验就在产业中进行应用，近年来越来越多的国际通用密码算法屡屡被破解和被攻击，存在大量的不可控因素，留下各种密码安全隐患。

面对日益严峻的安全形势，国家密码管理局发布了自主可控的国产算法，最常用的三种商用密码算法是SM2算法、SM3算法、SM4算法。SM2是基于椭圆曲线的非对称加密算法，SM3是数据摘要算法，SM4是以16字节为分组的对称块加密算法。

但由于以上国密算法与TLS1_3协议中所利用现有的算法不同，如密钥长度不同，迭代结构不同，不能按照现有的方法将国密算法应用于TLS1_3协议中。

本发明的目的在于提供一种基于国密算法在TLS1_3协议中建立通道的方法，将安全性更高的国密算法应用于TLS1_3协议中，增大数据传输的安全性。

发明内容

本文针对上述现有技术的问题，提供一种基于国密算法在TLS1_3协议中建立通道的方法，在密钥交换阶段，通过采用SM2算法，在密钥交换时即发送SM2曲线的参数和密钥协商时的公钥，即，使用SM2密钥协商发送两个公钥到对端，其中一个公钥在key_share扩展中传输，该公钥每次握手都会重新产生；另一个公钥在新增的SM2_key_share扩展中传输，作为用户公钥使用，通过计算得出共享密钥，并对ServerHello之后的报文进行加密发送，在身份认证阶段引入SM2_SM3签名算法，避免了在握手阶段密钥及所传输的报文内容窃取，增大了数据传输的安全性。

本发明提供的一种基于国密算法在TLS1_3协议中建立通道的方法，用于客户端1与服务器端2之间协商密钥并进行认证，所述方法包括如下步骤：

步聚S1，密钥交换阶段：用于选择加密参数并建立共享密钥，包括：步骤S11，客户端1向服务器端2发送ClientHello报文S11，包含密钥协商参数以及扩展；步骤S12，服务器端2向客户端1回复ServerHello报文，包含选定密钥协商参数及扩展发送给客户端1；

步骤S2，服务器参数阶段：服务器端2发送用于建立其他握手参数给客户端1，包括：步骤S21，服务器端2向客户端1发送Encrypted Extension报文，用于对ClientHello报文的响应；

步骤S3，身份认证：用于验证身份、密钥确认和握手完整性，包括：步骤S31，服务器端2发送Certificate报文给客户端1，用于传递自已的证书信息；步骤S32，服务器端2发送Certificate Verify报文给客户端1，证明自已持有该证书；S33，服务器端2发送Finish报文给客户端1，客户端1发送Finish报文给服务器端2，用于检验握手的完整性并验证双方是否协商出一致密钥；

包括：在步骤S1中，密钥交换阶段客户端1和服务器端2使用SM2密钥交换算法协商产生共享密钥，共享密钥通过HKDF算法导出[sender]_handshake_traffic_secret密钥，[sender]_handshake_traffic_secret密钥通过HKDF算法导出的密钥用于加密的步骤S2及步骤S3的报文。

进一步地，在步骤S21之后，还包括：步骤S22，服务器端2发送CertificateRequest报文给客户端1，用于向客户端1请求证书进行双向认证；

进一步地，在步骤S33，客户端1发送Finish报文给服务器端2之前，还包括：步骤S31’，客户端1向服务器端2发送Certificate报文，用于传递自已的证书信息；步骤S32’：客户端1向服务器端2发送Certificate Verify报文，证明自已持有该证书。

进一步地，在步骤S11中，客户端1的ClientHello报文的扩展包括：supported_groups、key_share；在supported_groups扩展中增加SM2曲线，用于客户端1和服务器端2两端协商指定的曲线类型；在key_share扩展中增加SM2曲线的加密参数；新增SM2_key_share扩展作为使用SM2密钥协商时的用户公钥；

步骤S12中，服务器端2ServerHello报文的扩展包括：key_share；服务器端2中选择的support_group扩展为SM2曲线时，key_share扩展中也增加SM2曲线的加密参数；同时，新增SM2_key_share扩展作为使用SM2密钥协商时的用户公钥。

进一步地，在步骤S1中，服务器端2能够找到接收的一组参数，但客户端1发送的ClientHello报文未包含足够信息时，服务器端2向客户端1发送HelloRetryRequest信息。

进一步地，在步骤S11中，客户端1的ClientHello报文的扩展还包括：signature_algorithms；在signature_algorithms扩展中增加SM2_SM3，作为签名算法用于步骤S3中的身份认证。

进一步地，在signature_algorithms扩展中增加SM2_SM3签名算法时，在步骤S11中客户端1发送的ClientHello报文中发送UID_Zvalue扩展，用于步骤3中身份认证时计算摘要信息。

进一步地，在步骤S11中，客户端1的ClientHello报文中增加UID_Zvalue扩展时，在步骤S2中的步骤S21中，服务器端2向客户端1发送的Encypted Extension报文中，也增加UID_Zvalue扩展。

进一步地，当服务器端2向客户端1发送的Encypted Extension报文中，未增加UID_Zvalue扩展时，使用默认UID_Value。

进一步地，在步骤S11中，客户端1的ClientHello报文的密钥协商参数中包括密码套件，在密码套件中增加TLS_SM4_GCM_SM3，SM4_GCM用于TLS协议中使用的AEAD算法，SM3用于HKDF的哈希算法。

进一步地，在步骤S11中，客户端1在密码套件中增加TLS_SM4_GCM_SM3时，在步骤S12中，服务器端2选定参数时，相应地从密码套件列表中选择TLS_SM4_GCM_SM3。

进一步地，客户端1接收到未提供的密码套件时，使用“illegal_parameter”告警中止流程。

进一步地，在HKDF算法导出密钥的过程中，使用SM3算法。

通过上述技术方案，本发明在密钥交换阶段，通过采用比现有ECDSA、ECDH等国际标准安全机制更强的SM2算法，使用SM2密钥协商发送两个公钥到对端，其中一个公钥在key_share扩展中传输，该公钥每次握手都会重新产生；另一个公钥在新增的SM2_key_share扩展中传输，作为用户公钥使用，通过计算得出共享密钥，并对ServerHello之后的报文进行加密发送，在身份认证阶段引入SM2_SM3加密算法，SM2相对于国际上主流的RSA算法，密钥长度更短，SM3在现有SHA256基础上改进，压缩函数每一轮都使用2个消息字，大大提升了安全性及性能；增加的TLS_SM4_GCM_SM3密码套件中，SM4比现有的对称加密标准AES算法，SM4采用了32轮非线性迭代结构，计算轮数远远大于AES算法，避免了在握手阶段密钥及所传输的报文内容窃取，增大了后续数据传输的安全性。

附图说明

图1为实施例中客户端和服务器端的消息交互过程的时序图。

具体实施方式

下面结合附图和实施例对本发明进行详细阐述。

图1示出了实施例中客户端和服务器端的消息交互过程的时序图。图中，“+”表示上一消息的扩展消息(加粗表示本实施例在原有的扩展上按照扩展规则进行了添加)；“*”表示可选扩展(加粗并加下划线表示本实施例中新添加的扩展)；“{}”表示这些报文是使用从[sender]_handshake_traffic_secret派生出的密钥保护的；“[]”表示这些报文是使用从traffic_secret_N派生出的密钥保护的。

安全信道中使用的密钥参数是由TLS1_3握手协议产生的。TLS1_3握手协议在客户端1(Client)和服务器端2(Server)第一次通信时使用，TLS1_3握手协议允许两端协商协议版本，选择加密算法，可选的相互认证和建立共享的密钥材料。一旦握手完成，两端使用协商的密钥保护应用层数据。

如图1所示，基于国密算法在TLS1_3协议中建立通道的方法，包括以下步骤：

步骤S1：密钥交换：用于选择加密参数并建立共享密钥。此阶段后的所有内容都已加密。

密钥交换消息用来决定客户端1和服务器端2之间的安全功能，并建立包括用于保护握手和数据的通信密钥的共享密钥。

在密钥交换阶段，首先执行步骤S11：客户端1发送ClientHello消息。

当客户端1首次连接到服务器端2时，需要发送ClientHello作为其第一条消息。ClientHello主要包括客户端1支持的协议版本、会话ID、一个随机数、密码套件、压缩算法、以及扩展消息。

在本实施例的示例性代码中，ClientHello消息结构如下：

在TLS1_3中，客户端1需按偏好顺序发送它支持的密码套件(cipher suites)的列表，包括一个AEAD算法和一个用在HKDF中的散列算法。这是客户端1支持的对称密码选项列表。如果列表中包含服务器端2无法识别、不支持或不希望使用的密码套件，则服务器端2必须忽略这些密码套件并照常处理剩余的密码套件。如果客户端1正在尝试建立PSK密钥，那么它应该至少包好一个与PSK相关的哈希的密码套件，本实施例未使用PSK扩展。

在本实施例中，在客户端1在支持的AEAD算法/HKDF哈希对的密码套件列表中增加TLS_SM4_GCM_SM3密码套件。该密码套件定义为表示使用SM4_GCM作为TLS协议中使用的AEAD算法，SM3作为HKDF的哈希算法。

对比现有技术中使用的密码套件TLS_AES_128_GCM_SHA256，SM4作为16字节分组的对称加密算法，对比现行的对称加密标准AES算法，具有相同的密钥长度，都是128bit，但SM4算法采用了32轮非线性迭代结构，而AES只提供10/12/14轮，计算轮数明显增多，因此，SM4算法比现有AES算法更安全。

TLS1_3消息包含tag-length-value编码的扩展结构。每个扩展都包含类型(type)、长度(length)、数据(data)三部分。

在本实施例的示例性代码中，TLS消息包含tag-length-value的扩展结构如下：

在上述扩展结构中：

“extension_type”标识特定的扩展类型。

“extension_data”包含特定扩展类型的信息。

当客户端1发送扩展消息时，“supported_groups”扩展指示客户端1支持密钥交换的命名组，从最优选到最不优选。

在本实施例中，在客户端1支持的(EC)DHE组的“supported_groups”扩展中增加SM2曲线，用于两端协商指定的曲线。

此扩展的“extension_data”字段包含“NamedGroupList”值：

SM2椭圆曲线(SM2DHE)表示对SM2曲线的支持。为支持SM2曲线在该扩展中增加SM2命名曲线，使用0x1045。

由于客户端1支持使用SM2曲线，因此还包含SM2共享参数的“key_share”扩展。即，key_share扩展中增加了SM2曲线的加密参数。

“key_share”扩展名包含端点的加密参数，其结构如下：

Gourp为被交换密钥的命名组；key_exchange为密钥交换信息，该字段的内容由指定的组及其相应的定义确定。

在ClientHello消息中，“key_share”扩展的“extension_data”字段包含“KeyShareClientHello”值，结构如下：

struct{

KeyShareEntry client_shares<0..2^16-1>；

}KeyShareClientHello；

client_shares按客户端1偏好降序提供KeyShareEntry值列表，每个KeyShareEntry值必须对应于“supported_groups”扩展中提供的一个组，并且必须以相同的顺序出现。但是，这些值可以是“supported_groups”扩展的非连续子集。客户端1可以提供任意数量的KeyShareEntry值，每个值代表一组密钥交换参数。每个KeyShareEntry的key_exchange值必须独立生成。客户不得为同一组提供多个KeyShareEntry值。

如果使用(EC)DHE密钥建立，服务器端2在ServerHello中只提供一个KeyShareEntry。该值必须与服务器端2为协商密钥交换选择的客户端1提供的KeyShareEntry值位于同一组中。

客户端1和服务器端2的(EC)DHE参数在KeyShare结构中KeyShareEntry的key_exchange字段中进行编码。对于secp256r1，secp384r1、secp521r1和SM2，内容是以下结构体的序列化值：

在上述结构体中，X和Y分别是网络字节顺序中X和Y值的二进制表示。没有内部长度标记，因此每个数字表示占用与曲线参数暗示的字节一样多的字节。对于P-256，这意味着X和Y中的每一个都使用32字节，必要时在左侧填充零。对于P-384，它们每个需要48字节；对于P-521，它们每个需要66字节。

在本实施例中，SM2曲线参数如下所示，0x0033表示扩展是“key_share”，0x008a表示扩展长度，0x0088表示整个SM2DHE参数的长度，0x0145表示曲线类型，0x0041表示第一个公钥长度，0x04表示非压缩点，紧接着的64字节表示第一个公钥的X和Y值。

在本实施例中，使用SM2密钥协商算法，发送两个公钥到对端，其中一个公钥在key_share扩展中传输，该公钥每次握手重新产生；另一个公钥在SM2_key_share扩展中传输，作为用户公钥使用，因此还添加SM2_key_share扩展并发送该扩展，用于指定SM2DHE密钥交换算法额外的共享参数。由于客户端1发送该扩展，并且服务器端2选择使用SM2DHE参数协商密钥，则服务器端2也需要发送该扩展。

SM2_key_share扩展中使用和Key Share相同的数据结构，扩展类型编码为0xFE02，服务器端2中该扩展使用服务器加密证书的公钥进行填充，即，配置了加密证书则SM2_key_share扩展中的公钥是加密证书的公钥。使用证书对客户端1进行身份认证时，客户端1中该扩展使用加密证书公钥进行填充，如不对客户端1进行身份认证，客户端1中该扩展生成新的SM2DHE密钥交换参数。

在本实施例中，SM2DHE密钥交换参数如下所示：

TLS 1_3的扩展消息中还包括“signature_algorithms”，用于指示客户端1可以接受的签名算法的“signature_algorithms”扩展，即，可以在数字签名中使用哪些签名算法。希望服务器端2通过证书进行身份验证的客户端1必须发送“signature_algorithms”。

在本实施例中，“signature_algorithms”扩展的“extension_data”字段包含一个SignatureSchemeList值：为支持国密算法应添加SM2_SM3签名算法支持，使用0x0C09。

在本实施例中，还新添加uid_zvalue扩展。表示在进行sm2_sm3签名时(ServerAuth阶段的CertificateVerify消息)计算Z值所使用的用户身份标识UID。即，使用签名方的用户身份标识和签名方公钥，通过运算得到Z值，使用Z值和待签名消息，通过SM3运算得到杂凑值H。杂凑值H用于SM2数字签名。

uid_zvalue扩展为可选扩展，如果客户端1使用默认UID(长度为16字节的固定值)，则可以不发送该扩展，服务器端2也不会响应该扩展，双方都使用默认UID。如果客户端1发送该扩展，服务器端2也响应该扩展，那么需要按照扩展中的UID计算Z值；如果服务器端2不响应该扩展，则双方都使用默认UID。

在本实施例中，身份认证阶段引入了SM2_SM3加密算法，SM2作为基于椭圆曲线的非对称加密算法，相对于国际上主流的RSA算法，其密钥长度为256位时的加密强度与3072位RSA算法安全性能相近，SM2相对于国际上主流的RSA算法，密钥长度更短，另外，SM2算法签名、密钥交换方面也不同于ECDSA、ECDH等国际标准，而采取了更安全的机制，在预处理方面，SM2包含了用户的信息，并且哈希算法指定SM3算法，SM3是数据摘要算法，其输出长度为256位，安全性明显高于MD5和SHA-1，SM3在现有SHA256基础上改进，压缩函数每一轮都使用2个消息字，具有更高的字全性。以上详述了增加的扩展消息。存在多种不同类型的扩展时，上述扩展可能以任何顺序出现，但是，当使用PSK扩展时，“pre_shared_key”必须是ClientHello中的最后一个扩展。本实施例为不使用PSK扩展的情况。

在密钥交换阶段，还要执行步骤S12：服务器端2发送ServerHello消息。

如果服务器端2能够根据ClientHello协商一组可接受的握手参数，服务器端2将发送此消息以响应ClientHello消息以继续握手。

服务器端2从ClientHello.cipher_suites中的列表中选择单个密码套件。在本实施例中，服务器端2选择TLS_SM4_GCM_SM3密码套件。

客户端1接收到未提供的密码套件时，必须使用“illegal_parameter”告警中止握手。

在extensions扩展名列表中，ServerHello必须只包含建立加密上下文和协商协议版本所需的扩展。所有TLS 1_3ServerHello消息必须包含“supported_versions”扩展名。本实施例中，服务器端2使用“key_share”扩展并且服务器端2所选择的曲线是SM2曲线。ServerHello还包含SM2曲线共享参数key_share扩展及SM2_key_share扩展。其余扩展在EncryptedExtensions消息中单独发送。

服务器端2能够找到可接受的一组参数，但客户端1发送的ClientHello消息中未包含足够的信息来继续握手，服务器端2将发送HelloRetryRequest消息以响应ClientHello消息。

在以上密钥交换阶段，通过双方发送的参数及用户公钥信息，协商出密钥材料(临时密钥)，使用SM2算法生成共享密钥。

步骤S2：服务器参数：建立其他握手参数。

在随后服务器端2发送的两条消息EncryptedExtensions和CertificateRequest(本实施例中，选择发送此消息)中，包含用于确定握手的其余部分服务器端2的信息。这些消息使用派生自server_handshake_traffic_secret的密钥加密，[sender]_handshake_traffic_secret是通过HDKF由共享密钥导出的。

步骤21：服务器端2发送Encrypted Extensions消息。

服务器端2必须在ServerHello消息之后立即发送EncryptedExtensions消息。这是在server_handshake_traffic_secret派生的密钥下加密的第一条消息，和密钥协商没有关系。

EncryptedExtensions消息包含被保护的扩展，此消息结构如下：

struct{

Extension extensions<0..2^16-1>；

}EncryptedExtensions；

在本实施例中，由于客户端1选用签名算法是SM2_SM3，并且选择了发送UID_Zvalue扩展，扩展中是签名值的UID值。因此，服务器端2的uid_zvalue扩展在该部分的加密扩展中发送。

服务器端2不发送该扩展时，服务器端2和客户端1双方使用国家秘密管理局指定的默认UID进行运算。

UID_Zvalue扩展序列化结构如下：

struct{

opaque UID<1..2^16-1>；

}UID_Zvalue；

在本实施方式中如下所示：

0000 FE 01 |.3|

0002 00 10 |..|

000b 31 32 33 34 35 36 37 38 31 32 33 34 35 36 37 38

|1234567812345678|

步骤22：服务器端2发送Certificate Request消息。

使用证书进行身份验证的服务器端2可以选择向客户端1发送CertificateRequest消息。在本实施例中，选择发送Certificate Request消息。此消息在EncryptedExtensions消息之后由服务器端2进行发送，此时，客户端1需要在后面发送自己的Certificate，并在Certificate消息中包含Certificate Request Context来进行响应。

Certificate Request消息结构如下：

certificate_request_context用于标识证书请求以及将在客户端1的证书消息中回显的字符串。

extensions描述所请求的证书参数的一组扩展。必须指定“signature_algorithms”扩展名。

在以前版本的TLS中，证书请求消息携带了服务器将接受的签名算法和证书颁发机构的列表。在TLS 1_3中，前者通过发送“signature_algorithms”表示，即在本实施例中，需要添加SM2_SM3算法支持。后者通过发送“certificate_authorities”扩展来表示。

步骤S3：身份认证：验证服务器(可选地验证客户端)，并提供密钥确认和握手完整性。

TLS通常使用一组通用的消息进行身份验证，密钥确认和握手完整性：Certificate，CertificateVerify和Finished。这三条消息总是作为握手中的最后一条消息发送。Certificate和CertificateVerify消息仅在某些情况下发送。

Finished消息始终作为Authentication块的一部分发送。这些消息在从[sender]_handshake_traffic_secret派生的密钥下加密。

身份验证消息的计算均需要以下输入：

a，要使用的证书和签名密钥。

b，握手上下文由要包含在transcripthash中的一组消息组成。

c，用于计算MAC密钥的Base key。

基于这些输入，消息将包含：

Certificate，要用于认证的证书以及链中的任何支持证书。

CertificateVerify，基于Transcript-Hash(Handshake Context，Certificate)的签名值。

Finished，使用从Base key派生的MAC密钥的值Transcript-Hash(HandshakeContext，Certificate，CertificateVerify)上的MAC。

下表为每种情况定义了握手上下文和MAC的Base key：

TLS中的许多加密计算都使用了哈希副本(Transcript-Hash)。这个值是通过级联每个包含的握手消息的方式进来哈希计算的，它包含握手消息头部携带的握手消息类型和长度字段，但是不包括记录层的头部。

Transcript-Hash(M1,M2,...MN)＝Hash(M1||M2...MN)作为此规则的一个例外情况，当服务器以HelloRetryRequest响应ClientHello时，ClientHello1的值被包含Hash(ClientHello1)值的握手类型为“message_hash”的特别合成握手消息所取代。

对应具体实现，transcripthash总是以下列顺序获取握手消息的，从第一个ClientHello开始，并只包含如下消息：ClientHello，HelloRetryRequest，ClientHello，ServerHello，EncryptedExtensions，server CertificateRequest，server Certificate，server CertificateVerify，serverFinished，EndOfEarlyData，client Certificate，client CertificateVerify，client Finished。

步骤S31,发送Certificate消息。该消息将端点的证书链传送给对端。

由于商定的密钥交换方法使用证书进行身份验证，服务器端2必须发送Certificate消息。当且仅当服务器端2通过步骤S22发送CertificateRequest消息请求客户端1认证时，客户端1必须在步骤S31’发送Certificate消息。如果服务器端2请求客户端1认证但没有合适的证书可用，则客户端1必须发送不包含证书的Certificate消息(即，“certificate_list”字段长度为0)。Certificate消息结构如下：

certificate_request_context：此消息是对CertificateRequest的响应，返回CertificateRequest消息中的certificate_request_context的值。否则(在服务器认证的情况下)，该字段应为零长度。

certificate_list：这是一个CertificateEntry结构的序列(链)，每个结构都包含一个证书和一组扩展。

Extensions：CertificateEntry的一组扩展值。如果未在加密扩展中协商相应的证书类型扩展(“server_certificate_type”或“client_certificate_type”)，或者协商了X.509证书类型，则每个CertificateEntry都包含DER编码的X.509证书。发送者证书必须是CertificateEntry链表中的第一个。链表中的下一张证书应该可以直接验证上一张证书。

在本实施例中，该部分发送国密证书，并且在Signature_Algorithm中支持SM2_SM3签名算法。考虑到国密双证，以及证书在TLS1_3协议中的作用，无须发送加密证书，仅提供签名证书即可。SM2的密钥交换需要对端提供两个公钥参与运算，其中key_share扩展中的公钥通过每次握手重新生成。如果配置了加密证书，则SM2_key_share扩展中的公钥作为加密证书的公钥。如果没有配置加密证书，则每次握手重新生成两对密钥的公钥，并都在Key_share扩展中传输。

步骤S32，发送CertificateVerify消息。此消息用于明确证明端点拥有与其证书相对应的私钥。CertificateVerify消息还提供了验证到该消息为止握手消息完整性的作用。

服务器端2必须在通过证书进行身份验证时发送此消息。无论何时通过证书进行身份验证，客户端1都必须在步骤S32’发送Certificate Verify消息。发送时，该消息必须紧接在Certificate消息之后并在Finished消息之前。此消息的结构体如下：

algorithm字段指定使用的签名算法，在本实施方式中，signature_algorithms选择SM2_SM3算法支持。签名是使用该算法的数字签名算法。签名中包含的内容是如下所示的哈希输出：

Transcript-Hash(HandshakeContext,Certificate)

数字签名后通过以下级联来计算：

由32(0x20)组成的字符串重复64次；

文本字符串；

单个0字节作为分隔符；

要签名的内容。

服务器端2签名的文本字符串是"TLS 1_3,server CertificateVerify"，客户端1签名的文本字符串是"TLS 1_3,client CertificateVerify"。

Transcript-Hash的值是长度为32的01字节(用来表示是SM3哈希值)，服务器CertificateVerify的数字签名原文的示意性内容如下：

在发送方，计算CertificateVerify消息的signature字段的过程，需要以下作为输入：

-签名原文

-与之前消息中发送的证书相对应的签名私钥

如果CertificateVerify消息是由服务器端2发送的，那么签名算法必须是客户端1的“signature_algorithms”扩展中提供的签名算法。如果由客户端1发送，签名使用的签名算法必须是CertificateRequest消息中“signature_algorithms”扩展supported_signature_algorithms字段中的签名算法之一。

CertificateVerify消息的接收者必须验证签名字段。验证过程需要输入：

-数字签名的原文

-包含在关联证书消息中的最终实体证书中的公钥。

-在CertificateVerify消息的signature字段中接收到的数字签名

由于本实施例的签名算法为SM2_SM3，需要进行带Z值的签名运算。

通过证书进行认证时，服务器端2发送证书和CertificateVerify消息。

步骤S32，发送Finished消息。

Finished消息是身份验证块中的最后一个消息。对提供握手认证和密钥计算至关重要。

接收到Finished消息后必须验证内容的正确性，如果不正确必须通过"decrypt_error"警告终止连接。一旦一方发送了Finished消息并接收验证来自其对方的Finished消息，它就可以开始通过连接发送和接收应用数据。

用于计算Finished消息的密钥是使用HKDF从base key计算得出的。

Finished消息的结构：

verify_data的值计算如下：

使用HKDF算法，以整个握手阶段的报文为输入，计算四次HKDF后得出最终密钥，客户端1和服务器端2开始交换应用层的数据并使用从traffic_secret_N派生出的密钥保护进行保护。

由以上实施例可知，本发明提供的基于国密算法在TLS1_3协议中建立通道的方法，在密钥交换阶段，通过采用比现有ECDSA、ECDH等国际标准安全机制更强的SM2算法，在密钥交换时即发送SM2曲线的参数和密钥协商时的公钥，通过计算得出共享密钥，并对ServerHello之后的报文进行加密发送，在身份认证阶段引入SM2_SM3加密算法，SM2相对于国际上主流的RSA算法，密钥长度更短，SM3在现有SHA256基础上改进，压缩函数每一轮都使用2个消息字，大大提升了安全性及性能；增加的TLS_SM4_GCM_SM3密码套件中，SM4比现有的对称加密标准AES算法，SM4采用了32轮非线性迭代结构，计算轮数远远大于AES算法，避免了在握手阶段密钥及所传输的报文内容窃取，增大了后续数据传输的安全性。

应当理解的是，本发明的上述具体实施方式仅仅用于示例性说明或解释本发明的原理，而不构成对本发明的限制。因此，在不偏离本发明的精神和范围的情况下所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。此外，本发明所附权利要求旨在涵盖落入所附权利要求范围和边界、或者这种范围和边界的等同形式内的全部变化和修改例。

Claims

1.一种基于国密算法在TLS1_3协议中建立通道的方法，用于客户端(1)与服务器端(2)之间协商密钥并进行认证，所述方法包括如下步骤：

步聚1(S1)，密钥交换阶段：用于选择加密参数并建立共享密钥，包括：步骤S11，客户端(1)向服务器端(2)发送ClientHello报文(S11)，包含密钥协商参数以及扩展；步骤S12，服务器端(2)向客户端(1)回复ServerHello报文，包含选定密钥协商参数及扩展发送给客户端(1)；

步骤2(S2)，服务器参数阶段：服务器端(2)发送用于建立其他握手参数给客户端(1)，包括：步骤S21，服务器端(2)向客户端(1)发送Encrypted Extension报文，用于对所述ClientHello报文的响应；

步骤3(S3)，身份认证：用于验证身份、密钥确认和握手完整性，包括：步骤S31，服务器端(2)发送Certificate报文给客户端(1)，用于传递自已的证书信息；步骤S32，服务器端(2)发送Certificate Verify报文给客户端(1)，证明自已持有该证书；步骤S33，服务器端(2)发送Finish报文给客户端(1)，客户端(1)发送Finish报文给服务器端(2)，用于检验握手的完整性并验证双方是否协商出一致密钥；

其特征在于，包括：在所述步骤1(S1)中，密钥交换阶段客户端(1)和服务器端(2)使用SM2密钥交换算法协商产生共享密钥，所述共享密钥通过HKDF算法导出[sender]_handshake_traffic_secret密钥，所述[sender]_handshake_traffic_secret密钥通过HKDF算法导出的密钥用于加密的步骤2(S2)及步骤3(S3)的报文。

2.根据权利要求1所述的方法，其特征在于，在所述步骤S21之后，还包括：步骤S22，所述服务器端(2)发送Certificate Request报文给所述客户端(1)，用于向所述客户端(1)请求证书进行双向认证。

3.根据权利要求2所述的方法，其特征在于，在所述步骤S33，所述客户端(1)发送Finish报文给所述服务器端(2)之前，还包括：步骤S31’：所述客户端(1)向所述服务器端(2)发送Certificate报文，用于传递自已的证书信息；步骤S32’：所述客户端(1)向所述服务器端(2)发送Certificate Verify报文，证明自已持有该证书。

4.根据权利要求1所述的方法，其特征在于，在所述步骤S11中，客户端(1)ClientHello报文的扩展包括：supported_groups、key_share；在所述supported_groups扩展中增加SM2曲线，用于客户端(1)和服务器端(2)两端协商指定的曲线类型；在所述key_share扩展中增加SM2曲线的加密参数；新增SM2_key_share扩展作为使用SM2密钥协商时的用户公钥。

所述步骤S12中，服务器端(2)ServerHello报文的扩展包括：key_share；所述服务器端(2)中选择的所述support_group扩展为SM2曲线时，所述key_share扩展中也增加SM2曲线的加密参数；同时，新增SM2_key_share扩展作为使用SM2密钥协商时的用户公钥。

5.根据权利要求1或4所述的方法，其特征在于，在所述步骤1(S1)中，服务器端(2)能够找到接收的一组参数，但客户端(1)发送的ClientHello报文未包含足够信息时，服务器端(2)向客户端(1)发送HelloRetryRequest信息。

6.根据权利要求4所述的方法，其特征在于，在所述步骤S11中，客户端(1)ClientHello报文的扩展还包括：signature_algorithms；在所述signature_algorithms扩展中增加SM2_SM3，作为签名算法用于步骤3(S3)中的身份认证。

7.根据权利要求6所述的方法，其特征在于，在所述signature_algorithms扩展中增加所述SM2_SM3签名算法时，在所述步骤S11中客户端(1)发送的ClientHello报文中发送UID_Zvalue扩展，用于所述步骤(3)中身份认证时计算摘要信息。

8.根据权利要求7所述的方法，其特征在于，在所述步骤S11中，客户端(1)ClientHello报文中增加UID_Zvalue扩展时，在所述步骤(S2)中的步骤S21中，服务器端(2)向客户端(1)发送的Encypted Extension报文中，也增加UID_Zvalue扩展。

9.根据权利要求6或7之一所述的方法，其特征在于，当服务器端(2)向客户端(1)发送的Encypted Extension报文中，未增加UID_Zvalue扩展时，使用默认UID_Value。

10.根据权利要求1或4所述的方法，其特征在于，在步骤S11中，客户端(1)ClientHello报文的密钥协商参数中包括密码套件，在所述密码套件中增加TLS_SM4_GCM_SM3，SM4_GCM用于TLS协议中使用的AEAD算法，SM3用于HKDF的哈希算法。

11.根据权利要求10所述的方法，其特征在于，在所述步骤S11中，客户端(1)在所述密码套件中增加TLS_SM4_GCM_SM3时，在所述步骤S12中，服务器端(2)选定参数时，相应地从密码套件列表中选择TLS_SM4_GCM_SM3。

12.根据权利要求11所述的方法，其特征在于，客户端(1)接收到未提供的密码套件时，使用“illegal_parameter”告警中止流程。

13.根据权利要求1所述的方法，其特征在于，在所述HKDF算法导出密钥的过程中，使用SM3算法。