API security verification method and system based on dynamic algorithm pool and intelligent scheduling

Abstract

The invention discloses an API security verification method and system based on a dynamic algorithm pool and intelligent scheduling, and belongs to the technical field of information security. The method comprises the following steps: automatically generating an encrypted signature algorithm pool containing more than 1000 different implementations through multi-dimensional combination; and establishing a metadata file containing a security level, a performance score and platform support information for each algorithm, when an API request is received, extracting multi-dimensional features of the request in real time, calculating a risk level based on a risk assessment model, matching an algorithm set of the corresponding security level according to the risk level, and obtaining an algorithm set of the corresponding security level. A specific algorithm is selected and distributed to a client in combination with a load balancing strategy, and the client loads a compatible algorithm version according to the platform type of the client to carry out security calculation, so that the dynamic, risk adaptive scheduling and full-platform compatibility of an encryption algorithm are realized, the problems that a fixed algorithm is easy to crack and a security strategy is statically rigid are effectively solved, and the security of the client is improved. And the security of API communication is obviously improved.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and in particular to an API security verification method and system based on dynamic algorithm pools and intelligent scheduling. Background Technology

[0002] With the widespread adoption of internet applications, APIs have become the primary channel for data interaction between applications and servers. API security is directly related to user data security and the integrity of business systems. Currently, mainstream API security verification schemes have the following limitations: First, the fixed encryption algorithm scheme: The client and server use a pre-agreed fixed encryption algorithm, such as AES, RSA, HMAC, etc. The main problem with this scheme is that the algorithm is fixed and unchanging. Once an attacker reverse-engineers and analyzes the algorithm logic and key, all API requests can be forged. In addition, algorithm updates require the release of a new client version, resulting in slow response times.

[0003] Second, dynamic token schemes, such as the OAuth 2.0 protocol, where the server issues time-limited tokens. In this scheme, the token may be intercepted and replayed within its validity period, and it's impossible to verify whether the request originated from a legitimate client environment.

[0004] Third, code obfuscation: This increases the difficulty of reverse engineering by obfuscating the client-side code. However, the obfuscated algorithm remains essentially fixed; once cracked, it remains permanently effective, and a trade-off must be made between obfuscation strength and runtime performance.

[0005] The common core problem with the above solutions is that the encryption algorithms and verification logic are statically fixed and lack dynamic adaptability; security protection cannot continuously evolve; and security policies cannot be dynamically adjusted according to the specific risk level of the request. Therefore, an API security verification solution that can dynamically change, is difficult to crack, and can be intelligently scheduled is needed. Summary of the Invention

[0006] In view of this, the purpose of this invention is to provide an API security verification method and system based on dynamic algorithm pool and intelligent scheduling, so as to solve the technical problems in the prior art where encryption algorithms are fixed and easy to crack, security policies are static and rigid, and cannot adapt to changes in risk.

[0007] According to a first aspect of the present invention, an API security verification method based on dynamic algorithm pool and intelligent scheduling is provided, comprising the following steps: S1: Construct an algorithm pool. Through a combination of multiple dimensions, including hash algorithm, key derivation, message authentication, encoding output, salt policy, and computation order, automatically generate N different implementations of encryption signature algorithms, where N≥1000. For each algorithm, establish a metadata algorithm file archive, including algorithm identifier, security level, performance score, and platform support information, and store it in distributed cloud storage. S2: Assess the risk level of API requests. When an API request is received from a client, extract the multi-dimensional features of the request in real time. The multi-dimensional features include user dimension, device dimension, network dimension, behavior dimension and business dimension. Calculate the risk score of the request based on the multi-dimensional features and the risk assessment model, and map the risk score to risk levels R1, R2, R3, R4 and R5. S3: Algorithms in the algorithm pool are classified into security levels L1, L2, L3, L4, and L5 based on hash algorithm strength, key derivation function strength, message authentication code strength, salt policy complexity, and computation order confusion. S4: Intelligent scheduling of target algorithms. Based on the risk level of API requests, it matches a set of algorithms with corresponding security levels. Within the matched set of algorithms, it schedules the target algorithm using a load balancing strategy. S5: The target algorithm scheduled by S4 is used for API security verification. The client loads the target algorithm version compatible with its own platform and executes the target algorithm version in the isolated sandbox environment for encryption and signature processing. S6: The server uses the same target algorithm to verify the signature, and updates the target algorithm status after successful verification.

[0008] In step S1, the hash algorithm dimension, key derivation dimension, message authentication dimension, encoding output dimension, salt value strategy dimension, and calculation order dimension are used to generate a basic algorithm combination through Cartesian product calculation. An automated code generation engine is used to generate executable algorithm code based on the algorithm template. The generated algorithms are then subjected to automated testing and security auditing, and algorithms that meet the requirements are selected and added to the algorithm pool.

