Heterogeneous remote attestation method and system based on proxy re-signature assistance

Abstract

The application discloses a heterogeneous remote attestation method and system based on proxy re-signature assistance, belongs to the technical field of information security, and is characterized in that two heterogeneous TEE nodes are respectively taken as a challenge party and a proving party, a joint remote verification proxy module is used for heterogeneous remote attestation, and the method comprises the following steps: the challenge party sends a challenge to the proving party; the proving party receives the challenge, generates a local report according to the TEE technology of the proving party platform, generates a primary signature and a node signature, and then sends a remote attestation request to the remote verification proxy module; the remote verification proxy module verifies the node signature first, then calls the verification logic corresponding to the TEE type of the proving party, verifies the local report, generates a proof result, generates a re-signature, and returns a remote attestation response message to the proving party; the proving party verifies the re-signature, and after confirmation, forwards the remote attestation response message to the challenge party; and the remote attestation is completed after being verified by the challenge party. The application can realize safer and more reliable remote attestation interaction.

Description

Technical Field

[0001] This invention belongs to the field of information security technology, and in particular relates to a heterogeneous remote proof method and system based on proxy resignature assistance. Background Technology

[0002] With the rise of the internet, network and information security technologies are constantly evolving and developing. Cutting-edge technologies such as cloud computing, the Internet of Things (IoT), and blockchain are profoundly reshaping existing lifestyles and work patterns. While these technologies bring convenience and efficiency, they also raise a series of new security issues, rendering traditional security technologies inadequate for ensuring information security. Addressing these issues requires moving away from passive defense and controlling insecure factors at the source. Remote authentication technology, as a key solution to these problems, can effectively verify the security and trustworthiness of remote devices in complex network environments. This remote authentication technology relies on a Trusted Execution Environment (TEE), providing remote devices with an isolated and secure operating space, enabling them to securely execute sensitive operations and store sensitive data. Currently, various TEE technologies have been researched, including but not limited to AMD SEV (memory encryption), Intel SGX (Software Guard eXtensions), ARM TrustZone (hardware isolation technology), and domestic technologies such as Hygon, Kunpeng, and Phytium. This diversity of technologies has fostered market prosperity but has also brought challenges to standardization.

[0003] In the current information technology field, the lack of a unified Trusted Execution Environment (TEE) technical specification leads to compatibility issues between products from different manufacturers. This not only increases development costs and complexity but may also affect the performance and efficiency of privacy-preserving computing applications. To promote the widespread adoption of privacy-preserving computing, there is an urgent need to develop a unified cross-platform standard. This would simplify the development process, enhance interoperability between TEE applications, and improve overall work efficiency. However, in practice, directly unifying the standards of different products from different vendors is extremely difficult.

[0004] Furthermore, during the development of privacy computing systems, the system gradually began to focus on the collaborative work between heterogeneous TEEs, but often neglected the security issues of interaction between TEEs. This neglect may expose the system to security threats such as man-in-the-middle attacks, and make it impossible to ensure the security of data interaction. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a heterogeneous remote proof method and system based on proxy re-signature assistance. A remote verification proxy module is constructed as the core component. This module centrally manages and coordinates all differentiated logic in the remote proof process, effectively addressing compatibility issues between different TEE platforms. Furthermore, the security features of proxy re-signature technology are considered, and this technology is introduced into the remote proof of heterogeneous TEEs. This effectively enhances the security and trust between heterogeneous TEEs during data exchange and provides anonymity support, overcoming the drawbacks of existing TEE implementations and meeting the security requirements of the remote proof interaction process.

[0006] In a first aspect, the present invention provides a heterogeneous remote proof method based on proxy resignature assistance.

[0007] A heterogeneous remote proof method based on proxy re-signature assistance, in which two heterogeneous TEE nodes act as the challenger and prover respectively, and jointly perform heterogeneous remote proof with a remote verification proxy module, including:

[0008] The challenger sends a challenge to the proving party;

