Cross-chain identity authentication method and device, electronic equipment, storage medium and product

Abstract

The invention provides a cross-chain identity authentication method and device, electronic equipment, a storage medium and a product. The method comprises the following steps: receiving an identity authentication request of a target node in a first block chain, and obtaining account login information of the target node in the first block chain, a first verification result of a target server on the target node and digital signature information of the target node; in response to successful verification of the digital signature information, obtaining a second verification result of the target node; in response to the fact that the second verification result is the same as the first verification result, distributing a target data permission to the target node in the second block chain; and in response to account login information of the target node in the first block chain, the target data permission is written into a block of the second block chain, and an identity authentication passing message is sent to the first block chain.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of identity authentication, and particularly relates to a cross-chain identity authentication method and device, electronic equipment, storage medium and product. BACKGROUND

[0002] In related cross-chain identity authentication schemes, a common cross-chain identity mutual authentication method is usually used, but the security levels of different types of blockchains are not considered, that is, the access permissions are different, and thus when a node in a blockchain with a low security level accesses data in a blockchain with a high security level, the data security cannot be guaranteed, and the risk of data leakage and illegal access is high. SUMMARY

[0003] The present disclosure provides a cross-chain identity authentication method, device, electronic equipment, storage medium and product to solve the problems in the related art.

[0004] The first aspect embodiment of the present disclosure provides a cross-chain identity authentication method, which comprises the following steps: receiving an identity authentication request of a target node in a first blockchain, obtaining account login information of the target node in the first blockchain, a first verification result of the target node by a target server, and digital signature information of the target node; in response to successful verification of the digital signature information, obtaining a second verification result of the target node; in response to the second verification result being the same as the first verification result, assigning a target data permission to the target node in a second blockchain; in response to writing the account login information of the target node in the first blockchain and the target data permission into a block of the second blockchain, sending an identity authentication pass message to the first blockchain.

[0005] In an embodiment, before receiving an identity authentication request of a target node in a first blockchain, obtaining account login information of the target node in the first blockchain, a first verification result of the target node by a target server, and digital signature information of the target node, the method provided by the present disclosure further comprises the following steps: receiving a public key generated by the target node, the public key and a private key generated by the target node forming an asymmetric encryption key pair, the private key being used for signature processing on the first verification result of the target node, a chain type identifier and a chain identifier of the first blockchain to generate the digital signature information, and the public key being used for verification of the digital signature information.

[0006] In an embodiment, in response to the second verification result being the same as the first verification result, assigning a target data permission to the target node in a second blockchain, comprises the following steps: in response to the second verification result being the same as the first verification result, determining whether the first blockchain is a blockchain that has established a node mutual trust relationship with the second blockchain. In response to the first blockchain being a blockchain that establishes a node mutual trust relationship with the second blockchain, obtain trust degree information of the first blockchain and the second blockchain; Based on the trust degree information, assign a target data authority to the target node in the second blockchain.

[0007] In an embodiment, based on the trust degree information, assigning a target data authority to the target node in the second blockchain comprises: Determine a trust level of the trust degree information; From a mapping relationship between the trust level and the data authority, determine a target data authority corresponding to the trust level; Assign the target data authority to the target node in the second blockchain.

[0008] In an embodiment, after determining whether the first blockchain is a blockchain that establishes a node mutual trust relationship with the second blockchain in response to the second verification result being the same as the first verification result, the method provided by the present disclosure further comprises: In response to the first blockchain not being a blockchain that establishes a node mutual trust relationship with the second blockchain, obtain a chain type identifier of the second blockchain; Based on the chain type identifier of the second blockchain and the chain type identifier of the first blockchain, determine high-low information of a data security level between the first blockchain and the second blockchain; According to the high-low information of the data security level, assign a target data authority to the target node in the second blockchain.

[0009] In an embodiment, according to the high-low information of the data security level, assigning a target data authority to the target node in the second blockchain comprises: In response to the high-low information of the data security level being that the data security level of the first blockchain is lower than the data security level of the second blockchain, determine the first data authority as the target data authority assigned to the target node in the second blockchain; In response to the high-low information of the data security level being that the data security level of the first blockchain is not lower than the data security level of the second blockchain, determine the second data authority as the target data authority assigned to the target node in the second blockchain.

[0010] In an embodiment, the identity authentication request further comprises a target timestamp and a consensus result of the target node in the first blockchain, and the target timestamp and the consensus result are used to determine that the identity of the target node is trusted.

[0011] In an embodiment, after receiving the identity authentication request of the target node in the first blockchain, obtaining account login information of the target node in the first blockchain, a first verification result of the target server on the target node, and digital signature information of the target node, the method provided by the present disclosure further comprises: In response to the failure to verify the digital signature information, a first notification message is sent to the target node. The first notification message is used to indicate that the identity authentication request failed.

[0012] In one embodiment, after obtaining the second verification result of the target node in response to successful verification of the digital signature information, the method provided in this disclosure further includes: In response to the difference between the second verification result and the first verification result, a second notification message is sent to the target node. The second notification message is used to indicate that the identity authentication request failed.

[0013] In one embodiment, in response to writing the target node's account login information and target data permissions in the first blockchain into a block of the second blockchain, and sending an authentication pass message to the first blockchain, the method provided in this disclosure further includes: In response to the target data in the block of the second blockchain, which includes the identity authentication request, the target data is sent to the target node.

[0014] In one embodiment, the chain type identifier indicates the chain type, including public chain, private chain, and consortium chain.

[0015] A second aspect of this disclosure provides a cross-chain identity authentication device, comprising: The first acquisition unit is used to receive the identity authentication request of the target node in the first blockchain, and to acquire the account login information of the target node in the first blockchain, the first verification result of the target server on the target node, and the digital signature information of the target node. The second acquisition unit is used to acquire the second verification result of the target node in response to the successful verification of the digital signature information. An allocation unit is used to allocate target data permissions to a target node in the second blockchain in response to the second verification result being the same as the first verification result. The authentication unit is used to send an authentication pass message to the first blockchain in response to writing the target node's account login information and target data permissions in the first blockchain into a block of the second blockchain.

[0016] A third aspect of this disclosure provides an electronic device comprising: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the methods described in the first aspect of this disclosure.

[0017] A fourth aspect of this disclosure provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to perform the methods described in the first aspect of this disclosure.

[0018] A fifth aspect of this disclosure provides a computer program product including a computer program that, when executed by a processor, implements the methods described in the first aspect of this disclosure.

