CN116318943A - Communication method, device and storage medium based on transport layer security protocol - Google Patents

Abstract

The application provides a communication method, a device and a storage medium based on a transmission layer security protocol, which relate to the technical field of communication and can use certificate-free key information to replace a traditional certificate in the communication process of the transmission layer security protocol, so that bandwidth resources occupied by processes such as certificate transmission and the like are reduced in the communication process. The method comprises the following steps: in a second handshake process based on a transport layer security protocol, receiving certificate-free key information of a server sent by the server, wherein the certificate-free key information of the server comprises an identifier of a first signature public key and an identifier of a first encryption public key; in a third handshake process based on a transport layer security protocol, verifying certificate-free key information of a server based on an identifier of the server; and after the verification is passed, sending the client-side certificateless key information to the server-side, wherein the client-side certificateless key information comprises the identification of the second signature public key and the identification of the second encryption public key.

Description

Communication method, device and storage medium based on transport layer security protocol

technical field

The present application relates to the technical field of communication, and in particular to a communication method, device and storage medium based on a transport layer security protocol.

Background technique

TLS and its predecessor, Secure Sockets Layer, are security protocols designed to provide security and data integrity guarantees for Internet communications. In the communication process of the traditional transport layer security protocol, in order to ensure the security of the communication, it is necessary for the certificate issuing authority (Certificate Authority, CA) to issue a public key certificate for the user to verify the real identity of the user and ensure the security of the communication. Communication Security.

Although user certificates guarantee the security of communication, during the establishment of communication connections, for low-power IoT devices, the transmission of certificates will occupy a large amount of bandwidth resources. In the case of fixed server bandwidth, the number of devices connected will be limited by the size of the certificate. The certificate management method is also relatively complicated, and the process of certificate storage, issuance, and revocation for massive IoT devices consumes a lot. Therefore, how to ensure the lightness of the communication connection is an urgent problem to be solved.

Contents of the invention

The embodiment of the present application provides a communication method, device, and storage medium based on the transport layer security protocol, which are used to reduce the bandwidth resources consumed by operations such as the transmission process in the communication process based on the transport layer security protocol, and take into account the communication connection process security in .

In the first aspect, a communication method based on the transport layer security protocol is provided, which is applied to the client, and the method includes: in the second handshake process based on the transport layer security protocol, receiving the certificateless certificate of the server sent by the server Key information, the non-certificate key information of the server includes the identification of the first signature public key and the identification of the first encryption public key; in the third handshake process based on the transport layer security protocol, based on the identification of the server, the service The non-certificate key information of the terminal is verified; after the verification is passed, the non-certificate key information of the client is sent to the server, and the non-certificate key information of the client includes the identification of the second signature public key and the identification of the second encryption public key.

The technical solutions provided by the embodiments of the present application bring at least the following beneficial effects: It can be seen that the present application receives and verifies the wireless data sent by the server during the second handshake and the third handshake based on the transport layer security protocol. Certificate key information, after the verification is successful, send the client's non-certificate key information to the server. In the above process, certificateless key information is used to replace the certificate in the traditional communication process, which reduces the bandwidth resources consumed by operations such as the outgoing process in the communication process based on the transport layer security protocol, and takes into account the security of the communication connection process .

As a possible implementation, during the third handshake process based on the transport layer security protocol, a key exchange message is sent to the server, and the key exchange message includes a random number encrypted by the second encrypted public key.

As a possible implementation, in the first handshake process based on the transport layer security protocol, a handshake request message is sent to the server, and the handshake request message is used to indicate the use of an authentication method without a certificate key.

In the second aspect, a communication method based on the transport layer security protocol is provided, which is applied to the server, and the method includes: in the second handshake process based on the transport layer security protocol, sending the certificateless encryption key of the server to the client. Key information, the non-certificate key information of the server includes the identification of the first signature public key and the identification of the first encryption public key; in the third handshake process based on the transport layer security The certificate key information, the certificate-free key information of the client includes the identification of the second signature public key and the identification of the second encryption public key; based on the identification of the client, the certificate-free key information of the client is verified.

The technical solution provided by the embodiment of the application brings at least the following beneficial effects: It can be seen that the application sends the server's certificateless encryption key to the client during the second handshake and the third handshake based on the key information, and receive and verify the client's non-certificate key information sent by the client. In the above process, certificateless key information is used to replace the certificate in the traditional communication process, which reduces the bandwidth resources consumed by operations such as the outgoing process in the communication process based on the transport layer security protocol, and takes into account the security of the communication connection process .

As a possible implementation, in the third handshake process based on the transport layer security protocol, the client key exchange message sent by the client is received, and the client key exchange message includes the key encrypted by the second encrypted public key An encrypted random number; according to the identification of the second encrypted public key, generate a second encrypted public key; use the second encrypted public key to decrypt the random number encrypted by the second encrypted public key.

As a possible implementation, in the first handshake process based on the transport layer security protocol, the handshake request message sent by the client is received, and the handshake request message is used to indicate the authentication mode without a certificate key.

In a third aspect, a client device is provided, and the device includes: a receiving module, configured to receive the certificate-less key information of the server sent by the server during the second handshake process based on the transport layer security protocol, and the server's The non-certificate key information includes the identification of the first signature public key and the identification of the first encryption public key; the verification module is used to verify the identity of the server based on the identification of the server during the third handshake process based on the transport layer security protocol. The non-certificate key information is verified; the sending module is used to send the client's non-certificate key information to the server after the verification is passed. The client's non-certificate key information includes the identity of the second signature public key and the second encryption public key Key ID.

