Remote key security management method and device for cloud virtualization cryptographic module

Abstract

The invention discloses a remote key security management method and device for a cloud virtualization cryptographic module, and aims to solve the problems of cloud key trust root, transmission security and the like. The core of the method is to keep the master key control right of a user locally, and through cooperative work of a local client, a cloud management platform and a distributed vHSM instance, through the four steps of system initialization and key fragmentation distribution, remote certification and secure channel establishment, distributed cooperative operation and local result synthesis, and by utilizing IBE, Shamir secret sharing, a threshold cryptographic algorithm and TEE technologies, the user master key control right and the distributed vHSM instance are subjected to remote certification and secure channel establishment, distributed cooperative operation and local result synthesis. And the key is available and invisible. The device comprises three modules, namely a local client, a cloud management platform and a vHSM cluster. The method guarantees secret key confidentiality and completeness, supports a national secret algorithm, meets compliance requirements, adapts to cloud native elasticity requirements, and is suitable for cloud secret key management in industries such as electric power and the like.

Description

Technical Field

[0001] This invention relates to the fields of cryptography, virtualization technology, and network security, specifically to key management technology for virtualized cryptographic modules. It is particularly applicable to remote secure management of key containers and methods for issuing unique identification keys under cloud computing, containerization, and microservice architectures. It can be widely used in critical information systems such as power grids, finance, and government affairs that have high requirements for key security, uniqueness, and traceability. Background Technology

[0002] As enterprises accelerate their migration to the cloud, traditional hardware security modules (HSMs) are no longer able to meet the elastic needs of cloud-native applications due to their physical limitations, high costs, and insufficient scalability. Virtualized HSMs (vHSMs) and key management services (KMS) provided by cloud service providers have emerged to address this need.

[0003] However, existing technologies have significant drawbacks: cloud-based vHSMs run on virtualization platforms controlled by cloud service providers, and tenants cannot fully trust the underlying infrastructure, leading to trust issues such as key theft or leakage; when users use cloud-based KMS, plaintext keys transmitted over the network are susceptible to man-in-the-middle attacks or eavesdropping; multi-tenant sharing of vHSM instances may result in cross-tenant key leakage due to vulnerabilities in the virtualization layer; at the same time, users lack sufficient control and auditing capabilities over the storage location, processing, and replication of keys, necessitating a solution that can guarantee the confidentiality, integrity, and availability of user keys on untrusted cloud infrastructures.

[0004] Full names of terms and abbreviations vHSM: Virtual Hardware Security Module, a logical security module built on virtualization technology, runs in a Trusted Execution Environment (TEE) and has core functions such as key storage, fragment management, and partial cryptographic operations. It is compatible with Chinese national cryptographic algorithms and internationally used cryptographic algorithms. In the document, it is used as the core execution node for distributed key fragment storage and collaborative operation to avoid the aggregation of complete keys in the cloud. KMS: Key Management Service, a centralized key management service provided by cloud service providers, which can realize the generation, storage, distribution and destruction of keys. In the document, it is used as a comparison object of existing technologies, which has defects such as plaintext key transmission and insufficient tenant key isolation. TEE: Trusted Execution Environment, is a runtime environment with hardware-level security isolation capabilities that can ensure the confidentiality and integrity of code and data. The documentation describes its construction using technologies such as Intel SGX and AMD SEV, providing a secure isolation space for vHSM instance operation and key sharding storage. IBE: Identity-Based Encryption, an encryption technology that does not require prior exchange of public key certificates. It can directly use the user's identity identifier as the public key. In the document, it is used to map the encrypted user's primary identity identifier to the secret shared original material, thereby binding the key material with the user's identity. PKI: Public Key Infrastructure, a security infrastructure built on asymmetric encryption technology, which includes components such as key generation, certificate issuance and verification. In the documentation, it is used to support secure interaction processes such as user authentication and digital signature verification. RSA: Rivest-Shamir-Adleman encryption algorithm, an internationally recognized asymmetric encryption standard. The documentation supports key lengths of at least 2048 bits, and it is used for user asymmetric key pair generation, digital signature verification, etc. AES-256: Advanced Encryption Standard 256-bit, an internationally used symmetric encryption algorithm with a 256-bit key length. In the document, it is used for local encrypted partition storage, key fragment encryption, etc., to ensure the confidentiality of data storage and transmission. AES-GCM-256: Advanced Encryption Standard - Galois / Counter Mode 256-bit, is an authenticated symmetric encryption mode that combines encryption and message authentication. It is used in the documentation for secure channel data transmission encryption to ensure data confidentiality and integrity. HMAC-SHA256: Hash-BasedMessage Authentication Code - Secure Hash Algorithm 256-bit, is a message authentication technology based on a hash function. The documentation describes its use to verify the integrity and authenticity of transmitted data, preventing data from being tampered with or forged. HKDF-SHA256: HMAC-based Key Derivation Function - Secure Hash Algorithm 256-bit, used to derive session keys from shared key negotiation parameters, supporting session key generation for secure channels in the documentation; TPM: Trusted Platform Module, is a hardware security chip integrated into the terminal device. It has functions such as key generation, encrypted storage, and platform identity authentication. The document describes it as being used for the encapsulation and storage of the user's root private key to ensure that the core key is not exported. PoD-Hellman: Proof of Diffie-Hellman, a key exchange protocol based on remote proof, is used in the document to establish a secure channel between user clients and vHSM instances to achieve secure negotiation of session keys; SPDnet: Secure Power Dispatch Data Network, a dedicated backbone communication network for the power industry, featuring high security and low latency. In the document, it serves as the communication network between local clients and cloud nodes, supporting the real-time transmission of power business key operation requests. SCADA: Supervisory Control and Data Acquisition, used for real-time monitoring and scheduling of industrial production processes. In the document, it serves as the application terminal for plaintext data in power dispatching, receiving the calculation results output by the local client for business scheduling. OMS: Operation and Maintenance System, used for the operation and maintenance management of enterprise IT resources and business systems. The documentation shows that it interfaces with the cloud virtualization cryptography module management platform to realize the operation and maintenance monitoring and management of vHSM instances. ElGamal: The Elgamal encryption algorithm is an asymmetric encryption algorithm based on the discrete logarithm problem. It is used in the document as an example algorithm for threshold cryptography to demonstrate the distributed collaborative decryption process. Shamir's Secret Sharing: A threshold-based secret sharing technology that splits a secret into N fragments, requiring at least t fragments to reconstruct the secret. The document describes the fragment generation and secret reconstruction of user key materials, ensuring the security of key fragment storage. Summary of the Invention

[0005] This invention discloses a remote key security management method and apparatus for a cloud-based virtualized cryptographic module, aiming to solve problems such as cloud key leakage and insufficient root of trust.

[0006] The core idea is to retain control of the user's master key locally, and to work together through a local client, a cloud management platform, and a distributed vHSM instance: first, the user's master identity and key pair are generated; then, a vHSM instance in a TEE environment is deployed in a multi-physical isolation area in the cloud, and the key material is stored in fragments; after remote authentication and activation of the instance through a secure channel, a partial result is generated through distributed threshold calculation by an arbitration group, and finally, the result is aggregated and output locally.

[0007] The device adopts a modular design, supports national cryptographic algorithms and international algorithms, and realizes the key as "usable but invisible". It takes into account security, compliance and scalability, and is suitable for cloud key management in high-risk industries such as power.

[0008] Technical solution The purpose of this invention is to overcome the shortcomings of the prior art and provide a remote key security management method and device for a cloud-based virtualized cryptographic module.

