Key retrieval, backup, migration methods and related equipment

Abstract

This invention provides a key retrieval, backup, and migration method and related equipment. The security processor includes: a virtual key device for configuring at least one physical key and binding it to a virtual machine; a command parsing module for determining the virtual key device bound to the virtual machine based on an acquired invocation command from the virtual machine; and a key retrieval module for invoking the physical key indicated by the invocation command from the determined virtual key device. It can be seen that the security processor in this invention can improve key retrieval efficiency.

Description

Technical Field

[0001] This invention relates to the field of data security technology, specifically to a key retrieval, backup, and migration method and related equipment. Background Technology

[0002] Virtualization technology allows a physical host to virtualize multiple virtual machines (VMs), thereby maximizing the utilization of the physical host's hardware resources. Each virtualized VM can have its data encrypted using cryptographic techniques, thus ensuring the data security of the VM.

[0003] A security processor is a trusted device that provides security management for physical hosts, offering services such as key management and secure memory management. However, existing security processors suffer from low efficiency in key retrieval processing. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a key retrieval, backup, and migration method and related equipment to quickly and efficiently determine the physical key called by the virtual machine, thereby improving the key retrieval efficiency.

[0005] To achieve the above objectives, the embodiments of the present invention provide the following technical solutions.

[0006] In a first aspect, embodiments of the present invention provide a security processor, comprising:

[0007] A virtual key device for configuring at least one physical key and for binding to a virtual machine;

[0008] The command parsing module is used to determine the virtual key device bound to the virtual machine based on the obtained virtual machine's invocation commands;

[0009] The key invocation module is used to invoke the physical key indicated by the invocation command from the determined virtual key device.

[0010] Optionally, the security processor further includes:

[0011] The virtual device configuration module is used to configure the physical key for the virtual key device;

[0012] The physical key is configured with an occupancy flag, which indicates whether the physical key is idle or occupied. When the physical key is configured to a virtual key device, the occupancy flag is configured as occupied. Specifically, when the occupancy flag of the physical key is idle, the virtual key device is allowed to configure the physical key, and when the occupancy flag of the physical key is occupied, the virtual key device is prohibited from configuring the physical key.

[0013] Optionally, the virtual key device indicates its configured physical key based on a virtual key identifier and a physical key identifier, wherein the virtual key identifier is mapped to the physical key identifier of the physical key;

[0014] The virtual device configuration module is used to configure physical keys for the virtual key device, including establishing a mapping relationship between the virtual key identifier in the virtual key device and the physical key identifier of the configured physical key;

[0015] The key invocation module is used to invoke the physical key indicated by the invocation command from the determined virtual key device. Specifically, based on the virtual key identifier in the invocation command, it determines the physical key identifier mapped by the virtual key identifier in the virtual key device, and invokes the corresponding physical key based on the physical key identifier.

[0016] Optionally, the invocation command includes the virtual key identifier; the virtual device configuration module is used to establish a mapping relationship between the virtual key identifier in the virtual key device and the physical key identifier of the configured physical key, specifically:

[0017] Before binding the virtual key device to the virtual machine, configure a physical key for the virtual key device;

[0018] or,

[0019] After binding the virtual key device to the virtual machine, a physical key is configured for the virtual key device based on the obtained key creation command.

[0020] Optionally, the virtual key device is configured with a virtual device identifier, and the virtual machine binds to the virtual key device based on the virtual device identifier;

[0021] The command parsing module is used to determine the virtual key device bound to the virtual machine based on the obtained virtual machine's call command. Specifically, it determines the virtual device identifier of the virtual key device based on the virtual machine that issued the call command.

[0022] Optionally, the command parsing module is further configured to: determine the virtual key device to be destroyed based on the acquired virtual device destruction command;

[0023] The security processor further includes a virtual device destruction module, used to release the physical key occupied by the virtual key device indicated by the virtual device destruction command based on the virtual device destruction command.

[0024] Optionally, the virtual key device indicates the physical key with a physical key identifier, and the virtual device destruction module is used to release the physical key occupied by the virtual key device, specifically by configuring the occupancy identifier of the physical key configured in the virtual key device to be free;

[0025] The virtual key device indicates the physical key by a mapping relationship between the virtual key identifier and the physical key identifier. The virtual device destruction module is used to release the physical key occupied by the virtual key device, including: removing the mapping relationship between the virtual key identifier and the physical key identifier in the virtual key device; and configuring the occupied identifier of the physical key corresponding to the physical key identifier as idle.

[0026] Optionally, the command parsing module is further configured to: determine the attribute parameters of the virtual key device to be created based on the acquired virtual device creation request, wherein the attribute parameters include the sharing type and the number of keys;

[0027] The security processor further includes a virtual device creation module for creating a virtual key device corresponding to the attribute parameters.

[0028] Optionally, the virtual device creation module is used to create a virtual key device corresponding to the attribute parameters, including:

[0029] Based on the number of virtual key devices that the security processor can support creating and the number of existing virtual key devices, determine whether to allow the creation of virtual key devices;

[0030] If so, generate a virtual device identifier corresponding to the virtual key device, and configure the maximum available key space for the virtual key device;

[0031] Based on the virtual device identifier, configure the sharing type of the virtual key device. The sharing type includes exclusive or shared. The exclusive sharing type indicates that the virtual key device is exclusively owned by a virtual machine, and the shared sharing type indicates that the virtual key device is allowed to be shared by multiple virtual machines.

[0032] Optionally, the command parsing module is further configured to: determine the virtual key device to be bound based on the acquired virtual device binding request;

[0033] The security processor further includes a virtual device binding module, which, when the virtual key device supports binding, records the correspondence between the virtual key device and the virtual machine based on the virtual device identifier, and configures the binding status of the virtual key device to be bound.

[0034] Secondly, embodiments of the present invention also provide a key retrieval method applied to a security processor, wherein the security processor is configured with a virtual key device, the virtual key device being used to configure at least one physical key and to bind to a virtual machine, including:

[0035] Obtain the virtual machine's invocation commands;

[0036] Based on the obtained virtual machine's invocation commands, determine the virtual key device bound to the virtual machine;

[0037] The virtual key device is used to invoke the physical key indicated by the invocation command.

[0038] Optionally, before obtaining the virtual machine's invocation command, the method further includes:

[0039] Before binding the virtual key device to the virtual machine, configure a physical key for the virtual key device;

[0040] or,

[0041] After binding the virtual key device to the virtual machine, configure the physical key for the virtual key device.

[0042] Optionally, the physical key is configured with an occupancy identifier, and configuring the physical key for the virtual key device includes:

[0043] Determine which physical keys are marked as idle in the security processor;

[0044] Configure the physical key marked as idle to the virtual key device;

[0045] Configure the occupancy flag of the physical key configured to the virtual key device as occupied.

[0046] Optionally, configuring a physical key for the virtual key device further includes: establishing a mapping relationship between the virtual key identifier in the virtual key device and the physical key identifier of the configured physical key;

[0047] The process of calling the physical key indicated by the calling command from the determined virtual key device specifically involves determining the physical key identifier mapped to the virtual key identifier in the virtual key device based on the virtual key identifier in the calling command, and calling the corresponding physical key based on the physical key identifier.

[0048] Optionally, before obtaining the virtual machine's invocation command, the method further includes:

[0049] Create a virtual key device;

[0050] Configure the maximum available key space for the virtual key device, and bind the virtual key device to the virtual machine.

[0051] Optionally, the virtual key creation device includes:

[0052] The attribute parameters of the virtual key device to be created are determined based on the obtained virtual device creation request. The attribute parameters include the sharing type and the number of keys.

[0053] Create a virtual key device corresponding to the attribute parameters.

[0054] Optionally, creating a virtual key device corresponding to the attribute parameters includes:

[0055] Based on the number of virtual key devices that the security processor can support creating and the number of existing virtual key devices, determine whether to allow the creation of virtual key devices;

[0056] If so, generate a virtual device identifier corresponding to the virtual key device, and configure the maximum available key space for the virtual key device;

[0057] Based on the virtual device identifier, configure the sharing type of the virtual key device. The sharing type includes exclusive or shared. The exclusive sharing type indicates that the virtual key device is exclusively owned by a virtual machine, and the shared sharing type indicates that the virtual key device is allowed to be shared by multiple virtual machines.

[0058] Optionally, binding the virtual key device to the virtual machine includes:

[0059] The virtual key device to be bound is determined based on the obtained virtual device binding request;

[0060] When the virtual key device supports binding, the correspondence between the virtual key device and the virtual machine is recorded based on the virtual device identifier, and the binding status of the virtual key device is configured as bound.

[0061] Optionally, the key invocation method further includes:

[0062] The virtual key device to be destroyed is determined based on the obtained virtual device destruction command;

[0063] Release the physical key occupied by the virtual key device indicated by the virtual device destruction command.

[0064] Optionally, the virtual key device indicates the physical key with a physical key identifier, and releasing the physical key occupied by the virtual key device specifically involves: setting the occupancy identifier of the physical key configured in the virtual key device to free;

[0065] The virtual key device indicates the physical key by mapping the virtual key identifier to the physical key identifier. Releasing the physical key occupied by the virtual key device includes: removing the mapping relationship between the virtual key identifier and the physical key identifier in the virtual key device; and configuring the occupied identifier of the physical key corresponding to the physical key identifier as idle.

[0066] Thirdly, embodiments of the present invention also provide a key backup method applied to a security processor, wherein the security processor is configured with a virtual key device, the virtual key device being used to configure at least one physical key and to bind to a virtual machine, including:

[0067] Based on the obtained key backup request, determine the virtual key device bound to the virtual machine, wherein the key backup request is used to indicate the key to be backed up;

[0068] Encrypt the key to be backed up in the virtual key device indicated by the key backup request to generate key ciphertext;

[0069] Store the encrypted key to the file system.

[0070] Fourthly, embodiments of the present invention also provide a key migration method, wherein when a source device migrates a virtual key device to a target device, the method is applied to a security processor of the source device, the security processor being configured with a virtual key device, the virtual key device being used to configure at least one physical key and to bind to a virtual machine, including:

[0071] Based on the obtained migration key request, determine whether the virtual key device to be migrated supports migration, wherein the key migration request includes the device public key;

[0072] Generate a temporary key, and encrypt the physical key configured in the virtual key device based on the temporary key to generate key ciphertext;

[0073] Based on the device's public key, the temporary key is encrypted to generate a temporary key ciphertext, so that the source device's host can send the data to be migrated to the target device based on the data migration message sent by the target device.

[0074] Fifthly, embodiments of the present invention also provide a key migration method, wherein when a source device migrates a virtual key device to a target device, the method is applied to a security processor of the target device, the security processor being configured with a virtual key device, the virtual key device being used to configure at least one physical key and to bind to a virtual machine, including:

[0075] Send a device certificate so that the source device generates a migration key request based on the device certificate, the device certificate including the device public key;

[0076] Based on the received migration request, determine whether to receive the data to be migrated, wherein the data to be migrated is generated based on the migration permission message of the source device;

[0077] The key ciphertext in the data to be migrated sent by the source device is decrypted and loaded into a virtual key device that meets the migration conditions.

[0078] In a sixth aspect, embodiments of the present invention also provide a computing device, including a physical host and the security processor described in the first aspect.

[0079] In a seventh aspect, embodiments of the present invention also provide a computer program comprising one or more computer-executable instructions, wherein when the one or more computer-executable instructions are executed, they implement the key invocation method as described in the second aspect, or implement the key backup method as described in the third aspect, or implement the key migration method as described in any one of the fourth or fifth aspects.

[0080] This invention provides a key retrieval, backup, and migration method and related equipment, wherein the security processor includes: a virtual key device for configuring at least one physical key and for binding with a virtual machine; a command parsing module for determining the virtual key device bound to the virtual machine based on the obtained retrieval command of the virtual machine; and a key retrieval module for retrieving the physical key indicated by the retrieval command from the determined virtual key device.

[0081] As can be seen, the security processor in this embodiment of the invention configures a virtual key device within it, so that the virtual machine is bound to the virtual key device. Based on the obtained virtual machine's invocation command, the processor can determine the virtual key device bound to the virtual machine, and then invoke the physical key indicated by the invocation command from the determined virtual key device. In other words, based on the binding relationship between the virtual machine and the virtual key device, the security processor can invoke the physical key while distinguishing the key resources corresponding to different virtual machines. This enables the processor to quickly and efficiently determine the physical key invoked by the virtual machine, thereby improving the key invocation efficiency. Attached Figure Description

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

[0083] Figure 1 This is a diagram of optional architectures for cloud services based on virtualization technology.

[0084] Figure 2 This is a schematic diagram of an optional architecture for a computing device using virtualization technology.

[0085] Figure 3 This is a schematic diagram of an optional structure of a computing device based on virtualization technology, provided as an embodiment of the present invention.

[0086] Figure 4 This is a key identifier configuration diagram for a virtual key device provided in an embodiment of the present invention.

[0087] Figure 5 This is a schematic diagram of an optional flow of a key retrieval method provided in an embodiment of the present invention.

[0088] Figure 6 This is a schematic diagram illustrating an optional process for configuring a virtual key device, as provided in an embodiment of the present invention.

[0089] Figure 7 This is an optional flowchart for creating a virtual key device, provided as an embodiment of the present invention.

[0090] Figure 8 An optional flowchart of step S230 provided in an embodiment of the present invention.

[0091] Figure 9 An optional flowchart of step S300 provided in an embodiment of the present invention.

[0092] Figure 10 This is an optional binding flowchart for a virtual key device provided in an embodiment of the present invention.

[0093] Figure 11 This is an optional destruction flowchart for a virtual key device provided in an embodiment of the present invention.

[0094] Figure 12 This is an optional backup flowchart for a virtual key device provided in an embodiment of the present invention.

[0095] Figure 13 This is an optional migration flowchart for a virtual key device provided in an embodiment of the present invention. Detailed Implementation

[0096] 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 embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0097] Virtualization technology can be applied to various scenarios. In particular, with the development of cloud services, virtualization technology has been increasingly widely used in cloud service scenarios. To facilitate understanding of virtualization technology, the following section will use cloud services based on virtualization technology as an example to introduce virtualization technology.

[0098] Reference Figure 1 The cloud service architecture shown is based on virtualization technology and may include: cloud host 100, network 200, and users 301 to 30n.

[0099] In this context, cloud host 100 refers to a host device (which can take the form of a server) deployed on the network side by a cloud service provider (such as a cloud service vendor) to provide cloud services. Based on the needs of different users, the cloud host can create one or more virtual machines for different users through virtualization technology. For example, a user can request the cloud host to create multiple virtual machines tailored to their business needs. The user can then run applications on these multiple virtual machines to collaboratively complete their specific business tasks. Essentially, a virtual machine is a client machine that provides services to the user.

[0100] Network 200 can be considered as the Internet or other forms of networks with communication functions. The cloud host and the user communicate and transmit data through the network. This embodiment of the invention does not limit the specific network form of network 200.

[0101] Users 301 to 30n are registered users of cloud services, and there can be multiple users. This embodiment of the invention does not limit the specific value of n. In a cloud service scenario, each user can have one or more virtual machines belonging to them on a cloud host to complete specific user-specific business tasks.

[0102] To ensure the security of virtual machine data, embodiments of the present invention can encrypt the virtual machine data stored in memory using cryptographic techniques. As an optional example, Figure 2 A schematic diagram of an optional architecture for a computing device using virtualization technology is shown, such as... Figure 2 As shown, the architecture may include: a CPU (Central Processing Unit) core 10 and a cryptographic coprocessor 20, memory 30 and a security processor (SP) 40 located on the physical host.

[0103] The CPU core 10 can virtualize multiple virtual machines 12 based on the host operating system (hereinafter referred to as the host) 11 running on it, through virtualization technology. These multiple virtual machines 12 can be managed and resources allocated based on the host 11.

[0104] The security processor 40 is a dedicated processor responsible for handling security-related operations of the computing device, providing services such as key management and memory management for the host / virtual machine. The security processor possesses its own dedicated hardware resources, thus enabling the construction of a trusted execution environment unaffected by CPU core interference. Furthermore, software running on the security processor can be verified by relevant security mechanisms (such as digital signatures), ensuring software trustworthiness. Additionally, the security processor communicates with the processor core through a specific internal hardware interface (hereinafter referred to as the default interface), enabling secure information exchange with the processor core via a call-based approach, guaranteeing secure communication between the security processor and the processor core.

