A migration method for virtual trusted roots under a dual-architecture approach

Abstract

This invention discloses a method for migrating a virtual root of trust (vTPCM) under a dual-architecture system, comprising three parts: S1: vTPCM key tree establishment; S2: vTPCM instance management; and S3: vTPCM migration. In a dual-architecture trusted computing environment, multiple virtual roots of trust (vTPCMs) can be virtualized based on the hardware root of trust (TPCM). The virtualization components of the TPCM are installed on the protection component. This invention establishes a vTPCM key tree based on the TCM key system, facilitating the management of vTPCM keys and enabling secure migration of vTPCM instances. The virtual root of trust migration method described in this invention includes core vTPCM components, including a vTPCM migration module, a remote authentication module, and a vTPCM instance management module, all deployed on the protection component. This effectively prevents external attacks, providing security, practicality, and facilitating the migration of vTPCM instances.

Description

Technical Field

[0001] This invention relates to the field of information security, and specifically to a method for migrating a virtual root of trust under a dual-architecture system. Background Technology

[0002] Trusted computing is a widely used trusted computing platform in computing systems, supported by hardware security modules, to improve the overall security of the system. The basic process of building a trusted computing system is to establish a trust chain based on a root of trust, from the hardware platform and operating system to the application. On this trust chain, starting from the root, each level measures and authenticates the next, and trusts the next level, thereby achieving the gradual expansion and transmission of trust at each level, thus building a secure and trusted computing environment.

[0003] Trusted computing has now evolved into Trusted 3.0, which is the proactive immunity stage. The core of Trusted Computing 3.0 theory is a dual-system architecture that combines computing and protection, forming a proactive immunity dual-system defense architecture that integrates computing and security protection through a combination of hardware and software.

[0004] The Trusted Computing 3.0 architecture comprises a computing component and a protection component. In this architecture, the protection component uses TPCM as the root of trust, starts before the computing component, and proactively measures and controls the computing component. The protection component can proactively access all resources of the computing component, while the computing component cannot access the resources of the protection component. The two can only interact through a dedicated secure channel. While providing trusted protection, the protection component does not interfere with the application, ensuring the correct completion of computing tasks and the integrity of the process.

[0005] Building a trusted computing system in a cloud environment requires extending the trust chain to the virtual machine manager and virtual machines. A virtual root of trust and supporting virtualization components are built on a trusted cloud server, thereby constructing a vTPCM to measure and control the behavior of virtual machines.

[0006] Virtual machines (VMs) have migration capabilities in traditional business scenarios, but in trusted computing systems, the migration capability of VM roots of trust also needs to be added. Compared to VM migration, migrating VM roots of trust in a cloud environment requires migrating data such as keys within the VM root instance, making the migration process more complex. Therefore, a secure and efficient method for migrating VM roots of trust needs to be proposed.

[0007] CN111125706A, entitled "A Trusted Middleware for a Cloud Platform," provides a trusted middleware for a cloud platform, comprising: a virtual trusted component, which includes a virtual root of trust and a virtual root of trust management module. The virtual root of trust is configured to extend the trust chain to virtual machines and provide root of trust services to the virtual machines; a trusted proxy, which includes a platform trusted proxy and a virtual machine trusted proxy, configured to measure relevant core programs and files at startup and detect the integrity of hardware and the system; and a trusted management end, which receives measurement reports and detection results sent by the trusted proxy and, upon detecting a change in the trusted state of the platform and / or the virtual machine, pushes the current trusted state to a virtualization software management end configured with the virtual root of trust management module. This invention extends the trust chain to virtual machines, providing tenants with virtual machines that offer trusted computing services. The virtual root of trust in this invention is implemented using vTPM, and the virtual root of trust migration module synchronously migrates the virtual root of trust-related data of the virtual machine to the destination during virtual machine migration. This invention only describes the establishment of a secure channel for migrating virtual root of trust data, without addressing the authentication of the migrating platforms or the protection of the migration data's integrity. Furthermore, this invention only applies to migrations where the virtual root of trust is implemented using software virtualization, not hardware virtualization, and cannot handle virtual root of trust migration scenarios in dual-architecture environments.