[0009] The user-dimensional features in step S2 include user identity and historical behavior features; the device-dimensional features include device fingerprint and reputation features; the network-dimensional features include network protocol and geographic location features; the behavior-dimensional features include request frequency and operation mode features; and the business-dimensional features include business sensitivity features. A risk assessment model is used to calculate the feature vectors and output a risk score of 0-100, where R1 is extremely low risk with a risk score of 0-20, R2 is low risk with a risk score of 21-40, R3 is medium risk with a risk score of 41-60, R4 is high risk with a risk score of 61-80, and R5 is extremely high risk with a risk score of 81-100.

[0010] In step S4, the mapping relationship between the API request risk level and the algorithm security level is as follows: risk level R1 is mapped to the algorithm set of security levels L1-L2, risk level R2 is mapped to the algorithm set of L2-L3, risk level R3 is mapped to the algorithm set of L3-L4, risk level R4 is mapped to the algorithm set of L4-L5, and risk level R5 is mapped to the algorithm set of L5 and triggers additional security verification.

[0011] Furthermore, the load balancing strategy includes calculating scheduling weights using a load balancing scheduling formula. This formula calculates scheduling weights based on the historical usage frequency, average response time, and time decay factor of the target algorithm. Based on these weights, a weighted random selection method is used to schedule the target algorithm for execution. The load balancing scheduling formula is: Scheduling weight = W1 × (1 / usage frequency) + W2 × (1 / average response time) + W3 × time decay factor; Where: W1 takes a value of 0.4, which is the algorithm usage frequency weight; W2 takes a value of 0.3, which is the algorithm response time weight; W3 takes a value of 0.3, which is the time decay weight; the time decay factor is: e^(-λt), where t is the time since the last use of the target algorithm.

[0012] According to a second aspect of the present invention, an API security verification system based on a dynamic algorithm pool and intelligent scheduling is provided, the system comprising: The algorithm generation and management module is used to automatically generate N different implementations of encryption signature algorithms through a multi-dimensional combination of hash algorithm dimension, key derivation dimension, message authentication dimension, encoding output dimension, salt value strategy dimension, and calculation order dimension, forming an algorithm pool, where N≥1000. Based on hash algorithm strength, key derivation function strength, message authentication code strength, salt value strategy complexity, and calculation order confusion, the algorithms in the algorithm pool are classified into L1, L2, L3, L4, and L5 security levels. Metadata algorithm file archives are established for each algorithm, including algorithm identifier, security level, performance score, and platform support information, and stored in distributed cloud storage. The API request risk assessment module is used to receive API requests from clients, extract multi-dimensional features of the requests in real time, including user dimension, device dimension, network dimension, behavior dimension and business dimension, calculate the risk score of the API request based on the multi-dimensional features and the built-in risk assessment model, and map the risk score to risk levels R1, R2, R3, R4 and R5. The intelligent scheduling module is used to match a set of algorithms with corresponding security levels according to the risk level of the API request, calculate the scheduling weight through the built-in load balancing scheduling formula, and use weighted random selection to schedule the target algorithm from the set of algorithms. The platform adaptation module is used to identify the client platform type and ensure that the target algorithm provided to the client is compatible with its platform type. Sandbox execution module: Used to securely execute target algorithms in an isolated environment; Signature verification module: Used to verify the signature submitted by the client.

[0013] Furthermore, the algorithm generation and management module generates a basic algorithm combination based on the dimensions of hash algorithm, key derivation, message authentication, encoding output, salt value strategy, and calculation order through Cartesian product calculation. It uses an automated code generation engine to generate executable algorithm code based on the algorithm template. It also includes an algorithm quality verification module, which is used to perform automated testing, security auditing, and quality screening on the algorithm code generated by the algorithm generation module, and decides whether to allow the algorithm to be included in the algorithm pool according to the preset comprehensive quality standards.

[0014] Furthermore, the mapping relationship between the API request risk level and the algorithm security level is as follows: risk level R1 is mapped to the algorithm set of security levels L1-L2, risk level R2 is mapped to the algorithm set of L2-L3, risk level R3 is mapped to the algorithm set of L3-L4, risk level R4 is mapped to the algorithm set of L4-L5, and risk level R5 is mapped to the algorithm set of L5 and triggers additional security verification.

