Cross-domain distributed identity authentication method in internet of things scene

Abstract

The application provides a cross-domain distributed identity trusted authentication method in an Internet of Things scene, belongs to the fields of blockchain application and network information security, and constructs an authentication system containing a public chain and a plurality of regional alliance chains; the alliance chain stores regional identity-public key mapping, the public chain stores an issuing end list, a public key commitment mapping and issuing end reputation information; the public key commitment is updated through a fast index tree to generate an initial certificate; a device end generates a display certificate through an interactive method and submits the display certificate to a verification end; the verification end verifies the legality of the public keys of the issuing end and the device end and the reputation state of the issuing end to complete cross-domain authentication. The application breaks away from centralization dependence, realizes effective supervision of the issuing end, and improves the credibility, security and efficiency of cross-domain authentication.

Description

Technical Field

[0001] This invention relates to the fields of blockchain applications and network information security, specifically to a cross-domain distributed identity trusted authentication method in the Internet of Things (IoT) scenario. Background Technology

[0002] The Internet of Things (IoT) is characterized by a large number of nodes, wide distribution, strong heterogeneity, and high dynamism in practical deployments. Traditional centralized identity authentication often relies on only a few central nodes, which is insufficient to meet the requirements of IoT scenarios. Distributed identity, with its decentralized, verifiable, and robust characteristics, has been widely used in identity authentication and access control in IoT scenarios. Its typical application process is as follows: In the registration phase, the issuer, device, and verifier each generate identity identifiers and public-private key pairs, and write the mapping between identity identifiers and public keys into the consortium blockchain through consensus nodes; In the certificate issuance phase, the issuer generates an initial certificate for the device containing identity proof and attribute proof, and signs the certificate with its own private key to ensure its authenticity and immutability; In the certificate usage phase, the device signs the initial certificate with its own private key to generate a display certificate for identity proof; In the certificate verification phase, the verifier verifies the legality of the issuer's and device's signatures based on the public key retrieved on the blockchain. However, identity authentication often exhibits regional characteristics in real-world applications. For example, in large industrial parks, different factories, workshops, or production lines often deploy independent identity management systems and consortium blockchains. When devices in one region need to be authenticated in another region, the need for cross-domain authentication arises.

[0003] However, in cross-domain authentication scenarios, existing technologies face significant challenges: On the one hand, consortium blockchain data in different regions are isolated from each other, and validators in the target region cannot access the on-chain data in the source region, making it impossible to verify the legitimacy of the public key of the certificate held by the device in the source region, resulting in compatibility issues; on the other hand, in cross-regional scenarios, there may be cases where untrusted issuers maliciously issue incorrect certificates (such as issuing a fully resource-sufficient certificate to a resource-constrained device), making it difficult for validators in the target region to determine whether the issuer in the source region has malicious behavior or abnormal operations, weakening the security and trustworthiness of cross-domain authentication. To solve the above problems, existing cross-chain authentication methods are mainly divided into two categories: one is a centralized institution-based authentication mechanism, which relies on a centralized authority with access to consortium blockchains in each region to complete certificate verification and return results, but this mechanism has a centralized dependency problem; the other is a chain-based issuer authentication mechanism, which selects a root issuer to authenticate and issue certificates to all regional issuers. During verification, the root issuer certificate must be verified first, and then the device certificate must be verified, but this mechanism also relies on a centralized root issuer.

[0004] In summary, the two most prominent core problems of existing technologies are: first, existing cross-domain authentication schemes are all centralized in nature, which contradicts the fully distributed requirements of distributed scenarios; second, there is a lack of effective supervision over certificate issuers, which cannot deal with the problem of untrusted issuers maliciously issuing incorrect certificates, thus affecting the security and trustworthiness of cross-domain authentication. Summary of the Invention

[0005] In view of this, it is necessary to provide a cross-domain distributed identity trusted authentication method in the Internet of Things scenario to solve the problems of reliance on centralization and insecure authentication caused by untrusted issuers in the existing technology.

[0006] To address the aforementioned technical problems, this invention provides a cross-domain distributed trusted identity authentication method in an IoT scenario, comprising: A blockchain authentication system is constructed, comprising one public chain and several consortium chains; each consortium chain corresponds to a region, used to store the identity identifier-public key mapping between devices and issuers within that region; the public chain is used to store the list of issuers, public key commitment mappings, and issuer reputation information for all regions; the public key commitment mapping is a mapping between the public key commitment of an issuer and the public key commitment of its issuing device. During the certificate issuance phase, a fast index tree is used to update the public key commitment on the device side, generate a public key commitment, and upload it to the public blockchain; the public key commitment is signed with the private key of the issuing end to generate an initial certificate; During the certificate usage phase, an interactive certificate usage method is adopted, in which the device generates a display certificate based on the initial certificate and submits the display certificate to the verification terminal in the target area. During the certificate verification phase, the verification end verifies the legitimacy of the issuing end, the legitimacy of the device's public key, and the reputation status of the issuing end based on the displayed certificate, thus completing cross-domain identity trusted authentication.

[0007] In one possible implementation, the construction of the fast index tree includes: Construct a sharded Merkle tree and a public key prefix mapping table to form a fast index tree; The sharded Merkle tree consists of multiple sub-Merkle trees with preset subtree storage capacity. Each sub-Merkle tree is a standard traditional Merkle tree used to store the device-side public key. The device-side public key is hashed and stored in the leaf node of the sharded Merkle tree. The root nodes of all the sub-Merkle trees are then concatenated in order to form a public key commitment. The key of the public key prefix mapping table is a prefix of a preset prefix length for the device-side public key, and the value is the root node value of the sub-Merkel tree where the device-side public key is located.

[0008] In one possible implementation, the public key commitment update of the device-side public key includes: If a certificate has been issued to the device through the issuing end, there is no need to update the public key commitment; if the certificate has not been issued to the device through the issuing end, the public key of the device to be updated needs to be added to the sharded Merkle tree for public key commitment update. If there is a sub-Merkel tree with insufficient capacity, hash the public key of the device to be updated and add it to the leaf node of the sub-Merkel tree, recalculate the root node value of the sub-Merkel tree and update it to the public key commitment. If all sub-Merkel trees are full, a new sub-Merkel tree is created using the public key of the device to be updated as the unique element. The root node of the newly created sub-Merkel tree is added to the public key commitment to obtain the updated public key commitment. The public key prefix mapping table is updated by associating the prefix of the preset prefix length of the public key to be updated with the corresponding root node value.

