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

: 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 di ﬀ erent 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 ﬂexibility 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 certiﬁcate 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.


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 1.
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 Electronics 2020, 9,634 3 of 21 during the authentication stage. Our method avoids the problem that IoT terminals need to maintain multiple digital certificates for different application domains.

2.
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. 3.
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.

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].

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.

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.
Electronics 2020, 9, x FOR PEER REVIEW 5 of 21 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.

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

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

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 presents the field description of OID. The length of each field can be any value from 1 to 1,600,000 [37].

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, 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.

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 presents the field description of OID. The length of each field can be any value from 1 to 1,600,000 [37]. 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. G 1 is an additive group and G 2 is a multiplicative group. The P and the q are 3.
the generator and order of the group, respectively. 4.

15.
Ver(σ, params, ID UE ) → valid/invalid ; SigID(m, params, Sk UE 1 ) → σ ; 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 Electronics 2020, 9, 634 8 of 21 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 1 and group G 2. Among them, G 1 is an additive group and G 2 is a multiplicative group. The P and the q are the generator and order of the group, respectively. e : G 1 × G 2 → G 2 is a bilinear mapping, and ∀P, Q ∈ G 1 and ∀x, y ∈ Z q , e(xP, yQ) = e(P, Q) xy . Three hash functions H 1 : Step 2. At first, the AS randomly chooses the master private key s ∈ 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 ∈ Z * q , and computes R = rp. Then UE submits its identity information ID UE , R, and using period t to the AS. Step 2. After receiving the message, AS computes Q ID = H 1 (ID UE t, R), S ID = sQ 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 ID UE .

Signing
Step 1. If UE wants to access the server, the UE first sends a authentication request to AS.
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.
Step 4.(θ, σ, R, ε) are the signatures of the message N. UE sends the signatures to AS.

