Cryptographic resource scheduling management method based on virtualized cryptographic module
By pooling physical cryptographic resources into virtual cryptographic modules using virtualization technology and combining them with an intelligent scheduler for dynamic resource allocation and security isolation, the problems of low resource utilization and insufficient security isolation in traditional cryptographic systems are solved, achieving efficient and secure resource management and real-time service.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- GUANGXI POWER GRID CORP
- Filing Date
- 2026-01-19
- Publication Date
- 2026-04-17
AI Technical Summary
Traditional cryptographic systems suffer from low resource utilization, insufficient scalability and elasticity in dynamic computing environments, prominent security isolation risks in multi-user shared scenarios, and a lack of a global intelligent scheduling and management framework, making it impossible to simultaneously optimize performance, security and resource utilization.
By pooling physical cryptographic resources into virtual cryptographic modules (VCMs) using virtualization technology, and combining them with an intelligent scheduler for resource allocation, real-time monitoring and dynamic adjustment, lightweight virtualization technologies such as Docker and Kubernetes are adopted, and scheduling utility functions are designed to achieve optimal resource allocation and security isolation.
It improves resource utilization, reduces hardware costs, enhances system resilience and scalability, ensures secure isolation, simplifies operation and maintenance management, and improves service real-time performance and resource utilization efficiency.
Smart Images

Figure CN121887499A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of information security and cryptographic resource management technology. Specifically, it is a cryptographic resource scheduling and management method that integrates virtualization technology and intelligent scheduling algorithms. It is applicable to scenarios that require refined and automated management of physical cryptographic resources (such as hardware security modules and cryptographic cards). It can meet the dynamic needs of multiple business systems for cryptographic services such as encryption, decryption, and digital signatures. In particular, it can solve the problems of low resource utilization, insufficient security isolation, and weak elastic expansion capabilities in traditional static cryptographic resource deployment. It is widely used in fields such as finance, power, and the Internet of Things where information security and resource scheduling efficiency are highly demanding. Background Technology
[0002] Cryptographic resources, as a core foundational component of information security, undertake critical services such as encryption and decryption. Traditional cryptographic systems rely on dedicated hardware and employ static, siloed deployment and management, facing bottlenecks in modern dynamic computing environments, including low resource utilization, insufficient scalability and elasticity, significant security isolation risks in multi-user shared scenarios, and complex operation and maintenance. While virtualization technology has been widely applied in computing, storage, and networking to address resource pooling and elasticity issues, existing virtualization solutions in the cryptographic resource field are mostly limited to simple resource partitioning, lacking a global intelligent scheduling and management framework. Furthermore, they often use polling or static priority algorithms to allocate requests, failing to simultaneously optimize performance, security, and resource utilization. Therefore, there is an urgent need for innovative methods that integrate virtualization technology with intelligent scheduling capabilities to achieve refined, automated, and optimized management of cryptographic resources.
[0003] Full names of terms and abbreviations
[0004] VCM: Virtual Cryptographic Module, a logical cryptographic service unit created through virtualization technology based on a physical cryptographic resource pool. It has an independent logical operating space, cryptographic service interface and secure access control mechanism, and can independently provide services such as encryption, decryption, digital signature, and key storage. In the document, it serves as the core carrier for the present invention to achieve dynamic scheduling and secure isolation of cryptographic resources.
[0005] HSM: Hardware Security Module, a dedicated hardware device with high security, which can provide cryptographic operation functions such as key storage, encryption and decryption. In the document, it is used as one of the traditional physical cryptographic devices and a basic component for building physical resource pools.
[0006] SLA: Service Level Agreement, is a service quality standard agreed upon between the business system and the resource manager. It is used in documents to formulate dynamic adjustment strategies for VCM resources (such as SLA-based assurance strategies) and priority rules for requesting services.
[0007] RSA-2048: An asymmetric encryption algorithm based on the large number factorization problem (RSA Algorithm with 2048-bit Key Length). 2048 bits is the key length. It is used as an example cryptographic algorithm in the document to determine the resource requirements of a request (such as the preset resource requirements corresponding to an RSA-2048 signature request).
[0008] Docker: A lightweight container virtualization technology that enables the packaging and isolation of applications from their dependent environments. It is documented as one of the lightweight virtualization technology options for building physical resource pools.
[0009] Kubernetes: A container orchestration and management platform that supports the deployment, scaling, and scheduling of containers. It is documented as one of the lightweight virtualization technology options for building physical resource pools and managing VCMs. Summary of the Invention
[0010] This invention discloses a cryptographic resource scheduling and management method based on a virtualized cryptographic module. First, lightweight virtualization technologies such as Docker and Kubernetes are used to pool physical cryptographic resources such as HSM clusters and cryptographic cards, creating a Virtualized Cryptographic Management (VCM) with independent security mechanisms and dynamically allocating initial resources. Then, a scheduler monitors requests and VCM status, models requests as tuples, and selects the optimal VCM to allocate requests based on a utility function that integrates business priority, security matching degree, and resource utilization. Finally, VCM and request metrics are collected in real time, and the load mean and variance are calculated. When thresholds are exceeded, request migration and VCM resource adjustments are performed to achieve load balancing. This method improves resource utilization and service real-time performance, strengthens security isolation, and is suitable for scenarios with high security requirements.
[0011] Technical solution
[0012] This invention proposes an innovative cryptographic resource scheduling and management method based on virtualized cryptographic modules. Its core idea is as follows: First, physical cryptographic resources are abstracted into a dynamically manageable resource pool using virtualization technology. Then, a multi-objective intelligent scheduler is designed and implemented. This scheduler can make optimal resource allocation decisions based on the real-time characteristics of requests and the global state of the system. Its implementation relies on a dynamic closed-loop system. This system ensures the continuity and adaptability of cryptographic resource scheduling and management through a cyclical mechanism of real-time data acquisition, decision calculation, and execution feedback. The system operation mainly includes three core stages, and the resource allocation, state evaluation, and adjustment decisions in each stage are based on preset mathematical models and quantitative formulas to ensure the scientific nature and traceability of the operation. The implementation process is as follows:
[0013] 1. Phase One: Construction of Virtualization Resource Pool
[0014] 1.1 Physical Resource Pooling and Virtual Module Creation
[0015] For physical cryptographic resources (specifically including hardware devices with cryptographic computation and key management functions such as Hardware Security Module (HSM) clusters and cryptographic cards), lightweight virtualization technologies (such as containerized deployment technologies like Docker and Kubernetes container architectures, which can reduce virtualization overhead while ensuring resource isolation) are used to uniformly pool the physical resources, forming a dynamically schedulable physical resource pool. Based on the physical resource pool, multiple Virtual Cryptographic Modules (VCMs) are further created. Each VCM has an independent logical operating space, cryptographic service interface, and secure access control mechanism, and can serve as a complete logical cryptographic service unit, independently providing cryptographic services such as encryption, decryption, digital signature, and key storage to users or business systems. Furthermore, different VCMs are isolated from each other through resource isolation and access control to avoid security risks such as data leakage and computational interference.
[0016] 1.2 Resource Capacity Definition and Dynamic Adjustment Rules
[0017] To achieve quantitative management of VCM resource allocation, the total physical resource capacity is first defined as follows: This parameter is quantified and determined based on the hardware specifications of the physical cryptographic device (such as computational throughput, key storage capacity, and concurrent processing capabilities); during the initial construction phase of the virtualization resource pool, Distribute evenly to N VCMs (the value of N can be pre-configured according to business needs, physical resource scale, and security isolation requirements), at which point each Initial resource capacity allocated Calculated using the following formula:
[0018]
[0019] It needs to be clarified that, These are not fixed values, but dynamically adjustable resource parameters. The system can monitor the resource usage, service request volume, and remaining physical resource pool capacity of each VCM in real time during operation, based on preset strategies (such as adjustment strategies based on business load fluctuations, optimization strategies based on resource utilization, and guarantee strategies based on User Service Level Agreements (SLAs)). Dynamically adding or removing resources allows for elastic scaling of cryptographic resources, avoiding service delays caused by overloading a single VCM resource and preventing waste caused by idle resources.
[0020] 2. Phase Two: Intelligent Scheduling and Resource Allocation
[0021] 2.1 Scheduler Functions and Monitoring Scope
[0022] As the core decision-making unit of the dynamic closed-loop system of this method, the scheduler undertakes the core functions of resource allocation and request scheduling. During its operation, it needs to continuously monitor two types of key objects in real time:
[0023] User request queue: Real-time collection of the number of requests to be processed in the queue, the submission time of each request, and the waiting time, to ensure that no requests are missed or excessively delayed;
[0024] Real-time monitoring of each Virtual Cryptographic Module (VCM): Real-time acquisition of the current resource utilization, processing progress, security policy effectiveness status, and service availability (e.g., whether it is in normal operation, maintenance, or fault status) of each VCM, providing accurate system status data support for subsequent scheduling decisions.
[0025] 2.2 User Request Modeling Rules
[0026] To achieve quantitative management and precise scheduling of requests, each user's password service request (denoted as request i, where i is a positive integer representing the unique identifier of the request) is uniformly modeled as a tuple. The definitions, value rules, and quantization methods of each parameter are as follows:
[0027] (Request arrival time): refers to the timestamp of the user request being submitted to the request queue through the system interface. The value is in standard time format (e.g., YYYY-MM-DD HH:MM:SS.XXX), and is used to calculate the request waiting time and determine the scheduling timeliness.
[0028] (Security Level Quantification): Based on the sensitivity of the data involved in the request and the security requirements of the business scenario, the security level of the request is quantified into discrete values. The example value rules are 1-low security level (such as ordinary public data encryption), 2-medium security level (such as general business data signing), and 3-high security level (such as financial transaction key management). The specific quantification standard can be preset by the system administrator according to the actual business needs.
[0029] (Requested Resource Requirements): This refers to the amount of VCM resources required to complete the cryptographic service (such as encryption operations or digital signature verification). Quantification dimensions include computing resources (such as the required CPU computing power percentage), storage resources (such as temporary key storage capacity), and concurrency resources (such as the number of dedicated threads). The value is determined by a pre-defined resource requirement mapping table based on the cryptographic algorithm type and data size of the request (e.g., for a signature request using the RSA-2048 algorithm, the pre-defined resource requirements are...). = 0.2 standard resource units);
[0030] (Business Priority): A priority value set according to the importance of the business to which the request belongs. The value is a positive integer, and the higher the value, the higher the priority (e.g., core transaction requests). = 10, Normal query request = 3), priority rules can be pre-configured by the business system according to the service level agreement (SLA) and synchronized to the scheduler.
[0031] 2.3 Design and Parameter Definition of Scheduling Utility Function
[0032] To achieve an optimal balance among the three competing goals of high performance (low request response time), high security (request matching with VCM security level), and high resource utilization (VCM load balancing), a scheduling utility function is designed to calculate the relationship between each request i and each available resource. (j is a positive integer representing the unique identifier of the VCM) constitutes a request-VCM pair utility value The function expression is as follows:
[0033]
[0034] The definitions, value constraints, and functions of each parameter are as follows:
[0035] , , (Weight coefficients): All are non-negative real numbers, and satisfy the following conditions: + + = 1, used to adjust the weighting of the three objectives in the scheduling decision. The specific value can be configured according to the application scenario requirements. For example, in a financial transaction scenario, to prioritize security, it can be set to... = 0.5、 = 0.3、 = 0.2; In typical IoT data encryption scenarios, to prioritize resource utilization, it can be set to... = 0.4、 = 0.3、 = 0.3;
[0036] ( Security Level: A quantified value of the security level set based on the VCM's security configuration (such as whether hardware encryption is enabled, whether key storage complies with national cryptographic standards, and whether it has the capability to prevent side-channel attacks). The value selection rules are consistent with the requested security level. Consistency (e.g., 1-low, 2-medium, 3-high) ensures high-security-level requests. Can be matched with high-security VCM To avoid risks caused by mismatched security levels;
[0037] ( Current load rate): refers to Current occupied resources and total allocated resource capacity The ratio, with a value range of [0,1], is calculated as follows: This is used to reflect the resource availability of the VCM.
[0038] ( Resource capacity): that is, the VCM dynamic resource capacity defined in Phase 1, which serves as the benchmark value for calculating load rate and ensuring the accuracy of load assessment.
[0039] 2.4 Scheduling Decision Logic and Execution Process
[0040] For each newly arrived request i, the scheduler executes a scheduling decision according to the following logic and process:
[0041] (1) VCM filtering is available: based on the security level of request i With resource demand Select a set of available VCMs that meet the following criteria from all VCMs: required security level of the VCMs. (Ensure safe matching), and the current remaining resources of VCM. (Ensure sufficient resources);
[0042] (2) Utility value calculation: For each available value after filtering Based on real-time acquisition , , , , Parameters and presets , , The coefficients are substituted into the scheduling utility function to calculate the corresponding... value;
[0043] (3) Optimal VCM selection: For all available VCMs The values are compared, and the VCM with the highest utility value is selected as the binding execution object for request i; if multiple VCMs exist... If the values are the same, the request waiting time is further compared, and the request is preferentially assigned to the VCM corresponding to the queue with the longest waiting time.
[0044] (4) Execution and Status Update: Assign request i to the selected This triggers the VCM to perform the password service and updates it in real time. Current resource usage and load rate The status of the user request queue provides the latest data for subsequent scheduling decisions.
[0045] 3. Phase Three: Dynamic Monitoring and Flexible Adjustment
[0046] 3.1 Functions and Indicator Collection Rules of the Monitoring Module
[0047] During system operation, the monitoring module needs to continuously and frequently collect two types of key data to provide data support for subsequent load assessment, elastic adjustment, and performance measurement. The specific collection scope and rules are as follows:
[0048] VCM operational status metrics: The core collects the real-time load rate of each Virtual Cryptographic Module (VCM). (j is the unique identifier of the VCM, and its value is a positive integer). This metric is calculated by comparing the amount of resources currently occupied by the VCM with the resource capacity allocated to it. The ratio is calculated to obtain, that is The data collection frequency is set to once every 1-5 seconds to ensure real-time reflection of VCM resource usage. At the same time, auxiliary indicators such as VCM service status (e.g., normal operation, insufficient resources, offline failure, etc.) and key operation success rate are collected synchronously to determine whether VCM has the ability to continuously process requests.
[0049] Request processing performance metrics: The focus is on collecting response time data for all user requests, including the arrival time of each request i (where i is a unique identifier for the request, and its value is a positive integer). Completion Time ,in Defined as the timestamp of the VCM completing the corresponding cryptographic service (such as encryption and signature verification) and returning the result to the user, the collection accuracy needs to reach the millisecond level; in addition, it is also necessary to collect indicators such as the backlog of request queues and request timeout rate to predict whether the system's processing capacity matches the request volume.
[0050] The data collected by the monitoring module needs to be stored in the system database in real time, and the data accuracy should be ensured through data verification mechanisms (such as timestamp consistency verification and numerical range verification) to avoid scheduling decision deviations due to data anomalies.
[0051] 3.2 Global Load Balancing Evaluation Mechanism
[0052] To prevent imbalances such as local VCM overload and local VCM idleness, the scheduler needs to periodically perform a quantitative assessment of the global load status. The specific assessment process and calculation rules are as follows:
[0053] Evaluation cycle setting: Load balancing evaluation cycle and monitoring module The data collection cycle is set to execute once every 5-30 seconds, which can be adjusted by the system administrator according to the frequency of business load fluctuations (e.g., shortening to 5 seconds during peak business periods and extending to 30 seconds during off-peak periods).
[0054] Average load calculation: First, calculate the average load of all normally operating VCMs. The calculation formula is:
[0055]
[0056] Where N is the total number of VCMs currently operating normally (excluding VCMs that are offline or under maintenance). Let be the real-time load rate of the j-th normally operating VCM.
[0057] Load variance calculation: based on average load Further calculate the variance of the load factor of all normally operating VCMs. To quantify the dispersion of load across each VCM, a larger variance indicates a more unbalanced load. The calculation formula is as follows:
[0058]
[0059] 3.3 Load Balancing Triggering Conditions and Execution Operations
[0060] System preset load variance threshold ( This is a non-negative real number; the example value is 0.1. The specific value can be adjusted according to the load balancing requirements of the business. For example, in scenarios with high stability requirements, it can be... (Set to 0.08), when the scheduler calculates the real-time load variance. > When the system automatically triggers load balancing, the operation is divided into the following two categories, and the system will automatically select or combine the following methods based on the actual scenario:
[0061] Request migration operation: for load factors exceeding (k is a preset coefficient, usually ranging from 1.2 to 1.5) overloaded VCMs, filtering out low-priority requests that are in the waiting queue or have just started processing (based on request i). (Value judgment), migrate to a load factor lower than Idle VCMs; during migration, the integrity of requests must be maintained, and the requests must be carried synchronously. , Set up core parameters and update the VCM identifier bound to the request to ensure that the VCM can process requests normally after migration.
[0062] VCM resource quota adjustment operation: For those continuously overloaded (for 3 consecutive assessment periods) The VCM (Virtual Management Center) increases resource quotas from the remaining capacity of the physical resource pool, thereby increasing... Value; for those continuously in an idle state (for 3 consecutive evaluation periods) VCM, reduce its resource quota (reduce) The released resources will be returned to the physical resource pool; the resource adjustment range is determined based on the overload / idleness level, and the single adjustment amount shall not exceed the original value. The value is set at 20% to avoid affecting VCM stability due to excessive resource fluctuations.
[0063] After the load balancing operation is executed, the monitoring module needs to re-collect data from each VCM within one evaluation cycle. ,verify Has it been reduced to If the target is not met, repeat the above operations until the system load returns to a balanced state.
[0064] 3.4 Definition and Calculation Rules of Performance Evaluation Indicators
[0065] To measure the resource scheduling effectiveness of this method, the following two core performance evaluation metrics are set. The metrics data are calculated from the raw data collected by the monitoring module, and the calculation frequency is consistent with the load balancing evaluation cycle:
[0066] Average response time Used to evaluate the timeliness of system request processing, defined as the average response time of all completed requests within a statistical period, where the response time is the request completion time. With arrival time The difference is calculated using the following formula:
[0067]
[0068] Where M is the total number of requests that have been processed within the statistical period. The response time for the i-th request (in milliseconds). The smaller the value, the faster the system processes requests.
[0069] resource utilization rate Used to evaluate the utilization efficiency of physical cryptographic resources, defined as the percentage of the total load of all normally operating VCMs to the total capacity of physical resources within a statistical period. The calculation formula is as follows:
[0070]
[0071] in This is the sum of the real-time load rates of all normally functioning VCMs. The total capacity of physical cryptographic resources (as defined in Phase 1) Consistent) A higher value indicates a lower level of idle physical resources and higher utilization efficiency.
[0072] The core objective of this method is to achieve average response time by dynamically monitoring and elastically adjusting the system, while ensuring system security through mechanisms such as VCM security isolation and request-VCM security level matching. Minimization and resource utilization Maximize.
[0073] Beneficial effects
[0074] The beneficial effects of this invention are as follows:
[0075] 1. This invention abstracts physical cryptographic resources into a globally scheduled resource pool by constructing and dynamically adjusting a virtualized resource pool. Combined with a load balancing mechanism (based on a load variance threshold to trigger resource quota adjustments or request migration) and resource utilization optimization using a scheduling utility function, it solves the "island effect" of traditional static deployment, significantly improves the utilization of physical cryptographic resources, and reduces hardware costs.
[0076] 2. Leveraging lightweight virtualization technologies such as Docker and Kubernetes, this invention supports the rapid creation / destruction of Virtual Cryptographic Modules (VCMs), and the VCM resource capacity can be dynamically adjusted according to business load fluctuations. It can adapt to surges in business volume without adding new physical hardware, and automatically reclaim resources during off-peak hours, enhancing system elasticity and scalability.
[0077] 3. This invention achieves isolation through an independent logical space for VCMs and access control. Combined with the security matching design of scheduling utility functions, it forces high-security-level requests to be allocated only to VCMs that meet the security level. With key operation monitoring and data verification, it strengthens security isolation and risk prevention in multi-user shared scenarios.
[0078] 4. The multi-objective intelligent scheduler integrates business priority, security matching, and resource utilization through utility functions to accurately calculate the optimal VCM matching. When utility values are the same, requests that have been waiting for a long time are processed first, avoiding the defects of traditional algorithms, reducing request response latency, and improving service real-time performance.
[0079] 5. The dynamic closed-loop system automates data acquisition and decision execution. Resource allocation and adjustment are based on quantitative formulas. Operation and maintenance personnel only need to preset parameters to achieve automated and refined management of cryptographic resources, simplifying operation and maintenance and reducing costs and error rates. Attached Figure Description
[0080] Figure 1 This is a schematic diagram illustrating the implementation process of the method described in this invention. The diagram shows the implementation process of the cryptographic resource scheduling and management method based on a virtualized cryptographic module. Detailed Implementation
[0081] The present invention will be further described below with reference to specific embodiments:
[0082] 1. Example
[0083] This embodiment takes the cryptographic resource scheduling and management scenario of a provincial power grid dispatch center as an example to explain in detail the specific implementation process, parameter configuration and application effect of the cryptographic resource scheduling and management method based on virtualized cryptographic modules of the present invention, and to verify the feasibility and superiority of the method.
[0084] 1.1 Application Scenarios and Background
[0085] The provincial power grid dispatch center needs to provide cryptographic services for multiple core business systems, including the power monitoring system, power trading system, and user electricity consumption information collection system. The cryptographic operations involved include device authentication encryption, power trading data signing, user electricity consumption privacy data encryption, and dispatch instruction integrity verification. The existing system uses three Hardware Security Modules (HSMs) as physical cryptographic resources. Under the traditional static allocation method, there are problems such as delayed response times to requests from the core trading system, idle resources in the ordinary data collection system, and insufficient security isolation between highly sensitive dispatch data and ordinary data. Therefore, there is an urgent need to achieve dynamic scheduling and refined management of cryptographic resources through the method of this invention.
[0086] 1.2 Implementation Parameter Configuration
[0087] 1.2.1 Physical Resources and Virtualization Parameters
[0088] Physical cryptographic resources: 3 identical HSM devices, each with a throughput of 10,000 operations / second (RSA-2048 signature operations), a key storage capacity of 10,000 key pairs, and a concurrent processing capacity of 500 requests. Defining the resource capacity of a single HSM as 1 standard unit, the total physical resource capacity is... =3 standard units.
[0089] Virtualization configuration: A physical resource pool is built using a Kubernetes container architecture, creating 6 virtual cryptographic modules ( Initial resource allocation is based on the formula Calculations show that N=6, therefore the initial resource capacity for each VCM is... =0.5 standard units.
[0090] VCM security level configuration: Set according to business security requirements. For high security level ( =3, supports the national cryptographic SM4 algorithm, and prevents side-channel attacks). Medium security level ( =2, supports RSA-2048 algorithm and encrypted key storage). For low security level ( =1, supports common symmetric encryption algorithms).
[0091] 1.2.2 Scheduling Parameter Configuration
[0092] (1) Weighting coefficient: Based on the characteristics of power grid business, priority is given to ensuring security and the timeliness of core business, and a weighting coefficient is set. =0.3 (Business Priority Weight) =0.5 (safety matching weight) =0.2 (Resource utilization rate weight).
[0093] (2) Load balancing threshold: Set the load variance threshold =0.08, load factor k=1.3, load balancing assessment period is 10 seconds, and the maximum single adjustment of VCM resources is 15% of the original capacity.
[0094] (3) Request parameter mapping rules: A pre-defined mapping table of security level, resource requirements and business priority for requests in the power grid scenario is used. The core configuration is as follows:
[0095] Scheduling instruction signature request: Security level =3, resource demand =0.3 standard units, business priority =10;
[0096] Power transaction data encryption request: Security level =2, resource demand =0.2 standard units, business priority =8;
[0097] User electricity consumption information collection encryption request: Security level =1, resource demand =0.1 standard unit, business priority =5;
[0098] System log verification request: Security level =1, resource demand =0.05 standard units, business priority =3.
[0099] 1.3 Implementation Process
[0100] 1.3.1 Construction of Virtualization Resource Pool
[0101] Three HSM devices are managed in a unified pool using the Kubernetes container platform, achieving virtualization and abstraction of hardware resources to form a physical resource pool. Six VCMs are created based on preset configurations, each allocated 0.5 standard units of initial resources and configured with independent access control policies and service interfaces. The high-security VCM is only open to the power grid dispatching system, while the medium- and low-security VCMs correspond to the power trading system and the electricity consumption information collection system, respectively, achieving isolation between services with different security levels.
[0102] 1.3.2 Intelligent Scheduling and Resource Allocation Execution
[0103] During a certain period, the system received four types of concurrent requests. The specific scheduling process is as follows:
[0104] (1) Request modeling: Tuple modeling is performed for each request. The scheduling instruction signature request r1=(2024-06-01 10:00:00.001, 3, 0.3, 10), the power transaction data encryption request r2=(2024-06-01 10:00:00.002, 2,0.2, 8), the user electricity information collection encryption request r3=(2024-06-01 10:00:00.003, 1, 0.1, 5), and the system log verification request r4=(2024-06-01 10:00:00.004, 1, 0.05, 3).
[0105] (2) VCM can be used for filtering:
[0106] r1 has a security level of 3, and filters out... VCMs with ≥3 and remaining resources ≥0.3, namely VCM1 and VCM2 (current load rate is 0.2, remaining resources 0.5-0.5×0.2=0.4≥0.3).
[0107] With r2 security level 2, VCM1-VCM4 are filtered out, and VCMs with insufficient resources after allocation are excluded. The final available VCMs are VCM3 and VCM4.
[0108] r3 and r4 have a security level of 1, and the available VCMs are VCM5 and VCM6.
[0109] (3) Utility value calculation:
[0110] For r1 and VCM1, VCM2, substitute into the utility function Calculated Similarly, U(1,2) is 3.62 (the two VCM states are consistent);
[0111] Since U(1,1)=U(1,2), compare the request waiting time (both are 0), and randomly select VCM1 as the execution object of r1;
[0112] Similarly, calculate the utility values of r2 and VCM3. Select VCM3, which has the highest utility value, and execute r2;
[0113] The utility values of r3 and r4 are calculated and VCMs are allocated sequentially. Finally, r3 is allocated to VCM5 and r4 is allocated to VCM6.
[0114] (4) Status Update: After allocation, update the occupied resources and load rate of each VCM. The load rate of VCM1 becomes VCM3 load rate becomes =0.5, and the load rates of the remaining VCMs are updated accordingly.
[0115] 1.3.3 Dynamic monitoring and flexible adjustment
[0116] The system monitoring module collects VCM load rate and request processing metrics every 10 seconds. Within a certain evaluation period, the average load μ of all normally operating VCMs was calculated to be 0.6, and the load variance... This triggers a load balancing operation.
[0117] (1) Overload VCM identification: VCM1 load rate is 0.8, exceeding (VCM1 load rate of 0.8 is within the threshold, but VCM3 load rate of 0.9 (assuming subsequent new requests caused this) is found to exceed the threshold.)
[0118] (2) Request migration: Encrypt one low-priority power transaction data request on VCM3 ( =8) After migrating to VCM4 with a load factor of 0.4, the load factor of VCM3 dropped to 0.7, and the load factor of VCM4 rose to 0.6.
[0119] (3) Resource quota adjustment: If the load rate of VCM1 remains at 0.75 (close to the threshold) for three consecutive evaluation periods, increase its resource quota by 15% from the physical resource pool. Adjusted to 0.5 × 1.15 = 0.575 standard units, the load rate decreased to ;
[0120] (4) Balance verification: Calculate the load variance σ in the next evaluation period. 2 =0.06<0.08, the system load has returned to a balanced state.
[0121] 1.4 Implementation Results
[0122] Through a three-month trial operation of the method of this invention at the provincial power grid dispatch center, compared with the traditional static allocation method, the core performance indicators are improved as follows:
[0123] (1) Average response time: The average response time for dispatch instruction signature requests decreased from 150 milliseconds to 80 milliseconds, the average response time for power transaction data encryption requests decreased from 120 milliseconds to 65 milliseconds, and the average response time for user electricity consumption information collection requests decreased from 90 milliseconds to 40 milliseconds. The speed was reduced by 46.7%, meeting the real-time requirements of power grid operations;
[0124] (2) Resource utilization rate: the average utilization rate of physical cryptographic resources The percentage increased from 52% to 83%, and idle resources decreased by 64%, avoiding the contradiction between the shortage of core business resources and the idleness of ordinary business resources under the traditional model;
[0125] (3) Security assurance: Through VCM security isolation and request-VCM security level matching mechanism, there is no risk of cross-access between highly sensitive data and ordinary data, and the key operation success rate is maintained at 99.99%, which meets the requirements of Level 3 Information Security Protection of the Power Industry.
[0126] The embodiments of the present invention are not limited to the above description. Depending on the security-sensitive scenarios such as power, the allocation of virtual cryptographic module resources, the adaptation of physical cryptographic resources, and the selection of SM4 / RSA-2048 algorithms can be adjusted. All such improvements fall within the protection scope of the present invention.
Claims
1. A method for managing cryptographic resource scheduling based on virtualized cryptographic modules, characterized in that, Includes the following steps: (1) Virtualization resource pool construction: adopt lightweight virtualization technology to pool the physical password resources to form a physical resource pool, create a plurality of virtual password modules (VCM) based on the physical resource pool, define the total capacity of the physical resources and initially allocate to each VCM, and configure the dynamic adjustment rules of the VCM resource capacity; (2) Intelligent scheduling and resource allocation: The scheduler monitors the user request queue and the running status of each VCM in real time, and models user requests as tuples. Design scheduling utility function , Based on the function, available VCMs are filtered, utility values are calculated, and the optimal VCM allocation request is selected, while the system status is updated. (3) Dynamic monitoring and elastic adjustment: The monitoring module collects VCM operation status indicators and request processing performance indicators in real time, and periodically calculates the global average load. With load variance ,when Exceeding the preset threshold At that time, request migration and VCM resource quota adjustment operations are performed to achieve load balancing.
2. The method according to claim 1, characterized in that, In step 1, the physical cryptographic resources include a Hardware Security Module (HSM) cluster and cryptographic cards; the lightweight virtualization technology is a Docker or Kubernetes container architecture; each VCM has an independent logical running space, cryptographic service interface, and secure access control mechanism, with an initial resource capacity of... , Configure the number of VCMs according to business needs.
3. The method according to claim 1, characterized in that, In step 2, the tuple The parameters are defined as follows: To request the arrival timestamp, The quantification values are for security levels 1-3. The resource requirements are determined based on the type of cryptographic algorithm and the amount of data. The priority of the service is a positive integer; in the utility function, , , The weight coefficients are non-negative and + + = 1, For VCM security level, .
4. The method according to claim 1, characterized in that, In step 2, the VCM filter must meet the following requirements. and When utility values are the same, requests are preferentially assigned to the VCM corresponding to the queue with the longest waiting time.
5. The method according to claim 1, characterized in that, In step 3, the VCM running status indicators include real-time load rate $load_{j}$, service status, and key operation success rate, collected every 1-5 seconds; the request processing performance indicators include request arrival time $t_{i}$, completion time $t_{complete,i}$, queue backlog number, and timeout rate, with collection accuracy down to the millisecond level.
6. The method according to claim 1, characterized in that, In step 3, the global load balancing evaluation period is 5-30 seconds. , This represents the total number of VCMs operating normally.
7. The method according to claim 1, characterized in that, In step 3, the migration request targets load rates exceeding [a certain threshold]. Overloaded VCM, migrate low-priority requests to locations with load rates below [value missing]. The idle VCM, k takes a value of 1.2-1.5; the single adjustment of VCM resource quota shall not exceed the original amount. 20% of the resources are allocated to overloaded VCMs, and resources are reduced for idle VCMs and recycled to the physical resource pool.
8. The method according to claim 1, characterized in that, Performance evaluation steps include: calculating the average response time. With resource utilization rate M represents the total number of requests completed within the statistical period.