[0019] In summary, this disclosure proposes a cross-chain identity authentication method, which includes: receiving an identity authentication request from a target node in a first blockchain; obtaining the target node's account login information in the first blockchain, the first verification result of the target node by the target server, and the target node's digital signature information; in response to successful verification of the digital signature information, obtaining the target node's second verification result; in response to the second verification result being the same as the first verification result, assigning target data permissions to the target node in the second blockchain; and in response to writing the target node's account login information and target data permissions in the first blockchain into a block of the second blockchain, sending an identity authentication pass message to the first blockchain.

[0020] According to the solution provided in this disclosure, by receiving an identity authentication request from a target node in the first blockchain, the system obtains the target node's account login information in the first blockchain, the target server's first verification result for the target node, and the target node's digital signature information. If the digital signature information is successfully verified, it confirms that the target node's identity is authentic and that the data, including the first verification result, has not been tampered with, and obtains the target node's second verification result. If the second verification result is the same as the first verification result, it ensures that the identity certificate on which the permission allocation is based is original and authentic, and assigns target data permissions to the target node in the second blockchain. By writing the target node's account login information and target data permissions in the first blockchain into a block of the second blockchain and sending an identity authentication pass message to the first blockchain, the system can prevent the permission configuration from being tampered with afterward, thereby reducing the security risks arising from data access from the target node in the first blockchain and lowering the risk of data leakage and unauthorized access during cross-chain data access.

[0021] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0023] Figure 1A schematic diagram illustrating a cross-chain identity authentication method provided in this application embodiment; Figure 2 A flowchart illustrating the cross-chain identity authentication method provided in this embodiment of the disclosure; Figure 3 A flowchart illustrating a method for assigning target data permissions to a target node, provided in an embodiment of this disclosure; Figure 4 A flowchart illustrating another method for assigning target data permissions to a target node, provided in an embodiment of this disclosure; Figure 5 This is a schematic diagram of the cross-chain identity authentication device provided in the embodiments of this disclosure; Figure 6 This is a schematic diagram of the hardware composition structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0024] Embodiments of this disclosure are described in detail below. Examples of these embodiments are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this disclosure, and should not be construed as limiting this disclosure.

[0025] "Web3.0" is an improvement on "Web2.0." In this environment, users no longer need to create multiple identities on different centralized platforms. Instead, they can build a decentralized, universal digital identity system that works across various platforms. Web3.0 is used to describe the potential next stage of the internet: a decentralized internet that runs on "blockchain" technology.

[0026] China Mobile Chain Web3.0 Center provides cross-chain identity verification. This cross-chain identity verification allows users to use the same set of identity information for authentication across different blockchain networks. Through standardized protocols and decentralized identity management, it achieves unified verification of identities across multiple platforms, protecting user privacy while promoting interoperability between different blockchain networks.

[0027] Generally, blockchain networks can be categorized into public blockchains (PBlockchain), private blockchains (Private Blockchain), and consortium blockchains (Consortium Blockchain). The core characteristics of public blockchains are decentralization and openness; anyone can become a node and participate in the blockchain network. The core characteristics of private blockchains are access control and efficiency; only authorized users can access and participate in the blockchain network. The core characteristics of consortium blockchains are decentralization and collaborative management; various organizations or institutions jointly participate in the management and maintenance of the blockchain network. The advantage of consortium blockchains lies in combining the advantages of both public and private blockchains. They possess both decentralization and transparency, as well as access control and efficiency, making them suitable for cooperation and sharing among multiple organizations or institutions.

[0028] Below is a brief introduction to two cross-chain identity authentication methods in related technologies: Solution A provides a blockchain system comprising a first blockchain and a second blockchain. The first blockchain includes at least one first node, which in turn includes a first cross-chain node; the second blockchain includes at least one second node, which in turn includes a second cross-chain node. The first and second blockchains communicate with each other through the first and second cross-chain nodes. Through this blockchain system, a blockchain can communicate with other blockchains via its corresponding cross-chain nodes, thus forming a complete blockchain communication architecture in communication business scenarios.

[0029] Solution B provides a blockchain-based transaction method and related equipment. The blockchain-based transaction method includes: a blockchain trading platform receiving a target transaction request sent by a first blockchain node, the target transaction request including the identity information of the first blockchain node and the identity information of a second blockchain node; the blockchain trading platform verifying the legality of the identity information of the first and second blockchain nodes; if legal, the blockchain trading platform grants transaction permissions between the first and second blockchain nodes, wherein the transaction permissions include access permissions of the first blockchain node to the identity information of the second blockchain node, and access permissions of the second blockchain node to the identity information of the first blockchain node, providing a convenient, efficient, transparent, and secure transaction method for both buyers and sellers.

[0030] The above solution has the following drawbacks: Cross-chain identity recognition does not yet take into account the security characteristics of different types of blockchain networks. It only provides a general method for cross-chain identity recognition. If the data security level requirements of the blockchain to which the blockchain node currently belongs and the blockchain across which its cross-chain authentication is conducted (the target blockchain) are inconsistent, especially when the data security level of the target blockchain is relatively high, it cannot be guaranteed that data access from other blockchain nodes will not pose a security risk. The risk of data leakage and unauthorized access is high.

[0031] To address the shortcomings of related technologies, this disclosure receives an identity authentication request from a target node in the first blockchain, obtains the target node's account login information in the first blockchain, the target server's first verification result for the target node, and the target node's digital signature information. If the digital signature information is successfully verified, it confirms the target node's authenticity and that the data, including the first verification result, has not been tampered with, and obtains the target node's second verification result. If the second verification result is the same as the first verification result, it ensures that the identity certificate used for permission allocation is original and authentic, and assigns target data permissions to the target node in the second blockchain. By writing the target node's account login information and target data permissions in the first blockchain into a block of the second blockchain and sending an identity authentication pass message to the first blockchain, it can prevent the permission configuration from being tampered with afterward, thereby reducing the security risks arising from data access from the target node in the first blockchain and lowering the risk of data leakage and unauthorized access during cross-chain data access.

[0032] The present disclosure will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0033] This disclosure provides a cross-chain identity authentication method, such as... Figure 1 As shown, Figure 1 This illustration shows a scenario of a cross-chain identity authentication method provided in this application, comprising a blockchain system with a first blockchain and a second blockchain. The first blockchain includes an identity verification platform Q; the second blockchain includes an identity verification platform X. The method can be executed by the identity verification platform X of the second blockchain. The method can be used in cross-chain interaction scenarios where a user uses a node on one blockchain to access resources on another blockchain, such as cross-chain data querying and sharing.

