API (Application Program Interface) anti-refreshing method, device, system, equipment, medium and product

Abstract

The invention discloses an API (Application Program Interface) anti-refreshing method, device, system, equipment, medium and product. A server calculates a terminal verification score of a user terminal according to a login verification result by responding to a login verification request of the user terminal; when the terminal verification score is greater than a preset score threshold, returning a key material according to a login state of a user terminal, so that the user terminal generates an initial zero-knowledge proof according to the key material, and recursively generates a service communication request according to the initial zero-knowledge proof in subsequent service communication; and in response to the service communication request of the user terminal, verifying the service communication request according to the previous local service communication request, and if the verification is passed, allowing the user terminal to execute the corresponding service logic. By adopting the embodiment of the invention, identity binding and privacy protection of the user terminal can be realized, and higher-level security and privacy can be realized.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to an API anti-scraping method, apparatus, system, device, medium, and product. Background Technology

[0002] Currently, API protection typically employs methods such as IP restrictions, CAPTCHA verification, user behavior analysis, device fingerprinting, or token verification for security protection and anti-fraud measures.

[0003] However, existing API anti-fraud technologies often focus on surface feature recognition and direct protection, making them susceptible to targeted circumvention and prone to misjudgment when distinguishing between normal and malicious users. Summary of the Invention

[0004] The embodiments of the present invention aim to provide an API anti-fraud method, device, system, equipment, medium and product, which can realize the identity binding and privacy protection of user terminals through key materials and zero-knowledge proofs, and can build a lightweight and continuous business request verification mechanism through recursive request chain to achieve a higher level of security and privacy in API anti-fraud scenarios.

[0005] In a first aspect, embodiments of the present invention provide an API anti-fraud method applied to a server, comprising: In response to a login verification request from a user terminal, a terminal verification score for the user terminal is calculated based on the login verification result. When the terminal verification score is greater than a preset score threshold, key materials are returned according to the login status of the user terminal, so that the user terminal can generate an initial zero-knowledge proof based on the key materials, and recursively generate business communication requests based on the initial zero-knowledge proof in subsequent business communications. In response to a service communication request from a user terminal, the service communication request is verified based on the previous local service communication request. If the verification is successful, the user terminal is allowed to execute the corresponding service logic.

[0006] As an improvement to the above scheme, the step of responding to a login verification request from a user terminal and calculating the terminal verification score of the user terminal based on the login verification result includes: In response to the login verification request from the user terminal, perform multi-factor login verification and obtain the current login verification result for each verification factor; Based on the current login verification result and the historical login verification result, calculate the factor verification score for each verification factor; Obtain the dynamic weights of the verification factors; The verification scores of the factors are weighted and summed according to the dynamic weights to obtain the verification score of the user terminal.

[0007] As an improvement to the above scheme, the step of calculating the factor verification score for each verification factor based on the current login verification result and the historical login verification results includes: Based on the current login verification results and historical login verification results, the initial verification score for each verification factor is calculated using the weighted moving average method. Based on the current verification environment, the initial verification score is adjusted to obtain the factor verification score for each verification factor.

[0008] As an improvement to the above scheme, obtaining the dynamic weights of the verification factors includes: Extract the feature vector of each validation factor, input the feature vector into the attention mechanism, and calculate the initial attention weight of each validation factor; An environmental adjustment factor calculated using a genetic algorithm is introduced. The initial attention weights in the current verification environment are adjusted using the environment adjustment factor to obtain dynamic weights.

[0009] As an improvement to the above scheme, the introduction of an environmental adjustment factor calculated using a genetic algorithm includes: A population of environmental factors is randomly generated, and each individual in the population of environmental factors represents a set of environmental factors. A fitness score is generated based on the safety and usability of individuals in the population of the environmental factors. Based on the fitness score, the environmental factor set of the environmental factor population is genetically iterated to generate the optimal individual and obtain the environmental adjustment factor.

[0010] As an improvement to the above scheme, the preset score threshold is calculated based on the dynamic weight of the verification factors and the historical verification success rate of the user terminal.

[0011] As an improvement to the above scheme, when the terminal verification score is greater than a preset score threshold, the key material is returned based on the user terminal's login status, including: When the terminal verification score is greater than a preset score threshold, the login status of the user terminal is obtained; If the login status is known device login or initial registration, a complete key is generated based on the terminal verification score and returned to the user terminal. If the login status is unknown device login, then the historically generated complete key is obtained, the complete key is split into several independent key fragments, and several key fragments are returned to the user terminal.

[0012] As an improvement to the above scheme, the step of generating a complete key based on the terminal verification score and returning the complete key to the user terminal includes: Generate random salts; The first concatenation string is obtained by concatenating the first key, the terminal verification score, and the random salt. A hash function is used to encrypt and compress the first concatenated string to obtain the complete key; The complete key is stored locally and then returned to the user terminal.

[0013] As an improvement to the above scheme, the step of obtaining the historically generated complete key involves splitting the complete key into several independent key fragments and returning several key fragments to the user terminal, including: Based on the current user, obtain the complete key generated by the current user during initial registration or the previous known login; The complete key is split into several independent key fragments using a secret sharing algorithm; Several of the key fragments are returned to the user terminal.

[0014] As an improvement to the above solution, in response to a user terminal's service communication request, the current service communication request is verified based on the previous local service communication request. If the verification passes, the corresponding business logic is executed, including: In response to a service communication request from a user terminal, the system obtains the request identifier, the user's current request sequence number, and the user's current proof from the service communication request; the user's current proof is recursively calculated based on the user's previous proof in the previous service communication request. Based on the previous local business communication request, obtain the previous local request sequence number and the previous local proof; The previous local request sequence number is matched with the current user request sequence number to obtain a first matching result; Based on the request identifier and the previous proof in the previous local business communication request, the current theoretical proof is recursively calculated. The current theoretical proof is matched with the current user proof to obtain a second matching result; When both the first matching result and the second matching result are successful, the verification is considered successful, and the user terminal is allowed to execute the business logic corresponding to the business communication request.

[0015] As an improvement to the above solution, if the service communication request is the first service communication request, then the method for obtaining the previous local service communication request is as follows: Based on the identification information of the user terminal, the sent key material is subjected to derivative encryption to obtain a derived key; Based on the derived key and the random number generated when the user terminal successfully logs in, an initial zero-knowledge proof is generated; The initial zero-knowledge proof is used as the previous local proof, the previous local request sequence number is set to 0, and the previous local business communication request is obtained based on the previous local proof and the previous local request sequence number.

[0016] As an improvement to the above scheme, the step of matching the previous local request sequence number with the current user request sequence number to obtain a first matching result includes: The maximum out-of-order range is set based on the parallel performance of the user terminal; Calculate the sequence number range based on the maximum out-of-order range and the local previous request sequence number; If the user's current request sequence number is within the sequence number range, the first matching result is considered a successful match; otherwise, the first matching result is considered a failed match.

[0017] As an improvement to the above scheme, the recursive computation of the current theoretical proof based on the request identifier and the previous proof in the previous local business communication request includes: The previous proof and the request identifier in the previous local business communication request are concatenated to obtain the second concatenated string; Obtain the derived key generated based on the key material; The theoretical current proof is calculated based on the derived key and the second concatenated string.

[0018] As an improvement to the above scheme, after the verification is considered successful when both the first matching result and the second matching result are successful, and the user terminal is allowed to execute the business logic corresponding to the business communication request, the API anti-fraud method further includes: The previous local business communication request is updated based on the business communication request.

[0019] Secondly, embodiments of the present invention provide an API anti-fraud method applied to a user terminal, comprising: Based on the key material returned by the server after the login verification request is passed, an initial zero-knowledge proof is generated; The initial zero-knowledge proof is used as the user's previous proof, the user's previous request sequence number is set to 0, and the initial user's previous business communication request is obtained based on the user's previous proof and the user's previous request sequence number. In response to the user's business instructions, a request identifier is generated, and a business communication request is recursively generated based on the user's previous business communication request and the request identifier. The business communication request is sent to the server, and when the server verifies the request, the business instruction is executed.

[0020] As an improvement to the above scheme, the step of generating an initial zero-knowledge proof based on the key material returned by the server after the login verification request is passed includes: Obtain the key material returned by the server after the login verification request is successful; When the key material is a complete key, the complete key is derivationally encrypted according to the identification information of the user terminal to obtain a derived key; When the key material is key fragments, each key fragment is derivationally encrypted according to the identification information of the user terminal, and all derivationally encrypted key fragments are integrated to obtain the derived key. An initial zero-knowledge proof is generated based on the derived key and the random number generated upon successful login.

[0021] As an improvement to the above solution, the step of responding to the user's business instruction, generating a request identifier, and recursively generating a business communication request based on the user's previous business communication request and the request identifier includes: The user's previous proof in the user's previous business communication request and the request identifier are concatenated to obtain a third concatenated string; Obtain the derived key generated based on the key material; Calculate the user's current proof based on the derived key and the third concatenated string; The sequence number of the user's previous business communication request is incremented to obtain the user's current request sequence number. A business communication request is generated based on the user's current authentication and the user's current request sequence number.

[0022] As an improvement to the above solution, after the business communication request is sent to the server and the server executes the business instruction upon successful verification, the API anti-fraud method further includes: Update the user's previous business communication request based on the aforementioned business communication request.

[0023] Thirdly, embodiments of the present invention provide an API anti-fraud device for servers, comprising: The terminal verification score calculation module is used to respond to the login verification request of the user terminal and calculate the terminal verification score of the user terminal based on the login verification result. The key material generation module is used to return key material based on the login status of the user terminal when the terminal verification score is greater than a preset score threshold, so that the user terminal generates an initial zero-knowledge proof based on the key material, and recursively generates a business communication request based on the initial zero-knowledge proof in subsequent business communications. The business communication request response module is used to respond to the business communication request of the user terminal, verify the business communication request based on the previous local business communication request, and allow the user terminal to execute the corresponding business logic if the verification is successful.

[0024] Fourthly, embodiments of the present invention provide an API anti-fraud device for user terminals, comprising: The initial zero-knowledge proof generation module is used to generate an initial zero-knowledge proof based on the key material returned by the server after the login verification request is passed. The initial business communication request setting module is used to use the initial zero-knowledge proof as the user's previous proof, set the user's previous request sequence number to 0, and use the user's previous proof and the user's previous request sequence number as the initial user's previous business communication request. The business instruction response module is used to respond to the user's business instruction, generate a request identifier, and recursively generate a business communication request based on the user's previous business communication request and the request identifier. The business instruction execution module is used to send the business communication request to the server, and execute the business instruction when the server verifies the request.

[0025] Fifthly, embodiments of the present invention provide an API anti-fraud system, comprising: Server; and, User terminal.

[0026] In a sixth aspect, embodiments of the present invention provide an API anti-fraud device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor executes the computer program to implement the API anti-fraud method as described above.

[0027] In a seventh aspect, embodiments of the present invention provide a computer-readable storage medium, the computer-readable storage medium including a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to perform the API anti-scraping method as described above.

[0028] Eighthly, embodiments of the present invention provide a computer program product, the computer program product including a computer program or computer instructions, wherein when the computer program or computer instructions are executed by a processor, the API anti-scraping method described above is performed.

[0029] Compared with existing technologies, this invention discloses an API anti-fraud method, apparatus, system, device, medium, and product. The server, in response to a user terminal's login verification request, calculates the user terminal's terminal verification score based on the login verification result. When the terminal verification score exceeds a preset threshold, the server returns key materials based on the user terminal's login status, enabling the user terminal to generate an initial zero-knowledge proof based on the key materials. In subsequent business communications, the server recursively generates business communication requests based on the initial zero-knowledge proof. In response to the user terminal's business communication request, the server verifies the previous business communication request. If the verification passes, the user terminal is allowed to execute the corresponding business logic. Using this invention, user terminal identity binding and privacy protection can be achieved, resulting in a higher level of security and privacy. Attached Figure Description

[0030] Figure 1 This is a flowchart illustrating the steps of an API anti-fraud method applied to a server, provided by an embodiment of the present invention. Figure 2 This is a flowchart illustrating the steps of an API anti-fraud method applied to a user terminal, as provided in an embodiment of the present invention. Figure 3 This is a schematic diagram of the structure of an API anti-scraping device applied to a server, provided by an embodiment of the present invention; Figure 4 This is a schematic diagram of an API anti-scraping device applied to a user terminal, provided by an embodiment of the present invention. Detailed Implementation

[0031] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. 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.

[0032] In the description and claims, it should be understood that the terms "first," "second," etc., used in the description and claims are only for the purpose of distinguishing the description of the same technical features, and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated, nor necessarily the order of description or chronological order. The terms are interchangeable where appropriate. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature.

[0033] In current API security practices, token-based authentication is the most popular and relatively high-performing mainstream solution. This mechanism requires the client to obtain a time-sensitive access token from the server after the initial authentication, and to include this token in the HTTP request header with each subsequent API request. The server verifies the validity and legitimacy of the token to determine whether to allow the request, thereby achieving basic access control and preventing unauthorized access.

[0034] However, in unencrypted HTTP connections, tokens may be transmitted in plaintext over the network, greatly increasing the risk of interception. Once a token is stolen, attackers can impersonate legitimate users to perform malicious operations, creating security vulnerabilities. Furthermore, traditional token verification mechanisms typically use tokens with fixed expiration dates, requiring the acquisition of new tokens after expiration. Managing expiration dates can be inconvenient or overlooked, leading to reduced security.

[0035] Existing anti-fraud technologies, such as token verification mechanisms, often focus on the static verification of surface identity credentials. Attackers can easily circumvent these surface-level protection rules through technical means.

[0036] Based on the above considerations, this invention provides an API anti-fraud method for servers. Please refer to... Figure 1 In this embodiment, the API anti-fraud method is specifically executed through steps S1 to S3: S1. In response to the login verification request from the user terminal, calculate the terminal verification score of the user terminal based on the login verification result; S2. When the terminal verification score is greater than a preset score threshold, key materials are returned according to the login status of the user terminal, so that the user terminal generates an initial zero-knowledge proof based on the key materials, and recursively generates a business communication request based on the initial zero-knowledge proof in subsequent business communications. S3. In response to the user terminal's service communication request, verify the service communication request based on the previous local service communication request. If the verification is successful, allow the user terminal to execute the corresponding service logic.

[0037] An API (Application Programming Interface) is a programmable endpoint for accessing business functions provided by a server. Each interface corresponds to a specific service or operation. The server carries the business logic and is the backend system that processes requests and returns responses. The server is responsible for user authentication, request verification, business execution, and data storage. A user terminal refers to the client device or application that initiates the request. A user terminal can access the server through multiple user identities, and a user can also access the server through multiple user terminals. However, at any given time, generally only one user is allowed to access the server through a single user terminal.

[0038] The user terminal first needs to send a login verification request to the server's API interface so that the server can determine whether the user terminal is online. Once the user terminal is online and logged in on the server, it can directly communicate with the server for continuous business through the API interface without having to log in repeatedly.

[0039] In this embodiment of the invention, the verification score during login verification is used as the initial trust input. The cryptographic proof chain is continuously passed and verified in subsequent requests, enabling the system to have the ability to extend to a continuously trusted session. This replaces the traditional static token mechanism that requires verification of sensitive information in the user token each time.

[0040] When the server receives a login verification request from a user terminal, it will verify the user terminal. Only when the terminal's verification score is greater than a preset score threshold will the server issue key materials to the user terminal, so that the user terminal can use the key materials to generate an initial zero-knowledge proof on its local machine, which will serve as the starting point for all subsequent business requests.

[0041] When a user terminal needs to call any business API of the server, there is no need to log in repeatedly. A new proof can be recursively generated based on the latest zero-knowledge proof stored locally, and then encapsulated together with the current business data and sent to the server's API interface.

[0042] Zero-knowledge proof (ZKP) is a method in cryptography used to prove that a specific statement is true without revealing any information other than the fact that the statement is true. The recursive approach uses the result of a previous proof as part of a subsequent proof, thus forming a chain of proofs that ensures the security and integrity of the entire process.

[0043] It should be noted that the user's identity information is not leaked during the initial zero-knowledge proof and subsequent proof recursion. Even if an attacker accidentally captures the proof information at a certain point in time, it is difficult to predict or forge the proof of the future state due to the lack of the internal logical chain required to deduce the subsequent proof. This significantly inhibits the feasibility of malicious traffic-boosting attacks and replay attacks, demonstrating the depth and foresight of the technical prevention strategy.

[0044] After receiving a business communication request, the server will perform a cryptographic comparison between the new proof in the request and the valid business request proof recorded locally on the server for the user terminal, in order to verify whether the business communication request is legal, continuous and has not been tampered with.

[0045] In this embodiment of the invention, the server does not need to maintain a large session state table, but only needs to store a latest proof for each successfully logged-in user terminal, which greatly reduces decision delay and system load.

[0046] The above scheme achieves user terminal identity binding and privacy protection through key materials and zero-knowledge proofs, and can build a lightweight and continuous business request verification mechanism through recursive request chains to achieve a higher level of security and privacy in API anti-fraud scenarios.

[0047] In a preferred implementation, step S1, in response to the login verification request from the user terminal, calculates the terminal verification score of the user terminal based on the login verification result, and is executed through steps S11-S14: S11. In response to the login verification request from the user terminal, perform multi-factor login verification and obtain the current login verification result of each verification factor; S12. Calculate the factor verification score for each verification factor based on the current login verification result and the historical login verification result; S13. Obtain the dynamic weights of the verification factors; S14. Based on the dynamic weights, the factor verification scores are weighted and summed to obtain the verification score of the user terminal.

[0048] In some preferred embodiments, the multi-factor login verification includes password verification, biometric verification, SMS verification code verification, user question verification, user number / membership level acquisition, number / package acquisition, behavior analysis, user access acquisition, and login frequency acquisition. The multi-factor login verification method is selected based on the specific login verification request from the user terminal.

[0049] For example, if the user terminal is the terminal device where the user logs in for the first time, then password verification, biometric verification, SMS verification code verification, user question verification, user number membership level acquisition, and number package acquisition are performed; if the user terminal is the terminal device where the user logs in again, then behavior analysis, user access acquisition, and login frequency acquisition are performed.

[0050] It should be noted that the dynamic weight reflects the importance coefficient of each verification factor in the scoring process. This coefficient is not fixed, but can be dynamically adjusted according to information such as the real-time risk environment, user behavior patterns, and attack trends, so as to reflect the judgment value of different factors at the current moment.

[0051] In this embodiment of the invention, by acquiring dynamic weights with environmental adaptability, it is possible to quickly focus on the verification features that should be of most concern at present, thereby improving the accuracy of risk identification.

[0052] The above scheme comprehensively considers historical login verification results and dynamic weights to score the current login verification result, thus ensuring security, accuracy, and user experience during the multi-factor authentication process.

[0053] Further, preferably, step S12, calculating the factor verification score for each verification factor based on the current login verification result and the historical login verification result, includes: Based on the current login verification results and historical login verification results, the initial verification score for each verification factor is calculated using the weighted moving average method. Based on the current verification environment, the initial verification score is adjusted to obtain the factor verification score for each verification factor.

[0054] The login verification results for different verification factors vary. For example, the performance factors for password verification include password complexity and number of verifications, while the performance factors for number package acquisition include package duration and package usage rate. Therefore, the methods for converting login verification results with different verification factors into quantitative scores will inevitably differ, but they are all calculated based on the performance factors of the verification factors. The specific calculation formula does not affect the beneficial effects produced by this invention.

[0055] In some preferred embodiments, the initial validation score of the i-th validation factor is represented as: ; in, It is a smoothing factor; This is the quantified score of the current login verification result; Let be the quantified score of the i-th verification factor in the k-th historical login verification result; n is the number of historical login verifications.

[0056] It should be noted that the weighted moving average method can assign higher weights to data from different periods. In the preferred embodiment of the present invention, the current login verification result and the historical login verification result are weighted with different weights. In some more preferred embodiments, the weights of the historical login verification results in different time periods can be set with finer granularity.

[0057] In some preferred embodiments, the factor validation score of the i-th validation factor is expressed as: ; in, This is an adjustment factor related to the current verification environment; j is the index number of the historical login verification.

[0058] Further, preferably, the adjustment factor related to the current verification environment is expressed as: ; in, The risk score for the i-th verification factor in the current session; These are the environmental context parameters associated with the i-th validation factor; This is the normalization function.

[0059] The initial validation score reflects the long-term reliability of the validation factor, but the validation results of the validation factor are also highly dependent on its usage environment. In this embodiment of the invention, the initial validation score is further adjusted by an adjustment factor. The adjustment factor can dynamically correct the current performance of the validation factor, so that the score calculation can reflect both long-term security strategies and adapt to real-time environmental changes, thereby improving the accuracy and robustness of the overall validation results.

[0060] In the above scheme, the historical login verification results of each verification factor are extracted into an initial verification score that can represent the recent steady state level by using a weighted moving average. Then, the initial verification score is adjusted according to the current verification environment, which can more effectively identify potential attack behaviors.

[0061] Preferably, step S13, obtaining the dynamic weights of the verification factors, includes: Extract the feature vector of each validation factor, input the feature vector into the attention mechanism, and calculate the initial attention weight of each validation factor; An environmental adjustment factor calculated using a genetic algorithm is introduced. The initial attention weights in the current verification environment are adjusted using the environment adjustment factor to obtain dynamic weights.

[0062] In this embodiment of the invention, the weights of the model output are obtained by inputting the feature vector into the attention mechanism of the Transformer model. Then through Calculate the initial attention weights for each validation factor.

[0063] Attention mechanism is represented as Where Q is the query matrix; K is the key matrix; and V is the value matrix; The dimension of the key; This refers to the transpose operation of a matrix. The specific techniques for constructing the attention space using eigenvectors will not be elaborated upon here.

[0064] The attention mechanism can analyze the complex interactions between various validation factors and then autonomously focus on the most discriminative validation factor, providing an intelligent and adaptive initial weight basis for subsequent weighted fusion.

[0065] The optimal weight adjustment strategy is a complex multi-objective optimization problem. Genetic algorithms can simulate the evolutionary process of survival of the fittest, efficiently searching for the optimal or near-optimal combination of adjustment factors within a vast strategy space to effectively address the current overall environment. In this embodiment of the invention, a genetic algorithm is used to achieve global weight strategy optimization, automatically finding the optimal weight adjustment strategy under different threat environments, enabling the anti-fraud scheme to continuously evolve.