[0008] The patent CN109783474A, titled "Secure Migration Method for Virtual Trusted Root Instance and Its Own State Data," is characterized by the following: regardless of whether the migration is initiated by a control node or requested by a compute node, the vTPCM instance and its own state data are encrypted and packaged using an encryption algorithm before being sent to a compute node designated by the control node. This compute node has the same or similar functions, sufficient memory space, and is migrated over a network from a compute node called the source platform to a compute node called the target platform under the control of the control node. This invention uses a virtualization architecture based on a Trusted Platform Control Module (TPCM) and KVM. Compared to a virtualization architecture using a Trusted Platform Module (TPM) and Xen, it has the advantage of not needing to recompile the entire operating system kernel when updating the virtual machine monitor, while also ensuring the security of the migrated data. However, this method lacks secure key migration during the migration of the virtual trusted root instance. Summary of the Invention

[0009] This invention proposes a migration method for virtual roots of trust (vTPCMs) in a dual-architecture environment based on a hardware-implemented vTPCM. In a dual-architecture trusted computing environment, multiple virtual roots of trust (vTPCMs) can be virtualized based on the hardware-implemented TPCM. The virtualization components of the TPCM are installed on the protection component. This invention designs a secure and efficient virtual root of trust migration method for this scenario. This invention establishes a vTPCM key tree based on the TCM key system, facilitating the management of vTPCM keys and enabling secure migration of vTPCM instances.

[0010] The solution of this invention is based on the migration of virtual trusted roots under a dual-architecture system. This solution mainly includes three parts:

[0011] S1: vTPCM Key Tree Establishment. TCM keys are divided into four groups based on the user's identity: for platform manufacturers, for users, for privacy-sensitive applications, and for temporary needs. Each group has a key seed, which is a large number and will never be leaked outside its security boundaries. TCM uses these key roots to create a master key, and then creates various other keys under the master key. Except for the master key, all other keys are encrypted and protected by their parent keys. TCM key migration is achieved through copy and import commands, and the key copying properties are mainly determined by `fixedTCM` and `fixedParent`, resulting in the following four scenarios:

[0012] 1) `fixedTCM` is true, `fixedParent` is false: This is not allowed. A key with `fixedTCM` true cannot be copied. A `fixedParent` false key indicates that the key can be moved to another parent key and may be migrated with the new parent key, contradicting the function of `fixedTCM` being true. TCM checks `fixedTCM` and `fixedParent` and does not allow this inconsistency.

[0013] 2) fixedTCM and fixedParent are true: Define an object that cannot be copied.

[0014] 3) `fixedTCM` is false, `fixedParent` is true: This indicates that a key cannot be directly copied. It is bound to a parent key. However, if the ancestor key is copied, this key will naturally move with it.

[0015] 4) If both fixedTCM and fixedParent are false, it means the key can be directly copied. If it is a parent key copying root, its child keys will be moved accordingly.

[0016] The following vTPCM key tree can be built based on the key replication attributes to facilitate vTPCM key management:

[0017] 1) Generate a primary key Primary_Key based on the root key. Under the primary key Primary_Key, generate a key Parents_vTPCM as the parent key of all vTPCM root keys. Its attributes are set to fixTCM and fixedParent are true.

[0018] 2) Then generate vTPCM1_R, vTPCM2_R and other keys under Parents_vTPCM as the root keys of each vTPCM, and set their attributes to false fixedTCM and false fixedParent;

[0019] 3) Subkeys such as vTPCM1_Key1 and vTPCM1_Key2 generated by vTPCM1_R are used for encryption and decryption functions of their respective vTPCMs.

[0020] When migrating a vTPCM key, only the vTPCM1_R level key needs to be copied and imported; the child keys under it only need to be transferred.