[0105] The security processor also incorporates physical key resources (also known as cryptographic resources), such as the chip endorsement key (CEK). The CEK private key is embedded within the chip housing the security processor and is stored as confidential information, preventing external hardware devices from accessing it. For each CEK private key, a public CEK certificate verifies its authenticity.

[0106] The computing device further includes dedicated secure memory and secure flash memory for the security processor, providing it with secure storage space. The secure memory stores the code or data running on the security processor, while the secure flash memory stores keys used in the security process. The secure memory and secure flash memory configured on the security processor can be equipped with automatic encryption and consistency protection functions at the hardware level, and are not accessible to the CPU core, thereby ensuring the data security of the security processor.

[0107] During the data flow process of computing devices, the security processor can manage physical keys so that different virtual machines can correspond to different physical keys, ensuring data isolation between virtual machines.

[0108] The cryptographic coprocessor 20 is used to encrypt and decrypt virtual machine data. The cryptographic coprocessor 20 is configured with cryptographic algorithm logic to encrypt and decrypt the corresponding virtual machine data based on the physical key configured in the security processor. The virtual machine data, after being encrypted by the cryptographic coprocessor, can be stored in system memory to ensure data security; when virtual machine data is read from system memory, it is decrypted by the cryptographic coprocessor to obtain the original virtual machine data.

[0109] Regarding key management for the security processor, in one example, the security processor can be configured with a cryptographic module to configure a corresponding physical key for the virtual machine based on the virtual machine's request, and when the virtual machine needs to perform encryption and decryption calculations, it can instruct the cryptographic coprocessor to perform encryption and decryption of the virtual machine's data based on the physical key, according to the correspondence.

[0110] However, in this approach, the security processor manages and configures physical keys uniformly and indiscriminately. In scenarios where there are multiple virtual machines and each virtual machine corresponds to multiple physical keys, the corresponding key configuration information becomes messy and complicated, resulting in low efficiency in key retrieval.

[0111] In view of this, embodiments of the present invention provide a security processor, comprising: a virtual key device for configuring at least one physical key and for binding to a virtual machine; a command parsing module for determining the virtual key device bound to the virtual machine based on an acquired invocation command of the virtual machine; and a key invocation module for invoking the physical key indicated by the invocation command from the determined virtual key device.

[0112] As can be seen, the security processor in this embodiment of the invention configures a virtual key device within it, so that the virtual machine is bound to the virtual key device. Based on the obtained virtual machine's invocation command, the processor can determine the virtual key device bound to the virtual machine, and then invoke the physical key indicated by the invocation command from the determined virtual key device. In other words, based on the binding relationship between the virtual machine and the virtual key device, the security processor can invoke the physical key while distinguishing the key resources corresponding to different virtual machines. This enables the processor to quickly and efficiently determine the physical key invoked by the virtual machine, thereby improving the key invocation efficiency.

[0113] Meanwhile, it is understandable that in existing key management methods, physical keys are associated with virtual machines, resulting in messy and complicated key configuration information. This makes it difficult to migrate and back up the configured physical keys simultaneously when the virtual machine needs to be migrated or backed up. However, the embodiments of this invention are essentially based on virtual key devices to manage the physical keys of virtual machines, thereby making the overall processing of the physical keys corresponding to the virtual machines a reality. As a result, when the virtual machine needs to be migrated or backed up, the migration and backup of the corresponding physical keys are also easy to achieve.

[0114] As an optional implementation of the disclosed content of the embodiments of the present invention, one embodiment of the present invention further provides a computing system based on virtualization technology, see reference. Figure 3The diagram shows an optional structure of a computing device based on virtualization technology. In this computing device, the physical host can be understood as a hardware combination that configures / runs the host operating system and virtual machines, also known as the host machine. The physical host interacts with the security processor to realize the use and management of physical keys.

[0115] Among them, reference Figure 3 The physical host runs a host application and multiple virtual machine applications. Both the host operating system and the virtual machines are configured with device drivers. The host application or the virtual machine applications can call the virtual key device based on the device drivers.

[0116] The physical host side is also equipped with a command relay module, which is used to forward commands or requests issued by the device driver to the security processor, so that the security processor can execute the corresponding commands or requests.

[0117] The security processor includes a virtual key device ( Figure 3 Taking multiple virtual key devices as an example, namely virtual key device 1, virtual key device 2, ..., virtual key device N), the virtual key devices are used to configure at least one physical key and are used to bind to a virtual machine; the command parsing module is used to determine the virtual key device bound to the virtual machine based on the obtained virtual machine call command; the key call module is used to call the physical key indicated by the call command from the determined virtual key device.

[0118] The command parsing module can acquire commands or requests from the virtual machine and parse them. It can be understood that upon acquiring a command to invoke the virtual machine's key, the virtual key device bound to the virtual machine can be determined based on the acquired command. This allows the key invocation module to invoke the physical key indicated by the command from the determined virtual key device.

[0119] The virtual key device is a virtual device created by the security processor for binding to a virtual machine and providing key resources for the virtual machine. The virtual key device is used to configure at least one physical key, which can be understood as the key resource of the virtual key device. In optional examples, the virtual key device can be a virtual cryptographic card or a physical cryptographic card.

[0120] The virtual key device can be configured as a key resource exclusively used by a virtual machine, or it can be configured as a key resource that can be shared by multiple virtual machines. When the virtual key device is used exclusively by a virtual machine, it can only be bound to one virtual machine, meaning only that virtual machine can use the bound key resource. When the virtual key device is used as a key resource shared by virtual machines, it can be bound to multiple virtual machines, allowing virtual machines bound to the same virtual key device to share its key resource.

[0121] In one optional example, the virtual key device can be used as an exclusive key resource or as a shared key resource. Specifically, the virtual key device can be configured with a corresponding sharing type based on preset information. The sharing type includes exclusive or shared, wherein the exclusive sharing type indicates that the virtual key device is exclusively used by a virtual machine, and the shared sharing type indicates that the virtual key device is allowed to be shared by multiple virtual machines.

[0122] It is understood that when the virtual key device is exclusively used by a virtual machine, the virtual key device can only be bound by one virtual machine, so that only the bound virtual machine uses the virtual key device; when the virtual key device is shared by multiple virtual machines, the virtual key device allows multiple virtual machines to bind to it, so that the bound multiple virtual machines use the virtual key device.

[0123] In an optional example, the virtual key device is configured with a one-to-one corresponding virtual device identifier (vid), see reference. Figure 3 The virtual device identifiers vid1, vid2, ..., vidn are shown, which allow the virtual machine to bind to the virtual key device based on the virtual device identifier. In a specific example, virtual key device 0 typically indicates the virtual key device corresponding to the host, and the corresponding virtual device identifier can be vid0. The characteristics of the virtual key device corresponding to the host can be the same as or different from those of the virtual key device corresponding to the virtual machine. In one example, the virtual key device corresponding to the host can be a physical cryptographic card, and the virtual key device corresponding to the virtual machine can be a virtual cryptographic card.

[0124] Accordingly, given a clear understanding of the binding relationship between the virtual machine and the virtual key, when the command parsing module determines the virtual key device bound to the virtual machine based on the acquired virtual machine's invocation command, it can determine the virtual device identifier of the virtual key device based on the virtual machine that issued the invocation command. It is understood that the virtual machine's invocation command for calling the key includes the identity information of the virtual machine that issued the command, thus allowing the determination of the invoker. This identity information can be, for example, a virtual machine identifier. Therefore, the virtual device identifier of the virtual key device bound to the virtual machine can be determined based on the virtual machine identifier in the invocation command.

[0125] In a further example, the virtual key device may also be configured with a virtual device configuration module for configuring physical keys for the virtual key device. Correspondingly, to indicate whether a physical key has been assigned, refer to... Figure 4 The diagram illustrates a key identifier configuration for a virtual key device. In this embodiment, the physical key is configured with an occupancy identifier, which indicates whether the physical key is idle or occupied. When the physical key is configured to the virtual key device, the occupancy identifier is configured as occupied. It is understood that when the occupancy identifier of the physical key is idle, the virtual key device is allowed to configure the physical key, and when the occupancy identifier of the physical key is occupied, the virtual key device is prohibited from configuring the physical key.

[0126] It is understandable that a physical key in an occupied state will not be reassigned. In other words, a physical key in an occupied state is not allowed to be occupied by other virtual key devices, thereby ensuring that the key is not accessed and called by multiple virtual key devices and ensuring the data security of virtual key devices and physical keys.

