Data transmission method, apparatus, storage medium and device

Abstract

Disclosed in the embodiments of the present application are a data transmission method, an apparatus, a storage medium and a device, which can be applied to various scenarios such as cloud technology, artificial intelligence, smart traffic and aided driving. The method comprises: by means of a dedicated transport layer security protocol between an applet and a server, sending a handshake request to the server; by means of the dedicated transport layer security protocol, receiving a dynamic key returned, on the basis of the handshake request, by the server and an encrypted string obtained on the basis of the dynamic key; acquiring data to be transmitted, and using the dynamic key to encrypt the data, so as to obtain a ciphertext; and, by means of a universal transport layer security protocol, sending the ciphertext and the encrypted string to the server, so that the server obtains the dynamic key on the basis of decrypting the encrypted string, and decrypts the ciphertext on the basis of the dynamic key to obtain decrypted data.

Description

Data transmission method, device, storage medium and equipment

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on October 17, 2023, with application number 202311348871.8, and invention name “A data transmission method, device, storage medium and equipment”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of communication technology, and in particular to a data transmission method, apparatus, storage medium and device. Background Art

[0003] Hypertext Transfer Protocol Secure (HTTPS) is a transmission protocol for secure communication over computer networks. HTTPS communicates over HTTP but uses the universal Transport Layer Security (TLS) protocol to encrypt data packets. It is a secure HTTP channel, built on HTTP's foundation, ensuring the security of the transmission process through transmission encryption and identity authentication.

[0004] In related technologies, TLS can encrypt data packets using symmetric encryption, that is, the server sends the static key to the client through TLS, so that the client and the server share the same static key. The data transmission party encrypts the plaintext (that is, the original data) and the static key together through a special encryption algorithm, so that the plaintext becomes a complex ciphertext and sends it to the data recipient. After the data recipient receives the ciphertext, it decrypts the ciphertext through the static key and the inverse algorithm of the special encryption algorithm, and restores it to readable plaintext to ensure the security of data transmission.

[0005] Technical content

[0006] The embodiments of the present application provide a data transmission method, apparatus, storage medium, and device, which can improve the security of data transmission.

[0007] The embodiments of this application provide the following technical solutions:

[0008] A data transmission method, executed by a terminal device, comprising:

[0009] Sending a handshake request to the server via a dedicated transport layer security protocol between the applet running in the terminal device and the server, wherein the dedicated transport layer security protocol has higher security than the general transport layer security protocol;

[0010] Receiving the dynamic key returned by the server and the encrypted string obtained according to the dynamic key through the dedicated transport layer security protocol;

[0011] Acquire data to be sent, and encrypt the data using the dynamic key to obtain ciphertext;

[0012] The ciphertext and the encrypted string are sent to a server via the universal transport layer security protocol, so that the server decrypts the encrypted string to obtain the dynamic key, and decrypts the ciphertext according to the dynamic key to obtain decrypted data.

[0013] A data transmission method, executed by a server device, comprising:

[0014] receiving a handshake request sent by the applet through a dedicated transport layer security protocol, where the dedicated transport layer security protocol has higher security than a general transport layer security protocol;

[0015] Generate a random dynamic key according to the handshake request, and obtain an encrypted string according to the dynamic key;

[0016] Returning the dynamic key and the encrypted string to the applet through the dedicated transport layer security protocol, so that the applet encrypts the data to be sent according to the dynamic key to obtain a ciphertext;

[0017] receiving the encrypted ciphertext and the encrypted string sent by the applet via the universal transport layer security protocol;

[0018] The encrypted string is decrypted to obtain the dynamic key, and the ciphertext is decrypted based on the dynamic key to obtain decrypted data.

[0019] A data transmission device, comprising:

[0020] A first sending unit is configured to send a handshake request to the server via a dedicated transport layer security protocol between the applet and the server, wherein the dedicated transport layer security protocol has higher security than the general transport layer security protocol;

[0021] a first receiving unit, configured to receive, through the dedicated transport layer security protocol, a dynamic key returned by the server according to the handshake request and an encrypted string obtained according to the dynamic key;

[0022] an encryption unit, configured to obtain data to be sent and encrypt the data using the dynamic key to obtain a ciphertext;

[0023] The second sending unit is used to send the ciphertext and the encrypted string to the server through the universal transport layer security protocol, so that the server decrypts the encrypted string to obtain the dynamic key, and decrypts the ciphertext according to the dynamic key to obtain decrypted data.

[0024] A data transmission device, comprising:

[0025] A first receiving unit is configured to receive a handshake request sent by the applet via a dedicated transport layer security protocol, where the dedicated transport layer security protocol has higher security than a general transport layer security protocol;

[0026] A generating unit, configured to generate a random dynamic key according to the handshake request, and obtain an encrypted string according to the dynamic key;

[0027] a returning unit, configured to return the dynamic key and the encrypted string to the applet via the dedicated transport layer security protocol, so that the applet encrypts the data to be sent according to the dynamic key to obtain a ciphertext;

[0028] A second receiving unit, configured to receive the ciphertext and the encrypted string sent by the applet via the universal transport layer security protocol;

[0029] The decryption unit is configured to decrypt the encrypted string to obtain the dynamic key, and decrypt the ciphertext based on the dynamic key to obtain decrypted data.

[0030] A computer-readable storage medium stores a plurality of instructions, wherein the instructions are suitable for being loaded by a processor to execute the steps in the above-mentioned data transmission method.

[0031] A computer device comprises a memory, a processor and a computer program stored in the memory and capable of running on the processor, wherein the processor implements the steps in the above-mentioned data transmission method when executing the computer program.

[0032] A computer program product or computer program includes computer instructions stored in a storage medium. A processor of a computer device reads the computer instructions from the storage medium and executes the computer instructions to implement the steps of the above-mentioned data transmission method.

[0033] Other features and advantages of the present disclosure will be described in the following description, and in part will become apparent from the description, or will be understood by practicing the present disclosure. The purposes and other advantages of the present disclosure can be realized and obtained by the structures particularly pointed out in the description, claims and drawings.

[0034] BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0036] FIG1 is a schematic diagram of the protocol structure of the data transmission method provided in some embodiments of the present application.

[0037] FIG2 is a schematic diagram of a scenario of a data transmission system provided in some embodiments of the present application.

[0038] FIG3 is a scenario diagram of a login system provided in some embodiments of the present application.

[0039] FIG4 is a schematic diagram of a scenario of a virtual resource payment system provided in some embodiments of the present application.

[0040] FIG5 is a flow chart of a data transmission method provided in some embodiments of the present application.

[0041] FIG6 is a schematic diagram of a scenario of a data transmission method provided in some embodiments of the present application.

[0042] FIG7 is another specific flow chart of step 203 in FIG5 ;

[0043] FIG8 is a schematic diagram of another scenario of the data transmission method provided in some embodiments of the present application.

[0044] FIG9 is a flow chart of a data transmission method provided in some embodiments of the present application.

[0045] FIG10 is another specific flow chart of step 405 in FIG9 ;

[0046] FIG11 is an interactive schematic diagram of a data transmission method provided in some embodiments of the present application.

[0047] FIG12 is an interactive flow chart of a data transmission method provided in some embodiments of the present application.

[0048] FIG13 is a schematic structural diagram of a data transmission device provided in some embodiments of the present application.

[0049] FIG14 is a schematic structural diagram of a data transmission device provided in some embodiments of the present application.

[0050] FIG15 is a schematic structural diagram of a terminal provided in some embodiments of the present application.

[0051] FIG16 is a schematic diagram of the structure of a server provided in some embodiments of the present application. DETAILED DESCRIPTION

[0052] In order to enable those skilled in the art to better understand the solutions of this application, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without making any creative efforts shall fall within the scope of protection of this application.

[0053] It is understandable that in the specific implementation of this application, when it comes to related data such as data to be encrypted, when the above embodiments of this application are applied to specific products or technologies, it is necessary to obtain the object's permission or consent, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards.

[0054] In addition, when the embodiment of the present application needs to obtain data related to the data to be encrypted, it will obtain a separate license or separate consent for the data related to the data to be encrypted, etc. through a pop-up window or jump to a confirmation page. After clearly obtaining a separate license or separate consent for the data related to the data to be encrypted, etc., it will obtain the necessary data related to the data to be encrypted, etc. for the normal operation of the embodiment of the present application.

[0055] It should be noted that some of the processes described in the specification, claims, and figures above include multiple steps that appear in a specific order. However, it should be clearly understood that these steps may be executed in a different order than the order in which they appear herein or in parallel. The step numbers are merely used to distinguish between different steps and do not themselves represent any order of execution. Furthermore, terms such as "first," "second," or "preset" are used herein to distinguish similar objects and are not necessarily used to describe a specific order or precedence.

[0056] Before further explaining the embodiments of the present disclosure in detail, the nouns and terms involved in the embodiments of the present disclosure are explained. The nouns and terms involved in the embodiments of the present disclosure are subject to the following interpretations:

[0057] The Transmission Control Protocol / Internet Protocol (TCP / IP) is a suite of protocols that enables information transmission across multiple networks. TCP / IP doesn't just refer to TCP and IP; it's a suite of protocols consisting of File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP), TCP, User Datagram Protocol (UDP), and Internet Protocol (IP). It's called TCP / IP simply because TCP and IP are the most representative. Also known as the Network Communication Protocol, it's the most fundamental communication protocol used on the Internet.

[0058] Hypertext Transfer Protocol (HTTP) is an application layer protocol for distributed, collaborative and hypermedia information systems. It is a request-and-response, stateless, application layer protocol that uses the TCP / IP protocol to transmit data. HTTP allows the transmission of any type of data object.

[0059] Mini Program: An application that can be used within an instant messaging client without downloading or installing.

[0060] Symmetric encryption refers to the process of encrypting and decrypting data using the same key.

[0061] Uniform Resource Locator (URL) is a method of indicating the location of information on the World Wide Web service program of the Internet, which can be understood as an access URL.

[0062] The universal Transport Layer Security protocol (TLS) is used to provide confidentiality and data integrity between two communicating applications.

[0063] Managed Mode Transport Layer Security (MMTLS) is a transport layer security protocol based on TLS, using TLS for encryption and authentication at the transport layer. Unlike traditional TLS, MMTLS adopts a managed model, transferring some control of the TLS protocol to the application layer. TLS, implemented in instant messaging clients, provides confidentiality and data integrity between the client and the server.

