A Prediction-Driven KMS Key Pre-Distribution and Elastic Scheduling Method

Abstract

The present invention provides a prediction-driven KMS key pre-distribution and elastic scheduling method, including: predicting the KMS key request volume and peak QPS within the next T hours, and outputting the confidence interval of the prediction result; dynamically calculating the size of the KMS pre-distributed key pool according to the prediction result and selecting a suitable key type; securely storing the pre-generated KMS keys in a three-level structure of a hot pool, a warm pool, and a cold pool; realizing priority routing and secure degradation processing of KMS key distribution according to the comparison between the real-time request volume and the prediction result. The present invention significantly improves the response speed of the key service through an intelligent pre-distribution mechanism. There has been a qualitative leap compared with the 215 ms of the traditional real-time generation scheme. This high-speed response ability directly improves the user experience, reduces the waiting time for business processing, and improves the overall operation efficiency of the system, which is particularly important for time-sensitive applications.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud computing security and key management, and particularly to a prediction-driven KMS key pre-allocation and elastic scheduling method. Background Art

[0002] With the increasing demand for data encryption, the Key Management System (KMS) has become a key infrastructure for ensuring information security. However, the current KMS technology faces various challenges, which severely limit its application effect in actual business scenarios. Traditional KMS generally adopts the method of generating keys in real time when dealing with sudden requests. This method has obvious performance bottlenecks, especially in asymmetric encryption algorithms. Taking the RSA 2048-bit key as an example, the single generation process takes more than 100 milliseconds, resulting in the accumulation of request queues and a significant extension of response time in high-concurrency scenarios, directly affecting the operation efficiency of associated business systems.

[0003] In response to the performance issues of real-time generation, the industry has proposed key pre-allocation schemes, but these static pre-allocation strategies still have inherent defects. Existing pre-allocation schemes usually adopt a fixed number of pre-generated key pools and cannot be dynamically adjusted according to changes in business loads. This leads to a double dilemma in resource allocation: during the business trough period, a large number of pre-generated keys are idle, causing resource waste; while during the business peak period, the pre-allocation pool may be quickly exhausted, and the system is forced to degrade to the real-time generation mode, facing performance issues again. In addition, the secure storage of pre-allocated keys also poses a severe challenge. To ensure security, the pre-generated keys must be encrypted for protection. However, large-scale pre-generation not only significantly increases the storage cost but also expands the potential attack surface. If the storage system is invaded, a large amount of key materials may be leaked, bringing serious security risks.

[0004] These technical bottlenecks are particularly prominent in high-concurrency scenarios such as business application upgrades and marketing campaign launches. The system response delay may extend from the millisecond level to the second level, affecting the user experience and increasing business risks. At the same time, in an industry environment with increasingly strict compliance requirements, imperfect key life cycle management also increases compliance risks and makes it difficult to ensure the complete destruction and effective tracking of expired keys. The industry urgently needs a new key management technology solution that can balance performance, cost, and security to meet the multi-dimensional requirements of modern information systems for key services. Summary of the Invention

[0005] To overcome the deficiencies of the prior art, the present invention proposes a prediction-driven KMS key pre-distribution and elastic scheduling method, which deeply embeds the performance prediction results into the management system of the pre-generated key pool, realizing the intelligence of the dynamic scaling strategy; based on the accurate analysis of the load characteristics of different business scenarios, it realizes the dynamic adjustment of the proportion of the pre-generated key algorithm; through the unique key sharding technology and the hot / warm / cold three-level storage structure, while ensuring the security of the keys, it realizes the optimization of the storage cost; a complete set of real-time request routing and security degradation mechanisms are constructed to ensure the stability and reliability of the system under various complex conditions.

[0006] To achieve the above object, the present invention proposes a prediction-driven KMS key pre-distribution and elastic scheduling method, including the following steps:

[0007] Step S1: Predict the KMS key request volume and peak QPS within the next T hours, and output the confidence interval of the prediction result;

[0008] Step S2: Dynamically calculate the size of the KMS pre-distributed key pool according to the prediction result and select a suitable key type;

[0009] Step S3: Securely store the pre-generated KMS keys in a three-level structure of a hot pool, a warm pool, and a cold pool;

[0010] Step S4: According to the comparison between the real-time request volume and the prediction result, realize the priority routing and security degradation processing of the KMS key distribution.

[0011] Further, in step S1, the prediction step uses a Prophet-LightGBM hybrid model for prediction, including:

[0012] Step S11: Perform baseline decomposition on the time series data through Prophet, and output the trend term, seasonal term, and residual term;

[0013] Step S12: Concatenate the decomposed features with the business features into a combined feature vector, where the business features include time features and business features;

[0014] Step S13: Perform residual prediction based on the combined features through LightGBM, through the error propagation formula:

[0015] ;

[0016] where, and respectively represent the lower and upper limits of the confidence interval;

[0017] : Calculate the lower limit of the confidence interval;

[0018] : Calculate the upper limit of the confidence interval;

[0019] Represents the predicted value of the Prophet model;

[0020] Represents the standard deviation of Prophet prediction;

[0021] Represents the half-width of the LightGBM quantile difference;

[0022] Represents the total prediction standard deviation.

[0023] Furthermore, the steps for dynamically calculating the size of the pre-allocated key pool include:

[0024] Step S21: Through the formula:

[0025] ;

[0026] Calculate the size of the pre-allocated key pool, where

[0027] is the predicted key request volume;

[0028] is the safety factor;

[0029] is the minimum pool capacity;

[0030] is the size of the pre-allocated key pool;

[0031] Step S22: Based on the predicted load characteristics, automatically adjust the type ratio of pre-generated keys, including: when the QPS peak is greater than 5000 times per second, generate 80% ECDSA P-256 keys and 20% RSA-2048 keys; when the business label is a financial transaction, generate ECDSA keys that comply with the FIPS 186-5 standard; when the national cryptography compliance requirements are detected, generate SM2 elliptic curve keys.

[0032] Furthermore, the three-level structure security storage steps include:

[0033] Step S31: Configure the hot pool to store the pre-generated keys that will be called in the near future using in-memory storage, and encrypt them using the AES-GCM encryption algorithm;

[0034] Step S32: Configure the warm pool to store the mid-term pre-generated keys using SSD and encrypt them using the SM4 encryption algorithm; and Step S33: Configure the cold pool to store redundant keys using object storage and enable it only when the load is high and the prediction deviation exceeds the threshold.

[0035] Further, the encryption steps include:

[0036] Step S311: Accelerate the hot pool using the AES-NI instruction set, parallelize the processing using the GCM mode of Intel AES-NI, and optimize the key block size to align with the L1 cache line;

[0037] Step S312: Use the SM4-CTR mode for the warm pool, utilize the parallel IO feature of SSD to batch process key blocks, and pre-compute the S-box lookup table and store it in the SSD controller cache.

[0038] Further, it also includes steps for lifecycle management of the pre-allocated KMS keys, including:

[0039] Set the TTL of the key, and when the survival time exceeds the TTL and the key has not been used, automatically destroy the key;

[0040] Adopt the key fragmentation storage technology, split a single key into multiple fragments and store them dispersedly to meet the k-N security threshold, where at least k fragments are required to restore the complete key. The key fragmentation storage adopts a (3,5) threshold scheme, and splits the key K into 5 fragments: K = s1 ⊕ s2 ⊕ s3 ⊕ s4 ⊕ s5.

[0041] Further, the steps to implement KMS key distribution include: Adopt the hot pool priority strategy and preferentially allocate keys from the hot pool; When the keys in the hot pool are exhausted and the actual request volume is lower than the predicted low confidence interval, allocate keys from the warm pool and trigger an asynchronous replenishment pre-generation operation.

[0042] Further, the asynchronous replenishment pre-generation operation adopts a double-buffer queue design, including: Set an active queue for the current service key pool and a preparatory queue for background key generation; When the remaining amount in the active queue is lower than the threshold, switch to the preparatory queue to provide services, and asynchronously trigger the key replenishment of the active queue, using a lock-free circular buffer.

[0043] Further, the steps to implement KMS key distribution also include: When the actual request volume exceeds the predicted high confidence interval, enable the cold pool keys, and at the same time trigger emergency key generation, preferentially using GPU acceleration; And the GPU acceleration adopts the parallelization scheme of CUDA to perform parallel optimization processing on RSA and ECDSA keys respectively.

[0044] Furthermore, the security degradation process includes: when detecting an abnormality in the storage node, automatically marking the affected keys as invalid; dynamically calculating the number of pre-generated keys to be supplemented based on a prediction model; starting the pre-generation process; and excluding the keys marked as invalid from the key distribution process.

[0045] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0046] 1. The present invention provides a prediction-driven KMS key pre-distribution and elastic scheduling method, which significantly improves the response speed of key services through an intelligent pre-distribution mechanism. In typical high-concurrency scenarios such as large-scale start / stop / upgrade of services, the response time of 99% of key requests is controlled within 10 ms, which is a qualitative leap compared with the 215 ms of the traditional real-time generation scheme. This high-speed response ability directly improves the user experience, reduces the waiting time for business processing, and improves the overall operation efficiency of the system, which is particularly important for time-sensitive applications.

[0047] 2. The present invention provides a prediction-driven KMS key pre-distribution and elastic scheduling method. The dynamic pre-distribution strategy intelligently adjusts the size of the pre-generated key pool, reducing its fluctuation range by 42% and increasing the storage resource utilization rate to 91% at the same time. This efficient resource configuration mode effectively solves the common problems of resource waste or shortage in traditional static pre-distribution schemes. The system can adaptively adjust resource allocation according to the predicted business load, ensuring service quality during peak periods and avoiding a large amount of idle resources during low periods, thus reducing the overall operating cost of enterprises.

[0048] 3. The present invention provides a prediction-driven KMS key pre-distribution and elastic scheduling method. The key fragmentation storage technology adopted reduces the single-point leakage risk by 83%. By splitting and dispersing keys in different media, even if a storage node is compromised, attackers cannot obtain the complete key. Combined with an accurate TTL (Time To Live) mechanism, the system achieves zero redundant key residue, ensuring that expired keys are destroyed in a timely manner without leaving security risks. These security measures provide strong protection capabilities for enterprise key management in today's increasingly severe network security environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for the description of the specific embodiments or the prior art. Obviously, the following drawings are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0050] Figure 1It is a schematic diagram of the system architecture of the present invention;

[0051] Figure 2 It is a decision flow chart of key pre-distribution;

[0052] Figure 3 It is a schematic diagram of fragmented storage of keys;

[0053] Figure 4 It is a schematic diagram of the state machine of the security degradation mechanism. Detailed implementation manners

[0054] Next, the technical solution of the present invention will be more clearly and completely elaborated by describing the preferred implementation manners of the present invention in conjunction with the accompanying drawings.

[0055] Term explanation:

[0056] Prophet-LightGBM hybrid model: A hybrid prediction model that combines the Prophet time series prediction model developed by Facebook and the LightGBM gradient boosting framework;

[0057] QPS: Queries Per Second;

[0058] AES-GCM: A mode of the Advanced Encryption Standard;

[0059] RSA: An asymmetric encryption algorithm;

[0060] ECDSA: Elliptic Curve Digital Signature Algorithm;

[0061] SM2 / SM4: Cryptographic algorithm standards;

[0062] TTL: Time To Live, referring to the length of time that data exists in the system;

[0063] AES-NI: An instruction set specifically used to accelerate AES encryption;

[0064] Fragmented storage of keys: A technology that divides a key into multiple parts and stores them dispersedly. Only by obtaining a sufficient number of fragments can the complete key be restored;

[0065] k-N security threshold: In the fragmented storage of keys, N represents the total number of fragments, and k represents the minimum number of fragments required to restore the key;

[0066] Threshold scheme: Such as the (3,5) threshold scheme in the text, indicating that the key is divided into 5 pieces, and any 3 of them can be used to restore it;

[0067] Information entropy: A measure of the uncertainty of information. The single-point leakage information entropy being 0 means that no useful information can be obtained from a single leakage point;

[0068] Miller-Rabin test: A probabilistic prime number test algorithm used for prime number verification in RSA key generation.

[0069] CUDA: A parallel computing platform and programming model developed by NVIDIA for GPU-accelerated computing;

[0070] P99 latency: A performance metric of system response time, indicating that 99% of requests can be responded within this time.

[0071] Hot pool / Warm pool / Cold pool: A three-level storage structure classified according to access frequency and response speed requirements;

[0072] Pre-allocation strategy: A method of generating and reserving keys in advance to improve system response speed.

[0073] As a specific implementation, the present invention proposes a prediction-driven KMS key pre-allocation and elastic scheduling method. As Figure 1 shown, the present invention predicts the key request volume and peak QPS within the next T hours through a performance prediction module, dynamically adjusts the size and type of the pre-allocated key pool based on the prediction results, stores keys securely and efficiently using a three-level storage architecture, and realizes intelligent routing and security degradation according to the actual request situation, thereby solving the performance bottleneck problem of existing KMS systems in high-concurrency scenarios.