[0021] S2: vTPCM Instance Management. A vTPCM instance contains vTPCM key data, trusted boot baseline data, and virtual PCR values. After deployment, vTPCM initializes and creates a mapping table to manage the correspondence between virtual machines and vTPCM instances. Throughout the virtual machine lifecycle, including creation, startup, migration, and destruction, vTPCM instances are managed accordingly.

[0022] S3: vTPCM Migration. Before migrating the virtual machine, the vTPCM instance is migrated first. After both migration platforms call the remote authentication module for remote authentication, they call the vTPCM migration module for key negotiation, establishing an encrypted channel using the negotiated key. The source platform packages the vTPCM instance, including key data, and sends it to the target platform via the encrypted channel. After the target platform's vTPCM migration module verifies the data integrity, it loads the vTPCM instance after the virtual machine migration is complete and notifies the source platform to destroy the source platform's vTPCM instance.

[0023] This invention is based on a trusted computing platform deployment environment employing a dual-architecture design. The computing component environment is a Linux operating system, while the protection component deploys a hardware TPCM. Most of the vTPCM components virtualized by the TPCM are deployed on the protection component side. The primary application scenario for this invention is a trusted computing platform with a dual-architecture design. The specific implementation includes the following processes.

[0024] Process 1: Initialization phase.

[0025] The vTPCM component is deployed before the first virtual machine on the platform is created. After deployment, the vTPCM instance management module first initializes, creates a mapping table to manage various data of the vTPCM instance, then creates the root key and the key Parents_vTPCM, and stores the key context. When the virtual machine is created, the vTPCM instance management module creates the vTPCM instance, associates it with the virtual machine's UUID, calculates the baseline value, creates the vTPCM root key, and stores the vTPCM instance data, including the baseline value, vPCR value, and the vTPCM root key context.

[0026] Process 2: vTPCM Migration. The main steps of vTPCM migration are as follows:

[0027] 1) The source platform sends a virtual machine migration command to trigger the vTPCM migration module. After the vTPCM migration is completed, the virtual machine migration is then performed.

[0028] 2) The vTPCM migration modules of the source platform and the target platform collaborate with a trusted third party to complete two-way remote authentication between the source platform and the target platform;

[0029] 3) After the remote verification is completed, the source platform vTPCM migration module and the target platform vTPCM migration module establish a secure transmission channel. Both parties call the hardware TCM to negotiate the key. The specific negotiation process is as follows;

[0030] The source platform and the target platform respectively call the TCM command to create a master key to generate a pair of elliptic curve keys. The elliptic curve adopts ECC_SM2_P256 and this key is used as a static key.

[0031] The source platform and the target platform each call the TCM key exchange protocol temporary key generation command ecephemeral to generate a pair of elliptic curve keys as temporary keys. The elliptic curve adopts ECC_SM2_P256.

[0032] The source platform and the target platform each send the public key of their static key and the public key of their temporary key to each other;

[0033] The vTPCM migration module of the source platform and the target platform calls the TCM two-stage key negotiation command zgen2phase to negotiate a shared secret Z based on the two public keys sent by the other party and its own two private keys. The shared secret is an elliptic curve point, and the shared secret negotiated by both parties will be the same.

[0034] The source and target platforms use the KDF function to expand Z into a 128-bit SM4 key, which will be used for encryption and decryption during subsequent migrations.

[0035] 4) The target platform sends its Parents_vTPCM public key to the source platform via an encrypted channel.

[0036] 5) The source platform vTPCM migration module loads the public key of Parents_vTPCM, copies the key to be migrated to this key, and then packages the data returned by the TCM copy command and the vTPCM instance together, adds the HMAC encrypted hash value to the end and sends them to the target platform. The HMAC uses the SM3 HASH algorithm and the negotiated encrypted channel key.

[0037] 6) The source platform vTPCM migration module transfers the vTPCM migration instance files to the target platform via a secure channel;

