Key calling, backup and migration method and related equipment

Abstract

The embodiment of the invention provides a key calling, backup and migration method and related equipment, and a security processor comprises virtual key equipment which is used for configuring at least one physical key and is bound with a virtual machine; the command analysis module is used for determining virtual key equipment bound with the virtual machine based on the acquired calling command of the virtual machine; and the key calling module is used for calling the physical key indicated by the calling command from the determined virtual key equipment. It can be seen that the security processor in the embodiment of the invention can improve the calling efficiency of the key.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of data security technology, and specifically to a key calling, backup, and migration method and related equipment. Background Art

[0002] Through virtualization technology, a physical host can be virtualized into multiple virtual machines (VMs), thereby maximizing the use of the physical host's hardware resources; each virtualized virtual machine can encrypt its data based on cryptographic technology to ensure the data security of the virtual machine.

[0003] A security processor is a trusted device that provides security management for a physical host, including key management, secure memory management, and other services. However, the key call processing efficiency of existing security processors is low. Summary of the Invention

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

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

[0006] In a first aspect, an embodiment of the present invention provides a security processor, including:

[0007] A virtual key device, used to configure at least one physical key and to bind to a virtual machine;

[0008] A command parsing module, configured to determine a virtual key device bound to the virtual machine based on the acquired calling command of the virtual machine;

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

[0010] Optionally, the security processor further includes:

[0011] A virtual device configuration module, configured to configure a physical key for the virtual key device;

[0012] The physical key is configured with an occupation flag, which is used to indicate whether the physical key is idle or occupied. When the physical key is configured to the virtual key device, the occupation flag is configured to occupied; wherein, when the occupation flag of the physical key is idle, the virtual key device is allowed to configure the physical key, and when the occupation 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 the virtual key identifier and the 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 a physical key for the virtual key device, including establishing a mapping relationship between a virtual key identifier in the virtual key device and a physical key identifier of the configured physical key;

[0015] The key calling module is used to call the physical key indicated by the calling command from the determined virtual key device, specifically, based on the virtual key identifier in the calling command, determine the physical key identifier mapped by the virtual key identifier in the virtual key device, and call the corresponding physical key based on the physical key identifier.

[0016] Optionally, the calling command includes the virtual key identifier; the virtual device configuration module is configured 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, configuring a physical key for the virtual key device;

[0018] or,

[0019] After the virtual key device is bound 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 is bound to the virtual key device based on the virtual device identifier;

[0021] The command parsing module is configured to determine the virtual key device bound to the virtual machine based on the acquired calling command of the virtual machine, specifically, to determine the virtual device identifier of the virtual key device based on the virtual machine that issues the calling 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, configured 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 a 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 occupation identifier of the physical key configured by the virtual key device to be idle;

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

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

[0027] The security processor further includes: a virtual device creation module, configured to create 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] Determining whether to allow creation of a virtual key device based on the number of virtual key devices supported by the security processor and the number of existing virtual key devices;

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

[0031] Based on the virtual device identifier, the sharing type of the virtual key device is configured, where the sharing type includes exclusive or shared. The exclusive sharing type indicates that the virtual key device is exclusively used by the 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 a 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 configured to record the correspondence between the virtual key device and the virtual machine based on the virtual device identifier when the virtual key device supports binding, and configure the binding state of the virtual key device to be bound.

[0034] In a second aspect, an embodiment of the present invention further provides a key calling method, which is applied to a security processor, wherein the security processor is configured with a virtual key device, the virtual key device is used to configure at least one physical key and is used to bind to a virtual machine, including:

[0035] Get the calling command of the virtual machine;

[0036] Determining a virtual key device bound to the virtual machine based on the acquired calling command of the virtual machine;

[0037] The physical key indicated by the calling command is called from the determined virtual key device.

[0038] Optionally, before obtaining the calling command of the virtual machine, the method further includes:

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

[0040] or,

[0041] After the virtual key device is bound to the virtual machine, a physical key is configured for the virtual key device.

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

[0043] Determine a physical key in a security processor that is marked as idle;

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

[0045] The occupation flag of the physical key configured to the virtual key device is configured as occupied.

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

[0047] The self-determined virtual key device calls the physical key indicated by the calling command, specifically, based on the virtual key identifier in the calling command, determines the physical key identifier mapped to the virtual key identifier in the virtual key device, and calls the corresponding physical key based on the physical key identifier.

[0048] Optionally, before obtaining the calling command of the virtual machine, the method further includes:

[0049] Create a virtual key device;

[0050] A maximum available key space is configured for the virtual key device, and the virtual key device is bound to a virtual machine.

[0051] Optionally, the creating a virtual key device includes:

[0052] Determining attribute parameters of a virtual key device to be created based on the obtained virtual device creation request, wherein the attribute parameters include a sharing type and a key quantity;

[0053] A virtual key device corresponding to the attribute parameters is created.

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

[0055] Determining whether to allow creation of a virtual key device based on the number of virtual key devices supported by the security processor and the number of existing virtual key devices;

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

[0057] Based on the virtual device identifier, the sharing type of the virtual key device is configured, where the sharing type includes exclusive or shared. The exclusive sharing type indicates that the virtual key device is exclusively used by the 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] Determining a virtual key device to be bound based on the obtained virtual device binding request;

[0060] When the virtual key device supports binding, the corresponding relationship between the virtual key device and the virtual machine is recorded based on the virtual device identifier, and the binding state of the virtual key device is configured to be bound.

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

[0062] Determining the virtual key device to be destroyed based on the acquired virtual device destruction command;

[0063] The physical key occupied by the virtual key device indicated by the virtual device destruction command is released.

[0064] Optionally, the virtual key device indicates a physical key with a physical key identifier, and releasing the physical key occupied by the virtual key device is specifically: configuring the occupation identifier of the physical key configured by the virtual key device to be idle;

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

[0066] In a third aspect, an embodiment of the present invention further provides a key backup method, which is 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, comprising:

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

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

[0069] The key ciphertext is stored in the file system.

[0070] In a fourth aspect, an embodiment of the present invention further provides a key migration method, which is applied to a security processor of the source device when migrating a virtual key device to a target device, 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 being used to bind to a virtual machine, comprising:

[0071] Determining whether the virtual key device to be migrated supports migration based on the obtained key migration request, wherein the key migration request includes a 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 a key ciphertext;

[0073] The temporary key is encrypted based on the device public key to generate a temporary key ciphertext, so that 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.

[0074] In a fifth aspect, an embodiment of the present invention further provides a key migration method, which is applied to a security processor of the target device when a source device migrates a virtual key device to a target device, 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 being bound to a virtual machine, comprising:

[0075] Sending a device certificate, so that the source device generates a migration key request based on the device certificate, wherein the device certificate includes a device public key;

[0076] determining, based on the obtained received migration request, whether to receive data to be migrated, the data to be migrated being generated based on a migration permission message from a source device;

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

[0078] In a sixth aspect, an embodiment of the present invention further provides a computing device comprising a physical host and the security processor described in the first aspect.

[0079] In the seventh aspect, an embodiment of the present invention also provides a computer program comprising one or more computer executable instructions, which, when executed, implement the key calling 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 aspect or the fifth aspect.

[0080] An embodiment of the present invention provides a key calling, backup, and migration method and related equipment, wherein a security processor includes: a virtual key device, used to configure at least one physical key and to bind to a virtual machine; a command parsing module, used to determine the virtual key device bound to the virtual machine based on an acquired calling command of the virtual machine; and a key calling module, used to call the physical key indicated by the calling command from the determined virtual key device.

[0081] It can be seen that the security processor in the embodiment of the present invention configures a virtual key device therein so that the virtual machine is bound to the virtual key device, and can determine the virtual key device bound to the virtual machine based on the obtained calling command of the virtual machine, thereby calling the physical key indicated by the calling 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 call the physical key on the premise of distinguishing the key resources corresponding to different virtual machines, so that the physical key called by the virtual machine can be determined quickly and efficiently, thereby improving the key calling efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0082] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0083] Figure 1 This is an optional architecture diagram for cloud services based on virtualization technology.

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

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

[0086] Figure 4 A key identification configuration diagram of a virtual key device provided by an embodiment of the present invention.

[0087] Figure 5 A schematic diagram of an optional flow chart of a key calling method provided in an embodiment of the present invention.

[0088] Figure 6 A schematic diagram of an optional flow chart for configuring a virtual key device provided by an embodiment of the present invention.

[0089] Figure 7 This is a flowchart of an optional creation of a virtual key device provided by an embodiment of the present invention.

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

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

[0092] Figure 10 A flowchart of optional binding of a virtual key device provided by an embodiment of the present invention.

[0093] Figure 11 A flowchart of optional destruction of a virtual key device provided by an embodiment of the present invention.

[0094] Figure 12 A flowchart of optional backup of a virtual key device provided by an embodiment of the present invention.

[0095] Figure 13 This is a flowchart of an optional migration of a virtual key device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0096] The following will be combined with the accompanying drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0097] Virtualization technology can be applied in a variety of scenarios. With the development of cloud services, in particular, virtualization technology has become increasingly widely used in cloud services. To facilitate understanding of virtualization technology, the following introduction uses a virtualization-based cloud service as an example.

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

