CN108650227A - 基于数据报安全传输协议的握手方法及系统 - Google Patents

Abstract

本发明提及一种基于数据报安全传输协议的握手方法及系统，该握手方法包括：客户端发送客户端问候消息至服务端，客户端问候消息中包含有该客户端支持的所有国产商用密码套件列表；服务端接收并且判断客户端问候消息是否携带有一无状态的消息认证码：如果有，利用国产杂凑算法计算得到一消息认证码，与客户端问候消息携带的消息认证码进行对比，以对客户端进行认证；认证后发送一服务端问候消息至客户端，告知客户端自身选择的国产商业密码套件；客户端和服务端按选择的国产商业密码套件更换密钥规格，建立数据传输链路。本发明能够满足我国对信息安全自主可控的需求，充分利用国产加密算法的独有优点，兼容了原有DTLS协议，便于横向扩展。

Description

基于数据报安全传输协议的握手方法及系统

技术领域

本发明涉及数据报安全传输协议领域，属于一种基于数据报安全传输协议的握手方法及系统。

背景技术

近年来出现了许多使用数据报传输的应用程序。这些应用包括实时视频会议，internet电话和在线游戏。这些应用都是延迟敏感的，因而使用了不可靠的数据报传输(UDP)。然而UDP协议本身不具备安全性，UDP协议是不面向连接的不可靠协议，且没有对传输的报文段进行加密，不能保证通信双方的身份认证、消息传输过程中的按序接收、不丢失和加密传送。

数据报传输层安全协议(DTLS)在UDP提供的套接字(socket)之上实现了客户机与服务端双方的握手连接，在握手过程中通过使用PSK或ECC实现了加密，利用cookie验证机制和证书实现了通信双方的身份认证，并且用在报文段头部加上序号，缓存乱序到达的报文段和重传机制实现了可靠传送。在握手完成之后，通信双方可以实现应用数据的安全加密和可靠传输。

随着信息安全上升到国家安全高度，国家有关机关和监管机构站在国家安全和长远战略的高度提出了推动国密算法应用实施、加强行业安全可控的要求。摆脱对国外技术和产品的过度依赖，建设行业网络安全环境，增强我国行业信息系统的“安全可控”能力显得尤为必要和迫切。

密码算法是保障信息安全的核心技术，尤其是通信行业核心领域长期以来都是沿用3DES、SHA-1、RSA等国际通用的密码算法体系及相关标准。DTLS采用的密钥协商算法(例如ECDH、ECDHE、RSA、PSK)、签名算法(例如ECDSA、RSA、PSK)、对称加密(例如AES)、摘要算法(例如AEAD、SHA1、SHA256)是美国所制定的算法标准，不支持国产商用密码算法，不能满足我国对信息安全自主可控的需求。

发明内容

本发明的目的在于提供一种基于数据报安全传输协议的握手方法，适于在客户端和服务端之间建立安全的数据传输链路，该握手方法适用于国产商用密码算法，能够满足我国对信息安全自主可控的需求，充分利用国产加密算法的独有优点，同时，本发明兼容了原有DTLS协议，便于横向扩展。

为达到上述目的，本发明提供如下技术方案：

一种基于数据报安全传输协议的握手方法，适于在客户端和服务端之间建立安全的数据传输链路，包括：

客户端发送用以请求服务端与其握手的客户端问候消息至服务端，所述客户端问候消息中包含有该客户端支持的所有国产商用密码套件列表；

所述服务端接收客户端问候消息，判断所述客户端问候消息是否携带有一无状态的消息认证码：如果有，则利用国产杂凑算法计算得到一消息认证码；

所述服务端将计算得到的消息认证码与所述客户端问候消息携带的消息认证码进行对比，以对所述客户端进行认证；

所述服务端在所述客户端认证通过后发送服务端问候消息至客户端，所述服务端问候消息中包含有所述服务端从所述国产商用密码套件列表中选择的其中一个能够匹配的国产商业密码套件；

所述客户端与所述服务端按选择的国产商业密码套件更换密钥规格，互相认证后在两者之间建立数据传输链路。

在前述方法的基础上，本发明还提及一种基于数据报安全传输协议的握手系统，包括一客户端和一服务端；

所述客户端包括：

用以发送通讯类消息至服务端、以及接收服务端发送的通讯类消息的第一通讯模块；

用以生成客户端问候消息的模块，所述客户端问候消息中包含有该客户端支持的所有国产商用密码套件列表；

用以生成无状态的消息认证码的模块；

用以按选择的国产商业密码套件更换密钥规格，认证后与服务端建立数据传输链路的模块；

所述服务端包括：

用以发送通讯类消息至客户端、以及接收客户端发送的通讯类消息的第二通讯模块；

