Anti-quantum cryptography algorithm-based interfacing and servitization capability implementation method

Abstract

The invention discloses an interfacing and servitization capability implementation method based on an anti-quantum cryptographic algorithm, and aims to solve the problems of quantum attack risk of a traditional public key cryptographic algorithm, difficulty in integration implementation of an existing PQC, poor performance and the like. The core of the method is that an anti-quantum cryptography algorithm subjected to NIST evaluation is packaged into a standardized interface, and service deployment is realized through a cloud-edge-end collaborative architecture. The process comprises four stages of algorithm selection, interface design, servitization deployment and performance optimization, the principles of modularization, low coupling and the like are followed, an interface supports double protocols of gRPC and RESTful API, a plug-in architecture is adopted to adapt to algorithm extension, and the performance is improved through FFT optimization and hardware acceleration. The method can resist quantum attacks, is compatible with existing software and hardware environments, adapts to multiple fields such as cloud computing, Internet of Things, finance and power grids, can guarantee data security and system expandability, and is remarkable in practical value.

Description

Technical Field

[0001] This invention relates to the field of cryptographic technology and service architecture, specifically a method for implementing interface and service capabilities based on quantum-resistant cryptographic algorithms. It is applicable to fields such as cloud computing, the Internet of Things, finance, and power grids, providing efficient, secure, and scalable cryptographic service support for data encryption, identity authentication, and other scenarios in the post-quantum era. Background Technology

[0002] With the development of quantum computing technology, traditional public-key cryptography algorithms such as RSA and ECC are facing the risk of quantum attacks such as Shor's algorithm. Quantum-resistant cryptography (PQC) has emerged to address this issue, and NIST has promoted the standardization of PQC algorithms such as Kyber and Rainbow. However, existing PQC implementations suffer from integration difficulties, performance bottlenecks, and compatibility problems. Traditional systems hard-code embedded algorithms, resulting in high upgrade and maintenance costs. Existing interface and service-oriented methods are not optimized for PQC, lack unified specifications and frameworks, and are difficult to deploy efficiently and securely. Therefore, an interface and service-oriented implementation solution for PQC is needed to solve the above problems.

[0003] Full names of terms and abbreviations

[0004] PQC: Post-Quantum Cryptography, designed based on mathematical problems such as lattice problems and encoding problems, can maintain security in quantum computing environments. It is used in the document to resist quantum attacks and ensure data confidentiality and integrity.

[0005] NIST (National Institute of Standards and Technology) promotes the standardization process of post-quantum cryptography and its documents serve as an important basis for the security assessment and selection of quantum-resistant cryptographic algorithms.

[0006] LWE: Learning With Errors, a fundamental and difficult problem in lattice cryptography, and the core of the security of lattice-based quantum-resistant cryptographic algorithms such as Kyber and Dilithium, as documented.

[0007] SOA: Service-oriented Architecture, which improves system flexibility and scalability through modular and distributed deployment. The document describes a service-oriented architecture design for quantum-resistant cryptography services.

[0008] gRPC: Remote Procedure Call framework, based on the HTTP / 2 protocol, supports bidirectional streaming communication and PB serialization, and is described in the documentation as an interface communication protocol adapted for low-latency scenarios;

[0009] RESTful API: Representational StateTransfer Application Programming Interface, based on the HTTP protocol, is used as the interface communication protocol in the documentation and is adapted for highly compatible scenarios;

[0010] PB: Protocol Buffers, a data serialization format used in the documentation for data transmission under the gRPC protocol to ensure data compactness and parsing efficiency;

[0011] TLS: Transport Layer Security, the document uses TLS version 1.3, which is used for encrypting API calls and data transmission between services to prevent data eavesdropping and tampering;

[0012] HSM: Hardware Security Module, documented as being used to securely store private keys for quantum-resistant cryptographic algorithms, ensuring that the keys are not leaked;

[0013] FFT: Fast Fourier Transform, described in the documentation as being used to optimize lattice-based polynomial multiplication operations and reduce computational complexity;

[0014] IFFT: Inverse Fast Fourier Transform, described in the documentation as working in conjunction with FFT to perform frequency-domain and time-domain conversion in polynomial multiplication, thereby accelerating computation.

[0015] Kubernetes: A container orchestration platform (Kubernetes), documented for the deployment, scaling, and fault recovery of quantum cryptography-resistant microservices to ensure high service availability;

[0016] Istio: Service Mesh (Istio), documented for microservice traffic management, load balancing, and inter-service encryption, reducing operational complexity;

[0017] Vault: A key management tool (HashiCorp Vault), documented as being used to centrally store sensitive information such as microservice private keys and API keys, and supporting dynamic key rotation;

[0018] Prometheus: A monitoring tool (Prometheus) used in the documentation to collect metrics such as microservice CPU utilization and response time, supporting performance optimization and alerts;

[0019] Grafana: A visualization tool (Grafana) used in the documentation to display monitoring metrics collected by Prometheus, making it easier for operations and maintenance personnel to intuitively understand the service status;

[0020] ELK Stack: Log management stack (Elasticsearch, Logstash, Kibana), documented for microservice log collection, storage, and analysis to meet security auditing requirements;

[0021] SCADA: Supervisory Control and Data Acquisition. As a traditional device in the power grid field, it needs to be compatible with quantum-resistant cryptographic services to achieve secure transmission of scheduling data.

[0022] RTU: Remote Terminal Unit, used in the document to collect operating data of power equipment. It needs to be connected to a quantum-resistant cryptographic service to ensure data transmission security. Summary of the Invention

[0023] This invention provides a method for implementing interface-based and service-oriented capabilities based on quantum-resistant cryptographic algorithms, addressing the challenges of integration difficulties, poor performance, insufficient compatibility, and quantum security vulnerabilities of traditional cryptographic algorithms in existing PQC implementations. The core of the method is to encapsulate quantum-resistant cryptographic algorithms into standardized interfaces and deploy them as services through a cloud-edge-device collaborative architecture. This involves four stages: selecting algorithms such as Kyber based on security and functionality standards and encapsulating them as components; designing standardized interfaces for encryption and decryption, supporting dual protocols and plug-in architectures, optimizing computation at the adaptation layer, and establishing security and maintenance mechanisms at the interface layer; encapsulating the interfaces as microservices and deploying them in a containerized manner within the cloud-edge-device architecture, integrating service mesh and key management, and designing dynamic service chains; optimizing performance through model parameter tuning, hardware acceleration, and dynamic scaling, achieving resistance to quantum attacks, adapting to multiple domains, and demonstrating significant practical value.

[0024] Technical solution

[0025] This invention aims to overcome the shortcomings of existing technologies and proposes a method for implementing interface-based and service-oriented capabilities based on quantum-resistant cryptographic algorithms. The specific implementation process is as follows:

[0026] 1. Algorithm Selection and Fundamentals

[0027] 1.1 Algorithm Selection Criteria

[0028] First, the selection of quantum-resistant cryptographic algorithms must meet the following core criteria to ensure compatibility with subsequent interface and service implementations:

[0029] (1) Security: The algorithm must be based on a mathematical problem that is difficult to solve in a quantum computing environment, and must pass at least one round of evaluation in the post-quantum cryptography standardization process of the National Institute of Standards and Technology (NIST) to ensure that it can resist typical quantum attacks such as Shor's algorithm and Grover's algorithm.

[0030] (2) Functionality: It needs to cover the core requirements of the cryptographic system, including data encryption, data decryption, digital signature generation, digital signature verification and other functions. The corresponding type of algorithm (such as encryption scheme, signature scheme) can be selected according to the application scenario (such as data transmission encryption, identity authentication).

[0031] (3) Performance adaptability: The computational complexity and resource utilization of the algorithm need to be adapted to the service-oriented deployment scenario. Under the premise of ensuring security, the service response delay should be avoided due to the excessive complexity of the algorithm. It is necessary to support the balance between security level and performance through parameter adjustment (such as key length and modulus).

[0032] (4) Compatibility: The algorithm must be compatible with the existing software and hardware environment. Its core operations (such as polynomial operations and matrix operations) can be implemented through general programming languages ​​(such as Java and C++) or hardware acceleration technologies (such as GPU and dedicated encryption chips) to facilitate subsequent interface encapsulation and service deployment.

[0033] Based on the above criteria, two types of quantum-resistant cryptographic algorithms are preferred:

[0034] Lattice-based encryption and signature schemes, such as the Kyber algorithm (for key encapsulation) and the Dilithium algorithm (for digital signatures), are characterized by high security, adjustable parameters, and optimizable computation, making them suitable for most scenarios.

