Data transmission methods, devices, equipment, and computer programs

Abstract

Embodiments of the present invention disclose a data transmission method, apparatus, storage medium, and device that can be applied to various scenarios such as cloud technology, artificial intelligence, smart transportation, and driver assistance. An applet sends a handshake request to the server via a dedicated transmission layer security protocol between the applet and the server. The applet receives a dynamic key and an encryption string obtained in response to the handshake request from the server via the dedicated transmission layer security protocol, obtains the data to be transmitted, encrypts the data using the dynamic key to obtain ciphertext, and sends the ciphertext and encryption string to the server via a general-purpose transmission layer security protocol. The server then decrypts the encryption string to obtain the dynamic key, decrypts the ciphertext using the dynamic key, and obtains the decrypted data.

Description

[Technical Field]

[0001] The present application relates to the technical field of communications, and specifically relates to a data transmission method, apparatus, storage medium, and device.

[0002] The present application claims priority from the Chinese patent application filed with the China National Intellectual Property Administration on October 17, 2023, with the application number 202311348871.8 and the invention title "Data transmission method, apparatus, storage medium, and device", the entire content of which is incorporated into the present application by reference. [Background Art]

[0003] Hypertext Transfer Protocol Secure (HTTPS) is a type of transmission protocol that performs secure communication via a computer network. HTTPS communicates via HTTP, but encrypts data packets using Transport Layer Security (TLS). It is an HTTP channel targeting security, and ensures the security of the transmission process through transmission encryption and identity authentication on the basis of HTTP.

[0004] In the related art, TLS can encrypt data packets by adopting a symmetric encryption scheme, that is, the server transmits a static key to a client terminal via TLS, so that both the client terminal and the server share the same static key. A data transmitting party encrypts plaintext (i.e., raw data) with the static key through a special encryption algorithm, converts the plaintext into a complex ciphertext, and transmits the ciphertext to a data receiving party. After receiving the ciphertext, the data receiving party decrypts the ciphertext through the static key and an inverse algorithm of the special encryption algorithm to restore readable plaintext, thereby ensuring the security of data transmission. [Summary of Invention] [Means for Solving the Problem]

[0005] Embodiments of the present invention provide data transmission methods, apparatus, storage media, and devices that can improve the security of data transmission.

[0006] The embodiments of this application provide the following technical means.

[0007] A data transmission method, which is performed by terminal equipment. A step of sending a handshake request to a server using a dedicated transmission layer security protocol between an applet operating within a terminal device and the server, wherein the dedicated transmission layer security protocol has higher security than a general-purpose transmission layer security protocol. The steps include receiving a dynamic key returned by the server via the dedicated transmission layer security protocol, and an encryption string obtained in accordance with the dynamic key, The steps include obtaining data to be transmitted and encrypting the data using the dynamic key to obtain a ciphertext, The method includes the steps of: sending the ciphertext and the encryption string to a server using the general-purpose transmission layer security protocol, the server decrypting the encryption string to obtain the dynamic key, and decrypting the ciphertext according to the dynamic key to obtain the decrypted data.

[0008] A data transmission method, which is executed by server equipment. A step of receiving a handshake request transmitted by an applet using a dedicated transmission layer security protocol, wherein the dedicated transmission layer security protocol has higher security than a general-purpose transmission layer security protocol. The steps include generating a random dynamic key in response to the handshake request and obtaining an encryption string according to the dynamic key, The steps include: sending the dynamic key and the encryption string back to the applet using the dedicated transmission layer security protocol, thereby encrypting the data to be sent according to the dynamic key and obtaining a ciphertext; The applet receives the encrypted ciphertext and the encryption string transmitted by the general-purpose transmission layer security protocol, The process includes the steps of decrypting the encryption string to obtain the dynamic key, and decrypting the ciphertext based on the dynamic key to obtain the decrypted data.

[0009] A data transmission device, A first transmission unit used to send a handshake request to a server via a dedicated transmission layer security protocol between an applet and a server, wherein the dedicated transmission layer security protocol has higher security than a general-purpose transmission layer security protocol, and the first transmission unit A first receiving unit used to receive a dynamic key that the server replies to the handshake request using the dedicated transmission layer security protocol, and an encryption string obtained in accordance with the dynamic key, An encryption unit used to obtain data to be transmitted and to encrypt the data using the dynamic key to obtain ciphertext, The system includes a second transmission unit used to send the ciphertext and the encryption string to the server using the general-purpose transmission layer security protocol, so that the server can decrypt the encryption string to obtain the dynamic key and decrypt the ciphertext according to the dynamic key to obtain the decrypted data.

[0010] A data transmission device, A first receiving unit used to receive a handshake request transmitted by an applet using a dedicated transmission layer security protocol, wherein the dedicated transmission layer security protocol has higher security than a general-purpose transmission layer security protocol, and the first receiving unit A generation unit used to generate a random dynamic key in response to the handshake request and to obtain an encryption string according to the dynamic key, A reply unit used to encrypt the data to be sent by the applet according to the dynamic key and obtain ciphertext by sending back the dynamic key and the encryption string to the applet using the dedicated transmission layer security protocol, A second receiving unit used to receive the ciphertext and encryption string transmitted by the applet using the general-purpose transmission layer security protocol, The system includes a decryption unit used to decrypt the encryption string to obtain the dynamic key, and to decrypt the ciphertext based on the dynamic key to obtain the decrypted data.

[0011] A computer-readable storage medium, wherein a plurality of instructions are stored in the computer-readable storage medium, and the instructions are suitable for a processor to load and execute the steps of the data transmission method.

[0012] A computer device comprising memory, a processor, and a computer program stored in the memory and capable of running on the processor, wherein the processor implements the steps of the data transmission method when executing the computer program.

[0013] A computer program product or computer program, the computer program product or computer program, includes computer instructions, the computer instructions are stored in a storage medium. The processor of the computer device reads the computer instructions from the storage medium, and the processor executes the computer instructions to realize the steps of the data transmission method.

[0014] Other features and benefits of this disclosure are described in the specification below, and some are evident from the specification or understood by implementing this disclosure. The purposes and other benefits of this disclosure can be realized and obtained by the structures specifically described in the specification, claims, and drawings.

[0015] In order to describe the technical solutions of the embodiments of the present application more clearly, the following briefly introduces the drawings required for the description of the embodiments. Obviously, the drawings in the following description are merely some embodiments of the present application, and those skilled in the art can obtain other drawings according to these drawings without creative efforts. Brief Description of the Drawings

[0016] [Figure 1] It is a schematic diagram of a protocol structure of a data transmission method provided by some embodiments of the present application. [Figure 2] It is a schematic scene diagram of a data transmission system provided by some embodiments of the present application. [Figure 3] It is a schematic scene diagram of a login system provided by some embodiments of the present application. [Figure 4] It is a schematic scene diagram of a virtual resource payment system provided by some embodiments of the present application. [Figure 5] It is a schematic flow diagram of a data transmission method provided by some embodiments of the present application. [Figure 6] It is a schematic scene diagram of a data transmission method provided by some embodiments of the present application. [Figure 7] It is another specific flowchart of step 203 in FIG. 5. [Figure 8] It is another schematic scene diagram of a data transmission method provided by some embodiments of the present application. [Figure 9] It is a schematic flow diagram of a data transmission method provided by some embodiments of the present application. [Figure 10] It is another specific flowchart of step 405 in FIG. 9. [Figure 11] It is an interaction schematic diagram of a data transmission method provided by some embodiments of the present application. [Figure 12] It is an interaction flowchart of a data transmission method provided by some embodiments of the present application. [Figure 13]This is a schematic diagram of the structure of a data transmission device provided by several embodiments of the present invention. [Figure 14] This is a schematic diagram of the structure of a data transmission device provided by several embodiments of the present invention. [Figure 15] This is a schematic diagram of the structure of a terminal provided by several embodiments of the present invention. [Figure 16] This is a schematic diagram of the structure of a server provided by some embodiments of the present invention. [Modes for carrying out the invention]

[0017] For the purpose of enabling those skilled in the art to better understand the means of the present application, the technical means of the embodiments of the present application are described below in clear and complete terms, in conjunction with the drawings of the embodiments of the present application. It is clear that the embodiments described are merely some embodiments of the present application, not all embodiments. All other embodiments obtained by those skilled in the art without creative work based on the embodiments of the present application are all within the scope of protection of the present application.

[0018] To ensure understanding, in specific embodiments of the present invention, with regard to relevant data such as data to be encrypted, when applying the above embodiments of the present invention to a specific product or technology, it is necessary to obtain the relevant permission or consent, and the collection, use, and processing of the relevant data must comply with relevant laws, regulations, and standards.

[0019] Furthermore, when it is necessary to obtain related data such as data to be encrypted in the embodiments of this application, sole permission or consent for obtaining such related data will be obtained through methods such as a pop-up window or a jump to a confirmation page. After clearly obtaining sole permission or consent for obtaining such related data, the necessary related data such as data to be encrypted, which is used to operate the embodiments of this application properly, will be obtained.

[0020] As needs to be explained, some flows described in the specification, claims, and drawings above include multiple steps that appear in a specific order, but as can be clearly understood, these steps do not have to be performed in the order they appear herein, or they may be performed in parallel, and the step numbers are not used merely to distinguish each different step, and the numbers themselves do not represent any order of execution. Also, descriptions such as “first,” “second,” or “predetermined” in this specification are used to distinguish similar subjects, but do not have to be used to describe a specific order or sequence.

[0021] Before describing the embodiments of this disclosure in further detail, we will explain the nouns and terms that are relevant in the embodiments of this disclosure, and these nouns and terms that are relevant in the embodiments of this disclosure can be interpreted as follows.

[0022] The Transmission Control Protocol / Internet Protocol (TCP / IP) refers to a protocol cluster that enables information transmission between multiple different networks. The TCP / IP protocol doesn't simply refer to the two protocols TCP and IP, but rather to a single protocol cluster composed of protocols such as File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP), TCP, User Datagram Protocol (UDP), and Internet Protocol (IP). It's simply called the TCP / IP protocol because TCP and IP are the most representative components. Also known as a network communication protocol, it is the most fundamental communication protocol in network usage.

[0023] The Hypertext Transfer Protocol (HTTP) is an application layer protocol used in distributed, cooperative, and hypermedia information systems. It is a stateless application layer protocol based on a single request and response, and it implements data transmission based on the TCP / IP protocol. HTTP allows the transmission of any type of data object.

[0024] Applet: A type of application program that can be used on an instant messaging client terminal without downloading or installing.

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

[0026] A uniform resource locator (URL) is a notation used to specify the location of information within the World Wide Web Services program of the Internet, and can be understood as a web address to access.

