A data processing method, apparatus, device, and medium

Abstract

This application discloses a data processing method, apparatus, device, and medium. The method includes: assigning a target sequence number to a target data block and recording the current timestamp as the target timestamp; wherein the target sequence numbers corresponding to the target data blocks from front to back are monotonically increasing; generating a target key based on a preset key derivation function, according to the target sequence number, target timestamp, and root key; wherein the root key is generated by a key exchange protocol when the sender and receiver establish a session, and is shared by the sender and receiver and used during the session; encrypting the target data block based on the target key to obtain an encrypted data block, and constructing a target data packet based on the encrypted data block, target sequence number, and target timestamp, and sending it to the receiver. The above scheme can balance the deficiencies in security, performance, and implementation complexity, achieving secure and efficient encryption.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a data processing method, apparatus, device and medium. Background Technology

[0002] To ensure data transmission security, the following two main key management schemes are currently adopted, but they face challenges in high-performance transmission scenarios: 1. Static or long-term key schemes: such as early TLS 1.2 or basic IPsec. A fixed session key is negotiated when the session is established and reused for encryption and decryption of all data throughout the session's lifecycle. To improve security, some implementations introduce periodic update mechanisms based on time or data transmission volume thresholds, renegotiating or deriving new keys through additional "key update" signaling. Periodic key update schemes require additional signaling interaction to synchronize the key states of both parties. This can disrupt the transmission pipeline in high-speed data streams, introducing millisecond- to second-level latency jitter and bandwidth overhead, fundamentally conflicting with the core requirements of high throughput and stable low latency. 2. Dynamic key schemes based on external events: Technical solutions: To pursue higher key dynamism, some schemes have emerged that rely on external events to trigger key changes. For example: Hardware-dependent: using the response of a physically unclonable function (PUF) or instructions from specific hardware security modules to generate or update keys. Interactive systems: These schemes negotiate new keys through inter-system interactions such as blockchain smart contract calls and instructions from external authorization servers. Based on well-known technologies: These schemes bind the dynamism of keys to hardware characteristics or the state of external systems. Dynamic key schemes based on external events (hardware responses, blockchain transactions, etc.) heavily rely on the reliability, real-time performance, and availability of external systems for key synchronization. This not only introduces single-point-of-failure risks and new sources of latency but also makes the recovery or auditing of historical session keys exceptionally complex and costly. In traditional architectures, data encryption, replay attack resistance, and out-of-order recovery are handled by different modules such as encryption modules, sequence number verification windows, and retransmission protocols. This decoupled design increases the complexity and processing overhead of system state management, potentially becoming a performance bottleneck when dealing with high-speed data streams. Summary of the Invention

[0003] This application provides a data processing method, apparatus, device, and medium that enables fine-grained dynamic key management without relying on external systems and solely through the communicating parties, thereby achieving real-time key generation and updating.

[0004] According to one aspect of this application, a data processing method is provided, applied at a sending end, the method comprising:

[0005] Assign a target sequence number to the target data block and record the current timestamp as the target timestamp; wherein, the target sequence number corresponding to the target data block from the beginning to the end of time is monotonically increasing;

[0006] Based on a preset key derivation function, a target key is generated according to the target sequence number, the target timestamp, and the root key; wherein, the root key is generated by the sender and receiver through a key exchange protocol when establishing a session, and the root key is shared by the sender and receiver and used during the session;

[0007] The target data block is encrypted using the target key to obtain an encrypted data block, and a target data packet is constructed based on the encrypted data block, the target sequence number, and the target timestamp and sent to the receiving end.

[0008] According to one aspect of this application, a data processing method is provided, applied at a receiving end, the method comprising:

[0009] The system receives a target data packet sent by a sender and parses the target data packet to obtain an encrypted data block, a receiving sequence number, and a receiving timestamp; wherein the target data packet is obtained by processing according to the data processing method of any embodiment.

[0010] Based on the preset key derivation function, a decryption key is generated according to the received sequence number, the received timestamp, and the root key;

[0011] The target data block is obtained by decrypting the encrypted data block using the decryption key.

[0012] According to one aspect of this application, a data processing apparatus is provided, configured at a transmitting end, the apparatus comprising:

[0013] The information determination module can be used to assign target sequence numbers to target data blocks and record the current timestamp as the target timestamp; wherein, the target sequence numbers corresponding to the target data blocks from front to back in time are monotonically increasing;

[0014] The target key generation module is used to generate a target key based on a preset key derivation function, according to the target sequence number, the target timestamp, and the root key; wherein, the root key is generated by the sending end and the receiving end through a key exchange protocol when they establish a session, and the root key is shared by the sending end and the receiving end and used during the session;

[0015] An encrypted data block generation module is used to encrypt the target data block based on the target key to obtain an encrypted data block, and to construct a target data packet based on the encrypted data block, the target sequence number and the target timestamp and send it to the receiving end.

[0016] According to one aspect of this application, a data processing apparatus is provided, configured at a receiving end, the apparatus comprising:

[0017] The parsing module is used to receive the target data packet sent by the sender and parse the target data packet to obtain an encrypted data block, a receiving sequence number, and a receiving timestamp; wherein the target data packet is obtained by processing according to the data processing method of any embodiment;

[0018] The decryption key generation module is used to generate a decryption key based on a preset key derivation function, according to the received sequence number, the received timestamp, and the root key.

[0019] The decryption module is used to decrypt the encrypted data block based on the decryption key to obtain the target data block.

[0020] According to another aspect of this application, an electronic device is provided, the electronic device comprising:

[0021] At least one processor; and,

[0022] A memory that is communicatively connected to at least one processor; wherein,

[0023] The memory stores a computer program that can be executed by at least one processor, such that the at least one processor can perform a data processing method applied to a sending end or a data processing method applied to a receiving end according to any embodiment of this application.

[0024] According to another aspect of this application, a computer-readable storage medium is provided, which stores computer instructions for causing a processor to execute and implement a data processing method applied to a transmitting end or a data processing method applied to a receiving end, according to any embodiment of this application.

[0025] According to another aspect of this application, a computer program product is provided, which includes a computer program that, when executed by a processor, implements a data processing method applied to a transmitting end or a data processing method applied to a receiving end according to any embodiment of this application.

[0026] The technical solution of this application embodiment assigns a target sequence number to a target data block and records the current timestamp as the target timestamp; wherein, the target sequence number corresponding to the target data block from front to back is monotonically increasing; based on a preset key derivation function, a target key is generated according to the target sequence number, the target timestamp, and the root key; wherein, the root key is generated by the sending end and the receiving end through a key exchange protocol when establishing a session, and the root key is shared by the sending end and the receiving end and used during the session; based on the target key, the target data block is encrypted to obtain an encrypted data block, and a target data packet is constructed according to the encrypted data block, the target sequence number, and the target timestamp and sent to the receiving end. The above solution achieves cross-session global uniqueness of the key derivation factor of a single data packet by forcing the data packet sequence number and the monotonically increasing session timestamp to be used as the joint input of the key derivation function; and achieves the intrinsic dependence of key validity on the "freshness" of the data packet time sequence by having the receiving end strictly verify and derive the key according to the sequence number and timestamp value in the data packet header. Ultimately, this achieves the goal of automatically rejecting any replay packets from a cryptographic mechanism, thereby eradicating the threat of cross-session replay attacks without the need to maintain and query additional replay protection status lists.

[0027] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0028] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0029] Figure 1 A flowchart illustrating a data processing method applied at the sending end, as provided in an embodiment of this application;

[0030] Figure 2 A flowchart illustrating a data processing method applied at a sending end, as provided in another embodiment of this application;

[0031] Figure 3 A flowchart illustrating a data processing method applied at a receiving end, as provided in an embodiment of this application;

[0032] Figure 4 An interactive schematic diagram of the data processing method provided in the embodiments of this application;

[0033] Figure 5A flowchart illustrating the specific implementation of the data processing method provided in the embodiments of this application;

[0034] Figure 6 This application provides a schematic diagram of the structure of a data processing device configured at the transmitting end according to an embodiment of the present application.

[0035] Figure 7 This application provides a schematic diagram of the structure of a data processing device configured at a receiving end according to an embodiment of the present application.

[0036] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0037] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0038] It should be noted that the terms "first," "second," "third," "fourth," "actual," "preset," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0039] The acquisition, storage, use, and processing of data in this application comply with relevant national laws and regulations. The acquired data is obtained with authorization and will not be disclosed without permission, used for illegal purposes, purposes detrimental to the interests of others, or for personalized analysis or product promotion. It should be noted that certain software, components, models, and other existing industry solutions may be mentioned in the embodiments of this application. These should be considered exemplary and intended only to illustrate the feasibility of implementing the technical solution of this application, but do not imply that the applicant has already used or necessarily used the relevant content of such solutions.

[0040] Figure 1 This is a flowchart illustrating a data processing method applied at a sending end, provided as an embodiment of this application. This embodiment is applicable to situations where a target key is generated to encrypt a target data block. The method can be executed by a data processing device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the method includes:

[0041] S110. Assign a target sequence number to the target data block and record the current timestamp as the target timestamp; wherein, the target sequence number corresponding to the target data block from front to back is monotonically increasing.

[0042] The target data block is the data block that needs to be encrypted. The target sequence number is a basic field that provides the sequential identifier of the target data block and is the basis for ensuring reliable transmission and basic state synchronization. The target sequence number is monotonically incremented by the sending protocol stack when sending the target data block; that is, the target sequence number corresponding to the target data block from beginning to end is monotonically increasing. The data type of the target data number is, for example, unit32 or unit63. Its format and increment rules can be defined by the underlying transport protocol specification. The target timestamp is a timestamp that uniquely identifies the target data block transmission event. The target timestamp can be generated by the sending protocol stack, and its recommended data structure is a 64-bit unsigned integer, representing the number of microseconds elapsed since the start of the current session. Essentially, it is a session-bound, monotonically increasing high-precision counter. The core value of the target timestamp lies in providing global uniqueness and resistance to cross-session replay: the target timestamp and the target sequence number form a two-factor binding, ensuring that the key derivation input is globally unique throughout the entire service lifecycle. Even if the target sequence number is repeated in a new session, the inherently different target timestamps prevent the replay of old packets from deriving the correct key, thus naturally immunizing against cross-session replay attacks. Enhanced robustness of state recovery: In the event of packet loss or out-of-order delivery, the target timestamp provides the receiver with a second dimension of recovery clues. The receiver can combine the sequentiality of the target sequence number with the monotonicity and continuity of the target timestamp to perform more intelligent state inference and attempts, significantly improving the efficiency and accuracy of synchronization recovery.

[0043] S120. Based on a preset key derivation function, generate a target key according to the target sequence number, the target timestamp, and the root key; wherein, the root key is generated by the sender and receiver through a key exchange protocol when establishing a session, and the root key is shared by the sender and receiver and used during the session.

[0044] The preset key derivation function is a pre-selected key derivation function, which is a cryptographic algorithm used to derive one or more secure encryption keys from a secret value (such as a password, master key, or shared key). Its core purpose is to enhance security and prevent threats such as brute-force attacks and rainbow table attacks. The root key is the top-level, most basic key in the key hierarchy, used to derive or protect other keys.

[0045] In this embodiment, the root key can be generated by a key exchange protocol when the sender and receiver establish a session. During session initialization, a root key shared by both parties is generated and securely stored using a standard key exchange protocol (such as ECDHE). This operation is performed only once at the start of the connection, shared between the sender and receiver, and used throughout the session.

[0046] In this embodiment of the application, the target sequence number, target timestamp and root key can be input into the preset key derivation function based on the preset key derivation function, thereby generating the target key in real time for temporary encryption.

[0047] S130. The target data block is encrypted based on the target key to obtain an encrypted data block, and a target data packet is constructed based on the encrypted data block, the target sequence number and the target timestamp and sent to the receiving end.

[0048] For example, the target data block can be encrypted using the target key to obtain an encrypted data block. When sending data to the receiving end, the encrypted data block, the target sequence number, and the target timestamp need to be sent to the receiving end so that the receiving end can generate a decryption key based on the target sequence number and the target timestamp to decrypt the encrypted data block and obtain the target data. Specifically, the target sequence number and the target timestamp are carried in plaintext in the header of the target data packet, and the encrypted data block is used as the data of the target data packet to construct the target data packet, which is then sent to the receiving end.

[0049] After receiving the target data packet, the receiving end calls the preset key derivation function based on the target sequence number and target timestamp in the header, as well as the root key that has been negotiated and stored with the sending end in advance, to generate a decryption key. The receiving end then decrypts the encrypted data block based on the decryption key to obtain the target data block.

[0050] The technical solution of this application embodiment assigns a target sequence number to a target data block and records the current timestamp as the target timestamp; wherein, the target sequence number corresponding to the target data block from front to back is monotonically increasing; based on a preset key derivation function, a target key is generated according to the target sequence number, the target timestamp, and the root key; wherein, the root key is generated by the sending end and the receiving end through a key exchange protocol when establishing a session, and the root key is shared by the sending end and the receiving end and used during the session; based on the target key, the target data block is encrypted to obtain an encrypted data block, and a target data packet is constructed according to the encrypted data block, the target sequence number, and the target timestamp and sent to the receiving end. The above solution achieves cross-session global uniqueness of the key derivation factor of a single data packet by forcing the data packet sequence number and the monotonically increasing session timestamp to be used as the joint input of the key derivation function; and achieves the intrinsic dependence of key validity on the "freshness" of the data packet time sequence by having the receiving end strictly verify and derive the key according to the sequence number and timestamp value in the data packet header. Ultimately, this achieves the goal of automatically rejecting any replay packets from a cryptographic mechanism, thereby eradicating the threat of cross-session replay attacks without the need to maintain and query additional replay protection status lists.

[0051] Figure 2 This is a flowchart illustrating a data processing method applied to a sending end, as provided in another embodiment of this application. This embodiment is an optimization based on the above embodiment; solutions not described in detail in this embodiment are found in the above embodiment. Figure 2 As shown, the method in this embodiment of the application specifically includes the following steps:

[0052] S210. Assign a target sequence number to the target data block.

[0053] S220. Determine the start time of the session established between the sending end and the receiving end.

[0054] For example, the sender generates a target timestamp for each target data block, but the target timestamp is not an absolute calendar time, but a microsecond-level counter that monotonically increases from the start of the session.

[0055] S230. Generate a counter that monotonically increases from the start time, and use the counter as the target timestamp.

[0056] For example, a counter that monotonically increases from the start time is generated, and this counter is used as the target timestamp. The timestamp is recommended to be defined as `uint64_t` (a 64-bit unsigned integer), representing the microsecond offset from the session establishment time. It will only wrap around after approximately 580,000 years, which can be considered as non-wrapping for a single session. The start time of the session established between the sender and receiver can be determined, and the target timestamp can be determined based on this start time. Wrap-around and session restart handling: Intra-session wrap-around: In extremely long sessions, if wrap-around occurs, the algorithm treats it as a new monotonically increasing cycle starting from 0. The receiver can identify this by detecting a sudden decrease in the value (but combined with a very large sequence number) and maintain monotonicity judgment by extending the high-order logical count. Monotonicity during session restart: To ensure global monotonicity across sessions (enhancing replay resistance), the base value of the target timestamp (session start time) should be taken from a system clock that never goes backward (such as `CLOCK_MONOTONIC`). Even if the application restarts, the target timestamp of the new session will always be later than that of all old sessions, thus maintaining the global increasing trend of time.

[0057] In this embodiment of the application, generating a counter that monotonically increases from the start time includes:

[0058] The elapsed time since the start time is detected by a monotonic clock;

[0059] The sum of the start time and the elapsed time is used as the value of the counter.

[0060] One feasible approach is to detect the elapsed time since the start time using a monotonic time counter, and then add the elapsed time to the start time as the value of a counter. (Target timestamp) .in It is the start time recorded when the session is established. The sending end uses a high-precision monotonic clock (such as...) after the session begins. (Measured elapsed time)

[0061] In this embodiment of the application, generating a counter that monotonically increases from the start time includes:

[0062] A counter is generated that monotonically increases from the start time, and increments by one for each target data block sent or at a preset time interval.

[0063] As another possible approach, a counter can be generated that monotonically increases from the start time, incrementing by one for each target data block sent or at preset time intervals. The preset time interval can be determined based on the actual situation, for example, it could be 1 microsecond.

[0064] Regardless of the method used, it must be ensured that within the same session, It strictly increases monotonically according to the order in which data packets are sent, and has sufficient precision (microsecond level).

[0065] S240. Concatenate the target sequence number with the target timestamp to obtain salt data.

[0066] For example, the target sequence number and the target timestamp can be concatenated to obtain salt data. To ensure consistency, it is recommended to specify a fixed byte order (e.g., big-endian) and length (e.g., both 64 bits) for concatenation. For example: Salt = Seq(8 bytes) || Ts(8 bytes).

[0067] S250. Input the root key and the salt data into a preset key derivation function to generate the target key.

[0068] The root key and salt data are input into the preset key derivation function to generate the target key.

[0069] Specifically, the root key is stored securely. For the input key material, use the target sequence number corresponding to the i-th target data block. and target timestamp The concatenation of the two bytes is used as the salt. The standard HKDF algorithm is then called (this solution recommends using the industry-standard, cryptographically verified HKDF-SHA-256 algorithm; the specific output length depends on the selected symmetric encryption algorithm. If AES-256-GCM is used, a 32-byte (256-bit) key material needs to be output). The sequence number (Seq) and timestamp (Ts) are used as the salt. To ensure consistency, it is recommended to specify a fixed byte order (e.g., big-endian) and length (e.g., both 64 bits) for concatenation. For example: Salt = Seq (8 bytes) || Ts (8 bytes). This derives the length-matching encryption algorithm requirements. This process is deterministic.

[0070] S260. The target data block is encrypted based on the target key to obtain an encrypted data block, and a target data packet is constructed based on the encrypted data block, the target sequence number, and the target timestamp and sent to the receiving end.

[0071] Encryption module use Encrypt and protect the target data block for integrity (e.g., using AES-256-GCM). Then, combine the ciphertext with the plaintext. , The target data packet is encapsulated with other necessary protocol headers and sent to the receiving end.

[0072] The scheme in this application embodiment determines the start time of the session established between the sending end and the receiving end; generates a counter that monotonically increases from the start time, and uses the counter as the target timestamp. By introducing a timestamp and combining it with a sequence number, this scheme overcomes the inherent defects of schemes that only use sequence numbers. The global monotonicity of the timestamp fundamentally defends against cross-session replay attacks, while the timing information it provides greatly enhances the receiver's self-recovery capability under adverse network conditions, giving the scheme higher security strength and practicality.

[0073] Figure 3 This is a flowchart illustrating a data processing method applied to a receiving end, as provided in one embodiment of this application. This embodiment is an optimization based on the above embodiment; solutions not described in detail in this embodiment are found in the above embodiment. Figure 3 As shown, the method in this embodiment of the application specifically includes the following steps:

[0074] S310. Receive the target data packet sent by the sending end, and parse the target data packet to obtain an encrypted data block, a receiving sequence number, and a receiving timestamp; wherein, the target data packet is obtained by the data processing method of the sending end in any of the above embodiments.

[0075] In this embodiment, the target data packet is obtained by applying the data processing method of the sending end in any of the above embodiments. After the sending end generates the target data packet, it sends it to the receiving end. The receiving end receives the target data packet and parses the target data table to obtain the encrypted data block, the receiving sequence number, and the receiving timestamp. Since the sequence number and timestamp obtained by parsing cannot be determined to be the target sequence number and target timestamp, they are named the receiving sequence number and receiving timestamp, which may be consistent with the target sequence number and target timestamp, or they may deviate.

[0076] S320. Based on the preset key derivation function, generate a decryption key according to the received sequence number, the received timestamp, and the root key.

[0077] For example, the preset key derivation function used by the receiver is the same as the preset key derivation function used by the sender. The root key is generated and stored by the receiver and sender through a key exchange protocol when establishing a session, and is consistent with the root key of the sender.

[0078] In this embodiment, a decryption key is generated based on a preset key derivation function, according to the received sequence number, the received timestamp, and the root key.

[0079] S330. Decrypt the encrypted data block based on the decryption key to obtain the target data block.

[0080] For example, the target data block is obtained by decrypting the encrypted data block based on the decryption key, thereby achieving secure transmission of the target data block.

[0081] The solution in this application embodiment receives a target data packet sent by a sending end, and parses the target data packet to obtain an encrypted data block, a receiving sequence number, and a receiving timestamp. The target data packet is processed by a data processing method applied to the sending end. A decryption key is generated based on a preset key derivation function, according to the receiving sequence number, the receiving timestamp, and a root key. The encrypted data block is decrypted using the decryption key to obtain the target data block. This solution enables secure reception and decryption of the target data packet, achieving real-time secure decryption and acquisition of the target data block without introducing an external system.

[0082] As a non-limiting implementation, based on a preset key derivation function, a decryption key is generated according to the received sequence number, the received timestamp, and the root key, including:

[0083] If the encryption of the data block fails to be decrypted based on the received sequence number, the received timestamp, and the key generated from the root key, then the received sequence number is adjusted to obtain an adjusted sequence number, and / or the received timestamp is adjusted to obtain an adjusted timestamp.

[0084] The adjustment of the received sequence number and / or received timestamp shall cease until at least one of the following is met, and the generated key shall be used as the decryption key:

[0085] The encrypted data block was successfully decrypted based on the adjusted sequence number, the received timestamp, and the key generated from the root key.

[0086] The encrypted data block was successfully decrypted based on the received sequence number, the adjusted timestamp, and the key generated from the root key;

[0087] The encrypted data block was successfully decrypted using the adjusted sequence number, the adjusted timestamp, and the key generated from the root key.

[0088] In this embodiment, after receiving the receiving sequence number, receiving timestamp, and root key, the encrypted data block is decrypted based on the receiving sequence, receiving timestamp, and root key. If decryption fails, meaning the target data block cannot be decrypted, the receiving sequence number is adjusted to obtain an adjusted sequence number, and / or the receiving timestamp is adjusted to obtain an adjusted timestamp. The adjustment process stops when at least one of the following conditions is met:

[0089] The encrypted data block was successfully decrypted based on the adjusted sequence number, the received timestamp, and the key generated from the root key;

[0090] The encrypted data block was successfully decrypted based on the received sequence number, the adjusted timestamp, and the key generated from the root key;

[0091] The encrypted data block was successfully decrypted using the adjusted sequence number, the adjusted timestamp, and the key generated from the root key.

[0092] For example, if only the received sequence number is adjusted, an adjusted sequence number is obtained. If the encrypted data block is successfully decrypted using the key generated based on the adjusted sequence number, the received timestamp, and the root key, this serves as a condition to stop the adjustment.

[0093] If only the received timestamp is adjusted, the adjusted timestamp is obtained. If the encrypted data block is successfully decrypted using the key generated based on the received sequence number, the adjusted timestamp, and the root key, this serves as the condition for stopping the adjustment.

[0094] If the received sequence number and received timestamp are adjusted simultaneously, the adjusted sequence number and adjusted timestamp are obtained. If the encrypted data block is successfully decrypted using the key generated from the adjusted sequence number, adjusted timestamp, and root key, this serves as the condition for stopping the adjustment.

[0095] As a non-limiting implementation, adjusting the received sequence number to obtain an adjusted sequence number includes:

[0096] The received sequence number is adjusted within the range defined by a preset attempt sequence number window to obtain the adjusted sequence number; wherein, the lower limit of the preset attempt sequence number window is the difference between the expected sequence number and the first adjustment amount, and the upper limit of the preset attempt sequence number window is the sum of the expected sequence number and the second adjustment amount; the expected sequence number is a sequence number predicted based on the decryption sequence number or the adjusted sequence number used in the process of generating the decryption key for successfully decrypting the previous encrypted data block.

[0097] In this embodiment of the application, during the process of adjusting the received serial number, the received serial number can be adjusted within the range limited by the preset attempt serial number window to obtain the adjusted serial number, thereby making effective adjustments within a reasonable range where suitable serial numbers can be found.

[0098] The lower limit of the preset attempt sequence number window is the difference between the expected sequence number and the first adjustment amount, and the upper limit of the preset attempt sequence number window is the sum of the expected sequence number and the second adjustment amount, expressed as follows: ;in, The expected serial number, The first adjustment amount, This is the second adjustment amount. The first and second adjustment amounts can be the smallest unit of the target sequence number, such as 2, 3, etc. The expected sequence number is determined based on the decryption sequence number or adjustment sequence number used to generate the decryption key when the previous encrypted data block was successfully decrypted. It can be predicted based on the previous decryption sequence number and adjustment sequence number, for example, by incrementing the previous decryption sequence number and adjustment sequence number according to the smallest sequence number unit.

[0099] As a non-limiting implementation, before the received timestamp is used to generate the decryption key, it also includes:

[0100] If the received timestamp falls within the first preset timestamp window, the received timestamp is used to generate a decryption key; wherein, the lower limit of the first preset timestamp window is the difference between the expected timestamp and the first adjustment value, and the upper limit of the first preset timestamp window is the sum of the expected timestamp and the second adjustment value;

[0101] If the received timestamp falls within the second preset timestamp window but not within the first preset timestamp window, the received timestamp is adjusted to obtain an adjusted timestamp used to generate a decryption key; wherein, the second preset timestamp window includes the first preset timestamp window, and the range of the second preset timestamp window is larger than that of the first preset timestamp window; the lower limit of the second preset timestamp window is the difference between the expected timestamp and the third adjustment value, and the upper limit of the second preset timestamp window is the sum of the expected timestamp and the fourth adjustment value.

[0102] For example, before generating the decryption key using the received timestamp, a certain judgment needs to be made on the received timestamp to determine whether it can be directly used to generate the decryption key. This can be done by determining whether the received timestamp falls within a first preset time window. If so, the received timestamp is used to generate the decryption key. The lower limit of the first preset time window is the difference between the expected timestamp and a first adjustment value, and the upper limit of the first preset time window is the sum of the expected timestamp and a second adjustment value, expressed as follows: ,in, For the desired timestamp, The first adjustment value, This is the second adjustment value. The expected timestamp can be the current predicted value based on the timestamp used by the successfully decrypted decryption key. The first and second adjustment values ​​can be values ​​determined based on the actual situation and can be multiples of the smallest timestamp unit.

[0103] If the received timestamp falls within the second preset timestamp window but not the first preset timestamp window, it means the received timestamp is not within the directly usable timestamp range, but still falls within a reasonable timestamp range. The received timestamp needs to be adjusted to obtain an adjusted timestamp, which is then used to generate the decryption key. Specifically, the second preset timestamp window includes the first preset timestamp window, and its range is larger than that of the first preset timestamp window. The lower limit of the second preset timestamp window is the difference between the expected timestamp and the third adjusted value, and the upper limit is the sum of the expected timestamp and the fourth adjusted value. The third adjusted value is greater than the first adjusted value, and the fourth adjusted value is greater than the second adjusted value.

[0104] As a non-limiting implementation, adjusting the received timestamp to obtain an adjusted timestamp for generating the decryption key includes:

[0105] For each received sequence number or adjustment sequence number, a candidate timestamp is determined based on the received timestamp and the preset deviation time; where the preset deviation time is the difference between the clock of the transmitting end and the clock of the receiving end in the historical period.

[0106] Based on the correspondence between historical timestamps and historical receiver clocks, and the current receiver clock, the candidate timestamps are adjusted to obtain the adjusted timestamps; wherein, the historical timestamps are the timestamps used when historical data blocks were successfully decrypted in historical periods.

[0107] For example, corresponding to each received sequence number or adjustment sequence number, if the received sequence number is parsed or the adjustment sequence number is adjusted, a candidate timestamp is determined based on the received timestamp and a preset time deviation. The preset deviation time is the difference between the clock of the transmitting end and the clock of the receiving end in historical periods. That is, the received timestamp is reasonably adjusted based on the difference between the clock of the transmitting end and the clock of the receiving end to ensure accurate adjustment. In other words, the receiving end first determines the preset deviation time based on the difference between the clock of the transmitting end and the clock of the receiving end in historical periods. For each received sequence number or adjustment sequence number, calculate the adjustment timestamp by comparing the corresponding received timestamp with the preset deviation time. . For receiving timestamps.

[0108] The adjusted timestamp is obtained by adjusting the candidate timestamps based on the correspondence between the historical timestamps (those used for successful decryption of historical data blocks within a historical period) and the historical receiver clock, along with the current receiver clock. This is because network latency may fluctuate. The system records the historical timestamps of the most recently successfully decrypted packets. By fitting a simple linear trend to the correspondence with historical receiver clocks, this trend can be used to adjust the current attempt. Fine-tuning was performed to obtain... .

[0109] As a non-limiting implementation, adjusting the received timestamp to obtain an adjusted timestamp for generating the decryption key includes:

[0110] The timestamp adjustment sub-window is determined based on the serial number adjustment sub-window in which the adjusted serial number is located within the preset attempt serial number window; wherein, the adjustment sub-window includes the window between the lower limit of the preset attempt serial number window and the desired serial number, and the window between the desired serial number and the upper limit of the preset attempt serial number window;

[0111] The received timestamp is adjusted in the timestamp adjustment sub-window to obtain the adjusted timestamp.

[0112] For example, the process of adjusting the received timestamp to obtain the adjusted timestamp can be as follows: A timestamp adjustment sub-window is determined based on the sequence number adjustment sub-window within the preset attempt sequence number window. That is, based on the range of the adjustment sequence number within the preset attempt sequence number window, the range of the adjusted timestamp is further predicted, and the timestamp adjustment sub-window is determined. The received timestamp is then adjusted within the timestamp adjustment sub-window to obtain the adjusted timestamp. Specifically, considering the monotonicity of timestamps, if the sequence number is adjusted... Compared to the current expected serial number If the packet is small (for handling out-of-order packets), then its corresponding timestamp adjustment is... It should also be smaller than the currently valid expected timestamp. The system will apply this constraint to narrow down the range of attempts, determining the timestamp adjustment sub-window to be the window between the lower limit of the preset attempt sequence number window and the desired sequence number. If the sequence number is adjusted... Compared to the current expected serial number For large (out-of-order packets), the corresponding timestamp adjustment is... It should also be larger than the currently valid expected timestamp. The system will apply this constraint to narrow down the range of attempts, determine the timestamp adjustment sub-window as the window between the desired sequence number and the upper limit of the preset attempt sequence number window, and adjust the received timestamp in the timestamp adjustment sub-window to obtain the adjusted timestamp.

[0113] As a non-limiting implementation, the process of determining the third adjustment value and the fourth adjustment value includes:

[0114] If the historical data block is successfully decrypted in a historical period, the difference between the time when the receiving end receives the historical data block and the historical timestamp carried in the historical data packet is used to obtain a delay sample, and the standard deviation of the delay sample is calculated.

[0115] The third adjustment value is determined by multiplying the standard deviation by the first preset parameter; the first preset parameter is an integer greater than 1.

[0116] The fourth adjustment value is determined by multiplying the standard deviation by the second preset parameter; the second preset parameter is less than the first preset parameter.

[0117] For example, when a historical data block is successfully decrypted in a historical period, the difference between the time the receiving end receives the historical data block and the historical timestamp carried in the historical data packet is determined to obtain a delay sample, and the standard deviation of the delay sample is calculated. A third adjustment value is determined based on the product of the standard deviation and a first preset parameter, and a fourth adjustment value is determined based on the product of the standard deviation and a second preset parameter, where the second preset parameter is less than the first preset parameter. Specifically, the difference between the time the receiving end receives the historical data block and the historical timestamp carried in the historical data packet for the most recent N (e.g., N=100) successfully decrypted data packets is recorded to obtain a set of delay samples. Calculate the base volatility: Calculate the standard deviation of this delayed sample set. Standard deviation effectively characterizes the statistical distribution of jitter. A third adjustment value is set: Can be set to (like or This is to cover most of the positive jitter. Fourth adjustment value. Typically small, primarily for handling out-of-order situations, it can be set to a fixed value (e.g.) ) or with Linkage.

[0118] As a non-limiting implementation, the method also includes:

[0119] During the decryption of the next target data block, the third adjustment value and the product of the standard deviation and the first preset parameter are weighted and summed to obtain a new third adjustment value.

[0120] To avoid sudden changes, a smoothing filter can be used for each update: At the same time, to prevent the tolerance window from shrinking excessively (leading to an overly sensitive system and frequent synchronization failures) or expanding excessively (leading to an overly sluggish system and tolerance for abnormal delays), it should be set as follows: , Set minimum and maximum boundary values.

[0121] As a non-limiting implementation, after decrypting the encrypted data block based on the decryption key to obtain the target data block, the method further includes:

[0122] The sequence number used to generate the decryption key will be used as the new expected sequence number.

[0123] The timestamp used to generate the decryption key is smoothed and filtered to obtain the new expected timestamp.

[0124] Use each group Derive the key and decrypt it for verification. If successful, not only update... Also updating: Based on this success Perform smoothing filtering (e.g., using a first-order low-pass filter). Based on this... The difference between the local reception time and the local reception time is dynamically reduced or increased. and To achieve window adaptive behavior. Update clock skew. The estimated value.

[0125] This application provides a specific implementation method, including:

[0126] This scheme reuses and enhances the "protocol-intrinsic fields" (such as packet sequence numbers and timestamps) that the transport protocol itself must maintain to achieve reliable and orderly transmission, using them as factors driving dynamic key changes. Through a cryptographically determined key derivation function (KDF), a shared root key is bound to these constantly changing fields, generating a unique encryption key for each packet or data block, thus achieving "signaling-free key updates." The "protocol-intrinsic fields" relied upon mainly refer to the following two types, which work together to achieve a balance between security and robustness:

[0127] Data packet sequence number: As a basic field, it provides the sequential identifier of data packets and is the basis for ensuring reliable transmission and performing basic state synchronization. The sequence number is monotonically incremented by the sending protocol stack when sending data packets (e.g., uint32 or uint64 type). Its format and increment rule (e.g., +1 each time) are defined by the underlying transport protocol (e.g., uQUIC), which is directly reused in this invention.

[0128] Timestamp: Generated by the sending protocol stack. Its recommended data structure is a 64-bit unsigned integer, representing the number of microseconds elapsed since the start of the current session. Essentially, it is a session-bound, monotonically increasing high-precision counter. As a key enhancement field, its core value lies in:

[0129] Provides global uniqueness and resistance to cross-session replay attacks: The timestamp (typically a monotonically increasing time value from the start of the session) and sequence number form a two-factor binding. This ensures that the key derivation input is globally unique throughout the entire service lifecycle. Even if the sequence number is repeated in a new session, the inherently different timestamps prevent replaying old packets from deriving the correct key, thus naturally protecting against cross-session replay attacks.

[0130] Enhanced robustness of state recovery: In the event of packet loss or out-of-order delivery, the timestamp provides the receiver with a second-dimensional recovery clue. The receiver can combine the sequentiality of the sequence number with the monotonicity and continuity of the timestamp to perform more intelligent state inference and attempts, significantly improving the efficiency and accuracy of synchronization recovery (see step S204).

[0131] Serial number and timestamp synchronization mechanism:

[0132] Basic synchronization: The fields themselves are carried in plaintext form in the header of the data packet. The receiving end obtains their original values ​​by parsing.

[0133] Intelligent Synchronization (Core of this Invention): The receiving end does not passively receive data, but actively synchronizes and recovers data by utilizing the inherent change patterns of the fields. For sequence numbers, the pattern is continuous increment. When the received sequence number is discontinuous, the receiving end attempts to synchronize within the [expected value - N, expected value + M] window. For timestamps, the pattern is monotonically incrementing and strongly correlated with the data packet sending frequency. The receiving end maintains a dynamic time window and, combined with historical latency jitter, verifies and intelligently adjusts the received timestamps (see tolerance calculation below for details).

[0134] Method and Flow

[0135] like Figure 4 and Figure 5 As shown, the complete process from sending to receiving and decryption is described.

[0136] Detailed steps:

[0137] S101 (Sender - Field Preparation): The sender's protocol processing engine assigns a monotonically increasing sequence number to the data block to be sent. And record the current high-precision timestamp. .

[0138] S102 (Sender - Key Derivation): The dynamic key derivation module securely stores... For input key material, and The concatenation of the two bytes is used as the salt. The standard HKDF algorithm is then called (this solution recommends using the industry-standard, cryptographically verified HKDF-SHA-256 algorithm; the specific output length depends on the selected symmetric encryption algorithm. If AES-256-GCM is used, a 32-byte (256-bit) key material needs to be output). The sequence number (Seq) and timestamp (Ts) are used as the salt. To ensure consistency, it is recommended to specify a fixed byte order (e.g., big-endian) and length (e.g., both 64 bits) for concatenation. For example: Salt = Seq (8 bytes) || Ts (8 bytes). This derives the length-matching encryption algorithm requirements. This process is deterministic.

[0139] S103 (Sender - Encrypted Transmission): Encryption module used Encrypt and protect the data payload for integrity (e.g., using AES-256-GCM). Then, combine the ciphertext with the plaintext. , Encapsulate with other necessary protocol headers and send to the network.

[0140] S201 (Receiver - Parsing and Initial Derivation): After receiving a packet, the receiver first parses out the header information... and The receiving end's dynamic key derivation module uses the same local key. and received , Calculated using the exact same algorithm .

[0141] S202 (Receiver - Attempt Decryption and Verification): Decryption module usage Attempt to decrypt and verify the integrity and authenticity of the data (such as GCM's authentication tags).

[0142] S203 (Judgment and Processing): If decryption and authentication are successful, the plaintext data is delivered to the upper-layer application, the protocol processing engine updates its status (such as the expected sequence number), and the process ends.

[0143] S204 (Synchronization Recovery Attempt - Core Advantage): If the initial decryption fails (possibly due to network packet loss or out-of-order delivery causing temporary state desynchronization), the receiving end will not immediately discard the packet. Its key derivation module will initiate a limited and efficient local attempt process:

[0144] Based on protocol rules (such as sequence numbers typically increasing sequentially), at the current expected sequence number A test window is preset nearby. (N and M are small integers, such as 3).

[0145] Within this window, sequentially... With received Combination (or pair) (Make reasonable estimations and adjustments), recalculate the temporary key, and attempt to decrypt.

[0146] This process requires no network signaling interaction and is entirely performed locally at the receiving end. Once in a certain... Successful decryption means that the state has been restored to synchronization, and the receiving end can process data and update normally. .

[0147] Key mechanisms detailed: timestamp generation, synchronization, and anti-jitter strategies

[0148] To ensure that timestamp-based key derivation works reliably in complex wide area network environments, this solution designs a sophisticated timestamp management mechanism, the core of which is to use relative timestamps and allow the receiving end to perform intelligent verification and adjustment.

[0149] 1. Timestamp Generation and Format (Sender): The sender generates a timestamp for each data packet. This is not an absolute calendar time, but a microsecond-level counter that monotonically increases from the start of the session. The recommended definition for the timestamp is `uint64_t` (a 64-bit unsigned integer), representing the microsecond offset from the start of the session. It will wrap around in approximately 580,000 years, and for a single session, it can be considered non-wrap-around.

[0150] Wraparound and session restart handling:

[0151] Intra-session wraparound: In extremely long sessions, if wraparound occurs, the algorithm treats it as a new monotonically increasing cycle starting from 0. The receiver can identify this by detecting a sudden decrease in the value (but combined with a very large sequence number) and maintain the monotonicity judgment by extending the high-order logical count.

[0152] Monotonicity during session restart: To ensure global monotonicity across sessions (enhancing replay resistance), the base value of the timestamp (session start time) should be taken from a system clock that never goes backward (such as CLOCK_MONOTONIC). In this way, even if the application restarts, the timestamp start point of the new session will always be later than all old sessions, thus maintaining the global increasing trend of time.

[0153] Timestamps can be implemented using one of the following two methods to ensure their continuity and resistance to interference:

[0154] Method A (System Clock Reference): .in It is the system clock value recorded when the session is established. The sending end uses a high-precision monotonic clock (such as...) after the session begins. (Measured elapsed time)

[0155] Method B (Independent Counter): Maintain a 64-bit monotonically increasing counter for this session, incrementing by one for each data packet sent or every fixed micro-time unit (e.g., 1 microsecond). .

[0156] Key point: Regardless of the method used, it is essential to ensure that within the same session... The timestamp is monotonically increasing strictly in the order the data packets are sent, and has sufficient precision (microseconds). This timestamp will be encapsulated as part of the plaintext in the packet header.

[0157] 2. Timestamp Verification and Dynamic Adjustment (Receiver)

[0158] After receiving the data packet, the receiving end does not directly use the parsed data. Instead of performing key derivation, a sub-process involving verification and intelligent adjustment is executed. This process occurs concurrently with the decryption attempt, as follows: Figure 2 The deepening manifestation of China's "synchronous recovery attempt":

[0159] S204a (Basic Authentication and Window Decision): The receiver maintains a dynamically acceptable timestamp window. .in It is the current expected value predicted based on the timestamp sequence of successfully decrypted packets. and It is a positive and negative tolerance dynamically calculated based on the historical network latency jitter (the initial value can be set to the estimated network round-trip latency).

[0160] If received If it falls within this window, it is considered "basically reliable" and can be used directly. Proceed to the key derivation and decryption process (S202).

[0161] like Seriously ahead of schedule ( This may indicate a replay attack or severe local state lag, triggering a security alert and causing the packet to be dropped.

[0162] like Lagging behind but not exceeding the lower limit ( If the value is slightly ahead of the limit but not exceeding it, then the adjustment and trial process will begin.

[0163] and Dynamic calculation method:

[0164] Sample collection: Record the (local reception time - packet timestamp) of the most recent N (e.g., N=100) successfully decrypted data packets to obtain a set of delay samples. .

[0165] Calculate the base volatility: Calculate the standard deviation of this delayed sample set. Standard deviation can effectively characterize the statistical distribution of jitter.

[0166] Setting dynamic tolerance: (Future tolerance) can be set to (like or ), to cover most of the positive jitter. (Historical tolerance) is usually small, mainly to deal with out-of-order issues, and can be set to a fixed value (e.g.) ) or with Linkage.

[0167] Smoothing and Boundaries: To avoid abrupt changes, smoothing filtering can be used for each update. At the same time, to prevent the tolerance window from shrinking excessively (leading to an overly sensitive system and frequent synchronization failures) or expanding excessively (leading to an overly sluggish system and tolerance for abnormal delays), it should be set as follows: , Set minimum and maximum boundary values.

[0168] S204b (Adjustment Attempt Procedure): This procedure is synchronized with the sequence number Seq attempt, but introduces a time dimension. The receiver will construct a... A two-dimensional space for experimentation.

[0169] Fixed bias compensation: The receiver first calculates the estimated fixed bias between the transmitter and the local clock based on historical packets. For each attempt First calculate .

[0170] Dynamic trend compensation: Network latency may fluctuate. The system records the actual value of the most recently successfully decrypted packet. The relationship between the current local time and the given time is fitted with a simple linear trend. For the current attempt, this trend can be used to... Fine-tuning was performed to obtain... .

[0171] Heuristic backtracking: Considering the monotonicity of timestamps, if Compared to the current Small (handling out-of-order packets), then its corresponding It should also be smaller than the currently valid one. The system will apply this constraint to narrow down the range of attempts.

[0172] S204c (Joint Decryption and State Update): Use each group Derive the key and decrypt it for verification. If successful, not only update... Also updating:

[0173] Based on this success Perform smoothing filtering (e.g., using a first-order low-pass filter).

[0174] According to this The difference between the local reception time and the local reception time is dynamically reduced or increased. and This enables the window to adapt automatically.

[0175] Optionally, update clock skew. The estimated value.

[0176] 3. Jitter and clock drift handling

[0177] The above dynamic window , Its adaptive mechanism allows the system to tolerate common network latency jitter.

[0178] For long-term, slow clock drift, through continuous updates The estimated value is automatically compensated during the decryption process, which will not cause the key to lose synchronization.

[0179] During the session, the data can be periodically (e.g., after every 1000 successfully decrypted packets)... The estimated value is lightweightly carried back to the sender via idle signaling or ACK messages (not specifically designed for key synchronization) within the protocol. The sender then fine-tunes its subsequent operations based on this. The generated reference enables long-term soft clock synchronization, and this operation does not affect the main data stream.

[0180] Figure 6 This is a schematic diagram of a data processing device configured at a transmitting end, provided as an embodiment of this application. This device can execute the data processing method applied to the transmitting end provided in any embodiment of this application, and possesses corresponding functional modules and beneficial effects for executing the method. For example... Figure 6 As shown, the device includes:

[0181] The information determination module 410 can be used to assign target sequence numbers to target data blocks and record the current timestamp as the target timestamp; wherein, the target sequence numbers corresponding to the target data blocks from front to back in time are monotonically increasing;

[0182] The target key generation module 420 is used to generate a target key based on a preset key derivation function, according to the target sequence number, the target timestamp, and the root key; wherein, the root key is generated by the sending end and the receiving end through a key exchange protocol when they establish a session, and the root key is shared by the sending end and the receiving end and used during the session;

[0183] The encrypted data block generation module 430 is used to encrypt the target data block based on the target key to obtain an encrypted data block, so as to construct a target data packet based on the encrypted data block, the target sequence number and the target timestamp and send it to the receiving end.

[0184] In this embodiment of the application, the information determination module 410 records the current timestamp as the target timestamp, including:

[0185] Determine the start time of the session established between the sending end and the receiving end;

[0186] Generate a counter that monotonically increases from the start time, and use the counter as the target timestamp.

[0187] In this embodiment of the application, the information determination module 410 generates a counter that monotonically increases from the start time, including:

[0188] The elapsed time since the start time is detected by a monotonic clock;

[0189] The sum of the start time and the elapsed time is used as the value of the counter.

[0190] In this embodiment of the application, the information determination module 410 generates a counter that monotonically increases from the start time, including:

[0191] A counter is generated that monotonically increases from the start time, and increments by one for each target data block sent or at a preset time interval.

[0192] In this embodiment, the encrypted data block generation module 430 generates a target key based on a preset key derivation function, according to the target sequence number, the target timestamp, and the root key, including:

[0193] The target sequence number is concatenated with the target timestamp to obtain salt data;

[0194] The root key and the salt data are input into a preset key derivation function to generate the target key.

[0195] The data processing device configured on the sending end provided in the embodiments of this application can execute a data processing method applied to the sending end provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects of executing the method.

[0196] Figure 7 This is a schematic diagram of a data processing device configured at a receiving end, provided as an embodiment of this application. This device can execute the data processing method applied to the receiving end provided in any embodiment of this application, and possesses corresponding functional modules and beneficial effects for executing the method. For example... Figure 7 As shown, the device includes:

[0197] The parsing module 510 is used to receive the target data packet sent by the sending end, and parse the target data packet to obtain an encrypted data block, a receiving sequence number, and a receiving timestamp; wherein the target data packet is obtained by the data processing method according to any one of claims 1-5;

[0198] The decryption key generation module 520 is used to generate a decryption key based on a preset key derivation function, according to the received sequence number, the received timestamp, and the root key.

[0199] The decryption module 530 is used to decrypt the encrypted data block based on the decryption key to obtain the target data block.

[0200] In this embodiment, the decryption key generation module 520 generates a decryption key based on a preset key derivation function, according to the received sequence number, the received timestamp, and the root key, including:

[0201] If the encryption of the data block fails to be decrypted based on the received sequence number, the received timestamp, and the key generated from the root key, then the received sequence number is adjusted to obtain an adjusted sequence number, and / or the received timestamp is adjusted to obtain an adjusted timestamp.

[0202] The adjustment of the received sequence number and / or received timestamp shall cease until at least one of the following is met, and the generated key shall be used as the decryption key:

[0203] The encrypted data block was successfully decrypted based on the adjusted sequence number, the received timestamp, and the key generated from the root key;

[0204] The encrypted data block was successfully decrypted based on the received sequence number, the adjusted timestamp, and the key generated from the root key;

[0205] The encrypted data block was successfully decrypted using the adjusted sequence number, the adjusted timestamp, and the key generated from the root key.

[0206] In this embodiment of the application, the decryption key generation module 520 adjusts the received sequence number to obtain an adjusted sequence number, including:

[0207] The received sequence number is adjusted within the range defined by a preset attempt sequence number window to obtain the adjusted sequence number; wherein, the lower limit of the preset attempt sequence number window is the difference between the expected sequence number and the first adjustment amount, and the upper limit of the preset attempt sequence number window is the sum of the expected sequence number and the second adjustment amount; the expected sequence number is a sequence number predicted based on the decryption sequence number or the adjusted sequence number used in the process of generating the decryption key for successfully decrypting the previous encrypted data block.

[0208] In this embodiment of the application, before the received timestamp is used to generate the decryption key, the device further includes a timestamp adjustment module, used for:

[0209] If the received timestamp falls within the first preset timestamp window, the received timestamp is used to generate a decryption key; wherein, the lower limit of the first preset timestamp window is the difference between the expected timestamp and the first adjustment value, and the upper limit of the first preset timestamp window is the sum of the expected timestamp and the second adjustment value;

[0210] If the received timestamp falls within the second preset timestamp window but not within the first preset timestamp window, the received timestamp is adjusted to obtain an adjusted timestamp for generating a decryption key; wherein, the second preset timestamp window includes the first preset timestamp window; the lower limit of the second preset timestamp window is the difference between the expected timestamp and the third adjustment value, and the upper limit of the second preset timestamp window is the sum of the expected timestamp and the fourth adjustment value.

[0211] In this embodiment of the application, the timestamp adjustment module adjusts the received timestamp to obtain an adjusted timestamp for generating a decryption key, including:

[0212] For each received sequence number or adjustment sequence number, a candidate timestamp is determined based on the received timestamp and the preset deviation time; where the preset deviation time is the difference between the clock of the transmitting end and the clock of the receiving end in the historical period.

[0213] Based on the correspondence between historical timestamps and historical receiver clocks, and the current receiver clock, the candidate timestamps are adjusted to obtain the adjusted timestamps; wherein, the historical timestamps are the timestamps used when historical data blocks were successfully decrypted in historical periods.

[0214] In this embodiment of the application, the timestamp adjustment module adjusts the received timestamp to obtain an adjusted timestamp for generating a decryption key, including:

[0215] The timestamp adjustment sub-window is determined based on the serial number adjustment sub-window in which the adjusted serial number is located within the preset attempt serial number window; wherein, the adjustment sub-window includes the window between the lower limit of the preset attempt serial number window and the desired serial number, and the window between the desired serial number and the upper limit of the preset attempt serial number window;

[0216] The received timestamp is adjusted in the timestamp adjustment sub-window to obtain the adjusted timestamp.

[0217] In this embodiment of the application, the process by which the timestamp adjustment module determines the third adjustment value and the fourth adjustment value includes:

[0218] If the historical data block is successfully decrypted in a historical period, the difference between the time when the receiving end receives the historical data block and the historical timestamp carried in the historical data packet is used to obtain a delay sample, and the standard deviation of the delay sample is calculated.

[0219] The third adjustment value is determined by multiplying the standard deviation by the first preset parameter; the first preset parameter is an integer greater than 1.

[0220] The fourth adjustment value is determined by multiplying the standard deviation by the second preset parameter; the second preset parameter is less than the first preset parameter.

[0221] In this embodiment of the application, the device further includes an adjustment value determination module, used for:

[0222] During the decryption of the next target data block, the third adjustment value and the product of the standard deviation and the first preset parameter are weighted and summed to obtain a new third adjustment value.

[0223] In this embodiment of the application, after decrypting the encrypted data block based on the decryption key to obtain the target data block, the device further includes an update module, used for:

[0224] The sequence number used to generate the decryption key will be used as the new expected sequence number.

[0225] The timestamp used to generate the decryption key is smoothed and filtered to obtain the new expected timestamp.

[0226] The data processing device configured at the receiving end provided in the embodiments of this application can execute a data processing method applied at the receiving end provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects of executing the method.

[0227] Figure 8A schematic diagram of the structure of an electronic device 10 that can be used to implement embodiments of this application is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workbenches, personal digital processors, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of this application as described herein and / or the first preset requirements.

[0228] like Figure 8 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0229] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0230] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as data processing methods.

