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

Authors: Xudong Jia; Ning Hu; Shi Yin; Yan Zhao; Chi Zhang; Xinda Cheng
Journal: Mobile Information Systems
 (2020)

---

## Abstract

The fifth-generation mobile 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. The decentralized authentication model can effectively solve the above problems. This article proposes a decentralized IoT authentication scheme called A2 Chain. First, A2 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, A2 Chain uses blockchain, and sidechain technologies are used to securely share the identity verification information of IoT devices. Additionally, A2 Chain replaces public key infrastructure (PKI) algorithm with identity-based cryptography (IBC) algorithm to eliminate the management overhead caused by centralized authentication model.


---

## Body

## 1. 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–3]. As defined by 3GPP, 5G supports access to at least 106 devices per square kilometre [4]. As 5G powers IoT, it also brings huge challenges to IoT security [5]. The 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–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 infrastructure-based 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. There 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–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; The 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 A2 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 IoT authentication structure based on application domain-alliance chains is proposed to deploy blockchains in different application domains as well as between application domains, respectively. The 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. The 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. This 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.The remainder of this paper is organized as follows: an overview of the related work is given in Section2. 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.


## 2. Related Work

### 2.1. 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 Things (IIoT) device authentication mechanism, but it stores the authentication data on a local server. Therefore, 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.


### 2.2. 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. The authentication information of all nodes was stored on the public blockchain at that time, which caused a certain storage burden.


## 2.1. 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 Things (IIoT) device authentication mechanism, but it stores the authentication data on a local server. Therefore, 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.


## 2.2. 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. The authentication information of all nodes was stored on the public blockchain at that time, which caused a certain storage burden.


## 3. Proposed Scheme

In this part, we design an application domain-alliance chain IoT authentication model called A2 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.


### 3.1. 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 Things applications [2, 3]. These massively connected terminal devices simultaneously initiate authentication requests, which will have a serious impact on the authentication server [9–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].Figure 1
(a) Centralized and (b) decentralized authentication models.
(a)(b)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. These 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 blockchain-based 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. This 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–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. Therefore, 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. The 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 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.


### 3.2. 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. The assumptions are as follows:Table 1
OID description.
FieldMandatory (M)/Option (O)InterpretationDomain IDMRegistered domain IDCategory IDOCategories of entities in the security domain, such as devices and serversEntity IDMThe unique number assigned to the entity(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)
The system initialization and key distribution process is secure


### 3.3. 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 Figure2 according to the different terminal device functions or usage scenarios. The 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]. Through distributed edge authentication nodes, we have realized the decentralization of the authentication structure.(3)
Terminal device (TD): This consists mainly of a large number of IoT terminal devices deployed in various application scenarios for sensing, serving, and communicating. These devices can detect or generate data for transmission to different IoT applications. Authentication is required to access the network or to access data.Figure 2
System architecture of A2 Chain.


#### 3.3.1. Types of Authentication

The 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 Figure2. 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 Figure2. 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.


#### 3.3.2. A2 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 A2 Chain authentication model, which consists of two main parts: the application domain blockchain and the alliance blockchain.(1)
Alliance blockchain: all domain management nodes are connected to the alliance blockchain as nodes of the alliance blockchain. The alliance blockchain is connected to multiple application domain blockchains via domain management nodes for secure management and sharing of authentication information between different application domains.(2)
Application domain blockchain: application domain blockchain consists of domain management nodes and edge authentication nodes according to the application domain and location, which avoids the consumption of computation and storage irrelevant transactions and reduces the delay caused by transmission. The application domain blockchain is used to store the authentication information of end devices within the domain.In addition, through the noncentralized nature of the blockchain, A2 Chain does not require a trusted third-party entity and achieves a good decentralized authentication.


### 3.4. 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 third-party entities to issue certificates, it satisfies the need for decentralized authentication. Moreover, the use of identity-based 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.The SM9 signature algorithm consists of five steps: system parameter generation, master key generation, device key generation, signature generation, and signature verification. The 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. The 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 identifiercid; the parameters q of the base field Fq of the elliptic curve; the parameters a andb of the elliptic curve equation; the prime factor N of the curve order and the residual factor cf relative toN; the embedding degree k of the curve EFq with respect to N; the generator P1 of the N order cyclic subgroup G1 of EFqd1, where d1 divides k; the generator P2 of the N-order cyclic subgroup G2 of EFqd2, where d2 divides k; identifier eid for bilinear pair e, bilinear pair e:G1×G2⟶GT, the order of GT is N; optionally, the homomorphic mapping Ψ from G2 to G1.System master key generation (MKGen): the KGS server generates a random numbers∈1,N−1 as the system’s master private key and computes the element Ppub=sP2 in G2 as the system’s master public key pair s,Ppub.Device signature key generation (DKGen): KGS selects and exposes a byte to represent the private key generation function identifierhid. Assuming the device’s identity is ID, to generate the device’s private key d, KGS first computes t1=H1ID‖hid,N+s on the finite domain FN. If t1=0, then it is necessary to regenerate the master private key, compute and expose the master public key, and update the existing device’s private key; otherwise compute t2=s⋅t1−1, and then calculate d=t2P1. d is the user’s signed private key.Signature generation (SigGen): assuming the message to be signed is a bit stringM, 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:Algorithm 1: Signature generation (SigGen) algorithm.
Input: message M, Ppub, and parametersm private key dOutput: signature (h, S)(1)
Compute the elementg=eP1,Ppub in group GT;(2)
Generate a random numberr∈1,N−1;(3)
Compute the element =gr in the group GT, converting the data type of ω to a bit string;(4)
Compute the integerh=H2M‖ω,N;(5)
Compute the integerL=r−h mod N; if L = 0, then return 2;(6)
Compute the elementS=Ld in group G1;(7)
Convert the data typesh and S to byte strings and the signature of the message M is (h, S).Algorithm 2: Signature verification (SigVer) algorithm.
Input: message M, Ppub, parameters, ID, and signature (h, S)Output: verification result—succeed or fail.(1)
Convert the data type ofh to an integer, check whether h∈1,N−1 holds, and if it does not, the verification fails;(2)
Convert the data type ofS to a point on an elliptic curve, and check whether S∈G1 holds, and if not, the verification fails;(3)
Compute the elementg=eP1,Ppub in the group GT;(4)
Compute the elementt=gh in the group GT;(5)
Compute the integerh1=H1ID‖hid,N;(6)
Compute the elementP=h1P2+Ppub in the group G2;(7)
Compute the elementu=eS,P in the group GT;(8)
Compute the elementω=u⋅t in the group GT, converting the data type of ω to a bit string;(9)
Compute the integerh2=H2M‖ω,N, check whether h2 = h is valid, if so the verification passes; otherwise the verification fails.


