A communication method, device and storage medium based on a transport layer security protocol

Abstract

The application provides a communication method and device based on a transport layer security protocol and a storage medium, relates to the technical field of communication, and can use a non-certificate key information to replace a traditional certificate in a communication process based on the transport layer security protocol, so that bandwidth resources occupied by a certificate transmission process are reduced in the communication process. The method comprises the following steps: in a second handshake process based on the transport layer security protocol, receiving non-certificate key information of a server sent by a server, wherein the non-certificate 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 the transport layer security protocol, verifying the non-certificate key information of the server based on the identifier of the server; and after verification, sending non-certificate key information of a client to the server, wherein the non-certificate key information of the client comprises an identifier of a second signature public key and an identifier of a second encryption public key.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a communication method, apparatus and storage medium based on a transport layer security protocol. Background Technology

[0002] Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are security protocols designed to provide security and data integrity guarantees for internet communications. In traditional TLS communication, to ensure security, a Certificate Authority (CA) issues public key certificates to users to verify their identity and guarantee communication security.

[0003] While user certificates ensure communication security, the transmission of certificates consumes significant bandwidth resources during connection establishment, especially for low-power IoT devices. With fixed server bandwidth, the number of connected devices is limited by the certificate size. Certificate management is also complex, with the processes of storing, issuing, and revoking certificates for massive numbers of IoT devices consuming considerable resources. Therefore, ensuring lightweight communication connections is a pressing issue that needs to be addressed. Summary of the Invention

[0004] This application provides a communication method, apparatus, and storage medium based on a transport layer security protocol, which reduces the bandwidth resources consumed by operations such as transmission during communication based on the transport layer security protocol, while taking into account the security of the communication connection process.

[0005] Firstly, a communication method based on a transport layer security protocol is provided, applied to a client. The method includes: during a second handshake process based on the transport layer security protocol, receiving certificateless key information from the server, the certificateless key information including an identifier of a first signing public key and an identifier of a first encryption public key; during a third handshake process based on the transport layer security protocol, verifying the certificateless key information from the server based on the server's identifier; and after successful verification, sending the client's certificateless key information to the server, the client's certificateless key information including an identifier of a second signing public key and an identifier of a second encryption public key.

[0006] The technical solution provided in this application provides at least the following beneficial effects: It can be seen that this application receives and verifies the certificateless key information sent by the server during the second and third handshake processes based on the transport layer security protocol. After successful verification, the client sends the client's certificateless key information to the server. By using certificateless key information to replace the certificate in the traditional communication process, the bandwidth resources consumed by operations such as outgoing transmission during transport layer security protocol communication are reduced, while also ensuring the security of the communication connection process.

[0007] As one possible implementation, during the third handshake process based on the transport layer security protocol, a key exchange message is sent to the server, which includes a random number encrypted with a second public key.

[0008] As one possible implementation, during the first handshake process based on the transport layer security protocol, a handshake request message is sent to the server. The handshake request message is used to indicate the use of a certificateless key authentication method.

[0009] Secondly, a communication method based on a transport layer security protocol is provided, applied to a server. The method includes: during the second handshake process based on the transport layer security protocol, sending the server's certificateless key information to the client, the server's certificateless key information including an identifier of a first signing public key and an identifier of a first encryption public key; during the third handshake process based on the transport layer security protocol, receiving the client's certificateless key information sent by the client, the client's certificateless key information including an identifier of a second signing public key and an identifier of a second encryption public key; and verifying the client's certificateless key information based on the client's identifier.

[0010] The technical solution provided in this application provides at least the following beneficial effects: It can be seen that this application sends the server's certificateless key information to the client during the second and third handshake processes based on the Transport Layer Security (TLS) protocol, and receives and verifies the client's certificateless key information sent by the client. By using certificateless key information to replace the certificate in the traditional communication process, the bandwidth resources consumed by operations such as outgoing transmission during TLS-based communication are reduced, while also ensuring the security of the communication connection process.

[0011] As one possible implementation, during the third handshake process based on the transport layer security protocol, a client key exchange message sent by the client is received. The client key exchange message includes a random number encrypted by the second encryption public key. A second encryption public key is generated according to the identifier of the second encryption public key. The random number encrypted by the second encryption public key is decrypted using the second encryption public key.

[0012] As one possible implementation, during the first handshake process based on the transport layer security protocol, a handshake request message sent by the client is received. The handshake request message is used to indicate the use of a certificateless key authentication method.

[0013] Thirdly, a client device is provided, comprising: a receiving module, configured to receive server-side certificateless key information sent by a server during a second handshake process based on a transport layer security protocol, the server-side certificateless key information including an identifier of a first signing public key and an identifier of a first encryption public key; a verification module, configured to verify the server-side certificateless key information based on the server-side identifier during a third handshake process based on the transport layer security protocol; and a sending module, configured to send client-side certificateless key information to the server after successful verification, the client-side certificateless key information including an identifier of a second signing public key and an identifier of a second encryption public key.