用以判断接收到的客户端问候消息中是否携带有无状态的消息认证码的模块；

用以利用国产杂凑算法计算得到消息认证码的模块；

用以将计算得到的消息认证码与所述客户端问候消息携带的消息认证码进行对比，以对所述客户端进行认证的模块；

用以生成服务端问候消息的模块，所述服务端问候消息中包含有所述服务端从所述国产商用密码套件列表中选择的其中一个能够匹配的国产商业密码套件；

用以按选择的国产商业密码套件更换密钥规格，认证后与客户端建立数据传输链路的模块。

本发明的有益效果在于：

1)客户端提供服务端其所支持的所有国产商用密码套件列表，服务端从中选择其中一个能够匹配的国产商业密码套件作为后续数据传输的密钥使用，从而使本发明所涉及的数据报安全传输协议能够支持国产商用密码算法，满足我国对信息安全自主可控的需求。

2)采用了国产商用密码算法作为密钥，因而能够充分利用国产加密算法的独有优点。

3)整个握手流程除密钥的选择之外，基本和基于DTLS协议的握手流程类似，能够兼容原有DTLS协议，便于横向扩展。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，并可依照说明书的内容予以实施，以下以本发明的较佳实施例并配合附图详细说明如后。

附图说明

图1为实施例一所提及的基于国产商用密码算法的握手方法的流程图。

图2为本发明所提及的的基于数据报安全传输协议的握手方法的流程图。

图3为本发明所提及的握手过程中客户端和服务端之间通讯方法的流程图。

具体实施方式

下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明，但不用来限制本发明的范围。

在本申请书中：

1.Client Hello：客户端问候消息。客户端将加密设置参数、与cookie有关的数据以及其它一些必要信息(至少包括客户端支持的国产商用密码套件列表)发送到服务端。

2.Server Hello：服务端问候消息。服务端将加密设置参数、与cookie有关的数据以及其它一些必要信息(至少包括从ClientHello消息中找到匹配的国产商业密码套件)发送给客户端。

3.Certificate(服务端发送)：服务端证书消息。服务端发一个证书或一个证书链到客户端，证书链开始于服务端公共钥匙并结束于证明权威的根证书。该证书用于向客户端确认服务端的身份，该消息是可选的。如果服务端需要验证服务端的身份，会发送该消息。

4.CertificateRequest：证书请求消息。如果配置服务端需要验证客户端身份，还要发出请求要求客户端提供客户端证书。

5.ServerKeyExchange：服务端密钥交换消息。服务端向客户端发送一个服务端密钥交换消息。本消息传送的信息用于客户端计算产生48字节的预主密钥。

6.ServerHelloDone：服务端问候完成消息。通知客户端，服务端已经完成了交流过程的初始化。

7.Certificate(客户端发送)：客户端证书消息。客户端发送客户端证书给服务端，仅当服务端请求客户端身份验证的时候会发送客户端证书。

8.ClientKeyExchange：客户端密钥交换消息。客户端产生一个会话密钥与服务端共享，在握手协议完成后，客户端与服务端通信信息的加密就会使用该会话密钥。

9.CertificateVerify：证书校验消息。如果服务端请求验证客户端，则这消息允许服务端完成验证过程。

10.Changecipherspec(客户端发送)：更改密钥规格消息。客户端要求服务端在后续的通信中使用加密模式。

11.Finished(客户端发送)：握手结束消息。客户端告诉服务端已经准备好安全通信了。

12.Changecipherspec(服务端发送)：更改密钥规格消息。服务端要求客户端在后续的通信中使用加密模式。

13.Finished(服务端发送)：握手结束消息。服务端告诉客户端它已经准备好安全通信了，握手完成的标志。

14.Application Data：应用程序数据。客户端和服务端在安全信道上进行加密信息的交流。

本发明提及一种基于数据报安全传输协议的握手方法，适于在客户端和服务端之间建立安全的数据传输链路，该握手方法适用于国产商用密码算法。

结合图1、图2、图3，本发明将通过一些具体的实施例来详细阐述此种基于数据报安全传输协议的握手方法的具体工作流程。

图3中的*表示可选或依赖于上下文关系的消息，不是每次都发送。

实施例一

假设该握手方法在客户端1和服务端1之间进行，客户端1请求与服务端1建立一数据传输链路，并且后续客户端1与服务端1之间传输的数据均需采用一国产商用密码算法加密，则客户端1与服务端1的握手流程如下：

S101、客户端1发送一用以请求服务端1与其握手的客户端问候消息至服务端1，所述客户端1问候消息中包含有该客户端支持的所有国产商用密码套件列表以供服务端选择。

S102、服务端1接收客户端问候消息，认证后发送一服务端问候消息至客户端1，所述服务端问候消息中包含有服务端1从所述国产商用密码套件列表中选择的其中一个能够匹配的国产商业密码套件。

