CN110839240B - 一种建立连接的方法及装置 - Google Patents
一种建立连接的方法及装置 Download PDFInfo
- Publication number
- CN110839240B CN110839240B CN201810942598.4A CN201810942598A CN110839240B CN 110839240 B CN110839240 B CN 110839240B CN 201810942598 A CN201810942598 A CN 201810942598A CN 110839240 B CN110839240 B CN 110839240B
- Authority
- CN
- China
- Prior art keywords
- client
- server
- key
- verification
- session
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本申请提供了一种建立连接的方法及装置，涉及通信技术领域。本申请通过向服务器发送握手请求报文，以使服务器根据握手请求报文的扩展字段中的客户端密钥标识和客户端验证码对客户端进行验证，接收服务器返回的握手应答报文，根据握手应答报文的扩展字段中的服务器验证码对服务器进行验证，从而建立与服务器之间的安全会话通道。在认证握手开始阶段就进行双方身份的验证，有效防止了流量攻击；且基于预制的共享密钥生成验证码，基于验证码进行客户端和服务器双方的身份验证，则无需再通过证书进行身份验证，减小协议对设备资源和运算能力的需求；通过对握手请求报文和握手应答报文的字段进行扩展，可减少了握手过程中的报文数量。
Description
技术领域
本申请涉及通信技术领域，特别是涉及一种建立连接的方法及装置。
背景技术
随着IoT(Interent of things，物联网)的快速发展，信息安全问题也得了越来越多的重视，为了保证通信数据的安全，需要保证链路的双向验证，建立安全通道，保证数据的私密性、完整性和不可抵赖性。
在传统的互联网领域，一般可在HTTP(HyperText Transfer Protocol，超文本传输协议)中加入TLS(Transport Layer Security，安全传输层协议)，建立客户端与服务器之间的安全通道，当采用标准的TLS协议应用于物联网时，可基于物联网客户端与物联网服务器之间的握手建立安全通道，具体的过程如下：A1、客户端向服务器发送握手请求报文Client Hello，在握手请求报文中包含有客户端生成的客户端随机数；A2、服务器在接收到握手请求报文后，将握手应答报文Server Hello返回至客户端，该握手应答报文中包括有服务器生成的服务器随机数；A3、服务器向客户端下发证书；A4、服务器向客户端发送Server Hello Done报文，通知客户端Server Hello过程结束；A5、客户端在接收到服务器下发的证书后，先验证证书的合法性，验证通过后取出证书中的公钥(即共享密钥)，通过公钥非对称加密随机数Random生成Pre-master，将Pre-master发送给服务器；A6、服务器用自己的私钥对Pre-master解密得到随机数Random；A7、客户端和服务器根据客户端随机数、服务器随机数和Random生成会话密钥；A8、客户端和服务器分别验证对方的会话密钥，如果验证通过，则握手过程结束，后续通过该会话密钥加密数据传输过程中的报文。
但是，对于物联网设备，在握手开始阶段，没有进行双方身份的认证，多个客户端均可向服务器发送握手请求报文Client Hello，服务器需响应每个客户端发送的报文，使得服务器容易遭受流量攻击而造成瘫痪，无法提供正常的服务。
发明内容
鉴于上述问题，本申请实施例提供一种建立连接的方法，以通过向服务器发送握手请求报文，以使服务器根据握手请求报文中的客户端密钥标识和客户端验证码对客户端进行验证，接收服务器返回的握手应答报文，根据握手应答报文中的服务器验证码对服务器进行验证，当服务器验证通过后，建立与服务器之间的安全会话通道，解决现有技术中对于物联网领域，服务器容易遭受流量攻击而造成瘫痪的问题。
相应的，本申请实施例还提供了一种建立连接的装置，用以保证上述方法的实现及应用。
为了解决上述问题，本申请实施例公开了一种建立连接的方法，包括：
向服务器发送握手请求报文；所述握手请求报文包括客户端密钥标识和客户端验证码，以使所述服务器根据所述客户端密钥标识和所述客户端验证码，对客户端进行验证；
接收所述服务器返回的握手应答报文；所述握手应答报文为所述服务器对所述客户端验证通过后返回的报文，所述握手应答报文包括服务器验证码；
根据所述服务器验证码对所述服务器进行验证；
当所述服务器验证通过后，建立与所述服务器之间的安全会话通道。
本申请实施例还公开了一种建立连接的方法，包括：
接收客户端发送的握手请求报文；所述握手请求报文包括客户端密钥标识和客户端验证码；
根据所述客户端密钥标识和所述客户端验证码，对所述客户端进行验证；
当所述客户端验证通过后，向所述客户端返回握手应答报文；所述握手应答报文包括服务器验证码，以使所述客户端根据所述服务器验证码对服务器进行验证；
建立与所述客户端之间的安全会话通道；所述安全会话通道为所述客户端对所述服务器验证通过后建立的通道。
相应的，本申请实施例还公开了一种建立连接的装置，包括：
握手请求报文发送模块，用于向服务器发送握手请求报文；所述握手请求报文包括客户端密钥标识和客户端验证码，以使所述服务器根据所述客户端密钥标识和所述客户端验证码，对客户端进行验证；
握手应答报文接收模块，用于接收所述服务器返回的握手应答报文；所述握手应答报文为所述服务器对所述客户端验证通过后返回的报文，所述握手应答报文包括服务器验证码；
服务器验证模块，用于根据所述服务器验证码对所述服务器进行验证；
第一通道建立模块，用于当所述服务器验证通过后，建立与所述服务器之间的安全会话通道。
本申请实施例还公开了一种建立连接的装置，包括：
握手请求报文接收模块，用于接收客户端发送的握手请求报文；所述握手请求报文包括客户端密钥标识和客户端验证码；
客户端验证模块，用于根据所述客户端密钥标识和所述客户端验证码，对所述客户端进行验证；
握手应答报文返回模块，用于当所述客户端验证通过后，向所述客户端返回握手应答报文；所述握手应答报文包括服务器验证码，以使所述客户端根据所述服务器验证码对服务器进行验证；
第二通道建立模块，用于建立与所述客户端之间的安全会话通道；所述安全会话通道为所述客户端对所述服务器验证通过后建立的通道。
相应的，本申请实施例还公开了一种装置，包括：
一个或多个处理器；和
其上存储有指令的一个或多个机器可读介质，当由所述一个或多个处理器执行时，使得所述装置执行一种建立连接的方法。
相应的，本申请实施例还公开了一个或多个机器可读介质，其上存储有指令，当由一个或多个处理器执行时，使得装置执行一种建立连接的方法。
本申请实施例包括以下优点：
本申请实施例通过向服务器发送握手请求报文，以使服务器根据握手请求报文中的客户端密钥标识和客户端验证码对客户端进行验证，接收服务器返回的握手应答报文，根据握手应答报文中的服务器验证码对服务器进行验证，当服务器验证通过后，建立与服务器之间的安全会话通道。在认证握手开始阶段就进行双方身份的验证，当服务器对客户端的身份验证不通过时，无需再向客户端返回握手应答报文，有效防止了流量攻击。
附图说明
图1示出了本申请实施例的一种建立连接的方法的交互图；
图2示出了本申请实施例的一种建立连接的方法的流程图；
图3示出了本申请实施例的一种建立连接的方法的具体流程图；
图4示出了本申请实施例的握手请求报文的结构示意图；
图5示出了本申请实施例的握手应答报文的结构示意图；
图6示出了本申请实施例的另一种建立连接的方法的流程图；
图7示出了本申请实施例的另一种建立连接的方法的具体流程图；
图8示出了本申请实施例的一种建立连接的装置的结构图；
图9示出了本申请实施例的另一种建立连接的装置的结构图；
图10示出了本申请实施例提供的一种客户端的结构示意图。
具体实施方式
为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。
参照图1，示出了本申请实施例的一种建立连接的方法的交互图。
针对一个客户端详细说明建立连接的方法的交互过程，该交互过程可以由客户端中的客户端密钥管理服务和客户端中的第一连接进程，以及服务器中的服务器密钥管理服和服务器中的第二连接进程配合完成。其中，客户端密钥管理服务可以理解为客户端中的一个进程，是一个可以实现客户端密钥管理功能的程序或插件，相应的，服务器密钥管理服务也可以理解为服务器中的一个进程，是一个可以实现服务器密钥管理功能的程序或插件；第一连接进程是客户端中一个与服务器实现握手功能的进程，第二连接进程是服务器中一个与客户端实现握手功能的进程。
当客户端和服务器之间需要进行应用数据传输时，首先需要进行认证握手，以建立客户端和服务器之间的安全会话通道，握手过程结束后才可进行应用数据的传输。
在握手过程中，首先执行步骤S1：通过客户端密钥管理服务获取客户端中存储的共享密钥，在获取到客户端中存储的共享密钥后，客户端密钥管理服务执行步骤S2：根据共享密钥加密第一随机数，生成客户端验证码，接着，客户端中的第一连接进程执行步骤S3：向服务器发送握手请求报文，其中，该握手请求报文包括客户端密钥标识、客户端验证码和第二随机数。
然后，服务器中的第二连接进程执行步骤S4：接收客户端发送的握手请求报文，服务器提取握手请求报文中的客户端密钥标识、客户端验证码和第二随机数，并将客户端密钥标识和客户端验证码传输至服务器密钥管理服务，接着执行步骤S5：根据客户端密钥标识，通过服务器密钥管理服务获取服务器中存储的客户端对应的共享密钥，在获取到服务器中存储的客户端对应的共享密钥后，服务器密钥管理服务执行步骤S6：根据客户端对应的共享密钥对客户端验证码进行解密，以对客户端进行验证，当客户端验证码解密成功时，则客户端验证通过；接着分别执行步骤S7：根据服务器中存储的客户端对应的共享密钥加密第四随机数，生成所述服务器验证码，以及步骤S8：根据服务器中存储的客户端对应的共享密钥加密第五随机数，生成采用共享密钥加密的预置主密钥，在执行完成步骤S6、S7和S8后，服务器中的第二连接进程执行步骤S9：当客户端验证通过后，向客户端返回握手应答报文，该握手应答报文包括服务器验证码、第三随机数和采用共享密钥加密的预置主密钥。
接着，客户端中的第一连接进程执行步骤S10：接收服务器返回的握手应答报文，客户端提取握手应答报文中的服务器验证码、第三随机数和采用共享密钥加密的预置主密钥，并将服务器验证码和采用共享密钥加密的预置主密钥传输至客户端密钥管理服务，客户端密钥管理服务执行步骤S11：根据客户端中存储的共享密钥对服务器验证码进行解密，以对服务器进行验证，当服务器验证码解密成功时，则服务器验证通过，步骤S12：当服务器验证通过后，根据客户端中存储的共享密钥对采用共享密钥加密的预置主密钥进行解密，得到解密后的预置主密钥，此时，客户端和服务器分别获取到第二随机数、第三随机数和解密后的预置主密钥，客户端中的第一连接进程执行步骤S13：根据第二随机数、第三随机数和解密后的预置主密钥，生成与服务器之间的会话所使用的会话密钥，服务器中的第二连接进程执行步骤S14：根据第二随机数、第三随机数和第五随机数，生成与客户端之间的会话所使用的会话密钥。
最后，在客户端和服务器在分别生成会话密钥后，客户端中的第一连接进程执行步骤S15：向服务器发送通过客户端生成的会话密钥加密后的第一密钥验证报文，服务器中的第二连接进程执行步骤S16：接收客户端发送的通过客户端生成的会话密钥加密后的第一密钥验证报文，接着执行步骤S17：通过服务器生成的会话密钥对第一密钥验证报文进行解密，以对客户端生成的会话密钥进行验证，当第一密钥验证报文解密成功时，则客户端生成的会话密钥验证成功，然后，服务器中的第二连接进程执行步骤S18：向客户端返回通过服务器生成的会话密钥加密后的第二密钥验证报文，客户端中的第一连接进程执行步骤S19：接收服务器返回的通过服务器生成的会话密钥加密后的第二密钥验证报文，接着执行步骤S20：通过客户端生成的会话密钥对第二密钥报文解密，以对服务器生成的会话密钥进行验证，当第二密钥报文解密成功时，则服务器生成的会话密钥验证成功。
当服务器对客户端生成的会话密钥验证成功，且客户端对服务器生成的会话密钥验证成功时，则建立了客户端与服务器之间的安全会话通道。
需要说明的是，本申请实施例中的客户端和服务器均可应用于物联网。
在本申请实施例中，在握手开始阶段就进行双方身份的验证，当服务器对客户端的身份验证不通过时，无需再向客户端返回握手应答报文，有效防止了流量攻击；且使用共享密钥生成验证码和加密的预置主密钥，而不是直接获取共享密钥本身，客户端和服务器的密钥管理服务可以很好地保护共享密钥的安全，验证码和加密的预置主密钥具有很强的随机性，可减小字典攻击的风险。
同时，比如在物联网(IOT，Internet of Things)领域，很多物联网设备由于资源和计算能力有限，无法在握手过程中进行证书的解析和认证，且标准的TLS认证报文较大，且报文数量较多，在一些低速网中传输的实时性较差，甚至不可用，而本发明通过对握手请求报文和握手应答报文的字段进行扩展，在扩展字段中添加验证码，基于验证码进行客户端和服务器双方的身份验证，无需再通过证书进行身份验证，物联网设备可通过验证码代替证书进行身份验证，不受其资源和计算能力影响；在扩展字段中加入验证码不会大幅度影响握手请求报文和握手应答报文的大小，且完成一次握手，报文数量最少可缩减至4个，减少了握手过程中的报文数量，在低速网络中仍可以保持较好的实时性，因此，本发明在保证安全性的同时，减少协议对设备和网络的依赖性，满足物联网设备对连接安全的要求，可广泛使用于物联网设备上，当然，在其他设备性能低、网速低的领域中，本申请实施例也适用。
实施例一
本申请实施例从客户端侧进行描述。
参照图2，示出了本申请实施例的一种建立连接的方法的流程图，具体可以包括如下步骤：
步骤201，向服务器发送握手请求报文；所述握手请求报文包括客户端密钥标识和客户端验证码，以使所述服务器根据所述客户端密钥标识和所述客户端验证码，对客户端进行验证。
在本申请实施例中，当客户端和服务器之间需要进行应用数据传输时，首先需要进行认证握手，以建立客户端和服务器之间的安全会话通道，保证后续应用数据传输的安全性。
在客户端中存储有与服务器对应的一个共享密钥，在服务器中存储有各个客户端对应的共享密钥，一个客户端对应一个共享密钥，一个共享密钥对应一个客户端密钥标识Key_id。
在握手开始阶段，客户端获取客户端密钥标识Key_id和客户端验证码authCode_C，并在握手请求报文Client Hello的两个扩展字段中分别添加客户端密钥标识Key_id和客户端验证码authCode_C，然后，向服务器发送包括有客户端密钥标识Key_id和客户端验证码authCode_C的握手请求报文Client Hello，以使得服务器根据握手请求报文ClientHello中的客户端密钥标识Key_id和客户端验证码authCode_C，对客户端进行身份验证。
其中，客户端密钥标识Key_id和客户端验证码authCode_C位于握手请求报文Client Hello的扩展字段中；握手请求报文Client Hello中还包括协议版本(Version)和加密套件(Cipher_suites)。
步骤202，接收所述服务器返回的握手应答报文；所述握手应答报文为所述服务器对所述客户端验证通过后返回的报文，所述握手应答报文包括服务器验证码。
在本申请实施例中，当服务器对客户端的身份验证通过后，生成服务器验证码authCode_S，并在握手应答报文Server Hello的扩展字段中添加服务器验证码authCode_S，然后向客户端返回握手应答报文Server Hello，客户端接收服务器返回的包括有服务器验证码authCode_S的握手应答报文Server Hello。
当服务器对客户端的身份验证不通过时，无需再向客户端返回握手应答报文Server Hello，有效防止了流量攻击。
其中，服务器验证码authCode_S位于握手应答报文Server Hello的扩展字段中；握手应答报文Server Hello中还包括协议版本和加密套件。
步骤203，根据所述服务器验证码对所述服务器进行验证。
在本申请实施例中，在接收到服务器返回的握手应答报文Server Hello后，提取握手应答报文Server Hello中的服务器验证码authCode_S，根据服务器验证码authCode_S对服务器进行身份验证。
步骤204，当所述服务器验证通过后，建立与所述服务器之间的安全会话通道。
在本申请实施例中，当客户端对服务器的身份验证通过后，建立与服务器之间的安全会话通道，后续的应用数据通过建立的安全会话通道可安全地进行传输。
本申请实施例通过向服务器发送握手请求报文，以使服务器根据握手请求报文中的客户端密钥标识和客户端验证码对客户端进行验证，接收服务器返回的握手应答报文，根据握手应答报文中的服务器验证码对服务器进行验证，当服务器验证通过后，建立与服务器之间的安全会话通道。在认证握手开始阶段就进行双方身份的验证，当服务器对客户端的身份验证不通过时，无需再向客户端返回握手应答报文，有效防止了流量攻击。
实施例二
本申请实施例从客户端侧进行描述。
参照图3，示出了本申请实施例的一种建立连接的方法的具体流程图，具体可以包括如下步骤：
步骤301，通过客户端密钥管理服务获取所述客户端中存储的共享密钥。
在本申请实施例中，在客户端中设置有客户端密钥管理服务，是一个可实现客户端密钥管理功能的程序或插件，在客户端中存储有与服务器对应的一个共享密钥，通过客户端密钥管理服务获取客户端中存储的共享密钥。
步骤302，根据所述共享密钥加密第一随机数，生成所述客户端验证码。
在本申请实施例中，客户端密钥管理服务在获取到客户端中存储的共享密钥后，根据共享密钥加密第一随机数Random1，生成客户端验证码authCode_C。
步骤303，向服务器发送握手请求报文；所述握手请求报文包括客户端密钥标识和客户端验证码，以使所述服务器根据所述客户端密钥标识和所述客户端验证码，对客户端进行验证。
在本申请实施例中，获取客户端中存储的共享密钥对应的客户端密钥标识Key_id，将客户端密钥标识Key_id和客户端验证码authCode_C添加至握手请求报文ClientHello的两个扩展字段中，并将该握手请求报文Client Hello发送至服务器，服务器在接收到握手请求报文Client Hello后，提取出握手请求报文Client Hello中的客户端密钥标识Key_id和客户端验证码authCode_C，传输至服务器密钥管理服务。
在服务器中存储有各个客户端对应的共享密钥，服务器密钥管理服务通过提取出的客户端密钥标识Key_id在服务器中查找客户端对应的共享密钥，根据查找到的客户端对应的共享密钥对客户端验证码authCode_C进行解密，当客户端验证码authCode_C解密成功时，则表明客户端的身份验证通过。
例如，服务器中存储有3个客户端对应的共享密钥，其对应的客户端密钥标识分别为Key_id1、Key_id2、Key_id3，当提取出的握手请求报文Client Hello中的客户端密钥标识为Key_id1时，查找服务器中存储的客户端密钥标识Key_id1对应的客户端的共享密钥。
其中，在握手请求报文Client Hello中还包括第二随机数Random2，服务器在接收到握手请求报文Client Hello后，同时可提取出第二随机数Random2。
参照图4，示出了本申请实施例的握手请求报文的结构示意图。
客户端向服务器发送的握手请求报文可以采用如图4所示的报文格式，在图4中，Version表示协议版本，Length表示报文的长度，Client Hello表示报文的类型为握手请求报文，在握手请求报文中包括有加密套件Cipher_suites、第二随机数Random2、客户端密钥标识Key_id和客户端验证码authCode_C，其中，客户端密钥标识Key_id和客户端验证码authCode_C位于握手请求报文的扩展字段中。
步骤304，接收所述服务器返回的握手应答报文；所述握手应答报文为所述服务器对所述客户端验证通过后返回的报文，所述握手应答报文包括服务器验证码。
在本申请实施例中，服务器密钥管理服务根据查找到的客户端对应的共享密钥加密第四随机数Random4，生成服务器验证码authCode_S，将服务器验证码authCode_S添加至握手应答报文Server Hello的其中一个扩展字段中；同时，根据查找到的客户端对应的共享密钥加密第五随机数Random5，生成采用共享密钥加密的预置主密钥Pre-master，将采用共享密钥加密的预置主密钥Pre-master添加至握手应答报文Server Hello的另一个扩展字段中。
当服务器对客户端的身份验证通过后，向客户端返回握手应答报文ServerHello，该握手应答报文Server Hello包括服务器验证码authCode_S和采用共享密钥加密的预置主密钥Pre-master，客户端接收服务器返回的握手应答报文Server Hello。
其中，在握手应答报文Server Hello中还包括第三随机数Random3。
参照图5，示出了本申请实施例的握手应答报文的结构示意图。
服务器向客户端返回的握手应答报文可以采用如图5所示的报文格式，在图5中，Version表示协议版本，Length表示报文的长度，Server Hello表示报文的类型为握手应答报文，在握手应答报文中包括有加密套件Cipher_suites、第三随机数Random3、服务器验证码authCode_S和共享密钥加密的预置主密钥Pre-master，其中，服务器验证码authCode_S位于握手应答报文Server Hello的扩展字段中，采用共享密钥加密的预置主密钥Pre-master位于握手应答报文Server Hello的扩展字段中。
需要说明的是，可以将采用共享密钥加密的预置主密钥Pre-master添加至握手应答报文Server Hello的一个扩展字段中，服务器再将握手应答报文Server Hello发送至客户端，这种情况下，客户端与服务器在握手阶段的报文数量为4个；也可以不在握手应答报文Server Hello的扩展字段中添加采用共享密钥加密的预置主密钥Pre-master，而是在服务器向客户端发送握手应答报文Server Hello后，再次向客户端发送一个包括有采用共享密钥加密的预置主密钥Pre-master的报文，这种情况下，客户端与服务器在握手阶段的报文数量为5个；还可以是客户端根据共享密钥加密第五随机数Random5，生成采用共享密钥加密的预置主密钥Pre-master，向服务器再次发送一个包括有采用共享密钥加密的预置主密钥Pre-master的报文，这种情况下，客户端与服务器在握手阶段的报文数量也为5个。
步骤305，根据所述客户端中存储的共享密钥对所述服务器验证码进行解密，以对所述服务器进行验证。
在本申请实施例中，客户端在接收到服务器返回的握手应答报文Server Hello后，提取出握手应答报文Server Hello中的服务器验证码authCode_S和采用共享密钥加密的预置主密钥Pre-master，并传输至客户端密钥管理服务。
客户端密钥管理服务根据客户端中存储的共享密钥对服务器验证码authCode_S进行解密，当服务器验证码authCode_S解密成功时，则表明服务器的身份验证通过。
步骤306，当所述服务器验证通过后，根据所述客户端中存储的共享密钥对所述采用共享密钥加密的预置主密钥进行解密，得到解密后的预置主密钥。
在本申请实施例中，当客户端对服务器的身份验证通过后，客户端密钥管理服务根据客户端中存储的共享密钥对采用共享密钥加密的预置主密钥Pre-master进行解密，得到解密后的预置主密钥，解密后的预置主密钥即为第五随机数Random5。
其中，在握手应答报文Server Hello中还包括第三随机数Random3，客户端在接收到握手应答报文Server Hello后，同时可提取出第三随机数Random3。
步骤307，根据所述第二随机数、所述第三随机数和所述解密后的预置主密钥，生成与所述服务器之间的会话所使用的会话密钥。
在本申请实施例中，客户端分别获取到了第二随机数Random2、第三随机数Random3和解密后的预置主密钥(即为第五随机数Random5)，根据第二随机数Random2、第三随机数Random3和解密后的预置主密钥，生成与服务器之间的会话所使用的会话密钥。
相应的，服务器也分别获取到了第二随机数Random2、第三随机数Random3和第五随机数Random5，基于与客户端相同的运算规则，根据第二随机数Random2、第三随机数Random3和第五随机数Random5，生成与客户端之间的会话所使用的会话密钥。
需要说明的是，标准的TLS协议是直接在证书中获取共享密钥本身，在服务器向客户端下发证书时，证书中的共享密钥容易被拦截获取，客户端和服务器无法为共享密钥提供高强度的保护，且容易遭遇字典攻击，导致通过共享密钥生成会话密钥泄露，使得客户端和服务器之间的连接不安全；而本申请实施例是将共享密钥存储在客户端和服务器中，客户端和服务器的密钥管理服务可以很好地保护共享密钥的安全，使用共享密钥生成验证码和加密的预置主密钥，再通过解密后的预置主密钥生成会话密钥，验证码和加密的预置主密钥具有很强的随机性，可减小字典攻击的风险，使得客户端和服务器之间的连接更安全。
步骤308，对与所述服务器之间的会话所使用的会话密钥进行交互验证，以建立与所述服务器之间的安全会话通道。
在本申请实施例中，在生成与服务器之间的会话所使用的会话密钥后，对与服务器之间的会话所使用的会话密钥进行交互验证，当会话密钥验证成功时，即可建立与服务器之间的安全会话通道。
本申请实施例基于预制的共享密钥生成验证码，基于验证码进行客户端和服务器双方的身份验证，并建立安全会话通道，在保证安全性的同时，无需再通过证书进行身份验证，完成一次握手，报文数量最少可缩减至4个，减少了握手过程中的报文数量，在低速网络中仍可以保持较好的实时性，减小协议对设备资源和运算能力的需求，可广泛使用于物联网设备上。
具体的，向所述服务器发送通过所述客户端生成的会话密钥加密后的第一密钥验证报文，以使所述服务器对所述客户端生成的会话密钥进行验证；接收所述服务器返回的通过所述服务器生成的会话密钥加密后的第二密钥验证报文；通过所述客户端生成的会话密钥对所述第二密钥报文解密，以对所述服务器生成的会话密钥进行验证。
首先，客户端生成第一密钥验证报文Client Finished，通过客户端生成的会话密钥加密第一密钥验证报文Client Finished，将通过客户端生成的会话密钥加密后的第一密钥验证报文Client Finished发送至服务器，服务器在接收到第一密钥验证报文ClientFinished后，根据服务器生成的会话密钥对第一密钥验证报文Client Finished进行解密，当第一密钥验证报文Client Finished解密成功时，则表明客户端生成的会话密钥验证成功。
然后，服务器生成第二密钥验证报文Server Finished，通过服务器生成的会话密钥加密第二密钥验证报文Server Finished，将通过服务器生成的会话密钥加密第二密钥验证报文Server Finished发送至客户端，客户端在接收到服务器返回的通过服务器生成的会话密钥加密后的第二密钥验证报文Server Finished后，根据客户端生成的会话密钥对第二密钥验证报文Server Finished进行解密，当第二密钥验证报文Server Finished解密成功时，则表明服务器生成的会话密钥验证成功。
当客户端生成的会话密钥验证成功，且服务器生成的会话密钥验证成功时，则建立了客户端与服务器之间的安全会话通道，后续的应用数据通过该会话密钥进行加密传输，保证应用数据的安全性和保密性。
在本申请实施例中，通过客户端密钥管理服务获取客户端中存储的共享密钥，根据共享密钥加密第一随机数，生成客户端验证码，向服务器发送握手请求报文，该握手请求报文包括客户端密钥标识和客户端验证码，以使服务器根据客户端密钥标识和客户端验证码，对客户端进行验证，接收服务器返回的握手应答报文，该握手应答报文为服务器对客户端验证通过后返回的报文，该握手应答报文包括服务器验证码，根据客户端中存储的共享密钥对服务器验证码进行解密，以对服务器进行验证，当服务器验证通过后，根据客户端中存储的共享密钥对采用共享密钥加密的预置主密钥进行解密，得到解密后的预置主密钥，根据第二随机数、第三随机数和解密后的预置主密钥，生成与服务器之间的会话所使用的会话密钥，对与服务器之间的会话所使用的会话密钥进行交互验证，以建立与服务器之间的安全会话通道。在握手开始阶段就进行双方身份的验证，当服务器对客户端的身份验证不通过时，无需再向客户端返回握手应答报文，有效防止了流量攻击；且使用共享密钥生成验证码和加密的预置主密钥，而不是直接获取共享密钥本身，客户端和服务器的密钥管理服务可以很好地保护共享密钥的安全，验证码和加密的预置主密钥具有很强的随机性，可减小字典攻击的风险，且完成一次握手，报文数量最少可缩减至4个，减少了握手过程中的报文数量，在低速网络中仍可以保持较好的实时性。
实施例三
本申请实施例从服务器侧进行描述。
参照图6，示出了本申请实施例的另一种建立连接的方法的流程图，具体可以包括如下步骤：
步骤601，接收客户端发送的握手请求报文；所述握手请求报文包括客户端密钥标识和客户端验证码。
在本申请实施例中，在客户端和服务器握手开始阶段，客户端获取客户端密钥标识Key_id和客户端验证码authCode_C，并在握手请求报文Client Hello的两个扩展字段中分别添加客户端密钥标识Key_id和客户端验证码authCode_C，然后，向服务器发送包括有客户端密钥标识Key_id和客户端验证码authCode_C的握手请求报文Client Hello，服务器接收客户端发送的握手请求报文Client Hello，该握手请求报文Client Hello包括客户端密钥标识Key_id和客户端验证码authCode_C。
其中，客户端密钥标识Key_id和客户端验证码authCode_C位于握手请求报文Client Hello的扩展字段中；握手请求报文Client Hello中还包括协议版本(Version)和加密套件(Cipher_suites)。
步骤602，根据所述客户端密钥标识和所述客户端验证码，对所述客户端进行验证。
在本申请实施例中，服务器在接收到客户端发送的握手请求报文Client Hello后，提取握手请求报文Client Hello中的客户端密钥标识Key_id和客户端验证码authCode_C，根据握手请求报文Client Hello中的客户端密钥标识Key_id和客户端验证码authCode_C，对客户端进行身份验证。
步骤603，当所述客户端验证通过后，向所述客户端返回握手应答报文；所述握手应答报文包括服务器验证码，以使所述客户端根据所述服务器验证码对服务器进行验证。
在本申请实施例中，当服务器对客户端的身份验证通过后，生成服务器验证码authCode_S，并在握手应答报文Server Hello的扩展字段中添加服务器验证码authCode_S，然后向客户端返回握手应答报文Server Hello，该握手应答报文Server Hello包括服务器验证码authCode_S，以使述客户端根据握手应答报文Server Hello中的服务器验证码authCode_S对服务器进行身份验证。
当服务器对客户端的身份验证不通过时，无需再向客户端返回握手应答报文Server Hello，有效防止了流量攻击。
其中，服务器验证码authCode_S位于握手应答报文Server Hello的扩展字段中；握手应答报文Server Hello中还包括协议版本和加密套件。
步骤604，建立与所述客户端之间的安全会话通道；所述安全会话通道为所述客户端对所述服务器验证通过后建立的通道。
在本申请实施例中，当客户端对服务器的身份验证通过后，建立与客户端之间的安全会话通道，后续的应用数据通过建立的安全会话通道可安全地进行传输。
本申请实施例通过接收客户端发送的握手请求报文，根据握手请求报文中的客户端密钥标识和客户端验证码对客户端进行验证，当客户端验证通过后，向客户端返回握手应答报文，以使客户端根据握手应答报文中的服务器验证码对服务器进行验证，当服务器验证通过后，建立与客户端之间的安全会话通道。在认证握手开始阶段就进行双方身份的验证，当服务器对客户端的身份验证不通过时，无需再向客户端返回握手应答报文，有效防止了流量攻击。
实施例四
本申请实施例从服务器侧进行描述。
参照图7，示出了本申请实施例的另一种建立连接的方法的具体流程图，具体可以包括如下步骤：
步骤701，接收客户端发送的握手请求报文；所述握手请求报文包括客户端密钥标识和客户端验证码。
在本申请实施例中，在客户端和服务器握手开始阶段，客户端根据自身存储与服务器对应的共享密钥加密第一随机数Random1，生成客户端验证码authCode_C，并获取客户端中存储的共享密钥对应的客户端密钥标识Key_id，将客户端密钥标识Key_id和客户端验证码authCode_C添加至握手请求报文Client Hello的两个扩展字段中，然后将握手请求报文Client Hello发送至服务器，服务器接收客户端发送的握手请求报文Client Hello，该握手请求报文Client Hello包括客户端密钥标识Key_id和客户端验证码authCode_C。
其中，在握手请求报文Client Hello中还包括第二随机数Random2；客户端密钥标识Key_id和客户端验证码authCode_C位于握手请求报文的扩展字段中。
步骤702，根据所述客户端密钥标识，通过服务器密钥管理服务获取所述服务器中存储的所述客户端对应的共享密钥。
在本申请实施例中，在服务器中设置有服务器密钥管理服务，是一个可以实现服务器密钥管理服务的程序或插件，在服务器中存储有各个客户端对应的共享密钥。
服务器在接收到客户端发送的握手请求报文Client Hello后，提取出握手请求报文Client Hello中的客户端密钥标识Key_id和客户端验证码authCode_C，传输至服务器密钥管理服务，服务器密钥管理服务根据客户端密钥标识获取服务器中存储的客户端对应的共享密钥。
步骤703，根据所述客户端对应的共享密钥对所述客户端验证码进行解密，以对所述客户端进行验证。
在本申请实施例中，根据获取到的客户端对应的共享密钥对客户端验证码authCode_C进行解密，当客户端验证码authCode_C解密成功时，则表明客户端的身份验证通过。
步骤704，根据所述服务器中存储的所述客户端对应的共享密钥加密第四随机数，生成所述服务器验证码。
在本申请实施例中，服务器密钥管理服务根据获取到的客户端对应的共享密钥加密第四随机数Random4，生成服务器验证码authCode_S。
步骤705，根据所述服务器中存储的所述客户端对应的共享密钥加密第五随机数，生成采用共享密钥加密的预置主密钥。
在本申请实施例中，服务器密钥管理服务根据获取到的客户端对应的共享密钥加密第五随机数Random5，生成采用共享密钥加密的预置主密钥Pre-master。
步骤706，当所述客户端验证通过后，向所述客户端返回握手应答报文；所述握手应答报文包括服务器验证码，以使所述客户端根据所述服务器验证码对服务器进行验证。
在本申请实施例中，当服务器对客户端的身份验证通过后，将服务器验证码authCode_S添加至握手应答报文Server Hello的扩展字段中，向客户端返回握手应答报文Server Hello。
客户端接收服务器返回的握手应答报文Server Hello，提取出握手应答报文Server Hello中的服务器验证码authCode_S，传输至客户端密钥管理服务，客户端密钥管理服务器根据客户端中存储的共享密钥对服务器验证码authCode_S进行解密，当服务器验证码authCode_S解密成功时，则表明服务器的身份验证通过。
在将服务器验证码authCode_S添加至握手应答报文Server Hello的扩展字段中时，也可以将采用共享密钥加密的预置主密钥Pre-master添加至握手应答报文ServerHello的扩展字段，并随着握手应答报文Server Hello返回至客户端，客户端提取出采用共享密钥加密的预置主密钥Pre-master后传输至客户端密钥管理服务，客户端密钥管理服务根据客户端中存储的共享密钥对采用共享密钥加密的预置主密钥Pre-master进行解密，得到解密后的预置主密钥，即为第五随机数Random5。
其中，在握手应答报文Server Hello中还包括第三随机数Random3；服务器验证码authCode_S位于握手应答报文Server Hello的扩展字段中，采用共享密钥加密的预置主密钥Pre-master位于握手应答报文Server Hello的扩展字段中。
步骤707，根据所述第二随机数、所述第三随机数和所述第五随机数，生成与所述客户端之间的会话所使用的会话密钥。
在本申请实施例中，服务器分别获取到了第二随机数Random2、第三随机数Random3和第五随机数Random5，根据第二随机数Random2、第三随机数Random3和第五随机数Random5，生成与客户端之间的会话所使用的会话密钥。
相应的，客户端也分别获取到了第二随机数Random2、第三随机数Random3和解密后的预置主密钥(即为第五随机数Random5)，基于与服务器相同的运算规则，根据第二随机数Random2、第三随机数Random3和解密后的预置主密钥，生成与服务器之间的会话所使用的会话密钥。
步骤708，对与所述客户端之间的会话所使用的会话密钥进行交互验证，以建立与所述客户端之间的安全会话通道。
在本申请实施例中，在生成与客户端之间的会话所使用的会话密钥后，对与客户端之间的会话所使用的会话密钥进行交互验证，当会话密钥验证成功时，即可建立与客户端之间的安全会话通道。
具体的，接收所述客户端发送的通过所述客户端生成的会话密钥加密后的第一密钥验证报文；通过所述服务器生成的会话密钥对所述第一密钥验证报文进行解密，以对所述客户端生成的会话密钥进行验证；向所述客户端返回通过所述服务器生成的会话密钥加密后的第二密钥验证报文，以使所述客户端对所述服务器生成的会话密钥进行验证
在本申请实施例中，在握手开始阶段就进行双方身份的验证，当服务器对客户端的身份验证不通过时，无需再向客户端返回握手应答报文，有效防止了流量攻击；且使用共享密钥生成验证码和加密的预置主密钥，而不是直接获取共享密钥本身，客户端和服务器的密钥管理服务可以很好地保护共享密钥的安全，验证码和加密的预置主密钥具有很强的随机性，可减小字典攻击的风险，且完成一次握手，报文数量最少可缩减至4个，减少了握手过程中的报文数量，在低速网络中仍可以保持较好的实时性。
实施例五
参照图8，示出了本申请实施例的一种建立连接的装置的结构图，主要应用于客户端，该装置800具体可以包括如下模块：
握手请求报文发送模块801，用于向服务器发送握手请求报文；所述握手请求报文包括客户端密钥标识和客户端验证码，以使所述服务器根据所述客户端密钥标识和所述客户端验证码，对客户端进行验证。
握手应答报文接收模块802，用于接收所述服务器返回的握手应答报文；所述握手应答报文为所述服务器对所述客户端验证通过后返回的报文，所述握手应答报文包括服务器验证码。
服务器验证模块803，用于根据所述服务器验证码对所述服务器进行验证。
第一通道建立模块804，用于当所述服务器验证通过后，建立与所述服务器之间的安全会话通道。
可选的，所述装置800还包括：
第一共享密钥获取模块，用于通过客户端密钥管理服务获取所述客户端中存储的共享密钥；
客户端验证码生成模块，用于根据所述共享密钥加密第一随机数，生成所述客户端验证码。
可选的，所述服务器验证模块803，包括：
服务器验证子模块，用于根据所述客户端中存储的共享密钥对所述服务器验证码进行解密，以对所述服务器进行验证。
可选的，所述握手请求报文还包括第二随机数，所述握手应答报文还包括第三随机数和采用共享密钥加密的预置主密钥，所述第一通道建立模块804，包括：
解密子模块，用于根据所述客户端中存储的共享密钥对所述采用共享密钥加密的预置主密钥进行解密，得到解密后的预置主密钥；
第一会话密钥生成子模块，用于根据所述第二随机数、所述第三随机数和所述解密后的预置主密钥，生成与所述服务器之间的会话所使用的会话密钥；
第一会话密钥验证子模块，用于对与所述服务器之间的会话所使用的会话密钥进行交互验证，以建立与所述服务器之间的安全会话通道。
可选的，所述第一会话密钥验证子模块，包括：
第一密钥验证报文发送单元，用于向所述服务器发送通过所述客户端生成的会话密钥加密后的第一密钥验证报文，以使所述服务器对所述客户端生成的会话密钥进行验证；
第二密钥验证报文接收单元，用于接收所述服务器返回的通过所述服务器生成的会话密钥加密后的第二密钥验证报文；
第二密钥报文解密单元，用于通过所述客户端生成的会话密钥对所述第二密钥报文解密，以对所述服务器生成的会话密钥进行验证。
可选的，所述客户端密钥标识和所述客户端验证码位于所述握手请求报文的扩展字段中。
可选的，所述服务器验证码位于所述握手应答报文的扩展字段中，所述采用共享密钥加密的预置主密钥位于所述握手应答报文的扩展字段中。
本申请实施例通过向服务器发送握手请求报文，以使服务器根据握手请求报文中的客户端密钥标识和客户端验证码对客户端进行验证，接收服务器返回的握手应答报文，根据握手应答报文中的服务器验证码对服务器进行验证，当服务器验证通过后，建立与服务器之间的安全会话通道。在认证握手开始阶段就进行双方身份的验证，当服务器对客户端的身份验证不通过时，无需再向客户端返回握手应答报文，有效防止了流量攻击。
实施例六
参照图9，示出了本申请实施例的另一种建立连接的装置的结构图，主要应用于服务器，该装置900具体可以包括如下模块：
握手请求报文接收模块901，用于接收客户端发送的握手请求报文；所述握手请求报文包括客户端密钥标识和客户端验证码。
客户端验证模块902，用于根据所述客户端密钥标识和所述客户端验证码，对所述客户端进行验证。
握手应答报文返回模块903，用于当所述客户端验证通过后，向所述客户端返回握手应答报文；所述握手应答报文包括服务器验证码，以使所述客户端根据所述服务器验证码对服务器进行验证。
第二通道建立模块904，用于建立与所述客户端之间的安全会话通道；所述安全会话通道为所述客户端对所述服务器验证通过后建立的通道。
可选的，所述客户端验证模块902，包括：
第二共享密钥获取子模块，用于根据所述客户端密钥标识，通过服务器密钥管理服务获取所述服务器中存储的所述客户端对应的共享密钥；
客户端验证子模块，用于根据所述客户端对应的共享密钥对所述客户端验证码进行解密，以对所述客户端进行验证。
可选的，所述装置900还包括：
服务器验证码生成模块，用于根据所述服务器中存储的所述客户端对应的共享密钥加密第四随机数，生成所述服务器验证码；
加密模块，用于根据所述服务器中存储的所述客户端对应的共享密钥加密第五随机数，生成采用共享密钥加密的预置主密钥。
可选的，所述握手请求报文还包括第二随机数，所述握手应答报文还包括第三随机数和所述采用共享密钥加密的预置主密钥，所述第二通道建立模块904，包括：
第二会话密钥生成子模块，用于根据所述第二随机数、所述第三随机数和所述第五随机数，生成与所述客户端之间的会话所使用的会话密钥；
第二会话密钥验证子模块，用于对与所述客户端之间的会话所使用的会话密钥进行交互验证，以建立与所述客户端之间的安全会话通道。
可选的，所述第二会话密钥验证子模块，包括：
第一密钥验证报文接收单元，用于接收所述客户端发送的通过所述客户端生成的会话密钥加密后的第一密钥验证报文；
第一密钥验证报文解密单元，用于通过所述服务器生成的会话密钥对所述第一密钥验证报文进行解密，以对所述客户端生成的会话密钥进行验证；
第二密钥验证报文返回单元，用于向所述客户端返回通过所述服务器生成的会话密钥加密后的第二密钥验证报文，以使所述客户端对所述服务器生成的会话密钥进行验证。
可选的，所述客户端密钥标识和所述客户端验证码位于所述握手请求报文的扩展字段中。
可选的，所述服务器验证码位于所述握手应答报文的扩展字段中，所述采用共享密钥加密的预置主密钥位于所述握手应答报文的扩展字段中。
本申请实施例通过接收客户端发送的握手请求报文，根据握手请求报文中的客户端密钥标识和客户端验证码对客户端进行验证，当客户端验证通过后，向客户端返回握手应答报文，以使客户端根据握手应答报文中的服务器验证码对服务器进行验证，当服务器验证通过后，建立与客户端之间的安全会话通道。在认证握手开始阶段就进行双方身份的验证，当服务器对客户端的身份验证不通过时，无需再向客户端返回握手应答报文，有效防止了流量攻击。
对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
图10是本申请实施例提供的一种客户端的结构示意图。参见图10，客户端1000可以用于实施上述实施例一和实施例二中提供的建立连接的方法。该客户端1000可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(centralprocessing units，CPU)1022(例如，一个或一个以上处理器)和存储器1032，一个或一个以上存储应用程序1042或数据1044的存储介质1030(例如一个或一个以上海量存储设备)。其中，存储器1032和存储介质1030可以是短暂存储的或持久存储的。存储在存储介质1030的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对客户端中的一系列指令操作。更进一步地，中央处理器1022可以设置为与存储介质1030通信，在客户端1000上执行存储介质1030中的一系列指令操作。
客户端1000还可以包括一个或一个以上电源1026，一个或一个以上有线或无线网络接口1050，一个或一个以上输入输出接口1058，一个或一个以上键盘1056，和/或，一个或一个以上操作系统1041，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。其中，中央处理器1022可以在客户端1000上执行以下操作的指令：
向服务器发送握手请求报文；所述握手请求报文包括客户端密钥标识和客户端验证码，以使所述服务器根据所述客户端密钥标识和所述客户端验证码，对客户端进行验证；
接收所述服务器返回的握手应答报文；所述握手应答报文为所述服务器对所述客户端验证通过后返回的报文，所述握手应答报文包括服务器验证码；
根据所述服务器验证码对所述服务器进行验证；
当所述服务器验证通过后，建立与所述服务器之间的安全会话通道。
本申请实施例还提供一种服务器，服务器可以用于实施上述实施例三和实施例四中提供的建立连接的方法。
该服务器的具体结构可参照图10所示的客户端1000的结构示意图，两者的不同之处在于，服务器的中央处理器和客户端1000的中央处理器执行的操作指令不同，其执行服务器侧的方法。
本申请提供一种装置，其上存储有指令的一个或多个机器可读介质，当由所述一个或多个处理器执行时，使得所述装置执行一种建立连接的方法。
本申请还提供一个或多个机器可读介质，其上存储有指令，当由一个或多个处理器执行时，使得装置执行一种建立连接的方法。
本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
以上对本申请所提供的一种建立连接的方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。
Claims (26)
1.一种建立连接的方法，其特征在于，包括：
向服务器发送握手请求报文；所述握手请求报文包括客户端密钥标识和客户端验证码，以使所述服务器根据所述客户端密钥标识和所述客户端验证码，对客户端进行验证，并在对所述客户端验证成功的情况下发送握手应答报文，在对所述客户端验证不成功的情况下不响应所述握手请求报文；所述客户端验证码根据共享密钥加密得到；所述客户端密钥标识和所述客户端验证码位于所述握手请求报文的扩展字段中；
接收所述服务器返回的握手应答报文；所述握手应答报文为所述服务器对所述客户端验证通过后返回的报文，所述握手应答报文包括服务器验证码；所述服务器验证码根据共享密钥加密得到；
根据所述服务器验证码对所述服务器进行验证；
当所述服务器验证通过后，建立与所述服务器之间的安全会话通道。
2.根据权利要求1所述的方法，其特征在于，在所述向服务器发送握手请求报文的步骤之前，还包括：
通过客户端密钥管理服务获取所述客户端中存储的共享密钥；
根据所述共享密钥加密第一随机数，生成所述客户端验证码。
3.根据权利要求1所述的方法，其特征在于，所述根据所述服务器验证码对所述服务器进行验证的步骤，包括：
根据所述客户端中存储的共享密钥对所述服务器验证码进行解密，以对所述服务器进行验证。
4.根据权利要求1所述的方法，其特征在于，所述握手请求报文还包括第二随机数，所述握手应答报文还包括第三随机数和采用共享密钥加密的预置主密钥，所述建立与所述服务器之间的安全会话通道的步骤，包括：
根据所述客户端中存储的共享密钥对所述采用共享密钥加密的预置主密钥进行解密，得到解密后的预置主密钥
根据所述第二随机数、所述第三随机数和所述解密后的预置主密钥，生成与所述服务器之间的会话所使用的会话密钥；
对与所述服务器之间的会话所使用的会话密钥进行交互验证，以建立与所述服务器之间的安全会话通道。
5.根据权利要求4所述的方法，其特征在于，所述对与所述服务器之间的会话所使用的会话密钥进行交互验证的步骤，包括：
向所述服务器发送通过所述客户端生成的会话密钥加密后的第一密钥验证报文，以使所述服务器对所述客户端生成的会话密钥进行验证；
接收所述服务器返回的通过所述服务器生成的会话密钥加密后的第二密钥验证报文；
通过所述客户端生成的会话密钥对所述第二密钥验证报文解密，以对所述服务器生成的会话密钥进行验证。
6.根据权利要求4所述的方法，其特征在于，所述服务器验证码位于所述握手应答报文的扩展字段中，所述采用共享密钥加密的预置主密钥位于所述握手应答报文的扩展字段中。
7.一种建立连接的方法，其特征在于，包括：
接收客户端发送的握手请求报文；所述握手请求报文包括客户端密钥标识和客户端验证码；所述客户端密钥标识和所述客户端验证码位于所述握手请求报文的扩展字段中；
根据所述客户端密钥标识和所述客户端验证码，对所述客户端进行验证，并在对所述客户端验证成功的情况下发送握手应答报文，在对所述客户端验证不成功的情况下不响应所述握手请求报文；所述客户端验证码根据共享密钥加密得到；
当所述客户端验证通过后，向所述客户端返回握手应答报文；所述握手应答报文包括服务器验证码，以使所述客户端根据所述服务器验证码对服务器进行验证；所述服务器验证码根据共享密钥加密得到；
建立与所述客户端之间的安全会话通道；所述安全会话通道为所述客户端对所述服务器验证通过后建立的通道。
8.根据权利要求7所述的方法，其特征在于，根据所述客户端密钥标识和所述客户端验证码，对所述客户端进行验证的步骤，包括：
根据所述客户端密钥标识，通过服务器密钥管理服务获取所述服务器中存储的所述客户端对应的共享密钥；
根据所述客户端对应的共享密钥对所述客户端验证码进行解密，以对所述客户端进行验证。
9.根据权利要求7所述的方法，其特征在于，在所述向所述客户端返回握手应答报文的步骤之前，还包括：
根据所述服务器中存储的所述客户端对应的共享密钥加密第四随机数，生成所述服务器验证码；
根据所述服务器中存储的所述客户端对应的共享密钥加密第五随机数，生成采用共享密钥加密的预置主密钥。
10.根据权利要求9所述的方法，其特征在于，所述握手请求报文还包括第二随机数，所述握手应答报文还包括第三随机数和所述采用共享密钥加密的预置主密钥，所述建立与所述客户端之间的安全会话通道的步骤，包括：
根据所述第二随机数、所述第三随机数和所述第五随机数，生成与所述客户端之间的会话所使用的会话密钥；
对与所述客户端之间的会话所使用的会话密钥进行交互验证，以建立与所述客户端之间的安全会话通道。
11.根据权利要求10所述的方法，其特征在于，所述对与所述客户端之间的会话所使用的会话密钥进行交互验证的步骤，包括：
接收所述客户端发送的通过所述客户端生成的会话密钥加密后的第一密钥验证报文；
通过所述服务器生成的会话密钥对所述第一密钥验证报文进行解密，以对所述客户端生成的会话密钥进行验证；
向所述客户端返回通过所述服务器生成的会话密钥加密后的第二密钥验证报文，以使所述客户端对所述服务器生成的会话密钥进行验证。
12.根据权利要求10所述的方法，其特征在于，所述服务器验证码位于所述握手应答报文的扩展字段中，所述采用共享密钥加密的预置主密钥位于所述握手应答报文的扩展字段中。
13.一种建立连接的装置，其特征在于，包括：
握手请求报文发送模块，用于向服务器发送握手请求报文；所述握手请求报文包括客户端密钥标识和客户端验证码，以使所述服务器根据所述客户端密钥标识和所述客户端验证码，对客户端进行验证，并在对所述客户端验证成功的情况下发送握手应答报文，在对所述客户端验证不成功的情况下不响应所述握手请求报文；所述客户端验证码根据共享密钥加密得到；所述客户端密钥标识和所述客户端验证码位于所述握手请求报文的扩展字段中；
握手应答报文接收模块，用于接收所述服务器返回的握手应答报文；所述握手应答报文为所述服务器对所述客户端验证通过后返回的报文，所述握手应答报文包括服务器验证码；所述服务器验证码根据共享密钥加密得到；
服务器验证模块，用于根据所述服务器验证码对所述服务器进行验证；
第一通道建立模块，用于当所述服务器验证通过后，建立与所述服务器之间的安全会话通道。
14.根据权利要求13所述的装置，其特征在于，还包括：
第一共享密钥获取模块，用于通过客户端密钥管理服务获取所述客户端中存储的共享密钥；
客户端验证码生成模块，用于根据所述共享密钥加密第一随机数，生成所述客户端验证码。
15.根据权利要求13所述的装置，其特征在于，所述服务器验证模块，包括：
服务器验证子模块，用于根据所述客户端中存储的共享密钥对所述服务器验证码进行解密，以对所述服务器进行验证。
16.根据权利要求13所述的装置，其特征在于，所述握手请求报文还包括第二随机数，所述握手应答报文还包括第三随机数和采用共享密钥加密的预置主密钥，所述第一通道建立模块，包括：
解密子模块，用于根据所述客户端中存储的共享密钥对所述采用共享密钥加密的预置主密钥进行解密，得到解密后的预置主密钥；
第一会话密钥生成子模块，用于根据所述第二随机数、所述第三随机数和所述解密后的预置主密钥，生成与所述服务器之间的会话所使用的会话密钥；
第一会话密钥验证子模块，用于对与所述服务器之间的会话所使用的会话密钥进行交互验证，以建立与所述服务器之间的安全会话通道。
17.根据权利要求16所述的装置，其特征在于，所述第一会话密钥验证子模块，包括：
第一密钥验证报文发送单元，用于向所述服务器发送通过所述客户端生成的会话密钥加密后的第一密钥验证报文，以使所述服务器对所述客户端生成的会话密钥进行验证；
第二密钥验证报文接收单元，用于接收所述服务器返回的通过所述服务器生成的会话密钥加密后的第二密钥验证报文；
第二密钥报文解密单元，用于通过所述客户端生成的会话密钥对所述第二密钥验证报文解密，以对所述服务器生成的会话密钥进行验证。
18.根据权利要求16所述的装置，其特征在于，所述服务器验证码位于所述握手应答报文的扩展字段中，所述采用共享密钥加密的预置主密钥位于所述握手应答报文的扩展字段中。
19.一种建立连接的装置，其特征在于，包括：
握手请求报文接收模块，用于接收客户端发送的握手请求报文；所述握手请求报文包括客户端密钥标识和客户端验证码；所述客户端密钥标识和所述客户端验证码位于所述握手请求报文的扩展字段中；
客户端验证模块，用于根据所述客户端密钥标识和所述客户端验证码，对所述客户端进行验证，并在对所述客户端验证成功的情况下发送握手应答报文，在对所述客户端验证不成功的情况下不响应所述握手请求报文；所述客户端验证码根据共享密钥加密得到；
握手应答报文返回模块，用于当所述客户端验证通过后，向所述客户端返回握手应答报文；所述握手应答报文包括服务器验证码，以使所述客户端根据所述服务器验证码对服务器进行验证；所述服务器验证码根据共享密钥加密得到；
第二通道建立模块，用于建立与所述客户端之间的安全会话通道；所述安全会话通道为所述客户端对所述服务器验证通过后建立的通道。
20.根据权利要求19所述的装置，其特征在于，所述客户端验证模块，包括：
第二共享密钥获取子模块，用于根据所述客户端密钥标识，通过服务器密钥管理服务获取所述服务器中存储的所述客户端对应的共享密钥；
客户端验证子模块，用于根据所述客户端对应的共享密钥对所述客户端验证码进行解密，以对所述客户端进行验证。
21.根据权利要求19所述的装置，其特征在于，还包括：
服务器验证码生成模块，用于根据所述服务器中存储的所述客户端对应的共享密钥加密第四随机数，生成所述服务器验证码；
加密模块，用于根据所述服务器中存储的所述客户端对应的共享密钥加密第五随机数，生成采用共享密钥加密的预置主密钥。
22.根据权利要求21所述的装置，其特征在于，所述握手请求报文还包括第二随机数，所述握手应答报文还包括第三随机数和所述采用共享密钥加密的预置主密钥，所述第二通道建立模块，包括：
第二会话密钥生成子模块，用于根据所述第二随机数、所述第三随机数和所述第五随机数，生成与所述客户端之间的会话所使用的会话密钥；
第二会话密钥验证子模块，用于对与所述客户端之间的会话所使用的会话密钥进行交互验证，以建立与所述客户端之间的安全会话通道。
23.根据权利要求22所述的装置，其特征在于，所述第二会话密钥验证子模块，包括：
第一密钥验证报文接收单元，用于接收所述客户端发送的通过所述客户端生成的会话密钥加密后的第一密钥验证报文；
第一密钥验证报文解密单元，用于通过所述服务器生成的会话密钥对所述第一密钥验证报文进行解密，以对所述客户端生成的会话密钥进行验证；
第二密钥验证报文返回单元，用于向所述客户端返回通过所述服务器生成的会话密钥加密后的第二密钥验证报文，以使所述客户端对所述服务器生成的会话密钥进行验证。
24.根据权利要求22所述的装置，其特征在于，所述服务器验证码位于所述握手应答报文的扩展字段中，所述采用共享密钥加密的预置主密钥位于所述握手应答报文的扩展字段中。
25.一种装置，其特征在于，包括：
一个或多个处理器；和
其上存储有指令的一个或多个机器可读介质，当由所述一个或多个处理器执行时，使得所述装置执行如权利要求1-12任一项所述的方法。
26.一个或多个机器可读介质，其上存储有指令，当由一个或多个处理器执行时，使得装置执行如权利要求1-12任一项所述的方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810942598.4A CN110839240B (zh) | 2018-08-17 | 2018-08-17 | 一种建立连接的方法及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810942598.4A CN110839240B (zh) | 2018-08-17 | 2018-08-17 | 一种建立连接的方法及装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110839240A CN110839240A (zh) | 2020-02-25 |
| CN110839240B true CN110839240B (zh) | 2022-07-05 |
Family
ID=69573676
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810942598.4A Active CN110839240B (zh) | 2018-08-17 | 2018-08-17 | 一种建立连接的方法及装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110839240B (zh) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113660328B (zh) * | 2021-08-13 | 2024-02-06 | 京东科技信息技术有限公司 | 通信连接的建立方法及装置、存储介质及电子设备 |
| CN114979237B (zh) * | 2022-05-16 | 2024-05-24 | 咪咕文化科技有限公司 | 一种长连接验证方法、装置、设备及可读存储介质 |
| CN115720176B (zh) * | 2022-12-26 | 2023-09-19 | 南京汇荣信息技术有限公司 | 基于Socket通信报文内容的动态加密方法、系统、网络设备及计算机可读存储介质 |
| CN116939599B (zh) * | 2023-08-20 | 2024-06-07 | 敦和安全科技(武汉)有限公司 | 一种面向低性能设备的高速加密通信方法及装置 |
| CN117119449B (zh) * | 2023-10-20 | 2024-01-19 | 长江量子(武汉)科技有限公司 | 车云安全通信方法及系统 |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101431415A (zh) * | 2008-12-12 | 2009-05-13 | 天柏宽带网络科技（北京）有限公司 | 一种双向认证的方法 |
| CN101860546A (zh) * | 2010-06-18 | 2010-10-13 | 杭州电子科技大学 | 一种改进ssl握手协议的方法 |
| CN103338215A (zh) * | 2013-07-26 | 2013-10-02 | 中金金融认证中心有限公司 | 基于国密算法建立tls通道的方法 |
| US8782393B1 (en) * | 2006-03-23 | 2014-07-15 | F5 Networks, Inc. | Accessing SSL connection data by a third-party |
| CN104506534A (zh) * | 2014-12-25 | 2015-04-08 | 青岛微智慧信息有限公司 | 安全通信密钥协商交互方案 |
| CN104821930A (zh) * | 2014-02-03 | 2015-08-05 | 塔塔咨询服务公司 | 计算机实施的物联网数据报传输轻型认证系统和方法 |
| CN105141568A (zh) * | 2014-05-28 | 2015-12-09 | 腾讯科技（深圳）有限公司 | 安全通信通道建立方法及系统、客户端和服务器 |
| CN107040373A (zh) * | 2016-01-15 | 2017-08-11 | 富士通株式会社 | 相互认证方法及认证设备 |
| WO2017200791A1 (en) * | 2016-05-19 | 2017-11-23 | Alibaba Group Holding Limited | Method and system for secure data transmission |
| CN107404461A (zh) * | 2016-05-19 | 2017-11-28 | 阿里巴巴集团控股有限公司 | 数据安全传输方法、客户端及服务端方法、装置及系统 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5132222B2 (ja) * | 2007-08-13 | 2013-01-30 | 株式会社東芝 | クライアント装置、サーバ装置及びプログラム |
-
2018
- 2018-08-17 CN CN201810942598.4A patent/CN110839240B/zh active Active
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8782393B1 (en) * | 2006-03-23 | 2014-07-15 | F5 Networks, Inc. | Accessing SSL connection data by a third-party |
| CN101431415A (zh) * | 2008-12-12 | 2009-05-13 | 天柏宽带网络科技（北京）有限公司 | 一种双向认证的方法 |
| CN101860546A (zh) * | 2010-06-18 | 2010-10-13 | 杭州电子科技大学 | 一种改进ssl握手协议的方法 |
| CN103338215A (zh) * | 2013-07-26 | 2013-10-02 | 中金金融认证中心有限公司 | 基于国密算法建立tls通道的方法 |
| CN104821930A (zh) * | 2014-02-03 | 2015-08-05 | 塔塔咨询服务公司 | 计算机实施的物联网数据报传输轻型认证系统和方法 |
| CN105141568A (zh) * | 2014-05-28 | 2015-12-09 | 腾讯科技（深圳）有限公司 | 安全通信通道建立方法及系统、客户端和服务器 |
| CN104506534A (zh) * | 2014-12-25 | 2015-04-08 | 青岛微智慧信息有限公司 | 安全通信密钥协商交互方案 |
| CN107040373A (zh) * | 2016-01-15 | 2017-08-11 | 富士通株式会社 | 相互认证方法及认证设备 |
| WO2017200791A1 (en) * | 2016-05-19 | 2017-11-23 | Alibaba Group Holding Limited | Method and system for secure data transmission |
| CN107404461A (zh) * | 2016-05-19 | 2017-11-28 | 阿里巴巴集团控股有限公司 | 数据安全传输方法、客户端及服务端方法、装置及系统 |
Non-Patent Citations (2)
| Title |
|---|
| "Mutual authentication protocol using identity-based shared secret key in cloud environments";Sandeep Saxena;《International Conference on Recent Advances and Innovations in Engineering (ICRAIE-2014)》;20140925;全文 * |
| 王国伟 ; 贾宗璞 ; 彭维平."基于动态共享密钥的移动RFID双向认证协议".《电子学报》.2017, * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110839240A (zh) | 2020-02-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109347835B (zh) | 信息传输方法、客户端、服务器以及计算机可读存储介质 | |
| CN110839240B (zh) | 一种建立连接的方法及装置 | |
| CN110380852B (zh) | 双向认证方法及通信系统 | |
| CN108401011B (zh) | 内容分发网络中握手请求的加速方法、设备及边缘节点 | |
| CN112564912B (zh) | 建立安全连接的方法、系统、装置和电子设备 | |
| CN106878016A (zh) | 数据发送、接收方法及装置 | |
| CN106788989B (zh) | 一种建立安全加密信道的方法及设备 | |
| CN105915342A (zh) | 一种应用程序通信处理系统、设备、装置及方法 | |
| CN113225352B (zh) | 一种数据传输方法、装置、电子设备及存储介质 | |
| CN111935712A (zh) | 一种基于NB-IoT通信的数据传输方法、系统及介质 | |
| CN112637136A (zh) | 加密通信方法及系统 | |
| CN108809633B (zh) | 一种身份认证的方法、装置及系统 | |
| CN110536292A (zh) | 发送终端序列号的方法和装置以及认证方法和装置 | |
| KR20150079489A (ko) | 실시간 통신 방법 및 시스템 | |
| CN112312393A (zh) | 5g应用接入认证方法及5g应用接入认证网络架构 | |
| CN112332986B (zh) | 一种基于权限控制的私有加密通信方法及系统 | |
| CN115766119A (zh) | 通信方法、装置、通信系统及存储介质 | |
| CN110690966A (zh) | 终端与业务服务器连接的方法、系统、设备及存储介质 | |
| CN111010399A (zh) | 一种数据传输方法、装置、电子设备及存储介质 | |
| CN110581829A (zh) | 通信方法及装置 | |
| CN114173328B (zh) | 密钥交换方法、装置、电子设备 | |
| CN115499250A (zh) | 一种数据加密方法及装置 | |
| CN114826659A (zh) | 一种加密通讯方法及系统 | |
| CN111836260B (zh) | 一种认证信息处理方法、终端和网络设备 | |
| CN115396153A (zh) | 一种数据通信方法、计算机设备及存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40024805 Country of ref document: HK |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |