A Chain: A Blockchain-Based Decentralized Authentication Scheme for 5G-Enabled IoT

+e fifth-generationmobile communication technology (5G) provides high-bandwidth and low-latency data channels for massive IoT terminals to access the core business network. At the same time, it also brings higher security threats and challenges. Terminal identity authentication is an important security mechanism to ensure the core business network; however, most of the existing solutions adopt a centralized authentication model. Once the number of authentication requests exceeds the processing capacity of the authentication center service, it will cause authentication request congestion or deadlock. +e decentralized authentication model can effectively solve the above problems. +is article proposes a decentralized IoT authentication scheme called A Chain. First, A Chain uses edge computing to decentralize the processing of authentication requests and eliminate the burden on authentication services and the network. Second, to implement cross-domain identity verification of IoT devices, A Chain uses blockchain, and sidechain technologies are used to securely share the identity verification information of IoT devices. Additionally, A Chain replaces public key infrastructure (PKI) algorithm with identity-based cryptography (IBC) algorithm to eliminate the management overhead caused by centralized authentication model.


Introduction
With the rapid development of 5G networks, their fast speed, low latency, and high access will provide a broader platform for the development of IoT technology [1][2][3]. As defined by 3GPP, 5G supports access to at least 10 6 devices per square kilometre [4]. As 5G powers IoT, it also brings huge challenges to IoT security [5]. e authentication of IoT devices is an important step in ensuring IoT security.
Traditional authentication schemes are usually centralized, which has high latency and untimely response problems in the 5G mass IoT device access scenario [6]. On the one hand, the authentication server or network node will have serious network congestion when massive IoT devices ask for authentication in this era where IoT devices are ubiquitous, and this will seriously affect the service quality of IoT applications [7][8][9][10][11]. On the other hand, centralized authentication usually requires the authentication center to respond to the authentication request of the IoT device.
However, due to the long link distance, it cannot satisfy the delay-sensitive applications (for example, the internet of vehicles and unmanned aerial drones) [12]. Also, traditional centralized authentication uses a public key infrastructurebased authentication structure, which carries high computational and communication costs for IoT devices that have limited resources in terms of power, memory, and processing power [13,14]. Secondly, in traditional public key infrastructure-(PKI-) based authentication models, there is a single point of failure and third-party trustworthiness issues [15].
Decentralized IoT authentication can meet the authentication needs of a large number of IoT devices, and authentication latency issues can be solved by authenticating the device identity through edge nodes. In decentralized authentication scheme of IoT, the decentralized security mechanism is necessary to protect network resources or data, especially to ensure the consistency of authentication data of edge authentication services. In recent years, blockchain technology has gained widespread attention in authentication and access control research due to its decentralized and cryptographic properties.
ere is a natural fit between blockchain technology as a distributed ledger and the decentralized edge computing model, and researchers have already adopted edge computing to support services in blockchain networks [16][17][18]. Besides, blockchain's nonfalsifiability and fault tolerance make it a good solution to authentication problems [19]. For example, in [20], the feasibility of using blockchain technology for IoT device authentication in edge computing systems is discussed, and blockchain-based smart contracts are introduced to handle the operation of authentication-related certificates; Jia et al. [21] proposed a blockchain-based cross-domain authentication system applied to the authentication process for data access to different IoT application domains; e study [22] was based on blockchain and elliptic curve cryptosystem cross-data center authentication and key exchange programs.
However, in existing blockchain-based authentication schemes, the authentication information of a large number of IoT devices is stored in a single blockchain, which poses a huge storage burden and scalability problem for blockchain nodes. In this paper, we propose a decentralized IoT authentication scheme combining edge computing and sidechain techniques. We named it A 2 Chain since the proposed authentication model includes two types of blockchains: application domain blockchain and alliance blockchain. Compared to past work, the innovations and contributions in this paper are as follows: (1) Edge computing technology is adopted to decentralize the processing of authentication requests through the authentication service nodes deployed at the edge of the network. On the one hand, it reduces the server burden caused by a large number of IoT authentication requests. On the other hand, the authentication service processing is close to the terminal, which can reduce the network burden and authentication delay and improve communication efficiency. (2) An IoTauthentication structure based on application domain-alliance chains is proposed to deploy blockchains in different application domains as well as between application domains, respectively. e application domain blockchain acts as a sidechain for the alliance blockchain. Each application domain blockchain can run the intradomain authentication process independently within the application domain. e federation chain stores the authentication information index of the application domain devices and proves the existence of the authentication information by simplified payment verification (SPV) proof when cross-domain authentication is required.
is structure occupies less storage space and improves the efficiency of searching for target information.
(3) Identity-based cryptography (IBC) is proposed for identity authentication without introducing any trusted third parties. In this case, public key certificates are no longer required, reducing the heavy workload of issuing, maintaining, and revoking digital certificates. e remainder of this paper is organized as follows: an overview of the related work is given in Section 2. In Section 3, the problem is further stated. Section 4 provides an overview of the proposed solution, Section 5 details the certification process of the solution, and Section 6 verifies the effectiveness and efficiency of the solution through experiments. In Section 7, we discuss the shortcomings of the program and look forward to future research directions. Finally, in Section 8, we conclude the paper.