## 3.1. 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 Things applications [2, 3]. These massively connected terminal devices simultaneously initiate authentication requests, which will have a serious impact on the authentication server [9–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].Figure 1
(a) Centralized and (b) decentralized authentication models.
(a)(b)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. These 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 blockchain-based 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. This 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–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. Therefore, 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. The 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 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.


## 3.2. 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. The assumptions are as follows:Table 1
OID description.
FieldMandatory (M)/Option (O)InterpretationDomain IDMRegistered domain IDCategory IDOCategories of entities in the security domain, such as devices and serversEntity IDMThe unique number assigned to the entity(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)
The system initialization and key distribution process is secure


## 3.3. 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 Figure2 according to the different terminal device functions or usage scenarios. The 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]. Through distributed edge authentication nodes, we have realized the decentralization of the authentication structure.(3)
Terminal device (TD): This consists mainly of a large number of IoT terminal devices deployed in various application scenarios for sensing, serving, and communicating. These devices can detect or generate data for transmission to different IoT applications. Authentication is required to access the network or to access data.Figure 2
System architecture of A2 Chain.


### 3.3.1. Types of Authentication

The 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 Figure2. 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 Figure2. 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.


### 3.3.2. A2 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 A2 Chain authentication model, which consists of two main parts: the application domain blockchain and the alliance blockchain.(1)
Alliance blockchain: all domain management nodes are connected to the alliance blockchain as nodes of the alliance blockchain. The alliance blockchain is connected to multiple application domain blockchains via domain management nodes for secure management and sharing of authentication information between different application domains.(2)
Application domain blockchain: application domain blockchain consists of domain management nodes and edge authentication nodes according to the application domain and location, which avoids the consumption of computation and storage irrelevant transactions and reduces the delay caused by transmission. The application domain blockchain is used to store the authentication information of end devices within the domain.In addition, through the noncentralized nature of the blockchain, A2 Chain does not require a trusted third-party entity and achieves a good decentralized authentication.


## 3.3.1. Types of Authentication

The 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 Figure2. 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 Figure2. 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.


## 3.3.2. A2 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 A2 Chain authentication model, which consists of two main parts: the application domain blockchain and the alliance blockchain.(1)
Alliance blockchain: all domain management nodes are connected to the alliance blockchain as nodes of the alliance blockchain. The alliance blockchain is connected to multiple application domain blockchains via domain management nodes for secure management and sharing of authentication information between different application domains.(2)
Application domain blockchain: application domain blockchain consists of domain management nodes and edge authentication nodes according to the application domain and location, which avoids the consumption of computation and storage irrelevant transactions and reduces the delay caused by transmission. The application domain blockchain is used to store the authentication information of end devices within the domain.In addition, through the noncentralized nature of the blockchain, A2 Chain does not require a trusted third-party entity and achieves a good decentralized authentication.


## 3.4. 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 third-party entities to issue certificates, it satisfies the need for decentralized authentication. Moreover, the use of identity-based 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.The SM9 signature algorithm consists of five steps: system parameter generation, master key generation, device key generation, signature generation, and signature verification. The 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. The 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 identifiercid; the parameters q of the base field Fq of the elliptic curve; the parameters a andb of the elliptic curve equation; the prime factor N of the curve order and the residual factor cf relative toN; the embedding degree k of the curve EFq with respect to N; the generator P1 of the N order cyclic subgroup G1 of EFqd1, where d1 divides k; the generator P2 of the N-order cyclic subgroup G2 of EFqd2, where d2 divides k; identifier eid for bilinear pair e, bilinear pair e:G1×G2⟶GT, the order of GT is N; optionally, the homomorphic mapping Ψ from G2 to G1.System master key generation (MKGen): the KGS server generates a random numbers∈1,N−1 as the system’s master private key and computes the element Ppub=sP2 in G2 as the system’s master public key pair s,Ppub.Device signature key generation (DKGen): KGS selects and exposes a byte to represent the private key generation function identifierhid. Assuming the device’s identity is ID, to generate the device’s private key d, KGS first computes t1=H1ID‖hid,N+s on the finite domain FN. If t1=0, then it is necessary to regenerate the master private key, compute and expose the master public key, and update the existing device’s private key; otherwise compute t2=s⋅t1−1, and then calculate d=t2P1. d is the user’s signed private key.Signature generation (SigGen): assuming the message to be signed is a bit stringM, 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:Algorithm 1: Signature generation (SigGen) algorithm.
Input: message M, Ppub, and parametersm private key dOutput: signature (h, S)(1)
Compute the elementg=eP1,Ppub in group GT;(2)
Generate a random numberr∈1,N−1;(3)
Compute the element =gr in the group GT, converting the data type of ω to a bit string;(4)
Compute the integerh=H2M‖ω,N;(5)
Compute the integerL=r−h mod N; if L = 0, then return 2;(6)
Compute the elementS=Ld in group G1;(7)
Convert the data typesh and S to byte strings and the signature of the message M is (h, S).Algorithm 2: Signature verification (SigVer) algorithm.
Input: message M, Ppub, parameters, ID, and signature (h, S)Output: verification result—succeed or fail.(1)
Convert the data type ofh to an integer, check whether h∈1,N−1 holds, and if it does not, the verification fails;(2)
Convert the data type ofS to a point on an elliptic curve, and check whether S∈G1 holds, and if not, the verification fails;(3)
Compute the elementg=eP1,Ppub in the group GT;(4)
Compute the elementt=gh in the group GT;(5)
Compute the integerh1=H1ID‖hid,N;(6)
Compute the elementP=h1P2+Ppub in the group G2;(7)
Compute the elementu=eS,P in the group GT;(8)
Compute the elementω=u⋅t in the group GT, converting the data type of ω to a bit string;(9)
Compute the integerh2=H2M‖ω,N, check whether h2 = h is valid, if so the verification passes; otherwise the verification fails.