[0014] As one 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 a random number encrypted with a second public key.

[0015] As one possible implementation, the sending module is also used to send a handshake request message to the server 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.

[0016] Fourthly, a server-side apparatus is provided, comprising: a sending module, configured to send server-side certificateless key information to a client during a second handshake process based on a transport layer security protocol, the server-side certificateless key information including an identifier of a first signing public key and an identifier of a first encryption public key; a receiving module, configured to receive client-side certificateless key information sent by the client during a third handshake process based on a transport layer security protocol, the client-side certificateless key information including an identifier of a second signing public key and an identifier of a second encryption public key; and a verification module, configured to verify the client-side certificateless key information based on the client's identifier.

[0017] As one possible implementation, the receiving module is also used to receive a 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 a random number encrypted by the second encryption public key. The above-mentioned device also includes: a generation module, used to generate a second encryption public key according to the identifier of the second encryption public key; and a decryption module, used to decrypt the random number encrypted by the second encryption public key using the second encryption public key.

[0018] As one possible implementation, the receiving module is also used to receive a 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.

[0019] Fifthly, a client device is provided, the device including a processor, which executes a computer program to implement the communication method based on the transport layer security protocol as described in the first aspect.

[0020] In a sixth aspect, a server apparatus is provided, the apparatus including a processor, which executes a computer program to implement the communication method based on the transport layer security protocol as described in the second aspect.

[0021] A seventh aspect provides a computer-readable storage medium comprising computer instructions; wherein, when executed, the computer instructions implement a communication method based on a transport layer security protocol as described in the first or second aspect.

[0022] The beneficial effects described in aspects three through seven of this application can be referred to the analysis of the beneficial effects of aspects one or two, and will not be repeated here. Attached Figure Description

[0023] Figure 1 A conventional communication flowchart based on a transport layer security protocol is provided for embodiments of this application;

[0024] Figure 2 This application provides a schematic diagram of the structure of a communication system according to an embodiment of the present application.

[0025] Figure 3 A flowchart illustrating a communication method based on a transport layer security protocol provided in this application embodiment;

[0026] Figure 4 A flowchart illustrating another communication method based on a transport layer security protocol provided in this application embodiment;

[0027] Figure 5 A complete flowchart illustrating a communication method based on a transport layer security protocol, provided for an embodiment of this application;

[0028] Figure 6 An interactive flowchart illustrating a communication method based on a transport layer security protocol provided in this application embodiment;

[0029] Figure 7 An interactive flowchart illustrating another communication method based on a transport layer security protocol provided in this application embodiment;

[0030] Figure 8An interactive flowchart illustrating another communication method based on a transport layer security protocol provided in this application embodiment;

[0031] Figure 9 An interactive flowchart illustrating another communication method based on a transport layer security protocol provided in this application embodiment;

[0032] Figure 10 This is a schematic diagram of the structure of a client device provided in an embodiment of this application;

[0033] Figure 11 This is a schematic diagram of the structure of a server device provided in an embodiment of this application;

[0034] Figure 12 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application. Detailed Implementation

[0035] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0036] In the description of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Furthermore, "at least one" means one or more, and "multiple" means two or more. The words "first," "second," etc., do not limit the quantity or order of execution, and "first," "second," etc., do not necessarily imply difference. It should be noted that in this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific manner. In the embodiments of this application, "instruction" can include direct and indirect instructions. For example, taking the first control information in the following text as an example, the first control information can directly carry information A itself or its index to achieve the purpose of directly instructing information A. Alternatively, the first control information can also carry information B that is related to information A, thereby achieving the purpose of indirectly instructing information A while instructing information B.

[0037] As described in the background section, current TLS (Transport Layer Security) communication largely employs the traditional Public Key Infrastructure (PKI) / Trusted Certificate Authority (CA) certificate system. PKI / CA based on digital certificates is a widely used public key cryptography system, where the 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 CA's signature. In the PKI / CA process, the certificate format typically uses X.509, which generally has a data length of 1K-2K.

[0038] Among them, such as Figure 1 As shown, TLS requires a four-way handshake to establish a secure connection.

[0039] The first handshake process includes:

[0040] S1. The client sends a Handshake Request message (CL ient Hello) to the server; correspondingly, the server receives the CL ient Hello message sent by the client. The CL ient Hello message includes the TLS protocol version supported by the client, a random number generated by the client, the session ID, the cipher suites supported by the client, a list of compression algorithms supported by the client, and extended content.

[0041] The second handshake process includes:

