Migration method of virtual trusted root under dual-system architecture

Abstract

The invention discloses a virtual trusted root migration method under a dual-system architecture. The method comprises the following three parts: S1, establishing a vTPCM key tree; and S2, vTPCM instance management is carried out. And S3, carrying out vTPCM migration. In a dual-system architecture trusted computing environment, a plurality of virtual trusted roots (vTPCMs) can be virtualized based on hardware trusted roots (TPCMs), virtualization components of the TPCMs are installed on protection components, a key tree of the vTPCMs is established on the basis of a TCM key system, keys of the vTPCMs are convenient to manage, and safe migration of vTPCM instances is convenient. According to the migration of the virtual trusted root, core vTPCM components including a vTPCM migration module, a remote attestation module and a vTPCM instance management module are all deployed on a protection component, external attacks can be effectively avoided, safety and practicability are achieved, and migration of vTPCM instances is facilitated.

Description

Technical Field

[0001] The present invention relates to the field of information security, and in particular to a method for migrating a virtual trusted root under a dual system architecture. Background Art

[0002] Trusted computing is the widespread use of trusted computing platforms supported by hardware security modules in computing systems to improve the overall security of the system. The basic process of building a trusted computing system is to establish a trust chain from the hardware platform, operating system to the application based on a trusted root. On this trust chain, the trust chain is measured and authenticated from the root level to the next level, and the trust level is trusted level by level, so as to achieve the step-by-step expansion and transfer of trust, thereby building a secure and trusted computing environment.

[0003] Trusted computing has now developed into Trusted 3.0, the active immunity stage. The core of Trusted Computing 3.0 theory is a dual-system architecture where computing and protection coexist. Through the combination of software and hardware, an active immune dual-system defense architecture with computing and security protection in parallel is formed.

[0004] The Trusted Computing 3.0 architecture includes computing components and protection components. In this architecture, the protection component uses TPCM as the trusted root, starts before the computing component, and actively measures and controls the computing component; the protection component can actively access all resources of the computing component, while the computing component cannot access the resources of the protection component. The two parties can only interact through a dedicated secure channel. While providing trusted protection, the application program is not interfered with, ensuring that the computing task can be completed correctly and the integrity of the patrol can be ensured.

[0005] To build a trusted computing system in a cloud environment, it is necessary to extend the trusted chain, pass the trust chain to the virtual machine manager and virtual machine, build a virtual trusted root and supporting virtualization components on the trusted cloud server, and then build a vTPCM to measure and control the behavior of the virtual machine.

[0006] In traditional business scenarios, virtual machines have migration functions, but in trusted computing systems, the migration function of virtual machine trusted roots needs to be added accordingly. Compared with virtual machine migration, the migration of virtual trusted roots in cloud environments also requires the migration of data such as keys in virtual trusted root instances, and the migration method is more complicated. Therefore, it is necessary to propose a safe and efficient method for migrating virtual trusted roots.

[0007] The patent name of CN111125706A is "A Trusted Middleware for a Cloud Platform", which provides a trusted middleware for a cloud platform, including: a virtual trusted component, the virtual trusted component includes a virtual trusted root and a virtual trusted root management module, the virtual trusted root is configured to extend the trust chain to the virtual machine and provide a trusted root service for the virtual machine; a trusted agent, the trusted agent includes a platform trusted agent and a virtual machine trusted agent, configured to measure the relevant core programs and files at startup, and detect the integrity of the hardware and system; a trusted management end, the trusted management end receives the measurement report and detection results sent by the trusted agent, and when the trusted state of the platform and / or the virtual machine is detected to send a change, the current trusted state is pushed to the virtualization software management end configured with the virtual trusted root management module. Through this invention, the trust chain can be extended to the virtual machine, providing tenants with a virtual machine with a trusted computing service. The virtual trusted root of the invention is implemented with vTPM, and the virtual trusted root migration module realizes the synchronous migration of the virtual trusted root related data of the virtual machine to the destination when the virtual machine is migrated. The invention only describes the establishment of a secure channel to migrate virtual trusted root data, but does not perform identity authentication on both platforms of the migration and integrity protection of the migrated data. Secondly, the invention is only applicable to the migration of virtual trusted roots implemented by software virtualization, but not to the migration of virtual trusted roots implemented by hardware virtualization, and cannot handle the migration scenario of virtual trusted roots under dual architecture.