[0009] The core idea of ​​this method is to retain absolute control of the user's master key locally, and use identity-based multi-party computation technology and secure enclaves (such as Intel SGX) to collaboratively generate and run virtualized cryptographic modules in the cloud, ensuring that no user master key ever appears in its complete form in the cloud, thereby achieving "usable but invisible" remote key security management.

[0010] The implementation process is as follows: 1. Implementation Process and Methods The overall architecture of the method of this invention consists of three core components: a local client, a cloud-based virtualized cryptographic module management platform, and multiple distributed vHSM instances. These components work collaboratively through a pre-defined secure interaction protocol to achieve remote secure management of the cloud-based virtualized cryptographic module and keys. The core implementation process is executed sequentially according to the following steps: 1.1 Step 1: System Initialization and Key Seed Distribution This step aims to generate basic user identity and key materials, securely deploy the cloud-based vHSM instance, and process key seed shards, establishing a secure foundation for subsequent remote key management. The specific execution process is as follows: (1) Generation of local master identity and asymmetric key pair Users perform initialization operations through the security key generation module built into the local client: first, generating a globally unique user primary identity identifier. This identifier is used for subsequent key fragmentation association, vHSM instance authentication, and identity binding for cryptographic operation requests; secondly, based on an asymmetric encryption algorithm approved by the State Cryptography Administration (such as the SM2 algorithm) or the internationally accepted RSA algorithm (key length not less than 2048 bits), a pair of asymmetric keys is generated. ),in For the user's private key, This is the user's public key.

[0011] For private keys It employs a high-security local storage mechanism for protection, which may include, but is not limited to: local encrypted partition storage (using AES-256 algorithm to encrypt stored files), storage bound to a local hardware security unit (such as a USBKey or local HSM), or key encapsulation storage based on a Trusted Platform Module (TPM), to ensure... The entire process remains within the user's local environment and is not transmitted to the cloud or other untrusted nodes via any network.

[0012] (2) vHSM instance creation request initiation and cloud deployment Users initiate a vHSM instance creation request to the cloud-based virtualized password module management platform through the local client's interactive interface. The request data packet must contain the following key information: user's primary identity identifier. The required number of vHSM instances N (N≥3), the security level required for vHSM instance operation (such as TEE environment type, cryptographic algorithm support range), and physical deployment isolation requirements.

[0013] After receiving the request, the cloud-based virtualized password module management platform first verifies the identity through a preset authentication mechanism (such as based on...). Digital signature verification verifies the user's identity and the legitimacy of the request. The verification content includes: The uniqueness of the signature, the validity of the signature request, and whether the N value meets the minimum security requirement of ≥3.

[0014] After verification, the management platform calls the cloud-based underlying infrastructure scheduling interface and coordinates with the physical server cluster management system and the virtualization resource scheduling system to deploy vHSM instances in at least three independent physical security zones. The physical security zones must meet geographical or physical isolation requirements (such as being distributed in different data center computer rooms, different server racks, or different physical server nodes), and each physical security zone must have independent network protection, access control, and environmental monitoring mechanisms.

[0015] Each vHSM instance runs within a Trusted Execution Environment (TEE), which must meet hardware-level security isolation requirements. Specifically, it can be built using, but is not limited to, Intel SGX (Software Guard Extensions), AMD SEV (Secure Encrypted Virtualization), or ARM TrustZone technologies. When a vHSM instance starts, it automatically loads a pre-set cryptographic algorithm library (supporting SM series algorithms, RSA, ECC, etc.) and a secure communication module to ensure that it has the basic capabilities of key fragment storage, partial cryptographic operations, and secure communication.

[0016] (3) Key fragmentation generation and security processing The user's local client invokes the built-in encryption and fragmentation processing module to generate key fragments according to the following process: The first step is to use the user's public key. For the main identity identifier Perform asymmetric encryption to obtain the encrypted result. Cipher This encryption process ensures It will not be leaked during subsequent association processing; The second step is based on the encrypted... The ciphertext is first encrypted using Identity-Based Encryption (IBE) technology. This is mapped to initial key material bound to the user's identity—specifically, through a preset IBE system public key (distributed to the user's local machine in advance by the management platform). Perform encryption operations to generate IBE ciphertext; then, decrypt the IBE ciphertext (using the IBE private key held locally by the user) to obtain the original material for secret sharing; The third step involves using secret sharing technology to fragment the original material, generating N key fragments. .

[0017] Each key fragment Contains only partial information from the original material, a single Or fewer than a preset threshold t (t≤N, and t≥2) The combination of these elements cannot deduce or reconstruct the complete original material or any valid key information; they can only serve as partial input material for subsequent distributed collaborative computing.

[0018] Related formulas (secretly shared) The generation of key fragments and subsequent secret reconstruction in this step are based on Shamir's Secret Sharing scheme. This scheme has a "threshold property," meaning that at least t fragments are required to reconstruct the secret; if fewer than t fragments are collected, no secret-related information can be obtained. The specific mathematical process is as follows: (1) Finite field and polynomial construction First, select a sufficiently large prime number p (the value of p must satisfy that p is much larger than the maximum value of the secret to be protected, and p≥N+1, so as to ensure that the x value assigned to each vHSM instance is unique in the finite field), and construct the finite field GF(p) based on the prime number p; Construct a polynomial of degree t-1 within the finite field GF(p): Where t is the threshold for secret reconstruction (t≤N, and the value of t must meet security requirements, usually set to N / 2 +1, such as t=3 when N=5). The coefficients are randomly selected from the finite field GF(p), and each coefficient is non-zero (to avoid reducing the safety level due to polynomial degree reduction); constant term The "secret" to be protected specifically refers to the original material obtained after the IBE processing in step 3 above, denoted as S. = S.