[0009] In one possible implementation, the step of signing the public key commitment with the issuer's private key to generate the initial certificate includes: The device's signature information is obtained by concatenating the issuer's identity identifier, device's identity identifier, device attributes, Merkel proof corresponding to the device's public key, and public key commitment; the Merkel proof is proof data composed of a series of sibling node hash values ​​on the path from the leaf node to the root node in the sub-Merkel tree where the device's public key is located. The device-side information to be signed is signed using the issuer's private key to obtain the issuer's signature information; The initial certificate is obtained by encapsulating the issuer identity, device identity, device attributes, Merkel proof corresponding to the device public key, public key commitment, and issuer signature information.

[0010] In one possible implementation, the interactive certificate usage method, which generates a display certificate on the device based on the initial certificate and submits the display certificate to the verification terminal in the target area, includes: Receive random challenge values ​​sent by the verification terminal in the target area via the device. And reply This indicates that the device received the data correctly. And agreed to The number of interactions is counted as a challenge value; when the device and the verification end complete a cross-domain authentication interaction, this interaction is counted in the number of interactions between the issuing end and the verification end and updated to the public chain to update the historical number of interactions. The challenge value is accessed via the device's private key. Signature generation ,Will and After splicing, the result is ,Will Uploaded to the public blockchain; verified via the public blockchain using the device's public key. After the legitimacy is established, Recorded on the public blockchain; The initial certificate is signed using the device's private key to generate device-side signature information. ; The initial certificate and device signature information Encapsulate the data and obtain the demonstration certificate.

[0011] In one possible implementation, the step of verifying the legitimacy of the issuing end based on the displayed certificate includes: The issuer identity identifier is extracted from the certificate of presentation by the verification end, and then the identity identifier is retrieved from the list of issuers in the public blockchain. If the issuer's identity identifier is not found, cross-domain authentication fails. If the issuer's identity identifier is found, the corresponding issuer's public key is obtained through the issuer's identity identifier-public key mapping, and the issuer's signature information in the initial certificate is compared using the issuer's public key based on hash comparison logic. Verification is required; If the signature information of the issuing end is verified, the issuing end is deemed legitimate; otherwise, cross-domain authentication is deemed to have failed.

[0012] In one possible implementation, the step of verifying the legitimacy of the device's public key based on the displayed certificate includes: Based on the determination of the legitimacy of the issuing end, the verification end extracts the public key commitment from the displayed certificate and verifies whether the public key commitment has been stored in the public blockchain; If the public key commitment is not stored in the public blockchain, cross-domain authentication fails; if the public key commitment is stored in the public blockchain, query the root node of the sub-Merkel tree corresponding to the device's public key through the public key prefix mapping table to verify whether the root node is contained in the public key commitment. If the root node of the corresponding sub-Merkel tree on the device is included in the public key commitment, the root node value of the sub-Merkel tree is recursively calculated based on the hash value of the device's public key and the corresponding Merkel proof. The calculated root node value is then compared with the root node value recorded in the certificate. If the comparison is successful, the device's public key is deemed valid; otherwise, cross-domain authentication is deemed to have failed.

[0013] In one possible implementation, the issuer reputation information includes an issuer blacklist and issuer activity quantification data; the issuer blacklist generation method includes: Based on the determination of the legality of the device's public key, if the device's identity or attributes are found to be fake through the verification end, the preset amount of collateral assets will be pledged to the corresponding issuing end of the public chain report. If the number of reports received by the public chain against the same issuer exceeds the preset reporting threshold within the preset period, the issuer's identity will be added to the blacklist and stored in the public chain, and the digital assets pledged by the verification end will be returned to the verification end. If the preset reporting threshold is not reached, the public chain will not add the issuer to the blacklist and will retain the verification end's pledged assets.

[0014] In one possible implementation, the issuing end activity metric data is obtained by weighted average calculation, specifically as follows:

[0015] in, To increase the activity of the issuing end, and These are the weighting coefficients. The number of times the issuing end updates the public key commitment. This refers to the historical number of interactions between the issuing end and the current verifying end. For the identity identifier of the issuing end, This serves as the identity identifier for the verification end.

[0016] In one possible implementation, the step of verifying the credibility of the issuing end based on the displayed certificate includes: After verifying the legitimacy of the issuing end and the public key of the device, the verification end queries the public chain to see if the issuing end is blacklisted; the verification end also obtains the activity level of the issuing end from the public chain. If the issuing end is not blacklisted and its activity level is greater than the preset activity level threshold, the cross-domain identity is deemed trustworthy; otherwise, the cross-domain authentication is deemed to have failed.

[0017] The beneficial effects of this invention are as follows: The cross-domain distributed identity trusted authentication method in the Internet of Things (IoT) scenario provided by this invention firstly, by constructing a blockchain authentication system containing a public chain and several regional consortium chains, the consortium chains store the identity identifier-public key mapping of their respective regions, while the public chain stores the core information related to the issuing end across all regions, thereby solving the problems of centralized dependence and data isolation between regional consortium chains in existing cross-domain authentication schemes; secondly, by updating the public key commitment through a fast index tree and generating an initial certificate through the issuing end's private key signature, the efficiency of public key management is improved, and the authenticity and immutability of the certificate are guaranteed; thirdly, by generating and displaying the certificate through an interactive method, trusted interaction between the device and the verification end is realized, while providing effective support for activity statistics; finally, cross-domain authentication is completed through multi-dimensional verification by the verification end of the issuing end's legitimacy, the device's public key legitimacy, and the issuing end's reputation status, effectively supervising the behavior of the issuing end, preventing untrusted issuers from maliciously issuing certificates, and ultimately significantly improving the trustworthiness, security, and efficiency of cross-domain identity authentication. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of an embodiment of the cross-domain distributed identity trusted authentication method in the Internet of Things scenario provided by the present invention. Figure 2 A schematic diagram of an embodiment of the blockchain authentication system provided by the present invention; Figure 3 A schematic diagram of an embodiment of the fast index tree provided by the present invention; Figure 4 This is a schematic diagram of an embodiment of the present invention for updating the public key commitment of the device-side public key; Figure 5 This is a schematic diagram of an embodiment of the present invention, which uses the private key of the issuing end to sign a public key commitment to generate an initial certificate. Figure 6 This is a schematic diagram of an embodiment of the present invention that uses an interactive certificate usage method to generate and display certificates; Figure 7 A schematic diagram of an embodiment of the verification of the legitimacy of the issuing terminal provided by the present invention; Figure 8 A schematic diagram of an embodiment of the present invention for verifying the legality of the device-side public key; Figure 9 A schematic diagram of an embodiment of the blacklist generation method for the issuing end provided by the present invention; Figure 10 This is a schematic diagram of an embodiment of the present invention, which verifies the reputation status of the issuing end based on the display certificate. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0021] In the description of the embodiments of the present invention, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0022] The terms "first," "second," etc., used in the embodiments of this invention are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a technical feature defined with "first" or "second" may explicitly or implicitly include at least one of that feature.