[0008] The patent name of CN109783474A is "A method for securely migrating a virtual trusted root instance and its own state data". It is characterized in that, whether it is migrated according to the control node instruction or in response to the computing node request, the vTPCM instance and its own state data are encrypted and packaged using an encryption algorithm and sent to a computing node designated by the control node that has the same or similar functions, sufficient memory space, and is migrated from a computing node called the source platform to a computing node called the target platform in a network manner under the control of the control node. The invention uses a virtualization architecture of a trusted platform control module TPCM and KVM. Compared with 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 ensuring the security of the migrated data. This method lacks secure migration of keys in the migration of virtual trusted root instances. Summary of the invention

[0009] The present invention is based on a hardware-implemented vTPCM and proposes a virtual trusted root migration method under a dual-architecture. In a dual-architecture trusted computing environment, multiple virtual trusted roots vTPCM can be virtualized based on the hardware trusted root TPCM, and the virtualization components of TPCM are installed on the protection component. The present invention designs a safe and efficient virtual trusted root migration method for this scenario. The present invention establishes a key tree of vTPCM based on the TCM key system, which is convenient for managing the keys of vTPCM and facilitating the secure migration of vTPCM instances.

[0010] The solution of the present invention is based on the migration of the virtual trusted root under the dual architecture, and the solution mainly includes three parts:

[0011] S1: vTPCM key tree establishment. TCM's keys are divided into four groups according to the identity of use: for platform manufacturers, for users, for privacy-sensitive applications, and for temporary needs. Each group has a key seed, which is a large number that will never be leaked outside its security boundary. TCM uses these cryptographic roots to create the master key, and then creates various keys under the master key. Except for the master key, other keys are encrypted and protected by their parent keys. The migration of TCM keys is implemented by copy and import commands, and the key replication properties are mainly determined by fixedTCM and fixedParent, so the following four situations occur:

[0012] 1) fixedTCM is true and fixedParent is false: This is not allowed. A key with fixedTCM true cannot be copied. However, fixedParent is false, indicating that the key can be moved to another parent key and may be migrated with the new parent key, which is contrary to the function of fixedTCM true. TCM will check fixedTCM and fixedParent and will not allow this inconsistency.

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

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

[0015] 4) fixedTCM is false and fixedParent is false, indicating that the key can be copied directly. If it is a parent key copy root, its child keys will move with it.

[0016] According to the key replication attribute, the following vTPCM key tree can be established to facilitate the management of vTPCM keys:

[0017] 1) Generate a primary key Primary_Key based on the password root, and generate a key Parents_vTPCM under the primary key Primary_Key as the parent key of all vTPCM root keys, and set its attributes to fixTCM true and fixedParent true;

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

[0019] 3) The subkeys vTPCM1_Key1, vTPCM1_Key2, etc. generated by vTPCM1_R, etc. 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, and the child keys under it only need to be transferred data.

[0021] S2: vTPCM instance management. The vTPCM instance contains the key data, trusted boot baseline value data, and virtual PCR value of the vTPCM. After the vTPCM component is deployed, the vTPCM is initialized first and a mapping table is created to manage the correspondence between the virtual machine and the vTPCM instance. The vTPCM instance is managed accordingly at each stage of the virtual machine life cycle, including creation, startup, migration, and destruction.

[0022] S3: vTPCM migration. Before migrating the virtual machine, the vTPCM instance is migrated first. After the two migration platforms call the remote attestation module for remote attestation, they call the vTPCM migration module for key negotiation and use the negotiated key to establish an encrypted channel. The migration source platform packages the vTPCM instance including the key data and sends it to the migration target platform through an encrypted channel; after the vTPCM migration module of the migration target platform verifies the data integrity, it loads the vTPCM instance after the virtual machine migration is completed, and notifies the migration source platform to destroy the source platform vTPCM instance.

[0023] The present invention is based on a trusted computing platform deployment environment with a dual-architecture, the computing component environment is a Linux operating system, the protection component deploys hardware TPCM, and most of the vTPCM components virtualized by TPCM are deployed on the protection component side. The application scenario of the present invention is mainly a trusted computing platform with a dual-architecture. The specific implementation includes the following process.