[0064] It's important to note that MMTLS doesn't trust self-signed certificates, only the certificates carried by the instant messaging client. Furthermore, the MMTLS protocol is highly customized, making it difficult to analyze with existing packet capture tools. Because MMTLS is customized, existing packet capture tools can't capture the specific contents of MMTLS. Therefore, subsequent dynamic key transmission via MMTLS is secure.

[0065] To better understand MMTLS, please refer to Figure 1, which is a schematic diagram of the protocol structure of the data transmission method provided in an embodiment of the present application. The TCP / IP adopts a layered design mode, dividing the protocol into four layers from top to bottom, namely:

[0066] Application Layer A: The Application Layer A is the highest-level protocol in the TCP / IP protocol suite. It provides communication services between object interfaces and application programs. HTTP, FTP, SMTP, and other protocols are examples of this layer. Application layer protocols interact directly with objects, processing specific types of data and handing it off to the next layer for processing.

[0067] Transport Layer B: Transport Layer B provides end-to-end data transmission services, such as TCP and UDP protocols. Transport layer protocols are responsible for passing data from the application layer to the network layer and ensuring data transmission reliability, flow control, error detection, and other functions.

[0068] Network Layer (C): Network Layer (C) primarily provides services for transmitting data packets across the network, such as the IP protocol. Network layer protocols are responsible for delivering data packets from the source host to the destination host, using technologies such as routing and forwarding to enable data transmission between different networks.

[0069] Link Layer (D): Link Layer (D) refers to data transmission at the physical layer, such as Ethernet, Wi-Fi, and other protocols. The link layer protocol is responsible for passing data from the network layer to the physical layer and then transmitting it to the receiving host through the physical layer.

[0070] The physical layer (unlabeled) is responsible for the transmission of bit streams between nodes, that is, for physical transmission. The protocols at this layer are related to both the link and the transmission medium. In layman's terms, it is the physical means of connecting computers.

[0071] Among them, the MMTLS is between the application layer and the network layer, does not affect the original network strategy, and is implemented based on TCP.

[0072] The handshake protocol, as the name suggests, is to negotiate the algorithm suite and encryption key used for encryption before encrypted communication. This is similar to the polite handshake that is usually required before two strangers start chatting.

[0073] In computer network communication scenarios, communication is generally carried out through HTTPS. The basis of HTTPS is HTTP, but it uses the universal transport layer security protocol to encrypt data packets.

[0074] In related technologies, TLS can use symmetric encryption to encrypt data packets, that is, the server sends the static key to the client through TLS, so that the client and the server share the same static key. The data transmission party encrypts the plaintext and the static key together through a special encryption algorithm, so that the plaintext becomes a complex ciphertext and sends it to the data recipient. After the data recipient receives the ciphertext, it decrypts the ciphertext through the static key and the inverse algorithm of the special encryption algorithm, and restores it to readable plaintext to ensure the security of data transmission.

[0075] However, the static key used in this data transmission method is easily analyzed and cracked because it is directly transmitted through TLS, and can be obtained by attackers through attack methods. At the same time, since the static key is fixed, once the attacker successfully obtains it, all ciphertexts can be easily cracked, resulting in data leakage.

[0076] In order to solve the above problems, the embodiments of the present application propose a method for transmitting dynamic keys and encrypted strings obtained by encrypting dynamic keys through a more secure dedicated transport layer security protocol, encrypting data to be sent through the dynamic key to generate corresponding ciphertext, and sending the ciphertext and encrypted string to the server through a universal transport layer security protocol, so that the server decrypts the encrypted string to obtain the dynamic key, and decrypts the ciphertext to obtain the decrypted data, thereby ensuring that the dynamic key is not intercepted by attackers, and sending the dynamic key to the server through a universal transport layer security protocol in the form of an encrypted string, avoiding the dynamic key from being transmitted in plain text, effectively preventing the dynamic key from being cracked, and improving the security of data transmission.

[0077] Please continue to refer to FIG. 2 , which is a schematic diagram of a scenario of a data transmission system provided in some embodiments of the present application, including a terminal 140 , the Internet 130 , a gateway 120 , a server 110 , and the like.

[0078] Terminal 140 includes, but is not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle-mounted terminals, aircraft, and the like. Embodiments of the present application can be applied to various scenarios, including, but not limited to, cloud technology, artificial intelligence, smart transportation, and assisted driving. Furthermore, it can be a single device or a combination of multiple devices. For example, multiple desktop computers connected to each other via a local area network, sharing a common display, and working collaboratively, together constitute a terminal 140. Terminal 140 can communicate with Internet 130 via wired or wireless means to exchange data.

[0079] Server 110 refers to a computer system that provides certain services to terminal 140. Compared to ordinary terminal 140, server 110 has higher requirements in terms of stability, security, and performance. Server 110 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0080] Gateway 120, also known as a gateway or protocol converter, implements network interconnection at the transport layer and is a computer system or device that performs a conversion function. It acts as a translator between two systems using different communication protocols, data formats, languages, or even completely different architectures. Gateways can also provide filtering and security functions. Messages sent from terminal 140 to server 110 are sent through gateway 120 to the corresponding server 110. Messages sent from server 110 to terminal 140 are also sent through gateway 120 to the corresponding terminal 140.

[0081] The embodiments of the present application can be applied in a variety of scenarios, such as the scenario of the login system shown in FIG3 and the scenario of the virtual resource payment system shown in FIG4 .

[0082] (1) System login scenario

[0083] The login system can realize the login function and complete login-related services. As shown in Figure 3, on the interface 11 of the terminal's login system, the object can enter the account and password to log in. The interface 11 can be the interface of the mini-program end. When the interface 11 of the login system is opened and displayed, the terminal will generate a handshake request and send a handshake request to the server through a dedicated transport layer security protocol between the mini-program end and the server. The dedicated transport layer security protocol has higher security than the general transport layer security protocol; the dynamic key returned by the server according to the handshake request and the encrypted string obtained by encryption based on the dynamic key are received through the dedicated transport layer security protocol; the data to be sent (which can be understood as the login account data and password data) is obtained, and the data is encrypting the data through the dynamic key to generate ciphertext; the ciphertext and the encrypted string are sent to the server through the general transport layer security protocol, so that the server decrypts the encrypted string to obtain the dynamic key, decrypts the ciphertext according to the dynamic key, and obtains the decrypted data.

[0084] (2) Scenario of Virtual Resource Payment System

[0085] The virtual resource payment system can implement payment functions and complete payment-related services. As shown in Figure 4, on the interface 12 of the virtual resource payment system of the terminal, the object can enter the virtual resources required to pay for the product, such as 1000, and the payment password, such as 123456, and click the order button to implement the payment function. The interface 12 can be the interface of the mini-program end. When the interface 12 of the virtual resource payment system is opened and displayed, the terminal will generate a handshake request and send a handshake request to the server through a dedicated transport layer security protocol between the mini-program end and the server. The dedicated transport layer security protocol has higher security than the general transport layer security protocol; the dynamic key returned by the server according to the handshake request and the encrypted string obtained by encryption based on the dynamic key are received through the dedicated transport layer security protocol; the data to be sent (which can be understood as the virtual resource data and payment password data for payment) are obtained, and the data is encrypting the data through the dynamic key to generate ciphertext; the ciphertext and the encrypted string are sent to the server through the general transport layer security protocol, so that the server decrypts the encrypted string to obtain the dynamic key, and decrypts the ciphertext according to the dynamic key to obtain the decrypted data.

[0086] It should be noted that the scenario diagram of the data transmission system shown in Figure 2 is only an example. The data transmission system and scenario described in the embodiment of the present application are intended to more clearly illustrate the technical solution of the embodiment of the present application, and do not constitute a limitation on the technical solution provided by the embodiment of the present application. Ordinary technicians in this field can know that with the evolution of the data transmission system and the emergence of new business scenarios, the technical solution provided by the embodiment of the present application is also applicable to similar technical problems.

[0087] In this embodiment, the description will be from the perspective of a data transmission device. The data transmission device can be integrated into a computer device having a storage unit and a microprocessor with computing capabilities. The computer device can be a terminal. The terminal can be installed with an instant messaging client. The instant messaging client can run a small program. In this embodiment, the description is based on the small program running on the terminal. In some embodiments of the present application, the server that interacts with the terminal can be an instant messaging server.

[0088] Please refer to Figure 5, which is a flow chart of a data transmission method provided in an embodiment of the present application. The data transmission method includes:

[0089] In step 201, a handshake request is sent to the server via a dedicated transport layer security protocol between the applet and the server.

[0090] TLS can encrypt data packets using symmetric encryption. That is, the server sends the static key to the client through TLS, so that both the client and the server share the same static key. The data transmission party encrypts the plaintext and the static key together through a special encryption algorithm, turning the plaintext into complex ciphertext and sending it to the data recipient. After receiving the ciphertext, the data recipient decrypts the ciphertext using the static key and the inverse algorithm of the special encryption algorithm, restoring it to readable plaintext to ensure the security of data transmission.

[0091] However, the static key used in this data transmission method is easily analyzed and cracked because it is directly transmitted through TLS, and can be analyzed and obtained by attackers through attack methods. At the same time, since the static key is fixed, once the attacker successfully obtains it, all ciphertexts can be easily cracked, resulting in data leakage. TLS can only provide security at the transport layer. However, with the advancement of packet capture and analysis tools, the use of TLS alone cannot resist packet capture and analysis tools based on self-signed certificates and is still vulnerable to attacks.

[0092] It should be noted that the mini program in the embodiment of the present application relies on the instant messaging client, that is, the instant messaging client can serve as the running container of the mini program, and the mini program runs on the instant messaging client, so the mini program can directly call the corresponding dedicated transport layer security protocol of the instant messaging client.

[0093] Therefore, in order to solve the above problems and ensure the security of data transmission, the embodiment of the present application can send a handshake request to the server through a dedicated transport layer security protocol between the mini program and the server, that is, a dedicated transport layer security protocol. The handshake request can carry the mini program identifier and instant messaging client version of the mini program, so that the server can identify whether the handshake request is sent by a normally usable mini program and instant messaging client version based on the mini program identifier and instant messaging client version.

[0094] Because the dedicated TLS protocol is highly customized, existing packet capture tools cannot analyze it. Specifically, because the dedicated TLS protocol is customized, existing packet capture tools cannot capture its handshake requests, preventing attackers from monitoring the handshake requests of mini-programs. Therefore, the dedicated TLS protocol offers higher security than the general TLS protocol.