[0127] In an optional implementation, the virtual key device can indicate its configured physical key based on a key identifier. The key identifier is used to identify the physical key of the virtual key device. The key identifier can be directly a physical key identifier, or it can include both a virtual key identifier and a physical key identifier, with the physical key of the virtual key device identified based on the mapping relationship between the virtual key identifier and the physical key identifier. The physical key identifier can be understood as identification information configured within the security processor that corresponds one-to-one with the physical key, such as a key index or key handle configured for the security processor. The virtual key identifier can be understood as identification information provided by the virtual key device for virtual machine invocation, such as a key index configured for the virtual key device. Therefore, in the specific invocation command of the virtual machine, the virtual key identifier indicates the physical key being invoked.

[0128] It is understandable that using the mapping relationship between virtual key identifiers and physical key identifiers to indicate physical keys can improve key confidentiality to a certain extent. At the same time, based on the correspondence between virtual key devices and virtual machines, the number of physical keys configured on the virtual key device is greatly reduced, and the corresponding virtual key identifier can be simplified, such as using fewer bits of data to represent the virtual key identifier, thereby reducing the complexity of the calling process.

[0129] In specific examples, refer to Figure 4 The diagram illustrates a key identifier configuration for a virtual key device. The key identifier includes a virtual key identifier and a physical key identifier, enabling the virtual key device to indicate its configured physical key based on these identifiers. Correspondingly, the virtual device configuration module configures the physical key for the virtual key device and further establishes a mapping relationship between the virtual key identifier in the virtual key device and the physical key identifier of the configured physical key. Correspondingly, the key invocation module determines the physical key identifier mapped to the virtual key identifier in the virtual key device based on the virtual key identifier in the invocation command, and further invokes the corresponding physical key based on the physical key identifier.

[0130] In a specific example, before binding the virtual key device to the virtual machine, a step of configuring a physical key for the virtual key device can be performed. Correspondingly, when configuring the physical key for the virtual key device, a corresponding mapping relationship is established. Specifically, the virtual device configuration module is used to configure a physical key for the virtual key device, and before binding the virtual key device to the virtual machine, establish a mapping relationship between the virtual key identifier and the physical key identifier of the configured physical key.

[0131] Understandably, once a mapping relationship is established between the physical key identifier and the corresponding virtual key identifier, and the corresponding physical key is configured to be in use, the physical key no longer belongs to an allocable resource. However, in most scenarios, the virtual machine only uses a small amount of key resources for data encryption, while other keys remain idle, resulting in low utilization efficiency of key resources.

[0132] In view of this, in a further example, the present invention reduces the probability of physical keys being idle and improves the utilization efficiency of key resources by changing the timing of establishing the mapping relationship between physical key identifiers and virtual key identifiers.

[0133] Specifically, the virtual device configuration module can configure a virtual key identifier for the virtual key device when it is created, and then configure a physical key for the virtual key device after binding the virtual key device to the virtual machine, for example, after obtaining the key creation command of the virtual machine, so as to establish the relevant mapping relationship.

[0134] In a specific example, with N physical keys, if P physical keys are pre-allocated to each virtual key device, then at most N / P virtual key devices can be allocated. In normal usage scenarios, the actual number of keys used by a virtual key device may be small, and reserving all the remaining keys would be wasteful, and the number of supported virtual key devices would be even smaller. The method described in this embodiment can be understood as an over-allocation approach, that is, after binding the virtual key device to the virtual machine, the step of configuring physical keys for the virtual key device is performed. Accordingly, in the specific configuration process, with... Figure 4 Taking the key identifier configuration of a virtual key device as an example, the virtual key device can be configured with a corresponding number of virtual key identifiers based on the maximum available key space (i.e., the maximum number of keys supported by the virtual key device) P' indicated in the virtual device creation request. Accordingly, the key range that the created virtual key device can use is 1 to P', where 1 to P' can be understood as the range of virtual key identifiers.

[0135] When the security processor receives a key creation command from a virtual machine bound to a corresponding virtual key device, it allocates a virtual key identifier. Specifically, it can select a virtual key identifier from its own virtual key identifier range. Then, it configures a physical key for the virtual key identifier. For example, it can call the physical key allocation interface to allocate a physical key for the virtual key identifier. At this time, it can also set the occupancy flag of the physical key to occupancy to indicate that the physical key has been occupied. After that, the virtual key identifier is mapped to the physical key identifier of the configured physical key.

[0136] Understandably, in the above example, the virtual key device only occupies the number of physical keys actually used. For example, if each virtual key device actually uses P / 10 physical keys on average, then all physical keys N can be allocated to N / (P / 10) virtual key devices, which is 10 times more efficient than the original N / P. If the actual average number of physical keys used is less, then the number of virtual key devices that can be supported will be more. Alternatively, even if some virtual key devices use a large number of keys, if other virtual key devices use a small number of keys, and the sum of the numbers used does not exceed the maximum number of physical resources, it can still be achieved, thus maximizing the use of physical key resources.

[0137] In a specific example, the creation of the virtual key device can be triggered by a virtual device creation request on the physical host side. This request can include attribute parameters of the virtual key device to be created, such as sharing type and number of keys. Specifically, after the command parsing module obtains the virtual device creation request, it can determine the attribute parameters of the virtual key device to be created based on the obtained request. These attribute parameters include sharing type and maximum available key space; where the sharing type indicates whether the virtual key device to be created is exclusive or shared, and the maximum available key space indicates the maximum number of keys supported by the virtual key device to be created.

[0138] The security processor further includes a virtual device creation module, used to create a virtual key device corresponding to the attribute parameters. Specifically, based on the sharing type in the attribute parameters, the created virtual key device can be configured as exclusive or shared, and based on the number of keys, a corresponding key identifier can be configured for the created virtual key device.

[0139] In the process of creating a virtual key device corresponding to the aforementioned attribute parameters, it is necessary to consider the number of virtual key devices that the security processor can support creating and the number of existing virtual key devices to determine whether the creation of a virtual key device is permitted. Specifically, the number of virtual key devices that the security processor can support creating (i.e., the maximum number of virtual key devices that the security processor can support creating) and the number of existing virtual key devices can be determined. It is then determined whether the number of virtual key devices that the security processor can support creating is greater than the number of existing virtual key devices. If so, the creation of the virtual key device is permitted, a virtual device identifier corresponding to the virtual key device is generated, and a maximum available key space is configured for the virtual key device. The maximum available key space indicates the maximum number of keys that the virtual key device can be configured with.

[0140] It is understood that, based on the maximum available key space, a corresponding number of virtual key identifiers or physical key identifiers can be configured for the virtual key device.

[0141] When configuring a physical key identifier, the corresponding physical key identifier is the physical key identifier corresponding to an idle physical key; when configuring a virtual key identifier, it can be the virtual key identifier configured by the security processor for the virtual key device, which is used to map to the physical key identifier.

[0142] After creating a virtual key device, virtual machines and virtual key devices can be bound based on the virtual device identifier. Accordingly, in the specific binding process, the physical host can issue a virtual device binding request, for example, when the virtual machine starts. In the security processor, the command parsing module can further determine the virtual key device (VID) to be bound based on the obtained virtual device binding request.

[0143] The security processor may further include a virtual device binding module, which, when the virtual key device supports binding, records the correspondence between the virtual key device and the virtual machine based on the virtual device identifier, and configures the binding status of the virtual key device to be bound.

[0144] The virtual key device supports binding. In an optional example, the virtual key device is exclusive and not bound, or it is shared by a virtual machine that is not bound or is already bound, allowing virtual machines that issue virtual device binding requests to share it. In a further example, the virtual key device is further configured with a valid identifier to identify whether the virtual key device is valid. Accordingly, the virtual key device supports binding, and further includes the valid identifier of the virtual key device indicating that the virtual key device is valid.

[0145] It is understandable that the virtual key device can be destroyed after its use (e.g., in the scenario of destroying a virtual machine, or when the virtual machine no longer uses the virtual key device). Accordingly, the destruction of the virtual key device can be triggered by a virtual device destruction command on the physical host side. For example, the virtual machine management machine or a host with virtual machine management capabilities in the physical host can issue a virtual device destruction command based on an administrator's instruction or an instruction triggered under a preset scenario. The virtual device destruction command can include the virtual device identifier of the virtual key device to be destroyed. Specifically, after the command parsing module obtains the virtual device destruction command, it can determine the virtual key device to be destroyed based on the obtained virtual device destruction command.