[0019] (2) Key fragmentation calculation Assign distinct x values ​​to N vHSM instances. The x values ​​must satisfy x∈GF(p) and x≠0 (e.g., assign x=1, x=2, ..., x=N in sequence). Substituting each value of x into the above (t-1)th degree polynomial f(x), performing modular arithmetic within the finite field GF(p), the corresponding key fragments are calculated: in, After the calculation is complete, each key is fragmented. Its corresponding x value (denoted as ) are associated and stored to form ( , The key-value pairs are used for subsequent secret reconstruction.

[0020] (3) Secret Reconstruction Rules When it is necessary to restore the secret S to be protected (i.e. When ), at least t key fragments and their corresponding x values ​​need to be collected from N vHSM instances, denoted as ( , ), ( , ), ...,( , ); By calculating these t pieces using Lagrange interpolation, the constant term of the polynomial can be reconstructed within the finite field GF(p). The secret S is calculated using the following formula: in, For Lagrange interpolation coefficients, the denominator is ( The inverse of GF(p) is solved by modular inverse operation within the finite field GF(p); If the number of collected key fragments is less than t, it is impossible to derive valid information about the secret S through any mathematical operation, thus failing to ensure the confidentiality of the secret during the fragment storage stage.

[0021] 1.2 Step 2: Secure Channel Establishment and vHSM Instance Activation This step aims to verify the trustworthiness of the vHSM instance's runtime environment through remote verification, thereby establishing an end-to-end secure communication link, completing the secure transmission of key fragments and activation of the vHSM instance, and providing a security prerequisite for subsequent distributed cryptographic operations. The specific execution process is as follows: (1) Generation of TEE hardware certification report and initiation of remote certification After each vHSM instance starts up in the TEE environment, it automatically calls the TEE's built-in hardware authentication module to generate a TEE hardware authentication report (Quote) containing key information about its own operating environment.

[0022] The report must include: the unique identifier of the vHSM instance, the TEE hardware vendor signature, the firmware version and hash value loaded by the vHSM instance, and the integrity check value of the TEE memory area, to ensure that the report can be used to prove the authenticity and tamper-proof nature of the vHSM instance's operating environment.

[0023] The user's local client sends a proof request to all vHSM instances through the preset Remote Attestation interface to obtain the TEE hardware certification report generated by each instance.

[0024] The client calls the remote verification module to verify the legality of the vendor signature in the report based on the root certificate public key provided by the TEE hardware vendor. At the same time, it compares the vHSM instance firmware hash value in the report with the locally stored legal firmware hash value to verify the integrity of the instance loader. In addition, it verifies the TEE memory area check value to confirm that the instance's running memory has not been injected with malicious code or tampered with.

[0025] The vHSM instance is determined to be running in a real, unaltered TEE environment only if all verification items pass; otherwise, subsequent interactions are rejected.

[0026] (2) Establishment of end-to-end secure encrypted channel After successful remote authentication, the user client initiates a secure channel establishment process with each vHSM instance, using a proof-based Diffie-Hellman (PoD-Hellman) key exchange protocol. First, the client and the vHSM instance each generate a temporary asymmetric key pair. , and exchange public keys via an unencrypted link. and Secondly, based on their respective temporary private keys and the other party's temporary public key, combined with the unique identifier of the TEE environment (such as the TEE device ID) obtained during the remote verification process, both parties calculate the shared session key negotiation parameters. Finally, the session key is derived from the negotiation parameters using a preset key derivation function (such as HKDF-SHA256). And determine the encryption algorithm (such as AES-GCM-256) and the message authentication algorithm (such as HMAC-SHA256).

[0027] The secure channel established through this protocol ensures the confidentiality (guaranteed by AES-GCM encryption), integrity (guaranteed by GCM authentication tags or HMAC verification), and non-repudiation (guaranteed by the uniqueness of the session key and the negotiation process) of subsequent transmitted data, preventing channel data from being eavesdropped on, tampered with, or forged.

[0028] (3) Secure transmission of key fragments and activation of vHSM instance The user client retrieves the N key fragments generated in step 1 from local secure storage. ( For each vHSM instance, its corresponding key is fragmented. Use the session key between this instance and the client Encryption is performed to generate encrypted fragments. After attaching a message authentication tag (such as a GCM tag), it is sent to the corresponding vHSM instance through a secure channel.

[0029] After receiving the encrypted fragment, the vHSM instance first verifies the message authentication tag to confirm that the data has not been tampered with during transmission; after successful verification, it uses its own session key. Decryption is performed inside the TEE to obtain fragments of the original key. Subsequently, the built-in secure sharding storage unit of the TEE is invoked to... Stored in an encrypted memory area or hardware-isolated storage partition within the TEE, and storage is prohibited during the storage process. It is exported to an external TEE.

[0030] When the vHSM instance successfully stores the key shards Afterwards, an activation confirmation message is returned to the client. Once the client receives the activation confirmation from all instances, it determines that the vHSM instance cluster has been activated and can enter the waiting state for computation.

[0031] 1.3 Step 3: Remote Cryptographic Operation Request and Collaborative Computation This step aims to receive users' remote cryptographic computation requests, dynamically select arbitration groups, and perform distributed collaborative computation based on key fragmentation, ensuring that computation is completed without the aggregation of complete keys. The specific execution process is as follows: (1) Generation and sending of remote cryptographic operation requests When a user needs to perform password operations in the cloud (such as data decryption, digital signature generation, etc., taking the decryption of Ciphertext data as an example), the local client's operation request module constructs a password operation request data packet.

[0032] This data packet must include: the user's primary identity identifier. (For associating the corresponding key fragment), cryptographic operation type identifier (e.g., "Decrypt"), data to be processed (e.g., ciphertext), operation parameters (e.g., encryption algorithm identifier "ElGamal"), and data based on the user's private key. A digital signature (used to verify the legitimacy and integrity of a request).

[0033] The client sends the request data packet to the cloud-based virtualized cryptographic module management platform through a secure communication link (such as TLS 1.3) to ensure that the request is not tampered with or forged during transmission.

[0034] (2) Selection of the arbitration panel and distribution of requests After receiving the request data packet, the cloud-based virtualized cryptographic module management platform first verifies the validity of the user's digital signature (using the user's public key). ), and verify After confirming the validity of the request by verifying its association with the already activated vHSM instance cluster, the arbitration group selection process is initiated.

[0035] The management platform, based on a preset selection strategy (such as random selection or load balancing selection), randomly selects at least t instances (t is the secret refactoring threshold, t≤N) from the N activated vHSM instances to form an arbitration group. The selection process must ensure that the instances in the arbitration group are distributed in different physical security areas (consistent with the isolation requirements of vHSM deployment in step 1) to avoid the arbitration group from failing due to a single physical area failure.

[0036] Once the selection is complete, the management platform will distribute the cryptographic operation request data packet (with user digital signatures removed but core operation information retained) to each vHSM instance within the arbitration group via a secure channel.

[0037] (3) Execution of distributed threshold cryptography algorithm and generation of partial results Upon receiving the request, each vHSM instance within the arbitration group initiates a threshold cryptography computation unit within the TEE and performs computation according to the following process: First, through Associated local storage key fragments ,confirm First, determine the correspondence with the current computation request; second, based on the encryption algorithm identifier in the request (such as "ElGamal"), load the corresponding threshold cryptography algorithm logic; finally, combine key fragmentation. Perform distributed threshold cryptographic operations on the data to be processed (such as ciphertext) to generate partial operation results. (e.g., partial decryption results, partial signature values).

[0038] Taking the ElGamal algorithm for decryption as an example, the mathematical implementation of its threshold operation process is as follows: Relevant Formulas (Threshold Decryption Example) Assuming the encryption process uses the ElGamal algorithm, the corresponding public key is PK, and the complete private key SK has been fragmented using the secret sharing technique in step 1. ( The ciphertext to be decrypted is stored in each vHSM instance. ,in For random elements, This is an element that contains plaintext information.

[0039] (1) Calculation of partial decryption results: Each vHSM instance in the arbitration group uses its own private key to fragment. Partial decryption is performed within the TEE to obtain a partial decryption result. The calculation formula is: (2) Partial result aggregation and complete decryption: When the client or a designated synthesizer (which can be the management platform and must run in a TEE environment) collects at least t partial decryption results Then, the aggregation results were calculated based on the Lagrange interpolation method. .

[0040] Let the Lagrange coefficients be (Calculated from the x-values ​​corresponding to each instance, consistent with the calculation logic of the Lagrange coefficients in the secret reconstruction in step 1), then the formula for calculating the aggregation result is: in, That is, the "logical aggregation" of private key fragmentation is achieved through Lagrange interpolation, but the complete private key SK is never actually reconstructed on any node; (3) Plaintext restoration: based on aggregation results With ciphertext The plaintext M is calculated using the following formula: (The division operation is performed within the finite field corresponding to the ElGamal algorithm.) It should be noted that throughout the entire threshold cryptography operation, the complete private key SK is never reconstructed or appears in the cloud vHSM instance, management platform, network link, or client (except for private key fragments). It achieves the same operation effect as the complete private key only through the collaborative operation of fragments, thus ensuring key security.

[0041] (4) Partial calculation results are returned Each vHSM instance within the arbitration group generates a portion of the computation results within the TEE. Afterwards, Attach a digital signature based on its own TEE environment (to ensure traceability of the result's origin) and transmit it through a secure channel. The signature is returned to the management platform; or, if a direct connection channel has been established between the client and the vHSM instance, it is returned directly to the user client. The specific return path can be determined by the system's preset configuration.

[0042] 1.4 Step 4: Result Synthesis and Output This step aims to receive, verify, and aggregate some of the computation results, generate the final cryptographic computation result, and ensure that sensitive results are only used locally by the user and not leaked to the cloud. The specific execution process is as follows: (1) Receiving and verifying partial calculation results If some calculation results Forwarded by the management platform, the client first receives the message sent by the management platform. The signature, along with the corresponding vHSM instance signature, is verified using the public key of each vHSM instance (distributed to the client in advance) to confirm its validity. Derived from legitimate arbitration panel examples; if The vHSM instance returns the signature directly, and the client directly verifies the instance signature.

[0043] Meanwhile, the client counts the valid received data. The result synthesis process is initiated only when the number reaches or exceeds the threshold t; if the number is less than t, a request is made to the management platform to reselect arbitration group instances and re-execute the calculation process in step 3 until a sufficient number of valid results are obtained. .

[0044] (2) Synthesis of the final cryptographic operation results The client starts the result synthesis module locally, selects the corresponding synthesis algorithm based on the type of cryptographic operation (mainly Lagrange interpolation, adapted to threshold cryptography logic), and performs synthesis on at least t valid results. Perform aggregate calculations: If it is a decryption operation (such as ElGamal decryption), follow the logic of "partial result aggregation and complete decryption" in step 3, calculate the aggregation result through the Lagrange coefficient, and then combine it with the ciphertext information to restore the plaintext. If it is a signature operation (such as a threshold RSA signature), then a portion of the signature value is interpolated using Lagrange interpolation. The signatures are aggregated into a complete digital signature, thus completing the signature generation process.

[0045] The entire synthesis process is executed locally on the user's local machine, and all After the synthesis is completed, the client will automatically delete the results to avoid security risks caused by the retention of some results.

[0046] (3) Local output and use of final results After the client generates the final cryptographic result (such as plaintext or a complete digital signature), it outputs it only in the local environment for user use. Specific use cases include: local applications reading plaintext for business processing, and generating files containing digital signatures locally.

[0047] Throughout the process, the final result is not transmitted to the cloud or other untrusted environments through any network, ensuring that sensitive information (such as plaintext data and complete signatures) is always within the user's controllable local security domain, completely avoiding the risk of sensitive information leakage caused by the untrusted cloud environment.

[0048] 2. Apparatus Corresponding to the aforementioned remote key security management method for cloud-based virtualized cryptographic modules, this invention also provides a remote key security management device for cloud-based virtualized cryptographic modules. This device, through the coordinated operation of hardware and software modules, achieves remote security control over the entire lifecycle of keys. Its specific composition and the functions of each module are as follows: 2.1 Local Client Module The local client module is deployed on a user-controlled local terminal (such as a user's personal computer, enterprise-specific terminal, hardware encryption device, etc.), and has independent computing, storage, and security protection capabilities. It is the core carrier for users to control key ownership and operational control. Its core functions and implementation details are as follows: (1) Ciphertext Master Identity and Root Key Generation Unit: Ciphertext supports generating user master identity identifiers based on national cryptographic standards (such as SM2) or internationally accepted algorithms (such as RSA-2048, ECC-P256). With the root key pair ( ).

[0049] The entire generation process is executed within a local secure environment (such as a terminal TPM chip or hardware encryption unit) to prevent key information leakage during the generation process; simultaneously, the generated... Perform uniqueness verification (such as comparing with a locally stored identity database) to ensure that it can be uniquely associated with the user's corresponding vHSM instance cluster in subsequent interactions.

[0050] (2) Ciphertext Key Sharding Calculation Unit: Ciphertext has a built-in Identity-Based Encryption (IBE) algorithm module and Shamir's Secret Sharing algorithm module, and can receive the master identity identifier. With root public key As input, first through right Encryption is performed, and then the encrypted result is mapped to the original secret shared material based on the IBE algorithm. Finally, N key fragments are generated according to the preset number of fragments N and the threshold t. .

[0051] This unit supports integrity verification of the fragmentation results (such as generating fragment hash values ​​and storing them locally), which facilitates verification of whether the fragments have been tampered with after subsequent transmission.

[0052] (3) Ciphertext Remote Proof Initiation and Verification Unit: Ciphertext provides a remote proof interaction interface with vHSM instances, can send proof requests to target vHSM instances, and receive and parse TEE hardware certification reports (Quotes).

[0053] It has a built-in TEE vendor root certificate library (such as Intel SGX root certificate, AMD SEV root certificate) to support the legality verification of vendor signatures in the report; at the same time, it has a firmware hash verification function, which can compare the firmware hash value of the vHSM instance in the report with the locally pre-stored legal firmware hash value to ensure that the vHSM runtime environment has not been tampered with; the subsequent secure channel establishment process is only allowed when all verification items pass.

[0054] (4) Ciphertext Secure Channel Establishment Unit: Ciphertext supports the proof-based Diffie-Hellman (PoD-Hellman) key exchange protocol and can negotiate and generate session keys with vHSM instances. It has a built-in AES-GCM-256 encryption module and HMAC-SHA256 authentication module, which can encrypt and authenticate subsequent key fragments, operation requests and other data based on the session key, to ensure the confidentiality, integrity and anti-tampering capability of data transmission; at the same time, it supports the life cycle management of session keys (such as automatically destroying the key after the session ends and updating the session key periodically), reducing the security risks of long-term key use.

[0055] (5) Ciphertext cryptographic operation result synthesis unit: Ciphertext has a built-in Lagrange interpolation algorithm module and threshold cipher result aggregation module, and can receive partial operation results returned by vHSM instance. First, Verify the legitimacy of the source (e.g., verify the vHSM instance signature), and then count the valid ones. The quantity (ensuring it is not less than the threshold t) is finally calculated using Lagrange interpolation or a preset aggregation algorithm. Combined into the final computation result (such as plaintext or complete digital signature).

[0056] The entire synthesis process is executed locally, and the temporarily stored data is automatically deleted upon completion. This is to avoid information leakage caused by retaining some results.

[0057] (6) Ciphertext Local Secure Storage Unit: Ciphertext adopts a hierarchical storage architecture for the root private key. Key fragmentation Sensitive data such as vHSM instance firmware hash values ​​and session keys are stored in storage areas with different security levels: such as... Stored in the terminal TPM chip or hardware encryption unit (cannot be exported). It stores data in a local encrypted partition (using AES-256 encryption) to ensure that sensitive data is difficult to steal even if the local terminal is compromised; at the same time, it supports access control of stored data (such as allowing only specified units within the local client module to access it) to prevent unauthorized operations.

[0058] 2.2 Virtualized Cryptographic Module Management Platform The virtualized cryptography module management platform is deployed in the cloud and has the capabilities of resource scheduling, request processing, instance monitoring, and security auditing. It is the core hub connecting the user's local client and the distributed vHSM instance. Its core functions and implementation details are as follows: (1) Ciphertext User Request Receiving and Verification Unit: Ciphertext provides standardized request access interfaces (such as RESTful API, gRPC) and supports receiving vHSM instance creation requests, cryptographic operation requests, etc. sent by user clients.

[0059] The built-in request validity verification module can verify the user's digital signature in the request (using the user's public key). ), Relationship (confirmed) Requests that fail verification (e.g., the vHSM instance cluster is registered and exists) and whose request parameters are complete (e.g., the number of vHSM instances N≥3, and the operation request contains complete encrypted data) are rejected and logged.

[0060] (2) Ciphertext vHSM instance scheduling and creation unit: Ciphertext connects to the underlying cloud infrastructure (such as physical server clusters, virtualization management systems, TEE resource pools), and supports scheduling TEE resources and creating vHSM instances in at least 3 independent physical security zones (such as different data centers, different racks, and different server nodes) based on the number of instances N in the user request and the physical isolation requirements.

[0061] During the creation process, a unique identifier (such as vHSM_ID) is automatically assigned to each vHSM instance, and information such as the instance's deployment location, TEE type, and firmware version is recorded to form an instance management ledger. At the same time, initial configurations (such as a list of supported cryptographic algorithms and secure communication parameters) are pushed to the created vHSM instances to ensure that the instances can quickly enter the activation state after startup.

[0062] (3) Ciphertext Arbitration Group Organization and Management Unit: Ciphertext has a built-in arbitration group selection strategy module (supporting random selection, load balancing selection, fault avoidance selection, etc.). It can select at least t instances from the N activated vHSM instances to form an arbitration group based on the requirements of cryptographic operation requests (such as response speed and security level) and the real-time status of vHSM instances (such as load rate, online status, and health).

[0063] During the selection process, ensure that instances within the arbitration group are distributed in different physical security areas to avoid the arbitration group failing due to a single area failure; at the same time, assign temporary identifiers (such as Arbiter_ID) to the arbitration group and synchronize the arbitration group member information to the user client and the corresponding vHSM instance to facilitate subsequent distribution of computation requests and aggregation of results.

[0064] (4) Ciphertext Security Audit and Monitoring Unit: Ciphertext supports full-link log recording of user requests received by the platform, creation / destruction / activation status of vHSM instances, selection and operation distribution process of arbitration groups, data transmission records, etc. The log content includes key information such as operation time, operation subject, operation content, result status, etc., and the log cannot be tampered with (such as using blockchain notarization or local hash chain storage).

[0065] Meanwhile, the built-in instance monitoring module can collect the running status of vHSM instances in real time (such as CPU load, memory usage, and TEE integrity status). When an instance abnormality is detected (such as offline or TEE integrity being compromised), an alarm is automatically triggered and the instance management ledger is updated to ensure that abnormal instances are avoided when the arbitration group is selected in the future.

[0066] 2.3 Distributed vHSM instance cluster The distributed vHSM instance cluster consists of N (N≥3) independent vHSM instances. Each instance runs in a TEE environment on a cloud physical server (such as Intel SGX Enclave, AMD SEV VM, ARM TrustZone SecureWorld), possessing hardware-level security isolation and confidential computing capabilities. It is the core execution node for implementing key sharding storage and distributed collaborative computing. Each vHSM instance embeds the following functional units: (1) Ciphertext Remote Authentication Unit: Ciphertext integrates the authentication interfaces provided by TEE hardware (such as Intel SGX EREPORT command, AMD SEV Attestation API), and can automatically generate TEE hardware authentication report (Quote) after the instance starts. The report includes the instance unique identifier (vHSM_ID), TEE hardware information (such as CPU model, TEE version), instance firmware hash value (SHA-256), TEE memory integrity check value and other information, and is signed by the TEE vendor private key.

[0067] It supports receiving verification requests from user clients and sending reports to the clients for environmental trustworthiness verification; at the same time, it can receive verification responses from clients to confirm that it has passed verification and provide a basis for the establishment of subsequent secure channels.

[0068] (2) Ciphertext Secure Sharded Storage Unit: Ciphertext is an encrypted memory area or hardware-isolated storage partition deployed in the TEE (such as SGX Enclave memory, SEV encrypted disk). It only supports access within the TEE and prohibits data from being exported to the outside of the TEE.

[0069] Supports receiving encrypted key fragments sent by user clients via secure channels. Use session keys inside the TEE Decryption yields the original fragment. and to Perform integrity verification (e.g., compare fragment hash values); after successful verification, ... With instance identifier vHSM_ID, user Associated storage forms a sharded storage index, which facilitates quick retrieval during subsequent operations; at the same time, it supports periodic integrity self-checks of shards (such as periodically recalculating and comparing shard hash values) to ensure that shards have not been tampered with during storage.

[0070] 3. Ciphertext Threshold Cryptography Unit: Ciphertext has built-in modules for various threshold cryptography algorithms (such as threshold ElGamal decryption, threshold RSA signature, threshold SM4 encryption, etc.) and can receive cryptographic computation requests distributed by the management platform (including...). Operation type, data to be processed, algorithm identifier), through Associated local storage key fragments And load the corresponding threshold operation logic according to the algorithm identifier.

[0071] Inside the TEE, combined Perform partial operations on the data to be processed and generate partial results. During the operation, it is forbidden to... Alternatively, intermediate results of the computation may be exposed outside the TEE to ensure that the complete key is not aggregated; after the computation is completed, [the following steps are taken]. An additional digital signature based on the instance's private key (used to verify the source of the result) is attached to provide security for subsequent result transmission.

[0072] (4) Ciphertext Secure Communication Unit: Ciphertext supports bidirectional secure communication with user clients and cloud-based virtualized cryptographic module management platforms. It has built-in proof-based Diffie-Hellman key exchange module, AES-GCM-256 encryption module, and HMAC-SHA256 authentication module.

[0073] When communicating with clients, a session key can be negotiated and generated, and key fragments and partial computation results can be transmitted in encrypted form. When communicating with the management platform, computation requests can be received and instance status can be reported through an encrypted link. At the same time, it supports the verification of received communication data (such as verifying message authentication tags and checking data integrity), and directly discards data that fails verification to prevent malicious data injection. In addition, it supports the security management of communication sessions (such as automatic destruction of sessions after timeout and cleanup of session keys after abnormal disconnection) to reduce the security risks of communication links.

[0074] Beneficial effects The beneficial effects of this invention are as follows: 1. Security: The user's core private key is stored in a local secure environment throughout the process and only interacts with the cloud through "threshold sharding". Shards smaller than the threshold cannot restore the key; the vHSM instance runs in a TEE hardware isolation environment, and the trustworthiness of the environment is verified through remote proof. Furthermore, the entire data transmission is encrypted and the operation is bound to identity signature, thus avoiding the risk of cloud key leakage and interaction attacks from the root.

[0075] 2. Compliance: Supports national cryptographic algorithms such as SM2 / SM3 / SM4, key management complies with the requirements of the Cryptography Law, generates tamper-proof logs for the entire operation chain and can be connected to the blockchain for evidence storage, meeting the needs of information security assessment and key lifecycle traceability in industries such as power and finance, and adapting to regulatory compliance control.

[0076] 3. Scalability: vHSM instances can be flexibly deployed in multiple physical regions, with the number adjusted as needed to adapt to cloud-native business expansion; they are compatible with multiple cryptographic algorithms, adopt a modular design, and can quickly connect to existing industry systems, reducing cross-scenario integration and transformation costs.

[0077] 4. Practicality: Distributed collaborative computing enables cloud-based sharded computation and local aggregation of results, balancing security and efficiency. It features low single-process computation time and strong concurrency capabilities. Users only need to complete extremely simple operations such as initialization, sending requests, and receiving results, while complex security logic is executed automatically, reducing the management threshold. Attached Figure Description

[0078] Figure 1 This is a schematic diagram of the method flow described in this invention, illustrating the implementation process of the remote key security management method and device for a cloud-based virtualized cryptographic module. Detailed Implementation

[0079] The present invention will be further described below with reference to specific embodiments: 1. Example This embodiment takes the cloud-based key security management scenario of Guangxi power grid enterprise as an example to explain in detail the specific application process of the remote key security management method and device of the cloud-based virtualized cryptographic module of the present invention, verify its feasibility and effectiveness in high-security scenarios in the Southern Power Grid region, and adapt to the key management needs of core scenarios such as the "West-to-East Power Transmission" supporting business of Guangxi Power Grid, distributed photovoltaic transactions in the region, and encryption of residential electricity information.

[0080] 1.1 Application Scenarios and Background As an important regional power grid of the Southern Power Grid, the Guangxi Power Grid needs to centrally manage the keys of multi-dimensional cloud business systems within the region (such as encrypted transmission of dispatch data for "West-to-East Power Transmission", signature authentication for power supply transactions at Beibu Gulf ports, de-identified storage of residential electricity consumption information throughout the region, and encrypted interaction of distributed photovoltaic grid-connected data).

[0081] In traditional solutions, the local hardware HSM deployment mode is difficult to support the low-latency call requirements of cloud services in 14 prefecture-level cities within the region, while general public cloud KMS cannot meet the compliance requirements of the power industry's Level 3 Information Security Protection and Cryptographic Application Security Assessment (Information Security Protection Evaluation) for key control.

[0082] This embodiment, through the method and apparatus of the present invention, enables the Guangxi power grid cloud key to be "controlled locally (Nanning headquarters) and available in the cloud (distributed nodes within the region)," which not only complies with the requirements of the "Southern Power Grid Network Security Management Measures" but also adapts to the elastic expansion needs of the Guangxi power grid's "city-county" hierarchical business.

[0083] 1.2 Implementation Prerequisites and Environmental Configuration 1.2.1 Hardware Environment Local client: Deployed at the security operation and maintenance center terminal of Guangxi Power Grid Nanning Headquarters, with built-in TPM 2.0 chip and Southern Power Grid customized USB Key (supporting hardware acceleration of national cryptographic algorithms), and has the ability to process AES-256, SM2 / SM4 / SM9 national cryptographic algorithms, ensuring the headquarters' absolute control over the core key.

[0084] Cloud infrastructure: It adopts the regional cloud resources of China Southern Power Grid, and the physical server cluster is distributed in three core nodes in Guangxi (Nanning main node, Liuzhou backup node, and Guilin disaster recovery node). The servers are all equipped with Intel Xeon Gold series processors (supporting SGX technology). Each node is configured with an independent power industry-specific firewall, intrusion prevention system (IPS) and environmental monitoring equipment (such as temperature and humidity, power supply monitoring) to meet the disaster recovery and isolation requirements of the regional power grid's "two locations and three centers".

[0085] Network environment: The local client and the cloud node are connected through the Guangxi Power Grid Dispatch Data Network (SPDnet), which supports the TLS 1.3 protocol and the power-specific encrypted transmission protocol. The network transmission latency is ≤30ms, ensuring the real-time nature of business call keys in various cities within the region.

[0086] 1.2.2 Software and Algorithm Configuration Local client software: The local client module of this invention is integrated, which supports SM2 / SM3 / SM4 national cryptographic algorithms and Southern Power Grid's dedicated dispatch encryption algorithm. It has a built-in Intel SGX root certificate library and a hash value list of Guangxi Power Grid's customized vHSM firmware. It supports key fragmentation and local encrypted storage (bound to the TPM chip at the Nanning headquarters) and the synthesis of calculation results.

[0087] Cloud-based virtualized cryptographic module management platform: Deployed on the private cloud of the Nanning main node of Guangxi Power Grid, it supports RESTful API interface and docking with the existing operation and maintenance management system of Guangxi Power Grid (such as OMS system). It has a built-in arbitration group selection strategy based on "city load balancing" (prioritizing vHSM instances near the business location) and can monitor the running status of vHSM instances in real time (such as CPU load, memory usage, TEE integrity).

[0088] Distributed vHSM instances: Configure N=5 vHSM instances (to meet the security requirement of N≥3), and deploy them on the Nanning master node (2 instances), Liuzhou backup node (2 instances), and Guilin disaster recovery node (1 instance). Each instance runs on the Intel SGX Enclave trusted execution environment and loads the Guangxi power grid dedicated cryptographic algorithm library (including the Southern Power Grid dispatch data encryption algorithm and the residential electricity consumption information desensitization algorithm).

[0089] Security parameter configuration: secret reconstruction threshold t=3 (satisfying the security strategy of t=N / 2+1, adapting to the disaster recovery requirements of "two sites and three centers"), session key is encrypted using AES-GCM-256 algorithm, key fragment transmission adopts PoD-Hellman protocol negotiation, and audit log storage is connected to Guangxi Power Grid Blockchain Evidence Storage System (meeting the power industry's requirement of tamper-proof logs).

[0090] 1.3 Specific Implementation Process 1.3.1 Step 1: System Initialization and Key Seed Distribution Local master identity and asymmetric key pair generation: Guangxi Power Grid Nanning headquarters maintenance personnel initiate an initialization operation through a local client to generate the user master identity identifier. =“GXPG-2024-001” (globally unique, associated with the Guangxi Power Grid's cloud-based business key cluster), generating an asymmetric key pair based on the SM2 national cryptographic algorithm ( ).

[0091] Among them, the private key The public key is stored on the TPM 2.0 chip at the Nanning headquarters (it cannot be exported and can only be accessed by maintenance personnel through multi-factor authentication). The data is uploaded to the cloud management platform of the Nanning main node for filing and synchronized to the Liuzhou and Guilin nodes for backup.

[0092] vHSM instance creation request initiation and cloud deployment: The local client sends a vHSM instance creation request to the cloud management platform. The request includes... The number of instances N=5, the security level (SGX TEE environment, supporting SM2 / SM4 / Southern Power Grid dedicated algorithms), and the physical deployment isolation requirements (distributed across 3 nodes in Nanning, Liuzhou, and Guilin).

[0093] Management platform through After verifying the validity of the request signature, vHSM_1~vHSM_2 are deployed on the Nanning master node, vHSM_3~vHSM_4 are deployed on the Liuzhou backup node, and vHSM_5 is deployed on the Guilin disaster recovery node. Each instance is assigned a unique identifier and its deployment location, TEE type, and other information are recorded.

[0094] Key fragmentation generation and security handling: Local client usage encryption ,get The ciphertext is encrypted using the pre-installed IBE system public key of Guangxi Power Grid (distributed by the Southern Power Grid Key Management Center), and then decrypted using the local IBE private key (stored in the USB Key) to obtain the secret shared original material S (associated with the Guangxi Power Grid's regional business root key material); based on Shamir's Secret Sharing scheme, in the finite field GF(p) ( Construct a quadratic polynomial within the key length of the national cryptographic algorithm (satisfying the prime number requirement and adapting to the key length of the national cryptographic algorithm). (t-1=2, , (Non-zero coefficients randomly selected from a finite field) are used to assign x = 1~5 (corresponding to vHSM_1~vHSM_5) to 5 vHSM instances, resulting in 5 key fragments. ~ Each fragment contains only a portion of the original material's information; without more than three fragments, S cannot be derived or reconstructed.

[0095] 1.3.2 Step 2: Secure Channel Establishment and vHSM Instance Activation TEE Hardware Authentication Report Generation and Remote Verification: After the five vHSM instances are started, each calls the SGX built-in authentication interface to generate a TEE hardware authentication report (Quote). The report includes the unique identifier of the vHSM instance (such as vHSM_1), the Intel SGX vendor signature, the hash value of the Guangxi Power Grid customized vHSM firmware, and the TEE memory area integrity verification value.

[0096] The local client initiates a remote authentication request to all vHSM instances via SPDnet. After receiving the report, it: ① verifies the legality of the vendor signature using the Intel SGX root certificate; ② compares the firmware hash value in the report with the locally stored Guangxi Power Grid customized firmware hash value (to prevent firmware tampering); ③ verifies the TEE memory integrity check value (to ensure that there is no malicious code injection in the instance's running memory).

[0097] The vHSM instance is considered to be running in a real, untampered TEE environment and the remote verification is successful only if all verification items of the 5 instances pass.

[0098] End-to-end secure encrypted channel establishment: After remote proof is successful, the local client and each vHSM instance initiate a proof-based Diffie-Hellman (PoD-Hellman) key exchange process: ① The client and the vHSM instance generate temporary asymmetric key pairs respectively. , ① Exchange public keys via an unencrypted link; ② Both parties combine the TEE device ID (such as SGX Enclave ID) obtained during the remote authentication process with their respective temporary private keys and the other party's temporary public keys to calculate shared negotiation parameters; ③ Generate a session key from the negotiation parameters using the HKDF-SHA256 key derivation function. The data encryption algorithm (AES-GCM-256) and message authentication algorithm (HMAC-SHA256) were determined.

[0099] Data transmitted through this channel can be guaranteed to be confidential (AES-GCM encryption), intact (GCM authentication tag verification), and non-repudiable (session key bound to TEE environment).

[0100] Secure key fragment transmission and vHSM instance activation: The local client retrieves 5 key fragments from the TPM encrypted storage. ~ For each vHSM instance, use its corresponding Encrypted fragments (such as S1 using vHSM_1) Encryption, generation After attaching an HMAC-SHA256 authentication tag, it is sent to the corresponding instance through a secure channel.

[0101] After receiving the data, the vHSM instance first verifies the HMAC authentication tag to confirm that the data transmission has not been tampered with; then it uses the data within the SGXEnclave. Perform the decryption operation to obtain the original fragment. ; ③ will Stored in an SGX encrypted memory area (exporting outside the Enclave is prohibited), and with Establish an index associated with vHSM instance identifiers.

[0102] Once all five vHSM instances have successfully stored the shards and returned activation confirmation messages to the client, the client determines that the Guangxi Power Grid vHSM instance cluster has been activated and enters the waiting state for computation.

[0103] 1.3.3 Step 3: Remote Cryptographic Operation Request and Collaborative Computation Remote cryptographic operation request generation and transmission: Guangxi Power Grid Liuzhou Branch needs to perform decryption operation on a "West-to-East Power Transmission" Liuzhou section dispatch ciphertext (encrypted using the ElGamal algorithm, containing dispatch instructions and transmission power data).

[0104] The Nanning headquarters operations and maintenance personnel construct a cryptographic operation request data packet through a local client. The data packet includes: ① = “GXPG-2024-001” (associated with the entire vHSM cluster); ② Operation type identifier “Decrypt”; ③ Ciphertext to be processed; ④ Algorithm identifier “ElGamal (Southern Power Grid adapted version)”; ⑤ Based on A digital signature (to ensure the legitimacy of the request).

[0105] The client sends request packets to the cloud management platform of the Nanning master node via the TLS 1.3 protocol and SPDnet.

[0106] Arbitration panel selection and request distribution: After receiving the request, the cloud management platform: ① uses ① Verify the validity of the user's digital signature; ② Verify ③ Verify the integrity of the request parameters (such as ciphertext format and compliance of algorithm identifiers).

[0107] After the verification is passed, based on the "city-level load balancing" strategy, three vHSM instances (vHSM_2 (Nanning), vHSM_3 (Liuzhou), and vHSM_5 (Guilin), covering three core nodes and meeting disaster recovery requirements) are randomly selected from the five vHSM instances to form an arbitration group.

[0108] The management platform removes the digital signature from the request, retains the core computing information, and distributes the request to the three vHSM instances within the arbitration group through a secure channel.

[0109] Distributed threshold cryptography algorithm execution and partial result generation: Each vHSM instance within the arbitration group initiates a threshold cryptography operation unit within the SGXEnclave: ① Through Associated key fragments stored locally (vHSM_2 association) vHSM_3 association vHSM_5 association ); ② Load the ElGamal threshold decryption algorithm logic adapted for China Southern Power Grid; ③ Combine key fragmentation with the ciphertext to be processed (Ciphertext=(C1,C2)) to perform partial decryption operations and generate partial results. .

[0110] The specific mathematical process is as follows: using the private key fragments corresponding to the shards. ,calculate (mod finite field GF(p)), i.e., partial decryption result = .

[0111] After the operation is completed, each vHSM instance will... Attach a digital signature based on your instance's private key (ensuring traceability of the result's origin) and transmit it through a secure channel. The signature is then returned to the local client at the Nanning headquarters.

[0112] 1.3.4 Step 4: Result Synthesis and Output (1) Receiving and verifying partial operation results: The local client receives the results returned by vHSM_2. vHSM_3 returned vHSM_5 returned The signature validity of the result is verified using the public keys of three vHSM instances (pre-distributed to local clients) to confirm all... All examples are derived from legitimate arbitration panel cases.

[0113] At the same time, statistical validity If the number is 3, the secret reconstruction threshold t=3 is reached, and the result synthesis process is started; if the effective number is less than t, the cloud management platform is requested to reselect the arbitration group (such as replacing it with vHSM_1, vHSM_4, vHSM_5), and step 3 is re-executed.

[0114] (2) Final cryptographic operation result synthesis: The local client starts the result synthesis module inside the terminal at the Nanning headquarters, and performs aggregation calculation based on the Lagrange interpolation method. The specific steps are as follows: ① Lagrange coefficient calculation: Calculate the corresponding Lagrange coefficients based on the x values ​​(x=2, x=3, x=5) of the three vHSM instances. , , .

[0115] The formula for calculating the coefficient is: (The operation is performed within the finite field GF(p), where t=3 (the secret reconstruction threshold). The x value for vHSM instances within the arbitration group (e.g., calculated) hour, (Take x=3, x=5); denominator The inverse element needs to be solved by the modular inverse operation in the finite field GF(p) to ensure that the division operation is legally executed in the finite field.

[0116] ② Partial result aggregation: Aggregate the results of the three partial operations. , , Combined with the corresponding Lagrange coefficients, an aggregation calculation is performed to obtain intermediate aggregation results. The formula is: Due to the mathematical properties of Lagrange interpolation, it satisfies (Where SK is the complete private key,) (This refers to the private key fragment corresponding to the key fragment), therefore the intermediate aggregation result can be equivalent to: ( This is the first part of the ciphertext to be decrypted. This equivalence ensures that the aggregation result is consistent with the effect of the full private key operation, but the full private key is never actually reconstructed.

[0117] ③ Plaintext restoration: based on intermediate aggregation results With the second part of the ciphertext Performing a division operation within the finite field GF(p) yields the plaintext M of the "West-to-East Power Transmission" dispatch line in Liuzhou. The formula is: (The operation is performed within the finite field GF(p)) The final restored plaintext contains the dispatch instruction "maintain the current transmission power of 500MW" and equipment status data (such as transmission line voltage and current parameters).

[0118] After the synthesis is complete, the client automatically deletes the temporary storage. , , This avoids the risk of key information leakage due to the retention of some calculation results.

[0119] (3) Local output and use of final results: Plaintext is only output to the local client at the Nanning headquarters. After the operation and maintenance personnel are authorized by multi-factor authentication (account password + USB Key), the plaintext is synchronized to the Guangxi Power Grid Dispatch Automation System (SCADA system) for power transmission dispatching operations in Liuzhou section. The plaintext is not transmitted to the cloud (Nanning, Liuzhou, Guilin nodes) or other untrusted environments through the network throughout the process to ensure the confidentiality of dispatching data.

[0120] Meanwhile, the cloud management platform records information such as the request time, arbitration panel members, and result status of this operation, generates audit logs, and synchronizes them to the Guangxi Power Grid Blockchain Evidence Storage System for subsequent compliance assessment and security audit.

[0121] 1.4 Implementation Effectiveness Verification Security verification: According to the Southern Power Grid Security Evaluation Center, in this embodiment, the key is stored in fragments (less than 3 fragments cannot be restored), isolated by a TEE environment (computation / storage is not exposed to the outside), and the master key is controlled locally. (Not uploaded to the cloud), it can resist risks such as man-in-the-middle attacks, cross-node key leakage, and cloud infrastructure tampering, with a key leakage probability of ≤ This meets the security requirements of the core business keys of the Guangxi power grid.

[0122] Compliance verification: It complies with the "Cryptography Law of the People's Republic of China", "Electric Power Industry Network Security Level Protection Assessment Requirements" and "Southern Power Grid Cryptography Application Security Assessment Specifications". Key storage and transmission adopt national cryptographic algorithms, audit logs are traceable, and it has passed the Guangxi Power Grid 2024 Cryptography Application Security Assessment.

[0123] Performance verification: vHSM instance creation response time ≤ 25s (low transmission latency between Guangxi nodes), total decryption time of a single "West-to-East Power Transmission" scheduling ciphertext ≤ 180ms, supports 1200+ concurrent operation requests per second (adapting to the peak business needs of 14 cities in Guangxi power grid); when the Liuzhou node vHSM instance fails, the management platform can reselect the arbitration group within 10s (e.g., replace it with Nanning vHSM_1, vHSM_2 and Guilin vHSM_5) to ensure business continuity.

[0124] This embodiment demonstrates, through regional application in the Guangxi power grid, that the method and apparatus of the present invention can achieve secure storage and remote computation of the core keys of the power grid on untrusted cloud infrastructure (regional cloud nodes), taking into account security, compliance and regional business adaptability, and can be extended to cloud key management scenarios in other regional power grids of the Southern Power Grid (such as Yunnan and Guizhou power grids).

[0125] The embodiments of the present invention are not limited to the above description. The configuration of the server / storage node, the number of vHSM instances (N≥3) and the deployment area can be adjusted according to actual scenarios such as power grid, finance, and government affairs to adapt to cryptographic algorithms such as SHA-256 / SM2 / SM4 and TLS1.3 / PoD-Hellman protocol. All such reasonable improvements fall within the protection scope of the present invention.

Claims

1. A remote key security management method for a cloud-based virtualized cryptographic module, characterized in that, Includes the following steps: System initialization and key seed distribution: Users generate a globally unique primary identity identifier through their local client. and asymmetric key pairs ( , ), The vHSM instance is stored locally and does not participate in network transmission; a vHSM instance creation request is initiated to the cloud management platform. After the platform verifies and approves the request, the vHSM instance is deployed and runs in the TEE environment in at least three independent physical security zones; the client accesses the server via... encryption The original material was obtained through IBE technology, and N key fragments were generated based on Shamir's Secret Sharing scheme. If N≥3, at least t fragments (t≤N and t≥2) are needed to restore the original material; Secure channel establishment and vHSM instance activation: The vHSM instance generates a TEE hardware authentication report, and the client verifies the trustworthiness of the environment through remote authentication; An end-to-end secure channel is established based on the PoD-Hellman protocol. The client transmits encrypted key fragments to the corresponding vHSM instance through this channel. The vHSM instance decrypts and stores the fragments securely to complete the activation. Remote cryptographic computation requests and collaborative computation: Client-generated requests containing Operation type, data to be processed and The signature computation request is sent to the cloud management platform; after the platform verifies the signature, it selects at least t vHSM instances to form an arbitration group and distributes the request; within the arbitration group, vHSM instances combine their local keys to perform threshold cryptographic operations and generate partial computation results. And return; Results Synthesis and Output: Client Verification For validity, when the number of valid results is greater than or equal to t, the final result is generated by aggregation using the Lagrange interpolation method. The result is only used for local output and is not transmitted to the cloud.

2. The method according to claim 1, characterized in that, Storage is encapsulated using local encrypted partitions, hardware security units, or TPM chips; the physical security zone deployed in vHSM instances meets geographical or physical isolation requirements and has independent network protection and monitoring mechanisms; the TEE environment is built using Intel SGX, AMD SEV, or ARM TrustZone technology.

3. The method according to claim 1, characterized in that, The key fragmentation generation process is as follows: using encryption get The ciphertext is encrypted using the preset IBE system public key, and then decrypted using the local IBE private key to obtain the original material; Construct a finite field GF(p) based on the prime number p, and construct a polynomial of degree t-1. ( (Assigning unique x values ​​to N vHSM instances as the original data), and substituting them into the polynomial yields... .

4. The method according to claim 1, characterized in that, Remote verification includes: verifying the legality of the TEE hardware vendor's signature, the consistency between the vHSM instance firmware hash value and the locally stored value, and the integrity of the TEE memory area; the secure channel uses AES-GCM-256 encryption and HMAC-SHA256 authentication, and the session key is derived through the HKDF-SHA256 function.

5. The method according to claim 1, characterized in that, The selection of the arbitration panel must ensure that instances are distributed across different physical security zones. Selection strategies include random selection and load balancing selection. Threshold cryptography supports algorithms such as ElGamal decryption, RSA signature, and SM4 encryption. The operation is performed inside the TEE, and key fragmentation and intermediate results are not exposed to the outside of the TEE.

6. The method according to claim 1, characterized in that, After the results are synthesized, the client automatically deletes the temporary storage. The cloud management platform generates immutable logs for the entire operation process, and these logs can be connected to a blockchain-based evidence storage system.

7. A remote key security management device for a cloud-based virtualized cryptographic module, characterized in that, The system comprises a local client module, a cloud-based virtualized cryptographic module management platform, and a distributed vHSM instance cluster, all of which work collaboratively through a secure interaction protocol. Local client module: Deployed on the user's local terminal, including a master identity and root key generation unit, a key fragment calculation unit, a remote proof initiation and verification unit, a secure channel establishment unit, a calculation result synthesis unit, and a local secure storage unit, used to generate key materials, process key fragments, verify the vHSM environment, establish secure channels, synthesize calculation results, and securely store sensitive data; Cloud-based virtualized cryptographic module management platform: Deployed in the cloud, it includes a user request receiving and verification unit, a vHSM instance scheduling and creation unit, an arbitration group organization and management unit, and a security audit and monitoring unit, which are used to process user requests, schedule the creation of vHSM instances, select arbitration groups, and record audit logs; Distributed vHSM instance cluster: Consists of N vHSM instances, each running in a TEE environment, including a remote authentication unit, a secure sharded storage unit, a threshold cryptography operation unit, and a secure communication unit, used to generate authentication reports, store key shards, perform some operations, and implement secure communication.

8. The apparatus according to claim 7, characterized in that, The local client module's local secure storage unit adopts a layered architecture. Stored in a TPM chip or hardware encryption unit, the key is stored in AES-256 encrypted partitions and access control is supported; the remote verification unit has a built-in TEE vendor root certificate library and initiates the secure channel establishment process only when all verification items pass.

9. The apparatus according to claim 7, characterized in that, The vHSM instance scheduling and creation unit of the cloud management platform connects to the underlying cloud infrastructure, assigns a unique identifier to each vHSM instance and records deployment information; the security audit and monitoring unit collects the vHSM instance running status in real time, triggers alarms and updates the instance ledger when an anomaly is detected.

10. The apparatus according to claim 7, characterized in that, The secure sharded storage unit of the distributed vHSM instance is deployed in TEE encrypted memory or hardware isolated partition, and supports shard integrity self-check; The threshold cryptography operation unit loads multiple threshold algorithm modules, and the operation result is appended with an instance private key signature; The secure communication unit supports two-way encrypted communication with the client and management platform, and directly discards data that fails verification.

Images