[0015] Furthermore, the load balancing scheduling formula calculates the scheduling weight based on the historical usage frequency, average response time, and time decay factor of the target algorithm, and then uses a weighted random selection method to schedule the target algorithm for execution based on the scheduling weight; the load balancing scheduling formula is: Scheduling weight = W1 × (1 / usage frequency) + W2 × (1 / average response time) + W3 × time decay factor; Where: W1 takes a value of 0.4, which is the algorithm usage frequency weight; W2 takes a value of 0.3, which is the algorithm response time weight; W3 takes a value of 0.3, which is the time decay weight; the time decay factor is: e^(-λt), where t is the time since the last use of the target algorithm.

[0016] Compared with the prior art, the present invention has the following beneficial effects: The algorithm pool built using this solution contains more than 1,000 different algorithms for implementing secure API request verification. Even if an attacker cracks the algorithm for a single request, the massive number of variations in the algorithm pool and the dynamic scheduling strategy mean that the crack cannot be used for other requests. Theoretically, all algorithms need to be cracked to completely compromise the system, thus achieving an exponential improvement in security.

[0017] By classifying the target algorithm into security levels and adapting it to the risk levels of API requests, the system can dynamically adjust the security level of the target algorithm based on the real-time risk level of the API request. High-security algorithms are activated for high-risk requests, while high-performance algorithms are activated for low-risk requests, thus achieving an optimal balance between security and performance.

[0018] The algorithm is stored in the cloud, and can be added and updated at any time, continuously enhancing security capabilities without relying on client application releases. Attached Figure Description

[0019] The accompanying drawings, which are included in and form part of this specification, illustrate exemplary embodiments, features, and aspects of this disclosure together with the specification and serve to explain the principles of this disclosure.

[0020] Figure 1 This is a flowchart of the API security verification method based on dynamic algorithm pool and intelligent scheduling disclosed in this invention.

[0021] Figure 2 This is a flowchart of the steps for constructing an algorithm pool as disclosed in this invention.

[0022] Figure 3 This is a flowchart of the intelligent scheduling algorithm for load balancing strategies disclosed in this invention.

[0023] Figure 4 This is a schematic diagram of the API security verification system based on dynamic algorithm pool and intelligent scheduling disclosed in this invention. Detailed Implementation

[0024] The technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are also within the scope of protection of this disclosure.

[0025] Example 1: Please refer to Figure 1 , Figure 2 An API security verification method based on dynamic algorithm pool and intelligent scheduling includes the following steps: S1: Construct an algorithm pool. Through a combination of multiple dimensions, including hash algorithm, key derivation, message authentication, encoding output, salt policy, and computation order, automatically generate N different implementations of encryption signature algorithms, where N≥1000. For each algorithm, establish a metadata algorithm file archive, including algorithm identifier, security level, performance score, and platform support information, and store it in distributed cloud storage. S2: Assess the risk level of API requests. When an API request is received from a client, extract the multi-dimensional features of the request in real time. The multi-dimensional features include user dimension, device dimension, network dimension, behavior dimension and business dimension. Calculate the risk score of the request based on the multi-dimensional features and the risk assessment model, and map the risk score to risk levels R1, R2, R3, R4 and R5. S3: Algorithms in the algorithm pool are classified into security levels L1, L2, L3, L4, and L5 based on hash algorithm strength, key derivation function strength, message authentication code strength, salt policy complexity, and computation order confusion. S4: Intelligent scheduling of target algorithms. Based on the risk level of API requests, it matches a set of algorithms with corresponding security levels. Within the matched set of algorithms, it schedules the target algorithm using a load balancing strategy. S5: The target algorithm scheduled by S4 is used for API security verification. The client loads the target algorithm version compatible with its own platform and executes the target algorithm version in the isolated sandbox environment for encryption and signature processing. S6: The server uses the same target algorithm to verify the signature, and updates the target algorithm status after successful verification.

[0026] In step S1, the hash algorithm dimension, key derivation dimension, message authentication dimension, encoding output dimension, salt value strategy dimension, and calculation order dimension are used to generate a basic algorithm combination through Cartesian product calculation. An automated code generation engine is used to generate executable algorithm code based on the algorithm template. The generated algorithms are then subjected to automated testing and security auditing, and algorithms that meet the requirements are selected and added to the algorithm pool.

[0027] The user-dimensional features in step S2 include user identity and historical behavior features; the device-dimensional features include device fingerprint and reputation features; the network-dimensional features include network protocol and geographic location features; the behavior-dimensional features include request frequency and operation mode features; and the business-dimensional features include business sensitivity features. A risk assessment model is used to calculate the feature vectors and output a risk score of 0-100, where R1 is extremely low risk with a risk score of 0-20, R2 is low risk with a risk score of 21-40, R3 is medium risk with a risk score of 41-60, R4 is high risk with a risk score of 61-80, and R5 is extremely high risk with a risk score of 81-100.

