SaaS service security verification method and system under zero-trust architecture

Abstract

The invention provides a SaaS service security verification method and system under a zero-trust architecture. The method comprises the following steps: a client sends a login request to a server; the server side verifies the login request and returns a dynamic key, a coding rule table and a shuffling rule to the client side based on the login request and a current time window; the client generates a first password table corresponding to the dynamic key, hashing data of the service request according to a coding rule table, embedding the data into the first password table, performing shuffling processing of various different schemes on the first password table according to a shuffling rule to obtain a client request signature, and sending the service request and the client request signature to the server; and the server side obtains the server side request signature according to the same logic, verifies the client side request signature based on the server side request signature, and returns a response result corresponding to the service request to the client side after the verification is passed. According to the method, the end-to-end data integrity and security in the communication process of the client and the server can be remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of SaaS service security technology, and in particular to a method and system for SaaS service security verification under a zero-trust architecture. Background Technology

[0002] Web (World Wide Web) application security is a crucial component of cybersecurity. During client-server interactions, the HTTP (Hypertext Transfer Protocol) protocol itself is typically stateless and transmits data in plaintext, failing to guarantee data security. HTTPS uses TLS (Transport Layer Security) / SSL (Secure Sockets Layer) encryption to ensure data security, but even so, it primarily protects the transport layer, preventing eavesdropping and tampering during transmission and ensuring data confidentiality and integrity. However, at the application layer, it doesn't provide absolute security guarantees for the processing between the two ends. Malware or attackers can still tamper with and forge data before client-side encryption. Therefore, relying solely on HTTPS is insufficient to address all application-layer threats, and numerous security risks remain, such as data tampering, request forgery, and replay attacks. Among them, data tampering refers to the attacker intercepting and modifying parameters in the request (such as user ID (identity document), URL parameters, request body content, etc.) before the request is sent, in order to achieve the purpose of unauthorized operation; request forgery refers to the attacker forging the request of a legitimate user, sending malicious information instructions to the server, and illegally obtaining data; replay attack refers to the attacker intercepting a legitimate request and sending the request repeatedly later, in order to achieve the purpose of repeatedly performing a certain operation.

[0003] To address these threats, the industry has developed various application-layer security mechanisms, including token authentication (such as JSON Web Token, JWT), OAuth authorization, API (Application Programming Interface) keys, and request signing. Request signing is a common mechanism; its core idea is that the client uses an agreed-upon algorithm and key to generate a signature on the key information of the request, and the server uses the same method to verify the signature to confirm the source and integrity of the request. Traditional signature mechanisms rely on fixed keys or relatively simple signature algorithms, and there is still a risk of key leakage or cracking under complex attack scenarios. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a method and system for security verification of SaaS services under a zero-trust architecture, which can significantly improve end-to-end data integrity and security during communication between the client and the server.

[0005] In a first aspect, this invention provides a method for security verification of SaaS services under a zero-trust architecture. The method is applied to a target system, which includes a client and a server. The method includes: The client sends a login request to the server; The server verifies the login request and, based on the login request and the current time window, returns a dynamic key, an encoding rule table, and a shuffling rule to the client. The encoding rule table contains multiple elements, and the value corresponding to the subscript index of each element is used to describe the embedding index of the string it is bound to in the password table. The client generates a first cryptographic table corresponding to the dynamic key, hashes the data of the business request according to the encoding rule table and embeds it into the first cryptographic table, and performs various different shuffling processes on the first cryptographic table according to the shuffling rules to obtain the client request signature, and sends the business request and the client request signature to the server. The server generates a second cryptographic table corresponding to the dynamic key. The data of the business request is hashed according to the encoding rules and embedded into the second cryptographic table. The second cryptographic table is shuffled according to various schemes according to the shuffling rules to obtain the server-side request signature. The server-side request signature is used to verify the client-side request signature. After successful verification, the server returns the response result corresponding to the business request to the client.

[0006] In one implementation, the first cryptographic table is shuffled using various schemes according to shuffling rules to obtain the client request signature, including: Iterate through the shuffling rules and the shuffling algorithms included; Invoke the current shuffling algorithm in the shuffling rules and use the current shuffling algorithm to shuffle the first cipher table; Continue calling the next shuffle algorithm in the shuffle rules, and use the next shuffle algorithm to shuffle the first cipher table after shuffling, until the last shuffle algorithm in the shuffle rules is used to shuffle the cipher table after shuffling. The strings corresponding to the elements in the first cipher table after shuffling are concatenated to obtain the client request signature.

[0007] In one implementation, the shuffling algorithm includes random shuffling; shuffling the first cipher table using the current shuffling algorithm includes: Generate the current element index based on the dynamic key, and construct the shuffle interval corresponding to the current element index; The index of the element to be swapped is determined by the shuffling interval; Swap the string corresponding to the element at the current element index with the string corresponding to the element at the index of the element to be swapped; Update the current element index, construct a new shuffling interval corresponding to the current element index, and stop element swapping when the preset conditions are met, thereby realizing the shuffling process of the elements contained in the first cipher table.

[0008] In one implementation, the shuffling algorithm includes hash shuffling; shuffling the first cryptographic table using the current shuffling algorithm further includes: The strings corresponding to the elements in the first cipher table are hashed to obtain the hash values ​​of the elements. Based on the hash value of the element and the index of the current element, determine the shuffling sorting factor of the element; Based on the shuffling sorting factor, the strings corresponding to the elements are sorted in descending or ascending order to shuffle the elements contained in the first cipher table.

[0009] In one implementation, the shuffling algorithm includes group shuffling; shuffling the first cipher table using the current shuffling algorithm further includes: The first cipher table is divided into multiple sub-cipher tables; For any given cipher subtable, perform the following operations: determine the dictionary value or shuffle sort factor of the string corresponding to the element contained in the cipher subtable, and sort the string corresponding to the element within the group according to the dictionary value or shuffle sort factor; Reassemble the sorted cipher sub-tables within the group to shuffle the elements contained in the first cipher table.

[0010] In one implementation, the shuffling algorithm includes cross-group shuffling; shuffling the first cipher table using the current shuffling algorithm further includes: The first cipher table is divided into multiple sub-cipher tables; For any given cipher subtable, perform the following operations: determine the dictionary value or shuffle sort factor of the string corresponding to the element contained in the cipher subtable, and sort the string corresponding to the element within the group according to the dictionary value or shuffle sort factor; Using fixed or random index mapping, the strings corresponding to the elements contained in the sorted cipher subtable within the group are swapped across groups. Reassemble the cipher sub-tables after cross-group exchange to shuffle the elements contained in the first cipher table.

[0011] In one implementation, the shuffling algorithm includes shift shuffling; shuffling the first cipher table using the current shuffling algorithm further includes: The dynamic key is hashed to obtain the hash value corresponding to the dynamic key; The displacement step size is determined based on the hash value corresponding to the dynamic key; Based on the displacement step size, the strings corresponding to the elements contained in the first cipher table are shifted left or right to achieve the shuffling of the elements contained in the first cipher table.

