Private key management method and device, and computer device

Abstract

The application discloses a private key management method, device and computer equipment, and the private key management method comprises the following steps: obtaining instance binding information sent by a virtualization platform; checking the instance binding information according to a preset key strategy, and generating a birth token when the checking is passed; splitting a logical private key based on the birth token, generating a first private key share and a derivation parameter used for deriving a second private key share, and encrypting and packaging the derivation parameter by taking the instance binding information as additional authentication data to form a key capsule containing the instance binding information; returning the key capsule to a corresponding instance, so that the instance unpacks the key capsule in a self-running environment and derives the second private key share; and when receiving a signature request sent by the instance based on the second private key share, generating a signature result based on the first private key share and the second private key share. The security and controllability of private key management can be effectively improved without relying on a special hardware module.

Description

Technical Field

[0001] This invention relates to the field of key management, and more particularly to a private key management method, apparatus, and computer equipment. Background Technology

[0002] With the development of virtualization and container technologies, business systems inevitably encounter "full lifecycle" security issues related to the creation and operation of numerous virtual machines / containers, including private key generation, distribution, use, rotation, and revocation. Typical risks include: private keys being leaked after images and rootfs are copied; snapshots / backups continuing to use their original private keys after being restored from a different location; difficulty in achieving instance-based binding and traceable auditing during cross-environment migrations; and irreversible, unrestricted, and unconstrained use of remotely issued documents or locally cached plaintext documents.

[0003] To address the aforementioned data and key security issues, a common industry approach involves injecting the private key (or an encrypted private key) into the instance during virtual machine or container startup via configuration files, environment variables, built-in image files, or mounted shared directories, allowing applications to read it directly. This method is simple to implement, has low modification costs, and good compatibility. However, this method results in the private key being permanently stored (making it vulnerable to export from the image, volume copying, and snapshot recovery).

[0004] Alternatively, private key materials can be sealed using vTPM / TPM or a confidential computing environment, or signature / decryption operations can be performed within a protected domain based on PKCS#11 / TEE. These methods are heavily reliant on infrastructure, resulting in high deployment and maintenance costs.

[0005] Therefore, how to enable private keys to securely participate in signature calculations without being stored on the physical machine in a virtualized or containerized environment that does not rely on large hardware security modules has become a pressing technical problem in this field. Summary of the Invention

[0006] Therefore, it is necessary to provide a private key management method, device, and computer equipment to address the above-mentioned technical problems, so as to solve the problem that traditional private key management methods cannot achieve secure participation of private keys in signature calculations without relying on large hardware security modules in virtualized or containerized environments.

[0007] A private key management method, the method comprising:

[0008] Obtain instance binding information sent by the virtualization platform;

[0009] The instance binding information is verified according to a preset key policy, and a birth token is generated when the verification passes.

[0010] The logical private key is split based on the birth token to generate a first private key share and a derived parameter for deriving a second private key share. The derived parameter is then encrypted and encapsulated with the instance binding information as additional authentication data to form a key capsule containing the instance binding information.

[0011] The key capsule is returned to the corresponding instance so that the instance can unseal the key capsule in its own runtime environment and derive the second private key share;

[0012] Upon receiving a signature request sent by the instance based on the second private key share, a signature result is generated collaboratively based on the first private key share and the second private key share.

[0013] Optionally, the instance binding information includes an image digest characterizing the instance's runtime environment, instance identifier, startup time, tenant identifier, key alias, and usage information. The verification of the instance binding information according to a preset key policy includes:

[0014] The consistency of the image digest, the instance identifier, and the startup time is verified to obtain the consistency verification result;

[0015] When the consistency verification result is successful, and the tenant identifier, key alias, and usage information meet the admission conditions of the key policy, the instance binding information is deemed to have passed verification.

[0016] Optionally, the step of splitting the logical private key based on the birth token to generate a first private key share and a derivation parameter for deriving a second private key share, and encrypting and encapsulating the derivation parameter with the instance binding information as additional authentication data to form a key capsule containing the instance binding information, includes:

[0017] A first private key share is generated based on a preset derivation basis and the birth token, and derivation parameters for generating a second private key share are derived based on the instance binding information.

[0018] Based on an encryption algorithm with an additional authentication field, the derived parameters are encrypted and encapsulated using the instance binding information as additional authentication data to generate the key capsule.

[0019] Optionally, the step of unsealing the key capsule and deriving the second private key share in its own operating environment includes:

[0020] The instance performs a consistency comparison between the additional authentication data of the key capsule and the binding information of the current instance in its own operating environment;

[0021] If the comparison is successful, the instance unseales the key capsule to obtain the derived parameters and derives the second private key share based on the derived parameters, and stores it in the memory of the instance;

[0022] In the event of a mismatch, failure to unseal the key capsule, or revocation, the second private key share is cleared, and subsequent signature requests for the instance are blocked.

[0023] Optionally, when receiving a signature request sent by the instance based on the second private key share, generating a signature result collaboratively based on the first private key share and the second private key share includes:

[0024] Obtain the signature purpose, request rate, and session state corresponding to the signature request;

[0025] When the signature purpose meets the preset purpose, the request rate does not exceed the preset threshold, and the session state is valid, a signature result is generated collaboratively based on the first private key share and the second private key share.

[0026] Optionally, the step of generating a signature result based on the first private key share and the second private key share includes:

[0027] Obtain the second signature fragment corresponding to the second private key share, wherein the second signature fragment is generated by the instance based on the second private key share;

[0028] A first signature fragment is generated based on the first private key share;

[0029] The first signature fragment and the second signature fragment are combined to obtain the signature result.

[0030] Optionally, the method further includes:

[0031] When an instance migration, instance restart, or snapshot restore event is detected, new instance binding information is regenerated;

[0032] The new instance binding information is used as additional authentication data to encrypt and encapsulate the derivation parameters used to derive the second private key share, forming a key capsule containing the new instance binding information.

[0033] Optionally, the method further includes:

[0034] When generating the birth token, encrypting and encapsulating the derived parameters to form the key capsule, and collaboratively generating the signature result, corresponding operation logs are generated respectively.

[0035] The operation logs are written into a chained log record in chronological order;

[0036] Upon receiving an audit request, an integrity check is performed based on the chained log records, and the audit is deemed complete when the check passes.

[0037] A private key management device, the device comprising:

[0038] The first acquisition module is used to acquire instance binding information sent by the virtualization platform;

[0039] The first verification module is used to verify the instance binding information according to a preset key policy, and generate a birth token when the verification is successful.

[0040] The first encapsulation module is used to split the logical private key based on the birth token, generate a first private key share and a derived parameter for deriving a second private key share, and encrypt and encapsulate the derived parameter with the instance binding information as additional authentication data to form a key capsule containing the instance binding information.

[0041] The first return module is used to return the key capsule to the corresponding instance, so that the instance can unseal the key capsule and derive the second private key share in its own runtime environment;

[0042] The first signature module is used to generate a signature result based on the first private key share and the second private key share when receiving a signature request sent by the instance based on the second private key share.

[0043] A computer device includes a memory, a processor, and computer-readable instructions stored in the memory and executable on the processor, wherein the processor implements the above-described private key management method when executing the computer-readable instructions.

