IRBA: An Identity-Based Cross-Domain Authentication Scheme for the Internet of Things

Abstract

The incredible development of Internet of things technology promotes the integration of application systems, which enable people to enjoy the convenience of multiple application services through a single intelligent device or terminal. In order to implement value exchange and information sharing between different applications, cross-domain access is inevitable. In order to prevent illegal access, identity authentication is necessary before the terminal accesses the service. Because of the need to introduce a trusted third party, the traditional centralized authentication model not only destroys the autonomy and flexibility of the application system, but also causes issues such as single point of failure and hidden dangers of unilateral control. This paper proposes an identity-based cross-domain authentication scheme for the Internet of Things. This scheme uses the Blockchain as a decentralized trust anchor instead of the traditional certificate of authority, and uses the identity-based self-authentication algorithm to replace the traditional PKI authentication algorithm. The scheme proposed in this paper implements a decentralized authentication model, which can guarantee the autonomy and initiative of the security domain.

1. Introduction

Internet of Things, also referred to as IoT, has become one of the most eye-catching technologies in recent years. In the immediate future, in 2025, more than 24.9 billion IoT connections are forecasted [1]. IoT brings huge innovation space and business value to many application fields, such as environmental monitoring, smart homes, smart cities, and so on. [2,3,4,5,6]. As the Internet of things technology is used more and more widely, security issues have also started to attract widespread attention. According to the report from Gartner, 20% of companies or organizations have experienced at least one IoT-based attack in the past three years [7].

Most IoT devices are vulnerable to malicious attacks, and the attack surfaces mainly include hardware, software, and protocols. The first is attack on the hardware. Because of the simple structure and low cost of the IoT device, it is relatively easy to be imitated and replaced. In addition, some devices are placed in unmanned areas, such as sensor nodes, which are vulnerable to physical damage. The second is attack on the software. An attacker can gain control of the terminal by hacking the operating system of the device or injecting malicious code, and illegally read user data stored on the device [8,9,10]. Once control of the IoT device is obtained, the device can be used as a springboard to further invade the back-end service system [11]. The last attack surface is attacking the protocol. Due to the limited capabilities of computing, storage, and communication, most IoT devices adopt lightweight designed communication protocols and identity authentication protocols. Because the key and encryption algorithm are too simple, the data is vulnerable to eavesdropping and tampering during transmission, and the confidentiality and integrity of the data are difficult to guarantee. Because of the huge number of IoT devices and the wide attack surface, once IoT devices are maliciously controlled, a large-scale denial of service attack could be constituted, such as the Dyn event in 2016 [12].

Through the above analysis, it can be found that the IoT device is the key to achieving IoT security. Usually, to prevent unauthorized users from accessing the system, most IoT terminals use password-based authentication. Facts have shown that this approach has huge security risks. Taking the city camera as an example, due to the large number of cameras, it is difficult for the staff to set the passwords one by one, and most of them use the default initial password. Once the password of a single camera is cracked, it will cause other cameras to lose control [13]. Therefore, identity authentication for IoT terminal is considered a key issue to ensure the security of IoT systems [14].

With the continuous enrichment of IoT application, it is inevitable that there will be requirement for cross-domain access, value exchange and collaborative control among different application systems. Since different application systems have their own user space and autonomy, these requirements of cross-domain access caused cross-domain authentication issue. For example, the smart bracelet of the smart medical system needs to be connected to the smart home system to obtain the environmental parameters of the patient’s living in order to provide reference data for the doctor’s diagnosis. Since the bracelet needs to access smart home system and smart medical system at the same time, Cross-domain authentication is needed. The issue of cross-domain authentication is described as follows. Assume that there are multiple security domains in a network, and each domain has its own users and certificate authority. The goal of cross-domain authentication is to integrate these security domains so that the same user identity can log in to different domains and access resources and services in it.

The traditional identity authentication protocol based on the public key infrastructure, also known as PKI, is considered to be the most secure identity authentication method, but this type of scheme is not suitable for IoT terminals [15]. Firstly, most IoT terminals have limited resources in terms of energy, memory and processing capacity, the calculation, storage, and communication costs generated by this type of identity authentication protocol are too high to resource constrained IoT terminals [16,17]. Secondly, the traditional PKI based authentication model is a centralized authentication model, which has a single point of failure risk and is difficult to resist DOS / DDoS attacks [18,19]. Additionally, in the mMtc application scenario of 5G, the authentication peak caused by massive terminal accesses may also cause the authentication system to be paralyzed. Finally, due to political, economic and many other reasons, it is difficult to require all application systems to believe in a unified third-party organization. Compared with the centralized authentication model, the decentralized authentication model has no single point of failure, and has good scalability, which is considered as the development trend of the Internet of things authentication technology. Blockchain technology is regarded as an effective means to realize decentralized authentication [20].

In this paper, we propose an identity-based cross-domain authentication scheme for the Internet of Things. For convenience, our algorithm is called IRBA, which is consisted by the first letter of the four words Identity, Recognize, Blockchain, and Algorithm. IRBA explored the cross-domain access control problems caused by multiple IoT applications and proposed a novel solution with low cost, fast response, and anti-attack function, while eliminating the security risks brought by trusted third parties.

Compared with the previous research works, the innovations and contributions of IRBA are as follows:

• Proposed a cross-domain access control oriented authentication method based on IBC (Identity-Based Cryptograph) algorithm.
  IRBA decomposes the cross-domain access control into two stages: identity authentication and access authorization. In the identity authentication stage, IRBA uses the identity of the IoT terminal to replace digital certificates issued by third parties and implements a decentralized identity authentication. Since every application domain can verify the authenticity of its identity through the identity of terminal, it does not need to rely on a third-party authentication server during the authentication stage. Our method avoids the problem that IoT terminals need to maintain multiple digital certificates for different application domains.
• Proposed a cross-domain joint authorization method based on threshold cryptographic algorithm.
  Using threshold cryptography algorithm, IRBA has designed a joint authorization method for cross-domain access. With this method, authentication servers in different application domains can jointly calculate the authorization signature and can independently verify the authorization signature. Therefore, the authorization process does not rely on trusted third parties. IRBA implements the authorization process through smart contracts to ensure the credibility of the authorization process. At the same time, the Blockchain is used to save the authorization results to ensure the authenticity of the authorization results. Through the above mechanism, IRBA achieves decentralized storage of access authorization results.
