Remote attestation method, system and related device based on TEE proxy verification

Abstract

The application provides a remote attestation method and system based on TEE proxy verification and related equipment, wherein the verification logic is locally implemented in a trusted execution environment inside a virtual server supervision system and a client virtual server, and the storage measurement log of the client virtual server does not need to be sent to the virtual server supervision system in the verification process, but only needs to return the verification result to the virtual server supervision system, thereby solving the problem of possible data leakage when the storage measurement log of the client virtual server is sent to the supervision system; and the execution process of the method of the application is implemented based on the existing cloud service architecture, and has small implementation difficulty and high compatibility.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and in particular to a remote verification method, system and related equipment based on TEE proxy verification. Background Technology

[0002] With the continuous development of the information industry, the security risks faced by information systems are also increasing. Software attacks against information systems are often accompanied by integrity breaches, such as executable program replacement, configuration file tampering, and backdoor program implantation. Therefore, the industry has proposed integrity protection technologies to measure and verify critical data during system startup and operation, ensuring that the system operates in a trusted state as intended by the design goals.

[0003] In data center-based client virtual server operation and maintenance scenarios, integrity protection technology's measurement and verification methods are implemented through integrity measurement and remote proof, respectively. Integrity measurement is the foundation of remote proof, providing static and dynamic measurements based on the virtualization trusted platform module within the client virtual server. Dynamic measurement involves the Integrity Measurement Architecture (IMA) of the client virtual server's operating system kernel calculating hash values ​​for files accessed during system operation and recording them in the operating system kernel's Storage Measurement Log (SML). Simultaneously, the IMA extends the hash values ​​to the Platform Configuration Register (PCR) of the virtualization trusted platform module through the module's hash extension interface for secure storage. Leveraging the immutable nature of the PCR provided by the virtualization trusted platform module, SML faithfully records the integrity measurement results of files accessed during system operation through integrity measurement records composed of a PCR index, filename, and hash value triple structure.

[0004] Remote authentication, based on integrity metrics, is an important service provided by cloud service providers to client virtual server tenants to verify the integrity of the client virtual server system. Existing remote authentication methods typically involve the cloud service provider's virtual server monitoring system acting as the verifier, sending a remote authentication request to the client virtual server (the authenticated party). The authenticated party sends a PCR value and an SML (System Details Language) to the verifier. The verifier uses the PCR value to verify the integrity of the SML, and then compares the hash value of the file recorded in the SML with a benchmark value held by the verifier to confirm the trustworthiness of the authenticated party's system.

[0005] However, in the aforementioned methods, after the client virtual server is delivered to the tenant, the tenant deploys and stores their own programs and data files on the client virtual server. These files are the tenant's private data but are still subject to IMA measurement. Therefore, the SML inevitably contains characteristic information of these programs and data files, including filenames and hash values. In existing remote proof methods, the verified party sends the SML to the verifier. Although the measured files themselves are not directly sent, the verified party has in fact exposed its own characteristic information. This not only violates the cloud service contract's clause prohibiting cloud service providers from spying on client virtual server data but also leaves an opportunity for malicious attackers. If the verifier is compromised, the attacker can obtain and analyze the SML, using a big data rainbow table to deduce the file content from the hash value, causing privacy leaks; or infer the type and version of the programs currently installed by the verified party and exploit vulnerabilities in those programs to specifically intrude into the verified party.

[0006] Clearly, the root cause of the aforementioned shortcomings lies in the fact that existing methods require the verified party to provide SML externally. Therefore, it is necessary to develop a new remote proof method to overcome these shortcomings. Summary of the Invention

[0007] This invention provides a remote verification method, system, and related equipment based on TEE proxy verification, aiming to solve the security problem of existing remote verification methods that require the verified party to provide log files to the outside world during the verification process.

[0008] To address the aforementioned technical problems, in a first aspect, the present invention provides a remote verification method based on TEE proxy verification. The remote verification method is implemented by a virtual server monitoring system acting as the verifier, and includes the following steps:

[0009] S101. Verify the initial trusted state of the client virtual server. If the client virtual server is in a trusted state, exchange identity authentication public keys with the client virtual server for each other's identity authentication credentials. Then, negotiate with the client virtual server to obtain a remote proof base key according to a preset key exchange method.

[0010] S102. Derive a remote proof session key for performing remote proof based on the remote proof base key;

[0011] S103. Determine the remote proof verification strategy for remote proof, and encrypt the remote proof verification strategy using the remote proof session key according to the preset authentication encryption algorithm before sending it out;

[0012] S104. Receive the remote proof verification result. The remote proof verification result is obtained by the client virtual server after decrypting and executing the remote proof verification strategy according to the preset authentication encryption algorithm, and then encrypting it using the remote proof session key it possesses according to the preset authentication encryption algorithm and sending it out.

[0013] S105. Using the remote proof session key, the remote proof verification result is decrypted according to the preset authentication encryption algorithm, and a remote proof judgment result regarding whether the current client virtual server is trustworthy is obtained based on the remote proof verification result.

[0014] Furthermore, step S101 includes the following sub-steps:

[0015] S1011. Create the client virtual server and verify its initial trusted state;

[0016] S1012. Send out the first identity authentication public key it possesses and obtain the second identity authentication public key; wherein, the second identity authentication public key is sent by the client virtual server;

[0017] S1013. Generate a first temporary key pair based on a preset key generation method. The first temporary key pair includes a first temporary public key and a first temporary private key. Sign the first temporary public key using the private key corresponding to the first identity authentication public key. Send out the signed first temporary public key.

[0018] S1014. Receive the second temporary public key and use the second identity authentication public key to sign and verify the second temporary public key. After the signature verification is successful, generate the remote proof base key according to the preset key exchange method using the first temporary private key and the second temporary public key as the data source. The second temporary public key is generated by the client virtual server based on the preset key generation method after receiving the first temporary public key and verifying the signature, and then signed with the private key corresponding to the second identity authentication public key before being issued.

[0019] Furthermore, the preset key generation method is the ECDSA digital signature algorithm; the preset key exchange method is the ECDH key negotiation algorithm.

[0020] Furthermore, step S102 includes the following sub-steps:

[0021] S1021. Generate a first random number and a second random number, and append the second random number to the end of the first random number to obtain a salt value;

[0022] S1022. Using the salt value and the remote proof base key as parameters of a preset key derivation algorithm, calculate the remote proof session key;

[0023] S1023. Send out the first random number, the second random number, and the salt value signed with the private key corresponding to the first identity authentication public key.

[0024] Furthermore, the preset key derivation algorithm is the HKDF key derivation algorithm.

[0025] Furthermore, in step S103, the remote proof verification strategy includes at least the platform configuration register index of the client virtual server and the file name and base value of the file to be audited corresponding to the platform configuration register index, wherein the file is a file in the software component when the client virtual server is created, and the base value is the hash value of the file;

[0026] The preset authentication encryption algorithm is the AES-GCM algorithm, and the first random number is used as the additional data used when the preset authentication encryption algorithm is encrypted, the second random number is used as the initial vector used when the preset authentication encryption algorithm is encrypted, and the first tag is used as the authentication tag of the remote proof verification strategy.

[0027] Furthermore, in step S105, the first random number is used as additional data for decryption by the preset authentication encryption algorithm, the second random number is used as the initial vector for decryption by the preset authentication encryption algorithm, and the second tag is used as the authentication tag for the remote proof verification result.

[0028] Secondly, the present invention also provides another remote verification method based on TEE proxy verification, wherein the remote verification method is implemented by a client virtual server acting as the verified party based on its trusted execution environment, and the remote verification method includes the following steps:

[0029] S201. After being verified by the virtual server monitoring system to be in an initial trusted state, the user exchanges identity authentication public keys with the virtual server monitoring system for each other's identity authentication credentials, and then negotiates with the virtual server monitoring system to obtain a remote proof base key according to a preset key exchange method.

[0030] S202. Derive a remote proof session key for performing remote proof based on the remote proof base key;

[0031] S203. Receive remote proof verification strategy, wherein the remote proof verification strategy is generated by the virtual server monitoring system and encrypted using the remote proof session key it possesses according to a preset authentication encryption algorithm before being sent out;

[0032] S204. Using the remote proof session key, decrypt and execute the remote proof verification strategy according to the preset authentication encryption algorithm to obtain the remote proof verification result of whether the current self-state is in a trusted state;

[0033] S205. Use the remote proof session key to encrypt the remote proof verification result according to the preset authentication encryption algorithm, and send the encrypted remote proof verification result.

[0034] Furthermore, step S201 includes the following sub-steps:

[0035] S2011. The client virtual server verifies its initial trusted state through the virtual server monitoring system, wherein the client virtual server is created by the virtual server monitoring system;

[0036] S2012. Receive the first identity authentication public key and store it in its own trusted execution environment, and then send out its own second identity authentication public key; wherein, the first identity authentication public key is sent by the virtual server monitoring system;

[0037] S2013. Receive the first temporary public key and verify its signature using the first identity authentication public key. After successful signature verification, generate a second temporary key pair based on a preset key generation method. The second temporary key pair includes a second temporary public key and a second temporary private key. Generate the remote proof base key using the first temporary public key and the second temporary private key as data sources according to the preset key exchange method. Then, sign the second temporary public key with the private key corresponding to the second identity authentication public key and send it out. The first temporary public key is generated and signed by the virtual server monitoring system before being sent out.

[0038] Furthermore, step S202 includes the following sub-steps:

[0039] S2021. Receive a first random number, a second random number, and a salt value signed with the private key corresponding to the first identity authentication public key; wherein, the first random number, the second random number, and the salt value are all generated and sent by the virtual server monitoring system;

[0040] S2022. Verify the signature of the salt value using the first identity authentication public key. After the signature verification is successful, calculate the remote proof session key using the salt value and the remote proof base key as parameters of the preset key derivation algorithm.

[0041] Furthermore, step S204 includes the following sub-steps:

[0042] S2041. Using the remote proof session key, the remote proof verification strategy is decrypted according to the preset authentication encryption algorithm to obtain the platform configuration register index of the client virtual server and the file name and base value of the file to be audited corresponding to the platform configuration register index; wherein, the preset authentication encryption algorithm is the AES-GCM algorithm, the first random number is used as the additional data used when the preset authentication encryption algorithm is decrypted, the second random number is used as the initial vector used when the preset authentication encryption algorithm is decrypted, and the first tag is used as the authentication tag of the remote proof verification strategy;

[0043] S2042. Obtain the platform configuration register value corresponding to itself using the platform configuration register index and the first random number as parameters, and obtain the storage metric log corresponding to itself based on the platform configuration register value. Based on the storage metric log and the benchmark value, check the integrity of the file obtained by the remote proof verification strategy decryption, and obtain the remote proof verification result of whether itself is in a trusted state. If the integrity check passes, it is in a trusted state.

[0044] Furthermore, in step S205, the first random number is used as additional data when the preset authentication encryption algorithm is used for encryption, the second random number is used as the initial vector when the preset authentication encryption algorithm is used for encryption, and the second tag is used as the authentication tag of the remote proof verification result.

[0045] Thirdly, the present invention also provides a remote verification system based on TEE proxy verification, the remote verification system including a first remote verification module implemented in a virtual server monitoring system, and a second remote verification module implemented in a client virtual server based on its trusted execution environment, wherein the first remote verification module includes:

[0046] The first base key negotiation module is used to verify the initial trusted state of the client virtual server. When the client virtual server is in a trusted state, it exchanges identity authentication public keys with the client virtual server for each other's identity authentication credentials. Then, it negotiates with the client virtual server to obtain a remote proof base key according to a preset key exchange method.

[0047] The first session key derivation module is used to derive a remote proof session key for performing remote proof based on the remote proof base key;

[0048] The remote proof sending module is used to determine the remote proof verification strategy for remote proof, and to encrypt the remote proof verification strategy using the remote proof session key according to a preset authentication encryption algorithm before sending it out;

[0049] The first remote proof receiving module is used to receive the remote proof verification result. The remote proof verification result is obtained by the client virtual server decrypting and executing the remote proof verification strategy according to the preset authentication encryption algorithm, and then encrypting it with the remote proof session key it possesses according to the preset authentication encryption algorithm before sending it out.

[0050] The remote proof decryption module is used to decrypt the remote proof verification result using the remote proof session key according to the preset authentication encryption algorithm, and obtain a remote proof judgment result on whether the current client virtual server is trustworthy based on the remote proof verification result;

[0051] The second remote verification module includes:

[0052] The second base key negotiation module is used to negotiate a remote proof base key with the virtual server monitoring system after exchanging identity authentication public keys used for mutual identity authentication credentials with the virtual server monitoring system when it is verified by the virtual server monitoring system to be in an initial trusted state.

[0053] The second session key derivation module is used to derive a remote proof session key for performing remote proof based on the remote proof base key;

[0054] The second remote proof receiving module is used to receive the remote proof verification strategy, wherein the remote proof verification strategy is generated by the virtual server monitoring system and encrypted using the remote proof session key it possesses according to a preset authentication encryption algorithm before being sent out;

[0055] The remote proof execution module is used to decrypt and execute the remote proof verification strategy using the remote proof session key according to the preset authentication encryption algorithm, and obtain the remote proof verification result of whether its current state is in a trusted state;

[0056] The remote proof encryption module is used to encrypt the remote proof verification result using the remote proof session key according to the preset authentication encryption algorithm, and then send the encrypted remote proof verification result.

[0057] Fourthly, the present invention also provides a computer device, comprising: a memory, a processor, and a remote proof program based on TEE proxy verification stored in the memory and executable on the processor, wherein the processor, when executing the remote proof program based on TEE proxy verification, implements the steps in the remote proof method based on TEE proxy verification as described above.

[0058] Fifthly, the present invention also provides a storage medium storing a remote proof program for TEE proxy verification, wherein the remote proof program for TEE proxy verification, when executed by a processor, implements the steps in the remote proof method based on TEE proxy verification as described above.

[0059] The beneficial effects achieved by this invention are that it proposes a remote verification method based on TEE proxy verification. This method localizes the verification logic in the virtual server monitoring system and the trusted execution environment inside the client virtual server. Moreover, the storage measurement logs of the client virtual server do not need to be sent to the virtual server monitoring system during the verification process, but only need to return the verification results to the virtual server monitoring system. This solves the data leakage problem that may occur when the storage measurement logs of the client virtual server are sent to the monitoring system. Furthermore, the execution process of the method of this invention is based on the existing cloud service architecture, which is easy to implement and highly compatible. Attached Figure Description

[0060] The present invention will now be described in detail with reference to the accompanying drawings. The above and other aspects of the present invention will become clearer and more readily understood through the detailed description following the accompanying drawings. In the drawings:

[0061] Figure 1 This is a flowchart of the steps of the remote proof method based on TEE proxy verification provided in the embodiments of the present invention;

[0062] Figure 2 This is a schematic diagram of the remote proof verification strategy provided in an embodiment of the present invention;

[0063] Figure 3 This is a flowchart of another remote proof method based on TEE proxy verification provided in an embodiment of the present invention;

[0064] Figure 4 This is a schematic diagram of the structure of the remote verification system based on TEE proxy verification provided in an embodiment of the present invention;

[0065] Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0066] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0067] Example 1

[0068] Please refer to Figure 1 , Figure 1This is a flowchart illustrating the steps of a remote verification method based on TEE proxy verification provided in this embodiment of the invention. The remote verification method is implemented by a virtual server monitoring system acting as the verifier, and includes the following steps:

[0069] S101. Verify the initial trusted state of the client virtual server. If the client virtual server is in a trusted state, exchange identity authentication public keys with the client virtual server for each other's identity authentication credentials. Then, negotiate with the client virtual server to obtain a remote proof base key according to a preset key exchange method.

[0070] Specifically, the Virtual Machine Supervisor (VMS) described in this embodiment of the invention is generally held and managed by a cloud service provider in real-world scenarios. It is responsible for the full lifecycle operation and maintenance of the Client Virtual Machine (CVM), including creation, updating, auditing, and recycling, and can be adjusted according to business scenarios. In this embodiment of the invention, it acts as the verifier of remote proof, while the client virtual machine acts as the verifier of remote proof. In cloud service scenarios, the client virtual machine is allocated to tenants for use. Therefore, the Virtual Machine Supervisor and the client virtual machine are not necessarily physically directly connected, making the client virtual machine less trustworthy than the Virtual Machine Supervisor. A Trusted Execution Environment (TEE) is a secure computing environment based on processor hardware isolation technology. It includes a secure system that isolates the TEE from a Rich Execution Environment (REE). The REE is a non-secure computing environment relative to the TEE and includes an operating system provided to tenants. The REE has integrity measurement capabilities based on a Virtualized Trusted Platform Module (vTPM) and remote authentication capabilities based on existing technologies. It is fully compatible with the Trusted Platform Module technical specifications developed by the Trusted Computing Group (TCG). The TEE and REE interact through a secure communication mechanism called a Secure Monitor Call (SMC), which ensures that sensitive data in the TEE is not illegally accessed or tampered with by the REE, and that the execution process of trusted applications in the TEE is not observed or interfered with by the REE.

[0071] The remote verification method described in Embodiment 1 of this invention is based on a virtual server monitoring system. Based on the technical concepts described above, specifically, step S101 includes the following sub-steps:

[0072] S1011. Create the client virtual server and verify its initial trusted state.

[0073] The software components of the client virtual server are allocated by the virtual server monitoring system during creation. Therefore, the virtual server monitoring system has the baseline values ​​of the software components, which enables the virtual server monitoring system to verify the trusted state of the client virtual server. This step can be achieved through existing proof methods. At the same time, since there are no tenant programs and data files in the client virtual server before it is delivered to the tenant, the remote proof verification of the initial trusted state of the client virtual server based on existing methods in step S1011 will not cause tenant privacy leakage.

[0074] S1012. Send out the first identity authentication public key it possesses and obtain the second identity authentication public key; wherein, the second identity authentication public key is sent by the client virtual server.

[0075] The first authentication public key is an asymmetric key pair held in advance by the virtual server monitoring system. The second authentication public key is an asymmetric key pair generated by the vTPM of the Rich Execution Environment (REE) when the client virtual server is created; this is a specification definition of Trusted Platform Module (TPM) technology.

[0076] Under this specification, the first identity authentication public key is PK_VMS, and its corresponding private key is SK_VMS. The private key SK_VMS is strictly kept confidential by the virtual server monitoring system and is used only for signature operations.

[0077] The second authentication public key is PK_CVM, and its corresponding private key is SK_CVM. The private key SK_CVM is stored in the client virtual server's vTPM after it is generated and cannot be read outside the vTPM. It can only be used by the client virtual server's vTPM for signing operations.