## 4. Authentication Mechanism

In this section, we will present the working of the proposed A2 Chain. The system consists of three main phases: the initialization phase, the registration phase, and the device authentication phase.


### 4.1. Initialization Phase

In the initialization phase, each domain management node uses the SPG algorithm to generate public parameter groupparameters and calls MKGen and DKGen to generate master key pair s,Ppub and asymmetric key pairs DMSK,DMID of the domain management node, in which DMSK demonstrates the signed private key of the domain management node and DMID represents the identity of the domain management node and the public key corresponding to DMSK.After generating public parameters and keys, the domain management node broadcasts them in the application domain; creates blocks with the identity IDDMID, 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. The relevant steps are as follows:(1)
First, the domain management node generates the public parameter groupparameters, the master key pair s,Ppub, and the asymmetric key pair DMSK,DMID(2)
The domain management node creates a transactionT1=DID,DMID,parameters,Ppub in the application domain blockchain and checks whether there is a DMIDin the blockchain to verify the transaction, where DID indicates the application domain ID(3)
IfDMID already exists in the application domain blockchain, the transaction validation fails and an error notification is returned to the domain management node(4)
If theDMID does not exist in the application domain blockchain, the transaction will be allowed and a new block will be created for it(5)
When the domain management node initialization is successful, the domain management nodeDMID, domain ID, and its block number Block_num are uploaded to the alliance blockchain to form a reference record of the authentication information sharing process(6)
The domain management node calls the DKGen algorithm to generate the device’s signature private keyTDSK according to the device’s identification TDID, and the domain management node calls the SigGen algorithm to sign the TDSK and generate the signature SigTDSK to send the device’s signature private key TDSK with the signature SigTDSK to the device TDIDin a secure manner


### 4.2. 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.The main steps in the registration phase are as follows:(1)
The device sends the registration request messageM1=TDID‖DMID‖RequestReg‖LT‖TS‖SigGenTDID‖DMID‖RequestReg‖LT‖TSTDSK to the domain management node; M1 includes the identifier TDID, the domain management node DMID, the registration request ReqestReg, life time (LT), timestamp (TS), and the corresponding signature(2)
Upon receipt of the messageM1, the domain management node verifies that the received DMID is in this application domain and that the TDID has not been registered(3)
If theDMID does not belong to the application domain or a device with a TDID that has been registered, registration will not be allowed and the registration process will be terminated(4)
If theDMID belongs to the application domain and the TDID 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)
The domain management node creates a transactionT2=TDIDDMIDLT‖SigGenUIDDMIDLTDMSK in the application domain blockchain, and the block structure is shown in Figure 3(7)
When the new device registration is successful, the deviceTDID and its block number Block_num will be uploaded to the alliance blockchain along with the corresponding domain management node DMID to form a reference record of the authentication information sharing process, as shown in Figure 4Figure 3
Structure and content of the application domain blockchain.Figure 4
Store indexes in the alliance blockchain.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.EAID and its block number Block_num and the corresponding domain management node DMID are also uploaded to the alliance blockchain to form a reference record of the authentication information sharing process.


### 4.3. Authentication Phase

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


#### 4.3.1. Intradomain Authentication

The edge authentication node authenticates the identity of the registered device. The edge authentication node authenticates the following conditions to allow the device to communicate and access to other devices or to the system: (1) theDMIDexists in the application domain blockchain; (2) the TDID is registered in the application domain blockchain; (3) the TDID is in the life cycle of the registration; (4) verify that the registration information is valid; and (5) verify that the TDID signature is valid.The authentication process within the application domain is described as follows:(1)
The device TD sends authentication request messageM2=RequestAuth_local‖DID‖DMID‖TDID‖TS‖HashSigTDID‖DMID‖LTDMSK‖SigRequestAuth_local‖DID‖DMID‖TDID‖TSTDSK, RequestAuth_local on behalf of the application domain authentication request, DID on behalf of the application domain to which the terminal device belongs,DMID indicates the domain management node identity associated with the device, TDIDindicates the identity of the device, TS for the timestamp, and Sig indicates the Signature for TDID.(2)
The edge authentication nodes check for the presence of the application domain blockchain forDMID.(3)
IfDMID 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 Ppub and the public parameter parameters of DMID and proceeds to the next authentication step.(4)
Checking for the presence ofTDID in the application domain blockchain.(5)
If the givenTDID 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.(6)
Check thatTDID is within the life cycle of the registration.(7)
If not in the life cycle, stop the authentication; otherwise continue to the next step.(8)
Check that the hash of the‖DMID signature of the registration information is consistent.(9)
Verifying the validity of the signatureSigRequestAuth_local‖DID‖DMID‖TDID‖TSTDSK.(10)
If the signature validation is successful, the authentication is successful; if the signature validation fails, the authentication fails.(11)
The edge authentication node returns the authentication results to the device and signs the results using the private key.(12)
The terminal device confirms the validity of the result by verifying the signature of the authentication result.Because the device authentication process is implemented at the nearest edge authentication node rather than on a cloud-based server, the communication burden and latency are greatly reduced.