[0042] S2. The server parses the Client Helllo message sent by the client and sends a Server Helllo message to the client in response. Correspondingly, the client receives the Server Helllo message sent by the server. The Server Helllo message includes the TLS version selected by the server, a random number generated by the server, the session ID, the cipher suite selected by the server, the compression algorithm selected by the server, and extended content.

[0043] S3. The server sends a Certificate message to the client; correspondingly, the client receives a Certificate message sent by the server. The Certificate message includes the server's certificate, which is in X.509 standard format. The certificate content includes the server's public key, the server's domain name, the issuing party's information, and the validity period information.

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

[0045] S5. The server sends a Key Request Message (Certificate Request) to the client; correspondingly, the client receives the Certificate Request Message sent by the server. The Certificate Request Message is used to request the client to send its certificate.

[0046] S6. The server sends a "Server Hello Done" message to the client; correspondingly, the client receives the "Server Hello Done" message sent by the server. The "Server Hello Done" message indicates that the server has completed sending all content related to the key exchange.

[0047] The third handshake process includes:

[0048] S7. The client sends a Certif icate message to the server; correspondingly, the server receives the Certif icate message sent by the client. The Certif icate message includes the client's certificate.

[0049] S8. The client sends a Client Random Number Message (Climate Key Exchange Message) to the server; correspondingly, the server receives the Climate Key Exchange Message sent by the client. The Climate Key Exchange Message includes the random number sent by the server.

[0050] S9. The client sends a Certify Verify message to the server; correspondingly, the server receives the Certify Verify message sent by the client. The Certify Verify message includes the digital signatures of all handshake messages sent during the three-way handshake process.

[0051] S10. The client sends a Change Cipher Spec message to the server; correspondingly, the server receives the Change Cipher Spec message sent by the client. The Change Cipher Spec message indicates that the client will begin encrypted transmission from the next handshake message.

[0052] S11. The client sends a Fini-shed handshake digest message to the server; correspondingly, the server receives the Fini-shed message sent by the client. The Fini-shed message includes a digital digest of all handshake information.

[0053] The fourth handshake includes:

[0054] S12. The server sends a Change Cipher Spec message to the client; correspondingly, the client receives the Change Cipher Spec message sent by the server. The Change Cipher Spec message indicates that the server will begin encrypted transmission from the next handshake message.

[0055] S13. The server sends a Fini-shed handshake digest message to the client; correspondingly, the client receives the Fini-shed message sent by the server. The Fini-shed message includes a digital digest of all handshake information.

[0056] In the handshake process described above, although TLS communication achieves identity authentication and communication encryption, it uses traditional authentication and certificate structures 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. With fixed server bandwidth, the number of devices connected will be limited by the certificate size. Using PKI / CA certificates for authentication based on TLS communication has two main disadvantages: (1) The number of CA frame digits 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 IoT devices with limited storage space and network bandwidth. (2) CA certificate management is complex. For the issuance, storage, and revocation of certificates for a large number of IoT devices, a large amount of time and bandwidth resources are required. How to ensure communication security while taking into account the convenience of the communication process, so as to reduce the occupation of additional bandwidth resources due to certificate transmission and other processes during communication, is an urgent problem to be solved.

[0057] Based on this, this application provides a communication method based on a transport layer security protocol. The idea is that, in the process of establishing a communication connection based on a transport layer security protocol, a certificateless key information is used instead of a traditional CA certificate, thereby achieving lightweight communication based on the transport layer security protocol and ensuring the security of the TLS communication process.

[0058] For example, Figure 2A schematic diagram of a communication system provided in an embodiment of this application is shown. The communication system may include a certificateless password management platform, a client, and a server. The server can communicate with one or more clients. It should be noted that... Figure 2 The diagram shown is merely a schematic representation of the communication system that can be applied to the embodiments of this application, in order to help those skilled in the art understand the technical content of this disclosure. However, it does not mean that the embodiments of this application cannot be used in other devices, systems, environments, or scenarios.

[0059] The certificateless password management platform is used to generate certificateless key information for the client / server by receiving the client / server's unique identifier information and public key during the initialization process. It can manage, store, and revoke the certificateless key information of the client / server.

[0060] The client can have various applications installed that support multiple types of transmission protocols, such as web browsers, search applications, shopping applications, instant messaging tools, email clients, and / or social media platforms (for example only). The client can be various electronic devices with a display screen that support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0061] The server can be a server that provides various services, such as a backend management server that supports the website browsed by the user using the client. The backend management server can analyze and process the data received from user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the client.

[0062] like Figure 3 As shown in the figure, this application provides a communication method based on a transport layer security protocol, applied to a client. The method includes the following steps:

[0063] S301. During the second handshake process based on the transport layer security protocol, receive the server's certificateless key information sent by the server.