[0034] like Figure 2 As shown, Figure 2 This is a flowchart illustrating the cross-chain identity authentication method provided in this embodiment of the disclosure. The cross-chain identity authentication method provided in this embodiment of the disclosure includes the following steps: Step 201: Receive the identity authentication request of the target node in the first blockchain, and obtain the account login information of the target node in the first blockchain, the first verification result of the target server for the target node, and the digital signature information of the target node; In one embodiment, the first blockchain and the second blockchain refer to two different blockchain networks. The first blockchain is the source chain to which the target node currently belongs, and the second blockchain is the target chain that the user wishes to access. Both the first and second blockchains can be public, private, or consortium blockchains. The target node refers to the user initiating the cross-chain authentication request or the device they use, such as a mobile phone or computer, and is a legitimate member on the first blockchain. The identity authentication request refers to a data packet sent by the target node to the identity verification platform of the second blockchain to apply for cross-chain access permissions.

[0035] In one embodiment, the target node's account login information in the first blockchain can be the target node's identity credentials on the first blockchain, typically including a registered username and password (or other authentication information, such as facial features).

[0036] In one embodiment, the target server refers to the identity verification platform Q in the first blockchain, which is responsible for verifying the legitimacy of the target node's identity on its blockchain. The first verification result refers to the proof document (such as a data token or message) issued by the target server (identity verification platform Q) after the target node's identity verification is successful, proving that the target node is a legitimate user of the first blockchain. The target node successfully logs in on the first blockchain, the target server (identity verification platform Q) verifies its legitimacy, generates the first verification result R, and obtains the type identifier of the first blockchain, such as public chain and chain identifier 01.

[0037] In one embodiment, the digital signature information is a unique string of data generated by the target node using its private key to perform a signature operation on the first verification result, the type identifier of the first blockchain, and the chain identifier. In one embodiment, the identity verification platform X of the second blockchain receives the identity authentication request from the target node in the first blockchain through an application programming interface (API), message queue, or peer-to-peer (P2P) network.

[0038] In one embodiment, an identity authentication request from a target node in a first blockchain is received, the identity authentication request is parsed, and the target node's account login information in the first blockchain, the target server's first verification result of the target node, and the target node's digital signature information are obtained.

[0039] Step 202: In response to the successful verification of the digital signature information, obtain the second verification result of the target node; In one embodiment, the identity verification platform X of the second blockchain uses the public key of the target node to verify the received digital signature information. If the verification is successful, it proves that the information covered by the signature has not been tampered with.

[0040] In one embodiment, the second verification result of the target node refers to comparing the first verification result, chain type identifier, and chain identifier recovered during the verification process with the corresponding information directly carried in the identity authentication request after the signature verification is successful. If they are completely consistent, it means that the information has not been tampered with during the transmission process.

[0041] Step 203: In response to the second verification result being the same as the first verification result, assign target data permissions to the target node in the second blockchain; In one embodiment, target data permissions refer to the data access permissions assigned to the target node by the identity verification platform of the second blockchain after successful cross-chain authentication.

[0042] In one embodiment, in response to the second verification result being the same as the first verification result, target data permissions can be assigned to the target node in the second blockchain based on the degree of mutual trust between the first blockchain and the second blockchain.

[0043] In one embodiment, in response to the second verification result being the same as the first verification result, target data permissions can be assigned to the target node in the second blockchain based on the relative levels of data security between the first blockchain and the second blockchain.

[0044] Step 204: In response to writing the target node's account login information and target data permissions in the first blockchain into a block of the second blockchain, send an identity authentication pass message to the first blockchain.

[0045] In one embodiment, writing the target node's account login information and target data permissions in the first blockchain into a block of the second blockchain means submitting the target node's username, password, and assigned permissions as a new transaction to the second blockchain network. After consensus is reached, the transaction is permanently recorded in a block of the blockchain, marking the completion of cross-chain registration.

[0046] In one embodiment, an identity authentication pass message can be sent to the first blockchain via SMS, email, or other means. This application does not limit the specific method of message sending.

[0047] This application receives an identity authentication request from a target node in the first blockchain, obtains the target node's account login information in the first blockchain, the target server's first verification result of the target node, and the target node's digital signature information. If the digital signature information is successfully verified, it confirms the target node's identity is genuine and that the data, including the first verification result, has not been tampered with, and obtains the target node's second verification result. If the second verification result is the same as the first verification result, it ensures that the identity certificate used for permission allocation is original and authentic, and assigns target data permissions to the target node in the second blockchain. By writing the target node's account login information and target data permissions in the first blockchain into a block of the second blockchain and sending an identity authentication pass message to the first blockchain, it can prevent the permission configuration from being tampered with afterward, thereby reducing the security risks arising from data access from the target node in the first blockchain and lowering the risk of data leakage and unauthorized access during cross-chain data access.

[0048] In one embodiment, before receiving the identity authentication request of the target node in the first blockchain, and before obtaining the target node's account login information in the first blockchain, the target server's first verification result of the target node, and the target node's digital signature information, the method provided in this disclosure further includes: Receive the public key generated by the target node. The public key and the private key generated by the target node form an asymmetric encryption key pair. The private key is used to sign the first verification result of the target node, the chain type identifier and the chain identifier of the first blockchain to generate digital signature information. The public key is used to verify the digital signature information.

[0049] In one embodiment, digital signature information refers to information generated by encrypting the hash value of the information using the private key of the target node, and anyone holding the public key of the target node can verify the digital signature information.

[0050] In one embodiment, verifying digital signature information refers to the process of using a public key to verify whether a digital signature is generated by its corresponding private key and to confirm that the information covered by the digital signature has not been tampered with.

[0051] In one embodiment, the chain type identifier refers to the nature of the blockchain (such as a public chain or a consortium chain), and the chain identifier is a unique ID of the chain used to distinguish different blockchains.

[0052] In one embodiment, the target node sends its public key to the identity verification platform X of the second blockchain via a secure channel, such as Hyper Text Transfer Protocol (HTTP) or in the initial cross-chain request (identity authentication request). The private key is securely stored locally on the device, ideally in a Trusted Execution Environment (TEE) or a hardware security module.

[0053] In one embodiment, the identity verification platform X receives the public key and associates it with the registered account name (or other unique identifier) ​​of the target node in the database. For example, a mapping table {"Account Name A":"Public Key 0x123"} is established so that when the platform receives a cross-chain request from the account, it can quickly find the corresponding public key to verify the signature. Without the public key, the authenticity of the signature cannot be verified, and the entire cross-chain identity mutual recognition mechanism will not be able to operate.

[0054] In one embodiment, such as Figure 3 As shown, Figure 3 This is a flowchart illustrating a method for allocating target data permissions to a target node according to an embodiment of the present disclosure. In response to a second verification result being identical to a first verification result, target data permissions are allocated to the target node in a second blockchain, including: Step 301: In response to the second verification result being the same as the first verification result, determine whether the first blockchain is a blockchain that has established a node mutual trust relationship with the second blockchain; In one embodiment, the fact that the second verification result is the same as the first verification result indicates that the identity verification platform of the second blockchain has successfully completed the signature verification and information consistency verification of the cross-chain request.