[0023] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0024] Before demonstrating the embodiments, the following terms will be explained.

[0025] Blockchain authentication system: Originally a system architecture built on blockchain technology to achieve trusted verification of identity or information, it uses the distributed and tamper-proof characteristics of blockchain to ensure the credibility of authentication. In this invention, it is a cross-domain identity verification architecture composed of public blockchain and consortium blockchain.

[0026] Public blockchain: A type of blockchain that is open to all participants. Any node can join and participate in data recording and verification. It is a distributed ledger with a high degree of decentralization. In this invention, it is used to store core information related to cross-regional issuing terminals and public keys.

[0027] Consortium blockchain: A type of blockchain jointly managed by multiple specific entities, with limited access granted only to members within the consortium. In this invention, it corresponds to different areas used to store identity and public key mapping information within that area.

[0028] Public key commitment: A cryptographic solution in which the committing party first discloses a "commitment value" bound to certain data, and subsequently discloses the data to verify the validity of the commitment. This ensures verifiability while avoiding premature data leakage. In this invention, it is commitment information bound to the device's public key, used for cross-domain verification of the public key's legitimacy.

[0029] Fast index tree: A tree structure for efficient data management, combining sharding and mapping tables to achieve fast data storage, updating and retrieval. In this invention, it consists of a sharded Merkle tree and a public key prefix mapping table, used to manage device-side public keys and generate public key commitments.

[0030] Sharded Merkle Tree: An improved structure based on the Merkle tree, which splits data into a collection of multiple independent sub-Merkle trees for storage, thereby improving data update and retrieval efficiency. In this invention, the public key is used for the block storage device, and each sub-Merkle tree corresponds to a portion of the public key.

[0031] Merkle tree: also called hash tree, is a tree structure built on hash values. Leaf nodes store data hash values, and non-leaf nodes store combinations of child node hashes. It can quickly verify data integrity and ownership. In this invention, it is the basic building block of the sharded Merkle tree.

[0032] Merkle proof: The verification data based on the Merkle tree is the set of sibling node hashes of a certain data in the Merkle tree from the leaf node to the root node. It can verify whether the data belongs to the corresponding Merkle tree. In this invention, it is used to verify whether the device-side public key belongs to the corresponding sub-Merkle tree.

[0033] Public key prefix mapping table: a key-value pair storage structure, using data prefixes as keys and associated information as values, used to quickly locate target data. In this invention, the device-side public key prefix is ​​used as the key and the corresponding sub-Merkel tree root node value is used as the value to assist in querying the sub-Merkel tree where the public key is located.

[0034] Interactive certificate usage method: The certificate usage and verification method is completed by dynamically exchanging information (such as challenge value and response) between the two parties in the certificate interaction, which can improve the security of the interaction. In this invention, the device end and the verification end generate and display the certificate through the interaction of challenge value.

[0035] Public and private keys: Public and private keys are paired asymmetric encryption keys that match each other. The private key is kept secret by the holder and cannot be disclosed. It can be used to sign data (proving that the data was issued by the holder). The public key can be publicly shared and is used to verify the validity of the signature of the private key. It can also be used to encrypt data (only the corresponding private key can decrypt it). In this invention, the issuing end signs the certificate with its own private key, and the verifying end verifies the validity of the signature with its public key; the device end signs the challenge value with its private key, and the public blockchain verifies the signature using the device end's public key.

[0036] This invention provides a cross-domain distributed trusted identity authentication method in the Internet of Things (IoT) scenario, which is described below.

[0037] Figure 1 This is a schematic diagram of an embodiment of the cross-domain distributed identity trusted authentication method in the Internet of Things scenario provided by the present invention, as shown below. Figure 1 As shown, a cross-domain distributed identity trusted authentication method in the Internet of Things (IoT) scenario includes: S101. Construct a blockchain authentication system, which includes one public chain and several consortium chains; each consortium chain corresponds to a region, used to store the identity identifier-public key mapping between the device and the issuer within that region; the public chain is used to store the list of issuers, public key commitment mapping, and issuer reputation information for all regions; the public key commitment mapping is the mapping between the issuer and the public key commitment of the issuing device. S102. During the certificate issuance phase, a fast index tree is used to update the public key commitment of the device-side public key, generate a public key commitment, and upload it to the public blockchain; the public key commitment is signed with the private key of the issuing end to generate the initial certificate. S103. During the certificate usage phase, an interactive certificate usage method is adopted, in which the device generates a display certificate based on the initial certificate and submits the display certificate to the verification terminal in the target area. S104. During the certificate verification phase, the verification end verifies the legitimacy of the issuing end, the legitimacy of the device's public key, and the reputation status of the issuing end based on the displayed certificate, thus completing cross-domain identity trusted authentication.

[0038] It should be noted that the device side refers to the physical device itself that requires cross-domain authentication in the Internet of Things; the issuing side refers to the organization or server that issues authentication certificates to these devices; and the verification side refers to the device or server in the target area that needs to verify the device's identity. "Issuing side" can correspond to "issuer," "device side" can correspond to "device," and "verification side" can correspond to "verifier." The use of the term "side" is to conform to the drafting specifications of method patents, clearly defining each entity as a functional entity that performs the corresponding steps of the method of this invention, and ensuring that the core responsibilities of each corresponding entity are completely consistent.

[0039] It should be noted that devices in different regions authenticate using a consortium blockchain, but the consortium blockchain only allows access to users / devices within that region. When validators in other regions need to verify certificates, it is difficult to verify the legitimacy of the public key by reading on-chain data. Therefore, as... Figure 2 As shown, this invention designs a heterogeneous, interconnected, layered blockchain authentication system. First, the system consists of two levels of blockchains: a public blockchain and several consortium blockchains.

[0040] For a public blockchain, anyone has read / write permissions. The public blockchain primarily records three aspects: an issuer list, a public key commitment mapping, and issuer reputation information. The issuer list refers to a list of issuers composed of certificate issuer identifiers from different regions, used for initial checks to see if the issuer is registered. The public key commitment mapping refers to the mapping between the issuer and the commitment of the public key of the device it issues. This invention uses vector commitments, which allows proving that an element is a member of a vector without revealing the content of other vectors. Issuer reputation information includes information such as the issuer's update frequency, number of interactions, and whether it is blacklisted, to constrain the issuer's behavior.