• Proposed an implementation scheme and evaluated the effectiveness through the prototype system
  We implemented a prototype system of IRBA based on two open source projects, which are Hyperledger Fabric and YH-RADIUS. Furthermore, we performed a performance evaluation of the core mechanism of IRBA. The experimental results show that IRBA has good processing performance and low computing overhead, which is very suitable for solving the cross-domain authentication problem of IoT.

The remainder of this article is organized as follows. Section 2 introduces the existing research and related work. Section 3 presents the motivation and our objectives. Section 4 gives a detail description of IRBA. Section 5 introduces the technical implementation of IRBA. Section 6 gives the results of performance evaluation. Section 7 summarizes of this article.

2. Related Work

2.1. Centralized Cross-Domain Authentication Scheme

Single sign-on is a typical representative of cross-domain authentication problems, and its purpose is to enable users to access data and services of different application systems through a one-time log in [21]. Single sign-on implements a type of federated identity management. By saving the user’s identity in a trusted third party, when the user accesses the application system, the application system forwards the user’s login request to the trusted third party. After the third party completes the authentication, the authorization code is returned to the application system and the user, and then the user uses the authorization code to access the application system. OAuth is the main solution for single sign-on [22]. OAuth implements cross-domain identity authentication in a proxy authentication manner instead of proposing an actual authentication algorithm.

Millán et al. construct a Bridge CA (BCA) model for cross-certification in the inter-domain networking [23]. The Bridge CA builds trust with several unrelated CAs. Each CA shares one or two cross certificates with BCA, thus establishing a trust relationship between CAs through BCA, a trusted independent node. Zhang et al. proposed a non-trusted center elliptic curve threshold signature to propose a virtual bridge CA-based virtual enterprise cross-domain authentication scheme, but due to the relatively large overhead cost, the scalability was not strong [24]. Yao et al. implemented the mutual authentication between PKI and Kerberos heterogeneous domains by using the bridge CA authentication model, but the certificate maintenance is complex, and the bridge CA management is difficult [25].

Due to the problem of certificate management in CA authentication system, researchers have conducted extensive research on identity-based cryptography (IBC). The authentication protocol proposed by Jiang et al uses the identity based cryptosystem, which takes the user’s identity as the public key, does not need to store certificates, and simplifies the network configuration [26]. Li et al. proposed a certificate-based wireless mesh network cross-domain authentication key protocol to implement mutual authentication and key exchange protocols between users [27]. Yuan et al. proposed a key agreement scheme for cross-heterogeneous domain authentication between the PKI domain and the IBC domain, but still bring about a large amount of calculation and communication [28].

2.2. Decentralized Cross-Domain Authentication Scheme

Certcoin, first proposed by Fromknecht et al., maintains the public ledger of the domain name and its related public keys [29]. The certificate issuance process is open and accessible to every user, which solves maintenance issues on single-point obstacles and certificate management in the traditional CA system. Ma et al. proposed a privacy-based Blockchain-based distributed key management scheme to achieve hierarchical access control [30]. Zhang et al. proposed the Town Crier (TC) system, which solves the problem of security authentication of its data source by providing the authenticated information for smart contracts [31]. Al-Bassam et al. proposed a PKI system based on decentralization and transparency to make malicious certificates easier to detect when they are issued [32]. The design of the trust network model enables the entities in the system to fine-granularity attributes of the identity of another entity verification becomes possible and realizes the trust transfer relationship between entity identity and entity attributes.

Zhou et al. proposed an efficient cross-domain authentication scheme based on Blockchain technology, and designed the trust model and system architecture of the Blockchain Certificate Authority (BCCA) [33]. In the BCCA trust model, the root CA joining the consortium chain is trusted, and the hash value of the certificate is recorded in the Blockchain to achieve safe and efficient cross-domain authentication. Chen et al. proposed a trust transfer scheme based on Blockchain to enhance trust and transfer [34]. This solution explores how to resolve the PKI unified trust service problem at the national level through consensus, transfers some CA management functions to the Blockchain, and builds the root CA of all security domains into a trust consortium. Trustroam is a Blockchain-based distributed authentication scheme for cross-domain roaming [35]. Different from the previous two schemes, the Trustroam verification process triggers a smart contract, and each verification is a transaction, instead of using the Blockchain as a database to query the Blockchain for data during the verification process. Ma et al. proposed a cross-heterogeneous domain authentication scheme based on Blockchain technology, in which the consortium chain model is composed of a Blockchain domain proxy server in the IBC domain and PKI domain Blockchain certificate server [36]. It enables secure and efficient communication between IBC and PKI heterogeneous domains.

3. Motivation and Objectives

Considering the vulnerability of IoT terminals in terms of security, most IoT application systems use identity authentication mechanisms to prevent malicious access by illegal terminals. When an IoT terminal needs to access the background services, it must first authenticate its identity through an authentication server. After confirming the authenticity of the terminal, the authentication server also needs to check the network access authorization result of the terminal. Only authorized users can be allowed to access. This process is often referred to as network access control. Access control not only occurs in a single application system, but also access control problems between different application systems. The problem of access control not only occurs in case of single application system, but also exists between different application systems. For example, with the popularity of wearable devices, people began to use these devices to replace wallets and ID cards. When users use wearable devices as identity cards or wallets to consume or enjoy services in different chain stores or supermarkets, cross-domain authentication problems exist. Because different application systems have their own user space and security policies, they are independent security autonomous domains. When customers in store A need to access the system of store B, cross-authentication requirement arise.

In order to solve the problem of cross-domain authentication, the traditional solution uses a centralized authentication model based on PKI. The authentication process is shown in Figure 1a. For convenience, we define an application system with a unified Certificate Authority (CA) and secure access control policies as a security domain. In Figure 1a, terminal X represents a user of security domain A. When X needs to access the service of security domain B, it has to pass the authentication and authorization checks from the authentication server of domain B. Since there is no direct trust relationship between domain A and domain B, Domain B entrusts C, which is a trusted third party, to authenticate terminal X and perform an authorization check before allowing X to access. The centralized authentication model destroys the autonomy and independence of the application system, and there are hidden dangers of single points and unilateral control problems.