[0044] In addition, to achieve the above objectives, this application also proposes a readable storage medium storing computer-readable instructions thereon, which, when executed by a processor, implement the above-described private key management method.

[0045] The aforementioned private key management method involves: acquiring instance binding information sent by the virtualization platform; verifying the instance binding information according to a preset key policy, generating a birth token upon successful verification; splitting the logical private key based on the birth token to generate a first private key share and a derivation parameter for deriving a second private key share, and encrypting and encapsulating the derivation parameter with the instance binding information as additional authentication data to form a key capsule containing the instance binding information; returning the key capsule to the corresponding instance so that the instance can unseal the key capsule in its own runtime environment and derive the second private key share; and upon receiving a signature request sent by the instance based on the second private key share, generating a signature result based on the first and second private key shares. By acquiring the instance binding information sent by the virtualization platform and verifying the binding information according to a preset key policy, the key usage capability corresponds to the runtime environment characteristics of the instance, ensuring that only instances that pass verification can obtain subsequent key operation permissions, thus preventing unauthorized instances from using private key resources at the source. By generating a birth token after successful verification and splitting the logical private key, the complete private key is divided into a first private key share and a second private key share that can be derived on the instance side. This avoids the private key existing in plaintext on any single node, thus achieving non-persistent private key storage. Based on this, instance binding information is used as additional authentication data to encrypt and encapsulate the derived parameters, forming a key capsule. This ensures that the key capsule can only be correctly decapsulated in a running instance consistent with the binding information, preventing key reuse and capability leakage caused by image copying, snapshot restoration, or cross-environment migration. When the instance decapsulates the key capsule and derives the second private key share, a signature result is generated collaboratively using the two private key shares held by the server and the instance respectively. Signature calculation is performed without exposing the complete private key, ensuring that the signature operation is controlled by both the server and the instance, providing higher security and verifiability. Ultimately, non-persistent private key storage, instance-level unique binding, and collaboratively controlled use can be achieved in virtualized or containerized environments, effectively improving the security and controllability of private key management without relying on dedicated hardware modules. Attached Figure Description

[0046] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0047] Figure 1 This is a flowchart illustrating a private key management method in one embodiment of the present invention;

[0048] Figure 2This is a schematic diagram of the private key management device in one embodiment of the present invention;

[0049] Figure 3 This is a schematic diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

[0050] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0051] In one embodiment, such as Figure 1 As shown, a private key management method is provided, including the following steps:

[0052] 101. Obtain instance binding information sent by the virtualization platform.

[0053] In this embodiment of the invention, the above-mentioned private key management method can be executed by a key management server to perform secure control over the key lifecycle during the creation or startup of an instance on a virtualization platform.

[0054] The aforementioned key management server can be a key management system (KMS) deployed in a cloud computing environment, used to perform operations such as key generation, encapsulation, splitting, and collaborative signing.

[0055] The aforementioned virtualization platform can be a cloud platform component that provides instance scheduling and runtime environment, such as OpenStack, Kubernetes, Docker, VMware vSphere, etc., used to create and run virtual machine or container instances in a resource pool.

[0056] The instance binding information mentioned above is used to characterize the uniqueness and trustworthiness of the instance's runtime environment, and may include image summary, instance identifier, startup time, tenant identifier, key alias, and usage information.

[0057] For example, when a virtualization platform schedules the creation of a new compute instance, the system automatically generates an instance identifier (such as VM-UUID (i.e., a globally unique identifier for a virtual machine instance) or ContainerID (i.e., a unique identifier for a container instance) during the instance creation phase, calculates an image digest (such as a SHA256 value based on the content of the image file (i.e., a 256-bit secure hash algorithm used to calculate an image digest)), and records the instance's startup time.

[0058] The platform combines the above information with the tenant identifier, key alias, and usage information to form instance binding information, and sends it to the key management server through a secure interface as the basic binding data for subsequent key generation and encapsulation.

[0059] 102. Verify the instance binding information according to the preset key policy, and generate a birth token when the verification is successful.

[0060] In this embodiment of the invention, the preset key policy can be a set of key usage and access control rules pre-configured by the key management server, which is used to limit the scope of key generation and use under different tenants, instances and purposes.

[0061] The aforementioned key policy may include image signature verification rules, tenant identity constraints, usage limitation parameters, request rate limits, key alias matching relationships, and validity period control information, which are used to implement access and usage control during the instance registration and signature request stages.

[0062] The above verification includes consistency verification of the image digest, instance identifier and startup time in the instance binding information to confirm that the current instance was indeed created by a trusted image and is in a valid running state; it also includes policy matching of tenant identifier, key alias and purpose information to determine whether the above instance meets the purpose, tenant and quota constraints specified in the key policy.

[0063] When the instance binding information meets the above policy conditions, the verification is deemed successful.

[0064] A birth token is a one-time, short-term token issued by a key management server to identify the legitimate identity and usability of an instance after verification through a key policy. This birth token can be generated using a cryptographic signature, for example, by signing structured data containing instance binding information and expiration time using the private key of the key management server, to ensure the tamper-proof nature and timeliness of the birth token.

[0065] For example, when a virtual machine instance sends a registration request to the key management server after its creation,

[0066] The key management server first reads the binding information {image digest = image_digest, instance ID = instance_ID, start time = start_time, tenant ID = tenant, key alias = alias, usage information = usage}, and verifies each item according to the preset key policy (also known as KeyPolicy: a key policy object that defines access and usage rules such as usage / rate / tenant). If the image source used by the above instance is trustworthy, the tenant matches, the usage is within the allowed range, and the request rate does not exceed the policy limit, the key management server generates bootstrap_token = Sign_KMS(BIND, exp = 60s) (bootstrap_token: birth token; Sign_KMS(·): a function by which the key management server digitally signs the input data; BIND: a set of binding information, such as image digest / instance ID / start time / tenant / alias / use; exp = 60s: the token is valid for 60 seconds), and returns the above token to the virtualization platform or instance for subsequent key capsule requests and derivation operations.

[0067] 103. Based on the birth token, the logical private key is split to generate a first private key share and a derived parameter for deriving a second private key share. The derived parameter is encrypted and encapsulated with instance binding information as additional authentication data to form a key capsule containing instance binding information.

[0068] In this embodiment of the invention, the logical private key can be a working key derived from the master key system of the key management server, used to perform operations such as signing and decryption. This logical private key is not directly exposed or persisted, but is temporarily generated in the server-side security module as an input source for key splitting.

[0069] The splitting process involves the key management server performing a splitting operation on the logical private key based on the content of the birth token, generating two complementary private key shares.

[0070] One of these is the first private key share held by the server in the long term, while the other is not directly issued but is provided as a derived parameter for the instance to generate a second private key share in a controlled environment.

[0071] The above splitting method can employ a 2-of-2 threshold signature algorithm (such as the SM2 collaborative signature protocol) or other similar secure splitting algorithms, so that no single private key share can independently complete the signature calculation.

[0072] The first private key share can be a signature share stored in the security domain of the key management server. It is used for joint computation with the instance-side share during the collaborative signature process and cannot be exported or accessed in plaintext.

[0073] The derived parameters of the second private key share can be intermediate key material calculated from the logical private key, birth token, and instance binding information using the key derivation function KDF_SM3 (a key derivation function based on SM3).

[0074] The above derived parameters do not contain directly usable private key values. Only through a specific derivation algorithm in a bound environment can a second private key share on the instance side be generated, thereby achieving a strong binding between the instance and the key capabilities.

[0075] Additional authentication data can be understood as a set of external data that participates in integrity verification and authentication during encryption encapsulation. Its content corresponds to instance binding information {image digest, instance identifier, startup time, tenant identifier, key alias, and purpose information}, which is used to ensure that the key capsule can only be unsealed in a runtime environment consistent with the binding information.

[0076] A key capsule can be a data object formed by encapsulating derived parameters with a symmetric encryption algorithm (such as SM4-GCM) with an additional authentication field. Its internal structure may include fields such as CapsuleHeader, Ciphertext, and Tag.

[0077] The CapsuleHeader records metadata such as the encapsulation algorithm, random salt, random number nonce, additional authentication data, and policy information, which are used for integrity verification and policy verification during unsealing.

[0078] For example, when the key management server receives the birth token, it first generates a random salt for deriving the key and a random number for cryptographic uniqueness.

[0079] Subsequently, based on the master key master_key, tenant identifier tenant, and key alias, the derived key kek (KeyEncryptionKey, encapsulation key) is calculated using the key derivation function KDF_SM3(·), that is: kek=KDF_SM3(master_key,salt||tenant||alias).

[0080] Then, the instance binding information is serialized to form Additional Authenticated Data (AAD), denoted as AAD=Serialize(BIND). The encryption algorithm SM4-GCM with additional authentication field is used, with the derived key kek and the random number nonce as encryption parameters, to encrypt the derived parameter (Payload) to obtain ciphertext C and authentication tag: (C,Tag)=SM4_GCM_Enc(kek,nonce,AAD,Payload).

[0081] Finally, the CapsuleHeader is assembled, which includes the version number (version), algorithm identifier (alg), random salt (salt), nonce (nonce), additional authentication data (aad), and policy information (policy={ttl, rate_limit, tenant, alias, usage}). After assembly, the complete key capsule structure is obtained: KeyCapsule=CapsuleHeader||C||Tag. This key capsule is then returned to the corresponding instance for subsequent unsealing and share derivation operations.

[0082] 104. Return the key capsule to the corresponding instance so that the instance can unseal the key capsule and derive the second private key share in its own runtime environment.

[0083] In this embodiment of the invention, the self-running environment can refer to the isolated execution environment in which the instance runs on a virtualization platform, such as a virtual machine operating system instance, a container runtime environment, or a restricted sandbox environment. This running environment is isolated from other instances and possesses security features such as memory residency, read-only file system access, or minimum privilege operation, enabling the unsealing of the key capsule and the derivation of the second private key share without exposing the private key data.

[0084] Unsealing refers to an instance performing decryption and integrity verification operations with additional authentication on a received key capsule within its own runtime environment. During unsealing, the instance first reads the CapsuleHeader and compares the additional authentication data recorded within it with the current instance's binding information item by item (including image digest, instance identifier, startup time, tenant identifier, key alias, and purpose information). When the comparison results match, the instance reconstructs the encapsulated key based on the algorithm parameters and random materials (salt, nonce) in the CapsuleHeader, and performs decryption operations with additional authentication fields, such as SM4-GCM, to recover the encapsulated derived parameters. If the comparison does not match or the unsealing verification fails, the operation is immediately terminated and temporary data is cleared to prevent the key capabilities from being illegally migrated or reused.

[0085] Derivation can refer to the process where, after successful unsealing, the instance uses the obtained derivation parameters in conjunction with the instance's runtime seed (such as instance_seed, runtime random numbers, etc.) to execute a key derivation function to calculate the local second private key share, share_B. This second private key share exists only in the instance's memory or kernel keyring, is not persistently stored on disk, and is immediately cleared when the instance exits, is revoked, or is triggered by an exception.

[0086] The second private key share can be used for subsequent collaborative signature operations with the server, but it cannot perform signature calculations or recover the complete private key on its own, thus achieving secure separation.

[0087] For example, when an instance receives a KeyCapsule returned by the key management server, a pre-injected lightweight agent mounts a temporary directory " / run / keyagent" inside the instance and manages the local communication interface " / run / keyagent.sock" for interacting with applications within the instance.

[0088] Before performing the unblocking operation, the agent first calls the binding verification function CheckBind(AAD(ctx),BIND).

[0089] Here, AAD(ctx) represents Additional Authenticated Data calculated in the instance's current runtime environment, which originates from binding fields collected during instance runtime (such as image digest, instance identifier, startup time, etc.); BIND represents the binding information recorded in the key capsule. The above function is used to compare the two items one by one to verify that the key capsule indeed belongs to the current instance.

[0090] When the comparison matches, it indicates that the binding relationship between the key capsule and the instance is valid. The agent then recalculates the encapsulation key kek (KeyEncryption Key, a derived key used for capsule encryption and decryption) through the key derivation function KDF_SM3(master_key,salt||tenant||alias) based on the random salt, nonce, tenant identifier, and key alias in the capsule header.

[0091] Next, the agent takes the encapsulation key kek, the random number nonce, and the additional authentication data AAD as input and executes the symmetric decryption algorithm SM4_GCM_Dec(kek,nonce,AAD,C,Tag) with additional authentication fields. Here, C (Ciphertext) is the encrypted data block in the key capsule, and Tag is the integrity tag generated by the encryption algorithm, which is used to verify that the decryption result has not been tampered with.

[0092] When decryption is successful and authentication verification passes, the original derived parameters (Payload) are restored.

[0093] Subsequently, the agent calls the derived function `DeriveShare(Payload, instance_seed)`, where `instance_seed` is a random seed generated by the instance at runtime to ensure the uniqueness and randomness of the derivation result. The function outputs a second private key share, `share_B`. This share is stored only in the instance's memory or kernel keyring, is not persisted to disk, and is used only by the local signing agent.

[0094] If any of the above steps result in unsealing authentication failure, binding mismatch, or detection of a revocation event, the agent will immediately perform a security cleanup operation Zeroize(share_B) to completely remove any remaining share data in memory and reject subsequent signing requests for the instance, thereby preventing the private key from being used by unauthorized instances or reused after snapshot recovery.

[0095] 105. Upon receiving a signature request sent by an instance based on the second private key share, generate a signature result collaboratively based on the first private key share and the second private key share.

[0096] In this embodiment of the invention, the signature request can be a signature call request sent by an instance to the key management server based on business needs after the key capsule has been unsealed and a second private key share has been derived. The signature request may include fields such as message digest, key alias, purpose information, timestamp, random number, and optional session token, used to characterize the context information of the current signature action.

[0097] When an instance generates a signature request, it can call the signature function through the interface / run / keyagent.sock managed by the local agent. The agent encapsulates the signature request and carries the signature fragment or negotiation parameters corresponding to the second private key share, and sends it to the collaborative signature interface (e.g., / v1 / cosign) of the key management server through a secure channel.

[0098] The signature result can be a digital signature value jointly calculated by the key management server and the instance based on their respective private key shares. The above signature result conforms to the signature format of national commercial cryptographic algorithms (such as SM2) and can be used to verify the integrity and authenticity of the message source.

[0099] During the generation process, the server only participates in calculating the first signature fragment, while the instance only calculates the second signature fragment. The two are combined through a security protocol to form the final signature result. Neither end can derive the complete private key or independently complete the signature calculation. The signature result can simultaneously generate a signature receipt (sig_receipt) to record information such as signature time, purpose, instance identifier, and quota count for subsequent auditing.

[0100] For example, when an application within an instance needs to digitally sign a business request message, it first calculates the hash value of the message to be signed to obtain a message digest (msg_hash, MessageHash), which is used as input for the subsequent signature algorithm.

[0101] The application then sends a signature request instruction SIGN(msg_hash, alias, usage) to the communication interface " / run / keyagent.sock" via a local lightweight agent.

[0102] Here, alias represents a key alias used to identify the logical key used for this signature; usage represents the purpose of the signature (e.g., "sign", "verify", "auth"), used to match the policy object to control signature permissions.

[0103] Upon receiving the above request, the instance agent first verifies the validity of the current session state to ensure the request originates from a legitimate instance environment. If verification is successful, the agent forwards the request to the key management server's collaborative signature interface / cosign to initiate a cross-platform collaborative signature operation.

[0104] After receiving the request, the key management server verifies the signature purpose and request rate based on the policy object KeyPolicy. KeyPolicy is a preset key policy object that defines security parameters such as signature purpose restrictions, call frequency limits, and tenant authorization scope.

[0105] When the usage of the signature meets the policy constraints and the request rate does not exceed the preset threshold, the server calculates the first stage result of the signature based on its own first private key share (share_A) to obtain the first signature fragment (partial_A).

[0106] At the same time, the instance-side agent calculates the second signature fragment (partial_B) based on the second private key share (share_B) stored in memory.

[0107] Subsequently, the key management server inputs the signature fragments from both ends into the collaborative signature synthesis function Combine_SM2(partial_A,partial_B). The function performs elliptic curve operations and random number recombination according to the 2-of-2 collaborative signature protocol of the SM2 elliptic curve digital signature algorithm to generate the final complete signature result sig(Signature).

[0108] While generating the signature, the key management server generates a signature receipt sig_receipt (SignatureReceipt), which records the signature time (timestamp), signature usage (usage), current tenant quota count (quota_count), and transparent log index log_index_sign (signature log index) for subsequent auditing and tracing.

[0109] Finally, the server returns the signature result sig and the corresponding receipt sig_receipt to the instance.

[0110] After receiving the returned result, the instance agent passes the signature result to the upper-layer application, which then appends the signature data to the business message and sends it to the target server for verification, thus completing the entire secure signature process.

[0111] In this embodiment of the invention, instance binding information sent by the virtualization platform is obtained; the instance binding information is verified according to a preset key policy, and a birth token is generated when the verification passes; the logical private key is split based on the birth token to generate a first private key share and a derivation parameter for deriving a second private key share, and the derivation parameter is encrypted and encapsulated with the instance binding information as additional authentication data to form a key capsule containing the instance binding information; the key capsule is returned to the corresponding instance so that the instance can unseal the key capsule in its own runtime environment and derive the second private key share; when a signature request is received from the instance based on the second private key share, a signature result is generated collaboratively based on the first private key share and the second private key share. By obtaining instance binding information sent by the virtualization platform and verifying the binding information according to a preset key policy, the key usage capability corresponds to the runtime environment characteristics of the instance, ensuring that only instances that pass verification can obtain subsequent key operation permissions, thus preventing unauthorized instances from using private key resources from the source. By generating a birth token after successful verification and splitting the logical private key, the complete private key is divided into a first private key share and a second private key share that can be derived on the instance side. This avoids the private key existing in plaintext on any single node, thus achieving non-persistent private key storage. Based on this, instance binding information is used as additional authentication data to encrypt and encapsulate the derived parameters, forming a key capsule. This ensures that the key capsule can only be correctly decapsulated in a running instance consistent with the binding information, preventing key reuse and capability leakage caused by image copying, snapshot restoration, or cross-environment migration. When the instance decapsulates the key capsule and derives the second private key share, a signature result is generated collaboratively using the two private key shares held by the server and the instance respectively. Signature calculation is performed without exposing the complete private key, ensuring that the signature operation is controlled by both the server and the instance, providing higher security and verifiability. Ultimately, non-persistent private key storage, instance-level unique binding, and collaboratively controlled use can be achieved in virtualized or containerized environments, effectively improving the security and controllability of private key management without relying on dedicated hardware modules.

[0112] It is understood that in the specific implementation of this application, data related to instance binding information, preset key policies, logical private keys, etc. are involved. When the embodiments in this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0113] Optionally, the instance binding information includes an image digest, instance identifier, startup time, tenant identifier, key alias, and usage information that characterize the instance's runtime environment. In the step of verifying the instance binding information according to a preset key policy, the consistency of the image digest, instance identifier, and startup time can also be verified to obtain a consistency verification result. If the consistency verification result is successful and the tenant identifier, key alias, and usage information meet the admission conditions of the key policy, the instance binding information is deemed to have passed verification.