As a possible implementation, the sending module is also used to send a key exchange message to the server during the third handshake process based on the transport layer security protocol. The key exchange message includes the key exchange message encrypted by the second encrypted public key Encrypted random number.

As a possible implementation, the sending module is further configured to send a handshake request message to the server during the first handshake process based on the transport layer security protocol, and the handshake request message is used to indicate the use of wireless The authentication method of the certificate key.

In a fourth aspect, a server device is provided, the device includes: a sending module, configured to send the certificate-less key information of the server to the client during the second handshake process based on the transport layer security protocol, and the certificate-free key information of the server. The non-certificate key information includes the identification of the first signature public key and the identification of the first encryption public key; the receiving module is used to receive the client's client-side message sent by the client during the third handshake process based on the transport layer security protocol. The non-certificate key information of the terminal, the non-certificate key information of the client includes the identification of the second signature public key and the identification of the second encrypted public key; verify.

As a possible implementation, the receiving module is also configured to receive the client key exchange message sent by the client during the third handshake process based on the transport layer security protocol, the client key exchange message includes the The random number encrypted by the second encryption public key; the above-mentioned device also includes: a generating module, which is used to generate a second encryption public key according to the identification of the second encryption public key; a decryption module, which is used to use the second encryption public key to generate The random number encrypted with the second encrypted public key is decrypted.

As a possible implementation, the receiving module is also used to receive the handshake request message sent by the client during the first handshake process based on the transport layer security protocol. The handshake request message is used to indicate the use of a certificateless key authentication method.

According to a fifth aspect, there is provided a client device, the above-mentioned device includes a processor, and when the processor executes a computer program, the communication method based on the transport layer security protocol as described in the first aspect is implemented.

In a sixth aspect, there is provided a server device, the above-mentioned device includes a processor, and when the processor executes a computer program, the communication method based on the transport layer security protocol as described in the second aspect is implemented.

In a seventh aspect, a computer-readable storage medium is provided, the above-mentioned computer-readable storage medium includes computer instructions; wherein, when the computer instructions are executed, the communication based on the transport layer security protocol as in the first aspect or the second aspect is realized method.

In this application, the beneficial effects described in the third aspect to the seventh aspect can refer to the beneficial effect analysis of the first aspect or the second aspect, and will not be repeated here.

Description of drawings

Fig. 1 is a kind of traditional communication flowchart based on transport layer security protocol provided by the embodiment of the present application;

FIG. 2 is a schematic structural diagram of a communication system provided by an embodiment of the present application;

FIG. 3 is a schematic flowchart of a communication method based on a transport layer security protocol provided in an embodiment of the present application;

FIG. 4 is a schematic flowchart of another communication method based on a transport layer security protocol provided in an embodiment of the present application;

FIG. 5 is a schematic diagram of a complete flow of a communication method based on a transport layer security protocol provided in an embodiment of the present application;

FIG. 6 is an interaction flowchart of a communication method based on a transport layer security protocol provided in an embodiment of the present application;

FIG. 7 is an interactive flowchart of another communication method based on the transport layer security protocol provided by the embodiment of the present application;

FIG. 8 is an interactive flowchart of another communication method based on the transport layer security protocol provided by the embodiment of the present application;

FIG. 9 is an interactive flowchart of another communication method based on the transport layer security protocol provided by the embodiment of the present application;

FIG. 10 is a schematic structural diagram of a client device provided by an embodiment of the present application;

FIG. 11 is a schematic structural diagram of a server device provided in an embodiment of the present application;

FIG. 12 is a schematic structural diagram of a communication device provided by an embodiment of the present application.

Detailed ways

The following will clearly and completely describe the technical solutions of the embodiments of the present application in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, not all of them. Based on this The embodiments in the application, and all other embodiments obtained by persons of ordinary skill in the art without creative efforts, all belong to the scope of protection of the present application.

In the description of the present application, unless otherwise specified, "/" means "or", for example, A/B may mean A or B. The "and/or" in this article is just an association relationship describing associated objects, which means that there can be three relationships, for example, A and/or B, which can mean: A exists alone, A and B exist at the same time, and B exists alone These three situations. In addition, "at least one" means one or more, and "plurality" means two or more. Words such as "first" and "second" do not limit the number and order of execution, and words such as "first" and "second" do not necessarily limit the difference. It should be noted that, in this application, words such as "exemplary" or "for example" are used as examples, illustrations or illustrations. Any embodiment or design described herein as "exemplary" or "for example" is not to be construed as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete manner. In this embodiment of the application, "instruction" may include direct instruction and indirect instruction. For example, taking the first control information hereinafter as an example, the first control information may directly carry the information A itself or its index, so as to achieve the purpose of directly indicating the information A. Alternatively, the first control information may also carry information B that is associated with information A, so as to indirectly indicate information A while indicating information B.

As mentioned in the background art, most of the current communication based on the transport layer security protocol TLS adopts the traditional public key infrastructure PKI/trusted certificate authority CA certificate structure. PKI/CA based on digital certificates is a public key cryptosystem widely used at present, and CA issues a public key certificate for each user. The public key certificate includes the user's identity information, the user's public key and the signature of the CA. In the PKI/CA process, the format of the certificate generally adopts the X.509 format, and the certificate in this format generally has a data length of 1K-2K.