[0009] The proving party receives the challenge, generates a local report based on the proving party platform's TEE technology, generates an initial signature for the local report and the challenge, generates a node signature for the initial signature, the local report and the TEE type, constructs a remote proof request and sends it.

[0010] The remote verification agent module receives a remote proof request, first verifies the node signature to confirm the correctness of the request, then calls the verification logic of the corresponding proof party TEE type to verify the local report, then calls the resignature generation algorithm to generate a resignature for the initial signature, and combines it with the local report to form a remote proof response message and return it to the proof party.

[0011] The proving party receives the remote proof response message, verifies the resignature, and forwards the remote proof response message to the challenger. After verification by the challenger, the remote proof is completed.

[0012] Secondly, this invention also proposes a heterogeneous remote proof system based on proxy resignation assistance.

[0013] A heterogeneous remote proof system based on proxy resignature assistance includes two heterogeneous TEE nodes acting as the challenger and the prover, respectively, and a remote verification proxy module;

[0014] The challenger sends a challenge to the prover;

[0015] The prover is used to receive challenges, generate a local report based on the prover platform's TEE technology, generate an initial signature for the local report and challenge, generate a node signature for the initial signature, local report and TEE type, construct a remote proof request and send it.

[0016] The remote verification agent module is used to receive remote proof requests. First, it verifies the node signature to confirm the correctness of the request. Then, it calls the verification logic of the corresponding proof party TEE type to verify the local report. Next, it calls the resignature generation algorithm to generate a resignature for the initial signature and combines it with the local report to form a remote proof response message to be returned to the proof party.

[0017] The proving party receives the remote proof response message, verifies the resignature, and forwards the remote proof response message to the challenger after confirmation.

[0018] The challenger receives the remote proof response message, verifies the resignature, and completes the remote proof for the challenger upon confirmation.

[0019] Thirdly, the present invention also provides an electronic device, comprising: a memory for storing executable instructions; and a processor for implementing the above-described heterogeneous remote proof method based on proxy resignature assistance when executing the executable instructions stored in the memory.

[0020] Fourthly, the present invention also provides a computer-readable storage medium storing executable instructions for causing a processor to execute the executable instructions to implement the above-described heterogeneous remote proof method based on proxy resignature assistance.

[0021] The above one or more technical solutions have the following beneficial effects:

[0022] 1. This invention provides a heterogeneous remote proof method and system based on proxy resignature assistance. A remote verification proxy module is constructed as the core component. This module is used to centrally manage and coordinate all the differentiated logic in the remote proof process, effectively addressing the compatibility issues between different TEE platforms, solving the drawbacks of existing TEE implementations, and avoiding the practical difficulties faced in formulating cross-platform unified standards. Based on the design of this module, heterogeneous TEEs can perform unified remote proof, and data collaboration with different TEE architectures can normally complete data collaboration through the privacy computing platform.

[0023] 2. The method proposed in this invention also considers the security features of proxy re-signature technology, introduces this technology into remote proof of heterogeneous TEEs, and proposes a remote proof method based on proxy re-signature that supports node interaction between heterogeneous TEEs. This allows heterogeneous TEE nodes to hide the random string nonce value used as a challenge while maintaining anonymity, preventing man-in-the-middle attacks and enabling secure and effective bidirectional remote proof. This effectively enhances the security and trust between heterogeneous TEEs during data exchange and meets the security requirements of the remote proof interaction process. Attached Figure Description

[0024] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0025] Figure 1 This is an overall flowchart of the heterogeneous remote proof method based on proxy resignature assistance as described in an embodiment of the present invention;

[0026] Figure 2 This is an overall framework diagram of the heterogeneous remote proof mechanism based on proxy resignature assistance in an embodiment of the present invention;

[0027] Figure 3 This is a schematic diagram of an abstract model of the remote proof process in an embodiment of the present invention;

[0028] Figure 4 This is a flowchart illustrating the specific process of heterogeneous TEE remote proof interaction in an embodiment of the present invention. Detailed Implementation