[0035] Multivariate signature schemes, such as the Rainbow algorithm, have advantages in signature generation and verification speed, and are suitable for scenarios with high requirements for signature efficiency (such as IoT device identity authentication).

[0036] 1.2 Core Mathematical Foundations of the Algorithm

[0037] Taking lattice-based algorithms (such as Kyber and Dilithium) as an example, their core security relies on the Learning With Errors (LWE) problem, a fundamental and difficult problem in lattice cryptography, defined and mathematically explained as follows:

[0038] (1) Parameter definition:

[0039] Limited domain , where q is a prime number, representing the modulus, and its value needs to be determined according to the security level (e.g., to meet the 128-bit security level, q can be 3329).

[0040] Let the matrix dimension parameters be m and n, where m > n, m is the number of rows in the matrix, and n is the number of columns in the matrix. The parameter values ​​need to be determined in combination with security requirements and computing performance (e.g., n = 256, m = 512).

[0041] random matrix Each element in the matrix originates from a finite field. The matrix is ​​randomly selected to ensure its randomness.

[0042] Secret Vector Each element in the vector originates from a finite field. The information is randomly selected from the data and serves as the core secret information of the algorithm, which must be kept strictly confidential.

[0043] Error vector Each element in the vector is selected from a preset discrete Gaussian distribution (e.g., mean 0, standard deviation 2.0). The introduction of the error vector is the key to the difficulty of solving the LWE problem.

[0044] (2) LWE problem definition:

[0045] Given a random matrix A, a secret vector s, and an error vector e, the following formula can be used to... The vector b is calculated; given A and b, the process of recovering the secret vector s from (A, b) is computationally infeasible, and even in a quantum computing environment, there is currently no polynomial-time algorithm that can solve this problem.

[0046] 1.3 Typical Algorithm Implementation Logic (Taking Kyber's Algorithm as an Example)

[0047] The Kyber algorithm, a lattice-based key encapsulation algorithm, has a core process that includes public key generation, private key generation, key encapsulation, and key decapsulation. Its specific implementation logic is based on the LWE problem.

[0048] (1) Key generation stage:

[0049] Public key generation: Generate a random matrix based on the LWE problem parameters. Secret Vector Error vector ; through formula t Calculate the vector t; use (A, t) as the public key pk, which can be publicly transmitted and stored for subsequent key encapsulation operations.

[0050] Private key generation: The secret vector s is used as the private key sk. The private key must be stored securely (such as encrypted storage or hardware security module HSM) and is only used for subsequent key decapsulation operations. It must not be disclosed.

[0051] (2) Key encapsulation stage (executed by the encryptor):

[0052] The encryptor obtains the recipient's public key pk = (A, t) and generates a random vector. With error vector , ;

[0053] Through formula The vector v is calculated using the formula. The session key k is calculated (where Hash is a normalized hash function, such as SHA-256).

[0054] (v, The key is sent as encrypted text to the recipient to complete the key encapsulation.

[0055] (3) Key decapsulation stage (executed by the receiver):

[0056] The receiver obtains the ciphertext (v, c) (where c = ... ), using the private key sk = s;

[0057] Through formula The session key k' is calculated.

[0058] Due to the difficulty of solving the LWE problem, attackers cannot recover the correct session key from the ciphertext, while the receiver can calculate the same session key k = k' as the encryptor using the private key, thus completing the key decryption.

[0059] 1.4 Algorithm Abstraction and Component-based Encapsulation

[0060] To accommodate subsequent interface design, the aforementioned quantum-resistant cryptography algorithm needs to be abstracted and encapsulated into components. The specific steps are as follows:

[0061] (1) Abstraction of core algorithm logic: The core operations of the algorithm, such as key generation, encryption, decryption, signing, and verification, are abstracted into independent functional functions, and a unified input and output parameter format is defined; for example, the key generation function uniformly outputs "public key-private key" pairs, and the encryption function uniformly receives "plaintext-public key" as input and outputs ciphertext.

[0062] (2) Algorithm parameter management component: Design an independent parameter management component to store and maintain parameters of different algorithms (such as q, m, n for LWE problem, hash function type), support dynamic configuration and query of parameters, and adjust parameter values ​​according to security requirements or application scenarios.

[0063] (3) Algorithm call interface component: Encapsulate the algorithm call interface component as the underlying support for subsequent standardized interface design; This component provides a unified algorithm call entry point, which can automatically call the core function of the corresponding algorithm according to the input "algorithm type" parameter (such as "Kyber" or "Dilithium"), and realize the unified call logic of different algorithms.

[0064] 2. Interface-based design

[0065] 2.1 Interface Design Goals and Core Principles

[0066] The core objective of interface-based design is to provide a unified and standardized interactive entry point for calling quantum-resistant cryptographic algorithms, solving the problems of complex algorithm integration, poor cross-platform compatibility, and high upgrade and maintenance costs in existing quantum-resistant cryptographic systems, while ensuring the security, efficiency, and scalability of interface calls.

[0067] The design process must adhere to the following core principles:

[0068] (1) Principle of uniformity: unify the functional definition, input and output format and calling logic of cryptographic operations so that the same operations (such as encryption and signature) of different quantum-resistant cryptographic algorithms (such as Kyber and Dilithium) can be called through the same interface, reducing the difficulty of adaptation of the upper-layer system;

[0069] (2) Cross-platform compatibility principle: Select communication protocols and data formats that support cross-language and cross-system capabilities to ensure that the interface can be called normally in different software and hardware environments such as cloud computing (such as AWS, Alibaba Cloud), Internet of Things (such as embedded devices, edge gateways), and financial terminals (such as POS machines, bank core systems);

[0070] (3) Security principle: The interface must have a built-in security protection mechanism to prevent data leakage, tampering and unauthorized access during the call process, and support flexible adjustment of the security level through parameter configuration to adapt to the security requirements of different scenarios;

[0071] (4) Scalability principle: The modular and plug-in architecture design supports the dynamic addition of quantum-resistant cryptographic algorithms and the expansion of interface functions, and the upgrade can be completed without large-scale modification of the core logic of the interface.

[0072] 2.2 Interface Communication Protocol and Data Format

[0073] To meet the requirements of cross-platform compatibility and call efficiency, the interface adopts the following communication protocol and data format:

[0074] (1) Communication protocol selection:

[0075] The gRPC protocol is preferred: it is suitable for scenarios with high requirements for call latency and data transmission efficiency (such as encryption of high-frequency financial trading data and real-time identity authentication of IoT devices). gRPC is implemented based on the HTTP / 2 protocol, supports bidirectional streaming communication, header compression and connection multiplexing, which can reduce network transmission overhead. At the same time, it improves data encoding and decoding efficiency by serializing data through Protocol Buffers (PB).

[0076] Compatible with RESTful API protocols: Suitable for scenarios with higher compatibility requirements and lower call frequency (such as encrypted transmission of government documents and encrypted data in cloud storage). RESTful APIs are based on HTTP / 1.1 or HTTP / 2 protocols, use JSON format for data transmission, support standard HTTP methods such as GET, POST, PUT, and DELETE, and can be directly called through HTTP clients of mainstream programming languages ​​(such as Java, Python, and Go), lowering the integration threshold.

[0077] (2) Data format specifications:

[0078] Protocol Buffers (PB) is adopted as the data serialization format for the gRPC protocol, and a unified message structure is defined (such as encrypted request messages containing "data" and "params" fields, and encrypted response messages containing "ciphertext" and "timestamp" fields) to ensure the compactness of data transmission and parsing efficiency.

[0079] JSON is used as the data exchange format for the RESTful API protocol. Field names follow the "snake naming convention" (such as "ciphertext" and "secret_key"). Numeric parameters (such as key length n and modulus q) are in integer format, and binary data (such as ciphertext and signature) are in Base64 encoding format to ensure consistent data parsing across different platforms.

[0080] 2.3 Core Interface Definition and Function Description

[0081] Based on the above protocol and format, the core operation interface of the quantum-resistant cryptosystem is defined, covering the four basic functions of encryption, decryption, signature, and verification. The input parameters, output results, and functional logic of each interface are shown in the table below:

[0082] Interface Name Input parameters Output Functional Logic encrypt 1. data: Plaintext data to be encrypted (bytes in PB format, Base64 encoded string in JSON format); 2. params: Encryption parameters (including "algorithm_type" specifying the algorithm type, such as "Kyber-768"; "key_length" specifying the key length n; "modulus_q" specifying the modulus q; "hash_alg" specifying the hash algorithm, such as "SHA-256") 1. ciphertext: The encrypted ciphertext data (bytes in PB format, Base64 encoded string in JSON format); 2. session_id: A unique identifier for this encrypted session (string); 3. timestamp: The timestamp of the API call (millisecond-level integer). 1. Load the corresponding quantum-resistant encryption algorithm according to "algorithm_type" in params; 2. Preprocess the data (e.g., segment according to algorithm requirements, add padding); 3. Use the algorithm to encrypt the preprocessed plaintext to generate ciphertext; 4. Generate session_id and timestamp, and return them together with the ciphertext. decrypt 1. ciphertext: The ciphertext data to be decrypted (format same as the encrypt interface output); 2. key: The decryption private key (bytes in PB format, Base64 encoded string in JSON format, must be transmitted through a secure channel); 3. session_id: The encrypted session identifier (consistent with the encrypt interface output). 1. plaintext: The decrypted plaintext data (format is the same as the input data in the encrypt interface); 2. status: Decryption status ("success" indicates success, "fail" indicates failure); 3. error_msg: Error description when failure occurs (empty string when status is "success") 1. Verify the validity of session_id (e.g., check session logs to confirm the existence of the session); 2. Parse the key to obtain the private key information and match the corresponding decryption algorithm; 3. Use the algorithm to perform decryption operation on ciphertext; 4. If decryption is successful, return plaintext and "success" status; if it fails (e.g., incorrect private key, ciphertext tampering), return empty plaintext, "fail" status and error description. sign 1. message: The message data to be signed (format is the same as the input data in the encrypt interface); 2. key: The signing private key (format is the same as the input key in the decrypt interface); 3. params: Signing parameters (including "algorithm_type" specifying the signing algorithm, such as "Dilithium-III"; "signature_length" specifying the signature length) 1. signature: The generated quantum-resistant digital signature (bytes in PB format, Base64 encoded string in JSON format); 2. sign_id: Unique identifier for the signature (string); 3. timestamp: Signature generation timestamp (millisecond-level integer) 1. Load the corresponding quantum-resistant signature algorithm according to "algorithm_type" in params; 2. Hash the message (using the algorithm specified by "hash_alg" in params); 3. Perform a signature operation on the hash result using the private key corresponding to the key to generate a signature; 4. Generate sign_id and timestamp, and return them together with the signature. verify 1. signature: The digital signature to be verified (format same as the output of the sign interface); 2. message: The message data corresponding to the signature (format same as the input of the sign interface); 3. key: The verification public key (format same as the input key of the decrypt interface); 4. sign_id: The signature identifier (consistent with the output of the sign interface). 1. `verify_result`: Verification result (boolean, true for success, false for failure); 2. `status`: Verification status ("success" indicates verification process completed, "fail" indicates verification process failed); 3. `error_msg`: Error description when an error occurs (empty string when status is "success"). 1. Verify the validity of sign_id (e.g., check the signature log to confirm the existence of the signature); 2. Parse the key to obtain the public key information and match the corresponding verification algorithm; 3. Perform the same hashing process on the message as when signing; 4. Use the algorithm and public key to perform verification operations on the signature and hash result, and return verify_result, status, and error description (if any).

[0083] 2.4 Plug-in Architecture Design

[0084] To enable dynamic loading and flexible switching of quantum-resistant cryptographic algorithms, the interface adopts a plug-in architecture, consisting of three layers: "interface layer," "algorithm adaptation layer," and "algorithm plug-in layer." The functions and interaction logic of each layer are as follows:

[0085] (1) Interface layer: that is, the core interface defined in Section 2.3, which is responsible for receiving the call request from the upper layer system, standardizing the request parameters and passing them to the "algorithm adaptation layer", and encapsulating the result returned by the "algorithm adaptation layer" into a unified format for output;

[0086] (2) Algorithm Adaptation Layer: As an intermediate adaptation bridge between the interface layer and the algorithm plugin layer, it is responsible for:

[0087] Algorithm registration and management: Maintain the "algorithm registry" to record information on loaded anti-quantum algorithm plugins (such as algorithm name, supported operation types, parameter range), and support dynamic registration (addition) and deregistration (deletion) of plugins;

[0088] Parameter validation and conversion: Perform validity validation on the parameters passed by the interface layer (such as "key_length" and "modulus_q" in params) (e.g., check whether n meets the value range required by the algorithm and whether q is a prime number), and convert the parameters into a format that the algorithm plugin can recognize;

[0089] Computational optimization: Reduce the computational overhead of the algorithm plugin through mathematical optimization methods. See Section 2.2.5 for the specific optimization logic;

[0090] (3) Algorithm Plugin Layer: Contains multiple independent quantum-resistant cryptographic algorithm plugins (such as Kyber plugin and Dilithium plugin). Each plugin encapsulates the core logic of the corresponding algorithm (such as Kyber plugin containing public key generation, encryption and decryption functions, and Dilithium plugin containing signature generation and verification functions). Plugins exist in the form of dynamic link libraries (such as .so and .dll files) or container images. The loading path can be specified through the configuration file to achieve "hot-plugging" (the addition or replacement of plugins can be completed without restarting the interface service).

[0091] 2.5 Computational Optimization Logic of the Algorithm Adaptation Layer

[0092] The algorithm adaptation layer accelerates computationally complex operations in quantum-resistant cryptographic algorithms (such as polynomial multiplication based on lattice algorithms) by introducing mathematical optimization formulas, thereby reducing the computational overhead of interface calls. The specific optimization method is illustrated using a lattice-based algorithm as an example:

[0093] 2.5.1 Optimization Scenarios and Mathematical Foundations

[0094] The core operation of lattice-based quantum-resistant cryptographic algorithms (such as Kyber and Dilithium) is multiplication on a polynomial ring, which is defined as follows: ,in:

[0095] Let q be a finite field, and q be the prime modulus.

[0096] For the reduced polynomial of the polynomial ring, that is, the result of polynomial multiplication needs to be reduced to the polynomial of the polynomial ring. Modulus (satisfying) );

[0097] n is the degree of the polynomial (i.e., the key length related parameter), usually taken as a power of 2 (such as 256, 512, 768) to adapt to the computation logic of Fast Fourier Transform (FFT).

[0098] Traditional polynomial multiplication uses the method of "multiplying each term and then combining like terms", with a time complexity of O(n). When n is a large value (e.g., n=768), the computation time increases significantly, affecting the interface response speed; FFT can reduce the time complexity of polynomial multiplication to O(nlog n), greatly improving computational efficiency.

[0099] 2.5.2 Optimization Formula and Execution Steps

[0100] Let f(x) and g(x) be polynomial rings. The expressions for the two polynomials on the given surface are as follows:

[0101]

[0102]

[0103] in These are polynomial coefficients. Implemented using FFT. The steps are as follows:

[0104] (1) Polynomial expansion: The coefficients of f(x) and g(x) are expanded to an array of length 2n, and the coefficients of the expanded part are all set to 0 to obtain f'(x) and g'(x), ensuring that the FFT transformation can cover all coefficients of the multiplication result;

[0105] (2) FFT transformation: Perform FFT transformation on the expanded coefficient array to obtain frequency domain arrays F = FFT(f') and G = FFT(g'). The FFT transformation adopts the Fast Fourier Transform algorithm and reduces the computational complexity through the divide-and-conquer strategy.

[0106] (3) Frequency domain dot product: Perform dot product operation on frequency domain arrays F and G (i.e., multiply corresponding elements) to obtain H = F G, where ;

[0107] (4) Inverse IFFT: Perform the inverse IFFT on H to obtain the time-domain array h = IFFT(H), and the elements of array h are f'(x). The coefficient of g'(x);

[0108] (5) Polynomial reduction: Since f(x) and g(x) belong to the ring We need to consider f'(x). g'(x) according to Reduce the coefficients h[k] (k n), combine them into h[k - n] and take the negative (h[k - n] = (h[k - n] - h[k]) mod q), and finally get f(x). g(x) in The coefficient array on;

[0109] (6) Modulo operation of coefficients: Take the modulo of q on all elements of the reduced coefficient array to ensure that the result conforms to the finite field. The range of values ​​for is used to obtain the final polynomial multiplication result.

[0110] The optimization process described above is encapsulated as a general function through the algorithm adaptation layer. When the algorithm plugin calls the polynomial multiplication operation, the optimization logic is automatically triggered without the need for the algorithm plugin to implement it separately, ensuring that different lattice-based algorithms can enjoy the computational acceleration effect.

[0111] 2.6 Interface Security and Operation and Maintenance Assurance Mechanism

[0112] To ensure the security and stability of the API call process, the following safeguards are designed:

[0113] (1) Calling authentication: The interface supports authentication mechanisms based on API key or OAuth 2.0. Before calling the interface, the upper layer system needs to obtain an access token from the authentication server and carry the token in the request header. The interface layer will verify the validity of the token before allowing subsequent operations to be performed.

[0114] (2) Data transmission encryption: Regardless of whether gRPC or RESTful API protocol is used, the transmitted data is encrypted using TLS 1.3 protocol to prevent the data from being eavesdropped or tampered with during network transmission;

[0115] (3) Request frequency limit: The interface layer has a built-in flow control module that limits the interface call frequency of a single client through the token bucket algorithm (e.g., a maximum of 100 calls per second) to avoid malicious requests causing interface overload;

[0116] (4) Logs and monitoring: The interface logs all call requests (including input parameters, output results, call time, and client information), and monitors the interface's response time, success rate, error rate, and other indicators. When the indicators exceed the preset thresholds (such as response time exceeding 500ms or error rate exceeding 1%), an alarm mechanism is triggered (such as sending emails or SMS messages to notify maintenance personnel).

[0117] (5) Version Management: The interface supports version control (e.g., the version number " / v1 / encrypt" is included in the URL). When the interface function is upgraded, the old version interface can be retained by adding a new version, ensuring that the upper layer system that has integrated the old version runs normally and achieving a smooth transition.

[0118] 3. Service-oriented deployment

[0119] 3.1 Service-Oriented Deployment Goals and Architecture Framework

[0120] The core objective of service-oriented deployment is to encapsulate the standardized interfaces defined in Chapter 2 into independent and scalable microservices, thereby solving the problems of poor deployment flexibility, low resource utilization, and performance bottlenecks in high-concurrency scenarios of traditional cryptographic systems. At the same time, it ensures the high availability and security of services in multiple environments such as cloud platforms and edge nodes, and ultimately achieves the large-scale and on-demand delivery of quantum-resistant cryptographic services.

[0121] The service-oriented deployment adopts a collaborative architecture framework of "cloud-edge-device", which is divided into three layers:

[0122] (1) Cloud service layer: Deploy core cryptographic microservice clusters to handle large-scale, high-concurrency cryptographic operation requests (such as financial transaction data encryption and government cloud data signing), and rely on the computing resources (CPU, GPU, dedicated encryption chip) of cloud platforms (such as AWS, Alibaba Cloud, Huawei Cloud) to achieve high-performance operation;

[0123] (2) Edge service layer: Deploy lightweight cryptographic microservice instances on edge nodes (such as edge gateways and IoT base stations) to handle localized requests with low latency requirements (such as IoT device authentication and industrial control data encryption) and reduce network overhead for data transmission to the cloud service layer.

[0124] (3) Terminal access layer: Provides a unified service access entry point (such as API gateway) to support terminal devices (such as financial terminals, IoT sensors, and personal computers) to access cloud or edge services through standardized protocols, and realizes request routing and service discovery.

[0125] 3.2 Selection of Core Technologies

[0126] To achieve high availability, elastic scaling, and secure communication in service-oriented deployments, the core technologies selected are shown in the table below:

[0127] Technology Category Selection scheme Selection criteria Containerization technology Docker (container packaging) + Kubernetes (container orchestration) Docker can package microservices and their dependencies (such as operating system environment, algorithm library, configuration file) into standardized containers to ensure environment consistency; Kubernetes supports automatic deployment, scaling up and down, and fault recovery of containers to meet the needs of high availability and elastic scaling of services. Communication Protocol HTTP / 2 (inter-microservice communication) + gRPC / RESTful API (terminal access) HTTP / 2 supports multiplexing and header compression, reducing network latency in communication between microservices; the gRPC / RESTful API is consistent with the interface protocol in Section 2.2 to ensure compatibility of terminal access. Service Mesh Technology Istio Istio provides functions such as traffic management (load balancing, canary releases), inter-service encryption, and monitoring and alerting, enabling service governance without modifying microservice code and reducing operational complexity. Key exchange protocol FrodoKEM (Quantum-resistant Key Exchange) + TLS 1.3 (Transport Layer Encryption) FrodoKEM is designed based on the lattice problem and can resist quantum attacks. It is used for key negotiation between microservices and between terminals and services. TLS 1.3 provides transport layer data encryption and authentication to prevent data eavesdropping and tampering. Monitoring and alarm tools Prometheus (metrics collection) + Grafana (visualization) + Alertmanager (alerts) Prometheus can collect metrics such as CPU utilization, response time, and request success rate of microservices in real time; Grafana supports visualization of metrics; Alertmanager can trigger alerts (such as email and SMS notifications) based on preset thresholds.

[0128] 3.3 Key Steps in Service-Oriented Deployment

[0129] Service-oriented deployment consists of four key steps: service encapsulation, containerization deployment, load balancing configuration, and security enhancement. The execution process and technical details of each step are as follows:

[0130] 3.3.1 Step 1: Service Encapsulation

[0131] The standardized interfaces (encrypt, decrypt, sign, verify) defined in Chapter 2 are encapsulated as independent microservices. The specific steps are as follows:

[0132] (1) Microservice decomposition: Decompose into microservices based on functional modules, with each microservice focusing on a single type of cryptographic operation, i.e.:

[0133] Encrypt Service: Only implements the encrypt interface functionality;

[0134] Decrypt Service: Only implements the decrypt interface functionality;

[0135] Sign Service: Only implements the sign interface functionality;

[0136] Verify Service: Only implements the verify interface functionality;

[0137] After splitting, each service can be scaled up or down independently, avoiding the impact of a single service failure on the overall system.

[0138] (2) Service code implementation: The microservice code is written using a high-concurrency programming language (such as Go or Java). The core logic includes:

[0139] Interface protocol parsing: Supports request parsing of gRPC / RESTful API protocols, converting parameters passed from the terminal into the standardized format defined in Chapter 2;

[0140] Algorithm call: By calling the "Algorithm Adaptation Layer" in Section 2.2.4, the corresponding quantum-resistant cryptographic algorithm operation is triggered;

[0141] Result encapsulation: Encapsulate the algorithm calculation results according to the protocol format and return them to the terminal or downstream microservices;

[0142] (3) Dependency management: Use dependency management tools (such as Go Modules, Maven) to manage the algorithm libraries (such as Kyber algorithm library, FFT optimization library) and communication libraries (such as gRPC library, HTTP / 2 library) that microservices depend on, and ensure the consistency of dependency versions.

[0143] 3.3.2 Step 2: Containerized Deployment

[0144] The process of containerizing microservices using Docker and Kubernetes is as follows:

[0145] (1) Docker image building:

[0146] Write a Dockerfile: Specify the base image (such as Alpine Linux, which is lightweight and secure), copy the microservice code and dependency libraries to the image, and set the service startup command (such as . / encrypt-service --port=8080).

[0147] Build the image: Execute the command `docker build -t encrypt-service:v1.0 .` to generate a Docker image for the encryption service. Similarly, build images for the decryption, signing, and verification services.

[0148] Image repository push: Push the built image to a private image repository (such as Harbor) to ensure that the Kubernetes cluster can safely pull the image.

[0149] (2) Kubernetes deployment configuration:

[0150] Write the Deployment configuration file: Define the number of container instances of the microservice (initial number of replicas), resource limits (such as 1 CPU core, 1GB memory), and health check rules (such as checking the service liveness status through the / health interface).

[0151] Execute the deployment command: Use the command `kubectl apply -f encrypt-service-deployment.yaml` to create microservice instances in the Kubernetes cluster, supporting deployment on Kubernetes nodes at the cloud service layer or edge service layer;

[0152] Service exposure: Expose the access ports of microservices through Kubernetes Service resources (such as NodePort, LoadBalancer), so that terminals or other microservices can access them by service name.

[0153] 3.3.3 Step 3: Load Balancing Configuration

[0154] To achieve load balancing of microservices and ensure even distribution of requests in high-concurrency scenarios, the Istio service mesh is used. The steps are as follows:

[0155] (1) Istio injection: Inject the Istio Sidecar proxy into the microservice namespace in the Kubernetes cluster. The Sidecar proxy will intercept all inbound and outbound traffic of the microservice.

[0156] (2) Virtual Service Configuration: Define virtual service rules to route terminal requests to the corresponding microservice clusters, for example, route the ` / v1 / encrypt` request to the encryption service cluster;

[0157] (3) Destination Rule Configuration: Specify the load balancing strategy, and give priority to the "minimum number of connections" strategy (distribute requests to the service instance with the fewest current connections) to avoid overloading some instances; at the same time, configure session affinity to ensure that continuous requests from the same terminal are routed to the same instance (if session consistency needs to be maintained).

[0158] (4) Gray release configuration: By using Istio's traffic splitting function, some requests (such as 10%) are routed to the new version microservice instance. After verifying the stability of the new version, the traffic ratio is gradually increased to achieve seamless upgrade.

[0159] 3.3.4 Step 4: Security Enhancement

[0160] By integrating quantum-resistant key exchange and transport layer encryption, the security of communication between services and between terminals and services is ensured. Specific measures are as follows:

[0161] (1) Encryption of inter-service communication:

[0162] Enable Istio's two-way TLS (mTLS): Communication between microservices uses TLS encryption by default. Istio automatically generates an identity certificate for each microservice and verifies the identity of the other party through the certificate to prevent malicious services from accessing the network.

[0163] Quantum-resistant key negotiation: During the TLS handshake phase, the FrodoKEM algorithm is used instead of the traditional RSA / ECC algorithm for key exchange, generating a session key for subsequent data encryption to resist quantum attacks;

[0164] (2) Terminal access security:

[0165] API Gateway Authentication: When deploying an API gateway (such as Istio Gateway) at the terminal access layer, the terminal needs to obtain access permissions through API key or OAuth 2.0 authentication. Only after successful authentication can the request be forwarded to the microservice.

[0166] Transport layer encryption: Communication between the terminal and the API gateway is encrypted using the TLS 1.3 protocol, and insecure encryption suites (such as SHA-1 and RC4) are disabled to ensure secure data transmission;

[0167] (3) Key management: Deploy a key management service (such as HashiCorp Vault) to centrally store sensitive information such as private keys and API keys of microservices. Reduce the risk of key leakage through a key rotation mechanism (such as rotating every 7 days). Microservices can dynamically obtain keys through Vault's API, avoiding hard-coded storage.

[0168] 3.4 Dynamic Service Chain Design

[0169] To enable flexible combinations of multiple cryptographic services and meet the needs of complex business scenarios (such as the combined operation of "data encryption + digital signature"), a "dynamic service chain" mechanism is designed, and its specific implementation is as follows:

[0170] (1) Service chain definition: A dynamic service chain is a workflow composed of multiple cryptographic microservices according to a preset logic, such as the "signature service → encryption service" chain (signing the data first, then encrypting the "data + signature") and the "decryption service → verification service" chain (decrypting the data first, then verifying the data signature).

[0171] (2) Service chain configuration: Define service chain rules through configuration files. The rules include:

[0172] Chain ID: A unique identifier for the service chain;

[0173] Service node list: Microservice names arranged in execution order (e.g., ["Sign Service", "EncryptService"]);

[0174] Parameter passing rules: Define how the output of the previous service is used as the input of the next service (e.g., the output "signature" of the signature service is used as part of the input "data" of the encryption service).

[0175] Security policy association: Associate the corresponding security policy (e.g., select Kyber-768 algorithm for encryption and Dilithium-III algorithm for signing);

[0176] (3) Service chain execution process:

[0177] When the terminal submits a request, it specifies the service chain ID (e.g., X-Chain-ID: sign-encrypt-001) in the request header.

[0178] After receiving the request, the API gateway queries the configured list of service nodes and parameter passing rules based on the service chain ID;

[0179] Requests are forwarded to each microservice in sequence: first, the original data is sent to the signature service to generate a signature, and then the "original data + signature" is sent as input to the encryption service to generate ciphertext;

[0180] Finally, the output (ciphertext) of the encryption service is returned to the terminal, while the execution logs of each node in the service chain (such as execution time and result status) are recorded.

[0181] 3.5 Performance Optimization Mechanism

[0182] By optimizing service performance through mathematical models and resource scheduling strategies, service response time is reduced and system throughput is increased. The core optimization mechanism is as follows:

[0183] 3.5.1 Service response time optimization

[0184] The optimization algorithm based on the "service response time model" calculates the time and network latency as follows:

[0185] (1) Definition of response time model: total service response time ,in:

[0186] Algorithm computation time, i.e. the time it takes for a microservice to execute quantum-resistant cryptographic algorithms (such as encryption and signature), is mainly affected by algorithm parameters (such as polynomial degree n and modulus q).

[0187] Network latency, or the time it takes for a request to be transmitted from the terminal to a microservice and for data to be transmitted between microservices, is mainly affected by network bandwidth and transmission distance.

[0188] (2) optimization:

[0189] Dynamic parameter adjustment: The algorithm parameters are dynamically adjusted according to the security and performance requirements of the business scenario. For example, in low-latency scenarios (such as real-time encryption of IoT), the polynomial degree n is reduced from 768 to 512 (while ensuring that the preset security level is still met) to reduce the amount of computation.

[0190] Hardware acceleration: Deploying GPUs or dedicated encryption chips (such as Intel SGX) in microservice instances at the cloud service layer accelerates computationally intensive operations such as polynomial multiplication and FFT transformation, reducing computational costs. ;

[0191] 3. optimization:

[0192] Edge deployment: Deploy frequently called microservices (such as IoT device signature services) to edge nodes to shorten the transmission distance between terminals and services and reduce network latency;

[0193] Data compression: When transmitting data between microservices, use lightweight compression algorithms (such as Snappy) to compress data (such as ciphertext and signatures) to reduce the amount of data transmitted and improve the transmission speed.

[0194] 3.5.2 Dynamic allocation of resources

[0195] The number of service instances is dynamically adjusted based on the "resource allocation formula" to maximize system throughput, as follows:

[0196] (1) Definition of resource allocation formula: In a containerized environment, the number of service instances N is determined according to the formula. Calculate, where:

[0197] Request arrival rate (unit: requests / second) is obtained by Prometheus in real time by collecting the request volume statistics of microservices;

[0198] Single-service instance processing rate (unit: requests / second), which is the number of requests that a single microservice instance can process per second, obtained from historical performance data statistics (e.g., single-instance processing rate of encryption service). = 500 requests / second);

[0199] The floor function ensures that the number of instances is an integer.

[0200] (2) Dynamic expansion and contraction implementation:

[0201] Configure Kubernetes HPA (Horizontal Pod Autoscaler): Associate HPA scaling rules with the resource allocation formulas mentioned above, and monitor HPA in real time. and The number of service instances N is automatically adjusted according to changes in [the data / conditions].

[0202] Scaling up and down threshold settings: To avoid frequent scaling up and down, set scaling up and down thresholds. For example, when the actual request volume exceeds 80% of the current instance's processing capacity, scaling up is triggered, and when it is below 30%, scaling down is triggered.

[0203] Resource reservation: When calculating N, reserve an additional 10%-20% of the number of instances (e.g., if N = 5, actually deploy 6 instances) to cope with sudden traffic surges and ensure system stability.

[0204] 3.6 Operation and Monitoring Mechanism

[0205] To ensure the stability of service-oriented deployments, a full lifecycle operation and monitoring mechanism will be established, as detailed below:

[0206] (1) Health check:

[0207] Liveness Probe: Kubernetes periodically checks whether a service is alive through the microservice's ` / health / live` interface. If it fails repeatedly, it restarts the instance.

[0208] Readiness Probe: Checks whether the service is ready (e.g., algorithm library loading completed, key acquisition successful) via the ` / health / ready` interface. Instances that are not ready will not receive requests.

[0209] (2) Log Management:

[0210] Centralized log collection: Deploy the ELK Stack (Elasticsearch, Logstash, Kibana). Microservice logs are collected by Logstash and stored in Elasticsearch. Logs are queried and analyzed using Kibana (e.g., to investigate the reasons for request failures).

[0211] Log anonymization: Sensitive information (such as private keys and plaintext data) in logs is anonymized (e.g., replaced with "*") to prevent information leakage;

[0212] (3) Alarm mechanism:

[0213] Alarm threshold configuration: Configure alarm rules in Prometheus, such as triggering alarms when the service response time exceeds 500ms, the error rate exceeds 1%, or the number of instances reaches the expansion limit;

[0214] Alarm classification: Alarms are classified into three levels: emergency (e.g., service unavailable), important (e.g., response time too high), and alert (e.g., insufficient number of instances). Emergency alarms are notified via SMS and email, while important / alert alarms are notified via email.

[0215] (4) Disaster recovery:

[0216] Multi-region deployment: Deploy microservice instances across multiple Availability Zones (AZs) in a Kubernetes cluster. When a single Availability Zone fails, requests are automatically routed to instances in other Availability Zones, achieving high availability.

[0217] Data backup: Regularly back up the configuration files and key information of microservices (such as keys in Vault), and store the backup data off-site to prevent data loss from causing service unavailability.

[0218] Beneficial effects

[0219] The beneficial effects of this invention are as follows:

[0220] 1. Resistant to quantum computing threats and ensures cryptographic security in the post-quantum era: The core uses an algorithm that has been standardized and evaluated by NIST PQC, which resists typical quantum attacks based on quantum intractable mathematical problems and solves the security vulnerabilities of traditional algorithms; through interface identity authentication, TLS 1.3 transmission encryption, inter-service mTLS, centralized key management and rotation, and algorithm plugin signature verification, a full-link security protection is formed to avoid risks such as key leakage and data tampering.

[0221] 2. Modular and service-oriented design enhances system scalability: A three-layer pluggable architecture is adopted, with algorithms encapsulated as plug-ins to support "hot-swappability". Adding new algorithms does not require modification of the core logic; containerized deployment is achieved based on Docker+Kubernetes, and dynamic scaling is achieved by combining HPA and resource allocation formulas. The "cloud-edge-device" architecture adapts to business needs of different scales.

[0222] 3. Standardized interfaces and cross-platform compatibility enhance interoperability: Define standardized interfaces covering core functions, unify calling logic and data format, and reduce the difficulty of upper-layer system integration; the interface supports dual protocols, and the algorithm operation is adapted to common languages ​​and hardware architectures, which can be seamlessly integrated with existing infrastructure in multiple fields without the need for large-scale modification of traditional systems.

[0223] 4. Improve performance and efficiency through mathematical optimization and resource scheduling: optimize polynomial multiplication through FFT and reduce algorithm computation time through hardware acceleration; achieve "minimum number of connections" load balancing with Istio, support dynamic parameter adjustment to balance security and performance, reduce network latency through edge deployment, and improve system throughput and resource utilization.

[0224] 5. Widely adaptable to various scenarios and highly practical: It can flexibly adapt to the needs of cloud computing, IoT, finance, power grid and other fields, providing secure and efficient cryptographic services for various fields and solving the pain points of cryptographic services in the post-quantum era of various industries. Attached Figure Description

[0225] Figure 1 This is a schematic diagram of the method flow described in this invention, illustrating the implementation process of the method for achieving interface and service capabilities based on quantum-resistant cryptographic algorithms. Detailed Implementation

[0226] The present invention will be further described below with reference to specific embodiments:

[0227] 1. Example

[0228] This embodiment takes the encrypted transmission scenario of power dispatch data in a power grid company as an example to explain in detail the implementation process of interface and service capabilities based on quantum-resistant cryptographic algorithms. This scenario needs to meet the core requirements of the power grid sector for data security (resistance to quantum attacks, ensuring dispatch instructions are not tampered with / stolen), real-time performance (dispatch instruction response time ≤ 500ms), high availability (service interruption time ≤ 1 minute / year), and compatibility (adaptation to traditional SCADA systems and new edge computing devices). The Kyber-768 algorithm (key encapsulation, used for dispatch data encryption) and the Dilithium-III algorithm (digital signature, used for dispatch instruction authentication) based on lattice are selected, and a service-oriented architecture based on cloud-edge-device collaboration is adopted for deployment.

[0229] 1.1 Implementation Environment and Parameter Configuration

[0230] 1.1.1 Hardware Environment

[0231] Cloud service layer: Deployed in the power grid company's private cloud cluster, the nodes are configured with an 8-core 16GB CPU (Intel Xeon Platinum 8375C), NVIDIA A30 GPU (for algorithm hardware acceleration), and 25Gbps optical network bandwidth, carrying the core encryption / signature service cluster and handling the large-scale data encryption needs of the provincial power dispatch center;

[0232] Edge service layer: Deployed on the edge computing node of the substation (ARM Cortex-A57 8-core processor, 8GB memory, 10Gbps industrial Ethernet bandwidth), running a lightweight decryption / verification service instance to handle real-time decryption and signature verification of local dispatch instructions in the substation;

[0233] Terminal access layer: includes traditional SCADA system (based on Windows Server 2016, used for substation equipment monitoring), new intelligent dispatch terminal (Android 13 system, used for issuing commands to on-site maintenance personnel), RTU (remote terminal unit, used to collect power equipment operation data), and access services through API gateway.

[0234] 1.1.2 Software Environment

[0235] Containerization tools: Docker 24.0.7, Kubernetes 1.29.0;

[0236] Service Mesh: Istio 1.20.0;

[0237] Key management: HashiCorp Vault 1.15.0 (supports national cryptographic algorithms and complies with power grid security standards);

[0238] Monitoring tools: Prometheus 2.48.0, Grafana 10.3.0 (integrated with a dedicated power grid monitoring panel, such as dispatch command transmission delay and service availability).

[0239] Algorithm libraries: Kyber-768 optimization library (supports industrial-grade stability, C++ language version), Dilithium-III library (integrates ARM NEON instruction set, adapted for edge nodes).

[0240] 1.1.3 Core Parameter Configuration

[0241] Parameter type Parameter name Value illustrate Algorithm parameters Kyber-768 parameters Modulus q = 3329, polynomial degree n = 768, matrix dimension m = 1536 Compliant with NIST PQC standards, corresponding to a 128-bit security level, meeting the encryption requirements of power grid dispatch data. Algorithm parameters Dilithium-III parameters Modulus q = 8380417, polynomial degree n = 256, signature length = 2420 bytes Supports authentication of dispatch commands to prevent forged commands from causing malfunctions in power grid equipment. Interface parameters Communication Protocol The encryption / signature service uses gRPC (low latency, adaptable to real-time scheduling requirements); the decryption / verification service is compatible with RESTful API (adapting to the HTTP interface of traditional SCADA systems). Balancing real-time power grid dispatch with compatibility with legacy systems Service parameters Initial number of replicas Cloud service layer: 6 copies of encryption service, 6 copies of signature service; Edge layer: 3 copies of decryption service, 3 copies of verification service. Based on the power grid dispatch peak (8000 instructions / second) and the resource allocation formula Calculation (λ = 8000 requests / second, μ = 1500 requests / second for a single instance of the encryption service, 1800 requests / second for a single instance of the signature service) Service parameters Request frequency limit A single RTU terminal can make a maximum of 30 calls per second, while a provincial dispatch center can make a maximum of 1000 calls per second. Preventing equipment malfunctions or malicious attacks from consuming service resources Hardware acceleration parameters GPU acceleration configuration In the CUDA 12.1 framework, the number of parallel threads for polynomial multiplication is 2048. Reduced the computation time of FFT for Kyber-768 single-encryption from 90ms to 30ms. Hardware acceleration parameters Edge node optimization ARM NEON instruction set, signature verification parallelism = 4 Reduced the single-pass validation time of Dilithium-III from 70ms to 40ms

[0242] 1.2 Implementation Steps

[0243] The core business process in this embodiment is "Provincial dispatch center issues load adjustment instruction → instruction signing → instruction encryption → substation edge node decryption → signature verification → RTU executes adjustment operation", and the corresponding service-oriented link is "Provincial dispatch center → API gateway → signature service → encryption service → substation edge decryption service → verification service → RTU terminal". The specific steps are as follows:

[0244] 1.2.1 Step 1: Service Deployment and Initialization

[0245] (1) Microservice encapsulation: The services are split according to the method in Section 3.3.1. The signature service (implementing the sign interface), encryption service (implementing the encrypt interface), decryption service (implementing the decrypt interface), and verification service (implementing the verify interface) are written in C++ (cloud service layer, adapted for GPU acceleration) and Go (edge ​​service layer, lightweight). It depends on the Kyber / Dilithium algorithm library (integrating GPU / NEON acceleration module) and gRPC / HTTP library (supporting industrial-grade TCP reconnection mechanism).

[0246] (2) Containerization build: Write a Dockerfile (the base image for the cloud service layer is Ubuntu Server 22.04, and the edge layer is Alpine Linux 3.19 with ARM architecture), execute `docker build -t power-sign-service:v1.0 .` to generate images for each service, and push them to the power grid's private Harbor repository (enable image signature verification to prevent malicious image injection).