[0064] The certificateless key information on the server side includes the identifier of the first signing public key and the identifier of the first encryption public key.

[0065] S302. During the third handshake process based on the transport layer security protocol, the server's certificateless key information is verified based on the server's identifier; after successful verification, the client's certificateless key information is sent to the server.

[0066] In some embodiments, during communication based on transport layer security protocols, the TLS cipher suite used by the client and server without a certificate-based cryptographic identifier integrates basic cryptographic functions.

[0067] The basic cryptographic functions include at least one of the following: verification of certificate-less key information, verification of the handshake message digest, or encryption of the handshake message. Verification of certificate-less key information is based on the Chinese national cryptographic algorithm SM2; verification of the handshake message digest is based on the Chinese national cryptographic algorithm SM3; and encryption of the handshake message is based on the Chinese national cryptographic algorithm SM4.

[0068] For example, 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 digest message. The specific content of the above messages is described below.

[0069] In some embodiments, during the client's verification of the server's uncertified key information, the server's uncertified key information is processed using the national cryptographic algorithm SM2 to obtain the server's identifier. If the obtained server identifier matches the server's identifier during the handshake process, the verification is successful, and the client continues to establish a secure connection with the server.

[0070] For example, in the third handshake process based on the transport layer security protocol, the server's identifier is 010101. The client receives the certificateless key information sent by the server and verifies it. The client verifies the server's certificateless key information using the basic cryptographic operation function in the certificateless key identifier suite, and performs calculations on the server's certificateless key information using the Chinese national cryptographic algorithm SM2. The resulting server identifier is 010101, which matches the server's identifier in the handshake process, indicating successful verification. The client and server then continue to establish a secure connection.

[0071] In another example, during the third handshake based on the Transport Layer Security (TLS) protocol, the server's identifier is 010101. The client receives the certificateless key information sent by the server and verifies it. The client verifies the server's certificateless key information using the basic cryptographic operation function in the certificateless key identifier suite. It performs calculations on the server's certificateless key information using the Chinese national cryptographic algorithm SM2. The resulting server identifier is 101010, which is inconsistent with the server identifier during the handshake process, i.e., the verification fails, and the client terminates the connection with the server.

[0072] In some embodiments, the client generates a first signing public key based on the first signing public key identifier in the server's certificateless key information. The first signing public key is used to verify messages signed by the certificateless private key.

[0073] In some embodiments, the client generates a first encryption public key based on the identifier of the first encryption public key in the server's certificateless key information. The first encryption public key is used to decrypt messages encrypted by the first encryption public key.

[0074] The technical solution provided in this application provides at least the following beneficial effects: In the communication process based on the transport layer security protocol, the client receives and verifies the server's certificateless key information, and after successful verification, sends the client's certificateless key information to the server. In the above process, certificateless key information replaces the traditional certificate, reducing the transmission burden in the handshake process based on the transport layer security protocol and improving the lightweight nature of communication.

[0075] like Figure 4 As shown in the figure, this application embodiment provides another communication method based on a transport layer security protocol, applied to a server. The method includes the following steps:

[0076] S401. During the second handshake process based on the transport layer security protocol, the server sends the certificateless key information to the client.

[0077] The certificateless key information on the server side includes the identifier of the first signing public key and the identifier of the first encryption public key.

[0078] In some embodiments, the server generates a first signing public key based on the identifier of the first signing public key in the server's certificateless key information. The first signing public key is used to verify messages signed by the server's certificateless private key.

[0079] In some embodiments, the server generates a first encryption public key based on the identifier of the first encryption public key in the server's certificateless key information. 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.

[0080] S402. During the third handshake process based on the transport layer security protocol, receive the client's uncertified key information sent by the client.

[0081] The client's certificateless key information includes the identifier of the second signing public key and the identifier of the second encryption public key.

[0082] In some embodiments, the server can generate a second signing public key based on the second signing public key identifier in the client's certificateless key information. The second signing public key is used to verify messages signed by the client's certificateless private key.

[0083] In some embodiments, the server can generate a second encryption public key based on the identifier of the second encryption public key in the client's certificateless key information. The second encryption public key is used to decrypt messages encrypted by the second encryption public key.

[0084] S403. Verify the client's uncertified key information based on the client's identifier.

[0085] In some embodiments, during the server's verification of the client's uncertified key information, the uncertified key information is processed using the national cryptographic algorithm SM2 to obtain the client's identifier. If the obtained client identifier matches the client's identifier during the handshake process, the verification is successful, and the server continues to establish a secure connection with the client.