Wherein, as shown in FIG. 1 , establishing a secure connection with TLS requires a four-way handshake process.

The first handshake process includes:

S1. The client sends a handshake request message, a Cl ient Hello message, to the server; correspondingly, the server receives the Client Hello message sent by the client. Among them, the Client Hello message includes the TLS protocol version supported by the client, the random number generated by the client, the session ID, the encryption suite supported by the client, the list of compression algorithms supported by the client, and the extended content.

The second handshake process includes:

S2. The server parses the Client Hello message sent by the client, and sends a handshake response message, a Server Hello message, to the client; correspondingly, the client receives the Server Hello message sent by the server. Among them, the Server Hello message includes the TLS version selected by the server, the random number generated by the server, the session ID, the encryption suite selected by the server, the compression algorithm selected by the server, and the extended content.

S3. The server sends a Cert ificate message to the client; correspondingly, the client receives the key information message Certificate message sent by the server. The Certificate message includes the certificate of the server, which is in the X.509 standard format, and the content of the certificate includes the public key of the server, the domain name of the server, the information of the issuer, and the information of the validity period.

S4. The server sends a server random number message, a Server Key Exchange message, to the client; correspondingly, the client receives the Server Key Exchange message sent by the server. Wherein, the Server Key Exchange message includes security parameters used by the client to generate random numbers.

S5. The server sends a key request message Cert if icate Request t message to the client; correspondingly, the client receives the Cert if icate Request t message sent by the server. Wherein, the Certif icate Request message is used to request the client to send the certificate of the client.

S6. The server sends a key completion message, a Server Hello Done message, to the client; correspondingly, the client receives the Server Hello Done message sent by the server. Among them, the Server Hello Done message indicates that the server has sent all relevant content related to the key exchange.

The third handshake process includes:

S7. The client sends the key information message Cert if icate message to the server; correspondingly, the server receives the Cert if icate message sent by the client. Wherein, the Cert if icate message includes the certificate of the client.

S8. The client sends a client random number message, a Client Key Exchange message, to the server; correspondingly, the server receives the Client Key Exchange message sent by the client. Wherein, the Client Key Exchange message includes a random number sent by the server.

S9. The client sends a digital signature message Cert if icate Verify message to the server; correspondingly, the server receives the Cert if icate Verify message sent by the client. Wherein, the Certificate Verify message includes digital signatures of all handshake messages during the three-way handshake process.

S10. The client sends an encrypted indication message Change Cipher Spec message to the server; correspondingly, the server receives the Change Cipher Spec message sent by the client. Among them, the Change Cipher Spec message is used to indicate that the client starts encrypted transmission from the next handshake information.

S11. The client sends a handshake summary message Fini shed message to the server; correspondingly, the server receives the Fini shed message sent by the client. Among them, the Fini shed message includes a digital summary of all handshake information.

The fourth handshake includes:

S12. The server sends an encrypted indication message Change Cipher Spec message to the client; correspondingly, the client receives the Change Cipher Spec message sent by the server. Among them, the Change Cipher Spec message is used to indicate that the server starts encrypted transmission from the next handshake information.

S13. The server sends the handshake summary message Fini shed message to the client; correspondingly, the client receives the Fini shed message sent by the server. Among them, the Fini shed message includes a digital summary of all handshake information.

In the above handshake process, although TLS communication implements identity authentication and communication encryption, traditional authentication and certificate structures are used in the process of establishing a secure connection. For low-power IoT devices, data collection and certificate transmission will occupy a large amount of bandwidth resources. When the bandwidth of the server is fixed, the number of devices connected will be limited by the size of the certificate. The use of PKI/CA certificates for authentication based on TSL communication mainly includes two disadvantages: (1) The number of bytes in the CA frame is too large, and the certificate needs to occupy a large amount of network bandwidth and storage resources during transmission and storage, which is not suitable for storage space and IoT devices with limited network bandwidth. (2) The management of CA certificates is complex, and the issuance, storage, and revocation of massive IoT device certificates consume a lot of time and bandwidth resources. How to take into account the portability of the communication process in the case of guaranteed communication security, so as to reduce the occupation of additional bandwidth resources caused by the transmission of certificates and other processes during the communication process, is an urgent problem to be solved.

Based on this, the embodiment of the present application provides a communication method based on the transport layer security protocol. The idea is: in the process of establishing a communication connection based on the transport layer security protocol, by using non-certificate key information instead of the traditional CA certificate, It realizes the lightweight communication based on the transport layer security protocol, and guarantees the security in the TLS communication process.

Exemplarily, FIG. 2 shows a schematic structural diagram of a communication system provided by an embodiment of the present application. The communication system may include a non-certificate password management platform, a client, and a server, and the server may communicate with one or more clients. It should be noted that Figure 2 is only a schematic diagram of the results of the communication system to which the embodiment of the present application can be applied, to help those skilled in the art understand the technical content of the present disclosure, but it does not mean that the embodiment of the present application cannot be used for Other equipment, systems, environments or scenarios.