[0074] The performance prediction module of the present invention uses a Prophet-LightGBM hybrid model for prediction. The model first performs baseline decomposition on time series data through Prophet, and outputs a trend term Tt, a seasonal term St, and a residual term Rt. The Prophet model is developed by Facebook and can handle factors such as trend changes, seasonality, and holidays in time series well. Subsequently, the decomposed features are concatenated with business features into a combined feature vector, where the business features include time features and business features. The time features include hour-granularity cycle encoding (sin / cos transformation), week ordinal number, and holiday flag bit; the business features include the timestamp of business upgrade events (one-hot encoding) and the real-time concurrency of the API gateway (sliding window mean). Finally, LightGBM performs residual prediction based on the combined features to obtain the final predicted value Q pred = T t + S t + LightGBM(R t ). LightGBM is an efficient gradient boosting framework with the advantages of fast training speed and less memory occupancy, and has strong processing ability for large-scale data. Combining Prophet and LightGBM gives full play to the advantages of Prophet in processing time series features and the strengths of LightGBM in model training efficiency and prediction accuracy.

[0075] The performance prediction module also calculates the confidence interval of the prediction result through the error propagation formula, and the formula is ;

[0076] Among them, and represent the lower limit and upper limit of the confidence interval respectively;

[0077] : Calculate the lower limit of the confidence interval;

[0078] : Calculate the upper limit of the confidence interval;

[0079] represents the predicted value of the Prophet model;

[0080] represents the standard deviation of Prophet prediction;

[0081] represents the half-width of the quantile difference of LightGBM;

[0082] represents the total prediction standard deviation. The confidence interval generation method includes: Prophet uses Monte Carlo simulation to generate the basic confidence interval, performs quantile regression on LightGBM (quantile = 0.05 and 0.95), and finally calculates the confidence interval through the error propagation formula. The confidence interval reflects the uncertainty of the prediction result, and the system can adjust the pre-allocation strategy according to the size of the confidence interval to cope with possible deviations.

[0083] Based on the output result of the performance prediction module, as Figure 2 shown, the pre-allocation strategy generation module dynamically calculates the size of the pre-allocated key pool and selects a suitable key type. The dynamic pool size calculation uses the formula:

[0084] ;

[0085] Calculate the size of the pre-allocated key pool, where

[0086] is the predicted key request volume;

[0087] is the safety factor, with a default value of 0.2;

[0088] is the minimum pool capacity;

[0089] is the size of the pre-allocated key pool. The role of the safety factor α is to add a certain margin to the predicted value to cope with prediction errors and sudden business growth. The determination of the α value is based on historical data analysis. When α = 0.1, the resource utilization rate is 92%, the request satisfaction rate is 96.3%, and the timeout rate is 3.7%; when α = 0.2, the resource utilization rate is 85%, the request satisfaction rate is 99.1%, and the timeout rate is 0.4%; when α = 0.3, the resource utilization rate is 79%, the request satisfaction rate is 99.6%, and the timeout rate is 0.1%. Through Pareto optimal analysis, α = 0.2 is selected to achieve the best balance with a satisfaction rate > 99% and a utilization rate > 85%. The minimum pool capacity Nmin is set to prevent the number of pre-generated keys from being too small due to too low a predicted value in the case of low load, resulting in the system being unable to work properly.

[0090] The key type selection is based on the predicted load characteristics and business tags, and automatically adjusts the type ratio of pre-generated keys. Different key types have differences in generation speed, security, and applicable scenarios. For example, RSA keys have high security but long generation times (e.g., RSA 2048 key generation takes > 100 ms); while ECDSA keys have fast generation speeds (generation time 5 ms) and are suitable for high-concurrency scenarios. The decision tree rules based on the QPS threshold and business tags are as follows: when the QPS peak is greater than 5000 times per second, generate 80% ECDSA P-256 keys (generation time 5 ms) and 20% RSA-2048 keys (generation time 120 ms); when the business tag is a financial transaction, generate ECDSA keys that meet the FIPS 186-5 standard; when the national cryptography compliance requirements are detected, generate SM2 elliptic curve keys (certified by the national cryptography bureau).