• Security Analysis
We consider the following two situations:

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].

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.

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 Electronics 2020, 9, 634 9 of 21 signing rights among n participants, each of whom has a private signing key. The signature requires a threshold of t (t ≤ 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. SigTh m, params, Sk i ID → σ i ; 7 SigCom σ 1, σ 2 , . . . , σ k → σ ,k ≥ T.; 8 9 Authority validation 10 [Verification]: 11 VerTh(σ, params, ID) → valid/invalid ; The signature scheme is described in detail as follows: 1.

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 ID 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 ∈ R Z q , n i ∈ R G 1 ,which 1 ≤ i ≤ t − 1.

Computes the polynomials:
3. Computes the distribution key for each AS h(i) = r i , H(i) = ε i . The verification key corresponding to each key are λ i = r i P, µ i = e(P, ε i ).
Step 3. Use the public key of AS i encrypted and sent to AS i (1

Signing
After receiving the signature request, AS j (1 < j < n, j i) perform the following steps to sign the authorization information, assuming that the authorization information is M Step 1. AS j computes and broadcasts θ j = r j H 2 (m), σ j = e H 2 (m), ε j , x j = e P, Q j ,y j = e H 2 (m), Q j , Q j ∈ G 1 which is chosen randomly.
Step 4. AS i verify the validity of partial signature. AS i checks if e θ j , P = e H 2 (m), l j , e P, V j = x j µ z j , e H 2 (M), V j = y j σ z j , j 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 θ = j∈Φ z Φ 0 j θ j , ε = j∈Φ z Φ 0 j V j .

Verification
Suppose the authentication server AS k verifies the authority signature.

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 τ, 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 ≤ i ≤ t − 1.
Step2. We firstly prove the "Private Key Distribution" can be simulated. 1. The adversary computes µ = e P pub , Q ID by system parameters params and the identity ID AC 2. Since µ = t j=1 µ z Φ 0 j i , the correct simulated value µ(t) can be computed by the adversary. It means that µ(t) is same as the result of "Private Key Distribution". The adversary also can compute the simulated value r t P correctly.
2. Suppose that H(x) be a polynomial function of degree t − 1, and 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.

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.

Authority for Cross-Domain Access
When a device, UE 1 , which belongs to domain D 1 , wants to access the services of another domain, the procedure of authority is presented in Figure 3.

•
The storage contract is used as the recipient of a transaction that contains authority data and signatures.

Authority for Cross-Domain Access
When a device, UE1, which belongs to domain D1, 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.
Step 1. 1  ); Step 2. After verifying the 1 request, 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. For the convenience of description, we define the symbols as shown in Table 2. Table 2. Description of symbols.

Parameter Description
Signing used Sk ID UE 1 : Public key of UE i Step 1. UE 1 → AS 1 : Request, ID UE 1 , Sig Sk UE 1 (Requset) UE 1 requests the cross domain authority from AS 1 and uses the private key Sk UE 1 to generate signature Sig Sk UE 1 (Requset); Step 2. After verifying the UE 1 request, AS 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.

Cross-Domian Authentication Process
It is assumed that the device UE 1 in the security domain D 1 initiates an authentication request to the authentication server AS 2 in security domain D 2 . The authentication process is shown in Figure 4. The symbol definition in the authentication process is shown in Table 3. The procedure of protocol is described as follows: 1.
UE 1 → AS 2 : Access request, ID UE 1 UE 1 initiate an authentication request to authentication server AS 2 in D 2 .

2.
AS 2 → UE 1 : {N 1 } After receiving the request from UE 1 , D 2 authentication server AS 2 responds to the request and sends a random number N 1 to D 1 device UE 1 . 3.
Device UE 1 receive the response from authentication server AS 2 using its private key Sk UE 1 to generate a signature Sig Sk UE 1 (N 1 ) of random number N 1 ; (2) UE 1 responds to the request of AS 2 and send the signature Sig Sk UE 1 (N 1 ) and random number N 1 are sent to AS 2 .
(2) AS 2 queries the result of authority from Blockchain.

5.
BC → AS 2 : Authority 1 (1) If there is no authority of UE 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 "Authority 1 ". If the authentication succeeds, the authentication passes; otherwise, the authentication fails.
If the authorization for UE 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.

Parameter Description
Public key of

Cross-Domian Authentication Process
It is assumed that the device 1 in the security domain D1 initiates an authentication request to the authentication server AS2 in security domain D2. The authentication process is shown in Figure 4. The symbol definition in the authentication process is shown in Table 3. The procedure of protocol is described as follows: Table 3. Description of symbols. Parameter Description Public key of Signing used ℎ ； Authority of 1. 1 → 2 : { , 1 } 1 initiate an authentication request to authentication server 2 in D2.

2.
2 → 1 ：{ 2 } After receiving the request from 1 , D2 authentication server 2 responds to the request and sends a random number 1 to D1 device 1 .

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.

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 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.
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 shows the schematic codes.  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 shows the schematic codes.

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

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.

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. cessing Performance of Authorization Verify this experiment, we evaluate the processing performance of authorization verify. Sim the threshold T as a variable. The test cast is re-executed for 100 times and the average

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

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. 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 summarizes the calculation and communication costs of different schemes. Table 7. Computation time consuming.

Description Time (ms)
Identity-based signature (T IDS ) Table 8. Analysis for overhead of computation and communication.

Schemes Computational Cost Delay (ms) Communication Cost (bit)
EIMAKP-I User T IDV + T AV + 2T PE + 2T PD + T SE + TSD + 3TM + TP + H M 116.25 1808 Server T AV + 2T PD + T SE +T SD + T IDS + 3T AS + T AV + 3T PE + T PD + T SE + T SD + 2 TP + 2H M + H P EIMAKP-II User T IDV + T AS + 2T PE +T PD + T SE + T SD + H P 111.05 1408 Server T IDV + 2T PD + T SE + T SD + 2T IDS + T AS + 2T AV + 2T PE + T PD + T SE + T SD T IDV + T IDTV 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.
Electronics 2020, 9, x FOR PEER REVIEW 18 of 21 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.

Conclusion
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 crossdomain 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.