[0066] In some preferred embodiments, the dynamic weights are represented as: ; in, is the environmental adjustment factor for the i-th verification factor; j is the index number of the historical login verification.

[0067] In the above scheme, the real-time feature association within a single request is processed through an attention mechanism, achieving micro-adaptation; and the global policy parameters under long-term conditions are optimized by using an environment adjustment factor calculated by a genetic algorithm, achieving macro-adaptation; the calculated dynamic weights can not only respond sensitively to the subtle features of a single verification, but also keep up with the ever-evolving external threat environment.

[0068] Furthermore, as a preferred embodiment, the introduction of an environmental adjustment factor calculated using a genetic algorithm includes: A population of environmental factors is randomly generated, and each individual in the population of environmental factors represents a set of environmental factors. A fitness score is generated based on the safety and usability of individuals in the population of the environmental factors. Based on the fitness score, the environmental factor set of the environmental factor population is genetically iterated to generate the optimal individual and obtain the environmental adjustment factor.

[0069] In some preferred embodiments, environmental factor populations are randomly generated. Then, a genetic algorithm is used to iteratively select, crossover, and mutate individuals in the population to select the optimal individuals.

[0070] In the iterative operation, individuals in the population are evaluated using a fitness function, which is expressed as: ; in, This is a preset balance factor; For security; For ease of use.

[0071] Understandably, both security and ease of use are translated into numerical values ​​for computation.

[0072] In some preferred embodiments, security is represented as: ; in, Let be the dynamic weight of the i-th validation factor; Let i be the factor validation score of the i-th validation factor; This represents the number of validation factors currently being validated. The number of factors that can support verification; Let be the correlation coefficient between the i-th validation factor and the j-th validation factor; , and All of these are preset coefficients.

[0073] Ease of use is expressed as: ; in, The average validation time for multi-factor validation; The average operational complexity for multi-factor validation; The failure rate for multi-factor validation; , and All of these are preset coefficients, which can be dynamically adjusted by the genetic algorithm during the optimization process.

[0074] Preferably, security reflects the security performance of the multi-factor verification scheme, calculated by the strength of the verification factors themselves, the number of verification factors, and the independence between verification factors. Usability reflects the user experience and availability of the multi-factor verification scheme, calculated by verification speed, user operation complexity, and failure rate.

[0075] When performing parent selection, roulette wheel selection or tournament selection can be used to select individuals with high fitness for crossover and mutation operations to generate the next generation population.

[0076] For example, the crossover operation uses the Blend crossover operation to generate new individuals. The mutation operation uses the Gaussian mutation operation to introduce diversity.

[0077] The above solution incorporates both security and usability into the fitness score, allowing the optimization process to find the optimal balance between security protection and user experience. This avoids the subjectivity, inefficiency, and difficulty in achieving global optimization inherent in traditional manual parameter tuning. Furthermore, this framework allows for continuous input of new data, enabling environmental adjustment factors to adapt to new threat patterns and changes in user behavior, thus achieving system self-evolution.

[0078] Furthermore, in some preferred embodiments, the user terminal's verification score is represented as: .

[0079] Preferably, the preset score threshold is calculated based on the dynamic weights of the verification factors and the historical verification success rate of the user terminal.

[0080] Login verification is only considered successful when the user terminal's verification score in the login verification process exceeds a preset score threshold, thus allowing the subsequent distribution of key materials. In this embodiment of the invention, the preset score threshold is not fixed; specifically, it is automatically adjusted based on dynamic weights and historical verification success rates.

[0081] In some preferred embodiments, the preset score threshold is expressed as: ; in, Let i be the dynamic weight of the i-th verification factor. Let be the historical validation success rate of the i-th validation factor.

[0082] Understandably, if a user terminal's verification score is lower than a preset threshold, the score can be improved by adding login verification under different verification factors. In other words, high-risk user terminals may require more types of verification operations compared to low-risk user terminals, and their preset threshold may also be higher.

[0083] In the above scheme, the dynamic preset score threshold is deeply embedded with the assessment of the current environmental risks and the measurement of the user's long-term trust, thereby achieving more intelligent and accurate anti-fraud access control.

[0084] In a preferred implementation, in step S2, when the terminal verification score is greater than a preset score threshold, the key material is returned according to the login status of the user terminal. First, step S21 is executed, and then step S22 or S23 is selected to be executed according to the login status: S21. When the terminal verification score is greater than a preset score threshold, obtain the login status of the user terminal; If the login status is known device login or initial registration, then execute step S22: generate a complete key based on the terminal verification score and return the complete key to the user terminal; If the login status is unknown device login, then step S23 is executed to obtain the historically generated complete key, split the complete key into several independent key fragments, and return several key fragments to the user terminal.

[0085] When a user's login status is "Known Device Login" or "Initial Registration," it indicates that the user's terminal is a known trusted terminal or a terminal with initial trust established. This login is conducted in a trusted environment, so a complete key is generated and returned to the user's terminal.

[0086] When a user's login status is "unknown device login," it's possible that the application was uninstalled and reinstalled on that user's terminal, or that a new terminal device was being used. Furthermore, the user has already established a connection with the server, meaning a complete key has been generated. Sending the complete key directly to the user's terminal at this point could lead to account manipulation. In this embodiment of the invention, the existing complete key is split into several independent key fragments, ensuring that a single device or single transmission cannot obtain complete access permissions, fundamentally preventing the complete loss of the key due to theft or leakage on a new device.

[0087] The above scheme strongly links key distribution with login status, realizing a technical solution that implements differentiated key distribution strategies based on risk levels, thus avoiding the security deficiencies caused by a one-size-fits-all approach.

[0088] Further, preferably, step S22, generating a complete key based on the terminal verification score and returning the complete key to the user terminal, includes: Generate random salts; The first concatenation string is obtained by concatenating the first key, the terminal verification score, and the random salt. A hash function is used to encrypt and compress the first concatenated string to obtain the complete key; The complete key is stored locally and then returned to the user terminal.

[0089] The value of the random salt varies depending on the user and session, and its value is randomly generated, which can increase the complexity and security of the hash function and prevent rainbow table attacks.

[0090] The first key is a base key held by the server itself, used to derive the complete key for the user, and is not directly distributed to the user.

[0091] A hash function is a function that takes an input of arbitrary length and produces an output of fixed length through computation. It is characterized by irreversibility and uniqueness. For example, in this embodiment of the invention, the hash function used is SHA-256.

[0092] In some preferred embodiments, the complete key is represented as: ; in, Represents a hash function; This is the server's own primary key; To verify the scores; It is a random salt.

[0093] In the above scheme, a unique complete key is derived from the server's first key through a defined algorithm and dynamic input. This process can be precisely reproduced by the server for verification, but external attackers cannot forge or predict the key due to the lack of the first key and random salt.

[0094] Preferably, step S23, obtaining the historically generated complete key, involves splitting the complete key into several independent key fragments and returning several key fragments to the user terminal, including: Based on the current user, obtain the complete key generated by the current user during initial registration or the previous known login; The complete key is split into several independent key fragments using a secret sharing algorithm; Several of the key fragments are returned to the user terminal.

[0095] Under the secret sharing algorithm mechanism, a single or multiple fragments cannot reveal any information about the original secret. Only when a sufficient number of key fragments are collected can the original secret be securely reconstructed through the algorithm.