[0146] Accordingly, the security processor may further include a virtual device destruction module, used to release the physical key occupied by the virtual key device indicated by the virtual device destruction command, based on the virtual device destruction command. It is understood that, based on the virtual device destruction command, data related to the virtual key device can also be further cleared, which will not be elaborated upon here.

[0147] As another optional implementation of the disclosed content of this invention, one embodiment further provides a key retrieval method. This method is applied to a security processor, which is configured with a virtual key device. The virtual key device is used to configure at least one physical key and is bound to a virtual machine. The description of the virtual key device, its configured physical key, and its binding relationship with the virtual machine can be found in the foregoing content. Figure 5 The diagram illustrates an optional flow of a key invocation method, which includes:

[0148] Step S100: The host forwards the virtual machine's call command to the security processor.

[0149] The invocation command can be issued by a virtual machine (specifically, a device driver for the virtual machine) to invoke a preset physical key, so as to encrypt and decrypt virtual machine data based on the corresponding physical key.

[0150] The invocation command includes a key identifier to indicate the specific physical key being invoked. This key identifier can be a physical key identifier or a virtual key identifier, depending on the type of key identifier configured in the virtual key device. When the virtual key device directly indicates its configured physical key using a physical key identifier, the key identifier in the corresponding invocation command is the physical key identifier. When the virtual key device indicates its configured physical key using a mapping relationship between virtual and physical key identifiers, the key identifier in the corresponding invocation command is the virtual key identifier.

[0151] It is understood that the invocation command also includes the identity information of the virtual machine that issued the invocation command, such as the virtual machine identifier, so that the issuer of the invocation command can be determined.

[0152] Step S110: The security processor determines the virtual key device bound to the virtual machine based on the obtained virtual machine invocation command.

[0153] By determining the virtual key device bound to the virtual machine, the key invocation module invokes the physical key indicated by the invocation command from the determined virtual key device.

[0154] It is understood that, in conjunction with the foregoing, the invocation command includes the identity information of the virtual machine that issued the invocation command. Therefore, the virtual key device bound to the virtual machine can be determined based on the binding relationship between the virtual machine and the virtual key device, as well as the identity information of the virtual machine that issued the invocation command.

[0155] Step S120: The security processor invokes the physical key indicated by the invocation command from the determined virtual key device.

[0156] After identifying the specific virtual key device, the security processor can invoke the corresponding physical key based on the key identifier in the invocation command.

[0157] Specifically, when the virtual key device directly indicates its configured physical key using a physical key identifier, the invocation command includes the physical key identifier, allowing the corresponding physical key to be directly invoked based on the physical key identifier. When the virtual key device identifies its physical key using a mapping relationship between virtual key identifiers and physical key identifiers, the invocation command includes the virtual key identifier. Accordingly, the security processor can determine the physical key identifier mapped to the virtual key identifier in the virtual key device based on the virtual key identifier in the invocation command, and invoke the corresponding physical key based on the physical key identifier.

[0158] It is understandable that a virtual key device can be created and configured before executing the physical key call, and correspondingly, refer to [reference needed]. Figure 6 The diagram illustrates an optional process for configuring a virtual key device. Before step S100, the computing device may further perform the following steps:

[0159] Step S200: Create a virtual key device;

[0160] Step S300: Configure a physical key for the virtual key device;

[0161] Step S400: Bind the virtual key device to the virtual machine.

[0162] It should be noted that the execution order of steps S300 and S400 is not restricted by their sequence numbers. In some optional examples, steps S300 and S400 can be executed sequentially or simultaneously. When steps S300 and S400 are executed sequentially, either step can be executed first.

[0163] Below, we will first explain in detail the process of creating a virtual key device, referring to step S200. (Reference) Figure 7 The diagram illustrates an optional creation flowchart for a virtual key device. The creation process for a virtual key device includes:

[0164] Step S210: The host sends a virtual device creation request;

[0165] The virtual device creation request is used to request the creation of a virtual key device that meets preset requirements. The virtual device creation request may include attribute parameters of the virtual key device to be created, such as sharing type and number of keys.

[0166] The descriptions of the sharing type and the number of keys can be found above, and will not be repeated here.

[0167] Step S220: The security processor determines the attribute parameters of the virtual key device to be created based on the acquired virtual device creation request. The attribute parameters include the sharing type and the number of keys.

[0168] After receiving the virtual device creation request, the security processor can parse and determine the attribute parameters of the virtual key device to be created, and then proceed with subsequent processes based on the attribute parameters.

[0169] Step S230: The security processor creates a virtual key device corresponding to the attribute parameters.

[0170] The creation of the virtual key device may include configuring a virtual device identifier and configuring corresponding resources for the virtual key device. That is, based on the virtual device creation request, a virtual device identifier (vid) is generated and configured accordingly based on specific attribute parameters.

[0171] For details, please refer to Figure 8 The optional flowchart of step S230 shown, which creates a virtual key device corresponding to the attribute parameters, may include:

[0172] Step S231: Based on the number of virtual key devices that the security processor supports creating and the number of existing virtual key devices, determine whether to allow the creation of virtual key devices;

[0173] Specifically, the number of virtual key devices that the security processor can support creating (i.e., the maximum number of virtual key devices that the security processor can support creating) and the number of existing virtual key devices can be determined. Furthermore, it can be determined whether the number of virtual key devices that the security processor can support creating is greater than the number of existing virtual key devices. If so, it indicates that the creation of virtual key devices is allowed, and step S232 can be executed. If not, the creation process is exited.

[0174] Step S232: Generate a virtual device identifier corresponding to the virtual key device, and configure the maximum available key space for the virtual key device;

[0175] The maximum available key space indicates the maximum number of keys that the virtual key device can be configured with. It is understood that, based on the maximum available key space, a corresponding number of virtual key identifiers or physical key identifiers can be configured for the virtual key device.

[0176] When configuring a physical key identifier, the corresponding physical key identifier is the physical key identifier corresponding to an idle physical key; when configuring a virtual key identifier, it can be the virtual key identifier configured by the security processor for the virtual key device, which is used to map to the physical key identifier.

[0177] In a specific example, based on the maximum available key space (i.e., the maximum number of keys supported by the virtual key device) P' indicated in the virtual device creation request, a corresponding number of virtual key identifiers are configured for the virtual key device. Accordingly, the key range that the created virtual key device can use is 1 to P', where 1 to P' can be understood as the range of virtual key identifiers.

[0178] Step S233: Configure the sharing type of the virtual key device based on the virtual device identifier;

[0179] The sharing type includes exclusive or shared. The exclusive sharing type indicates that the virtual key device is exclusively owned by a virtual machine, and the shared sharing type indicates that the virtual key device can be shared by multiple virtual machines.

[0180] Below, we will first describe in detail the optional process for configuring the physical key for the virtual key device, specifically step S300, which is executed by the security processor. (Reference) Figure 9 The optional flowchart shown for step S300 indicates that the configuration process for the virtual key device includes:

[0181] Step S310: Determine which physical key in the security processor is marked as idle;

[0182] In this embodiment of the invention, the physical key is configured with an occupancy identifier, which is used to indicate whether the physical key is idle or occupied. When the physical key is configured to a virtual key device, the occupancy identifier is configured as occupied. It can be understood that when the occupancy identifier of the physical key is idle, the virtual key device is allowed to configure the physical key, and when the occupancy identifier of the physical key is occupied, the virtual key device is prohibited from configuring the physical key.

[0183] Accordingly, by determining which physical keys in the security processor are marked as idle, the physical keys that allow the virtual key device to be configured are determined.

[0184] Step S320: Configure the physical key whose occupancy is marked as free to the virtual key device;

[0185] It is understandable that after identifying a physical key that is marked as idle, the physical key can be configured to the virtual key device based on preset requirements.

[0186] Specifically, the security processor can call the physical key distribution interface to allocate physical key entities to the virtual key device.

[0187] When the virtual key device configures the physical key based solely on the physical key identifier, the physical key identifier corresponding to the physical key can be directly configured under the virtual key device, and step S330 can be further executed to mark the physical key's occupancy status as occupied, so as to prevent other virtual key devices from occupying the physical key.