[0029] It should be noted that the following detailed descriptions are exemplary and are intended only to describe specific embodiments and to provide further explanation of the invention, and are not intended to limit the scope of exemplary embodiments of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0030] Example 1

[0031] As a type of advanced digital signature technology, proxy re-signature technology allows a trusted, non-trusted agent to transform an existing signature and generate a new signature that appears to be directly signed by the principal. This technology is suitable for scenarios requiring protection of the signer's identity or concealment of the signer's public key, while ensuring the validity and non-repudiation of the signature. Therefore, this embodiment introduces this proxy re-signature technology and proposes a private key-based proxy re-signature scheme. The agent holds a special private key that can transform the trustee's original signature to generate a new digital signature representing the principal's identity. The use of this proxy re-signature key provides the system with a flexible and robust security mechanism, enabling verification of signature authenticity without revealing the principal's public key.

[0032] In other words, this embodiment not only proposes a privacy-preserving computation method supporting interaction between heterogeneous TEEs, but also incorporates proxy re-signature technology to enhance security and trust during data exchange. This combination of technologies achieves key objectives such as cross-TEE interoperability, privacy protection, and resistance to man-in-the-middle attacks, solving security issues in existing privacy-preserving computation systems. Furthermore, by leveraging the isolation characteristics of TEEs and the anonymity of proxy re-signatures, it provides users with a solid foundation for secure interaction, helping to protect user privacy, build trust, and promote the practical application and widespread deployment of privacy-preserving computation systems.

[0033] The heterogeneous remote proof method based on proxy re-signature assistance proposed in this embodiment has good practicality. It mainly includes a remote verification proxy module, a node registration mechanism, and a bidirectional proof mechanism for heterogeneous TEE nodes based on proxy re-signature. Figure 1 As shown, two heterogeneous TEE nodes act as the challenger and prover, respectively, and work together with the remote verification proxy module to perform heterogeneous remote proof, specifically including the following steps:

[0034] The challenger sends a challenge to the proving party;

[0035] The proving party receives the challenge, generates a local report based on the proving party platform's TEE technology, generates an initial signature for the local report and the challenge, and generates a node signature for the initial signature, the local report and the TEE type, thereby constructing a remote proof request and sending it to the remote verification proxy module.

[0036] The remote verification agent module receives a remote proof request, first verifies the node signature to confirm the correctness of the request, then calls the verification logic of the corresponding proof party TEE type to verify the local report and generate the proof result, then calls the resignature generation algorithm to generate a resignature for the initial signature, and combines it with the local report to form a remote proof response message and return it to the proof party.

[0037] The proving party receives the remote proof response message, verifies and re-signs it, and then forwards the remote proof response message to the challenger. After the challenger verifies it, the remote proof is completed. That is, the challenger receives the remote proof response message, verifies and re-signs it, and then completes the remote proof for the challenger.

[0038] The following content provides a more detailed description of the heterogeneous remote proof (or remote verification) method based on proxy resignature assistance proposed in this embodiment.

[0039] In this embodiment, firstly, the standard procedure for unified remote verification is as follows:

[0040] (1) The challenger first sends a challenge to the target node to be proven (i.e., the prover);

[0041] (2) The target platform (i.e., the TEE platform) of the target node uses its own TEE technology to generate a unique TEE proof report;

[0042] (3) Return the certification report to the certifying party;

[0043] (4) The certifying party verifies the certifying report based on the TEE technology type of the target platform.

[0044] Based on the aforementioned unified remote verification standard process, this embodiment proposes a remote verification mechanism for heterogeneous TEEs, the architecture of which is as follows: Figure 2 As shown, the proposed remote verification method is technically based on the classic challenge-response protocol framework. For heterogeneous TEE environments, it allows for flexible adjustment of the logic for generating and verifying reports according to the specific characteristics of different TEE products, ensuring the universality and adaptability of the method.