[0041] For multiple consortium blockchains, each consortium blockchain is maintained within a different region. The blockchain stores the mapping between identity identifiers and public keys within that region for certificate verification. However, the on-chain data between different regions is not shared. Instead, cross-domain verification is achieved through interaction with the public blockchain, thereby supporting cross-regional trusted authentication.

[0042] It should be noted that in the certificate issuance phase, traditional schemes only require the issuer to sign the issuer's identifier, the device's identifier, and attributes to generate a complete certificate. However, in this invention, due to the lack of data sharing on consortium blockchains, verifiers find it difficult to verify the legitimacy of public keys by reading on-chain data. Therefore, this invention designs a new certificate issuance strategy. To achieve efficient certificate issuance, this invention first designs a fast index tree data structure to support efficient commitment value update operations on the public blockchain. During the issuance process, the issuer first performs a commitment update operation based on the fast index tree, enabling verifiers to verify the legitimacy of the device's public key; then, a signing operation is performed. In addition to the issuer's identifier, the device's identifier, and attributes, the issuer also needs to sign the public key proof. The public key proof is used to prove that the device's public key is included in the commitment value on the public blockchain, ensuring the initial certificate... Its authenticity and immutability.

[0043] During the certificate usage phase, in traditional solutions, the device only needs to use a private key pair. While signing is sufficient, in cross-domain scenarios, there is a risk of untrusted issuers issuing incorrect certificates. To support statistical operations on the number of interactions with issuers, this invention designs a new interactive certificate usage method. The main ideas include two points: 1) If the verifier and the device complete the authentication process, both parties upload their signatures to the public blockchain to ensure the verifiability of the result; 2) By introducing a random number as a challenge value, both parties sign the challenge value. This is because if the signature information is fixed each time, the device may maliciously increase the number of interactions by uploading the verifier's signature multiple times.

[0044] In the certificate verification phase, traditional schemes only require the verifier to verify the legitimacy of the issuer's and device's signatures to perform authentication. However, since consortium blockchain data is not shared between different regions and the issuer is untrusted, it is difficult to obtain the correct public key for signature verification by reading on-chain data. Therefore, this invention designs a new certificate verification strategy. The verifier needs to verify three aspects: 1) Verifying the legitimacy of the issuer, verifying whether the issuer's identifier is in the verifier list, and verifying whether the mapping between the verifier's identifier and the public key is recorded in the public blockchain; 2) Verifying the legitimacy of the device's public key, verifying whether the device's public key is included in the corresponding commitment value; 3) Verifying the issuer's reputation value, including whether the issuer is blacklisted, the issuer's update frequency, and the number of interactions. This invention designs corresponding data structures and interaction protocols to collect this information.

[0045] In summary, the cross-domain distributed identity trusted authentication method for IoT scenarios provided by this invention firstly solves the problems of centralized dependence and data isolation between regional consortium blockchains by constructing a blockchain authentication system containing a public blockchain and several regional consortium blockchains. The consortium blockchain stores the identity identifier-public key mapping for its region, while the public blockchain stores core information related to all regional issuers. Secondly, it updates the public key commitment using a fast index tree and generates an initial certificate by signing it with the issuer's private key, improving public key management efficiency and ensuring the authenticity and immutability of the certificate. Thirdly, it generates and displays the certificate through an interactive method, enabling trusted interaction between the device and the verification end, while also providing effective support for activity statistics. Finally, the verification end completes cross-domain authentication through multi-dimensional verification of the issuer's legitimacy, the device's public key legitimacy, and the issuer's reputation status, effectively monitoring issuer behavior and preventing untrusted issuers from maliciously issuing certificates. Ultimately, this significantly improves the trustworthiness, security, and efficiency of cross-domain identity authentication.

[0046] In some embodiments of the present invention, the construction of the fast index tree includes: Construct a sharded Merkle tree and a public key prefix mapping table to form a fast index tree; A sharded Merkle tree consists of multiple sub-Merkle trees with preset subtree storage capacity. Each sub-Merkle tree is a standard traditional Merkle tree used to store the device's public key. The device-side public key is hashed and stored in the leaf node of the sharded Merkle tree. The root nodes of all the sub-Merkle trees are then concatenated in order to form a public key commitment. The key of the public key prefix mapping table is the prefix of the device's public key with a preset prefix length, and the value is the root node value of the sub-Merkel tree where the device's public key is located.

[0047] It should be noted that in IoT cross-domain distributed identity authentication scenarios, issuers may issue certificates frequently. Using traditional vector commitment schemes, such as Merkle trees, would lead to inefficiency because each modification requires altering the entire structure. Therefore, this invention first designs a fast index tree data structure to efficiently generate public key commitments. This design features efficient retrieval and allows proof that an element is contained within the commitment without revealing other elements. Furthermore, based on this data structure, this invention designs a certificate issuance strategy for cross-domain scenarios, enabling verification of device public key legitimacy even in scenarios where on-chain data is not shared.

[0048] The fast index tree consists of a mapping and a sharded Merkle tree. First, to avoid requiring a complete overhaul of the structure for a single modification, this invention designs a sharded Merkle tree structure. A traditional Merkle tree is a tree-like data structure built based on a hash function, where leaf nodes store the hash value of a data block, and non-leaf nodes store the combined hash values ​​of their child nodes. This invention designs a sharded Merkle tree structure, which consists of multiple Merkle trees. The total number of elements in each Merkle tree is fixed. If a tree is full, a new Merkle tree is created, thus achieving efficient addition and retrieval. Then, the root node of each Merkle tree... By concatenating the public keys, a public key commitment can be obtained. commit public key The data is published to a public blockchain. Because this invention uses a Merkle tree structure, it proves that a given public key is contained within a commitment value without revealing other public key information. Furthermore, if only a sharded Merkle tree is used, the retrieval efficiency is relatively low because each public key retrieval requires traversing all public keys. Therefore, this invention adds a mapping relationship to the sharded Merkle tree. To reduce storage overhead, the key of this mapping is the first... The value is the root node value corresponding to the public key, since only the first few bits of the public key are used. bit prefix As a key, it's possible for one key to correspond to multiple values. This allows for searching only a portion of the tree, improving search efficiency. Note this... The larger the value, the higher the storage efficiency and retrieval efficiency due to the mapping. A smaller value increases storage efficiency but decreases retrieval efficiency, requiring a trade-off. This structure achieves fast retrieval by accessing only a portion of the Merkle tree for public key lookup; it also allows proof that a particular public key is included in the commitment value without revealing other public keys.