[0078] S1013. Generate a first temporary key pair based on a preset key generation method. The first temporary key pair includes a first temporary public key and a first temporary private key. Sign the first temporary public key using the private key corresponding to the first identity authentication public key. Send out the signed first temporary public key.

[0079] In this embodiment of the invention, the preset key generation method is the ECDSA digital signature algorithm.

[0080] S1014. Receive the second temporary public key and use the second identity authentication public key to sign and verify the second temporary public key. After the signature verification is successful, generate the remote proof base key according to the preset key exchange method using the first temporary private key and the second temporary public key as the data source. The second temporary public key is generated by the client virtual server based on the preset key generation method after receiving the first temporary public key and verifying the signature, and then signed with the private key corresponding to the second identity authentication public key before being issued.

[0081] Specifically, in this embodiment of the invention, the preset key exchange method is the ECDH (Elliptic Curve Diffie-Hellman) key negotiation algorithm, and the remote proof base key negotiation process in steps S1013-S1014 is as follows:

[0082] First, for the virtual server monitoring system, it is necessary to use the ECDSA digital signature algorithm to generate a temporary key pair (i.e., the first temporary key pair), which includes the first temporary public key PK_VMS_T and the first temporary private key SK_VMS_T;

[0083] Use the private key SK_VMS to perform a signature operation on the first temporary public key PK_VMS_T to obtain the signature of the first temporary public key PK_VMS_T;

[0084] Send the first temporary public key PK_VMS_T and its corresponding signature to the client virtual server;

[0085] Secondly, for the client virtual server, it is necessary to use the first identity authentication public key PK_VMS in the trusted execution environment to verify the signature of the first temporary public key PK_VMS_T;

[0086] If the signature verification passes, it also uses the ECDSA digital signature algorithm to generate a temporary key pair (i.e., the second temporary key pair), which includes the second temporary public key PK_CVM_T and the second temporary private key SK_CVM_T;

[0087] At this point, the client virtual server has obtained the first temporary public key and the second temporary private key pair. Subsequently, the client virtual server, in a trusted execution environment, uses the first temporary public key PK_VMS_T and the second temporary private key SK_CVM_T as data sources and employs the ECDH key negotiation algorithm to calculate the remote proof base key. The calculation process can be represented as follows:

[0088] KDK = ECDH(SK_CVM_T, PK_VMS_T);

[0089] KDK is the remote proof base key;

[0090] Then, the second temporary public key PK_CVM_T is transmitted to the rich execution environment REE through the SMC secure communication mechanism, and the second temporary public key PK_CVM_T is signed by the private key SK_CVM in the rich execution environment REE using vTPM to obtain its corresponding signature; then, the second temporary public key PK_CVM_T and its corresponding signature are sent to the virtual server monitoring system.

[0091] Finally, for the virtual server monitoring system, the signature of the second temporary public key PK_CVM_T is verified using the second identity authentication public key PK_CVM.

[0092] If the signature verification passes, the virtual server monitoring system obtains the first temporary key pair and the second temporary public key. Using the first temporary private key SK_VMS_T and the second temporary public key PK_CVM_T as its data source, it calculates the remote proof base key using the ECDH key negotiation algorithm. The calculation process can be represented as follows:

[0093] KDK = ECDH(SK_VMS_T, PK_CVM_T);

[0094] KDK stands for Remote Proof Base Key.

[0095] Understandably, based on the ECDH key negotiation algorithm principle, in this embodiment of the invention, the virtual server monitoring system and the client virtual server can each calculate the exact same remote proof base key using the temporary public key provided by the other party, without sharing each other's temporary private keys. Furthermore, based on the ECDSA digital signature algorithm key generation principle, the temporary key pairs generated by the virtual server monitoring system and the client virtual server for key negotiation calculation are random, and therefore the calculated remote proof base key is also random. This ensures that the virtual server monitoring system and different client virtual servers will theoretically always negotiate different remote proof base keys, also known as "one key per machine".

[0096] Based on the working principle of the Trusted Execution Environment (TEE), the second temporary private key SK_CVM_T is generated and used by the client virtual server in the TEE. The Rich Execution Environment (REE) cannot obtain this temporary private key, so the REE cannot calculate the remote proof base key, ensuring that the remote proof base key is always in a secure state.

[0097] After step S1014 is completed, the client virtual server is assigned to the tenant for use. Therefore, its trusted state changes to an untrusted state from the perspective of the virtual server monitoring system at the moment of assignment. In this state, the virtual server monitoring system needs to prove the current trusted state of the client virtual server through a remote authentication method.

[0098] S102. Derive a remote proof session key for performing remote proof based on the remote proof base key.

[0099] Step S102 occurs before each request from the virtual server monitoring system to perform remote authentication.

[0100] Specifically, step S102 includes the following sub-steps:

[0101] S1021. Generate a first random number and a second random number, and append the second random number to the end of the first random number to obtain a salt value.

[0102] In this embodiment of the invention, the virtual server monitoring system uses a true random number generator to generate a first random number N1 and a second random number N2. The salt value N1 || N2 is formed by concatenating N2 to the end of N1. The true random number generator is a hardware device in the virtual server monitoring system that can use the current entropy value as a seed to generate random number sequences. The entropy value is related to random physical signal noise such as temperature, time, voltage, and current of the hardware device at that time, and is a truly random value. Therefore, it can ensure that the generated random number sequence has true randomness.

[0103] S1022. Using the salt value and the remote proof base key as parameters of a preset key derivation algorithm, calculate the remote proof session key.

[0104] The remote authentication session key derivation process can be represented by the following relation:

[0105] KSK=HKDF(KDK,N1||N2);

[0106] Where KSK is the remote proof session key; N1 || N2 is the salt value formed by concatenating N2 to the end of N1.

[0107] S1023. Send out the first random number, the second random number, and the salt value signed with the private key corresponding to the first identity authentication public key.

[0108] In this embodiment of the invention, the preset key derivation algorithm is the HKDF key derivation algorithm (HMAC-based Key Derivation Function).

[0109] During the remote proof session key derivation phase, the virtual server monitoring system and the client virtual server each use the same parameters to calculate the same session key, instead of exchanging session keys with each other.

[0110] Understandably, based on the HKDF key derivation algorithm principle, in this embodiment of the invention, the virtual server monitoring system and the client virtual server can each calculate the exact same remote proof session key using the first random number N1 and the second random number N2 provided by the virtual server monitoring system, without transmitting the remote proof base key. Since the first random number N1 and the second random number N2 used in each remote proof session are randomly generated again by the virtual server monitoring system, the remote proof session key also has randomness. This ensures that each remote proof session between the virtual server monitoring system and the client virtual server theoretically always uses a different remote proof session key, also known as "one-time key".

[0111] Furthermore, although the first random number N1 and the second random number N2 are transmitted in plaintext, the Rich Execution Environment (REE) does not have a remote proof base key, so the REE cannot calculate the remote proof session key, thus ensuring that the remote proof session key is always in a secure state.

[0112] S103. Determine the remote proof verification strategy for remote proof, and encrypt the remote proof verification strategy using the remote proof session key according to the preset authentication encryption algorithm before sending it out.

[0113] S104. Receive the remote proof verification result. The remote proof verification result is obtained by the client virtual server after decrypting and executing the remote proof verification strategy according to the preset authentication encryption algorithm, and then encrypting it using the remote proof session key it possesses according to the preset authentication encryption algorithm and sending it out.

[0114] Specifically, to facilitate understanding of the specific implementation of the steps in the embodiments of the present invention, the embodiments of the present invention will describe the content of the remote proof verification strategy generated by the virtual server monitoring system:

[0115] The remote verification strategy sent by the virtual server monitoring system includes at least the Platform Configuration Register Index (PCR index) of the client virtual server, the filename and base value of the file to be audited corresponding to the PCR index, where the file is a file in the software component when the client virtual server was created, and the base value is the hash value of the file. During implementation, other fields may be added as needed.

[0116] It is understandable that the software components of the client virtual server are allocated by the virtual server monitoring system during creation, or by the virtual server monitoring system when updating and maintaining the client virtual server. Therefore, the virtual server monitoring system always has the correct hash value of the files in the client virtual server software components.

[0117] In the implementation of this invention embodiment, the content of a remote proof verification strategy is as follows: Figure 2 As shown, the typical range of platform configuration register indices is 0 to 23, corresponding to the 24 platform configuration register indices defined in the TCG Trusted Platform Module Technical Specification. Figure 2 The remote proof verification strategy set in the configuration has a PCR index of 10. In addition, it includes the filenames and baseline values ​​of four files that need to be audited. The filenames show that the files belong to the Linux operating system running on the Rich Execution Environment (REE) in the client virtual server software component.

[0118] The remote authentication policy determined by the virtual server monitoring system is encrypted using the AES-GCM algorithm and transmitted to the client virtual server. The first random number is used as additional data for encryption using the preset authentication encryption algorithm, the second random number is used as the initial vector, and the first tag is used as the authentication tag for the remote authentication policy. Specifically, the AES-GCM algorithm combines symmetric key encryption and message authentication. It uses an initial vector to ensure that different ciphertexts are generated when the same plaintext is encrypted with the same key, and uses additional data to establish a binding relationship with the ciphertext to prevent replay attacks. This simultaneously guarantees message confidentiality, integrity, and the trustworthiness of the sender.

[0119] The process by which a virtual server monitoring system encrypts a remote authentication and verification strategy using a preset authentication and encryption algorithm can be represented by the following equation:

[0120] {S_RAP,TAG1} = Encrypt(AES-GCM,KSK,RAP,IV,AAD);

[0121] Wherein, S_RAP is the ciphertext of the remote proof verification policy generated by the AES-GCM algorithm; TAG1 is the authentication tag of the remote proof verification policy generated by the AES-GCM algorithm, which is the first tag in this embodiment; Encrypt represents encryption operation; KSK is the remote proof session key; RAP is the remote proof verification policy; AAD is the additional data required for the encryption operation of the AES-GCM algorithm, which uses the first random number N1 in this embodiment; IV is the initial vector required for the encryption operation of the AES-GCM algorithm, which uses the second random number N2 in this embodiment.

[0122] Understandably, by using the first random number N1 and the second random number N2 as input parameters for encryption by the AES-GCM algorithm, the binding between the remote proof verification strategy and the current remote proof session is further enhanced, so that the remote proof verification strategy transmitted in the current remote proof session can and can only be used in the current remote proof session.

[0123] To facilitate understanding of the execution principle of the remote proof verification strategy, the process of the client virtual server executing the remote proof verification strategy will first be explained here (i.e., the content of step S204 in the subsequent embodiment two):

[0124] The client virtual server invokes the AES-GCM algorithm using the remote proof session key, the remote proof verification policy authentication tag in the encrypted remote proof verification policy, the initialization vector, and additional data. It then performs a decryption operation on the ciphertext of the encrypted remote proof verification policy to obtain the remote proof verification policy. The calculation process can be represented as follows:

[0125] RAP = Decrypt(AES-GCM,KSK,S_RAP,TAG1,IV,AAD);

[0126] Wherein, RAP is the remote proof verification strategy; Decrypt represents decryption operation; KSK is the remote proof session key; S_RAP is the remote proof verification strategy ciphertext; TAG1 is the remote proof verification strategy authentication tag, which is the first tag in this embodiment; AAD is the additional data required for the AES-GCM algorithm decryption operation, which uses the first random number N1 in this embodiment; IV is the initial vector required for the AES-GCM algorithm decryption operation, which uses the second random number N2 in this embodiment.

[0127] According to the principles of the AES-GCM algorithm, decryption can only succeed if the same initialization vector and additional data are used as those used during encryption, and if both the ciphertext and the ciphertext authentication tag have not been tampered with. Therefore, if the decryption operation is successful, it indicates that the remote proof verification strategy obtained from the decryption is trustworthy.

[0128] Furthermore, the client virtual server obtains its own corresponding platform configuration register value using the platform configuration register index and the first random number as parameters, and obtains its own corresponding storage metric log based on the platform configuration register value. Based on the storage metric log and the benchmark value, it checks the integrity of the file obtained by the remote proof verification strategy decryption to obtain the remote proof verification result of whether it is currently in a trusted state. If the integrity check passes, it is in a trusted state.

[0129] S105. Using the remote proof session key, the remote proof verification result is decrypted according to the preset authentication encryption algorithm, and a remote proof judgment result regarding whether the current client virtual server is trustworthy is obtained based on the remote proof verification result.

[0130] In step S105, the first random number is used as additional data for decryption by the preset authentication encryption algorithm, the second random number is used as the initial vector for decryption by the preset authentication encryption algorithm, and the second tag is used as the authentication tag for the remote proof verification result.

[0131] The virtual server monitoring system decrypts the encrypted remote proof verification result to obtain its content. The decryption process in step S105 can be expressed as the following equation:

[0132] Result = Decrypt(AES-GCM,KSK,S_Result,TAG2,IV,AAD);

[0133] Wherein, Result is the remote proof verification result; Decrypt represents the decryption operation; KSK is the remote proof session key; S_Result is the ciphertext of the remote proof verification result; TAG2 is the remote proof verification result authentication tag, which is the second tag in this embodiment; AAD is the additional data required for the AES-GCM algorithm decryption operation, which uses the first random number N1 in this embodiment; IV is the initial vector required for the AES-GCM algorithm decryption operation, which uses the second random number N2 in this embodiment.

[0134] The difference between step S105 and step S106 is that step S105 uses the second tag as the authentication tag when decrypting the remote proof verification result, thus marking the difference in the remote proof stage process.

[0135] According to the principles of the AES-GCM algorithm, decryption can only succeed if the same initialization vector and additional data used during encryption are employed, and if both the ciphertext and the ciphertext authentication tag have not been tampered with. Therefore, if the decryption operation is successful, it indicates that the remote proof verification result obtained by the virtual server monitoring system was indeed generated by the client virtual server and is complete. Subsequently, the virtual server monitoring system can confirm whether the current client virtual server is in a trusted state based on the content of the remote proof verification result.

[0136] Understandably, by using the first random number N1 and the second random number N2 as input parameters for encryption by the AES-GCM algorithm, the binding between the remote proof verification result and the current remote proof session is further enhanced, so that the remote proof verification result transmitted in the current remote proof session can and can only be used in the current remote proof session.

[0137] Example 2

[0138] Please refer to Figure 3 , Figure 3 This is a flowchart illustrating another remote verification method based on TEE proxy verification provided by an embodiment of the present invention. The remote verification method is implemented by a client virtual server, acting as the verified party, based on its trusted execution environment. The remote verification method includes the following steps:

[0139] S201. After being verified by the virtual server monitoring system to be in an initial trusted state, the user exchanges identity authentication public keys with the virtual server monitoring system for each other's identity authentication credentials, and then negotiates with the virtual server monitoring system to obtain a remote proof base key according to a preset key exchange method.

[0140] Unlike the process executed by the virtual server monitoring system in Embodiment 1, the remote proof method described in this embodiment is implemented by the client virtual server, acting as the verified party, based on its Trusted Execution Environment (REA). Compared to the virtual server monitoring system, the client virtual server is used by tenants, thus placing it in a relatively insecure environment. To address this, a relatively secure and trusted software environment can be implemented on the client virtual server using a REA. Based on this, the remote proof method described in this embodiment can be implemented as a Remote Proof Proxy (RAA) running in a REA. This RAA is a trusted application developed in accordance with trusted application development specifications and running in a REA. Its function is to securely participate in the execution of the remote proof method proposed in this embodiment within the REA, without being observed or interfered with by the client virtual server's Rich Execution Environment (REE).

[0141] Based on the technical concept described above, specifically, step S201 includes the following sub-steps:

[0142] S2011. The client virtual server verifies its initial trusted state through the virtual server monitoring system, wherein the client virtual server is created by the virtual server monitoring system.

[0143] The software components of the client virtual server are allocated by the virtual server monitoring system during creation. Therefore, the virtual server monitoring system has baseline values ​​for the software components, which enables the virtual server monitoring system to verify the trusted state of the client virtual server. This step can be achieved through existing proof methods.

[0144] S2012. Receive the first identity authentication public key and store it in its own trusted execution environment. Then, issue the second identity authentication public key it possesses. The first identity authentication public key is issued by the virtual server monitoring system.

[0145] Specifically, the second authentication public key is an asymmetric key pair generated by a vTPM within a Rich Execution Environment (REE) and held in advance by the client virtual server. This falls under the specification definition of Trusted Platform Module (TPM) technology. In step S1012, the virtual server monitoring system and the client virtual server exchange their respective authentication public keys. However, considering the trust risks associated with the client virtual server's REE, the first authentication public key received by the client virtual server needs to be stored within the REE.

[0146] S2013. Receive the first temporary public key and verify its signature using the first identity authentication public key. After successful signature verification, generate a second temporary key pair based on a preset key generation method. The second temporary key pair includes a second temporary public key and a second temporary private key. Generate the remote proof base key using the first temporary public key and the second temporary private key as data sources according to the preset key exchange method. Then, sign the second temporary public key with the private key corresponding to the second identity authentication public key and send it out. The first temporary public key is generated and signed by the virtual server monitoring system before being sent out.

[0147] The steps for negotiating the remote proof base key between the virtual server monitoring system and the client virtual server are fully described in steps S1013-S1014 of Embodiment 1, and will not be repeated here to avoid repetition.

[0148] Understandably, based on the ECDH key negotiation algorithm principle, in this embodiment of the invention, the virtual server monitoring system and the client virtual server can each calculate the exact same remote proof base key using the temporary public key provided by the other party, without sharing each other's temporary private keys. Furthermore, based on the ECDSA digital signature algorithm key generation principle, the temporary key pairs generated by the virtual server monitoring system and the client virtual server for key negotiation calculation are random, and therefore the calculated remote proof base key is also random. This ensures that the virtual server monitoring system and different client virtual servers will theoretically always negotiate different remote proof base keys, also known as "one key per machine".

[0149] Furthermore, based on the working principle of the Trusted Execution Environment (TEE), the second temporary private key SK_CVM_T is generated and used by the client virtual server in the TEE. The Rich Execution Environment (REE) cannot obtain this temporary private key, therefore the REE cannot calculate the remote proof base key, ensuring that the remote proof base key is always in a secure state.

[0150] After step S2013 is completed, the client virtual server is assigned to the tenant for use. Therefore, its trusted state changes to an untrusted state from the perspective of the virtual server monitoring system at the moment of assignment. In this state, the virtual server monitoring system needs to prove the current trusted state of the client virtual server through a remote authentication method.