[0095] To better illustrate the embodiments of the present application, please refer to FIG. 6 . The mini-program on the terminal 140 may send a handshake request to the server through a dedicated transport layer security protocol between the mini-program and the server to ensure the privacy of the handshake request.

[0096] In step 202, a dynamic key returned by the server according to the handshake request and an encrypted string obtained according to the dynamic key are received through a dedicated transport layer security protocol.

[0097] After receiving the handshake request sent by the applet via a dedicated transport layer security protocol, the server can generate a random dynamic key based on the handshake request. The dynamic key can be randomly generated by a secure random number generator in the server and can be 128 or 256 bits long. Unlike related technologies, the embodiment of the present application generates different dynamic keys based on different handshake requests, that is, the dynamic keys change in real time, thereby better resisting cracking by attackers.

[0098] It should be noted that due to the limited transmission capacity of the dedicated transport layer security protocol, subsequent data transmission still needs to be transmitted through the general transport layer security protocol. In order to avoid the dynamic key being transmitted in plain text on the general transport layer security protocol, the server can encrypt the dynamic key according to the set encryption rules to obtain the corresponding encrypted string.

[0099] Furthermore, the server can return the dynamic key and the encrypted string to the applet in the embodiment of the present application through the dedicated transport layer security protocol. In this way, the embodiment of the present application can receive the dynamic key returned by the server and the encrypted string encrypted based on the dynamic key through the dedicated transport layer security protocol to achieve a handshake, that is, to establish a connection between the applet and the server. Correspondingly, since the entire dedicated transport layer security protocol is highly customized, existing packet capture tools cannot perform packet capture analysis. That is, because the dedicated transport layer security protocol is customized, existing packet capture tools cannot capture the dynamic key and encrypted string transmitted by the dedicated transport layer security protocol, which better ensures the security of the dynamic key.

[0100] Please continue to refer to Figure 6. The server 110 can generate a random dynamic key according to the handshake request, and generate an encrypted string token based on the secret (i.e., the dynamic key) through the aes_encrypt(token, secret) function, and transmit the dynamic key and the encrypted string containing the dynamic key to the applet on the terminal 140 through a dedicated transport layer security protocol. Correspondingly, the applet on the terminal 140 can receive the dynamic key and the encrypted string containing the dynamic key.

[0101] In some embodiments, in order to achieve better data protection, each dynamic key can be specified to have a corresponding validity period, that is, after the dynamic key reaches the validity period, the dynamic key will become invalid accordingly, and the applet needs to resend the handshake request and re-receive the updated dynamic key and encryption string through the dedicated transport layer security protocol, so that the dynamic key can be updated regularly to better avoid analysis by attackers. The validity period can be set manually, such as 15 minutes or 30 minutes.

[0102] In some embodiments, mini-programs can be applied to different scenarios, such as login scenarios, ordering scenarios, and information browsing scenarios. The login scenario represents the subject using the mini-program to log in to an account, the ordering scenario represents the subject using the mini-program to place an order for a product, and the information browsing scenario represents the subject using the mini-program to browse information. Each scenario has different security requirements. For example, the login scenario requires higher security than the ordering scenario, which in turn requires higher security than the information browsing scenario. Based on this, different validity periods can be set for the dynamic keys allocated in each scenario.

[0103] Based on this, the handshake request can carry a corresponding scenario type, which indicates the corresponding scenario of the mini program when the handshake request is generated. The scenario type may include but is not limited to a login scenario type, an ordering scenario type, or an information browsing scenario type. When the mini program generates a handshake request in a login scenario, the scenario type carried by the handshake request is a login scenario type. When the mini program generates a handshake request in an ordering scenario, the scenario type carried by the handshake request is an ordering scenario type. Correspondingly, when the mini program generates a handshake request in an information browsing scenario, the scenario type carried by the handshake request is an information browsing scenario type.

[0104] Thus, the method further comprises:

[0105] Receiving, through the dedicated transport layer security protocol, the validity period corresponding to the dynamic key returned by the server according to the handshake request;

[0106] The valid time is the time determined by the server according to the scenario type carried in the handshake request.

[0107] Specifically, since the handshake request carries the corresponding scene type, the server can automatically match the corresponding validity period according to the scene type while determining the corresponding dynamic key. The mapping relationship between the scene type and the validity period is shown in Table 1. Table 1 is a preset mapping table, which includes the mapping relationship between different scene types and validity periods. Assuming that the scene type is a login scene type, the obtained validity period is 5 minutes. Assuming that the scene type is an order scene type, the obtained validity period is 10 minutes. Assuming that the scene type is an information browsing scene type, the obtained validity period is 30 minutes.

[0108] Table 1

[0109] Based on this, the server can return the dynamic key, the corresponding validity time of the dynamic key and the encrypted string to the mini program through a dedicated transport layer security protocol. Correspondingly, the mini program can receive the dynamic key, the corresponding validity time of the dynamic key and the encrypted string obtained by encryption based on the dynamic key returned by the server according to the handshake request through a dedicated transport layer security protocol. In this way, the validity time of the corresponding dynamic key can be flexibly set according to the security requirements of different scenario types when the mini program initiates a handshake request, thereby improving the flexibility of the validity time setting.

[0110] In some embodiments, since the application scenario of the mini program can change in real time, for example, the application scenario of the mini program switches from an ordering scenario type to a login scenario type, the requirements for the validity period of the dynamic key are also different due to the change in scenario. Therefore, after the mini program receives the dynamic key returned by the server in response to the handshake request, the corresponding validity period of the dynamic key, and the encrypted string obtained by encrypting the dynamic key through a dedicated transport layer security protocol, it is also necessary to monitor the change of the scenario type in real time to ensure the real-time update of the dynamic key, specifically including the following methods:

[0111] When a change in the scene type is detected, the dynamic key, the validity period corresponding to the dynamic key, and the encrypted string obtained by encrypting the dynamic key are deleted;

[0112] Re-execute sending a handshake request to the server through the dedicated transport layer security protocol between the applet and the server, so as to re-receive the updated dynamic key, validity time and encryption string through the dedicated transport layer security protocol.

[0113] Specifically, the mini program can continuously detect whether the scene type has changed. When a change in the scene type is detected, it indicates that the scene has changed, and the currently stored dynamic key, the corresponding validity period of the dynamic key, and the encrypted string obtained by encryption based on the dynamic key need to be deleted.

[0114] Furthermore, in order to achieve better security, the dynamic key needs to be updated. Therefore, the above embodiment can be re-executed to re-receive the updated dynamic key, validity time and encryption string under the changed scenario type. In this way, it is ensured that the dynamic key can change in real time as the scenario of the mini program application changes, thereby improving the flexibility of the dynamic key update.

[0115] In some embodiments, the mini program can be applied to different scenarios, such as login scenarios, ordering scenarios, and information browsing scenarios. The login scenario represents that the object logs in to the account through the mini program, the ordering scenario represents that the object places an order for goods through the mini program, and the information browsing scenario represents that the object browses information through the mini program. Each scenario has different security requirements. For example, the security required for the login scenario is higher than that for the ordering scenario, and the security required for the ordering scenario is higher than that for the information browsing scenario.

[0116] At the same time, there are many types of mini programs, such as office-type mini programs, game-type mini programs, or life-type mini programs, and each type of mini program has different security requirements. For example, office-type mini programs require higher security than life-type mini programs, and life-type mini programs require higher security than game-type mini programs. Based on this, different effective times can be flexibly set in combination with the application scenarios and types of mini programs.

[0117] Based on this, the handshake request can carry both the scenario type and the application privacy level. The scenario type indicates the corresponding scenario of the mini program when the handshake request is generated. The scenario type may include but is not limited to the login scenario type, the ordering scenario type, or the information browsing scenario type. When the mini program generates a handshake request in the login scenario, the scenario type carried by the handshake request is the login scenario type. When the mini program generates a handshake request in the ordering scenario, the scenario type carried by the handshake request is the ordering scenario type. Correspondingly, when the mini program generates a handshake request in the information browsing scenario, the scenario type carried by the handshake request is the information browsing scenario type.

[0118] The application privacy level indicates the privacy level corresponding to the type of mini-program when generating a handshake request. The application privacy level includes but is not limited to high, medium and low. In this way, the application privacy level of an office-type mini-program can be set to high, the application privacy level of a life-type mini-program can be set to medium, and the application privacy level of a game-type mini-program can be set to low. When the mini-program type is office-type and a handshake request is generated, the application privacy level carried by the handshake request is high. When the mini-program type is life-type and a handshake request is generated, the application privacy level carried by the handshake request is medium. When the mini-program type is game-type and a handshake request is generated, the application privacy level carried by the handshake request is low.

[0119] Thus, the method may include:

[0120] Receiving, through the dedicated transport layer security protocol, the validity period corresponding to the dynamic key returned by the server according to the handshake request;

[0121] The validity period is the period determined by the server based on the scenario type and application privacy level carried in the handshake request.

[0122] Specifically, since the handshake request can carry both the scene type and the application privacy level, the server can match the scene type with Table 1 (i.e., the preset mapping table) while determining the corresponding dynamic key to determine the initial validity period of the dynamic key. Assuming that the scene type carried by the handshake request is an order scene type, it can be determined that the initial validity period of the dynamic key is 10 minutes.

[0123] Furthermore, the server can automatically match the corresponding weight based on the application privacy level. The mapping relationship between application privacy level and weight is shown in Table 2. Assuming the application privacy level is high, the weight obtained is 0.6. Assuming the application privacy level is medium, the weight obtained is 0.8. Assuming the application privacy level is low, the weight obtained is 1. That is, the higher the application privacy level, the lower the weight, and the lower the application privacy level, the higher the weight.

[0124] Table 2

[0125] Based on the weights matched in Table 2, the initial valid time obtained by the previous match is weighted to obtain the final valid time of the dynamic key. Assuming that the application privacy level carried by the handshake request is medium, the initial valid time of 10 minutes is weighted according to the matched weight of 0.8, and the final valid time is 8 minutes.

[0126] Based on this, the server can return the dynamic key, the corresponding validity time of the dynamic key and the encrypted string to the mini program through a dedicated transport layer security protocol. Correspondingly, the mini program can receive the dynamic key, the corresponding validity time of the dynamic key, and the encrypted string obtained by encryption based on the dynamic key returned by the server according to the handshake request through a dedicated transport layer security protocol. In this way, the security requirements of different scenario types and mini program types when the mini program initiates a handshake request can be comprehensively considered, and the validity time of the corresponding dynamic key can be flexibly set, which further improves the flexibility of the validity time setting.

