Token anti-replay verification method and system based on dynamic salt value and bitmap sliding window

Abstract

This invention relates to the field of token verification technology and discloses a token anti-replay verification method and system based on dynamic salt value and Bitmap sliding window. By introducing a collaborative mechanism of dynamic salt value, sliding window and request sequence number status tracking, as well as bidirectional state synchronization logic between the client module and cloud service, multi-dimensional dynamic anti-replay verification of API tokens is achieved. Thus, without relying on high-precision time synchronization or complex centralized storage, the dual protection corresponding to the range limitation of dynamic credentials and sliding window and the idempotency verification of request sequence number status effectively resists attacks such as interception of replay and repeated submission within the window, thereby improving the security of token requests.

Description

Technical Field

[0001] This invention relates to the field of token verification technology, and in particular to a token anti-replay verification method and system based on dynamic salt value and Bitmap sliding window. Background Technology

[0002] Currently, the industry's technical solutions for preventing token replay attacks mainly revolve around two major dimensions: "uniqueness verification" and "timeliness control".

[0003] Among common mainstream implementations, the timestamp combined with random numbers rejects duplicate requests by recording used random numbers in the cloud service cache. While simple to implement, this approach is prone to misjudgments due to clock skew and puts significant pressure on the cache in high-concurrency scenarios. The monotonically increasing sequence number scheme achieves accurate replay prevention, but the initial sequence numbers are often fixed values, making them easy to guess, and there are inconsistencies in sequence number synchronization in distributed deployments. The sliding window scheme records request states by maintaining a fixed interval, balancing timeliness and uniqueness; however, traditional implementations use array storage, which significantly increases memory usage when the window is large. The one-time token scheme achieves absolute replay prevention by pre-generating single-use valid tokens, but it requires maintaining a token pool and additional interaction from the client module, reducing the efficiency of token interaction and processing.

[0004] Comprehensive analysis reveals that existing technical solutions generally suffer from the following shortcomings: First, they consume a large amount of memory, and the overhead of using array storage for sliding windows is significant when the window is large; second, their concurrency performance is limited, and caching or additional interactions can easily become bottlenecks; third, they have weak anti-guessing capabilities, and the fixed starting value of the incrementing sequence number poses a security risk; and fourth, they rely on time synchronization, and clock skew may cause verification failures. Summary of the Invention

[0005] This invention provides a token anti-replay verification method and system based on dynamic salt value and Bitmap sliding window. It achieves efficient and secure token deduplication by combining random initial request sequence number, dynamic salt value encryption for each request, fixed-size Bitmap sliding window modulo operation verification, and symmetric and asymmetric hybrid encryption.

[0006] The first aspect of this invention discloses a token anti-replay verification method based on dynamic salt value and Bitmap sliding window. The method is applied to a terminal device with an application installed. The terminal device is communicatively connected to a network-attached storage device and a cloud service. The terminal device accesses the network-attached storage device and the cloud service through the application. The method includes: When a Token acquisition request initiated by the client module of the application is detected, the cloud service decrypts the Token acquisition request to obtain key data, and performs a first encryption operation on the key data according to the pre-generated encryption parameters to obtain the first encrypted data for the key data; the encryption parameters include a dynamic salt value, a Token identifier, a sliding window, a request sequence number for the Token acquisition request and its corresponding sequence number usage status, and the request sequence number falls within the sliding window; The client module decrypts the first encrypted data to obtain decrypted data, and then performs an auto-increment operation on the request sequence number, a dynamic salt value generation operation, and a second encryption operation on the decrypted data to obtain second encrypted data for the decrypted data; the second encrypted data includes the business request and the basic encrypted data corresponding to the decrypted data; The cloud service performs data decryption, identity and status query, first verification operation for the sliding window, and second verification operation for the serial number usage status on the received second encrypted data to obtain the anti-replay verification result for the second encrypted data. After determining that the anti-replay verification result indicates that the verification is successful, it responds to the business item corresponding to the business request.

[0007] As an optional implementation, in the first aspect of the present invention, the step of obtaining key data by decrypting the Token acquisition request through a cloud service, and performing a first encryption operation on the key data according to pre-generated encryption parameters to obtain first encrypted data for the key data includes: The cloud service decrypts the Token acquisition request using the cloud service private key to obtain key data, and the key data includes at least the AES key corresponding to the Token acquisition request. The cloud service performs an initialization operation on the preset encryption parameters to obtain a first salt value, a unique token identifier for the client module, a first request sequence number for the token acquisition request, an initial sliding window for the first request sequence number, and an initial sequence number usage status, which serve as the initialization result for the encryption parameters; the initial sequence number usage status is recorded through a pre-generated Bitmap array; The cloud service performs a first concatenation operation on the key data based on the initialization result to obtain the first encrypted data for the key data.

[0008] As an optional implementation, in the first aspect of the present invention, the step of the cloud service performing a first concatenation operation on the key data according to the initialization result to obtain first encrypted data for the key data includes: The cloud service performs a first concatenation operation on the first salt value, the unique token identifier, the first request sequence number, and the AES key to obtain the first encrypted data for the key data. Furthermore, after the cloud service performs a first concatenation operation on the first salt value, the unique token identifier, the first request sequence number, and the AES key to obtain the first encrypted data for the key data, the method further includes: The cloud service stores the first encrypted data, the unique token identifier, the first request sequence number, the initial sliding window, and the Bitmap array in the memory of the cloud service; wherein, the initial sliding window includes the upper limit and lower limit of the window corresponding to the initial sliding window.

[0009] As an optional implementation, in the first aspect of the present invention, the decrypted data includes at least the first salt value, the unique token identifier, and the first request sequence number; The process involves performing an increment operation on the request sequence number, a dynamic salt value generation operation, and a second encryption operation on the decrypted data to obtain second encrypted data for the decrypted data, including: The client module increments the first request sequence number to obtain a second request sequence number and randomly generates a second salt value for the first salt value; the first salt value and the second salt value have the same number of bytes. The client module performs a second concatenation operation on the unique token identifier based on the preset client module public key, the second request sequence number, and the second salt value to obtain basic encrypted data; The client module generates a business request and adds the basic encrypted data to the business request to obtain second encrypted data for the decrypted data; the second encrypted data is sent to the cloud service; and the client module stores the basic encrypted data, the unique token identifier, and the second request sequence number in the memory of the client module.

[0010] As an optional implementation, in the first aspect of the present invention, the step of the cloud service performing data decryption, identity and status query, first verification operation for the sliding window, and second verification operation for the serial number usage status on the received second encrypted data to obtain an anti-replay verification result for the second encrypted data includes: The cloud service performs a data decryption operation on the second encrypted data based on the cloud service private key to obtain a decryption result for the second encrypted data; the decryption result includes at least the second salt value, the unique token identifier, and the second request sequence number. The cloud service performs an identity query operation on the unique token to obtain the identity query result; When the identity query result indicates that a record for the unique token exists in the database, the cloud service performs a status query operation on the unique token to obtain the initial sliding window and the Bitmap array corresponding to the unique token. The cloud service performs a first verification operation on the initial sliding window to obtain a first verification result, and performs a second verification operation on the Bitmap array to obtain a second verification result; The cloud service determines the first verification result and the second verification result as the anti-replay verification result for the second encrypted data.