[0099] The cloud host 100 is a host device (which may be 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 that meet their business needs based on their business needs, so that the user can run applications on multiple virtual machines belonging to the user, and collaborate to complete the user's specific business through the applications running on multiple virtual machines. It can be understood that the virtual machine is the client that provides services to the user.

[0100] The network 200 can be considered as the Internet, or other forms of networks with communication functions. Communication and data transmission are achieved between the cloud host and the user through the network. The embodiment of the present invention does not limit the specific network form of the network 200.

[0101] Users 301 to 30n are registered users of cloud services. There can be multiple users, and the embodiment of the present invention does not limit the specific value of n. In a cloud service scenario, each user can own one or more virtual machines on a cloud host, utilizing the user's virtual machines to complete user-specific services.

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

[0103] Among them, the CPU core 10 can be based on the host operating system (hereinafter referred to as host) 11 running therein, and can virtualize multiple virtual machines 12 through virtualization technology. The multiple virtual machines 12 can manage the virtual machines and allocate resources based on the host 11.

[0104] The security processor 40 is a specialized processor responsible for handling security-related operations of the computing device. It provides services such as key management and memory management for the host and virtual machines. The security processor has its own dedicated hardware resources, enabling it to establish a trusted execution environment free from interference from the CPU core. Furthermore, software running on the security processor can be verified by relevant security mechanisms (such as digital signatures), ensuring the software's trustworthiness. Furthermore, the security processor communicates with the processor core via a specific internal hardware interface (hereafter referred to as the preset interface), enabling call-based exchange of security information with the processor core, ensuring secure communication between the security processor and the processor core.

[0105] The security processor also has a built-in physical key resource (also known as a cryptographic resource), such as the chip endorsement key (CEK). The CEK private key is embedded within the chip housing the security processor and can be stored as confidential information of the security processor, preventing external hardware from accessing it. For each CEK private key, there is a public CEK public key certificate to verify its authenticity.

[0106] The computing device also includes dedicated secure memory and secure flash memory for the security processor, providing secure storage space for the processor. The secure memory can store code or data during the security processor's runtime, while the secure flash memory can store keys used in security processing. The secure memory and secure flash memory configured in the security processor can be configured with automatic encryption and consistency protection at the hardware level, without allowing access by the CPU core, thereby ensuring data security for the security processor.

[0107] During the data flow of the computing device, the security processor can manage the physical key 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. It is equipped with cryptographic algorithm logic to encrypt and decrypt the corresponding virtual machine data based on the physical key configured by the security processor. After being encrypted by the cryptographic coprocessor, virtual machine data can be stored in system memory to ensure data security. After reading virtual machine data from system memory, it is decrypted by the cryptographic coprocessor to obtain the original virtual machine data.

[0109] Regarding key management of the security processor, in one example, a cryptographic module can be configured inside the security processor 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, based on the correspondence, instruct the cryptographic coprocessor to perform encryption and decryption of the virtual machine data based on the physical key.

[0110] However, in this way, the security processor manages and configures physical keys uniformly and indiscriminately. In a scenario where there are multiple virtual machines and one virtual machine corresponds to multiple physical keys, the corresponding key configuration information is messy and complicated, making the corresponding key call efficiency low.

[0111] In view of this, an embodiment of the present invention provides a security processor, including: a virtual key device, used to configure at least one physical key and to bind to a virtual machine; a command parsing module, used to determine the virtual key device bound to the virtual machine based on the obtained calling command of the virtual machine; and a key calling module, used to call the physical key indicated by the calling command from the determined virtual key device.

[0112] It can be seen that the security processor in the embodiment of the present invention configures a virtual key device therein so that the virtual machine is bound to the virtual key device, and can determine the virtual key device bound to the virtual machine based on the obtained calling command of the virtual machine, thereby calling the physical key indicated by the calling 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 call the physical key on the premise of distinguishing the key resources corresponding to different virtual machines, so that the physical key called by the virtual machine can be determined quickly and efficiently, thereby improving the key calling efficiency.

[0113] At the same time, it is understandable that in the existing key management method, physical keys are used as units to correspond to virtual machines, and the key configuration information is messy and complicated, which makes it difficult to simultaneously achieve the migration and backup of the configured physical keys when the virtual machine needs to be migrated or backed up. The embodiment of the present invention is essentially based on the management of the physical keys of the virtual machine based on the virtual key device, thereby making the overall processing of the physical keys corresponding to the virtual machine a reality, so that 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 disclosure of the embodiment of the present invention, an embodiment of the present invention further provides a computing system based on virtualization technology, referring to Figure 3The figure shows an optional structural diagram of a computing device based on virtualization technology. In the computing device, the physical host can be understood as a hardware combination that configures / runs the host operating system and the virtual machine, also known as the host machine. The physical host side uses and manages the physical key by interacting with the security processor.

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

[0116] The physical host side is further configured with a command transfer 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; a command parsing module is used to determine the virtual key device bound to the virtual machine based on the obtained calling command of the virtual machine; and a key calling module is used to call the physical key indicated by the calling command from the determined virtual key device.

[0118] The command parsing module may obtain a command or request from the virtual machine and parse the obtained command or request. It is understood that upon obtaining a call command for the virtual machine to call a key, the virtual key device bound to the virtual machine may be determined based on the obtained call command, thereby causing the key calling module to call the physical key indicated by the call 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 a key resource for the virtual key device. In an optional example, the virtual key device can be a virtual password card or a physical password card.

[0120] The virtual key device can be configured as a key resource exclusively used by a virtual machine, or as a key resource that can be shared by multiple virtual machines. When the virtual key device is used as a key resource exclusively used by a virtual machine, it can only be bound to one virtual machine, so that 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, so that virtual machines bound to the same virtual key device can share the key resource of the virtual key device.

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

[0122] It can be 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 can use the virtual key device; when the virtual key device is shared by multiple virtual machines, the virtual key device allows multiple virtual machines to be bound, so that multiple bound virtual machines can use the virtual key device.

[0123] In an optional example, the virtual key device is configured with a virtual device identifier (vid) corresponding to one of the virtual device identifiers. Figure 3 The virtual device identifiers vid1, vid2, ..., vidn are shown, so that the virtual machine can bind the virtual key device based on the virtual device identifier. In a specific example, virtual key device 0 is generally used to indicate the virtual key device corresponding to the host, and the corresponding virtual device identifier can be vid0. The characteristics corresponding to the virtual key device corresponding to the host and the virtual key device corresponding to the virtual machine can be the same or different. In one example, the virtual key device corresponding to the host can be a physical password card, and the virtual key device corresponding to the virtual machine can be a virtual password card.

[0124] Accordingly, given that the binding relationship between the virtual machine and the virtual key is clear, when the command parsing module determines the virtual key device bound to the virtual machine based on the acquired virtual machine call command, it can determine the virtual device identifier of the virtual key device based on the virtual machine that issued the call command. It is understood that the call command for a virtual machine to call a key includes the identity information of the virtual machine that issued the call command, thereby determining the issuer of the call command. This virtual machine 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 call command.

[0125] In a further example, a virtual device configuration module may be configured in the virtual key device to configure a physical key for the virtual key device. Figure 4 A schematic diagram of a key identifier configuration of a virtual key device is shown. The physical key in an embodiment of the present invention is configured with an occupation identifier, which is used to indicate whether the physical key is idle or occupied. When the physical key is configured to the virtual key device, the occupation identifier is configured as occupied. It can be understood that when the occupation identifier of the physical key is idle, the virtual key device is allowed to configure the physical key, and when the occupation identifier of the physical key is occupied, the virtual key device is prohibited from configuring the physical key.

[0126] It is understandable that an occupied physical key will not be redistributed, that is, an occupied physical key will not be allowed to be occupied by other virtual key devices again, thereby ensuring that the key will not be cross-accessed and called by multiple virtual key devices, 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 a virtual key identifier and a physical key identifier, and the physical key of the virtual key device is 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 for the physical key in 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 to the virtual machine for virtual machine calls, such as a key index configured for the virtual key device. Therefore, in the specific call command of the virtual machine, the virtual key identifier is used to indicate the physical key it calls.

[0128] It is understood 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. Furthermore, based on the corresponding relationship between virtual key devices and virtual machines, the number of physical keys configured with virtual key devices is greatly reduced, and the corresponding virtual key identifier can be further simplified, such as using fewer digits to represent the virtual key identifier, thereby reducing the complexity of the call process.

[0129] In a specific example, refer to Figure 4 A schematic diagram of a key identifier configuration for a virtual key device is shown. The key identifier includes a virtual key identifier and a physical key identifier, so that the virtual key device indicates its configured physical key based on the virtual key identifier and the physical key identifier. Accordingly, the virtual device configuration module is used to configure a physical key for the virtual key device and also 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. The corresponding key call module, based on the virtual key identifier in the call command, determines the physical key identifier in the virtual key device to which the virtual key identifier is mapped, and further calls the corresponding physical key based on the physical key identifier.

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

[0131] It's understandable that once a mapping relationship is established between a physical key identifier and the corresponding virtual key identifier, and the corresponding physical key is configured as occupied, the physical key is no longer an allocable resource. However, in most scenarios, virtual machines only use a small amount of key resources for data encryption, while other keys remain idle, resulting in inefficient key resource usage.

[0132] In view of this, in a further example of the present invention, by changing the timing of establishing a mapping relationship between a physical key identifier and a virtual key identifier, the probability of the physical key being vacant is reduced, thereby improving the efficiency of using key resources.

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

[0134] In a specific example, with the number of physical keys being N, if P physical keys are allocated to each virtual key device in advance, then at most N / P virtual key devices can be allocated. In normal usage scenarios, the virtual key device may actually use fewer keys. If all the remaining keys are reserved, it will be a waste, and the number of supported virtual key devices will be even smaller. The above-mentioned method in the embodiment of the present invention can be understood as an idea of ​​over-allocation, that is, after binding the virtual key device to the virtual machine, the step of configuring a physical key for the virtual key device is executed. Accordingly, in the specific configuration process, Figure 4 Taking the key identifier configuration of a virtual key device shown as an example, a corresponding number of virtual key identifiers can be configured for the virtual key device 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 can be used by the created virtual key device is 1 to P', where 1 to P' can be understood as the virtual key identifier range.

[0135] When the security processor receives a key creation command for a virtual machine bound to a corresponding virtual key device, it allocates a corresponding 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 a physical key allocation interface to allocate a physical key for the virtual key identifier. At this time, it can also set the occupation identifier configuration bit of the physical key to occupied to indicate that the physical key has been occupied. Then, it maps the virtual key identifier to the physical key identifier of the configured physical key.

[0136] It can be understood that in the scheme 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 for use, which is 10 times higher than the original N / P. If the actual average number of physical keys used is smaller, the number of virtual key devices that can be supported will be greater. Alternatively, even if some virtual key devices are used in larger numbers, if other virtual key devices are used in smaller numbers, this can also be achieved when the sum of the used numbers does not exceed the maximum number of physical resources, thereby maximizing the use of physical key resources.

[0137] In one specific example, the creation of the virtual key device can be triggered based on a virtual device creation request from the physical host. The virtual device creation request can include attribute parameters of the virtual key device to be created, such as a sharing type and the number of keys. Specifically, after the command parsing module obtains the virtual device creation request, the attribute parameters of the virtual key device to be created can be determined based on the obtained virtual device creation request. The attribute parameters include a sharing type and a maximum available key space. 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 configured to create a virtual key device corresponding to the attribute parameters. The created virtual key device can be configured as exclusive or shared based on the sharing type in the attribute parameters, and a corresponding key identifier can be configured for the created virtual key device based on the number of keys.

[0139] In the process of creating a virtual key device corresponding to the attribute parameters, it is necessary to consider the number of virtual key devices supported by the security processor and the number of existing virtual key devices to determine whether the creation of the virtual key device is allowed. Specifically, the number of virtual key devices supported by the security processor (that is, the maximum number of virtual key devices supported by the security processor) and the number of existing virtual key devices can be determined to determine whether the number of virtual key devices supported by the security processor is greater than the number of existing virtual key devices; if so, it indicates that the creation of the virtual key device is allowed, 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, where the maximum available key space is used to indicate the maximum number of keys that can be configured for the virtual key device.

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

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

[0142] After creating a virtual key device, the virtual machine and the virtual key device 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 up. In the security processor, the command parsing module can then determine the virtual key device (VID) to be bound based on the virtual device binding request after receiving it.

[0143] The security processor may further include a virtual device binding module for recording the correspondence between the virtual key device and the virtual machine based on the virtual device identifier when the virtual key device supports binding, and configuring the binding state of the virtual key device to be bound.

[0144] The virtual key device supports binding. In an optional example, the virtual key device supports binding if it is exclusive and unbound, shared and unbound, or shared by a bound virtual machine that allows the virtual machine that issued the virtual device binding request to be shared. In a further example, the virtual key device is further configured with a valid identifier for identifying 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 after the virtual key device has been used up (for example, in the scenario of destroying the virtual machine, or in the scenario where the virtual key device is no longer used by the virtual machine), the virtual key device can also be destroyed. Accordingly, the destruction of the virtual key device can be triggered based on the virtual device destruction command on the physical host side. For example, the virtual machine management machine in the physical host or the host with virtual machine management function can issue a virtual device destruction command based on the administrator's instructions or instructions triggered in 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 configured to, based on the virtual device destruction command, release the physical key occupied by the virtual key device indicated by the virtual device destruction command. It is understood that, based on the virtual device destruction command, data associated with the virtual key device may be further cleared, which is not further described in detail in the present invention.

[0147] As another optional implementation of the disclosed content of the embodiment of the present invention, one embodiment of the present invention further provides a key calling method, which is applied to a security processor, wherein the security processor is configured with a virtual key device, and the virtual key device is used to configure at least one physical key and is used to bind to a virtual machine. The description of the virtual key device, the physical key configured therewith, and the binding relationship between the virtual key device and the virtual machine can refer to the above content, reference Figure 5 FIG. 1 is a schematic diagram of an optional flow chart of a key calling method, wherein the key calling method includes:

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

[0149] The calling command may be issued by a virtual machine (for example, a device driver of the virtual machine) to call a preset physical key, so as to implement encryption and decryption of virtual machine data based on the corresponding physical key.

[0150] The call command includes a key identifier to indicate the specific physical key being called. The 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 call command is a physical key identifier. When the virtual key device indicates its configured physical key using a mapping relationship between a virtual key identifier and a physical key identifier, the key identifier in the corresponding call command is a virtual key identifier.

[0151] It is understandable that the calling command also includes the identity information of the virtual machine that issues the calling command, such as a virtual machine identifier, so that the issuer of the calling command can be determined.

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

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

[0154] It can be understood that, in combination with the foregoing, the calling command includes the identity information of the virtual machine that issues the calling 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 issues the calling command.

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

[0156] After determining the specific virtual key device, the security processor can call the corresponding physical key based on the key identifier in the calling command.

[0157] When the virtual key device directly indicates its configured physical key using a physical key identifier, the call command includes the physical key identifier, thereby enabling the direct call of the corresponding physical key based on the physical key identifier. When the virtual key device identifies the physical key of the virtual key device using a mapping relationship between the virtual key identifier and the physical key identifier, the call command includes the virtual key identifier. Accordingly, the security processor can determine the physical key identifier in the virtual key device to which the virtual key identifier is mapped based on the virtual key identifier in the call command, and call the corresponding physical key based on the physical key identifier.

[0158] It is understood that before executing the call of the physical key, a virtual key device can be created and configured first. Figure 6 The figure shows an optional flow diagram of configuring a virtual key device. Before step S100, the computing device may further perform the following steps:

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

[0160] Step S300: configuring 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 step S300 and step S400 is not limited by the serial number. In some optional examples, step S300 and step S400 can be executed successively or simultaneously. When step S300 and step S400 are executed successively, either step can come first.

[0163] Next, the creation process of the virtual key device will be described in detail with reference to step S200. Figure 7 An optional creation flow chart of a virtual key device is shown, and the creation process of the 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 the sharing type and the number of keys.

[0166] Among them, the description about the sharing type and the number of keys can be referred to above, and the present invention will not be repeated here.

[0167] Step S220: The security processor determines attribute parameters of the virtual key device to be created based on the obtained virtual device creation request, where the attribute parameters include a sharing type and a key quantity;

[0168] After obtaining the virtual device creation request, the security processor may parse and determine the attribute parameters of the virtual key device to be created, so as to perform 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 corresponding resources for the virtual key device, that is, generating a virtual device identifier (vid) based on a virtual device creation request and performing corresponding configuration based on specific attribute parameters.

[0171] Specifically, refer to Figure 8 The optional flow chart of step S230 is shown, wherein step S230 creates a virtual key device corresponding to the attribute parameters, which may include:

[0172] Step S231: determining whether to allow the creation of a virtual key device based on the number of virtual key devices supported by the security processor and the number of existing virtual key devices;

[0173] Specifically, the number of virtual key devices supported by the security processor for creation (that is, the maximum number of virtual key devices supported by the security processor for creation) and the number of existing virtual key devices can be determined, and it can be further determined whether the number of virtual key devices supported by the security processor for creation is greater than the number of existing virtual key devices; if so, it indicates that the creation of the virtual key device 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 a maximum available key space for the virtual key device;

[0175] The maximum available key space is used to indicate the maximum number of keys that can be configured for the virtual key device. It is understandable 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] Among them, when configuring the physical key identifier, the corresponding physical key identifier is the physical key identifier corresponding to the idle physical key; when configuring the virtual key identifier, it can be the virtual key identifier configured by the security processor for the virtual key device, and the virtual key identifier is used to map to the physical key identifier.