[0086] For example, in the third handshake process based on the Transport Layer Security (TLS) protocol, the client's identifier is 111000. The server receives the certificateless key information sent by the client and verifies it. The server verifies the client's certificateless key information using the basic cryptographic operation function in the certificateless key identifier suite. It performs calculations on the client's certificateless key information using the Chinese national cryptographic algorithm SM2. The resulting client identifier is 010101, which matches the client's identifier during the handshake process, indicating successful verification. The server and client then continue to establish a secure connection.

[0087] In another example, during the third handshake based on the Transport Layer Security (TLS) protocol, the client's identifier is 111000. The server receives the certificateless key information sent by the client and verifies it. The server verifies the client's certificateless key information using the basic cryptographic operation function in the certificateless key identifier suite. It performs calculations on the client's certificateless key information using the Chinese national cryptographic algorithm SM2. The resulting server identifier is 000111, which is inconsistent with the client's identifier during the handshake process, i.e., verification fails, and the server terminates the connection with the client.

[0088] The technical solution provided in this application embodiment 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 certificateless key information to the client, receives the client's certificateless key information sent by the client and verifies it; in the above communication process, the use of certificateless key information replaces the certificate in the traditional process, reduces the bandwidth burden in the communication process, improves the lightweightness of the communication process, and ensures the security of the communication process.

[0089] like Figure 5 As shown in the figure, this application provides a complete communication method based on a transport layer security protocol, which includes the following steps:

[0090] S501, Initialization Phase.

[0091] like Figure 6 As shown, step S1 can be specifically implemented as follows:

[0092] S5101: The server calls the extended interface in the certificateless password management platform to generate the server's public and private keys.

[0093] The extended interface in the certificateless password management platform is used to provide the key generation function on the service side and the certificateless key envelope parsing function on the service side.

[0094] S5102. The server sends its identifier and public key to the certificateless password management platform, so that the certificateless password management platform can generate the server's certificateless key information based on the server's identifier and public key.

[0095] For example, the certificateless password management platform calls the extended interface to generate the certificateless key information of the server based on the server's identifier and public key, combined with the basic cryptographic operation functions in the TLS encryption suite.

[0096] The certificateless key information on the server side includes the identifier of the first signing public key and the identifier of the first encryption public key.

[0097] In some embodiments, the certificateless cryptography management platform also generates a certificateless key envelope for the server based on the server's identifier and public key. This certificateless key envelope includes a first signing public key envelope and a first encryption public key envelope.

[0098] S5103. The server obtains the certificateless key information generated by the certificateless password management platform.

[0099] S5104. The server calls the extended interface in the certificateless password management platform to generate a certificateless private key for the server.

[0100] For example, the certificateless password management platform stores the certificateless key information of the server and parses the certificateless key envelope of the server to generate the certificateless private key of the server.

[0101] The server's uncertified private key is used to sign the handshake information during the handshake process based on the transport layer security protocol, proving that the uncertified key information received by the client from the server corresponds to the server.

[0102] S5105: The client calls the extended interface in the certificateless password management platform to generate the client's public and private keys.

[0103] S5106. The client sends its identifier and public key to the certificateless password management platform, so that the certificateless password management platform can generate the client's certificateless key information based on the client's identifier and public key.

[0104] For example, the certificateless password management platform calls the extended interface to generate the certificateless key information of the server based on the server's identifier and public key, combined with the basic cryptographic operation functions in the TLS encryption suite.

[0105] The client's certificateless key information includes the identifier of the second signing public key and the identifier of the second encryption public key.

[0106] In some embodiments, the certificateless cryptography management platform also generates a certificateless key envelope for the client based on the client's identifier and public key. This certificateless key envelope includes a second signing public key envelope and a second encryption public key envelope.

[0107] S5107. The client obtains the certificateless key information generated by the certificateless password management platform.

[0108] S5108: The client calls the extended interface in the certificateless password management platform to generate the client's certificateless private key.

[0109] For example, the certificateless password management platform stores the certificateless key information of the client and parses the certificateless key envelope of the client to generate the certificateless private key of the client.

[0110] The client's uncertified private key is used to sign the handshake information during the handshake process based on the transport layer security protocol, proving that the uncertified key information received by the server from the client corresponds to the client.

[0111] S502, First Handshake Procedure.

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

[0113] The handshake request message is used to instruct the server to use a certificateless key authentication method during communication based on transport layer security protocols.

[0114] The handshake request message is equivalent to the Close Hello message in traditional TLS communication. A handshake request message may include at least one of the following: a TLS protocol version supported by the client that does not have certificate-identifying cryptographic authentication, a random number generated by the client, TLS cipher suites supported by the client that do not have certificate-identifying cryptographic authentication, a list of compression algorithms supported by the client, or extended content filled in by the client.

[0115] The TLS cipher suite without certificate password identification is used for client public key generation, certificateless envelope decryption and parsing, and certificateless key information synthesis.

