# A Lightweight Authentication Scheme Based on Consortium Blockchain for Cross-Domain IoT

Authors: Yujian Zhang; Yuhao Luo; Xing Chen; Fei Tong; Yuwei Xu; Jun Tao; Guang Cheng
Journal: Security and Communication Networks
 (2022)

---

## Abstract

Internet of Things (IoT) has been ubiquitous in both industrial and living areas, but also known for its weak security. Being as the first defense line against various cyberattacks, authentication is even more critical to IoT applications. Moreover, there has been a growing demand for cross-domain collaboration, leading to an increasing need for cross-domain authentication. Recently, certificate-based authentication schemes have been extensively studied. However, many of these schemes are not efficient in computation, storage, and communication, which are highly required in IoT. In this paper, we propose a lightweight authentication scheme based on consortium blockchain and design a cryptocurrency-like digital token to build trust. Furthermore, trust lifecycle management is performed by manipulating the amount of tokens. The comprehensive analysis and evaluation demonstrate that the proposed scheme is resistant to various common attacks and more efficient than competitor schemes in terms of storage, communication, and authentication cost.


---

## Body

## 1. Introduction

With the great power of bridging the physical world to the cyberspace, the Internet of Things (IoT) brings new paradigms for supporting diverse applications, such as smart cities, transportation, manufacturing, agriculture, and healthcare. According to a Statista report, the number of global IoT devices is forecast to triple from 8.74 billion in 2020 to more than 25.4 billion in 2030 [1]. The surging number suggests that IoT technology has been deeply involved in our daily lives. However, while enjoying the significant convenience brought by IoT, we need to be aware that IoT is still facing a bunch of challenges. The most critical one should be IoT security, since most IoT devices are limited in computation, storage, and network capacity; they have weak security and are more vulnerable to cyberattacks [2]. For example, in 2016, Mirai botnet took control of millions of IoT devices and launched an incredibly powerful Distributed Deny-of-Service (DDoS) attack [3]. Moreover, as reported by Gartner, 20% of organizations have experienced at least one IoT attack in the past three years [4]. Hence, there is an urgent demand for defensive strategies to protect IoT applications.Serving as the first defense line against various attacks, authentication is the most effective way to prevent unauthorized access and other potential threats, which is particularly crucial in IoT scenarios [5]. Specifically, IoT authentication refers to a model for building trust in the identities of IoT devices through an unsecured network, such as Internet. With the wide range of deployment, IoT devices from different domains have an increasing need to communicate with each other for better collaboration, as shown in Figure 1. For example, smart vehicles administered by different local government agencies construct a Vehicular Ad hoc Network (VANET) for intelligent transportation applications. More industrial IoT devices from different factories are organized to work collaboratively to improve the productivity of manufacturing. For security concerns, none of these domain administrators will allow their devices to be accessed from outside without authentication. However, building trust across different domains is a nontrivial task since it can refer to some sensitive data, which is more likely to be preserved within its own domain.Figure 1
An example scenario of cross-domain IoT collaboration.Existing IoT authentication methods are popularly based on the well-known Public Key Infrastructure (PKI) [6–14], which is built on top of asymmetric cryptography with public-private key pairs and uses certificates to authenticate the identities of individuals, devices, and other entities. Each PKI system depends on a Trusted Third Party (TTP) named Certificate Authority (CA) to provide the root of trust for all certificates. As long as these CAs are not compromised, IoT devices from outside domains can be authenticated by showing certificates signed by their administrative CAs. However, certificate management, including issuance, distribution, and revocation, requires significant efforts [13, 14] and is prone to misoperations [15]. To mitigate the management overhead in PKI-based methods, Identity-Based Cryptography (IBC) uses a publicly known string as the public key [16]. The private key is generated by another TTP, named Key Generation Center (KGC), which introduces a key-escrow problem and limits the mobility of IoT devices. Besides, both PKI-based and IBC-based methods rely on a TTP, which makes them suffer a threat of single-point failure.As an emerging technology for building trust, blockchain has attracted an increasing interest in IoT authentication. Many current research studies incorporate blockchain into conventional authentication methods to avoid their drawbacks [17–20]. For example, CA transparency can be largely improved when certificate histories are recorded in the distributed public ledger of blockchain [17]. Considering the model of cross-domain authentication, some research studies employ delegated agencies (e.g., IBC [21, 22] and private blockchain [23]) for IoT devices to participate in the blockchain system. However, blockchain-based certificate authentication retains the issues in the PKI method, such as local resource requirements and management overhead. Although delegated agencies can mitigate IoT resource limitations, they re-introduce the risk of single-point failure and complicate the authentication infrastructure. On the contrary, blockchain technology is still under development due to its high latency and energy consumption, especially for public blockchain (e.g., Bitcoin [24] and Ethereum [25]). Therefore, employing blockchain for cross-domain IoT authentication still remains several challenges, such as improving efficiency on computation and storage for cryptographic keys, lightweight authenticity lifecycle management, and transparency of authorities.Among different types of blockchain, consortium blockchain is a permissioned network, in which each entity needs a prior approval before joining an organization and works collaboratively across different organizations. Motivated by the fact that its structure well matches the model of cross-domain IoT, we propose a lightweight authentication scheme for cross-domain IoT based on consortium blockchain. The main idea is to utilize a digital token, named LiIDCoin (Lightweight IDentity Coin), to represent the trust of the identity of an IoT device or an entity (we will use them interchangeably in later sections). Different from most existing blockchain-based methods, such as CertCoin [18], AuthCoin [19], and CeCoin [20], which leverage blockchain to store public keys, challenge-response messages, and certificates, respectively, LiIDCoin is more like a cryptocurrency equipped with a set of coin operations to realize authentication process and lifecycle management. In this way, costs of computation, communication, and storage for authentication as well as lifecycle management efforts can be significantly reduced, which is highly preferable for IoT applications. This paper is an extend version of work published in [26]. We extend our previous work by adapting the method to IoT scenarios and conducting extensive experiments for detailed evaluations. The main contributions of this paper are summarized as follows.We propose a framework for cross-domain IoT authentication based on consortium blockchain by exploiting their well-matched architectures and the underlying idea of cryptocurrency to build trust between entitiesWe design a novel data structure based on the unspent transaction output (UTXO) coupled with a suite of coin operations, including issuance, transfer, query, and revocation, to support authentication and lifecycle managementWe perform comprehensive security analysis and implement a prototype on the HyperLedger Fabric (HLF) platform to validate the effectiveness and efficiency of the proposed schemeThe rest of this paper is organized as follows. Section2 reviews recent literature on IoT authentication mechanisms, while Section 3 presents main preliminaries for the stated problem. Section 4 provides the framework of the proposed scheme, followed with the design details in Section 5. The security analysis and performance evaluation of the proposed scheme are given in Section 6 and Section 7, respectively. Finally, Section 8 concludes the work.


## 2. Related Work

A majority of studies have been focused on PKI-based methods since it can realize distributed public key authentication as well as offering good scalability [6]. Azees et al. proposed a certificate-based authentication scheme with conditional privacy preservation for VANETs [7]. Vijayakumar et al. utilized short-term certificates to achieve anonymous authentication in IoT-based Wireless Body Area Networks (WBANs) [8]. Li et al. pushed CA functions closer to IoT nodes to minimize attack surfaces and authentication latency for smart living [9]. To accelerate certificate validation, Wang et al. cached and maintained validated certificates in a memory pool made up by all IoT devices [10]. In view of the resource-limited nature, delegated nodes, such as gateways [11] and mobile agents [12], were designated to perform complex functionalities for IoT devices. Ma et al. built a consensus of trust for IoT devices by sharing certain information among distributed nodes [27]. Besides, Li et al. considered the revoked certificates [13] and further proposed certificate update protocols to concern the whole lifecycle [14]. Admittedly, the cryptographic and management overhead of PKI-based methods has never been ignorable. Although Identity-Based Cryptography (IBC) [16] and Certificateless Signature (CLS) [28] remove the certificate management, they necessitate the need for a Key Generation Center (KGC), which limits the mobility of IoT devices and still suffer a threat of single-point failure.The emergence of blockchain technology with characteristics including unforgeability, redundancy, and transparency has revolutionized conventional authentication. Fromknecht et al. maintained domains and their associated public keys on the blockchain, named CertCoin, to build an alternative PKI [18]. Instead of public key bindings, Leiding et al. proposed an AuthCoin scheme to store challenge-response information for validation and authentication of public keys on the blockchain [19]. Qin et al. provided CeCoin services of multicertificate and identity assignment through blockchain transactions [20]. Hammi et al. created secure virtual zones (bubbles) for IoT authentication in between by manipulating bubble settings on a public blockchain [29]. For cross-domain scenarios, Jia et al. utilized IBC to authenticate local IoT entities and authorized them to access cross-domain resources through a threshold cryptographic algorithm on blockchain [21]. Li et al. deployed a private blockchain for each local domain and applied a cross-chain technology to the cross-domain IoT authentication through a public blockchain [23]. Shen et al. proposed a Blockchain-Assisted Secure Authentication (BASA) mechanism that integrated consortium blockchain with IBC to authenticate cross-domain industrial IoT devices for smart manufacturing [22]. Besides, benefiting from the public ledger, blockchain is able to build trust among entities and perform trust management in an open and distributed environment [30].The above studies provide promising solutions for IoT authentications, but there still remains several challenges. First, the computational and storage efficiency should be improved, especially in solutions which employ complex cryptographic primitives for security and privacy. Second, optimization on authenticity lifecycle management is highly desired, especially in the process of revocation due to its negative impacts on system scalability and efficiency. Third, activities of authorities should be transparent and those of authentication should be accountable. Although blockchain has been introduced for auditing these activities or incorporated into authentication process, in this paper, we attempt to make an in-depth integration by exploring native features of consortium blockchain.


## 3. Preliminaries

This section presents problem statement, analysis of classical PKI-based solution, and design goals of this work.


### 3.1. Problem Statement

The problem studied in this paper is illustrated in Figure2. Authentication is required between two entities, EXi and EYj, which belong to domain X and Y, respectively. For the case that EXi is authenticated by EYj, EXi is called the clamiant and EYj is called the verifier. In each domain, there is a centralized agency, named Trusted Authority (TA), to play roles of both an administrator and an endorser. As an administrator, a TA validates entity enrollments and maintains their legitimacies. Once accepting an entity, TA is also responsible for endorsing for its identification through various forms, such as certificates. Such a kind of architecture is quite common in practice to facilitate effective management within a domain. Therefore, the problem studied in this paper is “How to enable entities from different domains to authenticate each other in an IoT-applicable manner?”. In other words, the authentication infrastructure should be lightweight to meet the resource-limited and distributed nature of IoT devices.Figure 2
Problem overview of cross-domain IoT authentication.Most authentication schemes heavily rely on the following cryptographic primitives, which are also assumed to supported by the IoT devices in this paper.