[0011] As an optional implementation, in a first aspect of the present invention, the step of obtaining a first verification result by the cloud service performing a first verification operation on the initial sliding window includes: The cloud service determines whether the second request sequence number is less than or equal to the lower limit of the initial sliding window. When it is determined that the second request sequence number is less than or equal to the lower limit of the initial sliding window, an expiration identifier is generated to indicate that the service request is an expired request, and the service request is rejected based on the expiration identifier. When it is determined that the second request sequence number is greater than the lower limit of the initial sliding window, the cloud service determines whether the second request sequence number is greater than the upper limit of the initial sliding window. When it is determined that the second request sequence number is greater than the upper limit of the initial sliding window, the difference between the second request sequence number and the window size of the initial sliding window is calculated, and the difference is incremented by 1 to obtain the calculation result. The calculation result is determined as the new lower limit of the initial sliding window, and the second request sequence number is determined as the new upper limit of the initial sliding window. The cloud service determines the expired identifier or the updated initial sliding window as the first verification result for the initial sliding window.

[0012] As an optional implementation, in the first aspect of the present invention, the step of obtaining a second verification result by the cloud service performing a second verification operation on the Bitmap array includes: The cloud service calculates the modulo value between the second request sequence number and the window size; The cloud service performs a query operation on the Bitmap array based on the modulus value to obtain a query result for the Bitmap array. The query result is used to indicate the usage status of the second request sequence number recorded in the Bitmap array. When the sequence number is in the first preset state, the cloud service determines that the business request is a duplicate request, generates a duplicate request identifier, and refuses to respond to the business request as a second verification result. When the serial number usage status is the second preset status, the cloud service generates a compliance identifier for the business request and updates the serial number usage status to the first preset status as the second verification result.

[0013] A second aspect of this invention discloses a token anti-replay verification system based on dynamic salt value and Bitmap sliding window. The system is applied to a terminal device with an application installed. The terminal device is communicatively connected to a network-attached storage device and a cloud service. The terminal device accesses the network-attached storage device and the cloud service through the application. The cloud service includes: The first decryption module is used to decrypt the Token acquisition request to obtain key data when a Token acquisition request initiated by the client module of the application is detected. The first encryption module is used to perform a first encryption operation on the key data according to the pre-generated encryption parameters to obtain the first encrypted data for the key data; the encryption parameters include a dynamic salt value, a token identifier, a sliding window, a request sequence number for the token acquisition request and its corresponding sequence number usage status, and the request sequence number falls within the sliding window; The client module includes: The second decryption module is used to decrypt the obtained first encrypted data to obtain decrypted data; The second encryption module is used to perform an auto-increment operation on the request sequence number, a dynamic salt value generation operation, and a second encryption operation on the decrypted data to obtain second encrypted data for the decrypted data; the second encrypted data includes the business request and the basic encrypted data corresponding to the decrypted data; The cloud services also include: The anti-replay verification module is used to perform data decryption operation, identity and status query operation, first verification operation for the sliding window, and second verification operation for the serial number usage status on the received second encrypted data, so as to obtain the anti-replay verification result for the second encrypted data, and after determining that the anti-replay verification result indicates that the verification is successful, responding to the business item corresponding to the business request.

[0014] As an optional implementation, in a second aspect of the present invention, the method by which the first decryption module decrypts the Token acquisition request to obtain key data specifically includes: The key data is obtained by decrypting the Token acquisition request using the cloud service private key, and the key data includes at least the AES key corresponding to the Token acquisition request; The first encryption module performs a first encryption operation on the key data according to the pre-generated encryption parameters to obtain the first encrypted data for the key data. Specifically, this includes: An initialization operation is performed on the preset encryption parameters to obtain a first salt value, a unique token identifier for the client module, a first request sequence number for the token acquisition request, an initial sliding window for the first request sequence number, and an initial sequence number usage status, which serve as the initialization result for the encryption parameters; the initial sequence number usage status is recorded through a pre-generated Bitmap array; Based on the initialization result, a first concatenation operation is performed on the key data to obtain the first encrypted data for the key data.

[0015] As an optional implementation, in a second aspect of the present invention, the method by which the first encryption module performs a first concatenation operation on the key data according to the initialization result to obtain the first encrypted data for the key data specifically includes: Perform a first concatenation operation on the first salt value, the unique token identifier, the first request sequence number and the AES key to obtain the first encrypted data for the key data; In addition, the cloud service also includes: The storage module is configured to store the first encrypted data, the unique token identifier, the first request sequence number, and the Bitmap array into the memory of the cloud service after the first encryption module performs a first concatenation operation on the first salt value, the unique token identifier, the first request sequence number, and the AES key to obtain the first encrypted data for the key data; wherein the initial sliding window includes the upper limit and lower limit of the window corresponding to the initial sliding window.

[0016] As an optional implementation, in a second aspect of the present invention, the decrypted data includes at least the first salt value, the unique token identifier, and the first request sequence number; The second encryption module performs an increment operation on the request sequence number, a dynamic salt value generation operation, and a second encryption operation on the decrypted data, respectively, to obtain the second encrypted data for the decrypted data. Specifically, this includes: An increment operation is performed on the first request sequence number to obtain a second request sequence number, and a second salt value is randomly generated for the first salt value; the first salt value and the second salt value have the same number of bytes; Based on the preset client module public key, the second request sequence number, and the second salt value, a second concatenation operation is performed on the unique token identifier to obtain basic encrypted data; A business request is generated, and the basic encrypted data is added to the business request to obtain second encrypted data for the decrypted data; the second encrypted data is sent to the cloud service; and the basic encrypted data, the unique token identifier, and the second request sequence number are stored in the memory of the client module.

[0017] As an optional implementation, in the second aspect of the present invention, the method by which the anti-replay verification module performs data decryption operation, identity and status query operation, first verification operation for the sliding window, and second verification operation for the serial number usage status on the received second encrypted data to obtain the anti-replay verification result for the second encrypted data specifically includes: The second encrypted data is decrypted using the cloud service private key to obtain a decryption result for the second encrypted data; the decryption result includes at least the second salt value, the unique token identifier, and the second request sequence number. Perform an identity query operation on the unique token to obtain the identity query result; When the identity query result indicates that there is a record for the unique token in the database, a status query operation is performed on the unique token to obtain the initial sliding window and the Bitmap array corresponding to the unique token; A first verification operation is performed on the initial sliding window to obtain a first verification result, and a second verification operation is performed on the Bitmap array to obtain a second verification result; The first verification result and the second verification result are determined as the anti-replay verification results for the second encrypted data.

[0018] As an optional implementation, in a second aspect of the present invention, the method by which the anti-replay verification module performs a first verification operation on the initial sliding window to obtain a first verification result specifically includes: Determine whether the second request sequence number is less than or equal to the lower limit of the initial sliding window. When it is determined that the second request sequence number is less than or equal to the lower limit of the initial sliding window, generate an expiration identifier to indicate that the service request is an expired request, and refuse to respond to the service request based on the expiration identifier. When it is determined that the second request number is greater than the lower limit of the initial sliding window, it is determined whether the second request number is greater than the upper limit of the initial sliding window. When it is determined that the second request number is greater than the upper limit of the initial sliding window, the difference between the second request number and the window size of the initial sliding window is calculated, and the difference is incremented by 1 to obtain the calculation result. The calculation result is determined as the new lower limit of the initial sliding window, and the second request number is determined as the new upper limit of the initial sliding window. The expired identifier or the updated initial sliding window is determined as the first verification result for the initial sliding window.