#### 4.3.2. 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. Therefore, 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]. The 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: (1)
First calculate the hash value of the transaction TX C, N2 = Hash (TX C).(2)
The hash value of the parent node is then obtained by summing the hash values of N2 and N3 and calculating the hash: N5 = Hash (N2 + N3).(3)
As above, calculate the hash value of the root node from the hash values of N4 and N5: root = hash (N4 + N5)(4)
Finally compare the hash value from the previous calculation with the root hash value of Merkle Tree in the block header; if it is the same then, the transaction TX C exists; otherwise it does not.Figure 5
Merkle tree Path.As we discussed inSection 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. The advantage of A2 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) Cross-Domain Authentication Process. The cross-domain authentication process is described below:(1)
The device TD sends an authentication request messageM3=RequestAuth_cross‖DID‖DMID‖TDID‖TS‖parameters‖Ppub‖SigTDID‖DMID‖LTDMSK‖SigRequestAuth_cross‖DID‖DMID‖TDID‖TSTDSK to the edge authentication node EAB to access the application domain B. The DID terminal device belongs to the application domain, RequestAuth_cross is a cross-domain authentication request, DMID indicates the domain management node identity associated with the device, TDID indicates the identity of the device, TS is a timestamp, parameters,Ppub indicates the public parameters required for its signature, and Sig indicates the signature of TDID.(2)
The edge authentication node EAB receives the authentication request, and the authentication request is forwarded to the domain management node DMB of the application domain in which it is located.(3)
After the domain management node DMB receives the request, it searches the alliance blockchain containing the corresponding information (includingDMID,TDID, 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.(4)
Get theMerkle_Path of DMID andTDID in the blockchain of the application domain to which it belongs via Block_num.(5)
Verify the authentication information provided by the device. Compute the hash value of the authentication information provided by the end device and the hash value of each node on itsMerkle_Path, and compute the hash Merkle_hash of the Merkle root of the block in which it is located.(6)
Check that the computedMerkle_hash matches the Merkle_Root of the block header of the block in which it is located.(7)
Verify that the signatureSigRequestAuth_cross‖DID‖DMID‖TDID‖TSTDSK is valid.(8)
Get terminal device authorization information to verify that the signature is valid.(9)
Return authentication results to the edge authentication server.(10)
The 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 EAB node, the terminal device will perform the same validation process to verify the signature to confirm the validity of the authentication result.The authentication process and algorithm are shown in Figure6 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).Figure 6
Overview of the authentication process. The device TD belongs to application domain A with intradomain authentication and cross-domain authentication, respectively.Algorithm 3: Authentication mechanism.
Initialization phase(1)
if (DMID.exist = true) then(2)
return error()(3)
else(4)
creat.block(DID, DMID,parameters, Ppub, Domian_Chain)(5)
creat.block(DID, DMID, Block_num, Alliance_Chain)(6)
end ifRegistration phase(1)
if (DID.exist = true) then(2)
get(parameters, Ppub)(3)
If (TDID.exist = false) then(4)
If (Sig.TDID = valid) then(5)
creat.blockTDID,DMID,LT,SigTDIDDMIDLTDMSK,Domain_Chain(6)
creat.blockTDID,DMID,Block_num,cross_authorization,Alliance_Chain(7)
reg_sucess(8)
end if(9)
end if(10)
else(11)
return error()(12)
end ifIntradomain authentication(1)
if (DMID.exist = true) then(2)
get(parameters, Ppub)(3)
if (TDID.exist&LT = true) then(4)
if (Hash(Sig.DMID)&Sig.TDID = valid) then(5)
return auth_sucess(6)
end if(7)
end if(8)
else(9)
return error()(10)
end ifCross-domain authentication(1)
if (DMID.exist&TDID.exit = true) then(2)
get(parameters, Ppub)(3)
DMID.Merkle_Path = getDomainChainPath(DMID.Block_num)(4)
DMID.Merkle_Root = getDomainChainPath(DMID.Block_num)(5)
DMID.Merkle_hash = computeMerkleTree(DMID_info, Merkle_Path)(6)
if (DMID.Merkle_hash = DMID.Merkle_Root) then(7)
TDID.Merkle_Path = getDomainChainPath(TDID.Block_num)(8)
TDID.Merkle_Root = getDomainChainRoot(TDID.Block_num)(9)
TDID.Merkle_hash = computeMerkleTree(TDID_info, Merkle_Path)(10)
if (TDID.Merkle_hash = TDID.Merkle_Root) then(11)
if (Sig.TDID)&cross_authorization = valid) then(12)
return auth_sucess(13)
end if(14)
end if(15)
end if(16)
else(17)
return error()(18)
end if


## 4.1. Initialization Phase

In the initialization phase, each domain management node uses the SPG algorithm to generate public parameter groupparameters and calls MKGen and DKGen to generate master key pair s,Ppub and asymmetric key pairs DMSK,DMID of the domain management node, in which DMSK demonstrates the signed private key of the domain management node and DMID represents the identity of the domain management node and the public key corresponding to DMSK.After generating public parameters and keys, the domain management node broadcasts them in the application domain; creates blocks with the identity IDDMID, 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. The relevant steps are as follows:(1)
First, the domain management node generates the public parameter groupparameters, the master key pair s,Ppub, and the asymmetric key pair DMSK,DMID(2)
The domain management node creates a transactionT1=DID,DMID,parameters,Ppub in the application domain blockchain and checks whether there is a DMIDin the blockchain to verify the transaction, where DID indicates the application domain ID(3)
IfDMID already exists in the application domain blockchain, the transaction validation fails and an error notification is returned to the domain management node(4)
If theDMID does not exist in the application domain blockchain, the transaction will be allowed and a new block will be created for it(5)
When the domain management node initialization is successful, the domain management nodeDMID, domain ID, and its block number Block_num are uploaded to the alliance blockchain to form a reference record of the authentication information sharing process(6)
The domain management node calls the DKGen algorithm to generate the device’s signature private keyTDSK according to the device’s identification TDID, and the domain management node calls the SigGen algorithm to sign the TDSK and generate the signature SigTDSK to send the device’s signature private key TDSK with the signature SigTDSK to the device TDIDin a secure manner


