A cross-domain authentication and key agreement method and system based on multi-blockchain architecture

Abstract

The present invention relates to a cross-domain authentication and key agreement method and system based on a multi-blockchain architecture. By generating a pseudonym for a device and initiating an authentication request using the temporarily generated pseudonym during device authentication, the device's true identity information is effectively concealed. During the authentication process, traditional centralized verification mechanisms are eliminated, and portions of the verification process are incorporated into smart contracts, effectively improving verification efficiency. Furthermore, cross-domain authentication requests are verified and encrypted for transmission via cloud-based devices, ensuring secure cross-domain data interaction. This invention effectively improves the efficiency and reliability of cross-domain authentication.

Description

Technical Field

[0001] The present invention relates to the technical field of blockchain identity authentication and key negotiation, and in particular to a cross-domain authentication and key negotiation method and system based on a multi-blockchain architecture. Background Art

[0002] In recent years, with the rapid development of information technology and the decline in manufacturing costs, a large number of smart devices have been manufactured and applied in various Internet of Things (IoT) systems to meet production and daily needs. These smart devices are often clustered in domains, each with its own independent management system. For security reasons, domains are often closed to each other to prevent unauthorized users from stealing resources within them. When data sharing or collaboration between these domains is required, devices must perform intra-domain or cross-domain identity authentication before accessing domain resources to ensure the legitimacy of their identities. Existing blockchain-based cross-domain authentication schemes suffer from high on-chain storage costs, weak domain privacy protection, and insufficient device privacy protection. Therefore, a new solution with low on-chain storage costs and high domain and device privacy protection is urgently needed. Summary of the Invention

[0003] In order to solve the above problems, the purpose of the present invention is to provide a cross-domain authentication and key agreement method and system based on a multi-blockchain architecture, which effectively improves the efficiency and reliability of cross-domain authentication.

[0004] To achieve the above object, the present invention adopts the following technical solutions:

[0005] A cross-domain authentication and key agreement method based on a multi-blockchain architecture includes the following steps:

[0006] S1: System initialization, generating common parameters between different blockchains and writing them into each blockchain;

[0007] S2: The terminal device initiates a registration request. After receiving the registration request, the registration authority verifies the validity of the registration request. If the request is valid, a pseudonym for the terminal device is generated and returned to the terminal device. The identity information of the terminal device is also uploaded to the private chain and cloud alliance chain of the domain where the terminal device is located.

[0008] S3: The edge server initiates a registration request. After receiving the registration request, the registration authority verifies the validity of the registration request. If the request is valid, the identity information of the edge server is uploaded to the private chain and the cloud alliance chain.

[0009] S4: The terminal device generates a temporary pseudonym using the pseudonym obtained during the registration phase and initiates an identity authentication request;

[0010] S5: The edge server detects whether the terminal device information exists in the private chain of the current domain. If so, it performs the intra-domain identity authentication process to verify the identity of the terminal device and negotiates with the terminal device to generate a session key, thereby completing the intra-domain authentication and key negotiation; if not, it jumps to step S6;

[0011] S6: The edge server initiates a cross-domain authentication request to the cloud server. The cloud server first checks the consortium chain to confirm that the terminal device has been registered in a certain domain. If the terminal device identity information exists, the cloud server selects an edge server in the target domain, uses its own private key and the public key of the target domain edge server to generate a temporary key, uses the temporary key to encrypt the authentication request, and sends it to the target domain edge server.

[0012] S7: After receiving the cross-domain authentication request, the target domain edge server verifies the identity of the terminal device and returns the result to the edge server that initiated the cross-domain authentication. If the identity of the terminal device is legal, the edge server that initiated the cross-domain authentication negotiates with the terminal device to generate a session key, thereby completing the cross-domain identity authentication request.

[0013] The present invention also provides a cross-domain authentication and key agreement system based on a multi-blockchain architecture, comprising a processor, a memory, and a computer program stored on the memory. When the processor executes the computer program, it specifically performs the steps in the cross-domain authentication and key agreement method based on a multi-blockchain architecture as described above.

[0014] The present invention has the following beneficial effects:

[0015] This invention effectively hides the device's true identity by generating a pseudonym for the device and using it to initiate authentication requests during device authentication. This eliminates the need for traditional centralized verification mechanisms and integrates parts of the verification process into smart contracts, significantly improving verification efficiency. Furthermore, cross-domain authentication requests are verified and encrypted for transmission via cloud-based devices, ensuring secure cross-domain data exchange and significantly improving cross-domain authentication efficiency and reliability. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 It is the framework of the method of the present invention;

[0017] Figure 2 This is the intra-domain authentication process in one embodiment of the present invention;

[0018] Figure 3 This is the inter-domain authentication process in one embodiment of the present invention;

[0019] Figure 4 Symbols and meanings used in the protocol designed for this invention

[0020] Figure 5 Pseudo code of the smart contract system parameter configuration function in one embodiment of the present invention;

[0021] Figure 6 Pseudo code of the smart contract cloud server registration function in one embodiment of the present invention;

[0022] Figure 7 Pseudo code of the smart contract edge server registration function in one embodiment of the present invention;

[0023] Figure 8 Pseudo code of smart contract terminal device registration function I in one embodiment of the present invention;

[0024] Figure 9 Pseudo code of smart contract terminal device registration function II in one embodiment of the present invention;

[0025] Figure 10 Pseudo code of the smart contract system parameter acquisition function in one embodiment of the present invention;

[0026] Figure 11 Pseudo code of the smart contract terminal device identity information query function in one embodiment of the present invention;

[0027] Figure 12 Pseudo code of the smart contract target domain edge server identity information acquisition function in one embodiment of the present invention;

[0028] Figure 13 The time required for the calculation operation used in the present invention in the test environment;

[0029] Figure 14 The length of the variable used in the present invention under the test environment;

[0030] Figure 15 The calculation cost of the present invention;

[0031] Figure 16 The communication cost of the present invention;

[0032] Figure 17 It is the on-chain storage cost of the present invention. DETAILED DESCRIPTION

[0033] The present invention is further described in detail below with reference to the accompanying drawings and specific embodiments:

[0034] In this embodiment, the following is designed Figure 1 The multi-blockchain based identity authentication and key agreement framework shown here consists of the following main parts:

[0035] (1) End Devices (EDs): EDs are terminal device nodes deployed in the IoT, located at the device layer. EDs are equipped with sensors to collect information and are the entities that initiate the authentication process.

[0036] (2) Edge Servers ESs: ESs are edge servers deployed at the edge layer and are responsible for processing authentication requests from EDs.

[0037] (3) Cloud Server CSs: CSs is a cloud server located in the cloud, responsible for handling cross-chain data interaction during the cross-domain authentication phase. CS verifies the validity of the ED and ES identities, and is responsible for encrypting and sending cross-domain authentication requests to the target domain.

[0038] (4) Registration Authority (RA): RA is the registration authority in the system and is a highly secure entity. It is responsible for generating system parameters and the identity information of EDs and ESs.

[0039] (5) Private chain: The private chain of each domain stores the identity information of EDs registered in the domain and is maintained by authorized ESs in the domain.

[0040] (6) Consortium chain: The consortium chain is the cornerstone of cross-domain authentication. It is maintained by authorized CSs and stores the brief identity information of EDs and ESs. The brief information includes the domains where the ESs and EDs are located.

[0041] In this embodiment, reference Figure 2-3 The present invention provides a cross-domain authentication and key agreement method based on a multi-blockchain architecture, comprising the following steps:

[0042] S1: System initialization, generating common parameters between different blockchains and writing them into each blockchain;

[0043] S2: The terminal device initiates a registration request. After receiving the registration request, the registration authority verifies the validity of the registration request. If the request is valid, a pseudonym for the terminal device is generated and returned to the terminal device. The identity information of the terminal device is also uploaded to the private chain and cloud alliance chain of the domain where the terminal device is located.

[0044] S3: The edge server initiates a registration request. After receiving the registration request, the registration authority verifies the validity of the registration request. If the request is valid, the identity information of the edge server is uploaded to the private chain and the cloud alliance chain.

[0045] S4: The terminal device generates a temporary pseudonym using the pseudonym obtained during the registration phase and initiates an identity authentication request;

[0046] S5: The edge server detects whether the terminal device information exists in the private chain of the current domain. If so, it performs the intra-domain identity authentication process to verify the identity of the terminal device and negotiates with the terminal device to generate a session key, thereby completing the intra-domain authentication and key negotiation; if not, it jumps to step S6;

[0047] S6: The edge server initiates a cross-domain authentication request to the cloud server. The cloud server first checks the consortium chain to confirm that the terminal device has been registered in a certain domain. If the terminal device identity information exists, the cloud server selects an edge server in the target domain, uses its own private key and the public key of the target domain edge server to generate a temporary key, uses the temporary key to encrypt the authentication request, and sends it to the target domain edge server.

[0048] S7: After receiving the cross-domain authentication request, the target domain edge server verifies the identity of the terminal device and returns the result to the edge server that initiated the cross-domain authentication. If the identity of the terminal device is legal, the edge server that initiated the cross-domain authentication negotiates with the terminal device to generate a session key, thereby completing the cross-domain identity authentication request.

[0049] In this embodiment, the authentication protocol is divided into four parts: first, the RA generates system parameters; then, ESs and EDs register their identity information; finally, the ED initiates an identity authentication request to the ES. The ES performs either an intra-domain authentication process or a cross-domain authentication process based on its registration status within the ED domain. After successful authentication, the ES and ED perform key negotiation and generate a session key. The detailed process is as follows, and the parameter definitions are as follows: Figure 4 As shown:

[0050] (1) System initialization phase

[0051] The present invention is designed based on the elliptic curve discrete logarithm problem. is a finite field consisting of a large prime number Definition. In a finite field In the elliptic curve, the elliptic curve is defined as ,in Represents a point on an elliptic curve.

[0052] (a1) As a system security parameter, the RA generation bit length is prime numbers Then, RA orders is selected from the elliptic curve Cyclic groups of order, For its generator.

[0053] (a2) RA generation As the system private key, and calculate As the system public key, where is a large prime order group.

[0054] (a3) RA selects three hash functions , , and publish as system parameters.

[0055] (a4) RA creates a transaction and . Then, RA will Packed into a block identity The new block will be uploaded to the alliance blockchain. Packed into a block with a block identifier A new block. Calling Figure 5 The smart contract function shown uploads the system parameters to the alliance chain and private chain. In the system parameter writing function, first determine Is it established, It is the address of RA on the blockchain, that is, only RA can modify the system parameters recorded on the consortium chain and private chain.

[0056] (a5) Cloud Server Generate a random number and calculate .Then, The message Sent to RA.

[0057] (a6) Upon receiving the message After that, RA uses the smart contract algorithm to call Figure 6 The smart contract function shown will Upload to the private chain, thereby building a reference record for cross-blockchain information interaction. In the subsequent cross-domain authentication process, the domain All cross-domain authentication requests within will be sent to the cloud server Similarly, only RA is allowed to modify the cloud server identity information recorded on the private blockchain.

[0058] (2) ESs and EDs registration stage

[0059] In the registration phase, using asymmetric keys and signature algorithms, edge servers (ESs) and end devices (EDs) initiate online registration with the registration authority (RA) through a secure public channel. After registration is completed, the identity information of ESs and EDs is written into the blockchain. First, the registration process of the edge server:

[0060] (b1) An edge server , its identity , generate a random number , and calculate . Then, calculate the registration request message , and and signature Sent to RA, where is the timestamp.

[0061] (b2) Upon receiving the registration request message After that, cloud server Verify Timestamp and signature Validity (using the signature verification function If the timestamp and signature are valid, the cloud server decrypts (Right now ). Subsequently, RA creates a blockchain transaction , and Packed into a block number In a new block, call Figure 7 The smart contract function shown uploads the transaction to the consortium chain. The algorithm builds a reference record for cross-blockchain information interaction, where Is a Boolean variable that indicates whether the identity information stored in the block is valid. If , the identity information is valid, otherwise the identity information has expired.

[0062] Secondly, the registration process for EDs is as follows:

[0063] (c1) A connection to the edge server Terminal equipment , whose identity is , generate a random number , and calculate . The following parameters are then calculated:

[0064] ,

[0065] ,

[0066] .

[0067] Next, it generates the message , and finally send a registration request message To RA, Indicates a signature.

[0068] (c2) After receiving the registration request message, RA decrypts (Right now ). After decryption, RA checks the timestamp If it is not valid, the registration request is rejected. Then, the RA verifies the equation and Is it true? If so, RA generates a random number , and calculate the following parameters:

[0069] ,

[0070] ,in, is the timestamp,

[0071] ,

[0072] ,

[0073] ,

[0074] ,

[0075] in, Is RA Generate pseudonymous identity. Then, RA creates a blockchain transaction , and Packaged into a block with identity In the block, by calling Figure 8 The smart contract function shown uploads the block to the private chain.

[0076] (c3) Completed at RA After registration on the private chain, it creates a blockchain transaction , and Packaged into a block with identity In the new block, by calling Figure 9 The smart contract function shown is uploaded to the consortium chain.

[0077] (c4) After the identity information is written into the alliance chain and private chain, RA calculates the message and send to .exist get Afterwards, it passes get ,These parameters will be used in the subsequent identity authentication and key negotiation process.

[0078] (3) Intra-domain identity authentication and key negotiation process

[0079] Assuming that the domain Memory in terminal device , to the edge server in the domain Initiate an authentication request, then the system will perform intra-domain authentication. The cross-domain authentication process is as follows Figure 2 The specific description of the process is as follows:

[0080] (d1) Generate random numbers To calculate the following parameters:

[0081] ,

[0082] ,

[0083] ,

[0084] ,

[0085] .

[0086] in, 、 、 、 、 Represent the terminal device private key, public key, pseudonym, real identity and domain name of the domain; then, it will Send to ,in is the current timestamp.

[0087] (d2) After receiving the message back, Will check Is it valid? If not, the authentication process terminates; otherwise calculate and .Then, Calling Figure 10 The smart contract function shown gets the public parameters from the private chain .

[0088] (d3) By calling Figure 11 The smart contract function shown searches for the same Matching identity information and If If the relevant identity information does not exist, the authentication process will be terminated.

[0089] (d4) verify and Is it true? or , the authentication process terminates; otherwise, continue to execute subsequent processes.

[0090] (d5) Generate random numbers , calculate the following parameters:

[0091] ,

[0092] ,

[0093] ,

[0094] ,

[0095] And generate a session key .at last, Generate Message and send to ,in is the current timestamp.

[0096] (d6) Upon receiving the message back, examine Is it valid? If not, the authentication process terminates; otherwise, calculate the following parameters:

[0097] ,

[0098] ,

[0099] And generate a session key , then verify the equation Is it true? If the equation is true, then and Complete domain authentication and key negotiation, terminal device and edge servers Session keys are securely generated and stored , in order to conduct conversations on public channels.

[0100] (4) Cross-domain identity authentication and key negotiation process

[0101] Assuming identity of Is located in the domain Terminal device with identity of and have identity of Are located in the domain and domain Edge servers in . Is responsible for managing the domain The cloud server for cross-domain authentication requests. Private chain storage identity information. Towards Initiate an identity authentication request. In this case, a cross-domain authentication process will be executed. The cross-domain authentication process is as follows Figure 3 The specific instructions for cross-domain authentication are as follows:

[0102] (e1) Generate random numbers To calculate the following parameters:

[0103] ,

[0104] ,

[0105] ,

[0106] ,

[0107] .

[0108] Then, generate the message and send to ,in is the current timestamp.

[0109] (e2) receive After that, it first checks Is it valid? If not, the authentication process terminates; otherwise, calculate and .Then, Extract system parameters from private chain and Identity information .

[0110] (e3) Generate random numbers , and calculate the following parameters:

[0111] ,

[0112] ,

[0113] ,

[0114] .

[0115] Then, generate the message and send to ,in is the current timestamp.

[0116] (e4) Get After that, it first checks Is it valid? If not, the authentication process terminates; otherwise, calculate the following parameters:

[0117] ,

[0118] ,

[0119] .

[0120] Then, Search for relevant identity information in the consortium chain (i.e. , and ), to judge and Is it already registered? or If you have not registered yet, the certification will be suspended.

[0121] (e5) According to the above assumptions, the domain The private blockchain stores identity information. Calling Figure 12 The smart contract function shown randomly selects a node in the domain from the consortium blockchain. Edge Servers in , and obtain .then, Calculate the following parameters:

[0122] ,

[0123] ,

[0124] Generate Message and send to .Then, Generate a random number , and calculate the following parameters:

[0125] ,

[0126] ,

[0127] .

[0128] Then, generate the message and send to ,in , The current timestamp.

[0129] (e6) receive After that, it first checks Is it valid? If not, the authentication process terminates; otherwise, the following parameters are calculated:

[0130] ,

[0131] .

[0132] then, Calling Figure 11 The smart contract function shown searches for the same Matching identity information , If If the matching identity information does not exist, the authentication fails. If the identity information matches, verify and Is it true? If it is true, the authentication is successful; otherwise, the authentication fails. According to the authentication result, A response message will be returned. If the authentication is successful, Otherwise, let Finally, the authentication result message Send to ,in The current timestamp.

[0133] (e7) Received and authentication result message back, First check and Are they all valid? If not, the authentication process is terminated. Then, from Get The identity and public key of and Restore and . And according to The authentication result is confirmed by whether it is established. If it is not established, it means that the authentication has failed. The following parameters are calculated:

[0134] ,

[0135] ,

[0136] ,

[0137] .

[0138] And generate a session key, .at last, Generate Message and send to ,in The current timestamp.

[0139] (e8) receive After that, first check Is it valid? If not, the authentication process will terminate; if valid, the following parameters will be calculated:

[0140] ,

[0141] ,

[0142] And generate a session key . Then verify the equation Is it true? If the equation is true, then and Cross-domain authentication and key negotiation will be completed. At this point, the terminal device and edge servers Session keys are securely generated and stored for conversations over public channels.

[0143] In this embodiment, security analysis is performed and an attacker who attempts to attack the authentication scheme is called an "adversary". The adversary can read, modify, delete, forge, replay information or even insert false information through an insecure public channel between two communicating entities.

[0144] (1) Mutual authentication: If an adversary attempts to impersonate a legitimate ED to pass the authentication of an ES, it must generate Correct matching and .because Protected by the random number and ED's private key, the adversary cannot obtain , and only authorized ES nodes are allowed to access the private chain to obtain The adversary cannot steal identity information from the private chain. Therefore, the adversary cannot exploit and Generate valid and If the adversary pretends to be a legitimate ES and intends to successfully pass the verification of ED, he needs to calculate the correct .because Receive the random number, ED and ES private key protection, the adversary cannot generate a valid , so the adversary cannot generate the correct .

[0145] (2) Anonymity: In the proposed scheme, when ES performs authentication, ED does not send its real identity to ES. Instead, it sends a temporary identity generated by its pseudonym and a random number. Therefore, the communicating parties and the adversary cannot obtain ED's identity information. Similarly, ES and CS also use a temporary identity generated by their real identity and a random number during the authentication process. Therefore, the scheme can achieve anonymity, and the adversary cannot obtain the real identities of ED, ES, and CS. In addition, since ED uses a pseudonym when constructing its temporary identity, ES and CS can only obtain ED's pseudonym. ED's real identity is only known to the RA that generates its pseudonym.

[0146] (3) Untraceability: During the authentication process, the entity does not directly use a pseudonym or real name, but adopts a temporary identity protected by a random number and a private key (i.e. and ), and each temporary identity is different. Due to the randomness of the random number, the adversary cannot distinguish which two different pseudo-identities belong to the same entity.

[0147] (4) Forward and backward security: In the proposed technique, the session key By using the private keys of ED and ES and , the true identity of ES , ED's pseudonym , a random number selected by ED and ES and , and the latest timestamp. Therefore, the proposed scheme achieves forward and backward security.

[0148] (5) Ability to resist common attacks: The proposed scheme is able to resist the following common attacks: (a) Replay attack: Although the adversary can read the message on the public channel, the message contains a short-lived timestamp and a random number. Therefore, the proposed scheme is highly resistant to replay attacks; (b) Man-in-the-middle attack: The adversary can read and modify the message on the public channel through a man-in-the-middle attack, but to complete authentication and key agreement, the private key of ED or ES and the random number generated by ED and ES are required. Therefore, the adversary cannot complete authentication or destroy the protocol through a man-in-the-middle attack; (c) Impersonation attack: If the adversary attempts to impersonate a legitimate entity (such as ED), the security of mutual authentication must be compromised. As mentioned above, the adversary cannot impersonate a legitimate entity. Therefore, the proposed scheme is able to resist impersonation attacks; (d) Denial of Service (DoS): In the proposed scheme, any ES can access the private chain to complete authentication, and any ES can access the consortium chain to complete cross-domain data interaction. Therefore, the adversary cannot paralyze the authentication service by launching a DoS attack on a single or multiple ES or CS.

[0149] (6) Cross-domain data exchange security: During the cross-domain authentication process, the ES that responds to the authentication result only transmits the encrypted authentication result to the ES that initiates the request, rather than transmitting the device identity information stored in the private chain. In addition, CSs are responsible for reviewing and encrypting the transmission of cross-domain authentication requests. Therefore, during the cross-domain data exchange process, the data in the private chain will not be leaked.

[0150] In this example, we analyze the computational cost (the time required to perform an authentication process), communication cost (the network bandwidth required to perform an authentication process), and on-chain storage (the storage space occupied by the device identity information on the blockchain). It should be noted that since the registration phase is only performed once, the impact on the entire system is minimal. Therefore, this section focuses on the computational cost and communication cost of the authentication and key agreement phases. The overhead of some lightweight operations, such as XOR operations, The test environment is Ubuntu 16.04 LTS system, CPU is Intel Core i5-11400H, memory is 2GB RAM, using PBC library and OpenSSL library, programming language is C++, on elliptic curve Upper structure The performance of the proposed technology is tested by using bilinear pairings. The hash function used is MD5, and the asymmetric encryption algorithm, symmetric encryption algorithm and signature algorithm are RSA encryption algorithm and RSA signature algorithm respectively. Under the test environment described above, the calculation time of the operation used by the present invention is as follows: Figure 13 As shown, the variable length used is as follows Figure 14 The computational and communication overheads of the solution of the present invention are shown in Figure 15 and Figure 16 As shown, the on-chain storage cost is Figure 17 Through performance analysis, it can be seen that the computational cost, communication cost, and on-chain storage cost of the present invention are all reasonable, and the present invention is applicable to actual systems.

[0151] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0152] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0153] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0154] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0155] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any other manner. Any person skilled in the art may utilize the above-disclosed technical content to modify or modify the present invention into equivalent embodiments. However, any simple modifications, equivalent variations, and modifications to the above embodiments that do not depart from the technical content of the present invention and are based on the technical essence of the present invention remain within the scope of protection of the present invention.

Claims

1. A cross-domain authentication and key agreement method based on a multi-blockchain architecture, characterized in that: The following steps are involved: S1: System initialization, generating common parameters between different blockchains and writing them into each blockchain; S2: The terminal device initiates a registration request. After receiving the registration request, the registration authority verifies the validity of the registration request. If the request is valid, a pseudonym for the terminal device is generated and returned to the terminal device. The identity information of the terminal device is also uploaded to the private chain and cloud alliance chain of the domain where the terminal device is located. S3: The edge server initiates a registration request. After receiving the registration request, the registration authority verifies the validity of the registration request. If the request is valid, the identity information of the edge server is uploaded to the private chain and the cloud alliance chain. S4: The terminal device generates a temporary pseudonym using the pseudonym obtained during the registration phase and initiates an identity authentication request; S5: The edge server detects whether the terminal device information exists in the private chain of the current domain. If so, it executes the intra-domain identity authentication process to verify the identity of the terminal device and negotiates with the terminal device to generate a session key, thereby completing the intra-domain authentication and key negotiation; If not, jump to step S6; S6: The edge server initiates a cross-domain authentication request to the cloud server. The cloud server first checks the consortium chain to confirm that the terminal device has been registered in a certain domain. If the terminal device identity information exists, the cloud server selects an edge server in the target domain, uses its own private key and the public key of the target domain edge server to generate a temporary key, uses the temporary key to encrypt the authentication request, and sends it to the target domain edge server. S7: After receiving the cross-domain authentication request, the target domain edge server verifies the identity of the terminal device and returns the result to the edge server that initiated the cross-domain authentication. If the identity of the terminal device is legal, the edge server that initiated the cross-domain authentication negotiates with the terminal device to generate a session key, thereby completing the cross-domain identity authentication request.

2. A cross-domain authentication and key agreement method based on a multi-blockchain architecture according to claim 1, characterized in that: The registration process of the edge server is as follows: Set up an edge server , its identity , generate a random number , and calculate , P is the base point on the elliptic curve; Then, the registration request message is calculated , and and signature Sent to the registration authority, where is the timestamp, Enc is the symmetric encryption function, is the identity of the kth domain in the system, is the system public key; Upon receiving the registration request message After that, cloud server Verify Timestamp and signature The validity of the signature verification function ; If the timestamp and signature are valid, the cloud server decrypts ,Right now ; The registry then creates a blockchain transaction , and Packed into a block number In the new block, the smart contract function is called to upload the transaction to the alliance chain. The algorithm builds a reference record for cross-blockchain information interaction, where Is a Boolean variable that indicates whether the identity information stored in the block is valid. If , the identity information is valid, otherwise the identity information has expired.

3. A cross-domain authentication and key agreement method based on a multi-blockchain architecture according to claim 1, characterized in that: The edge server registration process is as follows: One connection to the edge server Terminal equipment , whose identity is , generate a random number , and calculate ; Then calculate the following parameters: ； ； ； Next, generate the message , and finally send a registration request message To the registration authority, Indicates signature; After receiving the registration request message, the registration authority decrypts ,Right now , after decryption, the registration authority checks the timestamp Is it valid? If not, the registration request is rejected. Then, the registration authority verifies the equation and Is it true? If so, the registration authority generates a random number , and calculate the following parameters: ； ,in, is the timestamp; ； ； ； ； in, Is the registration authority The generated pseudonym identity, s is the system private key, H1, H2, H3 are hash functions, is the intermediate parameter; then, the registration authority creates a blockchain transaction , and Packaged into a block with identity In the block, the block is uploaded to the private chain by calling the smart contract function; (c3) Completed at the registration authority After registration on the private chain, it creates a blockchain transaction , and Packaged into a block with identity In the new block, it is uploaded to the alliance chain by calling the smart contract function; (c4) After the identity information is written into the alliance chain and private chain, the registration agency calculates the message and send to ;exist get Afterwards, through get .

4. A cross-domain authentication and key agreement method based on a multi-blockchain architecture according to claim 1, characterized in that: If in domain Memory in terminal device , to the edge server in the domain Initiate an authentication request. The system will then perform domain authentication as follows: (d1) Generate random numbers To calculate the following parameters: ； ； ； ； ； in, 、 、 、 、 Represent the terminal device private key, public key, pseudonym, real identity and domain name of the domain; then, it will Send to ,in is the current timestamp; (d2) After receiving the message back, Will check Is it valid? If not, the authentication process terminates; otherwise calculate and ;Then, Call smart contract functions to obtain public parameters from the private chain ; (d3) Search for the same in the private blockchain by calling the smart contract function Matching identity information and ; If If the relevant identity information does not exist, the authentication process will be terminated; (d4) verify and Is it established? or , the authentication process terminates; otherwise, continue to execute the subsequent process; (d5) Generate random numbers , calculate the following parameters: ； ； ； ； And generate a session key ;at last, Generate Message and send to ,in is the current timestamp; (d6) Upon receiving the message back, examine Is it valid? If not, the authentication process terminates; otherwise, calculate the following parameters: ， ， And generate a session key , then verify the equation Is it true? If the equation is true, then and Complete domain authentication and key negotiation, terminal device and edge servers Session keys are securely generated and stored , in order to conduct conversations on public channels.

5. A cross-domain authentication and key agreement method based on a multi-blockchain architecture according to claim 1, characterized in that: Assume identity of Is located in the domain Terminal device with identity of and have identity of Domain and domain The edge server in Is responsible for managing the domain Cloud server for cross-domain authentication requests; Private chain storage identity information; if Towards When an identity authentication request is initiated, the cross-authentication process is executed as follows: (e1) Generate random numbers To calculate the following parameters: ； ； ； ； ； Then, generate the message and send to ,in is the current timestamp; (e2) receive After that, it first checks Is it valid? If not, the authentication process terminates; otherwise, calculate and ;Then, Extract system parameters from private chain and Identity information ; (e3) Generate random numbers , and calculate the following parameters: ； ； ； ； Then, generate the message and send to ,in is the current timestamp; (e4) Get After that, it first checks Is it valid? If not, the authentication process terminates; otherwise, calculate the following parameters: ； ； ； Then, Search for relevant identity information in the alliance chain to determine and Is it already registered? or If you have not yet registered, the certification will be suspended; (e5) Domain The private blockchain stores identity information; Call the smart contract function to randomly select a node in the domain from the consortium blockchain Edge Servers in , and obtain ;then, Calculate the following parameters: ； ； Generate Message and send to ;Then, Generate a random number , and calculate the following parameters: ； ； ； Then, generate the message and send to ,in , is the current timestamp; (e6) receive After that, first check Is it valid? If not, the authentication process terminates; otherwise, calculate the following parameters: ， ； then, Call smart contract function to search in private chain Matching identity information , ; If If the matching identity information does not exist, the authentication fails; if the matching identity information exists, the authentication fails. Matching identity information, then verify and Is it established? If it is established, the authentication is successful; otherwise, the authentication fails. According to the authentication result, A response message will be returned; If the authentication is successful, Otherwise, let ;Finally, the authentication result message Send to ,in is the current timestamp; (e7) Received and authentication result message back, First check and Are they all valid? If not, the authentication process is terminated; Then, from Get The identity and public key of and Restore and ; and according to If it is not established, it means the authentication has failed; otherwise, Generate random numbers , calculate the following parameters: ； ； ； ； And generate a session key, ;at last, Generate Message and send to ,in is the current timestamp; (e8) receive After that, first check Is it valid? If not, the authentication process will terminate. If valid, calculate the following parameters: ， ， And generate a session key ; Then verify the equation Is it true? If the equation is true, then and Cross-domain authentication and key negotiation will be completed; At this time, the terminal device and edge servers Session keys are securely generated and stored for conversations over public channels.

6. A cross-domain authentication and key agreement system based on a multi-blockchain architecture, characterized in that: The method comprises a processor, a memory, and a computer program stored in the memory. When the processor executes the computer program, the method specifically performs the steps in the cross-domain authentication and key agreement method based on a multi-blockchain architecture as described in any one of claims 1 to 5.

Images