[0049] It's important to note that the number of elements (i.e., the number of public keys) that each Merkle tree shard can hold is not a fixed value. Instead, it is determined by the specific application scenario and the total number of users in the consortium blockchain. Let's assume the total number of devices is N. For example, if you want lightweight certificates, frequent updates, and limited node storage space, you can set the number of elements in a single shard to be smaller, such as within N / 16, to improve the flexibility of indexing and updates. Conversely, in scenarios requiring large-scale device processing and lower public key update frequency, you can appropriately increase the capacity of each shard, such as above N / 16, to reduce the number of shards and the overhead of overall root node concatenation calculations.

[0050] In some embodiments of the present invention, the public key is used before bit prefix As a key, here Similarly, it is related to the total number of devices in the area. Taking a total of 1024 devices as an example, to improve retrieval efficiency, you can set... =5; To improve storage efficiency, you can set it to 5. =3.

[0051] In some embodiments of the present invention, such as Figure 3 As shown, the fast index tree consists of six Merkle trees and one mapping table. The capacity of each Merkle tree is set to 4. This invention uses the third Merkle tree as an example to illustrate the construction process of the Merkle tree. It is assumed that this Merkle tree contains [ , , , Four public keys, first, [ , , , Hash each element individually to obtain [ , , , ], then and Perform concatenation, and then hash the concatenated string. ,Will and Perform concatenation, and then hash the concatenated string. After that, and By piecing them together, we obtain the Merkelgen. ,Right now By piecing together the Merkel roots of each Merkel tree, ,Will Uploaded to the public blockchain.

[0052] By using a sharded Merkle tree to store device-side public keys in blocks, the efficiency of public key management and updates is improved. The public key prefix mapping table can quickly locate the root node of the sub-Merkle tree corresponding to the device-side public key, accelerating the retrieval speed. Combined with the public key commitment formed by splicing the root nodes of the sub-Merkle trees, the integrity of the public key is guaranteed, and it can adapt to the verification requirements in cross-domain scenarios, improving the efficiency and credibility of cross-domain public key verification.

[0053] In some embodiments of the present invention, updating the public key commitment on the device side includes: S401. If a certificate has been issued to the device through the issuing end, there is no need to update the public key commitment; if it has not been issued to the device through the issuing end, the public key of the device to be updated needs to be added to the sharded Merkle tree for public key commitment update. S402. If there is a sub-Merkel tree with insufficient capacity, hash the public key of the device to be updated and add it to the leaf node of the sub-Merkel tree, recalculate the root node value of the sub-Merkel tree and update it to the public key commitment. S403. If all sub-Merkel trees are full, create a new sub-Merkel tree with the public key of the device to be updated as the only element, add the root node of the new sub-Merkel tree to the public key commitment, and obtain the updated public key commitment. S404. Associate and store the prefix of the public key of the device to be updated with the corresponding root node value, and update the public key prefix mapping table.

[0054] It should be noted that in traditional schemes, the issuer only needs to sign the issuer's identifier, the device's identifier, and attributes when issuing a certificate. However, in cross-domain scenarios, the lack of data sharing in consortium blockchains makes it difficult for validators to verify the legitimacy of public keys by reading on-chain data. Therefore, this invention designs a new issuance process, including the following two steps: 1) Public key commitment update; 2) Signing.

[0055] In some embodiments of the invention, updates are made to public key commitments. If the issuer... The device was not provided. If a certificate has been issued, then it is necessary to... Corresponding public key Add it to the fast retrieval tree maintained locally by the validator, if previously given If a certificate has already been issued, this operation is unnecessary. The add operation can be divided into two cases: if the current fast search tree has an incomplete Merkle tree, then... Add to the incomplete Merkel tree, specifically, for Its adjacent sibling nodes are hashed to obtain the new root node. Replace the corresponding position in the table; if all Merkle trees are full, then only replace the corresponding position in the table. For each element, a new Merkle tree is constructed, and its root node is added to the public key commitment, thus obtaining the updated public key commitment. and will Upload it to the public blockchain so that validators can directly read it during the verification process. In addition, the mapping needs to be updated, first retrieved... The former bit prefix As a key, if the key already exists, the root node value of the Merkle tree corresponding to the public key is added to the value corresponding to the key; otherwise, a new key is added. A new mapping to the root node value.

[0056] By first determining whether the device has obtained a certificate, duplicate updates can be avoided, thus saving computing resources. Reusing sub-Merkel trees with insufficient capacity to update public keys improves storage utilization while ensuring the accuracy of public key commitments through real-time updates of the root node. When a sub-Merkel tree is full, a new tree is created to adapt to the growth of the number of public keys, enhancing the scalability of public key commitment updates. The public key prefix mapping table is updated synchronously to maintain the association between public keys and corresponding root nodes, facilitating rapid subsequent retrieval and improving cross-domain verification efficiency.

[0057] In some embodiments of the present invention, such as Figure 5 As shown, the initial certificate is generated by signing the public key commitment using the issuer's private key, including: S501. The issuing end identity identifier, device end identity identifier, device end attributes, Merkel proof corresponding to the device end public key, and public key commitment are concatenated to obtain the device end's signature information; the Merkel proof is the proof data composed of a series of sibling node hash values ​​on the path from the leaf node to the root node in the sub-Merkel tree where the device end public key is located. S502. Sign the information to be signed on the device using the issuer's private key to obtain the issuer's signature information; S503. Encapsulate the issuer's identity, device's identity, device attributes, Merkel proof corresponding to the device's public key, public key commitment, and issuer's signature information to obtain the initial certificate.

[0058] In some embodiments of the present invention, the signature mainly includes two steps: first, generating... Corresponding Merkel proof Merkel's proof is based on the target leaf node, i.e. The proof data consists of the hash values ​​of a series of sibling nodes along the path from the corresponding node to the root node of the Merkle tree, such as... Figure 3 middle, Merkel's proof Secondly, the issuer uses its private key to sign the relevant information (the information to be signed on the device) to ensure the authenticity and immutability of this information. This information includes the issuer's identity identifier. Equipment identification Device attributes Merkel's proof Public Key Commitment It can be obtained through the following formula 1-2: (1) (2) in, It is a signature function. Represents the use of private keys Regarding the message Sign up. This represents a string concatenation operation. Specifically, it refers to the certificate generated by the issuer, as shown in Equation 3 below: (3) By concatenating the identity, attributes, and Merkel proof information of the issuing and device ends as the content to be signed, it is possible to ensure that the initial certificate covers the core information required for authentication and guarantee information integrity. By signing with the private key of the issuing end, the uniqueness of the private key is used to ensure that the certificate is issued by a legitimate issuing end, which can prevent certificate forgery. Encapsulating all key information to generate the initial certificate and centrally packaging the associated data required for verification makes it easier for the subsequent verification end to quickly verify the authenticity and relevance of the certificate, thereby improving the efficiency of cross-domain authentication.