[0012] In one implementation, the shuffling algorithm includes shuffling the first and last digits; shuffling the first cipher table using the current shuffling algorithm further includes: Determine element pairs from both ends of the first cipher table, and mirror and swap the strings corresponding to the elements contained in the element pairs. Continue to determine new element pairs from both ends of the first cipher table until the preset conditions are met, then stop the mirror swap, thereby shuffling the elements contained in the first cipher table.

[0013] In one implementation, the shuffling algorithm includes reversing the shuffling; shuffling the first cipher table using the current shuffling algorithm further includes: The strings corresponding to the elements in the first cipher table are reversed, thus shuffling the elements in the first cipher table.

[0014] In one implementation, the shuffling algorithm includes parity shuffling; shuffling the first cipher table using the current shuffling algorithm further includes: The first cipher table is split according to the parity of the index of the current element corresponding to the element contained in the first cipher table, resulting in an odd-numbered cipher table and an even-numbered cipher table. The odd-numbered and even-numbered codebooks are recombined according to preset rules to shuffle the elements contained in the first codebook.

[0015] Secondly, this invention also provides a security verification system for SaaS services under a zero-trust architecture, including a client and a server: The client is used to send login requests to the server; The server is used to verify login requests and, based on the login request and the current time window, return a dynamic key, an encoding rule table, and shuffling rules to the client. The encoding rule table contains multiple elements, and the value corresponding to the subscript index of each element is used to describe the embedding index of the string it is bound to in the password table. The client is also used to generate a first cryptographic table corresponding to the dynamic key, hash the data of the business request according to the encoding rule table and embed it into the first cryptographic table, and perform various different shuffling processes on the first cryptographic table according to the shuffling rules to obtain the client request signature, and send the business request and the client request signature to the server. The server is also used to generate a second cryptographic table corresponding to the dynamic key, hash the data of the business request according to the encoding rules and embed it into the second cryptographic table, and shuffle the second cryptographic table according to various different schemes according to the shuffling rules to obtain the server-side request signature. The server-side request signature is used to verify the client-side request signature, and after the verification is successful, the response result corresponding to the business request is returned to the client.

[0016] This invention provides a method and system for security verification of SaaS services under a zero-trust architecture. The client sends a login request to the server. The server verifies the login request and, based on the login request and the current time window, returns a dynamic key, an encoding rule table, and shuffling rules to the client. The encoding rule table contains multiple elements, and the index of each element describes the embedding index of the string it is bound to in the password table. The client generates a first password table corresponding to the dynamic key, hashes the data of the business request according to the encoding rule table, embeds it into the first password table, and performs various shuffling operations on the first password table according to the shuffling rules to obtain a client request signature. The client sends the business request and the client request signature to the server. The server generates a second password table corresponding to the dynamic key, hashes the data of the business request according to the encoding rule, embeds it into the second password table, and performs various shuffling operations on the second password table according to the shuffling rules to obtain a server request signature. The server verifies the client request signature based on the server request signature, and returns the response result corresponding to the business request to the client upon successful verification. The above method introduces a shuffling mechanism into the enhanced request signature verification mechanism. The combination of multiple shuffling algorithms is completely unpredictable, and different combination orders will produce completely different transformation results, thereby hiding the original structure of the cipher table, greatly increasing the difficulty and cost of cracking by attackers, and improving the security of data during transmission or storage.

[0017] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0018] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0019] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating a security verification method for SaaS services under a zero-trust architecture, provided as an embodiment of the present invention. Figure 2 A schematic diagram of a system architecture provided for an embodiment of the present invention; Figure 3 This is a schematic diagram of another system architecture provided in an embodiment of the present invention; Figure 4 This invention provides a technical framework diagram of a method for secure signature verification of SaaS services. Figure 5 A schematic diagram of a mapping process provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of a shuffling rule for a cipher table provided in an embodiment of the present invention; Figure 7 This is a schematic diagram illustrating the principle of a rearrangement process provided in an embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, 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.

[0022] Currently, existing web security signature verification schemes mainly suffer from the following drawbacks: Static keys are easily leaked and cracked: Traditional schemes typically use fixed keys, which are valid for a long time once generated, unless manually or dynamically rotated. Once leaked or stolen, requests can be forged. Insufficient signature algorithm security: Traditional signature algorithms and logic are standardized and transparent. Attackers who obtain the key can arbitrarily tamper with data, construct legitimate requests, and illegally obtain data. Lack of dynamic signature mechanisms: The signature generation logic of traditional schemes is relatively simple and lacks dynamic change mechanisms, making them vulnerable to attack through analysis and cracking. Exposed client logic: The client-side code's data assembly and preprocessing logic is usually not effectively protected or obfuscated. Attackers can easily obtain the key and all implementation details of the signature algorithm through reverse engineering, decompiling, or debugging, thereby bypassing security protections.

[0023] Based on this, the present invention provides a method and system for security verification of SaaS services under a zero-trust architecture, which can significantly improve end-to-end data integrity and security during communication between the client and the server.

[0024] To facilitate understanding of this embodiment, a detailed description of a SaaS service security verification method under a zero-trust architecture, as disclosed in this embodiment of the invention, will be provided first. This method is applied to a target system, such as an integrated talent management platform. The target system includes a client and a server. See [link to relevant documentation]. Figure 1 The diagram shows a flowchart of a SaaS service security verification method under a zero-trust architecture. The method mainly includes the following steps S102 to S108: In step S102, the client sends a login request to the server.

[0025] In step S104, the server verifies the login request and, based on the login request and the current time window, returns the dynamic key, encoding rule table, and shuffling rules to the client.

[0026] The encoding rule table contains multiple elements, and the index of each element describes the embedding index of the string it is bound to in the password table. This password table is designated as the first password table and the second password table. The terms "first" and "second" in these tables are only used to distinguish between password tables generated by the client and server, and have no actual meaning.

[0027] In step S106, the client generates a first cryptographic table corresponding to the dynamic key, hashes the data of the business request according to the encoding rule table and embeds it into the first cryptographic table, and performs various different shuffling processes on the first cryptographic table according to the shuffling rules to obtain the client request signature, and sends the business request and the client request signature to the server.

[0028] In one example, a random seed is generated based on the dynamic key, and multiple random strings are randomly generated based on the random seed as the first cryptographic table. The strings consist of numbers 0-9 and uppercase and lowercase letters a, b, and c. From the elements contained in the encoding rule table, the target elements bound to the request elements contained in the business request are randomly assigned. Then, according to the embedding index described by the subscript index of the target element, the request elements contained in the business code are subjected to mixed hash processing, and the corresponding hash string is embedded into the element corresponding to the embedding index in the first cryptographic table. The various shuffling algorithms contained in the shuffling rules are called to shuffle the first cryptographic table in turn. After string concatenation, the client request signature can be obtained.

[0029] Step S108: The server generates a second cryptographic table corresponding to the dynamic key, hashes the data of the business request according to the encoding rules and embeds it into the second cryptographic table, and performs various different shuffling processes on the second cryptographic table according to the shuffling rules to obtain the server-side request signature. The server-side request signature is used to verify the client-side request signature, and after successful verification, the response result corresponding to the business request is returned to the client.