Authentication Scheme Based on Traditional Scheme.
At present, IoT usually adopts centralized authentication, which is more costly, prone to a single point of failure, and less efficient in the case of mass device authentication. [23]. Esfahani et al. [24] proposed a lightweight industrial Internet of ings (IIoT) device authentication mechanism, but it stores the authentication data on a local server. erefore, it is susceptible to a single point of failure. In order to meet the authentication requirements of many IoT devices in the 5G network environment, Ni et al. [25] used fog computing and network slicing technology to propose an efficient and secure service-oriented authentication framework. Users can use the fog node to select the appropriate network slice according to the service type of the access service and efficiently establish a connection with the core network. Gross et al. [26] introduced an authentication method based on IPsec and TLS. However, the higher computational cost required by Gross' scheme is intolerable for resource-constrained IoT devices. Lai et al. [27] proposed the CPAL scheme in order to enable IoT devices to access the mobile Internet all the time. In CPAL, secure roaming authentication can be provided for IoT devices through group signature technology.

Authentication Scheme Based on Blockchain.
Blockchain will play an important role in IoT device management and security due to its characteristics such as decentralized and untamperable. In [28], Hammi et al. discussed the current dilemma in IoT authentication and propose bubbles of trust, a decentralized authentication scheme based on blockchain, to create a secure virtual area in the blockchain, which enables IoT devices to communicate securely. However, due to the closed nature of its virtual region, IoT devices can only communicate with devices belonging to the same region and cannot communicate across domains. In [29], Bao et al. proposed the IoT Chain scheme, which consists of an authentication layer, a blockchain layer, and an application layer to achieve authentication, access control, privacy protection, lightweight features, regional node fault tolerance, denial-of-service resilience, and storage integrity. Khalid et al. [30] proposed a lightweight decentralized IoT based on the fog computing and blockchain technology Internet authentication scheme, IoT devices will be tied to the IoT application system where they are located when they register, and the latter will issue tokens for them, thus enabling secure communication between devices. Zhang et al. [31] proposed a blockchain-based decentralized vehicle authentication scheme and designed collaborative authentication based on secret sharing and blockchain-based data tracking and trust management in a dynamic agent edge computing model. Cui et al. [32], in his study, a hybrid blockchain-based multi-WSN authentication scheme, designed a wireless-aware network hierarchical model and a hybrid blockchain model combining private and public blockchains. For different types of devices, different blockchains were used for authentication. e authentication information of all nodes was stored on the public blockchain at that time, which caused a certain storage burden.

Proposed Scheme
In this part, we design an application domain-alliance chain IoT authentication model called A 2 Chain to meet the need for secure authentication in IoT. Firstly, the problem presented in this paper is stated; secondly, reasonable assumptions are made about the scheme; and finally, based on the above assumptions, our proposed authentication scheme is presented.