The certificateless password management platform is used to generate certificateless key information for the client/server by receiving the unique identification information and public key of the client/server during the initialization process, so as to realize the certificateless encryption of the client/server. Key information can be managed, stored, revoked, etc.

Various applications supporting multiple types of transmission protocols can be installed on the client, such as web browser applications, search applications, shopping applications, instant messaging tools, email clients and/or social platform software, etc. (only example). Clients can be various electronic devices that have a display screen and support web browsing, including but not limited to smartphones, tablet computers, laptops, desktop computers, and the like.

The server can be a server that provides various services, such as a background management server that provides support for the website that the user browses through the client. The background management server can analyze and process received data such as user requests, and feed back processing results (such as web pages, information, or data obtained or generated according to user requests) to the client.

As shown in Figure 3, the embodiment of the present application provides a communication method based on the transport layer security protocol, which is applied to the client, and the method includes the following steps:

S301. During the second handshake process based on the transport layer security protocol, receive the certificateless key information of the server sent by the server.

Wherein, the non-certificate key information of the server includes the identification of the first signature public key and the identification of the first encryption public key.

S302. In the third handshake process based on the transport layer security protocol, based on the identification of the server, verify the certificate-free key information of the server; after the verification is passed, send the certificate-free key information of the client to the server information.

In some embodiments, during the communication process based on the transport layer security protocol, the TLS cipher suite identified by the certificateless cipher used by the client and the server integrates a basic cryptographic operation function.

Wherein, the basic cryptographic operation function includes at least one of the following functions: certificateless key information verification, digest verification of handshake information or encryption of handshake information. The verification of the key information without a certificate is based on the national secret SM2 algorithm; the summary verification of the handshake information is based on the national secret SM3 algorithm; the encryption of the handshake information is based on the national secret SM4 algorithm.

Exemplarily, the handshake information may include at least one of the following: a handshake request message, a handshake response message, a key completion message, a key exchange message, an encryption instruction message, or a handshake summary message. The content contained in the above message is specifically described as follows.

In some embodiments, during the verification process of the client on the server's non-certificate key information, the server's non-certificate key information is calculated using the national secret SM2 algorithm to obtain the identification of the server. If the calculated server ID is consistent with the server ID in the handshake process, the verification is successful, and the client continues to establish a secure connection with the server.

Exemplarily, in the third handshake process based on the transport layer security protocol, the identifier of the server is 010101, and the client receives and verifies the non-certificate key information sent by the server. The client verifies the non-certificate key information of the server through the basic cipher operation function in the suite of the non-certificate cipher identification, and uses the national secret SM2 algorithm to calculate the non-certificate key information of the server, and the server identification obtained by the operation is 010101 , which is consistent with the identity of the server during the handshake process, that is, the verification is successful, and the client and the server continue to establish a secure connection.

In yet another example, in the third handshake process based on the transport layer security protocol, the identifier of the server is 010101, and the client receives and verifies the non-certificate key information sent by the server. The client verifies the non-certificate key information of the server through the basic cipher operation function in the suite of the non-certificate cipher identification, and uses the national secret SM2 algorithm to calculate the non-certificate key information of the server, and the server identification obtained by the operation is 101010 , is inconsistent with the identification of the server during the handshake process, that is, the authentication fails, and the client disconnects from the server.

In some embodiments, the client generates the first public signature key according to the identifier of the first public signature key in the non-certificate key information of the server. The first signature public key is used to verify the message signed by the non-certificate private key.

In some embodiments, the client generates the first encrypted public key according to the identifier of the first encrypted public key in the certificate-free key information of the server. The first encrypted public key is used to decrypt the message encrypted by the first encrypted public key.

The technical solution provided by the embodiment of the present application brings at least the following beneficial effects: During the communication process based on the transport layer security protocol, the client receives and verifies the certificate-free key information of the server, and sends the certificate-free key information of the client after the verification is passed. key information to the server. In the above process, the traditional certificate is replaced by non-certificate key information, which reduces the transmission burden in the handshake process based on the transport layer security protocol and improves the lightness of communication.

As shown in Figure 4, the embodiment of the present application provides another communication method based on the transport layer security protocol, which is applied to the server, and the method includes the following steps:

S401. During the second handshake process based on the transport layer security protocol, send the certificateless key information of the server to the client.

Wherein, the non-certificate key information of the server includes the identification of the first signature public key and the identification of the first encryption public key.

In some embodiments, the server generates the first public signature key according to the identification of the first public signature key in the non-certificate key information of the server. The first signature public key is used to verify the message signed by the non-certificate private key of the server.

In some embodiments, the server generates the first encrypted public key according to the identifier of the first encrypted public key in the non-certificate key information of the server. The first encryption public key is used to encrypt the handshake information sent by the server during the handshake process based on the transport layer security protocol.

S402. During the third handshake process based on the transport layer security protocol, receive the client's non-certificate key information sent by the client.

Wherein, the client's non-certificate key information includes the identifier of the second signature public key and the identifier of the second encryption public key.

In some embodiments, the server may generate the second public signature key according to the second signature public key identifier in the certificate-free key information of the client. The second public signature key is used to verify the message signed by the non-certificate private key of the client.

In some embodiments, the server may generate the second encryption public key according to the identifier of the second encryption public key in the certificate-free key information of the client. The second encrypted public key is used to decrypt the message encrypted by the second encrypted public key.

S403. Based on the identifier of the client, verify the non-certificate key information of the client.