[0030] In one example, the server generates a server-side request signature according to the same logic. It then performs multiple rounds of signature comparison and verification between the server-side request signature and the client-side request signature, taking into account the remaining validity period of the current time window. After passing the verification, it executes the business logic corresponding to the business request and returns the response result to the client.

[0031] The security verification method for SaaS services under a zero-trust architecture provided in this invention introduces a shuffling mechanism into the enhanced request signature verification mechanism. The combination of multiple shuffling algorithms is completely unpredictable, and different combination orders will produce completely different transformation results, thereby hiding the original structure of the password table, greatly increasing the difficulty and cost of cracking by attackers, and improving the security of data during transmission or storage.

[0032] Given the widespread adoption of SaaS applications and the continuous evolution of cyberattack methods, traditional web security verification mechanisms face increasingly severe challenges. Data may be tampered with, forged, or replayed during the request process, posing a serious threat to tenant data security and the correctness of business logic. This invention proposes a specific implementation method for secure signature verification of SaaS services. By introducing a signature algorithm employing multiple security technologies such as dynamic password tables, encoding rule tables, multiple hashing, reshuffling, and code obfuscation, it achieves high-strength signature verification of web requests, enhancing the security of client-server communication and the security protection capabilities of SaaS applications.

[0033] First, the system architecture will be explained. (See below) Figure 2 The diagram shown is a schematic of a system architecture. Figure 2 This illustration shows the client-server collaborative verification architecture used in an embodiment of the present invention. See also... Figure 3 Another system architecture diagram is shown below. Figure 3 The system provided in this embodiment of the invention mainly includes the following core components: Client-Signature Generation: Responsible for obtaining user keys and encoding tables, generating password tables, and generating request signatures according to rules; Server-Signature Verification: Responsible for signature generation and verification, and security event recording (this logic is built into the gateway); Server-Dynamic Password Rule Management Service: Responsible for the generation, distribution, storage, and updating of dynamic keys and encoding rule tables. (Dynamic keys and encoding rule tables are automatically updated after expiration; dynamic keys are used to generate password tables); Server-Business Services: Implement specific business logic and functions based on a domain model, typically divided into multiple independent microservice units according to the business domain.

[0034] Different tenants or users can configure independent security policy levels such as signature algorithms, key management, and encoding rules to achieve security isolation between tenants or even between users, prevent the spread of security risks across tenants and users, and ensure that even if the security mechanism of a certain tenant or user is cracked, it will not affect other tenants.

[0035] By embedding the server-side signature generation and verification logic within the gateway, the main purpose is to complete security verification and malicious request filtering before requests reach the backend business services. This reduces the computational burden and network pressure on the backend servers. At the same time, by leveraging the gateway's high concurrency processing capabilities and unified entry point, faster security response speeds, more centralized security policy management, and better system architecture decoupling are achieved. This allows the gateway to focus on security protection while the backend focuses on business logic, thereby significantly improving overall system performance and maintainability while ensuring security.

[0036] Based on the above system architecture, see Figure 4The diagram illustrates a technical framework for a SaaS service security signature verification method, primarily comprising client-side and server-side components. The client-side component includes processes such as client request authentication, obtaining tenant user ID information, obtaining a dynamic key and encoding rule table, generating a password table based on the dynamic key, request element index allocation, various hash calculations for request elements, updating and reshuffling the dynamic password table, concatenating the signature string and generating the final client request signature, and request construction and signature appending. The server-side component includes processes such as server authentication, obtaining a dynamic key and encoding rules, generating a password table based on the dynamic key, obtaining request parameters, various hash calculations for request parameters, updating and reshuffling the dynamic password table, concatenating the signature string and generating the final server-side request signature, and multi-round signature comparison verification. The multi-round signature comparison verification process involves verifying whether the client and server signatures match. If they match, the request is processed; otherwise, it continues to check if the comparison threshold has been exceeded. If not, the password table and encoding rule table from the previous window are retrieved, and the process of "updating and reshuffling the dynamic password table, concatenating the signature string and generating the final server-side request signature" is repeated. If the threshold is exceeded, the request is rejected.

[0037] based on Figure 4 The technical framework shown in this invention provides a specific implementation of a method for secure signature verification of SaaS services. This includes: (a) Client authentication: Users follow the standard authentication process (username / password) and send a login request to the server through the client to complete the login verification.

[0038] (ii) Server-side authentication: After receiving the login request from the client, the server performs authentication to obtain the login user ID and the tenant ID to which it belongs.

[0039] (III) Client obtains dynamic password rule table: Based on the user's identity information after login, the client sends a request to the server's dynamic password rule management service. The server returns information such as the key and encoding rule table based on the current time window, tenant ID, and user ID. The data returned for each tenant user is different, and has timeliness and uniqueness.

[0040] For example: "key": "secret_2025"; "patch": [15, 28, 45, 36, 72, 89, 81, 62, 25, 33]; "rule": 1,3,5; "ttl": 600; The dynamic key (Key) is used to generate 100 random strings, i.e., the cipher table (Table). The encoding rule table (Patch) contains 10 elements, with indices ranging from 0 to 9. The value corresponding to each index is a unique integer between 0 and 99. This index determines the position in the cipher table where the hashed key information should be inserted after hashing. The rule determines the shuffling rules for the updated cipher table; 1, 3, 5 indicates using shuffling schemes 1, 3, and 5. TTL (Time To Live) is the remaining validity period (in seconds). This information is time-sensitive and unique; expired information is unusable and needs to be retrieved again.

[0041] (iv) The client generates 100 random strings (password table) based on the dynamic key Key: the dynamic key Key is encoded to obtain the encoding array corresponding to the dynamic key Key; the encoding array is hashed to generate the random seed corresponding to the dynamic key Key based on the hash calculation result; multiple random strings are generated using the random seed to obtain the first password table; wherein the number of random strings is consistent with the number of elements in the first password table.

[0042] In the specific implementation, the client generates a 32-bit integer random seed based on the dynamic key Key. Then, it randomly generates 100 strings (consisting of digits 0-9 and uppercase and lowercase letters a, b, a) based on the seed, which serve as the first password table. For example, if the dynamic key Key is "secret_2025", the string Key is first converted to a UTF-8 byte array, and then a hash value is calculated using SHA-256, resulting in a 32-byte (256-bit) hash result. Subsequently, the first 4 bytes of the hash result are extracted using BitConverter.ToInt32(hash) and converted to a 32-bit integer. In this process, if configured for little-endian (low byte first), the first four bytes are read in byte order, resulting in a random seed of 2,004,074,403. Conversely, if configured for big-endian (high byte first), the byte order is reversed, resulting in the absolute value of a random seed of 1,563,781,510. Finally, 100 random strings are generated based on the random seed as the first cipher table and cached. This first cipher table becomes unusable after expiration and needs to be regenerated.