[0091] A three-level structure is adopted for key security storage, including a hot pool, a warm pool, and a cold pool. The hot pool uses memory as the storage medium to store pre-generated keys that will be called within the next 2 hours, and uses the AES-GCM encryption algorithm for encryption. The key access latency in the hot pool is less than 1 ms. The warm pool uses solid-state drives (SSDs) to store pre-generated keys for the next 2 - 12 hours and uses the national cryptography SM4 encryption algorithm for encryption. The key access latency in the warm pool is less than 10 ms. The cold pool uses object storage to store redundant keys and is only enabled when the load is high and the prediction deviation exceeds the threshold. The key access latency in the cold pool is less than 100 ms.

[0092] Encryption optimization measures are also adopted to improve encryption efficiency. The memory hot pool uses the AES-NI instruction set for acceleration, parallelizes the processing using the GCM mode of Intel AES-NI, and optimizes the key block size to be 64KB aligned (matching the L1 cache line). The test data shows that for a 4KB data block, traditional encryption takes 0.8ms, while it only takes 0.12ms after AES-NI optimization; for a 64KB data block, traditional encryption takes 12.4ms, while it only takes 1.05ms after AES-NI optimization. The SSD warm pool uses the SM4-CTR mode, utilizes the parallel IO characteristics of the SSD, processes 512 key blocks / request in batches, and pre-computes the S-box lookup table and stores it in the SSD controller cache.

[0093] Lifecycle management is performed on the pre-allocated KMS keys, including TTL setting and automatic destruction, and fragmented key storage. Set the TTL (time to live) for the pre-allocated keys. TTL refers to the time interval from key pre-generation to automatic destruction. When the lifetime of a key exceeds the TTL and it has not been used, the system will automatically destroy it and release the corresponding storage resources. As Figure 3 shown, fragmented key storage adopts a (3,5) threshold scheme, which divides the key K into 5 fragments: K = s1 ⊕ s2 ⊕ s3 ⊕ s4 ⊕ s5. Any 3 or more fragments can restore K, and the information entropy of single-point leakage is 0. The fragmented key storage technology splits a single key into multiple fragments for decentralized storage, meeting the k-N security threshold, that is, only when at least k fragments are obtained can the complete key be restored. This method increases the security of the key. Even if a storage node is leaked, the attacker cannot obtain the complete key. The system meets the k-N security threshold. For example, 2 fragments are required to restore the key among 3-5 fragments.

[0094] The elastic scheduling module realizes the priority routing and security degradation processing of KMS key distribution according to the comparison between the real-time request volume and the prediction result. The real-time request routing adopts the hot pool priority strategy, and preferentially allocates keys from the hot pool because the keys in the hot pool are stored in memory and have the fastest access speed, enabling low-latency key distribution. When the keys in the hot pool are exhausted and the actual request volume is not greater than the predicted low confidence interval, keys are allocated from the warm pool, and an asynchronous replenishment pre-generation operation is triggered. The asynchronous replenishment pre-generation adopts a double-buffer queue design to prevent contention, sets an active queue (Queue_A) for the current service key pool and a reserve queue (Queue_B) for the background generation queue. When the remaining amount in Queue_A is less than 30%, switch to Queue_B to provide services, and asynchronously trigger the key replenishment of Queue_A, and use a lock-free circular buffer to improve the concurrency performance.

[0095] When the actual request volume is greater than the predicted high confidence interval, the cold pool key is enabled, and at the same time, emergency key generation is triggered, with GPU acceleration given priority. The GPU emergency generation algorithm is implemented based on the parallelization scheme of CUDA. For RSA key generation optimization, the parallelization implementation of the Miller-Rabin test is used (each CUDA core processes different candidate prime numbers), and modular exponentiation is accelerated through shared memory; for ECDSA optimization, look-up tables for pre-computing elliptic curve base point multiplication are used on the GPU, and the NVIDIA cuRAND library is used to accelerate random number generation. Performance comparison shows that when using a Xeon CPU, 82 keys can be generated per second, while when using an A100 GPU, 1056 keys can be generated per second.

[0096] The security degradation mechanism is used to handle abnormal situations of storage nodes. When an abnormality in a storage node is detected (such as disk failure, network interruption, etc.), the system will automatically mark the affected keys as invalid, dynamically calculate the number of pre-generated keys to be supplemented based on the prediction model, start the pre-generation process, and exclude the marked invalid keys from the key distribution process to avoid using unavailable keys.