[0116] For example, the handshake request message includes the TLS protocol version supported by the client without certificate identifier cipher authentication, such as 1.0, 1.1, or 1.2; a random number generated by the client, such as 10; TLS cipher suites supported by the client without certificate identifier cipher authentication, such as ECDH_RSA or ECDH_ECDSA; a list of compression algorithms supported by the client, such as Deflate, GZIP, or LZO; and SNI extensions filled in by the client.

[0117] S503, Second Handshake Procedure.

[0118] like Figure 7 As shown, step S3 can be specifically implemented as follows:

[0119] S5201, The server parses the handshake request message sent by the client.

[0120] The handshake request message can be a handshake request message.

[0121] In some embodiments, the server determines the selectable parameter information during the connection establishment process by parsing the handshake request message sent by the client.

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

[0123] The handshake response message is the Server Hell message.

[0124] A Server Hell message may include at least one of the following: a TLS protocol version with no certificate-based cipher authentication selected by the server, a random number selected by the server, a TLS cipher suite with no certificate-based cipher authentication selected by the server, a compression algorithm selected by the server, or extended content filled by the server.

[0125] For example, 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 for this communication process; randomly selects one of the TLS cipher suites without certificate cipher identifiers supported by the client, such as ECDH_RSA, as the TLS cipher suite for this communication process; and randomly selects one of the compression algorithms supported by the client, such as GZIP, as the compression algorithm list for this communication process.

[0126] S5203, The server sends the certificateless key information from the server to the client; correspondingly, the client receives the certificateless key information from the server.

[0127] The certificateless key information on the server side includes the identifier of the first signing public key and the identifier of the first encryption public key.

[0128] In this embodiment, the format of the certificateless key information of the server can be X.509. In actual application, the format of the certificateless key information of the server can be set according to the requirements. This embodiment does not limit it in any way.

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

[0130] The Key Information Request message is used to request the client to send its uncertified key information to the server. For example, the Key Information Request message can be a Certificate Request message.

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

[0132] The key completion message indicates that the server has finished sending the certificate-less key information. For example, the key completion message can be a Server Hell Done message.

[0133] S504, the third handshake process.

[0134] like Figure 8 As shown, step S4 can be specifically implemented as follows:

[0135] S5301: The client verifies the certificateless key information sent by the server.

[0136] S5302, The client sends its uncertified key information to the server; correspondingly, the server receives the uncertified key information from the client.

[0137] In some embodiments, after the client sends its uncertified key information to the server, the client uses its uncertified signing private key to digitally sign the handshake information sent subsequently, indicating that the uncertified key information sent by the client to the server corresponds to the uncertified signing private key owned by the client.

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

[0139] The key exchange message is equivalent to the Closed Key Exchange message in traditional TLS communication. The key exchange message includes a random number encrypted by the client using a second public key from the client's uncertified key information.

[0140] For example, the client uses the identifier of the second encryption public key in the client's certificateless 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.

[0141] In some embodiments, during the third handshake process based on the transport layer security protocol, the server receives a key exchange message sent by the client; generates a second encryption public key based on the identifier of the second encryption public key; and decrypts a random number encrypted by the second encryption public key using the second encryption public key.

[0142] S5304. The client sends an encrypted instruction message to the server; correspondingly, the server receives the encrypted instruction message from the client.

[0143] The Change Cipher Spec message is used to inform the server that the next handshake message will be transmitted in encrypted form. For example, the Change Cipher Spec message can be used as the encryption indication message.

[0144] S5305: The client sends a handshake summary message to the server, and the server receives the handshake summary message from the client.

[0145] The handshake summary message includes a summary of all handshake information during the handshake process. For example, the handshake summary message can be a Finite Shed message.

[0146] In some embodiments, the client uses the SM3 hash algorithm to digest the handshake information, integrates it into a Finished message, generates a second encryption key based on the second encryption key identifier, and encrypts it using the second encryption public key before sending it to the server.

[0147] S505, the fourth handshake process.

[0148] like Figure 9 As shown, step S5 can be specifically implemented as follows:

[0149] S5401. The server verifies the certificateless key information sent by the client.

[0150] S5402, The server verifies the client's digital signature.

[0151] The server generates a second signature public key based on the identifier of the second signature public key in the client's certificateless key information, and uses the second signature public key to authenticate the client's digital signature.

[0152] S5403, The server sends an encrypted instruction message to the client; correspondingly, the client receives the encrypted instruction message from the server.

[0153] The encryption indication message is used to inform the client that the next handshake message will be transmitted in encrypted form. For example, the encryption indication message can be a Change Cipher Spec message.

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

[0155] The handshake summary message includes a summary of all handshake information during the handshake process. For example, the handshake summary message can be a Finite Shed message.