[0055] In one embodiment, the identity verification platform X accesses a mutual trust database or configuration file, which stores a list of all blockchains that have established mutual trust relationships with the second blockchain and their chain identifiers. By querying the chain identifier of the first blockchain in the database or configuration file, it determines whether the first blockchain is a blockchain that has established a node mutual trust relationship with the second blockchain.

[0056] In one embodiment, a mutual trust relationship refers to a formal trust agreement established in advance between the operators or governance organizations of two blockchains (a first blockchain and a second blockchain). This relationship is typically based on shared business objectives, security standards, or alliance membership, such as a memorandum of trust signed between two enterprise consortium blockchains.

[0057] Step 302: In response to the first blockchain being a blockchain that has established a node trust relationship with the second blockchain, obtain the trust level information between the first blockchain and the second blockchain; In one embodiment, trust level information refers to a hierarchical definition of the level of trust between two parties based on an established mutual trust relationship between nodes. It is usually divided into multiple levels (such as primary, intermediate, and advanced), with different levels corresponding to different data sharing and access permissions, reflecting the degree of consensus between the two parties on security strategies, governance mechanisms, and risk tolerance.

[0058] Step 303: Based on the trust level information, assign target data permissions to the target node in the second blockchain.

[0059] In one embodiment, after confirming the mutual trust relationship between the first blockchain and the second blockchain, the trust level information between the first blockchain and the second blockchain is obtained from the aforementioned mutual trust relationship database, including the specific trust level between the first blockchain and the second blockchain. According to the pre-set permission mapping rules, the target data permissions corresponding to the trust level are determined. The higher the trust level, the greater the data permissions.

[0060] In one embodiment, by responding to the second verification result being the same as the first verification result, it is determined whether the first blockchain is a blockchain that has established a node mutual trust relationship with the second blockchain; in response to the first blockchain being a blockchain that has established a node mutual trust relationship with the second blockchain, the trust level information between the first blockchain and the second blockchain is obtained; based on the trust level information, target data permissions are assigned to the target node in the second blockchain, which can be graded according to the trust level, realizing the refinement of cross-chain identity authentication, and is suitable for consortium blockchains and enterprise-level blockchain scenarios with high requirements for data security and access control.

[0061] In one embodiment, based on trust level information, target data permissions are assigned to target nodes in the second blockchain, including: Determine the trust level of the trust information; In one embodiment, trust levels can typically include primary, intermediate, and advanced levels, and can also be divided into more trust levels depending on the granularity of the data permissions required by the user.

[0062] Determine the target data permissions corresponding to the trust level from the mapping relationship between trust level and data permissions; In one embodiment, the mapping relationship between trust level and data permission can be represented in the form of a mapping relationship table or in the form of a mapping relationship array, and this application does not limit it in this way.

[0063] In one embodiment, taking the aforementioned trust levels as primary, intermediate, and advanced as an example, the target data permissions corresponding to the trust level are determined from the mapping relationship between trust levels and data permissions. These include: the target data permissions corresponding to primary level include non-sensitive data, such as public or low-risk data, such as block height, network status, and public market information; the target data permissions corresponding to intermediate level refer to the target data permissions corresponding to primary level, which also include sensitive data, such as data requiring authorized access, such as user behavior logs, transaction statistical analysis, and non-core business data; and the target data permissions corresponding to advanced level refer to the target data permissions corresponding to intermediate level, which also include confidential data, such as data with the highest level of confidentiality, such as private key management records, internal audit logs, and core business strategy data.

[0064] Assign target data permissions to the target node in the second blockchain.

[0065] In one embodiment, taking a target node as an example, after determining the target data permissions, the target data permissions are allocated to the target node in the second blockchain as follows: when the queried mutual trust level is primary, the identity verification platform X allocates access permissions for non-sensitive data, such as publicly available market data, to the target node's registered account name A; when the queried mutual trust level is intermediate, the identity verification platform X allocates access permissions for sensitive data (such as user behavior analysis data, but excluding personal identification information) and non-sensitive data to the target node's registered account name A; when the queried mutual trust level is primary, the identity verification platform X allocates access permissions for confidential data (such as internal transaction records), sensitive data, and non-sensitive data to the target node's registered account name A.

[0066] In one embodiment, different blockchains can be assigned different trust levels based on their depth of cooperation, thereby obtaining corresponding data access permissions, enabling the blockchain network to manage the access of external blockchains in a refined manner.

[0067] In one embodiment, such as Figure 4 As shown, Figure 4 This is a flowchart illustrating another method for allocating target data permissions to a target node according to an embodiment of this disclosure. In response to the second verification result being the same as the first verification result, after determining whether the first blockchain is a blockchain that has established a node trust relationship with the second blockchain, the method provided in this disclosure further includes: Step 401: In response to the fact that the first blockchain is not a blockchain that has established a node trust relationship with the second blockchain, obtain the chain type identifier of the second blockchain; In one embodiment, a blockchain that does not establish node trust with a second blockchain refers to a blockchain where the first blockchain and the second blockchain have not pre-established trust through a formal protocol. For example, if a user on a public blockchain attempts to access an independent consortium blockchain, data permissions cannot be assigned based on the level of trust.

[0068] In one embodiment, the data security level is determined based on the relative security levels of the two blockchains. Private blockchains are generally considered equivalent to consortium blockchains, with consortium blockchains considered superior to public blockchains, and this information is used to determine the level of access permissions a target node should receive.

[0069] Step 402: Based on the chain type identifier of the second blockchain and the chain type identifier of the first blockchain, determine the data security level information between the first blockchain and the second blockchain. In one embodiment, the chain type identifier of the first blockchain can be extracted from the cross-chain request, and the chain type identifier of the second blockchain can be obtained from the local configuration.

[0070] Step 403: Based on the data security level information, assign target data permissions to the target node in the second blockchain.

[0071] In one embodiment, as shown in Table 1, Table 1 is a table showing the relationship between the type of the original blockchain (first blockchain), the type of the target blockchain (second blockchain), the relative relationship of data security levels, and the data access permissions that can be allocated to nodes that can be authenticated across chains. It can be seen that chains of the same type are considered to have the same security level, and private chains and consortium chains are considered to have the same security level.

[0072]

[0073] Table 1. Data access permissions that can be assigned to the target node. In one embodiment, when the first blockchain is a public blockchain and the second blockchain is a consortium blockchain, the security level of the first blockchain is lower than that of the second blockchain, and the lowest level of permissions are assigned, usually limited to read-only access to non-sensitive data, to avoid the possibility that users of the low-security blockchain may not have strict identity management and that directly granting high permissions would threaten the security of the second blockchain.