[0019] As an optional implementation, in the second aspect of the present invention, the method by which the anti-replay verification module performs a second verification operation on the Bitmap array to obtain a second verification result specifically includes: Calculate the modulus between the second request number and the window size; A query operation is performed on the Bitmap array based on the modulus value to obtain a query result for the Bitmap array. The query result is used to indicate the usage status of the second request sequence number recorded in the Bitmap array. When the sequence number is in the first preset state, the service request is determined to be a duplicate request, and a duplicate request identifier is generated and the service request is rejected as a second verification result. When the sequence number usage status is the second preset status, a compliance identifier for the service request is generated, and the sequence number usage status is updated to the first preset status as the second verification result.

[0020] A third aspect of the present invention discloses a terminal device, the terminal device comprising: Memory containing executable program code; A processor coupled to the memory; The processor calls the executable program code stored in the memory to execute some or all of the steps in the Token Anti-Replay Verification Method based on Dynamic Salt Value and Bitmap Sliding Window as described in any of the first aspects of the present invention.

[0021] The fourth aspect of the present invention discloses a token anti-replay verification system based on dynamic salt value and Bitmap sliding window, which includes a terminal device as described in the third aspect of the present invention, and a network attached storage device communicatively connected to the terminal device. The terminal device is used to perform some or all of the steps in the Token anti-replay verification method based on dynamic salt value and Bitmap sliding window as described in any of the first aspects of this invention. The terminal device is also used to access the data stored in the network-attached storage device after confirming that the preset anti-replay verification process has been passed.

[0022] Compared with the prior art, the present invention has the following beneficial effects: This invention provides a token anti-replay verification method based on dynamic salt value and Bitmap sliding window. By introducing a collaborative mechanism of dynamic salt value, sliding window and request sequence number status tracking, and bidirectional state synchronization logic between the client module and cloud service, this invention achieves multi-dimensional dynamic anti-replay verification of API tokens. Therefore, without relying on high-precision time synchronization or complex centralized storage, the dual protection provided by the range limitation of dynamic credentials and sliding window, and the idempotency verification of request sequence number status effectively resists attacks such as intercepted replay and duplicate submissions within the window, thus improving the security of token requests. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of the present invention, 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a flowchart illustrating a token anti-replay verification method based on dynamic salt value and Bitmap sliding window disclosed in an embodiment of the present invention. Figure 2 This is a flowchart illustrating another token anti-replay verification method based on dynamic salt value and Bitmap sliding window disclosed in an embodiment of the present invention. Figure 3 This is a schematic diagram of the structure of a token anti-replay verification system based on dynamic salt value and Bitmap sliding window disclosed in an embodiment of the present invention; Figure 4 This is a schematic diagram of another token anti-replay verification system based on dynamic salt value and Bitmap sliding window disclosed in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a terminal device disclosed in an embodiment of the present invention; Figure 6This is a schematic diagram of the structure of another token anti-replay verification system based on dynamic salt value and Bitmap sliding window disclosed in an embodiment of the present invention. Detailed Implementation

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

[0026] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or end that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or ends.

[0027] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0028] This invention discloses a token anti-replay verification method and system based on dynamic salt value and Bitmap sliding window. By introducing a collaborative mechanism of dynamic salt value, sliding window, and request sequence number status tracking, as well as bidirectional state synchronization logic between the client module and the cloud service, multi-dimensional dynamic anti-replay verification of API tokens is achieved. Therefore, without relying on high-precision time synchronization or complex centralized storage, the dual protection provided by the range limitation of dynamic credentials and sliding window, and the idempotency verification of request sequence number status, effectively resists attacks such as intercepted replay and duplicate submissions within the window, thus improving the security of token requests. Detailed explanations follow.

[0029] Example 1 Please see Figure 1 , Figure 1This is a flowchart illustrating a token anti-replay verification method based on dynamic salt value and Bitmap sliding window disclosed in an embodiment of the present invention. Figure 1 The described token anti-replay verification method based on dynamic salt value and Bitmap sliding window can be applied to terminal devices with an application installed. The terminal device is communicatively connected to a network-attached storage device (NAT). The terminal device communicates with a cloud service via a network, and the application accesses both the NAT and the cloud service. This embodiment of the invention is not limited to this method. Figure 1 As shown, the token anti-replay verification method based on dynamic salt value and Bitmap sliding window can include the following operations: 101. When a Token acquisition request initiated by the application's client module is detected, the cloud service decrypts the Token acquisition request to obtain key data, and performs a first encryption operation on the key data according to the pre-generated encryption parameters to obtain the first encrypted data for the key data.

[0030] In this embodiment of the invention, the encryption parameters include a dynamic salt value, a token identifier, a sliding window, a request sequence number for the token acquisition request and its corresponding sequence number usage status, and the request sequence number falls within the sliding window.

[0031] In this embodiment of the invention, by introducing a dynamic verification factor corresponding to the "dynamic salt value" and the "request sequence number", each token generation and verification depends on the real-time changing salt value and the incrementing request sequence number, so that even if an attacker intercepts historical communication data, they will not be able to construct a legitimate replay request.

[0032] In this embodiment of the invention, a Bitmap structure is used to represent the usage status of request sequence numbers within a sliding window. Each bit of the Bitmap corresponds to the usage status (used / unused) of a request sequence number. This Bitmap structure has the advantages of minimal memory usage, support for fast bit operations, and efficient status tracking for thousands of concurrent requests. Compared to traditional hash tables, databases, or traditional arrays / lists, using a Bitmap structure to record the usage status of request sequence numbers significantly reduces storage overhead and query latency, while also preventing attackers from bypassing verification by forging high sequence numbers.

[0033] In this embodiment of the invention, the sliding window is limited to maintaining the status of request sequence numbers within a specific range, thus avoiding the overhead of infinitely growing sequence number management; at the same time, the Bitmap structure further optimizes memory usage and bit operation efficiency.

[0034] In this embodiment of the invention, before performing step 101, the method further includes: The client module generates a random AES key based on the preset token acquisition requirements; The client module performs a key encryption operation on the random AES key based on the preset public key, obtains the key encryption result for the AES key, adds the key encryption result to the pre-generated Token acquisition request, and sends it to the cloud service.

[0035] In this embodiment of the invention, when performing key encryption operations, an encryption algorithm combining RSA and AES can be used, wherein RSA is used for key transmission and AES is used for request data encryption.

[0036] In this embodiment of the invention, it should be noted that when using the RSA+AES hybrid encryption algorithm, the preset public key is the cloud service RSA public key, that is, the client module holds the cloud service's RSA public key; at the same time, the cloud service also holds the RSA private key paired with the RSA public key, so that after the cloud service receives the encryption result of the key, it can correctly decrypt the data according to the RSA private key it holds, and obtain the random AES key generated by the client.