[0188] When the virtual key device is configured with a virtual key identifier, after executing step S330 to mark the physical key's occupancy status as occupied, step S340 can be further executed to establish a mapping relationship between the physical key and the virtual key.

[0189] Step S330: Configure the occupancy flag of the physical key configured to the virtual key device as occupied.

[0190] By configuring the physical key occupancy flag to occupancy, the corresponding physical key can be prevented from being occupied by other virtual key devices.

[0191] When a virtual key device is configured with a virtual key identifier, the physical key can be configured to the virtual key device by establishing a mapping relationship. Specifically, step S340 is executed:

[0192] Step S340: Establish a mapping relationship between the virtual key identifier in the virtual key device and the physical key identifier of the configured physical key.

[0193] The established mapping relationship allows the corresponding physical key to be determined based on the virtual key identifier.

[0194] Below, we will first provide a detailed explanation of the virtual key device binding process, referring to step S400. (Reference) Figure 10 An optional binding process for a virtual key device is shown, the binding process for the virtual key device includes:

[0195] Step S410: The host sends a virtual device binding request;

[0196] The virtual device binding request is used to request binding a virtual key device to a preset virtual machine. Specifically, the virtual device binding request can be sent after the virtual key device has been successfully created and the corresponding creation response message has been obtained, thus confirming that the virtual key device to be bound has been created.

[0197] The virtual device binding request may include the virtual device identifier of the virtual key device, thereby determining the virtual key device to be bound.

[0198] Step S420: The security processor determines the virtual key device to be bound based on the acquired virtual device binding request;

[0199] After obtaining the virtual device binding request, the virtual key device to be bound can be determined based on the parsing of the virtual device binding request.

[0200] Step S430: When the virtual key device supports binding, the security processor records the correspondence between the virtual key device and the virtual machine based on the virtual device identifier, and configures the binding status of the virtual key device to be bound.

[0201] By recording the correspondence between the virtual key device and the virtual machine, a binding can be achieved. It is understood that when a virtual machine issues a command or request to the virtual key device, the corresponding virtual key device of the virtual machine can be determined by querying the binding information record.

[0202] Specifically, by configuring the binding status of the virtual key device to be bound, the exclusive type of virtual key device will no longer allow other virtual machines to bind.

[0203] Whether the virtual key device supports binding can be determined based on the corresponding sharing type and binding status. In an optional example, if the virtual key device is exclusive and not bound, shared and not bound, or shared and bound virtual machines allow virtual machines issuing virtual device binding requests to share it, then the virtual key device supports binding. In a further example, when the virtual key device is further configured with a valid identifier to determine whether the virtual key device is valid, the virtual key device supports binding, and the valid identifier of the virtual key device indicates that the virtual key device is valid.

[0204] In particular, after the security processor configures the virtual key device to be bound, it can further send a binding success message to the host to notify the host that the corresponding binding relationship has been established.

[0205] Understandably, to maximize the utilization of key resources, the virtual key device can be destroyed when the virtual machine no longer needs it (e.g., when the virtual machine is shut down or destroyed). The destruction process for the virtual key device is explained in detail below. (Reference) Figure 11 An optional destruction process for a virtual key device is shown, the destruction process of the virtual key device includes:

[0206] Step S500: The host sends a virtual device destruction request;

[0207] The virtual device destruction request is used to request the destruction of the virtual key device. The virtual device destruction request may include the virtual device identifier of the virtual key device, or the virtual machine identifier of the virtual machine bound to the virtual key device, thereby destroying the corresponding virtual key device based on the virtual device identifier or the virtual machine identifier.

[0208] Step S510: The security processor determines the virtual key device to be destroyed based on the acquired virtual device destruction command;

[0209] Specifically, when the virtual device destruction request includes the virtual device identifier of the virtual key device, the virtual key device can be destroyed directly based on the virtual device identifier; when the virtual device destruction request includes the virtual machine identifier of the virtual machine bound to the virtual key device, the virtual device identifier of the virtual key device bound to the virtual machine can be determined based on the virtual machine identifier, and then the virtual key device can be destroyed based on the virtual device identifier.

[0210] Step S520: The security processor releases the physical key occupied by the virtual key device indicated by the virtual device destruction command;

[0211] Specifically, by releasing the physical key, available physical key resources are provided to other virtual key devices.

[0212] In an optional example, where the virtual key device directly indicates the physical key with a physical key identifier, releasing the physical key occupied by the virtual key device may specifically include: configuring the occupancy identifier of the physical key configured by the virtual key device to be free.

[0213] In a further example, in the example where the virtual key device indicates the physical key with a mapping relationship between the virtual key identifier and the physical key identifier, releasing the physical key occupied by the virtual key device may specifically include: removing the mapping relationship between the virtual key identifier and the physical key identifier in the virtual key device, and configuring the occupied identifier of the physical key corresponding to the physical key identifier as idle.

[0214] In a further example, before step S520, it can be further determined whether the virtual key device supports destruction. If yes, then step S520 is executed; otherwise, the destruction process is exited.

[0215] Whether a virtual key device supports destruction can be determined based on its sharing type and sharing status. For example, exclusive virtual key devices support destruction, while shared virtual key devices only support destruction when all virtual machines bound to the virtual key device are allowed to destroy them. Specifically, destruction is not supported if any virtual machine bound to the virtual key device is in use of the virtual key device.

[0216] It is understandable that a virtual key device can include various key resources. Different key resources can perform corresponding data encryption and decryption for different data or in different scenarios, and consequently, different key resources have different requirements. In some scenarios, some key resources in the virtual key device need to be retained even after power loss. The physical key that meets the power loss retention requirement is used as the backup key. Accordingly, refer to... Figure 12 An optional backup procedure for a virtual key device is illustrated. This procedure, applied to a security processor, includes the following steps for backing up the virtual key device with a backup key:

[0217] Step S600: Based on the obtained key backup request, determine the virtual key device bound to the virtual machine;

[0218] The key backup request can be triggered by the host when the virtual machine is shut down, and is used to indicate the key to be backed up in the virtual key device; the key identifier used to indicate the key to be backed up in the key backup request is determined based on the key identifier type in the virtual machine. Accordingly, the key backup request can indicate the corresponding key to be backed up based on the virtual key identifier or the physical key identifier.

[0219] Step S610: Encrypt the key to be backed up in the virtual key device indicated by the key backup request to generate key ciphertext;

[0220] Specifically, when the key to be backed up is indicated based on a physical key identifier, the physical key indicated by the physical key identifier is the key with backup; when it is indicated based on a virtual key identifier, the physical key identifier can be determined based on the corresponding mapping relationship, and the physical key indicated by the mapped physical key identifier is the key with backup.

[0221] The encryption key with backup key can be generated based on CPU confidential information, user password, or a combination of both.

[0222] In schemes where encryption keys are generated based on CPU confidential information, the encryption key can be generated from CPU-specific confidential information, such as directly deriving from the CPU's unique confidential ID (identifier) ​​or generating a unique key corresponding to that CPU through methods like digest values. Because the encryption key is generated from information unique to each CPU, the corresponding encryption key is the same for different virtual machines running on the same machine. This means that the key ciphertext backed up by a virtual machine on the same machine can be restored in other virtual machines on the same machine, but will not be restored on other machines.

[0223] In a scheme where the encryption key is generated based on the user password, the encryption key can be derived from the user password or generated through a digest value, etc. Therefore, the encryption key can be generated as long as the user password is obtained. Correspondingly, any virtual machine can recover the ciphertext of the key as long as it obtains the user password.

[0224] In a scheme where the encryption key is generated based on a combination of CPU information and user password, the encryption key can be guaranteed to be obtained only within the virtual machine corresponding to the same CPU, and only when the user password is known. This scheme can achieve isolation between different CPUs and isolation within the same CPU by user password.

[0225] It should be noted that, to ensure the security of key data, after encrypting the key to be backed up, the integrity of the key ciphertext can also be protected.

[0226] Step S620: Store the key ciphertext to the file system.

[0227] It should be noted that in some examples, the encrypted key is typically stored in the non-volatile cache of the security processor. However, considering the limited non-volatile cache resources of the security processor, allocating corresponding non-volatile caches for multiple virtual machines created on the physical host for key backup can result in significant cache usage. Therefore, storing the encrypted key of virtual machines in a powered-off state in the file system can improve the utilization efficiency of the non-volatile cache in the security processor.