[0059] In some embodiments of the present invention, an interactive certificate usage method is employed, in which a display certificate is generated on the device side based on an initial certificate, and the display certificate is submitted to the verification terminal in the target area, such as... Figure 6 As shown, it includes: Receive random challenge values ​​sent by the verification terminal in the target area via the device. And reply This indicates that the device received the data correctly. And agreed to The challenge value is used to count the number of interactions; the challenge value is controlled via the device's private key. Signature generation ,Will and After splicing, the result is ,Will Uploaded to the public blockchain; verified via the public blockchain using the device's public key. After the legitimacy is established, Recorded on the public blockchain, this indicates that the device has begun the verification process; The initial certificate is signed using the device's private key to generate device-side signature information. ; Combine the initial certificate with the device signature information The certificate is encapsulated, obtained, and sent to the verification end. After verifying the legitimacy of the certificate through the verification terminal, the challenge value is signed using the verification terminal's private key to generate the signature. It is published on the public chain; this interaction is counted in the number of interactions between the issuing and verifying ends and updated to the public chain to update the historical number of interactions.

[0060] In some embodiments of the present invention, an interactive certificate usage process is designed to support the issuer's reputation score calculation. The device, in addition to... In addition to signing, the system must also support the counting of interactions to prevent the issuer from maliciously increasing the number of interactions. In this invention, the certificate usage process includes the following four steps: (1) Negotiated challenge value. The validator randomly generates a challenge value. and will Send to the device, and the device will reply upon receiving it. To show that they have received it correctly and agreed to The number of interactions is used as a challenge value.

[0061] (2) Device challenge value signing. The device uses its own private key to sign the challenge value and generate a signature. and will and After splicing, the result is ,Will Published on the public blockchain, verified by the public blockchain. Once the device is deemed legitimate, it is recorded on the blockchain, indicating that the device has begun the verification process.

[0062] (3) Certificate signing. The device... Sign it, that is ,generate and will Send it to the verifier.

[0063] (4) Verifier Challenge Value Signing. After verifying the validity of the certificate, the verifier uses their private key to sign the challenge value to generate the signature. When a document is published to a public blockchain, the number of interactions between the issuer and the validator recorded on the public blockchain is incremented by one.

[0064] Challenge value interaction can confirm valid communication between the device and the verification end, reducing invalid processes; dual signature on the device makes the certificate more trustworthy; both parties' signatures are uploaded to the public blockchain, making the authentication process verifiable and non-repudiable; by synchronously updating the number of interactions, it is easier to supervise the issuing end in the future, improving the security and trustworthiness of cross-domain authentication.

[0065] It should be noted that in cross-chain scenarios, there are issues such as the lack of data sharing among consortium blockchains and the existence of untrusted issuers. Traditional solutions based on verifying only the signature are not suitable for this scenario because it is difficult to directly verify the public keys of the issuer and the device. Therefore, this invention designs a new certificate verification process. In this invention, the verifier needs to verify three aspects: 1) verifying the legitimacy of the issuer; 2) verifying the legitimacy of the device's public key; and 3) verifying the reputation status of the issuer.

[0066] In some embodiments of the present invention, the legitimacy of the issuing end is verified by the verification end based on the certificate presented, such as... Figure 7 As shown, it includes: S701. Extract the issuer identity identifier from the certificate of presentation through the verification end, and retrieve the identity identifier from the issuer list of the public chain; S702. If the issuer identity identifier is not found, cross-domain authentication is deemed to have failed; if the issuer identity identifier is found, the corresponding issuer public key is obtained through the issuer identity identifier-public key mapping, and the issuer signature information in the initial certificate is verified through the issuer public key based on hash comparison logic. S703. If the signature information of the issuing end is verified, the issuing end is deemed legitimate; otherwise, cross-domain authentication is deemed to have failed.

[0067] In some embodiments of the present invention, the verifier from The corresponding issuer identifier can be retrieved from the search results. It then checks in the public blockchain whether the issuer has registered and retrieves the corresponding public key. And verify the issuer's signature.

[0068] By extracting the issuer's identity identifier from the displayed certificate and retrieving the list of public blockchain issuers through the verification end, unregistered and illegal issuers can be quickly filtered out using the full range of issuer information across the public blockchain. This avoids subsequent verification of invalid entities and saves verification resources. After retrieving the issuer's identity, the process of obtaining the corresponding public key through "identity identifier-public key mapping" and then verifying the issuer's signature ensures that the signature is verified using the issuer's legitimate public key, accurately determining whether the signature was genuinely issued by the issuer and preventing forged issuer signatures from passing verification. Using the signature verification result as the basis for determining the issuer's legitimacy can exclude certificates from untrusted issuers at the source, effectively improving the credibility of the issuer's identity in cross-domain authentication and reducing the authentication risks caused by illegal certificates.

[0069] In some embodiments of the present invention, the verification end verifies the legitimacy of the device's public key based on a certificate, such as... Figure 8 As shown, it includes: S801. Based on the determination that the issuing end is legitimate, the verification end extracts the public key commitment from the certificate and verifies whether the public key commitment has been stored in the public chain. S802. If the public key commitment is not stored in the public blockchain, cross-domain authentication fails. If the public key commitment is stored in the public blockchain, query the root node of the sub-Merkel tree corresponding to the public key on the device side through the public key prefix mapping table to verify whether the root node is contained in the public key commitment. S803. If the root node of the sub-Merkel tree corresponding to the device is included in the public key commitment, the root node value of the sub-Merkel tree where the hash value of the device's public key is recursively calculated based on the corresponding Merkel proof is compared with the root node value recorded in the certificate. If the comparison is successful, the device's public key is deemed valid; otherwise, cross-domain authentication is deemed to have failed.

[0070] In some embodiments of the present invention, the verifier first verifies the device public key based on a commitment. The legitimacy of, and based on Verify the device's signature. Specifically, the verifier first verifies... To verify Whether it is recorded on the public blockchain; the second step is verification. Whether or not The third step involves verifying the Merkel proof, which involves concatenating the elements in the Merkel proof pairwise, recursively hashing them to obtain the root node, and then comparing the calculated root node with the input. and Recorded in If the comparison is successful, then... It is legal and based on Verify the device's signature.

