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

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

Info

Publication number
CN116318943A
CN116318943A CN202310222447.2A CN202310222447A CN116318943A CN 116318943 A CN116318943 A CN 116318943A CN 202310222447 A CN202310222447 A CN 202310222447A CN 116318943 A CN116318943 A CN 116318943A
Authority
CN
China
Prior art keywords
client
server
key
public key
certificate
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310222447.2A
Other languages
Chinese (zh)
Inventor
王首媛
张晓辉
孙宁宁
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China United Network Communications Group Co Ltd
China Information Technology Designing and Consulting Institute Co Ltd
Original Assignee
China United Network Communications Group Co Ltd
China Information Technology Designing and Consulting Institute Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China United Network Communications Group Co Ltd, China Information Technology Designing and Consulting Institute Co Ltd filed Critical China United Network Communications Group Co Ltd
Priority to CN202310222447.2A priority Critical patent/CN116318943A/en
Publication of CN116318943A publication Critical patent/CN116318943A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0863—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving passwords or one-time passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer And Data Communications (AREA)

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 disclosure relates to the field of communications technologies, and in particular, to a communications method, apparatus, and storage medium based on a transport layer security protocol.
Background
The transmission layer security protocol and the precursor security socket layer are one kind of security protocol, and the purpose is to provide security and data integrity guarantee for internet communication. In the communication process of the traditional transport layer security protocol, in order to ensure the communication security, a public key certificate is required to be issued for a user by a certificate issuing mechanism (Cert ificate Author i ty, CA) for verifying the true identity of the user and ensuring the communication security.
The user certificate ensures the safety of communication, but in the process of establishing communication connection, for the low-power-consumption internet of things equipment, the transmission of the certificate occupies a large amount of bandwidth resources. In the case of a fixed server bandwidth, the number of accesses by the device will be limited by the size of the certificate. The management mode of the certificate is also complex, and the consumption of the processes of certificate storage, issuing, revocation and the like of mass internet of things equipment is large. Therefore, how to ensure the lightweight of the communication connection is a problem to be solved.
Disclosure of Invention
The embodiment of the application provides a communication method, a device and a storage medium based on a transmission layer security protocol, which are used for reducing bandwidth resources consumed by operations such as a transmission process in a communication process based on the transmission layer security protocol and considering security in a communication connection process.
In a first aspect, a communication method based on a transport layer security protocol is provided, and the method is applied to a client, and includes: 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.
The technical scheme provided by the embodiment of the application at least brings the following beneficial effects: it can be seen that the method and the device for verifying the client-side certification-free key information in the second handshake and the third handshake based on the transport layer security protocol receive and verify the certification-free key information sent by the server-side, and send the certification-free key information of the client-side to the server-side after the verification is successful. The use of the non-certificate key information in the above process replaces the certificate in the traditional communication process, reduces the bandwidth resources consumed by operations such as the outgoing process in the communication process based on the transport layer security protocol, and considers the security in the communication connection process.
As a possible implementation manner, in the third handshake process based on the transport layer security protocol, a key exchange message is sent to the server, where the key exchange message includes a random number encrypted by the second encryption public key.
As a possible implementation manner, in the first handshake process based on the transport layer security protocol, a handshake request message is sent to the server, where the handshake request message is used to indicate an authentication manner using a certificate-free key.
In a second aspect, a communication method based on a transport layer security protocol is provided, and the method is applied to a server, and includes: in a second handshake process based on a transport layer security protocol, sending certificate-free key information of a server to a client, 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, receiving client-side certificateless key information sent by a client-side, wherein the client-side certificateless key information comprises an identifier of a second signature public key and an identifier of a second encryption public key; and verifying the certificate-free key information of the client based on the identification of the client.
The technical scheme provided by the embodiment of the application at least brings the following beneficial effects: it can be seen that the present application receives and verifies the client's certificate-free key information sent by the client by sending the client's certificate-free key information to the client during the second and third handshakes based on the transport layer security protocol. The use of the non-certificate key information in the above process replaces the certificate in the traditional communication process, reduces the bandwidth resources consumed by operations such as the outgoing process in the communication process based on the transport layer security protocol, and considers the security in the communication connection process.
As one possible implementation manner, in a third handshake process based on the transport layer security protocol, receiving a client key exchange message sent by the client, where the client key exchange message includes a random number encrypted by the second encryption public key; generating a second encryption public key according to the identification of the second encryption public key; the random number encrypted by the second encryption public key is decrypted with the second encryption public key.
As a possible implementation manner, in a first handshake process based on the transport layer security protocol, a handshake request message sent by a client is received, where the handshake request message is used to indicate an authentication manner using a certificate-free key.
In a third aspect, a client device is provided, where the device includes a receiving module, configured to receive, in a second handshake process based on a transport layer security protocol, certificate-free key information of a server sent by the server, where the certificate-free key information of the server includes an identifier of a first signed public key and an identifier of a first encrypted public key; the verification module is used for verifying the certificate-free key information of the server based on the identification of the server in the third handshake process based on the transport layer security protocol; and the sending module is used for sending the certification-free key information of the client to the server after the verification is passed, wherein the certification-free key information of the client comprises the identification of the second signature public key and the identification of the second encryption public key.
As a possible implementation manner, the sending module is further configured to send, in a third handshake process based on the transport layer security protocol, a key exchange packet to the server, where the key exchange packet includes a random number encrypted by the second encryption public key.
As a possible implementation manner, the sending module is further configured to send, in a first handshake process based on a transport layer security protocol, a handshake request packet to the server, where the handshake request packet is used to indicate an authentication manner using a certificate-free key.
In a fourth aspect, a server device is provided, where the device includes: the sending module is used for sending the certification-free key information of the server to the client in the second handshake process based on the transport layer security protocol, wherein the certification-free key information of the server comprises the identification of the first signature public key and the identification of the first encryption public key; the receiving module is used for receiving the client-side certificateless key information sent by the client-side in the third handshake process based on the transport layer security protocol, 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; and the verification module is used for verifying the certificate-free key information of the client based on the identification of the client.
As a possible implementation manner, the receiving module is further configured to receive, in a third handshake process based on the transport layer security protocol, a client key exchange packet sent by the client, where the client key exchange packet includes a random number encrypted by the second encrypted public key; the device further comprises: the generation module is used for generating a second encryption public key according to the identification of the second encryption public key; and the decryption module is used for decrypting the random number encrypted by the second encryption public key by using the second encryption public key.
As a possible implementation manner, the receiving module is further configured to receive, in a first handshake process based on the transport layer security protocol, a handshake request packet sent by the client, where the handshake request packet is used to indicate an authentication manner using a certificate-free key.
In a fifth aspect, a client device is provided, the device comprising a processor, the processor implementing the communication method based on the transport layer security protocol according to the first aspect when executing a computer program.
In a sixth aspect, a server device is provided, where the device includes a processor, and the processor executes a computer program to implement a communication method based on a transport layer security protocol according to the second aspect.
In a seventh aspect, there is provided a computer readable storage medium comprising computer instructions; wherein the computer instructions, when executed, implement a communication method based on a transport layer security protocol as in the first or second aspect.
In this application, the beneficial effects described in the third aspect to the seventh aspect may refer to the beneficial effect analysis of the first aspect or the second aspect, which is not described herein.
Drawings
Fig. 1 is a communication flow chart based on a conventional transport layer security protocol according to an embodiment of the present application;
fig. 2 is a schematic structural diagram of a communication system according to an embodiment of the present application;
fig. 3 is a flow chart of a communication method based on a transport layer security protocol according to an embodiment of the present application;
fig. 4 is a flow chart of another communication method based on a transport layer security protocol according to an embodiment of the present application;
fig. 5 is a complete flow diagram of a communication method based on a transport layer security protocol according to an embodiment of the present application;
fig. 6 is an interaction flow chart of a communication method based on a transport layer security protocol according to an embodiment of the present application;
FIG. 7 is an interactive flow chart of another communication method based on a transport layer security protocol according to an embodiment of the present application;
FIG. 8 is an interactive flow chart of another communication method based on a transport layer security protocol according to an embodiment of the present application;
FIG. 9 is an interactive flow chart of another communication method based on a transport layer security protocol according to an embodiment of the present application;
fig. 10 is a schematic structural diagram of a client device according to an embodiment of the present application;
fig. 11 is a schematic structural diagram of a server device according to an embodiment of the present application;
Fig. 12 is a schematic structural diagram of a communication device according to an embodiment of the present application.
Detailed Description
The technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the described embodiments are only some embodiments of the present application, but not all embodiments, and all other embodiments obtained by those skilled in the art without making creative efforts based on the embodiments in the present application are all within the scope of protection of the present application.
In the description of the present application, "/" means "or" unless otherwise indicated, for example, a/B may mean a or B. "and/or" herein is merely an association relationship describing an association object, and means that three relationships may exist, for example, a and/or B may mean: a exists alone, A and B exist together, and B exists alone. Furthermore, "at least one" means one or more, and "a plurality" means two or more. The terms "first," "second," and the like do not limit the number and order of execution, and the terms "first," "second," and the like do not necessarily differ. In this application, the terms "exemplary" or "such as" are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "for example" should not 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 fashion. In embodiments of the present application, "indication" may include both direct indication and indirect indication. For example, taking the first control information hereinafter as an example, the first control information may directly carry the information a itself or an index thereof, so as to achieve the purpose of directly indicating the information a. Alternatively, the first control information may also carry information B having an association relationship with information a, so as to achieve the purpose of indirectly indicating information a while indicating information B.
As described in the background, most of the current transport layer security protocol TLS-based communications employ conventional public key infrastructure PKI/trusted certificate authority CA certificate constitution. PKI/CA based on digital certificates is a constitution of public key cryptography widely used at present, and a public key certificate is issued by CA for each user. The public key certificate includes the identity information of the user, the public key of the user, and the signature of the CA. In PKI/CA processes, the format of certificates typically takes the form of X.509, which is a certificate typically having a data length of 1K-2K.
Wherein, as shown in fig. 1, TLS requires a four-way handshake procedure to establish a secure connection.
The first handshake procedure includes:
s1, a client sends a handshake request message Cl client Hello message to a server; correspondingly, the server receives the client Hello message sent by the client. The client Hello message comprises a TLS protocol version supported by the client, a random number generated by the client, a session ID, an encryption suite supported by the client, a compression algorithm list supported by the client and expansion content.
The second handshake procedure includes:
s2, the Server analyzes the Cl client Hello message sent by the client and sends a handshake response message Server Hello message to the client; correspondingly, the client receives a Server Hello message sent by the Server. The Server hello message comprises a TLS version selected by the Server, a random number generated by the Server, a session ID, an encryption suite selected by the Server, a compression algorithm selected by the Server and an expansion content.
S3, the server side sends a certificate message to the client side; correspondingly, the client receives a key information message, namely a certificate message, sent by the server. The certificate comprises a certificate of a server, wherein the certificate is in an X.509 standard format, and the certificate content comprises a public key of the server, a domain name of the server, information of an issuer and validity period information.
S4, the server sends a server random number message Server Key Exchange to the client; accordingly, 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.
S5, the server side sends a key request message Cer t if icate Reques t message to the client side; accordingly, the client receives the Cert if icate Reques t message sent by the server. The Cert i f icate Reques t message is used for requesting the client to send the certificate of the client.
S6, the server sends a key completion message Server He l lo Done message to the client; accordingly, the client receives the Server Hel lo Done message sent by the server. The Server He l lo Done message indicates that the server has sent all the related contents exchanged with the key.
The third handshake procedure includes:
s7, the client sends a key information message (Certification) to the server; correspondingly, the server receives the certificate message sent by the client. The certificate message includes a certificate of the client.
S8, the client sends a client random number message Cl ient Key Exchange message to the server; accordingly, the server receives the Cl ient Key Exchange message sent by the client. The C l ient Key Exchange message includes a random number sent by the server.
S9, the client sends a digital signature message Cert if icate Ver i fy message to the server; accordingly, the server receives the Cer t if icate Ver ify message sent by the client. The Cert i f icate Ver ify message includes digital signatures of all handshake messages in the three-way handshake process.
S10, the client sends an encryption indication message Change C ipher Spec message to the server; accordingly, the server receives the Change C ipher Spec message sent by the client. The Change Cipher Spec message is used for indicating that the client starts to perform encrypted transmission from the next handshake information.
S11, the client sends a handshake abstract message finish message to the server; correspondingly, the server receives the finish message sent by the client. The finish message includes digital summaries of all handshake information.
The fourth handshake includes:
s12, the server sends an encryption indication message Change C ipher Spec message to the client; accordingly, the client receives the Change C ipher Spec message sent by the server. The Change Cipher Spec message is used for indicating that the server starts to perform encrypted transmission from the next handshake information.
S13, the server sends a handshake abstract message finish message to the client; correspondingly, the client receives the finish message sent by the server. The finish message includes digital summaries of all handshake information.
In the above-described handshake procedure, TLS communication implements identity authentication and communication encryption, but uses conventional authentication and certificate structures in establishing a secure connection. For low-power-consumption internet of things equipment, data acquisition and certificate transmission occupy a large amount of bandwidth resources. In the case of a fixed server bandwidth, the number of device accesses will be limited by the certificate size. Authentication using PKI/CA certificates in TSL-based communications mainly involves two drawbacks: (1) The CA frame number is too many in bytes, and the certificate occupies a large amount of network bandwidth and storage resources in the transmission and storage processes, so that the certificate is not suitable for the Internet of things equipment with limited storage space and network bandwidth. (2) The CA certificate is complex to manage, and a large amount of time resources and bandwidth resources are consumed in the processes of issuing, storing, withdrawing and the like of the mass internet of things equipment certificates. How to consider the portability in the communication process under the condition of the ensured communication safety, so that the occupation of extra bandwidth resources caused by the processes of transmitting certificates and the like in the communication process is reduced, and the problem to be solved is urgent.
Based on this, the embodiment of the application provides a communication method based on a transport layer security protocol, which is characterized in that: in the process of establishing communication connection based on the transport layer security protocol, the certificate-free key information is used for replacing the traditional CA certificate, so that the weight reduction of communication based on the transport layer security protocol is realized, and the security in the TLS communication process is ensured.
Fig. 2 is a schematic structural diagram of a communication system according to an embodiment of the present application. The communication system may include a certificateless password management platform, a client, and a server, which may be communicatively coupled to one or more clients. It should be noted that fig. 2 is merely a schematic diagram illustrating the result of a communication system to which the embodiments of the present application may be applied to help those skilled in the art understand the technical content of the present disclosure, but does not mean that the embodiments of the present application may not be used in other devices, systems, environments, or scenarios.
And the certificateless password management platform is used for generating certificateless key information for the client/server by receiving the unique identification information and the public key of the client/server in the initialization process, so that the certificateless key information of the client/server can be managed, stored, revoked and the like.
The client may have installed thereon various application programs supporting multiple types of transport protocols, such as a web browser application, a search class application, a shopping class application, an instant messaging tool, a mailbox client and/or social platform software, etc. (by way of example only). The client may be a variety of electronic devices having a display screen and supporting web browsing, including but not limited to smartphones, tablets, laptop and desktop computers, and the like.
The server may be a server providing various services, such as a background management server providing support for a website browsed by a user using a client. The background management server may analyze and process the received data such as the user request, and feed back the processing result (e.g., the web page, information, or data obtained or generated according to the user request) to the client.
As shown in fig. 3, an embodiment of the present application provides a communication method based on a transport layer security protocol, applied to a client, the method includes the following steps:
s301, in a second handshake process based on a transport layer security protocol, certificate-free key information of a server sent by the server is received.
The certificate-free key information of the server side comprises identification of a first signature public key and identification of a first encryption public key.
S302, verifying certificate-free key information of a server based on an identifier of the server in a third handshake process based on a transport layer security protocol; and after passing the verification, sending the certificate-free key information of the client to the server.
In some embodiments, the TLS encryption suite of the certificateless cryptographic identification used by the client and server during transport layer security protocol based communication integrates basic cryptographic operations.
Wherein the basic cryptographic operation function includes at least one of the following functions: verification of non-certificate key information, digest verification of handshake information, or encryption of handshake information. Verification of the key information without the certificate is based on a national secret SM2 algorithm; digest verification of handshake information is based on the national secret SM3 algorithm; the encryption of the handshake information is based on the national cipher SM4 algorithm.
Illustratively, the handshake information may include at least one of: handshake request message, handshake response message, key completion message, key exchange message, encryption indication message or handshake abstract message. The content contained in the above message is specifically described below.
In some embodiments, in the verification process of the client to the certificate-free key information of the server, the certificate-free key information of the server is operated by using a national secret SM2 algorithm to obtain the identifier of the server. If the service end identification obtained by operation is consistent with the identification of the service end in the handshake process, the verification is successful, and the client end continues to establish the secure connection with the service end.
Illustratively, 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 certificate-free key information sent by the server. The client verifies the certificate-free key information of the server through a basic password running function in the suite with the certificate-free password identification, the certificate-free key information of the server is operated by using a national secret SM2 algorithm, the identification of the operated server is 010101, the identification of the operated server is consistent with the identification of the server in the handshake process, namely, the verification is successful, and the client and the server continue to establish the secure connection.
In yet another exemplary embodiment, 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 certificate-free key information sent by the server. The client verifies the certificate-free key information of the server through a basic password running function in the suite with the certificate-free password identification, the SM2 cryptographic algorithm is used for operating the certificate-free key information of the server, the identification of the server obtained through operation is 101010, the identification of the server is inconsistent with the identification of the server in the handshake process, namely the verification fails, and the client interrupts the connection with the server.
In some embodiments, the client generates the first public signature key from a first public signature key identification in the certificate-less key information of the server. The first public signature key is used to verify messages signed by the certificate-less private key.
In some embodiments, the client generates the first encrypted public key from an identification of the first encrypted public key in the certificate-less key information of the server. The first encryption public key is used for decrypting the message encrypted by the first encryption public key.
The technical scheme provided by the embodiment of the application at least brings the following beneficial effects: in the communication process based on the transport layer security protocol, the client receives and verifies the certification-free key information of the server, and after the verification is passed, the certification-free key information of the client is sent to the server. In the process, the non-certificate key information is used for replacing the traditional certificate, so that the transmission burden in the handshake flow based on the transmission layer security protocol is reduced, and the communication light weight is improved.
As shown in fig. 4, another communication method based on a transport layer security protocol is provided in the embodiments of the present application, and is applied to a server, where the method includes the following steps:
s401, in a second handshake process based on a transport layer security protocol, certificate-free key information of a server side is sent to a client side.
The certificate-free key information of the server side comprises identification of a first signature public key and identification of a first encryption public key.
In some embodiments, the server generates the first public signature key from an identification of the first public signature key in the certificate-less key information of the server. The first signature public key is used for verifying the message signed by the certificate-free private key of the server.
In some embodiments, the server generates the first encrypted public key from an identification of the first encrypted public key in the certificate-less key information of the server. The first encryption public key is used for encrypting the handshake information sent by the server in the handshake process based on the transport layer security protocol.
S402, in a third handshake process based on the transport layer security protocol, the certificate-free key information of the client sent by the client is received.
Wherein the client's certificate-less key information includes an identification of the second signed public key and an identification of the second encrypted public key.
In some embodiments, the server may generate the second public signature key from the second public signature key identification in the client's certificate-less key information. The second public signature key is used to verify the message signed by the client's certificate-less private key.
In some embodiments, the server may generate the second encrypted public key from an identification of the second encrypted public key in the client's certificate-less key information. The second encryption public key is used for decrypting the message encrypted by the second encryption public key.
S403, based on the identification of the client, verifying the certificate-free key information of the client.
In some embodiments, in the verification process of the server side on the client side certificateless key information, the certificateless key information of the client side is operated by using a national secret SM2 algorithm to obtain the identifier of the client side. If the client identifier obtained by the operation is consistent with the client identifier in the handshake process, the verification is successful, and the server continues to establish the secure connection with the client.
Illustratively, in the third handshake process based on the transport layer security protocol, the identifier of the client is 111000, and the server receives and verifies the certificate-free key information sent by the client. The server verifies the certification-free key information of the client through a basic password running function in the suite with the certification-free password identification, the certification-free key information of the client is operated by using a national password SM2 algorithm, the identification of the operated client is 010101, the identification of the operated client is consistent with the identification of the client in the handshake process, namely, the verification is successful, and the server and the client continue to establish safe connection.
Still another exemplary, in a third handshake process based on the transport layer security protocol, the client has an identifier of 111000, and the server receives and verifies the certificate-free key information sent by the client. The server verifies the certification-free key information of the client through a basic password running function in the suite with the certification-free password identification, the national password SM2 algorithm is used for operating the certification-free key information of the client, the identification of the server obtained through operation is 000111, the identification of the server is inconsistent with the identification of the client in the handshake process, namely the verification fails, and the server is disconnected with the client.
The technical scheme provided by the embodiment of the application at least brings the following beneficial effects: it can be seen that in the communication process based on the transport layer security protocol, the server side sends the non-certificate key information of the server side to the client side, receives the non-certificate key information of the client side sent by the client side and verifies the non-certificate key information; in the communication process, the certificate-free key information is used to replace a certificate in the traditional process, so that the bandwidth burden in the communication process is reduced, the light weight in the communication process is improved, and the safety in the communication process is ensured.
As shown in fig. 5, an embodiment of the present application provides a complete communication method based on a transport layer security protocol, which includes the following steps:
s501, initializing.
As shown in fig. 6, step S1 may be embodied as the following steps:
s5101, the server side calls an expansion interface in the certificate-free password management platform to generate a public key and a private key of the server side.
The extension interface in the certificateless password management platform is used for providing a key generation function of the server side and a certificateless key envelope analysis function of the server side.
S5102, the server sends the identification and the public key of the server to the certificateless password management platform, so that the certificateless password management platform generates certificateless key information of the server according to the identification and the public key of the server.
The exemplary, non-certificate password management platform invokes the expansion interface to generate non-certificate key information of the server according to the identifier of the server and the public key of the server in combination with the basic password operation function in the TLS encryption suite.
The certificate-free key information of the server side comprises identification of a first signature public key and identification of a first encryption public key.
In some embodiments, the certificateless password management platform further generates a certificateless key envelope for the server according to the identity of the server and the public key. The certificate-free key envelope of the server comprises a first signature public key envelope and a first encryption public key envelope.
S5103, the server acquires the certificate-free key information of the server generated by the certificate-free password management platform.
S5104, the server side calls an expansion interface in the certificateless password management platform to generate a certificateless private key of the server side.
The certificateless password management platform stores certificateless key information of a server, analyzes a certificateless key envelope of the server, and generates a certificateless private key of the server.
The certificate-free private key of the server is used for signing the handshake information in the handshake process based on the transport layer security protocol, and is used for proving that the certificate-free private key information received by the client from the server corresponds to the server.
S5105, the client calls an expansion interface in the certificateless password management platform to generate a public key and a private key of the client.
S5106, the client sends the identification and the public key of the client to the certificateless password management platform, so that the certificateless password management platform generates certificateless key information of the client according to the identification and the public key of the client.
The exemplary, non-certificate password management platform invokes the expansion interface to generate non-certificate key information of the server according to the identifier of the server and the public key of the server in combination with the basic password operation function in the TLS encryption suite.
Wherein the client's certificate-less key information includes an identification of the second signed public key and an identification of the second encrypted public key.
In some embodiments, the certificateless password management platform also generates a certificateless key envelope for the client from the client's identity and public key. Wherein the client's certificate-less key envelope includes a second signed public key envelope and a second encrypted public key envelope.
S5107, the client obtains the client' S certificateless key information generated by the certificateless key management platform.
S5108, the client calls an expansion interface in the certificateless password management platform to generate a certificateless private key of the client.
Illustratively, the certificateless password management platform stores certificateless key information of the client, and parses a certificateless key envelope of the client to generate a certificateless private key of the client.
The client-side certificateless private key is used for signing handshake information in a handshake process based on a transport layer security protocol and is used for proving that the certificateless key information received by the server-side from the client-side corresponds to the client-side.
S502, a first handshake flow.
The client sends a handshake request message to the server; accordingly, the server receives the handshake request message from the client.
The handshake request message is used for indicating that the server adopts a certification mode without a certification key in a communication process based on a transmission layer security protocol.
The handshake request message is equivalent to a Cl client hello message in the conventional TLS communication process. The handshake request message may include at least one of: the method comprises the steps of a TLS protocol version of client-supported non-certificate identification password authentication, a random number generated by a client, a TLS encryption suite of client-supported non-certificate password identification, a compression algorithm list supported by the client or extension content filled by the client.
The TLS encryption suite without the certificate password identification is used for public key generation, non-certificate envelope unpacking analysis and non-certificate key information synthesis of the client.
Illustratively, the handshake request message includes a client-supported TLS protocol version, e.g., 1.0, 1.1, 1.2, with no certificate identification password authentication; a client-generated random number, e.g., 10; client-supported TLS encryption suites without certificate password identification, such as ecdh_rsa, ecdh_ecdsa; a list of compression algorithms supported by the client, e.g., deflate, GZIP, LZO; the client-side-filled extension content is an SNI extension.
S503, a second handshake flow.
As shown in fig. 7, step S3 may be embodied as the following steps:
s5201, the server analyzes the handshake request message sent by the client.
The handshake request message may be a client hel lo message.
In some embodiments, the server determines optional parameter information during connection establishment by parsing a handshake request message sent by the client.
S5202, the server sends a handshake response message to the client; accordingly, the client receives the handshake response message from the server.
The handshake response message is a Server Hello message.
The Server hello message may include at least one of: the method comprises the steps of a TLS protocol version of certificate-free password authentication selected by a server, a random number selected by the server, a TLS encryption suite of certificate-free password identification selected by the server, a compression algorithm selected by the server or expansion content filled by the server.
Illustratively, following the example in S2, the server selects the highest version 1.2 of the protocol versions supported by the client as the TLS protocol version in the current communication process; a TLS encryption suite supported by a client and without a certificate password identifier is randomly selected, for example ECDH_RSA is used as the TLS encryption suite in the communication process; one of the compression algorithm lists supported by the client is randomly selected, for example GZIP, as the compression algorithm list in the present communication process.
S5203, the server sends the certificate-free key information of the server to the client; accordingly, the client receives the certificate-free key information from the server.
The certificate-free key information of the server side comprises identification of a first signature public key and identification of a first encryption public key.
In this embodiment of the present application, the format of the certificate-free key information of the server may be x.509, and the format of the certificate-free key information of the server may be set according to the requirements in the actual application process, which is not limited in this embodiment of the present application.
S5204, the server sends a key information request message to the client; correspondingly, the client receives the key information request message from the server.
The key information request message is used for requesting the client to send the certificate-free key information of the client to the server. The key information request message may be a Cert ificate Reques t message, for example.
S5205, the server sends a key completion message to the client; correspondingly, the client receives the key completion message from the server.
The key completion message is used for indicating that the certificate-free key information of the server is sent completely. Illustratively, the key done message may be a Server He l lo Done message.
S504, a third handshake flow.
As shown in fig. 8, step S4 may be embodied as the following steps:
s5301, the client verifies the certificate-free key information sent by the server.
S5302, the client sends the certificate-free key information of the client to the server; accordingly, the server receives the certificate-less key information from the client.
In some embodiments, after the client sends the client's non-certificate key information to the server, the client digitally signs the handshake information sent later by using the client's non-certificate signing private key, to indicate that the non-certificate key information sent by the client to the server corresponds to the non-certificate signing private key owned by the client.
S5303, the client sends a key exchange message to the server; accordingly, the server receives the key exchange message from the client.
The key exchange message is equivalent to a C l ient Key Exchange message in the conventional TLS communication process. The key exchange message includes a random number encrypted by the client using a second encryption public key in the client's certificate-less key information.
Illustratively, the client generates a second encrypted public key using an identification of the second encrypted public key in the client's certificate-less key information, and encrypts the random number in the key exchange message using the second encrypted public key.
In some embodiments, during a third handshake process based on the transport layer security protocol, the server receives a key exchange message sent by the client; generating a second encryption public key according to the identification of the second encryption 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 encryption indication message to the server; correspondingly, the server receives the encryption indication message from the client.
The encryption indication message Change Ci pher Spec is used for informing the server that the next piece of handshake information starts encryption transmission. Illustratively, the encryption indication message may be a Change C ipher Spec message.
S5305, the client sends a handshake abstract message to the server, and correspondingly, the server receives the handshake abstract message from the client.
The handshake abstract message comprises abstracts of all handshake information in the handshake process. The handshake digest message may be, for example, a finish-shared message.
In some embodiments, the client uses a cryptographic SM3 digest algorithm to digest the handshake information, integrates the handshake information into an F ini shared message, generates a second encryption key according to the second encryption key identifier, and uses the second encryption public key to encrypt and send the second encryption key to the server.
S505, a fourth handshake process.
As shown in fig. 9, step S5 may be embodied as the following steps:
s5401, the server verifies the certificate-free key information sent by the client.
S5402, the server verifies the digital signature of the client.
And the server generates a second signature public key according to the identification of the second signature public key in the certificate-free key information of the client, and authenticates the digital signature of the client by using the second signature public key.
S5403, the server sends an encryption indication message to the client; correspondingly, the client receives the encryption indication message from the server.
The encryption indication message is used for informing the client that the next piece of handshake information starts encryption transmission. Illustratively, the encryption indication message may be a Change Cipher Spec message.
S5404, the server sends a handshake abstract message to the client; accordingly, the client receives the handshake abstract message from the server.
The handshake abstract message comprises abstracts of all handshake information in the handshake process. The handshake digest message may be, for example, a finish-shared message.
In some embodiments, the server uses the national secret SM3 digest algorithm to digest the handshake information, and integrates the handshake information into a handshake digest message, and sends the handshake digest message to the client. The foregoing description of the solution provided in the embodiments of the present application has been mainly presented in terms of a method. To achieve the above functions, it includes corresponding hardware structures and/or software modules that perform the respective functions. Those of skill in the art will readily appreciate that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be implemented as hardware or combinations of hardware and computer software. Whether a function is implemented as hardware or computer software driven hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
The embodiment of the present application may divide the functional modules of the communication device 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 integrated modules may be implemented in hardware or in software functional modules. Optionally, the division of the modules in the embodiments of the present application is schematic, which is merely a logic function division, and other division manners may be actually implemented.
Fig. 10 shows a schematic structural diagram of a client device according to an embodiment of the present application. As shown in fig. 10, the client device 60 includes a receiving module 601, a verifying module 602, and a transmitting module 603.
The receiving module 601 is configured to receive, in a second handshake process based on a transport layer security protocol, certificateless key information of a server sent by a server, where the certificateless key information of the server includes an identifier of a first signed public key and an identifier of a first encrypted public key.
The verification module 602 is configured to verify, based on the identifier of the server, the certificate-free key information of the server in a third handshake process based on the transport layer security protocol.
And the sending module 603 is configured to send, after the verification is passed, the client-side non-certificate key information to the server side, where the client-side non-certificate key information includes an identifier of the second signed public key and an identifier of the second encrypted public key.
In some embodiments, the sending module 603 is further configured to send, to the server, a key exchange packet during a third handshake process based on the transport layer security protocol, where the key exchange packet includes a random number encrypted by the second encrypted public key.
In some embodiments, the sending module 603 is further configured to send, during a first handshake process based on the transport layer security protocol, a handshake request packet to the server, where the handshake request packet is used to indicate an authentication manner using a certificateless key.
Fig. 11 shows a schematic structural diagram of a server device according to an embodiment of the present application. As shown in fig. 11, the server device 70 includes a transmitting module 701, a receiving module 702, a verifying module 703, a generating module 704, and a decrypting module 705.
The sending module 701 is configured to send, to the client, the server's certificate-free key information in a second handshake process based on the transport layer security protocol, where the server's certificate-free key information includes an identifier of the first signed public key and an identifier of the first encrypted public key.
The receiving module 702 is configured to receive, in a third handshake process based on a transport layer security protocol, the client's certificate-free key information sent by a client, where the client's certificate-free key information includes an identifier of a second signed public key and an identifier of a second encrypted public key.
And the verification module 703 is configured to verify the client's certificate-free key information based on the identifier of the client.
In some embodiments, the receiving module 702 is further configured to receive, in a third handshake process based on the transport layer security protocol, a client key exchange packet sent by the client, where the client key exchange packet includes a random number encrypted by the second encrypted public key; the device further comprises: a generating module 704, configured to generate a second encrypted public key according to the identifier of the second encrypted public key; the decryption module 705 is configured to decrypt the random number encrypted by the second encryption public key with the second encryption public key.
In some embodiments, the receiving module 702 is further configured to receive, during a first handshake process based on the transport layer security protocol, a handshake request packet sent by the client, where the handshake request packet is used to indicate an authentication manner using a certificateless key.
In the case where the functions of the integrated modules are implemented in the form of hardware, the results of the client device and the server device provided in the embodiments 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.
A communication interface 803 for connecting with other devices through a communication network. The communication network may be an ethernet, a radio access network, a wireless local area network (wi reles s local area networks, WLAN), etc.
The memory 801 may be, but is not limited to, a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (random access memory, RAM) or other type of dynamic storage device that can store information and instructions, or an electrically erasable programmable read-only memory (electr ica l ly erasable programmable read-only memory, EEPROM), magnetic disk storage or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer.
As a possible implementation, the memory 801 may exist separately from the processor 802, and the memory 801 may be connected to the processor 802 through the bus 804 for storing instructions or program code. The processor 802, when calling and executing instructions or program code stored in the memory 801, is capable of implementing the communication method based on the transport layer security protocol provided in the embodiments of the present application.
In another possible implementation, the memory 801 may also be integrated with the processor 802.
Bus 804 may be an extended industry standard architecture (extended indus try s tandard archi tecture, EISA) bus or the like. The bus 804 may be classified as an address bus, a data bus, a control bus, or the like. For ease of illustration, only one thick line is shown in fig. 12, but not only one bus or one type of bus.
The present application also provides a computer-readable storage medium including computer-executable instructions that, when executed on a computer, cause the computer to perform a method as provided in the above embodiments.
The present application also provides a computer program product directly loadable into a memory and including software code, which, when loaded and executed via a computer, is able to carry out the method provided by the above embodiments.
Those of skill in the art will appreciate that in one or more of the examples described above, the functions described herein may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, these 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 foregoing is merely a specific embodiment of the present application, but the protection scope of the present application is not limited thereto, and any changes or substitutions within the technical scope of the present disclosure should be covered in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (15)