[0027] The General-Purpose Transmission Layer Security Protocol (TLS) is used to provide confidentiality and data integrity between two communication application programs.

[0028] Managed Mode Transport Layer Security (MMTLS) is a type of transport layer secure protocol based on the TLS protocol, which uses the TLS protocol for encryption and authentication at the transport layer. Unlike the conventional TLS protocol, MMTLS employs a hosting mode, meaning it delegates some control over the TLS protocol to the application layer for management. The TLS protocol implemented in instant messaging client terminals provides confidentiality and data integrity between the instant messaging client terminal and the server.

[0029] As needs to be explained, MMTLS does not trust self-signed certificates, but only certificates provided by the instant messaging client terminal. Furthermore, because the entire MMTLS protocol is highly customizable, conventional packet capture tools cannot perform packet capture analysis. In other words, because MMTLS is customizable, conventional packet capture tools cannot capture the specific contents of MMTLS, and therefore, subsequent transmission of dynamic keys using MMTLS is secure.

[0030] To better understand MMTLS, please refer to Figure 1, which is a schematic diagram of the protocol structure of the data transmission method provided by the embodiment of the present invention, in which TCP / IP adopts a layered design mode and divides the protocol into four layers from top to bottom, as follows.

[0031] Application Layer A: Application Layer A is the highest layer protocol in the TCP / IP protocol suite. It provides communication services between object ports and application programs. For example, HTTP is an application layer protocol, as are other protocols such as FTP and SMTP. Application layer protocols are protocols that directly interact with objects. They process specific types of data and pass it on to lower-layer protocols for further processing.

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

[0033] Network Layer C: Network Layer C primarily provides data packet transmission services within a network, such as the IP protocol. Network layer protocols are responsible for transmitting data packets from a source host computer to a target host computer and facilitating data transmission between different networks through technologies such as routing selection and forwarding.

[0034] Link Layer D: Link Layer D refers to the transmission of data over the physical layer, and examples include protocols such as Ethernet and Wi-Fi. Link layer protocols are responsible for transmitting data from the network layer to the physical layer and then transmitting it to the receiving host computer via the physical layer.

[0035] The physical layer (not shown) is responsible for the transmission of bitstreams between nodes, that is, for physical transmission. The protocol of this layer is related not only to the links but also to the medium through which the data is transmitted. Simply put, it is the physical means of connecting computers.

[0036] Here, MMTLS is located between the application layer and the network layer, does not affect existing network strategies, and is implemented based on TCP.

[0037] The handshake protocol, as its name suggests, involves negotiating the suite of encryption algorithms and encryption keys to be used before encrypted communication begins. This is similar to the customary practice of two strangers shaking hands before starting a chat.

[0038] In computer network communication scenarios, communication is generally performed using HTTPS, and the basis of HTTPS is simply HTTP communication, which encrypts data packets using a general-purpose transmission layer security protocol.

[0039] In related technologies, TLS employs a symmetric encryption method to encrypt data packets. Specifically, the server sends a static key to the client terminal via TLS, ensuring that both the client terminal and the server share the same static key. The data transmission side encrypts the plaintext with the static key using a special encryption algorithm, converting the plaintext into complex ciphertext, which is then sent to the data receiver. After receiving the ciphertext, the data receiver decrypts it using the static key and the reverse algorithm of the special encryption algorithm, restoring it to readable plaintext, thereby guaranteeing the security of data transmission.

[0040] However, the static keys used in such data transmission methods are transmitted directly via TLS, making them highly susceptible to analysis and decryption. Attackers can obtain them through various attack methods, and because the static keys are fixed, once an attacker successfully obtains them, all ciphertexts can be easily decrypted, leading to data breaches.

[0041] An embodiment of the present invention proposes a method to solve the above problem by transmitting a dynamic key and an encrypted string obtained by encrypting the dynamic key using a dedicated transmission layer security protocol with higher security, encrypting the data to be transmitted using the dynamic key to generate a corresponding ciphertext, and sending the ciphertext and encrypted string to the server using a general-purpose transmission layer security protocol, so that the server decrypts according to the encrypted string to obtain the dynamic key and decrypts the ciphertext to obtain the decrypted data. This method ensures that the dynamic key cannot be intercepted by an attacker, and by sending the dynamic key to the server using a general-purpose transmission layer security protocol in the form of an encrypted string, the transmission of the dynamic key in plaintext is avoided, effectively preventing the dynamic key from being deciphered and improving the security of data transmission.

[0042] As continued to be referenced in Figure 2, Figure 2 is a schematic scene diagram of a data transmission system provided by several embodiments of the present application, including a terminal 140, an internet 130, a gateway 120, and a server 110, etc.

[0043] Terminal 140 includes, but is not limited to, mobile phones, computers, smart voice interaction devices, smart home appliances, in-vehicle terminals, and aircraft. The embodiments of this application can be applied to various scenarios and include, but are not limited to, cloud technology, artificial intelligence, smart transportation, and driver assistance. Furthermore, it may be a single device or a collection of multiple devices. For example, multiple desktop computers may be interconnected by a local area network, share a single display, and perform collaborative work to jointly constitute one terminal 140. Terminal 140 may communicate with the Internet 130 by wired or wireless means and exchange data.

[0044] Server 110 refers to a computer system that can provide several services to terminal 140. Compared to a regular terminal 140, server 110 is required to have higher requirements in terms of stability, security, and performance. Server 110 may be an independent physical server, a server cluster composed of multiple physical servers, or a distributed system. Furthermore, it may be 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, secure services, CDNs, and big data and artificial intelligence platforms.

[0045] Gateway 120 is also referred to as a network connector and protocol converter. A gateway is a type of computer system or device that enables network interconnection at the transmission layer and performs a conversion role. Between two systems that use different communication protocols, data formats, or languages, and thus have completely different system structures, the gateway acts as a translator. At the same time, the gateway can further provide filtering and security functions. Messages that terminal 140 sends to server 110 must be forwarded to the corresponding server 110 by gateway 120. Messages that server 110 sends to terminal 140 must also be forwarded to the corresponding terminal 140 by gateway 120.

[0046] The embodiments of this invention can be applied to multiple types of scenarios, such as the login system scene shown in Figure 3 and the virtual resource payment system scene shown in Figure 4.

[0047] (1) Login system scene The login system implements login functionality and completes login-related services. As shown in Figure 3, the terminal's login system interface 11 allows users to log in by entering an account and password. This interface 11 may also be the applet's interface. When the login system interface 11 is opened and displayed, the terminal generates a handshake request and sends it to the server via a dedicated transmission layer security protocol between the applet and the server. This dedicated transmission layer security protocol has higher security than a general-purpose transmission layer security protocol. The dedicated transmission layer security protocol allows the terminal to receive a dynamic key that the server replies to the handshake request, and an encrypted string obtained by performing encryption processing based on the dynamic key. The terminal then obtains the data to be sent (which can be understood as login account data and password data), encrypts the data using the dynamic key to generate ciphertext, and sends the ciphertext and encrypted string to the server via the general-purpose transmission layer security protocol. The server then decrypts the encrypted string to obtain the dynamic key, and decrypts the ciphertext according to the dynamic key to obtain the decrypted data.

[0048] (ii) Virtual Resource Payment System Scene The virtual resource payment system can implement payment functionality and complete payment-related services. As shown in Figure 4, the interface 12 of the virtual resource payment system on the terminal allows the user to enter virtual resources such as 1000, which are the items to be paid for, and a payment password such as 123456. The user then clicks the order button to implement the payment functionality. This interface 12 may also be the interface on the applet side. When the virtual resource payment system interface 12 is opened and displayed, the terminal generates a handshake request and sends the handshake request to the server via a dedicated transmission layer security protocol between the applet and the server. The dedicated transmission layer security protocol has higher security than the general-purpose transmission layer security protocol. The dedicated transmission layer security protocol receives a dynamic key that the server replies to the handshake request, and an encrypted string obtained by performing an encryption process based on the dynamic key. The data to be transmitted (which can be understood as virtual resource data to be paid and payment password data) is obtained, and the data is encrypted using the dynamic key to generate ciphertext. The general-purpose transmission layer security protocol sends the ciphertext and the encrypted string to the server, where 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.

[0049] As needs to be explained, the schematic diagram of the data transmission system shown in Figure 2 is merely one example, and the data transmission system and scenes described in the embodiments of the present application are intended to more clearly illustrate the technical means of the embodiments of the present application and do not constitute a limitation on the technical means provided by the embodiments of the present application. As those skilled in the art will see, with the evolution of data transmission systems and the emergence of new business scenarios, the technical means provided by the embodiments of the present application can be similarly applied to similar technical problems.

[0050] In this embodiment, the description will be made from the perspective of a data transmission device, which may be integrated into a computer device that has a storage unit and a microprocessor and has computing power, and the computer device may be a terminal, an instant messaging client terminal may be installed on the terminal, and an applet may be run on the instant messaging client terminal, and in this embodiment, an applet that runs on a terminal will be described. In some embodiments of the present application, the server that interacts with the terminal may be an instant messaging server.

[0051] As shown in Figure 5, Figure 5 is a schematic flowchart of a data transmission method provided by an embodiment of the present application. The data transmission method includes steps 201 to 204.

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

[0053] TLS employs a symmetric encryption method to encrypt data packets. Specifically, the server sends a static key to the client terminal via TLS, ensuring that both the client terminal and the server share the same static key. The data transmission side encrypts the plaintext with the static key using a special encryption algorithm, converting the plaintext into complex ciphertext, which is then sent to the data receiver. After receiving the ciphertext, the data receiver decrypts it using the static key and the reverse algorithm of the special encryption algorithm, restoring it to readable plaintext, thereby guaranteeing the security of data transmission.

[0054] However, the static keys used in such data transmission methods are transmitted directly via TLS, making them highly susceptible to analysis and decryption. Attackers can analyze and obtain them using various attack methods, and because the static keys are fixed, once an attacker successfully obtains them, all ciphertexts can be easily decrypted, leading to data leakage. Furthermore, TLS only provides security at the transmission layer; however, with advancements in packet capture and analysis tools, simply using TLS is no longer sufficient to counter packet capture and analysis tools based on self-signed certificates, leaving the system vulnerable to attacks.

[0055] As needs to be explained, the applet in the embodiment of the present application relies on an instant messaging client terminal, that is, the instant messaging client terminal can function as the operational container for the applet, the applet operates on the instant messaging client terminal, and therefore the applet can directly invoke the corresponding dedicated transmission layer security protocol of the instant messaging client terminal.