[0038] 7) After the target platform vTPCM verifies the data integrity, it imports the vTPCM key through the TCM import command, and then loads the public and private key data returned by the import command into the context of the new vTPCM root key under Parents_vTPCM through the TCM load key command; the vTPCM instance management module then stores the context of the vTPCM root key and other instance data.

[0039] 8) Perform virtual machine migration between the target platform and the source platform;

[0040] 9) After the migration is complete, the vTPCM instance management module establishes the association between the virtual machine and the vTPCM instance; the target platform then sends a message to the source platform that the virtual machine migration is complete, and the source platform deletes the virtual machine and the vTPCM instance.

[0041] Compared with existing technologies, the virtual root of trust migration described in this invention includes core vTPCM components such as the vTPCM migration module, remote authentication module, and vTPCM instance management module, all of which are deployed in the protection component, effectively preventing external attacks and possessing security and practicality.

[0042] This invention establishes a key tree for vTPCM based on hardware TCM, effectively manages vTPCM keys, and facilitates the migration of vTPCM instances. Attached Figure Description

[0043] Figure 1 This is a vTPCM key tree based on TCM key attributes.

[0044] Figure 2 This is a diagram of a virtual trusted root migration architecture based on a dual-system architecture.

[0045] Figure 3 This is a flowchart of the virtual trusted root migration process based on a dual-architecture system. Detailed Implementation

[0046] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0047] The solution of this invention is based on the migration of virtual trusted roots under a dual-architecture system. This solution mainly includes three parts:

[0048] Part 1: vTPCM Key Tree Establishment. TCM keys are divided into four groups based on the user's identity: for platform manufacturers, for users, for privacy-sensitive applications, and for temporary needs. Each group has a key seed, which is a large number and will never be leaked outside its security boundaries. TCM uses these key roots to create a master key, and then creates various other keys under the master key. Except for the master key, all other keys are encrypted and protected by their parent keys. TCM key migration is achieved through copy and import commands, and the key copying properties are mainly determined by `fixedTCM` and `fixedParent`, resulting in the following four scenarios:

[0049] 1. `fixedTCM` is true, `fixedParent` is false: This is not allowed. A key with `fixedTCM` true cannot be copied. A `fixedParent` false key indicates that the key can be moved to another parent key and may be migrated with the new parent key, contradicting the function of `fixedTCM` being true. TCM checks `fixedTCM` and `fixedParent` and does not allow this inconsistency.

[0050] 2. `fixedTCM` and `fixedParent` being true: Defines an object that cannot be copied.

[0051] 3. `fixedTCM` is false, `fixedParent` is true: This indicates that a key cannot be directly copied. It is bound to a parent key. However, if the ancestor key is copied, this key will naturally move with it.

[0052] 4. If both `fixedTCM` and `fixedParent` are false, it means the key can be directly copied. If it is a parent key copying root, its child keys will be moved accordingly.

[0053] The following vTPCM key tree can be built based on the key replication attributes to facilitate vTPCM key management:

[0054] 1. Generate a primary key Primary_Key based on the root key. Under the primary key Primary_Key, generate a key Parents_vTPCM as the parent key of all vTPCM root keys. Its attributes are set to fixTCM and fixedParent are true.

[0055] 2. Then, generate vTPCM1_R, vTPCM2_R, etc. under Parents_vTPCM as the root key for each vTPCM, and set their attributes to false for fixedTCM and false for fixedParent;

[0056] 3. Subkeys such as vTPCM1_Key1 and vTPCM1_Key2 generated by vTPCM1_R are used for encryption and decryption functions of their respective vTPCMs.

[0057] When migrating a vTPCM key, only the vTPCM1_R level key needs to be copied and imported; the child keys under it only need to be transferred.