#### 3.1.1. Digital Signature

A digital signature is a way of authenticating a digital data coming from a trusted source, which is typically represented by a tuple of three algorithmsGen,Sign,Verify. The key generation algorithm Gen1λ⟶pk,sk takes the security parameter 1λ as input and outputs a pair of public/private keys pk,sk. The signing algorithm Signsk,m⟶σ uses a private key sk to generate a signature σ on a message m, while the verification algorithm verifies the signature σ on message m through the public key pk, returning 1 if valid or ⊥ otherwise.


#### 3.1.2. Hash Function

A collision-resistant hash functionH·, defined by H:0,1∗⟶0,1l, takes an arbitrary length string as input and outputs a fixed length (l bits) hash value, which is extremely hard to be generated from another different input. Hence, H· is widely used for digesting large data.Table1 lists the key notations used in this paper.Table 1
Key notations.
NotationsDescriptionEXiTheith entity of domain XTAX and TAYTrusted authority of domainX and YpkZ and skZPublic key and private key of entity/TAZIDZ and CertZIdentity and certificate of entity/TAZSigZ·Signature function by entity/TAZH·Hash function0,1∗⟶0,1l∥Concatenate operationpA large primeZpCurve base field,Zp=0,1,…,p−1EZpCurve equation overZpa,bParameters of curve equation,a,b∈ZpGCurve base pointnCurve order


### 3.2. PKI-Based Solution

PKI provides a competitive solution to the stated problem by allowing TA to create, distribute, and revoke digital certificates for entity identification. Figure3 demonstrates the working mechanism of PKI-based solution, in which EXi is authenticated by EYj. First, EXi needs to register in TAX to get a certificate CertEXi represented by(1)CertEXi=IDEXi∥pkEXi∥Date∥Issuer∥Algorithm∥SigTAX·,where Date indicates the expiration time, Issuer represents its authority (e.g., TAX), and Algorithm denotes cryptographic primitives used to generate the certificate. Then, certificate of TAX, denoted as CertTAX, should be preinstalled in EYj as a trust anchor. The whole authentication process consists of four steps to not only validate the legitimacies of CertEXi and SigEXi once sent to EYj in step ① but also confirm its validity through Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) by steps ② and ③. Finally, step ④ gives the decision. Mutual authentication can be implemented by adding an inverse pass.Figure 3
Unilateral authentication of PKI-based solution.Although PKI provides an effective scheme for cross-domain IoT authentication, it still needs improvement on performance and security. On the one hand, PKI certificate requires resources for cryptographic computation, storage, and communication, which could not be affordable for resource-critical IoT devices and certificate management costs’ significant maintenance efforts. On the other hand, a certificate typically binds personal information with the public key, which could violate privacy preservation, and CA transparency still remains as a security issue in IoT scenarios.


### 3.3. Design Goals

A practical authentication scheme for cross-domain IoT authentication should accommodate the following requirements.


#### 3.3.1. Lightweight

Local resources required to accomplish authentication should be as low as possible for IoT devices. Moreover, relevant management efforts are also expected to be mitigated.


#### 3.3.2. Security

Due to the open nature of IoT environment, the authentication scheme should be resistant against common cyberattacks.


#### 3.3.3. Mobility

With the development of mobile computing and 5G technologies, there exhibits a growing demand for roaming, in which a IoT device needs to access the authentication service across its administrative domain.


## 3.1. Problem Statement

The problem studied in this paper is illustrated in Figure2. Authentication is required between two entities, EXi and EYj, which belong to domain X and Y, respectively. For the case that EXi is authenticated by EYj, EXi is called the clamiant and EYj is called the verifier. In each domain, there is a centralized agency, named Trusted Authority (TA), to play roles of both an administrator and an endorser. As an administrator, a TA validates entity enrollments and maintains their legitimacies. Once accepting an entity, TA is also responsible for endorsing for its identification through various forms, such as certificates. Such a kind of architecture is quite common in practice to facilitate effective management within a domain. Therefore, the problem studied in this paper is “How to enable entities from different domains to authenticate each other in an IoT-applicable manner?”. In other words, the authentication infrastructure should be lightweight to meet the resource-limited and distributed nature of IoT devices.Figure 2
Problem overview of cross-domain IoT authentication.Most authentication schemes heavily rely on the following cryptographic primitives, which are also assumed to supported by the IoT devices in this paper.


### 3.1.1. Digital Signature

A digital signature is a way of authenticating a digital data coming from a trusted source, which is typically represented by a tuple of three algorithmsGen,Sign,Verify. The key generation algorithm Gen1λ⟶pk,sk takes the security parameter 1λ as input and outputs a pair of public/private keys pk,sk. The signing algorithm Signsk,m⟶σ uses a private key sk to generate a signature σ on a message m, while the verification algorithm verifies the signature σ on message m through the public key pk, returning 1 if valid or ⊥ otherwise.


### 3.1.2. Hash Function

A collision-resistant hash functionH·, defined by H:0,1∗⟶0,1l, takes an arbitrary length string as input and outputs a fixed length (l bits) hash value, which is extremely hard to be generated from another different input. Hence, H· is widely used for digesting large data.Table1 lists the key notations used in this paper.Table 1
Key notations.
NotationsDescriptionEXiTheith entity of domain XTAX and TAYTrusted authority of domainX and YpkZ and skZPublic key and private key of entity/TAZIDZ and CertZIdentity and certificate of entity/TAZSigZ·Signature function by entity/TAZH·Hash function0,1∗⟶0,1l∥Concatenate operationpA large primeZpCurve base field,Zp=0,1,…,p−1EZpCurve equation overZpa,bParameters of curve equation,a,b∈ZpGCurve base pointnCurve order


## 3.1.1. Digital Signature

A digital signature is a way of authenticating a digital data coming from a trusted source, which is typically represented by a tuple of three algorithmsGen,Sign,Verify. The key generation algorithm Gen1λ⟶pk,sk takes the security parameter 1λ as input and outputs a pair of public/private keys pk,sk. The signing algorithm Signsk,m⟶σ uses a private key sk to generate a signature σ on a message m, while the verification algorithm verifies the signature σ on message m through the public key pk, returning 1 if valid or ⊥ otherwise.


## 3.1.2. Hash Function

A collision-resistant hash functionH·, defined by H:0,1∗⟶0,1l, takes an arbitrary length string as input and outputs a fixed length (l bits) hash value, which is extremely hard to be generated from another different input. Hence, H· is widely used for digesting large data.Table1 lists the key notations used in this paper.Table 1
Key notations.
NotationsDescriptionEXiTheith entity of domain XTAX and TAYTrusted authority of domainX and YpkZ and skZPublic key and private key of entity/TAZIDZ and CertZIdentity and certificate of entity/TAZSigZ·Signature function by entity/TAZH·Hash function0,1∗⟶0,1l∥Concatenate operationpA large primeZpCurve base field,Zp=0,1,…,p−1EZpCurve equation overZpa,bParameters of curve equation,a,b∈ZpGCurve base pointnCurve order


## 3.2. PKI-Based Solution

PKI provides a competitive solution to the stated problem by allowing TA to create, distribute, and revoke digital certificates for entity identification. Figure3 demonstrates the working mechanism of PKI-based solution, in which EXi is authenticated by EYj. First, EXi needs to register in TAX to get a certificate CertEXi represented by(1)CertEXi=IDEXi∥pkEXi∥Date∥Issuer∥Algorithm∥SigTAX·,where Date indicates the expiration time, Issuer represents its authority (e.g., TAX), and Algorithm denotes cryptographic primitives used to generate the certificate. Then, certificate of TAX, denoted as CertTAX, should be preinstalled in EYj as a trust anchor. The whole authentication process consists of four steps to not only validate the legitimacies of CertEXi and SigEXi once sent to EYj in step ① but also confirm its validity through Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) by steps ② and ③. Finally, step ④ gives the decision. Mutual authentication can be implemented by adding an inverse pass.Figure 3
Unilateral authentication of PKI-based solution.Although PKI provides an effective scheme for cross-domain IoT authentication, it still needs improvement on performance and security. On the one hand, PKI certificate requires resources for cryptographic computation, storage, and communication, which could not be affordable for resource-critical IoT devices and certificate management costs’ significant maintenance efforts. On the other hand, a certificate typically binds personal information with the public key, which could violate privacy preservation, and CA transparency still remains as a security issue in IoT scenarios.


## 3.3. Design Goals

A practical authentication scheme for cross-domain IoT authentication should accommodate the following requirements.


### 3.3.1. Lightweight

Local resources required to accomplish authentication should be as low as possible for IoT devices. Moreover, relevant management efforts are also expected to be mitigated.


### 3.3.2. Security

Due to the open nature of IoT environment, the authentication scheme should be resistant against common cyberattacks.


### 3.3.3. Mobility

With the development of mobile computing and 5G technologies, there exhibits a growing demand for roaming, in which a IoT device needs to access the authentication service across its administrative domain.


## 3.3.1. Lightweight

Local resources required to accomplish authentication should be as low as possible for IoT devices. Moreover, relevant management efforts are also expected to be mitigated.


## 3.3.2. Security

Due to the open nature of IoT environment, the authentication scheme should be resistant against common cyberattacks.


## 3.3.3. Mobility

With the development of mobile computing and 5G technologies, there exhibits a growing demand for roaming, in which a IoT device needs to access the authentication service across its administrative domain.


## 4. Overview of the Proposed Scheme

This section presents the framework of the proposed scheme and describes the main components. Design details will be given in the next section.


### 4.1. Framework

The whole framework, as demonstrated in Figure4, can be majorly divided into two layers, namely, entity layer and trust layer. The former represents IoT devices, each of which belongs to a specific domain. The latter layer provides a cross-domain authentication service built on top of consortium blockchain. Specifically, domain administrative servers are organized to create a Peer-to-Peer (P2P) network. Based on that, blockchain is deployed to build a consensus on entity states including their legitimacies and authentication activities. As consortium blockchain is introduced in the proposed scheme, a PKI system is incorporated to identify permissioned entities within the blockchain. In this way, each legal entity will be assigned with a domain-specific certificate, representing a trust anchor for the entity in the trust layer. For example, trust anchors of entity EXi and EYj in Figure 4 are certificate CertEXi and CertEYj, respectively. It is worth mentioning that, although PKI is also employed as the trust facility in our scheme, it will be used internally inside the blockchain thus can largely benefit security enhancement and save management effort. Moreover, instead of explicitly exchanging certificates, the proposed scheme accomplishes a fast and secure identification through a transaction of specific digital token.Figure 4
Layered framework of the proposed authentication scheme.


### 4.2. LiIDCoin: A UTXO Data Structure