[0231] In some embodiments, the data processing method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or mounted on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the data processing method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the data processing method by any other suitable means (e.g., by means of firmware).

[0232] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0233] Computer programs used to implement the methods of this application may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0234] In the context of this application, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0235] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0236] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0237] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0238] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the data processing method provided in any embodiment of this application.

[0239] In implementing the computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0240] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired information of the technical solution of this application can be achieved, and this is not limited herein.

[0241] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made based on the first design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A data processing method, characterized by, Applied to the sending end, the method includes: Assign a target sequence number to the target data block and record the current timestamp as the target timestamp; wherein, the target sequence number corresponding to the target data block from the beginning to the end of time is monotonically increasing; Based on a preset key derivation function, a target key is generated according to the target sequence number, the target timestamp, and the root key; wherein, the root key is generated by the sender and receiver through a key exchange protocol when establishing a session, and the root key is shared by the sender and receiver and used during the session; The target data block is encrypted using the target key to obtain an encrypted data block, and a target data packet is constructed based on the encrypted data block, the target sequence number, and the target timestamp and sent to the receiving end.

2. The method according to claim 1, characterized in that, Record the current timestamp as the target timestamp, including: Determine the start time of the session established between the sending end and the receiving end; Generate a counter that monotonically increases from the start time, and use the counter as the target timestamp.