[0114] In this embodiment of the invention, the instance runtime environment can refer to the actual virtual machine instance or container instance running in the virtualization platform. Its running status, image source, and tenant affiliation jointly determine the trustworthiness of the instance.

[0115] A mirror digest can be a hash digest value, such as a SHA256 value, calculated from the content of the mirror file used to create the instance. It is used to verify that the source and content of the mirror have not been tampered with and is an important basis for supply chain trust verification.

[0116] An instance identifier can be a unique identifier assigned by the virtualization platform, such as the UUID of a virtual machine or the ContainerID of a container, used to uniquely identify the currently running instance. Together with the image digest and startup time, it constitutes the "birth characteristics" of the instance.

[0117] The startup time can be a timestamp generated when the instance is created or restarted. It is used to distinguish the execution process of instances in different lifecycles and prevent instances from retaining their original identity after snapshot restoration or instance replication.

[0118] Tenant identifiers can be logical tags used to identify the user or project to which an instance belongs. The key management server can use this to distinguish the key space and usage quota of different tenants, thereby achieving multi-tenant isolation and auditing.

[0119] A key alias can be a stable reference name used in a key management system to identify logical private key objects, such as "sm2 / prod / order", so that it can be uniformly managed and replaced when rotated or revoked.

[0120] Purpose information can be the operation type declared by the instance when invoking the key, such as "sign", "verify", or "decrypt", which is used to limit the minimum authorized scope of key use at the policy level.

[0121] The admission criteria can be a set of verification rules defined in the preset key policy, including mirror signature or tag matching rules, tenant authorization scope, key alias corresponding to the purpose, request rate limit, and effective time window, etc.

[0122] The key management server will only issue a generation token and allow subsequent key operations if the instance's binding information meets all of the above admission conditions.

[0123] For example, when a tenant's virtual machine instance starts up, the virtualization platform first generates binding information to identify the runtime environment of the instance.

[0124] The binding information mentioned above may include the following fields:

[0125] Image Digest: A hash value calculated from the contents of the image file used by the instance, such as a digest generated using the SHA-256 (Secure Hash Algorithm 256) algorithm, used to verify that the image content has not been tampered with;

[0126] Instance ID: A globally unique identifier assigned by the virtualization platform, such as VM-UUID (Virtual Machine Universally Unique Identifier), used to distinguish different instances;

[0127] Start Time: The timestamp of the instance when it is created or restarted. It can be recorded in the ISO 8601 standard format to distinguish the runtime environment of different lifecycles.

[0128] Tenant ID: Used to identify the tenant account or project number to which the instance belongs;

[0129] Key Alias: A name used in the key management system to reference logical key objects, such as "sm2 / prod / pay";

[0130] Usage information: Indicates the authorized use of the key, such as "sign" (signing), "verify" (verifying), etc.

[0131] After receiving the above binding information, the key management server first performs a consistency verification on the image digest to confirm that it completely matches the registered trusted image record.

[0132] Subsequently, the server performs matching and verification of tenant identifier, key alias, and usage information based on the preset key policy object KeyPolicy (Key Management Policy).

[0133] The KeyPolicy allows configuration of constraints such as usage restrictions (e.g., only allowing payment signatures) and call rate limits (e.g., QPS≤10, i.e., a maximum of ten requests per second).

[0134] When the binding information meets the image consistency verification and passes the key policy matching, the binding verification of the above instance is determined to be successful. The key management server generates and issues the corresponding bootstrap token for subsequent key derivation and capsule encapsulation processes.

[0135] Optionally, in the steps of splitting the logical private key based on the birth token to generate a first private key share and a derivation parameter for deriving a second private key share, and encrypting and encapsulating the derivation parameter with instance binding information as additional authentication data to form a key capsule containing instance binding information, the first private key share can also be generated based on a preset derivation basis and the birth token, and the derivation parameter for generating the second private key share can be derived based on the instance binding information; the derivation parameter can be encrypted and encapsulated with instance binding information as additional authentication data based on an encryption algorithm with an additional authentication field to generate a key capsule.

[0136] In this embodiment of the invention, the preset derivation basis can be a set of basic parameters used to generate private key shares, such as the master key of the key management server, system random number, tenant identifier, key alias, and security policy version number. The key management server can use the combination of the above-mentioned derivation basis and birth token as input to calculate the first private key share through the key derivation function (KDF), thereby ensuring that the private key share corresponding to each instance is unique and unpredictable under different tenants, different uses, and different lifecycles.

[0137] Encryption algorithms with an additional authentication field can be symmetric encryption algorithms capable of performing integrity verification and authentication of external data while encrypting. Examples include national commercial cryptographic algorithms such as SM4-GCM, AES-GCM, or other equivalent AEAD (Authenticated Encryption with Associated Data) algorithms. In these algorithms, instance binding information is used as Additional Authentication Data (AAD) in the encryption operation. This AAD is not encrypted but is included in the generation process of the integrity verification tag, ensuring that the key capsule must provide completely consistent binding information to pass verification when unsealed, thus achieving a strong binding between the key capsule and the instance runtime environment.

[0138] For example, when the key management server needs to generate a key capsule for a certain instance, it first calculates the derived key for encapsulation based on the master key, tenant identifier, key alias, and random salt.

[0139] Specifically, the server calculates the derived key kek = KDF_SM3(master_key, salt||tenant||alias) using the key derivation function KDF_SM3(·) (a key derivation function based on the Chinese national cryptographic hash algorithm SM3) based on the master key, tenant identifier, key alias, and random salt. This derived key kek (Key Encryption Key) is used to encrypt and encapsulate subsequent derived parameters.

[0140] Subsequently, the server uses the serialized result of the instance binding information, AAD=Serialize(BIND), as Additional Authenticated Data (AAD). This data is not encrypted during the encryption process, but it participates in the integrity verification and can be used to verify the consistency between the key capsule and the instance's runtime environment.

[0141] Meanwhile, the server generates a random number (nonce) as a unique parameter for the encryption algorithm to prevent replay attacks and duplicate encryption.

[0142] After the above preparations are completed, the server executes the encryption algorithm SM4_GCM_Enc(kek,nonce,AAD,Payload) with an additional authentication field. SM4-GCM uses the Galois / Counter Mode (GCM) of the national commercial cryptographic algorithm SM4, which can simultaneously achieve confidentiality and integrity protection. The encryption result includes ciphertext C and an authentication tag.

[0143] Here, Payload represents the encrypted payload content, which may contain derived parameters or negotiation seeds used to generate a second private key share on the instance side.

[0144] After encryption is completed, the server assembles the key capsule header, which records the encapsulation algorithm version number, algorithm type, random salt, random number, additional authentication data, and policy information.

[0145] For example:

[0146] CapsuleHeader={version=1,alg="SM4-GCM",salt,nonce,aad=AAD,policy={ttl,rate_limit,tenant,alias,usage}}.

[0147] Finally, the server combines the key capsule header, ciphertext, and verification tag according to the structure to form a complete key capsule: KeyCapsule=CapsuleHeader||C||Tag, and returns the key capsule to the corresponding instance.

[0148] Since the instance binding information has been written into the additional authentication domain, it can only be unsealed through authentication in a runtime environment that is completely consistent with the binding information mentioned above.

[0149] Therefore, when mirror copying, snapshot restoration, or cross-environment migration causes the binding information to be inconsistent, the aforementioned key capsule will not be able to be properly unsealed, thus ensuring the non-transferability and non-reusability of key capabilities.

[0150] Optionally, in the step of unsealing the key capsule and deriving the second private key share in its own operating environment, the instance can also perform a consistency comparison between the additional authentication data of the key capsule and the current instance binding information in its own operating environment; if the comparison is consistent, the instance unseales the key capsule to obtain the derivation parameters and derives the second private key share based on the derivation parameters, and stores it in the instance's memory; if the comparison is inconsistent, the key capsule unsealing fails, or revocation is triggered, the second private key share is cleared and subsequent signature requests of the instance are blocked.

[0151] In this embodiment of the invention, before performing the unsealing operation, the instance first calls the binding verification function to compare the above-mentioned additional authentication data with the instance binding information of its own runtime. When the comparison is consistent, it confirms that the key capsule corresponds to the current instance before it can continue to unseal.

[0152] The unsealing process can employ symmetric decryption algorithms with additional authentication fields (such as SM4-GCM mode) to ensure data confidentiality and integrity.

[0153] Specifically, the instance reads the CapsuleHeader information and reconstructs the encapsulation key (kek) based on the random salt, random number (nonce), and instance binding information recorded therein.

[0154] Subsequently, the instance calls the decryption function SM4_GCM_Dec(kek,nonce,AAD,Ciphertext,Tag), where:

[0155] AAD (Additional Authenticated Data) is additional authentication data entered during encryption, used to verify the consistency of instance binding information;

[0156] Ciphertext is the encrypted ciphertext data block;

[0157] A Tag (Authentication Tag) is an authentication label generated by an encryption algorithm, used to detect whether data has been tampered with.

[0158] Once the above decryption operation is successfully completed, the instance can recover the encapsulated derived payload, which contains derived parameters used to generate the second private key share.

[0159] The instance then calls the derived function DeriveShare(Payload, instance_seed).

[0160] in:

[0161] DeriveShare(·) is a key derivation function used to calculate a new key share based on the input parameters;

[0162] instance_seed is a random seed generated at runtime for the instance to ensure that the derived result is unique and unpredictable across different instances.

[0163] The second private key share, calculated based on the derived parameters and the random seed, is denoted as share_B.

[0164] The aforementioned shares reside only in the instance's volatile memory or the operating system's keyring and are not persistently stored on disk.

[0165] When an instance exits, an exception occurs, or a revocation signal is detected, the system immediately performs a cleanup operation Zeroize(share_B), which erases all remaining private key data in memory to prevent subsequent recovery or unauthorized access.

[0166] If, during the unsealing process, the additional authentication data is found to be inconsistent with the current instance binding information, the unsealing verification fails, or a revocation event is triggered, the instance will also perform the Zeroize(share_B) operation and return an error status code to the upper-layer application, refusing to continue the signing request.

[0167] The above mechanism can prevent keys from being illegally reused in unauthorized instances or in environments restored from snapshots, thereby achieving instance-level binding and one-time anti-reuse protection for key capabilities.

[0168] Optionally, when receiving a signature request sent by an instance based on the second private key share, in the step of generating a signature result based on the first private key share and the second private key share, the signature purpose, request rate and session state corresponding to the signature request can also be obtained; when the signature purpose meets the preset purpose, the request rate does not exceed the preset threshold and the session state is valid, the signature result is generated based on the first private key share and the second private key share.

[0169] In this embodiment of the invention, the signature purpose can be the use case or functional category declared by the instance when initiating the signature request, such as "sign", "verify", "decrypt", or "attest". The key management server can match and verify the signature purpose according to the purpose field configured in the key policy, and only allow requests that are consistent with the current key alias, tenant, and policy-agreed purpose to pass, thereby preventing the key from being misused in unauthorized scenarios.

[0170] The request rate can refer to the number of signature calls or throughput rate of the same instance, tenant, or key alias within a preset time window. The key management server can calculate the request rate based on real-time statistics or a sliding window mechanism and compare it with the threshold in the policy. When the request rate exceeds the preset limit, degradation or blocking actions can be performed, such as temporarily rejecting signature requests, reducing the signature frequency, or triggering risk control warnings, to prevent the key capabilities from being abused or used in bulk by abnormal scripts.

[0171] Session state refers to the validity of the short-term token or session handle currently used by the instance, including whether the session is within a valid time window, whether it has been revoked, whether a migration / restart event has been triggered, or whether the re-proof process has been completed. When the session state is valid, it means that the instance is still in a trusted operating environment and has passed identity verification; if session expiration, revocation hit, or re-proof incomplete is detected, the key management server rejects the signature request and requires the instance to re-initiate the birth and capsule retrieval process to update key capabilities.

[0172] For example, when an instance needs to perform a transaction signing operation, the signing request it sends to the key management server can include the following parameters:

[0173] alias="sm2 / prod / pay": This indicates a key alias used to uniquely identify the logical key object used for this signing. For example, "sm2 / prod / pay" can represent the SM2 signing key used for payment transactions in a production environment.

[0174] usage="sign": Indicates the purpose of the key (Usage), which specifies that the request type is a signing operation, to distinguish it from other uses such as verification, decryption, etc.;

[0175] ts=timestamp: Represents a timestamp, used to identify the time when the signature request was initiated, and can be used for timeliness and replay verification on the server side;

[0176] token=session_token: This represents a session token, which is used to identify the session state and authorization credentials of the current instance. The server can use this token to verify whether the request source is legitimate and whether the session is valid.

[0177] After receiving the request, the key management server first verifies whether usage=sign is in accordance with the permitted use of the key policy, then counts whether the number of signature requests made by the above tenant in the last 60 seconds exceeds the configured threshold (e.g., 100 times / minute), and then checks whether the session_token is within its validity period and has not been included in the revocation list.

[0178] If all the above conditions are met, the server uses the first private key share (share_A) and the second private key share (share_B) returned by the instance to jointly execute the threshold signature algorithm, generate a signature result that conforms to the SM2 standard, and return the signature value and signature receipt.

[0179] If any condition is not met, the signing process will be terminated, and the reason for rejection and related session logs will be recorded.

[0180] Optionally, in the step of generating a signature result based on the first private key share and the second private key share, a second signature fragment corresponding to the second private key share can also be obtained, the second signature fragment being generated by the instance based on the second private key share; a first signature fragment is generated based on the first private key share; and the first signature fragment and the second signature fragment are combined to obtain the signature result.

[0181] In this embodiment of the invention, the collaborative signature process can be implemented using threshold signature or multi-party secure computation (MPC) protocol, such as the SM2 2-of-2 collaborative signature scheme that conforms to the national cryptographic standard.

[0182] In the above scheme, the logical private key is split into two independent private key shares, stored separately on the key management server and the instance. The share stored on the key management server is designated as the first private key share, and the share stored on the instance is designated as the second private key share. Neither share can be used to perform a signature operation independently; a complete signature can only be generated through protocol interaction.

[0183] The instance can calculate the second signature fragment based on its second private key share share_B and the hash digest msg_hash (Message Hash) of the message to be signed.

[0184] For example, the instance agent can first perform a hash operation on the message to be signed locally to obtain the message digest msg_hash, and then call the local signature function PartSign_B(share_B,msg_hash) to generate a second signature fragment partial_B that does not contain complete signature information.

[0185] The second signature fragment mentioned above only represents a partial signature calculation result of the message on the instance side. It cannot restore the complete signature and will not expose the private key content. Therefore, it can be transmitted to the key management server in a secure channel.

[0186] After receiving the second signature fragment partial_B, the key management server performs the first-stage signature calculation based on its own first private key share share_A and the same message digest msg_hash, and calls the function PartSign_A(share_A,msg_hash) to generate the first signature fragment partial_A.

[0187] Subsequently, the server calls the signature combination function Combine_SM2(partial_A,partial_B) to merge the two signature fragments from the server and the instance using elliptic curve operations to generate the final complete signature result sig.

[0188] During the above process, neither party can independently recover the complete signature or deduce the logical private key, effectively avoiding the risk of single point of leakage. In addition, the key management server can generate signature receipt information at the same time as generating the signature result, including the signature time, purpose, tenant identifier, key alias and quota count, and record it in a transparent log for subsequent auditing and traceability.

[0189] Optionally, the method can also regenerate new instance binding information when an instance migration, instance restart, or snapshot recovery event is detected; and use the new instance binding information as additional authentication data to encrypt and encapsulate the derivation parameters used to derive the second private key share, forming a key capsule containing the new instance binding information.

[0190] In this embodiment of the invention, a migration event can refer to an online migration operation performed by a virtual machine or container at the platform layer; a restart event can refer to the restart of an instance or an operating system-level restart process; and a snapshot recovery event can refer to the situation where an instance is restored from a snapshot or backup image. These events typically cause changes to the instance's runtime environment or context parameters, such as startup time, runtime location, resource allocation, or instance identifier, thus requiring the re-establishment of trusted bindings.

[0191] The new instance binding information may include fields such as the updated image summary, instance identifier, startup time, tenant identifier, key alias and usage information. The startup time field is regenerated each time the system restarts or recovers and is used to uniquely identify the new runtime cycle.

