Cross-domain authentication method for device anonymous traceability under a trusted execution environment
By deploying TEE in IoT devices, generating public and private keys and performing cross-domain identity authorization, the trust silos and authentication problems of IoT devices in cross-domain communication are solved, achieving anonymity and traceability, and improving the security and trustworthiness of the system.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-20
- Publication Date
- 2026-03-31
AI Technical Summary
IoT devices face the problem of trust silos and complex trust management and authentication challenges when communicating across domains. Traditional centralized authentication mechanisms are difficult to adapt to distributed environments, and resource-constrained devices cannot handle complex encryption and authentication calculations. Anonymous cross-domain authentication schemes do not consider the issues of trustworthiness and user identity traceability.
Deploy a Trusted Execution Environment (TEE), generate public and private keys and register devices, perform cross-domain real identity authorization through the interaction of challenge values and intermediate value sets, generate distributed keys through joint authentication nodes, use blockchain to query identities for cross-domain authentication, and track and revoke false identities on target domain devices.
It achieves anonymity and traceability of cross-domain authentication, improves the security of IoT devices and the credibility of the system, and reduces the impact of spoofing attacks and malicious behavior.
Smart Images
Figure CN120110662B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of network information security technology, specifically to a cross-domain authentication method for anonymous and traceable devices in a trusted execution environment. Background Technology
[0002] In today's era of rapidly increasing numbers of IoT devices, the security of data transmission has become a major concern. However, due to the widespread and dispersed nature of IoT devices, they reside in different trust domains. These different trust domains often exhibit trust silos due to variations in trust mechanisms and authentication methods. Therefore, IoT devices face complex trust management and authentication challenges when communicating across domains.
[0003] Traditional centralized authentication mechanisms are ill-suited to distributed, heterogeneous IoT environments and are prone to becoming single points of failure and targets for attacks. Furthermore, IoT devices are typically resource-constrained and unable to handle complex encryption and authentication calculations, further exacerbating the difficulty of cross-domain authentication.
[0004] Current anonymous cross-domain authentication schemes employ distributed key generation technology. However, these schemes do not consider the trustworthiness of other key-generating entities that are not entirely trusted when generating distributed keys for users. These entities are vulnerable to spoofing and man-in-the-middle attacks when generating key sets for users, and they themselves may engage in malicious behavior. This necessitates the design of appropriate monitoring and verification mechanisms. Furthermore, these schemes do not address the issue of tracing the user's true identity; the inability to trace malicious users severely compromises system security. Summary of the Invention
[0005] In order to solve the above-mentioned technical problems, this application proposes the following technical solution:
[0006] In a first aspect, embodiments of this application provide a cross-domain authentication method for anonymous and traceable devices in a trusted execution environment, including:
[0007] S1, deploy the Trusted Execution Environment (TEE) and complete the generation of public and private keys for the participants and the registration of local domain devices;
[0008] S2, based on the TEE, the local domain device and the target domain authentication node interact through a set of challenge values and a set of intermediate values to achieve cross-domain real identity authorization;
[0009] S3, based on the authentication nodes of the TEE local domain and the target domain, the local domain device jointly performs distributed key generation to achieve cross-domain anonymous identity authorization;
[0010] S4, during the authentication phase, the local domain device selects a real identity or a pseudo identity to send a cross-domain authentication request to the target domain device, and the target domain device queries the identity and corresponding public key on the blockchain to complete the cross-domain authentication.
[0011] In one possible implementation, the deployment of the Trusted Execution Environment (TEE), the generation of public and private keys for the participating parties, and the registration of local domain devices include:
[0012] S11, the registration authority generates a series of system parameters and generates the registration public and private keys;
[0013] S12, each domain authentication node generates public and private keys and deploys a Trusted Execution Environment (TEE) locally, generates TEE public and private keys and has built-in functions for generating and verifying proofs;
[0014] S13, the local domain device sends a registration request to the local domain authentication node, and the authentication node uploads the real identity and the first device's public key to the blockchain to complete the domain registration.
[0015] In one possible implementation, S11 includes: the registration authority generating system security parameters. ,enter Generate two large prime numbers p and q, where p = 2q + 1, and generate two cyclic groups with order q. , Define a bilinear mapping Generator For the group Any generator, Less than p A set of positive integers, a secure hash function , , The registration agency selects a random number. As a registration private key Register public key Then, the authentication nodes in each domain select random numbers. Private key as authentication node The public key of the authentication node is ;
[0016] S12 includes: each domain's authentication node selects a random number as its private key and generates an authentication node public key; then, the authentication node initializes and deploys a Trusted Execution Environment (TEE), generating a TEE public-private key pair. Built-in proof generation function Enter the TEE private key It takes other functions as input and generates other functions' outputs and proofs; it has a built-in verification proof function that takes the TEE public key, other functions' outputs, and proofs as input. Built-in verification and proof functions ,enter Other function outputs and
[0017] Prove that the statement is correct by outputting 0 or 1.
[0018] S13 includes: equipment use After encryption, a real identity domain registration request is sent to the local domain authentication node. The specific request content is as follows: The true identity of the device First device private key First device public key After receiving a registration request from within the device domain, the authentication node uses... Decrypt the request content to obtain the request content, then input the request content into... The proof is found in the function. The authentication node will then... Within the consortium blockchain smart contract jointly maintained by various domain authentication nodes, the following is submitted: For equipment The domain validity period of the real identity and the public key of the first device. The smart contract will use the timestamp of the message being uploaded to the blockchain. and Input to Verification and proof within the function The result of 1 indicates that the verification is correct and the domain device registration is completed; a result of 0 indicates that the domain registration has failed and a message is sent to the device.
[0019] In one possible implementation, the cross-domain real identity authorization based on the TEE, whereby the local domain device and the target domain authentication node interact through a set of challenge values and a set of intermediate values, includes:
[0020] S21, The local domain device sends a cross-domain permission request with real identity to the target domain authentication node;
[0021] S22, The target domain authentication node calculates the set of challenge values and sends them to the local domain device;
[0022] S23, After receiving the response value set, the local domain device calculates the response value set and sends it to the target domain authentication node;
[0023] S24. After the target domain authentication node verifies and confirms that the local domain device belongs to the user of the corresponding public key, it uploads the real identity of the local domain device to the blockchain to complete the cross-domain permission for the real identity.
[0024] In one possible implementation, S21 includes:
[0025] equipment use After encryption, a cross-domain permission request is sent to the authentication node of the target domain Y. The request content includes... ,in For the domain where the device is located, For the device target domain;
[0026] The s22 includes: after receiving the request, the Y domain authentication node queries the consortium blockchain to see if the X domain authentication node has published it. Real identity and the first device public key If the information exists, it needs to be checked whether it is within the validity period; after the check passes, the Y domain authentication node selects a random number. , input Generate a set of challenge values and proof And send to ,in , ;
[0027] S23 includes: Received challenge value set and proof Then, first call Verification and proof The correctness, if correct, First, calculate the intermediate temporary results. , Then the calculation results and , the set of response values Send it to the Y domain authentication node via smart contract, and at the same time... The encrypted value is sent to the smart contract; after receiving the response value set, the Y-domain authentication node calculates... Then verify If the equation is true, then call Generate proof and will Submitted to the consortium blockchain smart contract, where For equipment The validity period of the real identity and the public key of the first device in the Y domain. The timestamp for when the message was uploaded to the blockchain;
[0028] S24 includes: smart contract invocation use verify and The correctness of the result, if correct, will be Go on-chain to complete cross-domain permission for the device's true identity.
[0029] In one possible implementation, the authentication node, based on the TEE local domain and the target domain, jointly performs distributed key generation with the local domain device to achieve cross-domain anonymous identity authorization, including:
[0030] S31, the local domain device sends a key generation request to the authentication nodes of the local domain and the target domain through a smart contract;
[0031] S32, after receiving the request, the authentication node generates public and private key sets respectively, and the local domain device generates public and private key sets at the same time;
[0032] S33, the public key set is collected by the smart contract, and the private key set is sorted by the local domain device according to a random function and then input into the key generation function to generate the second device private key;
[0033] S34, the local domain device calculates the pseudo-identity and sends it to the authentication node. The smart contract puts the local domain device's pseudo-identity and corresponding public key on the blockchain to complete the cross-domain pseudo-identity authorization.
[0034] In one possible implementation, S31 includes: the device encrypts the cross-domain distributed key generation request and sends it to the consortium blockchain smart contract. The request content includes the domain name of the requested distributed key generation. The smart contract verifies whether there is cross-domain permission information published by the authentication node of the requested domain on the chain. If both exist, it checks whether the identity matches and whether it is within the validity period. After the check is correct, the smart contract sends the distributed key generation request to the authentication node of the requested domain.
[0035] S32 includes: after each authentication node receives the request, it calls... Function selection As a private key set At the same time, a proof is generated. , and public key set Simultaneous selection of equipment As a private key set Public key set ;
[0036] S33 includes: the device sending the public key set to the smart contract, each authentication node sending its public and private key sets and proofs to the smart contract, and the smart contract first calling... The function verifies the correctness of the proofs from each authentication node. If the verification is correct, it aggregates the public key sets of the device and each authentication node to obtain an aggregated public key set. The smart contract sends the private key sets of each authentication node to the device. The device then uses a random function to sort and aggregate its own generated private key set with the private key sets of each authentication node to obtain the final private key set. The final public key set is obtained by following the order of the private key set. Equipment calculation And convert it into a binary sequence ,in At the current time, the final public and private key set and binary sequence are input into the final key generation function to generate the second device private key. Second device public key The specific function is:
[0037] ;
[0038] S34 includes: a device Obtain the public / private key pair of the second device Then, use the registered public key. pk M Calculate temporary values computing devices Anonymous identity for cross-domain access , for hash value, The hash function used when the system is initially initialized; device Will Hand over to smart contract verification Once the smart contract verification equation is true, it will Cross-domain pseudo-identity permission is completed on the blockchain, among which This is the current time.
[0039] In one possible implementation, during the authentication phase, the local domain device selects either a real identity or a false identity to send a cross-domain authentication request to the target domain device. The target domain device then queries the blockchain for the identity and corresponding public key to complete the cross-domain authentication, including:
[0040] The X domain device initiates a cross-domain authentication request to the Y domain device using either a real or fake identity. The request includes the local domain name, the target domain name, the identity, the corresponding public key, and the timestamp.
[0041] Y-domain devices query the identity and public key in the request through the local domain authentication node to see if they exist on the consortium blockchain. If they do exist, they check if they are within the validity period.
[0042] After the check is passed, the identity and public key of domain X are obtained to communicate and complete cross-domain authentication.
[0043] In one possible implementation, the pseudo-identity of the target domain device is used to obtain the real identity through calculation by the administrator node, thereby enabling identity tracking and revocation.
[0044] In one possible implementation, the pseudo-identity of the target domain device is used to calculate the real identity through an administrator node, thereby enabling identity tracking and revocation, including:
[0045] When a device is detected using a false identity to communicate and initiate malicious behavior, a report on the false identity and malicious behavior of the malicious node is submitted to the registration authority via the blockchain. The message content sent includes... ,in and To spoof the identity and public key of the device initiating malicious behavior, Report malicious behavior;
[0046] The registration agency first calculates Then the true identity of the device is calculated. Complete device identity tracking: ;
[0047] After calculating the true identity of a device, the registration authority observes the device's behavior against the malicious behavior report. If the device does indeed engage in malicious behavior, the registration authority updates the device's false identity and true identity to the revocation list and records it on the consortium blockchain, thus completing the cross-domain device identity revocation.
[0048] In the embodiments of this application, TEEs are deployed on semi-trusted authentication nodes in each domain. The interaction of TEEs, challenge values, and intermediate value sets enables the supervision of authentication nodes, allowing authentication nodes to replace traditional trusted institutions within the domain to help devices perform cross-domain authentication. Attached Figure Description
[0049] Figure 1 This application provides a schematic diagram of a cross-domain authentication device composition for device anonymity and traceability in a trusted execution environment, as illustrated in an embodiment of the present application.
[0050] Figure 2 This is a flowchart illustrating a cross-domain authentication method for anonymous and traceable devices in a trusted execution environment, as provided in an embodiment of this application. Detailed Implementation
[0051] Before describing the method in this embodiment, a brief introduction to the parties involved in this application will be given. See [link to relevant documentation]. Figure 1The registration authority is typically deployed as a trusted server within the system, responsible for tracking and revoking device identities, and is a fully trusted entity. Authentication nodes in each domain are generally cloud servers or edge servers within the domain, deploying TEE hardware during system initialization and registration phases. They are responsible for cross-domain authentication of devices and are semi-trusted entities, relying on TEE to generate and verify proofs to ensure the credibility of communication content. IoT devices in each domain are the entities initiating cross-domain authentication, typically IoT devices with low computing power and limited communication capabilities. The consortium blockchain is a blockchain jointly maintained by authentication nodes in each domain, capable of storing authentication information of devices in each domain and using smart contracts for automated authentication.
[0052] The present solution will now be described in conjunction with the accompanying drawings and specific embodiments.
[0053] See Figure 2 The cross-domain authentication method for anonymous and traceable devices in a trusted execution environment provided in this embodiment includes:
[0054] S1, deploy the Trusted Execution Environment (TEE) and complete the generation of public and private keys for the participating parties and the registration of local domain devices.
[0055] In this embodiment, S1 includes: S11, the registration authority generates a series of system parameters and generates registration public and private keys. S12, each domain authentication node generates public and private keys and deploys a Trusted Execution Environment (TEE) locally, generates TEE public and private keys, and incorporates generation and verification proof functions. S13, local domain devices send registration requests to local domain authentication nodes, and the authentication nodes upload their real identity and the first device's public key to the blockchain to complete domain registration.
[0056] Specifically, S11 includes: the registration authority generating system security parameters. ,enter Generate two large prime numbers p and q, where p = 2q + 1, and generate two cyclic groups with order q. , Define a bilinear mapping Generator For the group Any generator, Less than p A set of positive integers, a secure hash function , , The registration agency selects a random number. As a registration private key Register public key Then, the authentication nodes in each domain select a random number. Private key as authentication node The public key of the authentication node is .
[0057] S12 includes: each domain's authentication node selects a random number as its private key and generates an authentication node public key. Then, the authentication node initializes and deploys a Trusted Execution Environment (TEE), generating a TEE public-private key pair. Built-in proof generation function Enter the TEE private key Input other functions and generate their outputs and proofs. Built-in verification and proof functions take the TEE public key, other function outputs, and proofs as input. Built-in verification and proof functions ,enter Other function outputs and
[0058] Prove that the output is 0 or 1, indicating whether the proof is correct.
[0059] S13 includes: equipment use After encryption, a real identity domain registration request is sent to the local domain authentication node. The specific request content is as follows: The true identity of the device First device private key First device public key After receiving a registration request from within the device domain, the authentication node uses... Decrypt the request content to obtain the request content, then input the request content into... The proof is found in the function. The authentication node will then... Within the consortium blockchain smart contract jointly maintained by various domain authentication nodes, the following is submitted: For equipment The domain validity period of the real identity and the public key of the first device. This is the timestamp for when the message is uploaded to the blockchain. The smart contract will... and Input to Verification and proof within the function The result of 1 indicates that the verification is correct and the domain device registration is completed; a result of 0 indicates that the domain registration has failed and a message is sent to the device.
[0060] S2, based on the TEE, the local domain device and the target domain authentication node interact through the challenge value set and the intermediate value set to achieve cross-domain real identity authorization.
[0061] In this embodiment, S2 includes: S21, the local domain device sends a real identity cross-domain permission request to the target domain authentication node. S22, the target domain authentication node calculates a challenge value set and sends it to the local domain device. S23, after receiving the challenge value set, the local domain device calculates a response value set and sends it to the target domain authentication node. S24, after verification, the target domain authentication node confirms that the local domain device is the user who owns the corresponding public key and then uploads the local domain device's real identity to the blockchain to complete the real identity cross-domain permission.
[0062] Specifically, S21 includes: a device use After encryption, a cross-domain permission request is sent to the authentication node of the target domain Y. The request content includes... ,in For the domain where the device is located, For the device target domain.
[0063] The s22 includes: after receiving the request, the Y domain authentication node queries the consortium blockchain to see if the X domain authentication node has published it. Real identity and the first device public key If the information exists, it needs to be checked to see if it is within its validity period. After the check passes, the Y-domain authentication node selects a random number. , input Generate a set of challenge values and proof And send to ,in , .
[0064] S23 includes: Received challenge value set and proof Then, first call Verification and proof The correctness, if correct, First, calculate the intermediate temporary results. , Then the calculation results and , the set of response values Send it to the Y domain authentication node via smart contract, and at the same time... The encrypted value is sent to the smart contract. After receiving the response value set, the Y-domain authentication node calculates... Then verify If the equation is true, then call Generate proof and will Submitted to the consortium blockchain smart contract, where For equipment The validity period of the real identity and the public key of the first device in the Y domain. This is the timestamp for when the message was uploaded to the blockchain.
[0065] S24 includes: smart contract invocation use verify and The correctness of the result, if correct, will be Go on-chain to complete cross-domain permission for the device's true identity.
[0066] S3, based on the authentication nodes of the TEE local domain and the target domain, the local domain device jointly performs distributed key generation to achieve cross-domain anonymous identity authorization.
[0067] In this embodiment, S3 includes: S31, the local domain device sends a key generation request to the authentication nodes of both the local domain and the target domain via a smart contract. S32, upon receiving the request, the authentication nodes generate public and private key sets respectively, and the local domain device simultaneously generates its own public and private key set. S33, the public key set is aggregated by the smart contract, and the private key set is sorted by the local domain device according to a random function and then input into the key generation function to generate a second device private key. S34, the local domain device calculates a pseudo-identity and sends it to the authentication node; the smart contract uploads the local domain device's pseudo-identity and corresponding public key to the blockchain, completing the cross-domain pseudo-identity authorization.
[0068] Specifically, step S31 includes: the device encrypts a cross-domain distributed key generation request and sends it to the consortium blockchain smart contract. The request content includes the domain name requesting the distributed key generation. The smart contract verifies whether cross-domain permission information published by the authentication node of the requested domain exists on the blockchain. If both exist, it checks whether the identity matches and whether it is within the validity period. After the check is correct, the smart contract sends the distributed key generation request to the authentication node of the requested domain.
[0069] S32 includes: after each authentication node receives the request, it calls... Function selection As a private key set At the same time, a proof is generated. , and public key set The equipment is selected simultaneously. As a private key set Public key set .
[0070] S33 includes: the device sending the public key set to the smart contract, each authentication node sending its public and private key sets and proofs to the smart contract, and the smart contract first calling... The function verifies the correctness of the proofs from each authentication node. If the verification is correct, it aggregates the public key sets of the device and each authentication node to obtain an aggregated public key set. The smart contract sends the private key sets of each authentication node to the device. The device then uses a random function to sort and aggregate its own generated private key set with the private key sets of each authentication node to obtain the final private key set. The final public key set is obtained by following the order of the private key set. Equipment calculation And convert it into a binary sequence ,in At the current time, the final public and private key set and binary sequence are input into the final key generation function to generate the second device private key. Second device public key The specific function is:
[0071] .
[0072] S34 includes: a device Obtain the public / private key pair of the second device Then, use the registered public key. pkM Calculate temporary values computing devices Anonymous identity for cross-domain access , for hash value, The hash function used when the system is initially initialized; device Will Hand over to smart contract verification Once the smart contract verification equation is true, it will Cross-domain pseudo-identity permission is completed on the blockchain, among which This is the current time.
[0073] S4, during the authentication phase, the local domain device selects a real identity or a pseudo identity to send a cross-domain authentication request to the target domain device, and the target domain device queries the identity and corresponding public key on the blockchain to complete the cross-domain authentication.
[0074] In this embodiment, S4 includes: a device Choose either a real identity or a fake identity to initiate a cross-domain authentication request to the device in domain Y. The request content includes... The Y-domain device queries the local domain authentication node to see if the identity and public key in the request exist on the consortium blockchain. If they exist, it checks if they are valid. After the check passes, it obtains... They communicate using their identity and public key to complete cross-domain authentication.
[0075] It should be noted that in this embodiment, during the authentication process, the pseudo identity of the target domain device is calculated by the administrator node to obtain the real identity, thereby enabling identity tracking and revocation.
[0076] Specifically, when a device is detected using a false identity to communicate and initiate malicious behavior, a report on the false identity and malicious behavior of the malicious node is submitted to the registration authority via the blockchain. The message content sent includes... ,in and To spoof the identity and public key of the device initiating malicious behavior, Reporting of malicious behavior. The registration authority first calculates... Then the true identity of the device is calculated. Complete device identity tracking: After calculating the true identity of a device, the registration authority observes the device's behavior against the malicious behavior report. If the device does indeed engage in malicious behavior, the registration authority updates the device's false and true identities to the revocation list and records it on the consortium blockchain, thus completing the cross-domain device identity revocation.
[0077] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent the existence of A alone, the simultaneous existence of A and B, or the existence of B alone. A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects have an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, and c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.
[0078] The above description is merely a specific embodiment of this application. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the protection scope of this application. The protection scope of this application should be determined by the protection scope of the claims.
Claims
1. A cross-domain authentication method for device anonymous traceability under a trusted execution environment, characterized in that, The application comprises the following steps: S1, deploying a trusted execution environment (TEE) in each domain authentication node, generating public and private keys of participants including a registration authority, each domain authentication node and a local domain device, and registering the local domain device which is an Internet of Things device in each domain; S2, realizing cross-domain real identity permission through interaction between the local domain device and the target domain authentication node based on the TEE, challenge value set and intermediate value set; S3, realizing cross-domain anonymous identity permission through joint distributed key generation of the local domain and the target domain authentication node based on the TEE, comprising the following steps: S31, the local domain device sends a key generation request to the authentication nodes of the local domain and the target domain through a smart contract; S32, after receiving the request, the authentication nodes generate a public and private key set respectively, and the local domain device generates a public and private key set simultaneously; 2. The cross-domain authentication method of claim 1, wherein, S33, the public key set is collected by the smart contract, and the private key set is sorted according to a random function and then input into a key generation function to generate a second device private key; S34, the local domain device calculates a pseudo-identity and sends it to the authentication nodes, and the smart contract chains the pseudo-identity of the local domain device and the corresponding public key to complete cross-domain pseudo-identity permission; S4, in the authentication stage, the local domain device selects a real identity or a pseudo-identity to send a cross-domain authentication request to the target domain device, and the target domain device queries the identity and the corresponding public key on a blockchain to complete cross-domain authentication, wherein the blockchain is a consortium chain maintained by the authentication nodes of each domain. The deployment of the TEE and the generation of the public and private keys of the participants and the registration of the local domain device comprise the following steps:
3. The cross-domain authentication method of claim 2, wherein, The S11 includes: the registration authority generates system security parameters , input Generate two large prime numbers p, q, where p = 2q + 1, generate two cyclic groups of order q 、 , define a bilinear mapping , the generator Any generator of the group , A set of positive integers less than p , a secure hash function 、 、 The registration authority selects a random number As the registration private key , the registration public key ; The S12 includes: authentication node selection random number of each domain Private key as authentication node , and authentication node public key ; then the authentication node initializes the trusted execution environment (TEE), generates a TEE public-private key pair ; the built-in generation proof function , input TEE private key and other function inputs, generates other function outputs and proofs; the built-in verification proof function inputs TEE public key, other function outputs and proofs , the built-in verification proof function , input , other function outputs and S11, the registration authority generates a series of system parameters and generates a registration public and private key; The S13 comprises a device Using After encrypting the request content, the real identity domain registration request is sent to the local domain authentication node, and the request content is specifically , wherein the real identity of the device , the first device private key , the first device public key ; after receiving the real identity domain registration request, the authentication node uses to decrypt the request content, and then inputs the request content into function to obtain the proof ; then the authentication node submits to the alliance chain smart contract commonly maintained by each domain authentication node, wherein is the domain valid period of the device real identity and the first device public key, is the time stamp of the on-chain ; the smart contract inputs and into function to verify the correctness of the proof , and the result is 1, representing that the proof is correct, completing the domain device registration, and the result is 0, representing that the device is sent a domain registration failure message.
4. The method of claim 1, wherein the method further comprises: S12, each domain authentication node generates a public and private key and locally deploys a TEE, generates a TEE public and private key and internally generates and verifies a proof function; S13, the local domain device sends a registration request to the local domain authentication node, and the authentication node chains the real identity and the first device public key to complete the registration in the domain. The proof outputs 0 or 1, i.e. whether the proof is correct; The realization of cross-domain real identity permission through interaction between the local domain device and the target domain authentication node based on the TEE, challenge value set and intermediate value set comprises the following steps: S21, the local domain device sends a real identity cross-domain permission request to the target domain authentication node; 5. The cross-domain authentication method of claim 4, wherein, S22, the target domain authentication node calculates a challenge value set and sends it to the local domain device; S23, the local domain device calculates a response value set after receiving the challenge value set and sends it to the target domain authentication node; S24, after verification, the target domain authentication node confirms that the local domain device is the user of the corresponding public key and chains the real identity of the local domain device to complete the real identity cross-domain permission. The S21 comprises the following steps: Device Using the authentication node public key Encrypt the request content and send the cross-domain permission request to the target domain Y domain authentication node, the request content includes , wherein is the domain where the device is located, is the target domain of the device, is the real identity of the device, is the first device public key; The S22 includes: after the Y domain authentication node receives the request, querying on the alliance chain whether there is information of the X domain authentication node Real identity And the first device public key If there is, it needs to check whether it is within the valid period; after the check is passed, the Y domain authentication node selects a random number Input into To generate a challenge value set And proof And send to , wherein , , Is a secure hash function, Is the private key of the authentication node; The S23 includes: Receiving a challenge value set And a proof After that, first call Verify the correctness of the proof If Correct, First calculate the intermediate temporary result , , then calculate the result And The response value set Is sent to the Y domain authentication node through the smart contract, and Is sent to the smart contract after encryption; After receiving the response value set, the Y domain authentication node calculates , then verifies , and calls Generate a proof , and submit To the consortium chain smart contract, where The real identity of the device And the validity period of the first device public key in the Y domain, Is the timestamp of On-chain, where: The first device private key The secure hash function The bilinear mapping function; The S24 includes: smart contract calling Using the TEE public key Verification And The correctness, if correct, will be Chained, complete device real identity cross-domain permission.
6. The method of claim 1, wherein the method further comprises: The S31 comprises: the device sends a cross-domain distributed key generation request to the alliance chain smart contract after encryption, and the request content comprises a domain name for which the distributed key is requested; the smart contract verifies whether cross-domain permission information issued by the authentication node of the requested domain exists on the chain; if both exist, the identity is checked for matching and whether it is within the valid period; after the check, the smart contract sends the distributed key generation request to the authentication node of the device requested domain; The S32 comprises: after each authentication node receives the request, calling Function selection As a private key set , while generating a proof , And the public key set ; The device simultaneously selects As a private key set , the public key set ; The S33 comprises: the device sending a public key set to the smart contract, each authentication node sending a public and private key set and a proof to the smart contract, and the smart contract first calling a function to verify the correctness of the proof of each authentication node, and if the verification is correct, aggregating the public key sets of the device and each authentication node to obtain an aggregated public key set ; the smart contract sending the private key set of each authentication node to the device, and the device aggregating the private key set generated by itself and the private key set of each authentication node after sorting by a random function to obtain a final private key set , obtaining a final public key set according to the private key set order ; the device calculating and converting it into a binary sequence , wherein is the current time, and inputting the final public and private key set and the binary sequence into a final key generation function to generate a second device private key and a second device public key ; The S34 comprises a device Obtain a second device public-private key pair After that, use the registration public key pk M Calculate a temporary value , Calculate the device Anonymous identity for cross-domain access , The hash value of The device Hand over to the smart contract for verification , After the smart contract verifies that the equation is correct, hand over , After the smart contract verifies that the equation is correct, hand over On-chain complete cross-domain pseudo-identity permission, wherein The current time is The secure hash function is The real identity of the device is The first device public key is The bilinear mapping function is The domain where the device is located is The target domain of the device is 7. The method of claim 1, wherein the method further comprises: In the authentication stage, the local domain device selects a real identity or a pseudo identity to send a cross-domain authentication request to the target domain device, and the target domain device queries the identity and corresponding public key on the blockchain to complete cross-domain authentication, comprising: The X domain device selects a real identity or a pseudo identity to initiate a cross-domain authentication request to the Y domain device, and the request content comprises a local domain name, a target domain name, an identity, a corresponding public key, and a timestamp; The Y domain device queries whether the identity and public key in the request exist on the alliance chain through the local domain authentication node, and if they exist, checks whether they are within the valid period; After the check, the identity and public key of the X domain are obtained for communication to complete cross-domain authentication.
8. The method of cross-domain authentication of a device under a trusted execution environment with traceable anonymity according to claim 1, characterized in that, Further comprising: The pseudo identity of the target domain device realizes identity tracking and revocation by calculating the real identity through the administrator node.
9. The cross-domain authentication method of claim 8, wherein, The pseudo identity of the target domain device realizes identity tracking and revocation by calculating the real identity through the administrator node, comprising: When it is found that a device uses a pseudo-identity for communication and initiates malicious behavior, a pseudo-identity of a malicious node and a malicious behavior report are submitted to a registration authority through a block chain, and the message content sent includes wherein and is a pseudo-identity of a device initiating malicious behavior and a public key, is a malicious behavior report; The registration authority first computes and then computes the true identity of the device Completes the device identity tracking: where: is the registration private key, is a secure hash function; After calculating the real identity of the device, the registration authority observes the device behavior by comparing with the malicious behavior report, and if the device indeed has malicious behavior, the registration authority updates the pseudo identity and real identity of the device to the revocation list and records on the alliance chain to complete cross-domain device identity revocation.