[0045] In this embodiment, the aforementioned remote verification proxy module, as a key component of the privacy computing system, operates independently, integrating the remote verification logic corresponding to all TEE types to centrally handle the differentiated logic of all remote proofs. The design goal of this proxy module is to unify and coordinate the remote proof process between heterogeneous TEE platforms, simplifying the proof logic between different TEE platforms, so that each TEE platform does not need to specifically adapt to the proof mechanism of heterogeneous TEEs.

[0046] Based on the aforementioned remote verification proxy module, the two heterogeneous TEE nodes, acting as the challenger and prover respectively, collaborate with the remote verification proxy module to perform heterogeneous remote proof, specifically including:

[0047] First, before the heterogeneous remote verification between the challenger and prover, a node registration mechanism is used. Each heterogeneous TEE node requests node registration from the remote verification agent module and obtains an AK certificate generated by the remote verification agent module. This node registration mechanism aims to ensure that heterogeneous TEE nodes can securely access the system and obtain certificates from the remote verification agent module.

[0048] The specific steps of the node registration mechanism include:

[0049] Step S1.1: Each heterogeneous TEE node first generates a public-private key pair for verifying its identity with the remote authentication agent module and a DH shared key for establishing a subsequent session; at the same time, the remote authentication agent module generates its own public-private key and root certificate.

[0050] Step S1.2: Each heterogeneous TEE node provides its own identity information (i.e., ID information), DH shared key, and public key to the remote verification agent module and requests node registration;

[0051] Step S1.3: After receiving the node registration request, the remote verification agent module generates the node's AK certificate based on the node's public key, and sends the AK certificate, root certificate, and DH shared key value of all nodes to the corresponding heterogeneous TEE node.

[0052] Step S1.4: Each heterogeneous TEE node obtains the root certificate of the remote verification agent module, the DH shared key value of other nodes, and the AK certificate used for remote verification, and completes the registration of the current node.

[0053] In addition, in the above process, for each heterogeneous node, the shared key between the corresponding two nodes is calculated based on the DH shared key values ​​of all nodes obtained after the node registration.

[0054] Secondly, the two heterogeneous TEE nodes, acting as the challenger and the prover respectively, perform heterogeneous remote proof according to the remote proof mechanism of heterogeneous TEE nodes based on proxy re-signature. The specific steps include:

[0055] Step S2.1: The challenger initiates a challenge to the prover, which includes a randomly generated string nonce value encrypted using the shared key.

[0056] Step S2.2: The proving party receives the challenge, decrypts it using the shared key to obtain the nonce value, and generates a local report based on its own platform's TEE technology; it combines the nonce value to generate a message signature for the local report and the nonce value as the initial signature; then it generates a node signature for the initial signature, the local report, and the TEE type; based on the initial signature, the local report, the TEE type, and the node signature, it constructs a remote proof request and sends it to the remote verification proxy module to request the remote verification proxy module to endorse the local report and provide a remote proof response message.

[0057] Step S2.3: After receiving the remote verification request, the remote verification agent module performs verification, including: verifying the node signature to confirm the legitimacy of the node from which the request originated; calling the verification logic of the corresponding TEE type to verify the local report and generate the verification result.

[0058] Specifically, the completeness and correctness of the request content are confirmed by verifying the node signature. If the request is verified to be complete and correct, it means that the node from which the request originated is legitimate and correct.

[0059] Furthermore, if the proof result indicates that the local report is trustworthy, a proxy resigning key is generated using the user's private key and the prover's public key. This key is then used to generate a resigned signature for the initial signature in the request, and together with the local report, forms a remote proof response message, which is returned to the prover. Otherwise, a message is returned to the prover indicating that the local report is untrustworthy.

[0060] Step S2.4: The proving party receives the returned remote proof response message, verifies the correctness of the re-signature, confirms that the message has not been tampered with, and then forwards the remote proof response message to the challenger.

[0061] Step S2.5: The challenger receives the remote proof response message, verifies the correctness of the re-signature, confirms that the message has not been tampered with, and accepts the proof result. At this point, the proof is complete.