[0028] In step S4, the mapping relationship between the API request risk level and the algorithm security level is as follows: risk level R1 is mapped to the algorithm set of security levels L1-L2, risk level R2 is mapped to the algorithm set of L2-L3, risk level R3 is mapped to the algorithm set of L3-L4, risk level R4 is mapped to the algorithm set of L4-L5, and risk level R5 is mapped to the algorithm set of L5 and triggers additional security verification.

[0029] Furthermore, the load balancing strategy includes calculating scheduling weights using a load balancing scheduling formula. This formula calculates scheduling weights based on the historical usage frequency, average response time, and time decay factor of the target algorithm. Based on these weights, a weighted random selection method is used to schedule the target algorithm for execution. The load balancing scheduling formula is: Scheduling weight = W1 × (1 / usage frequency) + W2 × (1 / average response time) + W3 × time decay factor; Where: W1 takes a value of 0.4, which is the algorithm usage frequency weight; W2 takes a value of 0.3, which is the algorithm response time weight; W3 takes a value of 0.3, which is the time decay weight; the time decay factor is: e^(-λt), where t is the time since the last use of the target algorithm.

[0030] In this embodiment, by combining multiple dimensions—hash algorithm dimension, key derivation dimension, message authentication dimension, encoding output dimension, salt policy dimension, and calculation order dimension—N different implementations of the encryption signature algorithm are automatically generated, where N≥1000. Specifically, the following steps are included: S1.1: Define the basic dimension matrix generated by the algorithm, including: Hash algorithm dimensions: SHA-256, SHA-512, SHA3-256, SHA3-512, BLAKE2b, BLAKE3, SM3; Key derivation dimensions: PBKDF2, Argon2, scrypt, HKDF, bcrypt; Message authentication dimensions: HMAC, CMAC, GMAC, Poly1305; Encoded output dimensions: Base64, Base58, Base32, Hex; Salting strategy dimensions: pre-salt, post-salt, segmented salt, dynamic positional salt, and multi-salt combination; Calculation order dimension: the calculation order of ten permutations and combinations.

[0031] S1.2: Employs an automated code generation engine to automatically generate algorithm variants using templates and rules. Number of algorithms = Hash types × Derivation types × Authentication types × Encoding types × Salt strategy × Calculation order = 7 × 5 × 4 × 4 × 5 × 10 = 28,000 basic combinations.

[0032] S1.3: Perform automated testing and security auditing on the generated algorithms to select N (N≥1000) high-quality algorithms.

[0033] In step S3, algorithms in the algorithm pool are classified into security levels L1, L2, L3, L4, and L5 based on hash algorithm strength, key derivation function strength, message authentication code strength, salt policy complexity, and computation order confusion. The specific quantification and technical classification standards are shown in Table 1 below: Table 1: Security level Core Cryptographic Component Configuration Standards Typical technical parameter examples Expected security objectives L1 Hash: SHA-256, BLAKE2b; Key derivation: None or HKDF (simple); Message authentication: HMAC-SHA256; Salt policy: Fixed-position single salt; Calculation order: Standard order (hash → HMAC). Number of iterations: ≤1000; Salt length: 16 bytes; Output encoding: Base64 / Hex. It defends against common collision attacks and provides basic data integrity and authentication. L2 Hash: SHA-384, SHA3-256; Key derivation: PBKDF2 (medium iteration); Message authentication: HMAC-SHA384; Salt policy: pre-salt or post-salt; Calculation order: 2-3 optional orders. Number of iterations: 1000-5000; Salt length: 16-24 bytes. In addition to L1, protection against key guessing attacks is added. L3 Hash: SHA-512, SHA3-512, SM3; Key derivation: PBKDF2 (high iteration) or scrypt; Message authentication: HMAC-SHA512, CMAC; Salt policy: segmented salt or double salt combination; Calculation order: 3-5 optional orders. Number of iterations: 5000-20000; Salt length: 24-32 bytes; Memory overhead (scrypt): ~16MB. Defend against more sophisticated offline dictionary and rainbow table attacks. L4 Hash: SHA3-512, SM3, BLAKE3; Key derivation: Argon2id (configured anti-parameter); Message authentication: HMAC-SHA3-512, Poly1305; Salt policy: dynamic positional salt or multi-salt mixture; Calculation order: 5-8 non-standard orders. Iteration count / time overhead: adjustable to high intensity; salt length: 32+ bytes; memory overhead (Argon2): ≥64MB. It offers resistance to side-channel attacks and a degree of resistance to quantum analysis, making it suitable for high-value transactions. L5 Hash: Combining two or more L4-level hashes (e.g., SM3+SHA3); Key derivation: Multi-level derivation (e.g., Argon2+scrypt); Message authentication: Multi-factor authentication (e.g., HMAC+CMAC); Salt policy: Dynamic multi-salt + random interference factor; Calculation order: 8-10 highly obfuscated orders. Multi-level iteration, total number of iterations > 50,000; total memory overhead ≥ 128MB; execution time can tolerate hundreds of milliseconds. Maximizing algorithmic uniqueness and inverse complexity aims to combat organized, well-resourced targeted attacks. Classification Basis and Working Principle: Through multi-dimensional quantitative scoring, each algorithm is automatically scored based on the aforementioned dimensions after generation. For example, the weighted sum of "hash strength" score, "derived complexity" score, "salt policy randomness" score, and "computation order obfuscation" score falls within a specific range, corresponding to the corresponding security level. The level thresholds are not completely fixed; the system periodically fine-tunes the minimum parameter requirements for each level, such as the minimum number of iterations, based on discovered attack techniques and advancements in computing power.