1. A communication method based on a transport layer security protocol, applied to a client, the method comprising:
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 the server based on the identifier of the server; and after the verification is passed, sending the certification-free key information of the client to the server, wherein the certification-free key information of the client comprises the identification of the second signature public key and the identification of the second encryption public key.
2. The method according to claim 1, wherein the method further comprises:
and in the third handshake process based on the transport layer security protocol, sending a key exchange message to the server, wherein the key exchange message comprises a random number encrypted by a second encryption public key.
3. The method according to claim 2, wherein the method further comprises:
in a first handshake process based on a transport layer security protocol, sending a handshake request message to the server, wherein the handshake request message is used for indicating an authentication mode adopting a certificateless key.
4. A communication method based on a transport layer security protocol, applied to a server, the method comprising:
in a second handshake process based on a transport layer security protocol, sending certificate-free key information of a server to a client, 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, receiving the client-side certificateless key information sent by the client-side, wherein the client-side certificateless key information comprises an identifier of a second signature public key and an identifier of a second encryption public key;
and verifying the certificate-free key information of the client based on the identification of the client.
5. The method according to claim 4, wherein the method further comprises:
in a third handshake process based on a transport layer security protocol, receiving a client key exchange message sent by the client, wherein the client key exchange message comprises a random number encrypted by a second encryption public key;
generating the second encryption public key according to the identification of the second encryption public key;
decrypting the random number encrypted by the second encryption public key with the second encryption public key.
6. The method of claim 5, wherein the method further comprises:
and in the first handshake process based on the transport layer security protocol, receiving a handshake request message sent by the client, wherein the handshake request message is used for indicating an authentication mode adopting a certificateless key.
7. A client device, the device comprising:
the device comprises a receiving module, a transmitting module and a receiving module, wherein the receiving module is used for receiving the certificate-free key information of a server, which is sent by the server, in a second handshake process based on a transmission layer security protocol, and 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;
the verification module is used for verifying the certificate-free key information of the server based on the identification of the server in a third handshake process based on a transport layer security protocol;
and the sending module is used for sending the certification-free key information of the client to the server after the verification is passed, wherein the certification-free key information of the client comprises the identification of the second signature public key and the identification of the second encryption public key.
8. The apparatus of claim 7, wherein the sending module is further configured to send a key exchange message to the server during a third handshake based on a transport layer security protocol, the key exchange message including a random number encrypted by a second encrypted public key.
9. The apparatus of claim 8, wherein the sending module is further configured to send a handshake request message to the server during a first handshake process based on a transport layer security protocol, the handshake request message being configured to indicate an authentication mode using a certificateless key.
10. A server device, the device comprising:
the device comprises a sending module, a client and a server, wherein the sending module is used for sending the certificateless key information of the server to the client in a second handshake process based on a transport layer security protocol, and the certificateless key information of the server comprises an identifier of a first signature public key and an identifier of a first encryption public key;
the receiving module is used for receiving the client-side certificateless key information sent by the client-side in a third handshake process based on a transport layer security protocol, wherein the client-side certificateless key information comprises an identifier of a second signature public key and an identifier of a second encryption public key;
and the verification module is used for verifying the certificate-free key information of the client based on the identification of the client.
11. The apparatus of claim 10, wherein the receiving module is further configured to receive a client key exchange message sent by the client during a third handshake based on a transport layer security protocol, the client key exchange message including a random number encrypted by a second encrypted public key; the apparatus further comprises:
the generation module is used for generating the second encryption public key according to the identification of the second encryption public key;
And the decryption module is used for decrypting the random number encrypted by the second encryption public key by using the second encryption public key.
12. The apparatus of claim 11, wherein the receiving module is further configured to receive a handshake request message sent by the client during a first handshake process based on a transport layer security protocol, the handshake request message being configured to indicate an authentication mode using a certificateless key.
13. A client device, characterized in that the device comprises a processor, which when executing a computer program implements a communication method based on a transport layer security protocol according to any of claims 1 to 3.
14. A server device, characterized in that the device comprises a processor, which when executing a computer program implements the communication method based on the transport layer security protocol according to any of claims 4 to 6.
15. A computer-readable storage medium, the computer-readable storage medium comprising computer instructions; wherein the computer instructions, when executed, implement the transport layer security protocol based communication method of any of claims 1 to 6.
CN202310222447.2A 2023-03-09 2023-03-09 Communication method, device and storage medium based on transport layer security protocol Pending CN116318943A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310222447.2A CN116318943A (en) 2023-03-09 2023-03-09 Communication method, device and storage medium based on transport layer security protocol

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310222447.2A CN116318943A (en) 2023-03-09 2023-03-09 Communication method, device and storage medium based on transport layer security protocol