[0228] In the case of backup and recovery, the encrypted key can be decrypted and loaded into the slot of the physical key of the virtual key device bound to the virtual machine. In the example with integrity protection, integrity verification is performed before decrypting the encrypted key; decryption is only performed after successful verification.

[0229] In scenarios that support virtual machine migration, virtual machines can be migrated from a source device to a target device. Similarly, based on the binding characteristic between virtual machines and virtual key devices, the virtual key device can also be migrated from a source device to a target device. For details, refer to... Figure 13An optional migration process for a virtual key device is illustrated, wherein the source device includes a host and a security processor, and the target device includes a host and a security processor. The hosts of the source and target devices are used for auxiliary functions such as data interaction and resource requests, while the security processors of the source and target devices are used for the specific implementation of the migration. Specifically, the migration process for the virtual key device includes:

[0230] Step S700: The source device's host requests the device certificate of the target device and generates a migration key request based on the obtained device certificate;

[0231] The process involves requesting the target device's device certificate for authentication and, based on the public key within the device certificate, encrypting the migration data. Upon receiving the request, the target device's security processor can issue the device certificate. This allows the source device's host to acquire the device certificate and, based on it, generate a migration key request. The source device's security processor then executes the corresponding migration process based on this migration key request.

[0232] Step S710: The security processor of the source device determines whether the virtual key device to be migrated supports migration based on the acquired migration key request;

[0233] Based on the information in the migration key request, the virtual key device to be migrated can be determined. Specifically, the migration key request may include a virtual machine identifier for the virtual machine to be migrated, and based on this virtual machine identifier, the corresponding virtual key device can be determined.

[0234] The key migration request may include a device certificate for the target device, which includes a device public key used to encrypt a subsequently generated temporary key. The keys corresponding to the device certificate (device public key and device private key) can be an asymmetric key pair. The device private key can be derived by the target device's security processor based on the CPU's unique confidential ID.

[0235] The device certificate may include a certificate chain used to prove the identity of the target device. After verifying the certificate chain, the source device may extract the corresponding device public key to the key migration request for key encryption before key migration.

[0236] Based on permission information and sharing information, it can be determined whether a virtual key device supports migration. For example, if a virtual key device is shared by multiple virtual machines, and only one of the virtual machines bound to it is migrated, then the corresponding virtual key device does not support migration; however, a virtual key device shared by a single virtual machine or exclusively used by a single virtual machine supports migration. If the virtual key device supports migration, step S720 is executed. If the virtual key device does not support migration, the migration process ends.

[0237] Step S720: The security processor of the source device generates a temporary key and encrypts the physical key configured in the virtual key device based on the temporary key to generate key ciphertext.

[0238] The temporary key can be a symmetric key, used to encrypt and protect the integrity of the physical key configured in the virtual key device, generating key ciphertext. The physical key configured in the virtual key device to be migrated can also be referred to as the key to be migrated.

[0239] Step S730: The security processor of the source device encrypts the temporary key based on the device's public key to generate temporary key ciphertext.

[0240] Encryption is performed using a temporary public key based on the device's public key, allowing the target device to decrypt the temporary key ciphertext using the device's private key, thereby obtaining the temporary key. The temporary key is then used to decrypt the key data in the physical key of the virtual key device.

[0241] Step S740: The host of the source device initiates a migration permission message so that the target device can determine whether to receive the data to be migrated.

[0242] The migration permission message indicates that the source device has completed the preparation work for key migration, thereby notifying the target device to determine whether to receive the data to be migrated, so as to realize the corresponding key migration. The data to be migrated may include the key ciphertext and the temporary key ciphertext.

[0243] In some specific examples, the key ciphertext and temporary key ciphertext can be migrated together with the data to be migrated in the virtual machine (also known as virtual machine data). Accordingly, the data to be migrated may also include virtual machine data.

[0244] Step S750: The security processor of the target device determines whether to receive the data to be migrated.

[0245] In an optional example, after receiving the migration permission message, the host of the target device generates and sends a migration request, so that the target device's security processing determines whether to receive the data to be migrated based on the migration request. This could include, for example, determining whether a virtual key device exists in the target device that meets migration conditions, wherein meeting migration conditions could include the virtual key device being available and allocable, and the number of keys within it matching the number of keys in the virtual key device to be migrated. If a virtual key device that meets the migration conditions exists, the target device is considered to receive the data to be migrated, and accordingly, a data migration message is sent, causing the source device to execute step S760 and send the data to be migrated.

[0246] If no virtual key device meets the migration criteria, it can be created to ensure the target device receives the data to be migrated. It should be noted that if a virtual key device meeting the migration criteria cannot be obtained, the target device will not receive the data, and the target device's host will return a migration status to the source device, indicating migration failure.

[0247] Step S760: The host of the source device sends the data to be migrated to the target device based on the data migration message sent by the target device.

[0248] Correspondingly, the host of the target device can receive the corresponding data to be migrated.

[0249] Step S770: The security processor of the target device decrypts the key ciphertext in the data to be migrated sent by the source device and loads it into a virtual key device that meets the migration conditions.

[0250] Specifically, the security processor of the target device can import the key ciphertext and the temporary key ciphertext into its own target security processor (i.e., the security processor within the target device). The target security processor decrypts the temporary key ciphertext based on the device's private key to obtain the temporary key, and further decrypts the key data of the virtual key device of the source device based on the temporary key. After integrity verification, the key data is loaded into the slot corresponding to the virtual key device that meets the migration conditions.

[0251] After the transfer is completed, the host of the target device can return the migration status to the source device, indicating that the data to be migrated (i.e., the key data) has been successfully migrated.

[0252] In an optional example, after the source device receives the migration status and confirms that the key data migration is successful, it can also destroy the migrated virtual key device and release the physical key occupied by the virtual key device. If the key data migration fails, the migration process ends.

[0253] This invention also provides a computing device that may include the security processor described above.

[0254] This invention also provides a computer program comprising one or more computer-executable instructions, wherein when the one or more computer-executable instructions are executed, they implement the key invocation method, or implement the key backup method, or implement the key migration method.

[0255] The foregoing describes multiple embodiments of the present invention. The optional methods described in each embodiment can be combined and cross-referenced without conflict, thereby extending to a variety of possible embodiments. These can all be considered as embodiments disclosed or made public by the present invention.

[0256] While the embodiments of the present invention have been disclosed above, this application is not limited thereto. Any person skilled in the art can make various modifications and alterations without departing from the spirit and scope of this application; therefore, the scope of protection of this application should be determined by the scope defined in the claims.

Claims

1. A security processor, characterized in that, include: A virtual key device is used to configure at least one physical key and to bind to a virtual machine; wherein the virtual key device indicates the configured physical key based on a virtual key identifier and a physical key identifier, the virtual key identifier being mapped to the physical key identifier of the physical key; The command parsing module is used to determine the virtual key device bound to the virtual machine based on the obtained virtual machine's invocation commands; The key invocation module is used to determine the physical key identifier mapped by the virtual key identifier in the virtual key device based on the virtual key identifier in the invocation command, and to invoke the corresponding physical key based on the physical key identifier.

2. The security processor according to claim 1, characterized in that, Also includes: The virtual device configuration module is used to configure the physical key for the virtual key device; The physical key is configured with an occupancy flag, which indicates whether the physical key is idle or occupied. When the physical key is configured to a virtual key device, the occupancy flag is configured as occupied. Specifically, when the occupancy flag of the physical key is idle, the virtual key device is allowed to configure the physical key, and when the occupancy flag of the physical key is occupied, the virtual key device is prohibited from configuring the physical key.

3. The security processor according to claim 2, characterized in that, The virtual device configuration module is used to configure physical keys for the virtual key device, including establishing a mapping relationship between the virtual key identifier in the virtual key device and the physical key identifier of the configured physical key.

4. The security processor according to claim 2, characterized in that, The virtual device configuration module is used to configure the physical key for the virtual key device, specifically: Before binding the virtual key device to the virtual machine, configure a physical key for the virtual key device; or, After binding the virtual key device to the virtual machine, a physical key is configured for the virtual key device based on the obtained key creation command.

5. The security processor according to claim 1, characterized in that, The virtual key device is configured with a virtual device identifier, and the virtual machine binds to the virtual key device based on the virtual device identifier; The command parsing module is used to determine the virtual key device bound to the virtual machine based on the obtained virtual machine's call command. Specifically, it determines the virtual device identifier of the virtual key device based on the virtual machine that issued the call command.