In some embodiments, during the process of verifying the client's non-certificate key information by the server, the client's non-certificate key information is calculated using the national secret SM2 algorithm to obtain the client's identity. If the calculated client ID is consistent with the client ID in the handshake process, the verification is successful, and the server continues to establish a secure connection with the client.

Exemplarily, in the third handshake process based on the transport layer security protocol, the identity of the client is 111000, and the server receives and verifies the non-certificate key information sent by the client. The server verifies the client's non-certificate key information through the basic cipher operation function in the non-certificate cipher suite, and uses the national secret SM2 algorithm to calculate the client's non-certificate key information. The client's identity obtained from the operation is 010101 , which is consistent with the identity of the client during the handshake process, that is, the verification is successful, and the server and client continue to establish a secure connection.

In yet another example, in the third handshake process based on the transport layer security protocol, the identity of the client is 111000, and the server receives and verifies the non-certificate key information sent by the client. The server verifies the client's non-certificate key information through the basic cipher operation function in the non-certificate cipher suite, and uses the national secret SM2 algorithm to calculate the client's non-certificate key information, and the calculated server ID is 000111 , is inconsistent with the identity of the client during the handshake process, that is, the verification fails, and the server terminates the connection with the client.

The technical solution provided by the embodiment of the present application brings at least the following beneficial effects: It can be seen that in the communication process based on the transport layer security protocol, the server sends the server's non-certificate key information to the client, and receives the client's key information sent by the client. The non-certificate key information of the terminal is verified; in the above communication process, the non-certificate key information is used to replace the certificate in the traditional process, which reduces the bandwidth burden in the communication process, improves the lightness of the communication process, and The security in the communication process is guaranteed.

As shown in Figure 5, the embodiment of the present application provides a complete communication method based on the transport layer security protocol, the method includes the following steps:

S501, an initialization phase.

As shown in Figure 6, step S1 can be specifically implemented as the following steps:

S5101. The server invokes an extension interface in the non-certificate password management platform to generate a public key and a private key of the server.

Among them, the extension interface in the certificateless password management platform is used to provide the key generation function of the server and the certificateless key envelope analysis function of the server.

S5102. The server sends the identification and public key of the server to the non-certificate password management platform, so that the non-certificate password management platform generates the non-certificate key information of the server according to the identification and public key of the server.

Exemplarily, the non-certificate password management platform invokes the extension interface, and generates the non-certificate key information of the server according to the identification of the server and the public key of the server combined with the basic cryptographic operation function in the TLS encryption suite.

Wherein, the non-certificate key information of the server includes the identification of the first signature public key and the identification of the first encryption public key.

In some embodiments, the non-certificate password management platform also generates the non-certificate key envelope of the server according to the identification and public key of the server. Wherein, the non-certificate key envelope of the server includes a first signed public key envelope and a first encrypted public key envelope.

S5103. The server acquires the non-certificate key information of the server generated by the non-certificate password management platform.

S5104. The server invokes an extension interface in the certificateless password management platform to generate a certificateless private key of the server.

Exemplarily, the non-certificate password management platform stores the non-certificate key information of the server, and parses the non-certificate key envelope of the server to generate the non-certificate private key of the server.

Wherein, the non-certificate private key of the server is used to sign the handshake information during the handshake process based on the transport layer security protocol, and is used to prove that the non-certificate key information received by the client from the server corresponds to the server.

S5105. The client invokes the extension interface in the certificateless password management platform to generate a public key and a private key of the client.

S5106. The client sends the client's identification and public key to the certificateless password management platform, so that the certificateless password management platform generates the client's certificateless key information according to the client's identification and public key.

Exemplarily, the non-certificate password management platform invokes the extension interface, and generates the non-certificate key information of the server according to the identification of the server and the public key of the server combined with the basic cryptographic operation function in the TLS encryption suite.

Wherein, the client's non-certificate key information includes the identifier of the second signature public key and the identifier of the second encryption public key.

In some embodiments, the certificateless password management platform also generates the client's certificateless key envelope according to the client's identifier and public key. Wherein, the non-certificate key envelope of the client includes a second signed public key envelope and a second encrypted public key envelope.

S5107. The client acquires certificate-free key information of the client generated by the certificate-free password management platform.

S5108. The client invokes an extension interface in the certificate-free password management platform to generate a certificate-free private key of the client.

Exemplarily, the non-certificate password management platform stores the client non-certificate key information, and parses the client non-certificate key envelope to generate the client non-certificate private key.

Among them, the client's non-certificate private key is used to sign the handshake information during the handshake process based on the transport layer security protocol, and is used to prove that the non-certificate key information received by the server from the client corresponds to the client.

S502. A first handshake process.

The client sends a handshake request message to the server; correspondingly, the server receives the handshake request message from the client.

Wherein, the handshake request message is used to instruct the server to adopt an authentication mode without a certificate key in the communication process based on the transport layer security protocol.

The handshake request message is equivalent to the Client Hello message in the traditional TLS communication process. The handshake request message may include at least one of the following: the TLS protocol version supported by the client for authentication without a certificate-identified password, the random number generated by the client, the TLS cipher suite supported by the client without a certificate-identified password, and the compression supported by the client Algorithm list or extended content populated by the client.

The TLS cipher suite identified by the certificate-free cipher is used for client-side public key generation, certificate-free envelope decapsulation and analysis, and certificate-free key information synthesis.