3. The method according to claim 2, characterized in that, Generating a counter that monotonically increases from the said start time includes: The elapsed time since the start time is detected by a monotonic clock; The sum of the start time and the elapsed time is used as the value of the counter.

4. The method according to claim 2, characterized in that, Generating a counter that monotonically increases from the said start time includes: A counter is generated that monotonically increases from the start time, and increments by one for each target data block sent or at a preset time interval.

5. The method according to claim 1, characterized in that, Based on a preset key derivation function, a target key is generated according to the target sequence number, the target timestamp, and the root key, including: The target sequence number is concatenated with the target timestamp to obtain salt data; The root key and the salt data are input into a preset key derivation function to generate the target key.

6. A data processing method, characterized in that, Applied to the receiving end, the method includes: The system receives a target data packet sent by a sending end and parses the target data packet to obtain an encrypted data block, a receiving sequence number, and a receiving timestamp; wherein the target data packet is obtained by the data processing method applied to the sending end as described in any one of claims 1-5. Based on the preset key derivation function, a decryption key is generated according to the received sequence number, the received timestamp, and the root key; The target data block is obtained by decrypting the encrypted data block using the decryption key.

7. The method according to claim 6, characterized in that, Based on a preset key derivation function, a decryption key is generated according to the received sequence number, the received timestamp, and the root key, including: If the encryption of the data block fails to be decrypted based on the received sequence number, the received timestamp, and the key generated from the root key, then the received sequence number is adjusted to obtain an adjusted sequence number, and / or the received timestamp is adjusted to obtain an adjusted timestamp. The adjustment of the received sequence number and / or received timestamp shall cease until at least one of the following is met, and the generated key shall be used as the decryption key: The encrypted data block was successfully decrypted based on the adjusted sequence number, the received timestamp, and the key generated from the root key. The encrypted data block was successfully decrypted based on the received sequence number, the adjusted timestamp, and the key generated from the root key; The encrypted data block was successfully decrypted using the adjusted sequence number, the adjusted timestamp, and the key generated from the root key.

8. The method according to claim 7, characterized in that, Adjusting the received sequence number to obtain an adjusted sequence number includes: The received sequence number is adjusted within the range defined by a preset attempt sequence number window to obtain the adjusted sequence number; wherein, the lower limit of the preset attempt sequence number window is the difference between the expected sequence number and the first adjustment amount, and the upper limit of the preset attempt sequence number window is the sum of the expected sequence number and the second adjustment amount; the expected sequence number is a sequence number predicted based on the decryption sequence number or the adjusted sequence number used in the process of generating the decryption key for successfully decrypting the previous encrypted data block.

9. The method according to claim 6, characterized in that, Before the received timestamp is used to generate the decryption key, it also includes: If the received timestamp falls within the first preset timestamp window, the received timestamp is used to generate a decryption key; wherein, the lower limit of the first preset timestamp window is the difference between the expected timestamp and the first adjustment value, and the upper limit of the first preset timestamp window is the sum of the expected timestamp and the second adjustment value; If the received timestamp falls within the second preset timestamp window but not within the first preset timestamp window, the received timestamp is adjusted to obtain an adjusted timestamp for generating a decryption key; wherein, the second preset timestamp window includes the first preset timestamp window; the lower limit of the second preset timestamp window is the difference between the expected timestamp and the third adjustment value, and the upper limit of the second preset timestamp window is the sum of the expected timestamp and the fourth adjustment value.

10. The method according to claim 9, characterized in that, Adjusting the received timestamp to obtain an adjusted timestamp is used to generate the decryption key, including: For each received sequence number or adjustment sequence number, a candidate timestamp is determined based on the received timestamp and the preset deviation time; where the preset deviation time is the difference between the clock of the transmitting end and the clock of the receiving end in the historical period. Based on the correspondence between historical timestamps and historical receiver clocks, and the current receiver clock, the candidate timestamps are adjusted to obtain the adjusted timestamps; wherein, the historical timestamps are the timestamps used when historical data blocks were successfully decrypted in historical periods.

11. The method according to claim 9 or 10, characterized in that, Adjusting the received timestamp to obtain an adjusted timestamp is used to generate the decryption key, including: The timestamp adjustment sub-window is determined based on the serial number adjustment sub-window in which the adjusted serial number is located within the preset attempt serial number window; wherein, the adjustment sub-window includes the window between the lower limit of the preset attempt serial number window and the desired serial number, and the window between the desired serial number and the upper limit of the preset attempt serial number window; The received timestamp is adjusted in the timestamp adjustment sub-window to obtain the adjusted timestamp.

12. The method according to claim 9, characterized in that, The process for determining the third adjustment value and the fourth adjustment value includes: If the historical data block is successfully decrypted in a historical period, the difference between the time when the receiving end receives the historical data block and the historical timestamp carried in the historical data packet is used to obtain a delay sample, and the standard deviation of the delay sample is calculated. The third adjustment value is determined by multiplying the standard deviation by the first preset parameter; the first preset parameter is an integer greater than 1. The fourth adjustment value is determined by multiplying the standard deviation by the second preset parameter; the second preset parameter is less than the first preset parameter.

13. The method according to claim 9, characterized in that, The method further includes: During the decryption of the next target data block, the third adjustment value and the product of the standard deviation and the first preset parameter are weighted and summed to obtain a new third adjustment value.

14. The method according to claim 6, characterized in that, After decrypting the encrypted data block using the decryption key to obtain the target data block, the method further includes: The sequence number used to generate the decryption key will be used as the new expected sequence number. The timestamp used to generate the decryption key is smoothed and filtered to obtain the new expected timestamp.

15. A data processing apparatus, characterized in that, Configured at the transmitting end, the data processing device includes: The information determination module can be used to assign target sequence numbers to target data blocks and record the current timestamp as the target timestamp; wherein, the target sequence numbers corresponding to the target data blocks from front to back in time are monotonically increasing; The target key generation module is used to generate a target key based on a preset key derivation function, according to the target sequence number, the target timestamp, and the root key; wherein, the root key is generated by the sending end and the receiving end through a key exchange protocol when they establish a session, and the root key is shared by the sending end and the receiving end and used during the session; An encrypted data block generation module is used to encrypt the target data block based on the target key to obtain an encrypted data block, and to construct a target data packet based on the encrypted data block, the target sequence number and the target timestamp and send it to the receiving end.

16. A data processing apparatus, characterized in that, Configured at the receiving end, the data processing device includes: The parsing module is used to receive the target data packet sent by the sending end, and parse the target data packet to obtain an encrypted data block, a receiving sequence number, and a receiving timestamp; wherein, the target data packet is obtained by the data processing method applied to the sending end as described in any one of claims 1-5; The decryption key generation module is used to generate a decryption key based on a preset key derivation function, according to the received sequence number, the received timestamp, and the root key. The decryption module is used to decrypt the encrypted data block based on the decryption key to obtain the target data block.

17. An electronic device, characterized in that, The electronic device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the data processing method applied to the transmitting end as described in any one of claims 1-5, or the data processing method applied to the receiving end as described in any one of claims 6-14.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the data processing method applied to the transmitting end as described in any one of claims 1-5, or the data processing method applied to the receiving end as described in any one of claims 6-14.

Images