[0037] 102. The first encrypted data obtained by the client module is decrypted to obtain decrypted data. The client module then performs an increment operation on the request sequence number, a dynamic salt value generation operation, and a second encryption operation on the decrypted data to obtain the second encrypted data.

[0038] In this embodiment of the invention, the second encrypted data includes a business request and basic encrypted data corresponding to the decrypted data.

[0039] In this embodiment of the invention, the dynamic salt value needs to be regenerated with each request and participates in the first and second encryption operations, ensuring that even with the same key data, the encryption results generated at different times are completely different. The use of this dynamic salt value breaks the regularity of the encryption output, which helps to improve the security of encrypted data.

[0040] 103. The cloud service performs data decryption, identity and status query, first verification operation for the sliding window, and second verification operation for the serial number usage status on the received second encrypted data to obtain the anti-replay verification result for the second encrypted data.

[0041] In this embodiment of the invention, the cloud service performs dual verification on the second encrypted data for both the sliding window and the sequence number usage status, ensuring that each request sequence number is accepted only once and must be within the valid window range, thus fundamentally eliminating replay behavior.

[0042] 104. After confirming that the anti-replay verification result indicates that the verification has passed, respond to the business item corresponding to the business request.

[0043] In this embodiment of the invention, the technical solutions of steps 101-104 are implemented based on existing general encryption algorithms (RSA / AES) and database technology. No third-party components need to be introduced, and the deployment cost is low. Parameters such as window size and initial request sequence number range can be dynamically adjusted according to business scenarios, which has the advantage of strong compatibility. Thus, the above solutions can be applied to various scenarios such as Web API, mobile terminal interface, and IoT device communication.

[0044] In this embodiment of the invention, it should be noted that the client module of the application refers to the module in the application that has functions such as request token, data decryption, and data encryption, and this embodiment does not limit it.

[0045] It is evident that implementation Figure 1 The described token anti-replay verification method based on dynamic salt value and Bitmap sliding window achieves multi-dimensional dynamic anti-replay verification of API tokens by introducing a collaborative mechanism of dynamic salt value, sliding window and request sequence number status tracking, and bidirectional state synchronization logic between the client module and cloud service. Thus, without relying on high-precision time synchronization or complex centralized storage, it effectively resists attacks such as interception and replay, and duplicate submission within the window by providing dual protection through the range limitation of dynamic credentials and sliding window and the idempotency verification of request sequence number status, thereby improving the security of token requests.

[0046] In an optional embodiment, step 101 above, where the key data is obtained by the cloud service decrypting the Token acquisition request, and the first encryption operation is performed on the key data according to the pre-generated encryption parameters to obtain the first encrypted data for the key data, specifically includes: The cloud service decrypts the token acquisition request using the cloud service's private key to obtain key data, which includes at least the AES key corresponding to the token acquisition request. The cloud service performs an initialization operation on the preset encryption parameters to obtain the first salt value, the unique token identifier for the client module, the first request sequence number for the token acquisition request, the initial sliding window for the first request sequence number, and the initial sequence number usage status, which serve as the initialization result for the encryption parameters; the initial sequence number usage status is recorded through a pre-generated Bitmap array; The cloud service performs the first concatenation operation on the key data based on the initialization result to obtain the first encrypted data for the key data.

[0047] In this optional embodiment, the first request sequence number and subsequent second request sequence numbers are set to a value range of 100w-200w by default, and can be randomly generated according to usage requirements. The purpose of this random generation is to avoid fixed initial values ​​being easily guessed by attackers, thereby reducing the risk of replay attacks from the source. Furthermore, the initial sliding window is set to have a window size WINDOW_SIZE of 4-8 times the current concurrency level.

[0048] In this optional embodiment, the method by which the cloud service performs the first concatenation operation on the key data based on the initialization result to obtain the first encrypted data for the key data specifically includes: The cloud service performs a first concatenation operation on the first salt value, the unique token identifier, the first request sequence number and the AES key to obtain the first encrypted data for the key data. Furthermore, after the cloud service performs a first concatenation operation with the first salt value, unique token identifier, first request sequence number, and AES key to obtain the first encrypted data for the key data, the method further includes: The cloud service stores the first encrypted data, the unique token identifier, the first request sequence number, the initial sliding window, and the Bitmap array in the cloud service's memory; wherein, the initial sliding window includes the upper limit and lower limit of the window corresponding to the initial sliding window.

[0049] In this optional embodiment, the request is decrypted using the cloud service's private key, employing a typical hybrid encryption strategy (also known as asymmetric transmission of symmetric keys). This leverages the high security of asymmetric encryption during the initial handshake phase to ensure the security of AES key distribution, while subsequent communication utilizes the efficiency of AES symmetric encryption for large-scale data transmission. This solves the problem of easy key leakage in pure symmetric encryption while avoiding the performance overhead of pure asymmetric encryption during massive business data interaction, effectively achieving a balance between security and performance.

[0050] In this optional embodiment, multiple parameters, including dynamic salt value (first salt value), token identifier, request sequence number, sliding window, and sequence number usage status (Bitmap), are initialized as a whole and concatenated with the AES key of the request. This achieves atomic binding of multi-factor security parameters, ensuring that every subsequent business request verification must simultaneously validate all these dimensions, none of which can be omitted. For an attacker to forge a request, they must simultaneously forge or predict all parameters, significantly raising the attack threshold.

[0051] As can be seen, in this optional embodiment, on the one hand, a secure and efficient communication credential between the terminal and the cloud service is established through a hybrid encryption strategy; on the other hand, by deeply coupling dynamic security parameters with the Bitmap state tracking mechanism, a fine-grained initial definition of the client module state is achieved with extremely low memory usage, providing an accurate and efficient data foundation for verifying the legitimacy of token requests.

[0052] In another optional embodiment, the decrypted data described above includes at least a first salt value, a unique token identifier, and a first request sequence number; Optionally, step 102 above performs an increment operation on the request sequence number, a dynamic salt value generation operation, and a second encryption operation on the decrypted data, respectively, to obtain the second encrypted data for the decrypted data. Specifically, this includes: The client module increments the first request sequence number to obtain the second request sequence number and randomly generates a second salt value for the first salt value; the first salt value and the second salt value have the same number of bytes. The client module performs a second concatenation operation on the unique token identifier based on the preset client module public key, the second request sequence number, and the second salt value to obtain the basic encrypted data; The client module generates a business request and adds basic encrypted data to the business request to obtain second encrypted data for the decrypted data; the second encrypted data is sent to the cloud service; and the client module stores the basic encrypted data, the unique token identifier, and the second request sequence number in the client module's memory.

[0053] In this optional embodiment, the first salt value and the second salt value are typically 8-byte random strings.

[0054] In this optional embodiment, the client module increments the request sequence number and randomly generates a second salt value with the same number of bytes as the first salt value. This allows the cloud service to verify the client module's "liveliness" and compliance with the protocol by checking if the sequence number strictly increments and if the salt value is fresh. This step effectively involves the client module in the security token construction process, preventing attackers from impersonating "zombie requests" by simply replaying old data packets.