[0192] After detecting the above events, the key management server re-executes the birth verification process based on the new binding information and re-encrypts and encapsulates the original derived parameters.

[0193] Specifically, the server can use the new instance binding information as Additional Authenticated Data (AAD) and call a symmetric encryption algorithm with an additional authentication field (such as SM4-GCM mode) to perform encryption operations on the payload data used to derive the second private key share.

[0194] During the above process, the server can generate a new random number nonce_new to ensure the uniqueness of the encryption process, and calculate the verification tag Tag_new to verify data integrity.

[0195] Encryption operations can be represented as:

[0196] (C_new,Tag_new)=SM4_GCM_Enc(kek,nonce_new,AAD_new,Payload),

[0197] Here, kek (Key Encryption Key) is the encapsulation key, used to perform symmetric encryption operations;

[0198] AAD_new represents the new additional authentication data, corresponding to the latest instance binding information;

[0199] C_new is the generated ciphertext data block;

[0200] Tag_new is the integrity verification tag.

[0201] After encryption is completed, the server can assemble the ciphertext, verification tag, and new metadata (including the random number nonce_new, timestamp, and policy field) into a new key capsule object KeyCapsule_new.

[0202] The key capsules mentioned above contain updated instance binding information, which can be correctly unsealed and used in the new operating environment.

[0203] Because the Additional Authentication Data (AAD) has been updated along with the new instance binding information, the authentication domain of the original key capsule no longer matches the current operating environment. Therefore, the old key capsule will not be able to pass the unsealing verification in the migrated or snapshot restored instance.

[0204] The above mechanism ensures that the old key capsule and its corresponding private key capabilities automatically become invalid in the new environment, thereby preventing the risk of key abuse and cross-instance reuse caused by virtual machine migration, image copying or snapshot rollback, and realizing environmental adaptive updating and failure isolation of key capabilities.

[0205] Optionally, the method can also generate corresponding operation logs when generating the birth token, encrypting and encapsulating the derived parameters to form a key capsule, and collaboratively generating the signature result; write the operation logs into a chain log record in chronological order; when an audit request is received, perform integrity verification based on the chain log record, and determine that the audit is complete when the verification passes.

[0206] In this embodiment of the invention, the operation log can be used to record operation information at each key stage of the private key lifecycle, including the birth verification stage, capsule generation stage, collaborative signature stage, key rotation and revocation stage, etc.

[0207] Each operation log entry may include fields such as event type, occurrence time, instance identifier, tenant identifier, key alias, purpose information, operation result, and hash digest, which are used to enable full-chain traceability of critical events.

[0208] Chained log records can be stored sequentially using hash chains or Merkle tree structures, where each log record contains the hash value or index path of the previous log record to ensure the correlation between records and the infeasibility of tampering.

[0209] For example, for the nth log entry Log_n, a chained hash can be calculated: Hash_n = SM3(Log_n||Hash_{n-1}), thus forming an untraceable log chain. Through this chained structure, even if some nodes are compromised or logs are exported, it is difficult to tamper with any historical record without compromising the hash consistency of the entire chain.

[0210] Upon receiving an audit request, the key management server can read the log chain in chronological order and perform integrity verification based on the index and hash value in the log.

[0211] If all log records match the hashes associated with them, the log chain is considered complete and the audit passes.

[0212] If any mismatch is detected, the log is deemed to be at risk of being tampered with or lost, and an audit alert is generated.

[0213] For example, when a tenant initiates a key audit request, the system will retrieve the corresponding log range to verify whether the records of birth token issuance, key capsule encapsulation, and collaborative signature all exist, and perform integrity calculation on the hash chain.

[0214] If the calculation results are consistent, the system will return an "Audit Passed" status.

[0215] If there is a discrepancy, a message "Log integrity error" will be displayed, and the index number of the abnormal node can be located further.

[0216] Through the above mechanism, the embodiments of the present invention can achieve traceability and non-repudiation of key operation behavior, providing technical support for secure and compliant management of the key lifecycle.

[0217] It can also support independent verification by third parties or regulatory agencies based on chained logs, thereby realizing a verifiable and falsifiable security audit system.

[0218] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0219] In one embodiment, a private key management device is provided, which corresponds one-to-one with the private key management methods described in the above embodiments. For example... Figure 2 As shown, the private key management device includes a first acquisition module 201, a first verification module 202, a first encapsulation module 203, a first return module 204, and a first signature module 205. Detailed descriptions of each functional module are as follows:

[0220] The first acquisition module 201 is used to acquire instance binding information sent by the virtualization platform;

[0221] The first verification module 202 is used to verify the instance binding information according to a preset key policy, and generate a birth token when the verification is successful.

[0222] The first encapsulation module 203 is used to split the logical private key based on the birth token, generate a first private key share and a derived parameter for deriving a second private key share, and encrypt and encapsulate the derived parameter with the instance binding information as additional authentication data to form a key capsule containing the instance binding information.

[0223] The first return module 204 is used to return the key capsule to the corresponding instance so that the instance can unseal the key capsule and derive the second private key share in its own runtime environment;

[0224] The first signature module 205 is used to generate a signature result based on the first private key share and the second private key share when receiving a signature request sent by the instance based on the second private key share.

[0225] Optionally, the instance binding information includes an image digest, instance identifier, startup time, tenant identifier, key alias, and usage information that characterize the instance's runtime environment. The first verification module 202 is further used for:

[0226] The consistency of the image digest, the instance identifier, and the startup time is verified to obtain the consistency verification result;

[0227] When the consistency verification result is successful, and the tenant identifier, key alias, and usage information meet the admission conditions of the key policy, the instance binding information is deemed to have passed verification.

[0228] Optionally, the first encapsulation module 203 is further configured to:

[0229] A first private key share is generated based on a preset derivation basis and the birth token, and derivation parameters for generating a second private key share are derived based on the instance binding information.

[0230] Based on an encryption algorithm with an additional authentication field, the derived parameters are encrypted and encapsulated using the instance binding information as additional authentication data to generate the key capsule.

[0231] Optionally, the first return module 204 is further configured to:

[0232] The instance performs a consistency comparison between the additional authentication data of the key capsule and the binding information of the current instance in its own operating environment;

[0233] If the comparison is successful, the instance unseales the key capsule to obtain the derived parameters and derives the second private key share based on the derived parameters, and stores it in the memory of the instance;

[0234] In the event of a mismatch, failure to unseal the key capsule, or revocation, the second private key share is cleared, and subsequent signature requests for the instance are blocked.

[0235] Optionally, the first signature module 205 is further configured to:

[0236] Obtain the signature purpose, request rate, and session state corresponding to the signature request;

[0237] When the signature purpose meets the preset purpose, the request rate does not exceed the preset threshold, and the session state is valid, a signature result is generated collaboratively based on the first private key share and the second private key share.

[0238] Optionally, the first signature module 205 is further configured to:

[0239] Obtain the second signature fragment corresponding to the second private key share, wherein the second signature fragment is generated by the instance based on the second private key share;

[0240] A first signature fragment is generated based on the first private key share;

[0241] The first signature fragment and the second signature fragment are combined to obtain the signature result.