## 4.2. 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.The main steps in the registration phase are as follows:(1)
The device sends the registration request messageM1=TDID‖DMID‖RequestReg‖LT‖TS‖SigGenTDID‖DMID‖RequestReg‖LT‖TSTDSK to the domain management node; M1 includes the identifier TDID, the domain management node DMID, the registration request ReqestReg, life time (LT), timestamp (TS), and the corresponding signature(2)
Upon receipt of the messageM1, the domain management node verifies that the received DMID is in this application domain and that the TDID has not been registered(3)
If theDMID does not belong to the application domain or a device with a TDID that has been registered, registration will not be allowed and the registration process will be terminated(4)
If theDMID belongs to the application domain and the TDID 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)
The domain management node creates a transactionT2=TDIDDMIDLT‖SigGenUIDDMIDLTDMSK in the application domain blockchain, and the block structure is shown in Figure 3(7)
When the new device registration is successful, the deviceTDID and its block number Block_num will be uploaded to the alliance blockchain along with the corresponding domain management node DMID to form a reference record of the authentication information sharing process, as shown in Figure 4Figure 3
Structure and content of the application domain blockchain.Figure 4
Store indexes in the alliance blockchain.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.EAID and its block number Block_num and the corresponding domain management node DMID are also uploaded to the alliance blockchain to form a reference record of the authentication information sharing process.


## 4.3. Authentication Phase

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


### 4.3.1. Intradomain Authentication

The edge authentication node authenticates the identity of the registered device. The edge authentication node authenticates the following conditions to allow the device to communicate and access to other devices or to the system: (1) theDMIDexists in the application domain blockchain; (2) the TDID is registered in the application domain blockchain; (3) the TDID is in the life cycle of the registration; (4) verify that the registration information is valid; and (5) verify that the TDID signature is valid.The authentication process within the application domain is described as follows:(1)
The device TD sends authentication request messageM2=RequestAuth_local‖DID‖DMID‖TDID‖TS‖HashSigTDID‖DMID‖LTDMSK‖SigRequestAuth_local‖DID‖DMID‖TDID‖TSTDSK, RequestAuth_local on behalf of the application domain authentication request, DID on behalf of the application domain to which the terminal device belongs,DMID indicates the domain management node identity associated with the device, TDIDindicates the identity of the device, TS for the timestamp, and Sig indicates the Signature for TDID.(2)
The edge authentication nodes check for the presence of the application domain blockchain forDMID.(3)
IfDMID 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 Ppub and the public parameter parameters of DMID and proceeds to the next authentication step.(4)
Checking for the presence ofTDID in the application domain blockchain.(5)
If the givenTDID 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.(6)
Check thatTDID is within the life cycle of the registration.(7)
If not in the life cycle, stop the authentication; otherwise continue to the next step.(8)
Check that the hash of the‖DMID signature of the registration information is consistent.(9)
Verifying the validity of the signatureSigRequestAuth_local‖DID‖DMID‖TDID‖TSTDSK.(10)
If the signature validation is successful, the authentication is successful; if the signature validation fails, the authentication fails.(11)
The edge authentication node returns the authentication results to the device and signs the results using the private key.(12)
The terminal device confirms the validity of the result by verifying the signature of the authentication result.Because the device authentication process is implemented at the nearest edge authentication node rather than on a cloud-based server, the communication burden and latency are greatly reduced.


### 4.3.2. 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. Therefore, 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]. The 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: (1)
First calculate the hash value of the transaction TX C, N2 = Hash (TX C).(2)
The hash value of the parent node is then obtained by summing the hash values of N2 and N3 and calculating the hash: N5 = Hash (N2 + N3).(3)
As above, calculate the hash value of the root node from the hash values of N4 and N5: root = hash (N4 + N5)(4)
Finally compare the hash value from the previous calculation with the root hash value of Merkle Tree in the block header; if it is the same then, the transaction TX C exists; otherwise it does not.Figure 5
Merkle tree Path.As we discussed inSection 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. The advantage of A2 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) Cross-Domain Authentication Process. The cross-domain authentication process is described below:(1)
The device TD sends an authentication request messageM3=RequestAuth_cross‖DID‖DMID‖TDID‖TS‖parameters‖Ppub‖SigTDID‖DMID‖LTDMSK‖SigRequestAuth_cross‖DID‖DMID‖TDID‖TSTDSK to the edge authentication node EAB to access the application domain B. The DID terminal device belongs to the application domain, RequestAuth_cross is a cross-domain authentication request, DMID indicates the domain management node identity associated with the device, TDID indicates the identity of the device, TS is a timestamp, parameters,Ppub indicates the public parameters required for its signature, and Sig indicates the signature of TDID.(2)
The edge authentication node EAB receives the authentication request, and the authentication request is forwarded to the domain management node DMB of the application domain in which it is located.(3)
After the domain management node DMB receives the request, it searches the alliance blockchain containing the corresponding information (includingDMID,TDID, 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.(4)
Get theMerkle_Path of DMID andTDID in the blockchain of the application domain to which it belongs via Block_num.(5)
Verify the authentication information provided by the device. Compute the hash value of the authentication information provided by the end device and the hash value of each node on itsMerkle_Path, and compute the hash Merkle_hash of the Merkle root of the block in which it is located.(6)
Check that the computedMerkle_hash matches the Merkle_Root of the block header of the block in which it is located.(7)
Verify that the signatureSigRequestAuth_cross‖DID‖DMID‖TDID‖TSTDSK is valid.(8)
Get terminal device authorization information to verify that the signature is valid.(9)
Return authentication results to the edge authentication server.(10)
The 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 EAB node, the terminal device will perform the same validation process to verify the signature to confirm the validity of the authentication result.The authentication process and algorithm are shown in Figure6 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).Figure 6
Overview of the authentication process. The device TD belongs to application domain A with intradomain authentication and cross-domain authentication, respectively.Algorithm 3: Authentication mechanism.
Initialization phase(1)
if (DMID.exist = true) then(2)
return error()(3)
else(4)
creat.block(DID, DMID,parameters, Ppub, Domian_Chain)(5)
creat.block(DID, DMID, Block_num, Alliance_Chain)(6)
end ifRegistration phase(1)
if (DID.exist = true) then(2)
get(parameters, Ppub)(3)
If (TDID.exist = false) then(4)
If (Sig.TDID = valid) then(5)
creat.blockTDID,DMID,LT,SigTDIDDMIDLTDMSK,Domain_Chain(6)
creat.blockTDID,DMID,Block_num,cross_authorization,Alliance_Chain(7)
reg_sucess(8)
end if(9)
end if(10)
else(11)
return error()(12)
end ifIntradomain authentication(1)
if (DMID.exist = true) then(2)
get(parameters, Ppub)(3)
if (TDID.exist&LT = true) then(4)
if (Hash(Sig.DMID)&Sig.TDID = valid) then(5)
return auth_sucess(6)
end if(7)
end if(8)
else(9)
return error()(10)
end ifCross-domain authentication(1)
if (DMID.exist&TDID.exit = true) then(2)
get(parameters, Ppub)(3)
DMID.Merkle_Path = getDomainChainPath(DMID.Block_num)(4)
DMID.Merkle_Root = getDomainChainPath(DMID.Block_num)(5)
DMID.Merkle_hash = computeMerkleTree(DMID_info, Merkle_Path)(6)
if (DMID.Merkle_hash = DMID.Merkle_Root) then(7)
TDID.Merkle_Path = getDomainChainPath(TDID.Block_num)(8)
TDID.Merkle_Root = getDomainChainRoot(TDID.Block_num)(9)
TDID.Merkle_hash = computeMerkleTree(TDID_info, Merkle_Path)(10)
if (TDID.Merkle_hash = TDID.Merkle_Root) then(11)
if (Sig.TDID)&cross_authorization = valid) then(12)
return auth_sucess(13)
end if(14)
end if(15)
end if(16)
else(17)
return error()(18)
end if