[0043] (v) The client hashes the data of the business request according to the encoding rule table and embeds it into the first cryptographic table to obtain the client request signature. This includes the processes of request element index allocation, various hash calculations of request elements, dynamic cryptographic table updates and reshuffling, concatenating the signature string, and generating the final client request signature. In specific implementation, the client performs the following operations: (5.1) Perform mixed hashing on the request elements contained in the business request to obtain the hash string corresponding to the request element. The request element includes one or more of the following: tenant ID, user ID, request path, request parameters, and request body. The five request elements are: TenantID: unique identifier of the current tenant; UserID: unique identifier of the current user; Path: URL path of the request; Querystring: URL query parameter string; Body: request body content (JSON or form data).

[0044] In practice, the tenant ID, user ID, request path (Path), request parameter (Querystring), and the actual request value in the request body are each subjected to a hybrid hash calculation. The hash algorithm can be MD5, SHA1, or SHA256, balancing computational efficiency and security. Note: For the request parameter (Querystring), it is first sorted by name (AZ) before applying the hash algorithm to prevent server-side verification failure due to changes in parameter position. Example: HashTenantID = SHA1(TenantID) HashUserID = SHA1(UserID) HashPath = MD5(Path) HashQuerystring = MD5(Sort(Querystring)) HashBody = SHA256(Body).

[0045] (5.2) According to the encoding rule table, embed the hash string corresponding to the request element into the first cryptographic table to obtain a new first cryptographic table. Specifically: (5.21) Determine the target element bound to the request element from the elements contained in the encoding rule table. In specific implementation, the five request elements, namely tenant ID, user ID, request path, request parameter querystring, and request body, are randomly (fixed) assigned to the corresponding target elements in the encoding rule table. For example, the elements corresponding to the five subscript indices 0, 1, 3, 5, and 9 are the target elements bound to each request element. That is, the tenant ID index is 0, the user ID index is 1, the path index is 3, the querystring index is 5, and the body index is 9.

[0046] Example: Five elements are assigned encoding rule table indices, corresponding to password table indices: TenantID → Index 0 → Patch[0] → Table Location Index Patch

[15] UserID → Index 1 → Patch[1] → Table Location Index Patch

[28] Path → Index 3 → Patch[3] → Table Location Index Patch

[36] Querystring → Index 5 → Patch[5] → Table position index Patch

[89] Body → Index 9 → Patch[9] → Table Location Index Patch

[33] .

[0047] (5.22) According to the embedding index described by the subscript index of the target element, replace the random string corresponding to the element at the embedding index in the first cipher table with the hash string corresponding to the request element, and obtain a new first cipher table.

[0048] In practice, based on the mapping relationship between the request elements, the encoding rule table, and the password table, the calculated hash value is replaced in the corresponding position in the password table. For example, see [link to example]. Figure 5 The diagram shown illustrates a mapping process:

[0049] Please refer to the example again, which involves replacing the random string at position 15 of the first password table with the hash string corresponding to the tenant ID. The updated password table has a length of 100, with 5 positions for the hash value of the newly replaced request element and 95 positions for the original random string.

[0050] (5.3) Shuffle the first cipher table using various different schemes according to the shuffling rules. Specifically, for the updated dynamic cipher table, the cipher table is reshuffled according to the shuffling rules. The following 8 schemes can be used for shuffling, which only rearrange the positions of the cipher table elements while keeping the content of the elements unchanged.

[0051] For example: see Figure 6 The diagram shows a shuffling rule for a cipher table. The cipher table shuffling rule is Rule 1, 3, 5, which means the combination is: Scheme 1 → Scheme 3 → Scheme 5 (random shuffling → group shuffling → shift shuffling). For example, the cipher table shuffling rule is Rule 6, 4, 2, 1, which means the combination is: Scheme 6 → Scheme 4 → Scheme 2 → Scheme 1 (first and last shuffling → cross-group shuffling → hash shuffling → random shuffling).

[0052] Specifically, there are 8 shuffling schemes: random shuffling, hash shuffling, grouping shuffling, cross-group shuffling, shift shuffling, first and last shuffling, reversal shuffling, and odd / even shuffling. The total number of permutations and combinations of these 8 shuffling schemes is: ; Here, 𝑃(8, 𝑘) represents selecting k options from 8 different schemes, where k ranges from 1, 2, ..., 8. Calculate the number of permutations for each k: When k=1: P(8,1) =8; When k=2: P(8,2) =8×7=56; When k=3: P(8,3) =8×7×6=336; When k=4: P(8,4) =8×7×6×5=1680; When k=5: P(8,5) = 8×7×6×5×4=6720; When k=6: P(8,6) =8×7×6×5×4×3=20160; When k=7: P(8,7) =8×7×6×5×4×3×2=40320; When k=8: P(8,8) =8×7×6×5×4×3×2×1=40320 (Note: 0!=1).

[0053] Finally, summing the results, among the 8 different schemes, the minimum number of schemes to choose is 1, and the maximum number of schemes to choose is all 8, resulting in a total of 109,600 combinations. This variety of shuffling schemes is completely unpredictable; different combinations will produce entirely different transformations, which will greatly increase the difficulty and cost for attackers to crack the scheme.

[0054] Based on this, this embodiment of the invention provides a specific implementation method for dynamic shuffling: traversing the shuffling algorithms included in the shuffling rules; calling the current shuffling algorithm in the shuffling rules and using the current shuffling algorithm to shuffle the first cipher table; continuing to call the next shuffling algorithm in the shuffling rules and using the next shuffling algorithm to shuffle the shuffled first cipher table, until the last shuffling algorithm in the shuffling rules is used to shuffle the shuffled cipher table. For ease of understanding, this embodiment of the invention explains and describes the eight shuffling algorithms respectively.

[0055] The first shuffling algorithm, random shuffling: generates the current element index based on the dynamic key, constructs the shuffling interval corresponding to the current element index; determines the index of the element to be swapped based on the shuffling interval; swaps the string corresponding to the element at the current element index with the string corresponding to the element at the index of the element to be swapped; updates the current element index, constructs a new shuffling interval corresponding to the current element index, and stops element swapping when a preset condition is met, thereby realizing the shuffling process of the elements contained in the first cipher table.

[0056] In practice, the updated first cipher table is randomly rearranged using a shuffling algorithm based on the dynamic key Key. After shuffling, the positions of the elements in the cipher table are completely rearranged, but the content of the elements remains unchanged. The core logic of the rearrangement process is to traverse backwards from the end of the array. In each step, such as... Figure 7 The diagram illustrates the principle of a rearrangement process. It includes: Randomly select an index: Based on the random seed generated by the dynamic key Key, determine the index i of the current element, take the index i of the current element as the end of the array, construct the rearrangement interval [0, i], and generate a random integer j in the range [0, i] as the index of the element to be swapped.

[0057] Swap elements: Swap the string at index i of the current element with the string at index j of the element to be swapped.

[0058] Move forward: Decrement the index of the current element i by 1, and repeat the above process until the beginning of the array is reached.