[0127] In some embodiments, the mini-program may receive the dynamic key returned by the server in response to the handshake request, the corresponding validity period of the dynamic key, and the encrypted string obtained by encrypting the dynamic key through a dedicated transport layer security protocol. Furthermore, the mini-program may need to monitor the validity period of the dynamic key in real time to ensure real-time updating of the dynamic key, specifically in the following ways:

[0128] Determine the corresponding effective expiration time according to the effective time;

[0129] When it is detected that the current time reaches the valid expiration time, the handshake request is sent to the server through the dedicated transport layer security protocol between the applet and the server again to re-receive the updated dynamic key, valid time and encryption string through the dedicated transport layer security protocol.

[0130] Specifically, the server can also send the generation time of the dynamic key to the mini program at the same time. In this way, the mini program can calculate the effective expiration time based on the generation time and effective time of the dynamic key. For example, if the generation time of the dynamic key is 11:51:00 on October 8, 2023, and the effective time is 8 minutes, then the effective expiration time is 11:59:00 on October 8, 2023.

[0131] In this way, the mini program can continuously detect whether the current time has reached the valid expiration time. When it is detected that the current time has not reached the valid expiration time, it means that the dynamic key is still valid. On the contrary, when it is detected that the current time has reached the valid expiration time, it means that the dynamic key has expired. In order to achieve better security, the dynamic key needs to be updated. Therefore, the above embodiment can be re-executed to re-receive the updated dynamic key, valid time and encryption string. In this way, it is ensured that the dynamic key can be updated regularly according to the valid time, the variability of the dynamic key is increased, and the difficulty of cracking is increased.

[0132] In some embodiments, after generating a dynamic key and obtaining the validity period of the dynamic key, the server may determine a timestamp for the dynamic key based on the validity period. The timestamp may include the issue time (iat) and expiration time (expire atime) of the dynamic key. For example, if the issue time is 11:51:00 on October 8, 2023, and the validity period is 8 minutes, then the expiration time is 11:59:00 on October 8, 2023. The server may also obtain an identity identifier for the mini-program, which may be an account identifier used to log in to the instant messaging client that the mini-program relies on, such as account identifier 12345. The server may then obtain a triple of [dynamic key, identity identifier, timestamp] and perform symmetric encryption on the [dynamic key, identity identifier, timestamp] based on a preset key to obtain a corresponding encrypted string. This allows the dynamic key to be subsequently transmitted as an encrypted string over a universal transport layer security protocol, preventing the dynamic key from being transmitted in plaintext and improving the security of dynamic key transmission.

[0133] It should be noted that the symmetric encryption processing can be an AES (Advanced Encryption Standard) encryption algorithm (Advanced Encryption Standard algorithm). The AES encryption algorithm can use 128-bit, 192-bit or 256-bit keys to encrypt and decrypt data, and has the advantages of high strength, high speed and easy implementation. The preset key is a 128-bit, 192-bit or 256-bit key used for encryption, and unlike the symmetric encryption in the related art, the preset key does not need to be transmitted to the terminal, but only needs to be retained inside the server, which can prevent the preset key from being leaked.

[0134] In step 203, the data to be sent is obtained, and the data is encrypted using a dynamic key to generate corresponding ciphertext.

[0135] Among them, the data to be sent is the plaintext to be sent, which is the data that the mini program needs to send to the server. It can be the login account password, or the password used for payment. This data is very confidential to the object. If it is transmitted directly in plain text, it can be easily intercepted and analyzed by attackers, and the confidential data of the object can be easily obtained, causing economic losses to the object and data leakage.

[0136] In order to solve the above problems, the embodiment of the present application can symmetrically encrypt the data through the dynamic key received through the dedicated transport layer security protocol to generate the corresponding ciphertext. In this way, even if the attacker intercepts the ciphertext, he will not be able to crack it because he does not have the dynamic key, thereby avoiding economic losses to the target and data leakage.

[0137] In some implementations, data may be encrypted using a dynamic key based on an AES encryption algorithm and in CBC (Cipher Block Chaining) mode. Referring to FIG. 7 , step 203 includes:

[0138] Step 301: Acquire data to be sent, generate an encryption initialization vector for the data, and perform an XOR operation on the data according to the encryption initialization vector to obtain an XOR result.

[0139] Step 302: Encrypt the XOR result using the dynamic key to obtain the ciphertext.

[0140] It should be noted that CBC is called Cipher Block Chaining mode (ciphertext group chaining mode), and "grouping" means that both encryption and decryption processes are performed in the form of groups. Each group size is 128 bits (16 bytes). If the length of the plaintext is not an integer multiple of 16 bytes, the last group needs to be padded (padding) so that the length of the last group is 16 bytes. "Link" means that the ciphertext groups are connected to each other like a chain. In this CBC mode, an initialization vector IV is required (that is, an encryption initialization vector in an embodiment of the present application). Therefore, the data to be sent (that is, plaintext) can be obtained, and an encryption initialization vector can be generated. The encryption initialization vector can randomly generate a numerical value for the applet and convert the numerical value into an encryption initialization vector. The conversion method of One-Hot encoding can be used. One-Hot encoding, for sequence data with discrete values, can use One-Hot encoding to represent each value as a vector.

[0141] In some implementations, generating an encryption initialization vector corresponding to the data may further include:

[0142] Generate random numbers;

[0143] Generate the message sequence number of the data;

[0144] The random number is combined with the message sequence number to generate a corresponding encryption initialization vector.

[0145] Specifically, a random number, Nonce, such as 20 or 30, can be generated, and a message sequence number, Seq, such as 1, 2, or 3, can be generated based on the order in which the data is generated. Accordingly, Nonce + Seq can be combined to generate a corresponding encryption initialization vector through one-hot encoding. Since the random number and message sequence number are dynamically changing, the encryption initialization vector is also constantly changing, ensuring that subsequent encryption of the same plaintext multiple times will result in different ciphertexts, making it more difficult for attackers to crack the ciphertext.

[0146] Accordingly, after obtaining the encryption initialization vector, the data can be encrypted in CBC mode in combination with the dynamic key to obtain the final ciphertext. Specifically, step 301 includes:

[0147] dividing the data into a plurality of data groups;

[0148] For a first data packet, performing an XOR operation on the encryption initialization vector and the first data packet to obtain a first XOR result of the first data packet;

[0149] For each data group in the other data groups, the sub-ciphertext of the previous data group of the data group is XORed with the data group to obtain a second XOR result for each data group in the other data groups.

[0150] Step 302 includes:

[0151] Encrypting the first XOR result using the dynamic key to obtain a sub-ciphertext corresponding to the first data group;

[0152] Encrypting the second XOR result of each data group in the other data groups by using the dynamic key to obtain a sub-ciphertext corresponding to each data group in the other data groups;

[0153] The sub-ciphertexts corresponding to the multiple data groups are combined into a ciphertext.

[0154] Specifically, the data can be grouped in such a way that each group size is 128 bits (i.e., 16 bytes). It should be noted that if the length of the plaintext is not an integer multiple of 16 bytes, the last group will be padded so that the length of the last group is also 16 bytes. To better illustrate the embodiment of the present application, please refer to FIG. 8 , in which the data can be divided into multiple data groups in such a way that each group size is 16 bytes.

[0155] It should be noted that exclusive OR, abbreviated as xor, is a mathematical operator. It is used in logical operations. The mathematical symbol for exclusive OR is The computer symbol is "xor". Its operation rules are: That is, if the values ​​of a and b are different, the XOR result is 1. If the values ​​of a and b are the same, the XOR result is 0. XOR is also called half-addition, and its operation is equivalent to binary addition without carry.

[0156] For the first data group, the encryption initialization vector can be XORed with the first data group to obtain a first XOR result of the first data group, and the first XOR result is sent to the block cipher encryption module and encrypted in combination with the dynamic key to obtain the sub-ciphertext corresponding to the first data group.

[0157] For other data groups, the sub-ciphertext corresponding to the previous data group may be XORed with the other data groups to obtain a second XOR result for the other data groups.

[0158] Furthermore, the second XOR result can be sent to the block cipher encryption module and encrypted in combination with the dynamic key to obtain sub-ciphertexts of other data groups. For example, for the second data group, the sub-ciphertext corresponding to the first data group can be XORed with the second data group to obtain the second XOR result of the second data group, and the corresponding second XOR result can be sent to the block cipher encryption module and encrypted in combination with the dynamic key to obtain the sub-ciphertext of the second data group. For the third data group, the sub-ciphertext corresponding to the second data group can be XORed with the third data group to obtain the second XOR result of the third data group, and the corresponding second XOR result can be sent to the block cipher encryption module and encrypted in combination with the dynamic key to obtain the sub-ciphertext of the third data group. And so on, the sub-ciphertext of each other data group can be obtained.

[0159] Accordingly, the sub-ciphertexts corresponding to each data group can be concatenated to obtain the final ciphertext.

[0160] In step 204, the ciphertext and the encrypted string are sent to the server via the universal transport layer security protocol.

[0161] Among them, since the transmission capacity of the dedicated transport layer security protocol is limited, the transmission of ciphertext and encrypted string needs to be transmitted through the general transport layer security protocol, that is, the applet can send the ciphertext and encrypted string to the server through the general transport layer security protocol.

[0162] Since the ciphertext is obtained through dynamic key encryption and the encrypted string is obtained through preset key encryption, neither the dynamic key nor the data will be transmitted in plain text on the general transport layer security protocol. The dynamic key is securely transmitted through a dedicated transport layer security protocol, and the preset key only exists on the server. Therefore, even if an attacker intercepts the ciphertext and encrypted string, he cannot perform the corresponding decryption. In this way, data security is protected and the security of data transmission is improved.

[0163] Please continue to refer to Figure 6. The terminal 140 encrypts the data using a dynamic key to obtain the corresponding ciphertext, and transmits the ciphertext to the server 110 via the universal transport layer security protocol. The encrypted string token can be placed in the URL and transmitted to the server 110.

[0164] After receiving the ciphertext and encrypted string, the server can decrypt the encrypted string according to the preset key to obtain the dynamic key. In this way, the ciphertext can be decrypted according to the dynamic key to obtain the corresponding data (i.e. plaintext), thereby achieving secure communication and effectively protecting the integrity and security of the data from the mini program to the server, preventing attackers from decrypting and cracking the data.