Publications (1)

Publication Number Publication Date
CN116318943A true CN116318943A (en) 2023-06-23

Family

ID=86782885

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310222447.2A Pending CN116318943A (en) 2023-03-09 2023-03-09 Communication method, device and storage medium based on transport layer security protocol

Country Status (1)

Country Link
CN (1) CN116318943A (en)

Similar Documents

Publication Publication Date Title
EP4216081A1 (en) Information verification method, related apparatus, device, and storage medium
CN110535628B (en) Method and device for performing multi-party security calculation through certificate signing and issuing
CN109088889B (en) SSL encryption and decryption method, system and computer readable storage medium
CN110677240B (en) Method, apparatus and medium for providing highly available computing services through certificate issuance
US20160269176A1 (en) Key Configuration Method, System, and Apparatus
US11303431B2 (en) Method and system for performing SSL handshake
US20150156025A1 (en) Message sending and receiving method, apparatus, and system
US20140337619A1 (en) Derived Certificate based on Changing Identity
CN106788989B (en) Method and equipment for establishing secure encrypted channel
US11323433B2 (en) Digital credential management method and device
CN113438071A (en) Method and device for secure communication
EP4258593A1 (en) Ota update method and apparatus
CN113992346B (en) Implementation method of security cloud desktop based on national security reinforcement
CN108809907B (en) Certificate request message sending method, receiving method and device
CA3120090A1 (en) Systems, methods, and apparatuses for network management
WO2022100356A1 (en) Identity authentication system, method and apparatus, device, and computer readable storage medium
CN114338844B (en) Cross-protocol communication method and device between client servers
CN110839240B (en) Method and device for establishing connection
CN112398826A (en) Data processing method and device based on state password, storage medium and electronic equipment
CN115021932A (en) Authentication method for handshake process of TLCP protocol
CN109995723B (en) Method, device and system for DNS information interaction of domain name resolution system
CN110213346B (en) Encrypted information transmission method and device
EP3220604A1 (en) Methods for client certificate delegation and devices thereof
CN114650181B (en) E-mail encryption and decryption method, system, equipment and computer readable storage medium
CN116318943A (en) Communication method, device and storage medium based on transport layer security protocol

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination