Post-quantum hybrid certificate full life cycle automation system and control method

Abstract

The invention provides a post-quantum hybrid certificate full life cycle automation system and a control method, and relates to the technical field of network security. A context and a security policy of a client are dynamically collected in a TLS handshake process through an adaptive handshake module, and are transmitted to a policy engine module. The strategy engine module intelligently selects an optimal post-quantum hybrid algorithm suite from a plurality of candidate algorithm suite according to the dynamic information, so that the defect that the traditional fixed algorithm configuration cannot adapt to a heterogeneous network environment is overcome, the problem of performance bottleneck or over-high energy consumption possibly occurring on resource-limited equipment is avoided, and the system performance is improved. The hybrid certificate automatic composer can automatically execute application, deployment and alternation of post-quantum hybrid certificates according to instructions of a strategy engine module, and solves the problems of complex certificate management, difficult algorithm adaptation, high security deployment risk and the like in a post-quantum cryptography migration process. And effective technical support is provided for smooth and safe transition to the post-quantum cryptography era.

Description

Technical Field

[0001] This application relates to the field of cybersecurity technology, and more specifically, to a post-quantum hybrid certificate full lifecycle automation system and control method. Background Technology

[0002] With the continuous development of quantum computing technology, the current public key infrastructure, which is widely based on RSA and elliptic curve cryptography, is facing imminent and severe security threats. To address this threat, the industry is actively migrating to post-quantum cryptography. During this transition phase, a hybrid certificate model combining basic PQC algorithms with post-quantum PQC algorithms is considered a core solution. For example, combining X25519 with Kyber768 for key exchange, or combining ECDSA with Dilithium for digital signatures.

[0003] However, the introduction and large-scale deployment of such hybrid certificates face significant engineering challenges and management complexities. First, hybrid certificates involve multiple key pairs, and their entire lifecycle management, including generation, application, deployment, rotation, and revocation, is extremely cumbersome and error-prone if relying on manual operations, resulting in high maintenance costs and difficulty in achieving the agility required for cryptographic algorithms. Second, client environments in networks are highly heterogeneous, ranging from high-performance servers to resource-constrained IoT devices, with vastly different requirements for algorithm performance. A single algorithm suite cannot achieve an optimal balance of computation, bandwidth, and energy consumption in all scenarios.

[0004] Furthermore, the deployment of the new PQC algorithm lacks a mature canary release and rollback mechanism like software deployment. If the new algorithm causes service anomalies due to compatibility or performance issues, it could trigger large-scale service disruptions, posing uncontrollable deployment risks to enterprises. Currently, existing technologies lack a unified, automated system to address these systemic engineering problems, from certificate management and algorithm adaptation to secure deployment, which severely hinders the smooth and secure migration to backward quantum cryptography.

[0005] There is currently no effective technical solution to the above problems. Summary of the Invention

[0006] The purpose of this application is to provide a post-quantum hybrid certificate full lifecycle automation system and control method, which aims to solve the technical problems of complex hybrid certificate management, difficulty in algorithm adaptation in heterogeneous environments, and lack of canary release and rollback mechanism for new algorithm deployment.

[0007] In a first aspect, this application provides a post-quantum hybrid certificate full lifecycle automation system, including: a policy engine module, an adaptive handshake module, and a hybrid certificate automation orchestrator; The adaptive handshake module is used to collect and pass the client's dynamic context vector and security policy vector to the policy engine module during the TLS handshake process. The policy engine module is used to select the optimal post-quantum hybrid algorithm suite for TLS handshake from multiple candidate algorithm suites based on the received dynamic context vector and security policy vector. The dynamic context vector includes metadata of device state information and network state information. The adaptive handshake module is also used to execute the optimal post-quantum hybrid algorithm suite selected by the policy engine module; The hybrid certificate auto-orchestrator is used to automate the application, deployment, and rotation of post-quantum hybrid certificates according to instructions from the policy engine module.

[0008] This application provides a comprehensive system that integrates intelligent policy decision-making, adaptive handshake and automated certificate management through this technical solution. It effectively solves the deployment and management challenges of hybrid certificates in complex heterogeneous environments, realizes a smooth transition and efficient application of post-quantum cryptography algorithms, and significantly improves the security and operational efficiency of the system.

[0009] Optionally, when the policy engine module selects the optimal post-quantum hybrid algorithm suite from multiple candidate algorithm suites for the TLS handshake based on the received dynamic context vector and security policy vector, it specifically performs the following: Based on the dynamic context vector and security policy vector, obtain the security weight, computational efficiency weight, latency weight, bandwidth weight, security score, computational efficiency score, latency score, and bandwidth score for each candidate algorithm suite; The comprehensive score of the corresponding candidate algorithm suite is calculated based on each security weight, computational efficiency weight, latency weight, bandwidth weight, security score, computational efficiency score, latency score, and bandwidth score. The candidate algorithm suite with the highest overall score is selected as the optimal post-quantum hybrid algorithm suite for TLS handshake selection.

[0010] By introducing multi-dimensional weights and scoring mechanisms and calculating comprehensive scores, quantitative evaluation and optimal selection of candidate algorithm suites are achieved, ensuring that the most suitable post-quantum hybrid algorithm suite can be selected under different dynamic environments, thereby optimizing system performance and resource utilization.

[0011] Optionally, when the policy engine module obtains security weights, computational efficiency weights, latency weights, bandwidth weights, security scores, computational efficiency scores, latency scores, and bandwidth scores for each candidate algorithm suite based on the dynamic context vector and security policy vector, it specifically performs the following: Obtain the security weights based on the security policy vector; The computational efficiency weights are obtained based on dynamic device status information; Based on dynamic network status information, obtain latency weights and bandwidth weights; Based on a preset security level mapping table, a security score is obtained according to the security policy vector. The security level mapping table records a level score that represents the inherent security strength of each candidate algorithm suite, pre-assigned based on authoritative cryptographic standards or internal security policies. Based on the first historical data and dynamic device status information, a computational efficiency score is obtained. The first historical data refers to the performance dataset obtained through offline benchmark testing, which characterizes the inherent computational resource consumption of each candidate algorithm suite when running on a standard computing device. Based on the second historical data and dynamic network status information, latency score and bandwidth score are obtained. The second historical data refers to the performance dataset obtained through offline testing, which characterizes the inherent network resource consumption of each candidate algorithm suite when communicating in a standard network environment.

[0012] By refining the methods for obtaining weights and scores, and combining security policies, dynamic device status, network status, and historical performance data, the selection of algorithm suites becomes more precise and intelligent, enabling a more comprehensive reflection of the complexity of the actual operating environment and further improving the accuracy and effectiveness of algorithm adaptation.

[0013] Optionally, when the strategy engine module calculates the comprehensive score of the corresponding candidate algorithm suite based on various security weights, computational efficiency weights, latency weights, bandwidth weights, security score, computational efficiency score, latency score, and bandwidth score, it specifically performs the following: Based on the various security weights, computational efficiency weights, latency weights, bandwidth weights, security scores, computational efficiency scores, latency scores, and bandwidth scores, the comprehensive score of the corresponding candidate algorithm suite is calculated using the following formula: Si(t)=α(C(t),P)*F_delay+β(C(t),P)*F_security+γ(C(t),P)*F_bandwidth+δ(C(t),P)*F_computation; Where Si(t) is the overall score of the i-th candidate algorithm suite, C(t) is the connection dynamic context vector at time t, including the network state vector N(t) and the device state vector D(t); P is the security policy vector; F_delay is the delay score, F_security is the security score, F_bandwidth is the bandwidth score, and F_computation is the computational efficiency score. α(C(t), P) is the delay weight dynamically calculated based on the connection dynamic context vector and security policy vector at time t, β(C(t), P) is the security weight dynamically calculated based on the connection dynamic context vector and security policy vector at time t, γ(C(t), P) is the bandwidth weight dynamically calculated based on the connection dynamic context vector and security policy vector at time t, and δ(C(t), P) is the computational efficiency weight dynamically calculated based on the connection dynamic context vector and security policy vector at time t, and satisfies α(C(t), P) + β(C(t), P) + γ(C(t), P) + δ(C(t), P) = 1.

[0014] Optionally, the device status information includes the device CPU load and the device remaining battery power; When the strategy engine module obtains the computational efficiency weights based on dynamic device status information, it specifically performs the following: The efficiency weight is calculated using the following formula, based on the device's CPU load and remaining battery power: δ(t)=δ0+k_δ_cpu*cpu_load(t)+k_δ_battery*(1-battery_level(t)); In the formula, δ(t) is the computational efficiency weight at time t, δ0 is the initial value of the computational efficiency weight, k_δ_cpu is the weight adjustment coefficient of CPU load, cpu_load(t) is the device CPU load at time t, k_δ_battery is the weight adjustment coefficient of battery power, and battery_level(t) is the remaining power of the device at time t.

[0015] Optionally, the strategy engine module also includes a machine learning unit, which optimizes the computational efficiency weights, latency weights, and bandwidth weights using stochastic gradient descent based on historical handshake performance data from each algorithm suite.

[0016] This application introduces a machine learning unit to continuously optimize the weights using stochastic gradient descent, enabling the system to learn from historical data and continuously improve its algorithm selection strategy. This results in a more intelligent and adaptive selection of algorithm suites, further enhancing the system's long-term performance and robustness.

[0017] Optionally, the strategy engine module also integrates the following secure canary release and rollback mechanisms: In the strategy engine module, set the initial traffic ratio for the new algorithm suite to be released; During the TLS handshake process, the policy engine module selects whether to use the new algorithm suite or the existing old algorithm suite for the current connection based on the initial traffic ratio. During the release of new algorithm suites, monitor system performance metrics related to both the new and old algorithm suites; The system performance metrics are used to determine whether there are any anomalies in the new algorithm suite. If there are anomalies, a rollback command is sent to the strategy engine module. The policy engine module responds to the rollback command by adjusting the traffic ratio of the new algorithm suite to zero, so that all subsequent connections are rolled back to the old algorithm suite in use.

[0018] By introducing canary release and rollback mechanisms, the risk of deploying new algorithm suites is effectively reduced, ensuring the stability and reliability of the system when introducing new PQC algorithms and avoiding large-scale service interruptions caused by problems with new algorithms.

[0019] Optionally, system performance metrics include metrics from the server and metrics from the client; The server-side metrics include at least one of the following: TLS handshake latency, CPU load, memory usage, and handshake error rate. Client metrics include at least one of the following: connection establishment success rate and application request timeout rate; The strategy engine module determines whether the new algorithm suite has any anomalies based on system performance metrics. If an anomaly is found, when sending a rollback command to the strategy engine module, the following specific actions are taken: Based on the system performance metrics, an independent first preset threshold is set for each system performance metric. The monitored system performance metrics are continuously compared with the corresponding first preset threshold. If at least one system performance metric exceeds its corresponding first preset threshold, it is determined that the new algorithm suite is abnormal. If an abnormality is found, a rollback command is sent to the strategy engine module.

[0020] Optionally, when the hybrid certificate automation orchestrator executes instructions from the policy engine module to automatically handle the application, deployment, and rotation of Quantum hybrid certificates, it specifically performs the following: When the hybrid certificate automation orchestrator detects that the remaining validity period of a certificate is lower than the second preset threshold, or senses that the preset certificate management policy has changed, it sends a query request to the policy engine module to obtain the certificate algorithm configuration to be used. The certificate algorithm configuration is determined by the policy engine module according to the predefined certificate management policy. Based on the queried certificate algorithm configuration, generate the corresponding key pair, and use the automated certificate management protocol to send a certificate application request to the certificate authority. The certificate application request includes the target domain name, the mixed public key, and the requested signature algorithm. Upon receiving a hybrid certificate issued by a certificate authority, the hybrid certificate auto-orchestrator automatically deploys the hybrid certificate to the target server and activates the new hybrid certificate by reloading the target server's configuration.

[0021] Secondly, this application also provides a post-quantum hybrid certificate lifecycle automation control method, applied to the post-quantum hybrid certificate lifecycle automation system as described in any of the preceding claims. The post-quantum hybrid certificate lifecycle automation control method includes: S1. During the TLS handshake process, collect and transmit the client's dynamic context vector and security policy vector to the policy engine module; S2. Based on the received dynamic context vector and security policy vector, select the optimal post-quantum hybrid algorithm suite for the TLS handshake from multiple candidate algorithm suites. The dynamic context vector includes metadata of device state information and network state information. S3. Execute the optimal post-quantum hybrid algorithm suite selected by the execution strategy engine module; S4. Based on the instructions of the policy engine module, automatically execute the application, deployment, and rotation of post-quantum hybrid certificates.

[0022] As described above, the automated system and control method for the entire lifecycle of post-quantum hybrid certificates provided in this application dynamically collects the client's context and security policy during the TLS handshake process through an adaptive handshake module and passes it to the policy engine module. Based on this dynamic information, the policy engine module intelligently selects the optimal post-quantum hybrid algorithm suite from multiple candidate algorithm suites. This overcomes the shortcomings of traditional fixed algorithm configurations that cannot adapt to heterogeneous network environments, and avoids potential performance bottlenecks or excessive energy consumption on resource-constrained devices. The hybrid certificate automated orchestrator can automatically execute the application, deployment, and rotation of post-quantum hybrid certificates according to the instructions of the policy engine module, greatly simplifying the complexity of hybrid certificate lifecycle management. It solves the problems of complex certificate management, difficult algorithm adaptation, and high security deployment risks faced during the post-quantum cryptography migration process, providing effective technical support for a smooth and secure transition to the post-quantum cryptography era.

[0023] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing embodiments of this application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings. Attached Figure Description

[0024] Figure 1 A schematic diagram of the structure of the post-quantum hybrid certificate full lifecycle automation system provided in this application embodiment.

[0025] Figure 2 A flowchart illustrating the automated control method for the entire lifecycle of a post-quantum hybrid certificate provided in this application embodiment.

[0026] Labeling Explanation: 101, Policy Engine Module; 102, Adaptive Handshake Module; 103, Hybrid Certificate Automation Orchestrator. Detailed Implementation

[0027] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0028] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0029] Firstly, please refer to Figure 1 This application provides a post-quantum hybrid certificate full lifecycle automation system, including: a policy engine module 101, an adaptive handshake module 102, and a hybrid certificate automation orchestrator 103; The adaptive handshake module 102 is used to collect and transmit the client's dynamic context vector and security policy vector to the policy engine module 101 during the TLS handshake process. The policy engine module 101 is used to select the optimal post-quantum hybrid algorithm suite for TLS handshake from multiple candidate algorithm suites based on the received dynamic context vector and security policy vector. The dynamic context vector includes metadata of device state information and network state information. The adaptive handshake module 102 is also used to execute the optimal post-quantum hybrid algorithm suite selected by the policy engine module 101; Hybrid certificate auto-orchestrator 103 is used to automate the application, deployment and rotation of post-quantum hybrid certificates according to the instructions of policy engine module 101.

[0030] The "TLS handshake" refers to a series of communication steps between the client and server before establishing a secure connection, in which they negotiate encryption algorithms, exchange keys, and verify identities.

[0031] "Dynamic context vector" refers to real-time environmental information collected from the client during the TLS handshake process, including metadata related to device status information (such as CPU load, memory usage, battery level, etc.) and network status information (such as bandwidth, latency, packet loss rate, etc.). This information is used by the policy engine module 101 for algorithm selection.

[0032] "Security policy vectors" refer to predefined security-related configurations and requirements, such as the minimum required security strength, permitted algorithm types, and compliance requirements.

[0033] A “candidate algorithm suite” refers to a set of cryptographic algorithms available for selection. Each suite includes key exchange algorithms, digital signature algorithms, and symmetric encryption algorithms, among others, and includes at least a post-quantum cryptography algorithm.

[0034] This system can be deployed in various network environments, such as cloud environments, enterprise intranets, or Internet of Things (IoT) device networks, to support communication scenarios of different scales and security requirements.

[0035] The adaptive handshake module 102 can be configured to carry the client's dynamic context vector and security policy vector in the ClientHello message of the TLS handshake protocol via extended fields. For example, the client device can have a built-in agent or SDK responsible for real-time monitoring of device status information such as CPU load, memory usage, and battery level, as well as network status information such as network bandwidth, latency, and packet loss rate. This information is encapsulated into a dynamic context vector. Simultaneously, the client can generate a security policy vector based on its preset security configuration or a security policy obtained from a central management platform. These vectors are then collected by the adaptive handshake module 102 and transmitted to the policy engine module 101 via an encrypted channel. Alternatively, the adaptive handshake module 102 can be deeply integrated with the client's operating system or browser, obtaining the necessary dynamic context information through system APIs or browser extensions. The security policy vector can be obtained from a local configuration file or from a policy server via a secure channel. During the TLS handshake process, the adaptive handshake module 102 encodes this information into TLS extended fields and sends it along with the ClientHello message to the server-side policy engine module 101.

[0036] The policy engine module 101 selects the optimal post-quantum hybrid algorithm suite for the TLS handshake from multiple candidate algorithm suites based on the received dynamic context vector and security policy vector. The dynamic context vector includes metadata related to device and network state information. For example, the policy engine module 101 can maintain a database containing multiple post-quantum hybrid algorithm suites, each of which has its performance characteristics pre-evaluated under different device and network conditions. When the policy engine module 101 receives the client's dynamic context vector (e.g., low CPU load, high bandwidth, low latency) and security policy vector (e.g., high security requirement), it scores each candidate algorithm suite in the database based on these inputs using a pre-defined evaluation model or algorithm. The algorithm suite with the highest score is selected as the optimal solution. Alternatively, the policy engine module 101 can employ a rule-based decision system. This system contains a series of predefined rules, such as "if the device CPU load is higher than 80% and the battery level is lower than 20%, then the algorithm suite with lower computational overhead is preferred." When the dynamic context vector and security policy vector are received, the policy engine module 101 will traverse these rules, find the rule that best matches the current conditions, and select the corresponding algorithm suite according to the rule.

[0037] The adaptive handshake module 102 is also used to execute the optimal post-quantum hybrid algorithm suite selected by the policy engine module 101. For example, once the policy engine module 101 determines the optimal algorithm suite, it returns the selection result to the adaptive handshake module 102 via the ServerHello message of the TLS handshake protocol or other negotiation mechanisms. Upon receiving this instruction, the adaptive handshake module 102 immediately configures the TLS connection and uses the post-quantum hybrid algorithm suite specified by the policy engine module 101 for subsequent key exchange, encryption, and signing operations. As an alternative implementation, the adaptive handshake module 102 can preload the implementation code of all candidate algorithm suites. When the policy engine module 101 returns the identifier of the optimal algorithm suite, the adaptive handshake module 102 dynamically loads and activates the corresponding algorithm implementation, thereby ensuring that the TLS connection proceeds according to the optimal policy.

[0038] The hybrid certificate orchestrator 103 is used to automatically execute the application, deployment, and rotation of post-quantum hybrid certificates according to the instructions of the policy engine module 101. For example, the hybrid certificate orchestrator 103 can be configured to periodically check the validity of existing certificates or initiate the certificate management process when it receives a certificate update instruction from the policy engine module 101. When a new certificate needs to be applied for, the orchestrator automatically generates a new key pair (including a base key and a post-quantum key) and initiates a certificate application request to a Certificate Authority (CA) using an automated certificate management protocol (such as the ACME protocol). The request includes the domain name, the hybrid public key, and the required signature algorithm. Once the hybrid certificate issued by the CA is received, the orchestrator automatically deploys it to the target server and makes the new certificate effective by smoothly reloading the server configuration (e.g., Nginx or Apache configuration) without interrupting service. As another implementation, the hybrid certificate orchestrator 103 can be integrated with an enterprise's internal PKI system. When the policy engine module 101 indicates that a certificate needs to be updated, the orchestrator calls the internal PKI system via API to automatically complete key generation, certificate signing, and distribution. During deployment, the orchestrator can use configuration management tools (such as Ansible, Puppet, or Chef) to push new certificates to the target server and perform necessary service restarts or reloads.

[0039] The post-quantum hybrid certificate full lifecycle automation system proposed in this embodiment aims to solve the core problems in the existing technology, such as the complexity of hybrid certificate management, the difficulty of algorithm adaptation in heterogeneous environments, and the lack of secure deployment mechanisms, demonstrating significant technical contributions and innovation.

[0040] Firstly, regarding automated certificate management, existing technologies often rely on manual operations for the application, deployment, and rotation of hybrid certificates. This is not only inefficient and error-prone, but also fails to meet the agile requirements of modern networks for cryptographic algorithms. This application introduces a hybrid certificate automated orchestrator 103 to achieve automated management of the entire lifecycle of post-quantum hybrid certificates. This orchestrator can automatically execute key generation, certificate application, deployment, and rotation operations according to the instructions of the policy engine module 101, significantly reducing operational costs and human error rates, and improving the efficiency and response speed of certificate management. Compared with traditional manual management methods, this system greatly simplifies the operation and maintenance process of hybrid certificates, providing feasibility for large-scale deployment.

[0041] Secondly, regarding dynamic algorithm adaptation, existing technologies using a single hybrid algorithm suite or a fixed algorithm configuration cannot achieve the optimal balance between computational efficiency, bandwidth utilization, and energy consumption in all heterogeneous scenarios. This application collects the client's dynamic context vector (including device status information and network status information) and security policy vector through an adaptive handshake module 102, and passes them to a policy engine module 101. Based on this real-time information, the policy engine module 101 dynamically selects the optimal post-quantum hybrid algorithm suite from multiple candidate algorithm suites. This dynamic selection mechanism enables the system to adaptively adjust the cryptographic algorithm used according to the client device's computing power, network conditions, and security requirements, thereby achieving the best balance between performance, energy consumption, and security. For example, on resource-constrained mobile devices, the system can choose an algorithm suite with lower computational overhead, while on high-performance servers, it can choose a more secure algorithm suite. This intelligent adaptation capability is not available in existing fixed configuration schemes.

[0042] Finally, this system integrates certificate management, algorithm adaptation, and secure deployment into a unified automated system, addressing the lack of a unified solution in existing technologies. By using the policy engine module 101 as the core decision-making unit to coordinate the work of the adaptive handshake module 102 and the hybrid certificate automated orchestrator 103, seamless integration from algorithm selection in the TLS handshake phase to full lifecycle certificate management is achieved. This integrated automated system not only simplifies the post-quantum cryptography migration process but also improves the robustness and security of the entire system. Compared to the fragmented and non-automated solutions in existing technologies, this application provides a comprehensive, efficient, and secure post-quantum cryptography migration path, offering solid technical support for addressing quantum computing threats.

[0043] In some implementations, when the policy engine module 101 selects the optimal post-quantum hybrid algorithm suite from multiple candidate algorithm suites for the TLS handshake based on the received dynamic context vector and security policy vector, it specifically performs the following: Based on the dynamic context vector and security policy vector, obtain the security weight, computational efficiency weight, latency weight, bandwidth weight, security score, computational efficiency score, latency score, and bandwidth score for each candidate algorithm suite; The comprehensive score of the corresponding candidate algorithm suite is calculated based on each security weight, computational efficiency weight, latency weight, bandwidth weight, security score, computational efficiency score, latency score, and bandwidth score. The candidate algorithm suite with the highest overall score is selected as the optimal post-quantum hybrid algorithm suite for TLS handshake selection.

[0044] Specifically, the dynamic context vector refers to metadata reflecting client device state and network state information, collected by the adaptive handshake module 102 and transmitted to the policy engine module 101 during the TLS handshake process. The security policy vector represents preset security requirements and preferences, such as the minimum security strength requirements for cryptographic algorithms. A candidate algorithm suite refers to a set of selectable combinations of post-quantum hybrid cryptographic algorithms, which may include combinations of different key exchange algorithms (such as Kyber and Dilithium) and signature algorithms (such as Falcon and SPHINCS+). Security weight, computational efficiency weight, latency weight, and bandwidth weight represent the importance or priority of different performance dimensions (security, computational efficiency, latency, and bandwidth) during the selection process. These weights are dynamically acquired and adjusted based on the current dynamic context vector and security policy vector. Security score, computational efficiency score, latency score, and bandwidth score represent the inherent performance or evaluation score of each candidate algorithm suite in a specific performance dimension. These scores can be preset benchmark data or dynamically calculated based on historical performance data. The overall score is obtained by weighted summation or other aggregation operations of the weights of each dimension and their corresponding scores, and is used to quantify the overall performance of each candidate algorithm suite. The optimal post-quantum hybrid algorithm suite refers to the algorithm suite that performs best overall under the current dynamic context and security policy.

[0045] This application's solution addresses the lack of refined trade-offs in algorithm suite selection within the basic scheme by introducing a multi-dimensional evaluation mechanism. Specifically, the policy engine module 101 first dynamically acquires security weights, computational efficiency weights, latency weights, and bandwidth weights for each candidate algorithm suite based on the current dynamic context vector (including device status information and network status information) and security policy vector. These weights reflect the importance of each performance indicator in the current environment. For example, computational efficiency weights may be increased on low-power devices; latency and bandwidth weights may be increased during network congestion. Simultaneously, the policy engine module 101 also acquires scores for each candidate algorithm suite in terms of security, computational efficiency, latency, and bandwidth. These scores characterize the inherent performance of the algorithm suite in each dimension. Subsequently, by weighting these dynamic weights with the corresponding scores, a comprehensive score for each candidate algorithm suite is obtained. This comprehensive score comprehensively reflects the overall applicability of the algorithm suite in the current environment. Finally, the algorithm suite with the highest comprehensive score is selected, ensuring that the post-quantum hybrid algorithm suite used in the TLS handshake process not only meets security requirements but also achieves an optimal performance balance, effectively addressing dynamically changing operating environments and security needs.

[0046] In some implementations, when the policy engine module 101 obtains security weights, computational efficiency weights, latency weights, bandwidth weights, security scores, computational efficiency scores, latency scores, and bandwidth scores for each candidate algorithm suite based on the dynamic context vector and the security policy vector, it specifically performs the following: Obtain the security weights based on the security policy vector; The computational efficiency weights are obtained based on dynamic device status information; Based on dynamic network status information, obtain latency weights and bandwidth weights; Based on a preset security level mapping table, a security score is obtained according to the security policy vector. The security level mapping table records a level score that represents the inherent security strength of each candidate algorithm suite, pre-assigned based on authoritative cryptographic standards or internal security policies. Based on the first historical data and dynamic device status information, a computational efficiency score is obtained. The first historical data refers to the performance dataset obtained through offline benchmark testing, which characterizes the inherent computational resource consumption of each candidate algorithm suite when running on a standard computing device. Based on the second historical data and dynamic network status information, latency score and bandwidth score are obtained. The second historical data refers to the performance dataset obtained through offline testing, which characterizes the inherent network resource consumption of each candidate algorithm suite when communicating in a standard network environment.

[0047] Among them, security weight refers to the degree of importance attached to the inherent security strength of the algorithm during the selection process of algorithm suite, and it is obtained directly based on the security policy vector. The security policy vector can include predefined security levels or specific requirements such as "high security", "balanced performance and security" or "low resource consumption". The policy engine module 101 dynamically adjusts the security weight according to these requirements to ensure that the selected algorithm suite meets the current security compliance or business needs.

[0048] Computational efficiency weight refers to the degree of importance placed on the computational resource consumption of algorithms during the selection of algorithm suites. It is obtained based on dynamic device status information, which can include real-time data such as CPU load, memory usage, and remaining battery power. When device resources are strained, the computational efficiency weight is increased to prioritize algorithm suites with lower computational overhead and avoid overloading the device.

[0049] Latency weight and bandwidth weight refer to the degree of importance placed on algorithm communication latency and bandwidth consumption, respectively, during the algorithm suite selection process. These weights are obtained based on dynamic network status information, which may include real-time network latency, available bandwidth, and packet loss rate. When the network environment is poor (e.g., high latency, low bandwidth), the latency weight and bandwidth weight are increased to prioritize algorithm suites that consume fewer network resources and have higher transmission efficiency.

[0050] The security score is a quantitative indicator measuring the inherent security strength of each candidate algorithm suite. It is obtained based on a pre-configured security level mapping table and security policy vectors. The security level mapping table is a pre-configured database that records the inherent security strength level score assigned to each candidate algorithm suite based on authoritative cryptographic standards (such as NIST standards) or internal security policies. For example, an algorithm suite conforming to the NIST PQC standard may receive a higher security score. The policy engine module 101, in conjunction with the current security policy vector, queries this mapping table to obtain the corresponding security score.

[0051] The computational efficiency score is a performance metric that measures the computational resource consumption of each candidate algorithm suite. It is obtained based on initial historical data and dynamic device status information. The initial historical data is a performance dataset obtained through offline benchmarking, characterizing the inherent resource consumption of each candidate algorithm suite when running on standard computing devices, such as CPU cycles and memory usage. The strategy engine module 101, combined with current device status information, can weight or adjust this historical data to more accurately reflect the computational efficiency performance of the algorithm suite under current device conditions.

[0052] Latency and bandwidth scores are performance metrics for each candidate algorithm suite in terms of network resource consumption. These scores are obtained based on second historical data and dynamic network state information. The second historical data is a performance dataset obtained through offline testing, characterizing the inherent network resource consumption of each candidate algorithm suite when communicating in a standard network environment, such as handshake latency and packet size. The policy engine module 101, combined with the current dynamic network state information, can weight or adjust this historical data to more accurately reflect the latency and bandwidth performance of the algorithm suite under current network conditions.

[0053] This application's solution achieves more refined algorithm suite selection by refining the methods for obtaining weights and scores. Specifically, the security weight is directly obtained from the security policy vector, ensuring that the algorithm selection complies with the security policy requirements; the computational efficiency weight is obtained from dynamic device status information, reflecting the device's current computing power and thus selecting the algorithm with the least impact on device load; the latency and bandwidth weights are obtained from dynamic network status information, adapting to changes in the network environment and selecting the algorithm with the least network resource consumption. Furthermore, the security score is obtained through a pre-defined security level mapping table, ensuring the inherent security of the algorithm; the computational efficiency score, latency score, and bandwidth score are obtained from historical data from offline benchmark tests and offline network tests, respectively, reflecting the algorithm's performance in actual operation.

[0054] Through the aforementioned technical solution, the policy engine module 101 can more accurately evaluate the performance of each candidate algorithm suite, thereby selecting the optimal post-quantum hybrid algorithm suite. This dynamic and refined evaluation mechanism enables the system to better adapt to constantly changing device states, network environments, and security policies, significantly improving the accuracy and efficiency of algorithm suite selection. This not only optimizes resource utilization and reduces system operating costs but also provides a smoother and more efficient user experience while ensuring security.

[0055] In some implementations, when the policy engine module 101 calculates the comprehensive score of the corresponding candidate algorithm suite based on various security weights, computational efficiency weights, latency weights, bandwidth weights, security score values, computational efficiency score values, latency score values, and bandwidth score values, it specifically performs the following: Based on the various security weights, computational efficiency weights, latency weights, bandwidth weights, security scores, computational efficiency scores, latency scores, and bandwidth scores, the comprehensive score of the corresponding candidate algorithm suite is calculated using the following formula: Si(t)=α(C(t),P)*F_delay+β(C(t),P)*F_security+γ(C(t),P)*F_bandwidth+δ(C(t),P)*F_computation; Where Si(t) is the overall score of the i-th candidate algorithm suite, C(t) is the connection dynamic context vector at time t, including the network state vector N(t) and the device state vector D(t); P is the security policy vector; F_delay is the delay score, F_security is the security score, F_bandwidth is the bandwidth score, and F_computation is the computational efficiency score. α(C(t), P) is the delay weight dynamically calculated based on the connection dynamic context vector and security policy vector at time t, β(C(t), P) is the security weight dynamically calculated based on the connection dynamic context vector and security policy vector at time t, γ(C(t), P) is the bandwidth weight dynamically calculated based on the connection dynamic context vector and security policy vector at time t, and δ(C(t), P) is the computational efficiency weight dynamically calculated based on the connection dynamic context vector and security policy vector at time t, and satisfies α(C(t), P) + β(C(t), P) + γ(C(t), P) + δ(C(t), P) = 1.

[0056] This application addresses the issue of ambiguous comprehensive score calculation by introducing a clear weighted summation formula. This formula weights and combines the scores of candidate algorithm suites across four key dimensions: latency, security, bandwidth, and computational efficiency, resulting in a quantified comprehensive score. The weights (α, β, γ, δ) are dynamically calculated based on the real-time connection context vector C(t) and the preset security policy vector P.

[0057] Among them, α(C(t),P)=α0+k_α*(rtt(t)-rtt_threshold); In the formula, α0 is the baseline value of the delay weight (determined by the security policy vector P, reflecting the basic importance that the business attaches to delay), k_α is the adjustment coefficient of the delay weight (determining the sensitivity of network delay changes to the delay weight), rtt(t) is the network round-trip delay at time t (a key component of the network state vector N(t)), and rtt_threshold is the preset network delay threshold. Where β(C(t), P) is directly determined by the security policy vector P, for example, by directly setting the corresponding security weight according to the security level; Among them, γ(C(t),P)=γ0+k_γ*(1 / available_bandwidth(t)); In the formula, γ0 is the baseline value of the bandwidth weight (determined by the security policy vector P), k_γ is the adjustment coefficient of the bandwidth weight, and available_bandwidth(t) is the available bandwidth at time t (a key component of the network state vector N(t)). Among them, δ(C(t),P)=δ0+k_δ_cpu*cpu_load(t)+k_δ_battery*(1-battery_level(t)); In the formula, δ0 is the baseline value for calculating the efficiency weight (determined by the security policy vector P), k_δ_cpu is the adjustment coefficient of the device CPU load, cpu_load(t) is the device CPU load at time t (a component of the device state vector D(t)), k_δ_battery is the adjustment coefficient of the device remaining power, and battery_level(t) is the device remaining power at time t (a component of the device state vector D(t)).

[0058] This means that when the network environment (such as network state vector N(t)) or device status (such as device state vector D(t)) changes, or when the security policy P is adjusted, the weights of each component will be dynamically adjusted to reflect the relative importance of each performance indicator in the current environment. For example, in a low-bandwidth network environment, the bandwidth weight γ(C(t), P) will be increased, allowing algorithm suites with high bandwidth efficiency to obtain higher overall scores; on devices with limited computing resources, the computational efficiency weight δ(C(t), P) will be increased to prioritize algorithm suites with low computational overhead. Through this dynamic weighting mechanism, the policy engine module 101 can perform refined evaluation of candidate algorithm suites based on the actual operating environment and security requirements, thereby ensuring that the selected post-quantum hybrid algorithm suite is optimal and can maximize the balance between security, performance, and resource consumption.