[0058] Part Two: vTPCM Instance Management. A vTPCM instance contains vTPCM key data, trusted boot baseline data, and virtual PCR values. After deployment, vTPCM initializes and creates a mapping table to manage the correspondence between virtual machines and vTPCM instances. Throughout the virtual machine lifecycle, including creation, startup, migration, and destruction, vTPCM instances are managed accordingly.

[0059] Part 3: vTPCM Migration. Before migrating the virtual machine, the vTPCM instance must be migrated first. Both migration platforms call the remote authentication module for remote authentication, and then call the vTPCM migration module for key negotiation, establishing an encrypted channel using the negotiated key. The source platform packages the vTPCM instance, including key data, and sends it to the target platform via the encrypted channel. After verifying data integrity, the target platform's vTPCM migration module loads the vTPCM instance after the virtual machine migration is complete and notifies the source platform to destroy the source platform's vTPCM instance.

[0060] This invention is based on a trusted computing platform deployment environment employing a dual-architecture design. The computing component environment is a Linux operating system, while the protection component deploys a hardware TPCM. Most of the vTPCM components virtualized by the TPCM are deployed on the protection component side. The primary application scenario for this invention is a trusted computing platform with a dual-architecture design. The specific implementation includes the following processes.

[0061] Process 1: Initialization phase.

[0062] The vTPCM component is deployed before the first virtual machine on the platform is created. After deployment, the vTPCM instance management module first initializes, creates a mapping table to manage various data of the vTPCM instance, then creates the root key and the key Parents_vTPCM, and stores the key context. When the virtual machine is created, the vTPCM instance management module creates the vTPCM instance, associates it with the virtual machine's UUID, calculates the baseline value, creates the vTPCM root key, and stores the vTPCM instance data, including the baseline value, vPCR value, and the vTPCM root key context.

[0063] Process 2: vTPCM Migration. The main steps of vTPCM migration are as follows:

[0064] 1) The source platform sends a virtual machine migration command to trigger the vTPCM migration module. After the vTPCM migration is completed, the virtual machine migration is then performed.

[0065] 2) The vTPCM migration modules of the source platform and the target platform collaborate with a trusted third party to complete two-way remote authentication between the source platform and the target platform;

[0066] 3) After the remote verification is completed, the source platform vTPCM migration module and the target platform vTPCM migration module establish a secure transmission channel. Both parties call the hardware TCM to negotiate the key. The specific negotiation process is as follows;

[0067] • The source platform and the target platform respectively call the TCM command to create a master key to generate a pair of elliptic curve keys. The elliptic curve adopts ECC_SM2_P256 and the key is used as a static key.

[0068] • The source platform and the target platform each call the TCM key exchange protocol temporary key generation command ecephemeral to generate a pair of elliptic curve keys as temporary keys. The elliptic curve adopts ECC_SM2_P256.

[0069] ● The source platform and the target platform each send the public key of their static key and the public key of their temporary key to each other;

[0070] ●The vTPCM migration module of the source platform and the target platform calls the TCM two-stage key negotiation command zgen2phase to negotiate a shared secret Z based on the two public keys sent by the other party and its own two private keys. The shared secret is an elliptic curve point, and the shared secrets negotiated by both parties will be the same.

[0071] ● The source and target platforms use the KDF function to expand Z into a 128-bit SM4 key, which will be used for encryption and decryption during subsequent migrations.

[0072] 4) The target platform sends its Parents_vTPCM public key to the source platform via an encrypted channel.

[0073] 5) The source platform vTPCM migration module loads the public key of Parents_vTPCM, copies the key to be migrated to this key, and then packages the data returned by the TCM copy command and the vTPCM instance together, adds the HMAC encrypted hash value to the end and sends them to the target platform. The HMAC uses the SM3 HASH algorithm and the negotiated encrypted channel key.

[0074] 6) The source platform vTPCM migration module transfers the vTPCM migration instance files to the target platform via a secure channel;