We develop a digital token for identifying entity, named LiIDCoin, based on the unspent transaction output (UTXO) data structure, which has been successfully applied in Bitcoin [24]. However, instead of free circulation in Bitcoin, LiIDCoin emphasizes token’s specificity and one-time use.Table2 lists the key items of LiIDCoin data structure, which is composed of three parts: basic, in, and out. The basic is a common part in a blockchain transaction. Tx_id is a unique string to identify a LiIDCoin transaction. Timestamp denotes the submission time of the transaction. Script represents the operation name for generating the current transaction, which can be defined as a reference to a smart contract or a script. Signature is used to prove sender’s agreement on the transaction. The in part of LiIDCoin describes the source of the token. Sender_id is a unique hash value to represent the address of token sender (e.g., IDTAX or IDEXi). Note that such a hash value is generated as a pseudonym to hide the real identity of an entity once enrolled. Type is an entity-specific attribute to restrict tokens to being only used by their original owner, which can be implemented by binding it with some entity-specific information. Furthermore, endorser information should be retained for validating management operations. To this end, the certificate of an entity could be a good candidate. For purposes of effective storage and communication, we use a hash value of certificate. For a specific entity EXi, we have(2)TypeEXi=HCertEXi,which implies that such tokens can only be spent by EXi and are endorsed by its authority TAX. In the out part, Recipient_id and Quantity represent the recipient address (e.g., IDEYj or IDTAX) and the amount of transferred tokens, respectively. For authentication, one token is sufficient to indicate the activity. Note that there can be more than one out field to represent multiple token recipients. For example, one token is spent for authentication while others remain in balance by being transferred to the owner itself.Table 2
Key items of the LiIDCoin data structure.
ItemNameDescriptionBasicTx_idTransaction IDTimestampTransaction submission timeScriptOperation nameSignatureSignature of senderInSender_idTA/Entity IDTypeToken type (hash of sender’s certificate)Out[..]Recipient_idTA/Entity IDQuantityToken amount (1 for authentication)


### 4.3. Trust Layer

In the proposed scheme, the trust layer is the key infrastructure to provide cross-domain authentication service, which is accomplished by consortium blockchain underneath. It is a trusted distributed ledger composed of blocks encapsulating numbers of transactions, which record entity states of token ownership and transfer activities. The trust layer can be further divided into the following three sublayers.


#### 4.3.1. Hardware

Administrative servers of different domains are organized to create the P2P network for blockchain. On the one hand, each server plays the role of a full node in blockchain network to store a complete copy of the ledger as well as running blockchain software (e.g., HLF). On the other hand, as located in its local domain, each administrative server is responsible for domain administration as a TA and handling all regional service requests, including those from roaming entities, to minimize network delays.


#### 4.3.2. Blockchain

Blockchain maintains a global distributed ledger of transactions, which carries the entire history of digital tokens. Furthermore, blockchain is responsible for building a consensus on token states among all peering servers. To realize prospective and automatic token state transition, smart contracts that implement authentication service logics are priorly installed on blockchain peers.


#### 4.3.3. PKI

Since the consortium blockchain is permissioned, each entity has to be a member of an organization in the blockchain. Consequently, PKI is deployed internally for on-chain identification, providing features such as entity registration and certificate management. As long as these certificates are never delivered for any external use, security risks and management efforts can be significantly reduced. Thus, each entity can be anchored to a long-term certificate in the system.


### 4.4. Entity Layer

The entity layer contains diverse IoT devices that have basic capabilities of processing encryption and network communication, such as smart vehicles, drones, and manufacturing robots. Note that some of them (e.g., vehicles and drones) have a vital requirement for mobility, which implies location-fixed delegated nodes or key centers could not be available when such IoT devices move into a foreign domain. Therefore, the authentication scheme should be feasible to address the mobility requirement.By anchoring to a PKI certificate in the blockchain, each entity essentially has a roamable account for authentication service as long as it can connect to any regional administrative server. The private key for generating the certificate is the root of entity control over all LiIDCoins associated with the corresponding address. Moreover, identity lifecycle management is implemented by manipulating the amount of LiIDCoins, rather than key managements (e.g., renewal and revocation) in conventional schemes.


## 4.1. Framework

The whole framework, as demonstrated in Figure4, can be majorly divided into two layers, namely, entity layer and trust layer. The former represents IoT devices, each of which belongs to a specific domain. The latter layer provides a cross-domain authentication service built on top of consortium blockchain. Specifically, domain administrative servers are organized to create a Peer-to-Peer (P2P) network. Based on that, blockchain is deployed to build a consensus on entity states including their legitimacies and authentication activities. As consortium blockchain is introduced in the proposed scheme, a PKI system is incorporated to identify permissioned entities within the blockchain. In this way, each legal entity will be assigned with a domain-specific certificate, representing a trust anchor for the entity in the trust layer. For example, trust anchors of entity EXi and EYj in Figure 4 are certificate CertEXi and CertEYj, respectively. It is worth mentioning that, although PKI is also employed as the trust facility in our scheme, it will be used internally inside the blockchain thus can largely benefit security enhancement and save management effort. Moreover, instead of explicitly exchanging certificates, the proposed scheme accomplishes a fast and secure identification through a transaction of specific digital token.Figure 4
Layered framework of the proposed authentication scheme.


## 4.2. LiIDCoin: A UTXO Data Structure

We develop a digital token for identifying entity, named LiIDCoin, based on the unspent transaction output (UTXO) data structure, which has been successfully applied in Bitcoin [24]. However, instead of free circulation in Bitcoin, LiIDCoin emphasizes token’s specificity and one-time use.Table2 lists the key items of LiIDCoin data structure, which is composed of three parts: basic, in, and out. The basic is a common part in a blockchain transaction. Tx_id is a unique string to identify a LiIDCoin transaction. Timestamp denotes the submission time of the transaction. Script represents the operation name for generating the current transaction, which can be defined as a reference to a smart contract or a script. Signature is used to prove sender’s agreement on the transaction. The in part of LiIDCoin describes the source of the token. Sender_id is a unique hash value to represent the address of token sender (e.g., IDTAX or IDEXi). Note that such a hash value is generated as a pseudonym to hide the real identity of an entity once enrolled. Type is an entity-specific attribute to restrict tokens to being only used by their original owner, which can be implemented by binding it with some entity-specific information. Furthermore, endorser information should be retained for validating management operations. To this end, the certificate of an entity could be a good candidate. For purposes of effective storage and communication, we use a hash value of certificate. For a specific entity EXi, we have(2)TypeEXi=HCertEXi,which implies that such tokens can only be spent by EXi and are endorsed by its authority TAX. In the out part, Recipient_id and Quantity represent the recipient address (e.g., IDEYj or IDTAX) and the amount of transferred tokens, respectively. For authentication, one token is sufficient to indicate the activity. Note that there can be more than one out field to represent multiple token recipients. For example, one token is spent for authentication while others remain in balance by being transferred to the owner itself.Table 2
Key items of the LiIDCoin data structure.
ItemNameDescriptionBasicTx_idTransaction IDTimestampTransaction submission timeScriptOperation nameSignatureSignature of senderInSender_idTA/Entity IDTypeToken type (hash of sender’s certificate)Out[..]Recipient_idTA/Entity IDQuantityToken amount (1 for authentication)


## 4.3. Trust Layer

In the proposed scheme, the trust layer is the key infrastructure to provide cross-domain authentication service, which is accomplished by consortium blockchain underneath. It is a trusted distributed ledger composed of blocks encapsulating numbers of transactions, which record entity states of token ownership and transfer activities. The trust layer can be further divided into the following three sublayers.


### 4.3.1. Hardware

Administrative servers of different domains are organized to create the P2P network for blockchain. On the one hand, each server plays the role of a full node in blockchain network to store a complete copy of the ledger as well as running blockchain software (e.g., HLF). On the other hand, as located in its local domain, each administrative server is responsible for domain administration as a TA and handling all regional service requests, including those from roaming entities, to minimize network delays.


### 4.3.2. Blockchain

Blockchain maintains a global distributed ledger of transactions, which carries the entire history of digital tokens. Furthermore, blockchain is responsible for building a consensus on token states among all peering servers. To realize prospective and automatic token state transition, smart contracts that implement authentication service logics are priorly installed on blockchain peers.


### 4.3.3. PKI

Since the consortium blockchain is permissioned, each entity has to be a member of an organization in the blockchain. Consequently, PKI is deployed internally for on-chain identification, providing features such as entity registration and certificate management. As long as these certificates are never delivered for any external use, security risks and management efforts can be significantly reduced. Thus, each entity can be anchored to a long-term certificate in the system.


## 4.3.1. Hardware

Administrative servers of different domains are organized to create the P2P network for blockchain. On the one hand, each server plays the role of a full node in blockchain network to store a complete copy of the ledger as well as running blockchain software (e.g., HLF). On the other hand, as located in its local domain, each administrative server is responsible for domain administration as a TA and handling all regional service requests, including those from roaming entities, to minimize network delays.


## 4.3.2. Blockchain

Blockchain maintains a global distributed ledger of transactions, which carries the entire history of digital tokens. Furthermore, blockchain is responsible for building a consensus on token states among all peering servers. To realize prospective and automatic token state transition, smart contracts that implement authentication service logics are priorly installed on blockchain peers.


## 4.3.3. PKI

Since the consortium blockchain is permissioned, each entity has to be a member of an organization in the blockchain. Consequently, PKI is deployed internally for on-chain identification, providing features such as entity registration and certificate management. As long as these certificates are never delivered for any external use, security risks and management efforts can be significantly reduced. Thus, each entity can be anchored to a long-term certificate in the system.


## 4.4. Entity Layer

The entity layer contains diverse IoT devices that have basic capabilities of processing encryption and network communication, such as smart vehicles, drones, and manufacturing robots. Note that some of them (e.g., vehicles and drones) have a vital requirement for mobility, which implies location-fixed delegated nodes or key centers could not be available when such IoT devices move into a foreign domain. Therefore, the authentication scheme should be feasible to address the mobility requirement.By anchoring to a PKI certificate in the blockchain, each entity essentially has a roamable account for authentication service as long as it can connect to any regional administrative server. The private key for generating the certificate is the root of entity control over all LiIDCoins associated with the corresponding address. Moreover, identity lifecycle management is implemented by manipulating the amount of LiIDCoins, rather than key managements (e.g., renewal and revocation) in conventional schemes.


## 5. Design Details

This section elaborates the design details of the proposed authentication scheme.


### 5.1. Initialization

The initialization phase is executed by the trust layer when the consortium blockchain is deployed on administrative servers from different domains. The main job is to select system parameters, including hash function and Elliptic Curve Cryptography (ECC), which is quite similar to the setup phase in the PKI system. The hash functionH· can be SHA-1 or more secure version. Meanwhile, a nonsingular elliptic curve in the following form is selected:(3)x,y∈Zp2|y2≡x3+ax+bmodp,4a3+27b2≡0modp∪O,where p is a large prime, a,b∈Zp are two constants, and O is the point at infinity. Then, a base point G is picked on the curve whose order is n such that n·G=O.The above parameters make a parameter tupleH·,p,a,b,G,n, which will be published both inside and outside the blockchain. Note that, as long as the hash function and ECC are secure, publishing these parameters will not affect the resistance ability against cryptography attacks. Furthermore, according to the concept of consortium blockchain, to join in the system, all participants, including domain administrators (e.g., TAX and TAY), need to generate a public-private key pair by(4)pk=sk·G,sk∈Zp,where sk is the private key randomly selected from Zp and pk is the public key. At the end of the initialization phase, each domain administrative TA publishes its public key inside the blockchain while keeping its private key as secret.


### 5.2. Off-Chain Registration

Each entity needs to register at its administrative TA to get engaged in the blockchain-based authentication service by the following off-chain steps.(1)
Firstly, an entity, such asEXi, gets the public parameter tuple from the blockchain and generates a public-private key pair (skEXi, pkEXi) according to equation (4). Then, it submits its real identity and public key pkEXi to its administrator TAX through an internal and secure channel.(2)
Secondly,TAX verifies EXi’s real identity to generate a certificate CertEXi as its trust anchor within the blockchain and then calculates EXi’s address on the blockchain by IDEXi=HpkEXi. Besides, TAX activates EXi’s authentication service through issuing a certain amount of LiIDCoins to the address IDEXi, which will be detailed in Section 5.3.1.(3)
Finally,TAX returns the address value IDEXi to EXi as a pseudonym for the rest phases. So far, the entity has completed the registration and only needs to keep the private key skEXi in the local device. It is worth noting that the certificate has never been exposed to the outside of the blockchain.


### 5.3. On-Chain Operations

After finishing registration, the entity obtains the authentication service through a set of on-chain operations on LiIDCoins, which covers the whole lifecycle of its identity.


#### 5.3.1. Issue

As mentioned above,TAX issues a certain amount of LiIDCoins to activate a validated entity EXi during the registration phase. This is implemented by a transaction from TAX to EXi in the following form of UXTO:(5)basic=tx_id∥t∥issue∥SigTAX·in=IDTAX∥HCertEXiout=IDEXi∥Qissue,where tx_id is a transaction ID generated by the blockchain, t is the timestamp when the transaction is created, issue indicates the operation name, SigTAX· shows the approval for the transaction from TAX, IDTAX and IDEXi denote that the transaction is launched by TAX and sent to EXi, HCertEXi is used to define the entity-specific type of these LiIDCoins, and Qissue is the quantity of issued LiIDCoins. According to the queuing theory, Qissue can be calculated by(6)Qissue=λW,where λ is the arrival rate of LiIDCoin transactions and W is the processing time per transaction.


#### 5.3.2. Transfer

A successful LiIDCoin transfer fromEXi to EYj reveals two facts: on one side, claimantEXi has the ability to launch a transfer endorsed by TAX, which is equivalent to showing a certificate signed by its CA in PKI, thus claiming the legitimacy of EXi. On the other side, such a transfer activity is recorded as a transaction on the blockchain, which will be confirmed by the verifierEYj as well as be used for auditing purposes. The UXTO for the transfer operation is formulated by(7)basic=tx_id∥t∥transfer∥SigEXi·in=IDEXi∥HCertEXiout=IDEYj∥1IDEXi∥Qbalance−1,where transfer indicates the operation name, SigEXi· is the transaction approval from EXi, IDEXi in in part denotes LiIDCoins in this transaction are coming from EXi while two recipients exist in the out part, with 1 for EYj and the rest for the change, respectively, and Qbalance is the number of LiIDCoins owned by EXi before this transaction.As aforementioned, LiIDCoin has a one-time use property, which is essentially different from other digital tokens. This is implemented by theType attribute, which is instantiated as HCertEXi for entity EXi. Before the transaction is actually recorded in the blockchain, it will be validated to ensure that the Type value conforms to the declared sender by verifying its signature in the UTXO and recalculating the hash value of its certificate. For example, supposing that EYj intends to spend the LiIDCoin that it has just received from EXi in equation (7), EYj needs to fill the in part as IDEYj∥HCertEXi. Note that Type is a read-only attribute once a LiIDCoin is issued by the TA, which implies that EYj cannot alter it to its own hash value (e.g., HCertEYj). In this case, the Type value will not conform to the signature for this transaction, leading to a rejection by the blockchain system.


#### 5.3.3. Query

The query operation is quite straightforward but essential to confirm the authenticity of an entity. Given an index (e.g.,tx_id) of a transaction, this operation provides required information about the transaction from the blockchain, which is fairly useful for the LiIDCoin recipient to verify sender’s claim. The simplest return value of the query operation can be True/False, indicating the validation result of the transaction.


#### 5.3.4. Revoke

This operation is equivalent to the certificate revocation in PKI, which is the key way to control the trust lifetime of an entity. However, most conventional schemes employ a black list, such as CRL, which requires extra storage, computation, and communication costs. In contrast, the proposed scheme achieves the goal through revoking all LiIDCoins of the entity by the following UTXO:(8)basic=tx_id∥t∥revoke∥SigTAX·in=IDEXi∥HCertEXiout=IDTAX∥Qbalance,where revoke is the operation name and SigTAX· denotes the approval from TAX. The sender and the recipient of Qbalance LiIDCoins are EXi and TAX, respectively. As a result, EXi’s LiIDCoin is cleared and EXi is no longer able to launch any new transaction, which implies it cannot be authenticated by others. This kind of transaction is allowed by the blockchain because TAX’s endorser role for EXi can be proved by investigating certificate CertEXi and the Type attribute.In summary, LiIDCoin is able to represent the whole lifecycle of entity identification, which can be easily activated and deactivated through issuing and revoking LiIDCoins, respectively. Besides, entity states are published and updated in a synchronous manner through the blockchain ledger, without any intermediate support (e.g., certificate and CRL), which saves significant management efforts.


### 5.4. Authentication Protocol