[0071] First, verify whether the public key commitment is on the public blockchain based on the legitimate issuing end. This can exclude invalid commitments that are not registered and save verification resources. Then, use the public key prefix mapping table to quickly locate the corresponding Merkle tree root node and verify whether it is included in the commitment, which improves the retrieval efficiency of public key ownership. By calculating the root node through hash and Merkle proof and comparing it, the authenticity and integrity of the public key can be accurately verified, effectively ensuring the legitimacy of the device-side public key and reducing the risk of fake public keys in cross-domain authentication.

[0072] In some embodiments of the present invention, the issuing end reputation information includes an issuing end blacklist and issuing end activity quantification data; the issuing end blacklist generation method includes: S901. Based on the determination of the legality of the device's public key, if the device's identity or attributes are found to be fake through the verification end, the preset amount of collateral assets will be pledged to the corresponding issuing end of the public chain report. S902. If the number of reports received by the public chain against the same issuer exceeds the preset reporting threshold within the preset period, the identity of the issuer will be written into the blacklist and stored in the public chain, and the digital assets pledged by the verification end will be returned to the verification end. If the preset reporting threshold is not reached, the public chain will not write the issuer into the blacklist and will retain the pledged assets of the verification end.

[0073] In some embodiments of this invention, a distributed reporting mechanism is designed. When a validator discovers that a device's identity is inconsistent or its attributes are falsified, the validator can report the issuer as a malicious issuer by pledging a portion of digital assets to the blockchain. Pledging digital assets raises the reporting threshold, preventing validators from making malicious reports. If the blockchain receives more than a certain number of reports from different validators within a certain period, the issuer is blacklisted, and the pledged digital assets are returned to the validators. This invention maintains a mapping `black_list` on the blockchain, where the key is the issuer's identity identifier. The value is a boolean value. If the value is True, it means that the issuer has been blacklisted; otherwise, the issuer has not been blacklisted.

[0074] The mechanism for reporting collateral assets on the verification side can reduce malicious reporting; the rule of blacklisting the issuing end only when a threshold is reached can avoid misjudgment; the blacklist is stored in the public chain to achieve cross-regional sharing, and the rewards and punishments (refund / retention of collateral assets) can regulate reporting and effectively restrain the fraudulent behavior of the issuing end.

[0075] In some embodiments of the present invention, the active measurement data of the issuing end is obtained by weighted average calculation, and the specific calculation formula is as follows: (4) in, To increase the activity of the issuing end, and These are the weighting coefficients. The number of times the issuing end updates the public key commitment. This represents the historical number of interactions between the issuing end and the current verifying end. For the identity identifier of the issuing end, This serves as the identity identifier for the verification end.

[0076] In some embodiments of this invention, a weighted average-based issuer activity metric mechanism is designed. In this invention, activity comprises two components: one is the number of times the issuer updates its public key commitment, which is recorded in... middle, It is a one-dimensional mapping, where the key is the issuer's identity identifier. The value represents the number of times the issuer updates its public key commitment; on the other hand, it represents the number of interactions between a specific issuer and a specific verifier. This invention uses a one-dimensional mapping. To record, the key is , This represents a concatenation operation, where the string resulting from concatenating the issuer's identity identifier and the verifier's identity identifier serves as the key, and the value is... and The number of interactions when the device is used Certificates issued and verifiers Perform the interaction; if the verification passes, then g_mapp[ Add one. Based on the number of updates and interactions, this invention calculates the issuer's reputation value using a weighted average.

[0077] The activity level is calculated by weighting the number of times the issuing end's public key commitment is updated and the number of interactions with the verification end, which can more comprehensively reflect its actual business participation. The adjustable weight design also adapts to the reputation assessment needs of different scenarios.

[0078] In some embodiments of the present invention, the verification end verifies the reputation status of the issuing end based on the display certificate, including: S1001. After verifying the legitimacy of the issuing end and the public key of the device, the verification end queries the public chain to see if the issuing end is blacklisted; the verification end obtains the activity level of the issuing end from the public chain. S1002. If the issuing end is not blacklisted and its activity level is greater than the preset activity level threshold, the cross-domain identity is deemed trustworthy; otherwise, the cross-domain authentication is deemed to have failed.

[0079] First, check the blacklist to quickly eliminate malicious issuers, and then verify activity to filter out low-participation entities. This two-dimensional verification improves the accuracy of issuer reputation assessment and further ensures the credibility of cross-domain authentication.

[0080] It should be noted that, due to the possibility of untrusted issuers issuing erroneous certificates, this invention mitigates this situation by verifying the issuer's credibility. In this invention, the issuer's credibility is determined by two factors: first, whether the issuer has been blacklisted; and second, whether the issuer is sufficiently active. Specifically, the verifier needs to verify two aspects: 1) Whether the issuer has been blacklisted. This invention designs a distributed reporting mechanism, allowing issuers from different regions to report issuers by staking digital assets. If a certain number of reports are received within a certain period, the issuer is added to the blacklist. If the verifier finds that the issuer is already blacklisted, it indicates that the issuer is malicious, and the verification fails; 2) Whether the issuer's activity level exceeds a certain threshold. This invention designs a weighted average issuer activity metric strategy. If the issuer's activity level exceeds a certain threshold, the issuer is considered trustworthy; otherwise, the verification fails.

[0081] In some embodiments of the present invention, the pseudocode for verifying the legitimacy of the issuing end, the legitimacy of the device's public key, and the reputation status of the issuing end is as follows:

[0082] The cross-domain distributed identity trusted authentication method in the Internet of Things scenario provided by the present invention has been described in detail above. Specific examples have been used to illustrate the principle and implementation of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core idea of ​​the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation and application scope based on the idea of ​​the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A cross-domain distributed trusted identity authentication method in an Internet of Things (IoT) scenario, characterized in that, include: Construct a blockchain authentication system, which includes one public blockchain and several consortium blockchains; Each consortium blockchain corresponds to a region, which is used to store the identity identifier-public key mapping between the device and the issuer within that region; the public blockchain is used to store the list of issuers, public key commitment mappings, and issuer reputation information for all regions; the public key commitment mapping is a mapping between the issuer and the public key commitment of the issuing device. During the certificate issuance phase, a fast index tree is used to update the public key commitment on the device side, generate a public key commitment, and upload it to the public blockchain; the public key commitment is signed with the private key of the issuing end to generate an initial certificate; During the certificate usage phase, an interactive certificate usage method is adopted, in which the device generates a display certificate based on the initial certificate and submits the display certificate to the verification terminal in the target area. During the certificate verification phase, the verification end verifies the legitimacy of the issuing end, the legitimacy of the device's public key, and the reputation status of the issuing end based on the displayed certificate, thus completing cross-domain identity trusted authentication.

