Heterogeneous remote attestation method and system based on proxy re-signature assistance
By constructing a remote verification proxy module and introducing proxy re-signature technology, the compatibility and security issues between heterogeneous TEE platforms are resolved, enabling secure data exchange and enhanced trust between heterogeneous TEEs, simplifying the development process, and improving the security and efficiency of the privacy computing system.
Patent Information
- Application Number
- CN202511414998.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-30
- Publication Date
- 2025-11-04
- Estimated Expiration
- 2045-09-30
AI Technical Summary
The lack of a unified Trusted Execution Environment (TEE) technical specification in the current technology leads to compatibility issues between TEE products from different vendors, increases development costs and complexity, and may affect the performance and efficiency of privacy computing applications. At the same time, it ignores the security of TEE interactions and is subject to security threats such as man-in-the-middle attacks.
By employing proxy re-signature technology, a remote verification proxy module is constructed to centrally manage and coordinate the remote verification process between heterogeneous TEE platforms. The introduction of proxy re-signature technology enhances security and trust, supports anonymity, and solves compatibility and security issues between TEEs.
It achieves compatibility and security between heterogeneous TEEs, enhances trust in the data exchange process, prevents man-in-the-middle attacks, simplifies the development process, and improves overall work efficiency and security.
Smart Images

Figure CN120896701A_ABST
Abstract
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: The challenger sends a challenge to the proving party; 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. 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. 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.
[0008] Secondly, this invention also proposes a heterogeneous remote proof system based on proxy resignation assistance.
[0009] 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; The challenger sends a challenge to the prover; 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. 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. The proving party receives the remote proof response message, verifies the resignature, and forwards the remote proof response message to the challenger after confirmation. The challenger receives the remote proof response message, verifies the resignature, and completes the remote proof for the challenger upon confirmation.
[0010] 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.
[0011] 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.
[0012] The above one or more technical solutions have the following beneficial effects: 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.
[0013] 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
[0014] 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.
[0015] 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; 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; Figure 3 This is a schematic diagram of an abstract model of the remote proof process in an embodiment of the present invention; 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
[0016] 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.
[0017] Example 1 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.
[0018] 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.
[0019] 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: The challenger sends a challenge to the proving party; 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. 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. 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.
[0020] 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.
[0021] In this embodiment, firstly, the standard procedure for unified remote verification is as follows: (1) The challenger first sends a challenge to the target node to be proven (i.e., the prover); (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; (3) Return the certification report to the certifying party; (4) The certifying party verifies the certification report based on the TEE technology type of the target platform.
[0022] 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.
[0023] 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.
[0024] 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: 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.
[0025] The specific steps of the node registration mechanism include: 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. 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; 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. 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.
[0026] 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.
[0027] 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: Step S2.1: The challenger initiates a challenge to the prover, which includes a randomly generated string nonce value encrypted using the shared key.
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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 switched.
[0035] The abstract model of the remote proof process in this embodiment is as follows: Figure 3As 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.
[0036] The specific process of bidirectional proof for heterogeneous TEE nodes based on proxy resignation 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.
[0037] 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.
[0038] In this embodiment, the specific process of node registration includes the following steps: 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; 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. 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); 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; 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.
[0039] 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: 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.
[0040] 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 report Finally, 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] Example 2 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: The challenger sends a challenge to the prover; 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. 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. The proving party receives the remote proof response message, verifies the resignature, and forwards the remote proof response message to the challenger after confirmation. The challenger receives the remote proof response message, verifies the resignature, and completes the remote proof for the challenger upon confirmation.
[0048] Example 3 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.
[0049] Example 4 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.
[0050] 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.
[0051] 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.
[0052] 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 proof method based on proxy resignature assistance, characterized in that, Two heterogeneous TEE nodes, acting as the challenger and prover respectively, work together with a remote verification proxy module to perform heterogeneous remote proof, including: The challenger sends a challenge to the proving party; 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. 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. 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.
2. The heterogeneous remote proof method based on proxy resignature assistance as described in claim 1, characterized in that, Before conducting heterogeneous remote verification between the challenger and the prover, each heterogeneous TEE node requests node registration from the remote verification agent module based on the node registration mechanism, and obtains the AK certificate generated by the remote verification agent module.
3. The heterogeneous remote proof method based on proxy resignature assistance as described in claim 2, characterized in that, For each heterogeneous TEE node, a node registration mechanism is adopted to register the node with the remote verification agent module, including: Each heterogeneous TEE node generates a public-private key pair for verifying its identity with the remote authentication agent module and a DH shared key for establishing a session; at the same time, the remote authentication agent module generates its own public-private key and root certificate. Each heterogeneous 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 a node registration request, the remote verification agent module generates an AK certificate for the node 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 purchased TEE node. 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.
4. The heterogeneous remote proof method based on proxy re-signature assistance as described in claim 3, characterized in that, For each heterogeneous node, the shared key is calculated based on the DH shared key values of all nodes obtained after node registration.
5. The heterogeneous remote proof method based on proxy re-signature assistance as described in claim 1, characterized in that, The challenger initiates a challenge against the prover, the challenge including a randomly generated string nonce value encrypted using a shared key; The proving party receives the challenge, decrypts it using the shared key to obtain the nonce value, and generates a local report based on the proving party platform's TEE technology; it then combines the nonce value to generate a message signature for the local report and the nonce value as the initial signature. Then generate node signatures for the initial signature, local report, and TEE type; A remote proof request is constructed based on the initial signature, local report, TEE type, and node signature, and sent to the remote verification proxy module.
6. The heterogeneous remote proof method based on proxy resignature assistance as described in claim 5, characterized in that, The remote verification proxy module receives a remote verification request from the certifier and performs verification, including: The node signature is verified using the provider's public key to confirm the legitimacy of the requesting node. Based on the TEE type of the proving party, the corresponding verification logic for the TEE type is invoked to verify the local report and generate the proof result; If the proof result indicates that the local report is trustworthy, a proxy re-signature key is generated using the remote verification proxy module's own private key and the prover's public key. This key is then used to re-sign the initial signature in the request. The generated re-signature and the local report together constitute a remote proof response message, which is then returned to the prover. Otherwise, a message is returned to the prover indicating that the local report is not trustworthy. Upon receiving the returned remote proof response message, the proving party 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. The challenger receives the remote proof response message, verifies the correctness of the resignature, confirms that the message has not been tampered with, accepts the proof result, and completes the proof. The verification of the correctness of the resignature is as follows: determine whether the bilinear mapping pairing is valid. If it is valid, the nonce value has not been tampered with, and the verification is correct.
7. The heterogeneous remote proof method based on proxy resignation assistance as described in claim 1, characterized in that, The identities of the two heterogeneous TEE nodes, which were originally the challenger and the prover, were swapped. That is, the heterogeneous TEE node of the original challenger became the prover, and the heterogeneous TEE node of the original prover became the challenger. Heterogeneous remote proof is performed again on the two heterogeneous TEE nodes whose identities are swapped, realizing bidirectional remote proof of heterogeneous TEE nodes based on proxy resigning.
8. A heterogeneous remote proof system based on proxy re-signature assistance, characterized in that, This includes two heterogeneous TEE nodes, one acting as the challenger and the other as the prover, and a remote verification proxy module, wherein: The challenger sends a challenge to the prover; 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. 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. The proving party receives the remote proof response message, verifies the resignature, and forwards the remote proof response message to the challenger after confirmation. The challenger receives the remote proof response message, verifies the resignature, and completes the remote proof for the challenger upon confirmation.
9. An electronic device, characterized in that, include: Memory, used to store executable instructions; The processor, when executing executable instructions stored in the memory, implements the heterogeneous remote proof method based on proxy resignature assistance as described in any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The device stores executable instructions that, when executed by a processor, implement the heterogeneous remote proof method based on proxy resignature assistance as described in any one of claims 1-7.
Citation Information
Patent Citations
Cross-domain identity authentication method based on proxy re-signature
CN105516119A
Method and device for implementing one-way proxy re-signature
CN109618348A
Message verification method, device and equipment and readable storage medium
CN110311791A
Privacy computing method supporting heterogeneous TEE computing power node interaction
CN113556339A
Novel Byzantine fault-tolerant consensus method based on trusted execution environment
CN113923093A