Motivation and Basic
Idea. Authentication is one of the indispensable means to ensure the security of network communication. 5G enables IoT to have higher transmission speed and capacity and lower transmission delay and can provide high coverage and massive device deployment for the Internet of ings applications [2,3]. ese massively connected terminal devices simultaneously initiate authentication requests, which will have a serious impact on the authentication server [9][10][11]. In traditional authentication mechanisms, a centralized mechanism is usually used, as in Figure 1(a), where all devices are authenticated through a centrally located authentication server. In the case of massive device access, centralized authentication will bring about a challenge to the availability of legitimate devices, or a weak link in resource exhaustion attacks [15,33].
As a decentralized and distributed technology, blockchain provides a new solution to the problems that exist in IoT authentication [28,34,35]. As in Figure 1(b), blockchain-based authentication schemes decentralize IoT authentication by establishing a blockchain network at a gateway or authentication server in the system to achieve distributed management of the authentication process. ese solutions work well to overcome the single point of failure of centralized authentication, third-party trust, and the difficulty of resisting DoS attacks. However, there are still some limitations and challenges of existing blockchainbased authentication schemes as follows: (1) Low authentication efficiency: the authentication process for IoT applications requires an authentication server to handle authentication requests, although blockchain-based authentication schemes enable distributed management of the authentication process and no longer rely on a single centralized authentication center. However, authentication servers are usually deployed on the side away from the end device or on cloud servers. is imposes higher latency and bandwidth consumption on the authentication process [36]. And when in IoT applications, latency-sensitive applications have strict requirements on response time. In addition, as the number of IoT devices increases, the burden on the authentication server increases significantly, which will also bring bottlenecks and delays in the system communication, thus limiting the quality of the system service.
(2) Scalability problem: with the popularity of IoT, the identity authentication problem in IoT does not only exist in a single IoT application, but also in different IoT applications with the same authentication needs [21,37], which we call cross-domain authentication.
Blockchain-based authentication schemes are usually deployed in a single application domain or intelligent system, and authentication information from different application domains or systems is not interoperable, lacking an effective cross-domain authentication scheme.
(3) Storage overload: even though some schemes solve the cross-domain authentication problem to some extent by forming federated blockchains [38][39][40], due to the nature of the blockchain, the full node of the blockchain must store every block on the blockchain and the transactions it contains. erefore, each authentication server has to store all registered IoT endpoint authentication information, which includes not only authentication information from this application, but also information from other application domains. e information from other application domains may include a large number of devices that do not require cross-domain authentication, resulting in a waste of storage space. All device information is stored in the federated blockchain, and frequent authentication operations consume a lot of resources and time, which does not meet the real-time requirements of IoT.
To overcome the aforementioned shortcomings of blockchain-based authentication, we propose to combine blockchain-sidechain technology as well as edge computing technology to authenticate IoT devices. In the decentralized authentication scheme proposed in this paper, the basic ideas include the following aspects. First, in the organization of the authentication architecture, we propose an authentication architecture based on edge computing to deploy authentication service nodes at the edge of the network, which we call edge authentication nodes (EAs). Since the authentication service is closer to the end device side, authentication requests from a large number of endpoints do Mobile Information Systems not need to be sent to the core network, which can effectively reduce authentication latency and network burden [41,42]. Second, we use blockchain and sidechain technology to build different application domain blockchains and alliance blockchains to share authentication information, instead of the trusted third-party authorization process. On the one hand, different application domains can ensure the independence of their own applications in different sidechains; on the other hand, sidechain technology provides a secure decentralized peer-to-peer data-sharing platform, and each application domain does not need to store unnecessary authentication information, which reduces the storage burden of blockchain nodes and improves the scalability of the authentication model [43,44]. Finally, in terms of the signature algorithm, we propose to adopt an identity-based signature algorithm [45], which can determine the authenticity of the user without a trusted third party and reduce the overhead of storing certificates on the end device.
When a user's device wants to access the network of the application domain to which it belongs, it can initiate an authentication request to the nearest edge authentication server to quickly pass identity authentication. When the device wants to access the network or data of other application domains, it can use sidechain technology to prove the reliability of its authentication information through SPV to achieve cross-domain authentication. In the following chapters, we will describe our plan in detail.

Assumptions.
We propose an IoT authentication model scheme based on an application domain-alliance blockchain based on several reasonable assumptions that can be satisfied under certain conditions. e assumptions are as follows: (1) Each IoT device has a unique object identifier [21], the object identifier (OID) structure is <Domain_ID. Category_ ID. Entity_ID>, and Table 1 describes the meaning of each field (2) All domain management nodes and edge authentication nodes are legitimate and trusted (3) e system initialization and key distribution process is secure

System
Architecture. According to different node functions, IoT nodes can be divided into domain management nodes, edge authentication nodes, and terminal devices. In order to facilitate the management of IoT devices and achieve their secure authentication, the system architecture is designed as shown in Figure 2 according to the different terminal device functions or usage scenarios. e entire architecture is divided into multiple application domains, and each network includes domain management nodes, edge authentication nodes, and end devices: (1) Domain manage node (DM): the main function is to manage the nodes in the application domain. As a node manager, it is trusted by the nodes in the network, and the terminal devices in the application domain need to register with the domain manage node before entering the network, and the domain manage node generates the private key for them according to the identity information provided and returns to the terminal devices.
(2) Edge authentication node (EA): edge authentication node is used to authenticate the identity of end devices and has strong computational and storage capabilities. Edge authentication nodes are deployed decentralized at the edge of the network, near the end device side, and have low latency, which reduces the load on authentication services and the network [12]. rough distributed edge authentication nodes, we have realized the decentralization of the authentication structure. (3) Terminal device (TD): is consists mainly of a large number of IoT terminal devices deployed in various application scenarios for sensing, serving, and communicating. ese devices can detect or generate data for transmission to different IoT applications. Authentication is required to access the network or to access data.

Types of Authentication.
e various nodes in the network collaborate with each other to accomplish various IoT application tasks. When a terminal device accesses the network or needs to access data, it needs to be authenticated, and in our proposed scenario, two types of authentication scenarios are involved: (A) Intradomain authentication: due to business requirements, the terminal device needs access to its registered application domain data, as shown in Request 1 in Figure 2. In this case, the edge authentication node can easily retrieve the public parameters of the terminal signature through the application domain blockchain to authenticate the identity of the terminal device. Such authentication type we call intradomain authentication. (B) Cross-domain authentication: with the rapid development of IoT, the number of application domains is increasing rapidly, and the interaction between different application domains is becoming more frequent. In some cases, devices from different application domains need to collaborate to complete a task, and terminal devices need to access application domain data outside their registered application domain, such as request 2 in Figure 2. Unlike intradomain authentication scenarios, application domains do not necessarily trust each other, as a domain is usually reluctant to let others access its sensitive data. In addition, the edge authentication node and the terminal device belong to different application domains, and the public parameters of the system signature are also different; in order to achieve the secure transmission of data from different application domains and terminal communication, cross-domain authentication of IoT terminals needs to be implemented, and the detailed process is described in Section 4.

A 2 Chain Model.
In the past blockchain-based authentication schemes, IoT nodes join the same blockchain network, but a large number of IoT nodes frequently undergoing authentication operations will bring a lot of resources and time consumption, cannot meet the real-time requirements of IoT devices [29]; at the same time, different application domains join the same blockchain, application domain authentication devices not only need to store the authentication information in this domain, but also need to store the authentication information of other application domains, greatly increasing the storage pressure of the authentication device and information search space, will also affect the efficiency of the authentication service.
To this end, in this paper, we propose an A 2 Chain authentication model, which consists of two main parts: the application domain blockchain and the alliance blockchain. In addition, through the noncentralized nature of the blockchain, A 2 Chain does not require a trusted third-party entity and achieves a good decentralized authentication.

Signature Algorithm.
In the authentication process, the proposed system uses an identity-based cryptosystem [45]. Since there is no need to use public key certificates in identity-based cryptographic systems and no trusted thirdparty entities to issue certificates, it satisfies the need for decentralized authentication. Moreover, the use of identitybased signature algorithms can reduce the complexity of deployment and management and has unique advantages in protecting IoT applications.
We use the identity-based cryptographic standard SM9 [46] issued by the State Cryptography Administration for authentication, and the strength of SM9's encryption is equivalent to the RSA encryption algorithm for 3072-bit keys.
e SM9 signature algorithm consists of five steps: system parameter generation, master key generation, device key generation, signature generation, and signature verification. e signer holds an identity and a corresponding private key, which is generated by the key generation server (KGS) through the combination of the master private key and the signer's identity. e signer uses its own private key to generate a digital signature on the data, and the verifier uses the signer's identity to generate its public key to verify the reliability of the signature, i.e., to verify the authenticity and integrity of the sent data and the identity of the data sender: System parameter generation (SPG): it includes the curve identifier cid; the parameters q of the base field F q of the elliptic curve; the parameters a and b of the elliptic curve equation; the prime factor N of the curve order and the residual factor cf relative to N; the embedding degree k of the curve E(F q ) with respect to N; the generator P 1 of the N order cyclic subgroup Signature generation (SigGen): assuming the message to be signed is a bit string M, perform the algorithmic steps given in Algorithm 1 as a signature device in order to obtain the digital signature (h, S) of the message M. Signature verification (SigVer): in order to verify the received message M and its digital signature (h, S), the verifier performs the following arithmetic steps:

Authentication Mechanism
In this section, we will present the working of the proposed A 2 Chain. e system consists of three main phases: the initialization phase, the registration phase, and the device authentication phase.

Initialization Phase.
In the initialization phase, each domain management node uses the SPG algorithm to generate public parameter group parameters and calls MKGen and DKGen to generate master key pair (s, P pub ) and asymmetric key pairs DM SK , DM I D of the domain management node, in which DM SK demonstrates the signed private key of the domain management node and DM I D represents the identity of the domain management node and the public key corresponding to DM SK .  Mobile Information Systems After generating public parameters and keys, the domain management node broadcasts them in the application domain; creates blocks with the identity ID DM I D , the public parameter group parameters, and the master public key P pub; writes them into the application domain blockchain; and stores their block numbers in the alliance blockchain. e relevant steps are as follows: (1) First, the domain management node generates the public parameter group parameters, the master key pair (s, P pub ), and the asymmetric key pair

Registration Phase.
During this phase, the IoT device will register with a domain management node within its application domain, and upon successful registration, the device will be associated with that application domain and the associated information will be counted in the alliance blockchain. e main steps in the registration phase are as follows: (1) e device sends the registration request message

Mobile Information Systems
(2) Upon receipt of the message M 1 , the domain management node verifies that the received DM I D is in this application domain and that the TD I D has not been registered (3) If the DM I D does not belong to the application domain or a device with a TD I D that has been registered, registration will not be allowed and the registration process will be terminated (4) If the DM I D belongs to the application domain and the TD I D is not registered, registration is allowed (5) Call the SigVer algorithm to verify the validity of the message by verifying the signature. If the validation is valid, the registration process continues; otherwise the registration process is aborted (6) e domain management node creates a transaction  (7) When the new device registration is successful, the device TD I D and its block number Block_num will be uploaded to the alliance blockchain along with the corresponding domain management node DM I D to form a reference record of the authentication information sharing process, as shown in Figure 4 Due to the business requirements of IoT applications, etc., the terminal device may need access to the network or data of other application domains. When a terminal device requests access to other application domains, the terminal device needs to be authenticated, i.e., cross-domain authentication. At this point, it can be combined with our previous study-IRBA scheme [21], where an end device with cross-domain access needs can make a cross-domain authorization request to the domain management node and the end device obtains the authorization from the management node of the application domain it needs to access through a threshold signature and credits the authorization to the alliance blockchain.
Similar to the terminal device registration process, an edge authentication node registers with the domain management node of the application domain to which it belongs in the same way to obtain its signature key pair. EA I D and its block number Block_num and the corresponding domain management node DM I D are also uploaded to the alliance blockchain to form a reference record of the authentication information sharing process.

Authentication Phase.
In the authentication phase, the authentication process is divided into intradomain and cross-domain authentication.

Intradomain Authentication.
e edge authentication node authenticates the identity of the registered device. e edge authentication node authenticates the following conditions to allow the device to communicate and access to other devices or to the system: (1) the DM I D exists in the application domain blockchain; (2) the TD I D is registered in the application domain blockchain; (3) the TD I D is in the life cycle of the registration; (4) verify that the registration information is valid; and (5) verify that the TD I D signature is valid. e authentication process within the application domain is described as follows: (1) e device TD sends authentication request mes- (2) e edge authentication nodes check for the presence of the application domain blockchain for DM I D .
(3) If DM ID does not exist in the application domain blockchain, the authentication process ends with an error; otherwise, the edge authentication node obtains the master public key P pub and the public parameter parameters of DM I D and proceeds to the next authentication step.
(4) Checking for the presence of TD I D in the application domain blockchain.
(5) If the given TD I D does not exist in the application domain blockchain, the authentication process stops due to an error. Otherwise, the process will continue to the next step. Because the device authentication process is implemented at the nearest edge authentication node rather than on a cloud-8 Mobile Information Systems  Mobile Information Systems based server, the communication burden and latency are greatly reduced.

Cross-Domain Authentication.
At present, a wide range of IoT applications are widely used and a large amount of IoT data is generated in different applications. Sharing data with other areas can be more useful as data sharing allows for a more rational allocation of resources and saves social costs. In order to achieve secure data sharing, future IoT networks need to implement a secure data sharing mechanism. In this case, if the terminal device needs to access data across application domains, the accessing application domain needs to be authenticated. However, if the previous authentication information block does not exist in the accessed application domain, the device will be required to re-register in the new application domain, which will take a lot of effort and time. erefore, the authentication information should be able to be shared between application domains. In the cross-domain authentication process, we propose the use of sidechaining techniques to share authentication information from different application domains and use SPVs to prove the validity of the authentication information.
(1) Sidechain and Merkel Tree. Sidechain technology [47] was proposed to improve the scalability and extensibility of the blockchain, the basic idea being that digital assets can be transferred from one blockchain to another via sidechain protocols and to reduce the burden on the main chain, thereby increasing the throughput and speed of transactions [44,48]. e flow of data between the main chain and the sidechains can be done using SPV (simple payment verification) proofs. SPV proofs consist of two parts: a list of block headers and a cryptographic proof, such as a Merkle proof, which indicates that a certain output occurred at a certain block in the list [49]. To prove that a certain transaction exists in a block, simply calculate the final Merkle root using the hash of this transaction against the hash of other related transactions and compare it to the root of the block header. If the result of the calculation agrees with the Merkle root of the block header, the transaction is proven to exist in this block. As shown in Figure 5, if we need to verify that a block contains a transaction Tx C and can get the hash value of the Merkle tree root, then we only need the Merkle path consisting of the hash values of N3 and N4 to prove it, as follows: ( As we discussed in Section 3.1, existing blockchain-based authentication schemes suffer from authentication inefficiencies, scalability, and storage overloads. We propose to use a decentralized edge computing model to reduce authentication latency to improve authentication efficiency. To handle scalability and storage problems, we propose to build blockchains of different application domains using sidechain technology. Sidechain, which is an extension of the blockchain, provides a decentralized peer-to-peer platform to maintain stored data while securely transferring authentication information between different application domains. e advantage of A 2 Chain's use of sidechain architecture is the independence of data and smart contracts, the alliance blockchain is primarily responsible for indexing, and the burden of the alliance blockchain does not increase with the number of application domains, avoiding the problem of rapid growth of data in the alliance blockchain. If the index between the alliance blockchain and the application domain blockchain is discarded, the application domain blockchain is an independently running blockchain that can run the domain authentication process independently. Based on the above, the sidechain technology not only improves the overall scalability of the system but also reduces the storage space of each application domain server and improves the search efficiency. (2) e edge authentication node EA B receives the authentication request, and the authentication request is forwarded to the domain management node DM B of the application domain in which it is located.
(3) After the domain management node DM B receives the request, it searches the alliance blockchain containing the corresponding information (includingDM I D ,TD I D , and the corresponding Block_num) through the authentication terminal device ID and its management domain management node ID to judge that the terminal device has been registered. If it is not registered, then stop the authentication; otherwise, continue the authentication process. (10) e edge authentication server forwards the results to the terminal device and attaches a signature that uses the private key. (11) Upon receipt of the authentication result that has been signed by the EA B node, the terminal device will perform the same validation process to verify the signature to confirm the validity of the authentication result.
e authentication process and algorithm are shown in Figure 6 and Algorithm 3, respectively. At the end of the authentication process, the accessed application domain saves the end device's authentication information in the local blockchain so that the end device can later achieve fast authentication and simplify the cross-domain authentication process. (Algorithm 3).

Security Evaluation
In order to ensure the effective operation and service of the proposed authentication scheme, in this section, we analyse the proposed scheme for common security requirements and attacks in IoT applications: (1) Integrity authentication: requests in the proposed system are signed by the requesting party using an identity-based signature algorithm before they are sent, and the final request message contains the data and the signature of the requestor. e receiving party can verify the message with the signature. In addition, authentication-related information is submitted to the alliance blockchain and the application domain blockchain. Due to the features of the blockchain, the data cannot be tampered with once submitted, also ensuring the integrity of the message. (2) Scalability: due to a large number of IoT applications and terminal devices, scalability is one of the important security requirements for IoT applications. In our proposed solution, terminal devices that can effectively authenticate access an identity-based signature scheme, and terminals do not need to store CA certificates, which is more flexible. e combination of application domain blockchain and alliance blockchain makes crossdomain authentication more convenient and business expansion of IoT applications more convenient and secure.
Initialization phase (1) if (DM ID .exist � true) then (2) return error() (3) else (4) creat.block(D ID , DM ID, parameters , P pub , Domian_Chain) (5) creat.block(D ID , DM ID , Block_num, Alliance_Chain) If (Sig.TD ID � valid) then (5) creat.block(TD ID , DM ID , LT, Sig(TD I D‖DM ID ‖LT) (DM SK ) , Domain Chain) (6) creat.block(TD ID , DM ID , Block num, cross authorization, Alliance Chain) (7) reg_sucess (8) end if (9) end if (10) else (11) return error() if (TD ID .exist&LT � true) then (4) if (Hash(Sig.DM ID )&Sig.TD ID � valid) then (5) return auth_sucess (6) end if (7) end if (8) else (9) return error() TD ID .Merkle_Path � getDomainChainPath(TD ID .Block_num) (8) TD ID .Merkle_Root � getDomainChainRoot(TD ID .Block_num) (9) TD ID .Merkle_hash � computeMerkleTree(TD ID _info, Merkle_Path) (10) if (TD ID .Merkle_hash � TD ID .Merkle_Root) then (11) if (Sig.TD ID )&cross_authorization � valid) then (12) return auth_sucess (13) end if (14) end if (15)  (3) Non-repudiation authentication: requests require a signature from the sender, and the private key used for the signature is generated by the sender's identifier and is kept by the sender. erefore, the sender cannot repudiate the authentication request it has made. (4) Authentication: for the terminal device that is going to access the network, it will first be registered in the system. e registration information will remain in the blockchain, and during the authentication process, the smart contract will check its legitimacy to allow the device to access the network. (5) Mutual authentication: first, in our scheme, we assume that all domain management nodes and edge authentication nodes are trustworthy; if there are malicious nodes disguised as authentication nodes to perform phishing attacks on terminal devices, in our scheme, we require the authentication nodes to sign the authentication results, and the terminal devices can identify whether the authentication nodes are trustworthy and the validity of the authentication results by verifying the signatures. (6) Sybil attack: in our proposed scheme, each endpoint device has a unique TD ID in the network and is associated with its registered application domain D ID and domain management node DM ID during the registration process, and each communication is preceded by endpoint authentication. Authentication takes place on the application domain blockchain and the federation blockchain. It is not possible for an attacker to forge legitimate nodes in the network to communicate with other nodes. (7) Spoofing attack: because each communication must be authenticated and its signature must be verified each time to prove its unique identity, an attacker cannot fake the identity of another node for an attack. (8) Message replay attack: in our scheme, authentication requests need to be signed with a timestamped token attached to them. A request with invalid signature validation will be rejected by the system. (9) Denial of service attack: authentication servers are scattered around the edge of the network, and attackers cannot expend significant resources on denial of service attacks against all authentication nodes. Even if one or some of the nodes fail, the remaining nodes can still work without affecting the normal operation of the system.
rough the above analysis, we compare it with existing blockchain-based IoT authentication solutions and get the results as shown in Table 2. Our proposed solution is more comprehensive in terms of security. e blockchain platform we have chosen for the proposed system is Hyperledger Fabric [51]. Hyperledger Fabric provides a scalable and extensible architecture that provides the basis for developing blockchain applications with a modular architecture. Unlike public blockchains, the Fabric platform is license-based, meaning that the participants in the blockchain network are not completely trustless with each other, which ensures the trustworthiness of the nodes. Smart contracts in Fabric become chain codes, and the writing of chain codes in Fabric can be done using the Written in a common programming language (e.g., Go, Node.js, and Java) rather than being restricted to domainspecific languages (domain-specific language, DSL), and Fabric does not require any transaction fees to perform operations such as chain coding or querying blockchain information. For authentication services, we use remote authentication dial-in user service (RADIUS) [52] to build the authentication servicer, which is often used to provide AAA (authenticate, authority, and audit) services. We chose the open source project, YH-RADIUS [53]. is project implements an extensible development framework for RADIUS.

Computing Consumption.
Each entity is involved in different cryptographic operations during the system operation. We summarize the cryptographic operations involved in the operation of the system, as shown in Table 3 (in statistics, the authorization issuance and verification of the cross-domain authentication process is not available yet). Also, Table 4 shows the computational burden of the different components of the system during its operation. It should be noted that operations such as hashing, integer addition, and multiplication are not taken into account, as they take very little time in the tests.  Table 5 shows the computational overhead of the different components of the test in different processes. From the computational overhead, it can be seen that the main overhead of our proposed system lies in the initialization of the domain management nodes and the registration process of the end devices, which do not need to be performed in the authentication. e results show that common smart IoT devices can bear the computational burden of the system. In addition, the bilinear pair computation g � e(P 1 , P pub ) in the used SM9 signature algorithm can be stored as a constant in advance in the end devices during the signature process to further reduce the computational burden.
To further demonstrate the advantage of our proposed system in terms of computational overhead, we compare it with existing authentication schemes ES 3 A [25], CPAL [27], LCCH [54], and E-AUA [55]. We first compared the overhead on the user side, as shown in Figure 7(a). It is clear that our proposed scheme takes less time to implement on the user side than the other schemes, as shown in Figure 7(b). We compared the computational overhead on the service side, and our proposed scheme also outperforms the other schemes.
In order to assess the time cost of the relevant operations on the blockchain, we used the blockchain testing tool Hyperledger Caliper [56] to test each type of operation 10,000 times, with run times as shown in Table 6. e time cost of both the registration and the transaction process is about 200 ms, which may seem high, but it is acceptable. erefore, registration and transactions do not happen frequently, but only when new devices are registered and device authentication information is changed. It takes about 10 milliseconds to look up the authentication information on the blockchain. In the authentication process, even taking into account the time spent querying the blockchain, the time spent is far less compared to other schemes.
We further counted the number of computational operations included in each scheme, as shown in Table 7. It can be seen from the table that ES 3 A [25], CPAL [27], and LCCH [54] are the three schemes with more complex cryptographic operations. E-AUA [55] and our proposed scheme are simpler in terms of cryptographic operations compared to the other three schemes, thus achieving a better performance.