[0062] In this embodiment, the process of the bidirectional proof mechanism based on proxy resigning of heterogeneous TEE nodes is the same as the remote proof mechanism described above, only requiring the challenger and prover to be swapped.

[0063] The abstract model of the remote proof process in this embodiment is as follows: Figure 3 As shown, after each proving party's TEE platform receives a challenge, it sends a local report to the Validator (i.e., the remote verification agent module). The Validator verifies the local report by calling the corresponding verification logic and sends the proof result back to the proving party's platform, which then forwards it to the challenging party's platform.

[0064] The specific process of bidirectional proof based on proxy re-signature for heterogeneous TEE nodes proposed in this embodiment is as follows: Figure 4 As shown, this example illustrates bidirectional remote proof between two heterogeneous TEE nodes: a Software Protection Extension (SGX) node and a Hygon node. In fact, this embodiment supports TEE technologies released by mainstream computing chip manufacturers, including domestic companies such as Hygon, Zhaoxin, Phytium, Kunpeng, Intel, AMD, and ARM.

[0065] This embodiment employs a bilinear mapping, where the global parameters involved are: Bilinear mapping , For the group generator (i.e.) A subgroup of order p is a prime number. (For safety parameters) It is a hash function that maps strings of arbitrary length to hash values. The elements in and These are the integer multiplication group modulo p and the integer ring modulo q, respectively.

[0066] In this embodiment, the specific process of node registration includes the following steps:

[0067] Step A1: The SGX node first generates a public-private key pair. Randomly select one ,Will As a private key and generate a public key. In addition, a public key is generated for use in DH key exchange. Similarly, a Haiguang node is randomly selected. Generate public-private key pairs ,in , In addition, it also generates DH Public Key The Validator then randomly selects one. Generate public-private key pairs ,in , In addition, Validator also generates its own root certificate. ,in, It is a randomly selected large integer, which is the private key used for key exchange; the root certificate is generated using OpenSSL tools and follows the X.509 standard format;

[0068] Step A2: The SGX node and the Hygon node send their ID information, AK public key, and DH key exchange public key to the Validator to request node registration.

[0069] Step A3: After receiving the request, the Validator generates an AK certificate based on the AK public key. and These correspond to SGX nodes and Hygon nodes respectively (AK certificates are generated using OpenSSL tools and follow the X.509 standard format);

[0070] Step A4: The Validator will issue the AK certificate for the SGX node. The median value of all existing nodes With its own local root certificate Send it along with the AK certificate to the SGX node, which will be issued for the Hygon node. DH keys of all existing nodes With its own local root certificate Send them together to the Hygon node;

[0071] Step A5: The SGX node and the Hygon node respectively store the corresponding certificates and intermediate values, and calculate the shared key. For use in remote verification processes.

[0072] In this embodiment, bidirectional remote verification is a process in which two heterogeneous TEE nodes remotely verify each other, similar to TLS bidirectional verification. Taking the verification of the SGX node by the Hygon node as an example, the specific process of unidirectional remote verification includes the following steps:

[0073] Step B1: The Hygon node, acting as the challenger, challenges the SGX node, acting as the prover, by generating a random string (nonce) and using the shared key. Encrypt to obtain Send to the SGX node.

[0074] Step B2: The SGX node first uses its own shared key. Decrypt 'c' to obtain the nonce, and generate a local report of type Intel SGX; perform initial signing on the nonce to obtain the signature. The calculation of R and s is as follows: Select a random number ,make , then calculate ; and then use its own Generate node signature Node signature The content includes: message signature TEE type Node ID information as well as reportFinally, considering that the correctness of a signature can only be verified based on the signature content and the public key, a remote proof request is constructed. Includes: message signature TEE type Node ID information, report, and node signature ; will request Send it to the Validator to request the Validator to endorse the local report and provide a remote verification response message.