For eliminating the disadvantages of the centralized authentication model, we hope to implement a decentralized authentication model, which is shown in Figure 1b. In Figure 1b, domain A and domain B establish a federal relationship and generate a user authorization list that allows cross-domain access, then jointly calculate the digital signature for the authorization list. After that, the authorization result is submitted to Blockchain to prevent repudiation and tampering. When terminal X accesses domain B, it uses a self-authentication identity authentication method instead of RSA authentication, so that B can complete the authentication of X identity without introducing a trusted third party. Next, the authentication server of domain B checks whether the authorization result stored on the Blockchain contains the terminal X. If it does, authentication succeeds otherwise fails. Compared with the centralized authentication model, decentralized authentication can guarantee the autonomy and initiative of the security domain. It does not need to rely on a third party to dynamically adjust the mutual trust relationship.

4. IRBA System

4.1. Basic Idea

Usually, the process of identity authentication mainly includes two stages: the first one is authentication stage, and the second one is authorization stage. In the authentication stage, the authentication server (AS) verifies the authenticity of the device (UE) identity. When it passes the authenticity verification, it enters the authorization stage. In the authorization stage, it mainly checks the network access rights of the device.

Figure 2 shows two typical authentication scenarios: intra-domain access and inter-domain access. In case of intra-domain access, both of the identity information and authorization information of the device are stored in the same server. Therefore, when the device wants to access intra domain services, the local authentication server can complete the whole authentication process. In case of inter-domain access, the situation is different. The identity information is stored locally, while the authorization information is stored in the remote domain. At this time, neither the local domain nor the remote domain can independently complete the authentication of the device. To adress this problem, the traditional authentication model introduces a trusted third party. The basic idea is to integrate the identity and authorization of the device in the third party, and the third party completes the identity check and authorization check of the device. Obviously, this solution destroys the autonomy of the security domain and violates the privacy protection requirements of the security domain.

In this paper, we propose a decentralized and self-organized control model for cross domain access and the basic idea includes two aspects. The first aspect is to replace the public key-based authentication algorithm with the identity-based authentication algorithm. During the process of authentication, the authentication algorithm based on identity can determine the authenticity of user without a trusted third party. We will discuss the identity-based authentication algorithm in Section 4.2. The second basic idea is to take advantage of consensus mechanism and smart contract of Blockchain to replace the trusted third-party authorization process.

When a user’s device wants to access to the service in other domain, the authentication servers of the local domain and remote domain will launch a transaction, and the transaction will trigger the execution of the Blockchain smart contract. In the smart contract, the authentication servers of both sides jointly calculate the signature for the authorization result and store it on the Blockchain. In this paper, we use the threshold cryptography algorithm to complete the signature calculation. We will also discuss threshold cryptography in the following section. Since the authorization results are jointly made by the security domains of both parties and stored on the Blockchain, it cannot be denied. By designing such a mechanism, we implement a cross-domain access authorization model without a trusted third party. In the following chapters, we will give a complete process description.

4.2. Signature Algorithm for Authentication

4.2.1. Identifier of Object

Before introducing the signature algorithm based on identity, we present the definition of ID. Object identifier (OID) is a coding scheme for identity proposed by ITU-T x.660. OID has many advantages, such as sufficient coding space, being independent of network technology, and not being affected by the underlying equipment. In this paper, we adopt OID as the identity of the device. The recommended OID structure is <Domain_ID.Category_ ID.Entity_ID>.

Table 1. OID description.

Field	Mandatory (M)/Option (O)	Interpretation
Domain ID	M	Registered Domain ID
Category ID	O	Categories of entities in the security domain, such as devices, servers, etc.
Entity ID	M	Unique number assigned to the entity

presents the field description of OID. The length of each field can be any value from 1 to 1,600,000 [37].

4.2.2. Identity-Based Signature Algorithm

• Identity-based cryptosystem (IBC)

The traditional certificate-based security system involves a large number of key management operations, including certificate issuance, query and revocation. Identity-based cryptosystem (IBC) is a cryptosystem that allow entities uses some public information to be public keys, such as name, address and email [38]. Compared with the traditional cryptosystem, the greatest advantage of IBC is that it has no certificate, is easy to use and manage, and can easily achieve data encryption, identity authentication and other security services. Therefore, IBC has unique advantage in ensuring the data security of the Internet of Things, which can save overall cost substantially and effectively support the needs of identity authentication, data security, transmission security, access control, etc., in the application process of the Internet of things [39].

However, IBC also has an inherent disadvantage: the problem of private key escrow, a "trusted" private key generator (PKG) knows all users’ private keys, so it can pretend to be any user to sign documents or decrypt encrypted messages. To overcome the private key escrow problem of PKG, Chen et al. [40] and Li et al [41] proposed the identity-based signature scheme without trusted PKG. Inspired by their work, we design an identity-based authentication scheme. In this scheme, each device has a key pair generated by ID as the public key. The authentication process can directly use the ID of the device to verify the signature without the participation of a third party. In the scheme, Authentication Server (AS) participates in the generation of keys as a PKG. We assume that the authentication server of each security domain uses the same public parameter and only the master key and the public key are different.

• Theory description of IBC

The Identity-based Signature Scheme mainly includes four stages: Setup, Extract, Signing and Verification. Algorithm 1 shows the IBC based authentication process.

Algorithm 1. Authentication Algorithm based on IBC
1.	/*
2.	G1 is an additive group and G2 is a multiplicative group. The P and the q are
3.	the generator and order of the group, respectively.
4.	$H_1:{\left\{0,1\right\}}^{*}\times G_1\to G_1,$ $H_2:{\left\{0,1\right\}}^{*}\to G_1,$ $H_3:G_2^4\to Z_q$
5.	$e:G_1\times G_2\to G_2$ is a bilinear mapping.
6.	$\forall P,Q\in G_1$ and $\forall a,b\in Z_q$, $e\left(aP,bQ\right)=e{\left(P,Q\right)}^{ab}$.
7.	*/
8.	Operation of AS (Authentication Server)
9.	[Setup]:
10.	$Gen\left(P\right)\to \left(s,P_{Pub}\right)$;
11.	$\left\{G_1,G_2,e,q,P,P_{Pub},H_1,H_2,H_3\right\}\to params$;
12.	[Extract]:
13.	$GenSK\left(x,params,I{D}_{UE}\right)\to S{k}_{UE}$;
14.	[Verification]:
15.	$Ver\left(\sigma ,params,I{D}_{UE}\right)\to valid/invalid$;
16.
17.	Operation of $UE$ (User Device)
18.	[Signing]:
19.	$SigID\left(m,params,S{k}_{U{E}_1}\right)\to \sigma$;