2. The method according to claim 1, characterized in that, The construction of the fast index tree includes: Construct a sharded Merkle tree and a public key prefix mapping table to form a fast index tree; The sharded Merkle tree consists of multiple sub-Merkle trees with preset subtree storage capacity. Each sub-Merkle tree is a standard traditional Merkle tree used to store the device-side public key. The device-side public key is hashed and stored in the leaf node of the sharded Merkle tree. The root nodes of all the sub-Merkle trees are then concatenated in order to form a public key commitment. The key of the public key prefix mapping table is a prefix of a preset prefix length for the device-side public key, and the value is the root node value of the sub-Merkel tree where the device-side public key is located.

3. The method according to claim 2, characterized in that, The step of updating the public key commitment on the device side includes: If a certificate has been issued to the device through the issuing end, there is no need to update the public key commitment; if the certificate has not been issued to the device through the issuing end, the public key of the device to be updated needs to be added to the sharded Merkle tree for public key commitment update. If there is a sub-Merkel tree with insufficient capacity, hash the public key of the device to be updated and add it to the leaf node of the sub-Merkel tree, recalculate the root node value of the sub-Merkel tree and update it to the public key commitment. If all sub-Merkel trees are full, a new sub-Merkel tree is created using the public key of the device to be updated as the unique element. The root node of the newly created sub-Merkel tree is added to the public key commitment to obtain the updated public key commitment. The public key prefix mapping table is updated by associating the prefix of the preset prefix length of the public key to be updated with the corresponding root node value.

4. The method according to claim 1, characterized in that, The step of signing the public key commitment using the issuer's private key to generate the initial certificate includes: The device's signature information is obtained by concatenating the issuer's identity identifier, device's identity identifier, device attributes, Merkel proof corresponding to the device's public key, and public key commitment; the Merkel proof is proof data composed of a series of sibling node hash values ​​on the path from the leaf node to the root node in the sub-Merkel tree where the device's public key is located. The device-side information to be signed is signed using the issuer's private key to obtain the issuer's signature information; The initial certificate is obtained by encapsulating the issuer identity, device identity, device attributes, Merkel proof corresponding to the device public key, public key commitment, and issuer signature information.

5. The method according to claim 4, characterized in that, The interactive certificate usage method, which generates a display certificate on the device based on the initial certificate and submits the display certificate to the verification terminal in the target area, includes: Receive random challenge values ​​sent by the verification terminal in the target area via the device. And reply This indicates that the device received the data correctly. And agreed to The challenge value is used to count the number of interactions; the challenge value is controlled via the device's private key. Signature generation ,Will and After splicing, the result is ,Will Uploaded to the public blockchain; verified via the public blockchain using the device's public key. After the legitimacy is established, Recorded on the public blockchain, this indicates that the device has begun the verification process; The initial certificate is signed using the device's private key to generate device-side signature information. ; Combine the initial certificate with the device signature information The certificate is encapsulated, obtained, and sent to the verification end. After verifying the legitimacy of the certificate through the verification terminal, the challenge value is signed using the verification terminal's private key to generate the signature. It is published on the public chain; this interaction is counted in the number of interactions between the issuing and verifying ends and updated to the public chain to update the historical number of interactions.

6. The method according to claim 1, characterized in that, The process of verifying the legitimacy of the issuing end based on the displayed certificate includes: The issuer identity identifier is extracted from the certificate of presentation by the verification end, and then the identity identifier is retrieved from the list of issuers in the public blockchain. If the issuer identity identifier is not found, cross-domain authentication is deemed to have failed; if the issuer identity identifier is found, the corresponding issuer public key is obtained through the issuer identity identifier-public key mapping, and the issuer signature information in the initial certificate is verified through the issuer public key based on hash comparison logic. If the signature information of the issuing end is verified, the issuing end is deemed legitimate; otherwise, cross-domain authentication is deemed to have failed.

7. The method according to claim 6, characterized in that, The step of verifying the legitimacy of the device's public key based on the displayed certificate by the verification end includes: Based on the determination of the legitimacy of the issuing end, the verification end extracts the public key commitment from the displayed certificate and verifies whether the public key commitment has been stored in the public blockchain; If the public key commitment is not stored in the public blockchain, cross-domain authentication fails; if the public key commitment is stored in the public blockchain, query the root node of the sub-Merkel tree corresponding to the device's public key through the public key prefix mapping table to verify whether the root node is contained in the public key commitment. If the root node of the corresponding sub-Merkel tree on the device is included in the public key commitment, the root node value of the sub-Merkel tree is recursively calculated based on the hash value of the device's public key and the corresponding Merkel proof. The calculated root node value is then compared with the root node value recorded in the certificate. If the comparison is successful, the device's public key is deemed valid; otherwise, cross-domain authentication is deemed to have failed.

8. The method according to claim 7, characterized in that, The issuer reputation information includes an issuer blacklist and quantified issuer activity data; the issuer blacklist is generated in the following ways: Based on the determination of the legality of the device's public key, if the device's identity or attributes are found to be fake through the verification end, the preset amount of collateral assets will be pledged to the corresponding issuing end of the public chain report. If the number of reports received by the public chain against the same issuer exceeds the preset reporting threshold within the preset period, the issuer's identity will be added to the blacklist and stored in the public chain, and the digital assets pledged by the verification end will be returned to the verification end. If the preset reporting threshold is not reached, the public chain will not add the issuer to the blacklist and will retain the verification end's pledged assets.

9. The method according to claim 7, characterized in that, The active data of the issuing end is calculated by weighted average, and the specific calculation formula is as follows: in, To increase the activity of the issuing end, and These are the weighting coefficients. The number of times the issuing end updates the public key commitment. This refers to the historical number of interactions between the issuing end and the current verifying end. For the identity identifier of the issuing end, This serves as the identity identifier for the verification end.

10. The method according to claim 9, characterized in that, The process of verifying the credibility of the issuing end based on the displayed certificate by the verification end includes: After verifying the legitimacy of the issuing end and the public key of the device, the verification end queries the public chain to see if the issuing end is blacklisted; the verification end also obtains the activity level of the issuing end from the public chain. If the issuing end is not blacklisted and its activity level is greater than the preset activity level threshold, the cross-domain identity is deemed trustworthy; otherwise, the cross-domain authentication is deemed to have failed.

Images