S103、客户端1和服务端1按选择的国产商业密码套件更换密钥规格，互相认证后在两者之间建立一数据传输链路，客户端1和服务端1发送的数据均采用选择的国产商业密码套件加密后再通过前述数据传输链路传输给对方。

由该实施例一可知，这一握手方法能够实施的前提是客户端1和服务端1均支持最终选择的国产商业密码套件。

客户端1和服务端1的前述握手流程，除需要通过在问候消息中携带国产商业密码套件的相关信息以确认之后需要采用的加密方式外，其他的问候流程、认证流程、更换密钥流程、建立数据传输链路的流程均可以借鉴现有基于DTLS协议的握手流程，因此本发明提出的这一握手方法能够兼容原有DTLS协议，便于后续的横向扩展。

在前述实施例一中提及的国产商用密码套件，可以由用户根据实际需求自行定义。

在一些例子中，S101中所提及的所述国产商用密码套件是客户端与服务端协商后续密钥交换算法、加密算法、校验算法的合集。例如密码套件SM2_SM4_SM3,表示后续的密钥交换算法使用SM2、加密算法使用SM4、校验算法使用SM3。实际上，密码套件的选择是整个数据报通信安全的基础。

至于密钥交换算法、加密算法、校验算法的选择，可以遵循以下规则：

1)所述密钥交换算法采用SM2算法、SM9算法、以及符合国家密码管理主管部门要求的RSA算法中的任意一种。RSA算法属于国际通过的密码算法体系，因此在选择使用时应当更为慎重，根据实际需求选择符合国家密码管理主管部门要求的RSA算法。

国产SM2算法基于椭圆曲线，在相同安全性下，相对于RSA所要更少的密钥长度，并且加解密速度更快。

SM9算法是基于用户标识的密钥交换算法(IBSDH)和加密算法(IBC)，原有算法套件不支持此种基于用户标识的算法。

2)所述加密算法采用SM1算法、SM4算法中的任意一种。为了确保满足我国对信息安全自主可控的需求，其中，加密算法必须采用SM1算法或者SM4算法，而不能采用其他算法。

SM1为对称加密，该算法不公开，调用该算法时，需要通过加密芯片的接口进行调用。

SM4为无线局域网标准的分组数据算法，同样属于对称加密。SM4分组密码算法是我国自主设计的分组对称密码算法，用于实现数据的加密/解密运算，以保证数据和信息的机密性。

要保证一个对称密码算法的安全性的基本条件是其具备足够的密钥长度，SM1算法、SM4算法与AES算法具有相同的密钥长度分组长度，即128比特，因此在安全性上高于3DES算法。

国产SM4算法在计算过程中增加非线性变换，理论上能大大提高其算法的安全性，并且由专业机构进行了密码分析，结论为安全性较高。

由于SM1、SM4加解密的分组大小为128bit，故对消息进行加解密时，若消息长度过长，需要进行分组，若消息长度不足，则要进行填充。

3)所述校验算法采用SM3算法、SHA1算法中的任意一种，其中，SM3算法属于国家商用密码算法，而SHA1算法属于非国密算法。

SM3算法的压缩函数与SHA-256的压缩函数具有相似的结构，但是SM3算法的设计更加复杂，比如压缩函数的每一轮都使用2个消息字。迄今为止，SM3算法的安全性相对较高。

上述SM1算法、SM2算法、SM3算法、SM4算法、SM9算法主要为我国自主研制算法，优点是自主安全可控，能够逐步摆脱对国外密码技术和产品的过度依赖。国密算法中签名证书与加密证书分离使用，安全性更高。

因此，由前述可知，由于客户端1和服务端1发送的数据均采用双方共同选择的国产商业密码套件加密后再传输至对方，一方面能够满足我国对信息安全自主可控的需求，另一方面也能够充分利用国产加密算法的独有优点。

应当理解，要实现前述目的，客户端1和服务端1共同选择的国产商业密码套件的三个参数(密钥交换算法、加密算法、校验算法)中，至少其中一个参数应当采用国密算法。

实施例二

假设该握手方法在客户端2和服务端2之间进行，客户端2请求与服务端2建立一数据传输链路，客户端2和服务端2需要通过一种方式以确定后续数据传输时采用的主密钥规格，则客户端2与服务端2的握手流程如下：

S201、客户端2发送一用以请求服务端2与其握手的客户端问候消息至服务端2，所述客户端2问候消息中包含有该客户端支持的所有国产商用密码套件列表以供服务端选择。

S202、服务端2接收客户端问候消息，认证后依次发送一服务端问候消息和一服务端密钥交换消息至客户端2，其中：