[0075] Step B3: The Validator receives the request. Then, first use the SGX public key. Verify node signature Confirm the legitimacy of node SGX and compare. The correctness of the above information is verified; after confirming the correctness of the above information, the corresponding SGX verification interface is called according to the TEE type to obtain the verification result of the report; if the verification result is credible, the Validator then calls the re-signature key generation algorithm, based on its own public and private keys and the received SGX message signature public key. Generate message resigning key Then, a resignature is generated from the initial signature. The calculation process is as follows: First, a random number is selected. ,make , The generated resignature is The validator will then... ||The report is sent to the SGX node; if the result is found to be unreliable, then msg2=0 is sent.

[0076] Step B4: The SGX node receives the remote proof response message. Verify the re-signature result and confirm. Established, will Forward to the Hygon node.

[0077] Step B5: The Hygon node also verifies the re-signature result and confirms it. Once established and the local report of SGX is confirmed to be credible, remote verification of the SGX node can be completed.

[0078] Furthermore, in this embodiment, the identities of the two heterogeneous TEE nodes, which were originally the challenger and the prover, are swapped. The original challenger's heterogeneous TEE node becomes the prover, and the original prover's heterogeneous TEE node becomes the challenger. Then, heterogeneous remote proof is performed again on the two pairs of heterogeneous TEE nodes with swapped identities, achieving bidirectional remote proof of heterogeneous TEE nodes based on proxy re-signature. The process of SGX node verifying Hygon nodes is basically the same as the above-described Hygon node verifying SGX node, with the only difference being the node generating local report and the Validator verifying the report. For Hygon nodes, the generated report uses a Hygon-specific format, while the Validator performs verification according to Hygon's verification logic.

[0079] The method proposed in this embodiment has cross-architecture remote proof capability. Through flexible remote proof methods, it can be seamlessly integrated into existing system architectures and supports operation across diverse TEE platforms, thus ensuring its wide applicability and flexibility. This method can enhance security by employing advanced encryption technology to effectively hide the critical random string nonce value, thereby resisting various network threats, including man-in-the-middle attacks and replay attacks. This feature significantly improves the security of the remote proof process.

[0080] By introducing proxy re-signature technology, the method proposed in this embodiment not only enhances the security of data exchange between heterogeneous TEE environments but also improves the privacy protection capabilities of the entire system. During the signature conversion process, the proxy leaves no traceable information that could identify the principal, thus protecting the principal's anonymity while ensuring data integrity and the authenticity of its source. Furthermore, the proxy re-signature technology in this method is also resistant to man-in-the-middle attacks. Since the proxy cannot independently generate a valid signature, any man-in-the-middle attempting to intercept and tamper with the data will be unable to generate a valid proxy signature, thereby guaranteeing the security of data transmission. This method proposed in this embodiment can provide users in more fields such as the Internet of Things with a fast and secure method for remote verification between heterogeneous TEEs.

[0081] Example 2

[0082] This embodiment provides a heterogeneous remote proof system based on proxy resignature assistance, including two heterogeneous TEE nodes acting as the challenger and prover respectively, and a remote verification proxy module, wherein:

[0083] The challenger sends a challenge to the prover;

[0084] The prover is used to receive challenges, generate a local report based on the prover platform's TEE technology, generate an initial signature for the local report and challenge, generate a node signature for the initial signature, local report and TEE type, construct a remote proof request and send it.

[0085] The remote verification agent module is used to receive remote proof requests. First, it verifies the node signature to confirm the correctness of the request. Then, it calls the verification logic of the corresponding proof party TEE type to verify the local report. Next, it calls the resignature generation algorithm to generate a resignature for the initial signature and combines it with the local report to form a remote proof response message to be returned to the proof party.

[0086] The proving party receives the remote proof response message, verifies the resignature, and forwards the remote proof response message to the challenger after confirmation.

[0087] The challenger receives the remote proof response message, verifies the resignature, and completes the remote proof for the challenger upon confirmation.

[0088] Example 3

[0089] This embodiment provides an electronic device, including: a memory for storing executable instructions; and a processor for executing the executable instructions stored in the memory to implement the method provided in this embodiment.

[0090] Example 4