[0059] This algorithm generates the same random sequence based on a dynamic key (key). By gradually narrowing the range of random selections, it reshuffles the first cryptographic table. This shuffling randomly rearranges the entire first cryptographic table, completely disrupting the original index-ordered elements. This makes it impossible for an attacker, even knowing the replacement positions of the hash values, to predict the final concatenation order of the signature string. The shuffling process uses a deterministic random number generator to ensure that, with the same input dynamic key (key), the client and server produce the same shuffling result, thus guaranteeing the consistency of signature verification.

[0060] The second shuffling algorithm, hash shuffling, involves hashing the strings corresponding to the elements in the first cipher table to obtain the hash value of each element; determining the shuffling sorting factor based on the hash value and the current element index; and then sorting the strings in descending or ascending order according to the shuffling sorting factor to shuffle the elements in the first cipher table.

[0061] In practice, each element value in the password table is calculated using a standard hashCode, and then rearranged based on its position index. The steps are as follows: Hash Calculation: Calculate the standard hashCode for each element value in Table[i]; Value Generation: Take the absolute value of the hash value and add it to the current element index i, using this as the shuffling sorting factor; Sorting Execution: Sort the elements in ascending or descending order according to the calculated shuffling sorting factor. For example, with 3 elements: Original array: ["SwbqlMLIHjtQUjbZgK", "i0O7TLSoMMDeh", "x3nF9kLmPqR"]; Location index: [0, 1, 2]; Formula: Value = abs(hashCode(str)) + index; HashCode Calculation: "SwbqlMLIHjtQUjbZgK".hashCode() → 1842346573; "i0O7TLSoMMDeh".hashCode() → -789543210; "x3nF9kLmPqR".hashCode() → 456789123; Numerical calculations: Element 0: |1842346573|+0=1842346573; Element 1: |-789543210|+1=789543211; Element 2: |456789123+2=456789125; The sorting result is: [456789125, 789543211, 1842346573]; New array: ["x3nF9kLmPqR", "i0O7TLSoMMDeh", "SwbqlMLIHjtQUjbZgK"].

[0062] The third shuffling algorithm is group shuffling: the first cipher table is divided into multiple cipher sub-tables; for any cipher sub-table, the following operations are performed: determine the dictionary value or shuffling sorting factor of the string corresponding to the element contained in the cipher sub-table, and sort the string corresponding to the element within the group according to the dictionary value or shuffling sorting factor; reassemble the sorted cipher sub-table within the group to realize the shuffling process of the elements contained in the first cipher table.

[0063] In practice, the cipher table is grouped into fixed-size groups (e.g., 10 groups, 20 groups), and each group is independently sorted while maintaining the overall order between groups. The steps are as follows: Grouping: Divide the cipher table into groups according to a preset number of groups; Sorting within each group: Sort the element values ​​within each group lexicographically or by hash value; Array reconstruction: Reassemble the array according to the group order to form a new cipher table. Example: Original array length: 100, divided into 10 groups, each group containing 10 elements. Grouping result: Group0: [elements 0-9] → sort within the group → [sorted elements 0-9]; Group1: [elements 10-19] → sort within the group → [sorted elements 10-19]; ...; Group9: [elements 90-99] → sort within the group → [sorted elements 90-99]; The final Table = Group0 + Group1 + ... + Group9.

[0064] The fourth shuffling algorithm, cross-group shuffling: The first cipher table is divided into multiple cipher sub-tables; for any cipher sub-table, the following operations are performed: Determine the dictionary value or shuffling sorting factor of the strings corresponding to the elements contained in the cipher sub-table; sort the strings corresponding to the elements within the group according to the dictionary value or shuffling sorting factor; use fixed index mapping or random index mapping to perform cross-group swaps on the strings corresponding to the elements contained in the sorted cipher sub-table; reassemble the cross-group swapped cipher sub-tables to achieve the shuffling process for the elements contained in the first cipher table. Fixed index mapping, also known as fixed position swapping, can be pre-configured with a swap rule matrix that describes the position of the elements swapped across groups; random index mapping, also known as random position swapping, can use a dynamic key (Key) as a seed to generate random numbers for corresponding position swaps.

[0065] In practice, based on the grouping of the cipher table, not only is the element within each group sorted, but some elements are also randomly swapped between different groups to increase cross-group randomness. The steps are as follows: Grouping: Divide the cipher table into groups; Element Swapping: Swap elements across groups according to swapping rules, including fixed-position swaps and random-position swaps; Re-sorting: After the swapping is complete, sort the entire array or each group separately. Example: Original grouping: Group0:[A0,A1,A2,A3,A4]; Group1:[B0,B1,B2,B3,B4]; Group2:[C0, C1, C2, C3, C4]; Group3:[D0, D1, D2, D3, D4]; Exchange rule matrix: Group0[1] ↔ Group2[3]; Group1[0] ↔ Group3[2]; Group2[4] ↔ Group0[2]; After the exchange: Group0:[A0, C3, C4, A3, A4]; Group1:[D2,B1,B2,B3,B4]; Group2:[C0, C1, C2, A1, A2]; Group3:[D0, D1, B0, D3, D4].

[0066] The fifth shuffling algorithm, shift shuffling, involves hashing the dynamic key to obtain its hash value, determining the shift step size based on the hash value, and shifting the strings corresponding to the elements in the first cipher table to the left or right according to the shift step size, thereby shuffling the elements in the first cipher table.

[0067] In practice, the dynamic key `Key` is hashed and then moduloed to obtain the step value `step`. The entire password table is then cyclically shifted left or right based on the step value. The steps are as follows: Step calculation: Hash the dynamic key string `Key` to obtain a hash value; Hash value modulo: Take the modulo of the resulting hash value (e.g., 10) to obtain the step value; Cyclic shift: Perform a cyclic shift operation (left or right) on the array based on the step value. Example: Original array: [A, B, C, D, E]; step = 2 → Shift left → [C, D, E, A, B].

[0068] The sixth shuffling algorithm, the head-tail shuffling, is as follows: Element pairs are determined from both ends of the first cipher table, and the strings corresponding to the elements contained in the element pairs are mirrored and swapped. New element pairs are then determined from both ends of the first cipher table until a preset condition is met, at which point the mirroring swapping stops, thus shuffling the elements contained in the first cipher table.

[0069] In practice, the two ends of the cipher table are mirrored to create a mirrored rearrangement. The steps are as follows: Swap pairs: Table[i] is swapped with Table[length-1-i]; Central element handling: For arrays of odd length (if any), the central element remains unchanged. Example: Original array: [A, B, C, D, E, F, G, H]; Exchange process: A↔H: [H, B, C, D, E, F, G, A]; B↔G: [H, G, C, D, E, F, B, A]; C↔F: [H, G, F, D, E, C, B, A]; D↔E: [H, G, F, E, D, C, B, A].

[0070] The seventh shuffling algorithm, Reverse Shuffling: Reverses the strings corresponding to the elements in the first cipher table to shuffle the elements in the first cipher table.

[0071] In practice, the entire password table is completely reversed. The steps are as follows: Reversal Execution: Use the reversal function to perform the reversal. Example: Original array: [A, B, C, D] → Reverse → [D, C, B, A].