[0177] In a specific example, based on the maximum available key space (that is, 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 can be used by the created virtual key device is 1 to P', where 1 to P' can be understood as the virtual key identifier range.

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

[0179] The sharing type includes exclusive or shared. If the sharing type is exclusive, it indicates that the virtual key device is exclusively used by the virtual machine. If the sharing type is shared, it indicates that the virtual key device is allowed to be shared by multiple virtual machines.

[0180] Next, the optional process of configuring the physical key for the virtual key device is described in detail with reference to step S300, wherein step S300 is executed by the security processor. Figure 9 In the optional flowchart of step S300 shown, the configuration process of the virtual key device includes:

[0181] Step S310: determining a physical key in the security processor that is marked as idle;

[0182] In which, the physical key in the embodiment of the present invention is configured with an occupation flag, and the occupation flag is used to indicate whether the physical key is idle or occupied. When the physical key is configured to the virtual key device, the occupation flag is configured as occupied; it can be understood that when the occupation flag of the physical key is idle, the virtual key device is allowed to configure the physical key, and when the occupation flag of the physical key is occupied, the virtual key device is prohibited from configuring the physical key.

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

[0184] Step S320: configuring the physical key marked as idle to the virtual key device;

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

[0186] Specifically, the security processor may call the physical key distribution interface to distribute a physical key entity to the virtual key device.

[0187] When the virtual key device configures the physical key only based 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 is further performed to mark the occupation status of the physical key as occupied 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 occupation state of the physical key as occupied, step S340 is further executed to associate the physical key with the virtual key by establishing a mapping relationship.

[0189] Step S330: configuring the occupation flag of the physical key configured to the virtual key device to be occupied.

[0190] By configuring the occupation flag of the physical key to be occupied, other virtual key devices are prevented from occupying the corresponding physical key.

[0191] When the 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 performed:

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

[0193] Among them, through the established mapping relationship, the corresponding physical key can be determined based on the virtual key identifier.

[0194] Next, the binding process of the virtual key device will be described in detail with reference to step S400. Figure 10 An optional binding process for a virtual key device is shown. The binding process for a 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 the virtual key device to a preset virtual machine. The virtual device binding request can be issued after the virtual key device is successfully created and a corresponding creation response message is obtained, thereby 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, so that the virtual key device to be bound can be determined.

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

[0199] After obtaining the virtual device binding request, the virtual key device to be bound may be determined based on parsing 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 state of the virtual key device to be bound.

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

[0202] The binding state of the virtual key device is configured to be bound, so that the exclusive virtual key device no longer allows other virtual machines to bind to it.

[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 unbound, shared and unbound, or shared and the bound virtual machine allows the virtual machine that issued the virtual device binding request to share, then the virtual key device supports binding. In a further example, if the virtual key device is further configured with a valid identifier for identifying whether the virtual key device is valid, then 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.

[0204] After the security processor configures the binding state of the virtual key device as bound, it may further send a binding success message to the host to notify the host that the corresponding binding relationship has been established.

[0205] It is understandable that in order to maximize the utilization of key resources, when the virtual key device is no longer used by the virtual machine (for example, the virtual machine is shut down or destroyed), the virtual key device can also be destroyed. The following is a detailed description of the destruction process of the virtual key device. Figure 11 An optional destruction process of a virtual key device is shown, and 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 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] Among them, 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] By releasing the physical key, available physical key resources are provided for other virtual key devices.