[0151] S202. Derive a remote proof session key for performing remote proof based on the remote proof base key.

[0152] Step S202 includes the following sub-steps:

[0153] S2021. Receive a first random number, a second random number, and a salt value signed with the private key corresponding to the first identity authentication public key; wherein the first random number, the second random number, and the salt value are all generated and issued by the virtual server monitoring system.

[0154] Specifically, the virtual server monitoring system uses a true random number generator to generate a first random number N1 and a second random number N2. The salt value N1 || N2 is formed by concatenating N2 to the end of N1.

[0155] S2022. Verify the signature of the salt value using the first identity authentication public key. After the signature verification is successful, calculate the remote proof session key using the salt value and the remote proof base key as parameters of the preset key derivation algorithm.

[0156] The remote proof session key derivation process in step S2022 can be represented by the following relation:

[0157] KSK=HKDF(KDK,N1||N2);

[0158] Where KSK is the remote proof session key; N1 || N2 is the salt value formed by concatenating N2 to the end of N1.

[0159] During the remote proof session key derivation phase, the virtual server monitoring system and the client virtual server each use the same parameters to calculate the same session key, instead of exchanging session keys with each other. Therefore, in step S2022, the client virtual server uses the public key PK_VMS in the TEE to verify the signature of N1 || N2. If the signature verification passes, the remote proof session key is calculated using the same HKDF key derivation algorithm and calculation formula as the virtual server monitoring system.

[0160] Understandably, based on the HKDF key derivation algorithm principle, in this embodiment of the invention, the virtual server monitoring system and the client virtual server can each calculate the exact same remote proof session key using the first random number N1 and the second random number N2 provided by the virtual server monitoring system, without transmitting the remote proof base key. Since the first random number N1 and the second random number N2 used in each remote proof session are randomly generated again by the virtual server monitoring system, the remote proof session key also has randomness. This ensures that each remote proof session between the virtual server monitoring system and the client virtual server theoretically always uses a different remote proof session key, also known as "one-time key".

[0161] Furthermore, although the first random number N1 and the second random number N2 are transmitted in plaintext, the Rich Execution Environment (REE) does not have a remote proof base key, so the REE cannot calculate the remote proof session key, thus ensuring that the remote proof session key is always in a secure state.

[0162] S203. Receive remote proof verification policy, wherein the remote proof verification policy is generated by the virtual server monitoring system and encrypted using the remote proof session key it possesses according to a preset authentication encryption algorithm before being sent.

[0163] Specifically, the remote verification strategy determined by the virtual server monitoring system includes at least the Platform Configuration Register (PCR) index and the filename and baseline value of the file to be audited corresponding to that PCR index, and other fields can be added as needed. Furthermore, since the software components of the client virtual server are allocated by the virtual server monitoring system when the client virtual server is created, or when the virtual server monitoring system updates and maintains the client virtual server, the virtual server monitoring system always possesses the correct hash values ​​of the files within the client virtual server software components.

[0164] S204. Using the remote proof session key, decrypt and execute the remote proof verification strategy according to the preset authentication encryption algorithm to obtain the remote proof verification result of whether the current self-state is in a trusted state.

[0165] The remote authentication policy determined by the virtual server monitoring system is encrypted using the AES-GCM algorithm and transmitted to the client virtual server. Correspondingly, the client virtual server needs to decrypt it before processing. Specifically, step S204 includes the following sub-steps:

[0166] S2041. Using the remote proof session key, the remote proof verification strategy is decrypted according to the preset authentication encryption algorithm to obtain the platform configuration register index of the client virtual server and the file name and base value of the file to be audited corresponding to the platform configuration register index; wherein, the preset authentication encryption algorithm is the AES-GCM algorithm, the first random number is used as the additional data used when the preset authentication encryption algorithm is decrypted, the second random number is used as the initial vector used when the preset authentication encryption algorithm is decrypted, and the first tag is used as the authentication tag of the remote proof verification strategy;

[0167] S2042. Obtain the platform configuration register value corresponding to itself using the platform configuration register index and the first random number as parameters, and obtain the storage metric log corresponding to itself based on the platform configuration register value. Based on the storage metric log and the benchmark value, check the integrity of the file obtained by the remote proof verification strategy decryption, and obtain the remote proof verification result of whether itself is in a trusted state. If the integrity check passes, it is in a trusted state.

[0168] Specifically, the client virtual server invokes the AES-GCM algorithm using the remote proof session key, the remote proof verification policy authentication tag in the encrypted remote proof verification policy, the initialization vector, and additional data to perform a decryption operation on the ciphertext of the encrypted remote proof verification policy, thereby obtaining the remote proof verification policy. The calculation process can be represented as follows:

[0169] RAP = Decrypt(AES-GCM,KSK,S_RAP,TAG1,IV,AAD);

[0170] Wherein, RAP is the remote proof verification strategy; Decrypt represents decryption operation; KSK is the remote proof session key; S_RAP is the remote proof verification strategy ciphertext; TAG1 is the remote proof verification strategy authentication tag, which is the first tag in this embodiment; AAD is the additional data required for the AES-GCM algorithm decryption operation, which uses the first random number N1 in this embodiment; IV is the initial vector required for the AES-GCM algorithm decryption operation, which uses the second random number N2 in this embodiment.

[0171] Furthermore, the client virtual server verifies the integrity of its own content based on the decrypted remote proof verification strategy. The verification process is as follows:

[0172] The client virtual server uses the SMC secure communication mechanism to call the vTPM's tpm2_quote interface to pass the PCR index (10 is used as an example in this embodiment) and the first random number N1 to the vTPM;

[0173] vTPM returns PCR

[10] and a signature bound to the first random number N1, signed by the private key SK_CVM, to RAA through the tpm2_quote interface;

[0174] The above signature is verified using the public key PK_CVM. If the signature verification is successful, the obtained PCR value is considered trustworthy.

[0175] It should be noted that the method of passing the PCR index and the first random number N1 through the tpm2_quote interface, and the method of vTPM returning the PCR

[10] and the signature signed by the private key SK_CVM and bound to the first random number N1 through the tpm2_quote interface, is defined by the TCG Trusted Platform Module Technical Specification. According to the definition of the tpm2_quote interface in the TCG Trusted Platform Module Technical Specification, passing the first random number N1 to vTPM can make the returned signature carry the characteristics of the first random number N1, so that the attacker cannot replay the outdated (previous session) PCR value, thus ensuring security.

[0176] Furthermore, based on the determined PCR values, it is necessary to further verify the reliability of the corresponding SML. The client virtual server reads the SML from the operating system kernel of the REE (Rich Execution Environment) through the SMC secure communication mechanism;

[0177] The PCR value for replay is calculated using the hash expansion algorithm based on the hash values ​​of all measured files associated with the PCR index in the SML.

[0178] Compare the replayed PCR values ​​with the obtained PCR values. If they match, the SML can be confirmed as reliable.

[0179] Specifically, in the implementation process, reading the SML from the operating system kernel of the Rich Execution Environment (REE) refers to reading the SML from the Linux operating system kernel file system path. The hash expansion algorithm is a PCR value calculation method defined by the TCG Trusted Platform Module Technical Specification. It is used to calculate a new PCR value by hash expansion based on the hash value of the measured file and the current PCR value when performing integrity measurements. It is also used to calculate the replay PCR value by hash expansion based on the hash values ​​of each integrity measurement record associated with the specified PCR index in the SML when performing remote attestation. Its effectiveness and security have been widely recognized in the industry. The specific process of using the hash expansion algorithm to perform integrity measurements is as follows:

[0180] During the operation of the verified party (in this embodiment, the client virtual server), the IMA of the operating system kernel writes the hash value of each measured file into the SML (i.e., adds a new integrity measurement record associated with the specified PCR index in the SML). Simultaneously, it extends this hash value into the PCR corresponding to the specified PCR index within the vTPM through the vTPM's hash extension interface tpm2_pcr_extend (which implements the hash extension algorithm defined by the TCG Trusted Platform Module Technical Specification). Because each measured file is measured at different times, the hash values ​​in the integrity measurement records associated with the specified PCR index in the SML naturally have a sequential order (this order is called the hash value sequence).

[0181] Clearly, the PCR value corresponding to the specified PCR index within vTPM is the result of the hash expansion algorithm iteratively calculating based on the hash value sequence.

[0182] The specific process of using the hash expansion algorithm to perform remote proof is as follows: The party being verified (in this embodiment, a client virtual server, or a RAA running in its trusted execution environment) reads the hash values ​​(i.e., hash value sequences) from each integrity metric record associated with the specified PCR index from the SML, and iteratively calculates the PCR value sequentially based on the hash value sequence using the same hash expansion algorithm to obtain the replayed PCR value. If the SML has not been tampered with, the replayed PCR value will be exactly the same as the PCR value obtained through the tpm2_quote interface of vTPM (which has been verified by signature); otherwise, if the two are inconsistent, it indicates that the integrity of the SML has been compromised.

[0183] Based on this, step S2042 also requires verifying the integrity of all documents requiring auditing using SML and benchmark values, specifically:

[0184] Based on the filename of each file that needs to be audited in the remote proof verification strategy, find the integrity measurement record of each file in SML;

[0185] Extract the hash value of each file from the found integrity metric records and compare it with the baseline value of that file in the remote proof verification strategy;

[0186] If the hash values ​​of all files match the baseline value, all files to be audited are considered complete, and a remote proof verification result Result = 0x01 (indicating trustworthiness) is generated. If the hash value of any file does not match the baseline value, the file to be audited is considered to have been tampered with, and a remote proof verification result Result = 0x00 (indicating untrustworthiness) is generated. Based on the content of the remote proof verification result, when the virtual server monitoring system obtains this content, it can directly confirm whether the current client virtual server is in a trustworthy state.

[0187] S205. Use the remote proof session key to encrypt the remote proof verification result according to the preset authentication encryption algorithm, and send the encrypted remote proof verification result.

[0188] In step S205, the first random number is used as additional data for the preset authentication encryption algorithm, the second random number is used as the initial vector for the preset authentication encryption algorithm, and the second tag is used as the authentication tag for the remote proof verification result.

[0189] The encryption process for remote proof results can be represented by the following relationship:

[0190] {S_Result, TAG2} = Encrypt(AES-GCM, KSK, Result, IV, AAD);

[0191] Wherein, S_Result is the ciphertext of the remote proof verification result generated by the AES-GCM algorithm; TAG2 is the authentication tag of the remote proof verification result generated by the AES-GCM algorithm, which is the second tag in this embodiment; Encrypt represents encryption operation; KSK is the remote proof session key; Result is the remote proof verification result; AAD is the additional data required for the encryption operation of the AES-GCM algorithm, which uses the first random number N1 in this embodiment; IV is the initial vector required for the encryption operation of the AES-GCM algorithm, which uses the second random number N2 in this embodiment.

[0192] Understandably, by using the first random number N1 and the second random number N2 as input parameters for encryption by the AES-GCM algorithm, the binding between the remote proof verification result and the current remote proof session is further enhanced, so that the remote proof verification result transmitted in the current remote proof session can and can only be used in the current remote proof session.

[0193] Through the above embodiments one and two, the embodiments of the present invention describe the steps and flow of the proposed remote proof method from the perspectives of the virtual server monitoring system and the client virtual server, respectively. It can be understood that the remote proof event is actually implemented through the interaction between the virtual server monitoring system and the client virtual server. Therefore, steps S101 to S105 and steps S201 to S205 in the above embodiments one and two should also have a certain order in their implementation logic. Specifically, the remote proof method proposed in the embodiments of the present invention can also be described as follows, based on the interaction order between the virtual server monitoring system and the client virtual server:

[0194] S101. (By the virtual server monitoring system) verify the initial trusted state of the client virtual server. If the client virtual server is in a trusted state, exchange public keys for identity authentication credentials with the client virtual server. Then, negotiate with the client virtual server to obtain a remote proof base key according to a preset key exchange method.

[0195] S201. After the client virtual server is verified by the virtual server monitoring system to be in an initial trusted state, it exchanges identity authentication public keys with the virtual server monitoring system for each other's identity authentication credentials, and then negotiates with the virtual server monitoring system to obtain a remote proof base key according to a preset key exchange method.

[0196] In the initial verification and remote proof base key negotiation phases, steps S101 and S201 are actually the same step performed by different entities in the remote proof method.

[0197] S102, (by the virtual server monitoring system) derive a remote proof session key for performing remote proof based on the remote proof base key;

[0198] S202. (By the client virtual server) derive a remote proof session key for performing remote proof based on the remote proof base key.

[0199] Referring to the descriptions of steps S102 and S202 in Embodiment 1 and Embodiment 2, the derivation process of the remote proof session key actually has a sequential order. In this stage, the virtual server monitoring system first needs to generate a random number and a salt value, and then the virtual server monitoring system sends the parameters it generates to the client virtual server. Both derive the remote proof session key based on the same parameters.

[0200] S103. (By the virtual server monitoring system) determine the remote proof verification strategy for remote proof, and encrypt the remote proof verification strategy using the remote proof session key according to the preset authentication encryption algorithm before sending it out.

[0201] S203. (The client virtual server) receives the remote proof verification policy, wherein the remote proof verification policy is generated by the virtual server monitoring system and encrypted using the remote proof session key it possesses according to a preset authentication encryption algorithm before being sent out.

[0202] S204. (By the client virtual server) using the remote proof session key to decrypt and execute the remote proof verification strategy according to the preset authentication encryption algorithm, and obtain the remote proof verification result of whether its current state is in a trusted state.

[0203] S205. (By the client virtual server) encrypts the remote proof verification result using the remote proof session key according to the preset authentication encryption algorithm, and sends the encrypted remote proof verification result.

[0204] S104. (The virtual server monitoring system) receives the remote proof verification result. The remote proof verification result is obtained by the client virtual server after decrypting and executing the remote proof verification strategy according to the preset authentication encryption algorithm, and then encrypting it with the remote proof session key it possesses according to the preset authentication encryption algorithm and sending it out.

[0205] S105. (By the virtual server monitoring system) the remote proof session key is used to decrypt the remote proof verification result according to the preset authentication encryption algorithm, and a remote proof judgment result on whether the current client virtual server is trustworthy is obtained based on the remote proof verification result.

[0206] After the remote proof session key is derived, the actual remote proof process begins. This stage follows the logic of the virtual server monitoring system initiating the remote proof, the client virtual server executing the remote proof and obtaining the result, and the virtual server monitoring system receiving the result.

[0207] In the overall process of the remote verification method based on TEE proxy verification proposed in this embodiment of the invention, the client virtual server only returns the verification result to the virtual server monitoring system to indicate whether the client virtual server is trustworthy or untrustworthy, without transmitting any file hash value, file name or other characteristic information, so that even if the attacker intercepts the communication content, he will not be able to deduce the file content from the communication content.

[0208] Furthermore, the remote proof method proposed in this embodiment of the invention utilizes existing remote proof methods to verify the initial state of the client virtual server before it delivers the data to the tenant. The remote proof after the client virtual server delivers the data to the tenant adopts the technical solution of this invention, which is based on the dynamic measurement implemented by the operating system kernel IMA and vTPM in the rich execution environment REE, and follows the same TCG trusted platform module technical specifications.

[0209] In summary, the beneficial effects achieved by this invention are that it proposes a remote verification method based on TEE proxy verification. This method localizes the verification logic in the virtual server monitoring system and the trusted execution environment inside the client virtual server. Furthermore, the storage measurement logs of the client virtual server do not need to be sent to the virtual server monitoring system during the verification process; instead, the verification results only need to be returned to the virtual server monitoring system. This solves the data leakage problem that may occur when the storage measurement logs of the client virtual server are sent to the monitoring system. Moreover, the execution process of this invention is based on the existing cloud service architecture, making it easy to implement and highly compatible.

[0210] Example 3

[0211] This invention also provides a remote verification system 300 based on TEE proxy verification, please refer to... Figure 4 , Figure 4 This is a schematic diagram of the structure of a remote verification system based on TEE proxy verification provided in an embodiment of the present invention. It includes a first remote verification module 301 implemented in a virtual server monitoring system and a second remote verification module 302 implemented in a client virtual server based on its trusted execution environment. The first remote verification module 301 includes:

[0212] The first base key negotiation module 3011 is used to verify the initial trusted state of the client virtual server. When the client virtual server is in a trusted state, it exchanges identity authentication public keys with the client virtual server for each other's identity authentication credentials. Then, it negotiates with the client virtual server to obtain a remote proof base key according to a preset key exchange method.

[0213] The first session key derivation module 3012 is used to derive a remote proof session key for performing remote proof based on the remote proof base key;

[0214] The remote proof sending module 3013 is used to determine the remote proof verification strategy for remote proof, and to encrypt the remote proof verification strategy using the remote proof session key according to a preset authentication encryption algorithm before sending it out;

[0215] The first remote proof receiving module 3014 is used to receive the remote proof verification result. The remote proof verification result is obtained by the client virtual server decrypting and executing the remote proof verification strategy according to the preset authentication encryption algorithm, and then encrypting it with the remote proof session key it possesses according to the preset authentication encryption algorithm before sending it out.

[0216] The remote proof decryption module 3015 is used to decrypt the remote proof verification result using the remote proof session key according to the preset authentication encryption algorithm, and to obtain a remote proof judgment result on whether the current client virtual server is trustworthy based on the remote proof verification result;

[0217] The second remote verification module 302 includes:

[0218] The second base key negotiation module 3021 is used to negotiate with the virtual server monitoring system to obtain a remote proof base key after exchanging identity authentication public keys used for mutual identity authentication credentials with the virtual server monitoring system when it is verified by the virtual server monitoring system to be in an initial trusted state.

[0219] The second session key derivation module 3022 is used to derive a remote proof session key for performing remote proof based on the remote proof base key;

[0220] The second remote proof receiving module 3023 is used to receive a remote proof verification strategy, wherein the remote proof verification strategy is generated by the virtual server monitoring system and encrypted using the remote proof session key it possesses according to a preset authentication encryption algorithm before being sent out;

[0221] The remote proof execution module 3024 is used to use the remote proof session key to decrypt and execute the remote proof verification strategy according to the preset authentication encryption algorithm, and obtain the remote proof verification result of whether its current state is in a trusted state;

[0222] The remote proof encryption module 3025 is used to encrypt the remote proof verification result using the remote proof session key according to the preset authentication encryption algorithm, and to send the encrypted remote proof verification result.

[0223] The remote proof system 300 based on TEE proxy verification can implement the steps in the remote proof method based on TEE proxy verification as described in Embodiments 1 and 2 above, and can achieve the same technical effect. Referring to the description in the above embodiments, it will not be repeated here.