[0096] In some preferred embodiments, the complete key K is split into n key fragments using the Shamir secret sharing algorithm. .

[0097] Preferably, the key fragments are sent to the user terminal in stages through multiple communications, and the user terminal is required to perform the verification operation required by the server in each communication.

[0098] In the above scheme, the static complete key is transformed into fragmented access credentials through cryptographic means to realize decentralized control in high-risk scenarios, which significantly improves the security of establishing trust on untrusted devices.

[0099] In a preferred implementation, step S3, in response to a service communication request from a user terminal, verifies the current service communication request based on the previous local service communication request. If the verification passes, the corresponding service logic is executed, as per steps S31-36: S31. In response to a service communication request from a user terminal, obtain the request identifier, the user's current request sequence number, and the user's current proof from the service communication request; the user's current proof is recursively calculated based on the user's previous proof in the previous service communication request. S32. Based on the previous local business communication request, obtain the previous local request sequence number and the previous local proof; S33. Match the previous local request sequence number with the current user request sequence number to obtain a first matching result; S34. Based on the request identifier and the previous proof in the previous local business communication request, recursively calculate the current theoretical proof; S35. Match the current theoretical proof with the current user proof to obtain a second matching result; S36. When both the first matching result and the second matching result are successful, the verification is considered successful, and the user terminal is allowed to execute the business logic corresponding to the business communication request.

[0100] It should be noted that the server side stores the proof in the latest business communication request of the user terminal. Since each proof is recursively generated based on the previous proof on the user terminal side, in this embodiment of the invention, the server side only needs to infer the current proof based on the historical proof stored internally, and thus determine whether there is a risk of data manipulation.

[0101] The previous local business communication request is a request data from the same user terminal that was successfully verified and recorded by the server, and this request is the most recent valid business communication request. By parsing the previous local business communication request, the previous local request sequence number and the previous local proof can be obtained.

[0102] Since the sequence number increases regularly in the recursive calculation, the current request sequence number of the user can be determined by the sequence number of the previous local request to determine whether it meets the rule, so as to perform the first match.

[0103] Preferably, if the first matching result is a matching failure, the verification can be directly determined to be unsuccessful, and the verification failure information can be fed back to the user terminal without performing a subsequent second matching.

[0104] Based on the previously stored local proof and the currently received request identifier, the server can use the same recursive algorithm as the user terminal to simulate and calculate the expected proof value, i.e., the theoretical current proof. Furthermore, the theoretical current proof is then matched a second time with the user's current proof. A successful match means that the proof generated by the client is completely consistent with the expected proof calculated by the server based on historical records and the current request.

[0105] In this embodiment of the invention, the request identifier and sequence number ensure that each business communication request and its proof are unique, preventing replay attacks; and during the request verification process, the user's private key and sensitive information are not transmitted over the network, only the proof result and sequence number are transmitted, protecting user privacy.

[0106] In the above scheme, the server only needs to maintain the latest certificate and serial number to verify the user terminal's business communication requests, without having to save the status information of each user request, thus reducing the complexity of data storage and management.

[0107] Further, preferably, if the service communication request is the first service communication request, then the method for obtaining the previous local service communication request is as follows: Based on the identification information of the user terminal, the sent key material is subjected to derivative encryption to obtain a derived key; Based on the derived key and the random number generated when the user terminal successfully logs in, an initial zero-knowledge proof is generated; The initial zero-knowledge proof is used as the previous local proof, the previous local request sequence number is set to 0, and the previous local business communication request is obtained based on the previous local proof and the previous local request sequence number.

[0108] In some preferred embodiments, the derived key is represented as: ; in, For key materials; This refers to the identification information of the user terminal.

[0109] When the key material is a complete key, K directly uses the complete key; when the key material is key fragments, K obtains the key by integrating the key fragments. Preferably, the identification information includes a user identifier and an application identifier.

[0110] A derived key is a new key obtained through a derivative encryption operation. It originates from the key material issued by the server, but is bound to the user's specific identification information, becoming a cryptographic seed specifically used for the generation of subsequent proofs for that user.

[0111] In some preferred embodiments, the initial zero-knowledge proof is represented as: ; in, For derived keys, A random number generated when a user successfully logs in to their terminal.

[0112] In the above scheme, since there is no actual business communication request when generating the initial zero-knowledge proof, i.e., there is no corresponding request identifier, therefore... By directly using random numbers, the randomness and difficulty in replicating the initial zero-knowledge proof are guaranteed.

[0113] For the initial business communication request, there is no real local previous business communication request. Therefore, the server creates a virtual local previous business communication request record to verify the first real business request sent by the user.

[0114] Preferably, step S33, matching the previous local request sequence number with the current user request sequence number to obtain a first matching result, includes: The maximum out-of-order range is set based on the parallel performance of the user terminal; Calculate the sequence number range based on the maximum out-of-order range and the local previous request sequence number; If the user's current request sequence number is within the sequence number range, the first matching result is considered a successful match; otherwise, the first matching result is considered a failed match.

[0115] The current request sequence number of a user is the sequential position of the user terminal in the request stream as perceived by the user terminal, but the actual arrival order of requests sent in parallel by the user terminal may be different from the sequential position perceived by the server side.

[0116] For example, a user sends business communication requests with current request sequence numbers 20, 21, and 22 in parallel, but the server receives them in the order of 21, 22, and 20. If a simple sequence number increment algorithm is used directly, the request reception will fail.

[0117] In some preferred embodiments, the serial number range is represented as ,in, The sequence number of the previous request on the local machine; This represents the maximum range of disordered values.

[0118] In the above scheme, a maximum out-of-order range is set to avoid the situation where requests fail due to parallel request sending.

[0119] Preferably, step S34, recursively calculating the current theoretical proof based on the request identifier and the previous proof in the previous local service communication request, includes: The previous proof and the request identifier in the previous local business communication request are concatenated to obtain the second concatenated string; Obtain the derived key generated based on the key material; The theoretical current proof is calculated based on the derived key and the second concatenated string.

[0120] In some preferred embodiments, the current theoretical proof is expressed as follows: ; in, For derived keys; This is the proof of the previous one; The request identifier; It is a hash-based message authentication code algorithm.

[0121] In the above scheme, the server actively reconstructs and verifies the cryptographic operations of the user terminal. This process not only verifies the legitimacy of the current request, but also verifies the correctness of the entire request chain from its history to the present. It is difficult for attackers to simulate or maintain such a cryptographic state chain that needs to evolve continuously and correctly.

[0122] Preferably, after performing step S36, the API anti-scraping method further includes: The previous local business communication request is updated based on the business communication request.

[0123] In this embodiment of the invention, during the update process of the previous local business communication request, the current user certificate of the current request is updated to the new previous local certificate, the current user request sequence number of the current request is updated to the new previous local request sequence number, and the relevant information of the current verified request is used to replace or overwrite the previous business communication request record of the user stored locally on the server.

[0124] Traditional session management requires storing a large amount of session data on the server side. In this embodiment of the invention, the server can achieve continuous authentication and replay protection by maintaining a very simple state, which greatly reduces the server load.

[0125] This invention also provides an API anti-fraud method for user terminals. Please refer to [link / reference]. Figure 2 In this embodiment of the invention, the API anti-fraud method is specifically executed through steps P1 to P4: P1. Generate an initial zero-knowledge proof based on the key material returned by the server after the login verification request is passed; P2. Use the initial zero-knowledge proof as the user's previous proof, set the user's previous request sequence number to 0, and obtain the initial user's previous business communication request based on the user's previous proof and the user's previous request sequence number. P3. In response to the user's business instruction, generate a request identifier, and recursively generate a business communication request based on the user's previous business communication request and the request identifier. P4. Send the business communication request to the server. When the server verifies the request, execute the business instruction.