[0055] In this optional embodiment, after generating basic encrypted data, the client module stores it, along with a unique token identifier and a second request sequence number, in local memory. This eliminates the need for the client module to re-initiate the token acquisition process for each business request, reducing the pressure on the cloud service. Simultaneously, it can construct an independent verification context. The client module locally maintains the state of the current session (current sequence number, salt value), allowing the generation of subsequent requests to be independent of the real-time participation of the cloud service. However, logically, it maintains a strict correspondence with the cloud service's preset sliding window and Bitmap state, achieving collaboration between the stateless cloud service and the stateful client module.

[0056] As can be seen, this optional embodiment achieves state synchronization between the client module and the cloud service under stateless interaction, enabling each business request to carry dynamically generated, unpredictable security credentials from the client module. This not only significantly reduces the session storage pressure on the cloud service but also effectively prevents replay, delayed processing, and session hijacking of business requests, significantly improving the real-time performance and attack resistance of business interactions while ensuring high concurrency performance.

[0057] Example 2 Please see Figure 2 , Figure 2 This is a flowchart illustrating another token anti-replay verification method based on dynamic salt value and Bitmap sliding window disclosed in an embodiment of the present invention. Figure 2 The described token replay protection method based on dynamic salt value and Bitmap sliding window can be applied to token replay protection devices based on dynamic salt value and Bitmap sliding window, and the embodiments of the present invention are not limited thereto. Figure 2 As shown, the token anti-replay verification method based on dynamic salt value and Bitmap sliding window can include the following operations: 201. When a Token acquisition request initiated by the application's client module is detected, the cloud service decrypts the Token acquisition request to obtain key data, and performs a first encryption operation on the key data according to the pre-generated encryption parameters to obtain the first encrypted data for the key data.

[0058] 202. The first encrypted data obtained by the client module is decrypted to obtain decrypted data. The client module then performs an increment operation on the request sequence number, a dynamic salt value generation operation, and a second encryption operation on the decrypted data to obtain the second encrypted data.

[0059] 203. The cloud service performs a data decryption operation on the second encrypted data based on the cloud service private key to obtain the decryption result of the second encrypted data.

[0060] In this embodiment of the invention, the decryption result includes at least a second salt value, a unique token identifier, and a second request sequence number.

[0061] 204. The cloud service performs an identity query operation on the unique token to obtain the identity query result.

[0062] In this embodiment of the invention, when the identity query result indicates that there is no record for the unique token in the database, the unique token is marked as an expired token and the business request corresponding to the decryption result is refused, as the anti-replay verification result for the second encrypted data.

[0063] 205. When the identity query result indicates that there is a record for the unique token in the database, the cloud service performs a status query operation on the unique token to obtain the initial sliding window and Bitmap array corresponding to the unique token.

[0064] 206. The cloud service performs a first verification operation on the initial sliding window to obtain a first verification result, and performs a second verification operation on the Bitmap array to obtain a second verification result.

[0065] 207. The cloud service determines the first verification result and the second verification result as the anti-replay verification result for the second encrypted data.

[0066] 208. After confirming that the anti-replay verification result indicates that the verification has passed, respond to the business item corresponding to the business request.

[0067] For further descriptions of steps 201-202 and 208 in this embodiment of the invention, please refer to the other specific descriptions of steps 101-102 and 104 in Embodiment 1. These descriptions will not be repeated in this embodiment of the invention.

[0068] It is evident that implementation Figure 2 The described token anti-replay verification method based on dynamic salt value and Bitmap sliding window first performs an identity query operation on the unique token to realize intelligent verification of the validity of the unique token. Then, the sliding window is used as a coarse filter and the Bitmap is used for fine verification, which ensures that the final business logic request must be a legitimate request that is both within the time window and has not been used before, thereby improving the accuracy and efficiency of anti-replay detection of client module requests.

[0069] In an optional embodiment, the method by which the cloud service performs the first verification operation on the initial sliding window to obtain the first verification result in step 206 specifically includes: The cloud service determines whether the sequence number of the second request is less than or equal to the lower limit of the initial sliding window. When it is determined that the sequence number of the second request is less than or equal to the lower limit of the initial sliding window, an expiration flag is generated to indicate that the business request is an expired request, and the business request is rejected based on the expiration flag. When it is determined that the second request sequence number is greater than the lower limit of the initial sliding window, the cloud service determines whether the second request sequence number is greater than the upper limit of the initial sliding window. When it is determined that the second request sequence number is greater than the upper limit of the initial sliding window, the difference between the second request sequence number and the window size of the initial sliding window is calculated, and the difference is incremented by 1 to obtain the calculation result. The calculation result is determined as the new lower limit of the initial sliding window, and the second request sequence number is determined as the new upper limit of the initial sliding window. The cloud service determines the expired identifier or the updated initial sliding window as the first verification result for the initial sliding window.

[0070] In this optional embodiment, an on-demand adjustment mechanism based on request sequence number is set, which allows client module requests to fluctuate freely within a reasonable range (within the window size) without causing legitimate requests to be mistakenly rejected due to strict time windows.

[0071] In this optional embodiment, specifically, for requests with sequence numbers less than or equal to the lower window limit, an expiration flag is directly generated and the response is rejected, achieving rapid interception of replay attacks. Any request attempting replay will have a sequence number significantly lower than the current window limit. This logic identifies such requests as expired requests and discards them directly during the initial verification phase, avoiding unnecessary computational overhead such as subsequent decryption and Bitmap lookups, saving cloud service computing resources, and improving the response speed to replay attacks.

[0072] In this optional embodiment, for cases where the request sequence number exceeds the upper limit of the initial sliding window, a new lower limit of the window is determined by "second request sequence number - window size + 1", instead of simply discarding requests exceeding the limit or recharge windows. This ensures the continuity and non-overlapping nature of the windows during the sliding process. Simultaneously, it guarantees that there are no gaps between the new and old windows (preventing missed requests) and no excessive overlap (avoiding Bitmap state confusion), achieving a smooth transition of session state and maintaining the consistency and continuity of sequence number verification.

[0073] As can be seen, in this optional embodiment, on the one hand, the expiration interception of the lower window limit enables rapid identification of replay attacks and resource conservation; on the other hand, the trigger sliding mechanism of the upper window limit allows for fluctuations in request sequence numbers caused by normal factors such as network latency while ensuring the security of anti-replay, further improving the accuracy and reliability of subsequent token identification verification.

[0074] In another optional embodiment, the method by which the cloud service performs a second verification operation on the Bitmap array to obtain the second verification result specifically includes: The cloud service calculates the modulo value between the second request sequence number and the window size; The cloud service performs a query operation on the Bitmap array based on the modulus value to obtain the query results for the Bitmap array. The query results are used to indicate the usage status of the second request sequence number recorded in the Bitmap array. When the sequence number usage status is the first preset status, the cloud service determines that the business request is a duplicate request, generates a duplicate request identifier and rejects the business request as the second verification result; When the serial number usage status is the second preset status, the cloud service generates a compliance identifier for the business request and updates the serial number usage status to the first preset status as the second verification result.