[0156] In some embodiments, the server uses the SM3 hash algorithm to digest the handshake information and integrates it into a handshake digest message, which is then sent to the client. The above mainly describes the solution provided by the embodiments of this application from a methodological perspective. To achieve the above functions, it includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0157] This application embodiment can divide the communication device into functional modules according to the above method example. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. Optionally, the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0158] Figure 10 This diagram illustrates the structure of a client device according to an embodiment of this application. Figure 10 As shown, the client device 60 includes a receiving module 601, a verification module 602, and a sending module 603.

[0159] The receiving module 601 is used to receive the server's uncertified key information sent by the server during the second handshake process based on the transport layer security protocol. The server's uncertified key information includes the identifier of the first signing public key and the identifier of the first encryption public key.

[0160] The verification module 602 is used to verify the server's uncertified key information based on the server's identifier during the third handshake process based on the transport layer security protocol.

[0161] The sending module 603 is used to send the client's certificateless key information to the server after successful verification. The client's certificateless key information includes the identifier of the second signing public key and the identifier of the second encryption public key.

[0162] 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 a random number encrypted by the second encryption public key.

[0163] 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, the handshake request message being used to indicate the use of a certificateless key authentication method.

[0164] Figure 11 This diagram illustrates the structure of a server-side device according to an embodiment of this application. Figure 11 As shown, 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.

[0165] The sending module 701 is used to send the server's certificateless key information to the client during the second handshake process based on the transport layer security protocol. The server's certificateless key information includes the identifier of the first signing public key and the identifier of the first encryption public key.

[0166] The receiving module 702 is used to receive the client's uncertified key information sent by the client during the third handshake process based on the transport layer security protocol. The client's uncertified key information includes the identifier of the second signing public key and the identifier of the second encryption public key.

[0167] The verification module 703 is used to verify the client's uncertified key information based on the client's identifier.

[0168] In some embodiments, the receiving module 702 is further configured to receive a 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 including a random number encrypted by the second encryption public key; the above apparatus further includes: a generation module 704, configured to generate a second encryption public key according to the identifier of the second encryption public key; and a decryption module 705, configured to decrypt the random number encrypted by the second encryption public key using the second encryption public key.

[0169] In some embodiments, the receiving module 702 is further configured to receive a 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 an authentication method without a certificate key.

[0170] When the functions of the integrated modules described above are implemented in hardware, the embodiments of this application provide client and server devices for reference. Figure 12 The results of the communication device shown. For example... Figure 12 As shown, the communication device 80 includes: a processor 802, a bus 804, and a communication interface 803.

[0171] The communication interface 803 is used to connect to other devices via a communication network. This communication network can be Ethernet, wireless access network, wireless local area network (WLAN), etc.

[0172] The memory 801 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0173] In one possible implementation, the memory 801 can exist independently of the processor 802. The memory 801 can be connected to the processor 802 via a bus 804 and is used to store instructions or program code. When the processor 802 calls and executes the instructions or program code stored in the memory 801, it can implement the communication method based on the transport layer security protocol provided in this application embodiment.

[0174] In another possible implementation, the memory 801 can also be integrated with the processor 802.

[0175] The 804 bus can be an Extended Industry Standard Architecture (EISA) bus, etc. The 804 bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 12 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0176] This application also provides a computer-readable storage medium, which includes computer-executable instructions that, when executed on a computer, cause the computer to perform the method provided in the above embodiments.

[0177] This application also provides a computer program product that can be directly loaded into a memory and contains software code. After being loaded and executed by a computer, the computer program product can implement the methods provided in the above embodiments.

[0178] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in this application can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium accessible to a general-purpose or special-purpose computer.

[0179] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A communication method based on a transport layer security protocol, characterized in that, Applied to a client, the method includes: during the second handshake process based on the transport layer security protocol, receiving server-side certificateless key information sent by the server, wherein the server-side certificateless key information includes an identifier of a first signing public key and an identifier of a first encryption public key; and the server-side certificateless key information is generated by a certificateless cryptography management platform based on the server-side identifier and the server-side public key; During the third handshake process based on the transport layer security protocol, the server's certificateless key information is verified based on the server's identifier. After successful verification, the client's certificateless key information is sent to the server. The client's certificateless key information includes the identifier of the second signature public key and the identifier of the second encryption public key. The client's certificateless key information is generated by the certificateless cryptography management platform based on the client's identifier and the client's public key.

2. The method according to claim 1, characterized in that, The method further includes: During the third handshake process based on the transport layer security protocol, a key exchange message is sent to the server. The key exchange message includes a random number encrypted with a second encryption public key. The second encryption public key is generated by the client based on the second encryption public key identifier in its own certificateless key information.