Exemplarily, the handshake request message includes the TLS protocol version supported by the client without certificate identification password authentication, such as 1.0, 1.1, 1.2; the random number generated by the client, such as 10; the TLS protocol version supported by the client without certificate identification password authentication Cipher suites, such as ECDH_RSA, ECDH_ECDSA; the list of compression algorithms supported by the client, such as Def late, GZIP, LZO; the extension content filled by the client is the SNI extension.

S503. A second handshake process.

As shown in Figure 7, step S3 can be specifically implemented as the following steps:

S5201. The server parses the handshake request message sent by the client.

Wherein, the handshake request message may be a client hello message.

In some embodiments, the server determines optional parameter information during connection establishment by analyzing the handshake request message sent by the client.

S5202. The server sends a handshake response message to the client; correspondingly, the client receives the handshake response message from the server.

Wherein, the handshake response message is a Server Hello message.

The Server Hello message may include at least one of the following: the TLS protocol version selected by the server for authentication without a certificate password, the random number selected by the server, the TLS cipher suite identified by a certificateless password selected by the server, and the compression protocol selected by the server. Algorithm or extended content filled by the server.

Exemplarily, following the example in S2, the server selects the highest version 1.2 of the protocol version supported by the client as the TLS protocol version in this communication process; randomly selects a One, such as ECDH_RSA as the TLS encryption suite in this communication process; randomly select one from the compression algorithm list supported by the client, such as GZIP as the compression algorithm list in this communication process.

S5203. The server sends the non-certificate key information of the server to the client; correspondingly, the client receives the non-certificate key information from the server.

Wherein, the non-certificate key information of the server includes the identification of the first signature public key and the identification of the first encryption public key.

In the embodiment of this application, the format of the non-certificate key information of the server can be X.509, and the format of the non-certificate key information of the server can be set according to the requirements during the actual application process. Do not make any restrictions.

S5204. The server sends a key information request message to the client; correspondingly, the client receives the key information request message from the server.

Wherein, the key information request message is used to request the client to send the client's non-certificate key information to the server. Exemplarily, the key information request message may be a Certificate Request t message.

S5205. The server sends a key completion message to the client; correspondingly, the client receives the key completion message from the server.

Wherein, the key completion message is used to indicate that the non-certificate key information of the server has been sent. Exemplarily, the key completion message may be a Server Hello Done message.

S504. A third handshake process.

As shown in Figure 8, step S4 can be specifically implemented as the following steps:

S5301. The client verifies the non-certificate key information sent by the server.

S5302. The client sends the certificateless key information of the client to the server; correspondingly, the server receives the certificateless key information from the client.

In some embodiments, after the client sends the client's non-certificate key information to the server, the client uses the client's non-certificate signature private key to digitally sign the handshake information sent later, which is used to indicate that the client sends to the server The non-certificate key information corresponds to the non-certificate signing private key owned by the client.

S5303. The client sends a key exchange message to the server; correspondingly, the server receives the key exchange message from the client.

Wherein, the key exchange message is equivalent to the Client Key Exchange message in the traditional TLS communication process. The key exchange message includes a random number encrypted by the client using the second encrypted public key in the certificateless key information of the client.

Exemplarily, the client uses the identifier of the second encryption public key in the client's non-certificate key information to generate a second encryption public key, and uses the second encryption public key to encrypt the random number in the key exchange message.

In some embodiments, during the third handshake process based on the transport layer security protocol, the server receives the key exchange message sent by the client; generates the second encrypted public key according to the identity of the second encrypted public key; The random number encrypted by the second encryption public key is decrypted with the second encryption public key.

S5304. The client sends an encrypted indication message to the server; correspondingly, the server receives the encrypted indication message from the client.

Wherein, the encryption instruction message Change Cipher Spec message is used to inform the server to start encrypted transmission of the next handshake information. Exemplarily, the encrypted indication message may be a Change C ipher Spec message.

S5305. The client sends a handshake summary message to the server, and correspondingly, the server receives the handshake summary message from the client.

Wherein, the handshake summary message includes a summary of all handshake information during the handshake process. Exemplarily, the handshake summary message may be a Fini shed message.

In some embodiments, the client uses the national secret SM3 digest algorithm to digest the handshake information, and after integrating it into a Fini shed message, generates a second encryption key according to the second encryption key identifier, and uses the second encryption public key to perform Encrypted and sent to the server.

S505 , a fourth handshake process.

As shown in Figure 9, step S5 can be specifically implemented as the following steps:

S5401. The server verifies the non-certificate key information sent by the client.

S5402. The server verifies the digital signature of the client.

The server generates the second signature public key according to the identification of the second signature public key in the certificate-free key information of the client, and uses the second signature public key to authenticate the digital signature of the client.

S5403. The server sends an encrypted indication message to the client; correspondingly, the client receives the encrypted indication message from the server.

Wherein, the encryption instruction message is used to inform the client that the next piece of handshake information starts encrypted transmission. Exemplarily, the encrypted indication message may be a Change Cipher Spec message.

S5404. The server sends a handshake summary message to the client; correspondingly, the client receives the handshake summary message from the server.

Wherein, the handshake summary message includes a summary of all handshake information during the handshake process. Exemplarily, the handshake summary message may be a Fini shed message.