[0242] Optionally, the device further includes:

[0243] The first detection module is used to regenerate new instance binding information when instance migration, instance restart or snapshot recovery events are detected;

[0244] The second encapsulation module is used to encrypt and encapsulate the derivation parameters used to derive the second private key share with the new instance binding information as additional authentication data, forming a key capsule containing the new instance binding information.

[0245] Optionally, the device further includes:

[0246] The first generation module is used to generate corresponding operation logs when generating the birth token, encrypting and encapsulating the derived parameters to form the key capsule, and collaboratively generating the signature result.

[0247] The first writing module is used to write the operation log into the chained log record in chronological order.

[0248] The second verification module is used to perform integrity verification based on the chained log records when an audit request is received, and to determine that the audit is completed when the verification is successful.

[0249] For specific limitations regarding the private key management device, please refer to the limitations on the private key management method above, which will not be repeated here. Each module in the aforementioned private key management device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independently of the processor in the computer device, or stored in software in the memory of the computer device, so that the processor can call and execute the corresponding operations of each module.

[0250] In one embodiment, a computer device is provided, which may be a terminal device, and its internal structure diagram may be as follows: Figure 3 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a readable storage medium storing computer-readable instructions. The network interface communicates with external terminals via a network connection. When executed by the processor, the computer-readable instructions implement a private key management method. The readable storage medium provided in this embodiment includes both non-volatile and volatile readable storage media.

[0251] In this application embodiment, a computer device is provided, including a memory, a processor, and computer-readable instructions stored in the memory and executable on the processor. When the processor executes the computer-readable instructions, it implements the steps of the private key management method described above.

[0252] In one embodiment of the application, a readable storage medium is provided, which stores computer-readable instructions. When the computer-readable instructions are executed by a processor, they implement the steps of the private key management method described above.

[0253] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware with computer-readable instructions. These computer-readable instructions can be stored in a non-volatile readable storage medium or a volatile readable storage medium. When executed, these computer-readable instructions can include the processes of the embodiments of the methods described above. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0254] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0255] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A private key management method, characterized in that, The method includes: Obtain instance binding information sent by the virtualization platform; The instance binding information is verified according to a preset key policy, and a birth token is generated when the verification passes. The logical private key is split based on the birth token to generate a first private key share and a derived parameter for deriving a second private key share. The derived parameter is then encrypted and encapsulated with the instance binding information as additional authentication data to form a key capsule containing the instance binding information. The key capsule is returned to the corresponding instance so that the instance can unseal the key capsule in its own runtime environment and derive the second private key share; Upon receiving a signature request sent by the instance based on the second private key share, a signature result is generated collaboratively based on the first private key share and the second private key share; The instance binding information includes an image digest representing the instance's runtime environment, instance identifier, startup time, tenant identifier, key alias, and usage information. The verification of the instance binding information according to a preset key policy includes: The consistency of the image digest, the instance identifier, and the startup time is verified to obtain the consistency verification result; When the consistency verification result is successful, and the tenant identifier, key alias, and usage information meet the admission conditions of the key policy, the instance binding information verification is deemed successful. The process involves splitting the logical private key based on the birth token to generate a first private key share and a derived parameter for deriving a second private key share. The derived parameter is then encrypted and encapsulated using the instance binding information as additional authentication data to form a key capsule containing the instance binding information. This includes: A first private key share is generated based on a preset derivation basis and the birth token, and derivation parameters for generating a second private key share are derived based on the instance binding information. Based on an encryption algorithm with an additional authentication field, the derived parameters are encrypted and encapsulated using the instance binding information as additional authentication data to generate the key capsule.

2. The private key management method as described in claim 1, characterized in that, The step of unsealing the key capsule and deriving the second private key share in its own operating environment includes: The instance performs a consistency comparison between the additional authentication data of the key capsule and the binding information of the current instance in its own operating environment; If the comparison is successful, the instance unseales the key capsule to obtain the derived parameters and derives the second private key share based on the derived parameters, and stores it in the memory of the instance; In the event of a mismatch, failure to unseal the key capsule, or revocation, the second private key share is cleared, and subsequent signature requests for the instance are blocked.

3. The private key management method as described in claim 1, characterized in that, When receiving a signature request sent by the instance based on the second private key share, the step of collaboratively generating a signature result based on the first private key share and the second private key share includes: Obtain the signature purpose, request rate, and session state corresponding to the signature request; When the signature purpose meets the preset purpose, the request rate does not exceed the preset threshold, and the session state is valid, a signature result is generated collaboratively based on the first private key share and the second private key share.

4. The private key management method as described in claim 3, characterized in that, The step of generating a signature result based on the first private key share and the second private key share includes: Obtain the second signature fragment corresponding to the second private key share, wherein the second signature fragment is generated by the instance based on the second private key share; A first signature fragment is generated based on the first private key share; The first signature fragment and the second signature fragment are combined to obtain the signature result.

5. The private key management method as described in claim 1, characterized in that, The method further includes: When an instance migration, instance restart, or snapshot restore event is detected, new instance binding information is regenerated; The new instance binding information is used as additional authentication data to encrypt and encapsulate the derivation parameters used to derive the second private key share, forming a key capsule containing the new instance binding information.

6. The private key management method as described in claim 1, characterized in that, The method further includes: When generating the birth token, encrypting and encapsulating the derived parameters to form the key capsule, and collaboratively generating the signature result, corresponding operation logs are generated respectively. The operation logs are written into a chained log record in chronological order; Upon receiving an audit request, an integrity check is performed based on the chained log records, and the audit is deemed complete when the check passes.

7. A private key management device, characterized in that, The device includes: The first acquisition module is used to acquire instance binding information sent by the virtualization platform; The first verification module is used to verify the instance binding information according to a preset key policy, and generate a birth token when the verification is successful. The first encapsulation module is used to split the logical private key based on the birth token, generate a first private key share and a derived parameter for deriving a second private key share, and encrypt and encapsulate the derived parameter with the instance binding information as additional authentication data to form a key capsule containing the instance binding information. The first return module is used to return the key capsule to the corresponding instance, so that the instance can unseal the key capsule and derive the second private key share in its own runtime environment; The first signature module is used to generate a signature result based on the first private key share and the second private key share when receiving a signature request sent by the instance based on the second private key share; The instance binding information includes an image digest characterizing the instance's runtime environment, instance identifier, startup time, tenant identifier, key alias, and usage information. The first verification module is further configured to: The consistency of the image digest, the instance identifier, and the startup time is verified to obtain the consistency verification result; When the consistency verification result is successful, and the tenant identifier, key alias, and usage information meet the admission conditions of the key policy, the instance binding information verification is deemed successful. The first encapsulation module is further configured to: A first private key share is generated based on a preset derivation basis and the birth token, and derivation parameters for generating a second private key share are derived based on the instance binding information. Based on an encryption algorithm with an additional authentication field, the derived parameters are encrypted and encapsulated using the instance binding information as additional authentication data to generate the key capsule.

8. A computer device comprising a memory, a processor, and computer-readable instructions stored in the memory and running on the processor, characterized in that, When the processor executes the computer-readable instructions, it implements the private key management method as described in any one of claims 1 to 6.

Images