[0056] To solve the above problems and ensure the security of data transmission, an embodiment of the present invention allows a handshake request to be sent to the server by a dedicated transmission layer security protocol between the applet and the server, i.e., a dedicated transmission layer security protocol, the handshake request may include the applet identifier of the applet and the instant messaging client terminal version, so that the server can identify whether the handshake request is a transmission of a usable applet and instant messaging client terminal version based on the applet identifier and the instant messaging client terminal version.

[0057] Because the entire protocol of a dedicated transmission layer security protocol is highly customized, conventional packet capture tools cannot perform packet capture analysis. In other words, because the dedicated transmission layer security protocol is customized, conventional packet capture tools cannot capture the handshake request of the dedicated transmission layer security protocol, thus preventing attackers from monitoring the applet's handshake request, and therefore the dedicated transmission layer security protocol has higher security than a general-purpose transmission layer security protocol.

[0058] To better illustrate the embodiment of the present invention, as shown in conjunction with Figure 6, the applet on terminal 140 can ensure the privacy of the handshake request by sending the handshake request to the server via a dedicated transmission layer security protocol between the applet and the server.

[0059] In step 202, the server receives a dynamic key that it replies to in response to the handshake request, and an encrypted string obtained in accordance with the dynamic key, via a dedicated transmission layer security protocol.

[0060] Here, after the server receives a handshake request transmitted by the applet via a dedicated transmission layer security protocol, it can generate a random dynamic key in response to the handshake request. This dynamic key can be randomly generated by a secure random number generator on the server and may have a length of 128 or 256 bits, etc. Unlike related technologies, the embodiments of the present application generate different dynamic keys based on different handshake requests, meaning the dynamic keys change in real time, thereby making them more resistant to decryption by attackers.

[0061] As needs to be explained, because the transmission capacity of the dedicated transmission layer security protocol is limited, subsequent data transmission still needs to be done by the general-purpose transmission layer security protocol. To avoid the dynamic key being transmitted in plain text over the general-purpose transmission layer security protocol, the server can encrypt the dynamic key using configured encryption rules to obtain an appropriate encrypted string.

[0062] Furthermore, the server can return the dynamic key and the encryption string to the applet in the embodiment of the present invention via the dedicated transmission layer security protocol, thereby enabling the embodiment of the present invention to receive the dynamic key returned by the server and the encryption string obtained by encryption based on the dynamic key via the dedicated transmission layer security protocol, thereby enabling a handshake, that is, establishing a connection between the applet and the server. Accordingly, the entire protocol of the dedicated transmission layer security protocol is highly customized, so conventional packet capture tools cannot perform packet capture analysis. In other words, because the dedicated transmission layer security protocol is customized, conventional packet capture tools cannot capture the dynamic key and encryption string transmitted by the dedicated transmission layer security protocol, thus better guaranteeing the security of the dynamic key.

[0063] As shown in Figure 6, the server 110 generates a random dynamic key in response to a handshake request, and generates an encrypted string token based on the secret (i.e., the dynamic key) using the aes_encrypt(token, secret) function, and can transmit the dynamic key and the encrypted string containing the dynamic key to the applet on terminal 140 using a dedicated transmission layer security protocol, and the applet on terminal 140 can receive the dynamic key and the encrypted string containing the dynamic key.

[0064] In some embodiments, to better achieve data protection, it can be specified that each dynamic key has a corresponding validity period, that is, after the dynamic key has reached its validity period, the dynamic key becomes correspondingly invalid, the applet must resend the handshake request, and the dynamic key is periodically updated by the dedicated transmission layer security protocol by re-receiving the updated dynamic key and encryption string, thereby better evading attacker analysis, and the validity period can be manually set, for example, 15 minutes or 30 minutes.

[0065] In some embodiments, applets can be applied to different scenes, such as login scenes, order scenes, and information viewing scenes. The login scene represents the user logging into an account via the applet, the order scene represents the user placing an order for a product via the applet, and the information viewing scene represents the user viewing information via the applet. On the other hand, each scene has different security requirements; for example, the security required for the login scene is higher than that for the order scene, but the security required for the order scene is higher than that for the information viewing scene. Based on this, dynamic keys assigned in each scene are set to have different validity periods.

[0066] Based on this, the handshake request may have a corresponding scene type, which indicates the corresponding scene of the applet when generating the handshake request, and the scene type may include, but is not limited to, a login scene type, an order scene type, or an information browsing scene type. When an applet generates a handshake request in a login scene, the scene type of the handshake request is a login scene type. When an applet generates a handshake request in an order scene, the scene type of the handshake request is an order scene type. Accordingly, when an applet generates a handshake request in an information browsing scene, the scene type of the handshake request is an information browsing scene type.

[0067] Therefore, the above method The dedicated transmission layer security protocol further includes the step of receiving a corresponding validity period of the dynamic key that the server replies to in response to the handshake request, Here, the validity period is the time that the server determines depending on the scene type that the handshake request has.

[0068] Specifically, since the handshake request has a corresponding scene type, the server can determine a corresponding dynamic key and automatically match a corresponding validity period according to the scene type. The mapping relationship between scene types and validity periods is shown in Table 1, which is a predetermined mapping table containing different mapping relationships between scene types and validity periods. If we assume the scene type is a login scene type, we obtain that the validity period is 5 minutes. If we assume the scene type is an order scene type, we obtain that the validity period is 10 minutes. If we assume the scene type is an information browsing scene type, we obtain that the validity period is 30 minutes.

[0069] [Table 1]

[0070] Based on this, the server can return the dynamic key, the appropriate validity period of the dynamic key, and the encryption string to the applet using a dedicated transmission layer security protocol. In response, the applet can receive the dynamic key, the appropriate validity period of the dynamic key, and the encryption string obtained by performing encryption processing based on the dynamic key, which the server returns in response to the handshake request, using the dedicated transmission layer security protocol. This allows for flexible setting of the appropriate validity period of the dynamic key according to the security requirements of different scene types when the applet initiates the handshake request, thereby improving the flexibility of validity period settings.

[0071] In some embodiments, the application scene of the applet can change in real time, for example, switching from an order scene type to a login scene type. Since the requirements for the validity period of the dynamic key also differ when the scene changes, the applet needs to monitor the scene type change in real time after receiving the dynamic key, the corresponding validity period of the dynamic key, and the encryption string obtained by performing encryption processing based on the dynamic key, which the server replies to the handshake request via a dedicated transmission layer security protocol, thereby ensuring real-time updates of the dynamic key. Specifically, this includes the following methods:

[0072] When a change in the scene type is detected, the dynamic key, the corresponding validity period of the dynamic key, and the encryption string obtained by performing encryption processing based on the dynamic key are deleted. By re-executing the step of sending a handshake request to the server via a dedicated transmission layer security protocol between the applet and the server, the applet receives the updated dynamic key, validity period, and encryption string again via the same dedicated transmission layer security protocol.

[0073] Specifically, the applet must be able to continuously detect whether or not the scene type is changing, and when a change in scene type is detected, it must indicate that the scene has changed and delete the currently stored dynamic key, the appropriate validity period of the dynamic key, and the encryption string obtained by performing encryption processing based on the dynamic key.

[0074] Furthermore, to achieve better security, dynamic keys need to be updated. Therefore, by re-executing the above embodiment, the updated dynamic key, validity period, and encryption string can be re-received in the changed scene type. This ensures that the dynamic key can change in real time in response to changes in the applet's application scene, thereby improving the flexibility of dynamic key updates.

[0075] In some embodiments, the applet can be applied to different scenes, such as a login scene, an order scene, and an information viewing scene, where the login scene represents the user logging into an account via the applet, the order scene represents the user placing an order for a product via the applet, and the information viewing scene represents the user viewing information via the applet. On the other hand, each scene has different security requirements; for example, the security required for the login scene is higher than that for the order scene, but the security required for the order scene is higher than that for the information viewing scene.

[0076] At the same time, there are various types of applets, such as office-type applets, game-type applets, and lifestyle-type applets. Each type of applet has different security requirements. For example, the security required for office-type applets is higher than that for lifestyle-type applets, and vice versa. Based on this, different effective timeframes can be flexibly set in combination with the application scenario and type of applet.

[0077] Based on this, the handshake request may simultaneously include a scene type and an application privacy level, the scene type indicating the corresponding scene of the applet when generating the handshake request, and the scene type may include, but is not limited to, a login scene type, an order scene type, or an information browsing scene type. When an applet generates a handshake request in a login scene, the scene type included in the handshake request is a login scene type. When an applet generates a handshake request in an order scene, the scene type included in the handshake request is an order scene type. Accordingly, when an applet generates a handshake request in an information browsing scene, the scene type included in the handshake request is an information browsing scene type.

[0078] The application privacy level indicates the appropriate privacy level for the type of applet when generating a handshake request, and includes, but is not limited to, three levels: high, medium, and low. This allows setting the application privacy level to high for office-type applets, medium for lifestyle-type applets, and low for game-type applets. For example, if an applet is of office type and generates a handshake request, the application privacy level of that handshake request is high. If an applet is of lifestyle type and generates a handshake request, the application privacy level of that handshake request is medium. If an applet is of game type and generates a handshake request, the application privacy level of that handshake request is low.

[0079] Therefore, the above method The dedicated transmission layer security protocol may include the step of receiving a corresponding validity period for the dynamic key that the server replies to in response to the handshake request. Here, the validity period is the time that the server determines based on both the scene type and the application privacy level of the handshake request.

[0080] Specifically, since the handshake request may include both a scene type and an application privacy level, the server can determine a corresponding dynamic key and, at the same time, match it with Table 1 (i.e., a predetermined mapping table) according to the scene type to determine the corresponding initial validity period of the dynamic key. If the scene type included in the handshake request is the ordered scene type, the server can determine that the corresponding initial validity period of the dynamic key is 10 minutes.

[0081] Furthermore, the server can automatically match weights according to the application privacy level. The mapping relationship between application privacy level and weight is shown in Table 2. Assuming a high application privacy level, the weight is 0.6. Assuming a medium application privacy level, the weight is 0.8. Assuming a low application privacy level, the weight is 1. In other words, the higher the application privacy level, the lower the weight, and the lower the application privacy level, the higher the weight.

[0082] [Table 2]

[0083] Based on the matching weights in Table 2, the initial validity period obtained from a previous match is weighted to obtain the final validity period of the dynamic key. Assuming the application privacy level of the handshake request is medium, the initial validity period of 10 minutes is weighted according to the weight of 0.8 obtained from the match, resulting in a final validity period of 8 minutes.