[0059] Through the above technical solution, this application provides a clear and quantifiable comprehensive score calculation method, significantly improving the accuracy and reliability of the policy engine module 101 in selecting the optimal post-quantum hybrid algorithm suite. This formula dynamically adjusts the weights of various performance indicators, enabling the system to flexibly adapt to different operating scenarios based on real-time network environment, device status, and security policies, thus selecting the most suitable algorithm suite under various conditions. This dynamic adaptability avoids the limitations of traditional static evaluation methods, ensuring that the TLS handshake achieves the optimal balance between security, efficiency, and resource utilization. Furthermore, the clear calculation formula reduces the interference of subjective judgment, making the algorithm suite selection process more transparent and reliable, thereby improving the robustness and performance of the entire automated post-quantum hybrid certificate lifecycle system.

[0060] The following is a concrete example. Suppose that the policy engine module 101 needs to select the optimal post-quantum hybrid algorithm suite for a TLS handshake. There are currently two candidate algorithm suites: Algorithm Suite A and Algorithm Suite B.

[0061] Suppose that at time t, the connection dynamic context vector C(t) indicates that the current network bandwidth is low and the client device CPU load is high, while the security policy vector P requires high security.

[0062] Based on C(t) and P, the policy engine module 101 dynamically calculates the weights of each item: Delay weight α(C(t),P)=0.2; security weight β(C(t),P)=0.4; bandwidth weight γ(C(t),P)=0.3; computational efficiency weight δ(C(t),P)=0.1; then α(C(t),P)+β(C(t),P)+γ(C(t),P)+δ(C(t),P)=0.2+0.4+0.3+0.1=1; simultaneously, the policy engine module 101 obtains the score values ​​of the two candidate algorithm suites: For algorithm suite A: F_delay_A = 80 (higher score indicates lower latency); F_security_A = 95 (higher score indicates higher security); F_bandwidth_A = 70 (higher score indicates higher bandwidth efficiency); F_computation_A = 60 (higher score indicates higher computational efficiency). For Algorithm Suite B: F_delay_B=75; F_security_B=90; F_bandwidth_B=85; F_computation_B=50; The overall score is calculated using the formula Si(t)=α(C(t),P)*F_delay+β(C(t),P)*F_security+γ(C(t),P)*F_bandwidth+δ(C(t),P)*F_computation. The overall score of algorithm suite A is Si(t)A = 0.2*80 + 0.4*95 + 0.3*70 + 0.1*60 = 16 + 38 + 21 + 6 = 81; The overall score of algorithm suite B is Si(t)B = 0.2*75 + 0.4*90 + 0.3*85 + 0.1*50 = 15 + 36 + 25.5 + 5 = 81.5; In this example, although algorithm suite A is slightly more secure, due to the high requirements of bandwidth efficiency and latency in the current environment (reflected in the weights), and because algorithm suite B performs better in bandwidth efficiency, the final overall score of algorithm suite B is slightly higher than that of algorithm suite A. Therefore, the policy engine module 101 will select algorithm suite B as the optimal post-quantum hybrid algorithm suite. This example illustrates how dynamic weights affect the final selection, ensuring accurate identification of the optimal algorithm suite in a specific environment.

[0063] In some implementations, device status information includes device CPU load and remaining device battery power; When the strategy engine module 101 obtains the calculation efficiency weight based on dynamic device status information, it specifically performs the following: The efficiency weight is calculated using the following formula, based on the device's CPU load and remaining battery power: δ(t)=δ0+k_δ_cpu*cpu_load(t)+k_δ_battery*(1-battery_level(t)); In the formula, δ(t) is the computational efficiency weight at time t, δ0 is the initial value of the computational efficiency weight, k_δ_cpu is the weight adjustment coefficient of CPU load, cpu_load(t) is the device CPU load at time t, k_δ_battery is the weight adjustment coefficient of battery power, and battery_level(t) is the remaining power of the device at time t.

[0064] Specifically, device status information refers to real-time operational data of client devices, primarily reflecting the device's computing power and resource availability. Among these, device CPU load (cpu_load(t)) refers to the utilization or activity level of the device's central processing unit (CPU) at time t, usually expressed as a percentage, reflecting the current workload of the device's computing tasks. Remaining battery power (battery_level(t)) refers to the remaining battery power level at time t, usually expressed as a percentage, reflecting the device's battery life and energy consumption limitations. Further, the computational efficiency weight δ(t) is a parameter used to evaluate the importance of computational efficiency for different candidate algorithm suites under the current device status. This weight is not a fixed value but is dynamically calculated based on the device's CPU load and remaining battery power. In the formula, δ0 is the initial value of the computational efficiency weight, representing the computational efficiency weight under ideal or baseline device conditions. k_δ_cpu is the CPU load weight adjustment coefficient, used to quantify the impact of CPU load changes on the computational efficiency weight. When the CPU load is high, this coefficient will reduce the computational efficiency weight accordingly, prompting the system to select algorithm suites with lower computational resource consumption. k_δ_battery is a weighting adjustment coefficient for battery power, used to quantify the impact of changes in battery power on the computational efficiency weight. When the device has low remaining battery power, this coefficient reduces the computational efficiency weight to prioritize the selection of lower-energy-consuming algorithm suites, thereby extending the device's battery life. In this way, the computational efficiency weight can more precisely reflect the device's current computing power and energy limitations.

[0065] This application's solution addresses the impact of dynamic device state changes on the computational efficiency of algorithm suites in complex network environments by introducing device CPU load and remaining battery power as key indicators for dynamically adjusting computational efficiency weights. Specifically, when the policy engine module 101 receives the client's dynamic context vector, the device state information (including device CPU load cpu_load(t) and remaining battery power battery_level(t)) is used to calculate the current computational efficiency weight δ(t) in real time. This calculation is implemented through a linear formula, where a higher CPU load results in a smaller computational efficiency weight δ(t), indicating that the system is more inclined to select algorithm suites with lower computational complexity to reduce the CPU burden; conversely, a lower remaining battery power results in a smaller computational efficiency weight δ(t), prompting the system to select algorithm suites with lower energy consumption to extend battery life. This dynamic adjustment mechanism allows the computational efficiency weight to accurately reflect the device's current actual operating state and resource constraints, thereby enabling a more reasonable evaluation of the applicability of each candidate algorithm suite in subsequent comprehensive score calculations. Therefore, the policy engine module 101 can select the truly optimal post-quantum hybrid algorithm suite for TLS handshake based on the real-time status of the device, avoiding performance bottlenecks or handshake failures caused by insufficient device resources, thereby improving the overall stability and reliability of the system.

[0066] In some implementations, the strategy engine module 101 further includes a machine learning unit that optimizes the computational efficiency weights, latency weights, and bandwidth weights using stochastic gradient descent based on historical handshake performance data from each algorithm suite.

[0067] In practical applications, the machine learning unit constructs a loss function based on historical handshake performance data. This loss function quantifies the degree of "suboptimality" in the selection of the algorithm suite under the current weight configuration. For example, if an algorithm suite exhibits high latency or computational cost in practical applications, and its corresponding latency or computational efficiency weights fail to accurately reflect this situation, the loss function value will be high. Through stochastic gradient descent, the machine learning unit can gradually adjust these weights to more accurately reflect the performance characteristics of the algorithm suite in the real-world environment, thereby enabling the policy engine module 101 to select the optimal algorithm suite that better suits the current dynamic context.

[0068] This application's solution introduces a machine learning unit into the policy engine module 101 and utilizes historical handshake performance data from each algorithm suite to dynamically optimize computational efficiency weights, latency weights, and bandwidth weights using stochastic gradient descent. This solves the problem of non-optimal algorithm suite selection caused by fixed or untimely weight adjustments in traditional solutions. Specifically, the machine learning unit continuously collects and analyzes performance data of each algorithm suite during the actual TLS handshake process, which constitutes historical handshake performance data. Based on this data, the machine learning unit can iteratively adjust the computational efficiency weights, latency weights, and bandwidth weights used by the policy engine module 101 to calculate the comprehensive score using stochastic gradient descent. This dynamic adjustment mechanism allows the weights to adaptively optimize according to actual operating conditions and environmental changes, thereby more accurately reflecting the true performance of different algorithm suites under the current network environment and device status. Therefore, when selecting the optimal post-quantum hybrid algorithm suite, the policy engine module 101 uses more precise and real-time weights, ensuring that the selected algorithm suite can adapt to the current dynamic context vector and security policy vector to the greatest extent. This not only improves the efficiency and security of TLS handshake, but also better adapts to dynamically changing network environments and device states, ensuring that the system can maintain high performance and high resource utilization in various complex scenarios. This enhances the intelligence level and robustness of the entire post-quantum hybrid certificate lifecycle automation system.

[0069] In some implementations, the policy engine module 101 also integrates the following secure canary release and rollback mechanisms: In strategy engine module 101, set the initial traffic ratio for the new algorithm suite to be released; During the TLS handshake process, the policy engine module 101 selects whether to use the new algorithm suite or the existing old algorithm suite for the current connection based on the initial traffic ratio. During the release of new algorithm suites, monitor system performance metrics related to both the new and old algorithm suites; The system performance indicators determine whether there are any abnormalities in the new algorithm suite. If there are any abnormalities, a rollback command is sent to the strategy engine module 101. In response to the rollback command, the policy engine module 101 adjusts the traffic ratio of the new algorithm suite to zero so that all subsequent connections are rolled back to the old algorithm suite in use.

[0070] Specifically, the secure canary release and rollback mechanism refers to a controlled deployment strategy designed to introduce new algorithm suites in stages and on a small scale, with real-time monitoring during their operation. If problems are detected, a rapid rollback to a stable state is possible. "Setting an initial traffic percentage for the new algorithm suite to be released" refers to the percentage of connection requests or user traffic allocated to the new algorithm suite during the canary release phase. This percentage can be flexibly configured based on the maturity of the new algorithm, expected risks, and the system's risk tolerance; for example, it can be set to 1%, 5%, or 10%. During the TLS handshake process, the policy engine module 101 dynamically selects whether to use the new algorithm suite or the existing old algorithm suite for the current connection based on this preset initial traffic percentage, using methods such as random number generation or hash algorithms. This means that only a small portion of connections will attempt to use the new algorithm suite, thus limiting the impact of potential problems.

[0071] During the release of the new algorithm suite, the system continuously monitors system performance metrics related to both the new and old algorithm suites. These metrics may include, but are not limited to, TLS handshake latency, CPU load, memory usage, handshake error rate, connection establishment success rate, and application request timeout rate. By collecting and analyzing this data in real time, the performance of the new algorithm suite in the actual operating environment can be objectively evaluated. Furthermore, determining whether the new algorithm suite is abnormal based on system performance metrics is achieved by comparing the monitored system performance metrics with preset thresholds. For example, if the handshake error rate of the new algorithm suite is significantly higher than that of the old algorithm suite, or exceeds a preset error rate limit, it can be determined that the new algorithm suite is abnormal. Once an anomaly is detected, the system automatically generates and sends a rollback command to the policy engine module 101. Upon receiving the rollback command, the policy engine module 101 responds quickly, adjusting the traffic ratio of the new algorithm suite to zero. As a result, all subsequent TLS connections will automatically roll back to using the verified and stable old algorithm suite, thereby isolating the problem in the shortest possible time and ensuring service continuity and stability.

[0072] Through the above technical solution, this application achieves effective risk management during the deployment of post-quantum hybrid algorithm suites. Compared to the uncontrollable risks that may arise from directly deploying new algorithms across the board, the canary release mechanism of this application allows for small-scale, controlled testing of the new algorithm suite in a real production environment, thereby enabling the discovery of potential compatibility, performance, or security issues at an early stage. Once an anomaly is detected, the automatic rollback mechanism can quickly switch traffic back to the stable old algorithm suite, minimizing the impact on user services and avoiding large-scale service interruptions. Therefore, this solution significantly improves the stability and availability of the system when introducing new technologies, providing a solid guarantee for the smooth transition and secure deployment of post-quantum cryptographic algorithms, and reducing the operational risks for enterprises during technology upgrades.

[0073] In some implementations, system performance metrics include metrics from the server and metrics from the client; The server-side metrics include at least one of the following: TLS handshake latency, CPU load, memory usage, and handshake error rate. Client metrics include at least one of the following: connection establishment success rate and application request timeout rate; When the strategy engine module 101 executes a system performance metric to determine if the new algorithm suite has any anomalies, and if an anomaly is found, it sends a rollback command to the strategy engine module 101, specifically executing the following: Based on the system performance indicators, an independent first preset threshold is set for each system performance indicator. The monitored system performance indicators are continuously compared with the corresponding first preset threshold. If at least one system performance indicator exceeds its corresponding first preset threshold, it is determined that the new algorithm suite is abnormal. If an abnormality is found, a rollback command is sent to the strategy engine module 101.

[0074] Specifically, system performance metrics can be understood as key performance parameters used to measure the performance of a new algorithm suite in a real-world operating environment. These metrics are divided into two categories: server-side metrics and client-side metrics. Server-side metrics primarily reflect the resource consumption and processing efficiency of the new algorithm suite on the server side. For example, TLS handshake latency aims to assess the additional computational or communication overhead introduced by the new algorithm suite; CPU load and memory utilization are used to monitor whether server resources are excessively consumed due to the operation of the new algorithm suite; and the handshake error rate directly reflects the stability and compatibility of the new algorithm suite when establishing secure connections. Client-side metrics focus on user experience and service availability. For example, connection establishment success rate aims to measure whether the client can successfully establish a secure connection with the server; and application request timeout rate is used to assess whether the new algorithm suite causes application-level response latency or failure.

[0075] Setting an independent first preset threshold for each system performance indicator means pre-setting an upper or lower limit value for different performance indicators based on their characteristics and acceptable fluctuation range. For example, a maximum acceptable number of milliseconds can be set for TLS handshake latency; a percentage upper limit can be set for CPU load; and a minimum acceptable percentage can be set for connection establishment success rate. These first preset thresholds can be determined based on historical data, system baselines, or service level agreements (SLAs). Continuously comparing the monitored system performance indicators with their corresponding first preset thresholds aims to evaluate the operational status of the new algorithm suite in real time. Once at least one system performance indicator exceeds its corresponding first preset threshold—for example, if the TLS handshake latency exceeds the preset upper limit or the connection establishment success rate falls below the preset lower limit—the new algorithm suite is immediately deemed abnormal. Consequently, the policy engine module 101 will receive a rollback instruction and process it according to the preset rollback strategy.

[0076] This application's solution effectively addresses the shortcomings in accuracy and timeliness of anomaly detection in basic solutions by introducing refined system performance metrics and a threshold-based anomaly detection mechanism. Specifically, by simultaneously monitoring server-side metrics (such as TLS handshake latency, CPU load, memory usage, and handshake error rate) and client-side metrics (such as connection establishment success rate and application request timeout rate), the operational status of the new algorithm suite can be comprehensively evaluated from multiple dimensions, including system resource consumption, connection stability, and user experience. Server-side metrics directly reflect the impact of the new algorithm suite on the backend infrastructure, while client-side metrics can promptly capture changes perceived by the user. Furthermore, setting an independent first preset threshold for each system performance metric makes the anomaly detection process more refined and objective. When any monitored metric exceeds its corresponding first preset threshold, it is considered that the new algorithm suite has an anomaly, thus enabling rapid and accurate identification of potential problems and timely triggering of rollback instructions. This multi-dimensional, threshold-based monitoring and detection mechanism ensures that any performance degradation or compatibility issues caused by the new algorithm suite can be quickly captured during the canary release process, providing a reliable basis for subsequent automatic rollback operations.

[0077] Through the above technical solution, this application can significantly improve the accuracy and timeliness of anomaly detection for new algorithm suites. Multi-dimensional system performance indicator monitoring, combined with independently set first preset thresholds for each indicator, enables the system to comprehensively and meticulously evaluate the operational status of the new algorithm suite, avoiding misjudgments or omissions that may arise from single indicators or fuzzy judgments. Once an anomaly is detected, the system can quickly trigger a rollback command, switching traffic back to the stable old algorithm suite, thereby effectively reducing the risk of deploying new algorithms and avoiding large-scale service interruptions caused by compatibility or performance issues with the new algorithms. Therefore, this application greatly enhances the stability and availability of the post-quantum hybrid certificate lifecycle automation system, providing enterprises with a safer and more reliable algorithm upgrade path.

[0078] In some preferred embodiments, it is assumed that the policy engine module 101 is conducting a canary release of a new post-quantum hybrid algorithm suite. To monitor its operational status, the system continuously collects the following performance metrics: server-side TLS handshake latency, CPU load, memory utilization, and handshake error rate, while also collecting client-side connection establishment success rate and application request timeout rate. Specifically, the following first preset thresholds are set for these metrics: a TLS handshake latency threshold of 200 milliseconds, a CPU load threshold of 80%, a memory utilization threshold of 90%, a handshake error rate threshold of 0.5%, a connection establishment success rate threshold of 99%, and an application request timeout rate threshold of 1%. During the canary release process, if the system detects that the TLS handshake latency of the new algorithm suite consistently exceeds 200 milliseconds, or that the connection establishment success rate drops to 98% (below the 99% threshold), even if other metrics remain within the normal range, the policy engine module 101 will immediately determine that the new algorithm suite is abnormal. Subsequently, the policy engine module 101 will receive the rollback instruction and quickly adjust the traffic ratio of the new algorithm suite to zero, ensuring that all subsequent connections are rolled back to use the original old algorithm suite, thereby avoiding potential service interruptions.