所述服务端问候消息中包含有服务端2从所述国产商用密码套件列表中选择的其中一个能够匹配的国产商业密码套件。

所述服务端密钥交换消息用以使得客户端计算产生一预主密钥。

预主密钥是客户端和服务端在key exchange阶段产生的结果，是计算主密钥的材料，而主密钥是后续数据加密的密钥来源。

S203、所述客户端响应于所述服务端密钥交换消息，发送一用以请求服务端更改密钥规格的客户端密钥交换消息至服务端，客户端密钥交换消息中包含预主密钥和/或计算预主密钥的必要条件。

S204、客户端2和服务端2按选择的国产商业密码套件更换密钥规格，互相认证后在两者之间建立一数据传输链路，客户端2和服务端2发送的数据均采用选择的国产商业密码套件加密后再通过前述数据传输链路传输给对方。

关于S203中所提及的计算预主密钥的必要条件，如果密钥交换算法使用SM2加密算法、SM9算法和RSA算法，服务端产生随机数和服务端的密钥交换参数通过server keyexchange消息传递给客户端，然后预主密钥由客户端产生，采用服务端的加密公钥进行加密，经client key exchange阶段传递给服务端，当服务端收到加密后的预主密钥后，利用相应的私钥进行解密，即可获得预主密钥的明文。

如果密钥交换算法使用SM2密钥交换算法ECDH算法，则握手双方在keyexchange阶段交换密钥计算参数，然后根据己端和对端发送的参数按照密钥交换算法产生预主密钥。

优选的，所述预主密钥采用48字节。

实际上，发送服务端密钥交换消息是基于国产商用密码算法的数据报安全传输协议的的握手流程中必须的一步，通过一双向加密解密的过程实现双方数据传输时采用主密钥的协商和确定。具体的，服务端用私钥加密一消息/文件后将之发送至客户端，客户端接收该消息/文件，用公钥解密，该公钥可以从服务端发送的消息/文件中获取，继而客户端发送一采用前述公钥加密后的预主密钥至服务端，服务端接收预主密钥，采用私钥解密。

下面通过一个具体的例子来说明这一双向加密解密过程。

服务端2接收客户端问候消息，认证后依次发送一服务端问候消息、一服务端证书消息、一服务端密钥交换消息至客户端2，其中，服务端证书消息用以向客户端2确认服务端2的身份，该消息是可选的，如果客户端2需要验证服务端2的身份，服务端2会发送该消息，否则不发送。

服务端2采用公钥将该服务端证书消息加密后发送至客户端2，客户端2接收加密后的服务端证书消息，从加密证书中获取服务端2提供的公钥，继而生成一预主密钥，采用获取的公钥加密后发送至服务端2，服务端2接收预主密钥，采用私钥解密，实现主密钥的协商和确认。

至于服务端密钥交换消息、客户端密钥交换消息、服务端证书消息所包含的内容及其对应的消息结构，具体如下：

(一)服务端密钥交换消息的消息结构

服务端密钥交换消息的消息结构和选择采用的国产商用密码套件相关，具体规则如下：

a)当使用SM2的ECDH算法交换密钥时，服务端密钥交换消息的消息结构如下:

其中，ServerECDHEParams为服务端的密钥交换参数，交换的参数见GM/T 0009，其中服务端的公钥不需要交换，客户端直接从服务端的加密证书中获取。ServerECDHEParamsd的结构如下：

使用SM2算法时，ECParameters为推荐曲线参数，此参数不校验。

signed_params是服务端对双方随机数和服务端密钥交换参数的签名。

b)当使用SM2的ECC算法交换密钥时，服务端密钥交换消息的消息结构如下:

其中ASN.1Cert为符合ASN.1编码规范的证书。signed_params是服务端对双方随机数和服务端的加密证书的签名。

c)当使用SM9的IBSDH算法时，服务端密钥交换消息的消息结构如下:

使用SM9的IBSDH算法时，ServerIBSDHParams为服务端的密钥交换参数，密钥交换参数格式见SM9算法。signed_params是服务端对双方随机数和服务端密钥交换参数的签名。

d)当使用SM9的IBC算法时，服务端密钥交换消息的消息结构如下:

其中ServerIBCParams为服务端的密钥交换参数，其格式参见SM9算法。IBCEncryptionKey为服务端的加密公钥，长度为1024字节。signed_params是服务端对双方随机数和服务端密钥交换参数的签名。

e)当使用RSA算法时，服务端密钥交换消息的消息结构如下:

其中signed_params是服务端对双方随机数和服务端的加密证书的签名。

(二)客户端密钥交换消息所包含的内容及其消息结构

客户端密钥交换消息中包含的内容由密钥交换算法决定，具体规则如下：