[0224] Example 3

[0225] This invention also provides a computer device, please refer to... Figure 5 , Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. The computer device 400 includes: a memory 402, a processor 401, and a computer program stored in the memory 402 and executable on the processor 401.

[0226] The processor 401 calls the computer program stored in the memory 402, which is implemented by the virtual server monitoring system acting as the verifier, and executes the steps in the remote verification method based on TEE proxy verification provided in Embodiment 1 of this invention. Please refer to... Figure 1 Specifically, it includes the following steps:

[0227] S101. Verify the initial trusted state of the client virtual server. If the client virtual server is in a trusted state, exchange identity authentication public keys with the client virtual server for each other's identity authentication credentials. Then, negotiate with the client virtual server to obtain a remote proof base key according to a preset key exchange method.

[0228] S102. Derive a remote proof session key for performing remote proof based on the remote proof base key;

[0229] S103. Determine the remote proof verification strategy for remote proof, and encrypt the remote proof verification strategy using the remote proof session key according to the preset authentication encryption algorithm before sending it out;

[0230] S104. Receive the remote proof verification result. The remote proof verification result is obtained by the client virtual server after decrypting and executing the remote proof verification strategy according to the preset authentication encryption algorithm, and then encrypting it using the remote proof session key it possesses according to the preset authentication encryption algorithm and sending it out.

[0231] S105. Using the remote proof session key, the remote proof verification result is decrypted according to the preset authentication encryption algorithm, and a remote proof judgment result regarding whether the current client virtual server is trustworthy is obtained based on the remote proof verification result.

[0232] Furthermore, step S101 includes the following sub-steps:

[0233] S1011. Create the client virtual server and verify its initial trusted state;

[0234] S1012. Send out the first identity authentication public key it possesses and obtain the second identity authentication public key; wherein, the second identity authentication public key is sent by the client virtual server;

[0235] S1013. Generate a first temporary key pair based on a preset key generation method. The first temporary key pair includes a first temporary public key and a first temporary private key. Sign the first temporary public key using the private key corresponding to the first identity authentication public key. Send out the signed first temporary public key.

[0236] S1014. Receive the second temporary public key and use the second identity authentication public key to sign and verify the second temporary public key. After the signature verification is successful, generate the remote proof base key according to the preset key exchange method using the first temporary private key and the second temporary public key as the data source. The second temporary public key is generated by the client virtual server based on the preset key generation method after receiving the first temporary public key and verifying the signature, and then signed with the private key corresponding to the second identity authentication public key before being issued.

[0237] Furthermore, the preset key generation method is the ECDSA digital signature algorithm; the preset key exchange method is the ECDH key negotiation algorithm.

[0238] Furthermore, step S102 includes the following sub-steps:

[0239] S1021. Generate a first random number and a second random number, and append the second random number to the end of the first random number to obtain a salt value;

[0240] S1022. Using the salt value and the remote proof base key as parameters of a preset key derivation algorithm, calculate the remote proof session key;

[0241] S1023. Send out the first random number, the second random number, and the salt value signed with the private key corresponding to the first identity authentication public key.

[0242] Furthermore, the preset key derivation algorithm is the HKDF key derivation algorithm.

[0243] Furthermore, in step S103, the remote proof verification strategy includes at least the platform configuration register index of the client virtual server and the file name and base value of the file to be audited corresponding to the platform configuration register index, wherein the file is a file in the software component when the client virtual server is created, and the base value is the hash value of the file;

[0244] The preset authentication encryption algorithm is the AES-GCM algorithm, and the first random number is used as the additional data used when the preset authentication encryption algorithm is encrypted, the second random number is used as the initial vector used when the preset authentication encryption algorithm is encrypted, and the first tag is used as the authentication tag of the remote proof verification strategy.

[0245] Furthermore, in step S105, the first random number is used as additional data for decryption by the preset authentication encryption algorithm, the second random number is used as the initial vector for decryption by the preset authentication encryption algorithm, and the second tag is used as the authentication tag for the remote proof verification result.

[0246] Alternatively, the processor 401 may call the computer program stored in the memory 402, which is implemented by the client virtual server (as the verified party) based on its trusted execution environment, and execute the steps in another remote verification method based on TEE proxy verification provided in Embodiment 2 of the present invention. Please refer to... Figure 3 Specifically, it includes the following steps:

[0247] S201. After being verified by the virtual server monitoring system to be in an initial trusted state, the user exchanges identity authentication public keys with the virtual server monitoring system for each other's identity authentication credentials, and then negotiates with the virtual server monitoring system to obtain a remote proof base key according to a preset key exchange method.

[0248] S202. Derive a remote proof session key for performing remote proof based on the remote proof base key;

[0249] S203. Receive remote proof verification strategy, wherein the remote proof verification strategy is generated by the virtual server monitoring system and encrypted using the remote proof session key it possesses according to a preset authentication encryption algorithm before being sent out;

[0250] S204. Using the remote proof session key, decrypt and execute the remote proof verification strategy according to the preset authentication encryption algorithm to obtain the remote proof verification result of whether the current self-state is in a trusted state;

[0251] S205. Use the remote proof session key to encrypt the remote proof verification result according to the preset authentication encryption algorithm, and send the encrypted remote proof verification result.

[0252] Furthermore, step S201 includes the following sub-steps:

[0253] S2011. The client virtual server verifies its initial trusted state through the virtual server monitoring system, wherein the client virtual server is created by the virtual server monitoring system;

[0254] S2012. Receive the first identity authentication public key and store it in its own trusted execution environment, and then send out its own second identity authentication public key; wherein, the first identity authentication public key is sent by the virtual server monitoring system;

[0255] S2013. Receive the first temporary public key and verify its signature using the first identity authentication public key. After successful signature verification, generate a second temporary key pair based on a preset key generation method. The second temporary key pair includes a second temporary public key and a second temporary private key. Generate the remote proof base key using the first temporary public key and the second temporary private key as data sources according to the preset key exchange method. Then, sign the second temporary public key with the private key corresponding to the second identity authentication public key and send it out. The first temporary public key is generated and signed by the virtual server monitoring system before being sent out.

[0256] Furthermore, step S202 includes the following sub-steps:

[0257] S2021. Receive a first random number, a second random number, and a salt value signed with the private key corresponding to the first identity authentication public key; wherein, the first random number, the second random number, and the salt value are all generated and sent by the virtual server monitoring system;

[0258] S2022. Verify the signature of the salt value using the first identity authentication public key. After the signature verification is successful, calculate the remote proof session key using the salt value and the remote proof base key as parameters of the preset key derivation algorithm.

[0259] Furthermore, step S204 includes the following sub-steps:

[0260] S2041. Using the remote proof session key, the remote proof verification strategy is decrypted according to the preset authentication encryption algorithm to obtain the platform configuration register index of the client virtual server and the file name and base value of the file to be audited corresponding to the platform configuration register index; wherein, the preset authentication encryption algorithm is the AES-GCM algorithm, the first random number is used as the additional data used when the preset authentication encryption algorithm is decrypted, the second random number is used as the initial vector used when the preset authentication encryption algorithm is decrypted, and the first tag is used as the authentication tag of the remote proof verification strategy;

[0261] S2042. Obtain the platform configuration register value corresponding to itself using the platform configuration register index and the first random number as parameters, and obtain the storage metric log corresponding to itself based on the platform configuration register value. Based on the storage metric log and the benchmark value, check the integrity of the file obtained by the remote proof verification strategy decryption, and obtain the remote proof verification result of whether itself is in a trusted state. If the integrity check passes, it is in a trusted state.

[0262] Furthermore, in step S205, the first random number is used as additional data when the preset authentication encryption algorithm is used for encryption, the second random number is used as the initial vector when the preset authentication encryption algorithm is used for encryption, and the second tag is used as the authentication tag of the remote proof verification result.

[0263] The computer device 400 provided in this embodiment of the invention can implement the steps in the remote proof method based on TEE proxy verification as described in the above embodiments, and can achieve the same technical effect. Referring to the description in the above embodiments, it will not be repeated here.

[0264] Example 4

[0265] This invention also provides a storage medium storing a remote proof program based on TEE proxy verification. When the remote proof program based on TEE proxy verification is executed by a processor, it implements the various processes and steps in the remote proof method based on TEE proxy verification provided in this invention and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0266] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by hardware related to computer programs or instructions. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0267] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0268] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0269] The embodiments of the present invention have been described above with reference to the accompanying drawings. The disclosed embodiments are merely preferred embodiments of the present invention. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many equivalent changes in form under the guidance of the present invention without departing from the spirit and scope of the claims. All such changes are within the protection scope of the present invention.

Claims