[0126] In the user terminal, after the login verification request is successful, an initial trust is established in the terminal security environment. The initial zero-knowledge proof serves as the root of trust for all subsequent business communication requests. Step P2 creates the initial state of the user's previous business communication request for the chained request mechanism, enabling the user terminal's request chain to be recursively constructed smoothly.

[0127] Whenever a user triggers a business instruction, the user terminal generates a request identifier for that instruction, then calls a pre-agreed recursive function with the server to calculate the new business communication request based on the user's previous business communication request. Once the server successfully verifies the business communication request, it sends data to enable the user terminal to execute the corresponding user instruction.

[0128] In the above scheme, the user terminal can independently construct and maintain a verifiable request chain using key materials, which can form a complete closed loop with the server-side process. Furthermore, the user terminal's long-term secrets are stored locally on the terminal during business communication and will not be repeatedly transmitted in the network, reducing the risk of leakage.

[0129] As a preferred implementation, step P1, generating an initial zero-knowledge proof based on the key material returned by the server after the login verification request is passed, includes: Obtain the key material returned by the server after the login verification request is successful; When the key material is a complete key, the complete key is derivationally encrypted according to the identification information of the user terminal to obtain a derived key; When the key material is key fragments, each key fragment is derivationally encrypted according to the identification information of the user terminal, and all derivationally encrypted key fragments are integrated to obtain the derived key. An initial zero-knowledge proof is generated based on the derived key and the random number generated upon successful login.

[0130] The login verification request sent by the user terminal may be for a known device login or initial registration, or it may be for an unknown device login. When the login status is different, the format of the specific key material returned by the server will be different.

[0131] In this embodiment of the invention, when the key material is a complete key, derivation encryption is performed directly based on the complete key; when the key material is key fragments, protection is added to each fragment to ensure that even if a single fragment is leaked during transmission or storage, an attacker cannot use it directly, and the derived key obtained by integrating all the derivation encryption key fragments has the same function as the derived key derived from the complete key.

[0132] It should be noted that in some preferred embodiments, when the key material is in the form of key fragments, the key fragments are integrated before derivation encryption is performed. The specific derivation encryption logic is agreed upon in advance with the server.

[0133] For example, when the key material is a key fragment, the derived key is represented as: ; in, This is the i-th key fragment after derivation and encryption; This is the preset modulus.

[0134] In the above scheme, the root of trust for all subsequent business communication requests is initialized and constructed, which is a prerequisite for the autonomous and secure operation of the entire terminal-side API anti-fraud logic.

[0135] In a preferred implementation, step P3, responding to the user's service instruction, generates a request identifier and recursively generates service communication requests based on the user's previous service communication request and the request identifier, including: The user's previous proof in the user's previous business communication request and the request identifier are concatenated to obtain a third concatenated string; Obtain the derived key generated based on the key material; Calculate the user's current proof based on the derived key and the third concatenated string; The sequence number of the user's previous business communication request is incremented to obtain the user's current request sequence number. A business communication request is generated based on the user's current authentication and the user's current request sequence number.

[0136] It should be noted that when the server and user terminal are synchronizing, the previous local business communication request stored in the server should correspond completely with the previous user business communication request on the user terminal. That is, the user's previous proof corresponds to the server's previous local proof, and the user's previous request sequence number corresponds to the server's previous local request sequence number.

[0137] Therefore, in order to verify the user's current proof, the generation logic of the user's current proof is consistent with the generation logic of the theoretical current proof in the server, and will not be elaborated here.

[0138] For user terminals, request sequence numbers are maintained based on the request flow. Therefore, the sequentiality of requests can be guaranteed by simply incrementing the sequence number of the user's previous request based on the order of requests in time or logic. Request sequence numbers can effectively defend against replay attacks.

[0139] The above scheme ensures that the recursive construction process of the request chain is stable and reliable.

[0140] In a preferred embodiment, after performing step P4, the API anti-scraping method further includes: Update the user's previous business communication request based on the aforementioned business communication request.

[0141] In this embodiment of the invention, during the update process of the user's previous business communication request, the user's current proof for the current request is updated to the new user's previous proof, and the user's current request sequence number for the current request is updated to the new user's previous request sequence number.

[0142] Preferably, the user terminal can store historical business communication requests; alternatively, it can update the user's previous business communication request directly through an overwrite method.

[0143] The API anti-fraud method provided by this invention uses key materials and zero-knowledge proofs to achieve user terminal identity binding and privacy protection, and can build a lightweight and continuous business request verification mechanism through recursive request chains to achieve a higher level of security and privacy in API anti-fraud scenarios.

[0144] This invention provides an API anti-fraud device for servers. Please refer to [link / reference]. Figure 3 The API anti-fraud device 1 includes a terminal verification score calculation module 11, a key material generation module 12, and a business communication request response module 13, wherein: The terminal verification score calculation module 11 is used to calculate the terminal verification score of the user terminal based on the login verification result in response to the login verification request of the user terminal. The key material generation module 12 is used to return key material according to the login status of the user terminal when the terminal verification score is greater than a preset score threshold, so that the user terminal generates an initial zero-knowledge proof based on the key material, and recursively generates a business communication request based on the initial zero-knowledge proof in subsequent business communications. The business communication request response module 13 is used to respond to the business communication request of the user terminal, verify the business communication request based on the previous local business communication request, and allow the user terminal to execute the corresponding business logic if the verification is successful.

[0145] In a preferred embodiment, the terminal verification score calculation module 11 includes: The login verification result acquisition unit is used to respond to the login verification request from the user terminal, perform multi-factor login verification, and obtain the current login verification result of each verification factor; The factor verification score calculation unit is used to calculate the factor verification score of each verification factor based on the current login verification result and the historical login verification result. A dynamic weight acquisition unit is used to acquire the dynamic weights of the verification factors; The verification score calculation unit is used to perform a weighted summation of the factor verification scores according to the dynamic weights to obtain the verification score of the user terminal.

[0146] Further, preferably, the factor verification score calculation unit is specifically used for: Based on the current login verification results and historical login verification results, the initial verification score for each verification factor is calculated using the weighted moving average method. Based on the current verification environment, the initial verification score is adjusted to obtain the factor verification score for each verification factor.

[0147] Preferably, the dynamic weight acquisition unit is specifically used for: Extract the feature vector of each validation factor, input the feature vector into the attention mechanism, and calculate the initial attention weight of each validation factor; An environmental adjustment factor calculated using a genetic algorithm is introduced. The initial attention weights in the current verification environment are adjusted using the environment adjustment factor to obtain dynamic weights.

[0148] Furthermore, as a preferred embodiment, the introduction of an environmental adjustment factor calculated using a genetic algorithm includes: A population of environmental factors is randomly generated, and each individual in the population of environmental factors represents a set of environmental factors. A fitness score is generated based on the safety and usability of individuals in the population of the environmental factors. Based on the fitness score, the environmental factor set of the environmental factor population is genetically iterated to generate the optimal individual and obtain the environmental adjustment factor.

[0149] Preferably, the preset score threshold is calculated based on the dynamic weights of the verification factors and the historical verification success rate of the user terminal.

[0150] In a preferred embodiment, the key material generation module 12 includes: The login status acquisition unit is used to acquire the login status of the user terminal when the terminal verification score is greater than a preset score threshold. The complete key return unit is used to generate a complete key based on the terminal verification score and return the complete key to the user terminal if the login status is known device login or initial registration. The key fragment return unit is used to obtain the historically generated complete key if the login status is unknown device login, split the complete key into several independent key fragments, and return several key fragments to the user terminal.