[0072] The eighth shuffling algorithm, parity shuffling: The first cipher table is split according to the parity of the index of the current element corresponding to the element contained in the first cipher table, resulting in an odd-numbered cipher table and an even-numbered cipher table; the odd-numbered cipher table and the even-numbered cipher table are then recombined according to preset rules to shuffle the elements contained in the first cipher table.

[0073] In practice, the cipher table is split according to the parity of its element indices, and then the odd and even arrays are sorted and merged separately. The steps are as follows: Parity separation: The original cipher table array is divided into two subarrays based on the parity of its indices; Permutation and combination: The arrays are recombined according to a preset rule (odd numbers first / even numbers first). Example: Original array: [A, B, C, D, E, F]; Index Classification: Even Index: [A, C, E] (Index: 0, 2, 4); Odd Index: [B, D, F] (Index: 1, 3, 5) Option A, odd numbers first: [B, D, F, A, C, E]; Option B, even numbers first: [A, C, E, B, D, F].

[0074] (5.4) Concatenate the strings corresponding to the elements in the shuffled first cipher table to obtain the client request signature. The string concatenation process is as follows: Concatenate the 100 elements of the shuffled first cipher table into a complete string in sequence: ConcatString = Table[0] + Table[1]+ ... + Table

[99] Perform a SHA256 hash calculation on the concatenated string ConcatString to generate the final client signature: RequestSign = SHA256(ConcatString). This signature is unique and unpredictable.

[0075] (vi) Client request construction and signature appending: The client constructs an HTTP request and appends the RequestSign signature parameter to the end of the original request QueryString, https: / / {Domain} / {Path} / {Querystring}&RequestSign={RequestSign}. Then, together with relevant Cookie, Header, Body and other information, the request is sent to the server.

[0076] (vii) Client-side code obfuscation: Using professional JavaScript obfuscation tools to perform multi-layered processing and protection on the client-side code logic to reduce code readability, making it difficult for humans to read, understand, and reverse engineer, thereby increasing the cost and difficulty for attackers to crack the code. Examples include replacing meaningful variable names and function names with random character sequences; string encryption / encoding; control flow flattening; inserting invalid code logic; adding invalid function calls, etc.

[0077] (viii) Server-side retrieval of dynamic password rule table: Based on the tenant ID and user ID, the server retrieves the same dynamic key (Key) and encoding rule table (Patch) as the client from the internal backend dynamic password rule management service. To prevent boundary deviations within the time window, the server will simultaneously return the key (Key) and encoding rule table from the previous time window (the number of returned windows is configurable). If the server-side and client signatures do not match, the server will attempt to re-verify the signature using information from the previous time window, thus downgrading and increasing fault tolerance. Additionally, the dynamic keys in the dynamic password rule management service are stored in isolated tenant-level key environments.

[0078] (ix) The server generates 100 random strings (password table) based on the dynamic key Key: It executes the same logic as the client, generating a 32-bit integer seed based on the dynamic key Key. Then, based on the seed, it generates 100 random strings (strings consisting of digits 0-9 and uppercase and lowercase letters a, b, a), which are used as the password table and cached. Similar to the client, the password table becomes unusable after expiration, and the server needs to regenerate it.

[0079] (x) The server hashes the business request data according to the encoding rule table and embeds it into the second cryptographic table. It then performs various shuffling operations on the second cryptographic table according to the shuffling rules to obtain the server-side request signature. This includes obtaining request parameters, performing multiple hash calculations on the request parameters, dynamically updating and reshuffling the cryptographic table, concatenating the signature string, and generating the final server-side request signature. In specific implementation, the server performs the following operations: Obtain request parameters: Extract tenant ID, user ID, request path, request parameter querystring, request body, and client signature RequestSign from the client request.

[0080] Multiple hash calculations are performed on request parameters: SHA1, MD5, or SHA256 hash calculations are performed on the extracted tenant ID, user ID, request path, request parameter Querystring, and request body, respectively. This process is completely consistent with the client. For the request parameter Querystring, the RequestSign parameter and its value are removed before applying the hash algorithm, and then sorted by name (AZ).

[0081] For example: HashTenantID = SHA1(TenantID) HashUserID = SHA1(UserID) HashPath = MD5(Path) HashQuerystring = MD5(Sort(RemoveRequestSign(Querystring))) HashBody = SHA256(Body) Update the second cryptographic table: The server executes the same logic as the client, replacing the corresponding hash string with the corresponding index position in the second cryptographic table based on the second cryptographic table and the encoding rule table.

[0082] For example: Table[Patch[0]] = HashTenantID Table[Patch[1]] = HashUserID Table[Patch[3]] = HashPath Table[Patch[5]] = HashQuerystring Table[Patch[9]] = HashBody Reshuffling the dynamic cipher table: For details, please refer to the shuffling process performed by the client. The updated dynamic cipher table is reshuffled according to the preset cipher table sorting scheme rule. This embodiment of the invention will not elaborate further on this process.

[0083] Generate server request signature: Concatenate all elements in the reshuffled second cipher table into a complete string ConcatString, perform SHA256 hashing, and finally generate the server signature ServerSign.

[0084] ConcatString = Table[0] + Table[1]+ ... + Table

[99] ServerSign =SHA256(ConcatString).

[0085] (xi) The server-side verification of the client-side request signature based on the server-side request signature includes: determining whether the server-side request signature ServerSign and the client-side request signature RequestSign are consistent and whether the remaining validity period is not 0; if either judgment result is negative, a re-signing test is performed based on the dynamic password rule information corresponding to the previous time window, and if either judgment result in the re-signing test is still negative, the verification is deemed to fail; if both judgment results are positive, the verification is deemed to pass.

[0086] In practice, the client's RequestSign is compared with the server's ServerSign. If the signatures match, the verification passes, indicating that the request is valid and the data has not been tampered with. The server accepts the request and submits it for further business processing. Otherwise, the signatures do not match, and a re-signing attempt is performed using the password table and encoding rule table from the previous time window. If they still do not match, it indicates that the request may have been modified, expired, or forged. In this case, the server will reject the request, return a security warning message, and record a security event in the security event log.

[0087] Retrying multiple rounds of signature verification is primarily for fault tolerance and degradation, aiming to improve system continuity and user experience. The number of comparison rounds is configurable, with each round corresponding to different password tables and encoding rule tables within a time window. If the maximum round threshold is reached, the request will be rejected directly. Additionally, if the number of failures within a short period reaches the required security policy threshold, the client IP will be blocked, preventing further requests.

[0088] In summary, the method for secure signature verification of SaaS services provided in this embodiment of the invention includes at least the following key technical points: (1) Dynamic randomized signature mechanism: Unlike traditional fixed-key signature schemes, the signature elements in this embodiment of the invention have a high degree of dynamism and randomness.

[0089] Unpredictability: The dynamic password table and encoding rule table within each time window are dynamically and randomly generated, and attackers cannot predict the generation of future signature requests based on historical data.

[0090] Personalized customization: Each tenant and user can have their own password table and encoding rules to provide different levels of security. For example, whether a shared link is for exclusive use by the user or shared within the same tenant.