[0084] Based on this, the server can return the dynamic key, the appropriate validity period of the dynamic key, and the encryption string to the applet using a dedicated transmission layer security protocol. In response, the applet can receive the dynamic key, the appropriate validity period of the dynamic key, and the encryption string obtained by performing encryption processing based on the dynamic key, which the server returns in response to the handshake request, using the dedicated transmission layer security protocol. This allows for flexible setting of the appropriate validity period of the dynamic key, taking into account the security requirements of different scene types and applet types when the applet initiates the handshake request, further improving the flexibility of validity period settings.

[0085] In some embodiments, the applet needs to monitor the validity period of the dynamic key in real time after it has received the dynamic key, the corresponding validity period of the dynamic key, and the encryption string obtained by performing an encryption process based on the dynamic key, via a dedicated transmission layer security protocol, and to ensure real-time updates of the dynamic key, and specifically includes the following methods.

[0086] An appropriate termination time is determined according to the effective period. When it is detected that the current time has reached the effective termination time, the applet and the server re-execute the step of sending a handshake request to the server via the dedicated transmission layer security protocol between the applet and the server, thereby receiving the updated dynamic key, effective time, and encryption string again via the dedicated transmission layer security protocol.

[0087] Specifically, the server can also simultaneously send the dynamic key generation time to the applet, allowing the applet to calculate the expiration time based on the dynamic key generation time and validity period. For example, if the dynamic key generation time is 11:51:00 on October 8, 2023, the validity period is 8 minutes, and in this case, the expiration time is 11:59:00 on October 8, 2023.

[0088] This allows the applet to continuously detect whether the current time is approaching the expiration time. When it is detected that the current time is not approaching the expiration time, it indicates that the dynamic key is still valid. Conversely, when it is detected that the current time is approaching the expiration time, it indicates that the dynamic key has expired. To better achieve security, the dynamic key needs to be updated. Therefore, by re-executing the above embodiment, the updated dynamic key, expiration time, and encryption string can be re-received. This ensures that the dynamic key can be periodically updated according to the expiration time, increasing the variability of the dynamic key and increasing the difficulty of decryption.

[0089] In some embodiments, after generating a dynamic key and obtaining the validity period of the dynamic key, the server may determine a timestamp of the dynamic key according to the validity period, the timestamp may include the issue time (iat) and the expiration time (exp) 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, the expiration time is 11:59:00 on October 8, 2023. Then, the identity identifier of the applet is obtained, and this identity identifier may be the account identifier used to log in to the instant messaging client on which the applet depends, for example, account identifier 12345. Furthermore, a triplet of "dynamic key, identity identifier, timestamp" is obtained, and symmetric encryption is performed on this "dynamic key, identity identifier, timestamp" based on a predetermined key to obtain a corresponding encrypted string. This allows the dynamic key to be transmitted in the form of an encrypted string in a subsequent general-purpose transmission layer security protocol, avoiding the transmission of the dynamic key in plaintext and improving the security of dynamic key transmission.

[0090] As needs to be explained, the symmetric encryption process may be the AES (Advanced Encryption Standard) encryption algorithm, which can encrypt and decrypt data using a 128-bit, 192-bit, or 256-bit key, and has advantages such as high strength, high speed, and ease of implementation. The predetermined key is a 128-bit, 192-bit, or 256-bit key used for encryption, and unlike symmetric encryption in related technologies, the predetermined key does not need to be transmitted to the terminal but only needs to be stored internally on the server, thus preventing leakage of the predetermined key.

[0091] In step 203, the data to be transmitted is obtained, and the data is encrypted using a dynamic key to generate an appropriate ciphertext.

[0092] Here, the data to be transmitted is plaintext, data that the applet needs to send to the server, which may be an account password for logging in or a password used for payment. This data is highly sensitive to the target, and if transmitted directly in plaintext, it is very easy for an attacker to intercept and analyze it, allowing the target's sensitive data to be easily obtained, resulting in financial loss and data breaches.

[0093] To solve the above problem, the embodiment of the present invention can perform symmetric encryption on the data using a dynamic key received by a dedicated transmission layer security protocol, thereby generating a suitable ciphertext. As a result, even if an attacker intercepts the ciphertext, they cannot decrypt it because they do not have the dynamic key, thus avoiding economic loss and data leakage to the target.

[0094] In some embodiments, data can be encrypted using a dynamic key based on the AES encryption algorithm and using CBC (Cipher Block Chaining) mode, i.e., as shown in Figure 7, step 203 includes steps 301-302.

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

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

[0097] As needs to be explained, the full name of CBC is Cipher Block Chaining mode, where "block" refers to the fact that both the encryption and decryption processes are performed in block form. Each block is 128 bits (16 bytes) in size, and if the length of the plaintext is not an integer multiple of 16 bytes, the last block must be padded to make the length of the last block 16 bytes. "Chaining" refers to connecting the ciphertext blocks together like a chain. In this CBC mode, one initialization vector IV (which is the encryption initialization vector in the embodiment of this application) is required, and therefore, the data to be transmitted (i.e., plaintext) is obtained and the encryption initialization vector is generated, which may be obtained by an applet randomly generating a single number and converting that number into the encryption initialization vector, and one-hot encoding can be used as the conversion method, and for one-hot encoding, for sequence data having discrete values, one-hot encoding can be used to represent each value in a single vector.

[0098] In some embodiments, the step of generating a corresponding encryption initial vector for the data is: The steps for generating random numbers, The steps include generating a message sequence number for the data, The process may further include the step of combining the random number and the message sequence number to generate a corresponding encryption initial vector.

[0099] Specifically, it can generate a random number Nonce, for example 20 or 30, and a message sequence number Seq, for example 1, 2, or 3, for the generated data, depending on the data generation order. Accordingly, Nonce + Seq can be combined and a suitable encryption initialization vector can be generated by one-hot encoding. Since both the random number and the message sequence number change dynamically, the encryption initialization vector also changes continuously, ensuring that even if the same plaintext is encrypted multiple times subsequently, the resulting ciphertext will be different, thereby increasing the difficulty for an attacker to decrypt it.

[0100] Accordingly, after obtaining the initial encryption vector, it is possible to encrypt the data in CBC mode by combining it with a dynamic key to obtain the final ciphertext. Specifically, step 301 is: The steps include dividing the data into multiple data blocks, The steps include: performing an XOR operation on the first data block with the encryption initialization vector and the first data block to obtain the first XOR result of the first data block; The process includes the step of performing an XOR operation on each of the other data blocks with the subciphertext of the preceding data block to obtain the second XOR result for each of the other data blocks.

[0101] Step 302 is, The steps include: encrypting the first XOR result with the dynamic key to obtain a subciphertext corresponding to the first data block; The steps include: encrypting the second XOR result of each of the other data blocks using the dynamic key described above, and obtaining a subciphertext corresponding to each of the other data blocks described above; The process includes the step of constructing a ciphertext with subciphertexts corresponding to multiple data blocks.

[0102] Specifically, the data can be divided into blocks according to a scheme in which each block is 128 bits (i.e., 16 bytes) in size. As needs to be explained, if the length of the plaintext is not an integer multiple of 16 bytes, the last block will be padded, and the length of the last block will also be 16 bytes. To better illustrate the embodiment of the present invention, the data can be divided into multiple data blocks according to the fact that each block is 16 bytes in size, as shown in conjunction with Figure 8.

[0103] As needs to be explained, XOR, short for exclusive OR in English, is a mathematical operator. It is applied to logical operations. The mathematical symbol for XOR is:

number

number

[0104] For the first data block, an XOR operation is performed between the encryption initialization vector and the first data block to obtain the first XOR result of the first data block. This first XOR result is then input into the block password encryption module, and encryption is performed by combining it with the dynamic key to obtain a subciphertext corresponding to the first data block.

[0105] On the other hand, for any other data block, you can perform an XOR operation on the subciphertext corresponding to the previous data block and the other data block to obtain the second XOR result of the other data block.

[0106] Furthermore, the second XOR result can be input into the block password encryption module and encrypted by combining it with a dynamic key to obtain the subciphertexts of the other data blocks. For example, for the second data block, the second XOR result can be obtained by performing an XOR operation on the second data block and the subciphertext corresponding to the first data block. This corresponding second XOR result can then be input into the block password encryption module and encrypted by combining it with a dynamic key to obtain the subciphertext of the second data block. Similarly, for the third data block, the second XOR result can be obtained by performing an XOR operation on the third data block and the subciphertext corresponding to the second data block. This corresponding second XOR result can then be input into the block password encryption module and encrypted by combining it with a dynamic key to obtain the subciphertext of the third data block. By analogy, the subciphertexts of each of the other data blocks can be obtained.

[0107] Accordingly, the final ciphertext can be obtained by concatenating the sub-ciphertexts corresponding to each data block.

[0108] In step 204, the ciphertext and encryption string are sent to the server using a general-purpose transmission layer security protocol.

[0109] Here, because the transmission capacity of the dedicated transmission layer security protocol is limited, the transmission of ciphertext and encrypted strings must be done by a general-purpose transmission layer security protocol; that is, the applet can send ciphertext and encrypted strings to the server using a general-purpose transmission layer security protocol.

[0110] Since the ciphertext is obtained by encrypting it with a dynamic key, and the encrypted string is obtained by encrypting it with a predetermined key, neither the dynamic key nor the data is transmitted in plaintext form over a general-purpose transmission layer security protocol. Furthermore, the dynamic key is transmitted securely by a dedicated transmission layer security protocol, while the predetermined key exists only on the server. Therefore, even if an attacker intercepts the ciphertext and encrypted string, they cannot perform appropriate decryption, thereby protecting data security and improving the security of data transmission.

[0111] As shown in Figure 6, terminal 140 can encrypt data using a dynamic key to obtain a corresponding ciphertext, transmit the ciphertext to server 110 using a general-purpose transmission layer security protocol, and then store the encrypted string token in a URL and transmit it to server 110.

[0112] After receiving the ciphertext and encryption string, the server can decrypt the encryption string according to a predetermined key to obtain a dynamic key. This allows the server to decrypt the ciphertext according to the dynamic key to obtain the corresponding data (i.e., plaintext), thereby achieving secure communication, effectively protecting the integrity and security of data transmitted from the applet to the server, and preventing attackers from decrypting or deciphering the data.

[0113] In some embodiments, since the applet encrypts the data using the AES encryption algorithm and CBC (Cipher Block Chaining) mode with a dynamic key, the applet also needs to send an encryption initialization vector to the server, i.e., step 204 is: The further step includes sending the encrypted initial vector to the server using a general-purpose transmission layer security protocol.