[0247] (3) Kubernetes Deployment: Write the Deployment configuration file, set resource limits (2 CPU cores and 4GB memory for a single instance of the encryption service, with GPU resources enabled; 1 CPU core and 2GB memory for a single instance of the edge decryption service), and health check rules (live probe checks the / health / live interface, checking once every 5 seconds, restarting after 2 failures; ready probe checks the / health / ready interface, accepting requests after confirming successful algorithm library loading and key acquisition); execute kubectl apply -f power-encrypt-deployment.yaml to complete the cloud / edge layer service deployment, where the edge service is deployed on the local Kubernetes cluster of the substation (supports offline operation to prevent service unavailability due to network interruption);

[0248] (4) Istio configuration: Inject Sidecar proxy into cloud / edge services, define virtual services (route / v1 / power / sign to the signature service and / v1 / power / encrypt to the encryption service), configure destination rules: load balancing strategy is "minimum number of connections" (to adapt to unbalanced requests of scheduling instructions), session timeout is 5 minutes (to ensure the continuity of the signature-encryption link of the same scheduling instruction); cross-region disaster recovery rules (when the substation edge service fails, automatically route to the edge service of the adjacent substation).

[0249] (5) Key initialization: Generate Kyber-768 public-private key pairs (for encrypting dispatch data, distributed to provincial dispatch centers and substations) and Dilithium-III public-private key pairs (for instruction signing, distributed to dispatcher accounts and RTU terminals) through Vault; set the key rotation cycle to 14 days (in compliance with power grid safety management regulations); microservices dynamically obtain keys through Vault API (supports offline caching, automatic synchronization when keys are updated), and hard-coded storage is prohibited.

[0250] (6) Parallel configuration of dual algorithms: The crypto_mode field is added to the params parameter of the encrypt / sign interface in the interface layer to support "pq_only" (pure quantum-resistant) and "hybrid" (hybrid mode); in "hybrid" mode, the algorithm adaptation layer automatically executes "Kyber-768+SM2" encryption and "Dilithium-III+SM3withSM2" signing in parallel, and outputs "double ciphertext / double signature" to adapt to the SM2 decryption logic of traditional SCADA systems.

[0251] 1.2.2 Step 2: Terminal Request Initiation and Authentication

[0252] (1) The dispatcher at the provincial dispatch center inputs a load adjustment instruction (content: {"substation_id":"SD-001","load_adjustment":"-5MW","execute_time":"2024-12-31T15:30:00","operator_id":"OP-12345"}) through the dispatch system and submits an instruction issuance request;

[0253] (2) The dispatching system calls the authentication interface of the API gateway, passes in the dispatcher's USBKey certificate (compliant with the power grid PKI system) and dynamic password. After the gateway verifies the validity of the certificate through Vault, it returns an access token (valid for 30 minutes, bound to the dispatcher's account and operation permissions).

[0254] (3) The scheduling system carries Authorization: Bearer {Access Token}, X-Chain-ID: power-sign-encrypt-001 (specifying the “signature → encryption” service chain) and X-Crypto-Mode:hybrid (enabling hybrid encryption mode) in the request header, and sends the instruction data to the API gateway via the gRPC protocol.

[0255] 1.2.3 Step 3: Service Chain Execution (Signature → Encryption, including dual-algorithm parallelism and hardware acceleration)

[0256] (1) Signature service call (including NEON / GPU acceleration):

[0257] According to the service chain rules, the gateway sends the instruction data (Base64 encoded), the signing private key (obtained from Vault and associated with the scheduler account), and parameters (algorithm_type: Dilithium-III, crypto_mode: hybrid) to the signing service;

[0258] The signature service loads the Dilithium-III algorithm through the algorithm adaptation layer, enables GPU acceleration (cloud service layer) or NEON acceleration (edge ​​layer), performs SHA-256 hash processing on the instruction data, and simultaneously executes Dilithium-III signature and SM3withSM2 signature in parallel to generate "dual signature" (Dilithium signature length 2420 bytes, SM2 signature length 64 bytes).

[0259] The signature service returns the signature (double signature concatenation, Base64 encoded), sign_id: PWR-S20241231001, and timestamp: 1735668599000 to the gateway.

[0260] (2) Encrypted service call (including FFT optimization and dual-algorithm parallelism):

[0261] The gateway, according to the service chain parameter transmission rules, concatenates "command data + double signature" into {"power_cmd":"...", "hybrid_signature": "..."}, and transmits it to the encryption service as the data to be encrypted;

[0262] The encryption service loads the Kyber-768 algorithm, calls the FFT optimization function of the algorithm adaptation layer (executed according to the steps in Section 2.5.2, reducing the time consumption of polynomial multiplication through GPU parallel computing), and simultaneously executes Kyber-768 encryption and SM2 encryption in parallel to generate "double ciphertext" (Kyber ciphertext is about 1500 bytes long, and SM2 ciphertext is about 256 bytes long).

[0263] The encryption service returns ciphertext (double ciphertext concatenation, Base64 encoded), session_id: PWR-E20241231001, and timestamp: 1735668599300 to the gateway. The gateway then returns the ciphertext to the dispatch system, which forwards it to the substation edge node via the dedicated power network (SDH / MSTP).

[0264] 1.2.4 Step 4: Edge layer decryption and verification (including fault degradation)

[0265] (1) Decryption service call (including adaptation to traditional algorithms):

[0266] After receiving the ciphertext, the substation edge node calls the local decryption service (an HTTP interface adapted to traditional SCADA systems) via a RESTful API, passing in the ciphertext, the decryption private key (obtained from Vault and associated with the substation ID), and session_id: PWR-E20241231001.

[0267] If the edge decryption service is normal, the service automatically parses the "double ciphertext" and performs Kyber-768 decryption and SM2 decryption in parallel to restore the "instruction data + double signature". If the edge service fails (such as network interruption), the Istio fault degradation rule is triggered, and the service is automatically routed to the edge decryption service of the adjacent substation (switching time ≤ 100ms).

[0268] The decryption service returns plaintext (restored instruction data and double signature) and status: success to the substation SCADA system.

[0269] (2) Verify service call:

[0270] The SCADA system extracts the double signature from the plaintext, calls the verification service, and passes in the signature, instruction data, verification public key (Dilithium-III public key and SM2 public key), and sign_id: PWR-S20241231001;

[0271] The verification service rehashes the instruction data, verifies the Dilithium-III signature and SM2 signature in parallel, and returns verify_result: true, status: success. If the verification fails (e.g., the instruction has been tampered with), the substation's audible and visual alarm is immediately triggered, and the RTU is prohibited from performing operations.

[0272] 1.2.5 Step 5: Result Feedback and Monitoring

[0273] (1) The RTU receives the verification pass instruction issued by the SCADA system, performs load adjustment operation, and sends the operation result ({"execute_status": "success", "current_load": "45MW"}) back to the provincial dispatch center after encryption through the edge service;

[0274] (2) Prometheus collects service metrics in real time: encryption service response time 85ms (including GPU acceleration), signature service response time 60ms (including NEON acceleration), edge decryption service response time 75ms, verification service response time 50ms, and total end-to-end time 360ms (meets the real-time requirement of ≤500ms).

[0275] (3) Grafana displays a dedicated power grid monitoring panel: service availability of 99.999% (meets the requirement of annual interruption ≤ 1 minute), command transmission success rate of 99.998%, and GPU / NEON acceleration utilization of 70%-80% (balanced resource utilization).

[0276] (4) ELK Stack collects full-link logs, desensitizes sensitive information such as scheduling instructions and key IDs in the logs, supports tracing the entire process of instruction transmission by sign_id / session_id, and meets the requirements of power grid security audit.

[0277] 1.3 Implementation Effectiveness Verification

[0278] 1.3.1 Security Verification