[0212] In an optional example, in an 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 occupation identifier of the physical key configured by the virtual key device to be idle.

[0213] In a further example, in an example in which the virtual key device indicates the physical key using a mapping relationship between a virtual key identifier and a physical key identifier, releasing the physical key occupied by the virtual key device may specifically include: releasing the mapping relationship between the virtual key identifier and the physical key identifier in the virtual key device, and configuring the occupation identifier of the physical key corresponding to the physical key identifier to be idle.

[0214] In a further example, before step S520, it may be further determined whether the virtual key device supports destruction. If so, step S520 is executed; if not, the destruction process is exited.

[0215] Whether the virtual key device supports destruction can be determined based on the sharing type and sharing status of the virtual key device. For example, an exclusive virtual key device supports destruction, while a shared virtual key device supports destruction only when all virtual machines bound to the virtual key device allow destruction. However, if any of the virtual machines bound to the virtual key device is in the state of using the virtual key device, destruction is not supported.

[0216] It is understandable that a virtual key device may include multiple key resources. Different key resources can implement corresponding data encryption and decryption for different data or in different scenarios. Accordingly, different key resources have different requirements. In some scenarios, some key resources in the virtual key device have the requirement of not being lost in case of power failure. The physical key with the requirement of not being lost in case of power failure is used as the backup key. Accordingly, reference Figure 12 An optional backup process for a virtual key device is shown. This process is applied to a security processor. The process of backing up the backup key in the virtual key device may include:

[0217] Step S600: determining a virtual key device bound to the virtual machine based on the obtained key backup request;

[0218] In which, 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; in which, in the key backup request, the key identifier used to indicate the key to be backed up is determined based on the key identifier type in the virtual machine, and accordingly, the key backup request can indicate the corresponding key to be backed up based on the virtual key identifier, or can indicate the corresponding key to be backed up based on 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 a key ciphertext;

[0220] Among them, 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 backup key; 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 backup key.

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

[0222] In schemes where encryption keys are generated based on CPU confidential information, the encryption key can be generated based on the CPU's unique confidential information, such as by directly deriving it from the CPU's unique confidential ID (identifier) ​​or by using a digest value to generate a unique key for that CPU. Because encryption keys are generated using information unique to each CPU, the corresponding encryption keys are the same for different virtual machines running on the same machine. In other words, the key ciphertext backed up by a virtual machine corresponding to the same machine can be restored in other virtual machines on the same machine, but not in other machines.

[0223] In a scheme where the encryption key is generated based on the user password, the encryption key can be derived based on the user password or generated through a digest value, etc. Therefore, the encryption key can be generated by obtaining the user password. Correspondingly, any virtual machine can recover the key ciphertext by obtaining the user password.

[0224] In a solution where the encryption key is generated based on a combination of CPU information and a user password, the encryption key can ensure that the correct encryption key can be obtained and the key ciphertext can be recovered only in a virtual machine corresponding to the same CPU and knowing the user password. This solution can isolate different CPUs and isolate the same CPU by the user password.

[0225] It should be noted that, in order to ensure the security of key data, after the backup key is encrypted, the key ciphertext can also be integrity protected.

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

[0227] It should be noted that in some examples, key ciphertext is typically stored in the security processor's non-volatile cache. However, given the limited resources of the security processor's non-volatile cache, allocating corresponding non-volatile caches for key backup to multiple virtual machines created on a physical host can significantly increase the non-volatile cache usage. Therefore, storing the key ciphertext of powered-off virtual machines in the file system can improve the efficiency of the security processor's non-volatile cache.

[0228] When backup and recovery are required, the key ciphertext can be decrypted and loaded into the slot where the physical key of the virtual key device bound to the virtual machine is located. In the example with integrity protection, integrity verification is performed before decrypting the key ciphertext. After verification is passed, the key ciphertext is decrypted.

[0229] In a scenario where virtual machine migration is supported, the virtual machine can be migrated from the source device to the target device. Accordingly, based on the binding characteristics of the virtual machine and the virtual key device, the virtual key device can also be migrated from the source device to the target device. Figure 13An optional migration process of a virtual key device is shown, 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 device and the target device are used for auxiliary functions such as data exchange and resource request, and the security processors of the source device and the target device are used for specific implementation of the migration. Specifically, the migration process of the virtual key device includes:

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

[0231] The target device's device certificate is requested to authenticate the target device and encrypt the migration data based on the public key in the device certificate. Upon receiving the request, the target device's security processor can issue the device certificate. This allows the source device's host to obtain the device certificate and generate a migration key request based on the device certificate. The source device's security processor then executes the migration process based on the 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 obtained migration key request;

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