[0074] In one embodiment, in response to the first blockchain not establishing a mutual trust relationship with the second blockchain, the chain type identifier of the second blockchain is obtained; based on the chain type identifier of the second blockchain and the chain type identifier of the first blockchain, the data security level information between the first blockchain and the second blockchain is determined; according to the data security level information, target data permissions are assigned to the target node in the second blockchain, which can automatically adopt a conservative strategy and prioritize the protection of data in the high-security-level blockchain when the mutual trust relationship with the first blockchain cannot be confirmed.

[0075] In one embodiment, based on data security level information, target data permissions are assigned to target nodes in the second blockchain, including: In response to the information on the level of data security, if the data security level of the first blockchain is lower than that of the second blockchain, the first data permission is determined to be the target data permission to be assigned to the target node in the second blockchain. In response to the information on the level of data security, if the data security level of the first blockchain is not lower than that of the second blockchain, the second data permission is determined as the allocation of target data permissions to the target node in the second blockchain.

[0076] In one embodiment, the lower data security level of the first blockchain compared to the second blockchain can be a scenario where the first blockchain is a public blockchain and the second blockchain is a consortium blockchain, or a scenario where the first blockchain is a public blockchain and the second blockchain is a private blockchain. In this case, the second blockchain faces a higher security risk.

[0077] In one embodiment, the data security level of the first blockchain being no lower than that of the second blockchain can be in the scenario where the first blockchain and the second blockchain are of the same chain type, such as the scenario where both the first blockchain and the second blockchain are public chains, both are private chains, or both are consortium chains; or it can be in the scenario where the first blockchain and the second blockchain are of different chain types, such as the scenario where the first blockchain is a private chain and the second blockchain is a consortium chain or a public chain, or the scenario where the first blockchain is a consortium chain and the second blockchain is a private chain or a public chain. In this case, the security risks faced by the second blockchain are controllable.

[0078] In one embodiment, the first data permission refers to a restricted, low-level access permission, such as only non-sensitive data, which may be block headers, network status, public market data, etc. The second data permission refers to a more lenient, standard-level access permission, such as public and some sensitive data.

[0079] In one embodiment, even if the blockchains have not previously established a mutual trust relationship, basic and secure interactions can still be performed between blockchains of different security levels. When a user of a low-security blockchain accesses a high-security blockchain, their permissions are automatically restricted to prevent the user of the low-security blockchain from posing a threat to the high-security blockchain, effectively curbing potential attacks and abuse.

[0080] In one embodiment, the identity authentication request also includes a target timestamp and consensus result of the target node in the first blockchain, the target timestamp and consensus result being used to determine the trustworthiness of the target node's identity.

[0081] In one embodiment, the target timestamp is used to indicate the original registration timestamp of the target node.

[0082] In one embodiment, the consensus result refers to the consensus result of each transaction that has occurred in the first blockchain.

[0083] In one embodiment, after receiving an identity authentication request from a target node in the first blockchain, and obtaining the target node's account login information in the first blockchain, the target server's first verification result of the target node, and the target node's digital signature information, the cross-chain identity authentication method further includes: In response to the failure to verify the digital signature information, a first notification message is sent to the target node. The first notification message is used to indicate that the identity authentication request failed.

[0084] In one embodiment, the first notification message may be in the form of an email or a text message; this application does not limit the form of the notification.

[0085] In one embodiment, after successfully verifying the digital signature information and obtaining the second verification result of the target node, the cross-chain identity authentication method further includes: In response to the difference between the second verification result and the first verification result, a second notification message is sent to the target node. The second notification message is used to indicate that the identity authentication request failed.

[0086] In one embodiment, the second notification message may be in the same form as the first notification message, or it may be in a different form.

[0087] In one embodiment, in response to writing the target node's account login information and target data permissions in the first blockchain into a block of the second blockchain, and sending an authentication success message to the first blockchain, the cross-chain authentication method further includes: In response to the target data in the block of the second blockchain, which includes the identity authentication request, the target data is sent to the target node.

[0088] In one embodiment, the target data refers to data in the second blockchain of the identity authentication request.

[0089] In one embodiment, applied to the aforementioned Figure 1 In the scenario shown, the cross-chain identity authentication method in this application includes the following steps: Step 1: After successfully logging into the first blockchain, node 1 (first node) of the first blockchain obtains the result R of the identity verification platform Q in the first blockchain verifying the identity information of node 1, and obtains the type identifier of the first blockchain and the identifier 01 of the first blockchain provided by the identity verification platform Q. The result R indicates that the identity verification platform Q in the first blockchain recognizes node 1 as a legitimate node in the first blockchain. The identity verification platform Q can specifically be a business server within the first blockchain. The type identifier of the first blockchain indicates whether the blockchain network type is a public chain, a private chain, or a consortium chain.

[0090] Step 2: After receiving the result R, Node 1 calls the TEE software installed on Node 1 to execute: using the private key generated in Node 1, sign the result R, the type identifier of the first blockchain, and the identifier 01 of the first blockchain to obtain the digital signature R'; Specifically, the TEE software can use the private key of node 1, which is generated in advance for node 1, to sign R, the type identifier of the first blockchain, and the identifier 01 of the first blockchain to obtain a digital signature R'.

[0091] During cross-chain authentication, the identity verification platform X of the target blockchain can verify the signature of R' based on the public key of node 1. If the signature verification is successful, the identity verification platform X can obtain the result R, the type identifier of the first blockchain, and the identifier 01 of the first blockchain.

[0092] If the result R represents that the identity verification platform Q in the first blockchain has successfully verified the identity information of node 1, then the identity verification platform X recognizes that node 1 is a legitimate node in the first blockchain and has the basic conditions to log in to the target blockchain.

[0093] Step 3: Node 1 sends the registered account name A and password in the first blockchain, the result R, and the digital signature R' together in the cross-chain identity verification request to the identity verification platform X in the second blockchain; The password mentioned above can also be replaced with other user authentication information, such as facial features.

[0094] Step 4: Identity verification platform X receives the cross-chain identity verification request sent by node 1, and obtains node 1's registered account name A and password, result R and digital signature R' in the first blockchain from the request; Step 5: The identity verification platform X queries the public key of node 1 stored corresponding to the registered account name A of node 1, and uses the queried public key to verify the signature of R'; if the signature verification is successful, it means that the digitally signed information has not been tampered with, and then proceeds to step 6. In step 5, if the identity verification platform X cannot find the public key or the signature verification fails, it sends a cross-chain authentication failure notification message to node 1, thereby terminating the authentication process.