[0114] Here, the applet can send the encryption initialization vector, ciphertext, and encryption string to the server via a transmission layer security protocol. After the server receives the encryption initialization vector, ciphertext, and encryption string, it can decrypt the encryption string according to a predetermined key, recover the dynamic key, and decrypt the ciphertext by combining the dynamic key with the encryption initialization vector. The specific processing steps are as follows: The ciphertext is divided into blocks according to a scheme where each block is 128 bits (i.e., 16 bytes) in size, obtaining multiple ciphertext subblocks. The first ciphertext subblock is decrypted using a dynamic key to obtain a first decryption result, and this first decryption result is XORed with the encryption initialization vector to obtain the corresponding sub-plaintext of the first ciphertext subblock. The second ciphertext subblock is decrypted using a dynamic key to obtain a second decryption result, and this second decryption result is XORed with the sub-ciphertext of the previous ciphertext subblock (i.e., the first ciphertext subblock) to obtain the corresponding sub-plaintext of the second ciphertext subblock. The third ciphertext subblock is decrypted using a dynamic key to obtain a third decryption result, and this third decryption result is XORed with the sub-ciphertext of the previous ciphertext subblock (i.e., the second ciphertext subblock) to obtain the corresponding sub-plaintext of the third ciphertext subblock. By analogy in this way, the sub-plaintext of each ciphertext subblock can be obtained.

[0115] To obtain the data, the sub-plaintext of each ciphertext sub-block can be joined together.

[0116] As can be seen from the above, in the embodiment of the present invention, a handshake request is sent to the server by a dedicated transmission layer security protocol between the applet and the server, the dedicated transmission layer security protocol has higher security than the general-purpose transmission layer security protocol, the dedicated transmission layer security protocol receives a dynamic key that the server replies to the handshake request and an encrypted string obtained by performing encryption processing based on the dynamic key, obtains the data to be sent, encrypts the data with the dynamic key to generate a corresponding ciphertext, and sends the ciphertext and encrypted string to the server by the general-purpose transmission layer security protocol, the server decrypts the ciphertext according to the dynamic key that has been decrypted to recover the encrypted string and obtains the decrypted data. Compared with methods in related technologies that achieve symmetric encryption using static keys, the embodiment of the present invention can receive dynamic keys using a dedicated transmission layer security protocol with higher security, ensuring that dynamic keys cannot be intercepted by attackers, and transmits dynamic keys to the server in the form of an encryption string using a general-purpose transmission layer security protocol, thereby avoiding the transmission of dynamic keys in plaintext form, effectively preventing the decryption of dynamic keys, and improving the security of data transmission.

[0117] The methods described in the above embodiments will be explained in more detail below with reference to examples.

[0118] In this embodiment, the description will be based on the viewpoint of a data transmission device. Specifically, the data transmission device may be integrated into a computer device that includes a storage unit and is equipped with a microprocessor and has computing power. The computer device may be a server; in other words, a server will be described in this embodiment.

[0119] As can be seen in conjunction with Figure 9, Figure 9 is a schematic flowchart of a data transmission method provided by an embodiment of the present invention. The flow of the method may include steps 401 to 405.

[0120] In step 401, the applet receives a handshake request sent via a dedicated transmission layer security protocol.

[0121] Here, the server can receive a handshake request sent by the applet via a dedicated transmission layer security protocol, which may include the applet identifier and instant messaging client terminal version of the applet, thereby allowing the server to authenticate whether the applet identifier and instant messaging client terminal version are usable and not. If it is authenticated that the applet identifier or instant messaging client terminal version is not usable, for example, an applet identifier error or an instant messaging client terminal version that is too low, the server will not respond to the handshake request.

[0122] Accordingly, when both the applet identifier and the instant messaging client terminal are authenticated as being in working order, the handshake request is responded to and step 402 is performed.

[0123] In step 402, a random dynamic key is generated in response to the handshake request, and a corresponding cryptographic string is obtained based on the above dynamic key.

[0124] Here, the server, in response to the handshake request, generates a random dynamic key according to a secure random number generator, the length of which may be 128 bits, 256 bits, etc. That is, since the dynamic key changes in real time, it can be easily countered by an attacker by decrypting it.

[0125] As needs to be explained, because the transmission capacity of the dedicated transmission layer security protocol is limited, data transmitted by subsequent applets still needs to be transmitted by the general-purpose transmission layer security protocol. To avoid the dynamic key being transmitted in plain text over the general-purpose transmission layer security protocol, the server can encrypt the dynamic key using configured encryption rules to obtain an appropriate encrypted string.

[0126] In some embodiments, to better achieve data protection, it can be specified that the dynamic key has a reasonable validity period, that is, after the validity period is reached, the dynamic key becomes reasonably invalid, the applet needs to resend the handshake request, and the server periodically updates the dynamic key by generating and sending an updated dynamic key and encryption string to the applet in response to the resent handshake request, thereby better evading attacker analysis.

[0127] In other words, step 402 is, The steps include generating a random dynamic key in response to the handshake request and determining the validity period of the dynamic key, A step of determining the timestamp of the dynamic key based on the validity period, The steps may include obtaining the identity identifier of the applet, encrypting the dynamic key, identity identifier, and timestamp, and obtaining a corresponding encryption string.

[0128] Here, the validity period can be manually set, for example, by default to 15 minutes or 30 minutes, and in the embodiment of the present application, 30 minutes will be described as an example. The server can generate a random 256-bit dynamic key in response to the handshake request and determine that the validity period of the dynamic key is 30 minutes.

[0129] Accordingly, a timestamp of the dynamic key can be determined based on the 30-minute validity period in order to subsequently authenticate the validity of the encryption string, and the timestamp may include the issue time (iat) and the expiration time (exp) of the dynamic key, for example, the issue time being 11:50:00 on October 8, 2023, the validity period being 30 minutes, and in this case, the expiration time being 12:20:00 on October 8, 2023.

[0130] Furthermore, in order to perform identity authentication on the subsequent encrypted string, the identity identifier of the applet that sends another handshake request can be obtained, and this identity identifier may be the account identifier used to log in to the instant messaging client terminal on which the applet depends, for example, account identifier 12345, and a triplet of [dynamic key, identity identifier, timestamp] is obtained, and symmetric encryption is performed on this [dynamic key, identity identifier, timestamp] based on a predetermined key to obtain a corresponding encrypted string, thereby enabling the dynamic key to be transmitted in the form of an encrypted string in a subsequent general-purpose transmission layer security protocol, avoiding the transmission of the dynamic key in plaintext, and improving the security of dynamic key transmission.

[0131] As needs to be explained, the symmetric encryption process may be the AES (Advanced Encryption Standard) encryption algorithm, which encrypts and decrypts data using a 128-bit, 192-bit, or 256-bit key, and has advantages such as high strength, high speed, and ease of implementation. The predetermined key is a 128-bit, 192-bit, or 256-bit key used for encryption, and unlike symmetric encryption in related technologies, the predetermined key does not need to be transmitted to the terminal but only needs to be stored internally on the server, thus preventing leakage of the predetermined key.

[0132] In some embodiments, the encrypted string may be a binary ciphertext, the data length becomes very large, affecting the transmission speed, and subsequently the applet needs to store the encrypted string in a URL and send it back to the server. However, URLs only support a limited character set and cannot encode binary ciphertext, so further simplification processing is required for the encrypted string, namely, the steps of encrypting the dynamic key, identity identifier, and timestamp to obtain a corresponding encrypted string are as follows: The steps include: performing encryption on the dynamic key, identity identifier, and timestamp according to a predetermined key to obtain an initial encryption string; The process includes the step of performing an encoding conversion on the initial encryption string using a predetermined number of printable characters to obtain a corresponding encryption string.

[0133] As needs to be explained, the predetermined number of printable characters can be understood as Base64 encoding, which is one of the most common encoding schemes used to transmit 8-bit byte code, and it is a way of representing binary data based on 64 printable characters. The encoding set consists of 64 characters: 26 uppercase letters A-Z, 26 lowercase letters a-z, 10 digits 0-9, the symbol "+", and the symbol " / ".

[0134] Specifically, based on a predetermined key, symmetric encryption is performed on the [dynamic key, identity identifier, timestamp] to obtain an initial encryption string, which is a binary ciphertext. For the convenience of subsequent transmission, the initial encryption string can be re-encoded using Base64 encoding. Specifically, the initial encryption string can be divided into sets of three bytes, each set containing a total of 24 binary bits. These 24 binary bits are then divided into four sets of six bits each (i.e., 6 × 4 = 24 binary bits). Next, we prefix each set with 00 to expand it to 8 × 4 = 32 binary bits, i.e., 4 bytes (since there are two zeros before each byte, the maximum value of each byte is 63, and adding two zeros at the beginning is simply to align one byte, the numerical value does not change), and finally, according to the Base64 encoding table, we convert the code values ​​of the 4 bytes to the corresponding Base64 characters to obtain the corresponding encrypted string.

[0135] In some embodiments, applets can be applied to different scenes, such as login scenes, order scenes, and information viewing scenes. The login scene represents the user logging into an account via the applet, the order scene represents the user placing an order for a product via the applet, and the information viewing scene represents the user viewing information via the applet. On the other hand, each scene has different security requirements; for example, the security required for the login scene is higher than that for the order scene, but the security required for the order scene is higher than that for the information viewing scene. Based on this, dynamic keys assigned in each scene are set to have different validity periods.

[0136] Based on this, a handshake request sent by an applet may have a corresponding scene type, which indicates the corresponding scene of the applet when generating the handshake request, and which may include, but is not limited to, a login scene type, an order scene type, or an information browsing scene type. When an applet generates a handshake request in a login scene, the scene type of the handshake request is a login scene type. When an applet generates a handshake request in an order scene, the scene type of the handshake request is an order scene type. Accordingly, when an applet generates a handshake request in an information browsing scene, the scene type of the handshake request is an information browsing scene type.

[0137] As a result, the step of determining the validity period of the dynamic key is The process may include the step of determining a suitable validity period for the dynamic key according to a predetermined mapping table. Here, the predetermined mapping table includes the mapping relationship between different scene types and effective time.

[0138] Specifically, the predetermined mapping table can refer to the previous table 1, and the server can quickly match the appropriate validity period of the generated dynamic key according to the scene type provided by the handshake request. If the scene type provided by the handshake request is the order scene type, it can be determined that the appropriate initial validity period of the dynamic key is 10 minutes.

[0139] In some embodiments, the applet can be applied to different scenes, such as a login scene, an order scene, and an information viewing scene, where the login scene represents the user logging into an account via the applet, the order scene represents the user placing an order for a product via the applet, and the information viewing scene represents the user viewing information via the applet. On the other hand, each scene has different security requirements; for example, the security required for the login scene is higher than that for the order scene, but the security required for the order scene is higher than that for the information viewing scene.