In some embodiments, the server uses the national secret SM3 digest algorithm to digest the handshake information, and integrates it into a handshake summary message and sends it to the client. The foregoing mainly introduces the solutions provided by the embodiments of the present application from the perspective of methods. In order to realize the above functions, it includes corresponding hardware structures and/or software modules for performing various functions. Those skilled in the art should easily realize that the embodiments of the present application can be implemented in the form of hardware or a combination of hardware and computer software in combination with the example units and algorithm steps described in the embodiments disclosed herein. Whether a certain function is executed by hardware or computer software drives hardware depends on the specific application and design constraints of the technical solution. Skilled artisans may use different methods to implement the described functions for each specific application, but such implementation should not be regarded as exceeding the scope of the present application.

In the embodiment of the present application, the functional modules of the communication device may be divided according to the above method example. For example, each functional module may be divided corresponding to each function, or two or more functions may be integrated into one processing module. The above-mentioned integrated modules can be implemented in the form of hardware or in the form of software function modules. Optionally, the division of modules in this embodiment of the present application is schematic, and is only a logical function division, and there may be another division manner in actual implementation.

FIG. 10 shows a schematic structural diagram of a client device provided by an embodiment of the present application. As shown in FIG. 10 , the client device 60 includes a receiving module 601 , a verification module 602 , and a sending module 603 .

The receiving module 601 is configured to receive the certificateless key information of the server sent by the server during the second handshake process based on the transport layer security protocol. The certificateless key information of the server includes the identity of the first signature public key and Identification of the first encrypted public key.

The verification module 602 is configured to verify the non-certificate key information of the server based on the identifier of the server during the third handshake process based on the transport layer security protocol.

The sending module 603 is configured to send the certificateless key information of the client to the server after the verification is passed, and the certificateless key information of the client includes the identification of the second signature public key and the identification of the second encryption public key.

In some embodiments, the sending module 603 is further configured to send a key exchange message to the server during the third handshake process based on the transport layer security protocol, the key exchange message includes of random numbers.

In some embodiments, the sending module 603 is further configured to send a handshake request message to the server during the first handshake process based on the transport layer security protocol, and the handshake request message is used to indicate that certificateless Authentication method of the key.

FIG. 11 shows a schematic structural diagram of a server device provided by an embodiment of the present application. As shown in FIG. 11 , the server device 70 includes a sending module 701 , a receiving module 702 , a verification module 703 , a generation module 704 , and a decryption module 705 .

The sending module 701 is configured to send the certificateless key information of the server to the client during the second handshake process based on the transport layer security protocol. The certificateless key information of the server includes the identity of the first signature public key and Identification of the first encrypted public key.

The receiving module 702 is configured to receive the client's non-certificate key information sent by the client during the third handshake process based on the transport layer security protocol, the client's non-certificate key information includes the second signature public key ID and ID of the second encrypted public key.

The verification module 703 is configured to verify the certificate-less key information of the client based on the identification of the client.

In some embodiments, the receiving module 702 is further configured to receive the client key exchange message sent by the client during the third handshake process based on the transport layer security protocol, the client key exchange message includes the The random number encrypted by the second encrypted public key; the above-mentioned device also includes: a generation module 704, which is used to generate a second encrypted public key according to the identification of the second encrypted public key; a decryption module 705, which is used to use the second encrypted public key to The random number encrypted by the second encrypted public key is decrypted.

In some embodiments, the receiving module 702 is also configured to receive a handshake request message sent by the client during the first handshake process based on the transport layer security protocol, and the handshake request message is used to indicate the use of certificate-less key verification method.

In the case that the functions of the above-mentioned integrated modules are implemented in the form of hardware, the results of the client device and the server device provided in the embodiment of the present application may refer to the results of the communication device shown in FIG. 12 . As shown in FIG. 12 , the communication device 80 includes: a processor 802 , a bus 804 and a communication interface 803 .

The communication interface 803 is used to connect with other devices through the communication network. The communication network may be Ethernet, wireless access network, wireless local area network (wireless local area networks, WLAN) and so on.

The memory 801 may be a read-only memory (read-only memory, ROM) or other types of static storage devices that can store static information and instructions, a random access memory (random access memory, RAM) or other types that can store information and instructions Type of dynamic storage device, also can be electrically erasable programmable read-only memory (electrically erasable programmable read-only memory, EEPROM), magnetic disk storage medium or other magnetic storage devices, or can be used to carry or store instructions or Desired program code in the form of a data structure and any other medium capable of being accessed by a computer, but not limited thereto.

As a possible implementation manner, the memory 801 may exist independently of the processor 802, and the memory 801 may be connected to the processor 802 through the bus 804, and is used for storing instructions or program codes. When the processor 802 invokes and executes the instructions or program codes stored in the memory 801, the communication method based on the transport layer security protocol provided by the embodiment of the present application can be implemented.

In another possible implementation manner, the memory 801 may also be integrated with the processor 802 .

The bus 804 may be an extended industry standard architecture (extended indus try standard architecture, EISA) bus or the like. The bus 804 can be divided into address bus, data bus, control bus and so on. For ease of representation, only one thick line is used in FIG. 12 , but it does not mean that there is only one bus or one type of bus.

The embodiment of the present application also provides a computer-readable storage medium, the computer-readable storage medium includes computer-executable instructions, and when the computer-executable instructions are run on the computer, the computer is made to execute the method provided in the foregoing embodiments.

