[go: up one dir, main page]

WO2025082030A1 - 数据传输方法、装置、存储介质及设备 - Google Patents

数据传输方法、装置、存储介质及设备 Download PDF

Info

Publication number
WO2025082030A1
WO2025082030A1 PCT/CN2024/113806 CN2024113806W WO2025082030A1 WO 2025082030 A1 WO2025082030 A1 WO 2025082030A1 CN 2024113806 W CN2024113806 W CN 2024113806W WO 2025082030 A1 WO2025082030 A1 WO 2025082030A1
Authority
WO
WIPO (PCT)
Prior art keywords
dynamic key
data
server
transport layer
ciphertext
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/CN2024/113806
Other languages
English (en)
French (fr)
Inventor
龙灏天
周榕彬
邓坤力
黄灿辉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Publication of WO2025082030A1 publication Critical patent/WO2025082030A1/zh
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0457—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply dynamic encryption, e.g. stream encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/065—Encryption by serially and continuously modifying data stream elements, e.g. stream cipher systems, RC4, SEAL or A5/3
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer

Definitions

  • the present application relates to the field of communication technology, and in particular to a data transmission method, apparatus, storage medium and device.
  • HTTPS Hypertext Transfer Protocol Secure
  • TLS Transport Layer Security
  • TLS can encrypt data packets using symmetric encryption, that is, the server sends the static key to the client through TLS, so that the client and the server share the same static key.
  • the data transmission party encrypts the plaintext (that is, the original data) and the static key together through a special encryption algorithm, so that the plaintext becomes a complex ciphertext and sends it to the data recipient.
  • the data recipient receives the ciphertext, it decrypts the ciphertext using the static key and the inverse algorithm of the special encryption algorithm and restores it to readable plaintext to ensure the security of data transmission.
  • the embodiments of the present application provide a data transmission method, apparatus, storage medium and device, which can improve the security of data transmission.
  • a data transmission method executed by a terminal device, comprising:
  • the ciphertext and the encrypted string are sent to the server via the universal transport layer security protocol so that the The server decrypts the encrypted string to obtain the dynamic key, and decrypts the ciphertext according to the dynamic key to obtain decrypted data.
  • a data transmission method executed by a server device, comprising:
  • the encrypted string is decrypted to obtain the dynamic key, and the ciphertext is decrypted based on the dynamic key to obtain decrypted data.
  • a data transmission device comprising:
  • a first sending unit configured to send a handshake request to the server through a dedicated transport layer security protocol between the applet and the server, wherein the dedicated transport layer security protocol has higher security than a general transport layer security protocol;
  • a first receiving unit configured to receive, through the dedicated transport layer security protocol, a dynamic key returned by the server according to the handshake request and an encrypted string obtained according to the dynamic key;
  • An encryption unit used for acquiring data to be sent, and encrypting the data by using the dynamic key to obtain a ciphertext
  • the second sending unit is used to send the ciphertext and the encrypted string to the server through the universal transport layer security protocol, so that the server decrypts the encrypted string to obtain the dynamic key, and decrypts the ciphertext according to the dynamic key to obtain decrypted data.
  • a data transmission device comprising:
  • a first receiving unit configured to receive a handshake request sent by the applet through a dedicated transport layer security protocol, wherein the dedicated transport layer security protocol has higher security than a general transport layer security protocol;
  • a generating unit configured to generate a random dynamic key according to the handshake request, and obtain an encrypted string according to the dynamic key
  • a returning unit used to return the dynamic key and the encrypted string to the applet through the dedicated transport layer security protocol, so that the applet encrypts the data to be sent according to the dynamic key to obtain a ciphertext
  • a second receiving unit configured to receive the ciphertext and the encrypted string sent by the applet via the universal transport layer security protocol
  • a decryption unit configured to decrypt the encrypted string to obtain the dynamic key, and decrypt the encrypted string based on the dynamic key. Text, get the decrypted data.
  • a computer-readable storage medium stores a plurality of instructions, wherein the instructions are suitable for a processor to load to execute the steps in the above-mentioned data transmission method.
  • a computer device comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps in the above data transmission method when executing the computer program.
  • a computer program product or a computer program the computer program product or the computer program comprises computer instructions, the computer instructions are stored in a storage medium.
  • a processor of a computer device reads the computer instructions from the storage medium, and the processor executes the computer instructions, so as to implement the steps in the above data transmission method.
  • FIG1 is a schematic diagram of a protocol structure of a data transmission method provided in some embodiments of the present application.
  • FIG. 2 is a schematic diagram of a scenario of a data transmission system provided in some embodiments of the present application.
  • FIG3 is a scenario diagram of a login system provided in some embodiments of the present application.
  • FIG. 4 is a schematic diagram of a scenario of a virtual resource payment system provided in some embodiments of the present application.
  • FIG5 is a flow chart of a data transmission method provided in some embodiments of the present application.
  • FIG6 is a schematic diagram of a scenario of a data transmission method provided in some embodiments of the present application.
  • FIG7 is another specific flow chart of step 203 in FIG5 ;
  • FIG8 is a schematic diagram of another scenario of the data transmission method provided in some embodiments of the present application.
  • FIG9 is a flow chart of a data transmission method provided in some embodiments of the present application.
  • FIG10 is another specific flow chart of step 405 in FIG9 ;
  • FIG. 11 is an interactive schematic diagram of a data transmission method provided in some embodiments of the present application.
  • FIG12 is an interactive flow chart of a data transmission method provided in some embodiments of the present application.
  • FIG. 14 is a schematic diagram of the structure of a data transmission device provided in some embodiments of the present application.
  • FIG. 15 is a schematic diagram of the structure of a terminal provided in some embodiments of the present application.
  • FIG16 is a schematic diagram of the structure of a server provided in some embodiments of the present application.
  • a separate license or separate consent for the data to be encrypted and other related data will be obtained through a pop-up window or by jumping to a confirmation page.
  • the necessary data to be encrypted and other related data required to enable the normal operation of the embodiment of the present application will be obtained.
  • Transmission Control Protocol/Internet Protocol refers to a protocol suite that can realize information transmission between multiple different networks.
  • TCP/IP protocol does not only refer to TCP and IP protocols, but also refers to a protocol suite composed of File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP), TCP, User Datagram Protocol (UDP), Internet Protocol (IP) and other protocols. It is called TCP/IP protocol because TCP and IP are the most representative in TCP/IP protocol. It is also called network communication protocol, which is the most basic communication protocol in the use of network.
  • Hypertext Transfer Protocol is an application layer protocol for distributed, collaborative and hypermedia information systems. It is a request-and-response, stateless, application layer protocol that transmits data based on the TCP/IP protocol. HTTP allows the transmission of any type of data object.
  • Mini Program An application that can be used in an instant messaging client without downloading or installing.
  • Symmetric encryption refers to the process of encrypting and decrypting data using the same key.
  • Uniform resource locator is a method of indicating the location of information on the World Wide Web service program of the Internet, which can be understood as an access URL.
  • TLS Transport Layer Security protocol
  • Managed Mode Transport Layer Security is a transport layer security protocol based on TLS. It uses TLS for encryption and authentication at the transport layer. Unlike traditional TLS, MMTLS uses a managed model, which means that part of the control of TLS is handed over to the application layer.
  • the TLS protocol implemented in the instant messaging client provides confidentiality and data integrity between the instant messaging client and the server.
  • the MMTLS will not trust self-signed certificates, but only the certificates carried by the instant messaging client.
  • the entire MMTLS protocol is highly customized, so existing packet capture tools cannot perform packet capture analysis. That is, because MMTLS is customized, existing packet capture tools cannot capture the specific content of MMTLS, so the subsequent transmission of dynamic keys through the MMTLS is safe.
  • FIG. 1 is a schematic diagram of the protocol structure of the data transmission method provided in an embodiment of the present application.
  • the TCP/IP adopts a layered design mode, and divides the protocol into four levels from top to bottom, namely:
  • Application layer A is the highest level protocol in the TCP/IP protocol family. It provides communication services between object interfaces and applications. For example, HTTP is in the application layer, as well as FTP, SMTP and other protocols. Application layer protocols are protocols that interact directly with objects. They process specific types of data and hand it over to the next layer of protocols for processing.
  • Transport layer B provides end-to-end data transmission services, such as TCP and UDP protocols.
  • the transport layer protocol is responsible for transferring data from the application layer to the network layer and ensuring data transmission reliability, flow control, error detection and other functions.
  • Network Layer C mainly provides data packet transmission services in the network, such as IP protocol.
  • the network layer protocol is responsible for transferring data packets from the source host to the destination host, and realizes data transmission between different networks through technologies such as routing selection and forwarding.
  • Link Layer D refers to the transmission of data on the physical layer, such as Ethernet, Wi-Fi and other protocols.
  • the link layer protocol is responsible for transferring data from the network layer to the physical layer, and transmitting it to the receiving host through the physical layer.
  • the physical layer (unlabeled) is responsible for the transmission of bit streams between nodes, that is, for physical transmission.
  • the protocol is related to both the link and the transmission medium. In layman's terms, it is the physical means of connecting computers.
  • the MMTLS is between the application layer and the network layer, does not affect the original network strategy, and is implemented based on TCP.
  • the handshake protocol is to negotiate the algorithm suite and encryption key used for encryption before encrypted communication, which is similar to the courtesy handshake that is usually required before two strangers start chatting.
  • HTTPS HyperText Transfer Protocol
  • HTTPS HyperText Transfer Protocol
  • TLS can encrypt data packets using symmetric encryption, that is, the server sends the static key to the client through TLS, so that the client and the server share the same static key.
  • the data transmission party encrypts the plaintext and the static key together through a special encryption algorithm, so that the plaintext becomes a complex ciphertext and sends it to the data recipient.
  • the data recipient After the data recipient receives the ciphertext, it decrypts the ciphertext through the static key and the inverse algorithm of the special encryption algorithm and restores it to readable plaintext to ensure the security of data transmission.
  • the static key used in this data transmission method is easily analyzed and cracked because it is directly transmitted through TLS, and can be obtained by attackers through attack methods.
  • the static key is fixed, once the attacker successfully obtains it, all ciphertexts will be easily cracked, causing data leakage.
  • the embodiments of the present application propose a method of transmitting a dynamic key and an encrypted string obtained by encrypting the dynamic key through a dedicated transport layer security protocol with higher security, encrypting the data to be sent through the dynamic key to generate a corresponding ciphertext, and sending the ciphertext and the encrypted string to the server through a general transport layer security protocol, so that the server decrypts the encrypted string to obtain the dynamic key, and decrypts the ciphertext to obtain the decrypted data, thereby ensuring that the dynamic key is not intercepted by an attacker, and sending the dynamic key to the server through a general transport layer security protocol in the form of an encrypted string, thereby avoiding the dynamic key from being transmitted in plain text, effectively preventing the dynamic key from being cracked, and improving the security of data transmission.
  • FIG. 2 is a schematic diagram of a scenario of a data transmission system provided in some embodiments of the present application, including a terminal 140 , the Internet 130 , a gateway 120 , a server 110 , and the like.
  • the terminal 140 includes but is not limited to mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle-mounted terminals, aircraft, etc.
  • the embodiments of the present application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, assisted driving, etc.
  • it can be a single device or a combination of multiple devices.
  • multiple desktop computers are interconnected through a local area network, share a display, etc. to work together, and together constitute a terminal 140.
  • the terminal 140 can communicate with the Internet 130 in a wired or wireless manner to exchange data.
  • the server 110 is a computer system that can provide certain services to the terminal 140. Compared with the ordinary terminal 140, the server 110 has higher requirements in terms of stability, security, performance, etc.
  • the server 110 can be an independent physical server. It can also be a server cluster or distributed system composed of multiple physical servers. It can also 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, security services, CDN, as well as big data and artificial intelligence platforms.
  • the gateway 120 is also called an internetwork connector or a protocol converter.
  • the gateway realizes network interconnection at the transport layer and is a computer system or device that acts as a converter.
  • the gateway is a translator between two systems that use different communication protocols, data formats or languages, or even completely different architectures.
  • the gateway can also provide filtering and security functions.
  • the message sent by the terminal 140 to the server 110 must be sent to the corresponding server 110 through the gateway 120.
  • the message sent by the server 110 to the terminal 140 must also be sent to the corresponding terminal 140 through the gateway 120.
  • the embodiments of the present application can be applied in a variety of scenarios, such as the scenario of the login system shown in FIG. 3 and the scenario of the virtual resource payment system shown in FIG. 4 .
  • the login system can realize the login function and complete login-related services.
  • the object can enter the account and password to log in.
  • the interface 11 can be the interface of the mini-program end.
  • the terminal When the interface 11 of the login system is opened and displayed, the terminal will generate a handshake request and send a handshake request to the server through a dedicated transport layer security protocol between the mini-program end and the server.
  • the dedicated transport layer security protocol has higher security than the general transport layer security protocol; the dynamic key returned by the server according to the handshake request and the encrypted string obtained by encryption based on the dynamic key are received through the dedicated transport layer security protocol; the data to be sent (which can be understood as the login account data and password data) is obtained, and the data is encrypting the data through the dynamic key to generate a ciphertext; the ciphertext and the encrypted string are sent to the server through the general transport layer security protocol, so that the server decrypts the encrypted string to obtain the dynamic key, and decrypts the ciphertext according to the dynamic key to obtain the decrypted data.
  • the virtual resource payment system can realize the payment function and complete payment-related services.
  • the object can enter the virtual resources required to pay for the goods, such as 1000, and the payment password, such as 123456, and click the order button to realize the payment function.
  • the interface 12 can be the interface of the mini-program end.
  • the terminal When the interface 12 of the virtual resource payment system is opened and displayed, the terminal will generate a handshake request and send a handshake request to the server through the dedicated transport layer security protocol between the mini-program end and the server.
  • the dedicated transport layer security protocol has higher security than the general transport layer security protocol; the dynamic key returned by the server according to the handshake request and the encrypted string obtained by encryption based on the dynamic key are received through the dedicated transport layer security protocol; the data to be sent (which can be understood as the virtual resource data and payment password data for payment) are obtained, and the data is encrypting the data through the dynamic key to generate ciphertext; the ciphertext and the encrypted string are sent to the general transport layer security protocol.
  • 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.
  • scenario diagram of the data transmission system shown in Figure 2 is only an example.
  • the data transmission system and scenario described in the embodiment of the present application are for more clearly illustrating the technical solution of the embodiment of the present application, and do not constitute a limitation on the technical solution provided in the embodiment of the present application.
  • Ordinary technicians in this field can know that with the evolution of the data transmission system and the emergence of new business scenarios, the technical solution provided in the embodiment of the present application is also applicable to similar technical problems.
  • the description will be made from the perspective of a data transmission device, which can be integrated into a computer device having a storage unit and a microprocessor and having computing power, and the computer device can be a terminal, in which an instant messaging client can be installed, and on which a small program can be run, and in this embodiment, the small program running on the terminal is used for description.
  • the server interacting with the terminal can be an instant messaging server.
  • the data transmission method includes:
  • step 201 a handshake request is sent to the server via a dedicated transport layer security protocol between the applet and the server.
  • TLS can encrypt data packets using symmetric encryption, that is, the server sends the static key to the client through TLS, so that the client and the server share the same static key.
  • the data transmission party encrypts the plaintext and the static key together through a special encryption algorithm, turning the plaintext into complex ciphertext and sending it to the data receiver.
  • the data receiver decrypts the ciphertext using the static key and the inverse algorithm of the special encryption algorithm and restores it to readable plaintext to ensure the security of data transmission.
  • TLS can only provide security at the transport layer.
  • packet capture and analysis tools the simple use of TLS cannot resist packet capture and analysis tools based on self-signed certificates and is still vulnerable to attacks.
  • the mini program in the embodiment of the present application relies on the instant messaging client, that is, the instant messaging client can serve as the running container of the mini program, and the mini program runs on the instant messaging client, so the mini program can directly call the corresponding dedicated transport layer security protocol of the instant messaging client.
  • the embodiment of the present application can send a handshake request to the server through a dedicated transport layer security protocol between the applet and the server, that is, a dedicated transport layer security protocol.
  • the handshake request may carry the applet identifier and the instant messaging client version of the applet, so that the server can identify whether the handshake request is sent by a normally usable applet and instant messaging client version according to the applet identifier and the instant messaging client version.
  • the dedicated transport layer security protocol Since the entire dedicated transport layer security protocol is highly customized, existing packet capture tools cannot perform packet capture analysis. That is, because the dedicated transport layer security protocol is customized, existing packet capture tools cannot capture the handshake request of the dedicated transport layer security protocol, preventing attackers from monitoring the handshake request of the applet. Therefore, the dedicated transport layer security protocol has higher security than the general transport layer security protocol.
  • the mini program on the terminal 140 may send a handshake request to the server via a dedicated transport layer security protocol between the mini program and the server to ensure the privacy of the handshake request.
  • step 202 a dynamic key returned by the server according to the handshake request and an encrypted string obtained according to the dynamic key are received through a dedicated transport layer security protocol.
  • the server after the server receives the handshake request sent by the applet through the dedicated transport layer security protocol, it can generate a random dynamic key according to the handshake request.
  • the dynamic key can be randomly generated by a secure random number generator in the server, and the length can be 128 or 256 bits, etc.
  • the embodiment of the present application generates different dynamic keys based on different handshake requests, that is, the dynamic key changes in real time, so as to better resist cracking by attackers.
  • the server can encrypt the dynamic key according to the set encryption rules to obtain the corresponding encrypted string.
  • the server can return the dynamic key and the encrypted string to the mini-program in the embodiment of the present application through the dedicated transport layer security protocol.
  • the embodiment of the present application can receive the dynamic key returned by the server and the encrypted string encrypted based on the dynamic key through the dedicated transport layer security protocol to achieve handshake, that is, to establish a connection between the mini-program and the server.
  • the entire dedicated transport layer security protocol is highly customized, existing packet capture tools cannot perform packet capture analysis. That is, because the dedicated transport layer security protocol is customized, existing packet capture tools cannot capture the dynamic key and encrypted string transmitted by the dedicated transport layer security protocol, which better ensures the security of the dynamic key.
  • the server 110 can generate a random dynamic key according to the handshake request, and generate an encrypted string token based on the secret (i.e., the dynamic key) through the aes_encrypt(token, secret) function, and transmit the dynamic key and the encrypted string containing the dynamic key to the small terminal 140 through the dedicated transport layer security protocol.
  • Program, accordingly, the applet on the terminal 140 can receive the dynamic key and the encrypted string containing the dynamic key.
  • each dynamic key has a corresponding validity period, that is, after the dynamic key reaches the validity period, the dynamic key will become invalid accordingly, and the applet needs to resend the handshake request and re-receive the updated dynamic key and encryption string through the dedicated transport layer security protocol, so that the dynamic key can be updated regularly to better avoid analysis by attackers.
  • the validity period can be set manually, for example 15 minutes or 30 minutes.
  • the mini program can be applied to different scenarios, such as login scenario, ordering scenario and information browsing scenario.
  • the login scenario represents that the object uses the mini program to log in to the account
  • the ordering scenario represents that the object uses the mini program to place an order for goods
  • the information browsing scenario represents that the object uses the mini program to browse information.
  • Each scenario has different security requirements. For example, the security required for the login scenario is higher than that for the ordering scenario, and the security required for the ordering scenario is higher than that for the information browsing scenario. Based on this, different validity periods can be set for the dynamic keys allocated in each scenario.
  • the handshake request can carry a corresponding scenario type, which indicates the corresponding scenario of the mini program when the handshake request is generated.
  • the scenario type may include but is not limited to a login scenario type, an ordering scenario type, or an information browsing scenario type.
  • the scenario type carried by the handshake request is a login scenario type.
  • the scenario type carried by the handshake request is an ordering scenario type.
  • the scenario type carried by the handshake request is an information browsing scenario type.
  • the method further comprises:
  • the effective time is the time determined by the server according to the scenario type carried in the handshake request.
  • the server can automatically match the corresponding valid time according to the scene type while determining the corresponding dynamic key.
  • the mapping relationship between the scene type and the valid time is shown in Table 1.
  • Table 1 is a preset mapping table, which includes the mapping relationship between different scene types and valid times. Assuming that the scene type is a login scene type, the valid time obtained is 5 minutes. Assuming that the scene type is an ordering scene type, the valid time obtained is 10 minutes. Assuming that the scene type is an information browsing scene type, the valid time obtained is 30 minutes.
  • the server can return the dynamic key, the corresponding validity time of the dynamic key and the encrypted string to the mini program through a dedicated transport layer security protocol.
  • the mini program can receive the dynamic key, the corresponding validity time of the dynamic key and the encrypted string obtained by encryption based on the dynamic key returned by the server according to the handshake request through a dedicated transport layer security protocol.
  • the validity time of the corresponding dynamic key can be flexibly set according to the security requirements of different scenario types when the mini program initiates a handshake request, thereby improving the flexibility of the validity time setting.
  • the application scenario of the mini program since the application scenario of the mini program can change in real time, for example, the application scenario of the mini program switches from the ordering scenario type to the login scenario type. Due to the change in scenario, the requirements for the validity period of the dynamic key are also different. Therefore, after the mini program receives the dynamic key returned by the server according to the handshake request, the corresponding validity period of the dynamic key, and the encrypted string obtained by encrypting the dynamic key through a dedicated transport layer security protocol, it is also necessary to monitor the change of the scenario type in real time to ensure the real-time update of the dynamic key, which specifically includes the following methods:
  • the dynamic key, the corresponding validity period of the dynamic key, and the encrypted string obtained by encrypting the dynamic key are deleted;
  • Re-execute sending a handshake request to the server through the dedicated transport layer security protocol between the applet and the server to re-receive the updated dynamic key, validity time and encryption string through the dedicated transport layer security protocol.
  • the mini program can continuously detect whether the scene type has changed. When a change in the scene type is detected, it indicates that the scene has changed, and the currently stored dynamic key, the corresponding validity period of the dynamic key, and the encrypted string obtained by encryption based on the dynamic key need to be deleted.
  • the dynamic key needs to be updated. Therefore, the above embodiment can be re-executed to re-receive the updated dynamic key, validity period and encryption string under the changed scenario type. In this way, it is ensured that the dynamic key can change in real time as the scenario of the mini-program application changes, thereby improving the flexibility of the dynamic key update.
  • the mini program can be applied to different scenarios, such as login scenarios, ordering scenarios, and information browsing scenarios.
  • the login scenario represents that the object logs in to the account through the mini program
  • the ordering scenario represents that the object orders goods through the mini program
  • the information browsing scenario represents that the object browses information through the mini program.
  • Each scenario has different security requirements. For example, the security required for the login scenario is higher than that for the ordering scenario, and the security required for the ordering scenario is higher than that for the information browsing scenario.
  • mini programs such as office-type mini programs, game-type mini programs, or life-type mini programs
  • each type of mini program has different security requirements.
  • office-type mini programs require higher security than life-type mini programs
  • life-type mini programs require higher security than game-type mini programs. Based on this, different effective times can be flexibly set in combination with the application scenarios of the mini programs and the types of the mini programs.
  • the handshake request can carry both the scenario type and the application privacy level.
  • the scenario type indicates the corresponding scenario of the mini program when the handshake request is generated.
  • the scenario type may include but is not limited to the login scenario type, the ordering scenario type, or the information browsing scenario type.
  • the scenario type carried by the handshake request is the login scenario type.
  • the scenario type carried by the handshake request is the ordering scenario type.
  • the scenario type carried by the handshake request is the information browsing scenario type.
  • the application privacy level indicates the privacy level corresponding to the type of the mini-program when generating a handshake request.
  • the application privacy level includes but is not limited to high, medium and low levels. In this way, the application privacy level of the mini-program of the office type can be set to high, the application privacy level of the mini-program of the life type can be set to medium, and the application privacy level of the mini-program of the game type can be set to low.
  • the mini-program type is the office type and a handshake request is generated
  • the application privacy level carried by the handshake request is high.
  • the mini-program type is the life type and a handshake request is generated
  • the application privacy level carried by the handshake request is medium.
  • the mini-program type is the game type and a handshake request is generated, the application privacy level carried by the handshake request is low.
  • the method may include:
  • the effective time is the time determined by the server according to the scenario type and application privacy level carried in the handshake request.
  • the server when the server determines the corresponding dynamic key, it can match the scene type with Table 1 (i.e., the preset mapping table) to determine the initial validity period of the dynamic key. Assuming that the scene type carried by the handshake request is an order scene type, it can be determined that the initial validity period of the dynamic key is 10 minutes.
  • Table 1 i.e., the preset mapping table
  • the server can also automatically match the corresponding weight according to the application privacy level.
  • the mapping relationship between the application privacy level and the weight is shown in Table 2. Assuming that the application privacy level is high, the weight obtained is 0.6. Assuming that the application privacy level is medium, the weight obtained is 0.8. Assuming that the application privacy level is low, the weight obtained is 1, that is, the higher the application privacy level, the lower the weight, and the lower the application privacy level, the higher the weight.
  • the initial valid time obtained by the previous match is weighted to obtain the final valid time of the dynamic key. Assuming that the application privacy level carried by the handshake request is medium, the initial valid time of 10 minutes is weighted according to the weight 0.8 obtained by the match, and the final valid time is 8 minutes.
  • the server can return the dynamic key, the corresponding validity time of the dynamic key and the encrypted string to the mini program through a dedicated transport layer security protocol.
  • the mini program can receive the dynamic key, the corresponding validity time of the dynamic key, and the encrypted string obtained by encrypting the dynamic key returned by the server according to the handshake request through a dedicated transport layer security protocol.
  • the applet may receive the dynamic key returned by the server according to the handshake request, the corresponding validity period of the dynamic key, and the encrypted string obtained by encrypting the dynamic key through a dedicated transport layer security protocol, and further needs to monitor the validity period of the dynamic key in real time to ensure the real-time update of the dynamic key, specifically including the following methods:
  • the handshake request is sent to the server through the dedicated transport layer security protocol between the applet and the server again to re-receive the updated dynamic key, valid time and encryption string through the dedicated transport layer security protocol.
  • the server can also send the generation time of the dynamic key to the mini program at the same time, so that the mini program can calculate the effective expiration time based on the generation time and effective time of the dynamic key. For example, if the generation time of the dynamic key is 11:51:00 on October 8, 2023, and the effective time is 8 minutes, then the effective expiration time is 11:59:00 on October 8, 2023.
  • the mini program can continuously detect whether the current time has reached the effective expiration time. When it is detected that the current time has not reached the effective expiration time, it means that the dynamic key is still valid. On the contrary, when it is detected that the current time has reached the effective expiration time, it means that the dynamic key has expired.
  • the dynamic key needs to be updated. Therefore, the above embodiment can be re-executed to re-receive the updated dynamic key, effective time and encryption string. In this way, it is ensured that the dynamic key can be updated regularly according to the effective time, the variability of the dynamic key is increased, and the difficulty of cracking is increased.
  • the server after the server generates a dynamic key and obtains the validity period of the dynamic key, it can determine the timestamp of the dynamic key according to the validity period.
  • the timestamp can include the issue time (iat) and expiration time (expire atime, 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, then the expiration time is 11:51 on October 8, 2023. 59:00.
  • the identity of the mini program which can be the account ID logged in on the instant messaging client that the mini program relies on, such as account ID 12345, and then obtain the triple of [dynamic key, identity ID, timestamp], and perform symmetric encryption processing on the [dynamic key, identity ID, timestamp] based on the preset key to obtain the corresponding encrypted string, so that the dynamic key can be subsequently transmitted in the form of an encrypted string on the general transport layer security protocol, avoiding the dynamic key from being transmitted in plain text, and improving the security of dynamic key transmission.
  • the symmetric encryption processing can be an AES (Advanced Encryption Standard) encryption algorithm (Advanced Encryption Standard algorithm).
  • the AES encryption algorithm can use 128-bit, 192-bit or 256-bit keys to encrypt and decrypt data, and has the advantages of high strength, high speed and easy implementation.
  • the preset key is a 128-bit, 192-bit or 256-bit key used for encryption. Unlike the symmetric encryption in the related technology, the preset key does not need to be transmitted to the terminal, but only needs to be retained inside the server, thereby preventing the preset key from being leaked.
  • step 203 the data to be sent is obtained, and the data is encrypted by a dynamic key to generate a corresponding ciphertext.
  • the data to be sent is the plaintext to be sent, which is the data that the mini program needs to send to the server. It can be the login account password, or the password used for payment.
  • This data is very confidential to the object. If it is transmitted directly in plain text, it can be easily intercepted and analyzed by attackers, and the confidential data of the object can be easily obtained, causing economic losses to the object and data leakage.
  • the embodiment of the present application can symmetrically encrypt the data through the dynamic key received through the dedicated transport layer security protocol to generate the corresponding ciphertext. In this way, even if the attacker intercepts the ciphertext, he will not be able to crack it because he does not have the dynamic key, thereby avoiding economic losses and data leakage to the target.
  • step 203 includes:
  • Step 301 obtaining data to be sent, generating an encryption initialization vector for the data, and performing an XOR operation on the data according to the encryption initialization vector to obtain an XOR result;
  • Step 302 Encrypt the XOR result using the dynamic key to obtain the ciphertext.
  • CBC Cipher Block Chaining mode
  • Grouping means that the encryption and decryption processes are performed in the form of groups. The size of each group is 128 bits (16 bytes). If the length of the plaintext is not an integer multiple of 16 bytes, the last group needs to be padded (padding) so that the length of the last group is 16 bytes.
  • Link means that the ciphertext groups are connected to each other like a chain.
  • an initialization vector IV is required (that is, the encryption initial vector in the embodiment of the present application). Therefore, the data to be sent (that is, the plaintext) can be obtained, and the encryption initial vector can be generated. The encryption initial vector can be randomly generated for the mini program. A numerical value is converted into an encrypted initial vector.
  • One-Hot coding can be used for the conversion. For sequence data with discrete values, One-Hot coding can be used to represent each value as a vector.
  • generating an encryption initialization vector corresponding to the data may further include:
  • the random number is combined with the message sequence number to generate a corresponding encryption initialization vector.
  • a random number Nonce may be generated, such as 20 or 30, and a message sequence number Seq may be generated according to the data generation order, such as 1, 2 or 3, etc.
  • Nonce+Seq may be combined to generate a corresponding encryption initialization vector through One-Hot encoding. Since the random number and the message sequence number are both dynamically changing, the encryption initialization vector is also constantly changing, ensuring that the same plaintext is encrypted multiple times in real time, and the ciphertext obtained in the end is also different, which increases the difficulty for attackers to crack.
  • step 301 includes:
  • For a first data group performing an XOR operation on the encryption initialization vector and the first data group to obtain a first XOR result of the first data group;
  • the sub-ciphertext of the previous data packet of the data packet is XORed with the data packet to obtain a second XOR result of each data packet in the other data packets.
  • Step 302 includes:
  • the sub-ciphertexts corresponding to a plurality of the data groups are combined into a ciphertext.
  • the data can be grouped in a manner that each group size is 128 bits (i.e., 16 bytes). It should be noted that if the length of the plaintext is not an integer multiple of 16 bytes, the last group will be padded so that the length of the last group is also 16 bytes. To better illustrate the embodiment of the present application, please refer to FIG. 8 , where the data can be divided into multiple data groups in a manner that each group size is 16 bytes.
  • exclusive OR abbreviated as xor
  • xor is a mathematical operator. It is used in logical operations.
  • the mathematical symbol of exclusive OR is The computer symbol is "xor”.
  • Its operation rules are: That is, if the values of a and b are different, the XOR result is 1. If the values of a and b are the same, the XOR result is 0.
  • XOR is also called half-addition operation, and its operation rule is equivalent to binary addition without carry.
  • the encryption initial vector can be XORed with the first data group to obtain a first XOR result of the first data group, and the first XOR result is sent to the block cipher encryption module and encrypted in combination with the dynamic key to obtain the sub-ciphertext corresponding to the first data group.
  • the sub-ciphertext corresponding to the previous data group may be XORed with the other data groups to obtain a second XOR result of the other data groups.
  • the second XOR result can be sent to the block cipher encryption module and encrypted in combination with the dynamic key to obtain sub-ciphertexts of other data groups.
  • the sub-ciphertext corresponding to the first data group can be XORed with the second data group to obtain a second XOR result of the second data group, and the corresponding second XOR result can be sent to the block cipher encryption module and encrypted in combination with the dynamic key to obtain the sub-ciphertext of the second data group.
  • the sub-ciphertext corresponding to the second data group can be XORed with the third data group to obtain the second XOR result of the third data group, and the corresponding second XOR result can be sent to the block cipher encryption module and encrypted in combination with the dynamic key to obtain the sub-ciphertext of the third data group. And so on, the sub-ciphertext of each other data group can be obtained.
  • the sub-ciphertexts corresponding to each data group can be concatenated to obtain the final ciphertext.
  • step 204 the ciphertext and the encrypted string are sent to the server via the general transport layer security protocol.
  • the transmission capacity of the dedicated transport layer security protocol is limited, the transmission of ciphertext and encrypted string needs to be transmitted through the general transport layer security protocol, that is, the applet can send the ciphertext and encrypted string to the server through the general transport layer security protocol.
  • the terminal 140 encrypts the data using a dynamic key to obtain a corresponding ciphertext, and transmits the ciphertext to the server 110 via the universal transport layer security protocol, and the encrypted string token can be placed in a URL to be transmitted to the server 110 .
  • the server After receiving the ciphertext and encrypted string, the server can decrypt the encrypted string according to the preset key to obtain the dynamic key. Thereby, the ciphertext can be decrypted according to the dynamic key to obtain the corresponding data (i.e. plain text), thereby achieving secure communication and effectively protecting the integrity and security of the data from the mini program to the server, preventing attackers from decrypting and cracking the data.
  • the server After receiving the ciphertext and encrypted string, the server can decrypt the encrypted string according to the preset key to obtain the dynamic key.
  • the ciphertext can be decrypted according to the dynamic key to obtain the corresponding data (i.e. plain text), thereby achieving secure communication and effectively protecting the integrity and security of the data from the mini program to the server, preventing attackers from decrypting and cracking the data.
  • the applet is encrypted using the AES encryption algorithm and CBC (Cipher Block Chaining) mode, the data is encrypted by a dynamic key. Therefore, the applet also needs to send the encryption initial vector to the server, that is, step 204 further includes:
  • the encryption initialization vector is sent to the server via the general transport layer security protocol.
  • the applet can send the encryption initialization vector, ciphertext and the encrypted string to the server through the transport layer security protocol, so that after receiving the encryption initialization vector, ciphertext and the encrypted string, the server can decrypt the encrypted string according to the preset key, restore the dynamic key, and combine the dynamic key with the encryption initialization vector to decrypt the ciphertext.
  • the specific processing process is:
  • the ciphertext is grouped in a manner that each group size is 128 bits (i.e., 16 bytes) to obtain multiple ciphertext subgroups.
  • For the first ciphertext subgroup it is decrypted by the dynamic key to obtain a first decryption result, and the first decryption result is XORed with the encryption initial vector to obtain a sub-plaintext corresponding to the first ciphertext subgroup.
  • the second ciphertext subgroup For the second ciphertext subgroup, it can be decrypted by the dynamic key to obtain a second decryption result, and the sub-ciphertext of the previous ciphertext subgroup (i.e., the first ciphertext subgroup) is XORed with the second decryption result to obtain a sub-plaintext corresponding to the second ciphertext subgroup.
  • the third ciphertext subgroup it can be decrypted by the dynamic key to obtain a third decryption result, and the sub-ciphertext of the previous ciphertext subgroup (i.e., the second ciphertext subgroup) is XORed with the third decryption result to obtain a sub-plaintext corresponding to the third ciphertext subgroup.
  • the sub-plaintext of each ciphertext subgroup can be obtained.
  • each ciphertext subgroup can be concatenated to obtain data.
  • the embodiment of the present application sends a handshake request to the server through a dedicated transport layer security protocol between the mini program and the server, and the dedicated transport layer security protocol has higher security than the general transport layer security protocol; receives the dynamic key returned by the server according to the handshake request and the encrypted string obtained by encryption based on the dynamic key through the dedicated transport layer security protocol; obtains the data to be sent, and encrypts the data through the dynamic key to generate the corresponding ciphertext; sends the ciphertext and the encrypted string to the server through the general transport layer security protocol, so that the server decrypts the ciphertext according to the dynamic key restored by decrypting the encrypted string to obtain the decrypted data.
  • the dynamic key and the encrypted string obtained by encryption processing based on the dynamic key are received through a dedicated transport layer with higher security than the general transport layer security protocol, the data to be sent is encrypted by the dynamic key to generate corresponding ciphertext, and the ciphertext and the encrypted string are sent to the server through the general transport layer security protocol, so that the server decrypts the ciphertext according to the dynamic key restored by decrypting the encrypted string to obtain the decrypted data.
  • the embodiment of the present application can receive the dynamic key through a more secure dedicated transport layer security protocol to ensure that the dynamic key is not intercepted by attackers, and send the dynamic key to the server in the form of an encrypted string through the general transport layer security protocol, avoiding the dynamic key from being transmitted in plain text, effectively preventing the dynamic key from being cracked, and improving the security of data transmission.
  • the description will be made from the perspective of a data transmission device.
  • the data transmission device can be specifically integrated in a computer device having a storage unit and a microprocessor installed therein and having computing capabilities.
  • the computer device can be a server, that is, a server is used for description in this embodiment.
  • FIG. 9 is a flow chart of a data transmission method provided by an embodiment of the present application.
  • the method flow may include:
  • step 401 a handshake request sent by the applet via a dedicated transport layer security protocol is received.
  • the server can receive a handshake request sent by the mini program through a dedicated transport layer security protocol.
  • the handshake request can carry the mini program identifier and instant messaging client version of the mini program.
  • the server can verify whether the mini program identifier and instant messaging client version can be used normally. When it is verified that the mini program identifier or the instant messaging client version cannot be used normally, for example, the mini program identifier is wrong or the instant messaging client version is too low, the handshake request will not be responded to.
  • step 402 when it is verified that the applet identifier and the instant messaging client can be used normally, the handshake request is responded to and step 402 is executed.
  • step 402 a random dynamic key is generated according to the handshake request, and a corresponding encryption string is obtained according to the dynamic key.
  • the server generates a random dynamic key according to the secure random number generator in response to the handshake request, and the length of the dynamic key can be 128 bits or 256 bits, etc. That is, the dynamic key changes in real time and can better resist cracking by attackers.
  • the server can encrypt the dynamic key according to the set encryption rules to obtain the corresponding encrypted string.
  • the dynamic key in order to achieve better data protection, it can be stipulated that the dynamic key has a corresponding validity period, that is, after the dynamic key reaches the validity period, the dynamic key will become invalid accordingly, and the mini program needs to resend the handshake request.
  • the server will generate an updated dynamic key and encryption string based on the resent handshake request and send it to the mini program, so that the dynamic key can be updated regularly to better avoid analysis by attackers.
  • step 402 may include:
  • the identity of the applet is obtained, and the dynamic key, the identity and the timestamp are encrypted to obtain a corresponding encrypted string.
  • the validity period can be manually set, for example, 15 minutes or 30 minutes by default. In the embodiment of the present application, 30 minutes is used as an example for explanation.
  • the server can respond to the handshake request, generate a random 256-bit dynamic key, and And determine that the validity period of the dynamic key is 30 minutes.
  • the timestamp of the dynamic key can be determined based on the valid time.
  • the timestamp can include the dynamic key production time (issue atime, iat) and expiration time (expire atime, exp). For example, if the production time is 11:50:00 on October 8, 2023 and the valid time is 30 minutes, then the expiration time is 12:20:00 on October 8, 2023.
  • the identity of the mini program that sends the handshake request can also be obtained.
  • the identity can be the account ID logged in on the instant messaging client that the mini program relies on, such as account ID 12345, and then the triple of [dynamic key, identity, timestamp] can be obtained.
  • the [dynamic key, identity, timestamp] can be symmetrically encrypted based on the preset key to obtain the corresponding encrypted string.
  • the dynamic key can be subsequently transmitted in the form of an encrypted string on the general transport layer security protocol, avoiding the transmission of the dynamic key in plain text, thereby improving the security of dynamic key transmission.
  • the symmetric encryption processing can be an AES (Advanced Encryption Standard) encryption algorithm (Advanced Encryption Standard algorithm).
  • AES Advanced Encryption Standard
  • the AES encryption algorithm will use 128-bit, 192-bit or 256-bit keys to encrypt and decrypt data. It has the advantages of high strength, high speed and easy implementation.
  • the preset key is a 128-bit, 192-bit or 256-bit key used for encryption. Unlike the symmetric encryption in the related technology, the preset key does not need to be transmitted to the terminal, but only needs to be retained inside the server, thereby preventing the preset key from being leaked.
  • the encrypted string can be a binary ciphertext, and the length of the data will be very large, affecting the transmission speed.
  • the subsequent applet since the subsequent applet also needs to place the encrypted string in the URL and transmit it back to the server, and the URL only supports a limited character set and cannot encode binary ciphertext, it is also necessary to simplify the encrypted string, that is, encrypt the dynamic key, identity and timestamp to obtain the corresponding encrypted string, including:
  • the dynamic key, the identity identifier and the timestamp are encrypted according to the preset key to obtain an initial encrypted string;
  • the initial encrypted string is converted into an encoding using a preset number of printable characters to obtain a corresponding encrypted string.
  • the preset number of printable characters can be understood as Base64 encoding, which is one of the most common encoding methods for transmitting 8-bit bytecodes. It is a method of representing binary data based on 64 printable characters.
  • the encoding set consists of 64 characters: 26 uppercase letters A to Z, 26 lowercase letters a to z, 10 numbers 0 to 9, the symbol "+” and the symbol "/”.
  • the [dynamic key, identity, timestamp] is symmetrically encrypted to obtain the initial encrypted string, which is the binary ciphertext.
  • the mini program can be applied to different scenarios, such as login scenario, ordering scenario and information browsing scenario.
  • the login scenario represents that the object uses the mini program to log in to the account
  • the ordering scenario represents that the object uses the mini program to place an order for goods
  • the information browsing scenario represents that the object uses the mini program to browse information.
  • Each scenario has different security requirements. For example, the security required for the login scenario is higher than that for the ordering scenario, and the security required for the ordering scenario is higher than that for the information browsing scenario. Based on this, different validity periods can be set for the dynamic keys allocated in each scenario.
  • the handshake request sent by the mini program can carry a corresponding scenario type, which indicates the corresponding scenario of the mini program when the handshake request is generated.
  • the scenario type may include but is not limited to a login scenario type, an ordering scenario type, or an information browsing scenario type.
  • the scenario type carried by the handshake request is a login scenario type.
  • the scenario type carried by the handshake request is an ordering scenario type.
  • the scenario type carried by the handshake request is an information browsing scenario type.
  • determining the validity period of the dynamic key may include:
  • the preset mapping table includes mapping relationships between different scene types and effective times.
  • the preset mapping table can refer to the previous Table 1, and the server can quickly match the corresponding validity period of the generated dynamic key according to the scenario type carried in the handshake request. Assuming that the scenario type carried by the handshake request is an order scenario type, it can be determined that the initial validity period of the dynamic key is 10 minutes.
  • the mini program can be applied to different scenarios, such as login scenarios, ordering scenarios, and information browsing scenarios.
  • the login scenario represents that the object logs in to the account through the mini program
  • the ordering scenario represents that the object orders goods through the mini program
  • the information browsing scenario represents that the object browses information through the mini program.
  • Each scenario has different security requirements. For example, the security required for the login scenario is higher than that for the ordering scenario, and the security required for the ordering scenario is higher than that for the information browsing scenario.
  • mini programs such as office-type mini programs, game-type mini programs, or life-type mini programs
  • each type of mini program has different security requirements.
  • office-type mini programs require higher security than life-type mini programs
  • life-type mini programs require higher security than game-type mini programs. Based on this, different effective times can be flexibly set in combination with the application scenarios of the mini programs and the types of the mini programs.
  • the handshake request can carry both the scenario type and the application privacy level.
  • the scenario type indicates the generation of the handshake.
  • the scene type may include but is not limited to the login scene type, the order scene type or the information browsing scene type.
  • the scene type carried by the handshake request is the login scene type.
  • the scene type carried by the handshake request is the order scene type.
  • the scene type carried by the handshake request is the information browsing scene type.
  • the application privacy level indicates the privacy level corresponding to the type of the mini-program when generating a handshake request.
  • the application privacy level includes but is not limited to high, medium and low levels. In this way, the application privacy level of the mini-program of the office type can be set to high, the application privacy level of the mini-program of the life type can be set to medium, and the application privacy level of the mini-program of the game type can be set to low.
  • the mini-program type is the office type and a handshake request is generated
  • the application privacy level carried by the handshake request is high.
  • the mini-program type is the life type and a handshake request is generated
  • the application privacy level carried by the handshake request is medium.
  • the mini-program type is the game type and a handshake request is generated, the application privacy level carried by the handshake request is low.
  • determining the validity period of the dynamic key may also include:
  • the preset mapping table includes mapping relationships between different scene types and effective times
  • a weight is determined according to the privacy level of the application, and the initial validity time is weighted based on the weight to obtain the validity time of the dynamic key.
  • the preset mapping table can refer to the previous Table 1, and the server can quickly match the initial validity period of the generated dynamic key according to the scenario type carried in the handshake request. Assuming that the scenario type carried by the handshake request is an order scenario type, it can be determined that the initial validity period of the dynamic key is 10 minutes.
  • the server can also automatically match the corresponding weight according to the application privacy level. Please refer to Table 2 for the mapping relationship between the application privacy level and the weight. For example, if the application privacy level carried by the handshake request is medium, then the initial valid time of 10 minutes is weighted according to the matched weight of 0.8, and the final valid time is 8 minutes.
  • step 403 the dynamic key and the encrypted string are returned to the applet via a dedicated transport layer security protocol.
  • the server can return the dynamic key and the encrypted string to the applet in the embodiment of the present application through the dedicated transport layer security protocol.
  • the applet can receive the dynamic key returned by the server and the encrypted string obtained by encryption based on the dynamic key through the dedicated transport layer security protocol to achieve handshake, that is, establish a connection between the applet and the server, so that the applet can encrypt the data to be sent (that is, plain text) according to the dynamic key.
  • handshake that is, establish a connection between the applet and the server
  • the applet can encrypt the data to be sent (that is, plain text) according to the dynamic key.
  • the entire dedicated transport layer security protocol is highly customized, existing packet capture tools cannot perform packet capture analysis. That is, because the dedicated transport layer security protocol is customized, existing packet capture tools cannot capture the dedicated transport layer security protocol.
  • the dynamic key and encryption string transmitted by the protocol can better ensure the security of dynamic key transmission.
  • the server may also return the validity period of the dynamic key to the applet, that is, return the dynamic key and the encrypted string to the applet through a dedicated transport layer security protocol, including:
  • the dynamic key, the corresponding validity period of the dynamic key and the encrypted string are returned to the applet via a dedicated transport layer security protocol.
  • the server can return the dynamic key, the corresponding validity period of the dynamic key, and the encrypted string to the mini-program through a dedicated transport layer security protocol.
  • the mini-program can receive the dynamic key, the corresponding validity period of the dynamic key, and the encrypted string obtained by encryption based on the dynamic key returned by the server according to the handshake request through a dedicated transport layer security protocol, so that the mini-program can encrypt the data to be sent according to the dynamic key within the effective expiration time determined by the validity period.
  • step 404 the ciphertext and encrypted string sent by the applet through the universal transport layer security protocol are received.
  • the applet can symmetrically encrypt the data (i.e., plain text) according to the dynamic key received through the dedicated transport layer security protocol, generate the corresponding ciphertext, and send the ciphertext and the encrypted string to the server through the universal transport layer security protocol.
  • the server can receive the ciphertext and the encrypted string sent by the applet through the universal transport layer security protocol.
  • the encrypted string can be placed in the URL for transmission by the applet.
  • step 405 the encrypted string is decrypted to obtain a dynamic key, and the ciphertext is decrypted based on the dynamic key to obtain decrypted data.
  • the server can decrypt the encrypted string to obtain the dynamic key. Then, the ciphertext can be decrypted according to the dynamic key to obtain the corresponding data (i.e., plain text), thereby realizing secure communication and effectively protecting the integrity and security of the data from the mini program to the server, preventing attackers from decrypting and cracking the data.
  • the server can decrypt the encrypted string to obtain the dynamic key. Then, the ciphertext can be decrypted according to the dynamic key to obtain the corresponding data (i.e., plain text), thereby realizing secure communication and effectively protecting the integrity and security of the data from the mini program to the server, preventing attackers from decrypting and cracking the data.
  • the encrypted string when the encrypted string is obtained by Base64 encoding, it is necessary to first restore the encrypted string to binary ciphertext and then decrypt the encrypted string.
  • step 405 includes:
  • Step 501 decrypt the encrypted string using a preset key to obtain the dynamic key, identity and timestamp;
  • Step 502 When the identity and the timestamp are verified, the ciphertext is decrypted according to the dynamic key to obtain the decrypted data.
  • the server can decrypt the encrypted string according to the preset key to obtain the [dynamic key, identity, timestamp] triple in the encrypted string.
  • the server can authenticate the sender according to the identity obtained by decryption, and perform time verification through the timestamp obtained by decryption.
  • the server can obtain the sender's identity to be verified, and compare the identity to be verified with the identity obtained by decryption. When the two match, it is determined that the identity authentication is passed, and when the two do not match, it is determined that the identity authentication is failed.
  • the generation time of the ciphertext can also be obtained to determine whether the generation time is within the valid time range indicated by the timestamp. When the generation time is within the valid time range indicated by the timestamp, it is determined that the timestamp verification is passed, and when the generation time is not within the valid time range indicated by the timestamp, it is determined that the timestamp verification is failed.
  • the ciphertext can be decrypted according to the dynamic key to obtain the decrypted data (i.e., plain text), thereby achieving secure communication and effectively protecting the integrity and security of the data from the applet to the server, and preventing attackers from decrypting and cracking the data.
  • the server does not need to store the identity and dynamic key, but only needs to decrypt the encrypted string to obtain the identity and dynamic key, thereby saving the server's storage resources.
  • identity verification and time verification are required before decrypting the ciphertext, that is, when the identity and the timestamp verification pass, the ciphertext is decrypted according to the dynamic key to obtain the decrypted data, including:
  • the ciphertext is decrypted according to the dynamic key to obtain the decrypted data.
  • an identity tampering attack refers to an attack in which an attacker intercepts data sent by a mini-program through a universal transport layer security protocol and uses the attacker's client to send data to attack.
  • a replay attack refers to a type of attack in which the attacker does not need to decrypt the actual data packet, but records the data request itself and replays the data request after a period of time.
  • the embodiment of the present application will perform identity verification and time verification.
  • the server can obtain the current identity of the applet that sends the ciphertext and encrypted string and the generation time of the ciphertext.
  • the current identity identifier and the decrypted identity identifier can be compared. When the two are the same, it is determined that the identity identifier and the current identity identifier match. When the two are different, it is determined that the identity identifier and the current identity identifier do not match and the identity has been tampered with.
  • the effective expiration date of the dynamic key can also be determined based on the expiration time in the timestamp. End time. Check whether the generation time is before the effective end time. When it is detected that the generation time is before the effective end time, it means that the time verification is passed. When it is detected that the generation time is not before the effective end time, it means that the time verification fails, which is a replay attack.
  • the ciphertext is decrypted according to the dynamic key to obtain the decrypted data. In this way, identity tampering attacks and replay attacks can be prevented, and the security of data transmission can be better protected.
  • the server side needs to decrypt the ciphertext using the dynamic key and also needs to decrypt the encrypted initial vector, that is, the ciphertext is decrypted according to the dynamic key to obtain the decrypted data, including:
  • the ciphertext is decrypted according to the dynamic key to obtain a first decryption result, and the first decryption result and the encryption initial vector are XORed to obtain decrypted data.
  • the server can also receive the encryption initialization vector sent by the applet, group the ciphertext in a manner that each group size is 128 bits (i.e., 16 bytes), and obtain multiple ciphertext subgroups. For the first ciphertext subgroup, decrypt it by using the dynamic key to obtain a first decryption result, and perform an XOR operation on the first decryption result and the encryption initialization vector to obtain a sub-plaintext corresponding to the first ciphertext subgroup.
  • the second ciphertext subgroup decrypt it by using the dynamic key to obtain a second decryption result, and perform an XOR operation on the sub-ciphertext of the previous ciphertext subgroup (i.e., the first ciphertext subgroup) and the second decryption result to obtain a sub-plaintext corresponding to the second ciphertext subgroup.
  • the third ciphertext subgroup decrypt it by using the dynamic key to obtain a third decryption result, and perform an XOR operation on the sub-ciphertext of the previous ciphertext subgroup (i.e., the second ciphertext subgroup) and the third decryption result to obtain a sub-plaintext corresponding to the third ciphertext subgroup.
  • the sub-plaintext of each ciphertext subgroup can be obtained.
  • each ciphertext subgroup can be concatenated to obtain the decrypted data.
  • Figure 11 is an interactive schematic diagram of the data transmission method provided by the embodiment of the present application.
  • the server can generate a dynamic key according to the handshake request, and symmetrically encrypt the dynamic key identity and timestamp according to the preset key to generate a corresponding encrypted string.
  • the dynamic key and encrypted string are sent to the applet through a dedicated transport layer security protocol.
  • the applet can symmetrically encrypt the data (i.e., plain text) based on the encryption initial vector and the dynamic key to obtain the corresponding ciphertext, and send the encryption initial vector, ciphertext, and encrypted string to the server through the general transport layer security protocol.
  • data i.e., plain text
  • the server decrypts the encrypted string using the preset key and recovers the dynamic key, identity and time.
  • the dynamic key is transmitted through a dedicated transport layer with higher security than the general transport layer security protocol, and the encrypted string obtained by encryption processing based on the dynamic key, the data to be sent is encrypted by the dynamic key, the corresponding ciphertext is generated, and the ciphertext and the encrypted string are sent to the server through the general transport layer security protocol, so that the server decrypts the ciphertext according to the dynamic key restored by decryption of the encrypted string to obtain the decrypted data.
  • the embodiment of the present application can receive the dynamic key through a more secure dedicated transport layer security protocol to ensure that the dynamic key is not intercepted by attackers, and the dynamic key is sent to the server through the general transport layer security protocol in the form of an encrypted string, avoiding the dynamic key from being transmitted in plain text, effectively preventing the dynamic key from being cracked, and improving the security of data transmission.
  • Figure 12 is an interactive flow chart of the data transmission method provided by the embodiment of the present application. Referring to Figure 12 below, the specific interactive process of the data transmission method of the embodiment of the present application is described in detail. The process includes but is not limited to the following steps 601 to 613.
  • Step 601 the applet of the terminal 140 sends a handshake request to the server 110 via a dedicated transport layer security protocol between the applet and the server.
  • Step 602 The server 110 receives a handshake request sent by the applet via a dedicated transport layer security protocol, and generates a random dynamic key according to the handshake request.
  • Step 603 the server 110 queries a preset mapping table according to the scenario type to determine the corresponding validity period of the dynamic key.
  • step 604 the server 110 determines a timestamp of the dynamic key based on the validity time.
  • step 605 the server 110 obtains the identity of the mini-program, and encrypts the dynamic key, the identity and the timestamp according to a preset key to obtain an initial encrypted string.
  • step 606 the server 110 performs encoding conversion on the initial encrypted string using a preset number of printable characters to obtain a corresponding encrypted string.
  • Step 607 The server 110 returns the dynamic key, the corresponding validity period of the dynamic key, and the encrypted string to the applet of the terminal 140 via a dedicated transport layer security protocol.
  • Step 608 The applet on the terminal 140 receives the dynamic key, the corresponding validity period of the dynamic key, and the encrypted string returned by the server through a dedicated transport layer security protocol.
  • step 609 the applet on the terminal 140 obtains the data to be sent, generates a random number, generates a message sequence number of the data according to the data generation order, combines the random number and the message sequence number, and generates a corresponding encryption initialization vector.
  • Step 610 The applet on the terminal 140 divides the data into multiple data groups.
  • the encryption initialization vector is XORed with the first data group to obtain a first XOR result of the first data group.
  • the first XOR result is encrypted by the dynamic key to obtain a sub-ciphertext corresponding to the first data group.
  • Group XOR the sub-ciphertext corresponding to the previous data group of other data groups with other data groups to obtain a second XOR result of other data groups, encrypt the second XOR result with a dynamic key to obtain the sub-ciphertext corresponding to other data groups, and combine the sub-ciphertexts corresponding to multiple data groups into a ciphertext.
  • step 611 the applet on the terminal 140 sends the encryption initialization vector, the ciphertext and the encryption string to the server 110 via the universal transport layer security protocol.
  • step 612 the server 110 receives the encrypted ciphertext, encryption initialization vector and encryption string sent by the applet via the universal transport layer security protocol.
  • step 613 the server 110 decrypts the encrypted string using a preset key, recovers the dynamic key, identity and timestamp, and when the identity and timestamp are verified, decrypts the ciphertext according to the dynamic key and the encryption initial vector to obtain the decrypted data.
  • the embodiment of the present application also provides a device based on the above data transmission method.
  • the meanings of the terms are the same as those in the above data transmission method, and the specific implementation details can refer to the description in the method embodiment.
  • Figure 13 is a structural diagram of a data transmission device provided in an embodiment of the present application.
  • the data transmission device is applied to a terminal, wherein the data transmission device may include a first sending unit 701, a first receiving unit 702, an encryption unit 703 and a second sending unit 704, etc.
  • the first sending unit 701 is used to send a handshake request to the server through a dedicated transport layer security protocol between the applet and the server, where the dedicated transport layer security protocol has higher security than the general transport layer security protocol.
  • the first receiving unit 702 is configured to receive, through the dedicated transport layer security protocol, the dynamic key returned by the server according to the handshake request and an encrypted string obtained according to the dynamic key.
  • the encryption unit 703 is used to obtain the data to be sent, and encrypt the data using the dynamic key to obtain a ciphertext.
  • the second sending unit 704 is used to send the ciphertext and the encrypted string to the server through the universal transport layer security protocol, so that the server decrypts the encrypted string to obtain a dynamic key, and decrypts the ciphertext according to the dynamic key to obtain decrypted data.
  • Figure 14 is a structural diagram of a data transmission device provided in an embodiment of the present application.
  • the data transmission device is applied to a terminal, wherein the data transmission device may include a first receiving unit 801, a generating unit 802, a returning unit 803, a second receiving unit 804 and a decryption unit 805, etc.
  • the first receiving unit 801 is used to receive a handshake request sent by the applet through a dedicated transport layer security protocol, where the dedicated transport layer security protocol has higher security than the general transport layer security protocol.
  • the generating unit 802 is used to generate a random dynamic key according to the handshake request, and obtain an encrypted string according to the dynamic key.
  • the returning unit 803 is used to return the dynamic key and the encrypted string to the applet through the dedicated transport layer security protocol, so that the applet encrypts the data to be sent according to the dynamic key to obtain the ciphertext.
  • the second receiving unit 804 is used to receive the ciphertext and the encrypted string sent by the applet through the universal transport layer security protocol.
  • the decryption unit 805 is used to decrypt the encrypted string to obtain the dynamic key, and decrypt the ciphertext based on the dynamic key to obtain decrypted data.
  • the embodiment of the present application further provides a computer device, which may be a terminal.
  • a computer device which may be a terminal.
  • FIG15 it shows a schematic diagram of the structure of the terminal involved in the embodiment of the present application. Specifically:
  • the computer device may include a radio frequency (RF) circuit 901, a memory 902 including one or more computer-readable storage media, an input unit 903, a display unit 904, a sensor 905, an audio circuit 906, a wireless fidelity (WiFi) module 907, a processor 908 including one or more processing cores, and a power supply 909.
  • RF radio frequency
  • the memory 902 can be used to store software programs and modules, and the processor 908 executes various functional applications and information retrieval by running the software programs and modules stored in the memory 902.
  • the memory 902 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area may store data created according to the use of the terminal (such as audio data, a phone book, etc.), etc.
  • the memory 902 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices. Accordingly, the memory 902 may also include a memory controller to provide the processor 908 and the input unit 903 with access to the memory 902.
  • the processor 908 in the terminal will load the executable files corresponding to the processes of one or more applications into the memory 902 according to the following instructions, and the processor 908 will run the applications stored in the memory 902, thereby implementing the methods provided in the embodiments of the present application.
  • the embodiment of the present application further provides a computer device, which may be a server, as shown in FIG16 , which shows a schematic diagram of the structure of the server involved in the embodiment of the present application, specifically:
  • the computer device may include components such as a processor 1010 with one or more processing cores, a memory 1020 with one or more computer-readable storage media, a power supply 1030, and an input unit 1040.
  • a processor 1010 with one or more processing cores
  • a memory 1020 with one or more computer-readable storage media
  • a power supply 1030 with one or more computer-readable storage media
  • an input unit 1040 an input unit
  • the computer device may further include a display unit, etc., which will not be described in detail herein.
  • the processor 1010 in the computer device will load the executable files corresponding to the processes of one or more application programs into the memory 1020 according to the following instructions, and the processor 1010 will run the application programs stored in the memory 1020, thereby implementing the various method steps provided in the aforementioned embodiments.
  • an embodiment of the present application provides a computer-readable storage medium, in which multiple instructions are stored, and the instructions can be loaded by a processor to execute the steps in any data transmission method provided in the embodiment of the present application.
  • a computer program product or a 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, so that the computer device executes the method provided in various optional implementations provided in the above embodiments.
  • the computer readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or CD, etc.
  • the instructions stored in the computer-readable storage medium can execute the steps in any one of the data transmission methods provided in the embodiments of the present application, the beneficial effects that can be achieved by any one of the data transmission methods provided in the embodiments of the present application can be achieved. Please refer to the previous embodiments for details and will not be repeated here.

Landscapes

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

Abstract

本申请实施例公开了一种数据传输方法、装置、存储介质及设备，可应用于云技术、人工智能、智慧交通、辅助驾驶等各种场景。通过小程序和服务器之间的专用传输层安全性协议向服务器发送握手请求；通过专用传输层安全性协议接收服务器根据握手请求返回的动态密钥和根据动态密钥得到的加密串；获取待发送的数据，并通过动态密钥对数据进行加密，得到密文；通过通用传输层安全性协议将密文和加密串发送至服务器，以使得服务器根据解密加密串得到动态密钥，根据动态密钥解密密文，得到解密后的数据。

Description

数据传输方法、装置、存储介质及设备
本申请要求于2023年10月17日提交中国专利局、申请号为202311348871.8，发明名称为“一种数据传输方法、装置、存储介质及设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信技术领域，具体涉及一种数据传输方法、装置、存储介质及设备。
背景技术
超文本传输安全协议(Hypertext Transfer Protocol Secure，HTTPS)，是一种透过计算机网络进行安全通信的传输协议。HTTPS经由HTTP进行通信，但利用通用传输层安全性协议(Transport Layer Security，TLS)来加密数据包。是以安全为目标的HTTP通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性。
在相关技术中，TLS可以采用对称加密的方式加密数据包，即服务器将静态密钥通过TLS发送至客户端，使客户端和服务器均共享相同的静态密钥，数据传输方将明文(即原始数据)和静态密钥一起经过特殊加密算法进行加密，使明文变成复杂的密文并发送给数据接收方，数据接收方收到密文后，则通过静态密钥和特殊加密算法的逆算法对密文进行解密，恢复为可读的明文，以保证数据传输的安全性。
技术内容
本申请实施例提供一种数据传输方法、装置、存储介质及设备，可以提升数据传输的安全性。
本申请实施例提供以下技术方案：
一种数据传输方法，由终端设备执行，包括：
通过终端设备内运行的小程序和服务器之间的专用传输层安全性协议向服务器发送握手请求，所述专用传输层安全性协议具有比通用传输层安全性协议更高的安全性；
通过所述专用传输层安全性协议接收所述服务器返回的动态密钥和根据所述动态密钥得到的加密串；
获取待发送的数据，并通过所述动态密钥对所述数据进行加密，得到密文；
通过所述通用传输层安全性协议将所述密文和所述加密串发送至服务器，以使得所述 服务器解密所述加密串得到所述动态密钥，并根据所述动态密钥解密所述密文得到解密后的数据。
一种数据传输方法，由服务器设备执行，包括：
接收小程序通过专用传输层安全性协议发送的握手请求，所述专用传输层安全性协议具有比通用传输层安全性协议更高的安全性；
根据所述握手请求生成随机的动态密钥，根据所述动态密钥得到加密串；
通过所述专用传输层安全性协议向所述小程序返回所述动态密钥和所述加密串，以使得所述小程序根据所述动态密钥对待发送的数据进行加密得到密文；
接收小程序通过所述通用传输层安全性协议发送的加密后的密文和所述加密串；
解密所述加密串得到所述动态密钥，并基于所述动态密钥解密所述密文得到解密后的数据。
一种数据传输装置，包括：
第一发送单元，用于通过小程序和服务器之间的专用传输层安全性协议向服务器发送握手请求，所述专用传输层安全性协议具有比通用传输层安全性协议更高的安全性；
第一接收单元，用于通过所述专用传输层安全性协议接收所述服务器根据所述握手请求返回的动态密钥和根据所述动态密钥得到的加密串；
加密单元，用于获取待发送的数据，并通过所述动态密钥对所述数据进行加密，得到密文；
第二发送单元，用于通过所述通用传输层安全性协议将所述密文和所述加密串发送至服务器，以使得所述服务器解密所述加密串得到所述动态密钥，并根据所述动态密钥解密所述密文，得到解密后的数据。
一种数据传输装置，包括：
第一接收单元，用于接收小程序通过专用传输层安全性协议发送的握手请求，所述专用传输层安全性协议具有比通用传输层安全性协议更高的安全性；
生成单元，用于根据所述握手请求生成随机的动态密钥，根据所述动态密钥得到加密串；
返回单元，用于通过所述专用传输层安全性协议向所述小程序返回所述动态密钥和所述加密串，以使得所述小程序根据所述动态密钥对待发送的数据进行加密得到密文；
第二接收单元，用于接收小程序通过所述通用传输层安全性协议发送的所述密文和所述加密串；
解密单元，用于解密所述加密串得到所述动态密钥，并基于所述动态密钥解密所述密 文，得到解密后的数据。
一种计算机可读存储介质，所述计算机可读存储介质存储有多条指令，所述指令适于处理器进行加载，以执行上述数据传输方法中的步骤。
一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可以在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述数据传输方法中的步骤。
一种计算机程序产品或计算机程序，所述计算机程序产品或计算机程序包括计算机指令，所述计算机指令存储在存储介质中。计算机设备的处理器从存储介质读取所述计算机指令，处理器执行所述计算机指令，使得实现上述数据传输方法中的步骤。
本公开的其他特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本公开而了解。本公开的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。
附图简要说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请一些实施例提供的数据传输方法的协议结构示意图。
图2为本申请一些实施例所提供的数据传输系统的场景示意图。
图3为本申请一些实施例所提供的登录系统的场景示意图。
图4为本申请一些实施例所提供的虚拟资源支付系统的场景示意图。
图5为本申请一些实施例提供的数据传输方法的流程示意图。
图6为本申请一些实施例提供的数据传输方法的场景示意图。
图7为图5中步骤203的另一个具体流程图；
图8为本申请一些实施例提供的数据传输方法的另一场景示意图。
图9为本申请一些实施例提供的数据传输方法的流程示意图。
图10为图9中步骤405的另一个具体流程图；
图11为本申请一些实施例提供的数据传输方法的交互示意图。
图12为本申请一些实施例提供的数据传输方法的交互流程图。
图13是本申请一些实施例提供的数据传输装置的结构示意图。
图14是本申请一些实施例提供的数据传输装置的结构示意图。
图15是本申请一些实施例提供的终端的结构示意图。
图16是本申请一些实施例提供的服务器的结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本申请的方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
可以理解的是，在本申请的具体实施方式中，涉及到待加密数据等相关的数据，当本申请以上实施例运用到具体产品或技术中时，需要获得对象许可或者同意，且相关数据的收集、使用和处理需要遵守相关法律法规和标准。
此外，当本申请实施例需要获取待加密数据等相关的数据时，会通过弹窗或者跳转到确认页面等方式获得待加密数据等相关的数据的单独许可或者单独同意，在明确获得待加密数据等相关的数据的单独许可或者单独同意之后，再获取用于使本申请实施例能够正常运行的必要的待加密数据等相关的数据。
需要说明的是，在说明书、权利要求书和上述附图所描述的一些流程中，包含了按照特定顺序出现的多个步骤，但应该清楚了解，这些步骤可以不按照其在本文中出现的顺序来执行或并行执行，步骤序号仅仅是用于区分开各个不同的步骤，序号本身不代表任何的执行顺序。此外，本文中的“第一”、“第二”或者“预设”等描述，是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
对本公开实施例进行进一步详细说明之前，对本公开实施例中涉及的名词和术语进行说明，本公开实施例中涉及的名词和术语适用于如下的解释：
传输控制协议/网际协议(Transmission Control Protocol/Internet Protocol，TCP/IP)，是指能够在多个不同网络间实现信息传输的协议簇，TCP/IP协议不仅仅指的是TCP和IP两个协议，而是指一个由文件传输协议(File Transfer Protocol，FTP)、简单邮件传输协议(Simple Mail Transfer Protocol，SMTP)、TCP、对象数据报协议(User Datagram Protocol，UDP)、网际互连协议(Internet Protocol，IP)等协议构成的协议簇，只是因为在TCP/IP协议中TCP协议和IP协议最具代表性，所以被称为TCP/IP协议。也被叫做网络通讯协议，是在网络的使用中最基本的通信协议。
超文本传输协议(Hypertext Transfer Protocol，HTTP)，是一种用于分布式、协作式和超媒体信息系统的应用层协议，是一个基于请求与响应，无状态的，应用层的协议，基于TCP/IP协议来实现传输数据，HTTP允许传输任意类型的数据对象。
小程序：一种在即时通讯客户端内不需要下载安装即可使用的应用程序。
对称加密，指通过同一个密钥对数据进行加密和解密的过程。
统一资源定位系统(uniform resource locator，URL)，是因特网的万维网服务程序上用于指定信息位置的表示方法，可以理解为访问网址。
通用传输层安全性协议(TLS)，用于在两个通信应用程序之间提供保密性和数据完整性。
专用传输层安全性协议(MMTLS，Managed Mode Transport Layer Security)，是一种基于TLS协议的传输层安全协议，它在传输层使用TLS协议进行加密和认证。与传统的TLS协议不同，MMTLS采用了托管模式，即将TLS协议的部分控制权交给应用层管理。在即时通讯客户端中实现的TLS协议，在即时通讯客户端与服务端之间提供保密性和数据完整性。
需要说明的是，该MMTLS不会信任自签名证书，只信任即时通讯客户端携带的证书。另外就是MMTLS整个协议高度定制化，所以现有抓包工具无法进行抓包分析。即因为MMTLS是定制化，所以现有抓包工具无法抓取MMTLS的具体内容，因此后续通过该MMTLS进行动态密钥的传输是安全的。
为了更好的理解MMTLS，请一并参阅图1所示，图1是本申请实施例提供的数据传输方法的协议结构示意图，该TCP/IP采用分层的设计模式，从上至下将协议划分为四个层次，分别为：
应用层(Application Layer)A：应用层A是TCP/IP协议族中最高层的协议，它提供了对象接口和应用程序之间的通信服务，如HTTP就是应用层中的、还有FTP、SMTP等协议。应用层协议是与对象直接交互的协议，它们处理特定类型的数据，并将其交给下一层协议处理。
传输层(Transport Layer)B：传输层B提供了端到端的数据传输服务，如TCP和UDP协议。传输层协议负责将数据从应用层传递到网络层，并保证数据传输的可靠性、流量控制、错误检测等功能。
网络层(Network Layer)C：网络层C主要提供了数据包在网络中的传输服务，如IP协议。网络层协议负责将数据包从源主机传递到目标主机，通过路由选择和转发等技术实现数据在不同网络之间的传输。
链路层(Link Layer)D：链路层D是指数据在物理层上的传输，如Ethernet、Wi-Fi等协议。链路层协议负责将数据从网络层传递到物理层，并通过物理层传输到接收方主机。
该物理层(未标识)指负责比特流在节点之间的传输，即负责物理传输，这一层的协 议既与链路有关，也与传输的介质有关。通俗来说就是把计算机连接起来的物理手段。
其中，该MMTLS处于应用层和网络层之间，不影响原有的网络策略，都是基于TCP实现的。
握手协议，如字面所言，是在加密通信之前，对于加密使用的算法套件及加密密钥进行协商，这和在两个陌生人开始聊天前，通常都需要礼节性的握手类似。
在计算机网络通信场景中，一般是通过HTTPS进行通信，该HTTPS的基础为HTTP进行通信，只是利用了通用传输层安全性协议来加密数据包。
相关技术中，TLS可以采用对称加密的方式加密数据包，即服务器将静态密钥通过TLS发送至客户端，使客户端和服务器均共享相同的静态密钥，数据传输方将明文和静态密钥一起经过特殊加密算法进行加密，使明文变成复杂的密文并发送给数据接收方，数据接收方收到密文后，则通过静态密钥和特殊加密算法的逆算法对密文进行解密，恢复为可读的明文，以保证数据传输的安全性。
但是，这种数据传输方式中用到的静态密钥由于通过TLS直接传输，很容易被分析和破解，会被攻击者通过攻击的手段分析得到，同时，由于静态密钥是固定的，一旦攻击者成功得到，会导致所有密文均被轻松破解，造成数据泄露。
本申请实施例为了解决上述问题，提出一种通过安全性更高的专用传输层安全性协议来传输动态密钥以及对动态密钥进行加密处理得到的加密串，通过动态密钥对待发送的数据进行加密，生成相应的密文，且通过通用传输层安全性协议将密文和加密串发送至服务器，以使得服务器根据加密串进行解密得到动态密钥，并对密文进行解密，得到解密后的数据，保证动态密钥不被攻击者截取，且通过加密串的形式将动态密钥通过通用传输层安全性协议发送至服务器，避免动态密钥以明文形式进行传输，有效防止动态密钥被破解，提升了数据发送的安全性。
请继续参阅图2，图2为本申请一些实施例所提供的数据传输系统的场景示意图，包括终端140、互联网130、网关120、服务器110等。
终端140包括但不限于手机、电脑、智能语音交互设备、智能家电、车载终端、飞行器等，本申请实施例可应用于各种场景，包括但不限于云技术、人工智能、智慧交通、辅助驾驶等。另外，它可以是单台设备，也可以是多台设备组合的集合。例如，多台桌面电脑通过局域网相互连接，共用一台显示器等进行协同工作，共同构成一个终端140。终端140可以以有线或无线的方式与互联网130进行通信，交换数据。
服务器110是指能对终端140提供某些服务的计算机系统。相对于普通终端140来说，服务器110在稳定性、安全性、性能等方面都要求更高。服务器110可以是独立的物理服 务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。
网关120又称网间连接器、协议转换器。网关在传输层上实现网络互连，是一种充当转换作用的计算机系统或设备。在使用不同的通信协议、数据格式或语言，甚至体系结构完全不同的两种系统之间，网关是一个翻译器。同时，网关也可以提供过滤和安全功能。终端140向服务器110发送的消息要通过网关120发送到相应的服务器110。服务器110向终端140发送的消息也要通过网关120发送到相应的终端140。
本申请实施例可以应用在多种场景下，如图3所示的登录系统的场景以及图4所示的虚拟资源支付系统的场景。
(一)登录系统的场景
登录系统可以实现登录功能，完成登录相关的业务，如图3所示，在终端的登录系统的界面11上，对象可以输入账号以及密码实现登录，该界面11可以为小程序端的界面，在开启并显示该登录系统的界面11时，终端会生成握手请求，并通过小程序端和服务器之间的专用传输层安全性协议向服务器发送握手请求，该专用传输层安全性协议具有比通用传输层安全性协议更高的安全性；通过该专用传输层安全性协议接收该服务器根据该握手请求返回的动态密钥和基于该动态密钥进行加密处理得到的加密串；获取待发送的数据(可以理解为登录的账号数据和密码数据)，并通过该动态密钥对该数据进行加密，生成密文；通过该通用传输层安全性协议将该密文和该加密串发送至服务器，以使得该服务器对该加密串进行解密得到该动态密钥，根据动态密钥对该密文进行解密，得到解密后的数据。
(二)虚拟资源支付系统的场景
虚拟资源支付系统可以实现支付功能，完成支付相关的业务，如图4所示，在终端的虚拟资源支付系统的界面12上，对象可以输入商品需要支付的虚拟资源，例如1000，以及支付的密码，例如123456，点击下单按钮实现支付功能，该界面12可以为小程序端的界面，在开启并显示该虚拟资源支付系统的界面12时，终端会生成握手请求，并通过小程序端和服务器之间的专用传输层安全性协议向服务器发送握手请求，该专用传输层安全性协议具有比通用传输层安全性协议更高的安全性；通过该专用传输层安全性协议接收该服务器根据该握手请求返回的动态密钥和基于该动态密钥进行加密处理得到的加密串；获取待发送的数据(可以理解为支付的虚拟资源数据和支付密码数据)，并通过该动态密钥对该数据进行加密，生成密文；通过该通用传输层安全性协议将该密文和该加密串发送至 服务器，以使得该服务器对该加密串进行解密得到该动态密钥，根据动态密钥对该密文进行解密，得到解密后的数据。
需要说明的是，图2所示的数据传输系统的场景示意图仅仅是一个示例，本申请实施例描述的数据传输系统以及场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着数据传输系统的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。
在本实施例中，将从数据传输装置的角度进行描述，该数据传输装置具体可以集成在具备储存单元并安装有微处理器而具有运算能力的计算机设备中，计算机设备可以为终端，该终端中可以安装即时通讯客户端，该即时通讯客户端上可以运行小程序，在本实施例中以终端上运行的小程序进行说明。在本申请一些实施例中，与终端交互的服务器可以为即时通信服务器。
请参阅图5，图5是本申请实施例提供的数据传输方法的流程示意图。该数据传输方法包括：
在步骤201中，通过小程序和服务器之间的专用传输层安全性协议向服务器发送握手请求。
TLS可以采用对称加密的方式加密数据包，即服务器将静态密钥通过TLS发送至客户端，使客户端和服务器均共享相同的静态密钥，数据传输方将明文和静态密钥一起经过特殊加密算法进行加密，使明文变成复杂的密文并发送给数据接收方，数据接收方收到密文后，则通过静态密钥和特殊加密算法的逆算法对密文进行解密，恢复为可读的明文，以保证数据传输的安全性。
但是，这种数据传输方式中用到的静态密钥由于通过TLS直接传输，很容易被分析和破解，会被攻击者通过攻击的手段分析得到，同时，由于静态密钥是固定的，一旦攻击者成功得到，会导致所有密文均被轻松破解，造成数据泄露，且TLS仅能提供传输层的安全，但是随着抓包工具和分析工具的进步，单纯使用TLS无法抵抗基于自签名证书的抓包分析工具，仍然容易受到攻击。
需要说明的是，本申请实施例中的小程序依托于即时通讯客户端，即该即时通讯客户端可以作为该小程序的运行容器，该小程序运行于即时通讯客户端，因此该小程序可以直接调用该即时通讯客户端相应的专用传输层安全性协议。
以此，为了解决上述问题，保证数据传输的安全，本申请实施例可以通过小程序和服务器之间的专用传输层安全性协议，即专用传输层安全性协议来向服务器发送握手请求， 该握手请求可以携带小程序的小程序标识和即时通讯客户端版本，以使得服务器可以根据小程序标识和即时通讯客户端版本来识别该握手请求是否为可正常使用的小程序和即使通讯客户端版本发送。
由于专用传输层安全性协议整个协议高度定制化，所以现有抓包工具无法进行抓包分析。即因为专用传输层安全性协议是定制化，所以现有抓包工具无法抓取专用传输层安全性协议的握手请求，避免攻击者监测小程序的握手请求，因此，该专用传输层安全性协议具有比通用传输层安全性协议更高的安全性。
为了更好的说明本申请实施例，请一并参阅图6所示，终端140上的小程序可以通过小程序和服务器之间的专用传输层安全性协议向服务器发送握手请求，以保证握手请求的私密性。
在步骤202中，通过专用传输层安全性协议接收服务器根据握手请求返回的动态密钥和根据所述动态密钥得到的加密串。
其中，该服务器接收到小程序通过专用传输层安全性协议发送的握手请求之后，可以根据该握手请求生成随机的动态密钥，该动态密钥可以通过服务器中的安全随机数生成器随机生成，长度可以为128或者256位等等。与相关技术不同的是，本申请实施例基于不同的握手请求会生成不同的动态密钥，即动态密钥实时变化，从而可以更好的抵御攻击者破解。
需要说明的是，由于该专用传输层安全性协议的传输能力有限，因此，后续的数据传输仍然需要通过通用传输层安全性协议进行传输，为了避免该动态密钥以明文的形式在通用传输层安全性协议上进行传输，该服务器可以通过设定的加密规则对该动态密钥进行加密处理，得到相应的加密串。
进一步的，该服务器可以通过该专用传输层安全性协议向本申请实施例中的小程序返回该动态密钥和该加密串，以此，本申请实施例可以通过该专用传输层安全性协议接收该服务器返回的动态密钥和基于该动态密钥进行加密得到的加密串，实现握手，即小程序和服务器之间建立连接，相应的，由于专用传输层安全性协议整个协议高度定制化，所以现有抓包工具无法进行抓包分析。即因为专用传输层安全性协议是定制化，所以现有抓包工具无法抓取专用传输层安全性协议传输的动态密钥和加密串，更好的保证了动态密钥的安全性。
请继续参阅图6所示，服务器110可以根据握手请求生成随机的动态密钥，并通过aes_encrypt(token，secret)函数，基于该secret(即动态密钥)，生成加密串token，并将动态密钥和包含动态密钥的加密串通过专用传输层安全性协议传输给终端140上的小 程序，相应的，终端140上的小程序可以接收动态密钥和包含动态密钥的加密串。
在一些实施例中，为了实现更好的数据保护，可以规定每个动态密钥有相应的有效时间，即该动态密钥在达到有效时间之后，该动态密钥会相应失效，小程序需要重新发送握手请求，通过该专用传输层安全性协议重新接收更新的动态密钥和加密串，以使得该动态密钥定期更新，更好的避免攻击者的分析，该有效时间可以人工设定，例如15分钟或者30分钟等。
在一些实施例中，小程序可以应用于不同的场景，例如登录场景、下单场景以及信息浏览场景，该登录场景代表对象通过小程序实现账号登录，该下单场景代表对象通过小程序实现商品下单，该信息浏览场景代表对象通过小程序实现信息浏览，而每种场景具有不同的安全性要求，例如，登录场景需要的安全性高于下单场景，而下单场景需要的安全性高于信息浏览场景。基于此，可以为每种场景下分配的动态密钥设定不同的有效时间。
基于此，该握手请求可以携带相应的场景类型，该场景类型指示生成握手请求时小程序的相应的场景，该场景类型可以包括但不限于登录场景类型、下单场景类型或者信息浏览场景类型。当小程序在登录场景下生成握手请求时，该握手请求携带的场景类型为登录场景类型。当小程序在下单场景下生成握手请求时，该握手请求携带的场景类型为下单场景类型。相应的，当小程序在信息浏览场景下生成握手请求时，该握手请求携带的场景类型为信息浏览场景类型。
以此，所述方法进一步包括：
通过该专用传输层安全性协议接收该服务器根据该握手请求返回的动态密钥相应的有效时间；
其中，该有效时间为服务器根据该握手请求携带的该场景类型确定的时间。
具体的，由于该握手请求携带相应的场景类型，因此，服务器在确定出相应的动态密钥的同时，可以根据场景类型自动匹配出相应的有效时间，场景类型与有效时间的映射关系如表1所示，表1即为预设映射表，该预设映射表中包括不同场景类型与有效时间的映射关系，假定场景类型为登录场景类型，则获取到有效时间为5分钟。假定场景类型为下单场景类型，则获取到有效时间为10分钟。假定场景类型为信息浏览场景类型，则获取到有效时间为30分钟。
表1
基于此，服务器可以通过专用传输层安全性协议向该小程序返回该动态密钥、动态密钥相应的有效时间以及该加密串，对应的，小程序可以通过专用传输层安全性协议接收该服务器根据该握手请求返回的动态密钥、该动态密钥相应的有效时间、以及基于该动态密钥进行加密处理得到的加密串，以此，可以根据小程序发起握手请求时不同的场景类型的安全性要求，灵活设置相应的动态密钥的有效时间，提升了有效时间设置的灵活性。
在一些实施方式中，由于小程序应用的场景可以是实时变化的，例如小程序的应用场景由下单场景类型切换至登录场景类型，由于场景变化，对于动态密钥的有效时间的要求也不相同，因此，小程序通过专用传输层安全性协议接收该服务器根据该握手请求返回的动态密钥、该动态密钥相应的有效时间、以及基于该动态密钥进行加密处理得到的加密串之后，还需要实时监测场景类型变化，保证动态密钥的实时更新，具体包括如下方式：
当检测到该场景类型变化时，删除该动态密钥、该动态密钥相应的有效时间、以及基于该动态密钥进行加密处理得到的加密串；
重新执行通过小程序和服务器之间的专用传输层安全性协议向服务器发送握手请求，以通过该专用传输层安全性协议重新接收更新的动态密钥、有效时间和加密串。
具体的，小程序可以持续检测场景类型是否发生变化，当检测到场景类型变化时，说明场景变化，需要将当前存储的动态密钥、动态密钥相应的有效时间以及基于该动态密钥进行加密处理得到的加密串删除。
进一步的，为了实现更好的安全性，需要更新动态密钥，因此，可以重新执行上述实施例，以重新接收在变化后的场景类型下更新的动态密钥、有效时间和加密串，以此，保证动态密钥可以随着小程序应用的场景变化而实时变化，提升动态密钥更新的灵活性。
在一些实施方式中，小程序可以应用于不同的场景，例如登录场景、下单场景以及信息浏览场景，该登录场景代表对象通过小程序实现账号登录，该下单场景代表对象通过小程序实现商品下单，该信息浏览场景代表对象通过小程序实现信息浏览，而每种场景具有不同的安全性要求，例如，登录场景需要的安全性高于下单场景，而下单场景需要的安全性高于信息浏览场景。
同时，小程序的类型也有多种多样，例如办公类型的小程序，游戏类型的小程序或者生活类型的小程序，而每种类型的小程序具有不同的安全性要求，例如，办公类型的小程序需要的安全性高于生活类型的小程序，而生活类型的小程序需要的安全性高于游戏类型的小程序，基于此，可以结合小程序应用的场景和小程序的类型，灵活设定不同的有效时间。
基于此，该握手请求可以同时携带场景类型和应用隐私级别，该场景类型指示生成握手请求时小程序的相应的场景，该场景类型可以包括但不限于登录场景类型、下单场景类型或者信息浏览场景类型。当小程序在登录场景下生成握手请求时，该握手请求携带的场景类型为登录场景类型。当小程序在下单场景下生成握手请求时，该握手请求携带的场景类型为下单场景类型。相应的，当小程序在信息浏览场景下生成握手请求时，该握手请求携带的场景类型为信息浏览场景类型。
该应用隐私级别指示生成握手请求时小程序的类型相应的隐私级别，该应用隐私级别包括但不限于高、中和低三种级别，以此，可以将办公类型的小程序的应用隐私级别设置为高，将生活类型的小程序的应用隐私级别设置为中，将游戏类型的小程序的应用隐私级别设置为低，当小程序的类型为办公类型且生成握手请求时，该握手请求携带的应用隐私级别为高。当小程序的类型为生活类型且生成握手请求时，该握手请求携带的应用隐私级别为中。当小程序的类型为游戏类型且生成握手请求时，该握手请求携带的应用隐私级别为低。
以此，所述方法可以包括：
通过该专用传输层安全性协议接收该服务器根据该握手请求返回的动态密钥相应的有效时间；
其中，该有效时间为服务器根据该握手请求携带的该场景类型和应用隐私级别一并确定的时间。
具体的，由于该握手请求可以同时携带场景类型和应用隐私级别，因此，服务器在确定出相应的动态密钥的同时，可以根据场景类型与表1(即预设映射表)进行匹配，确定动态密钥相应的初始有效时间，假设该握手请求携带的场景类型为下单场景类型，那么可以确定动态密钥相应的初始有效时间为10分钟。
进一步的，服务器还可以根据应用隐私级别自动匹配出相应权重，应用隐私级别与权重的映射关系如表2所示，假定应用隐私级别为高，则获取到权重为0.6。假定应用隐私级别为中，则获取到权重为0.8。假定应用隐私级别为低，则获取到权重为1，即应用隐私级别越高，权重越低，应用隐私级别越低，权重越高。
表2
基于表2匹配出的权重，对之前匹配得到的初始有效时间进行加权处理，得到动态密钥最后的有效时间，假设该握手请求携带的应用隐私级别为中，那么根据匹配得到的权重0.8对初始有效时间10分钟进行加权处理，得到最后的有效时间为8分钟。
基于此，服务器可以通过专用传输层安全性协议向该小程序返回该动态密钥、动态密钥相应的有效时间以及该加密串，对应的，小程序可以通过专用传输层安全性协议接收该服务器根据该握手请求返回的动态密钥、该动态密钥相应的有效时间、以及基于该动态密钥进行加密处理得到的加密串，以此，可以根据小程序发起握手请求时不同的场景类型和小程序的类型的安全性要求进行综合考量，灵活设置相应的动态密钥的有效时间，进一步的提升了有效时间设置的灵活性。
在一些实施方式中，小程序可以通过专用传输层安全性协议接收该服务器根据该握手请求返回的动态密钥、该动态密钥相应的有效时间、以及基于该动态密钥进行加密处理得到的加密串之后，还需要实时监测动态密钥的有效时间，保证动态密钥的实时更新，具体包括如下方式：
根据该有效时间确定相应的有效终止时间；
当检测到当前时间到达该有效终止时间时，重新执行通过小程序和服务器之间的专用传输层安全性协议向服务器发送握手请求，以通过该专用传输层安全性协议重新接收更新的动态密钥、有效时间和加密串。
具体的，服务器还可以同时把动态密钥的生成时间一并发送给小程序，以此，小程序可以根据动态密钥的生成时间和有效时间计算出有效终止时间，例如动态密钥的生成时间为2023年10月8日11点51分00秒时，有效时间为8分钟，那么有效终止时间即为2023年10月8日11点59分00秒。
以此，小程序可以持续检测当前时间是否到达有效终止时间，当检测到当前时间未到达有效终止时间时，说明该动态密钥仍然有效，相反的，当检测到当前时间到达有效终止时间时，说明该动态密钥到期，为了实现更好的安全性，需要更新动态密钥，因此，可以重新执行上述实施例，以重新接收更新的动态密钥、有效时间和加密串，以此，保证可以按照有效时间定期更新动态密钥，增加动态密钥的变化性，增加破解难度。
在一些实施方式中，服务器在生成动态密钥，以及获取到该动态密钥的有效时间之后，可以根据该有效时间确定该动态密钥的时间戳，该时间戳可以包含动态密钥生产时间(issue atime，iat)和到期时间(expire atime，exp)，例如生产时间为2023年10月8日11点51分00秒，假设有效时间为8分钟，那么该到期时间为2023年10月8日11 点59分00秒。并且获取小程序的身份标识，该身份标识可以为小程序依托的即时通讯客户上登录的账号标识，例如账号标识12345，进而得到【动态密钥、身份标识、时间戳】的三元组，并可以基于预设密钥对该【动态密钥、身份标识、时间戳】进行对称加密处理，得到相应的加密串，以此，使得动态密钥后续在通用传输层安全性协议上可以以加密串的形式进行传输，避免动态密钥以明文的方式进行传输，提升动态密钥传输的安全性。
需要说明的是，该对称加密处理可以为AES(Advanced Encryption Standard)加密算法(高级加密标准算法)，该AES加密算法可以使用128位、192位或256位的密钥对数据进行加密和解密，具有高强度、高速度和易于实现等优点，该预设密钥即用于加密的128位、192位或256位的密钥，并且与相关技术中的对称加密不同的是，该预设密钥不需要传输给终端，只保留在服务器内部即可，可以防止该预设密钥泄露。
在步骤203中，获取待发送的数据，并通过动态密钥对数据进行加密，生成相应的密文。
其中，待发送的数据即为待发送的明文，为小程序需要发送给服务器的数据，可以为登录的账号密码，或者支付使用的密码，这些数据对于对象来说是非常机密的，假设以明文直接进行传输，很容易会被攻击者拦截并分析，轻易的获取到对象的机密数据，造成对象的经济损失以及数据泄露。
本申请实施例为了解决上述问题，可以通过专用传输层安全性协议接收到的动态密钥对该数据进行对称加密，生成相应的密文，以此，即时攻击者拦着到该密文，也会因为没有动态密钥而无法破解，避免造成对象的经济损失以及数据泄露。
在一些实施方式中，可以基于AES加密算法，并且使用CBC(Cipher Block Chaining)模式，通过动态密钥对数据进行加密，即参照图7，步骤203包括：
步骤301，获取待发送的数据，生成该数据的加密初始向量，并根据所述加密初始向量对所述数据进行异或，得到异或结果；
步骤302，通过所述动态密钥对所述异或结果进行加密，得到所述密文。
需要说明的是，CBC全称为Cipher Block Chaining模式(密文分组链接模式)，“分组”是指加密和解密过程都以分组的形式进行。每一个分组大小为128bits(16字节)，如果明文的长度不是16字节的整数倍，需要对最后一个分组进行填充(padding)，使得最后一个分组的长度为16字节。“链接”是指密文分组像链条一样相互连接在一起。在该CBC模式中，需要一个初始化向量IV(在本申请实施例中即为加密初始向量)，因此，可以获取待发送的数据(即明文)，以及生成加密初始向量，该加密初始向量可以为小程序随机生成 一个数值，并将该数值转化为加密初始向量，可以使用One-Hot编码的转化方式，One-Hot编码，对于具有离散取值的序列数据，可以使用One-Hot编码将每个取值表示为一个向量。
在一些实施方式中，该生成该数据相应的加密初始向量，还可以包括：
生成随机数；
生成该数据的消息序列号；
将该随机数和该消息序列号结合，生成相应的加密初始向量。
具体的，还可以生成随机数Nonce，例如20或者30等等，并且根据数据的生成顺序生成数据生成数据的消息序列号Seq，例如1、2或者3等等。相应的可以将Nonce+Seq进行组合，通过One-Hot编码生成相应的加密初始向量，由于该随机数和消息序列号都是动态变化的，因此，该加密初始向量也是不断的变化的，保证后续即时对相同的明文进行多次加密，最终得到的密文也是不同的，提升攻击者破解的难度。
相应的，在获取到加密初始向量之后，可以结合动态密钥在CBC模式下对数据进行加密，得到最后的密文，具体而言，该步骤301，包括：
将该数据划分为多个数据分组；
对于第一个数据分组，将该加密初始向量与该第一个数据分组进行异或，得到该第一个数据分组的第一异或结果；
对于其它数据分组中的每一个数据分组，将该数据分组的前一个数据分组的子密文与该数据分组进行异或，得到所述其它数据分组中每一个数据分组的第二异或结果。
步骤302包括：
通过该动态密钥对该第一异或结果进行加密，得到该第一个数据分组对应的子密文；
通过所述动态密钥对其他数据分组中每一个数据分组的所述第二异或结果进行加密，得到所述其它数据分组中每一个数据分组对应的子密文；
将多个该数据分组对应的该子密文组成为密文。
具体的，可以将数据按照每一个分组大小为128bits(即16字节)的方式进行分组，需要说明的是，如果明文的长度不是16字节的整数倍，那么会对最后一个分组进行填充，使得最后一个分组的长度也为16字节。为了更好的说明本申请实施例，请一并参阅图8所示，可以将数据按照每一个分组大小为16字节划分为多个数据分组。
需要说明的是，异或，英文为exclusive OR，缩写成xor，是一个数学运算符。它应用于逻辑运算。异或的数学符号为计算机符号为“xor”。其运算法则为： 即如果a、b两个值不相同，则异或结果为1。如果a、b两个值相同，异或结果为0。异或也叫半加运算，其运算法则相当于不带进位的二进制加法。
对于第一个数据分组，可以将该加密初始向量与第一个数据分组进行异或，得到第一数据分组的第一异或结果，并将该第一异或结果送入块密码加密模块并结合动态密钥进行加密，得到第一数据分组对应的子密文。
而对于其他数据分组，可以将前一个数据分组对应的子密文与其他数据分组进行异或，得到其他数据分组的第二异或结果。
进一步的，可以将第二异或结果送入块密码加密模块并结合动态密钥进行加密，得到其他数据分组的子密文，例如，对于第二个数据分组，可以将第一个数据分组对应的子密文和该第二个数据分组进行异或，得到第二个数据分组的第二异或结果，并将其相应的第二异或结果送入块密码加密模块并结合动态密钥进行加密，得到第二个数据分组的子密文，对于第三个数据分组，可以将第二个数据分组对应的子密文和该第三个数据分组进行异或，得到第三个数据分组的第二异或结果，并将其相应的第二异或结果送入块密码加密模块并结合动态密钥进行加密，得到第三个数据分组的子密文，以此类推，可以得到每个其他数据分组的子密文。
相应的，可以将每个数据分组对应的子密文进行拼接，得到最后的密文。
在步骤204中，通过通用传输层安全性协议将密文和加密串发送至服务器。
其中，由于该专用传输层安全性协议的传输能力有限，因此，密文和加密串的传输需要通过通用传输层安全性协议进行传输，即小程序可以通过通用传输层安全性协议将密文和加密串发送至服务器。
由于密文为经过动态密钥加密处理得到，该加密串经过预设密钥加密处理得到，所以动态密钥和数据均不会以明文形式在通用传输层安全性协议上进行传输，且动态密钥通过专用传输层安全性协议进行安全传输，而预设密钥只存在于服务器，因此，攻击者即时截取到该密文和加密串，也无法进行相应的解密，以此，保护了数据安全，提升了数据传输的安全性。
请继续参阅图6所示，终端140通过动态密钥加密数据，得到相应的密文，并通过通用传输层安全性协议将该密文传输至服务器110，并且可以将该加密串token放在URL中传输至服务器110。
服务器在接收到密文和加密串后，可以根据预设密钥对该加密串进行解密，得到动态密钥，以此，可以根据该动态密钥对该密文进行解密，得到相应的数据(即明文)，实现安全通信，有效保护小程序到服务器的数据的完整性和安全性，避免攻击者对数据进行解密和破解。
在一些实施方式中，小程序由于通过AES加密算法，并且使用CBC(Cipher Block  Chaining)模式，通过动态密钥对数据进行加密，因此，小程序还需要将加密初始向量一并发送至服务器，即步骤204进一步包括：
通过通用传输层安全性协议将该加密初始向量发送至服务器。
其中，小程序可以通过传输层安全性协议将该加密初始向量、密文和该加密串发送至服务器，以使得服务器在接收到加密初始向量、密文和该加密串之后，可以根据预设密钥对加密串进行解密，恢复动态密钥，将该动态密钥结合加密初始向量，对密文进行解密，具体处理过程为：
将密文按照每一个分组大小为128bits(即16字节)的方式进行分组，得到多个密文子分组，对于第一个密文子分组，通过动态密钥进行解密，得到第一解密结果，并将该第一解密结果与加密初始向量进行异或，得到第一个密文子分组相应的子明文，而对于第二个密文子分组，可以通过动态密钥进行解密，得到第二解密结果，并将前一个密文子分组(即第一个密文子分组)的子密文与第二解密结果进行异或，得到第二个密文子分组相应的子明文。对于第三个密文子分组，可以通过动态密钥进行解密，得到第三解密结果，并将前一个密文子分组(即第二个密文子分组)的子密文与第三解密结果进行异或，得到第三个密文子分组相应的子明文，以此类推，可以得到每个密文子分组的子明文。
相应的，可以将每个密文子分组的子明文进行拼接，得到数据。
由上述可知，本申请实施例通过小程序和服务器之间的专用传输层安全性协议向服务器发送握手请求，专用传输层安全性协议具有比通用传输层安全性协议更高的安全性；通过专用传输层安全性协议接收服务器根据握手请求返回的动态密钥，和基于动态密钥进行加密处理得到的加密串；获取待发送的数据，并通过动态密钥对数据进行加密，生成相应的密文；通过通用传输层安全性协议将密文和加密串发送至服务器，以使得服务器根据对加密串进行解密恢复的动态密钥，对密文进行解密，得到解密后的数据。以此，通过具有比通用传输层安全性协议更高安全性的专用传输层来接收动态密钥以及基于动态密钥进行加密处理得到的加密串，通过动态密钥对待发送的数据进行加密，生成相应的密文，且通过通用传输层安全性协议将密文和加密串发送至服务器，以使得服务器根据加密串进行解密恢复的动态密钥对密文进行解密，得到解密后的数据，相对于相关技术中通过静态密钥来实现对称加密的方案而言，本申请实施例可以通过安全性更高的专用传输层安全性协议接收动态密钥，保证动态密钥不被攻击者截取，且通过加密串的形式将动态密钥通过通用传输层安全性协议发送至服务器，避免动态密钥以明文形式进行传输，有效防止动态密钥被破解，提升了数据传输的安全性。
结合上述实施例所描述的方法，以下将举例作进一步详细说明。
在本实施例中，将从数据传输装置的角度进行描述，该数据传输装置具体可以集成在具备储存单元并安装有微处理器而具有运算能力的计算机设备中，计算机设备可以为服务器，即在本实施例中以服务器进行说明。
请一并参阅图9，图9为本申请实施例提供的数据传输方法的流程示意图。该方法流程可以包括：
在步骤401中，接收小程序通过专用传输层安全性协议发送的握手请求。
其中，服务器可以接收小程序通过专用传输层安全性协议发送的握手请求，该握手请求可以携带小程序的小程序标识和即时通讯客户端版本，以此，服务器可以验证小程序标识和即时客户端版本是否为可正常使用，当验证到小程序标识或者即时通讯客户端版不能正常使用时，例如，小程序标识错误或者即时客户端版本过低时，不响应该握手请求。
相应的，当验证到小程序标识以及即时通讯客户端均可以正常使用时，响应该握手请求，并执行步骤402。
在步骤402中，根据握手请求生成随机的动态密钥，根据所述动态密钥得到相应的加密串。
其中，服务器响应于该握手请求，根据安全随机数生成器生成随机的动态密钥，该动态密钥的长度可以为128位或者256位等等。即该动态密钥是实时变化的，可以更好的抵御攻击者破解。
需要说明的是，由于专用传输层安全性协议的传输能力有限，因此，后续的小程序传输的数据仍然需要通过通用传输层安全性协议进行传输，为了避免该动态密钥以明文的形式在通用传输层安全性协议上进行传输，服务器可以通过设定的加密规则对该动态密钥进行加密处理，得到相应的加密串。
在一些实施例中，为了实现更好的数据保护，可以规定动态密钥有相应的有效时间，即该动态密钥在达到有效时间之后，该动态密钥会相应失效，小程序需要重新发送握手请求，服务器会根据重新发送的握手请求，生成更新的动态密钥和加密串并发送给小程序，以使得该动态密钥定期更新，更好的避免攻击者的分析。
即步骤402，可以包括：
根据该握手请求生成随机的动态密钥，并确定该动态密钥的有效时间；
基于该有效时间确定该动态密钥的时间戳；
获取该小程序的身份标识，加密该动态密钥、身份标识和时间戳，得到相应的加密串。
其中，该有效时间可以人工设定，例如默认15分钟或者30分钟，在本申请实施例中，以30分钟为例进行说明，服务器可以响应握手请求，生成随机的256位的动态密钥，并 且确定该动态密钥的有效时间为30分钟。
相应的，可以基于该有效时间30分钟，为了后续对加密串进行有效性验证，可以基于该有效时间确定动态密钥的时间戳，该时间戳可以包含动态密钥生产时间(issue atime，iat)和到期时间(expire atime，exp)，例如生产时间为2023年10月8日11点50分00秒，有效时间为30分钟，那么该到期时间为2023年10月8日12点20分00秒。
进一步的，为了后续对加密串进行身份验证，还可以获取发送握手请求的小程序的身份标识，该身份标识可以为小程序依托的即时通讯客户端上登录的账号标识，例如账号标识12345，进而得到【动态密钥、身份标识、时间戳】的三元组，并可以基于预设密钥对该【动态密钥、身份标识、时间戳】进行对称加密处理，得到相应的加密串，以此，使得动态密钥后续在通用传输层安全性协议上可以以加密串的形式进行传输，避免动态密钥以明文的方式进行传输，提升动态密钥传输的安全性。
需要说明的是，该对称加密处理可以为AES(Advanced Encryption Standard)加密算法(高级加密标准算法)，该AES加密算法会使用128位、192位或256位的密钥对数据进行加密和解密，具有高强度、高速度和易于实现等优点，该预设密钥即用于加密的128位、192位或256位的密钥，并且与相关技术中的对称加密不同的是，该预设密钥不需要传输给终端，只保留在服务器内部即可，可以防止该预设密钥泄露。
在一些实施方式中，该加密后的加密串可以为二进制的密文，数据的长度会非常大，影响传输的速度，并且由于后续小程序还需要将该加密串放置到URL中传回服务器，而URL只支持有限的字符集，不能编码二进制的密文，因此，还需要对加密后的加密串进行简化处理，即加密该动态密钥、身份标识和时间戳，得到相应的加密串，包括：
根据预设密钥对该动态密钥、身份标识和时间戳进行加密处理，得到初始加密串；
对该初始加密串通过预设数量个可打印字符进行编码转换，得到相应的加密串。
需要说明的是，该预设数量个可打印字符可以理解为Base64编码，Base64编码是最常见的用于传输8比特字节码的编码方式之一，它是一种基于64个可打印字符来表示二进制数据的方法。由64个字符组成编码集：26个大写字母A～Z，26个小写字母a～z，10个数字0～9，符号“+”与符号“/”。
具体的，基于预设密钥对该【动态密钥、身份标识、时间戳】进行对称加密处理，得到初始加密串，该初始加密串即为二进制的密文，为了便于后续传输，可以将该初始加密串通过Base64编码进行编码转换，具体的，可以将该初始加密串按照每三个字节作为一组进行划分，每组一共是24个二进制位，再将24个二进制位，按照每6个一划分，分为4组(即6×4＝24个二进制位)。然后在每组前面补上00，扩展成8×4＝32个二进制位， 即四个字节(因为每个字节前面有2个0，所以每个字节的最大值是63，最前面加两个0只是为了凑成一个字节，数值不会发生变化)，最后根据Base64编码表，将四个字节的码值，转换为对应的Base64字符，即得到相应的加密串。
在一些实施例中，小程序可以应用于不同的场景，例如登录场景、下单场景以及信息浏览场景，该登录场景代表对象通过小程序实现账号登录，该下单场景代表对象通过小程序实现商品下单，该信息浏览场景代表对象通过小程序实现信息浏览，而每种场景具有不同的安全性要求，例如，登录场景需要的安全性高于下单场景，而下单场景需要的安全性高于信息浏览场景。基于此，可以为每种场景下分配的动态密钥设定不同的有效时间。
基于此，小程序发送的握手请求可以携带相应的场景类型，该场景类型指示生成握手请求时小程序的相应的场景，该场景类型可以包括但不限于登录场景类型、下单场景类型或者信息浏览场景类型。当小程序在登录场景下生成握手请求时，该握手请求携带的场景类型为登录场景类型。当小程序在下单场景下生成握手请求时，该握手请求携带的场景类型为下单场景类型。相应的，当小程序在信息浏览场景下生成握手请求时，该握手请求携带的场景类型为信息浏览场景类型。
以此，确定该动态密钥的有效时间，可以包括：
根据预设映射表，确定该动态密钥相应的有效时间；
其中，该预设映射表中包括不同场景类型与有效时间的映射关系。
具体的，该预设映射表具体可以参照之前的表1，将服务器可以根据握手请求中携带的场景类型，快速匹配生成的动态密钥相应的有效时间。假设该握手请求携带的场景类型为下单场景类型，那么可以确定动态密钥相应的初始有效时间为10分钟。
在一些实施方式中，小程序可以应用于不同的场景，例如登录场景、下单场景以及信息浏览场景，该登录场景代表对象通过小程序实现账号登录，该下单场景代表对象通过小程序实现商品下单，该信息浏览场景代表对象通过小程序实现信息浏览，而每种场景具有不同的安全性要求，例如，登录场景需要的安全性高于下单场景，而下单场景需要的安全性高于信息浏览场景。
同时，小程序的类型也有多种多样，例如办公类型的小程序，游戏类型的小程序或者生活类型的小程序，而每种类型的小程序具有不同的安全性要求，例如，办公类型的小程序需要的安全性高于生活类型的小程序，而生活类型的小程序需要的安全性高于游戏类型的小程序，基于此，可以结合小程序应用的场景和小程序的类型，灵活设定不同的有效时间。
基于此，该握手请求可以同时携带场景类型和应用隐私级别，该场景类型指示生成握 手请求时小程序的相应的场景，该场景类型可以包括但不限于登录场景类型、下单场景类型或者信息浏览场景类型。当小程序在登录场景下生成握手请求时，该握手请求携带的场景类型为登录场景类型。当小程序在下单场景下生成握手请求时，该握手请求携带的场景类型为下单场景类型。相应的，当小程序在信息浏览场景下生成握手请求时，该握手请求携带的场景类型为信息浏览场景类型。
该应用隐私级别指示生成握手请求时小程序的类型相应的隐私级别，该应用隐私级别包括但不限于高、中和低三种级别，以此，可以将办公类型的小程序的应用隐私级别设置为高，将生活类型的小程序的应用隐私级别设置为中，将游戏类型的小程序的应用隐私级别设置为低，当小程序的类型为办公类型且生成握手请求时，该握手请求携带的应用隐私级别为高。当小程序的类型为生活类型且生成握手请求时，该握手请求携带的应用隐私级别为中。当小程序的类型为游戏类型且生成握手请求时，该握手请求携带的应用隐私级别为低。
以此，确定该动态密钥的有效时间，还可以包括：
根据预设映射表，确定该动态密钥相应的初始有效时间；
其中，该预设映射表中包括不同场景类型与有效时间的映射关系；
根据该应用隐私级别确定权重，并基于该权重对该初始有效时间进行加权，得到该动态密钥的有效时间。
具体的，该预设映射表具体可以参照之前的表1，将服务器可以根据握手请求中携带的场景类型，快速匹配生成的动态密钥相应的初始有效时间。假设该握手请求携带的场景类型为下单场景类型，那么可以确定动态密钥相应的初始有效时间为10分钟。
进一步的，服务器还可以根据应用隐私级别自动匹配出相应权重，应用隐私级别与权重的映射关系请继续参阅表2所示，例如，该握手请求携带的应用隐私级别为中，那么根据匹配得到的权重0.8对初始有效时间10分钟进行加权处理，得到最后的有效时间为8分钟。
在步骤403中，通过专用传输层安全性协议向小程序返回动态密钥和加密串。
其中，服务器可以通过该专用传输层安全性协议向本申请实施例中的小程序返回该动态密钥和该加密串，小程序可以通过该专用传输层安全性协议接收该服务器返回的动态密钥，和基于该动态密钥进行加密处理得到的加密串，实现握手，即小程序和服务器之间建立连接，以使得小程序可以根据该动态密钥对待发送的数据(即明文)进行加密，相应的，由于专用传输层安全性协议整个协议高度定制化，所以现有抓包工具无法进行抓包分析。即因为专用传输层安全性协议是定制化，所以现有抓包工具无法抓取专用传输层安全性协 议传输的动态密钥和加密串，更好的保证了动态密钥传输的安全性。
在一些实施方式中，服务器还可以将动态密钥的有效时间一并返回给小程序，即通过专用传输层安全性协议向小程序返回动态密钥和加密串，包括：
通过专用传输层安全性协议向该小程序返回该动态密钥、动态密钥相应的有效时间以及该加密串。
具体的，服务器可以通过专用传输层安全性协议向该小程序返回该动态密钥、动态密钥相应的有效时间以及该加密串，对应的，小程序可以通过专用传输层安全性协议接收该服务器根据该握手请求返回的动态密钥、该动态密钥相应的有效时间、以及基于该动态密钥进行加密处理得到的加密串，以使得小程序可以在该有效时间确定的有效终止时间以内，根据该动态密钥对待发送的数据进行加密。
在步骤404中，接收小程序通过通用传输层安全性协议发送的密文和加密串。
其中，小程序可以根据通过专用传输层安全性协议接收的动态密钥对数据(即明文)进行对称加密，生成相应的密文，并通过通用传输层安全性协议将密文和加密串发送至服务器。相应的，服务器可以接收小程序通过通用传输层安全性协议发送的密文和加密串。需要说明的是该加密串可以为小程序放置在URL中进行传输的。
由于密文为经过动态密钥加密处理得到，该加密串也经过加密处理得到，所以动态密钥和数据均不会以明文形式在通用传输层安全性协议上进行传输，且动态密钥通过专用传输层安全性协议进行安全传输，而预设密钥只存在于服务器，因此，攻击者即时截取到该密文和加密串，也无法进行相应的解密，以此，保护了数据安全，提升了数据传输的安全性。
在步骤405中，对加密串进行解密，得到动态密钥，并基于动态密钥对密文进行解密，得到解密后的数据。
其中，服务器在接收到密文和加密串后，可以根据对该加密串进行解密，得到动态密钥，以此，可以根据该动态密钥对该密文进行解密，得到相应的数据(即明文)，实现安全通信，有效保护小程序到服务器的数据的完整性和安全性，避免攻击者对数据进行解密和破解。
在一些实施方式中，当该加密串为Base64编码得到的时，还需要先将该加密串恢复为二进制的密文，再对该加密串进行解密处理。
在一些实施方式中，服务器中会存储之前对动态密钥进行对称加密处理的预设密钥，所以需要通过预设密钥对加密串进行解密，即参照图10，步骤405包括：
步骤501，通过预设密钥对该加密串进行解密，得到该动态密钥、身份标识和时间戳；
步骤502，当该身份标识和该时间戳验证通过时，根据该动态密钥对该密文进行解密，得到解密后的数据。
其中，服务器在接收到密文和加密串后，可以根据预设密钥对该加密串进行解密，得到加密串中的【动态密钥、身份标识、时间戳】三元组，以此，服务器可以根据解密得到的身份标识对发送者进行身份验证，并通过解密得到时间戳进行时间验证，例如，服务器可以获取发送者的待验证身份标识，将该待验证身份标识与解密得到的身份标识进行比对，当两者匹配时，判定为身份验证通过，当两者不匹配时，判定为身份验证不通过。还可以获取密文的生成时间，判断生成时间是否在时间戳指示的有效时间范围内，当生成时间在时间戳指示的有效时间范围内时，判定为时间戳验证通过，当生成时间不在时间戳指示的有效时间范围内时，判定为时间戳验证不通过。
进一步的，当该身份标识和时间戳均验证通过时，即说明身份验证和时间验证均通过，可以根据该动态密钥对该密文进行解密，得到解密后的数据(即明文)，实现安全通信，有效保护小程序到服务器的数据的完整性和安全性，避免攻击者对数据进行解密和破解。以此，服务器无需存储身份标识和动态密钥，只需要通过解密加密串即可得到身份标识和动态密钥，从而节省了服务器的存储资源。
在一些实施方式中，为了防止身份篡改攻击以及重放攻击，在对密文进行解密之前，还需要进行身份验证以及时间验证，即该当该身份标识和该时间戳验证通过时，根据该动态密钥对该密文进行解密，得到解密后的数据，包括：
获取发送该密文和该加密串的小程序的当前身份标识，以及该密文的生成时间；
获取该时间戳指示的有效终止时间；
当检测到该身份标识和该当前身份标识匹配以及该生成时间在该有效终止时间之前时，根据该动态密钥对该密文进行解密，得到解密后的数据。
需要说明的是，身份篡改攻击指攻击者截取小程序通过通用传输层安全性协议发送的数据，以攻击者的客户端发送数据进行攻击，重放攻击指攻击者不需要解密实际数据包，通过录制数据请求本身，并在一段时间后重放数据请求，导致的一类攻击。
本申请实施例为了防止上述身份篡改攻击以及重放攻击，会对进行身份验证以及时间验证，具体为，服务器可以获取发送密文和加密串的小程序的当前身份标识以及该密文的生成时间。
进一步的，可以将该当前身份标识和解密得到的身份标识进行比对，当两者相同时，判定为身份标识和当前身份标识匹配，当两者不同时，判定为身份标识和当前身份标识不匹配，身份发生篡改。相应的，还可以根据时间戳中的到期时间确定出动态密钥的有效终 止时间。检测该生成时间是否在该有效终止时间之前，当检测到生成时间在有效终止时间之前时，说明时间验证通过，而当检测到生成时间不在有效终止时间之前时，说明时间验证不通过，为重放攻击。基于此，当检测到该身份标识和该当前身份标识匹配以及该生成时间在该有效终止时间之前时，即身份验证和时间验证同时通过时，执行根据该动态密钥对该密文进行解密，得到解密后的数据，以此，可以防止身份篡改攻击以及重放攻击，更好的保护数据传输的安全。
在一些实施方式中，由于小程序对数据进行加密的方式可以为基于AES加密算法，并且使用CBC(Cipher Block Chaining)模式，通过动态密钥对数据进行加密，因此，服务器端通过动态密钥对密文进行解密还需要加密初始向量一并进行解密，即该根据该动态密钥对该密文进行解密，得到解密后的数据，包括：
接收小程序发送的加密初始向量；
根据该动态密钥，对该密文进行解密，得到第一解密结果，将所述第一解密结果和所述加密初始向量进行异或，得到解密后的数据。
具体的，服务器还可以接收小程序发送的加密初始向量，将密文按照每一个分组大小为128bits(即16字节)的方式进行分组，得到多个密文子分组，对于第一个密文子分组，通过动态密钥进行解密，得到第一解密结果，并将该第一解密结果与加密初始向量进行异或，得到第一个密文子分组相应的子明文，而对于第二个密文子分组，可以通过动态密钥进行解密，得到第二解密结果，并将前一个密文子分组(即第一个密文子分组)的子密文与第二解密结果进行异或，得到第二个密文子分组相应的子明文。对于第三个密文子分组，可以通过动态密钥进行解密，得到第三解密结果，并将前一个密文子分组(即第二个密文子分组)的子密文与第三解密结果进行异或，得到第三个密文子分组相应的子明文，以此类推，可以得到每个密文子分组的子明文。
相应的，可以将每个密文子分组的子明文进行拼接，得到解密后的数据。
为了更好的说明本申请实施例，请一并参阅图11进行理解，图11为本申请实施例提供的数据传输方法的交互示意图。在握手阶段，服务器可以根据握手请求生成动态密钥，并根据预设密钥对动态密钥身份标识和时间戳进行对称加密处理，生成相应的加密串。并通过专用传输层安全性协议将动态密钥和加密串发送至小程序。
在加密阶段，小程序可以根据加密初始向量和动态密钥对数据(即明文)进行对称加密，得到相应的密文，并将加密初始向量、密文和加密串通过通用传输层安全性协议一并发送至服务器。
在解密阶段，服务器通过预设密钥对加密串进行解密，恢复动态密钥、身份标识和时 间戳，并在身份标识和时间戳验证通过后，通过动态密钥结合加密初始向量对密文进行解密，得到解密后的数据。以此，通过具有比通用传输层安全性协议更高安全性的专用传输层来传输动态密钥，以及基于动态密钥进行加密处理得到的加密串，通过动态密钥对待发送的数据进行加密，生成相应的密文，且通过通用传输层安全性协议将密文和加密串发送至服务器，以使得服务器根据加密串进行解密恢复的动态密钥对密文进行解密，得到解密后的数据，相对于相关技术中通过静态密钥来实现对称加密的方案而言，本申请实施例可以通过安全性更高的专用传输层安全性协议接收动态密钥，保证动态密钥不被攻击者截取，且通过加密串的形式将动态密钥通过通用传输层安全性协议发送至服务器，避免动态密钥以明文形式进行传输，有效防止动态密钥被破解，提升了数据传输的安全性。
为了更好的说明本申请实施例，请一并参阅图12进行理解，图12为本申请实施例提供的数据传输方法的交互流程图。下面参阅图12，详细说明本申请实施例的数据传输方法的具体交互过程。该过程包括但不限于以下步骤601至步骤613。
步骤601，终端140的小程序通过小程序和服务器之间的专用传输层安全性协议向服务器110发送握手请求。
步骤602，服务器110接收小程序通过专用传输层安全性协议发送的握手请求，根据握手请求生成随机的动态密钥。
步骤603，服务器110根据场景类型查询预设映射表，确定动态密钥相应的有效时间。
步骤604，服务器110基于有效时间确定动态密钥的时间戳。
步骤605，服务器110获取小程序的身份标识，并根据预设密钥对动态密钥、身份标识和时间戳进行加密，得到初始加密串。
步骤606，服务器110对初始加密串通过预设数量个可打印字符进行编码转换，得到相应的加密串。
步骤607，服务器110通过专用传输层安全性协议向终端140的小程序返回动态密钥、动态密钥相应的有效时间以及加密串。
步骤608，终端140上的小程序通过专用传输层安全性协议接收服务器返回的动态密钥、动态密钥相应的有效时间、以及加密串。
步骤609，终端140上的小程序获取待发送的数据，生成随机数，根据数据的生成顺序生成数据的消息序列号，将随机数和消息序列号结合，生成相应的加密初始向量。
步骤610，终端140上的小程序将数据划分为多个数据分组，对于第一个数据分组，将加密初始向量与第一个数据分组进行异或，得到第一个数据分组的第一异或结果，通过动态密钥对第一异或结果进行加密，得到第一个数据分组对应的子密文，对于其它数据分 组，将其它数据分组的前一个数据分组对应的子密文与其它数据分组进行异或，得到其它数据分组的第二异或结果，通过动态密钥对第二异或结果进行加密，得到其它数据分组对应的子密文，将多个数据分组对应的子密文组成为密文。
步骤611，终端140上的小程序通过通用传输层安全性协议将加密初始向量、密文和加密串发送至服务器110。
步骤612，服务器110接收小程序通过通用传输层安全性协议发送的加密后的密文、加密初始向量和加密串。
步骤613，服务器110通过预设密钥对加密串进行解密，恢复动态密钥、身份标识和时间戳，当身份标识和时间戳验证通过时，根据动态密钥和加密初始向量，对密文进行解密，得到解密后的数据。
其中名词的含义与上述数据传输方法中相同，具体实现细节可以参考方法实施例中的说明，在此不再赘述。
为便于更好的实施本申请实施例提供的数据传输方法，本申请实施例还提供一种基于上述数据传输方法的装置。其中名词的含义与上述数据传输方法中相同，具体实现细节可以参考方法实施例中的说明。
请参阅图13，图13为本申请实施例提供的数据传输装置的结构示意图，该数据传输装置应用于终端，其中该数据传输装置可以包括第一发送单元701、第一接收单元702、加密单元703及第二发送单元704等。
第一发送单元701，用于通过小程序和服务器之间的专用传输层安全性协议向服务器发送握手请求，该专用传输层安全性协议具有比通用传输层安全性协议更高的安全性。
第一接收单元702，用于通过该专用传输层安全性协议接收该服务器根据该握手请求返回的动态密钥和根据所述动态密钥得到的加密串。
加密单元703，用于获取待发送的数据，并通过该动态密钥对该数据进行加密，得到密文。
第二发送单元704，用于通过该通用传输层安全性协议将该密文和该加密串发送至服务器，以使得该服务器解密该加密串得到动态密钥，并根据所述动态密钥对该密文进行解密，得到解密后的数据。
以上各个单元的具体实施可参见前面的实施例，在此不再赘述。
请参阅图14，图14为本申请实施例提供的数据传输装置的结构示意图，该数据传输装置应用于终端，其中该数据传输装置可以包括第一接收单元801、生成单元802、返回单元803、第二接收单元804及解密单元805等。
第一接收单元801，用于接收小程序通过专用传输层安全性协议发送的握手请求，该专用传输层安全性协议具有比通用传输层安全性协议更高的安全性。
生成单元802，用于根据该握手请求生成随机的动态密钥，根据该动态密钥得到加密串。
返回单元803，用于通过该专用传输层安全性协议向该小程序返回该动态密钥和该加密串，以使得该小程序根据该动态密钥对待发送的数据进行加密得到密文。
第二接收单元804，用于接收小程序通过该通用传输层安全性协议发送的密文和该加密串。
解密单元805，用于对该加密串进行解密，得到该动态密钥，并基于该动态密钥对该密文进行解密，得到解密后的数据。
以上各个单元的具体实施可参见前面的实施例，在此不再赘述。
本申请实施例还提供一种计算机设备，该计算机设备可以为终端，如图15所示，其示出了本申请实施例所涉及的终端的结构示意图，具体来讲：
该计算机设备可以包括射频(RF，Radio Frequency)电路901、包括有一个或一个以上计算机可读存储介质的存储器902、输入单元903、显示单元904、传感器905、音频电路906、无线保真(WiFi，Wireless Fidelity)模块907、包括有一个或者一个以上处理核心的处理器908、以及电源909等部件。本领域技术人员可以理解，图15中示出的终端结构并不构成对终端的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：
存储器902可用于存储软件程序以及模块，处理器908通过运行存储在存储器902的软件程序以及模块，从而执行各种功能应用以及信息检索。存储器902可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据终端的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器902可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器902还可以包括存储器控制器，以提供处理器908和输入单元903对存储器902的访问。
在本实施例中，终端中的处理器908会按照如下的指令，将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器902中，并由处理器908来运行存储在存储器902中的应用程序，从而实现本申请各实施例提供的方法。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分， 可以参见上文针对文件传输方法的详细描述，此处不再赘述。
本申请实施例还提供一种计算机设备，该计算机设备可以为服务器，如图16所示，其示出了本申请实施例所涉及的服务器的结构示意图，具体来讲：
该计算机设备可以包括一个或者一个以上处理核心的处理器1010、一个或一个以上计算机可读存储介质的存储器1020、电源1030和输入单元1040等部件。本领域技术人员可以理解，图16中示出的计算机设备结构并不构成对计算机设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：
尽管未示出，计算机设备还可以包括显示单元等，在此不再赘述。具体在本实施例中，计算机设备中的处理器1010会按照如下的指令，将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器1020中，并由处理器1010来运行存储在存储器1020中的应用程序，从而实现前述实施例提供的各种方法步骤。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见上文针对队列处理方法的详细描述，此处不再赘述。
本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以通过指令来完成，或通过指令控制相关的硬件来完成，该指令可以存储于一计算机可读存储介质中，并由处理器进行加载和执行。
为此，本申请实施例提供一种计算机可读存储介质，其中存储有多条指令，该指令能够被处理器进行加载，以执行本申请实施例所提供的任一种数据传输方法中的步骤。
根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述实施例提供的各种可选实现方式中提供的方法。
以上各个操作的具体实施可参见前面的实施例，在此不再赘述。
其中，该计算机可读存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取记忆体(RAM，Random Access Memory)、磁盘或光盘等。
由于该计算机可读存储介质中所存储的指令，可以执行本申请实施例所提供的任一种数据传输方法中的步骤，因此，可以实现本申请实施例所提供的任一种数据传输方法所能实现的有益效果，详见前面的实施例，在此不再赘述。
以上对本申请实施例所提供的一种数据传输方法、装置、存储介质及设备进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的技术人员，依据本申 请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (22)

  1. 一种数据传输方法，由终端设备执行，包括：
    通过终端设备内运行的小程序和服务器之间的专用传输层安全性协议向服务器发送握手请求，所述专用传输层安全性协议具有比通用传输层安全性协议更高的安全性；
    通过所述专用传输层安全性协议接收所述服务器返回的动态密钥和根据所述动态密钥得到的加密串；
    获取待发送的数据，并通过所述动态密钥对所述数据进行加密，得到密文；
    通过所述通用传输层安全性协议将所述密文和所述加密串发送至服务器，以使得所述服务器解密所述加密串得到所述动态密钥，并根据所述动态密钥解密所述密文，得到解密后的数据。
  2. 根据权利要求1所述的数据传输方法，其中，所述获取待发送的数据，并通过所述动态密钥对所述数据进行加密，得到密文，包括：
    获取待发送的数据，生成所述数据的加密初始向量，并根据所述加密初始向量对所述数据进行异或，得到异或结果；
    通过所述动态密钥对所述异或结果进行加密，得到所述密文。
  3. 根据权利要求2所述的数据传输方法，其中，所述生成所述数据的加密初始向量，包括：
    生成随机数；
    生成所述数据的消息序列号；
    将所述随机数和所述消息序列号结合，生成所述加密初始向量。
  4. 根据权利要求3所述的数据传输方法，其中，所述根据所述加密初始向量对所述数据进行异或，得到异或结果，包括：
    将所述数据划分为多个数据分组；
    对于第一个数据分组，将所述加密初始向量与所述第一个数据分组进行异或，得到所述第一个数据分组的第一异或结果；
    对于其它数据分组中的每一个数据分组，将该数据分组的前一个数据分组的子密文与该数据分组进行异或，得到所述其它数据分组中每一个数据分组的第二异或结果；
    所述通过所述动态密钥对所述异或结果进行加密，得到所述密文，包括：
    通过所述动态密钥对所述第一异或结果进行加密，得到所述第一个数据分组的子密文；
    通过所述动态密钥对其他数据分组中每一个数据分组的所述第二异或结果进行加密，得到所述其它数据分组中每一个数据分组对应的子密文；
    将多个所述数据分组对应的所述子密文组成为密文。
  5. 根据权利要求2至4任一项所述的数据传输方法，进一步包括：
    通过通用传输层安全性协议将所述加密初始向量发送至服务器，以使得所述服务器根据所述动态密钥解密所述密文得到第一解密结果，将所述第一解密结果和所述加密初始向量进行异或，得到所述解密后的数据。
  6. 根据权利要求1至5任一项所述的数据传输方法，其中，所述握手请求携带场景类型；
    所述方法进一步包括：
    通过所述专用传输层安全性协议接收所述服务器返回的所述动态密钥的有效时间；
    其中，所述有效时间为服务器根据所述握手请求携带的所述场景类型确定的。
  7. 根据权利要求6所述的数据传输方法，进一步包括：
    根据所述有效时间确定所述动态密钥的有效终止时间；
    当检测到当前时间到达所述有效终止时间时，重新执行通过小程序和服务器之间的专用传输层安全性协议向服务器发送握手请求，以通过所述专用传输层安全性协议重新接收更新的动态密钥、有效时间和加密串。
  8. 根据权利要求6所述的数据传输方法，进一步包括：
    当检测到所述场景类型变化时，删除所述动态密钥、所述动态密钥的有效时间、以及基于所述动态密钥进行加密处理得到的加密串；
    重新执行通过小程序和服务器之间的专用传输层安全性协议向服务器发送握手请求，以通过所述专用传输层安全性协议重新接收更新的动态密钥、有效时间和加密串。
  9. 根据权利要求1至5任一项所述的数据传输方法，其中，所述握手请求携带场景类型和应用隐私级别；
    所述方法进一步包括：
    通过所述专用传输层安全性协议接收所述服务器根据所述握手请求返回的所述动态密钥的有效时间；
    其中，所述有效时间为服务器根据所述握手请求携带的所述场景类型和应用隐私级别一并确定的。
  10. 根据权利要求1至9任一项所述的数据传输方法，其中，所述专用传输层安全性协议为MMTLS协议；所述通用传输层安全性协议为TLS协议。
  11. 一种数据传输方法，由服务器设备执行，包括：
    接收小程序通过专用传输层安全性协议发送的握手请求，所述专用传输层安全性协议 具有比通用传输层安全性协议更高的安全性；
    根据所述握手请求生成随机的动态密钥，根据所述动态密钥得到加密串；
    通过所述专用传输层安全性协议向所述小程序返回所述动态密钥和所述加密串，以使得所述小程序根据所述动态密钥对待发送的数据进行加密得到密文；
    接收小程序通过所述通用传输层安全性协议发送的所述密文和所述加密串；
    解密所述加密串得到所述动态密钥，并基于所述动态密钥解密所述密文得到解密后的数据。
  12. 根据权利要求11所述的数据传输方法，其中，所述根据所述握手请求生成随机的动态密钥，根据所述动态密钥得到所述加密串，包括：
    根据所述握手请求生成随机的动态密钥，并确定所述动态密钥的有效时间；
    基于所述有效时间确定所述动态密钥的时间戳；
    获取所述小程序的用户身份标识，加密所述动态密钥、用户身份标识和时间戳，得到所述加密串。
  13. 根据权利要求12所述的数据传输方法，其中，所述加密所述动态密钥、身份标识和时间戳，得到所述加密串，包括：
    根据预设密钥对所述动态密钥、身份标识和时间戳进行加密处理，得到初始加密串；
    对所述初始加密串通过预设数量个可打印字符进行编码转换，得到所述加密串。
  14. 根据权利要求12或13所述的数据传输方法，其中，所述握手请求携带场景类型；
    所述确定所述动态密钥的有效时间，包括：
    根据第一预设映射表，确定所述动态密钥的有效时间；
    其中，所述第一预设映射表中包括不同场景类型与有效时间的映射关系。
  15. 根据权利要求12或13所述的数据传输方法，其中，所述握手请求携带场景类型和应用隐私级别；
    所述确定所述动态密钥的有效时间，包括：
    根据第二预设映射表，确定所述动态密钥的初始有效时间；
    其中，所述第二预设映射表中包括不同场景类型与初始有效时间的映射关系；
    根据所述应用隐私级别确定权重，并基于所述权重对所述初始有效时间进行加权，得到所述动态密钥的有效时间。
  16. 根据权利要求12至15任一项所述的数据传输方法，进一步包括：
    通过专用传输层安全性协议向所述小程序返回所述动态密钥的有效时间，以使得所述小程序在所述有效时间内，根据所述动态密钥对待发送的数据进行加密。
  17. 根据权利要求12至16任一项所述的数据传输方法，进一步包括：
    对从小程序接收的所述加密串进行解密，得到所述身份标识和时间戳；
    当所述身份标识和所述时间戳验证通过时，执行根据所述动态密钥对所述密文进行解密的操作。
  18. 根据权利要求17所述的数据传输方法，其中，所述根据所述动态密钥对所述密文进行解密，得到解密后的数据，包括：
    接收小程序发送的加密初始向量；
    根据所述动态密钥，解密所述密文得到第一解密结果，将所述第一解密结果和所述加密初始向量进行异或，得到所述解密后的数据。
  19. 一种数据传输装置，包括：
    第一发送单元，用于通过小程序和服务器之间的专用传输层安全性协议向服务器发送握手请求，所述专用传输层安全性协议具有比通用传输层安全性协议更高的安全性；
    第一接收单元，用于通过所述专用传输层安全性协议接收所述服务器根据所述握手请求返回的动态密钥和根据所述动态密钥得到的加密串；
    加密单元，用于获取待发送的数据，并通过所述动态密钥对所述数据进行加密，得到密文；
    第二发送单元，用于通过所述通用传输层安全性协议将所述密文和所述加密串发送至服务器，以使得所述服务器解密所述加密串得到所述动态密钥，并根据所述动态密钥解密所述密文，得到解密后的数据。
  20. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有多条指令，所述指令适于处理器进行加载，以执行权利要求1至18任一项所述的数据传输方法中的步骤。
  21. 一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可以在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至18任一项所述的数据传输方法中的步骤。
  22. 一种计算机程序产品，所述计算机程序产品包括计算机指令，所述计算机指令存储在计算机可读存储介质中，当所述计算机指令被执行时，实现权利要求1至18任一项所述的数据传输方法中的步骤。
PCT/CN2024/113806 2023-10-17 2024-08-22 数据传输方法、装置、存储介质及设备 Pending WO2025082030A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202311348871.8 2023-10-17
CN202311348871.8A CN119853935A (zh) 2023-10-17 2023-10-17 一种数据传输方法、装置、存储介质及设备

Publications (1)

Publication Number Publication Date
WO2025082030A1 true WO2025082030A1 (zh) 2025-04-24

Family

ID=95365803

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2024/113806 Pending WO2025082030A1 (zh) 2023-10-17 2024-08-22 数据传输方法、装置、存储介质及设备

Country Status (2)

Country Link
CN (1) CN119853935A (zh)
WO (1) WO2025082030A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN120200738A (zh) * 2025-05-22 2025-06-24 上海正先电子科技有限公司 基于加密处理的lcd安全保护系统
CN120768669A (zh) * 2025-08-20 2025-10-10 北京创卓文化传播有限公司 一种大数据网络安全数据传输方法
CN120785653A (zh) * 2025-09-10 2025-10-14 浪潮电子信息产业股份有限公司 通信失步状态防护方法、设备、介质及程序产品

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1449617A (zh) * 2000-08-25 2003-10-15 捷讯研究有限公司 实现增强型传输层安全协议的系统和方法
US20190386966A1 (en) * 2018-06-19 2019-12-19 Cypress Semiconductor Corporation Secured communication from within non-volatile memory device
CN116318947A (zh) * 2023-03-09 2023-06-23 戎码科技(北京)有限公司 一种基于tls协议的数据传输的方法、介质及电子设备
CN116405282A (zh) * 2023-04-06 2023-07-07 威胜集团有限公司 一种基于动态协商密钥的数据通信方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1449617A (zh) * 2000-08-25 2003-10-15 捷讯研究有限公司 实现增强型传输层安全协议的系统和方法
US20190386966A1 (en) * 2018-06-19 2019-12-19 Cypress Semiconductor Corporation Secured communication from within non-volatile memory device
CN116318947A (zh) * 2023-03-09 2023-06-23 戎码科技(北京)有限公司 一种基于tls协议的数据传输的方法、介质及电子设备
CN116405282A (zh) * 2023-04-06 2023-07-07 威胜集团有限公司 一种基于动态协商密钥的数据通信方法

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN120200738A (zh) * 2025-05-22 2025-06-24 上海正先电子科技有限公司 基于加密处理的lcd安全保护系统
CN120768669A (zh) * 2025-08-20 2025-10-10 北京创卓文化传播有限公司 一种大数据网络安全数据传输方法
CN120785653A (zh) * 2025-09-10 2025-10-14 浪潮电子信息产业股份有限公司 通信失步状态防护方法、设备、介质及程序产品

Also Published As

Publication number Publication date
CN119853935A (zh) 2025-04-18

Similar Documents

Publication Publication Date Title
US10693848B2 (en) Installation of a terminal in a secure system
US8447970B2 (en) Securing out-of-band messages
US5657390A (en) Secure socket layer application program apparatus and method
CN114244508B (zh) 数据加密方法、装置、设备及存储介质
US12432042B2 (en) Network traffic obfuscation
EP3205048B1 (en) Generating a symmetric encryption key
US20040088539A1 (en) System and method for securing digital messages
CN102088441B (zh) 消息中间件的数据加密传输方法和系统
CN112689014B (zh) 一种双全工通信方法、装置、计算机设备和存储介质
WO2025082030A1 (zh) 数据传输方法、装置、存储介质及设备
EP3614292A1 (en) File transfer system comprising an upload, storage and download device
WO2016003525A2 (en) System and method for secure data transmission and storage
CN101867473B (zh) 抗阻塞攻击的共享媒体终端连接建立方法和接入认证系统
CN102088352B (zh) 消息中间件的数据加密传输方法和系统
US20250133068A1 (en) Encrypted communication method and apparatus, device, and storage medium
CN107210915A (zh) 相互认证
CN107408187A (zh) 通过认证令牌的改进安全
CN110995730B (zh) 数据传输方法、装置、代理服务器和代理服务器集群
US20130283363A1 (en) Secure data transfer over an arbitrary public or private transport
CN108701195B (zh) 一种数据安全保护方法及装置
CN110417804B (zh) 一种适于单片机实现的双向身份认证加密通信方法及系统
CN107104888A (zh) 一种安全的即时通信方法
CN107612691A (zh) 认证信息传输方法和装置以及用户信息认证系统
Schulz et al. d 2 Deleting Diaspora: Practical attacks for profile discovery and deletion
CN107343001B (zh) 数据处理方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24878681

Country of ref document: EP

Kind code of ref document: A1