[0140] At the same time, there are various types of applets, such as office-type applets, game-type applets, and lifestyle-type applets. Each type of applet has different security requirements. For example, the security required for office-type applets is higher than that for lifestyle-type applets, and vice versa. Based on this, different effective timeframes can be flexibly set in combination with the application scenario and type of applet.

[0141] Based on this, the handshake request may simultaneously include a scene type and an application privacy level, the scene type indicating the corresponding scene of the applet when generating the handshake request, and the scene type may include, but is not limited to, a login scene type, an order scene type, or an information browsing scene type. When an applet generates a handshake request in a login scene, the scene type included in the handshake request is a login scene type. When an applet generates a handshake request in an order scene, the scene type included in the handshake request is an order scene type. Accordingly, when an applet generates a handshake request in an information browsing scene, the scene type included in the handshake request is an information browsing scene type.

[0142] The application privacy level indicates the appropriate privacy level for the type of applet when generating a handshake request, and includes, but is not limited to, three levels: high, medium, and low. This allows setting the application privacy level to high for office-type applets, medium for lifestyle-type applets, and low for game-type applets. For example, if an applet is of office type and generates a handshake request, the application privacy level of that handshake request is high. If an applet is of lifestyle type and generates a handshake request, the application privacy level of that handshake request is medium. If an applet is of game type and generates a handshake request, the application privacy level of that handshake request is low.

[0143] As a result, the step of determining the validity period of the dynamic key is A step of determining a suitable initial validity period for the dynamic key according to a predetermined mapping table, Here, the predetermined mapping table includes the mapping relationship between different scene types and effective time, in steps: The process may further include determining weights according to the application privacy level, weighting the initial validity period based on those weights, and obtaining the validity period of the dynamic key.

[0144] Specifically, the predetermined mapping table can refer to the previous table 1, and the server can quickly match the appropriate initial validity period of the generated dynamic key according to the scene type provided by the handshake request. If the scene type provided by the handshake request is the order scene type, it can be determined that the appropriate initial validity period of the dynamic key is 10 minutes.

[0145] Furthermore, the server can automatically match weights according to the application privacy level, and the mapping relationship between the application privacy level and the weights is shown by continuously referring to Table 2. For example, if the application privacy level of the handshake request is medium, then the weighting process is performed on the initial validity period of 10 minutes according to the weight of 0.8 obtained through matching, resulting in a final validity period of 8 minutes.

[0146] In step 403, the applet is returned with a dynamic key and encryption string via a dedicated transmission layer security protocol.

[0147] Here, the server can return the dynamic key and the encryption string to the applet in the embodiment of the present invention by the dedicated transmission layer security protocol, and the applet can receive the dynamic key returned by the server and the encryption string obtained by performing encryption processing based on the dynamic key by the dedicated transmission layer security protocol, thereby enabling a handshake, that is, establishing a connection between the applet and the server, and enabling the applet to encrypt the data to be sent according to the dynamic key (i.e., plaintext). Accordingly, the entire protocol of the dedicated transmission layer security protocol is highly customized, so conventional packet capture tools cannot perform packet capture analysis. In other words, because the dedicated transmission layer security protocol is customized, conventional packet capture tools cannot capture the dynamic key and encryption string transmitted by the dedicated transmission layer security protocol, thus better guaranteeing the security of dynamic key transmission.

[0148] In some embodiments, the server may also return the validity period of the dynamic key to the applet, i.e., the step of returning the dynamic key and encryption string to the applet by a dedicated transmission layer security protocol is: The process includes the step of returning the dynamic key, the corresponding validity period of the dynamic key, and the encryption string to the applet using a dedicated transmission layer security protocol.

[0149] Specifically, the server can return the dynamic key, the appropriate validity period of the dynamic key, and the encryption string to the applet using a dedicated transmission layer security protocol. In response, the applet can receive the dynamic key, the appropriate validity period of the dynamic key, and the encryption string obtained by performing encryption processing based on the dynamic key, which the server returns in response to the handshake request, using the dedicated transmission layer security protocol. The applet can then encrypt the data to be transmitted according to the dynamic key within the validity termination time determined by the validity period.

[0150] In step 404, the applet receives the ciphertext and encrypted string transmitted by the General Purpose Transmission Layer Security Protocol.

[0151] Here, the applet can perform symmetric encryption on the data (i.e., plaintext) in accordance with a dynamic key received by a dedicated transmission layer security protocol, generate a corresponding ciphertext, and send the ciphertext and encryption string to the server by a general-purpose transmission layer security protocol. Accordingly, the server can receive the ciphertext and encryption string sent by the applet by the general-purpose transmission layer security protocol. As needs to be explained, the encryption string may be stored in a URL and transmitted by the applet.

[0152] Since the ciphertext is obtained by encryption using a dynamic key, and the encrypted string is also obtained by encryption, neither the dynamic key nor the data is transmitted in plaintext form over a general-purpose transmission layer security protocol. Furthermore, the dynamic key is transmitted securely by a dedicated transmission layer security protocol, but the predetermined key exists only on the server. Therefore, even if an attacker intercepts the ciphertext and encrypted string, they cannot perform appropriate decryption, thereby protecting data security and improving the security of data transmission.

[0153] 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 the decrypted data.

[0154] Here, after the server receives the ciphertext and encryption string, it can decrypt the encryption string to obtain a dynamic key, which in turn can decrypt the ciphertext according to the dynamic key to obtain the corresponding data (i.e., plaintext), thereby achieving secure communication, effectively protecting the integrity and security of the data from the applet to the server, and preventing attackers from decrypting or deciphering the data.

[0155] In some embodiments, when the encrypted string is obtained by Base64 encoding, it is necessary to further decrypt the encrypted string into a binary ciphertext and then decrypt the encrypted string again.

[0156] In some embodiments, the server will have a predetermined key stored in front of the dynamic key for performing symmetric encryption, so it will be necessary to decrypt the encryption string with the predetermined key, that is, as shown in Figure 10, step 405 will include steps 501-502.

[0157] Step 501: Decrypt the encrypted string using a predetermined key to obtain the dynamic key, identity identifier, and timestamp.

[0158] Step 502: When the authentication of the identity identifier and the timestamp is successful, the ciphertext is decrypted according to the dynamic key to obtain the decrypted data.

[0159] Here, after receiving the ciphertext and encryption string, the server can decrypt the encryption string according to a predetermined key and obtain a triplet of "dynamic key, identity identifier, and timestamp" in the encryption string. With this, the server can perform identity authentication on the sender according to the identity identifier obtained by decryption, and time authentication on the timestamp obtained by decryption. For example, the server can obtain the identity identifier to be authenticated by the sender, compare this identity identifier with the identity identifier obtained by decryption, and determine that identity authentication is successful if the two match, and unsuccessful if the two do not match. Furthermore, the server can obtain the generation time of the ciphertext and determine whether the generation time is within the valid time range indicated by the timestamp. If the generation time is within the valid time range indicated by the timestamp, the server determines that timestamp authentication is successful, and if the generation time is not within the valid time range indicated by the timestamp, the server determines that timestamp authentication is unsuccessful.

[0160] Furthermore, when both the identity identifier and timestamp authentication are successful, it indicates that both identity authentication and time authentication are successful, allowing the ciphertext to be decrypted according to the dynamic key to obtain the decrypted data (i.e., plaintext), thus achieving secure communication, effectively protecting the integrity and security of data from the applet to the server, and preventing attackers from decrypting or deciphering the data. As a result, the server does not need to store the identity identifier and dynamic key, and can obtain the identity identifier and dynamic key simply by decrypting the encryption string, thereby saving the server's memory resources.

[0161] In some embodiments, in order to prevent identity tampering attacks and replay attacks, it is necessary to perform further identity and time authentication before decrypting the ciphertext, that is, when the authentication of the identity identifier and the timestamp is successful, the step of decrypting the ciphertext according to the dynamic key to obtain the decrypted data is: The steps include obtaining the current identity identifier of the applet that sends the ciphertext and the encryption string, and the generation time of the ciphertext, The steps include obtaining the effective termination time indicated by the timestamp, The process includes the step of decrypting the ciphertext according to the dynamic key to obtain decrypted data when it is detected that the identity identifier matches the current identity identifier and that the generation time is before the effective termination time.

[0162] As needs to be explained, an identity tampering attack refers to an attack where an attacker intercepts data transmitted from an applet via a general-purpose transmission layer security protocol and then sends data from the attacker's client terminal to carry out the attack, while a replay attack refers to a type of attack where the attacker does not need to decrypt the actual data packets, but instead records the data request itself and replays the data request after a certain period of time.

[0163] In the embodiment of the present invention, identity authentication and time authentication are performed to prevent the above-mentioned identity tampering attacks and replay attacks. Specifically, the server can obtain the current identity identifier of the applet that sends the ciphertext and encryption string, and the time the ciphertext was generated.

[0164] Furthermore, the current identity identifier can be compared with the identity identifier obtained by decryption. If the two are the same, it is determined that the identity identifier matches the current identity identifier. If the two are different, it is determined that the identity identifier does not match the current identity identifier and that the identity has been tampered with. Accordingly, the expiration time of the dynamic key can be determined according to the expiration time in the timestamp. It is detected whether the generation time is before the expiration time. If it is detected that the generation time is before the expiration time, it indicates that time authentication is successful. On the other hand, if it is detected that the generation time is not before the expiration time, it indicates that time authentication is unsuccessful and that it is a replay attack. Based on this, when it is detected that the identity identifier matches the current identity identifier and the generation time is before the expiration time, that is, when identity authentication and time authentication are successful simultaneously, the step of decrypting the ciphertext according to the dynamic key and obtaining the decrypted data is executed. This prevents identity tampering attacks and replay attacks, and better protects the security of data transmission.

[0165] In some embodiments, the method by which the applet encrypts data may be based on the AES encryption algorithm, using CBC (Cipher Block Chaining) mode, and encrypting the data with a dynamic key. Therefore, in order for the server to decrypt the ciphertext using the dynamic key, it is necessary to decrypt the encryption initialization vector as well. That is, the step of decrypting the ciphertext according to the dynamic key and obtaining the decrypted data is as follows: The applet sends an encrypted initial vector, and The process includes the steps of: decrypting the ciphertext according to the dynamic key to obtain a first decryption result; performing an XOR operation on the first decryption result and the encryption initialization vector to obtain the decrypted data.