[0075] 7) After the target platform vTPCM verifies the data integrity, it imports the vTPCM key through the TCM import command, and then loads the public and private key data returned by the import command into the context of the new vTPCM root key under Parents_vTPCM through the TCM load key command; the vTPCM instance management module then stores the context of the vTPCM root key and other instance data.

[0076] 8) Perform virtual machine migration between the target platform and the source platform;

[0077] 9) After the migration is complete, the vTPCM instance management module establishes the association between the virtual machine and the vTPCM instance; the target platform then sends a message to the source platform that the virtual machine migration is complete, and the source platform deletes the virtual machine and the vTPCM instance.

[0078] Compared with existing technologies, the virtual root of trust migration described in this invention includes core vTPCM components such as the vTPCM migration module, remote authentication module, and vTPCM instance management module, all of which are deployed in the protection component, effectively preventing external attacks and possessing security and practicality.

[0079] This invention establishes a key tree for vTPCM based on hardware TCM, effectively manages vTPCM keys, and facilitates the migration of vTPCM instances.

Claims

1. A migration method for virtual trusted roots under a dual-architecture system, characterized in that, It includes three parts: S1: vTPCM key tree establishment; TCM keys are divided into four groups based on the user identity: for platform manufacturers, for users, for privacy-sensitive applications, and for temporary needs; each group has a key seed, and TCM uses these key seeds to create a master key, and then creates various keys under the master key; except for the master key, all other keys are encrypted and protected by their parent key. S2: vTPCM instance management; a vTPCM instance contains vTPCM key data, trusted boot baseline value data, and virtual PCR value; after the vTPCM component is deployed, vTPCM is first initialized and a mapping table is created to manage the correspondence between virtual machines and vTPCM instances; at each stage of the virtual machine lifecycle, including creation, startup, migration, and destruction, the vTPCM instance is managed accordingly. S3: vTPCM migration; Before migrating the virtual machine, the vTPCM instance is migrated first. After both platforms call the remote authentication module to perform remote authentication, they call the vTPCM migration module to perform key negotiation and establish an encrypted channel using the key negotiated key. The source platform will package the vTPCM instance, including key data, and send it to the target platform via an encrypted channel. After the target platform vTPCM migration module verifies the data integrity, it loads the vTPCM instance after the virtual machine migration is complete and notifies the source platform to destroy the source platform vTPCM instance.

2. The migration method for a virtual trusted root under a dual-architecture system according to claim 1, characterized in that, TCM key migration is achieved through copy and import commands, and the key copy attributes are determined by fixedTCM and fixedParent, resulting in the following four scenarios: 1) fixedTCM is true and fixedParent is false: This is not allowed; a key with fixedTCM true cannot be copied; fixedParent is false, indicating that the key can be moved to another parent key and may be migrated with the new parent key, which contradicts the function of fixedTCM being true; TCM will check fixedTCM and fixedParent and will not allow such inconsistencies. 2) `fixedTCM` and `fixedParent` being true: Defines an object that cannot be copied; 3) fixedTCM is false, fixedParent is true: This means that a key cannot be directly copied and is bound to a parent key; If the ancestor key is copied, the key will naturally move with it; 4) If fixedTCM is false and fixedParent is false, it means that the key can be directly copied; if it is a parent key copy root, its child keys will be moved accordingly.

3. The migration method for a virtual trusted root under a dual-architecture system according to claim 1, characterized in that, To facilitate vTPCM key management, the following vTPCM key tree is established based on the key replication attributes: 1) Generate a primary key Primary_Key based on the root key. Under the primary key Primary_Key, generate a key Parents_vTPCM as the parent key of all vTPCM root keys. Its attributes are set to fixTCM and fixedParent are true. 2) Then generate vTPCM1_R and vTPCM2_R keys under Parents_vTPCM as the root keys for each vTPCM, and set the attributes to false for fixedTCM and false for fixedParent; 3) The subkeys vTPCM1_Key1 and vTPCM1_Key2 generated by vTPCM1_R are used for encryption and decryption functions of their respective vTPCMs; When migrating a vTPCM key, only the vTPCM1_R level key needs to be copied and imported; the child keys under it only need to be transferred.