[0034] Table 2 below is a parameter table showing the corresponding security levels for "Hash Strength" score, "Derived Complexity" score, "Salt Policy Randomness" score, and "Computation Order Confusion" score. After the algorithm passes automated testing and security auditing, the system will automatically rate it according to the table shown in Table 2. Table 2: Evaluation Dimensions L1 L2 L3 L4 L5 Hash strength 1 2 3 4 5 Key derivation strength 0-1 2 3 4 5 Message verification strength 1 2 3 4 5 Salt strategy complexity 1 2 3 4 5 Calculate order confusion 1 2 3 4 5 Minimum composite score 4-5 6-8 9-12 13-16 17-25 Scoring Explanation: Each dimension is assigned a strength score of 1-5 points based on its specific implementation (such as hash algorithm type, number of derivation iterations, salt policy type, etc.), where 0 points indicates that the feature is not used. The scores of each dimension are added together to obtain a comprehensive score, which determines the final security level.

[0035] In this embodiment, the user-dimensional features in step S2 include user identity and historical behavior features; the device-dimensional features include device fingerprint and reputation features; the network-dimensional features include network protocol and geographic location features; the behavior-dimensional features include request frequency and operation mode features; and the business-dimensional features include business sensitivity features. A risk assessment model is used to calculate the feature vectors, outputting a risk score of 0-100. As a specific embodiment, a weighted linear scoring model is used to identify key features from five dimensions. Feature normalization maps each feature value to the 0-1 range. The total score is calculated by weighting each dimension, and then mapped to risk levels R1-R5. The following explains the features and normalization of the five dimensions: 1. User Trustworthiness Characteristics (U) U = (User Trust Score / 100) × 0.5 + (Account Active Days / 1000) × 0.3 + (Historical Success Rate) × 0.2, where: User Trust Score ∈ [0, 100], Account Active Days ≥ 0, Historical Success Rate ∈ [0, 1], U ∈ [0, 1], and the higher the value, the more trustworthy the user.

[0036] 2. Equipment Safety Features (D) D = (1 - whether jailbroken / ROOT) × 0.4 + (1 - whether emulator is used) × 0.3 + (device stability score / 100) × 0.3, where: whether jailbroken / ROOT ∈ {0,1}, whether emulator is used ∈ {0,1}, device stability score ∈ [0,100], D ∈ [0,1], and the higher the value, the more secure the device is.

[0037] 3. Network Environment Characteristics (N) N = (IP reputation score / 100) × 0.5 + (1 - whether it is a proxy / VPN) × 0.3 + (1 - geolocation anomaly) × 0.2, where: IP reputation score ∈ [0, 100], whether it is a proxy / VPN ∈ {0, 1}, geolocation anomaly ∈ [0, 1], N ∈ [0, 1], and the higher the value, the more secure the network.

[0038] 4. Abnormal Behavioral Characteristics (B) B = min(number of requests in the last minute / 10, 1) × 0.6 + operation time anomaly score × 0.4, where: number of requests in the last minute ≥ 0, operation time anomaly score ∈ [0, 1] (0 represents normal time, 1 represents abnormal time), B ∈ [0, 1], the higher the value, the more abnormal the behavior.

[0039] 5. Business Sensitivity Characteristics (S) S = API preset sensitivity level × 0.5 + min(operation amount / average daily amount per user, 2) × 0.5, where: API preset sensitivity level ∈ {1, 2, 3, 4, 5} normalized to [0, 1], operation amount ≥ 0, S ∈ [0, 2], and the higher the value, the more sensitive the business.