[0165] In some embodiments, the mini program uses the AES encryption algorithm and the CBC (Cipher Block Chaining) mode to encrypt data using a dynamic key. Therefore, the mini program also needs to send the encryption initialization vector to the server. That is, step 204 further includes:

[0166] The encryption initialization vector is sent to the server via the general transport layer security protocol.

[0167] The mini-program can send the encryption initialization vector, ciphertext, and encrypted string to the server via the transport layer security protocol, so that after receiving the encryption initialization vector, ciphertext, and encrypted string, the server can decrypt the encrypted string according to the preset key, recover the dynamic key, and decrypt the ciphertext by combining the dynamic key with the encryption initialization vector. The specific processing process is as follows:

[0168] The ciphertext is grouped into 128-bit (i.e., 16-byte) blocks, resulting in multiple ciphertext subblocks. The first ciphertext subblock is decrypted using the dynamic key to obtain a first decryption result. This first decryption result is then XORed with the initial encryption vector to obtain the sub-plaintext corresponding to the first ciphertext subblock. The second ciphertext subblock is decrypted using the dynamic key to obtain a second decryption result. The sub-ciphertext of the previous ciphertext subblock (i.e., the first ciphertext subblock) is XORed with the second decryption result to obtain the sub-plaintext corresponding to the second ciphertext subblock. The third ciphertext subblock is decrypted using the dynamic key to obtain a third decryption result. The sub-ciphertext of the previous ciphertext subblock (i.e., the second ciphertext subblock) is XORed with the third decryption result to obtain the sub-plaintext corresponding to the third ciphertext subblock. This process is repeated to obtain the sub-plaintext corresponding to each ciphertext subblock.

[0169] Correspondingly, the sub-plaintexts of each ciphertext subgroup can be concatenated to obtain data.

[0170] From the above, it can be seen that the embodiment of the present application sends a handshake request to the server through a dedicated transport layer security protocol between the mini program and the server. The dedicated transport layer security protocol has higher security than the general transport layer security protocol; receives the dynamic key returned by the server according to the handshake request and the encrypted string obtained by encryption based on the dynamic key through the dedicated transport layer security protocol; obtains the data to be sent, and encrypts the data through the dynamic key to generate the corresponding ciphertext; sends the ciphertext and the encrypted string to the server through the general transport layer security protocol, so that the server decrypts the ciphertext according to the dynamic key recovered by decrypting the encrypted string to obtain the decrypted data. In this way, the dynamic key and the encrypted string obtained by encryption based on the dynamic key are received through a dedicated transport layer with higher security than the general transport layer security protocol, the data to be sent is encrypted by the dynamic key to generate corresponding ciphertext, and the ciphertext and the encrypted string are sent to the server through the general transport layer security protocol, so that the server decrypts the ciphertext according to the dynamic key restored by decryption of the encrypted string to obtain the decrypted data. Compared with the solution of realizing symmetric encryption through static keys in the related art, the embodiment of the present application can receive the dynamic key through a more secure dedicated transport layer security protocol, ensure that the dynamic key is not intercepted by attackers, and send the dynamic key to the server in the form of an encrypted string through the general transport layer security protocol, avoiding the dynamic key from being transmitted in plain text, effectively preventing the dynamic key from being cracked, and improving the security of data transmission.

[0171] In combination with the method described in the above embodiment, the following examples are given to further illustrate the method in detail.

[0172] In this embodiment, the description will be made from the perspective of a data transmission device. The data transmission device can be specifically integrated into a computer device having a storage unit and a microprocessor installed therein and having computing capabilities. The computer device can be a server, that is, a server is used for description in this embodiment.

[0173] Please refer to Figure 9, which is a flow chart of a data transmission method provided by an embodiment of the present application. The method flow may include:

[0174] In step 401, a handshake request sent by the applet via a dedicated transport layer security protocol is received.

[0175] Among them, the server can receive a handshake request sent by the mini program through a dedicated transport layer security protocol. The handshake request can carry the mini program identifier and instant messaging client version of the mini program. In this way, the server can verify whether the mini program identifier and instant messaging client version can be used normally. When it is verified that the mini program identifier or instant messaging client version cannot be used normally, for example, the mini program identifier is wrong or the instant messaging client version is too low, the handshake request will not be responded to.

[0176] Correspondingly, when it is verified that the mini program identifier and the instant messaging client can be used normally, the handshake request is responded to and step 402 is executed.

[0177] In step 402, a random dynamic key is generated according to the handshake request, and a corresponding encryption string is obtained according to the dynamic key.

[0178] Among them, the server responds to the handshake request and generates a random dynamic key according to a secure random number generator. The length of the dynamic key can be 128 bits or 256 bits, etc. That is, the dynamic key changes in real time and can better resist cracking by attackers.

[0179] It should be noted that due to the limited transmission capacity of the dedicated transport layer security protocol, the data transmitted by subsequent mini-programs still needs to be transmitted through the general transport layer security protocol. In order to avoid the dynamic key being transmitted in plain text on the general transport layer security protocol, the server can encrypt the dynamic key according to the set encryption rules to obtain the corresponding encrypted string.

[0180] In some embodiments, in order to achieve better data protection, it can be stipulated that the dynamic key has a corresponding validity period, that is, after the dynamic key reaches the validity period, the dynamic key will become invalid accordingly, and the applet needs to resend the handshake request. The server will generate an updated dynamic key and encryption string based on the resent handshake request and send it to the applet, so that the dynamic key is updated regularly to better avoid analysis by attackers.

[0181] That is, step 402 may include:

[0182] Generate a random dynamic key according to the handshake request and determine the validity period of the dynamic key;

[0183] determining a timestamp of the dynamic key based on the validity time;

[0184] Obtain the identity of the applet, encrypt the dynamic key, identity and timestamp, and obtain the corresponding encrypted string.

[0185] Among them, the validity period can be set manually, for example, the default is 15 minutes or 30 minutes. In the embodiment of the present application, 30 minutes is taken as an example. The server can respond to the handshake request, generate a random 256-bit dynamic key, and determine that the validity period of the dynamic key is 30 minutes.

[0186] Accordingly, based on the valid time of 30 minutes, in order to subsequently verify the validity of the encrypted string, the timestamp of the dynamic key can be determined based on the valid time. The timestamp can include the dynamic key production time (issue atime, iat) and expiration time (expire atime, exp). For example, if the production time is 11:50:00 on October 8, 2023 and the valid time is 30 minutes, then the expiration time is 12:20:00 on October 8, 2023.

[0187] Furthermore, in order to subsequently authenticate the encrypted string, the identity identifier of the mini program that sends the handshake request can also be obtained. The identity identifier can be the account identifier logged in on the instant messaging client that the mini program relies on, such as account identifier 12345, and then the triplet of [dynamic key, identity identifier, timestamp] is obtained. The [dynamic key, identity identifier, timestamp] can be symmetrically encrypted based on the preset key to obtain the corresponding encrypted string. In this way, the dynamic key can be subsequently transmitted in the form of an encrypted string on the general transport layer security protocol, avoiding the transmission of the dynamic key in plain text, thereby improving the security of the dynamic key transmission.

[0188] It should be noted that the symmetric encryption processing can be an AES (Advanced Encryption Standard) encryption algorithm (Advanced Encryption Standard algorithm). The AES encryption algorithm uses 128-bit, 192-bit or 256-bit keys to encrypt and decrypt data. It has the advantages of high strength, high speed and easy implementation. The preset key is a 128-bit, 192-bit or 256-bit key used for encryption. And unlike the symmetric encryption in the related technology, the preset key does not need to be transmitted to the terminal, but only needs to be retained inside the server, which can prevent the preset key from being leaked.

[0189] In some implementations, the encrypted string may be binary ciphertext. The length of the data will be very large, affecting the transmission speed. In addition, since the subsequent applet needs to place the encrypted string in a URL and transmit it back to the server, and the URL only supports a limited character set and cannot encode binary ciphertext, it is necessary to simplify the encrypted string, that is, encrypt the dynamic key, identity identifier, and timestamp to obtain the corresponding encrypted string, including:

[0190] Encrypt the dynamic key, identity identifier and timestamp according to the preset key to obtain an initial encrypted string;

[0191] The initial encrypted string is converted into an encoding using a preset number of printable characters to obtain a corresponding encrypted string.

[0192] It should be noted that this preset number of printable characters can be understood as Base64 encoding. Base64 encoding is one of the most common encoding methods for transmitting 8-bit bytecodes. It is a method of representing binary data based on 64 printable characters. The encoding set consists of 64 characters: 26 uppercase letters A through Z, 26 lowercase letters a through z, 10 digits 0 through 9, and the "+" and " / " symbols.

[0193] Specifically, the [dynamic key, identity identifier, and timestamp] are symmetrically encrypted based on a preset key to obtain an initial encrypted string. This initial encrypted string is binary ciphertext. To facilitate subsequent transmission, this initial encrypted string can be encoded and converted using Base64 encoding. Specifically, the initial encrypted string can be divided into groups of three bytes, each group containing 24 binary bits. The 24 binary bits are then divided into four groups of six (i.e., 6 × 4 = 24 binary bits). 00 is then added to the front of each group, expanding it to 8 × 4 = 32 binary bits, i.e., four bytes (because each byte has two leading zeros, the maximum value of each byte is 63. The two leading zeros are only added to make up a byte and do not change the value). Finally, according to the Base64 encoding table, the four-byte code value is converted to the corresponding Base64 character to obtain the corresponding encrypted string.

[0194] In some embodiments, mini-programs can be applied to different scenarios, such as login scenarios, ordering scenarios, and information browsing scenarios. The login scenario represents the subject using the mini-program to log in to an account, the ordering scenario represents the subject using the mini-program to place an order for a product, and the information browsing scenario represents the subject using the mini-program to browse information. Each scenario has different security requirements. For example, the login scenario requires higher security than the ordering scenario, which in turn requires higher security than the information browsing scenario. Based on this, different validity periods can be set for the dynamic keys allocated in each scenario.

[0195] Based on this, the handshake request sent by the mini program can carry a corresponding scenario type, which indicates the corresponding scenario of the mini program when the handshake request is generated. The scenario type may include but is not limited to the login scenario type, the ordering scenario type or the information browsing scenario type. When the mini program generates a handshake request in the login scenario, the scenario type carried by the handshake request is the login scenario type. When the mini program generates a handshake request in the ordering scenario, the scenario type carried by the handshake request is the ordering scenario type. Correspondingly, when the mini program generates a handshake request in the information browsing scenario, the scenario type carried by the handshake request is the information browsing scenario type.