[0279] Quantum resistance verification: A quantum computing simulator (based on Shor's algorithm) was used to attempt to crack the Kyber-768 ciphertext and Dilithium-III signature. The key was not successfully recovered or the instructions were not tampered with within the 72-hour simulation period, thus verifying the quantum resistance security.

[0280] Hybrid mode security verification: Simulating a scenario where the SM2 algorithm is compromised by traditional cracking methods, the Kyber-768 ciphertext remains undecryptable, ensuring that the scheduling data remains secure even if the traditional algorithm fails;

[0281] Anti-tampering verification: If the encrypted dispatch command is manually tampered with (the load adjustment value is changed to "-20MW"), the verification service will return verify_result: false after decryption and trigger an alarm to prevent malicious operation from causing power grid accidents.

[0282] 1.3.2 Performance Verification

[0283] Real-time performance verification: During peak grid load periods (8000 commands / second), the average response time across the entire link is 380ms, and the 99th percentile response time is 450ms, both meeting the requirement of ≤500ms.

[0284] Throughput verification: The total throughput of the cloud service layer encryption service with 6 replicas is 9000 requests / second, and the total throughput of the signature service with 6 replicas is 10800 requests / second, which can support the peak instruction transmission needs of the provincial dispatch center;

[0285] Hardware acceleration verification: After disabling GPU / NEON acceleration, the response time of the encryption service increased to 210ms and the response time of the signature service increased to 150ms, verifying that hardware acceleration can improve the performance of core services by 2-3 times.

[0286] 1.3.3 Compatibility and Usability Verification

[0287] Cross-terminal compatibility verification: Traditional SCADA systems (supporting SM2), new intelligent scheduling terminals (supporting quantum-resistant algorithms), and RTU devices can all call the service normally without any protocol or data format compatibility issues;

[0288] Fault recovery verification: Simulate a substation edge service outage scenario. Istio automatically switches to the service of the adjacent substation. The switching time is 95ms and the command transmission is uninterrupted, verifying the effectiveness of the fault degradation mechanism.

[0289] Offline operation verification: After disconnecting the substation from the provincial cloud service, the edge service can still process local dispatch instructions normally based on locally cached keys and algorithm plugins, ensuring that critical power grid operations are not interrupted.

[0290] This embodiment demonstrates that the interface and service capability implementation method based on quantum-resistant cryptographic algorithms proposed in this invention can operate stably in the power dispatching scenario of power grid companies, meeting the requirements of security, real-time performance, high availability and compatibility, and providing reliable cryptographic service support for power grid data transmission in the post-quantum era.

[0291] The embodiments of the present invention are not limited to the above description. The parameters of the quantum-resistant algorithm (such as the modulus q of Kyber and the polynomial degree n of Dilithium), the number of instance replicas in service-oriented deployment, the node order and parameter passing rules of the dynamic service chain, the hardware acceleration configuration (such as the number of parallel threads of GPU and the parallelism of ARM NEON instruction set) and the interface communication protocol (such as gRPC for high-frequency scenarios and RESTful API for traditional systems) can be adjusted according to actual security-sensitive application scenarios such as power dispatching and financial transactions. All such improvements fall within the protection scope of the present invention.

Claims

1. A method for implementing interface and service capabilities based on quantum-resistant cryptographic algorithms, characterized in that, Includes the following steps: (1) Algorithm selection: Based on the standards of security, functionality, performance adaptability and compatibility, quantum-resistant cryptographic algorithms that have passed the post-quantum cryptography standardization evaluation of the National Institute of Standards and Technology (NIST) are selected. The algorithms include the lattice-based Kyber algorithm, the Dilithium algorithm and the multivariate-based Rainbow algorithm. (2) Interface design: Design a standardized interface covering encryption, decryption, digital signature generation and digital signature verification functions. The interface supports both gRPC and RESTful API communication protocols, adopts Protocol Buffers (PB) and JSON data format, and the interface architecture is divided into interface layer, algorithm adaptation layer and algorithm plugin layer. The algorithm adaptation layer optimizes the polynomial multiplication operation in the quantum-resistant cryptographic algorithm through fast Fourier transform (FFT). (3) Service-oriented deployment: Adopting a "cloud-edge-device" collaborative architecture, the standardized interface is encapsulated into four types of microservices: encryption service, decryption service, signature service, and verification service through Docker. Kubernetes is used to implement container orchestration, and Istio service mesh is combined to configure load balancing and secure communication. HashiCorp Vault is deployed for centralized key management and dynamic rotation. (4) Performance optimization: The algorithm parameters are dynamically adjusted based on the service response time model. GPUs or dedicated encryption chips are deployed in the cloud service layer, and the ARM NEON instruction set is used to implement hardware acceleration in the edge service layer. Service instances are dynamically scaled up and down according to the resource allocation formula through Kubernetes HPA.

2. The method according to claim 1, characterized in that, The security standard for the algorithm selected in step 1 is that the algorithm is based on intractable mathematical problems in a quantum computing environment, including the Learning With Errors (LWE) problem and multivariable equation system problems, which can resist attacks by Shor's algorithm and Grover's algorithm. The performance adaptability standard is that the algorithm's computational complexity and resource utilization are adapted to service-oriented deployment scenarios, and it supports balancing security level and performance by adjusting key length and modulus parameters. The compatibility standard is that the core operation of the algorithm can be implemented through general programming languages ​​such as Java and C++ or hardware acceleration technologies such as GPU and dedicated encryption chips.

3. The method according to claim 1, characterized in that, In step 2, the standardized interface's input parameters for the encryption interface include the plaintext data to be encrypted, encryption parameters including algorithm type, key length, modulus, and hash algorithm, and output parameters including ciphertext data, a unique identifier for the encryption session, and an interface call timestamp. The input parameters for the decryption interface include the ciphertext data to be decrypted, the decryption private key, and the encryption session identifier, and output parameters including the decrypted plaintext data, decryption status, and error description. The input parameters for the signature interface include the message data to be signed, the signature private key, and signature parameters including algorithm type and signature length, and output parameters including a quantum-resistant digital signature, a unique signature identifier, and a signature generation timestamp. The input parameters for the verification interface include the digital signature to be verified, the message data corresponding to the signature, the verification public key, and the signature identifier, and output parameters including the verification result, verification status, and error description.

4. The method according to claim 1, characterized in that, Step 2, the FFT optimization polynomial multiplication operation of the algorithm adaptation layer includes: expanding the polynomial coefficients to an array of length 2n, performing an FFT transformation on the expanded array to obtain a frequency domain array, performing a dot product operation on the frequency domain array, performing an inverse IFFT transformation on the result, merging the coefficients according to the polynomial cyclic reduction rule, and taking the modulus of the coefficients to obtain the final result, where n is the polynomial degree.

5. The method according to claim 1, characterized in that, In step 3, the cloud service layer of the "cloud-edge-device" collaborative architecture deploys a core cryptographic microservice cluster to handle large-scale, high-concurrency cryptographic operation requests; the edge service layer deploys lightweight cryptographic microservice instances on edge nodes to handle low-latency localized requests. The terminal access layer provides an API gateway as a unified service access point, supporting terminal devices to access cloud or edge services through standardized protocols.

6. The method according to claim 1, characterized in that, In step 3, the load balancing strategy configured in the Istio service mesh is the minimum number of connections strategy, which supports session persistence and enables microservice canary release through traffic splitting. The secure communication configuration includes enabling bidirectional TLS (mTLS) and using the FrodoKEM algorithm for key exchange during the TLS handshake phase.

7. The method according to claim 1, characterized in that, In step 4, the service response time model is: Total service response time = Algorithm computation time + Network latency. Network latency optimization includes deploying high-frequency microservices on edge nodes and using lightweight compression algorithms to compress transmitted data. The resource allocation formula is: Number of service instances ,in For the request arrival rate, For single-service instance processing rate, The function is rounded up, and the scaling threshold is configured to avoid frequent scaling up and down, reserving 10%-20% of instances to cope with sudden traffic surges.

8. The method according to claim 1, characterized in that, Step 3 also includes dynamic service chain design, which defines the chain ID of the service chain, the list of service nodes arranged in execution order, parameter passing rules and security policy associations through configuration files. Terminal requests are forwarded to each microservice by the API gateway according to the rules through the specified service chain ID, and the execution logs of each node in the service chain are recorded.

9. The method according to claim 1, characterized in that, In step 2, the interface layer is also configured with call authentication, data transmission encryption, request frequency limiting, log monitoring and version management mechanisms. Call authentication uses API key or OAuth2.0 mechanism, data transmission encryption uses TLS 1.3 protocol, request frequency limiting is implemented through token bucket algorithm, log monitoring records interface call request information and monitors response time, success rate and error rate indicators, and version management enables smooth interface upgrades by including version number in URL.

10. The method according to claim 1, characterized in that, Step 1 also includes algorithm abstraction and component encapsulation. The key generation, encryption, decryption, signing and verification operations of the algorithm are abstracted into independent functional functions. An algorithm parameter management component is designed to store and maintain algorithm parameters. An algorithm call interface component is encapsulated to provide a unified algorithm call entry point and support calling the corresponding algorithm core functional functions according to the input algorithm type parameters.

Images