3. The method according to claim 2, characterized in that, The method further includes: During the first handshake process based on the transport layer security protocol, a handshake request message is sent to the server. The handshake request message is used to indicate the use of a certificateless key authentication method. The certificateless key information corresponding to the certificateless key authentication method is generated by the certificateless cryptography management platform based on the identifier and public key of the communicating party.

4. A communication method based on a transport layer security protocol, characterized in that, Applied to the server side, the method includes: During the second handshake process based on the transport layer security protocol, the server sends certificateless key information to the client. The certificateless key information of the server includes the identifier of the first signing public key and the identifier of the first encryption public key. The certificateless key information of the server is generated by the certificateless cryptography management platform based on the server's identifier and the server's public key. During the third handshake process based on the transport layer security protocol, the client's certificateless key information is received from the client. The client's certificateless key information includes the identifier of the second signing public key and the identifier of the second encryption public key. The certificateless key information is generated by the certificateless cryptography management platform based on the client's identifier and the client's public key. The client's certificateless key information is verified based on the client's identifier.

5. The method according to claim 4, characterized in that, The method further includes: During the third handshake process based on the transport layer security protocol, a client key exchange message sent by the client is received, the client key exchange message including a random number encrypted by the second encryption public key; Generate the second encryption public key based on the identifier of the second encryption public key; The random number encrypted with the second public key is decrypted.

6. The method according to claim 5, characterized in that, The method further includes: During the first handshake process based on the transport layer security protocol, a handshake request message sent by the client is received. The handshake request message is used to indicate the use of a certificateless key authentication method. The certificateless key authentication method and the corresponding server certificateless key information and client certificateless key information are both generated by the certificateless password management platform based on the server identifier and server public key, client identifier and client public key.

7. A client device, characterized in that, The device includes: The receiving module is used to receive the server's certificateless key information sent by the server during the second handshake process based on the transport layer security protocol. The server's certificateless key information includes the identifier of the first signing public key and the identifier of the first encryption public key. The certificateless key information is generated by the certificateless cryptography management platform based on the server's identifier and the server's public key. The verification module is used to verify the certificateless key information of the server based on the server's identifier during the third handshake process based on the transport layer security protocol. The sending module is used to send the client's certificateless key information to the server after successful verification. The client's certificateless key information includes the identifier of the second signing public key and the identifier of the second encryption public key. The certificateless key information is generated by the certificateless password management platform based on the client's identifier and the client's public key.

8. The apparatus according to claim 7, characterized in that, 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 key exchange message including a random number encrypted by the second encryption public key; the device further includes a generation module configured to generate the second encryption public key based on the second encryption public key identifier in the client's certificateless key information.

9. The apparatus according to claim 8, characterized in that, The sending module is also used to send a handshake request message to the server 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. The certificateless key information corresponding to the certificateless key authentication method is generated by the certificateless password management platform based on the identifier and public key of the communicating party.

10. A server-side device, characterized in that, The device includes: a sending module, configured to send server-side certificateless key information to the client during the second handshake process based on the transport layer security protocol, wherein the server-side certificateless key information includes an identifier of a first signing public key and an identifier of a first encryption public key; and the server-side certificateless key information is generated by a certificateless cryptography management platform based on the server-side identifier and the server-side public key; The receiving module is used to receive the client's certificateless key information sent by the client during the third handshake process based on the transport layer security protocol. The client's certificateless key information includes the identifier of the second signing public key and the identifier of the second encryption public key. The certificateless key information is generated by the certificateless cryptography management platform based on the client's identifier and the client's public key. The verification module is used to verify the client's certificateless key information based on the client's identifier.

11. The apparatus according to claim 10, characterized in that, The receiving module is also configured to receive a 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 including a random number encrypted by the second encryption public key; The device further includes: The generation module is used to generate the second encrypted public key based on the identifier of the second encrypted public key; the identifier of the second encrypted public key is part of the client's certificateless key information generated by the certificateless password management platform; The decryption module is used to decrypt a random number encrypted with the second encryption public key using the second encryption public key.

12. The apparatus according to claim 11, characterized in that, The receiving module is also used to receive a 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. The certificateless key authentication method corresponds to the server certificateless key information and the client certificateless key information, which are generated by the certificateless password management platform based on the server identifier and server public key, client identifier and client public key.

13. A client device, characterized in that, The device includes a processor that, when executing a computer program, implements the communication method based on a transport layer security protocol as described in any one of claims 1 to 3.

14. A server-side device, characterized in that, The device includes a processor that, when executing a computer program, implements the communication method based on a transport layer security protocol as described in any one of claims 4 to 6.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer instructions; wherein, when the computer instructions are executed, they implement the communication method based on a transport layer security protocol as described in any one of claims 1 to 6.

Images