[0196] Thus, determining the validity period of the dynamic key may include:

[0197] Determine the corresponding validity period of the dynamic key according to the preset mapping table;

[0198] The preset mapping table includes mapping relationships between different scene types and valid times.

[0199] Specifically, the preset mapping table can refer to Table 1 above, and the server can quickly match the corresponding validity period of the generated dynamic key according to the scenario type carried in the handshake request. Assuming that the scenario type carried in the handshake request is an order scenario type, it can be determined that the initial validity period of the dynamic key is 10 minutes.

[0200] In some embodiments, the mini program can be applied to different scenarios, such as login scenarios, ordering scenarios, and information browsing scenarios. The login scenario represents that the object logs in to the account through the mini program, the ordering scenario represents that the object places an order for goods through the mini program, and the information browsing scenario represents that the object browses information through the mini program. Each scenario has different security requirements. For example, the security required for the login scenario is higher than that for the ordering scenario, and the security required for the ordering scenario is higher than that for the information browsing scenario.

[0201] At the same time, there are many types of mini programs, such as office-type mini programs, game-type mini programs, or life-type mini programs, and each type of mini program has different security requirements. For example, office-type mini programs require higher security than life-type mini programs, and life-type mini programs require higher security than game-type mini programs. Based on this, different effective times can be flexibly set in combination with the application scenarios and types of mini programs.

[0202] Based on this, the handshake request can carry both the scenario type and the application privacy level. The scenario type indicates the corresponding scenario of the mini program when the handshake request is generated. The scenario type may include but is not limited to the login scenario type, the ordering scenario type, or the information browsing scenario type. When the mini program generates a handshake request in the login scenario, the scenario type carried by the handshake request is the login scenario type. When the mini program generates a handshake request in the ordering scenario, the scenario type carried by the handshake request is the ordering scenario type. Correspondingly, when the mini program generates a handshake request in the information browsing scenario, the scenario type carried by the handshake request is the information browsing scenario type.

[0203] The application privacy level indicates the privacy level corresponding to the type of mini-program when generating a handshake request. The application privacy level includes but is not limited to high, medium and low. In this way, the application privacy level of an office-type mini-program can be set to high, the application privacy level of a life-type mini-program can be set to medium, and the application privacy level of a game-type mini-program can be set to low. When the mini-program type is office-type and a handshake request is generated, the application privacy level carried by the handshake request is high. When the mini-program type is life-type and a handshake request is generated, the application privacy level carried by the handshake request is medium. When the mini-program type is game-type and a handshake request is generated, the application privacy level carried by the handshake request is low.

[0204] Thus, determining the validity period of the dynamic key may also include:

[0205] Determine the initial validity period of the dynamic key according to the preset mapping table;

[0206] The preset mapping table includes mapping relationships between different scene types and valid times;

[0207] A weight is determined according to the privacy level of the application, and the initial validity time is weighted based on the weight to obtain the validity time of the dynamic key.

[0208] Specifically, the preset mapping table can refer to Table 1 above, and the server can quickly match the initial validity period of the generated dynamic key according to the scenario type carried in the handshake request. Assuming that the scenario type carried in the handshake request is an order scenario type, the initial validity period of the dynamic key can be determined to be 10 minutes.

[0209] Furthermore, the server can also automatically match the corresponding weight according to the application privacy level. Please refer to Table 2 for the mapping relationship between the application privacy level and the weight. For example, if the application privacy level carried by the handshake request is medium, then the initial valid time of 10 minutes is weighted according to the matched weight of 0.8, and the final valid time is 8 minutes.

[0210] In step 403, the dynamic key and the encrypted string are returned to the applet via a dedicated transport layer security protocol.

[0211] Among them, the server can return the dynamic key and the encrypted string to the applet in the embodiment of the present application through the dedicated transport layer security protocol. The applet can receive the dynamic key returned by the server and the encrypted string obtained by encryption based on the dynamic key through the dedicated transport layer security protocol to achieve handshake, that is, establish a connection between the applet and the server so that the applet can encrypt the data to be sent (i.e., plain text) according to the dynamic key. Accordingly, since the entire dedicated transport layer security protocol is highly customized, the existing packet capture tools cannot perform packet capture analysis. That is, because the dedicated transport layer security protocol is customized, the existing packet capture tools cannot capture the dynamic key and encrypted string transmitted by the dedicated transport layer security protocol, which better ensures the security of dynamic key transmission.

[0212] In some implementations, the server may also return the validity period of the dynamic key to the applet, that is, return the dynamic key and the encrypted string to the applet via a dedicated transport layer security protocol, including:

[0213] The dynamic key, the corresponding validity period of the dynamic key and the encrypted string are returned to the applet via a dedicated transport layer security protocol.

[0214] Specifically, the server can return the dynamic key, the corresponding validity period of the dynamic key, and the encrypted string to the mini-program through a dedicated transport layer security protocol. Correspondingly, the mini-program can receive the dynamic key, the corresponding validity period of the dynamic key, and the encrypted string obtained by encryption based on the dynamic key returned by the server according to the handshake request through a dedicated transport layer security protocol, so that the mini-program can encrypt the data to be sent according to the dynamic key within the effective expiration time determined by the validity period.

[0215] In step 404, the ciphertext and encrypted string sent by the applet via the universal transport layer security protocol are received.

[0216] The mini-program can symmetrically encrypt data (i.e., plaintext) based on a dynamic key received via a dedicated transport layer security protocol, generate corresponding ciphertext, and send the ciphertext and encrypted string to the server via a universal transport layer security protocol. Correspondingly, the server can receive the ciphertext and encrypted string sent by the mini-program via the universal transport layer security protocol. It should be noted that the encrypted string can be placed in the URL for transmission by the mini-program.

[0217] Since the ciphertext is obtained through dynamic key encryption and the encrypted string is also encrypted, neither the dynamic key nor the data will be transmitted in plain text on the general transport layer security protocol. The dynamic key is securely transmitted through a dedicated transport layer security protocol, and the preset key only exists on the server. Therefore, even if an attacker intercepts the ciphertext and encrypted string, he cannot perform the corresponding decryption. In this way, data security is protected and the security of data transmission is improved.

[0218] In step 405, the encrypted string is decrypted to obtain a dynamic key, and the ciphertext is decrypted based on the dynamic key to obtain decrypted data.

[0219] Among them, after receiving the ciphertext and encrypted string, the server can decrypt the encrypted string to obtain the dynamic key. In this way, the ciphertext can be decrypted according to the dynamic key to obtain the corresponding data (i.e. plaintext), thereby realizing secure communication and effectively protecting the integrity and security of the data from the mini program to the server, preventing attackers from decrypting and cracking the data.

[0220] In some implementations, when the encrypted string is obtained by Base64 encoding, it is necessary to first restore the encrypted string to binary ciphertext and then decrypt the encrypted string.

[0221] In some embodiments, the server stores a preset key that was previously used to symmetrically encrypt the dynamic key, so the encrypted string needs to be decrypted using the preset key. That is, referring to FIG. 10 , step 405 includes:

[0222] Step 501: decrypt the encrypted string using a preset key to obtain the dynamic key, identity identifier, and timestamp;

[0223] Step 502: When the identity and the timestamp are verified, the ciphertext is decrypted according to the dynamic key to obtain decrypted data.

[0224] Among them, after receiving the ciphertext and encrypted string, the server can decrypt the encrypted string according to the preset key to obtain the [dynamic key, identity identifier, timestamp] triple in the encrypted string. In this way, the server can authenticate the sender based on the identity identifier obtained by decryption, and perform time verification through the timestamp obtained by decryption. For example, the server can obtain the sender's identity identifier to be verified, compare the identity identifier to be verified with the identity identifier obtained by decryption, and when the two match, it is determined that the identity authentication is passed; when the two do not match, it is determined that the identity authentication is failed. It can also obtain the generation time of the ciphertext and determine whether the generation time is within the valid time range indicated by the timestamp. When the generation time is within the valid time range indicated by the timestamp, it is determined that the timestamp verification is passed; when the generation time is not within the valid time range indicated by the timestamp, it is determined that the timestamp verification is failed.

[0225] Furthermore, when both the identity and timestamp are verified, indicating that both identity verification and time verification have passed, the ciphertext can be decrypted using the dynamic key to obtain the decrypted data (i.e., plaintext), achieving secure communication and effectively protecting the integrity and security of the data from the mini-program to the server, preventing attackers from decrypting and cracking the data. This eliminates the need for the server to store the identity and dynamic key; it can simply decrypt the encrypted string to obtain the identity and dynamic key, thus saving server storage resources.

[0226] In some embodiments, in order to prevent identity tampering attacks and replay attacks, identity verification and time verification are required before decrypting the ciphertext. That is, when the identity identifier and the timestamp verification are passed, the ciphertext is decrypted according to the dynamic key to obtain the decrypted data, including:

[0227] Obtain the current identity of the applet that sent the ciphertext and the encrypted string, as well as the time when the ciphertext was generated;

[0228] Get the valid end time indicated by the timestamp;

[0229] When it is detected that the identity identifier matches the current identity identifier and the generation time is before the valid expiration time, the ciphertext is decrypted according to the dynamic key to obtain decrypted data.

[0230] It should be noted that an identity tampering attack refers to an attacker intercepting data sent by a mini-program through the universal transport layer security protocol and sending data as the attacker's client to attack. A replay attack refers to a type of attack in which the attacker does not need to decrypt the actual data packet, but records the data request itself and replays the data request after a period of time.

[0231] In order to prevent the above-mentioned identity tampering attacks and replay attacks, the embodiment of the present application will perform identity verification and time verification. Specifically, the server can obtain the current identity of the applet that sends the ciphertext and encryption string and the generation time of the ciphertext.

[0232] Furthermore, the current identity identifier and the decrypted identity identifier can be compared. When the two are the same, it is determined that the identity identifier and the current identity identifier match. When the two are different, it is determined that the identity identifier and the current identity identifier do not match, and the identity has been tampered with. Accordingly, the effective expiration time of the dynamic key can also be determined based on the expiration time in the timestamp. Check whether the generation time is before the effective expiration time. When it is detected that the generation time is before the effective expiration time, it means that the time verification is passed. When it is detected that the generation time is not before the effective expiration time, it means that the time verification fails, and it is a replay attack. Based on this, when it is detected that the identity identifier and the current identity identifier match and the generation time is before the effective expiration time, that is, when the identity authentication and time verification are passed at the same time, the ciphertext is decrypted according to the dynamic key to obtain the decrypted data. In this way, identity tampering attacks and replay attacks can be prevented, and the security of data transmission can be better protected.

