A lightweight and robust cross-domain identity authentication method based on master-slave blockchain

Abstract

The present invention discloses a lightweight and robust cross-domain identity authentication method based on a master-slave blockchain, which splits the entire blockchain into a master blockchain and multiple slave blockchains, and the cross-domain communication node is responsible for the information interaction between the master chain and the slave chain, and the nodes with different functions in the trust domain of different systems are functionally matched in the master-slave chain. Due to the decentralized nature of the blockchain itself, the centralized risk can be reduced, and then a local consensus different from the previous whole chain consensus is used. Only consensus is needed between the authentication-related slave chain and the master chain to complete data consensus sharing. The slave chain stores specific certificates, and the master chain stores the hash value of the certificate, which effectively reduces the number of consensus participating nodes and improves the authentication efficiency. At the same time, the authentication process requires two asymmetric encryptions, three digital signatures and verifications based on asymmetric encryption, and one hash operation, so the computational complexity is further reduced.

Description

Technical Field

[0001] The present invention relates to the field of cross-domain authentication technology, and in particular to a lightweight and robust cross-domain identity authentication method based on a master-slave blockchain. Background Art

[0002] With the rapid development of 5G, devices in two regions with different authentication mechanisms often need to exchange information. When users interact with cross-domain information, the limitations brought by identity authentication and access control mechanisms are inevitable. In particular, when authentication is performed in heterogeneous regions with different authentication mechanisms, various complex mechanisms need to be introduced, such as introducing third-party certificates to construct trust links. However, these cross-domain authentication mechanisms have poor efficiency and robustness, and are difficult to meet the low latency and high reliability requirements of the Internet of Things. Therefore, it is of great significance to study lightweight and robust cross-domain authentication mechanisms.

[0003] The mainstream security technology solution in the field of identity authentication is the Public Key Infrastructure (PKI), in which user identities are managed by trusted institutions. There are three mainstream PKI-based technologies: The first is a certificate-based approach, in which users use certificates to verify the legitimacy of their identities and achieve data confidentiality and security. However, there are problems such as heavy certificate management burden, high computational complexity, high communication overhead, and single point failure. The second is the identity-based public key cryptography system (IBC), which optimizes the problem of high certificate management overhead and has the advantage of easy maintenance, but still has problems such as low efficiency, key escrow, and single point failure. The third is the certificate-less public key cryptography (CL-PKC) technology, which solves the problem of difficult certificate management and divides the user's key into two parts, one of which is generated by the trusted key generation center (KGC) and the other by the user. KGC cannot know all the private keys of the user, which improves the security of the key.

[0004] Most of the existing blockchain-based cross-domain identity management technologies adopt a single alliance chain model, such as reference 1 ([1] Hammi MT, Hammi B, Bellot P, et al. Bubbles of Trust: A decentralized blockchain-based authentication system for IoT [J]. Computers & Security, 2018, 78: 126-142.) and reference 2 ([2] Esposito C, Ficco M, Gupta BB. Blockchain-based authentication and authorization for smart city applications [J]. Information Processing & Management, 2021, 58 (2): 102468.). This model is more advantageous when the scale of the Internet of Things is small, but in large-scale Internet of Things scenarios, the maintenance cost of the alliance chain increases sharply, and the time required to complete an identity authentication increases sharply. A few cross-domain identity authentication technologies that use master-slave blockchains, such as Reference 3 ([3] Guo S, Wang F, Zhang N, et al. Master-slave chain based trusted cross-domain authentication mechanism in IoT [J]. Journal of Network and Computer Applications, 2020, 172: 102812) and Reference 4 ([4] Zhang Z, Zhong C, Guo S, et al. A master-slave chain architecture model for cross-domain trusted and authentication of power services [C] / / Proceedings of the 2019 7th International Conference on Information Technology: IoT and Smart City. 2019: 483-487), although they relieve the pressure on the main blockchain, lack a mechanism for security protection of cross-domain communication nodes. When hackers launch network attacks such as DDos against vulnerabilities in smart contracts, it is difficult for current technologies to successfully complete identity authentication in such a network environment. It is necessary to add corresponding mechanisms to increase its robustness. Summary of the invention

[0005] In view of the shortcomings of the prior art, the present invention proposes a lightweight and robust cross-domain authentication scheme based on Master-Slave Blockchain (LRCA-MSB), which reduces time complexity and completes authentication in a shorter time. It is applicable to scenarios where the computing resources of IoT devices are relatively scarce in IoT environments. At the same time, a reputation-based cross-domain communication node selection algorithm is proposed. The algorithm uses a trust evaluation method to select appropriate nodes for cross-domain communication and master blockchain maintenance, making the system more robust.

[0006] In order to achieve the above object, the present invention provides the following technical solutions:

[0007] First, a lightweight and robust cross-domain identity authentication method based on a master-slave blockchain, wherein:

[0008] Split the entire blockchain into a master blockchain and multiple slave blockchains;

[0009] Allow certificate authorities to participate in maintaining the blockchain as ordinary nodes;

[0010] The identity authentication server is divided into cross-domain communication nodes and ordinary nodes. Among them, ordinary nodes participate in maintaining the slave blockchain; cross-domain communication nodes are elected from ordinary nodes using a trust evaluation method, and maintain both the slave blockchain and the master blockchain. They are responsible for the information interaction between the master and slave blockchains. Through a hierarchical consensus mechanism, nodes with different functions in different trust domains of different systems are functionally matched in the master and slave blockchains, becoming a cross-domain bridge;

[0011] Before identity authentication, the user first registers the identity through the slave blockchain of this trust domain, and then authenticates the identity in conjunction with the smart contract of the master-slave blockchain. The generated digital certificate is stored in the slave blockchain, and the hash value of the certificate is stored in the master blockchain.

[0012] Furthermore, the node with the highest reputation value is elected as the cross-domain communication node through the trust evaluation method.

[0013] Furthermore, the election method of the cross-domain communication node is:

[0014] (1) Communicate with all identity authentication server nodes through the certificate authority node, and record the number of successful interactions and the number of failed interactions within a period T;

[0015] (2) Calculate the direct trust value of the identity authentication server node i in period T according to formula (1):

[0016]

[0017] Where i represents the AS node, j represents the certificate authority node, Indicates the direct trust value of the identity authentication server node, represents the number of successful interactions between nodes i and j in period T, represents the number of failed interactions between nodes i and j, q is the abnormal factor, which represents the impact of network attack behavior on the result. The formula for defining q is:

[0018]

[0019] in Indicates the number of interaction failures caused by network attacks within period T, Indicates the total number of interaction failures;

[0020] (3) The comprehensive reputation value of the identity authentication server node is predicted using the reputation value at the past time, expressed as:

[0021]

[0022] in is the reputation value of the identity authentication server node after T period, μ is the weight parameter, which is set to 0.7, and Δt is the time difference between time T and time T-1;

[0023] (4) After obtaining the reputation values ​​of all nodes, the node with the highest reputation value is selected as the cross-domain communication node. The reputation value is continuously updated as the system runs. When the reputation value of the cross-domain node is lower than the preset parameter θ, the cross-domain communication node is reselected.

[0024] Furthermore, the hierarchical consensus mechanism is as follows: the slave blockchain in the trust domain uses the cross-domain communication node as the master node to reach a consensus in the trust domain, and then uses the cross-domain communication node as the consensus initiating node to reach a consensus in the master blockchain.

[0025] Furthermore, the process of identity registration is:

[0026] (1) The user initiates a registration request and sends his or her identity code, user identity information, and user public key to the CA;

[0027] (2) After receiving the user's request, the certificate issuing authority will determine whether the user's identity information conflicts with existing information. If not, it will generate a user identity summary based on the user's identity code and user identity information and send the user's identity summary to the user;

[0028] (3) The user signs his or her identity summary and sends it together with the identity code to the CA;

[0029] (4) After receiving the user's request, the certificate authority first verifies the digital signature. If it is legitimate, it generates a digital certificate for the user, stores the user's identity code, public key, and digital certificate on the blockchain in this trust domain, and then synchronizes them to the main blockchain through the cross-domain communication node;

[0030] (5) If successfully stored in the blockchain, the digital certificate will be sent to the user, indicating that the identity registration is successful.

[0031] Furthermore, the identity authentication process is:

[0032] (1) User U A Your own identity code UID A 、Public key UserPK A After signing with the timestamp T, it is the same as the user identity code UID A Sent together to the identity authentication server AS in domain B B ;

[0033] (2) Identity authentication server AS in domain B B After receiving the digital signature of the user, the AS B Get user U A Identity code UID A 、Public key UserPK A and timestamp T, and (UID A , UserPK A , T) as user U A Identity information UII A , UII A Sent to the authentication server AS in domain A A Verify U A The legitimacy of the identity;

[0034] (3)If U A The identity of the B domain authentication server AS B Generate a random number r and calculate T r =T+r and Hash(UID A , T t ), after signing, send the certificate authority CA of domain B B Apply for U's cross-domain certificate;

[0035] (4) Receive the authentication data from the AS server in domain B B After the request is made, the signature is verified first. If it is legal, according to UII A Generate a cross-domain certificate and digital signature Stored in the slave blockchain of this trust domain, the certificate hash value is synchronized to the master blockchain, and then sent to the identity authentication server AS in domain B B ;

[0036] (5) Identity authentication server AS in domain B B Will and Send to U A , informing that the authentication is successful.

[0037] In a second aspect, the present invention further provides a lightweight and robust cross-domain identity authentication device based on a master-slave blockchain, comprising an Internet of Things device, an identity authentication server and a certificate authority, to implement any of the above methods, wherein:

[0038] The entire blockchain consists of a master blockchain and multiple slave blockchains;

[0039] The certificate authority participates in maintaining the blockchain as a normal node;

[0040] The identity authentication server is divided into cross-domain communication nodes and ordinary nodes. Ordinary nodes participate in maintaining the slave blockchain. Cross-domain communication nodes are elected from ordinary nodes and maintain both the slave blockchain and the master blockchain, becoming a cross-domain bridge.

[0041] Before identity authentication, the user first registers the identity through the slave blockchain of this trust domain, and then authenticates the identity in conjunction with the smart contract of the master-slave blockchain. The generated digital certificate is stored in the slave blockchain, and the hash value of the certificate is stored in the master blockchain.

[0042] In a third aspect, the present invention further provides an electronic device comprising a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus; the memory is used to store computer programs; and the processor is used to implement the steps of any of the methods described above when executing the program stored in the memory.

[0043] In a fourth aspect, the present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of any of the methods described above are implemented.

[0044] In a fifth aspect, the present invention further provides a computer program product comprising instructions, characterized in that when the computer program product is run on a computer, the computer is enabled to execute the steps of any of the methods described above.

[0045] Compared with the prior art, the present invention has the following beneficial effects:

[0046] The lightweight and robust cross-domain identity authentication method based on the master-slave blockchain proposed in the present invention splits the entire blockchain into a main chain and multiple slave chains, and the cross-domain communication node is responsible for the information interaction between the main chain and the slave chain. The nodes with different functions in the trust domains of different systems are functionally matched in the master-slave chain, which can reduce the centralized risk, and then use the local consensus that is different from the previous whole chain consensus. It is only necessary to reach a consensus in the authentication-related slave chain and the main chain to complete the data consensus sharing. The slave chain stores specific certificates, and the main chain stores the hash value of the certificate, which effectively reduces the number of consensus participating nodes and improves the authentication efficiency. At the same time, the master-slave chain structure is more scalable, and the addition of any new trust domain has no effect on other slave chain trust domains. In addition, a cross-domain communication node election algorithm is adopted, and the time complexity is low. The authentication process requires two asymmetric encryptions, three digital signatures and verifications based on asymmetric encryption, and one hash operation, so the computational complexity is low. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0048] Figure 1 A flowchart of a lightweight and robust cross-domain identity authentication method based on a master-slave blockchain provided in an embodiment of the present invention.

[0049] Figure 2 A timing diagram of cross-domain identity authentication provided by an embodiment of the present invention.

[0050] Figure 3 The impact of DDOS attacks on the authentication success rate provided by the embodiment of the present invention. DETAILED DESCRIPTION

[0051] In order to better understand the technical solution, the method of the present invention is described in detail below with reference to the accompanying drawings.

[0052] like Figure 1 As shown, the lightweight and robust cross-domain identity authentication device based on the master-slave blockchain proposed by the present invention mainly involves Internet of Things devices, identity authentication servers (Authentication Server, AS) and certificate authorities (Certificate Authority, CA). CA participates in the maintenance of blockchain as a common node, and the authentication server is divided into cross-domain communication nodes and common nodes, among which the common nodes participate in the maintenance of the slave chain; the cross-domain communication nodes are elected from the common nodes, which maintain both the slave chain and the master chain, and become a cross-domain bridge.

[0053] Based on the above device, the lightweight and robust cross-domain identity authentication method based on the master-slave blockchain proposed by the present invention splits the entire blockchain into a master blockchain and multiple slave blockchains; the cross-domain communication node is responsible for the information interaction between the master chain and the slave chain, and the nodes with different functions in the trust domains of different systems are functionally matched in the master-slave chain. Due to the decentralized nature of the blockchain itself, the centralized risk can be reduced, and then the local consensus different from the previous whole chain consensus is used. Only the consensus of the authentication-related slave chain and the main chain can be reached to complete the data consensus sharing. The slave chain stores the specific certificate, and the main chain stores the hash value of the certificate, which effectively reduces the number of consensus participating nodes and improves the authentication efficiency. At the same time, the master-slave chain structure is more scalable. The addition of any new trust domain has no effect on other slave chain trust domains. It is only necessary to match the nodes in the trust domain with the slave chain node functions, and add the main chain node of this trust domain to the main chain. The newly added trust domain will pass the main chain consensus, and the original trust certificate of the main chain will be consensused to the local of the new main chain node, so that all the data and trust certificates of the previous consensus are obtained.

[0054] The main core points of the present invention are the hierarchical consensus mechanism based on the cross-domain communication node trusted selection algorithm and the identity authentication technology based on the master-slave blockchain. The consensus mechanism maintains the operation order, fairness and robustness of the blockchain, and the blockchain provides a lightweight and secure user identity certificate management method.

[0055] 1. Hierarchical consensus mechanism based on cross-domain communication node trusted selection algorithm

[0056] The consensus mechanism of the present invention is mainly improved based on the Practical Byzantine Fault Tolerance (PBFT) algorithm. The slave chain in the trust domain uses the cross-domain communication node as the master node to reach a consensus in this trust domain, and then uses the cross-domain communication node as the consensus initiation node to reach a consensus in the main chain. The specific consensus process is similar to the PBFT algorithm, and the difference lies in the selection and replacement of the master node. The present invention mainly selects the node with the highest reputation value as the cross-domain communication node based on the trust evaluation method.

[0057] The specific implementation steps of the cross-domain communication node election method are as follows:

[0058] (1) Communicate with all AS nodes through the CA node, and record the number of successful interactions and the number of failed interactions within a period T;

[0059] (2) Calculate the direct trust value of AS node i in period T according to formula (1):

[0060]

[0061] Where i represents the AS node, j represents the CA node, Indicates the direct trust value of the node AS, represents the number of successful interactions between nodes i and j in period T, represents the number of failed interactions between nodes i and j, q is the abnormal factor, which represents the impact of network attack behavior on the result. The formula for defining q is:

[0062]

[0063] in Indicates the number of interaction failures caused by network attacks within period T, Indicates the total number of interaction failures;

[0064] (3) The comprehensive reputation value of the AS node is predicted using the reputation value at the past time, expressed as:

[0065]

[0066] in is the reputation value of the node AS after T period, μ is the weight parameter, which is set to 0.7, and Δt is the time difference between time T and time T-1;

[0067] (4) After obtaining the reputation values ​​of all nodes, the node with the highest reputation value is selected as the cross-domain communication node. The reputation value is continuously updated as the system runs. When the reputation value of the cross-domain node is lower than the preset parameter θ, the cross-domain communication node is reselected. In the present invention, θ is set to 0.8.

[0068] The time complexity of the cross-domain communication node election method of the present invention is O(n), wherein both formula (1) and formula (3) only require O(1) time calculation, so the time complexity of the trust evaluation of n authentication servers in each cycle T is O(n), and the time complexity of selecting the node with the highest reputation value is O(n), so the time complexity of the entire algorithm is O(n). The algorithm only needs to store the comprehensive trust value of the device in the previous cycle and the direct trust value of this cycle, and the space complexity can be obtained. O(n). It can be seen that the method of the present invention is relatively lightweight and can be applied to scenarios where the computing resources of the Internet of Things devices are relatively scarce in the Internet of Things environment. At the same time, a cross-domain communication node selection algorithm based on reputation is proposed. The algorithm adopts a trust evaluation method to select suitable nodes for cross-domain communication and main chain maintenance, making the system more robust.

[0069] 2. Identity authentication technology based on master-slave blockchain

[0070] The identity authentication technology based on the master-slave blockchain mainly includes identity registration and identity authentication. Identity registration means registering your own identity in the blockchain system. Identity authentication can only be performed after registration is completed.

[0071] The present invention requires identity registration through the blockchain of this trust domain before identity authentication, and only registered users can perform identity authentication.

[0072] like Figure 1 As shown, the process of identity registration is:

[0073] (1) The user initiates a registration request and sends his / her User Identity Document (UID), User Identity Information (UII), and User Public Key (UserPK) to the CA.

[0074] (2) After receiving the user's request, the CA will determine whether the user's identity information conflicts with existing information. If not, it will generate a user identity summary (UIS) based on the user's identity code (UID) and user identity information (UII) and send the user's identity summary (UIS) to the user;

[0075] (3) The user signs his / her own identity summary (UIS) and sends the identity summary (UIS) and identity code (UID) to the CA;

[0076] (4) After receiving the user's request, the CA first verifies the digital signature. If it is legitimate, it generates a digital certificate for the user, stores the user's identity code, public key, and digital certificate on the blockchain in this trust domain, and then synchronizes them to the main blockchain through the cross-domain communication node;

[0077] (5) If successfully stored in the blockchain, the digital certificate will be sent to the user, indicating that the identity registration is successful.

[0078] The cross-domain authentication process is as follows Figure 2 As shown in the figure, AS represents the authentication server, U represents the user, and CA represents the certificate authority. In the present invention, the identity authentication is performed in combination with the smart contract of the master-slave blockchain, the generated digital certificate is stored in the slave blockchain, and the master blockchain stores the hash value of the certificate, giving full play to the decentralization and immutability of the blockchain, overcoming the shortcomings of low authentication efficiency and poor robustness of traditional authentication methods. The specific implementation steps of identity authentication are as follows:

[0079] (1) User U A Put your own UID A 、Public key USerPK A After signing with the timestamp T, it is the same as the user identity code UID A Sent together to the authentication server AS in domain B B ;

[0080] (2)ASB After receiving the digital signature of the user, the AS B Get UID A , UserPK A , timestamp T, (UID A , UserPK A , T) as user A's identity information UII A , UII A Send to AS A Verify U A The legitimacy of the identity;

[0081] (3)If U A The identity is legal, AS B Generate a random number r and calculate T r =T+r and Hash(UID A , T t ), signed and sent to CA B Apply for U A Cross-domain certificate;

[0082] (4) Receive AS B After the request is made, the signature is verified first. If it is legal, according to UII A Generate a cross-domain certificate and digital signature In this trust domain, the certificate hash value is synchronized to the main blockchain from the blockchain storage, and then sent to the AS B .

[0083] (5)AS B Will and Send to U A , informing that the authentication is successful.

[0084] The authentication process of the present invention requires two asymmetric encryptions, three digital signatures and verifications based on asymmetric encryption, and one hash operation, so the computational complexity is low, which is lighter than other identity authentication schemes and can complete the authentication in a shorter time.

[0085] In order to simulate the impact of DDOS attacks on the success rate of authentication, the malicious nodes that are attacked by DDOS are set to have a 70% packet loss probability. In the experiment, the proportion of malicious nodes is continuously increased, that is, the intensity of DDOS attacks suffered by the system is increased, and the robustness of different models is demonstrated by comparing the number of successful authentications. The experimental results are shown in Figure 2. Figure 3As shown. Compared with the other two models, our model LRCA-MSB can still maintain a high authentication success rate when there are more malicious nodes. The poor results of the other two methods are because IBE-BCIOT [Shao S, Chen F, Xiao X, et al. IBE-BCIOT: An IBE based cross-chain communication mechanism of blockchain in IoT [J]. World Wide Web, 2021, 24 (5): 1665-1690] does not consider the impact of network attacks on the network environment, and XAuth [Chen J, Zhan Z, He K, et al. XAuth: Efficient privacy-preserving cross-domain authentication [J]. IEEE Transactions on Dependable and Secure Computing, 2021] ensures data security, but does not consider attacks such as DDos. Experiments show that our model has better robustness under poor network conditions.

[0086] In summary, the present invention can more stably complete identity authentication in the scenario of large-scale network attacks. Simulation experiments have proved that when subjected to DDos attacks, the identity authentication failure rate of the present invention is reduced by 30% compared with similar methods.

[0087] Corresponding to the lightweight and robust cross-domain identity authentication method based on master-slave blockchain provided in the above-mentioned embodiment of the present invention, the embodiment of the present invention also provides an electronic device, including a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus.

[0088] Memory, used to store computer programs;

[0089] The processor is used to implement the steps of any lightweight and robust cross-domain identity authentication method based on master-slave blockchain provided by the above-mentioned embodiments of the present invention when executing the program stored in the memory.

[0090] The communication bus mentioned in the above electronic device can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.

[0091] The communication interface is used for communication between the above electronic device and other devices.

[0092] The memory may include a random access memory (RAM) or a non-volatile memory (NVM), such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0093] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0094] A computer program is stored in a computer-readable storage medium, and when the computer program is executed by a processor, the steps of any lightweight and robust cross-domain identity authentication method based on a master-slave blockchain provided in the above-mentioned embodiments of the present invention are implemented.

[0095] In another embodiment provided by the present invention, a computer program product comprising instructions is also provided. When the computer is run on a computer, the computer executes the steps of any lightweight and robust cross-domain identity authentication method based on a master-slave blockchain provided by the above-mentioned embodiments of the present invention.

[0096] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented by software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present invention is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk Solid State Disk (SSD)), etc.

[0097] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0098] Each embodiment in this specification is described in a related manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device embodiment, electronic device embodiment, computer-readable storage medium embodiment, and computer program product embodiment, since they are basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0099] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features thereof may be replaced by equivalents. However, such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A lightweight and robust cross-domain identity authentication method based on master-slave blockchain, characterized in that: Split the entire blockchain into a master blockchain and multiple slave blockchains; Allow certificate authorities to participate in maintaining the blockchain as ordinary nodes; The identity authentication server is divided into cross-domain communication nodes and ordinary nodes. Among them, ordinary nodes participate in maintaining the slave blockchain; cross-domain communication nodes are elected from ordinary nodes using a trust evaluation method, and maintain both the slave blockchain and the master blockchain. They are responsible for the information interaction between the master and slave blockchains. Through a hierarchical consensus mechanism, nodes with different functions in different trust domains of different systems are functionally matched in the master and slave blockchains, becoming a cross-domain bridge; Before identity authentication, the user first registers the identity through the slave blockchain of this trust domain, and then authenticates the identity in conjunction with the smart contract of the master and slave blockchains. The generated digital certificate is stored in the slave blockchain, and the hash value of the certificate is stored in the master blockchain. The specific implementation steps for cross-domain communication nodes to be elected from ordinary nodes using the trust evaluation method are as follows: (1) Communicate with all identity authentication server nodes through the certificate authority node, and record the number of successful interactions and the number of failed interactions within a period T; (2) Calculate the direct trust value of the identity authentication server node i in period T according to formula (1): Where i represents the AS node, j represents the certificate authority node, Indicates the direct trust value of the identity authentication server node, represents the number of successful interactions between nodes i and j in period T, represents the number of failed interactions between nodes i and j, q is the abnormal factor, which represents the impact of network attack behavior on the result. The formula for defining q is: in Indicates the number of interaction failures caused by network attacks within period T, Indicates the total number of interaction failures; (3) The comprehensive reputation value of the identity authentication server node is predicted using the reputation value at the past time, expressed as: in is the reputation value of the identity authentication server node after T period, μ is the weight parameter, which is set to 0.7, and Δt is the time difference between time T and time T-1; (4) After obtaining the reputation values ​​of all nodes, the node with the highest reputation value is selected as the cross-domain communication node. The reputation value is continuously updated as the system runs. When the reputation value of the cross-domain node is lower than the preset parameter θ, the cross-domain communication node is reselected; Identity authentication combined with the smart contract of the master-slave blockchain mainly includes identity registration and identity authentication. The process of identity registration is as follows: (1) The user initiates a registration request and sends his or her identity code, user identity information, and user public key to the CA; (2) After receiving the user's request, the certificate issuing authority will determine whether the user's identity information conflicts with existing information. If not, it will generate a user identity summary based on the user's identity code and user identity information and send the user's identity summary to the user; (3) The user signs his or her identity summary and sends it together with the identity code to the CA; (4) After receiving the user's request, the certificate authority first verifies the digital signature. If it is legitimate, it generates a digital certificate for the user, stores the user's identity code, public key, and digital certificate on the blockchain in this trust domain, and then synchronizes them to the main blockchain through the cross-domain communication node; (5) If the data is successfully stored in the blockchain, the digital certificate will be sent to the user, indicating that the identity registration is successful; The identity authentication process is: (1) User U A Your own identity code UID A 、Public key UserPK A After signing with the timestamp T, it is the same as the user identity code UID A Sent together to the identity authentication server AS in domain B B ; (2) Identity authentication server AS in domain B B After receiving the digital signature of the user, the AS B Get user U A Identity code UID A 、Public key UserPK A and timestamp T, and (UID A , UserPK A , T) as user U A Identity information UII A , UII A Sent to the authentication server AS in domain A A Verify U A The legitimacy of the identity; (3)If U A The identity of the B domain authentication server AS B Generate a random number r and calculate T r =T+e and Hash(UID A ,T t ), after signing, send the certificate authority CA of domain B B Apply for U A Cross-domain certificate; (4) Receive the authentication data from the AS server in domain B B After the request is made, the signature is verified first. If it is legal, according to UII A Generate a cross-domain certificate and digital signature Stored in the slave blockchain of this trust domain, the certificate hash value is synchronized to the master blockchain, and then sent to the identity authentication server AS in domain B B ; (5) Identity authentication server AS in domain B B Will and Send to U A , informing that the authentication is successful.

2. According to claim 1, the lightweight and robust cross-domain identity authentication method based on master-slave blockchain is characterized in that: The hierarchical consensus mechanism is as follows: the slave blockchain in the trust domain uses the cross-domain communication node as the master node to reach a consensus in the trust domain, and then uses the cross-domain communication node as the consensus initiating node to reach a consensus in the main blockchain.

3. A lightweight and robust cross-domain identity authentication device based on master-slave blockchain, characterized in that: The method comprises an Internet of Things device, an identity authentication server and a certificate authority to implement the method as described in any one of claims 1 to 2, wherein: The entire blockchain consists of a master blockchain and multiple slave blockchains; The certificate authority participates in maintaining the blockchain as a normal node; The identity authentication server is divided into cross-domain communication nodes and ordinary nodes. Ordinary nodes participate in maintaining the slave blockchain. Cross-domain communication nodes are elected from ordinary nodes and maintain both the slave blockchain and the master blockchain, becoming a cross-domain bridge. Before identity authentication, the user first registers the identity through the slave blockchain of this trust domain, and then authenticates the identity in conjunction with the smart contract of the master-slave blockchain. The generated digital certificate is stored in the slave blockchain, and the hash value of the certificate is stored in the master blockchain.

4. An electronic device, characterized in that: The invention comprises a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; the memory is used to store computer programs; and the processor is used to implement the steps of the method described in any one of claims 1 to 2 when executing the program stored in the memory.

5. A computer-readable storage medium, wherein a computer program is stored in the computer-readable storage medium, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 2 are implemented.

6. A computer program product comprising instructions, characterized in that When the method is executed on a computer, the computer is enabled to execute the steps of the method according to any one of claims 1 to 2.

Images