[0151] Further, preferably, the complete key return unit is specifically used for: Generate random salts; The first concatenation string is obtained by concatenating the first key, the terminal verification score, and the random salt. A hash function is used to encrypt and compress the first concatenated string to obtain the complete key; The complete key is stored locally and then returned to the user terminal.

[0152] Preferably, the key fragment return unit is specifically used for: Based on the current user, obtain the complete key generated by the current user during initial registration or the previous known login; The complete key is split into several independent key fragments using a secret sharing algorithm; Several of the key fragments are returned to the user terminal.

[0153] In a preferred embodiment, the service communication request and response module 13 is used for: In response to a service communication request from a user terminal, the system obtains the request identifier, the user's current request sequence number, and the user's current proof from the service communication request; the user's current proof is recursively calculated based on the user's previous proof in the previous service communication request. Based on the previous local business communication request, obtain the previous local request sequence number and the previous local proof; The previous local request sequence number is matched with the current user request sequence number to obtain a first matching result; Based on the request identifier and the previous proof in the previous local business communication request, the current theoretical proof is recursively calculated. The current theoretical proof is matched with the current user proof to obtain a second matching result; When both the first matching result and the second matching result are successful, the verification is considered successful, and the user terminal is allowed to execute the business logic corresponding to the business communication request.

[0154] Further, preferably, if the service communication request is the initial service communication request, then the method for obtaining the previous local service communication request is as follows: Based on the identification information of the user terminal, the sent key material is subjected to derivative encryption to obtain a derived key; Based on the derived key and the random number generated when the user terminal successfully logs in, an initial zero-knowledge proof is generated; The initial zero-knowledge proof is used as the previous local proof, the previous local request sequence number is set to 0, and the previous local business communication request is obtained based on the previous local proof and the previous local request sequence number.

[0155] Preferably, the step of matching the previous local request sequence number with the current user request sequence number to obtain a first matching result includes: The maximum out-of-order range is set based on the parallel performance of the user terminal; Calculate the sequence number range based on the maximum out-of-order range and the local previous request sequence number; If the user's current request sequence number is within the sequence number range, the first matching result is considered a successful match; otherwise, the first matching result is considered a failed match.

[0156] Preferably, the step of recursively calculating the current theoretical proof based on the request identifier and the previous proof in the previous local business communication request includes: The previous proof and the request identifier in the previous local business communication request are concatenated to obtain the second concatenated string; Obtain the derived key generated based on the key material; The theoretical current proof is calculated based on the derived key and the second concatenated string.

[0157] Preferably, the service communication request and response module 13 is further configured to: The previous local business communication request is updated based on the business communication request.

[0158] This invention provides an API anti-fraud device for user terminals. Please refer to [link / reference]. Figure 4 The API anti-fraud device 2 includes an initial zero-knowledge proof generation module 21, an initial business communication request setting module 22, a business instruction response module 23, and a business instruction execution module 24, wherein: The initial zero-knowledge proof generation module 21 is used to generate an initial zero-knowledge proof based on the key material returned by the server after the login verification request is passed. The initial business communication request setting module 22 is used to set the initial zero-knowledge proof as the user's previous proof, set the user's previous request sequence number to 0, and use the user's previous proof and the user's previous request sequence number as the initial user's previous business communication request. The business instruction response module 23 is used to respond to the user's business instruction, generate a request identifier, and recursively generate a business communication request based on the user's previous business communication request and the request identifier. The business instruction execution module 24 is used to send the business communication request to the server, and execute the business instruction when the server verifies the request.

[0159] In a preferred embodiment, the initial zero-knowledge proof generation module 21 is specifically used for: Obtain the key material returned by the server after the login verification request is successful; When the key material is a complete key, the complete key is derivationally encrypted according to the identification information of the user terminal to obtain a derived key; When the key material is key fragments, each key fragment is derivationally encrypted according to the identification information of the user terminal, and all derivationally encrypted key fragments are integrated to obtain the derived key. An initial zero-knowledge proof is generated based on the derived key and the random number generated upon successful login.

[0160] In a preferred embodiment, the business instruction response module 23 is specifically used for: The user's previous proof in the user's previous business communication request and the request identifier are concatenated to obtain a third concatenated string; Obtain the derived key generated based on the key material; Calculate the user's current proof based on the derived key and the third concatenated string; The sequence number of the user's previous business communication request is incremented to obtain the user's current request sequence number. A business communication request is generated based on the user's current authentication and the user's current request sequence number.

[0161] In a preferred embodiment, the API anti-scraping device 2 further includes an update module for: Update the user's previous business communication request based on the aforementioned business communication request.

[0162] The API anti-fraud device provided by this invention uses key materials and zero-knowledge proofs to achieve user terminal identity binding and privacy protection, and can build a lightweight and continuous business request verification mechanism through recursive request chains to achieve a higher level of security and privacy in API anti-fraud scenarios.

[0163] This invention also provides an API anti-fraud device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, it implements an API anti-fraud method as described above. The working principles and beneficial effects of the two are one-to-one, so they will not be described in detail here.

[0164] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0165] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. An API fraud prevention method, characterized by, The API anti-brushing method applied to a server comprises: In response to a login verification request of a user terminal, a terminal verification score of the user terminal is calculated according to a login verification result; When the terminal verification score is greater than a preset score threshold, key material is returned according to a login state of the user terminal, so that the user terminal generates initial zero-knowledge proof according to the key material, and recursively generates a business communication request according to the initial zero-knowledge proof in subsequent business communication; In response to a business communication request of a user terminal, the business communication request is verified according to a previous local business communication request, and if the verification is passed, the user terminal is allowed to execute corresponding business logic.

2. The API fraud prevention method of claim 1, wherein, The response to the login verification request of the user terminal, the terminal verification score of the user terminal is calculated according to the login verification result, comprising: In response to a login verification request of a user terminal, multi-factor login verification is performed, and a current login verification result of each verification factor is obtained; According to the current login verification result and the historical login verification result, a factor verification score of each verification factor is calculated; The dynamic weight of the verification factor is obtained; According to the dynamic weight, the factor verification score is weighted and summed to obtain the verification score of the user terminal.

3. The API fraud prevention method of claim 2, wherein, The current login verification result and the historical login verification result are calculated according to the current login verification result and the historical login verification result, and the factor verification score of each verification factor is calculated. According to the current verification environment, the initial verification score is adjusted to obtain the factor verification score of each verification factor. The dynamic weight of the verification factor is obtained, comprising:

4. The API fraud prevention method of claim 2, wherein, Extracting the feature vector of each verification factor, inputting the feature vector into the attention mechanism, and calculating the initial attention weight of each verification factor; An environmental adjustment factor calculated by using a genetic algorithm is introduced; The initial attention weight under the current verification environment is adjusted through the environmental adjustment factor to obtain the dynamic weight. The environmental adjustment factor calculated by using a genetic algorithm is introduced, comprising:

5. The API fraud prevention method of claim 4, wherein, Randomly generating an environmental factor population, and each individual in the environmental factor population represents an environmental factor set; According to the security and ease of use of the individuals in the environmental factor population, an adaptability score is generated; According to the adaptability score, the environmental factor set of the environmental factor population is iteratively generated by genetic algorithm to generate an optimal individual, and an environmental adjustment factor is obtained. The preset score threshold is calculated according to the dynamic weight of the verification factor and the historical verification success rate of the user terminal.