6. The security processor according to claim 1, characterized in that, The command parsing module is also used to: determine the virtual key device to be destroyed based on the obtained virtual device destruction command; The security processor further includes a virtual device destruction module, used to release the physical key occupied by the virtual key device indicated by the virtual device destruction command based on the virtual device destruction command.

7. The security processor according to claim 6, characterized in that, The virtual key device indicates the physical key with a physical key identifier. The virtual device destruction module is used to release the physical key occupied by the virtual key device, specifically by configuring the occupancy identifier of the physical key configured in the virtual key device to be free. The virtual key device indicates the physical key by a mapping relationship between the virtual key identifier and the physical key identifier. The virtual device destruction module is used to release the physical key occupied by the virtual key device, including: removing the mapping relationship between the virtual key identifier and the physical key identifier in the virtual key device; and configuring the occupied identifier of the physical key corresponding to the physical key identifier as idle.

8. The security processor according to claim 1, characterized in that, The command parsing module is further configured to: determine the attribute parameters of the virtual key device to be created based on the acquired virtual device creation request, wherein the attribute parameters include the sharing type and the number of keys; The security processor further includes a virtual device creation module for creating a virtual key device corresponding to the attribute parameters.

9. The security processor according to claim 8, characterized in that, The virtual device creation module is used to create a virtual key device corresponding to the attribute parameters, including: Based on the number of virtual key devices that the security processor can support creating and the number of existing virtual key devices, determine whether to allow the creation of virtual key devices; If so, generate a virtual device identifier corresponding to the virtual key device, and configure the maximum available key space for the virtual key device; Based on the virtual device identifier, configure the sharing type of the virtual key device. The sharing type includes exclusive or shared. The exclusive sharing type indicates that the virtual key device is exclusively owned by a virtual machine, and the shared sharing type indicates that the virtual key device is allowed to be shared by multiple virtual machines.

10. The security processor according to claim 1, characterized in that, The command parsing module is also used to: determine the virtual key device to be bound based on the obtained virtual device binding request; The security processor further includes a virtual device binding module, which, when the virtual key device supports binding, records the correspondence between the virtual key device and the virtual machine based on the virtual device identifier, and configures the binding status of the virtual key device to be bound.

11. A key retrieval method, characterized in that, An application is made to a security processor, wherein a virtual key device is configured within the security processor. The virtual key device is used to configure at least one physical key and to bind to a virtual machine. The virtual key device indicates the configured physical key based on a virtual key identifier and a physical key identifier, wherein the virtual key identifier is mapped to the physical key identifier of the physical key. The method includes: Obtain the virtual machine's invocation commands; Based on the obtained virtual machine's invocation commands, determine the virtual key device bound to the virtual machine; Based on the virtual key identifier in the invocation command, the physical key identifier mapped by the virtual key identifier in the virtual key device is determined, and the corresponding physical key is invoked based on the physical key identifier.

12. The key retrieval method according to claim 11, characterized in that, Before obtaining the virtual machine's invocation command, the process also includes: Before binding the virtual key device to the virtual machine, configure a physical key for the virtual key device; or, After binding the virtual key device to the virtual machine, configure the physical key for the virtual key device.

13. The key retrieval method according to claim 12, characterized in that, The physical key is configured with an occupancy identifier. Configuring the physical key for the virtual key device includes: Determine which physical keys are marked as idle in the security processor; Configure the physical key marked as idle to the virtual key device; Configure the occupancy flag of the physical key configured to the virtual key device as occupied.

14. The key retrieval method according to claim 12, characterized in that, Configuring a physical key for the virtual key device further includes: establishing a mapping relationship between the virtual key identifier in the virtual key device and the physical key identifier of the configured physical key.

15. The key retrieval method according to claim 11, characterized in that, Before obtaining the virtual machine's invocation command, the process also includes: Create a virtual key device; Configure the maximum available key space for the virtual key device, and bind the virtual key device to the virtual machine.

16. The key retrieval method according to claim 15, characterized in that, The creation of the virtual key device includes: The attribute parameters of the virtual key device to be created are determined based on the obtained virtual device creation request. The attribute parameters include the sharing type and the number of keys. Create a virtual key device corresponding to the attribute parameters.

17. The key retrieval method according to claim 16, characterized in that, The creation of a virtual key device corresponding to the attribute parameters includes: Based on the number of virtual key devices that the security processor can support creating and the number of existing virtual key devices, determine whether to allow the creation of virtual key devices; If so, generate a virtual device identifier corresponding to the virtual key device, and configure the maximum available key space for the virtual key device; Based on the virtual device identifier, configure the sharing type of the virtual key device. The sharing type includes exclusive or shared. The exclusive sharing type indicates that the virtual key device is exclusively owned by a virtual machine, and the shared sharing type indicates that the virtual key device is allowed to be shared by multiple virtual machines.

18. The key retrieval method according to claim 15, characterized in that, Binding the virtual key device to the virtual machine includes: The virtual key device to be bound is determined based on the obtained virtual device binding request; When the virtual key device supports binding, the correspondence between the virtual key device and the virtual machine is recorded based on the virtual device identifier, and the binding status of the virtual key device is configured as bound.

19. The key retrieval method according to claim 11, characterized in that, Also includes: The virtual key device to be destroyed is determined based on the obtained virtual device destruction command; Release the physical key occupied by the virtual key device indicated by the virtual device destruction command.

20. The key retrieval method according to claim 19, characterized in that: The virtual key device indicates the physical key with a physical key identifier. Releasing the physical key occupied by the virtual key device specifically involves setting the occupancy identifier of the physical key configured in the virtual key device to be free. The virtual key device indicates the physical key by mapping the virtual key identifier to the physical key identifier. Releasing the physical key occupied by the virtual key device includes: removing the mapping relationship between the virtual key identifier and the physical key identifier in the virtual key device; and configuring the occupied identifier of the physical key corresponding to the physical key identifier as idle.

21. A key backup method, characterized in that, An application is made to a security processor, wherein a virtual key device is configured within the security processor. The virtual key device is used to configure at least one physical key and to bind to a virtual machine. The virtual key device indicates the configured physical key based on a virtual key identifier and a physical key identifier, wherein the virtual key identifier is mapped to the physical key identifier of the physical key. The method includes: Based on the obtained key backup request, determine the virtual key device bound to the virtual machine, wherein the key backup request is used to indicate the key to be backed up; Encrypt the key to be backed up in the virtual key device indicated by the key backup request to generate key ciphertext; Store the encrypted key to the file system.

22. A key migration method, characterized in that, When a source device migrates a virtual key device to a target device, a security processor is applied to the source device. The security processor is configured with a virtual key device, which is used to configure at least one physical key and to bind to a virtual machine. The virtual key device indicates its configured physical key based on a virtual key identifier and a physical key identifier, where the virtual key identifier is mapped to the physical key identifier of the physical key. The method includes: Based on the obtained migration key request, determine whether the virtual key device to be migrated supports migration, wherein the migration key request includes the device public key; Generate a temporary key, and encrypt the physical key configured in the virtual key device based on the temporary key to generate key ciphertext; Based on the device's public key, the temporary key is encrypted to generate a temporary key ciphertext, so that the source device's host can send the data to be migrated to the target device based on the data migration message sent by the target device.

23. A key migration method, characterized in that, When a source device migrates a virtual key device to a target device, a security processor is applied to the target device. The security processor is configured with a virtual key device, which is used to configure at least one physical key and to bind to a virtual machine. The virtual key device indicates its configured physical key based on a virtual key identifier and a physical key identifier, where the virtual key identifier is mapped to the physical key identifier of the physical key. The method includes: Send a device certificate so that the source device generates a migration key request based on the device certificate, the device certificate including the device public key; Based on the received migration request, determine whether to receive the data to be migrated, wherein the data to be migrated is generated based on the migration permission message of the source device; The key ciphertext in the data to be migrated sent by the source device is decrypted and loaded into a virtual key device that meets the migration conditions.

24. A computing device, characterized in that, Includes a physical host and a security processor as described in any one of claims 1-10.

25. A computer program, characterized in that, It includes one or more computer-executable instructions, which, when executed, implement the key retrieval method as described in any one of claims 11-20, or implement the key backup method as described in claim 21, or implement the key migration method as described in any one of claims 22-23.

Images