[0095] It should be noted that the public key of node 1 stored corresponding to A (this public key is a pair with the private key mentioned in step 2) is generated in advance by node 1 and synchronized to the identity verification platform X.

[0096] In this proposal, identity verification platforms in different blockchains can synchronize the public keys generated by their respective nodes, enabling cross-chain authentication of nodes based on these public keys. Therefore, after receiving the public key from node 1, identity verification platform X can synchronize it with identity verification platform X.

[0097] Step 6: After the identity verification platform X verifies the digital signature R', the R obtained from the verification is consistent with the R in the cross-chain identity mutual recognition request; if they are consistent (considering extreme or abnormal scenarios, such as the signature verification was performed incorrectly but the hash value was not actually compared), then proceed to step 7; If the comparison results are inconsistent in this step, the identity verification platform X sends a cross-chain authentication failure notification message to node 1, thereby terminating the authentication process.

[0098] Step 7: The identity verification platform X determines whether the first blockchain is a blockchain that has established a node trust relationship with the second blockchain based on the identifier 01 of the first blockchain; if so, proceed to step 8. If the result of the judgment is negative in this step, then proceed to step 11.

[0099] For example, identity verification platform X can use the identifier 01 of the first blockchain to query a pre-saved list of identifiers of blockchains that have established a mutual trust relationship with the second blockchain, and determine whether the identifier 01 of the first blockchain matches an identifier in the list; if it matches, it is determined that the first blockchain is a blockchain that has established a mutual trust relationship with the second blockchain.

[0100] Step 8: Further, the identity verification platform X determines the mutual trust level between the first blockchain and the second blockchain; and according to the mutual trust level, assigns data access permissions matching the mutual trust level to the registered account name A of node 1, and then executes step 9; For example, the first blockchain and the second blockchain can pre-agree on a mutual trust protocol that they must both follow. The content of this mutual trust protocol may include, for example: The level of mutual trust between the first and second blockchains is: primary. That is, the second blockchain allows nodes in the first blockchain (referring to nodes whose identities have been proven legitimate) to access specific data in the second blockchain—such as non-sensitive data; at the same time, the first blockchain allows nodes in the second blockchain (referring to nodes whose identities have been proven legitimate) to access specific data in the first blockchain—such as non-sensitive data.

[0101] Alternatively, the level of mutual trust between the first and second blockchains can be classified as medium. That is, the second blockchain allows nodes in the first blockchain (referring to nodes whose identities have been proven legitimate) to access specific data within the second blockchain—such as sensitive and non-sensitive data, excluding confidential data; simultaneously, the first blockchain allows nodes in the second blockchain (referring to nodes whose identities have been proven legitimate) to access specific data within the first blockchain—such as sensitive and non-sensitive data, excluding confidential data.

[0102] Alternatively, the level of mutual trust between the first and second blockchains can be classified as "high." This means that the second blockchain allows nodes in the first blockchain (those whose identities have been proven legitimate) to access all data in the second blockchain; simultaneously, the first blockchain allows nodes in the second blockchain (those whose identities have been proven legitimate) to access all data in the first blockchain.

[0103] The level of mutual trust between the first blockchain and the second blockchain can also be recorded in the above list. The identity verification platform X can query the level of mutual trust between the first blockchain and the second blockchain from the list based on the identifier 01 of the first blockchain.

[0104] When the mutual trust level found is primary, the identity verification platform X assigns access permissions for non-sensitive data to the registered account name A of node 1. When the mutual trust level is found to be medium, the identity verification platform X assigns access permissions for sensitive data to the registered account name A of node 1. When the mutual trust level is found to be at the initial level, the identity verification platform X assigns access permissions for confidential data to the registered account name A of node 1.

[0105] Step 9: The identity verification platform X treats node 1 as a successfully registered user in the second blockchain and writes the registered account name A, password, and data access permissions assigned to that account name in the first blockchain into the block of the second blockchain; Step 10: After the identity verification platform X successfully writes the registered account name A, password and data access permissions into the block, it sends a notification message to node 1 that the cross-chain authentication has been passed, and sets the current login status of the account name A corresponding to node 1 in the second blockchain to "logged in", thereby completing the cross-chain authentication of node 1. After executing step 10, if node 1 wants to obtain the target data in the second blockchain, it can directly send a data acquisition request containing the target data identifier and the registered account name A to the identity verification platform X in the second blockchain. If the identity verification platform X confirms that account name A is currently logged in on the second blockchain, it will obtain data access permissions based on account name A. If the data access permission indicates that account name A can obtain the target data, then the identity verification platform X sends the data acquisition request to the block where the target data is currently located, and after obtaining the target data returned by the block, sends the target data to node 1.

[0106] Step 11: Identity verification platform X obtains the type identifier of the second blockchain and determines the relative relationship between the data security levels of the first blockchain and the second blockchain based on the type identifier of the second blockchain and the type identifier of the first blockchain; Step 12: The identity verification platform X determines the data access permissions for node 1 when accessing data in the second blockchain based on the relative relationship between the data security levels of the first blockchain and the second blockchain, and then assigns the determined data access permissions to node 1. After allocating the determined data access permissions to node 1, proceed to step 9 to complete the cross-chain authentication of node 1.

[0107] In one embodiment, if node 1 expects the identity verification platform X in the second blockchain to grant it relatively high data access permissions, then the following steps can be performed: Step a: In step 1, after obtaining the type identifier of the first blockchain provided by the identity verification platform Q, node 1 determines whether the type of the first blockchain is a public blockchain based on the type identifier. If it is a public blockchain, node 1 is expected to be granted lower data access permissions, thereby executing step b; if it is not a public blockchain, it can continue to execute step 2. Step b: Node 1 requests the identity verification platform Q to obtain the original registration timestamp of Node 1's registration to the first blockchain and the consensus results of each transaction that has occurred in the first blockchain from each node of the consensus group of the first blockchain, as strong proof that Node 1's identity is credible and reliable. A consensus group is a set of secure and trusted nodes selected from the first blockchain. These nodes are primarily responsible for block production and transaction verification. For example, DPoS can be used to select nodes to form a consensus group.

[0108] Step c: In step 3, in the cross-chain identity recognition request, in addition to adding the registered account name A and password, result R and digital signature R' of node 1 in the first blockchain, node 1 also adds the above evidence.

[0109] It should be noted that, generally, Node 1 is only allowed to send evidence to other blockchains if the first blockchain it registers with is a public blockchain. If the blockchain is a private blockchain or a consortium blockchain, relevant rules can be formulated as appropriate to limit the security risks associated with cross-chain data sharing.