Communication Consumption.
In this section, we analyse the communication overhead of the proposed scheme. e end device sends 192 bytes signed authentication request to the edge authentication node. In the intra-application domain authentication process, the edge authentication node obtains the relevant authentication information directly from the local blockchain to verify the signature and authenticate the end device. In the crossdomain authentication process, the edge authentication node forwards the request to the domain management node after receiving the authentication request. e domain management node obtains 196 bytes of authentication information in a two-way Peg protocol. At the end of the authentication, the 32-byte authentication result is returned to the interrupting device. erefore, the communication overhead of our scheme during intradomain and crossdomain authentication is 228 bytes and 616 bytes, respectively. e number of interactions of our proposed scheme is significantly less than other schemes in the authentication process, and there is no certificate exchange process.
erefore, compared with ES3A, LCCH, CPAL, and E-AUA whose communication cost is 1336 bytes, 2016 bytes, 1232 bytes, and 652 bytes, respectively, the communication cost of our scheme is much smaller and more efficient. In Figure 8, we list the cost comparison between the above schemes and our scheme, which shows more visually the advantages of our scheme in communication overhead performance.

Storage Consumption.
Different from existing blockchain-based authentication schemes, in our scheme the alliance blockchain stores only the index information of the IoT devices, so only simplified blocks of information need to be stored additionally in the domain management nodes. In contrast, in the existing scheme, the entire blockchain is updated by all nodes each time a new device is registered.
In our scheme, it is assumed that there are 10 application domains, each containing 10,000 IoT devices. As described in the scheme, the authentication information of the blockchain storage device in the application domain is about 8 bytes in the federation blockchain storage device ID and block number. e block header is 80 bytes, and the authentication information is about 192 bytes. For the traditional blockchain-based case and our proposed scheme, the storage overhead is about 26.32 MB and 5.95 MB, respectively. Our proposed scheme is only 22.6% of the traditional blockchain-based scheme, which greatly reduces the available storage space.

Discussion
A 2 Chain builds a decentralized IoT authentication scheme by introducing blockchain-sidechain technology with edge computing technology. In this scheme, we utilize the edge computing model to reduce authentication latency. However, in IoT applications, there are some scenarios where the terminals are dense. In this case, the authentication service needs to implement load balancing and congestion control for authentication requests. is is one of our future research directions.
In addition, in our scheme, we apply an identity-based signature algorithm SM9, and the keys of the terminal
In our scheme, we assume that the domain management node is honest and trustworthy. In practice, there may be a malicious domain management node or a domain management node that is controlled by an adversary. In this case, it may lead to the leakage of the device's private key and jeopardize the security of the IoT application. In future work, we need to investigate the signature algorithm in case the key generation center is not fully trustworthy.

Conclusions
In this paper, we propose an application domain blockchainalliance blockchain combined decentralized IoT authentication scheme called A 2 Chain, which enables a secure authentication information sharing process. Simulation results show that the scheme can significantly shorten the authentication time and reduce the communication cost and storage space compared to existing IoT authentication methods. In addition, we deploy the authentication server at the edge of the network through edge computing technology, which greatly reduces the authentication time and network latency.

Data Availability
All relevant data are included within the article.

Conflicts of Interest
e authors declare that there are no conflicts of interest regarding the publication of this paper. Mobile Information Systems 17