[0040] The risk score is calculated using a weighted linear model, and the formula for calculating the risk score is as follows: Risk score = 100 × [K1 × (1-U) + K2 × (1-D) + K3 × (1-N) + K4 × B + K5 × (S / 2)] Where: K1 is the user dimension weight, with a value of 0.20; K2 is the device dimension weight, with a value of 0.15; K3 is the network dimension weight, with a value of 0.15; K4 is the behavior dimension weight, with a value of 0.25; K5 is the business dimension weight, with a value of 0.25, and satisfies K1+K2+K3+K4+K5=1; where (1-U), (1-D), and (1-N) are used to convert security features into risk features; S / 2 is used to normalize the business sensitivity to [0,1], and the weighted sum of each dimension is multiplied by 100 to obtain a risk score of 0-100.

[0041] As an example, API request risk score calculation: User trust score: 80 Account activity days: 150 Historical success rate: 0.95 Jailbroken / Rooted: 0 Emulator required: 0 Equipment stability rating: 90 IP Reputation Score: 70 Proxy / VPN required: 0 Geographic location anomaly: 0.2 (slight anomaly) Number of requests in the last minute: 3 Operation time anomaly level: 0 (normal working hours) API default sensitivity level: 3 (1-5, 3 is medium). Transaction amount: 2000 Average daily spending per user: 1000 User blacklisted: No The following describes how to calculate the feature values ​​for each dimension: U=(80 / 100)×0.5+(150 / 1000)×0.3+0.95×0.2=0.635 D=(1-0)×0.4+(1-0)×0.3+(90 / 100)×0.3=0.97 N=(70 / 100)×0.5+(1-0)×0.3+(1-0.2)×0.2=0.81 B=min(3 / 10,1)×0.6+0×0.4=0.18 S=(3 / 5)×0.5+min(2000 / 1000,2)×0.5=0.8 The following is the calculation method for the risk score: Risk score = 100 × [0.2 × (1 - 0.635) + 0.15 × (1 - 0.97) + 0.15 × (1 - 0.81) + 0.25 × 0.18 + 0.25 × (0.8 / 2)] = 25.1. By mapping risk level, the risk score is 25.1, which is risk level R2.

[0042] One embodiment of the weighted random selection algorithm for scheduling the target uses a roulette wheel selection method, which includes calculating the sum of weights; generating random numbers; traversing and accumulating weights; and selecting an algorithm. When the accumulated weights exceed the random point for the first time, the current algorithm is selected.

[0043] As an example: Suppose there are three algorithms with scheduling weights of [2.0, 3.0, 5.0], and a total weight of 2.0 + 3.0 + 5.0 = 10.0; generate random numbers in the range [0, 10.0), such as 4.2, and accumulate them as follows: First algorithm: current_weight=2.0, 4.2>2.0, continue; The second algorithm: current_weight = 2.0 + 3.0 = 5.0, 5.0 > 4.2, so the second algorithm is selected.

[0044] Example 2:

[0045] Please refer to Figure 4 This paper provides an API security verification system based on a dynamic algorithm pool and intelligent scheduling. The system includes:

[0046] The algorithm generation and management module is used to automatically generate N different implementations of encryption signature algorithms through a multi-dimensional combination of hash algorithm dimension, key derivation dimension, message authentication dimension, encoding output dimension, salt value strategy dimension, and calculation order dimension, forming an algorithm pool, where N≥1000. Based on hash algorithm strength, key derivation function strength, message authentication code strength, salt value strategy complexity, and calculation order confusion, the algorithms in the algorithm pool are classified into L1, L2, L3, L4, and L5 security levels. Metadata algorithm file archives are established for each algorithm, including algorithm identifier, security level, performance score, and platform support information, and stored in distributed cloud storage. The API request risk assessment module is used to receive API requests from clients, extract multi-dimensional features of the requests in real time, including user dimension, device dimension, network dimension, behavior dimension and business dimension, calculate the risk score of the API request based on the multi-dimensional features and the built-in risk assessment model, and map the risk score to risk levels R1, R2, R3, R4 and R5. The intelligent scheduling module is used to match a set of algorithms with corresponding security levels according to the risk level of the API request, calculate the scheduling weight through the built-in load balancing scheduling formula, and use weighted random selection to schedule the target algorithm from the set of algorithms. The platform adaptation module is used to identify the client platform type and ensure that the target algorithm provided to the client is compatible with its platform type. The platform type includes various forms such as iOS and Android native applications, as well as Web applications and desktop applications. The sandbox execution module is used to securely execute target algorithms in an isolated environment; The signature verification module is used to verify the signature submitted by the client.

[0047] Furthermore, the algorithm generation and management module generates a basic algorithm combination based on the dimensions of hash algorithm, key derivation, message authentication, encoding output, salt value strategy, and calculation order through Cartesian product calculation. It uses an automated code generation engine to generate executable algorithm code based on the algorithm template. It also includes an algorithm quality verification module, which is used to perform automated testing, security auditing, and quality screening on the algorithm code generated by the algorithm generation module, and decides whether to allow the algorithm to be included in the algorithm pool according to the preset comprehensive quality standards.