[0091] Algorithm uniqueness: The signature algorithm achieves uniqueness through dynamic mapping of multiple hash algorithms with cipher tables and encoding rule tables, as well as random rearrangement of the shuffling algorithm, increasing unpredictability and the difficulty of reverse analysis.

[0092] Double randomization: Combining a dynamic cipher table and a shuffling algorithm, it achieves double protection of content randomness and position randomness.

[0093] (2) Time window fault tolerance mechanism: The mechanism is based on a time window for dynamic password table updates and provides fault-tolerant verification functionality for the previous time window.

[0094] Time synchronization tolerance: Solves the technical challenge of time synchronization between clients and servers in a distributed environment.

[0095] User experience optimization: Avoids the possibility of legitimate requests being mistakenly rejected due to time differences.

[0096] Security Guarantee: Replay attacks are prevented by limiting the number and duration of fault-tolerant windows.

[0097] (3) Multi-layered encryption protection system: Construct a multi-layered security protection system that includes keys, multiple hashing algorithms, and code obfuscation.

[0098] Progressive encryption strength: from transport layer encryption to application layer signature, from client to server, achieving end-to-end security protection.

[0099] Diverse algorithms: Employing multiple hash algorithms such as MD5, SHA1, and SHA256 increases the complexity of algorithm analysis.

[0100] Code protection: Effective protection of client-side signature generation logic is achieved through JavaScript obfuscation techniques, preventing reverse engineering.

[0101] Preventing cross-tenant and cross-user security risks: Different tenants or users can configure independent signature algorithms, keys, password tables, encoding rules and other management policies and security levels to achieve secure isolation between tenants and even between users, effectively preventing the spread of security risks across tenants and users.

[0102] Chaining and nesting: Using a cipher table and an encoding rule table, the request elements are hashed, and these hash values ​​are embedded into the cipher table according to the encoding rules. The table is then reshuffled, and finally, the shuffled cipher tables are concatenated and hashed using SHA256 to generate the final signature. This layered and interlocking approach of multiple algorithms further enhances the security of the signature algorithm, making it difficult for attackers to predict and reproduce the signature generation process.

[0103] The enhanced request signature verification mechanism provided in this invention, based on a dynamic random string password table and encoding rule table (password table filling rules), and a Web secure signature verification scheme using multiple hybrid hash algorithms, aims to improve end-to-end data integrity and security during client-server communication. Its core lies in introducing a dynamic key and encoding rule table, dynamically generated by the server and time-sensitive for a specific tenant / user. After obtaining this information, the client generates a password table based on the dynamic key, then applies multiple hash algorithms to the key parameters of the request to be sent (tenant ID, user ID, request path, query parameters, request body), dynamically embeds the hash results into the password table according to the encoding rules, and reshuffles the result to generate the client request signature. The server then uses the same logic as the client to generate its own request signature and compares the two signatures to ensure data security and integrity, thereby fundamentally improving the security protection capabilities of existing Web secure signature verification.

[0104] This invention constructs a request-centric zero-trust verification system. The proposed request signature verification security mechanism, based on a dynamic password table, encoding rule table, multiple hashing, and multiple shuffling methods, effectively compensates for the static nature and reversibility of traditional signature schemes. Through a series of measures, including server-side distribution of dynamic keys, encoding rule tables, shuffling rules, dynamic index mapping for each request, multi-level hash nesting of request elements, reshuffling, and front-end obfuscation, the security strength of Web requests in request transmission and integrity verification is significantly improved. This greatly enhances the ability to resist forgery, tampering, cracking, and replay attacks. Compared to traditional solutions, this solution is highly practical and innovative, providing more secure and reliable protection. This invention has at least the following characteristics: (1) Enhance anti-tampering capability: By hashing the key elements of the request using multiple algorithms, and combining the password table and the encoding rule table, the hashed elements are integrated into the signature process, so that any minor changes to these contents will cause the server signature verification to fail, thus ensuring the integrity of the data during the request process.

[0105] (2) Resisting replay attacks: The dynamic password table and encoding rule mechanism based on the time window validity period effectively prevents expired requests from being requested again.

[0106] (3) Increase the difficulty of reverse analysis: By obfuscating the code, the client signature generation logic is effectively protected, which increases the difficulty for attackers to reverse analyze the signature generation logic and increases the attack cost for malicious users.

[0107] (4) Enhance key security: Personalized key management and regular update mechanism to reduce the risk of key leakage.

[0108] Based on the foregoing embodiments, this invention provides a SaaS service security verification system under a zero-trust architecture, including a client and a server: The client is used to send login requests to the server; The server is used to verify login requests and, based on the login request and the current time window, return to the client a dynamic key, an encoding rule table, and shuffling rules. The encoding rule table contains multiple elements, and the value corresponding to the subscript index of each element is used to describe the embedding index of the string it is bound to in the password table. The client is also used to generate a first cryptographic table corresponding to the dynamic key, hash the data of the business request according to the encoding rule table and embed it into the first cryptographic table, and perform various different shuffling processes on the first cryptographic table according to the shuffling rules to obtain the client request signature, and send the business request and the client request signature to the server. The server is also used to generate a second cryptographic table corresponding to the dynamic key, hash the data of the business request according to the encoding rules and embed it into the second cryptographic table, and shuffle the second cryptographic table according to various different schemes according to the shuffling rules to obtain the server-side request signature. The server-side request signature is used to verify the client-side request signature, and after the verification is successful, the response result corresponding to the business request is returned to the client.

[0109] The security verification system for SaaS services under a zero-trust architecture provided in this invention introduces a shuffling mechanism into the enhanced request signature verification mechanism. The combination of multiple shuffling algorithms is completely unpredictable, and different combination orders will produce completely different transformation results, thereby hiding the original structure of the password table, greatly increasing the difficulty and cost of cracking by attackers, and improving the security of data during transmission or storage.

[0110] The system provided in this embodiment of the invention has the same implementation principle and technical effects as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the system embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0111] This invention provides an electronic device, specifically, the electronic device includes a processor and a storage device; the storage device stores a computer program, and the computer program, when run by the processor, executes the method described in any of the above embodiments.

[0112] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. The electronic device 100 includes: a processor 80, a memory 81, a bus 82, and a communication interface 83. The processor 80, the communication interface 83, and the memory 81 are connected through the bus 82. The processor 80 is used to execute executable modules, such as computer programs, stored in the memory 81.

[0113] The memory 81 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 83 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc.

[0114] Bus 82 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 8 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0115] The memory 81 is used to store programs. After receiving an execution instruction, the processor 80 executes the program. The method executed by the device for defining the flow process disclosed in any of the foregoing embodiments of the present invention can be applied to the processor 80 or implemented by the processor 80.

[0116] The processor 80 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 80 or by instructions in software form. The processor 80 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 81. The processor 80 reads the information in memory 81 and, in conjunction with its hardware, completes the steps of the above method.

[0117] The computer program product of the readable storage medium provided in the embodiments of the present invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the foregoing method embodiments. For specific implementation, please refer to the foregoing method embodiments, which will not be repeated here.