[0091] This embodiment also provides a computer-readable storage medium storing executable instructions, which, when executed by a processor, will cause the processor to execute the method described above in this embodiment.

[0092] The steps and methods involved in Embodiments 2 to 4 above correspond to those in Embodiment 1. For specific implementation details, please refer to the relevant description section of Embodiment 1. The term "computer-readable storage medium" should be understood as a single medium or multiple media including one or more instruction sets; it should also be understood as including any medium capable of storing, encoding, or carrying an instruction set for execution by a processor and enabling the processor to perform any of the methods in this invention.

[0093] Those skilled in the art will understand that the modules or steps of the present invention described above can be implemented using general-purpose computer devices. Optionally, they can be implemented using computer-executable program code, thereby allowing them to be stored in a storage device for execution by a computer device, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. The present invention is not limited to any particular combination of hardware and software.

[0094] The above description is only a preferred embodiment of the present invention. Although the specific implementation of the present invention has been described in conjunction with the accompanying drawings, it is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that, based on the technical solution of the present invention, various modifications or variations that can be made by those skilled in the art without creative effort are still within the scope of protection of the present invention.

Claims

1. A heterogeneous remote attestation method based on proxy re-signature assistance, characterized in that, Two isomeric TEE nodes are respectively as a challenge party and a proving party, jointly remote verification agent module, and perform isomeric remote proving, including: The challenge party sends a challenge to the proving party; The proving party receives the challenge, generates a local report according to the TEE technology of the proving party platform, generates a primary signature for the local report and the challenge, generates a node signature for the primary signature, the local report and the TEE type, constructs a remote proving request and sends it; The remote verification agent module receives the remote proving request, first verifies the node signature to confirm the correctness of the request, then calls the verification logic of the corresponding proving party TEE type to verify the local report, and then calls the re-signing generation algorithm to generate a re-signature for the primary signature, and returns a remote proving response message to the proving party; the remote verification agent module receives the remote proving request sent by the proving party and performs verification, including: The node signature is verified using the public key of the proving party to confirm the legitimacy of the source node; According to the TEE type of the proving party, the corresponding TEE type verification logic is called to verify the local report and generate a proof result; If the proof result indicates that the local report is trusted, a proxy re-signature key is generated using the private key of the remote verification agent module and the public key of the proving party, the primary signature in the request is re-signed, and the generated re-signature and the local report constitute a remote proving response message and are returned to the proving party; otherwise, a message is returned to the proving party indicating that the local report is not trusted; The proving party receives the returned remote proving response message, verifies the correctness of the re-signature, confirms that the message has not been tampered with, and then forwards the remote proving response message to the challenge party; The challenge party receives the remote proving response message, verifies the correctness of the re-signature, confirms that the message has not been tampered with, approves the proof result, and completes the proof; wherein the correctness of the re-signature is verified: whether the bilinear mapping pairing is established, if so, the nonce value has not been tampered with, at this time the verification is correct; The proving party receives the remote proving response message, verifies the re-signature, confirms it, and then forwards the remote proving response message to the challenge party, which completes the remote proving after verification by the challenge party.

2. The heterogeneous remote attestation method based on proxy re-signature assistance of claim 1, wherein, Before performing isomeric remote proving of the challenge party and the proving party, first, based on the node registration mechanism, each isomeric TEE node requests node registration from the remote verification agent module and obtains the AK certificate generated by the remote verification agent module.

3. The heterogeneous remote attestation method based on proxy re-signature assistance of claim 2, wherein, For each isomeric TEE node, the node registration mechanism is adopted to perform node registration with the remote verification agent module, including: Each isomeric TEE node generates a pair of public and private keys for verifying identity to the remote verification agent module and a DH shared key for establishing a session; at the same time, the remote verification agent module generates its own public and private keys and a root certificate; Each isomeric TEE node sends its own ID information, DH shared key and public key to the remote verification agent module to request node registration; After receiving the node registration request, the remote verification agent module generates an AK certificate for the node according to the node's public key, and sends the AK certificate, root certificate and DH shared key values of all nodes to the corresponding TEE node. Each isomer TEE node respectively acquires the root certificate of the remote verification agent module, the DH shared key value of other nodes and the AK certificate for remote attestation, and completes the registration of the current node.