4. The migration method for a virtual trusted root under a dual-architecture system according to claim 1, characterized in that, Based on a trusted computing platform deployment environment with a dual-architecture approach, the computing component environment is a Linux operating system, the protection component deploys a hardware TPCM, and most of the vTPCM components virtualized by the TPCM are deployed on the protection component side; the application scenario is a trusted computing platform with a dual-architecture approach.

5. The migration method for a virtual trusted root under a dual-architecture system according to claim 4, characterized in that, The specific implementation of the trusted computing platform under the dual-architecture model includes the following processes; Process 1: Initialization phase; The vTPCM component is deployed before the first virtual machine on the platform is created. After the vTPCM component is deployed, the vTPCM instance management module first initializes, creates a mapping table to manage various data of the vTPCM instance, and then creates the root key and the key Parents_vTPCM, and stores the context of the key. When the virtual machine is created, the vTPCM instance management module creates the vTPCM instance, associates it with the virtual machine UUID, calculates the baseline value, creates the root key of vTPCM, and stores the vTPCM instance data, including the baseline value, vPCR value, and the context of the vTPCM root key. Process 2: vTPCM migration; The steps for implementing vTPCM migration are as follows: 1) The source platform sends a virtual machine migration command to trigger the vTPCM migration module. After the vTPCM migration is completed, the virtual machine migration is then performed. 2) The vTPCM migration modules of the source platform and the target platform collaborate with a trusted third party to complete two-way remote authentication between the source platform and the target platform; 3) After remote authentication is completed, the source platform vTPCM migration module and the target platform vTPCM migration module establish a secure transmission channel, and both parties call the hardware TCM to negotiate the key; 4) The target platform sends its Parents_vTPCM public key to the source platform via an encrypted channel; 5) The source platform vTPCM migration module loads the public key of Parents_vTPCM, copies the key to be migrated to this key, and then packages the data returned by the TCM copy command and the vTPCM instance together, adds the HMAC encrypted hash value to the end and sends them to the target platform. The HMAC uses the SM3 HASH algorithm and the negotiated encrypted channel key. 6) The source platform vTPCM migration module transfers the vTPCM migration instance files to the target platform via a secure channel; 7) After the target platform vTPCM verifies the data integrity, it imports the vTPCM key through the TCM import command, and then loads the public and private key data returned by the import command into the context of the new vTPCM root key under Parents_vTPCM through the TCM load key command; the vTPCM instance management module then stores the context of the vTPCM root key and other instance data. 8) Perform virtual machine migration between the target platform and the source platform; 9) After the migration is complete, the vTPCM instance management module establishes the association between the virtual machine and the vTPCM instance; the target platform then sends a message to the source platform that the virtual machine migration is complete, and the source platform deletes the virtual machine and the vTPCM instance.

6. The migration method for a virtual trusted root under a dual-architecture system according to claim 5, characterized in that, The specific process of key negotiation in hardware TCM is as follows; The source platform and the target platform respectively call the TCM command to create a master key to generate a pair of elliptic curve keys. The elliptic curve adopts ECC_SM2_P256 and this key is used as a static key. The source platform and the target platform each call the TCM key exchange protocol temporary key generation command ecephemeral to generate a pair of elliptic curve keys as temporary keys. The elliptic curve adopts ECC_SM2_P256. The source platform and the target platform each send the public key of their static key and the public key of their temporary key to each other; The vTPCM migration module of the source platform and the target platform calls the TCM two-stage key negotiation command zgen2phase to negotiate a shared secret Z based on the two public keys sent by the other party and its own two private keys. The shared secret is an elliptic curve point, and the shared secret negotiated by both parties will be the same. The source and target platforms use the KDF function to expand Z into a 128-bit SM4 key, which will be used for encryption and decryption during subsequent migrations.

Images