[0075] In this optional embodiment, after determining that the anti-replay verification result indicates that the verification has passed, the method further includes: Clean up the unique token identifier mentioned above and initially generate the memory corresponding to the first request sequence number; Optionally, when it is determined that the sliding window has changed, the memory corresponding to the initial sliding window and the Bitmap corresponding to the initial sliding window are cleaned up simultaneously. That is, a global resource cleanup mechanism is designed to proactively release resources such as connection pools and mutexes through the exit callback function, avoiding resource leaks when the program exits and improving the long-term stability of the system.

[0076] In this optional embodiment, the position in the Bitmap array is located by calculating the modulus of the second request sequence number and the window size. This allows the linearly growing infinite request sequence numbers to be mapped to a circular buffer on a fixed-length Bitmap array, achieving cyclic reuse of request states within an infinite time window using a fixed-size memory space. Regardless of the duration of the business request or the growth of the sequence number, the size of the Bitmap array remains constant (determined by the window size), greatly saving memory resources.

[0077] In this optional embodiment, each bit of the Bitmap records the "usage status" of a sequence number, and the request is marked as processed by updating the status to a "first preset state" (e.g., 1). This allows the cloud service to complete the status query and update with extremely low computational overhead (one bit operation). Once a request is processed, the corresponding bit is immediately flipped. Any subsequent request carrying the same sequence number (i.e., a replay attack) will immediately hit the "first preset state" and be rejected when querying that bit. This algorithmically ensures that business requests are strictly executed once, that is, it achieves nanosecond-level request idempotency verification, which is beneficial to improving verification efficiency and also supports high-concurrency scenarios.

[0078] As can be seen, in this optional embodiment, by utilizing Bitmap's extremely low memory usage (one request per bit) and efficient bit operation capabilities, combined with a modulo index with a fixed window size, precise idempotency verification of each request number within the sliding window is achieved, greatly improving the accuracy and precision of verifying the compliance of each request number.

[0079] Example 3 Please see Figure 3 , Figure 3 This is a schematic diagram of a token anti-replay verification system based on dynamic salt value and Bitmap sliding window disclosed in an embodiment of the present invention. This token anti-replay verification system based on dynamic salt value and Bitmap sliding window can be applied to a terminal device with an application installed. The terminal device is communicatively connected to a network attached storage device and a cloud service, respectively. The terminal device accesses the network attached storage device and the cloud service through the application. Figure 3 As shown, the cloud service 301 may include a first decryption module 3011 and a first encryption module 3012; wherein: The first decryption module 3011 is used to decrypt the Token acquisition request to obtain key data when a Token acquisition request initiated by the application's client module 401 is detected. The first encryption module 3012 is used to perform a first encryption operation on the key data according to the pre-generated encryption parameters to obtain the first encrypted data for the key data; the encryption parameters include a dynamic salt value, a token identifier, a sliding window, a request sequence number for the token acquisition request and its corresponding sequence number usage status, and the request sequence number falls in the sliding window; like Figure 3 As shown, the client module 401 may include a second decryption module 4011 and a second encryption module 4012, wherein: The second decryption module 4011 is used to decrypt the acquired first encrypted data to obtain decrypted data; The second encryption module 4012 is used to perform an auto-increment operation on the request sequence number, a dynamic salt value generation operation, and a second encryption operation on the decrypted data to obtain the second encrypted data for the decrypted data; the second encrypted data includes the business request and the basic encrypted data corresponding to the decrypted data; like Figure 3 As shown, the cloud service 301 also includes a replay protection verification module 3013, wherein: The anti-replay verification module 3013 is used to perform data decryption operation, identity and status query operation, first verification operation for sliding window, and second verification operation for serial number usage status on the received second encrypted data, so as to obtain the anti-replay verification result for the second encrypted data. After determining that the anti-replay verification result indicates that the verification is successful, it responds to the business item corresponding to the business request.

[0080] It is evident that implementation Figure 3 The described token anti-replay verification system based on dynamic salt and Bitmap sliding window achieves multi-dimensional dynamic anti-replay verification of API tokens by introducing a collaborative mechanism of dynamic salt, sliding window and request sequence number status tracking, as well as bidirectional state synchronization logic between the client module and cloud service. Thus, without relying on high-precision time synchronization or complex centralized storage, it effectively resists attacks such as interception and replay, and duplicate submission within the window, and improves the security of token requests through the dual protection corresponding to the range limitation of dynamic credentials and sliding window and the idempotency verification of request sequence number status.

[0081] In an optional embodiment, the first decryption module 3011 obtains the key data by decrypting the Token acquisition request in the following specific ways: The key data is obtained by decrypting the Token acquisition request using the cloud service's 301 private key. The key data includes at least the AES key corresponding to the Token acquisition request. The first encryption module 3012 performs a first encryption operation on the key data according to the pre-generated encryption parameters to obtain the first encrypted data for the key data. Specifically, the method includes: An initialization operation is performed on the preset encryption parameters to obtain the first salt value, the unique token identifier for client module 401, the first request sequence number for the token acquisition request, the initial sliding window for the first request sequence number, and the initial sequence number usage status, which serve as the initialization result for the encryption parameters; the initial sequence number usage status is recorded through a pre-generated Bitmap array; Based on the initialization result, the first concatenation operation is performed on the key data to obtain the first encrypted data for the key data.

[0082] In this optional embodiment, the first encryption module 3012 performs a first concatenation operation on the key data according to the initialization result to obtain the first encrypted data for the key data. Specifically, this includes: Perform a first concatenation operation on the first salt value, the unique token identifier, the first request sequence number and the AES key to obtain the first encrypted data for the key data; And, please see Figure 4 , Figure 4 This is a schematic diagram of another token anti-replay verification system based on dynamic salt value and Bitmap sliding window disclosed in an embodiment of the present invention. Figure 4 As shown, the cloud service 301 may also include a storage module 3014, wherein: The storage module 3014 is used to store the first encrypted data, the unique token identifier, the first request sequence number, and the AES key into the memory of the cloud service 301 after the first encryption module 3012 performs a first concatenation operation on the first salt value, the unique token identifier, the first request sequence number, and the AES key key to obtain the first encrypted data for the key data; wherein, the initial sliding window includes the upper limit and lower limit of the window corresponding to the initial sliding window.

[0083] As can be seen, in this optional embodiment, on the one hand, a secure and efficient communication credential between the terminal and the cloud service is established through a hybrid encryption strategy; on the other hand, by deeply coupling dynamic security parameters with the Bitmap state tracking mechanism, a fine-grained initial definition of the client module state is achieved with extremely low memory usage, providing an accurate and efficient data foundation for verifying the legitimacy of token requests.

[0084] In another optional embodiment, the decrypted data includes at least a first salt value, a unique token identifier, and a first request sequence number; The second encryption module 4012 performs an increment operation on the request sequence number, a dynamic salt value generation operation, and a second encryption operation on the decrypted data, respectively, to obtain the second encrypted data for the decrypted data. The specific methods include: The first request sequence number is incremented to obtain the second request sequence number, and a second salt value is randomly generated for the first salt value; the first salt value and the second salt value have the same number of bytes. Based on the preset client module 401 public key, the second request sequence number, and the second salt value, the second concatenation operation is performed on the unique token identifier to obtain the basic encrypted data; Generate a business request and add the basic encrypted data to the business request to obtain the second encrypted data for the decrypted data; send the second encrypted data to the cloud service 301; and store the basic encrypted data, the unique token identifier, and the second request sequence number in the memory of the client module 401.