[0079] In some implementations, when the hybrid certificate automation orchestrator 103 executes instructions from the policy engine module 101 to automatically process the application, deployment, and rotation of post-quantum hybrid certificates, it specifically performs the following: When the hybrid certificate automation orchestrator 103 detects that the remaining validity period of a certificate is lower than the second preset threshold, or senses that the preset certificate management policy has changed, it sends a query request to the policy engine module 101 to obtain the certificate algorithm configuration to be used. The certificate algorithm configuration is determined by the policy engine module 101 according to the predefined certificate management policy. Based on the queried certificate algorithm configuration, generate the corresponding key pair, and use the automated certificate management protocol to send a certificate application request to the certificate authority. The certificate application request includes the target domain name, the mixed public key, and the requested signature algorithm. After receiving a hybrid certificate issued by a certificate authority, the hybrid certificate auto-orchestrator 103 automatically deploys the hybrid certificate to the target server and makes the new hybrid certificate effective by reloading the configuration of the target server.

[0080] Specifically, the hybrid certificate automated orchestrator 103 is configured to continuously monitor the status of deployed certificates in the system. "The remaining validity period of a certificate is lower than a second preset threshold" means that the system will trigger a certificate renewal process when the certificate's validity period is about to expire. This second preset threshold can be set according to actual needs; for example, it could be 30, 60, or 90 days before the certificate expires, allowing sufficient time to complete the certificate application and deployment. Furthermore, "Detecting a change in the preset certificate management policy" means that when the system administrator updates the certificate usage policy, such as changing the recommended encryption algorithm, key length, or certificate authority, the orchestrator can also respond promptly and initiate the update process.

[0081] When any of the above conditions are met, the hybrid certificate auto-orchestrator 103 sends a query request to the policy engine module 101. The purpose of this query request is to obtain the most suitable certificate algorithm configuration for the current environment. The policy engine module 101 then determines and returns the optimal certificate algorithm configuration based on predefined certificate management policies, combined with the security requirements and performance considerations of the current system. This configuration may include information such as the required hybrid encryption algorithm type, signature algorithm type, and key length.

[0082] After obtaining the certificate algorithm configuration, the hybrid certificate orchestrator 103 automatically generates a new key pair, namely a public key and a private key, based on this configuration. Since this system involves post-quantum cryptography, the generated key pair will be a hybrid public key, combining characteristics of traditional and post-quantum cryptography. Subsequently, the orchestrator uses an automated certificate management protocol (such as the ACME protocol) to initiate a certificate request to a pre-defined certificate authority. This request includes the target server's domain name, the newly generated hybrid public key, and the requested signature algorithm, ensuring that the certificate authority can correctly issue a compliant hybrid certificate.

[0083] Once the hybrid certificate orchestrator 103 successfully receives the hybrid certificate issued by the certificate authority, it will automatically perform the certificate deployment operation. Specifically, the hybrid certificate will be deployed to the target server, replacing the old certificate that is about to expire or does not conform to the new policy. To ensure that the new hybrid certificate takes effect immediately, the hybrid certificate orchestrator 103 will also reload the target server's configuration, such as restarting the relevant web services or TLS services, thereby ensuring that all subsequent TLS connections can use the new hybrid certificate for encryption and authentication.

[0084] The solution presented in this application effectively addresses the inefficiencies and security risks inherent in traditional certificate management by introducing an intelligent monitoring and automated processing mechanism within a hybrid certificate orchestrator 103. Specifically, the hybrid certificate orchestrator 103 proactively manages the certificate lifecycle by continuously monitoring the remaining validity period of certificates and changes in certificate management policies. When a certificate update is detected, the orchestrator no longer relies on manual judgment but automatically queries the policy engine module 101 for the latest certificate algorithm configuration, ensuring that the applied certificate always complies with current security policies and system requirements.

[0085] Furthermore, the orchestrator automatically generates key pairs based on the acquired configuration and initiates an application with the Certificate Authority (CA), avoiding errors and delays that might be introduced by manual operation. Upon receiving the issued hybrid certificate, the orchestrator can automatically deploy it to the target server and reload the configuration to make it effective, thus automating the entire certificate application and deployment process. This automation mechanism ensures that certificates are updated in a timely and accurate manner, avoiding service interruptions or security vulnerabilities caused by expired certificates or policy inconsistencies. Therefore, the entire post-quantum hybrid certificate lifecycle management becomes more efficient, reliable, and secure.

[0086] Through the above technical solutions, this application significantly improves the automation level of the entire lifecycle management of post-quantum hybrid certificates. First, by intelligently monitoring certificate validity and management policies, the system can proactively identify certificate update needs, avoiding the risk of certificate expiration due to human error. Second, the linkage with the policy engine module 101 ensures that the applied hybrid certificates always use the optimal algorithm configuration that conforms to the latest security policies, enhancing the overall security of the system. Furthermore, the automated process of generating key pairs, initiating certificate applications, and deploying and activating certificates greatly reduces manual intervention, lowering operational costs and the possibility of human error. Finally, this solution ensures that post-quantum hybrid certificates can be rotated and updated in a timely and seamless manner, thereby continuously and effectively addressing potential quantum computing attack threats and guaranteeing the confidentiality and integrity of communications.

[0087] Secondly, please refer to Figure 2This application also provides a post-quantum hybrid certificate lifecycle automation control method, applied to the post-quantum hybrid certificate lifecycle automation system as described in any of the preceding claims. The post-quantum hybrid certificate lifecycle automation control method includes: S1. During the TLS handshake process, collect and transmit the client's dynamic context vector and security policy vector to the policy engine module 101; S2. Based on the received dynamic context vector and security policy vector, select the optimal post-quantum hybrid algorithm suite for the TLS handshake from multiple candidate algorithm suites. The dynamic context vector includes metadata of device state information and network state information. S3. The optimal post-quantum hybrid algorithm suite selected by the execution strategy engine module 101; S4. Based on the instructions of the policy engine module 101, automatically execute the application, deployment, and rotation of post-quantum hybrid certificates.

[0088] The solution proposed in this application achieves dynamic selection of the post-quantum hybrid algorithm suite by combining dynamic information during the TLS handshake process with the intelligent decision-making of the policy engine module 101. Specifically, the adaptive handshake module 102 collects the client's dynamic context vector and security policy vector at the beginning of the TLS handshake. This information comprehensively reflects the client's real-time operating environment and security requirements. Subsequently, these vectors are passed to the policy engine module 101. Based on this real-time data and preset logic, the policy engine module 101 can intelligently evaluate and select the optimal post-quantum hybrid algorithm suite for the current environment from multiple candidate algorithm suites. This dynamic selection mechanism enables the system to adjust the encryption policy according to the actual situation, such as prioritizing low-latency algorithms when network conditions are poor, or selecting computationally efficient algorithms when device resources are limited, while always meeting the requirements of the security policy.

[0089] Furthermore, this method achieves automated lifecycle management of post-quantum hybrid certificates through the collaborative work of the hybrid certificate automation orchestrator 103 and the policy engine module 101. The policy engine module 101 is not only responsible for selecting algorithm suites but also issues instructions to the hybrid certificate automation orchestrator 103 based on certificate management policies or system status. The hybrid certificate automation orchestrator 103 responds to these instructions, automating tedious tasks such as certificate application, deployment, and rotation. This tight integration and automation effectively avoids the errors and delays that may result from traditional manual certificate management, ensuring timely certificate updates and validity, thereby maintaining the continuous secure operation of the system.

[0090] Through the above technical solution, this application enables automated control of the entire lifecycle of post-quantum hybrid certificates, significantly reducing manual maintenance costs and greatly improving system efficiency and security. The mechanism of dynamically selecting the optimal algorithm suite allows the system to flexibly adapt to the needs of different client device states and network environments, ensuring compatibility and performance optimization of the TLS handshake process. Simultaneously, the automated certificate application, deployment, and rotation functions ensure that certificates are always up-to-date and valid, effectively mitigating security risks caused by certificate expiration or mismanagement. This comprehensive automated control method provides an efficient, reliable, and adaptive solution for network security communication in the post-quantum cryptography era.

[0091] This embodiment provides a post-quantum hybrid certificate lifecycle automation control method, which is applied to the post-quantum hybrid certificate lifecycle automation control system provided in the first aspect above. The principle of the post-quantum hybrid certificate lifecycle automation control method provided in this embodiment is the same as that of the post-quantum hybrid certificate lifecycle automation control system provided in the first aspect above, and will not be discussed in detail here.