## 4.3.1. Intradomain Authentication

The edge authentication node authenticates the identity of the registered device. The edge authentication node authenticates the following conditions to allow the device to communicate and access to other devices or to the system: (1) theDMIDexists in the application domain blockchain; (2) the TDID is registered in the application domain blockchain; (3) the TDID is in the life cycle of the registration; (4) verify that the registration information is valid; and (5) verify that the TDID signature is valid.The authentication process within the application domain is described as follows:(1)
The device TD sends authentication request messageM2=RequestAuth_local‖DID‖DMID‖TDID‖TS‖HashSigTDID‖DMID‖LTDMSK‖SigRequestAuth_local‖DID‖DMID‖TDID‖TSTDSK, RequestAuth_local on behalf of the application domain authentication request, DID on behalf of the application domain to which the terminal device belongs,DMID indicates the domain management node identity associated with the device, TDIDindicates the identity of the device, TS for the timestamp, and Sig indicates the Signature for TDID.(2)
The edge authentication nodes check for the presence of the application domain blockchain forDMID.(3)
IfDMID 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 Ppub and the public parameter parameters of DMID and proceeds to the next authentication step.(4)
Checking for the presence ofTDID in the application domain blockchain.(5)
If the givenTDID 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.(6)
Check thatTDID is within the life cycle of the registration.(7)
If not in the life cycle, stop the authentication; otherwise continue to the next step.(8)
Check that the hash of the‖DMID signature of the registration information is consistent.(9)
Verifying the validity of the signatureSigRequestAuth_local‖DID‖DMID‖TDID‖TSTDSK.(10)
If the signature validation is successful, the authentication is successful; if the signature validation fails, the authentication fails.(11)
The edge authentication node returns the authentication results to the device and signs the results using the private key.(12)
The terminal device confirms the validity of the result by verifying the signature of the authentication result.Because the device authentication process is implemented at the nearest edge authentication node rather than on a cloud-based server, the communication burden and latency are greatly reduced.