[0048] Furthermore, the mapping relationship between the API request risk level and the algorithm security level is as follows: risk level R1 is mapped to the algorithm set of security levels L1-L2, risk level R2 is mapped to the algorithm set of L2-L3, risk level R3 is mapped to the algorithm set of L3-L4, risk level R4 is mapped to the algorithm set of L4-L5, and risk level R5 is mapped to the algorithm set of L5 and triggers additional security verification.

[0049] Furthermore, the load balancing scheduling formula calculates the scheduling weight based on the historical usage frequency, average response time, and time decay factor of the target algorithm, and then uses a weighted random selection method to schedule the target algorithm for execution based on the scheduling weight; the load balancing scheduling formula is: Scheduling weight = W1 × (1 / usage frequency) + W2 × (1 / average response time) + W3 × time decay factor; Where: W1 takes a value of 0.4, which is the algorithm usage frequency weight; W2 takes a value of 0.3, which is the algorithm response time weight; W3 takes a value of 0.3, which is the time decay weight; the time decay factor is: e^(-λt), where t is the time since the last use of the target algorithm.

[0050] The risk score calculation involved in the API request risk level assessment, the principle, standard and specific process of dividing algorithm security levels, and the scheduling weight calculation and weighted random selection involved in scheduling the target algorithm through load balancing scheduling strategy are described in detail in the API security verification method based on dynamic algorithm pool and intelligent scheduling in Embodiment 1, and will not be repeated here.

[0051] The parts not described in detail in this technical solution specification are obvious to those skilled in the art and can be supplemented and improved based on existing technical knowledge. At the same time, those skilled in the art should understand that the above embodiments are merely preferred embodiments of the present invention. For those skilled in the art, several improvements and modifications can be made without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. An API security verification method based on dynamic algorithm pool and intelligent scheduling, characterized in that, Includes the following steps: S1: Construct an algorithm pool. Through a combination of multiple dimensions, including hash algorithm, key derivation, message authentication, encoding output, salt policy, and computation order, automatically generate N different implementations of encryption signature algorithms, where N≥1000. For each algorithm, establish a metadata algorithm file archive, including algorithm identifier, security level, performance score, and platform support information, and store it in distributed cloud storage. S2: Assess the risk level of API requests. When an API request is received from a client, extract the multi-dimensional features of the request in real time. The multi-dimensional features include user dimension, device dimension, network dimension, behavior dimension and business dimension. Calculate the risk score of the request based on the multi-dimensional features and the risk assessment model, and map the risk score to risk levels R1, R2, R3, R4 and R5. S3: Algorithms in the algorithm pool are classified into security levels L1, L2, L3, L4, and L5 based on hash algorithm strength, key derivation function strength, message authentication code strength, salt policy complexity, and computation order confusion. S4: Intelligent scheduling of target algorithms. Based on the risk level of API requests, it matches a set of algorithms with corresponding security levels. Within the matched set of algorithms, it schedules the target algorithm using a load balancing strategy. S5: The target algorithm scheduled by S4 is used for API security verification. The client loads the target algorithm version compatible with its own platform and executes the target algorithm version in the isolated sandbox environment for encryption and signature processing. S6: The server uses the same target algorithm to verify the signature, and updates the target algorithm status after successful verification.

2. The API security verification method based on dynamic algorithm pool and intelligent scheduling according to claim 1, characterized in that, In step S1, the hash algorithm dimension, key derivation dimension, message authentication dimension, encoding output dimension, salt value strategy dimension, and calculation order dimension are used to generate a basic algorithm combination through Cartesian product calculation. An automated code generation engine is used to generate executable algorithm code based on the algorithm template. The generated algorithms are then subjected to automated testing and security auditing, and algorithms that meet the requirements are selected and added to the algorithm pool.

3. The API security verification method based on dynamic algorithm pool and intelligent scheduling according to claim 1, characterized in that, The user-dimensional features in step S2 include user identity and historical behavior features; device-dimensional features include device fingerprint and reputation features; network-dimensional features include network protocol and geographic location features; behavior-dimensional features include request frequency and operation mode features; and business-dimensional features include business sensitivity features. A risk assessment model is used to calculate the feature vectors and output a risk score of 0-100, where R1 is extremely low risk with a risk score of 0-20, R2 is low risk with a risk score of 21-40, R3 is medium risk with a risk score of 41-60, R4 is high risk with a risk score of 61-80, and R5 is extremely high risk with a risk score of 81-100.