[0085] As can be seen, this optional embodiment achieves state synchronization between the client module and the cloud service under stateless interaction, enabling each business request to carry dynamically generated, unpredictable security credentials from the client module. This not only significantly reduces the session storage pressure on the cloud service but also effectively prevents replay, delayed processing, and session hijacking of business requests, significantly improving the real-time performance and attack resistance of business interactions while ensuring high concurrency performance.

[0086] In another optional embodiment, the anti-replay verification module 3013 performs data decryption, identity and status query, first verification operation for the sliding window, and second verification operation for the serial number usage status on the received second encrypted data, and obtains the anti-replay verification result for the second encrypted data in the following ways: The data decryption operation is performed on the second encrypted data using the cloud service 301 private key to obtain the decryption result of the second encrypted data; the decryption result includes at least the second salt value, the unique token identifier, and the second request sequence number. Perform an identity lookup operation on the unique token to obtain the identity lookup result; When the identity query result indicates that there is a record for the unique token in the database, a status query operation is performed on the unique token to obtain the initial sliding window and Bitmap array corresponding to the unique token. Perform a first verification operation on the initial sliding window to obtain a first verification result, and perform a second verification operation on the Bitmap array to obtain a second verification result; The first verification result and the second verification result are determined as the anti-replay verification results for the second encrypted data.

[0087] As can be seen, in this optional embodiment, an identity query operation is first performed on the unique token to realize intelligent verification of the validity of the unique token. Then, a sliding window is used for coarse filtering and a Bitmap is used for fine verification, which ensures that the final business logic request must be a legitimate request that is both within the time window and has not been used before, thereby improving the accuracy and efficiency of anti-replay detection of client module requests.

[0088] In another optional embodiment, the method by which the anti-replay verification module 3013 performs the first verification operation on the initial sliding window to obtain the first verification result specifically includes: Determine whether the sequence number of the second request is less than or equal to the lower limit of the initial sliding window. If it is determined that the sequence number of the second request is less than or equal to the lower limit of the initial sliding window, generate an expiration flag to indicate that the business request is an expired request, and refuse to respond to the business request based on the expiration flag. When it is determined that the second request number is greater than the lower limit of the initial sliding window, it is determined whether the second request number is greater than the upper limit of the initial sliding window. When it is determined that the second request number is greater than the upper limit of the initial sliding window, the difference between the second request number and the window size of the initial sliding window is calculated, and the difference is incremented by 1 to obtain the calculation result. The calculation result is determined as the new lower limit of the initial sliding window, and the second request number is determined as the new upper limit of the initial sliding window. The expired flag or the updated initial sliding window is determined as the first verification result for the initial sliding window.

[0089] As can be seen, in this optional embodiment, on the one hand, the expiration interception of the lower window limit enables rapid identification of replay attacks and resource conservation; on the other hand, the trigger sliding mechanism of the upper window limit allows for fluctuations in request sequence numbers caused by normal factors such as network latency while ensuring the security of anti-replay, further improving the accuracy and reliability of subsequent token identification verification.

[0090] In yet another optional embodiment, the method by which the anti-replay verification module 3013 performs a second verification operation on the Bitmap array to obtain a second verification result specifically includes: Calculate the modulus between the second request number and the window size; A query operation is performed on the Bitmap array based on the modulus value to obtain the query result for the Bitmap array. The query result is used to indicate the usage status of the second request sequence number recorded in the Bitmap array. When the sequence number usage status is the first preset status, the business request is determined to be a duplicate request, and a duplicate request identifier and a rejection of the business request are generated as the second verification result; When the sequence number usage status is the second preset status, a compliance identifier for the business request is generated, and the sequence number usage status is updated to the first preset status as the second verification result.

[0091] As can be seen, in this optional embodiment, by utilizing Bitmap's extremely low memory usage (one request per bit) and efficient bit operation capabilities, combined with a modulo index with a fixed window size, precise idempotency verification of each request number within the sliding window is achieved, greatly improving the accuracy and precision of verifying the compliance of each request number.

[0092] Example 4 Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a terminal device disclosed in an embodiment of the present invention. Figure 5 As shown, the terminal device may include: Memory 501 storing executable program code; Processor 502 coupled to memory 501; The processor 502 calls the executable program code stored in the memory 501 to execute some or all of the steps in any of the Token anti-replay verification methods based on dynamic salt value and Bitmap sliding window described in Embodiment 1 or Embodiment 2 of the present invention.

[0093] Example 5 Please see Figure 6 , Figure 6 This is a schematic diagram of another token anti-replay verification system based on dynamic salt value and Bitmap sliding window disclosed in an embodiment of the present invention. Figure 6 As shown, the system includes a terminal device as described in Embodiment 4 of the present invention, and a network-attached storage device communicatively connected to the terminal device. The terminal device is used to execute some or all of the steps in the Token Anti-Replay Verification Method based on Dynamic Salt Value and Bitmap Sliding Window described in Embodiment 1 or Embodiment 2 of the present invention. The terminal device is also used to access data stored on a network-attached storage device after confirming that the preset anti-replay verification process has been passed.

[0094] The system embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0095] Through the detailed description of the above embodiments, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, including read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), one-time programmable read-only memory (OTPROM), electrically-Erasable Programmable Read-Only Memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, disk storage, magnetic tape storage, or any other computer-readable medium that can be used to carry or store data.

[0096] Finally, it should be noted that the above embodiments are merely preferred embodiments of the present invention and are only used to illustrate the technical solutions of the present invention, not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A Token anti-replay verification method based on dynamic salt value and Bitmap sliding window, characterized in that, The method is applied to a terminal device with an application installed, the terminal device being communicatively connected to a network-attached storage device and a cloud service, respectively, and the terminal device accessing the network-attached storage device and the cloud service through the application, the method comprising: When a Token acquisition request initiated by the client module of the application is detected, the cloud service decrypts the Token acquisition request to obtain key data, and performs a first encryption operation on the key data according to the pre-generated encryption parameters to obtain the first encrypted data for the key data; the encryption parameters include a dynamic salt value, a Token identifier, a sliding window, a request sequence number for the Token acquisition request and its corresponding sequence number usage status, and the request sequence number falls within the sliding window; The client module decrypts the first encrypted data to obtain decrypted data, and then performs an auto-increment operation on the request sequence number, a dynamic salt value generation operation, and a second encryption operation on the decrypted data to obtain second encrypted data for the decrypted data; the second encrypted data includes the business request and the basic encrypted data corresponding to the decrypted data; The cloud service performs data decryption, identity and status query, first verification operation for the sliding window, and second verification operation for the serial number usage status on the received second encrypted data to obtain the anti-replay verification result for the second encrypted data. After determining that the anti-replay verification result indicates that the verification is successful, it responds to the business item corresponding to the business request.