Based on the above coin operations, the proposed authentication scheme is implemented by three rounds of request-response communications. The whole process is illustrated in Figure5, where claimant EXi from domain X proves its identity to verifierEYj in domain Y. Note that the blockchain system itself is assumed to be secure since it is beyond the scope of this paper. In this case, we only illustrate essential payload in each request/response packet.Figure 5
Authentication process of the proposed scheme.The whole authentication process is accomplished by the following six steps. In step ①,EXi sends a request to its regional server TAX for launching a LiIDCoin transfer transaction by providing verifier’s ID (e.g., IDEYj) and claimant’s approval (e.g., SigEXiIDEYj. Upon receiving the request, TAX checks its validity by an ingoing authentication algorithm (Algorithm 1). If the request is valid, the transaction is submitted to the blockchain for updating the ledger, and a transaction ID tx_id is returned to EXi in step ②. Based on the transaction, EXi formally sends an authentication request framed with tx_id to EYj in the following form:(9)Authi,jPayload=IDi∥Timestamp∥Payload∥Sigi·,where Authi,j represents an authentication request from claimanti to verifierj, Payload indicates the message carried in the packet, and Timestamp is a point in time, used to prevent replay attack. Furthermore, the whole packet is signed by the claimant in case of spoofing attack. To determine whether the claimant is trustworthy, EYj forwards Authi,j to TAY to confirm the existence and the validity of the transaction by an outgoing authentication algorithm (Algorithm 2 during steps ④ and ⑤). Finally, a decision of acceptance or rejection is immediately sent back to EXi in step ⑥.Algorithm1 depicts the key process of approving a new LiIDCoin transaction. Once receiving a transfer request from EXi, its certificate CertEXi is retrieved from the blockchain system (line 1) and then EXi’s public key pkEXi is extracted from CertEXi (line 2). If the signature in the request can be verified using pkEXi, a transfer UXTO is created and submitted to the blockchain to generate the transaction (lines 3–7). Note that generate Transaction represents a metafunction provided by the blockchain for generating a transaction. Finally, the transaction ID tx_id is returned if no error occurs (line 6), otherwise error_code is provided (line 8).Algorithm 1:Ingoing authentication.
Input:IDEYj and SigEXi·Output:tx_id or error_code.(1)
GetEXi’s certificate CertEXi in the blockchain(2)
ExtractEXi’s public key pkEXi from CertEXi(3)
ifSigEXi· is valid by using pkEXithen(4)
Construct a transferUTXO from EXi to EYj(5)
tx_id←generate TransactionUXTO(6)
returntx_id(7)
end if(8)
returnerror_codeOn the other side, the process of validating a given authentication request is shown in Algorithm2. First, the signature in the request is verified (lines 1–3). If the signature is valid, the UTXO of the transaction indicated by tx_id is retrieved from the blockchain by another metafunction query Transaction (line 4). Then, both the sender and the recipient in the UTXO are verified to conform to the claimant and the verifier, respectively (line 5). Furthermore, the time frame of the authentication is checked by UTXO.Timestamp−Tcurrent<ΔT (line 6), where Tcurrent is the current time and ΔT is the maximum allowable delay. After these investigations, True/False will be returned to indicate the judgment of the transaction (lines 7 and 11).Algorithm 2: Outgoing authentication.
Input:Authi,j and IDEXiOutput:True or False(1)
GetEXi’s certificate CertEXi in the blockchain(2)
ExtractEXi’s public key pkEXi from CertEXi(3)
ifAuthi,j.SigEXi· is valid by using pkEXithen(4)
UTXO←query TransactionAuthi,j.tx_id(5)
ifUTXO.Sender_id==IDEXi && UTXO.Recipient_id==Authi,j.IDEYjthen(6)
ifUTXO.Timestamp−Tcurrent<ΔTthen(7)
returnTrue(8)
end if(9)
end if(10)
end if(11)
returnFalseBesides,EYj maintains a local database to store transaction IDs that have been used for authentication. So far, the identity of EXi has been successfully authenticated by EYj, without transmitting any certificate or CRL files.


### 5.5. Mutual Authentication and Key Agreement

Mutual authentication refers to two entities authenticating each other’s identities before formal communication is established. This can be implemented by adding an inverse pass, as shown in Figure6. After EXi proves its identity to EYj through transaction tx_idi,j, the two entities exchange their roles, with EYj the claimant and EXi the verifier, which means EYj also proves its identity to EXi through another transaction tx_idj,i following the above protocol.Figure 6
Mutual authentication and session key exchange.Upon a successful mutual authentication, the two entities should be able to negotiate a session key for secure communication, which is called key agreement. Based on the elliptic curve in the system setup, we use the Ephemeral Elliptic Curve-based Diffie–Hellman (ECDHE) mechanism for key negotiation and incorporate it into the authentication process. ECDHE is a key agreement protocol that allows two entities to compute the same session key by exchanging their public keys based on the ECC algorithm. Specifically, the two entities obtain the parameter tuplep,a,b,G,n from the blockchain. As shown in Figure 6, EXi and EYj randomly pick two secret keys ri,rj∈Zp, respectively. Then, EXi computes its public key Pi=ri·G and sends it to EYj through Authi,j. Based on that, EYj gets the session key by SK=rj·Pi=rj·ri·G. Similarly, in the inverse pass for authentication, EYj sends its public key Pj=rj·G to EXi; thus, EXi obtains the same session key by SK=ri·Pj=ri·rj·G.The ECDHE mechanism provides perfect forward secrecy by using the ephemeral keys. Moreover, these keys are exchanged through the authentication process; thus, security concerns (e.g., man-in-the-middle attack and replay-attack) can be addressed along with the proposed scheme. Details about security analysis will be given in Section6.


### 5.6. LiIDCoin Recycling

The one-time use property of LiIDCoins will make them exhausted eventually, which can be easily tackled by issuing new LiIDCoins to the entity based on its trust evaluation. This process is called LiIDCoin recycling (or renewal), which can be performed in two modes, including real-time mode and periodic mode. In the real-time mode, once a LiIDCoin is spent for the authentication, a new one will be immediately issued back for supplementation. In this case, the entity will always have sufficient LiIDCoins for authentication service, but trust evaluation complemented with each renewal process could increase system workload. In case of that, the periodic mode allows entities to be supplemented at a specific time interval, and LiIDCoin exhaustion should also be considered. In practice, the two modes can be selected according to specific applications.


## 5.1. Initialization

The initialization phase is executed by the trust layer when the consortium blockchain is deployed on administrative servers from different domains. The main job is to select system parameters, including hash function and Elliptic Curve Cryptography (ECC), which is quite similar to the setup phase in the PKI system. The hash functionH· can be SHA-1 or more secure version. Meanwhile, a nonsingular elliptic curve in the following form is selected:(3)x,y∈Zp2|y2≡x3+ax+bmodp,4a3+27b2≡0modp∪O,where p is a large prime, a,b∈Zp are two constants, and O is the point at infinity. Then, a base point G is picked on the curve whose order is n such that n·G=O.The above parameters make a parameter tupleH·,p,a,b,G,n, which will be published both inside and outside the blockchain. Note that, as long as the hash function and ECC are secure, publishing these parameters will not affect the resistance ability against cryptography attacks. Furthermore, according to the concept of consortium blockchain, to join in the system, all participants, including domain administrators (e.g., TAX and TAY), need to generate a public-private key pair by(4)pk=sk·G,sk∈Zp,where sk is the private key randomly selected from Zp and pk is the public key. At the end of the initialization phase, each domain administrative TA publishes its public key inside the blockchain while keeping its private key as secret.


## 5.2. Off-Chain Registration

Each entity needs to register at its administrative TA to get engaged in the blockchain-based authentication service by the following off-chain steps.(1)
Firstly, an entity, such asEXi, gets the public parameter tuple from the blockchain and generates a public-private key pair (skEXi, pkEXi) according to equation (4). Then, it submits its real identity and public key pkEXi to its administrator TAX through an internal and secure channel.(2)
Secondly,TAX verifies EXi’s real identity to generate a certificate CertEXi as its trust anchor within the blockchain and then calculates EXi’s address on the blockchain by IDEXi=HpkEXi. Besides, TAX activates EXi’s authentication service through issuing a certain amount of LiIDCoins to the address IDEXi, which will be detailed in Section 5.3.1.(3)
Finally,TAX returns the address value IDEXi to EXi as a pseudonym for the rest phases. So far, the entity has completed the registration and only needs to keep the private key skEXi in the local device. It is worth noting that the certificate has never been exposed to the outside of the blockchain.


## 5.3. On-Chain Operations

After finishing registration, the entity obtains the authentication service through a set of on-chain operations on LiIDCoins, which covers the whole lifecycle of its identity.


### 5.3.1. Issue

As mentioned above,TAX issues a certain amount of LiIDCoins to activate a validated entity EXi during the registration phase. This is implemented by a transaction from TAX to EXi in the following form of UXTO:(5)basic=tx_id∥t∥issue∥SigTAX·in=IDTAX∥HCertEXiout=IDEXi∥Qissue,where tx_id is a transaction ID generated by the blockchain, t is the timestamp when the transaction is created, issue indicates the operation name, SigTAX· shows the approval for the transaction from TAX, IDTAX and IDEXi denote that the transaction is launched by TAX and sent to EXi, HCertEXi is used to define the entity-specific type of these LiIDCoins, and Qissue is the quantity of issued LiIDCoins. According to the queuing theory, Qissue can be calculated by(6)Qissue=λW,where λ is the arrival rate of LiIDCoin transactions and W is the processing time per transaction.


### 5.3.2. Transfer

A successful LiIDCoin transfer fromEXi to EYj reveals two facts: on one side, claimantEXi has the ability to launch a transfer endorsed by TAX, which is equivalent to showing a certificate signed by its CA in PKI, thus claiming the legitimacy of EXi. On the other side, such a transfer activity is recorded as a transaction on the blockchain, which will be confirmed by the verifierEYj as well as be used for auditing purposes. The UXTO for the transfer operation is formulated by(7)basic=tx_id∥t∥transfer∥SigEXi·in=IDEXi∥HCertEXiout=IDEYj∥1IDEXi∥Qbalance−1,where transfer indicates the operation name, SigEXi· is the transaction approval from EXi, IDEXi in in part denotes LiIDCoins in this transaction are coming from EXi while two recipients exist in the out part, with 1 for EYj and the rest for the change, respectively, and Qbalance is the number of LiIDCoins owned by EXi before this transaction.As aforementioned, LiIDCoin has a one-time use property, which is essentially different from other digital tokens. This is implemented by theType attribute, which is instantiated as HCertEXi for entity EXi. Before the transaction is actually recorded in the blockchain, it will be validated to ensure that the Type value conforms to the declared sender by verifying its signature in the UTXO and recalculating the hash value of its certificate. For example, supposing that EYj intends to spend the LiIDCoin that it has just received from EXi in equation (7), EYj needs to fill the in part as IDEYj∥HCertEXi. Note that Type is a read-only attribute once a LiIDCoin is issued by the TA, which implies that EYj cannot alter it to its own hash value (e.g., HCertEYj). In this case, the Type value will not conform to the signature for this transaction, leading to a rejection by the blockchain system.


### 5.3.3. Query

The query operation is quite straightforward but essential to confirm the authenticity of an entity. Given an index (e.g.,tx_id) of a transaction, this operation provides required information about the transaction from the blockchain, which is fairly useful for the LiIDCoin recipient to verify sender’s claim. The simplest return value of the query operation can be True/False, indicating the validation result of the transaction.


### 5.3.4. Revoke

This operation is equivalent to the certificate revocation in PKI, which is the key way to control the trust lifetime of an entity. However, most conventional schemes employ a black list, such as CRL, which requires extra storage, computation, and communication costs. In contrast, the proposed scheme achieves the goal through revoking all LiIDCoins of the entity by the following UTXO:(8)basic=tx_id∥t∥revoke∥SigTAX·in=IDEXi∥HCertEXiout=IDTAX∥Qbalance,where revoke is the operation name and SigTAX· denotes the approval from TAX. The sender and the recipient of Qbalance LiIDCoins are EXi and TAX, respectively. As a result, EXi’s LiIDCoin is cleared and EXi is no longer able to launch any new transaction, which implies it cannot be authenticated by others. This kind of transaction is allowed by the blockchain because TAX’s endorser role for EXi can be proved by investigating certificate CertEXi and the Type attribute.In summary, LiIDCoin is able to represent the whole lifecycle of entity identification, which can be easily activated and deactivated through issuing and revoking LiIDCoins, respectively. Besides, entity states are published and updated in a synchronous manner through the blockchain ledger, without any intermediate support (e.g., certificate and CRL), which saves significant management efforts.


## 5.3.1. Issue

As mentioned above,TAX issues a certain amount of LiIDCoins to activate a validated entity EXi during the registration phase. This is implemented by a transaction from TAX to EXi in the following form of UXTO:(5)basic=tx_id∥t∥issue∥SigTAX·in=IDTAX∥HCertEXiout=IDEXi∥Qissue,where tx_id is a transaction ID generated by the blockchain, t is the timestamp when the transaction is created, issue indicates the operation name, SigTAX· shows the approval for the transaction from TAX, IDTAX and IDEXi denote that the transaction is launched by TAX and sent to EXi, HCertEXi is used to define the entity-specific type of these LiIDCoins, and Qissue is the quantity of issued LiIDCoins. According to the queuing theory, Qissue can be calculated by(6)Qissue=λW,where λ is the arrival rate of LiIDCoin transactions and W is the processing time per transaction.


## 5.3.2. Transfer

A successful LiIDCoin transfer fromEXi to EYj reveals two facts: on one side, claimantEXi has the ability to launch a transfer endorsed by TAX, which is equivalent to showing a certificate signed by its CA in PKI, thus claiming the legitimacy of EXi. On the other side, such a transfer activity is recorded as a transaction on the blockchain, which will be confirmed by the verifierEYj as well as be used for auditing purposes. The UXTO for the transfer operation is formulated by(7)basic=tx_id∥t∥transfer∥SigEXi·in=IDEXi∥HCertEXiout=IDEYj∥1IDEXi∥Qbalance−1,where transfer indicates the operation name, SigEXi· is the transaction approval from EXi, IDEXi in in part denotes LiIDCoins in this transaction are coming from EXi while two recipients exist in the out part, with 1 for EYj and the rest for the change, respectively, and Qbalance is the number of LiIDCoins owned by EXi before this transaction.As aforementioned, LiIDCoin has a one-time use property, which is essentially different from other digital tokens. This is implemented by theType attribute, which is instantiated as HCertEXi for entity EXi. Before the transaction is actually recorded in the blockchain, it will be validated to ensure that the Type value conforms to the declared sender by verifying its signature in the UTXO and recalculating the hash value of its certificate. For example, supposing that EYj intends to spend the LiIDCoin that it has just received from EXi in equation (7), EYj needs to fill the in part as IDEYj∥HCertEXi. Note that Type is a read-only attribute once a LiIDCoin is issued by the TA, which implies that EYj cannot alter it to its own hash value (e.g., HCertEYj). In this case, the Type value will not conform to the signature for this transaction, leading to a rejection by the blockchain system.


## 5.3.3. Query

The query operation is quite straightforward but essential to confirm the authenticity of an entity. Given an index (e.g.,tx_id) of a transaction, this operation provides required information about the transaction from the blockchain, which is fairly useful for the LiIDCoin recipient to verify sender’s claim. The simplest return value of the query operation can be True/False, indicating the validation result of the transaction.


## 5.3.4. Revoke

This operation is equivalent to the certificate revocation in PKI, which is the key way to control the trust lifetime of an entity. However, most conventional schemes employ a black list, such as CRL, which requires extra storage, computation, and communication costs. In contrast, the proposed scheme achieves the goal through revoking all LiIDCoins of the entity by the following UTXO:(8)basic=tx_id∥t∥revoke∥SigTAX·in=IDEXi∥HCertEXiout=IDTAX∥Qbalance,where revoke is the operation name and SigTAX· denotes the approval from TAX. The sender and the recipient of Qbalance LiIDCoins are EXi and TAX, respectively. As a result, EXi’s LiIDCoin is cleared and EXi is no longer able to launch any new transaction, which implies it cannot be authenticated by others. This kind of transaction is allowed by the blockchain because TAX’s endorser role for EXi can be proved by investigating certificate CertEXi and the Type attribute.In summary, LiIDCoin is able to represent the whole lifecycle of entity identification, which can be easily activated and deactivated through issuing and revoking LiIDCoins, respectively. Besides, entity states are published and updated in a synchronous manner through the blockchain ledger, without any intermediate support (e.g., certificate and CRL), which saves significant management efforts.


## 5.4. Authentication Protocol

Based on the above coin operations, the proposed authentication scheme is implemented by three rounds of request-response communications. The whole process is illustrated in Figure5, where claimant EXi from domain X proves its identity to verifierEYj in domain Y. Note that the blockchain system itself is assumed to be secure since it is beyond the scope of this paper. In this case, we only illustrate essential payload in each request/response packet.Figure 5
Authentication process of the proposed scheme.The whole authentication process is accomplished by the following six steps. In step ①,EXi sends a request to its regional server TAX for launching a LiIDCoin transfer transaction by providing verifier’s ID (e.g., IDEYj) and claimant’s approval (e.g., SigEXiIDEYj. Upon receiving the request, TAX checks its validity by an ingoing authentication algorithm (Algorithm 1). If the request is valid, the transaction is submitted to the blockchain for updating the ledger, and a transaction ID tx_id is returned to EXi in step ②. Based on the transaction, EXi formally sends an authentication request framed with tx_id to EYj in the following form:(9)Authi,jPayload=IDi∥Timestamp∥Payload∥Sigi·,where Authi,j represents an authentication request from claimanti to verifierj, Payload indicates the message carried in the packet, and Timestamp is a point in time, used to prevent replay attack. Furthermore, the whole packet is signed by the claimant in case of spoofing attack. To determine whether the claimant is trustworthy, EYj forwards Authi,j to TAY to confirm the existence and the validity of the transaction by an outgoing authentication algorithm (Algorithm 2 during steps ④ and ⑤). Finally, a decision of acceptance or rejection is immediately sent back to EXi in step ⑥.Algorithm1 depicts the key process of approving a new LiIDCoin transaction. Once receiving a transfer request from EXi, its certificate CertEXi is retrieved from the blockchain system (line 1) and then EXi’s public key pkEXi is extracted from CertEXi (line 2). If the signature in the request can be verified using pkEXi, a transfer UXTO is created and submitted to the blockchain to generate the transaction (lines 3–7). Note that generate Transaction represents a metafunction provided by the blockchain for generating a transaction. Finally, the transaction ID tx_id is returned if no error occurs (line 6), otherwise error_code is provided (line 8).Algorithm 1:Ingoing authentication.
Input:IDEYj and SigEXi·Output:tx_id or error_code.(1)
GetEXi’s certificate CertEXi in the blockchain(2)
ExtractEXi’s public key pkEXi from CertEXi(3)
ifSigEXi· is valid by using pkEXithen(4)
Construct a transferUTXO from EXi to EYj(5)
tx_id←generate TransactionUXTO(6)
returntx_id(7)
end if(8)
returnerror_codeOn the other side, the process of validating a given authentication request is shown in Algorithm2. First, the signature in the request is verified (lines 1–3). If the signature is valid, the UTXO of the transaction indicated by tx_id is retrieved from the blockchain by another metafunction query Transaction (line 4). Then, both the sender and the recipient in the UTXO are verified to conform to the claimant and the verifier, respectively (line 5). Furthermore, the time frame of the authentication is checked by UTXO.Timestamp−Tcurrent<ΔT (line 6), where Tcurrent is the current time and ΔT is the maximum allowable delay. After these investigations, True/False will be returned to indicate the judgment of the transaction (lines 7 and 11).Algorithm 2: Outgoing authentication.
Input:Authi,j and IDEXiOutput:True or False(1)
GetEXi’s certificate CertEXi in the blockchain(2)
ExtractEXi’s public key pkEXi from CertEXi(3)
ifAuthi,j.SigEXi· is valid by using pkEXithen(4)
UTXO←query TransactionAuthi,j.tx_id(5)
ifUTXO.Sender_id==IDEXi && UTXO.Recipient_id==Authi,j.IDEYjthen(6)
ifUTXO.Timestamp−Tcurrent<ΔTthen(7)
returnTrue(8)
end if(9)
end if(10)
end if(11)
returnFalseBesides,EYj maintains a local database to store transaction IDs that have been used for authentication. So far, the identity of EXi has been successfully authenticated by EYj, without transmitting any certificate or CRL files.


## 5.5. Mutual Authentication and Key Agreement

Mutual authentication refers to two entities authenticating each other’s identities before formal communication is established. This can be implemented by adding an inverse pass, as shown in Figure6. After EXi proves its identity to EYj through transaction tx_idi,j, the two entities exchange their roles, with EYj the claimant and EXi the verifier, which means EYj also proves its identity to EXi through another transaction tx_idj,i following the above protocol.Figure 6
Mutual authentication and session key exchange.Upon a successful mutual authentication, the two entities should be able to negotiate a session key for secure communication, which is called key agreement. Based on the elliptic curve in the system setup, we use the Ephemeral Elliptic Curve-based Diffie–Hellman (ECDHE) mechanism for key negotiation and incorporate it into the authentication process. ECDHE is a key agreement protocol that allows two entities to compute the same session key by exchanging their public keys based on the ECC algorithm. Specifically, the two entities obtain the parameter tuplep,a,b,G,n from the blockchain. As shown in Figure 6, EXi and EYj randomly pick two secret keys ri,rj∈Zp, respectively. Then, EXi computes its public key Pi=ri·G and sends it to EYj through Authi,j. Based on that, EYj gets the session key by SK=rj·Pi=rj·ri·G. Similarly, in the inverse pass for authentication, EYj sends its public key Pj=rj·G to EXi; thus, EXi obtains the same session key by SK=ri·Pj=ri·rj·G.The ECDHE mechanism provides perfect forward secrecy by using the ephemeral keys. Moreover, these keys are exchanged through the authentication process; thus, security concerns (e.g., man-in-the-middle attack and replay-attack) can be addressed along with the proposed scheme. Details about security analysis will be given in Section6.


## 5.6. LiIDCoin Recycling

The one-time use property of LiIDCoins will make them exhausted eventually, which can be easily tackled by issuing new LiIDCoins to the entity based on its trust evaluation. This process is called LiIDCoin recycling (or renewal), which can be performed in two modes, including real-time mode and periodic mode. In the real-time mode, once a LiIDCoin is spent for the authentication, a new one will be immediately issued back for supplementation. In this case, the entity will always have sufficient LiIDCoins for authentication service, but trust evaluation complemented with each renewal process could increase system workload. In case of that, the periodic mode allows entities to be supplemented at a specific time interval, and LiIDCoin exhaustion should also be considered. In practice, the two modes can be selected according to specific applications.


## 6. Security Analysis

In this section, we analyze the security requirements that the proposed scheme can accommodate. Note that the cryptographic primitives and the blockchain are assumed to be secure since they are beyond the scope of this paper. Details of the security analysis are given as follows.


### 6.1. Single Registration

For ease use, each entity needs to register only once before it enjoys the authentication service. According to the proposed scheme, an entity enrolls into the system at its administrative TA through an off-chain registration. The entity submits its real identity and public key during the registration. Once they are approved, the TA generates a certificate and a certain amount of LiIDCoin for the entity in the blockchain. After that, the entity can launch requests without any further registration, and the request messages can be signed by the entity using it private key independently. Therefore, the proposed scheme is able to provide a one-off registration.


### 6.2. Forgery Attack

The adversary spoofs the signature of a legitimate entity and sends it to others. In the proposed scheme, the private key is generated and preserved by each entity itself. As long as it is not compromised, the cryptographic theory can guarantee that it is infeasible to fake a valid signature without knowing the private key.


### 6.3. Man-in-the-Middle Attack

The adversary secretly intercepts communications or alters them between two entities. In our proposal, the authentication request is represented byAuthi,jtx_id, in which the claimant and the verifier are already determined in the form of a transaction in the blockchain before it is sent. The adversary cannot insert itself into a communication without interacting with the blockchain. Once it happens, the malicious behavior will be revealed by the blockchain ledger.


### 6.4. Replay Attack

The adversary fraudulently delays or resends a request to the receiver. In the proposed scheme, a timestamp is introduced to the authentication request along with a time threshold, to ensure the particular request cannot be processed more than once. Even within the threshold, a used request can be easily detected by looking up a local database that stores the latest accepted ones.


### 6.5. Identity Revealing Attack

In this attack, the adversary attempts to reveal the real identity of a target entity. According to the proposal, the real identity of each entity is only required during the registration phase and an address is then assigned to the entity as a pseudonym for all later operations. Moreover, the identity-pseudonym mapping is exclusively maintained by its administrative TA. As long as the TA is not compromised, the privacy of the entity is preserved.


### 6.6. Deny-of-Service Attack

The adversary attempts to overload the system to prevent it from serving clients. In our proposal, the authentication service is mainly implemented by transferring LiIDCoins between entities. The number of LiIDCoins owned by each entity is limited and each transaction is recorded in the blockchain. In this case, the adversary needs to pay a price and risk its reputation to launch such an attack. Moreover, abnormal transactions can be detected from the server side.


### 6.7. Authority Abuse Attack

In this attack, a TA arbitrarily issues tokens to illegal entities or revoke tokens of legal entities. In the proposed scheme, all the activities of issuing and revoking tokens are transparent and verifiable in the blockchain. Based on that, abuse behaviors of a TA affect its reputation in the consortium; thus, it could be eliminated from the system.


## 6.1. Single Registration

For ease use, each entity needs to register only once before it enjoys the authentication service. According to the proposed scheme, an entity enrolls into the system at its administrative TA through an off-chain registration. The entity submits its real identity and public key during the registration. Once they are approved, the TA generates a certificate and a certain amount of LiIDCoin for the entity in the blockchain. After that, the entity can launch requests without any further registration, and the request messages can be signed by the entity using it private key independently. Therefore, the proposed scheme is able to provide a one-off registration.


## 6.2. Forgery Attack

The adversary spoofs the signature of a legitimate entity and sends it to others. In the proposed scheme, the private key is generated and preserved by each entity itself. As long as it is not compromised, the cryptographic theory can guarantee that it is infeasible to fake a valid signature without knowing the private key.


## 6.3. Man-in-the-Middle Attack

The adversary secretly intercepts communications or alters them between two entities. In our proposal, the authentication request is represented byAuthi,jtx_id, in which the claimant and the verifier are already determined in the form of a transaction in the blockchain before it is sent. The adversary cannot insert itself into a communication without interacting with the blockchain. Once it happens, the malicious behavior will be revealed by the blockchain ledger.


## 6.4. Replay Attack

The adversary fraudulently delays or resends a request to the receiver. In the proposed scheme, a timestamp is introduced to the authentication request along with a time threshold, to ensure the particular request cannot be processed more than once. Even within the threshold, a used request can be easily detected by looking up a local database that stores the latest accepted ones.


## 6.5. Identity Revealing Attack

In this attack, the adversary attempts to reveal the real identity of a target entity. According to the proposal, the real identity of each entity is only required during the registration phase and an address is then assigned to the entity as a pseudonym for all later operations. Moreover, the identity-pseudonym mapping is exclusively maintained by its administrative TA. As long as the TA is not compromised, the privacy of the entity is preserved.


## 6.6. Deny-of-Service Attack

The adversary attempts to overload the system to prevent it from serving clients. In our proposal, the authentication service is mainly implemented by transferring LiIDCoins between entities. The number of LiIDCoins owned by each entity is limited and each transaction is recorded in the blockchain. In this case, the adversary needs to pay a price and risk its reputation to launch such an attack. Moreover, abnormal transactions can be detected from the server side.


## 6.7. Authority Abuse Attack

In this attack, a TA arbitrarily issues tokens to illegal entities or revoke tokens of legal entities. In the proposed scheme, all the activities of issuing and revoking tokens are transparent and verifiable in the blockchain. Based on that, abuse behaviors of a TA affect its reputation in the consortium; thus, it could be eliminated from the system.


## 7. Implementation and Evaluation

In this section, we implement our scheme and conduct experiments to evaluate its performance in terms of functionality, storage cost, communication cost, and authentication efficiency.


### 7.1. Experimental Setup

Two administrative domains are simulated in the experiments. In each domain, there are one TA server and one IoT device, respectively. In addition, as we implement our scheme on the HyperLedger Fabric platform and use the Raft algorithm for consensus, we deploy a third server to satisfy the requirement for an odd number of ordering servers. Figure7(a) illustrates the logical architecture of the simulation. Therefore, we have three Lenovo 510S desktops with Intel Core i5 CPU@2.9 GHz and 8 GB memory running on CentOS v8.3 for TA servers, and two Raspberry Pi 3B+ with Broadcom Cortex-A53 CPU@1.4 GHz and 1 GB memory as IoT devices, as shown in Figure 7(b). All desktops and IoT devices are connected to their subnetworks through a H3C S5560 switch, which supports multiple Virtual Local Area Networks (VLANs) and network routing. Furthermore, we deploy HLF v2.0 as the consortium blockchain and implement smart contracts (also known as chaincode) using Node.js. For the client side, cryptographic primitives and authentication protocol are implemented by Python.Figure 7
(a) Logical architecture and (b) physical architecture of the simulated cross-domain IoT.
(a)(b)We compared our scheme with four classic competitors, including PKI, CertCoin [18], AuthCoin [19], CeCoin [20], and BASA [22]. For comparison purposes, we use the same cryptographic parameter settings. Specifically, we use the prime256v1 elliptic curve to create the public/private keys and Elliptic Curve Digital Signature Algorithm (ECDSA) for generating signatures. In this case, the lengths of the private key and the signature are 256 bits and 512 bits, respectively.


### 7.2. Functionality

We compared the functionalities that have been achieved (indicated by0) or not achieved (indicated by ×) in Table 3. All schemes have the functions of registration and validation, only AuthCoin and BASA can hardly renew and revoke identity proofs since the former inherits the spirits from Web of Trust (WoT) and the latter employ a pseudoanonymous identity for each authentication. Besides, blockchain-based schemes realize the function of transparency except for AuthCoin since it only stores challenge-response messages in the blockchain. Among these schemes, only BASA and the proposed scheme have the function of lightweight client, which is critically important for IoT scenarios. However, since BASA is based on IBC, the KGC introduces a key-escrow problem as well as a restriction on mobility. More results will be given in the following experiments to support the above conclusion.Table 3
Comparison of functionality.
FunctionPKICertCoinAuthCoinCeCoinBASALiIDCoinRegistration✔✔✔✔✔✔Renewal✔✔×✔×✔Revocation✔✔×✔×✔Validation✔✔✔✔✔✔Transparency×✔×✔✔✔Privacy preservation××××✔✔Lightweight client××××✔✔Mobility✔✔✔✔×✔


### 7.3. Storage Cost

The comparison results of storage cost for the six authentication schemes are listed in Table4. Note that we only count in the most necessary data that should be stored in local device for authentication. As we used 256 bit ECC keys, we have the size of private key Ssk=32 bytes while the size of certificate SCert could be various according to its contents; in this experiment, SCert=557 bytes. The total rough costs of the six schemes are also given in Table 4.Table 4
Comparison of storage cost.
SchemeTotal costTotal rough cost (byte)PKI2SCert+Ssk1146CertCoin2Spk+Ssk128AuthCoinSpk+Ssk64CeCoinSCert+Ssk589BASA2Ssk64LiIDCoinSsk32For PKI, we assume that OCSP is used for certificate status validation, otherwise it will cost extra storage to maintain CRL files. In CertCoin, each entity is associated with two pairs of public-private keys for privacy preservation. Among the above schemes, LiIDCoin cost the least storage since only the private key is kept in local device while others (e.g., certificates) are maintained in the blockchain servers.


### 7.4. Communication Cost

We evaluate the communication cost of the authentication scheme by accumulating all key payloads during the authentication process. Since CertCoin, AuthCoin, and CeCoin have not been implemented yet, we only compared our scheme with PKI and BASA in this experiment. As shown in Figures3 and 5, PKI has four steps while LiIDCoin has six steps. The original work of BASA has three components in the server side and requires 24 steps for one unilateral authentication. To fit the topology in this experiment, we deployed all server-side components of BASA on the same physical server; thus, we only consider communication cost between the IoT device and the server. The size of entity ID, signature, timestamp, random number, cryptographic key, transaction ID, certificate ID, and binary result (Yes/No or True/False) is denoted as SID, SSig, STS, SN, SKey, STx_id, and SBin, the values of which are 32, 64, 4, 4, 32, 32, and 1 byte(s), respectively. We use the same certificate in the above experiment; thus, we have SCert=557 and SCert_ID=20. The rough cost of PKI authentication is 643 bytes, in which certificate occupies the majority. BASA costs 430 bytes in communication; it is worth mentioning that when the server-side components are deployed in a distributed way, this value would be even more. By contract, the communication overhead of LiIDCoin is only 394 bytes. Details are listed in Table 5.Table 5
Comparison of communication cost.
StepPKIBASALiIDCoin①SCert+SSig2SID+SSig+SNSID+SSig②SCert_IDSKey+SSigSTx_id③SBinSN+SID+SSigSID+STS+STx_id+SSig④SBinSN+SID+SSigSID+STS+STx_id+SSig⑤—SBinSBin⑥—SBinSBinTotal rough cost (byte)643430394


### 7.5. Authentication Efficiency

The efficiency of the whole authentication process is another critical metric for evaluating an authentication scheme. Since the proposed scheme is closely associated with the on-chain operations (e.g., transfer and query), we firstly investigate the server-side efficiency, which is normally described by the Transactions Per Second (TPS) of the blockchain. We launched 10 000 transactions for each operation with respect to different transaction numbers encapsulated in a block. As illustrated in Figure8, TPS of each operation increases and then becomes stable as the block-encapsulated transactions grows. Being as the most complex transaction, Transfer is less efficient than the other two operations. It is worth mentioning that the throughput can be further improved by employing high-performance servers as well as other optimization strategies [31].Figure 8
Throughput of LiIDCoin operations.When the maximum throughput is selected, the time costs of on-chain operations are listed in Table6. Although Transfer is the most time-consuming operation, it is still less than 7 ms. Note that Query is a read-only operation, which is not related to transaction settings.Table 6
Time cost of on-chain operations.
OperationAverage time (ms)Issue3.71Transfer6.16Query4.31Revoke3.62Besides, the overall time cost of an authentication scheme is highly affected by the required cryptographic primitives. Table7 lists time costs of the basic cryptographic operations used in this experiment. Each data is an average value of 100 measurements. It can be observed that time cost of cryptographic computations on the server is far lower than that on the IoT device.Table 7
Time cost of cryptographic operations.
OperationAverage time (ms)Server (Lenovo PC)IoT (Raspberry Pi)Sign2.0421.98Verify0.8615.53Based on this knowledge, we compared the whole authentication process of LiIDCoin with that of BASA and PKI in this experiment. We conduct authentications by using BASA, PKI, and LiIDCoin, respectively, each for 100 times. The average time costs of the three schemes are illustrated in Figure9, in which LiIDCoin is the most time efficient, costing only 72 ms on average for one unilateral authentication. We also investigate time consumption of the main operations in each scheme. Since all cryptographic operations in PKI need to be conducted by the IoT devices while those in LiIDCoin can be partly performed in the TA servers, the latter scheme consumes less time than the former in terms of cryptographic operations. Meanwhile, although BASA also migrates cryptographic operations from IoT devices to powerful severs, it introduces more cryptographic operations and require more steps to perform one single authentication. In contrast to PKI, LiIDCoin requires extra time for blockchain operations (e.g., Transfer and Query). However, according to Table 6, time consumption of these operations are acceptable. Besides basic operations, there are many other steps, including network transmission, for completing the authentication. In PKI, the step of certificate status validation tends to take up a significant part of the time cost, which is coherent to the investigative findings in OCSP applications [32]. Compared to PKI, BASA requires much more communication due to its numerous steps, while LiIDCoin spends less time in network transmission since it has moderate steps and fully utilizes regional network for communications.Figure 9
Time cost of the whole authentication process.


### 7.6. Discussion and Limitations

In the evaluation, we investigate various metrics of the proposed method LiIDCoin, including functionality, storage cost, communication cost, and authentication efficiency from both the server side and the client side. Compared with the traditional PKI, LiIDCoin is more efficient in terms of storage, communication and client-side authentication, and trust management overhead is largely mitigated. In comparison with the blockchain-based competitor BASA, LiIDCoin is not based on IBC, thus does not have key-escrow problems, and is more feasible for mobile IoT applications. Besides, it costs less communication bandwidth and computation resources.As our work is still an early study in the field of blockchain-based IoT authentication, there remains some open challenges that can be considered. Firstly, as the infrastructure of authentication service, blockchain still faces some issues, such as server-side storage cost, energy cost, and scalability. Secondly, in the current proposal, the entity ID is used during it is entire lifecycle, which may suffer from a linkability attack. Thus, privacy issues can be further enhanced. Thirdly, there is a need to optimize trust management in segments of LiIDCoin recycling and activity auditing. We plan to explore the above challenges based on the current implementation in our future work.


## 7.1. Experimental Setup

Two administrative domains are simulated in the experiments. In each domain, there are one TA server and one IoT device, respectively. In addition, as we implement our scheme on the HyperLedger Fabric platform and use the Raft algorithm for consensus, we deploy a third server to satisfy the requirement for an odd number of ordering servers. Figure7(a) illustrates the logical architecture of the simulation. Therefore, we have three Lenovo 510S desktops with Intel Core i5 CPU@2.9 GHz and 8 GB memory running on CentOS v8.3 for TA servers, and two Raspberry Pi 3B+ with Broadcom Cortex-A53 CPU@1.4 GHz and 1 GB memory as IoT devices, as shown in Figure 7(b). All desktops and IoT devices are connected to their subnetworks through a H3C S5560 switch, which supports multiple Virtual Local Area Networks (VLANs) and network routing. Furthermore, we deploy HLF v2.0 as the consortium blockchain and implement smart contracts (also known as chaincode) using Node.js. For the client side, cryptographic primitives and authentication protocol are implemented by Python.Figure 7
(a) Logical architecture and (b) physical architecture of the simulated cross-domain IoT.
(a)(b)We compared our scheme with four classic competitors, including PKI, CertCoin [18], AuthCoin [19], CeCoin [20], and BASA [22]. For comparison purposes, we use the same cryptographic parameter settings. Specifically, we use the prime256v1 elliptic curve to create the public/private keys and Elliptic Curve Digital Signature Algorithm (ECDSA) for generating signatures. In this case, the lengths of the private key and the signature are 256 bits and 512 bits, respectively.


## 7.2. Functionality

We compared the functionalities that have been achieved (indicated by0) or not achieved (indicated by ×) in Table 3. All schemes have the functions of registration and validation, only AuthCoin and BASA can hardly renew and revoke identity proofs since the former inherits the spirits from Web of Trust (WoT) and the latter employ a pseudoanonymous identity for each authentication. Besides, blockchain-based schemes realize the function of transparency except for AuthCoin since it only stores challenge-response messages in the blockchain. Among these schemes, only BASA and the proposed scheme have the function of lightweight client, which is critically important for IoT scenarios. However, since BASA is based on IBC, the KGC introduces a key-escrow problem as well as a restriction on mobility. More results will be given in the following experiments to support the above conclusion.Table 3
Comparison of functionality.
FunctionPKICertCoinAuthCoinCeCoinBASALiIDCoinRegistration✔✔✔✔✔✔Renewal✔✔×✔×✔Revocation✔✔×✔×✔Validation✔✔✔✔✔✔Transparency×✔×✔✔✔Privacy preservation××××✔✔Lightweight client××××✔✔Mobility✔✔✔✔×✔


## 7.3. Storage Cost

The comparison results of storage cost for the six authentication schemes are listed in Table4. Note that we only count in the most necessary data that should be stored in local device for authentication. As we used 256 bit ECC keys, we have the size of private key Ssk=32 bytes while the size of certificate SCert could be various according to its contents; in this experiment, SCert=557 bytes. The total rough costs of the six schemes are also given in Table 4.Table 4
Comparison of storage cost.
SchemeTotal costTotal rough cost (byte)PKI2SCert+Ssk1146CertCoin2Spk+Ssk128AuthCoinSpk+Ssk64CeCoinSCert+Ssk589BASA2Ssk64LiIDCoinSsk32For PKI, we assume that OCSP is used for certificate status validation, otherwise it will cost extra storage to maintain CRL files. In CertCoin, each entity is associated with two pairs of public-private keys for privacy preservation. Among the above schemes, LiIDCoin cost the least storage since only the private key is kept in local device while others (e.g., certificates) are maintained in the blockchain servers.


## 7.4. Communication Cost

We evaluate the communication cost of the authentication scheme by accumulating all key payloads during the authentication process. Since CertCoin, AuthCoin, and CeCoin have not been implemented yet, we only compared our scheme with PKI and BASA in this experiment. As shown in Figures3 and 5, PKI has four steps while LiIDCoin has six steps. The original work of BASA has three components in the server side and requires 24 steps for one unilateral authentication. To fit the topology in this experiment, we deployed all server-side components of BASA on the same physical server; thus, we only consider communication cost between the IoT device and the server. The size of entity ID, signature, timestamp, random number, cryptographic key, transaction ID, certificate ID, and binary result (Yes/No or True/False) is denoted as SID, SSig, STS, SN, SKey, STx_id, and SBin, the values of which are 32, 64, 4, 4, 32, 32, and 1 byte(s), respectively. We use the same certificate in the above experiment; thus, we have SCert=557 and SCert_ID=20. The rough cost of PKI authentication is 643 bytes, in which certificate occupies the majority. BASA costs 430 bytes in communication; it is worth mentioning that when the server-side components are deployed in a distributed way, this value would be even more. By contract, the communication overhead of LiIDCoin is only 394 bytes. Details are listed in Table 5.Table 5
Comparison of communication cost.
StepPKIBASALiIDCoin①SCert+SSig2SID+SSig+SNSID+SSig②SCert_IDSKey+SSigSTx_id③SBinSN+SID+SSigSID+STS+STx_id+SSig④SBinSN+SID+SSigSID+STS+STx_id+SSig⑤—SBinSBin⑥—SBinSBinTotal rough cost (byte)643430394


## 7.5. Authentication Efficiency

The efficiency of the whole authentication process is another critical metric for evaluating an authentication scheme. Since the proposed scheme is closely associated with the on-chain operations (e.g., transfer and query), we firstly investigate the server-side efficiency, which is normally described by the Transactions Per Second (TPS) of the blockchain. We launched 10 000 transactions for each operation with respect to different transaction numbers encapsulated in a block. As illustrated in Figure8, TPS of each operation increases and then becomes stable as the block-encapsulated transactions grows. Being as the most complex transaction, Transfer is less efficient than the other two operations. It is worth mentioning that the throughput can be further improved by employing high-performance servers as well as other optimization strategies [31].Figure 8
Throughput of LiIDCoin operations.When the maximum throughput is selected, the time costs of on-chain operations are listed in Table6. Although Transfer is the most time-consuming operation, it is still less than 7 ms. Note that Query is a read-only operation, which is not related to transaction settings.Table 6
Time cost of on-chain operations.
OperationAverage time (ms)Issue3.71Transfer6.16Query4.31Revoke3.62Besides, the overall time cost of an authentication scheme is highly affected by the required cryptographic primitives. Table7 lists time costs of the basic cryptographic operations used in this experiment. Each data is an average value of 100 measurements. It can be observed that time cost of cryptographic computations on the server is far lower than that on the IoT device.Table 7
Time cost of cryptographic operations.
OperationAverage time (ms)Server (Lenovo PC)IoT (Raspberry Pi)Sign2.0421.98Verify0.8615.53Based on this knowledge, we compared the whole authentication process of LiIDCoin with that of BASA and PKI in this experiment. We conduct authentications by using BASA, PKI, and LiIDCoin, respectively, each for 100 times. The average time costs of the three schemes are illustrated in Figure9, in which LiIDCoin is the most time efficient, costing only 72 ms on average for one unilateral authentication. We also investigate time consumption of the main operations in each scheme. Since all cryptographic operations in PKI need to be conducted by the IoT devices while those in LiIDCoin can be partly performed in the TA servers, the latter scheme consumes less time than the former in terms of cryptographic operations. Meanwhile, although BASA also migrates cryptographic operations from IoT devices to powerful severs, it introduces more cryptographic operations and require more steps to perform one single authentication. In contrast to PKI, LiIDCoin requires extra time for blockchain operations (e.g., Transfer and Query). However, according to Table 6, time consumption of these operations are acceptable. Besides basic operations, there are many other steps, including network transmission, for completing the authentication. In PKI, the step of certificate status validation tends to take up a significant part of the time cost, which is coherent to the investigative findings in OCSP applications [32]. Compared to PKI, BASA requires much more communication due to its numerous steps, while LiIDCoin spends less time in network transmission since it has moderate steps and fully utilizes regional network for communications.Figure 9
Time cost of the whole authentication process.


## 7.6. Discussion and Limitations

In the evaluation, we investigate various metrics of the proposed method LiIDCoin, including functionality, storage cost, communication cost, and authentication efficiency from both the server side and the client side. Compared with the traditional PKI, LiIDCoin is more efficient in terms of storage, communication and client-side authentication, and trust management overhead is largely mitigated. In comparison with the blockchain-based competitor BASA, LiIDCoin is not based on IBC, thus does not have key-escrow problems, and is more feasible for mobile IoT applications. Besides, it costs less communication bandwidth and computation resources.As our work is still an early study in the field of blockchain-based IoT authentication, there remains some open challenges that can be considered. Firstly, as the infrastructure of authentication service, blockchain still faces some issues, such as server-side storage cost, energy cost, and scalability. Secondly, in the current proposal, the entity ID is used during it is entire lifecycle, which may suffer from a linkability attack. Thus, privacy issues can be further enhanced. Thirdly, there is a need to optimize trust management in segments of LiIDCoin recycling and activity auditing. We plan to explore the above challenges based on the current implementation in our future work.


## 8. Conclusion

In this paper, we proposed a lightweight authentication scheme based on consortium blockchain by designing a cryptocurrency-like digital token named LiIDCoin to represent entity trust. In this way, the authenticity of an entity can be proved by providing evidence of its transaction capability in the blockchain. Moreover, lifecycle management can be carried out by manipulating the amount of LiIDCoins. We conducted an overall analysis to demonstrate the security requirements that the proposed scheme satisfies. Furthermore, we implemented our scheme on the HLF platform and compared it with several competitor schemes. Experimental results reveal that our scheme is more efficient in terms of storage, communication, and authentication efficiency.In future work, we would like to conduct extensive experiments on real-world IoT applications as well as extending our scheme to more cross-domain authentication scenarios, such as eduroam (education roaming). Privacy enhancement and fine-grained trust management can also be considered.



---

*Source: 9686049-2022-01-03.xml*