The Setup and Extract are executed in the registration phase, and Signing and Verification are executed in the authentication phase. The registration phase is performed interactively by the authentication server (AS) and the device (UE). We assume that the communication channel between AS and UE is private and secure at this phase.

• Setup
  Step 1. The AS first picks group G₁ and group G_2. Among them, G₁ is an additive group and G₂ is a multiplicative group. The P and the q are the generator and order of the group, respectively. $e:G_1\times G_2\to G_2$ is a bilinear mapping, and $\forall P,Q\in G_1$ and $\forall x,y\in Z_q$, $e\left(xP,yQ\right)=e{\left(P,Q\right)}^{xy}$. Three hash functions $H_1:{\left\{0,1\right\}}^{*}\times G_1\to G_1,$ $H_2:{\left\{0,1\right\}}^{*}\to G_1,$ and $H_3:G_2^4\to Z_q$.
  Step 2. At first, the AS randomly chooses the master private key $s\in Z_q^{*}$, and then computes the master public key through formula $P_{pub}=sP$.
  Step 3. The AS secret storage $s$.
• Extract
  Step 1. The UE chooses an integer $r\in Z_q^{*}$, and computes $R=rp$. Then UE submits its identity information $I{D}_{UE}$, $R$, and using period $t$ to the AS.
  Step 2. After receiving the message, AS computes $Q_{ID}=H_1\left(I{D}_{UE}\parallel t,R\right),S_{ID}=s{Q}_{ID}$.
  Step 3. The AS sends $S_{ID}$ to the UE. $(S_{ID}$,$r)$ are the private key pair of UE, whose corresponding public key is $I{D}_{UE}$.
• Signing
  Step 1. If UE wants to access the server, the UE first sends a authentication request to AS.
  Step 2. After the authentication request message is received, the AS generates a random number $N$. The AS then sends a response message to the UE.
  Step 3. The UE responds to the received message. UE computes $\theta =r{H}_2\left(m\right)$, $\sigma =e\left(H_2\left(N\right),S_{ID}\right),\omega =e\left(H_2\left(N\right),Q_{ID}\right)$. $\epsilon =Q+z{S}_{ID},z=H_3\left(x,y,\omega ,\sigma \right)$.
  Step 4.$\left(\theta ,\sigma ,R,\epsilon \right)$ are the signatures of the message $N$. UE sends the signatures to AS.
• Verification
  Step 1. The AS computes $Q_{ID}=H_1\left(I{D}_{UE}\parallel t,R\right),\omega =e\left(H_2\left(N\right),Q_{ID}\right),\mu =e\left(P_{pub},Q_{ID}\right),z=H_1\left(x,y,\omega ,\sigma \right)$.
  Step 2. If the equation $e\left(\theta ,P\right)=e\left(H_2\left(N\right),R\right),e\left(P,\epsilon \right)=x{\mu }^z,e\left(H_2\left(N\right),\epsilon \right)=y{v}^z$ hold, the signature verification succeed.

• Security Analysis

We consider the following two situations:

1. As is untrustworthy

According to the working principle of PKG introduced earlier, the PKG server will computes $S_{ID}$ and sends it back to UE as a partial private key. In case of AS is untrustworthy, the adversary can obtain the target UE’s public key and $S_{ID}$ from the PKG server.

If the adversary wants to compute the corresponding $V$ for a special message $m$, it has to compute the spoof without knowing the randomly element selected by UE. Obviously, under the assumption of CDHP in $G_1$ is intractable, the probability of an adversary successfully forging a valid signature is negligible [40,41,42].

2. As is trustworthy

In case of AS is trustworthy, the adversary cannot get the UE’s $S_{ID}$ and from the PKG server. Since the randomly integer chosen by UE only exists t time. Under the assumption of CDHP, there is no algorithm that can generate fake signatures with a non-negligible probability. Nor the CDHP can be addressed.

4.2.3. Threshold Signature Algorithm

• Threshold signature

The idea of threshold signature was first proposed by Shamir [43] in 1979. It is used to obtain consensus or approval of a group of participants. The threshold signature scheme allows sharing signing rights among $n$ participants, each of whom has a private signing key. The signature requires a threshold of $t$ ($t\le n$) or more participants, and any group whose population less than $t$ cannot generate a signature. The digital signature can be verified though public key [44].

We propose a threshold cryptography-based signature algorithm for cross-domain access authorization. The authorization for cross-domain access can only be generated when the threshold is reached. The verification process of threshold signature is the same as that of traditional signature, which will not affect the verification efficiency [40]. The algorithm mainly includes five parts, which are Setup, Extract. Private Key Distribution, Signing and Verification. Algorithm 2 shows the process of using threshold signature authorization.

Algorithm 2. Authentication Algorithm based on Threshold Signature
1	Authority Issuance
2	/* The process of [Setup] and [Extract] is the same as Authentication Algorithm */
3	[Private Key Distribution]:
4	$GenTh()$: generates a set of n secret key shares {S$k_{ID}^1,S{k}_{ID}^2,\dots ,S{k}_{ID}^n$};
5	[Signing]:
6	$SigTh\left(m,params,S{k}_{ID}^i\right)\to {\sigma }_i$;
7	$SigCom\left({\sigma }_{1,}{\sigma }_2,\dots ,{\sigma }_k\right)\to \sigma$,$k\ge T$.;
8
9	Authority validation
10	[Verification]:
11	$VerTh\left(\sigma ,params,ID\right)\to valid/invalid$;

The signature scheme is described in detail as follows:

• Private Key Distribution:
  Step 1. The Method of public key setting is similar to the identity-based signature, except that the public and private key pair are generated using the Blockchain address of authority contract as the $I{D}_{AC}$ after the authority contract is created.
  Step 2. The authority contract distributes the private key to the n ASes to sign the authority.
  1. The authority contract chooses $m_i{\in }_R{Z}_q,n_i{\in }_R{G}_1$,which $1\le i\le t-1$.
  2. Computes the polynomials:

  $$h\left(x\right)=r+m_{1}x+m_2{x}^2+\dots +m_{t-1}{x}^{t-1}$$

  $$H\left(x\right)=S_{ID}+n_{1}x+n_2{x}^2+\dots +n_{t-1}{x}^{t-1}$$
  3. Computes the distribution key for each AS $h\left(i\right)=r_i,H\left(i\right)={\epsilon }_i$. The verification key corresponding to each key are ${\lambda }_i=r_{i}P,{\mu }_i=e\left(P,{\epsilon }_i\right)$.
  Step 3. Use the public key of AS_i encrypted and sent to AS_i $(1<i<n)$. $h\left(x\right)={\displaystyle \sum }_{j\in \mathsf{\Phi }}{z}_{xj}^{\mathsf{\Phi }}{r}_j,H\left(x\right)={\displaystyle \sum }_{j\in \mathsf{\Phi }}{z}_{xj}^{\mathsf{\Phi }}{\epsilon }_j$, where $z_{xj}^{\mathsf{\Phi }}={\displaystyle \prod }_{l\in \varphi ,l\ne j}\frac{x-l}{j-l},\mathsf{\Phi }\subset \left\{1,2,\dots ,n\right\},\left|\mathsf{\Phi }\right|\ge t$.
• Signing
  After receiving the signature request, AS_j $(1<j<n,j\ne i)$ perform the following steps to sign the authorization information, assuming that the authorization information is $M$
  Step 1. AS_j computes and broadcasts ${\theta }_j=r_j{H}_2\left(m\right),{\sigma }_j=e\left(H_2\left(m\right),{\epsilon }_j\right),x_j=e\left(P,Q_j\right)$,$y_j=e\left(H_2\left(m\right),Q_j\right)$, $Q_j\in G_1$ which is chosen randomly.
  Step 2.AS_j Computes $x={\displaystyle \prod }_{j\in \mathsf{\Phi }}{x}_j^{z_{0j}^{\mathsf{\Phi }}},y={\displaystyle \prod }_{j\in \mathsf{\Phi }}{y}_j^{z_{0j}^{\mathsf{\Phi }}},\sigma ={\displaystyle \prod }_{j\in \mathsf{\Phi }}{\sigma }_j^{z_{0j}^{\mathsf{\Phi }}}$.
  Step 3. AS_j computes and broadcasts $V_j=Q_j+z{\epsilon }_j$, $\omega =e\left(H_2\left(M\right),Q_{ID}\right)$ where $z=H_3\left(x,y,\omega ,\sigma \right)$.
  Step 4. AS_i verify the validity of partial signature. AS_i checks if $e\left({\theta }_j,P\right)=e\left(H_2\left(m\right),l_j\right),e\left(P,V_j\right)=x_j{\mu }_j^z,e\left(H_2\left(M\right),V_j\right)=y_j{\sigma }_j^z,j\ne i$ hold. If some of the equations do not hold, the broadcast restarts the calculation.
  Step 5. After the completion of partial signature verification, the authority contract collects partial signatures of AS, computes $\theta ={\displaystyle \sum }_{j\in \mathsf{\Phi }}{z}_{0j}^{\mathsf{\Phi }}{\theta }_j,\epsilon ={\displaystyle \sum }_{j\in \mathsf{\Phi }}{z}_{0j}^{\mathsf{\Phi }}{V}_j$.
  Step 6.$\left(\theta ,\sigma ,R,\epsilon \right)$ are the signatures of the authorization information $M$.
• Verification
  Suppose the authentication server $A{S}_k$ verifies the authority signature.
  Step 1. The $A{S}_k$ first computes

  $$Q_{ID}=H_1\left(I{D}_{AC}\parallel t,R\right),\omega =e\left(H_2\left(M\right),Q_{ID}\right),\mu =e\left(P_{pub},Q_{ID}\right),z=H_1\left(x,y,\omega ,\sigma \right)$$
  Step 2. If the equation $e\left(\theta ,P\right)=e\left(H_2\left(M\right),R\right),e\left(P,\epsilon \right)=x{\mu }^z,e\left(H_2\left(M\right),\epsilon \right)=y{\sigma }^z$ hold, the signature verification succeeds.