[0097] The present invention has significant advantages compared with traditional solutions. In terms of storage security and cost, the single-point leakage risk of the full-memory storage solution is 100%, and the storage cost is 482,000 yuan per month, while the single-point leakage risk of the three-level fragmented storage solution of the present invention is reduced to 17%, and the storage cost is only 154,000 yuan per month. Under concurrent requests of a large number of business applications, the average response time of the traditional solution is 214 ms, the P99 latency is 1852 ms, and the key generation failure rate is 3.7%; while the average response time of the present invention is only 9.6 ms, the P99 latency is 28 ms, and the key generation failure rate is reduced to 0.05%. Through actual testing, compared with the fixed pool solution, the resource consumption of the present invention is reduced by 57%, and the key generation time is significantly reduced from 102 ms of static RSA pre-generation to 8.2 ms.

[0098] As Figure 4 shown, this mechanism realizes adaptive service level adjustment according to resource usage and external conditions.

[0099] The system initially is in the initial state and immediately enters the Normal (normal) state after startup. In the normal state, the system provides full-function services, and all user requests are processed normally without restrictions on key distribution. When it is monitored that the resource utilization rate of the system key pool reaches 80% saturation, the system automatically switches from the Normal state to the HotActive (hot active) state. In the HotActive state, the system begins to take measures to control resource consumption, but still maintains the ability to respond to all user requests.

[0100] When the resource saturation of the key pool further drops to 20% in the HotActive state, the system enters the WarmStandby state. At this time, the system enters the resource protection mode and begins to implement traffic limiting measures for non-critical service requests. If the utilization rate of the warm pool exceeds 90% or the replenishment of the warm pool is not completed, the system switches to the WarmBackup state, which is a composite state containing multiple sub-states.

[0101] In the WarmBackup state, the system processes through two parallel paths: on the one hand, it starts the AsyncGen (asynchronous generation) mechanism to reserve the URL layer keys to ensure the resources required for critical services; on the other hand, it triggers the RaiseLimit operation to issue a non-zero warning for network limits, reminding the administrator of the tight state of system resources. At this stage, the system ensures the continuity of core services by restricting non-priority requests.

[0102] When the system detects emergency situations such as DoS attacks or storage failures, regardless of the state it is in, it will directly switch to the ColdEmergency state. In this state, the system activates the VIPOnly mode, provides services only for VIP users, and implements strict resource allocation policies. The ColdEmergency state includes two key operations: the VIPOnly [switch to VIP priority] mechanism to ensure the service quality of high-value users; and the ColdBackup [all key degradation] operation to degrade all key services to save system resources to the greatest extent.

[0103] This state machine design implements a smooth degradation strategy for the system in the face of different loads and security threats. Through a multi-level guarantee mechanism, it ensures the availability of critical services under extreme conditions, while maximizing the resource utilization efficiency. This mechanism is particularly suitable for key management systems that require high reliability and security, providing an effective framework for the elastic scheduling of the system.

[0104] The prediction-driven KMS key pre-allocation and elastic scheduling method realizes the intelligent allocation and dynamic scheduling of key resources through the deep integration of prediction algorithms and key management, improves the performance and security reliability of the KMS system in high-concurrency scenarios, and provides an efficient and stable key management service for various business applications.

[0105] The above specific implementation manners only describe the preferred implementation manners of the present invention, rather than limiting the protection scope of the present invention. Without departing from the design concept and spirit scope of the present invention, various deformations, substitutions, and improvements made by those of ordinary skill in the art to the technical solutions of the present invention based on the written description and drawings provided by the present invention shall all fall within the protection scope of the present invention. The protection scope of the present invention is determined by the claims.

Claims