[0024] Process 1: Initialization phase.

[0025] 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 is initialized first, creates a mapping table to manage various data of the vTPCM instance, and then creates the storage root key and the key Parents_vTPCM, and stores the key context. When the virtual machine is created, the vTPCM instance management module creates a vTPCM instance, associates it with the virtual machine uuid, calculates the baseline value, creates the root key of the vTPCM, and stores the vTPCM instance data, including the baseline value, vPCR value, and the context of the vTPCM root key.

[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 performed;

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

[0029] 3) After the remote attestation 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 for key negotiation. The specific process of the negotiation is as follows;

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

[0031] The source platform and the target platform 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 uses 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 the temporary key to each other;

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

[0034] The source platform and the target platform use the KDF function to expand Z into a 128-bit SM4 key. The encrypted channel required for subsequent migration between the two parties will use this key for encryption and decryption.

[0035] 4) The target platform sends the public key of its Parents_vTPCM to the source platform through 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 the key, and then packages the data returned by the TCM copy command and the vTPCM instance, adds the hash value encrypted by HMAC at the end and sends them to the target platform. The HASH algorithm used by HMAC is SM3, and the key used is the negotiated encryption channel key;

[0037] 6) The source platform vTPCM migration module transmits the vTPCM migration instance file to the target platform through 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 Parents_vTPCM through the TCM load key command to return the context of the new vTPCM root key; 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 completed, the vTPCM instance management module establishes an association between the virtual machine and the vTPCM instance; the target platform then sends a message to the source platform indicating that the virtual machine migration is completed, and the source platform deletes the virtual machine and the vTPCM instance.

[0041] Compared with the prior art, the migration of the virtual root of trust described in the present invention includes that the core vTPCM components including the vTPCM migration module, the remote attestation module and the vTPCM instance management module are all deployed in the protection component, which can effectively avoid external attacks and is safe and practical.

[0042] The present invention establishes a key tree of vTPCM based on hardware TCM, effectively manages vTPCM keys, and facilitates migration of vTPCM instances. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0044] Figure 2 The following is a diagram of the virtual root of trust migration architecture based on a dual architecture.

[0045] Figure 3 The figure is a flowchart of virtual trusted root migration based on dual architecture. DETAILED DESCRIPTION

[0046] The present invention is described in detail below with reference to the accompanying drawings and embodiments.

[0047] The solution of the present invention is based on the migration of the virtual trusted root under the dual architecture, and the solution mainly includes three parts:

[0048] Part 1: vTPCM key tree establishment. TCM's keys are divided into four groups based on the identity of use: for platform manufacturers, for users, for privacy-sensitive applications, and for temporary needs. Each group has a key seed, which is a large number that will never be leaked outside its security boundary. TCM uses these cryptographic roots to create the master key, and then creates various keys under the master key. Except for the master key, other keys are encrypted and protected by their parent keys. The migration of TCM keys is implemented by copy and import commands, and the key replication properties are mainly determined by fixedTCM and fixedParent, so the following four situations occur:

[0049] 1. fixedTCM is true and fixedParent is false: This is not allowed. A key with fixedTCM true cannot be copied. However, fixedParent is false, indicating that the key can be moved to another parent key and may be migrated with the new parent key, which is contrary to the function of fixedTCM being true. TCM will check fixedTCM and fixedParent and will not allow this inconsistency.

[0050] 2.fixedTCM is true and fixedParent is true: defines an object that cannot be copied.

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

[0052] 4. fixedTCM is false, fixedParent is false, indicating that the key can be copied directly. If it is a parent key copy root, its child keys will move with it.

[0053] According to the key replication attribute, the following vTPCM key tree can be established to facilitate the management of vTPCM keys:

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

[0055] 2. Generate vTPCM1_R, vTPCM2_R and other keys under Parents_vTPCM as the root key of each vTPCM, and set their attributes to fixedTCM to false and fixedParent to false;

[0056] 3. The subkeys vTPCM1_Key1, vTPCM1_Key2, etc. generated by vTPCM1_R, etc. 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, and the child keys under it only need to be transferred data.