1)如果密钥交换算法采用RSA算法、ECC算法、以及IBC算法中的任意一种，客户端密钥交换消息中包含有预主密钥，该预主密钥由客户端产生，采用服务端的加密公钥以加密。当服务端收到加密后的预主密钥后，利用相应的私钥进行解密，获取所述预主密钥的明文。

例如，如果密钥交换算法采用IBC算法，客户端根据获取的服务端和IBC公开参数以生成服务端公钥。

再例如，如果密钥交换算法采用RSA算法，客户端采用RSA公钥密码体系对RSA加密后的密文进行编码以生成服务端公钥。优选的，选择采用pkcs#1rsa加密版本1.5对RSA加密后的密文进行编码。

2)如果密钥交换算法采用ECDHE算法或SM9算法，客户端密钥交换消息中包含有计算预主密钥的客户端密钥交换参数。

客户端密钥交换消息的消息结构与密钥交换算法相关，具体定义如下:

A)如果密钥交换算法使用SM2的ECDH算法，则客户端密钥交换消息的消息结构为:

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

其中ClientECDHParams的结构如下：

SM2算法中曲线参数使用推荐曲线，所以第一个字段不校验。

B)如果密钥交换算法使用SM9的IBSDH算法，则客户端密钥交换消息的消息结构为:

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

其中ClientIBSDHParams为客户端的密钥交换参数。

C)如果密钥交换算法使用SM2的ECC算法，则客户端密钥交换消息的消息结构为:

opaque ECCEncryptedPreMasterSecret<0..2^16-1>；

其中ECCEncryptedPreMasterSecret为用服务端公钥加密的预主密钥。

D)如果密钥交换算法使用sm9的IBC算法，则客户端密钥交换消息的消息结构为:

opaque IBCEncryptedPreMasterSecret<0..2^16-1>；

其中IBCEncryptedPreMasterSecret为用服务端公钥加密的预主密钥。

E)如果密钥交换算法使用RSA算法，则客户端密钥交换消息的消息结构为:

opaque RSAEncryptedPreMasterSecret<0..2^16-1>；

其中RSAEncryptedPreMasterSecret为用服务端公钥加密的预主密钥。

上述C)、D)、E)的预主密钥的数据结构如下:

其中client_version是客户端所支持的版本号。服务端要检查这个值是否跟客户端Hello消息中所发送的值相匹配。random[46]是46字节的随机数。

(三)服务端证书消息所包含的内容及其消息结构

所述服务端证书消息包含有一服务端证书。

如果服务端问候消息中包含的国产商业密码套件采用RSA算法或SM2算法，服务端证书消息包含的服务端证书采用服务端的签名证书和加密证书；如果服务端问候消息中包含的国产商业密码套件采用SM9算法，服务端证书消息包含的服务端证书采用服务端标识和SM9公共参数。

当选中的密码套件使用RSA或SM2算法时，服务端证书消息的内容为服务端的签名证书和加密证书，服务端证书消息的消息结构如下:

opaque ASN.1Cert<1..2^24-1>；

struct{

ASN.1Cert certificate<1..2^24-1>；

}Certificate；

其中，opaque表示任意数据类型的一个字节；ASN.1Cert表示符合ASN.1编码的证书；<1..2^24-1>表示证书所占opaque的个数为1..2^24-1；struct结构里表示有1..2^24-1个证书,至少有一个证书。

当选中的密码套件使用SM9时，其消息内容为SM9标识及公共参数，其结构如下:

其中，sm9_id为服务端标识，parameter为公共参数，遵循ASN.1编码。

在实际应用中，服务端2继服务端密钥交换消息之后还发送有一服务端问候完成消息，服务端问候完成消息表示握手过程的问候消息阶段完成，发送完该消息后服务端会等待客户端的响应消息。客户端接收到服务端问候完成消息之后，应验证服务端证书是否有效，并检验服务端的服务端问候消息是否可以接受。

实施例三

假设该握手方法在客户端3和服务端3之间进行，客户端3与服务端3的握手流程如下：

S301、客户端3发送一用以请求服务端3与其握手的客户端问候消息至服务端3，所述客户端3问候消息中仅包含有该客户端支持的所有国产商用密码套件列表以供服务端选择。

S302、服务端3接收客户端问候消息，判断客户端问候消息是否携带有一无状态的消息认证码。

S303、如果服务端3接收到客户端问候消息中携带有无状态的消息认证码，服务端3利用国产杂凑算法计算得到一消息认证码，将计算得到的消息认证码与所述客户端问候消息携带的消息认证码进行对比，以对所述客户端3进行认证。

S304、服务端3认证通过后发送一服务端问候消息至客户端3，所述服务端问候消息中包含有服务端3从所述国产商用密码套件列表中选择的其中一个能够匹配的国产商业密码套件。