• Correctness Analysis
  Step 1. Note that

  $$\theta ={{\displaystyle \sum }}_{j\in \mathsf{\Phi }}{z}_{0j}^{\mathsf{\Phi }}{\theta }_j={{\displaystyle \sum }}_{j\in \mathsf{\Phi }}{z}_{0j}^{\mathsf{\Phi }}{r}_j{H}_{2}M=r{H}_2\left(M\right)$$
  Therefore, we have $\epsilon ={{\displaystyle \sum }}_{j\in \mathsf{\Phi }}{z}_{0j}^{\mathsf{\Phi }}{W}_j={{\displaystyle \sum }}_{j\in \mathsf{\Phi }}{c}_{0j}^{\mathsf{\Phi }}\left(Q_j+z{\epsilon }_j\right)$
  Step 2.

  $$e\left(\theta ,P\right)=e\left(H_2\left(M\right),R\right)$$

  $$\begin{gathered} e\left(P,\epsilon \right)=e\left(P,{{\displaystyle \sum }}_{j\in \mathsf{\Phi }}{z}_{0j}^{\mathsf{\Phi }}\left(Q_j+z{\epsilon }_j\right)\right)=e\left(P,{{\displaystyle \sum }}_{j\in \mathsf{\Phi }}{z}_{0j}^{\mathsf{\Phi }}{Q}_j+{{\displaystyle \sum }}_{j\in \mathsf{\Phi }}{z}_{0j}^{\mathsf{\Phi }}{\epsilon }_j\right) \\ =e\left(P,{{\displaystyle \sum }}_{j\in \mathsf{\Phi }}{z}_{0j}^{\mathsf{\Phi }}{Q}_j\right)e{\left(P,S_{ID}\right)}^z=x{\mu }^z \end{gathered}$$
  Step 3.

  $$\begin{gathered} e\left(H_2\left(M\right),\epsilon \right)=e\left(H_2\left(M\right),{{\displaystyle \sum }}_{j\in \mathsf{\Phi }}{z}_{0j}^{\mathsf{\Phi }}\left(Q_j+z{\epsilon }_j\right)\right)=e\left(H_2\left(M\right),{{\displaystyle \sum }}_{j\in \mathsf{\Phi }}{z}_{0j}^{\mathsf{\Phi }}{Q}_j+{{\displaystyle \sum }}_{j\in \mathsf{\Phi }}{z}_{0j}^{\mathsf{\Phi }}{\epsilon }_j\right) \\ =e(H_2\left(M\right),{{\displaystyle \sum }}_{j\in \mathsf{\Phi }}{z}_{0j}^{\mathsf{\Phi }}{Q}_{j}e{\left(H_2\left(M\right),S_{ID}\right)}^z=y{\sigma }^z \end{gathered}$$
• Security of Analysis
  The “Simulatability” of identity-based threshold signatures was defined by Baek [45]. Meanwhile he proved that the security of identity-based threshold signature depends on the identity-based signature sel.

Definition 1.

If an identity-based threshold signature satisfies the following conditions, the signature scheme can be simulated.

1. “Private key distribution” can be simulated: The adversary’s view can be simulate by the simulator when key distribution is executed under the condition that the public parameters, identity $ID$ are known.

2.“Signature” can be simulated: The adversary’s view can be simulate by the simulator when the signature is executed by knowing the public parameters of the identity based threshold signature, the authorization information $M$ and the corresponding signature $\tau$, as well as the $t-1$ key shares and the corresponding public information for verification.

Theorem 1.

The threshold signature scheme based on identity is un-forgeable, while the signature scheme is un-forgeable and the identity-based threshold signature scheme can be simulated.

In Reference [45], Theorem 1 has been proved. Therefore, the security of the identity-based threshold signature scheme only needs to prove that it can be simulated.

Lemma 1.

The threshold signature method based on identity in our scheme can be simulated.

Proof. 

 

Step1. let’s suppose that the adversary corrupted the authentication server AS_i, where $1\le i\le t-1$.

Step2. We firstly prove the “Private Key Distribution” can be simulated.

1. The adversary computes $\mu =e\left(P_{pub},Q_{ID}\right)$ by system parameters $params$ and the identity $I{D}_{AC}$

2. Since $\mu ={\displaystyle \prod }_{j=1}^t{\mu }_i^{z_{0j}^{\mathsf{\Phi }}}$, the correct simulated value $\mu \left(t\right)$ can be computed by the adversary. It means that $\mu \left(t\right)$ is same as the result of “Private Key Distribution”. The adversary also can compute the simulated value $r_{t}P$ correctly.

Step3. Then, we prove that the “signature” can be simulated.

1. The adversary computes ${\theta }_i=r_i{H}_2\left(M\right)$. Given the identity $I{D}_{AC}$, system parameters, authorization information $M$, $t-1$ private key shares $\left(r_i,{\epsilon }_i\right)$, corresponding signature $\tau =\left(\theta ,\sigma ,R,x,y,\epsilon \right)$ and corresponding verification keys $\left(R,e\left(P,{\epsilon }_i\right)\right)$.

2. Suppose that $H\left(x\right)$ be a polynomial function of degree $t-1$, and $H\left(0\right)=\theta$, $\left(i\right)={\theta }_i$ $1\leqq i\leqq t-1$. The adversary can compute $\theta \left(i\right)=H\left(i\right)$, $t\le i\le n$. The adversary also can compute ${\sigma }_i,x_i,V_i$, $t\le i\le n.$

According to the security analysis of identity-based signature, Theorem 1 and Lemma 1, we can get the conclusion that the identity-based threshold signature scheme is un-forgeability. □

4.3. Authority Mechanism

4.3.1. Smart Contracts in IRBA

The smart contract is a kind of computer program which aims to spread, verify or execute the contract by way of code. Different to real contracts, smart contracts can carry out traceable, irreversible and secure transactions without the participation of third parties. All information related to the transaction is included in the smart contract, which can only be executed when the conditions are met.

In order to achieve the request and issue of cross-domain authority, we use the following three types of smart contracts:

• The main contract accepts authority requests and maintains the application list. There is only one main contract on the Blockchain, and all entities know its Blockchain address. To obtain a cross-domain authority, the authentication server should set up a new authority contract by using the master contract.
• The authority contract is created by the main contract and receives a signature. It enables authentication server to create threshold signatures by providing an exchange of publicly available random numbers.
• The storage contract is used as the recipient of a transaction that contains authority data and signatures.

4.3.2. Authority for Cross-Domain Access

When a device, UE₁, which belongs to domain D₁, wants to access the services of another domain, the procedure of authority is presented in Figure 3.

For the convenience of description, we define the symbols as shown in

Table 2. Description of symbols.

Parameter	Description
$U{E}_i$:	$UE$ in domain i
$A{S}_i$:	AS in domain i
$Si{g}_{Sk}()$:	Signing used $Sk$
$I{D}_{U{E}_1}$:	Public key of $U{E}_i$

.

Step 1. $U{E}_1\to A{S}_1:\left\{Request,I{D}_{U{E}_1},Si{g}_{S{k}_{U{E}_1}}\left(Requset\right)\right\}$

$U{E}_1$ requests the cross domain authority from ${AS}_1$ and uses the private key $S{k}_{U{E}_1}$ to generate signature $Si{g}_{S{k}_{U{E}_1}}\left(Requset\right)$;

Step 2. After verifying the $U{E}_1$ request, $A{S}_1$ use the main contract to create an authority contract, and specify the AS address of the security domain to be accessed to collect signatures.

Step 3. The authority contract generates a key for signing and encrypts it with the public key of the AS in the specified domain, and distributes the encrypted signature key to the corresponding AS. The AS generates the partial signature and sends it to the authority contract.

Step 4. The authority contract collects signatures, combines the collected signatures into a complete authority signature.

Step 5. The storage contract packages the authority transaction into a block and stores it on the Blockchain.

4.4. Cross-Domian Authentication Process

It is assumed that the device $U{E}_1$ in the security domain D₁ initiates an authentication request to the authentication server AS₂ in security domain D₂. The authentication process is shown in Figure 4. The symbol definition in the authentication process is shown in

Table 3. Description of symbols.

Parameter	Description
$I{D}_{U{E}_1}$i	Public key of $U{E}_i$
$U{E}_i$:	$UE$in domain i
$A{S}_i$:	AS in domain i
$BC$:	Blockchain
$Si{g}_{Sk}()$:	Signing used $Sk$
$Authorit{y}_i$:	Authority of $U{E}_i$

. The procedure of protocol is described as follows:

• $U{E}_1\to A{S}_2:\left\{Access request,I{D}_{U{E}_1}\right\}$
  $U{E}_1$ initiate an authentication request to authentication server $A{S}_2$ in D₂.
• $A{S}_2\to U{E}_1:\left\{N_1\right\}$
  After receiving the request from $U{E}_1$, D₂ authentication server $A{S}_2$ responds to the request and sends a random number $N_1$ to D₁ device $U{E}_1$.
• $U{E}_1\to A{S}_2:\left\{Si{g}_{S{k}_{U{E}_1}}\left(N_1\right),N_1\right\}$

  (1)

  Device $U{E}_1$ receive the response from authentication server $A{S}_2$ using its private key $S{k}_{U{E}_1}$ to generate a signature $Si{g}_{S{k}_{U{E}_1}}\left(N_1\right)$ of random number $N_1$;

  (2)

  $U{E}_1$ responds to the request of $A{S}_2$ and send the signature $Si{g}_{S{k}_{U{E}_1}}\left(N_1\right)$ and random number $N_1$ are sent to $A{S}_2$.

• $A{S}_2\to BC:\left\{I{D}_{U{E}_1}\right\}$

  (1)

  $A{S}_2$ uses $I{D}_{U{E}_1}$ to verify signature $Si{g}_{S{k}_{U{E}_1}}\left(N_1\right).$

  (2)

  $A{S}_2$ queries the result of authority from Blockchain.

• $BC\to A{S}_2:\left\{Authorit{y}_1\right\}$

  (1)

  If there is no authority of $U{E}_1$ in the query result, the authentication fails

  (2)

  If the authority exists, check whether the validity period and the list of trusted domains allowed to access are valid. Verify the signature of “$Authorit{y}_1$”. If the authentication succeeds, the authentication passes; otherwise, the authentication fails.

  (3)

  If the authorization for $U{E}_1$ is not found, the authentication fails.

  (4)

  If the authorization exists, check whether the validity period and the list of trusted domains that are allowed to be accessed are valid.

• $A{S}_2\to U{E}_1:\left\{Auth-result\right\}$
  $A{S}_2$ returns the authentication result of $U{E}_1$.

5. System Implementation

We develop a prototype system of IRBA with Go language. For convenience, we still use IRBA to represent the prototype system in this article. The IRBA consists of three parts. The first is the Blockchain platform. We adopt Hyperledger Fabric v1.0 [46] in IRBA. Since IRBA does not need to change the underlying mechanism of the Blockchain, not only Hyperledger Fabric, but other Blockchain platforms that support smart contracts can also be selected. The second part is smart contract, which is called chain-code in Hyperledger Fabric. IRBA implements threshold cryptographic algorithms based on smart contracts. When the security domain wishes to establish a cross-domain trust relationship with other domains, it issues smart contracts through transactions. The third part is the authentication protocol. As we all know, Remote Authentication Dial In User Service (RADIUS) [47] is often used to build AAA servers, also known as Authenticate, Authority and Audit server. Therefore, we choose the open source project-YH-RADIUS [48]. This project implements an extensible development framework of RADIUS. The composition of the entire prototype system is shown in Figure 5.

Given that near-field communication protocols such as Bluetooth cannot support remote access, in our prototype system, only the case of TCP / IP-based networks is considered for the time being.

In the Figure 5, Extensible Authentication Protocol (EAP) is a universal authentication protocol standard framework running on TCP / IP networks [49]. This framework implements different authentication processes by encapsulating different protocol plug-ins. By using an identity-based signature algorithm, we implement the EAP-IBE protocol in IRBA. The module of domain management in Figure 5 is responsible for member registration, member removing, cross-domain request processing and smart contract release. When different security domains need to access each other, they release smart contracts through the domain management module, which is used to calculate joint authorization signatures of permission for cross-domain access. The model of authority management provides functions of appending, querying and retreating for cross-domain access authority. Because the Blockchain does not allow deletion of records that have been stored, both appending and retreating function will generate a new record with timestamp. When querying authorization results, the record with latest timestamp must prevail.

IRBA is installed on all authentication servers, providing full identity authentication and cross-domain access authentication capabilities. All IRBA-certified servers form a Fabric-based permission Blockchain [50]. Every authentication server can be configured as endorsement node, confirmation node and CA node. Each authentication server locally saves the identity information of members in the domain, and also maintained the distributed ledger and chain code. In order to ensure the reliability of the Blockchain system, the deployment of the sequencing service adopts the Kafka model of Fabric, which can prevent single points of failure of the sequencing nodes. Figure 6 presents a conceptual deployment scenario.

IRBA is composed of two subsystems which are authentication and access authorization. In the traditional AAA system implementation, the identity authentication subsystem interacts with the authorization subsystem through the RADIUS protocol. However, in IRBA, due to the special nature of smart contracts, the identity authentication subsystem calls the smart contract through the API of fabric SDK to complete the interaction.

Table 4. Interaction with smart contract.

Schematic codes. Calling smart contract in IRBA
1	var Fabric_Client = require(’fabric-client’);
2	var channel = fabric_client.newChannel(’newChannel’);
3	var peer = fabric_client.newPeer(’grpc://localhost:7051’);
4	channel.addPeer(peer);
5	var order = fabric_client.newOrderer(’grpc://localhost:7050’)
6	channel.addOrderer(order);
7	var request = {
8	chaincodeId: ’AuthorityChaincode’,
9	fcn: ’appendFunc’,
10	args: [’targetDomianID’, ’ srcDomianID ’, ’UserID’],
11	chainId: ’ newChannel ’,
12	txId: tx_id };
13	channel.sendTransactionProposal(request);

shows the schematic codes.

6. Performance Evaluation

6.1. Experiment Setup

To evaluating the performance of IRBA, we built an experimental environment as shown in Figure 7. In this experimental environment, there are ten PC servers with IRBA system and Hyper Ledger Fabric installed on them. Each of these servers represents an authentication server of a security domain. The authentication server is responsible for cross-domain access authorization and device cross-domain access authentication. These ten authentication servers form a consortium Blockchain. We also deploy an IoT device in every security domain with authentication client software installed on it. The configuration of our experiment is listed in

Table 5. Configuration for the experiment.

Parameters	Values
Authentication servers	Intel-Core i5 6300 HQ CPU (2.30 GHz),16GB, Ubuntu 16.04
IoT device	ARM Cortex A53 (1.2 GHz),1 GB, Raspbian GNU/Linux 8
Switch	1Gbps*24
Block Size	30 transactions per block
Block Timeout	2 second

.

6.2. Processing Performance of Authority for Cross-Domain Access

In this experiment, we establish cross-domain access relationships from 2 to 10 security domains in turn, and observe the performance change of authorized signature calculations as the number of domains increases. For example, the first time, we have two security domains access each other and then we have three security domains access each other and so on, and finally expand to 10 security domains to access each other.

The results of this experiment are shown in Figure 8. From the chart, we found that the authority processing time does not exceed 5 seconds, and in most cases, the duration does not exceed 3 seconds, accounting for 60%–70%; meanwhile, the time required to issue an authority varies slightly with the threshold T.

6.3. Processing Performance of Authorization Verify

In this experiment, we evaluate the processing performance of authorization verify. Similarly, we use the threshold T as a variable. The test cast is re-executed for 100 times and the average of the 100 samples is taken. The results obtained are shown in the

Table 6. Authority verification time (TIDTV).

Count of Authentication Server(T)	Time (ms)
2	5.556
4	5.672
8	5.724
10	5.542

.

From the experiment results we found that the verification time does not change much with the change of threshold T, which means IRBA has good scalability.

6.4. Processing Performance of the Authentication

In this section, we make a performance comparison between IRBA and three typical authentication methods, which include which include Enterprise Instant Messaging Authenticated Key Agreement Protocol (EIMAKP) [28], Blockchain Certificate Authority (BCCA) [33], and Cross heterogeneous domain authentication scheme (CHDA) [36]. Among these three methods, EIMAKP adopts centralized authentication scheme, BCCA uses Blockchain storage certificate for cross domain authentication and CHDA uses Blockchain to build a heterogeneous trust alliance between PKI and IBC domains. We will compare the performance of some cryptographic operations in the related protocols given by Ma et al [24]. The experiment results are listed in

Table 7. Computation time consuming.

Description	Time (ms)
Identity-based signature (TIDS)	23.866
Identity-based signature verification (TIDV)	5.872
Asymmetric signature (TAS)	3.85
Asymmetric signature verification (TAV)	0.1925
Public-key-based encryption (TPE)	3.85
Public key-based decryption (TPD)	3.85
symmetrical encryption (TSE)	0.0046
Symmetric decryption (TSD)	0.0046
Scalar multiplication (TM)	20226
Bilinear pairing (TP)	5.811
$H_n:{\left\{0,1\right\}}^{*}\to Z_n$	0.0023
$H_P:{\left\{0,1\right\}}^{*}\to G_1$	12.418
$H_M:{\left\{0,1\right\}}^{*}\to G_2$	0.974
$H_S:{\left\{0,1\right\}}^{*}\to {\left\{0,1\right\}}^{*}$	0.0046

. The overall performance of the system is little affected by the performance evaluation in the registration phase and the running time of some lightweight operations, so we ignore them.

Table 8. Analysis for overhead of computation and communication.

Schemes	Computational Cost		Delay (ms)	Communication Cost (bit)
EIMAKP-Ⅰ	User	TIDV + TAV + 2TPE + 2TPD + TSE + TSD + 3TM + TP + HM	116.25	1808
	Server	TAV + 2TPD + TSE +TSD + TIDS + 3TAS + TAV + 3TPE + TPD + TSE + TSD + 2TP + 2HM + HP
EIMAKP-Ⅱ	User	TIDV + TAS + 2TPE +TPD + TSE + TSD + HP	111.05	1408
	Server	TIDV + 2TPD + TSE + TSD + 2TIDS + TAS + 2TAV + 2TPE + TPD + TSE + TSD
BCCA	User	2TAS	32.92	2720
	Server	2TAV + HS
CHDA-Ⅰ	User	TPE	96.98	1040
	Server	TIDS + TAV + TPE + TPD + TIDV + 3TAS + 2TAV + 4TPE + 5TPD + 4TM2Hn + HS
CHDA-Ⅱ	User	TPE	80.27	1040
	Server	TIDV + TAS+ TPD+ TIDS +2TAS + 3TAV + 4TPE + 4TPD + 2HS
IRBA	User	TIDS	40.502	592
	Server	TIDV + TIDTV

summarizes the calculation and communication costs of different schemes.

In Figure 9, we can see that IRBA takes much less time than EIMAKP and CHDA. This is because EIMAKP and CHDA need several rounds of message exchange during the authentication process, which increases the calculation cost of the system. However, compared with BCCA, IRBA takes more time. This is because the IBC algorithm used by IRBA is more complex than the hash algorithm used by BCCA.

In Figure 10, we found the cost of IRBA is lower than for other solutions. For EIMAKP and CHDA, because of multiple round of cipher text and cert exchange, the communication overhead is the highest of all. For IRBA, since the authority results are stored on the Blockchain, and the authentication server has the copy of ledge, less information needs to be exchanged. Therefore, IRBA is more suitable for resource-constrained IoT devices.

7. Conclusions

In this paper, we propose an identity-based cross-domain authentication scheme for the Internet of Things. We have made innovations in the traditional authentication scheme, which include cross-domain authentication method based on IBC and a multi-domain joint authorization mechanism based on threshold cryptography and smart contracts. Through the combination of these methods, we implement a decentralized cross-domain authentication model. We have also developed a prototype system for the evaluation of information energy. Experimental results show that IRBA has good processing performance and flexibility, and it is very suitable for many scenarios of the IoT.