1. A prediction-driven KMS key pre-distribution and elastic scheduling method, characterized in that It includes the following steps: Step S1: Predict the KMS key request volume and peak QPS within the next T hours, and output the confidence interval of the prediction result; The prediction step uses a Prophet-LightGBM hybrid model for prediction, including: Step S11: Perform baseline decomposition on the time series data through Prophet, and output the trend term, seasonal term, and residual term; Step S12: Concatenate the decomposed features with the business features into a combined feature vector, where the decomposed features are the trend term, seasonal term, and residual term output in Step S11; the business features include time features and business features; Step S13: Perform residual prediction based on the combined features through LightGBM, using the error propagation formula: ； wherein, and respectively represent the lower limit and the upper limit of the confidence interval; : Calculate the lower limit of the confidence interval; : Calculate the upper limit of the confidence interval; Indicates the predicted value of the Prophet model; Indicates the standard deviation of Prophet prediction; Denote the half-width of the LightGBM quantile difference; Indicates the total predicted standard deviation; Step S2: Dynamically calculate the size of the KMS pre-allocated key pool according to the prediction result and select a suitable key type; the step of dynamically calculating the size of the pre-allocated key pool includes: Step S21: Through the formula: ； Calculate the size of the pre-allocated key pool, where is the predicted key request volume; is the safety factor; is the minimum pool capacity; is the size of the pre-allocated key pool; Step S22: Automatically adjust the type ratio of the pre-generated keys based on the predicted load characteristics, including: when the QPS peak is greater than 5000 times per second, generate 80% ECDSA P-256 keys and 20% RSA-2048 keys; when the business label is a financial transaction, generate ECDSA keys that meet the FIPS 186-5 standard; when the national cryptography compliance requirement is detected, generate SM2 elliptic curve keys; Step S3: Securely store the pre-generated KMS keys in a three-level structure of a hot pool, a warm pool, and a cold pool; the three-level structure secure storage step includes: Step S31: Configure the hot pool to store the pre-generated keys that will be called in the near future in memory, and encrypt them using the AES-GCM encryption algorithm; Step S32: Configure the warm pool to store the medium-term pre-generated keys using SSD, and encrypt them using the SM4 encryption algorithm; and Step S33: Configure the cold pool to store redundant keys using object storage, and only enable them when the load is high and the prediction deviation exceeds the threshold; Step S4: According to the comparison between the real-time request volume and the prediction result, implement priority routing and security degradation processing for KMS key distribution; KMS key distribution adopts a hot pool first strategy, and keys are preferentially allocated from the hot pool; when the keys in the hot pool are exhausted and the actual request volume is lower than the predicted low confidence interval, keys are allocated from the warm pool; when the actual request volume exceeds the predicted high confidence interval, cold pool keys are enabled.

2. The method for predicting-driven KMS key pre-distribution and elastic scheduling according to claim 1, characterized in that The encryption step includes: Step S311: Accelerate the hot pool using the AES-NI instruction set, parallelize the processing using the GCM mode of Intel AES-NI, and optimize the key block size to align with the L1 cache line; Step S312: Adopt the SM4-CTR mode for the warm pool, batch process the key blocks using the parallel IO characteristics of SSD, and pre-compute the S-box lookup table and store it in the SSD controller cache.

3. A prediction-driven KMS key pre-distribution and elastic scheduling method according to claim 1, characterized in that It also includes the steps of lifecycle management for the pre-allocated KMS keys, including: Set the TTL of the key, and automatically destroy the key when the survival time exceeds the TTL and it has not been used. Adopt the key fragmentation storage technology, split a single key into multiple fragments and store them dispersedly to meet the k-N security threshold, where at least k fragments are required to restore the complete key. The key fragmentation storage adopts a (3,5) threshold scheme, and splits the key K into 5 fragments: K = s1 ⊕ s2 ⊕ s3 ⊕ s4 ⊕ s5.

4. A prediction-driven KMS key pre-distribution and elastic scheduling method according to claim 1, characterized in that The steps for implementing KMS key distribution further include: when the keys in the hot pool are exhausted and the actual request volume is lower than the predicted low confidence interval, allocate keys from the warm pool and trigger an asynchronous supplementary pre-generation operation. The asynchronous supplementary pre-generation operation adopts a double-buffer queue design, including: setting an active queue for the current service key pool and a reserve queue for background key generation; when the remaining amount in the active queue is lower than the threshold, switch to the reserve queue to provide services and asynchronously trigger the key replenishment of the active queue, using a lock-free circular buffer.

5. A prediction-driven KMS key pre-distribution and elastic scheduling method according to claim 1, characterized in that The steps for implementing KMS key distribution further include: when the actual request volume exceeds the predicted high confidence interval, enable the cold pool keys and simultaneously trigger emergency key generation, giving priority to GPU acceleration; the GPU acceleration adopts a parallelization scheme of CUDA to perform parallel optimization processing on RSA and ECDSA keys respectively.

6. A prediction-driven KMS key pre-distribution and elastic scheduling method according to claim 1, characterized in that The security degradation processing includes: when an abnormal storage node is detected, automatically mark the affected keys as invalid; dynamically calculate the number of pre-generated keys required to be supplemented based on a prediction model; start the pre-generation process; exclude the keys marked as invalid from the key distribution process.

Images