S305、客户端3和服务端3按选择的国产商业密码套件更换密钥规格，互相认证后在两者之间建立一数据传输链路。

而如果客户端问候消息中没有携带无状态的消息认证码，整个握手流程将会增加如下步骤：

S302’、服务端3发送一问候验证请求消息至客户端3，请求客户端3重新发送携带无状态的消息认证码的客户端问候消息，该问候验证请求消息中包含一无状态的消息认证码。

客户端3响应于服务端3发送的问候验证请求消息，发送一新的客户端问候消息至服务端3，新的客户端3问候消息中除包含有该客户端支持的所有国产商用密码套件列表以供服务端选择之外，还包括前述无状态的消息认证码。

当服务端3判断接收到的新的客户端问候消息携带有一无状态的消息认证码时，将协同客户端3继续执行S303至S305。

在本发明中，提出在客户端问候消息中携带一无状态的cookie(消息认证码)，原因如下：

数据报协议因为是面向无连接的协议，对拒绝服务攻击非常敏感。例如，a.攻击者可以通过发送一系列握手启动请求来消耗服务端上的过多资源，从而导致服务端分配状态并潜在地执行昂贵的加密操作。b.攻击者可以使用服务端作为放大器，通过发送连接启动消息与伪造的受害者的来源。然后，服务端将其下一个消息(在DTLS中，证书消息可能相当大)发送到受害机器，从而使其泛滥。

而使用cookie的过程如下：

当客户端3向服务端3发送一个客户端问候消息时，若该客户端问候消息中没有携带无状态的消息认证码，服务端3生成一个随机数然后结合客户端3的IP地址信息和由客户端问候消息携带的信息通过HMAC-SM3算法计算出一个消息认证码(Cookie值)。这个消息认证码随问候验证请求消息发送给客户端3，客户端3需要使用第一次发送客户端问候消息时的信息(版本，随机数，会话ID，密码套件，压缩方法)重新发送一个新的客户端问候消息(同时携带cookie值)。服务端3根据客户端3发送来的信息重新使用HMAC-SM3算法计算出一个消息认证码，并和随客户端问候消息携带过来的消息认证码做对比，如果一致，则继续进行握手，否则，停止当前握手流程。

如果客户端3向服务端3发送的第一个客户端问候消息携带有无状态的消息认证码，服务端3直接对其进行认证，认证通过后继续进行握手流程。

所述cookie具有多种表现形式，其中一种表现形式为HMAC-SM3(Secret,Client-IP,Client-Parameters)。其中，HMAC-SM3为使用国产杂凑算法的哈希运算消息认证码，Secret为随机数，Client-IP为客户端IP地址，Client-Parameters为ClientHello携带的参数。

所述HMAC-SM3算法的实现是用国产散列算法SM3作为HMAC的散列函数。

不管是ClientHello消息中携带的cookie，还是HelloVerfyRequest消息中携带的cookie，均可以采用前述表现形式。

实施例四

假设该握手方法在客户端4和服务端4之间进行，服务端4请求验证客户端4，客户端4与服务端4的握手流程增加步骤如下：

服务端4响应于认证完成客户端问候消息，发送一证书请求消息至客户端4以请求验证客户端证书。

所述客户端4同时响应于接收到的服务端证书有效、服务端问候消息可接受、以及证书请求消息，依次发送一客户端证书消息、客户端密钥交换消息、一证书校验消息至服务端4。

这一过程为可选择的，非必要流程。

客户端4还向服务端4发送一证书校验消息，证书校验消息用于鉴别客户端4是否为证书的合法持有者，只有客户端证书消息发送时才发送此消息，紧跟于客户端密钥交换消息之后。

关于证书请求消息、客户端证书消息、证书校验消息的消息结构，具体如下：

(一)证书请求消息的消息结构

证书请求消息的结构定义如下:

其中certificate_types是要求客户端提供的证书类型的列表。列表如下：

enum{

ras_sign(1),ecdsa_sign(64),ibc_params(80)

}ClientCertificateType；

如果ClientCertificateType是ibc_params,则certificate_authorities字段的内容是IBC密钥管理中心的信任域名列表。否则时服务端信任的CA的证书DN列表，包括根CA或者二级CA的DN。定义如下:

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

(二)客户端证书消息的消息结构

客户端4响应于证书请求消息，向服务端4发送一客户端证书消息。当协商的密码套件使用SM9算法时，此消息的内容为客户端标识和SM9公共参数，用于客户端4与服务端4协商SM9公开参数。

客户端证书消息的结构与前述服务端证书消息的结构相同。

(三)证书校验消息的消息结构

证书校验消息的数据结构如下:

struct{

Signature signature；

}CertificateVerify；

其中，Signature的结构如下:

a.当签名算法使用rsa_sha1时，证书校验消息的结构为:

digitally-signed struct{

opaque sha1_hash[20]；

}；

b.当签名算法使用rsa_sm3时，证书校验消息的结构为:

digitally-signed struct{

opaque sm3_hash[32]；

}；

c.当签名算法使用ecc_sm3时(当ECC使用SM2时使用这个签名算法)，证书校验消息的结构如下:

digitally-signed struct{

opaque sm3_hash[32]；

}；

d.当签名算法使用ibs_sm3时，证书校验消息的结构如下:

digitally-signedstruct{

opaque sm3_hash[32]；

}

上述sm3_hash和sha1_hash是指hash运算的结果，运算的内容时自客户端Hello消息开始直到本消息为止(不包括本消息)的所有与握手有关的消息(加密证书要包在签名计算中)，包括握手消息的类型和长度域。当使用SM2算法签名时，使用客户端的签名密钥。

实施例五

在完成国产商业密码套件的互相选择、确认和更改(该步骤可由前述实施例一至实施例四中所提及的方式实现)之后，客户端和服务端需要再次发送消息告知对方自身状态，同时也需确认对方是否已经完成密码规格的修改。

所述握手方法还包括：

客户端和服务端更改各自的密码规格后，分别向对方发送一握手结束消息(Finished消息)以验证本次客户端和服务端之间密钥交换过程的成功性、以及校验本次握手流程的完整性。

服务端和客户端各自在密码规格变更消息之后向对方发送本消息，用于验证密钥交换过程是否成功，并校验握手过程的完整性，因此握手结束消息的接收方必须检验消息内容的正确性。

优选的，握手结束消息采用本次握手过程协商出的算法和密钥保护。

客户端和服务端分别向对方发送一握手结束消息、并且验证客户端和服务端之间密钥交换过程成功后，在客户端和服务端之间建立一数据传输链路。

握手结束消息的数据结构如下:

struct{

opaque verify_data[12]；

}Finished；

其中，verify_data为校验数据，该数据产生的方法如下:

PRF(master_secret,finished_label,SM3(handshake_messages))[0..11].

表达式中的两个概念具体解释如下:

1)finished_label:

对于由客户端发送的结束消息，该标签时字符串”client finished”。对于服务端，该标签时字符串”server finished”。

2)handshake_message:

指自客户端问候消息开始直到本消息为止(不包括本消息、密码规格变更消息)的所有与握手有关的消息，包括握手消息的类型和长度域。

在前述方法的基础上，本发明还提及一种基于数据报安全传输协议的握手系统，包括一客户端和一服务端；

所述客户端包括：

用以发送通讯类消息至服务端、以及接收服务端发送的通讯类消息的第一通讯模块；

用以生成客户端问候消息的模块，所述客户端问候消息中包含有该客户端支持的所有国产商用密码套件列表；

用以生成无状态的消息认证码的模块；

用以按选择的国产商业密码套件更换密钥规格，认证后与服务端建立数据传输链路的模块；

所述服务端包括：

用以发送通讯类消息至客户端、以及接收客户端发送的通讯类消息的第二通讯模块；

用以判断接收到的客户端问候消息中是否携带有无状态的消息认证码的模块；

用以利用国产杂凑算法计算得到消息认证码的模块；

用以将计算得到的消息认证码与所述客户端问候消息携带的消息认证码进行对比，以对所述客户端进行认证的模块；

用以生成服务端问候消息的模块，所述服务端问候消息中包含有所述服务端从所述国产商用密码套件列表中选择的其中一个能够匹配的国产商业密码套件；

用以按选择的国产商业密码套件更换密钥规格，认证后与客户端建立数据传输链路的模块。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (11)

1.一种基于数据报安全传输协议的握手方法，其特征在于，包括：

客户端发送用以请求服务端与其握手的客户端问候消息至服务端，所述客户端问候消息中包含有该客户端支持的所有国产商用密码套件列表；

所述服务端接收客户端问候消息，判断所述客户端问候消息是否携带有一无状态的消息认证码：如果有，则利用国产杂凑算法计算得到一消息认证码；

所述服务端将计算得到的消息认证码与所述客户端问候消息携带的消息认证码进行对比，以对所述客户端进行认证；

所述服务端在所述客户端认证通过后发送服务端问候消息至客户端，所述服务端问候消息中包含有所述服务端从所述国产商用密码套件列表中选择的其中一个能够匹配的国产商业密码套件；

所述客户端与所述服务端按选择的国产商业密码套件更换密钥规格，互相认证后在两者之间建立数据传输链路。

2.根据权利要求1所述的基于数据报安全传输协议的握手方法，其特征在于，所述国产商用密码套件包括：一密钥交换算法、一加密算法和一校验算法；