## 4.3.2. 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. Therefore, 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]. The 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: (1)
First calculate the hash value of the transaction TX C, N2 = Hash (TX C).(2)
The hash value of the parent node is then obtained by summing the hash values of N2 and N3 and calculating the hash: N5 = Hash (N2 + N3).(3)
As above, calculate the hash value of the root node from the hash values of N4 and N5: root = hash (N4 + N5)(4)
Finally compare the hash value from the previous calculation with the root hash value of Merkle Tree in the block header; if it is the same then, the transaction TX C exists; otherwise it does not.Figure 5
Merkle tree Path.As we discussed inSection 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. The advantage of A2 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) Cross-Domain Authentication Process. The cross-domain authentication process is described below:(1)
The device TD sends an authentication request messageM3=RequestAuth_cross‖DID‖DMID‖TDID‖TS‖parameters‖Ppub‖SigTDID‖DMID‖LTDMSK‖SigRequestAuth_cross‖DID‖DMID‖TDID‖TSTDSK to the edge authentication node EAB to access the application domain B. The DID terminal device belongs to the application domain, RequestAuth_cross is a cross-domain authentication request, DMID indicates the domain management node identity associated with the device, TDID indicates the identity of the device, TS is a timestamp, parameters,Ppub indicates the public parameters required for its signature, and Sig indicates the signature of TDID.(2)
The edge authentication node EAB receives the authentication request, and the authentication request is forwarded to the domain management node DMB of the application domain in which it is located.(3)
After the domain management node DMB receives the request, it searches the alliance blockchain containing the corresponding information (includingDMID,TDID, 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.(4)
Get theMerkle_Path of DMID andTDID in the blockchain of the application domain to which it belongs via Block_num.(5)
Verify the authentication information provided by the device. Compute the hash value of the authentication information provided by the end device and the hash value of each node on itsMerkle_Path, and compute the hash Merkle_hash of the Merkle root of the block in which it is located.(6)
Check that the computedMerkle_hash matches the Merkle_Root of the block header of the block in which it is located.(7)
Verify that the signatureSigRequestAuth_cross‖DID‖DMID‖TDID‖TSTDSK is valid.(8)
Get terminal device authorization information to verify that the signature is valid.(9)
Return authentication results to the edge authentication server.(10)
The 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 EAB node, the terminal device will perform the same validation process to verify the signature to confirm the validity of the authentication result.The authentication process and algorithm are shown in Figure6 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).Figure 6
Overview of the authentication process. The device TD belongs to application domain A with intradomain authentication and cross-domain authentication, respectively.Algorithm 3: Authentication mechanism.
Initialization phase(1)
if (DMID.exist = true) then(2)
return error()(3)
else(4)
creat.block(DID, DMID,parameters, Ppub, Domian_Chain)(5)
creat.block(DID, DMID, Block_num, Alliance_Chain)(6)
end ifRegistration phase(1)
if (DID.exist = true) then(2)
get(parameters, Ppub)(3)
If (TDID.exist = false) then(4)
If (Sig.TDID = valid) then(5)
creat.blockTDID,DMID,LT,SigTDIDDMIDLTDMSK,Domain_Chain(6)
creat.blockTDID,DMID,Block_num,cross_authorization,Alliance_Chain(7)
reg_sucess(8)
end if(9)
end if(10)
else(11)
return error()(12)
end ifIntradomain authentication(1)
if (DMID.exist = true) then(2)
get(parameters, Ppub)(3)
if (TDID.exist&LT = true) then(4)
if (Hash(Sig.DMID)&Sig.TDID = valid) then(5)
return auth_sucess(6)
end if(7)
end if(8)
else(9)
return error()(10)
end ifCross-domain authentication(1)
if (DMID.exist&TDID.exit = true) then(2)
get(parameters, Ppub)(3)
DMID.Merkle_Path = getDomainChainPath(DMID.Block_num)(4)
DMID.Merkle_Root = getDomainChainPath(DMID.Block_num)(5)
DMID.Merkle_hash = computeMerkleTree(DMID_info, Merkle_Path)(6)
if (DMID.Merkle_hash = DMID.Merkle_Root) then(7)
TDID.Merkle_Path = getDomainChainPath(TDID.Block_num)(8)
TDID.Merkle_Root = getDomainChainRoot(TDID.Block_num)(9)
TDID.Merkle_hash = computeMerkleTree(TDID_info, Merkle_Path)(10)
if (TDID.Merkle_hash = TDID.Merkle_Root) then(11)
if (Sig.TDID)&cross_authorization = valid) then(12)
return auth_sucess(13)
end if(14)
end if(15)
end if(16)
else(17)
return error()(18)
end if


## 5. 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. The 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. The combination of application domain blockchain and alliance blockchain makes cross-domain authentication more convenient and business expansion of IoT applications more convenient and secure.(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. Therefore, 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. The 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 uniqueTDID in the network and is associated with its registered application domain DID and domain management node DMID 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.Through the above analysis, we compare it with existing blockchain-based IoT authentication solutions and get the results as shown in Table2. Our proposed solution is more comprehensive in terms of security.Table 2
Security comparison of different schemes.
[37][17][18][28][29][50]A2 ChainSybil✓✓✓✓✓✓Message replay✓✓✓✓✓✓DOS✓✓✓✓✓✓Scalability✓✓✓✓✓✓Cross-domain authentication✓✓✓Decentralization✓✓✓✓✓✓✓


## 6. Performance Evaluation

### 6.1. Experimental Setup

We simulate two application domain blockchains and one alliance blockchain in our experiments, each containing the necessary entities, including domain management nodes and edge authentication nodes. The edge authentication node for each application domain runs on a separate host configured with an Intel (R) Core (TM) i7-6600U CPU with 8 GB of RAM. The domain management nodes run in a virtual machine that uses VMware Workstation 15 Pro hosted on an Intel (R) Core (TM) i7-6700 CPU 3.40 GHZ and 16 GB RAM. Four edge authentication nodes are set up per application domain. All machines are interconnected in a local network. The network connection of the virtual machines is configured to connect directly to the same LAN as the host in bridge mode. Terminal device operations are performed on a laptop with an Intel(R) Core(TM) i5-6300HQ and 4 GB RAM.The 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 domain-specific 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]. This project implements an extensible development framework for RADIUS.