[0092] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0093] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A post-quantum hybrid certificate full lifecycle automation system, characterized in that, include: Policy engine module (101), adaptive handshake module (102), and hybrid certificate automation orchestrator (103). An adaptive handshake module (102) is used to collect and transmit the client's dynamic context vector and security policy vector to the policy engine module (101) during the TLS handshake process. The policy engine module (101) is used to select the optimal post-quantum hybrid algorithm suite for TLS handshake from multiple candidate algorithm suites based on the received dynamic context vector and security policy vector. The dynamic context vector includes metadata of device state information and network state information. The adaptive handshake module (102) is also used to execute the optimal post-quantum hybrid algorithm suite selected by the policy engine module (101); A hybrid certificate auto-orchestrator (103) is used to automate the application, deployment and rotation of post-quantum hybrid certificates according to the instructions of the policy engine module (101).

2. The post-quantum hybrid certificate full lifecycle automation system according to claim 1, characterized in that, When the policy engine module (101) selects the optimal post-quantum hybrid algorithm suite from multiple candidate algorithm suites for the TLS handshake based on the received dynamic context vector and security policy vector, it specifically performs the following: Based on the dynamic context vector and security policy vector, obtain the security weight, computational efficiency weight, latency weight, bandwidth weight, security score, computational efficiency score, latency score, and bandwidth score for each candidate algorithm suite; The comprehensive score of the corresponding candidate algorithm suite is calculated based on each security weight, computational efficiency weight, latency weight, bandwidth weight, security score, computational efficiency score, latency score, and bandwidth score. The candidate algorithm suite with the highest overall score is selected as the optimal post-quantum hybrid algorithm suite for TLS handshake selection.

3. The post-quantum hybrid certificate full lifecycle automation system according to claim 2, characterized in that, When the policy engine module (101) performs the following steps to obtain the security weight, computational efficiency weight, latency weight, bandwidth weight, security score, computational efficiency score, latency score, and bandwidth score for each candidate algorithm suite based on the dynamic context vector and security policy vector: Obtain the security weights based on the security policy vector; The computational efficiency weights are obtained based on dynamic device status information; Based on dynamic network status information, obtain latency weights and bandwidth weights; Based on a preset security level mapping table, a security score is obtained according to the security policy vector. The security level mapping table records a level score that represents the inherent security strength of each candidate algorithm suite, pre-assigned based on authoritative cryptographic standards or internal security policies. Based on the first historical data and dynamic device status information, a computational efficiency score is obtained. The first historical data refers to the performance dataset obtained through offline benchmark testing, which characterizes the inherent computational resource consumption of each candidate algorithm suite when running on a standard computing device. Based on the second historical data and dynamic network status information, latency score and bandwidth score are obtained. The second historical data refers to the performance dataset obtained through offline testing, which characterizes the inherent network resource consumption of each candidate algorithm suite when communicating in a standard network environment.

4. The post-quantum hybrid certificate full lifecycle automation system according to claim 2, characterized in that, When the strategy engine module (101) calculates the comprehensive score of the corresponding candidate algorithm suite based on each security weight, computational efficiency weight, latency weight, bandwidth weight, security score, computational efficiency score, latency score, and bandwidth score, it specifically performs the following: Based on the various security weights, computational efficiency weights, latency weights, bandwidth weights, security scores, computational efficiency scores, latency scores, and bandwidth scores, the comprehensive score of the corresponding candidate algorithm suite is calculated using the following formula: Si(t)=α(C(t),P)*F_delay+β(C(t),P)*F_security+γ(C(t),P)*F_bandwidth+δ(C(t),P)*F_computation; Where Si(t) is the overall score of the i-th candidate algorithm suite, C(t) is the connection dynamic context vector at time t, including the network state vector N(t) and the device state vector D(t); P is the security policy vector; F_delay is the delay score, F_security is the security score, F_bandwidth is the bandwidth score, and F_computation is the computational efficiency score. α(C(t), P) is the delay weight dynamically calculated based on the connection dynamic context vector and security policy vector at time t, β(C(t), P) is the security weight dynamically calculated based on the connection dynamic context vector and security policy vector at time t, γ(C(t), P) is the bandwidth weight dynamically calculated based on the connection dynamic context vector and security policy vector at time t, and δ(C(t), P) is the computational efficiency weight dynamically calculated based on the connection dynamic context vector and security policy vector at time t, and satisfies α(C(t), P) + β(C(t), P) + γ(C(t), P) + δ(C(t), P) = 1.

5. The post-quantum hybrid certificate full lifecycle automation system according to claim 3, characterized in that, Device status information includes device CPU load and remaining battery power; When the strategy engine module (101) obtains the calculation efficiency weight based on dynamic device status information, it specifically performs the following: The efficiency weight is calculated using the following formula, based on the device's CPU load and remaining battery power: δ(t)=δ0+k_δ_cpu*cpu_load(t)+k_δ_battery*(1-battery_level(t)); In the formula, δ(t) is the computational efficiency weight at time t, δ0 is the initial value of the computational efficiency weight, k_δ_cpu is the weight adjustment coefficient of CPU load, cpu_load(t) is the device CPU load at time t, k_δ_battery is the weight adjustment coefficient of battery power, and battery_level(t) is the remaining power of the device at time t.

6. The post-quantum hybrid certificate full lifecycle automation system according to claim 2, characterized in that, The strategy engine module (101) also includes a machine learning unit, which optimizes the computation efficiency weights, latency weights, and bandwidth weights using stochastic gradient descent based on the historical handshake performance data of each algorithm suite.

7. The post-quantum hybrid certificate full lifecycle automation system according to claim 1, characterized in that, The strategy engine module (101) also integrates the following secure canary release and rollback mechanisms: In the strategy engine module (101), set the initial traffic ratio for the new algorithm suite to be released; During the TLS handshake process, the policy engine module (101) selects whether to use the new algorithm suite or the original old algorithm suite for the current connection based on the initial traffic ratio. During the release of new algorithm suites, monitor system performance metrics related to both the new and old algorithm suites; Based on the system performance indicators, determine whether there is an anomaly in the new algorithm suite. If there is an anomaly, send a rollback command to the strategy engine module (101). The policy engine module (101) responds to the rollback command by adjusting the traffic ratio of the new algorithm suite to zero so that all subsequent connections are rolled back to the old algorithm suite used.

8. The post-quantum hybrid certificate full lifecycle automation system according to claim 7, characterized in that, System performance metrics include metrics from the server side and metrics from the client side; The server-side metrics include at least one of the following: TLS handshake latency, CPU load, memory usage, and handshake error rate. Client metrics include at least one of the following: connection establishment success rate and application request timeout rate; The strategy engine module (101) executes a judgment based on system performance indicators to determine whether there are any anomalies in the new algorithm suite. If there are any anomalies, when sending a rollback instruction to the strategy engine module (101), the following specific actions are taken: Based on the system performance indicators, an independent first preset threshold is set for each system performance indicator. The monitored system performance indicators are continuously compared with the corresponding first preset threshold. If at least one system performance indicator exceeds its corresponding first preset threshold, it is determined that the new algorithm suite is abnormal. If an abnormality exists, a rollback instruction is sent to the strategy engine module (101).

9. The post-quantum hybrid certificate full lifecycle automation system according to claim 1, characterized in that, When the hybrid certificate auto-orchestrator (103) executes instructions from the policy engine module (101) to automatically handle the application, deployment, and rotation of post-quantum hybrid certificates, it specifically performs the following: When the hybrid certificate automation orchestrator (103) detects that the remaining validity period of the certificate is lower than the second preset threshold, or senses that the preset certificate management policy has changed, it sends a query request to the policy engine module (101) to obtain the certificate algorithm configuration to be used. The certificate algorithm configuration is determined by the policy engine module (101) according to the predefined certificate management policy. Based on the queried certificate algorithm configuration, generate the corresponding key pair, and use the automated certificate management protocol to send a certificate application request to the certificate authority. The certificate application request includes the target domain name, the mixed public key, and the requested signature algorithm. After receiving a hybrid certificate issued by a certificate authority, the hybrid certificate auto-orchestrator (103) automatically deploys the hybrid certificate to the target server and makes the new hybrid certificate effective by reloading the configuration of the target server.

10. A method for fully automated control of the entire lifecycle of a post-quantum hybrid certificate, characterized in that, Applied to any one of claims 1-9, the post-quantum hybrid certificate lifecycle automation control method includes: S1. During the TLS handshake process, collect and transmit the client's dynamic context vector and security policy vector to the policy engine module (101). S2. Based on the received dynamic context vector and security policy vector, select the optimal post-quantum hybrid algorithm suite for the TLS handshake from multiple candidate algorithm suites. The dynamic context vector includes metadata of device state information and network state information. S3. Execute the optimal post-quantum hybrid algorithm suite selected by the execution strategy engine module (101); S4. Automated execution of the application, deployment and rotation of post-quantum hybrid certificates according to the instructions of the policy engine module (101).

Images