2. The token anti-replay verification method based on dynamic salt value and Bitmap sliding window according to claim 1, characterized in that, The process involves decrypting the Token acquisition request by the cloud service to obtain key data, performing a first encryption operation on the key data according to pre-generated encryption parameters, and obtaining first encrypted data for the key data, including: The cloud service decrypts the Token acquisition request using the cloud service private key to obtain key data, and the key data includes at least the AES key corresponding to the Token acquisition request. The cloud service performs an initialization operation on the preset encryption parameters to obtain a first salt value, a unique token identifier for the client module, a first request sequence number for the token acquisition request, an initial sliding window for the first request sequence number, and an initial sequence number usage status, which serve as the initialization result for the encryption parameters; the initial sequence number usage status is recorded through a pre-generated Bitmap array; The cloud service performs a first concatenation operation on the key data based on the initialization result to obtain the first encrypted data for the key data.

3. The token anti-replay verification method based on dynamic salt value and Bitmap sliding window according to claim 2, characterized in that, The first concatenation operation performed by the cloud service on the key data according to the initialization result to obtain the first encrypted data for the key data includes: The cloud service performs a first concatenation operation on the first salt value, the unique token identifier, the first request sequence number, and the AES key to obtain the first encrypted data for the key data. Furthermore, after the cloud service performs a first concatenation operation on the first salt value, the unique token identifier, the first request sequence number, and the AES key to obtain the first encrypted data for the key data, the method further includes: The cloud service stores the first encrypted data, the unique token identifier, the first request sequence number, the initial sliding window, and the Bitmap array in the memory of the cloud service; wherein, the initial sliding window includes the upper limit and lower limit of the window corresponding to the initial sliding window.

4. The token anti-replay verification method based on dynamic salt value and Bitmap sliding window according to claim 2 or 3, characterized in that, The decrypted data includes at least the first salt value, the unique token identifier, and the first request sequence number; The process involves performing an increment operation on the request sequence number, a dynamic salt value generation operation, and a second encryption operation on the decrypted data to obtain second encrypted data for the decrypted data, including: The client module increments the first request sequence number to obtain a second request sequence number and randomly generates a second salt value for the first salt value; the first salt value and the second salt value have the same number of bytes. The client module performs a second concatenation operation on the unique token identifier based on the preset client module public key, the second request sequence number, and the second salt value to obtain basic encrypted data; The client module generates a business request and adds the basic encrypted data to the business request to obtain second encrypted data for the decrypted data; the second encrypted data is sent to the cloud service; and the client module stores the basic encrypted data, the unique token identifier, and the second request sequence number in the memory of the client module.

5. The token anti-replay verification method based on dynamic salt value and Bitmap sliding window according to claim 4, characterized in that, The cloud service performs data decryption, identity and status query, first verification operation for the sliding window, and second verification operation for the serial number usage status on the received second encrypted data to obtain an anti-replay verification result for the second encrypted data, including: The cloud service performs a data decryption operation on the second encrypted data based on the cloud service private key to obtain a decryption result for the second encrypted data; the decryption result includes at least the second salt value, the unique token identifier, and the second request sequence number. The cloud service performs an identity query operation on the unique token to obtain the identity query result; When the identity query result indicates that a record for the unique token exists in the database, the cloud service performs a status query operation on the unique token to obtain the initial sliding window and the Bitmap array corresponding to the unique token. The cloud service performs a first verification operation on the initial sliding window to obtain a first verification result, and performs a second verification operation on the Bitmap array to obtain a second verification result; The cloud service determines the first verification result and the second verification result as the anti-replay verification result for the second encrypted data.

6. The token anti-replay verification method based on dynamic salt value and Bitmap sliding window according to claim 5, characterized in that, The first verification result obtained by the cloud service performing a first verification operation on the initial sliding window includes: The cloud service determines whether the second request sequence number is less than or equal to the lower limit of the initial sliding window. When it is determined that the second request sequence number is less than or equal to the lower limit of the initial sliding window, an expiration identifier is generated to indicate that the service request is an expired request, and the service request is rejected based on the expiration identifier. When it is determined that the second request sequence number is greater than the lower limit of the initial sliding window, the cloud service determines whether the second request sequence number is greater than the upper limit of the initial sliding window. When it is determined that the second request sequence number is greater than the upper limit of the initial sliding window, the difference between the second request sequence number and the window size of the initial sliding window is calculated, and the difference is incremented by 1 to obtain the calculation result. The calculation result is determined as the new lower limit of the initial sliding window, and the second request sequence number is determined as the new upper limit of the initial sliding window. The cloud service determines the expired identifier or the updated initial sliding window as the first verification result for the initial sliding window.

7. The token anti-replay verification method based on dynamic salt value and Bitmap sliding window according to claim 6, characterized in that, The second verification result obtained by the cloud service performing a second verification operation on the Bitmap array includes: The cloud service calculates the modulo value between the second request sequence number and the window size; The cloud service performs a query operation on the Bitmap array based on the modulus value to obtain a query result for the Bitmap array. The query result is used to indicate the usage status of the second request sequence number recorded in the Bitmap array. When the sequence number is in the first preset state, the cloud service determines that the business request is a duplicate request, generates a duplicate request identifier, and refuses to respond to the business request as a second verification result. When the serial number usage status is the second preset status, the cloud service generates a compliance identifier for the business request and updates the serial number usage status to the first preset status as the second verification result.

8. A token anti-replay verification system based on dynamic salt value and Bitmap sliding window, characterized in that, The system is applied to a terminal device with an application installed. The terminal device is communicatively connected to a network-attached storage device and a cloud service. The terminal device accesses the network-attached storage device and the cloud service through the application. The cloud service includes: The first decryption module is used to decrypt the Token acquisition request to obtain key data when a Token acquisition request initiated by the client module of the application is detected. The first encryption module is used to perform a first encryption operation on the key data according to the pre-generated encryption parameters to obtain the first encrypted data for the key data; the encryption parameters include a dynamic salt value, a token identifier, a sliding window, a request sequence number for the token acquisition request and its corresponding sequence number usage status, and the request sequence number falls within the sliding window; The client module includes: The second decryption module is used to decrypt the obtained first encrypted data to obtain decrypted data; The second encryption module is used to perform an auto-increment operation on the request sequence number, a dynamic salt value generation operation, and a second encryption operation on the decrypted data to obtain second encrypted data for the decrypted data; the second encrypted data includes the business request and the basic encrypted data corresponding to the decrypted data; The cloud services also include: The anti-replay verification module is used to perform data decryption operation, identity and status query operation, first verification operation for the sliding window, and second verification operation for the serial number usage status on the received second encrypted data, so as to obtain the anti-replay verification result for the second encrypted data, and after determining that the anti-replay verification result indicates that the verification is successful, responding to the business item corresponding to the business request.

9. A terminal device, characterized in that, The terminal device includes: Memory containing executable program code; A processor coupled to the memory; The processor calls the executable program code stored in the memory to execute the Token anti-replay verification method based on dynamic salt value and Bitmap sliding window as described in any one of claims 1-7.

10. A token anti-replay verification system based on dynamic salt value and Bitmap sliding window, characterized in that, The system includes the terminal device as described in claim 9, and a network-attached storage device communicatively connected to the terminal device; The terminal device is used to execute the Token anti-replay verification method based on dynamic salt value and Bitmap sliding window as described in any one of claims 1-7; The terminal device is also used to access the data stored in the network-attached storage device after confirming that the preset anti-replay verification process has been passed.

Images