6. The API fraud prevention method of claim 2, wherein, When the terminal verification score is greater than the preset score threshold, the login state of the user terminal is obtained; 7. The API fraud prevention method of claim 1, wherein, If the login state is a known device login or initial registration, a complete key is generated according to the terminal verification score, and the complete key is returned to the user terminal; ​ ​ If the login state is an unknown device login, a complete key generated in history is obtained, the complete key is split into a plurality of independent key fragments, and the plurality of key fragments are returned to the user terminal.

8. The API fraud prevention method of claim 7, wherein, The generating a complete key according to the terminal verification score and returning the complete key to the user terminal comprises: generating a random salt; concatenating a first key of the user terminal, the terminal verification score and the random salt to obtain a first concatenated string; encrypting and compressing the first concatenated string by using a hash function to obtain the complete key; storing the complete key locally and returning the complete key to the user terminal.

9. The API fraud prevention method of claim 7, wherein, The obtaining a complete key generated in history and splitting the complete key into a plurality of independent key fragments and returning the plurality of key fragments to the user terminal comprises: obtaining, according to a current access user, a complete key generated by the current access user at initial registration or at a last known login; splitting the complete key into a plurality of independent key fragments by using a secret sharing algorithm; returning the plurality of key fragments to the user terminal.

10. The API fraud prevention method of claim 1, wherein, The verifying, according to a local previous service communication request, the service communication request in response to the service communication request of the user terminal and allowing the user terminal to execute corresponding business logic if the verification is passed comprises: obtaining a request identifier, a user current request sequence number and a user current proof in the service communication request in response to the service communication request of the user terminal; the user current proof is recursively calculated based on a user previous proof of the user in a previous service communication request; obtaining a local previous request sequence number and a local previous proof according to the local previous service communication request; matching the local previous request sequence number and the user current request sequence number to obtain a first matching result; recursively calculating a theoretical current proof according to the request identifier and the previous proof in the local previous service communication request; matching the theoretical current proof and the user current proof to obtain a second matching result; when the first matching result and the second matching result are both matching success, it is considered that the verification is passed, and the user terminal is allowed to execute the business logic corresponding to the service communication request.

11. The API fraud prevention method of claim 10, wherein, If the service communication request is an initial service communication request, the method for obtaining the local previous service communication request comprises: deriving and encrypting the key material sent according to the identification information of the user terminal to obtain a derived key; generating an initial zero-knowledge proof according to the derived key and a random number generated when the user terminal logs in successfully; taking the initial zero-knowledge proof as the local previous proof, taking the local previous request sequence number as 0, and obtaining the local previous service communication request according to the local previous proof and the local previous request sequence number.

12. The API fraud prevention method of claim 10, wherein, The matching the local previous request sequence number and the user current request sequence number to obtain a first matching result comprises: setting a maximum out-of-order range according to the parallel performance of the user terminal; calculating a sequence number range according to the maximum out-of-order range and the local previous request sequence number; If the current user request sequence number is in the sequence number range, the first matching result is considered as a matching success, otherwise, the first matching result is considered as a matching failure.

13. The API fraud prevention method of claim 10, wherein, The theoretical current proof is recursively calculated according to the request identifier and the previous proof in the local previous business communication request, including: The previous proof in the local previous business communication request and the request identifier are spliced to obtain a second spliced string; A derived key generated based on the key material is obtained; The theoretical current proof is calculated according to the derived key and the second spliced string.

14. The API fraud prevention method of claim 10, wherein, After the first matching result and the second matching result are both considered as matching successes, the API anti-brushing method further includes: The local previous business communication request is updated according to the business communication request.

15. An API fraud prevention method, characterized by, The API anti-brushing method applied to a user terminal includes: An initial zero-knowledge proof is generated according to the key material returned by the server after the login verification request is passed; The initial zero-knowledge proof is taken as a user previous proof, and a user previous request sequence number is set as 0, and an initial user previous business communication request is obtained according to the user previous proof and the user previous request sequence number; A request identifier is generated in response to a user business instruction, and a business communication request is recursively generated according to the user previous business communication request and the request identifier; The business communication request is sent to a server, and when the server passes the verification, the business instruction is executed.

16. The API fraud prevention method of claim 15, wherein, The initial zero-knowledge proof is generated according to the key material returned by the server after the login verification request is passed, including: The key material returned by the server after the login verification request is passed is obtained; When the key material is a complete key, the complete key is derived and encrypted according to the identification information of the user terminal to obtain a derived key; When the key material is a key fragment, all key fragments are derived and encrypted according to the identification information of the user terminal, and all derived and encrypted key fragments are integrated to obtain a derived key; An initial zero-knowledge proof is generated according to the derived key and a random number generated when the login is successful.

17. The API fraud prevention method of claim 15, wherein, The request identifier is generated in response to the user business instruction, and the business communication request is recursively generated according to the user previous business communication request and the request identifier, including: The user previous proof in the user previous business communication request and the request identifier are spliced to obtain a third spliced string; A derived key generated based on the key material is obtained; The user current proof is calculated according to the derived key and the third spliced string; The user previous request sequence number of the user previous business communication request is subjected to a self-increment operation to obtain a user current request sequence number; The business communication request is generated according to the user current proof and the user current request sequence number.

18. The API fraud prevention method of claim 15, wherein, After the business communication request is sent to the server, and when the server passes the verification, the API anti-brushing method further includes: The user previous business communication request is updated according to the business communication request.

19. An API fraud prevention apparatus, comprising: Applied to a server, the API anti-brushing device comprises: A terminal verification score calculation module, configured to calculate a terminal verification score of a user terminal according to a login verification result in response to a login verification request of the user terminal; A key material generation module, configured to return key material according to a login state of the user terminal when the terminal verification score is greater than a preset score threshold, so that the user terminal generates an initial zero-knowledge proof according to the key material, and recursively generates a business communication request according to the initial zero-knowledge proof in subsequent business communication; A business communication request response module, configured to verify the business communication request according to a previous business communication request locally in response to a business communication request of the user terminal, and allow the user terminal to execute corresponding business logic if the verification is passed.

20. An API fraud prevention apparatus, comprising: Applied to a user terminal, the API anti-brushing device comprises: An initial zero-knowledge proof generation module, configured to generate an initial zero-knowledge proof according to the key material returned by the server after passing the login verification request; An initial business communication request setting module, configured to set the initial zero-knowledge proof as a previous user proof, set a previous request sequence number of the user as 0, and generate an initial previous business communication request of the user according to the previous user proof and the previous request sequence number of the user; A business instruction response module, configured to generate a request identifier in response to a business instruction of the user, and recursively generate a business communication request according to the previous business communication request of the user and the request identifier; A business instruction execution module, configured to send the business communication request to the server, and execute the business instruction when the server verifies the business communication request.

21. An API fraud prevention system, comprising: Comprise: A server configured to perform the API anti-brushing method according to any one of claims 1-14; And, A user terminal configured to perform the API anti-brushing method according to any one of claims 15-18.

22. An API fraud prevention device, comprising: The computer readable storage medium comprises a computer program stored therein, wherein the computer program controls the device where the computer readable storage medium is located to perform the API anti-brushing method according to any one of claims 1-14, or the API anti-brushing method according to any one of claims 15-18 when the computer program is running.

23. A computer-readable storage medium, characterized in that, The computer program product comprises computer programs or computer instructions, which are executed by a processor to perform the API anti-brushing method according to any one of claims 1-14, or the API anti-brushing method according to any one of claims 15-18.

24. A computer program product, characterised in that, ​

Images