4. The heterogeneous remote attestation method based on proxy re-signature assistance of claim 3, wherein, For each isomer node, the shared key is calculated according to the DH shared key value of all nodes obtained after node registration.

5. The heterogeneous remote attestation method based on proxy re-signature assistance of claim 1, wherein, The challenge direction attestation party initiates a challenge, and the challenge includes a randomly generated string nonce value encrypted by the shared key; The attestation party receives the challenge, decrypts the nonce value by using the shared key, generates a local report according to the TEE technology of the attestation party platform, generates a message signature as a primary signature for the local report and the nonce value in combination with the nonce value; A node signature is further generated for the primary signature, the local report and the TEE type; A remote attestation request is constructed based on the primary signature, the local report, the TEE type and the node signature, and is sent to the remote verification agent module.

6. The heterogeneous remote attestation method based on proxy re-signature assistance of claim 1, wherein, The two isomer TEE nodes respectively as the challenge party and the attestation party exchange identities, that is, the isomer TEE node of the original challenge party is regarded as the attestation party, and the isomer TEE node of the original attestation party is regarded as the challenge party; The isomer remote attestation is performed again on the two isomer TEE nodes after the identity exchange, so as to realize the bidirectional remote attestation of the isomer TEE nodes based on the proxy re-signature.

7. A heterogeneous remote attestation system based on proxy re-signature assistance, characterized in that, The two isomer TEE nodes respectively as the challenge party and the attestation party and the remote verification agent module are included, wherein: The challenge party is used for sending a challenge to the attestation party; The attestation party is used for receiving the challenge, generating a local report according to the TEE technology of the attestation party platform, generating a primary signature for the local report and the challenge, generating a node signature for the primary signature, the local report and the TEE type, constructing a remote attestation request and sending; The remote verification agent module is used for receiving the remote attestation request, verifying the node signature to confirm the correctness of the request, calling the verification logic of the corresponding attestation party TEE type to verify the local report, calling the re-signature generation algorithm to generate a re-signature for the primary signature, and returning a remote attestation response message to the attestation party in combination with the local report; After receiving the remote attestation request sent by the attestation party, the remote verification agent module verifies, including: The node signature is verified by using the public key of the attestation party to confirm the legitimacy of the node of the request source; According to the TEE type of the attestation party, the verification logic of the corresponding TEE type is called to verify the local report to generate an attestation result; If the attestation result shows that the local report is trusted, a proxy re-signature key is generated by using the private key of the remote verification agent module and the public key of the attestation party, the primary signature in the request is re-signed, the generated re-signature and the local report constitute a remote attestation response message, and the remote attestation response message is returned to the attestation party; Otherwise, a message is returned to the attestation party to indicate that the local report is not trusted; The attestation party receives the returned remote attestation response message, verifies the correctness of the re-signature, confirms that the message has not been tampered with, and then forwards the remote attestation response message to the challenge party; The challenger receives the remote attestation response message, verifies the correctness of the re-signature, confirms that the message is not tampered, approves the attestation result, and completes the attestation; wherein the correctness of the re-signature is verified by judging whether the bilinear mapping pairing is established, and if so, the nonce value is not tampered, and at this time the verification is correct; The prover is configured to receive the remote attestation response message, verify the re-signature, and forward the remote attestation response message to the challenger after verification; The challenger is configured to receive the remote attestation response message, verify the re-signature, and complete the remote attestation of the challenger after verification.

8. An electronic device, comprising: Comprise: A memory for storing executable instructions; A processor for executing the executable instructions stored in the memory, realizing the proxy re-signature assisted heterogeneous remote attestation method of any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, Executable instructions are stored for causing the processor to execute the executable instructions, realizing the proxy re-signature assisted heterogeneous remote attestation method of any one of claims 1-6.

Images