[0166] Specifically, the server further receives the encryption initialization vector sent by the applet, divides the ciphertext into blocks according to a scheme where each block is 128 bits (i.e., 16 bytes) in size, and obtains multiple ciphertext subblocks. For the first ciphertext subblock, it decrypts it using a dynamic key to obtain a first decryption result, and then performs an XOR operation on this first decryption result and the encryption initialization vector to obtain the corresponding sub-plaintext of the first ciphertext subblock. On the other hand, for the second ciphertext subblock, it decrypts it using a dynamic key to obtain a second decryption result, and then performs an XOR operation on the sub-ciphertext of the previous ciphertext subblock (i.e., the first ciphertext subblock) and the second decryption result to obtain the corresponding sub-plaintext of the second ciphertext subblock. The third ciphertext subblock can be decrypted using a dynamic key to obtain the third decryption result, and then XORed with the subciphertext of the previous ciphertext subblock (i.e., the second ciphertext subblock) and the third decryption result to obtain the corresponding subplaintext of the third ciphertext subblock. By analogy, the subplaintext of each ciphertext subblock can be obtained.

[0167] To obtain the decrypted data, the sub-plaintext of each ciphertext sub-block can be joined together.

[0168] To better illustrate the embodiments of this application, please refer to and understand Figure 11, which is a schematic diagram of the interaction of the data transmission method provided by the embodiments of this application. During the handshake phase, the server generates a dynamic key in response to the handshake request and performs symmetric encryption on the identity identifier and timestamp of the dynamic key according to the predetermined key to generate a corresponding encrypted string. The server then transmits the dynamic key and encrypted string to the applet using a dedicated transmission layer security protocol.

[0169] During the encryption phase, the applet performs symmetric encryption on the data (i.e., plaintext) according to the encryption initialization vector and dynamic key, obtains the corresponding ciphertext, and can then send the encryption initialization vector, ciphertext, and encryption string together to the server using a general-purpose transmission layer security protocol.

[0170] In the decryption stage, the server decrypts the encrypted string using a predetermined key, recovers the dynamic key, identity identifier, and timestamp, and after successful authentication of the identity identifier and timestamp, decrypts the ciphertext by combining it with the encryption initialization vector using the dynamic key to obtain the decrypted data. This means that the dynamic key and the encrypted string obtained by performing encryption processing based on the dynamic key are transmitted by a dedicated transmission layer which has higher security than a general-purpose transmission layer security protocol, the data to be transmitted is encrypted using the dynamic key to generate a corresponding ciphertext, and the ciphertext and encrypted string are sent to the server using a general-purpose transmission layer security protocol. The server decrypts the encrypted string and decrypts the ciphertext according to the recovered dynamic key to obtain the decrypted data. Compared to means that achieve symmetric encryption using a static key in related technologies, the embodiment of the present invention can receive the dynamic key using a dedicated transmission layer security protocol which has higher security, guaranteeing that the dynamic key will not be intercepted by an attacker, and transmits the dynamic key to the server using a general-purpose transmission layer security protocol in the form of an encrypted string, avoiding the transmission of the dynamic key in plaintext, effectively preventing the dynamic key from being deciphered, and improving the security of data transmission.

[0171] To better illustrate the embodiments of the present application, please refer to and understand Figure 12, which is an interaction flowchart of the data transmission method provided by the embodiments of the present application. Hereinafter, the specific interaction process of the data transmission method of the embodiments of the present application will be described in detail, as shown in Figure 12. The process includes, but is not limited to, the following steps 601 to 613.

[0172] Step 601: The applet on terminal 140 sends a handshake request to server 110 via a dedicated transmission layer security protocol between the applet and the server.

[0173] Step 602: Server 110 receives a handshake request sent by the applet via a dedicated transmission layer security protocol and generates a random dynamic key in response to the handshake request.

[0174] Step 603: Server 110 queries a predetermined mapping table according to the scene type and determines the appropriate validity period for the dynamic key.

[0175] Step 604: Server 110 determines the timestamp of the dynamic key based on its validity period.

[0176] Step 605: Server 110 obtains the applet's identity identifier and, according to a predetermined key, encrypts the dynamic key, identity identifier, and timestamp to obtain an initial encryption string.

[0177] Step 606: Server 110 performs an encoding conversion on the initial encryption string using a predetermined number of printable characters to obtain a corresponding encryption string.

[0178] Step 607: Server 110 returns the dynamic key, the corresponding validity period of the dynamic key, and the encryption string to the applet on terminal 140 using a dedicated transmission layer security protocol.

[0179] Step 608: The applet on terminal 140 receives the dynamic key, the corresponding validity period of the dynamic key, and the encryption string from the server via a dedicated transmission layer security protocol.

[0180] Step 609: The applet on terminal 140 retrieves the data to be sent, generates a random number, generates a message sequence number for the data according to the data generation order, combines the random number and the message sequence number, and generates a corresponding encryption initial vector.

[0181] Step 610: The applet on terminal 140 divides the data into multiple data blocks, performs an XOR operation on the first data block with the encryption initialization vector to obtain the first XOR result of the first data block, encrypts the first XOR result with the dynamic key to obtain a subciphertext corresponding to the first data block, performs an XOR operation on the other data blocks with the subciphertext corresponding to the data block preceding the other data block to obtain the second XOR result of the other data block, encrypts the second XOR result with the dynamic key to obtain a subciphertext corresponding to the other data block, and constructs a ciphertext with the subciphertexts corresponding to the multiple data blocks.

[0182] Step 611: The applet on terminal 140 sends the encrypted initialization vector, ciphertext, and encrypted string to server 110 using a general-purpose transmission layer security protocol.

[0183] Step 612: Server 110 receives the encrypted ciphertext, encryption initialization vector, and encryption string transmitted by the applet using the General-Purpose Transmission Layer Security Protocol.

[0184] Step 613: Server 110 decrypts the encryption string using a predetermined key, recovers the dynamic key, identity identifier, and timestamp, and when authentication of the identity identifier and timestamp is successful, decrypts the ciphertext according to the dynamic key and encryption initialization vector to obtain the decrypted data.

[0185] Here, the meaning of the noun is the same as in the data transmission method described above, and for specific implementation details, please refer to the explanation in the embodiment of the method, which will not be explained again here.

[0186] To facilitate the better implementation of the data transmission method provided by the embodiments of the present application, the embodiments of the present application further provide a device based on the above data transmission method. Here, the meaning of the nouns is the same as in the above data transmission method, and specific implementation details can be found in the description of the embodiments of the method.

[0187] As shown in Figure 13, Figure 13 is a schematic diagram of the structure of a data transmission device provided by an embodiment of the present invention, which is applied to a terminal, and the data transmission device may include a first transmitting unit 701, a first receiving unit 702, an encryption unit 703, and a second transmitting unit 704, etc.

[0188] The first transmission unit 701 is used to send a handshake request to the server using a dedicated transmission layer security protocol between the applet and the server, and this dedicated transmission layer security protocol has higher security than a general-purpose transmission layer security protocol.

[0189] The first receiving unit 702 is used to receive, by means of the dedicated transmission layer security protocol, a dynamic key that the server replies to in response to the handshake request, and an encrypted string obtained in accordance with the dynamic key.

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

[0191] The second transmission unit 704 transmits the ciphertext and the encryption string to the server using the general-purpose transmission layer security protocol, which is used by the server to decrypt the encryption string to obtain a dynamic key, and then decrypt the ciphertext according to the dynamic key to obtain the decrypted data.

[0192] The specific implementation of each of the above units can be found in the previous examples and will not be explained again here.

[0193] As shown in Figure 14, Figure 14 is a schematic diagram of the structure of a data transmission device provided by an embodiment of the present invention, which is applied to a terminal, and which may include a first receiving unit 801, a generating unit 802, a reply unit 803, a second receiving unit 804, and a decoding unit 805, etc.

[0194] The first receiving unit 801 is used to receive handshake requests transmitted by the applet using a dedicated transmission layer security protocol, which has higher security than a general-purpose transmission layer security protocol.

[0195] The generation unit 802 is used to generate a random dynamic key in response to the handshake request and to obtain an encryption string according to the dynamic key.

[0196] The reply unit 803 is used to encrypt the data that the applet should send according to the dynamic key and obtain ciphertext by sending back the dynamic key and the encryption string to the applet using the dedicated transmission layer security protocol.

[0197] The second receiving unit 804 is used to receive the ciphertext and encrypted string transmitted by the applet using the general-purpose transmission layer security protocol.

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

[0199] The specific implementation of each of the above units can be found in the previous examples and will not be explained again here.

[0200] Embodiments of the present application further provide computer equipment, which may be a terminal, and as shown in Figure 15, it shows a schematic diagram of the structure of a terminal relating to embodiments of the present application, specifically, The computer equipment may include components such as a radio frequency (RF) circuit 901, a memory 902 containing 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 containing one or more processing cores, and a power supply 909. As those skilled in the art will understand, the terminal structure shown in Figure 15 does not constitute a limitation on the terminal, and may include more or fewer components than shown, or combine some components, or arrange different components. Memory 902 can be used to store software programs and modules, and the processor 908 operates the software programs and modules stored in memory 902, thereby performing various functional applications and information retrieval. Memory 902 may mainly include a program storage area and a data storage area, where the program storage area can store an operating system, application programs necessary for at least one function (e.g., audio playback function and image playback function), etc., and the data storage area can store data newly created in accordance with the use of the terminal (e.g., audio data and phone book, etc.). Memory 902 may also include high-speed random access memory, and may further include, for example, at least one magnetic disk storage device and non-volatile memory such as a flash memory device, or other volatile solid-state storage devices. Accordingly, memory 902 may further include a memory controller, thereby providing the processor 908 and the input unit 903 with access to memory 902.

[0201] In this embodiment, the processor 908 in the terminal loads executable files corresponding to the processes of one or more application programs into memory 902 according to the following instructions, and the processor 908 operates the application programs stored in memory 902, thereby realizing the methods provided by each embodiment of the present invention.

[0202] In the above embodiments, each embodiment focuses on a different aspect, and for parts not detailed in a particular embodiment, please refer to the detailed description of the file transmission method described above; they will not be explained again here.

[0203] Embodiments of the present application further provide computer equipment, which may be a server, and as shown in Figure 16, it shows a schematic diagram of the structure of a server according to embodiments of the present application, specifically, The computer equipment may include components such as a processor 1010 having one or more processing cores, a memory 1020 having one or more computer-readable storage media, a power supply 1030, and an input unit 1040. As those skilled in the art will understand, the structure of the computer equipment shown in Figure 16 does not constitute a limitation on the computer equipment, and it may include more or fewer components than shown, or combine some components, or arrange different components. Here, Although not shown, the computer equipment may further include a display unit and the like, which will not be described again here. Specifically, in this embodiment, the processor 1010 in the computer equipment loads an executable file corresponding to the process of one or more application programs into memory 1020 in accordance with the following instructions, and the processor 1010 operates the application programs stored in memory 1020, thereby realizing the steps of the various methods provided by the embodiment described above.