[0233] In some embodiments, the mini-program may encrypt data using the AES encryption algorithm and the CBC (Cipher Block Chaining) mode with a dynamic key. Therefore, the server-side decrypts the ciphertext using the dynamic key and also needs to decrypt the encrypted initialization vector. That is, the ciphertext is decrypted using the dynamic key to obtain the decrypted data, including:

[0234] Receive the encryption initialization vector sent by the applet;

[0235] The ciphertext is decrypted according to the dynamic key to obtain a first decryption result, and the first decryption result and the encryption initialization vector are XORed to obtain decrypted data.

[0236] Specifically, the server can also receive the encryption initialization vector sent by the mini-program, group the ciphertext in such a way that each group size is 128 bits (i.e., 16 bytes), and obtain multiple ciphertext sub-groups. For the first ciphertext sub-group, decrypt it using the dynamic key to obtain a first decryption result, and perform an XOR operation on the first decryption result with the encryption initialization vector to obtain the sub-plaintext corresponding to the first ciphertext sub-group. For the second ciphertext sub-group, decrypt it using the dynamic key to obtain a second decryption result, and perform an XOR operation on the sub-ciphertext of the previous ciphertext sub-group (i.e., the first ciphertext sub-group) with the second decryption result to obtain the sub-plaintext corresponding to the second ciphertext sub-group. For the third ciphertext sub-group, decrypt it using the dynamic key to obtain a third decryption result, and perform an XOR operation on the sub-ciphertext of the previous ciphertext sub-group (i.e., the second ciphertext sub-group) with the third decryption result to obtain the sub-plaintext corresponding to the third ciphertext sub-group. And so on, the sub-plaintext of each ciphertext sub-group can be obtained.

[0237] Correspondingly, the sub-plaintexts of each ciphertext subgroup can be concatenated to obtain the decrypted data.

[0238] To better illustrate the embodiments of this application, please refer to Figure 11 for further understanding. Figure 11 is an interactive diagram of the data transmission method provided in the embodiments of this application. During the handshake phase, the server can generate a dynamic key based on the handshake request and symmetrically encrypt the dynamic key identity and timestamp using a preset key to generate a corresponding encrypted string. The dynamic key and encrypted string are then sent to the mini-program via a dedicated transport layer security protocol.

[0239] During the encryption stage, the applet can symmetrically encrypt the data (i.e., plaintext) based on the encryption initial vector and dynamic key to obtain the corresponding ciphertext, and send the encryption initial vector, ciphertext, and encrypted string to the server through the universal transport layer security protocol.

[0240] During the decryption phase, the server decrypts the encrypted string using a preset key, recovering the dynamic key, identity, and timestamp. After the identity and timestamp are verified, the server decrypts the ciphertext using the dynamic key combined with the encryption initial vector to obtain the decrypted data. In this way, the dynamic key is transmitted through a dedicated transport layer with higher security than the general transport layer security protocol, and the encrypted string obtained by encryption based on the dynamic key is used to encrypt the data to be sent using the dynamic key to generate the corresponding ciphertext. The ciphertext and the encrypted string are sent to the server through the general transport layer security protocol, so that the server decrypts the ciphertext based on the dynamic key recovered by decrypting the encrypted string to obtain the decrypted data. Compared with the solution of implementing symmetric encryption through static keys in the related art, the embodiment of the present application can receive the dynamic key through a more secure dedicated transport layer security protocol, ensuring that the dynamic key is not intercepted by attackers, and sending the dynamic key to the server through the general transport layer security protocol in the form of an encrypted string, avoiding the dynamic key from being transmitted in plain text, effectively preventing the dynamic key from being cracked, and improving the security of data transmission.

[0241] To better illustrate the embodiments of the present application, please refer to Figure 12 for further understanding. Figure 12 is an interactive flow chart of the data transmission method provided in the embodiments of the present application. Referring to Figure 12, the specific interactive process of the data transmission method provided in the embodiments of the present application is described in detail. This process includes but is not limited to steps 601 through 613.

[0242] In step 601 , the applet of the terminal 140 sends a handshake request to the server 110 via a dedicated transport layer security protocol between the applet and the server.

[0243] In step 602, the server 110 receives a handshake request sent by the applet via a dedicated transport layer security protocol, and generates a random dynamic key according to the handshake request.

[0244] In step 603, the server 110 searches a preset mapping table according to the scenario type to determine the corresponding validity period of the dynamic key.

[0245] In step 604 , the server 110 determines a timestamp of the dynamic key based on the validity time.

[0246] In step 605 , the server 110 obtains the identity of the mini-program and encrypts the dynamic key, the identity and the timestamp according to a preset key to obtain an initial encrypted string.

[0247] In step 606 , the server 110 performs encoding conversion on the initial encrypted string using a preset number of printable characters to obtain a corresponding encrypted string.

[0248] In step 607, the server 110 returns the dynamic key, the corresponding validity period of the dynamic key, and the encrypted string to the applet of the terminal 140 via a dedicated transport layer security protocol.

[0249] In step 608, the applet on the terminal 140 receives the dynamic key, the corresponding validity period of the dynamic key, and the encrypted string returned by the server through a dedicated transport layer security protocol.

[0250] In step 609 , the applet on the terminal 140 obtains the data to be sent, generates a random number, generates a message sequence number of the data according to the order in which the data is generated, combines the random number and the message sequence number, and generates a corresponding encryption initialization vector.

[0251] In step 610, the mini-program on the terminal 140 divides the data into multiple data groups. For the first data group, the encryption initial vector is XORed with the first data group to obtain a first XOR result of the first data group. The first XOR result is encrypted by the dynamic key to obtain the sub-ciphertext corresponding to the first data group. For other data groups, the sub-ciphertext corresponding to the previous data group of the other data groups is XORed with the other data groups to obtain a second XOR result of the other data groups. The second XOR result is encrypted by the dynamic key to obtain the sub-ciphertext corresponding to the other data groups. The sub-ciphertexts corresponding to the multiple data groups are combined into a ciphertext.

[0252] In step 611 , the applet on the terminal 140 sends the encryption initialization vector, ciphertext, and encrypted string to the server 110 via the universal transport layer security protocol.

[0253] In step 612 , the server 110 receives the encrypted ciphertext, encryption initialization vector, and encryption string sent by the applet via the universal transport layer security protocol.

[0254] In step 613, the server 110 decrypts the encrypted string using the preset key, recovers the dynamic key, identity and timestamp, and when the identity and timestamp are verified, decrypts the ciphertext based on the dynamic key and the encryption initialization vector to obtain the decrypted data.

[0255] The meanings of the terms are the same as those in the above-mentioned data transmission method. For specific implementation details, please refer to the description in the method embodiment and will not be repeated here.

[0256] To facilitate better implementation of the data transmission method provided in the embodiment of the present application, the embodiment of the present application also provides a device based on the above data transmission method. The meanings of the terms are the same as those in the above data transmission method, and the specific implementation details can be referred to the description in the method embodiment.

[0257] Please refer to Figure 13, which is a structural diagram of the data transmission device provided in an embodiment of the present application. The data transmission device is applied to a terminal, wherein the data transmission device may include a first sending unit 701, a first receiving unit 702, an encryption unit 703 and a second sending unit 704, etc.

[0258] The first sending unit 701 is configured to send a handshake request to the server via a dedicated transport layer security protocol between the applet and the server. The dedicated transport layer security protocol has higher security than the general transport layer security protocol.

[0259] The first receiving unit 702 is configured to receive, through the dedicated transport layer security protocol, the dynamic key returned by the server according to the handshake request and an encrypted string obtained according to the dynamic key.

[0260] The encryption unit 703 is used to obtain data to be sent and encrypt the data using the dynamic key to obtain ciphertext.

[0261] The second sending unit 704 is used to send the ciphertext and the encrypted string to the server through the universal transport layer security protocol, so that the server decrypts the encrypted string to obtain a dynamic key, and decrypts the ciphertext according to the dynamic key to obtain decrypted data.

[0262] The specific implementation of each of the above units can be found in the previous embodiments and will not be described again here.

[0263] Please refer to Figure 14, which is a structural diagram of the data transmission device provided in an embodiment of the present application. The data transmission device is applied to the terminal, wherein the data transmission device may include a first receiving unit 801, a generating unit 802, a returning unit 803, a second receiving unit 804 and a decryption unit 805, etc.

[0264] The first receiving unit 801 is configured to receive a handshake request sent by a mini-program via a dedicated transport layer security protocol, where the dedicated transport layer security protocol has higher security than the general transport layer security protocol.

[0265] The generating unit 802 is configured to generate a random dynamic key according to the handshake request, and obtain an encrypted string according to the dynamic key.

[0266] The returning unit 803 is used to return the dynamic key and the encrypted string to the applet through the dedicated transport layer security protocol, so that the applet encrypts the data to be sent according to the dynamic key to obtain a ciphertext.

[0267] The second receiving unit 804 is configured to receive the ciphertext and the encrypted string sent by the applet via the universal transport layer security protocol.

[0268] The decryption unit 805 is configured to decrypt the encrypted string to obtain the dynamic key, and decrypt the ciphertext based on the dynamic key to obtain decrypted data.

[0269] The specific implementation of each of the above units can be found in the previous embodiments and will not be described again here.

[0270] The embodiment of the present application further provides a computer device, which may be a terminal. FIG15 shows a schematic diagram of the structure of the terminal involved in the embodiment of the present application. Specifically:

[0271] The computer device may include components such as a radio frequency (RF) circuit 901, a memory 902 including one or more computer-readable storage media, an input unit 903, a display unit 904, a sensor 905, an audio circuit 906, a wireless fidelity (WiFi) module 907, a processor 908 including one or more processing cores, and a power supply 909. It will be understood by those skilled in the art that the terminal structure shown in FIG15 does not constitute a limitation on the terminal, and may include more or fewer components than shown, or combine certain components, or arrange the components differently. Among them:

[0272] The memory 902 can be used to store software programs and modules. The processor 908 executes various functional applications and information retrieval by running the software programs and modules stored in the memory 902. The memory 902 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area may store data created according to the use of the terminal (such as audio data, a phone book, etc.). In addition, the memory 902 may include a high-speed random access memory and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage device. Accordingly, the memory 902 may also include a memory controller to provide the processor 908 and the input unit 903 with access to the memory 902.

[0273] In this embodiment, the processor 908 in the terminal will load the executable files corresponding to the processes of one or more applications into the memory 902 according to the following instructions, and the processor 908 will run the applications stored in the memory 902, thereby implementing the methods provided in each embodiment of the present application.

[0274] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the detailed description of the file transmission method above, and will not be repeated here.

[0275] The present application also provides a computer device, which may be a server. FIG16 shows a schematic diagram of the structure of the server involved in the present application. Specifically:

[0276] The computer device may include components such as a processor 1010 with one or more processing cores, a memory 1020 with one or more computer-readable storage media, a power supply 1030, and an input unit 1040. Those skilled in the art will appreciate that the computer device structure shown in FIG16 does not limit the computer device, and may include more or fewer components than shown, or combine certain components, or arrange the components differently.

[0277] Although not shown, the computer device may further include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 1010 in the computer device will load the executable files corresponding to one or more application processes into the memory 1020 according to the following instructions, and the processor 1010 will run the application stored in the memory 1020, thereby implementing the various method steps provided in the aforementioned embodiments.

[0278] In the above embodiments, the description of each embodiment has its own focus. For the part that is not described in detail in a certain embodiment, please refer to the detailed description of the queue processing method above, which will not be repeated here.

[0279] Those skilled in the art will appreciate that all or part of the steps in the various methods of the above embodiments may be accomplished by instructions, or by controlling related hardware through instructions. The instructions may be stored in a computer-readable storage medium and loaded and executed by a processor.

[0280] To this end, an embodiment of the present application provides a computer-readable storage medium, which stores multiple instructions, and the instructions can be loaded by a processor to execute the steps in any data transmission method provided in the embodiment of the present application.

[0281] According to one aspect of the present application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various optional implementations provided in the above embodiments.

[0282] The specific implementation of the above operations can be found in the previous embodiments and will not be repeated here.

[0283] The computer-readable storage medium may include a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0284] Since the instructions stored in the computer-readable storage medium can execute the steps in any data transmission method provided in the embodiments of the present application, the beneficial effects that can be achieved by any data transmission method provided in the embodiments of the present application can be achieved. Please refer to the previous embodiments for details and will not be repeated here.

[0285] The above is a detailed introduction to a data transmission method, device, storage medium and equipment provided in the embodiments of the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core ideas. At the same time, for technical personnel in this field, based on the ideas of the present application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A data transmission method, executed by a terminal device, comprising: Sending a handshake request to the server through a dedicated transport layer security protocol between the applet running in the terminal device and the server, wherein the dedicated transport layer security protocol has higher security than the general transport layer security protocol; Receiving the dynamic key returned by the server and the encrypted string obtained according to the dynamic key through the dedicated transport layer security protocol; Acquire data to be sent, and encrypt the data using the dynamic key to obtain ciphertext; The ciphertext and the encrypted string are sent to the server through the universal transport layer security protocol, so that the server decrypts the encrypted string to obtain the dynamic key, and decrypts the ciphertext according to the dynamic key to obtain the decrypted data.

2. The data transmission method according to claim 1, wherein: The step of obtaining the data to be sent and encrypting the data by using the dynamic key to obtain a ciphertext includes: Acquire data to be sent, generate an encryption initialization vector for the data, and perform an XOR operation on the data according to the encryption initialization vector to obtain an XOR result; The XOR result is encrypted by the dynamic key to obtain the ciphertext.

3. The data transmission method according to claim 2, wherein: The step of generating an encryption initialization vector for the data comprises: Generate random numbers; generating a message sequence number for the data; The random number is combined with the message sequence number to generate the encryption initialization vector.

4. The data transmission method according to claim 3, wherein: The performing XOR on the data according to the encryption initial vector to obtain an XOR result includes: dividing the data into a plurality of data groups; For a first data packet, performing an XOR operation on the encryption initialization vector and the first data packet to obtain a first XOR result of the first data packet; For each data group in the other data groups, perform XOR on the sub-ciphertext of the previous data group of the data group and the data group to obtain a second XOR result of each data group in the other data groups; The step of encrypting the XOR result by using the dynamic key to obtain the ciphertext includes: Encrypting the first XOR result by using the dynamic key to obtain a sub-ciphertext of the first data packet; Encrypting the second XOR result of each data group in the other data groups by using the dynamic key to obtain a sub-ciphertext corresponding to each data group in the other data groups; The sub-ciphertexts corresponding to the multiple data groups are combined into a ciphertext.

5. The data transmission method according to any one of claims 2 to 4, further comprising: The encryption initialization vector is sent to the server through the universal transport layer security protocol, so that the server decrypts the ciphertext according to the dynamic key to obtain a first decryption result, and performs an XOR operation on the first decryption result and the encryption initialization vector to obtain the decrypted data.

6. The data transmission method according to any one of claims 1 to 5, wherein: The handshake request carries a scenario type; The method further comprises: Receiving the validity period of the dynamic key returned by the server through the dedicated transport layer security protocol; The effective time is determined by the server according to the scenario type carried in the handshake request.

7. The data transmission method according to claim 6, further comprising: Determine the effective expiration time of the dynamic key according to the effective time; When it is detected that the current time reaches the valid expiration time, the handshake request is sent to the server through the dedicated transport layer security protocol between the applet and the server again to re-receive the updated dynamic key, valid time and encryption string through the dedicated transport layer security protocol.

8. The data transmission method according to claim 6, further comprising: When a change in the scene type is detected, deleting the dynamic key, the validity period of the dynamic key, and the encrypted string obtained by encrypting the dynamic key; Re-execute sending a handshake request to the server through a dedicated transport layer security protocol between the applet and the server, so as to re-receive an updated dynamic key, valid time and encryption string through the dedicated transport layer security protocol.

9. The data transmission method according to any one of claims 1 to 5, wherein: The handshake request carries a scenario type and an application privacy level; The method further comprises: Receiving, through the dedicated transport layer security protocol, the validity time of the dynamic key returned by the server according to the handshake request; The validity period is determined by the server according to the scenario type and application privacy level carried in the handshake request.

10. The data transmission method according to any one of claims 1 to 9, wherein: The dedicated transport layer security protocol is the MMTLS protocol; the universal transport layer security protocol is the TLS protocol.

11. A data transmission method, executed by a server device, comprising: The handshake request sent by the receiving applet through the dedicated transport layer security protocol Has higher security than the general transport layer security protocol; Generate a random dynamic key according to the handshake request, and obtain an encrypted string according to the dynamic key; Returning the dynamic key and the encrypted string to the applet through the dedicated transport layer security protocol, so that the applet encrypts the data to be sent according to the dynamic key to obtain a ciphertext; receiving the ciphertext and the encrypted string sent by the applet through the universal transport layer security protocol; The encrypted string is decrypted to obtain the dynamic key, and the ciphertext is decrypted based on the dynamic key to obtain decrypted data.

12. The data transmission method according to claim 11, wherein: Generating a random dynamic key according to the handshake request, and obtaining the encrypted string according to the dynamic key, includes: Generate a random dynamic key according to the handshake request, and determine the validity period of the dynamic key; Determining a timestamp of the dynamic key based on the validity time; The user identity of the mini program is obtained, and the dynamic key, the user identity and the timestamp are encrypted to obtain the encrypted string.

13. The data transmission method according to claim 12, wherein: The step of encrypting the dynamic key, the identity identifier and the timestamp to obtain the encrypted string includes: Encrypting the dynamic key, identity identifier and timestamp according to a preset key to obtain an initial encrypted string; The initial encrypted string is converted into the encrypted string by using a preset number of printable characters.

14. The data transmission method according to claim 12 or 13, wherein: The handshake request carries a scenario type; Determining the validity period of the dynamic key includes: Determining the validity period of the dynamic key according to the first preset mapping table; The first preset mapping table includes mapping relationships between different scene types and effective times.

15. The data transmission method according to claim 12 or 13, wherein: The handshake request carries a scenario type and an application privacy level; Determining the validity period of the dynamic key includes: Determining the initial validity period of the dynamic key according to the second preset mapping table; Wherein, the second preset mapping table includes a mapping relationship between different scene types and initial effective time; A weight is determined according to the application privacy level, and the initial validity time is weighted based on the weight to obtain the validity time of the dynamic key.

16. The data transmission method according to any one of claims 12 to 15, further comprising: The valid time of the dynamic key is returned to the applet through a dedicated transport layer security protocol, so that the applet encrypts the data to be sent according to the dynamic key within the valid time.

17. The data transmission method according to any one of claims 12 to 16, further comprising: Decrypt the encrypted string received from the applet to obtain the identity identifier and timestamp; When the identity identifier and the timestamp are verified, an operation of decrypting the ciphertext according to the dynamic key is performed.

18. The data transmission method according to claim 17, wherein: The decrypting the ciphertext according to the dynamic key to obtain decrypted data includes: Receive the encryption initialization vector sent by the applet; The ciphertext is decrypted according to the dynamic key to obtain a first decryption result, and the first decryption result and the encryption initial vector are XORed to obtain the decrypted data.

19. A data transmission device, comprising: A first sending unit, configured to send a handshake request to the server through a dedicated transport layer security protocol between the applet and the server, wherein the dedicated transport layer security protocol has higher security than a general transport layer security protocol; A first receiving unit, configured to receive, through the dedicated transport layer security protocol, a dynamic key returned by the server according to the handshake request and an encrypted string obtained according to the dynamic key; An encryption unit, used for acquiring data to be sent, and encrypting the data by using the dynamic key to obtain a ciphertext; The second sending unit is used to send the ciphertext and the encrypted string to the server through the universal transport layer security protocol, so that the server decrypts the encrypted string to obtain the dynamic key, and decrypts the ciphertext according to the dynamic key to obtain decrypted data.

20. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a plurality of instructions, and the instructions are suitable for being loaded by a processor to execute the steps in the data transmission method according to any one of claims 1 to 18.

21. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the data transmission method according to any one of claims 1 to 18 are implemented.

22. A computer program product, comprising computer instructions, wherein the computer instructions are stored in a computer-readable storage medium, and when the computer instructions are executed, the steps in the data transmission method according to any one of claims 1 to 18 are implemented.

Images