4. The API security verification method based on dynamic algorithm pool and intelligent scheduling according to claim 3, characterized in that, In step S4, the mapping relationship between API request risk level and algorithm security level is as follows: risk level R1 is mapped to the algorithm set of security levels L1-L2, risk level R2 is mapped to the algorithm set of L2-L3, risk level R3 is mapped to the algorithm set of L3-L4, risk level R4 is mapped to the algorithm set of L4-L5, and risk level R5 is mapped to the algorithm set of L5 and triggers additional security verification.

5. The API security verification method based on dynamic algorithm pool and intelligent scheduling according to claim 1, characterized in that, The load balancing strategy includes calculating the scheduling weight using a load balancing scheduling formula. The load balancing scheduling formula calculates the scheduling weight based on the historical usage frequency, average response time, and time decay factor of the target algorithm. Based on the scheduling weight, a weighted random selection is used to schedule the target algorithm for execution. The load balancing scheduling formula is: Scheduling weight = W1 × (1 / usage frequency) + W2 × (1 / average response time) + W3 × time decay factor; Where: W1 takes a value of 0.4, which is the algorithm usage frequency weight; W2 takes a value of 0.3, which is the algorithm response time weight; W3 takes a value of 0.3, which is the time decay weight; the time decay factor is: e^(-λt), where t is the time since the last use of the target algorithm.

6. An API security verification system based on a dynamic algorithm pool and intelligent scheduling, characterized in that, include: The algorithm generation and management module is used to automatically generate N different implementations of encryption signature algorithms through a multi-dimensional combination of hash algorithm dimension, key derivation dimension, message authentication dimension, encoding output dimension, salt value strategy dimension, and calculation order dimension, forming an algorithm pool, where N≥1000. Based on hash algorithm strength, key derivation function strength, message authentication code strength, salt value strategy complexity, and calculation order confusion, the algorithms in the algorithm pool are classified into L1, L2, L3, L4, and L5 security levels. Metadata algorithm file archives are established for each algorithm, including algorithm identifier, security level, performance score, and platform support information, and stored in distributed cloud storage. The API request risk assessment module is used to receive API requests from clients, extract multi-dimensional features of the requests in real time, including user dimension, device dimension, network dimension, behavior dimension and business dimension, calculate the risk score of the API request based on the multi-dimensional features and the built-in risk assessment model, and map the risk score to risk levels R1, R2, R3, R4 and R5. The intelligent scheduling module is used to match a set of algorithms with corresponding security levels according to the risk level of the API request, calculate the scheduling weight through the built-in load balancing scheduling formula, and use weighted random selection to schedule the target algorithm from the set of algorithms. The platform adaptation module is used to identify the client platform type and ensure that the target algorithm provided to the client is compatible with its platform type. Sandbox execution module: Used to securely execute target algorithms in an isolated environment; Signature verification module: Used to verify the signature submitted by the client.

7. The API security verification system based on dynamic algorithm pool and intelligent scheduling according to claim 6, characterized in that, The algorithm generation and management module generates basic algorithm combinations based on the dimensions of hash algorithm, key derivation, message authentication, encoded output, salt value strategy, and calculation order through Cartesian product calculation. It uses an automated code generation engine to generate executable algorithm code based on algorithm templates. The module also includes an algorithm quality verification module, which performs automated testing, security auditing, and quality screening on the algorithm code generated by the algorithm generation module, and decides whether to allow the algorithm to be included in the algorithm pool based on preset comprehensive quality standards.

8. The API security verification system based on dynamic algorithm pool and intelligent scheduling according to claim 6, characterized in that, The mapping relationship between the API request risk level and the algorithm security level is as follows: risk level R1 is mapped to the algorithm set of security levels L1-L2, risk level R2 is mapped to the algorithm set of L2-L3, risk level R3 is mapped to the algorithm set of L3-L4, risk level R4 is mapped to the algorithm set of L4-L5, and risk level R5 is mapped to the algorithm set of L5 and triggers additional security verification.

9. The API security verification system based on dynamic algorithm pool and intelligent scheduling according to claim 6, characterized in that, The load balancing scheduling formula calculates the scheduling weight based on the historical usage frequency, average response time and time decay factor of the target algorithm, and uses a weighted random selection to schedule the target algorithm for execution based on the scheduling weight. The load balancing scheduling formula is: Scheduling weight = W1 × (1 / usage frequency) + W2 × (1 / average response time) + W3 × time decay factor; Where: W1 takes a value of 0.4, which is the algorithm usage frequency weight; W2 takes a value of 0.3, which is the algorithm response time weight; W3 takes a value of 0.3, which is the time decay weight; the time decay factor is: e^(-λt), where t is the time since the last use of the target algorithm.

Images