[0110] Step d: In step 12, when the identity verification platform X determines the relative relationship between the data security levels of the first blockchain and the second blockchain as "the data security level of the first blockchain < the data security level of the second blockchain" based on the type identifier of the second blockchain and the type identifier of the first blockchain, it can further determine whether a higher data access permission can be assigned to node 1 based on the above evidence. If the evidence determines that Node 1's identity is trustworthy and reliable, Node 1 can be granted the same data access permissions as regular nodes in the second blockchain, and then step 9 can be executed.

[0111] For example, if the original registration timestamp in the evidence is far removed from the current time, and there are no anomalies in the consensus result of the transaction, then it can be determined that the identity of Node 1 is trustworthy and reliable.

[0112] In summary, the solution provided in this public disclosure is as follows: First, upon receiving an identity authentication request from the target node in the first blockchain, the system obtains the target node's account login information in the first blockchain, the target server's first verification result for the target node, and the target node's digital signature information. If the digital signature verification is successful, it confirms the target node's authenticity and that the data, including the first verification result, has not been tampered with, thus obtaining the target node's second verification result. If the second verification result is identical to the first verification result, it ensures that the identity verification used for permission allocation is original and authentic, and the system allocates target data permissions to the target node in the second blockchain. By writing the target node's account login information and target data permissions from the first blockchain into a block of the second blockchain and sending an identity authentication pass message to the first blockchain, the system prevents the permission configuration from being tampered with afterward, thereby reducing security risks arising from data access from the target node in the first blockchain and lowering the risk of data leakage and unauthorized access during cross-chain data access.

[0113] Secondly, by responding to the first blockchain not establishing a mutual trust relationship with the second blockchain, the chain type identifier of the second blockchain is obtained; based on the chain type identifiers of the second blockchain and the first blockchain, the data security level information between the first blockchain and the second blockchain is determined; according to the data security level information, target data permissions are assigned to target nodes in the second blockchain, which can automatically adopt a conservative strategy and prioritize the protection of data in the high-security-level blockchain when the mutual trust relationship with the first blockchain cannot be confirmed.

[0114] Furthermore, even without prior mutual trust, blockchains of different security levels can still engage in basic, secure interactions. When a user from a low-security blockchain accesses a high-security blockchain, their permissions are automatically restricted, preventing the low-security blockchain user from posing a threat to the high-security blockchain and effectively curbing potential attacks and abuse.

[0115] To implement the cross-chain identity authentication method provided in this disclosure, this disclosure also provides a cross-chain identity authentication device, such as... Figure 5 As shown. Figure 5 This is a schematic diagram of the cross-chain identity authentication device provided in this embodiment of the disclosure. The cross-chain identity authentication device 500 includes: The first acquisition unit 501 is used to receive the identity authentication request of the target node in the first blockchain, and to acquire the account login information of the target node in the first blockchain, the first verification result of the target server on the target node, and the digital signature information of the target node. The second acquisition unit 502 is used to acquire the second verification result of the target node in response to the successful verification of the digital signature information. The allocation unit 503 is used to allocate target data permissions to the target node in the second blockchain in response to the second verification result being the same as the first verification result. The authentication unit 504 is used to send an identity authentication pass message to the first blockchain in response to writing the target node's account login information and target data permissions in the first blockchain into a block of the second blockchain.

[0116] In one embodiment, the cross-chain identity authentication device 500 further includes a receiving unit, which is used for: Receive the public key generated by the target node. The public key and the private key generated by the target node form an asymmetric encryption key pair. The private key is used to sign the first verification result of the target node, the chain type identifier and the chain identifier of the first blockchain to generate digital signature information. The public key is used to verify the digital signature information.

[0117] In one embodiment, the allocation unit 503 is specifically used for: If the second verification result is the same as the first verification result, determine whether the first blockchain is a blockchain that has established a node mutual trust relationship with the second blockchain; In response to the first blockchain establishing a node trust relationship with the second blockchain, information on the level of trust between the first blockchain and the second blockchain is obtained. Based on trust level information, target data permissions are assigned to target nodes in the second blockchain.

[0118] In one embodiment, the allocation unit 503 is specifically used for: Determine the trust level of the trust information; Determine the target data permissions corresponding to the trust level from the mapping relationship between trust level and data permissions; Assign target data permissions to the target node in the second blockchain.

[0119] In one embodiment, the allocation unit 503 is specifically used for: In response to the first blockchain not establishing a node trust relationship with the second blockchain, obtain the chain type identifier of the second blockchain; Based on the chain type identifier of the second blockchain and the chain type identifier of the first blockchain, the data security level between the first blockchain and the second blockchain is determined. Based on the data security level, target data permissions are assigned to target nodes in the second blockchain.

[0120] In one embodiment, the allocation unit 503 is specifically used for: In response to the information on the level of data security, if the data security level of the first blockchain is lower than that of the second blockchain, the first data permission is determined to be the target data permission to be assigned to the target node in the second blockchain. In response to the information on the level of data security, if the data security level of the first blockchain is not lower than that of the second blockchain, the second data permission is determined as the allocation of target data permissions to the target node in the second blockchain.

[0121] In one embodiment, the identity authentication request also includes a target timestamp and consensus result of the target node in the first blockchain, the target timestamp and consensus result being used to determine the trustworthiness of the target node's identity.

[0122] In one embodiment, the cross-chain identity authentication device 500 further includes a sending unit, which is used for: In response to the failure to verify the digital signature information, a first notification message is sent to the target node. The first notification message is used to indicate that the identity authentication request failed.

[0123] In one embodiment, the transmitting unit is further configured to: In response to the difference between the second verification result and the first verification result, a second notification message is sent to the target node. The second notification message is used to indicate that the identity authentication request failed.

[0124] In one embodiment, the transmitting unit is further configured to: In response to the target data in the block of the second blockchain, which includes the identity authentication request, the target data is sent to the target node.

[0125] In one embodiment, the chain type identifier indicates the chain type, including public chain, private chain, and consortium chain.

[0126] It should be noted that the cross-chain identity authentication device provided in the above embodiments is only illustrated by the division of the above program modules when performing cross-chain identity authentication. In practical applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the cross-chain identity authentication device can be divided into different program modules to complete all or part of the processing described above. In addition, the cross-chain identity authentication device provided in the above embodiments and the cross-chain identity authentication method embodiments provided in this disclosure belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0127] Figure 6 This is a schematic diagram of the hardware composition structure of the electronic device provided in the embodiments of this disclosure, such as... Figure 6As shown, the electronic device 600 includes at least one processor 602; and a memory 601 communicatively connected to at least one processor 602; wherein the memory 601 stores instructions executable by at least one processor 602, the instructions being executed by at least one processor 602 to implement the steps of the cross-chain identity authentication method of the present disclosure embodiments.