[0204] In the above embodiments, the descriptions for each embodiment focus on different aspects. For parts not detailed in a particular embodiment, please refer to the detailed description of the queue processing method described above, and will not be explained again here.

[0205] As those skilled in the art will understand, all or some of the steps of the various methods in the above embodiments can be completed by instructions, or by instructions controlling relevant hardware, which can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0206] Therefore, the embodiment of the present application provides a computer-readable storage medium in which a plurality of instructions are stored, and these instructions can be loaded into a processor to perform any one of the steps of the data transmission method provided by the embodiment of the present application.

[0207] In one aspect of the present application, a computer program product or computer program is provided, the computer program product or computer program includes computer instructions, the computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, thereby causing the computer device to perform the methods provided in the various selectable implementations provided in the above embodiment.

[0208] For specific details on how to perform each of the above operations, please refer to the previous examples, as they will not be explained again here.

[0209] Here, the computer-readable storage medium may include read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0210] Since the instructions stored in the computer-readable storage medium can perform any step of the data transmission method provided by the embodiments of the present invention, beneficial effects that can be achieved by any one of the data transmission methods provided by the embodiments of the present invention can be realized, and for details, please refer to the previous embodiments, which will not be explained again here.

[0211] The data transmission methods, apparatus, storage media, and devices provided by the embodiments of this application have been described in detail above. The principles and embodiments of this application are described herein by applying specific examples. The above description of the embodiments is used solely to aid in understanding the methods and core ideas of this application. At the same time, those skilled in the art can modify the specific embodiments and scope of application based on the ideas of this application, and therefore, the contents of this specification should not be understood as limiting this application. [Explanation of symbols]

[0212] 110 Servers 120 Gateways 130 Internet 140 devices 701 First Transmitting Unit 702 First Receiving Unit 703 Encryption Unit 704 Second Transmitting Unit 801 First receiving unit 802 Generation Unit 803 Reply Unit 804 Second receiving unit 805 Decoding Unit 901 Radio Frequency (RF) Circuit 902 memory 903 Input Unit 904 Display Unit 905 Sensor 906 Audio Circuit 908 Processor 909 Power supply 1010 Processor 1020 memory 1030 Power supply 1040 Input Unit 12345 Account Identifier

Claims

1. A data transmission method, which is performed by terminal equipment. A step of sending a handshake request to a server using a dedicated transmission layer security protocol between an applet operating within a terminal device and the server, wherein the dedicated transmission layer security protocol has higher security than a general-purpose transmission layer security protocol. The steps include receiving a dynamic key returned by the server via the dedicated transmission layer security protocol, and an encryption string obtained in accordance with the dynamic key, The steps include obtaining data to be transmitted and encrypting the data using the dynamic key to obtain a ciphertext, A data transmission method comprising the steps of: sending the ciphertext and the encryption string to a server using the general-purpose transmission layer security protocol, the server decrypting the encryption string to obtain the dynamic key, and decrypting the ciphertext according to the dynamic key to obtain the decrypted data.

2. The step of obtaining data to be transmitted and encrypting the data with the dynamic key to obtain a ciphertext is: The steps include obtaining data to be transmitted, generating an encryption initialization vector for the data, performing an XOR operation on the data according to the encryption initialization vector, and obtaining the XOR result, The data transmission method according to claim 1, comprising the step of encrypting the XOR result with the dynamic key to obtain the ciphertext.

3. The step of generating an encryption initial vector for the aforementioned data is: The steps for generating random numbers, The steps include generating a message sequence number for the aforementioned data, The data transmission method according to claim 2, comprising the step of combining the random number and the message sequence number to generate the encryption initial vector.

4. The step of performing an XOR operation on the data according to the encryption initial vector and obtaining the XOR result is: The steps include dividing the aforementioned data into multiple data blocks, The steps include: performing an XOR operation on the first data block with the encryption initialization vector and the first data block to obtain the first XOR result of the first data block; The steps include: performing an XOR operation on each of the other data blocks with the subciphertext of the preceding data block to obtain the second XOR result for each of the other data blocks; The step of encrypting the XOR result using the dynamic key to obtain the ciphertext is as follows: The steps include: encrypting the first XOR result using the dynamic key to obtain a subciphertext of the first data block; The steps include: encrypting the second XOR result of each of the other data blocks using the dynamic key, and obtaining a subciphertext corresponding to each of the other data blocks; The data transmission method according to claim 3, comprising the step of constructing an ciphertext with the subciphertexts corresponding to a plurality of data blocks.

5. A data transmission method according to any one of claims 2 to 4, further comprising the steps of: sending the encryption initialization vector to a server using a general-purpose transmission layer security protocol; the server decrypting the ciphertext according to the dynamic key to obtain a first decryption result; performing an XOR operation on the first decryption result and the encryption initialization vector to obtain the decrypted data.

6. The aforementioned handshake request includes a scene type, The aforementioned method, The dedicated transmission layer security protocol further includes the step of receiving the validity period of the dynamic key returned by the server, The data transmission method according to any one of claims 1 to 5, wherein the effective time is determined by the server according to the scene type provided by the handshake request.

7. The steps include determining the expiration time of the dynamic key according to the expiration time, The data transmission method according to claim 6, further comprising the step of re-executing the step of sending a handshake request to the server by a dedicated transmission layer security protocol between the applet and the server when it is detected that the current time has reached the effective termination time, thereby re-receiving the updated dynamic key, effective time, and encryption string by the dedicated transmission layer security protocol.

8. When a change in the scene type is detected, the steps include deleting the dynamic key, the validity period of the dynamic key, and the encryption string obtained by performing an encryption process based on the dynamic key, The data transmission method according to claim 6, further comprising the step of re-executing the step of sending a handshake request to the server by a dedicated transmission layer security protocol between the applet and the server, thereby re-receiving the updated dynamic key, validity period, and encryption string by the dedicated transmission layer security protocol.

9. The aforementioned handshake request includes a scene type and an application privacy level. The aforementioned method, The dedicated transmission layer security protocol further includes the step of receiving the validity period of the dynamic key that the server replies to in response to the handshake request, The data transmission method according to any one of claims 1 to 5, wherein the effective time is determined by the server according to both the scene type and the application privacy level provided by the handshake request.

10. The data transmission method according to any one of claims 1 to 9, wherein the dedicated transmission layer security protocol is the MMTLS protocol and the general-purpose transmission layer security protocol is the TLS protocol.

11. A data transmission method, which is executed by server equipment. A step of receiving a handshake request transmitted by an applet using a dedicated transmission layer security protocol, wherein the dedicated transmission layer security protocol has higher security than a general-purpose transmission layer security protocol. The steps include generating a random dynamic key in response to the handshake request and obtaining an encryption string according to the dynamic key, The steps include: sending the dynamic key and the encryption string back to the applet using the dedicated transmission layer security protocol, thereby encrypting the data to be sent according to the dynamic key and obtaining a ciphertext; The applet receives the ciphertext and the encryption string transmitted by the general-purpose transmission layer security protocol, A data transmission method comprising the steps of decrypting the encryption string to obtain the dynamic key, and decrypting the ciphertext based on the dynamic key to obtain the decrypted data.

12. The step of generating a random dynamic key in response to the handshake request and obtaining the cryptographic string according to the dynamic key is: The steps include generating a random dynamic key in response to the handshake request and determining the validity period of the dynamic key, The steps include determining the timestamp of the dynamic key based on the validity period, The data transmission method according to claim 11, comprising the steps of obtaining the user identity identifier of the applet, and encrypting the dynamic key, the user identity identifier, and the timestamp to obtain the encryption string.

13. The step of encrypting the dynamic key, identity identifier, and timestamp to obtain the encryption string is: The steps include: performing encryption on the dynamic key, identity identifier, and timestamp according to a predetermined key to obtain an initial encryption string; The data transmission method according to claim 12, comprising the step of performing an encoding conversion on the initial encryption string using a predetermined number of printable characters to obtain the encryption string.

14. The aforementioned handshake request includes a scene type, The step of determining the validity period of the dynamic key is: The step includes determining the validity period of the dynamic key according to a first predetermined mapping table, The data transmission method according to claim 12 or 13, wherein the first predetermined mapping table includes a mapping relationship between different scene types and effective time.

15. The aforementioned handshake request includes a scene type and an application privacy level. The step of determining the validity period of the dynamic key is: A step of determining the initial validity period of the dynamic key according to a second predetermined mapping table, The second predetermined mapping table includes a mapping relationship between different scene types and initial validity periods, and steps: A data transmission method according to claim 12 or 13, comprising the steps of determining weights according to the application privacy level, weighting the initial validity period based on the weights, and obtaining the validity period of the dynamic key.

16. The data transmission method according to any one of claims 12 to 15, further comprising the step of encrypting the data to be transmitted by the applet in accordance with the dynamic key within the validity period by sending back the validity period of the dynamic key to the applet using a dedicated transmission layer security protocol.

17. The steps include: decrypting the encrypted string received from the applet to obtain the identity identifier and timestamp; A data transmission method according to any one of claims 12 to 16, further comprising the step of performing an operation to decrypt the ciphertext in accordance with the dynamic key when the authentication of the identity identifier and the timestamp is successful.

18. The step of decrypting the ciphertext according to the dynamic key to obtain the decrypted data is: The applet sends an encrypted initial vector, and The data transmission method according to claim 17, comprising the steps of: decrypting the ciphertext according to the dynamic key to obtain a first decryption result; performing an XOR operation on the first decryption result and the encryption initial vector to obtain the decrypted data.

19. A data transmission device, A first transmission unit used to send a handshake request to a server via a dedicated transmission layer security protocol between an applet and a server, wherein the dedicated transmission layer security protocol has higher security than a general-purpose transmission layer security protocol, and the first transmission unit A first receiving unit used to receive a dynamic key that the server replies to the handshake request using the dedicated transmission layer security protocol, and an encryption string obtained in accordance with the dynamic key, An encryption unit used to obtain data to be transmitted and to encrypt the data using the dynamic key to obtain ciphertext, A data transmission device comprising: a second transmission unit used to send the ciphertext and the encryption string to a server using the general-purpose transmission layer security protocol, so that the server decrypts the encryption string to obtain the dynamic key, and decrypts the ciphertext according to the dynamic key to obtain the decrypted data.

20. A computer-readable storage medium, wherein a plurality of instructions are stored in the computer-readable storage medium, and the instructions are suitable for loading by a processor, thereby enabling the execution of the steps of the data transmission method described in any one of claims 1 to 18.

21. A computer device comprising memory, a processor, and a computer program stored in the memory and operable on the processor, wherein the processor, when executing the computer program, realizes the steps of the data transmission method described in any one of claims 1 to 18.

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

Images