所述密钥交换算法采用SM2算法、SM9算法、以及RSA算法中的任意一种；

所述加密算法采用SM1算法、SM4算法中的任意一种；

所述校验算法采用SM3算法、SHA1算法中的任意一种。

3.根据权利要求2所述的基于数据报安全传输协议的握手方法，其特征在于，所述握手方法还包括：

所述服务端响应于认证完成客户端问候消息，继服务端问候消息之后发送一服务端密钥交换消息至客户端，所述服务端密钥交换消息用以使得客户端计算产生一预主密钥。

4.根据权利要求3所述的基于数据报安全传输协议的握手方法，其特征在于，所述握手方法还包括：

所述客户端响应于所述服务端密钥交换消息，发送一用以请求服务端更改密钥规格的客户端密钥交换消息至服务端，客户端密钥交换消息中包含预主密钥和/或计算预主密钥的必要条件。

5.根据权利要求4所述的基于数据报安全传输协议的握手方法，其特征在于，当所述密钥交换算法采用RSA算法、ECC算法、以及IBC算法中的任意一种时，客户端密钥交换消息中包含有预主密钥，该预主密钥采用服务端的加密公钥以加密；

或者，当所述密钥交换算法采用ECDHE算法或SM9算法时，客户端密钥交换消息中包含有计算预主密钥的客户端密钥交换参数。

6.根据权利要求5所述的基于数据报安全传输协议的握手方法，其特征在于，所述握手方法还包括：

当所述密钥交换算法采用IBC算法时，客户端根据获取的服务端和IBC公开参数以生成服务端公钥；

当所述密钥交换算法采用RSA算法时，客户端采用RSA公钥密码体系对RSA加密后的密文进行编码以生成服务端公钥。

7.根据权利要求1-6任意一项所述的基于数据报安全传输协议的握手方法，其特征在于，所述握手方法还包括：

所述服务端响应于认证完成客户端问候消息，继服务端问候消息之后发送一用以使客户端对其进行认证的服务端证书消息至客户端；

其中，如果服务端问候消息中包含的国产商业密码套件采用RSA算法或SM2算法，服务端证书消息包含的服务端证书采用服务端的签名证书和加密证书；

如果服务端问候消息中包含的国产商业密码套件采用SM9算法，服务端证书消息包含的服务端证书采用服务端标识和SM9公共参数。

8.根据权利要求1所述的基于数据报安全传输协议的握手方法，其特征在于，所述握手方法还包括：

所述服务端响应于接收到的客户端问候消息中未携带无状态的消息认证码，发送一问候验证请求消息至客户端，请求客户端重新发送携带无状态的消息认证码的客户端问候消息，该问候验证请求消息中包含一无状态的消息认证码。

9.根据权利要求1或8所述的基于数据报安全传输协议的握手方法，其特征在于，所述消息认证码的格式为HMAC-SM3(Secret,Client-IP,Client-Parameters)；

其中，HMAC-SM3为使用国产杂凑算法的哈希运算消息认证码，Secret为随机数，Client-IP为客户端IP地址，Client-Parameters为客户端问候消息携带的参数。

10.根据权利要求1-6任意一项所述的基于数据报安全传输协议的握手方法，其特征在于，所述握手方法还包括：

服务端响应于认证完成客户端问候消息，发送一证书请求消息至客户端以请求验证客户端证书；

所述客户端同时响应于接收到的服务端证书有效、服务端问候消息可接受、以及证书请求消息，依次发送一客户端证书消息、客户端密钥交换消息、一证书校验消息至服务端。

11.一种基于数据报安全传输协议的握手系统，其特征在于，包括一客户端和一服务端；

所述客户端包括：

用以发送通讯类消息至服务端、以及接收服务端发送的通讯类消息的第一通讯模块；

用以生成客户端问候消息的模块，所述客户端问候消息中包含有该客户端支持的所有国产商用密码套件列表；

用以生成无状态的消息认证码的模块；

用以按选择的国产商业密码套件更换密钥规格，认证后与服务端建立数据传输链路的模块；

所述服务端包括：

用以发送通讯类消息至客户端、以及接收客户端发送的通讯类消息的第二通讯模块；

用以判断接收到的客户端问候消息中是否携带有无状态的消息认证码的模块；

用以利用国产杂凑算法计算得到消息认证码的模块；

用以将计算得到的消息认证码与所述客户端问候消息携带的消息认证码进行对比，以对所述客户端进行认证的模块；

用以生成服务端问候消息的模块，所述服务端问候消息中包含有所述服务端从所述国产商用密码套件列表中选择的其中一个能够匹配的国产商业密码套件；

用以按选择的国产商业密码套件更换密钥规格，认证后与客户端建立数据传输链路的模块。