[0128] Optionally, the electronic device may specifically be a cross-chain identity authentication device in the embodiments of this application, and the electronic device may implement the corresponding processes implemented by the cross-chain identity authentication device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0129] It is understood that the electronic device also includes a communication interface 603. Various components in the electronic device are coupled together via a bus system 604. It is understood that the bus system 604 is used to implement communication between these components. In addition to a data bus, the bus system 604 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 6 The general designated all buses as Bus System 604.

[0130] It is understood that memory 601 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memory 601 described in this embodiment of the invention is intended to include, but is not limited to, these and any other suitable types of memory.

[0131] The methods disclosed in the above embodiments can be applied to or implemented by processor 602. Processor 602 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above methods can be completed by integrated logic circuits in the hardware of processor 602 or by instructions in software form. Processor 602 may be a general-purpose processor, DSP, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 602 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. A general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this invention can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, specifically memory 601. Processor 602 reads information from memory 601 and, in conjunction with its hardware, completes the steps of the aforementioned methods.

[0132] In an exemplary embodiment, the electronic device may be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), FPGAs, general-purpose processors, controllers, MCUs, microprocessors, or other electronic components to perform the aforementioned method.

[0133] This disclosure also provides a non-transitory computer-readable storage medium storing computer instructions, which are used to cause a computer to execute the steps of the cross-chain identity authentication method of this invention.

[0134] Optionally, the computer-readable storage medium can be applied to the cross-chain identity authentication device in the embodiments of this application, and the computer instructions cause the computer to execute the corresponding processes implemented by the cross-chain identity authentication device in the various methods of the embodiments of this application. For the sake of brevity, they will not be described in detail here.

[0135] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the cross-chain identity authentication method provided in this embodiment of the invention.

[0136] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0137] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0138] In addition, in the various embodiments of the present invention, each functional unit can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0139] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0140] Alternatively, if the integrated units of this invention are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0141] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A cross-chain identity authentication method, characterized in that, The methods include: Upon receiving an identity authentication request from a target node in the first blockchain, the system obtains the target node's account login information in the first blockchain, the target server's first verification result of the target node, and the target node's digital signature information. In response to successful verification of the digital signature information, a second verification result of the target node is obtained; In response to the second verification result being the same as the first verification result, target data permissions are assigned to the target node in the second blockchain; In response to writing the target node's account login information in the first blockchain and the target data permissions into a block of the second blockchain, an identity authentication pass message is sent to the first blockchain.

2. The method according to claim 1, characterized in that, Before receiving the identity authentication request from the target node in the first blockchain and obtaining the target node's account login information in the first blockchain, the first verification result of the target server for the target node, and the target node's digital signature information, the method further includes: The system receives a public key generated by a target node. The public key and the private key generated by the target node form an asymmetric encryption key pair. The private key is used to sign the first verification result of the target node, the chain type identifier and the chain identifier of the first blockchain to generate digital signature information. The public key is used to verify the digital signature information.

3. The method according to claim 1, characterized in that, The step of assigning target data permissions to the target node in the second blockchain in response to the second verification result being the same as the first verification result includes: In response to the second verification result being the same as the first verification result, it is determined whether the first blockchain is a blockchain that has established a node mutual trust relationship with the second blockchain; In response to the fact that the first blockchain is a blockchain that has established a node trust relationship with the second blockchain, information on the degree of trust between the first blockchain and the second blockchain is obtained; Based on the trust level information, target data permissions are assigned to the target node in the second blockchain.

4. The method according to claim 3, characterized in that, The process of allocating target data permissions to the target node in the second blockchain based on the trust level information includes: Determine the trust level of the trust information; The target data permissions corresponding to the trust level are determined from the mapping relationship between trust level and data permissions; In the second blockchain, target data permissions are assigned to the target node.

5. The method according to claim 3, characterized in that, After determining whether the first blockchain is a blockchain that has established a node trust relationship with the second blockchain in response to the second verification result being the same as the first verification result, the method further includes: In response to the first blockchain not being a blockchain that has established a node trust relationship with the second blockchain, the chain type identifier of the second blockchain is obtained; Based on the chain type identifier of the second blockchain and the chain type identifier of the first blockchain, the data security level information between the first blockchain and the second blockchain is determined. Based on the data security level information, target data permissions are assigned to the target node in the second blockchain.

6. The method according to claim 5, characterized in that, The step of allocating target data permissions to the target node in the second blockchain based on the data security level information includes: In response to the data security level information that the data security level of the first blockchain is lower than the data security level of the second blockchain, the first data permission is determined to be the allocation of target data permission to the target node in the second blockchain; In response to the data security level information that the data security level of the first blockchain is not lower than the data security level of the second blockchain, the second data permission is determined to be the allocation of target data permissions to the target node in the second blockchain.

7. The method according to claim 1, characterized in that, The identity authentication request also includes the target timestamp and consensus result of the target node in the first blockchain, and the target timestamp and consensus result are used to determine the trustworthiness of the target node's identity.

8. The method according to claim 1, characterized in that, After receiving the identity authentication request of the target node in the first blockchain, and obtaining the target node's account login information in the first blockchain, the first verification result of the target server for the target node, and the target node's digital signature information, the method further includes: In response to the failure to verify the digital signature information, a first notification message is sent to the target node, the first notification message indicating that the identity authentication request failed.

9. The method according to claim 1, characterized in that, After successfully verifying the digital signature information and obtaining the second verification result of the target node, the method further includes: In response to the second verification result being different from the first verification result, a second notification message is sent to the target node, the second notification message being used to indicate that the identity authentication request failed.

10. The method according to claim 1, characterized in that, After responding to writing the target node's account login information in the first blockchain and the target data permissions into a block of the second blockchain, and sending an authentication pass message to the first blockchain, the method further includes: In response to the target data including the identity authentication request in a block of the second blockchain, the target data is sent to the target node.

11. The method according to claim 2, characterized in that, The chain type identifier indicates the chain type, including public chain, private chain, and consortium chain.

12. A cross-chain identity authentication device, characterized in that, The device includes: The first acquisition unit is configured to receive an identity authentication request from a target node in the first blockchain, and acquire the target node’s account login information in the first blockchain, the first verification result of the target server for the target node, and the target node’s digital signature information. The second acquisition unit is used to acquire the second verification result of the target node in response to the successful verification of the digital signature information. An allocation unit is configured to allocate target data permissions to the target node in the second blockchain in response to the second verification result being the same as the first verification result. The authentication unit is used to send an authentication pass message to the first blockchain in response to writing the target node's account login information in the first blockchain and the target data permissions into a block of the second blockchain.

13. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 11.

14. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1 to 11.

15. A computer program product comprising a computer program that, when executed by a processor, implements the method of any one of claims 1 to 11.

Images