[0058] Part 2: vTPCM instance management. The vTPCM instance contains the key data, trusted boot baseline value data, and virtual PCR value of the vTPCM. After the vTPCM component is deployed, the vTPCM is initialized first and a mapping table is created to manage the correspondence between the virtual machine and the vTPCM instance. The vTPCM instance is managed accordingly at each stage of the virtual machine life cycle, including creation, startup, migration, and destruction.

[0059] Part 3: vTPCM migration. Before migrating the virtual machine, the vTPCM instance must be migrated first. After the two migration platforms call the remote attestation module for remote attestation, they call the vTPCM migration module for key negotiation and use the negotiated key to establish an encrypted channel. The migration source platform packages the vTPCM instance including the key data and sends it to the migration target platform through an encrypted channel; after the vTPCM migration module of the migration target platform verifies the data integrity, it loads the vTPCM instance after the virtual machine migration is completed, and notifies the migration source platform to destroy the source platform vTPCM instance.

[0060] The present invention is based on a trusted computing platform deployment environment with a dual-architecture, the computing component environment is a Linux operating system, the protection component deploys hardware TPCM, and most of the vTPCM components virtualized by TPCM are deployed on the protection component side. The application scenario of the present invention is mainly a trusted computing platform with a dual-architecture. The specific implementation includes the following process.

[0061] Process 1: Initialization phase.

[0062] 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 is initialized first, creates a mapping table to manage various data of the vTPCM instance, and then creates the storage root key and the key Parents_vTPCM, and stores the key context. When the virtual machine is created, the vTPCM instance management module creates a vTPCM instance, associates it with the virtual machine uuid, calculates the baseline value, creates the root key of the vTPCM, and stores the vTPCM instance data, including the baseline value, vPCR value, and the context of the vTPCM root key.

[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 performed;

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

[0066] 3) After the remote attestation 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 for key negotiation. The specific process of the negotiation is as follows;

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

[0068] The source platform and the target platform 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 uses 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 the temporary key to each other;

[0070] The vTPCM migration modules of the source platform and the target platform call the TCM two-phase key negotiation command zgen2phase to negotiate a shared secret Z based on the two public keys sent by the other party and their 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 in the encrypted channels that will be used during subsequent migrations.

[0072] 4) The target platform sends the public key of its Parents_vTPCM to the source platform through 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 the key, and then packages the data returned by the TCM copy command and the vTPCM instance, adds the hash value encrypted by HMAC at the end and sends them to the target platform. The HASH algorithm used by HMAC is SM3, and the key used is the negotiated encryption channel key;

[0074] 6) The source platform vTPCM migration module transmits the vTPCM migration instance file to the target platform through 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 Parents_vTPCM through the TCM load key command to return the context of the new vTPCM root key; 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 completed, the vTPCM instance management module establishes an association between the virtual machine and the vTPCM instance; the target platform then sends a message to the source platform indicating that the virtual machine migration is completed, and the source platform deletes the virtual machine and the vTPCM instance.

[0078] Compared with the prior art, the migration of the virtual root of trust described in the present invention includes that the core vTPCM components including the vTPCM migration module, the remote attestation module and the vTPCM instance management module are all deployed in the protection component, which can effectively avoid external attacks and is safe and practical.

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

Claims

1. A method for migrating a virtual root of trust under a dual architecture, characterized in that: It consists of three parts: S1: vTPCM key tree establishment; TCM's keys are divided into four groups according to 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 cryptographic seeds to create a master key, and then creates various keys under the master key; except for the master key, other keys are encrypted and protected by their parent keys; S2: vTPCM instance management; vTPCM instances contain vTPCM key data, trusted boot baseline value data, and virtual PCR values; after the vTPCM components are deployed, vTPCM is initialized first and a mapping table is created to manage the correspondence between virtual machines and vTPCM instances; vTPCM instances are managed accordingly at various stages of the virtual machine life cycle, including creation, startup, migration, and destruction; S3: vTPCM migration: Before migrating the virtual machine, the vTPCM instance is migrated first. After the migration platforms call the remote attestation module for remote attestation, the vTPCM migration module is called for key negotiation, and the key negotiated is used to establish an encrypted channel. The migration source platform packages the vTPCM instance including the key data and sends it to the migration target platform through an encrypted channel; After the vTPCM migration module of the migration target platform verifies the data integrity, it loads the vTPCM instance after the virtual machine migration is completed and notifies the migration source platform to destroy the source platform vTPCM instance.