[0118] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0119] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, 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, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for security verification of SaaS services under a zero-trust architecture, characterized in that, The method is applied to a target system, the target system including a client and a server, and the method includes: The client sends a login request to the server; The server verifies the login request and, based on the login request and the current time window, returns a dynamic key, an encoding rule table, and a shuffling rule to the client. The encoding rule table contains multiple elements, and the value corresponding to the subscript index of each element is used to describe the embedding index of the string it is bound to in the password table. The client generates a first cryptographic table corresponding to the dynamic key, hashes the data of the business request according to the encoding rule table and embeds it into the first cryptographic table, and performs shuffling processing on the first cryptographic table according to the shuffling rule using multiple different schemes to obtain the client request signature, and sends the business request and the client request signature to the server. The server generates a second cryptographic table corresponding to the dynamic key, hashes the data of the business request according to the encoding rules and embeds it into the second cryptographic table, and performs shuffling of the second cryptographic table according to the shuffling rules using various different schemes to obtain the server-side request signature. The server-side request signature is used to verify the client-side request signature, and after successful verification, the server returns the response result corresponding to the business request to the client.

2. The method for security verification of SaaS services under a zero-trust architecture as described in claim 1, characterized in that, The first cipher table is shuffled using various schemes according to the shuffling rules to obtain the client request signature, including: Iterate through the shuffling algorithms included in the shuffling rules; The current shuffling algorithm in the shuffling rules is invoked, and the first password table is shuffled using the current shuffling algorithm; Continue calling the next shuffle algorithm in the shuffle rules, and use the next shuffle algorithm to shuffle the first cipher table after shuffling, until the last shuffle algorithm in the shuffle rules is used to shuffle the cipher table after shuffling; The strings corresponding to the elements in the first cipher table after shuffling are concatenated to obtain the client request signature.

3. The method for security verification of SaaS services under a zero-trust architecture as described in claim 2, characterized in that, The shuffling algorithm includes hash shuffling; Shuffling the first cipher table using the current shuffling algorithm further includes: The strings corresponding to the elements contained in the first password table are hashed to obtain the hash values ​​corresponding to the elements; Based on the hash value corresponding to the element and the index of the current element corresponding to the element, determine the shuffling sorting factor corresponding to the element; According to the shuffling sorting factor, the strings corresponding to the elements are processed in descending or ascending order to achieve the shuffling process of the elements contained in the first password table.

4. The method for security verification of SaaS services under a zero-trust architecture as described in claim 2, characterized in that, The shuffling algorithm includes group shuffling; shuffling the first cipher table using the current shuffling algorithm further includes: The first cipher table is divided into multiple cipher sub-tables; For any of the aforementioned cipher subtables, perform the following operations: determine the dictionary value or shuffle sorting factor of the string corresponding to the element contained in the cipher subtable, and sort the string corresponding to the element within the group according to the dictionary value or the shuffle sorting factor; The sorted cipher sub-tables within the group are reassembled to shuffle the elements contained in the first cipher table.

5. The method for security verification of SaaS services under a zero-trust architecture as described in claim 2, characterized in that, The shuffling algorithm includes cross-group shuffling; Shuffling the first cipher table using the current shuffling algorithm further includes: The first cipher table is divided into multiple cipher sub-tables; For any of the aforementioned cipher subtables, perform the following operations: determine the dictionary value or shuffle sorting factor of the string corresponding to the element contained in the cipher subtable, and sort the string corresponding to the element within the group according to the dictionary value or the shuffle sorting factor; Using fixed or random index mapping, the strings corresponding to the elements contained in the sorted cryptographic subtable within the group are swapped across groups. The cipher sub-tables after cross-group exchange are reassembled to shuffle the elements contained in the first cipher table.

6. The method for security verification of SaaS services under a zero-trust architecture according to claim 2, characterized in that, The shuffling algorithm includes displacement shuffling; Shuffling the first cipher table using the current shuffling algorithm further includes: The dynamic key is hashed to obtain the hash value corresponding to the dynamic key; The displacement step size is determined based on the hash value corresponding to the dynamic key; According to the displacement step size, the strings corresponding to the elements contained in the first password table are shifted to the left or right to achieve the shuffling of the elements contained in the first password table.

7. The method for security verification of SaaS services under a zero-trust architecture as described in claim 2, characterized in that, The shuffling algorithm includes shuffling the first and last digits; shuffling the first cipher table using the current shuffling algorithm further includes: Element pairs are determined from both ends of the first password table, and the strings corresponding to the elements contained in the element pairs are mirrored and swapped. Continue to determine new element pairs from both ends of the first cipher table until the preset conditions are met, at which point the mirror swap stops, thereby shuffling the elements contained in the first cipher table.

8. The method for security verification of SaaS services under a zero-trust architecture as described in claim 2, characterized in that, The shuffling algorithm includes a reverse shuffling; shuffling the first cipher table using the current shuffling algorithm further includes: The strings corresponding to the elements contained in the first password table are reversed, thereby shuffling the elements contained in the first password table.

9. The method for security verification of SaaS services under a zero-trust architecture according to claim 2, characterized in that, The shuffling algorithm includes parity shuffling; shuffling the first cipher table using the current shuffling algorithm further includes: The first cipher table is split according to the parity of the index of the current element corresponding to the element contained in the first cipher table, resulting in an odd cipher table and an even cipher table. The odd-numbered and even-numbered codeword tables are recombined according to preset rules to shuffle the elements contained in the first codeword table.

10. The method for security verification of SaaS services under a zero-trust architecture according to claim 2, characterized in that, The shuffling algorithm includes random shuffling; shuffling the first cipher table using the current shuffling algorithm includes: Generate the current element index based on the dynamic key, and construct the shuffle interval corresponding to the current element index; The index of the element to be swapped is determined using the shuffling interval as a constraint; Swap the string corresponding to the element at the current element index with the string corresponding to the element at the index of the element to be swapped; The current element index is updated, and a new shuffling interval corresponding to the current element index is constructed until the element exchange stops when a preset condition is met, thereby realizing the shuffling process of the elements contained in the first password table.

11. A security verification system for SaaS services under a zero-trust architecture, characterized in that, Including client and server sides: The client is used to send a login request to the server. The server is used to verify the login request and, based on the login request and the current time window, return a dynamic key, an encoding rule table, and a shuffling rule to the client. The encoding rule table contains multiple elements, and the value corresponding to the subscript index of each element is used to describe the embedding index of the string it is bound to in the password table. The client is also configured to generate a first cryptographic table corresponding to the dynamic key, hash the data of the business request according to the encoding rule table and embed it into the first cryptographic table, and perform shuffling processing on the first cryptographic table according to the shuffling rule in multiple different schemes to obtain the client request signature, and send the business request and the client request signature to the server. The server is further configured to generate a second cryptographic table corresponding to the dynamic key, hash the data of the business request according to the encoding rules and embed it into the second cryptographic table, and perform shuffling of the second cryptographic table according to the shuffling rules using various different schemes to obtain a server-side request signature, verify the client-side request signature based on the server-side request signature, and return the response result corresponding to the business request to the client after successful verification.

Images