1. A remote verification method based on TEE proxy verification, characterized in that, The remote authentication method is implemented by a virtual server monitoring system acting as the verifier, and includes the following steps: S101. Verify the initial trusted state of the client virtual server. If the client virtual server is in a trusted state, exchange identity authentication public keys with the client virtual server for each other's identity authentication credentials. Then, negotiate with the client virtual server to obtain a remote proof base key according to a preset key exchange method. S102. Derive a remote proof session key for performing remote proof based on the remote proof base key; S103. Determine the remote proof verification strategy for remote proof, and encrypt the remote proof verification strategy using the remote proof session key according to the preset authentication encryption algorithm before sending it out; S104. Receive the remote proof verification result. The remote proof verification result is obtained by the client virtual server after decrypting and executing the remote proof verification strategy according to the preset authentication encryption algorithm, and then encrypting it using the remote proof session key it possesses according to the preset authentication encryption algorithm and sending it out. S105. Using the remote proof session key, the remote proof verification result is decrypted according to the preset authentication encryption algorithm, and a remote proof judgment result regarding whether the current client virtual server is trustworthy is obtained based on the remote proof verification result. Step S101 includes the following sub-steps: S1011. Create the client virtual server and verify its initial trusted state; S1012. Send out the first identity authentication public key it possesses and obtain the second identity authentication public key; wherein, the second identity authentication public key is sent by the client virtual server; S1013. Generate a first temporary key pair based on a preset key generation method. The first temporary key pair includes a first temporary public key and a first temporary private key. Sign the first temporary public key using the private key corresponding to the first identity authentication public key. Send out the signed first temporary public key. S1014. Receive the second temporary public key and use the second identity authentication public key to sign and verify the second temporary public key. After the signature verification is successful, generate the remote proof base key according to the preset key exchange method using the first temporary private key and the second temporary public key as the data source. The second temporary public key is generated by the client virtual server based on the preset key generation method after receiving the first temporary public key and verifying the signature, and then signed with the private key corresponding to the second identity authentication public key before being issued.

2. The remote verification method based on TEE proxy verification according to claim 1, characterized in that, The preset key generation method is the ECDSA digital signature algorithm; the preset key exchange method is the ECDH key negotiation algorithm.

3. The remote verification method based on TEE proxy verification according to claim 1, characterized in that, Step S102 includes the following sub-steps: S1021. Generate a first random number and a second random number, and append the second random number to the end of the first random number to obtain a salt value; S1022. Using the salt value and the remote proof base key as parameters of a preset key derivation algorithm, calculate the remote proof session key; S1023. Send out the first random number, the second random number, and the salt value signed with the private key corresponding to the first identity authentication public key.

4. The remote verification method based on TEE proxy verification according to claim 3, characterized in that, The preset key derivation algorithm is the HKDF key derivation algorithm.

5. The remote verification method based on TEE proxy verification according to claim 3, characterized in that, In step S103, the remote proof verification strategy includes at least the platform configuration register index of the client virtual server and the file name and base value of the file to be audited corresponding to the platform configuration register index. The file is a file in the software component when the client virtual server is created, and the base value is the hash value of the file. The preset authentication encryption algorithm is the AES-GCM algorithm, and the first random number is used as the additional data used when the preset authentication encryption algorithm is encrypted, the second random number is used as the initial vector used when the preset authentication encryption algorithm is encrypted, and the first tag is used as the authentication tag of the remote proof verification strategy.

6. The remote verification method based on TEE proxy verification according to claim 3, characterized in that, In step S105, the first random number is used as additional data for decryption by the preset authentication encryption algorithm, the second random number is used as the initial vector for decryption by the preset authentication encryption algorithm, and the second tag is used as the authentication tag for the remote proof verification result.

7. A remote verification method based on TEE proxy verification, characterized in that, The remote proof method is implemented by a client virtual server, acting as the verified party, based on its trusted execution environment. The remote proof method includes the following steps: S201. After being verified by the virtual server monitoring system to be in an initial trusted state, the system exchanges identity authentication public keys with the virtual server monitoring system for each other's identity authentication credentials, and then negotiates with the virtual server monitoring system to obtain a remote proof base key according to a preset key exchange method. S202. Derive a remote proof session key for performing remote proof based on the remote proof base key; S203. Receive remote proof verification strategy, wherein the remote proof verification strategy is generated by the virtual server monitoring system and encrypted using the remote proof session key it possesses according to a preset authentication encryption algorithm before being sent out; S204. Using the remote proof session key, decrypt and execute the remote proof verification strategy according to the preset authentication encryption algorithm to obtain the remote proof verification result of whether the current self-state is in a trusted state; S205. Encrypt the remote proof verification result using the remote proof session key according to the preset authentication encryption algorithm, and send the encrypted remote proof verification result. Step S201 includes the following sub-steps: S2011. The client virtual server verifies its initial trusted state through the virtual server monitoring system, wherein the client virtual server is created by the virtual server monitoring system; S2012. Receive the first identity authentication public key and store it in its own trusted execution environment, and then send out its own second identity authentication public key; wherein, the first identity authentication public key is sent by the virtual server monitoring system; S2013. Receive the first temporary public key and verify its signature using the first identity authentication public key. After successful signature verification, generate a second temporary key pair based on a preset key generation method. The second temporary key pair includes a second temporary public key and a second temporary private key. Generate the remote proof base key using the first temporary public key and the second temporary private key as data sources according to the preset key exchange method. Then, sign the second temporary public key with the private key corresponding to the second identity authentication public key and send it out. The first temporary public key is generated and signed by the virtual server monitoring system before being sent out.

8. The remote verification method based on TEE proxy verification according to claim 7, characterized in that, Step S202 includes the following sub-steps: S2021. Receive a first random number, a second random number, and a salt value signed with the private key corresponding to the first identity authentication public key; wherein, the first random number, the second random number, and the salt value are all generated and sent by the virtual server monitoring system; S2022. Verify the signature of the salt value using the first identity authentication public key. After the signature verification is successful, calculate the remote proof session key using the salt value and the remote proof base key as parameters of the preset key derivation algorithm.

9. The remote verification method based on TEE proxy verification according to claim 8, characterized in that, Step S204 includes the following sub-steps: S2041. Using the remote proof session key, the remote proof verification strategy is decrypted according to the preset authentication encryption algorithm to obtain the platform configuration register index of the client virtual server and the file name and base value of the file to be audited corresponding to the platform configuration register index; wherein, the preset authentication encryption algorithm is the AES-GCM algorithm, the first random number is used as the additional data used when the preset authentication encryption algorithm is decrypted, the second random number is used as the initial vector used when the preset authentication encryption algorithm is decrypted, and the first tag is used as the authentication tag of the remote proof verification strategy; S2042. Obtain the platform configuration register value corresponding to itself using the platform configuration register index and the first random number as parameters, and obtain the storage metric log corresponding to itself based on the platform configuration register value. Based on the storage metric log and the benchmark value, check the integrity of the file obtained by the remote proof verification strategy decryption, and obtain the remote proof verification result of whether itself is in a trusted state. If the integrity check passes, it is in a trusted state.

10. The remote verification method based on TEE proxy verification according to claim 9, characterized in that, In step S205, the first random number is used as the additional data used when encrypting with the preset authentication encryption algorithm, the second random number is used as the initial vector used when encrypting with the preset authentication encryption algorithm, and the second tag is used as the authentication tag of the remote proof verification result.

11. A remote verification system based on TEE (Telecommunications Equipment Proxy) verification, characterized in that, The remote authentication system includes a first remote authentication module implemented in a virtual server monitoring system and a second remote authentication module implemented in a client virtual server based on its trusted execution environment, wherein the first remote authentication module includes: The first base key negotiation module is used to verify the initial trusted state of the client virtual server. When the client virtual server is in a trusted state, it exchanges identity authentication public keys with the client virtual server for each other's identity authentication credentials. Then, it negotiates with the client virtual server to obtain a remote proof base key according to a preset key exchange method. The first session key derivation module is used to derive a remote proof session key for performing remote proof based on the remote proof base key; The remote proof sending module is used to determine the remote proof verification strategy for remote proof, and to encrypt the remote proof verification strategy using the remote proof session key according to a preset authentication encryption algorithm before sending it out; The first remote proof receiving module is used to receive the remote proof verification result. The remote proof verification result is obtained by the client virtual server decrypting and executing the remote proof verification strategy according to the preset authentication encryption algorithm, and then encrypting it with the remote proof session key it possesses according to the preset authentication encryption algorithm before sending it out. The remote proof decryption module is used to decrypt the remote proof verification result using the remote proof session key according to the preset authentication encryption algorithm, and obtain a remote proof judgment result on whether the current client virtual server is trustworthy based on the remote proof verification result; The second remote verification module includes: The second base key negotiation module is used to negotiate a remote proof base key with the virtual server monitoring system after exchanging identity authentication public keys used for mutual identity authentication credentials with the virtual server monitoring system when it is verified by the virtual server monitoring system to be in an initial trusted state. The second session key derivation module is used to derive a remote proof session key for performing remote proof based on the remote proof base key; The second remote proof receiving module is used to receive the remote proof verification strategy, wherein the remote proof verification strategy is generated by the virtual server monitoring system and encrypted using the remote proof session key it possesses according to a preset authentication encryption algorithm before being sent out; The remote proof execution module is used to decrypt and execute the remote proof verification strategy using the remote proof session key according to the preset authentication encryption algorithm, and obtain the remote proof verification result of whether its current state is in a trusted state; The remote proof encryption module is used to encrypt the remote proof verification result using the remote proof session key according to the preset authentication encryption algorithm, and then send the encrypted remote proof verification result.

12. A computer device, characterized in that, include: The system includes a memory, a processor, and a remote proof program based on TEE proxy verification stored on the memory and executable on the processor. When the processor executes the remote proof program based on TEE proxy verification, it implements the steps of the remote proof method based on TEE proxy verification as described in any one of claims 1-6 or 7-10.

13. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the steps of the remote proof method based on TEE proxy verification as described in any one of claims 1-6 or 7-10.

Images