[0234] The key migration request may include the target device's device certificate, which includes the device public key. The device public key is used to encrypt the subsequently generated temporary key. The keys corresponding to the device certificate (the device public key and the device private key) may be an asymmetric key pair. The device private key may 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 for proving 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 to perform key encryption before key migration.

[0236] Based on the permission information and sharing information, etc., it can be determined whether the virtual key device supports migration. For example, if a virtual key device is shared by multiple virtual machines and only one of its bound virtual machines is migrated, the corresponding virtual key device does not support migration. However, a virtual key device shared by one virtual machine or exclusively owned by one 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 a key ciphertext.

[0238] The temporary key may be a symmetric key used to encrypt and integrity-protect the physical key configured in the virtual key device to generate a key ciphertext. The physical key configured in the virtual key device to be migrated may also be referred to as a key to be migrated.

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

[0240] The temporary public key is encrypted based on the device public key, so that the target device can decrypt the temporary key ciphertext based on the device private key to obtain the temporary key, and then decrypt the key data in the physical key of the virtual key device based on the temporary key.

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

[0242] The migration permission message indicates that the source device has completed preparations for key migration, thereby notifying the target device to determine whether to receive the data to be migrated to implement 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 the temporary key ciphertext may be migrated together with the data to be migrated in the virtual machine (also referred to 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 issues a migration acceptance request, so that the target device's security processing determines whether to receive the data to be migrated based on the migration acceptance request. For example, this may include determining whether a virtual key device that meets migration conditions exists in the target device, where the migration conditions may include the virtual key device being available and allocable, and the number of keys within the virtual key device 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 deemed to have received 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 meeting the migration conditions exists, a virtual key device meeting the migration conditions can be created, thereby ensuring that the target device receives the data to be migrated. It should be noted that if no virtual key device meeting the migration conditions can be obtained, it is determined that the target device does not receive the data to be migrated. Accordingly, the host of the target device returns a migration status to the source device, indicating that the migration has failed.

[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 may 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 the target security processor therein (i.e., the security processor within the target device), and the target security processor decrypts the temporary key ciphertext based on the device 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, and after integrity verification, loads the key data 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 may return a migration status to the source device, indicating that the key data of the data to be migrated (ie, key data) has been successfully migrated.

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

[0253] An embodiment of the present invention further provides a computing device, which may include the above-mentioned security processor.

[0254] An embodiment of the present invention also provides a computer program comprising one or more computer executable instructions, which, when executed, implement the key calling method, or the key backup method, or the key migration method.

[0255] The above describes multiple embodiment schemes provided by the embodiments of the present invention. The various optional methods introduced in each embodiment scheme can be combined and cross-referenced with each other without conflict, thereby extending a variety of possible embodiment schemes, which can all be considered as embodiment schemes disclosed and open in the embodiments of the present invention.

[0256] Although the embodiments of the present invention are disclosed above, the present application is not limited thereto. Any person skilled in the art may make various changes and modifications without departing from the spirit and scope of the present application. Therefore, the scope of protection of the present application shall be subject to the scope defined by the claims.

Claims

1. A security processor, characterized in that: include: A virtual key device, used to configure at least one physical key and to bind to a virtual machine; A command parsing module, used to determine a virtual key device bound to the virtual machine based on the acquired calling command of the virtual machine; The key calling module is used to call the physical key indicated by the calling command from the determined virtual key device.

2. The security processor according to claim 1, characterized in that: Also includes: A virtual device configuration module, used to configure a physical key for the virtual key device; The physical key is configured with an occupation flag, and the occupation flag is used to indicate whether the physical key is idle or occupied. When the physical key is configured to the virtual key device, the occupation flag is configured as occupied; wherein, when the occupation flag of the physical key is idle, the virtual key device is allowed to configure the physical key, and when the occupation 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 key device indicates the physical key configured therein based on the virtual key identifier and the physical key identifier, wherein the virtual key identifier is mapped to the physical key identifier of the physical key; The virtual device configuration module is used to configure a physical key for the virtual key device, including establishing a mapping relationship between a virtual key identifier in the virtual key device and a physical key identifier of the configured physical key; The key calling module is used to call the physical key indicated by the calling command from the determined virtual key device, specifically, based on the virtual key identifier in the calling command, determine the physical key identifier mapped by the virtual key identifier in the virtual key device, and call the corresponding physical key based on the physical key identifier.

4. The security processor according to claim 2, characterized in that: The virtual device configuration module is used to configure a physical key for the virtual key device, specifically: Before binding the virtual key device to the virtual machine, configuring a physical key for the virtual key device; or, After the virtual key device is bound to the virtual machine, a physical key is configured for the virtual key device based on the acquired 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 is bound 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 acquired calling command of the virtual machine, specifically, to determine the virtual device identifier of the virtual key device based on the virtual machine that issues the calling command.

6. The security processor according to claim 1, characterized in that: The command parsing module is further used to: determine the virtual key device to be destroyed based on the acquired virtual device destruction command; The security processor further includes: a virtual device destruction module, configured 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, and the virtual device destruction module is used to release the physical key occupied by the virtual key device, specifically: configuring the occupation identifier of the physical key configured by the virtual key device to be idle; The virtual key device indicates the physical key with a mapping relationship between a virtual key identifier and a physical key identifier. The virtual device destruction module is used to release the physical key occupied by the virtual key device, including: releasing the mapping relationship between the virtual key identifier and the physical key identifier in the virtual key device; and configuring the occupation identifier of the physical key corresponding to the physical key identifier to be idle.

8. The security processor according to claim 1, characterized in that: The command parsing module is further used to: determine attribute parameters of the virtual key device to be created based on the acquired virtual device creation request, wherein the attribute parameters include a sharing type and a key quantity; The security processor also includes: a virtual device creation module, which is used to create 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: Determining whether to allow the creation of a virtual key device based on the number of virtual key devices supported by the security processor and the number of existing virtual key devices; If so, generating a virtual device identifier corresponding to the virtual key device, and configuring a maximum available key space for the virtual key device; Based on the virtual device identifier, the sharing type of the virtual key device is configured, the sharing type including exclusive or shared, wherein the sharing type of exclusive indicates that the virtual key device is exclusively used by the virtual machine, and the sharing type of shared 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 further 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 is used to record the corresponding relationship between the virtual key device and the virtual machine based on the virtual device identifier when the virtual key device supports binding, and configure the binding state of the virtual key device to be bound.

11. A key calling method, characterized in that: Applied to a security processor, wherein a virtual key device is configured in the security processor, and the virtual key device is used to configure at least one physical key and is used to bind to a virtual machine, including: Get the calling command of the virtual machine; Determine a virtual key device bound to the virtual machine based on the acquired calling command of the virtual machine; The physical key indicated by the calling command is called from the determined virtual key device.

12. The key calling method according to claim 11, characterized in that: Before obtaining the calling command of the virtual machine, the method further includes: Before binding the virtual key device to the virtual machine, configuring a physical key for the virtual key device; or, After the virtual key device is bound to the virtual machine, a physical key is configured for the virtual key device.

13. The key calling method according to claim 12, characterized in that: The physical key is configured with an occupation mark, and the configuring the physical key for the virtual key device includes: Determine a physical key in a security processor that is marked as idle; configuring the physical key whose occupation mark is idle to the virtual key device; The occupation flag of the physical key configured to the virtual key device is configured as occupied.

14. The key calling method according to claim 12, characterized in that: The configuring a physical key for the virtual key device further includes: establishing a mapping relationship between a virtual key identifier in the virtual key device and a physical key identifier of the configured physical key; The self-determined virtual key device calls the physical key indicated by the calling command, specifically, based on the virtual key identifier in the calling command, determines the physical key identifier mapped by the virtual key identifier in the virtual key device, and calls the corresponding physical key based on the physical key identifier.

15. The key calling method according to claim 11, characterized in that: Before obtaining the calling command of the virtual machine, the method further includes: Create a virtual key device; A maximum available key space is configured for the virtual key device, and the virtual key device is bound to a virtual machine.

16. The key calling method according to claim 15, characterized in that: The step of creating a virtual key device comprises: Determine attribute parameters of a virtual key device to be created based on the acquired virtual device creation request, wherein the attribute parameters include a sharing type and a key quantity; A virtual key device corresponding to the attribute parameters is created.

17. The key calling method according to claim 16, characterized in that: The step of creating a virtual key device corresponding to the attribute parameter comprises: Determining whether to allow the creation of a virtual key device based on the number of virtual key devices supported by the security processor and the number of existing virtual key devices; If so, generating a virtual device identifier corresponding to the virtual key device, and configuring a maximum available key space for the virtual key device; Based on the virtual device identifier, the sharing type of the virtual key device is configured, the sharing type including exclusive or shared, wherein the sharing type of exclusive indicates that the virtual key device is exclusively used by the virtual machine, and the sharing type of shared indicates that the virtual key device is allowed to be shared by multiple virtual machines.

18. The key calling method according to claim 15, characterized in that: The step of binding the virtual key device to the virtual machine includes: Determining a virtual key device to be bound based on the obtained virtual device binding request; When the virtual key device supports binding, the corresponding relationship between the virtual key device and the virtual machine is recorded based on the virtual device identifier, and the binding state of the virtual key device is configured to be bound.

19. The key calling method according to claim 11, characterized in that: Also includes: Determining the virtual key device to be destroyed based on the acquired virtual device destruction command; The physical key occupied by the virtual key device indicated by the virtual device destruction command is released.

20. The key calling method according to claim 19, characterized in that: The virtual key device indicates the physical key with a physical key identifier, and the releasing of the physical key occupied by the virtual key device is specifically: configuring the occupation identifier of the physical key configured by the virtual key device to be idle; The virtual key device indicates the physical key with a mapping relationship between a virtual key identifier and a physical key identifier, and releasing the physical key occupied by the virtual key device includes: releasing the mapping relationship between the virtual key identifier and the physical key identifier in the virtual key device; and configuring the occupation identifier of the physical key corresponding to the physical key identifier to be idle.

21. A key backup method, characterized in that: Applied to a security processor, wherein a virtual key device is configured in the security processor, and the virtual key device is used to configure at least one physical key and is used to bind to a virtual machine, including: Determining a virtual key device bound to the virtual machine based on the obtained key backup request, wherein the key backup request is used to indicate a key to be backed up; Encrypting the key to be backed up in the virtual key device indicated by the key backup request to generate a key ciphertext; The key ciphertext is stored in 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 of the source device is applied, wherein the security processor is configured with a virtual key device, and the virtual key device is used to configure at least one physical key and is used to bind to a virtual machine, including: Determining whether the virtual key device to be migrated supports migration based on the obtained key migration request, wherein the key migration request includes a 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 a key ciphertext; The temporary key is encrypted based on the device public key to generate a temporary key ciphertext, so that 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.

23. A key migration method, characterized in that: When the source device migrates the virtual key device to the target device, a security processor of the target device is applied, wherein the security processor is configured with the virtual key device, and the virtual key device is used to configure at least one physical key and is used to bind to the virtual machine, including: Sending a device certificate so that the source device generates a migration key request based on the device certificate, wherein the device certificate includes a device public key; Based on the obtained received migration request, determining whether to receive data to be migrated, the data to be migrated being generated based on a 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 the virtual key device that meets the migration conditions.

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

25. A computer program, characterized in that It comprises one or more computer executable instructions, which, when executed, implement the key calling method as described in any one of claims 11 to 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 to 23.

Images