### 6.2. 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 Table3 (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 3
Notation description of cryptographic operations.
NotationDescriptionTPA1A point addition inG1TPA2A point addition inG2TSM1A scale multiplication inG1TSM2A scale multiplication inG2TSMTA scale multiplication inGTTETA exponentiation inGTTBPA bilinear pairingTable 4
Stats on time-consuming cryptographic operations.
PhaseComputation costUEEADMSetup and register——2TSM1 + TSM2 + 2TSMT + TPA2 +2 TET + 2TBPIntradomain authenticationTSM1 + TSM2 + 2TSMT + TPA2 + 2TET + 2TBPTSM1 + TSM2 + 2TSMT + TPA2 + 2TET + 2TBP\Cross-domain authenticationTSM1 + TSM2 + 2TSMT + TPA2 + 2TET+2TBP—TSM1 + TSM2 + 2TSMT + TPA2 +2 TET + 2TBPTable5 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. The results show that common smart IoT devices can bear the computational burden of the system. In addition, the bilinear pair computation g=eP1,Ppub 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.Table 5
Computation cost on each entity.
Computation cost (ms)Setup and registerIntradomain authenticationCross-domain authenticationUE23.86625.754EA—15.872—DM85.067—34.538To further demonstrate the advantage of our proposed system in terms of computational overhead, we compare it with existing authentication schemes ES3A [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.Figure 7
Comparison of computational overhead. (a) Cost on users for authentication. (b) Cost on servers for authentication.
(a)(b)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. The time cost of both the registration and the transaction process is about 200 ms, which may seem high, but it is acceptable. Therefore, 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.Table 6
Time costs (in s) of the blockchain.
OperationsRegistrationQueryTransferMax time (s)2.190.062.23Min time (s)0.030.010.03Avg time (s)0.180.010.16We further counted the number of computational operations included in each scheme, as shown in Table7. It can be seen from the table that ES3A [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.Table 7
Comparison of time cost cryptographic operations in authentication.
SchemeUserServerA2 ChainTSM1 + TSM2 + 2TSMT + TPA2 + 2 TET + 2TBPTSM1 + TSM2 +2TSMT + TPA2+2TET+2TBPES3A [25]6TSM1 + 3TSM2 + 3TBP + TET3TSM1 + 8TBP + 4TETCPAL [27]16TET + 7TBP10TET + 7TBPLCCH [54]30TE11 + 8TET + 8TBP23TE1 + 6TET + 5TBPE-AUA [55]2TSM1 +3TPA1 + TE12TBP + 2TE1 + TH1TE1 indicates the exponentiation in G1, and the meanings of other symbols are similar to the above definition.


### 6.3. Communication Consumption

In this section, we analyse the communication overhead of the proposed scheme. The 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 cross-domain authentication process, the edge authentication node forwards the request to the domain management node after receiving the authentication request. The 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. Therefore, the communication overhead of our scheme during intradomain and cross-domain authentication is 228 bytes and 616 bytes, respectively.The number of interactions of our proposed scheme is significantly less than other schemes in the authentication process, and there is no certificate exchange process. Therefore, 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 Figure8, 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.Figure 8
Communication cost comparisons of different schemes.


### 6.4. 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. The 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.


## 6.1. Experimental Setup

We simulate two application domain blockchains and one alliance blockchain in our experiments, each containing the necessary entities, including domain management nodes and edge authentication nodes. The edge authentication node for each application domain runs on a separate host configured with an Intel (R) Core (TM) i7-6600U CPU with 8 GB of RAM. The domain management nodes run in a virtual machine that uses VMware Workstation 15 Pro hosted on an Intel (R) Core (TM) i7-6700 CPU 3.40 GHZ and 16 GB RAM. Four edge authentication nodes are set up per application domain. All machines are interconnected in a local network. The network connection of the virtual machines is configured to connect directly to the same LAN as the host in bridge mode. Terminal device operations are performed on a laptop with an Intel(R) Core(TM) i5-6300HQ and 4 GB RAM.The 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 domain-specific 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]. This project implements an extensible development framework for RADIUS.


## 6.2. 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 Table3 (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 3
Notation description of cryptographic operations.
NotationDescriptionTPA1A point addition inG1TPA2A point addition inG2TSM1A scale multiplication inG1TSM2A scale multiplication inG2TSMTA scale multiplication inGTTETA exponentiation inGTTBPA bilinear pairingTable 4
Stats on time-consuming cryptographic operations.
PhaseComputation costUEEADMSetup and register——2TSM1 + TSM2 + 2TSMT + TPA2 +2 TET + 2TBPIntradomain authenticationTSM1 + TSM2 + 2TSMT + TPA2 + 2TET + 2TBPTSM1 + TSM2 + 2TSMT + TPA2 + 2TET + 2TBP\Cross-domain authenticationTSM1 + TSM2 + 2TSMT + TPA2 + 2TET+2TBP—TSM1 + TSM2 + 2TSMT + TPA2 +2 TET + 2TBPTable5 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. The results show that common smart IoT devices can bear the computational burden of the system. In addition, the bilinear pair computation g=eP1,Ppub 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.Table 5
Computation cost on each entity.
Computation cost (ms)Setup and registerIntradomain authenticationCross-domain authenticationUE23.86625.754EA—15.872—DM85.067—34.538To further demonstrate the advantage of our proposed system in terms of computational overhead, we compare it with existing authentication schemes ES3A [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.Figure 7
Comparison of computational overhead. (a) Cost on users for authentication. (b) Cost on servers for authentication.
(a)(b)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. The time cost of both the registration and the transaction process is about 200 ms, which may seem high, but it is acceptable. Therefore, 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.Table 6
Time costs (in s) of the blockchain.
OperationsRegistrationQueryTransferMax time (s)2.190.062.23Min time (s)0.030.010.03Avg time (s)0.180.010.16We further counted the number of computational operations included in each scheme, as shown in Table7. It can be seen from the table that ES3A [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.Table 7
Comparison of time cost cryptographic operations in authentication.
SchemeUserServerA2 ChainTSM1 + TSM2 + 2TSMT + TPA2 + 2 TET + 2TBPTSM1 + TSM2 +2TSMT + TPA2+2TET+2TBPES3A [25]6TSM1 + 3TSM2 + 3TBP + TET3TSM1 + 8TBP + 4TETCPAL [27]16TET + 7TBP10TET + 7TBPLCCH [54]30TE11 + 8TET + 8TBP23TE1 + 6TET + 5TBPE-AUA [55]2TSM1 +3TPA1 + TE12TBP + 2TE1 + TH1TE1 indicates the exponentiation in G1, and the meanings of other symbols are similar to the above definition.


## 6.3. Communication Consumption

In this section, we analyse the communication overhead of the proposed scheme. The 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 cross-domain authentication process, the edge authentication node forwards the request to the domain management node after receiving the authentication request. The 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. Therefore, the communication overhead of our scheme during intradomain and cross-domain authentication is 228 bytes and 616 bytes, respectively.The number of interactions of our proposed scheme is significantly less than other schemes in the authentication process, and there is no certificate exchange process. Therefore, 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 Figure8, 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.Figure 8
Communication cost comparisons of different schemes.


## 6.4. 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. The 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.


## 7. Discussion

A2 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. This 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 devices are generated by the domain management nodes. 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.


## 8. Conclusions

In this paper, we propose an application domain blockchain-alliance blockchain combined decentralized IoT authentication scheme called A2 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.



---

*Source: 8889192-2020-12-21.xml*