The embodiment of the present application also provides a computer program product, which can be directly loaded into a memory and contains software codes. After being loaded and executed by a computer, the computer program product can implement the methods provided in the above embodiments.

Those skilled in the art should be aware that, in the above one or more examples, the functions described in this application may be implemented by hardware, software, firmware or any combination thereof. When implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a general purpose or special purpose computer.

The above is only a specific implementation of the application, but the protection scope of the application is not limited thereto, and any changes or replacements within the technical scope disclosed in the application should be covered within the protection scope of the application . Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims (15)

1. A communication method based on a transport layer security protocol, characterized in that it is applied to a client, and the method comprises: In the second handshake process based on the transport layer security protocol, the certificateless key information of the server sent by the server is received, and the certificateless key information of the server includes the identity of the first signature public key and the first encrypted public key. identification of the key; In the third handshake process based on the transport layer security protocol, based on the identification of the server, verify the non-certificate key information of the server; after the verification is passed, send the client's key information to the server The non-certificate key information of the client includes the identification of the second signature public key and the identification of the second encryption public key. 2. The method according to claim 1, characterized in that the method further comprises: In the third handshake process based on the transport layer security protocol, a key exchange message is sent to the server, and the key exchange message includes a random number encrypted by the second encrypted public key. 3. The method according to claim 2, wherein the method further comprises: In the first handshake process based on the transport layer security protocol, a handshake request message is sent to the server, and the handshake request message is used to indicate that an authentication mode without a certificate key is adopted. 4. A communication method based on a transport layer security protocol, characterized in that it is applied to a server, and the method comprises: In the second handshake process based on the transport layer security protocol, the certificateless key information of the server is sent to the client, and the certificateless key information of the server includes the identification of the first signature public key and the first encryption public key logo; In the third handshake process based on the transport layer security protocol, receiving the client's non-certificate key information sent by the client, the client's non-certificate key information includes the identity of the second signature public key and identification of the second encryption public key; Based on the identifier of the client, the certificateless key information of the client is verified. 5. method according to claim 4, is characterized in that, described method also comprises: In the third handshake process based on the transport layer security protocol, receiving the client key exchange message sent by the client, the client key exchange message includes a random number encrypted by the second encrypted public key ; generating the second encrypted public key according to the identifier of the second encrypted public key; Decrypt the random number encrypted by the second encryption public key with the second encryption public key. 6. The method according to claim 5, further comprising: In the first handshake process based on the transport layer security protocol, a handshake request message sent by the client is received, and the handshake request message is used to indicate that an authentication mode without a certificate key is adopted. 7. A client device, characterized in that the device comprises: The receiving module is configured to receive the certificateless key information of the server sent by the server during the second handshake process based on the transport layer security protocol, and the certificateless key information of the server includes the identification of the first signature public key and the identification of the first encrypted public key; A verification module, configured to verify the non-certificate key information of the server based on the identifier of the server during the third handshake process based on the transport layer security protocol; A sending module, configured to send the certificate-free key information of the client to the server after the verification is passed, the certificate-free key information of the client includes the identity of the second signature public key and the identity of the second encryption public key logo. 8. The device according to claim 7, wherein the sending module is further configured to send a key exchange message to the server during the third handshake process based on the transport layer security protocol, the The key exchange message includes a random number encrypted by the second encrypted public key. 9. The device according to claim 8, wherein the sending module is further configured to send a handshake request message to the server during the first handshake process based on the transport layer security protocol, the The handshake request message is used to indicate the authentication mode without certificate key. 10. A server device, characterized in that the device comprises: The sending module is configured to send the certificate-free key information of the server to the client during the second handshake process based on the transport layer security protocol, and the certificate-free key information of the server includes the identity of the first signature public key and identification of the first encrypted public key; A receiving module, configured to receive the certificateless key information of the client sent by the client during the third handshake process based on the transport layer security protocol, where the certificateless key information of the client includes a second signature identification of the public key and identification of the second encrypted public key; A verification module, configured to verify the certificate-less key information of the client based on the identifier of the client. 11. The device according to claim 10, wherein the receiving module is further configured to receive the client key exchange message sent by the client during the third handshake process based on the transport layer security protocol. In the text, the client key exchange message includes a random number encrypted by the second encrypted public key; the device also includes: A generating module, configured to generate the second encrypted public key according to the identifier of the second encrypted public key; A decryption module, configured to use the second encryption public key to decrypt the random number encrypted by the second encryption public key. 12. The device according to claim 11, wherein the receiving module is further configured to receive the handshake request message sent by the client during the first handshake process based on the transport layer security protocol, the The above handshake request message is used to indicate the authentication mode without certificate key. 13. A client device, characterized in that the device comprises a processor, and when the processor executes a computer program, the communication method based on the transport layer security protocol according to any one of claims 1 to 3 is implemented. 14. A server device, characterized in that the device comprises a processor, and when the processor executes a computer program, the communication method based on the transport layer security protocol according to any one of claims 4 to 6 is realized. 15. A computer-readable storage medium, characterized in that the computer-readable storage medium comprises computer instructions; wherein, when the computer instructions are executed, the method based on any one of claims 1 to 6 is realized The communication method of the Transport Layer Security protocol.

Images