2. The method for migrating a virtual root of trust under a dual architecture according to claim 1, characterized in that: The migration of TCM keys is implemented by the copy and import commands, and the key replication attributes are determined by fixedTCM and fixedParent. The following four situations occur: 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 is contrary to the function to be achieved when fixedTCM is true; TCM will check fixedTCM and fixedParent and does not allow such inconsistency; 2) fixedTCM is true and fixedParent is true: defines an object that cannot be copied; 3) fixedTCM is false and fixedParent is true: This means that a key cannot be directly copied and is bound to a parent key; If an ancestor key is copied, this key naturally moves with it; 4) fixedTCM is false and fixedParent is false, indicating that the key can be copied directly; if it is a parent key copy root, its child keys will move with it.

3. The method for migrating a virtual root of trust under a dual architecture according to claim 1, characterized in that: The following vTPCM key tree is established based on the key replication attribute to facilitate the management of vTPCM keys: 1) Generate a primary key Primary_Key based on the password root, and generate a key Parents_vTPCM under the primary key Primary_Key as the parent key of all vTPCM root keys, and set its attributes to fixTCM true and fixedParent true; 2) Generate vTPCM1_R and vTPCM2_R keys under Parents_vTPCM as the root keys of each vTPCM, and set the attributes to fixedTCM to false and fixedParent to false; 3) The subkeys vTPCM1_Key1 and vTPCM1_Key2 generated by vTPCM1_R are used for the 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, and the child keys under it only need to be transferred data.

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

5. The method for migrating a virtual root of trust under a dual architecture according to claim 4, characterized in that: The specific implementation of the dual-architecture trusted computing platform 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 is initialized first, a mapping table is created to manage various data of the vTPCM instance, and then the root key and the key Parents_vTPCM are created, and the key context is stored; when the virtual machine is created, the vTPCM instance management module creates a vTPCM instance, associates it with the virtual machine uuid, calculates the baseline value, creates the root key of the 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 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 performed; 2) The vTPCM migration modules of the source and target platforms collaborate with the trusted third party to complete the two-way remote attestation of the source and target platforms; 3) After the remote attestation 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 for key negotiation; 4) The target platform sends the public key of its Parents_vTPCM to the source platform through an encrypted channel; 5) The source platform vTPCM migration module loads the public key of Parents_vTPCM, copies the key to be migrated to the key, and then packages the data returned by the TCM copy command and the vTPCM instance, adds the hash value encrypted by HMAC at the end and sends them to the target platform. The HASH algorithm used by HMAC is SM3, and the key used is the negotiated encryption channel key; 6) The source platform vTPCM migration module transmits the vTPCM migration instance file to the target platform through 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 Parents_vTPCM through the TCM load key command to return the context of the new vTPCM root key; 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 completed, the vTPCM instance management module establishes an association between the virtual machine and the vTPCM instance; the target platform then sends a message to the source platform indicating that the virtual machine migration is completed, and the source platform deletes the virtual machine and the vTPCM instance.

6. The method for migrating a virtual root of trust under a dual architecture according to claim 5, characterized in that: The specific process of hardware TCM key negotiation is as follows: The source platform and the target platform respectively call the TCM create master key command to generate a pair of elliptic curve keys. The elliptic curve uses ECC_SM2_P256, and the key is used as a static key. The source platform and the target platform 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 uses ECC_SM2_P256. The source platform and the target platform each send the public key of their static key and the public key of the temporary key to each other; The vTPCM migration modules of the source platform and the target platform call the TCM two-phase key negotiation command zgen2phase to negotiate a shared secret Z based on the two public keys sent by the other party and their own two private keys. The shared secret is an elliptic curve point, and the shared secrets negotiated by both parties will be the same; The source platform and the target platform use the KDF function to expand Z into a 128-bit SM4 key. The encrypted channel required for subsequent migration between the two parties will use this key for encryption and decryption.

Images