# A Certificateless-Based Authentication and Key Agreement Scheme for IIoT Cross-Domain

Authors: Xiangyang Wang; Chunxiang Gu; Fushan Wei; Siqi Lu; Zhaoxuan Li
Journal: Security and Communication Networks
 (2022)

---

## Abstract

The Industrial Internet of Things (IIoT) improves productivity and intelligent manufacturing process through revolutionary technology. Due to the complexity of the manufacturing process, cross-domain access is inevitable. Recently, Meng et al. proposed a secure and efficient blockchain-assisted entity authentication mechanism BASA for IIoT cross-domain. In the BASA scheme, the authors utilized identity-based signature (IBS) to realize mutual authentication and the Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) exchange mechanism to negotiate the session key. Due to the inherent key escrow problem of identity-based cryptography (IBC), the key generation center (KGC) can obtain the session key negotiated between two entities distributed in different domains. When KGC is threatened, the security of the session key is worrying. Considering this security concern, based on the BASA scheme, in this article, we first show a secure and efficient certificateless public-key signature (CL-PKS) scheme with anonymity. Then, combined with the ECDHE key exchange mechanism, we give an efficient cross-domain authentication and key agreement scheme CL-BASA with the aid of consortium blockchain. After that, we make security verification by the formal analysis tool, Tamarin, which shows that our CL-BASA is secure. The evaluation demonstrates that our CL-BASA may have a slight disadvantage in storage overhead, but it has obvious advantages than competitor schemes in terms of communication overhead and computational overhead.


---

## Body

## 1. Introduction

IoT technology provides a platform to connect equipment and factory domains to promote the task of automated manufacturing, which greatly improves productivity and minimizes management costs. Due to the emergence of Industry 4.0 [1], Industrial Internet of Things (IIoT) is becoming an important enabling technology. However, considering the complexity of the current production process, it has become a trend that some related domains cooperate to complete the production of products.To complete the production of products, devices distributed in different domains need to share and exchange data by an efficient communication mechanism. In general, two different domains may not trust each other. Therefore, it is not easy to establish a secure communication mechanism between entities distributed in different domains. In the existing cross-domain authentication schemes, most of them adopt traditional KPI technology and digital certificate to realize cross-domain authentication. In traditional public-key cryptography (PKC), the user’s random public key is associated with the user’s identity through a certificate. This inevitably leads to a large amount of storage and computational overhead for the certificate management. Due to the resource constraints of IoT devices, these cross-domain schemes are inappropriate under the IoT scenarios. To simplify the certificate management, Shamir [2] introduced the identity-based cryptosystem (IBC), in which some public known information, such as e-mail address, is used as the user’s public key. Therefore, the certificate of the random public key is no longer required.For the tamper-proof and decentralized characteristics, blockchain is increasingly used to solve the problems of identity credibility and data credibility in the field of the IoT [3]. The consortium blockchain is called “shared authentication blockchain,” and its essence is a distributed hosting accounting system. The system is controlled by multiple “authoritative” nodes designated by the organization. These nodes manage and send the whole system according to the consensus mechanism. Consortium blockchain can be used as a public and trusted platform for domain-specific information sharing to establish trust between different domains. At present, many scholars have studied the combination of blockchain and cross-domain communication, but these studies generally adopt the IBS scheme in the authentication stage. As we all know, IBC has obvious advantages in storage and computation overhead, but it has the problem of key escrow. Therefore, the malicious KGC can forge the signature of any signer. In the cross-domain scenario, the key escrow problem can directly lead KGC to calculate the session key negotiated between the parties. So, in the scenario with high security, IBC-based schemes are unreliable.To solve the inherent key escrow problem of IBC, Al-Riyami and Paterson [4] proposed the certificateless public key cryptography (CL-PKC) in 2003, which not only eliminates the use of certificates in PKC but also solves the problem of key escrow in IBC. In the CL-PKC, the private key of the user is constructed by the secret value and the partial private key. The former is randomly chosen by the user, while the latter is generated by KGC. In the past few years, a large number of CL-PKC schemes have been proposed. In addition, in 2001, Brown et al. [5] proposed a modification scheme of the optimal mail certificate (OMC) scheme [6]; it was later called the Elliptic Curve Qu-Vanstone (ECQV) implicit certificate scheme [7]. In addition to the certificateless scheme, ECQV implicit certificate scheme can also avoid the problem of key escrow. ECQV implicit certificate schemes have found application in the IoT. For example, it becomes part of the encryption suite building block in the ZigBee smart energy standard [8]. In recent years, the applications of implicit certificate schemes based on ECQV in the scenario of IoT have also been widely studied. However, compared with the certificateless scheme, the implicit certificate scheme based on ECQV needs to store an implicit certificate, so the management and maintenance of the certificate will inevitably bring more overhead.In this article, based onBASA [9] proposed by Meng et al., we adopt the certificateless signature scheme and ECDHE key exchange mechanism to design a cross-domain authentication and key agreement scheme CL-BASA with the aid of blockchain, which is suitable for IIoT cross-domain. In detail, we first design a secure and efficient certificateless short signature scheme CL-PKS with anonymity; then, during mutual authentication stage, consortium blockchain is used to provide the authenticity of anonymous identity and public key, while CL-PKS is exploited to ensure data integrality. Finally, during the key agreement stage, CL-PKS and ECDHE are combined to realize cross-domain key agreement between two entities distributed in different domains. Compared with the competitor schemes, our scheme may be slightly insufficient in storage overhead, but it is significantly better in terms of communication overhead and computational overhead.Our contributions are as follows:(i)
We design a secure and efficient certificateless public-key signature scheme CL-PKS with anonymity. Based on the Elliptic Curve Computational Diffie-Hellman (ECCDH) problem, we prove that our signature scheme satisfies the existentially unforgeable one against adaptively chosen message attacks (EUF-CMA) in the random oracle model. See Appendix A for the detailed proof.(ii)
Based on theBASA, we use CL-PKS and ECDHE key exchange mechanism to design a cross-domain authentication scheme CL-BASA suitable for IIoT cross-domain. Compared with the BASA scheme, our CL-BASA scheme avoids the possible security threats caused by the key escrow problem and is superior to BASA in terms of communication overhead.(iii)
For the management of anonymous identity, we designed a simple identity management mechanism, which is designed based on the CL-PKS scheme with anonymity. Compared with the identity management mechanism inBASA, our mechanism reduces the overhead of identity management and the computation overhead of generating anonymous identity.(iv)
In order to illustrate the security of our CL-BASA, we make security verification by the formal analysis tool, Tamarin. The result of formal verification shows that our CL-BASA is secure. The evaluation demonstrates that our CL-BASA has more obvious advantages than competitor schemes in terms of communication overhead and computational overhead.The rest of this article is organized as follows: Section2 reviews the existing authentication mechanisms proposed for IoT. Section 3 introduces some basic knowledge. In Section 4, we show our certificateless public-key signature scheme CL-PKS and the security model. In Section 5, we introduce our authentication and key agreement mechanism CL-BASA for IIoT cross-domain. Section 6 is the security analysis. Section 7 is the security verification of our scheme. We give a performance evaluation in Section 8. Section 9 is the summary of our work.


## 2. Related Work

In this section, we introduce the authentication schemes that have been proposed for the IoT scenario and show them from three aspects, namely, certificate-based schemes, identity-based schemes, and certificateless-based schemes.


### 2.1. Certificate-Based Schemes

Due to the resource limitation of wireless sensor networks, security solutions based on the elliptic curve are often used in wireless sensor networks. Several implicit certificate schemes for wireless sensor networks were introduced [10, 11]. In addition, the applications in IoT scenario of ECQV implicit certificate schemes have been well studied. By combining Elliptic Curve Diffie-Hellman (ECDH) key exchange mechanisms and ECQV implicit certificate scheme, a key management protocol suitable for mobile and IIoT systems was proposed [12]. For robust key negotiation, lightweight node authentication, fast key reset, and effective replay attack protection, the ECQV implicit certificate scheme was used to make a lightweight security association suitable for IoT devices [13]. Considering the deficiency of the PAuthKey protocol, it does not clearly point out how to share the network key between IoT devices, and CA only authenticates each authorized device based on the network key rather than a single key. The authors propose a new ECQV implicit certificate-based protocol, which solves the problem of the PAuthKey protocol. The first nontrivial identity-based authentication (IBI) scheme [14] with implicit authentication is given by using the ECQV implicit certificate scheme. Compared with the traditional identity-based scheme, the method based on implicit certificates can resist key escrow. All the above research studies pay attention to authentication in the single-domain. Besides, there are also some research studies based on the ECQV implicit certificate scheme in IoT cross-domain scenarios. To maintain the reliable connection and accessibility of IoT devices distributed in different domains, the authors of [15] proposed an authentication mechanism based on the ECQV implicit certificate scheme. This two-stage authentication protocol allows sensor nodes and end-users to make mutual authentication and establish a secure connection. For realizing efficient and dynamic certificate distribution at a lower cost in the vehicle cloud network, the authors of [16] designed an effective certificate distribution mechanism based on the ECQV implicit certificate scheme in the vehicle cloud network. These schemes only make the research on cross-domain authentication in the distributed IoT architecture. Strictly speaking, the management domains in their study are not independent. Besides, they need to store implicit certificates and add additional storage overhead. The authors of [17] proposed a certificate-based scheme for cross-domain IoT, which is a lightweight authentication scheme based on consortium blockchain and designed a cryptocurrency-like digital token to build trust. This scheme has obvious advantages in computation and communication overhead, but it only realizes one-way authentication and provides additional overhead for certificate storage.


### 2.2. Identity-Based Schemes

Considering the advantages of identity-based cryptography (IBC), many identity-based authentication schemes have been proposed. An identity-based mutual authentication scheme for power line communication (PLC) was developed [18]. Similarly, the authors of [19] proposed an identity-based authentication scheme for cloud computing, which is considered more effective than the SSL authentication protocol. However, this scheme does not consider the mutual authentication of terminal devices. The authors of [9] proposed a blockchain-assisted entities authentication mechanism BASA for IIoT cross-domain. Specifically, the authors utilized a consortium blockchain to realize decentralization and build trust between different factory domains. Besides, identity-based signature (IBS) was used for identity authentication, and ECDHE was adopted to negotiate the session key. In their work, cross-domain identity authentication was completed under the cooperation of key generation center (KGC), authentication agent server (AAS), and blockchain agent server (BAS), which needs a lot of executions and interactions among the coordination elements and causes a large communication overhead. In the IIoT scenario, the authors of [20] proposed a cloud-based cross-domain data sharing platform based on multiple security gateways. These security gateways store information in a centralized cloud with the aid of blockchain. In this scheme, recent technologies such as blockchain, machine learning, ECDHE, IBS, and cloud computing are used to realize the trust of cross-domain communication between entities. But it is not secured for sharing data, and the authors only verify the user or organization to exchange the data. By combining the IoT platform and the Hyperledger Fabric framework, the authors of [21] proposed a framework sash for IoT data sharing. In this framework, the blockchain was used to store access control policies and make access control decisions. At the same time, identity-based encryption is used to provide encryption mandatory access control. The authors have not defined how to distribute the encryption key to decrypt the obtained data, and the use of the encryption key distribution agencies has brought the problems of centralized networks and reliance on authority. The authors of [22] built a secure, lightweight, and blockchain-based IoT cross-domain access control system by integrating licensed blockchain, attribute-based access control, and identity-based signature. The authors of [23] proposed a decentralized IoT authentication scheme A2chain, which is based on IBC. This scheme uses edge computing to disperse the processing of authentication requests and eliminate the burden of authentication and uses blockchain and sidechain technology to securely share authentication information. But this scheme only provides mutual authentication between the terminal device in domain A and the edge authentication server in domain B and not between the terminal device, and there is no session key negotiation. All abovementioned schemes utilize the blockchain technology to achieve decentralization, but the inherent key escrow problem of IBC can lead to KGC to decrypt any ciphertext of any user and forge a signature on any message. Therefore, IBC seems to be only applicable to small private networks with low-security requirements and inevitably faces some security challenges in cross-domain communication.


### 2.3. Certificateless-Based Schemes

To solve the inherent problem of key escrow in IBC, Al-Riyami and Paterson proposed the CL-PKC. The certificateless signature scheme is one of the several feasible methods to provide data integrity and user identity security for the devices with limited resources. In the current research, the applications of the certificateless schemes in the IoT scenario are often combined with signcryption schemes. The authors of [24] proposed a short signcryption scheme S-ECSC based on the elliptic curve cryptosystem for the IoT scenarios, which provides confidentiality and unforgeability and ensures secure data storage and transmission. The wireless body area network (WBAN) is one of the emerging technologies of the IoT. The authors of [25] designed a lightweight and provable secure cross-domain access control scheme for WBAN. This scheme adopts a certificateless signcryption scheme on the application provider and an identity-based signcryption scheme on the WBAN. For the security and efficiency of data transmission, the authors of [26] constructed a secure and lightweight hybrid signcryption scheme for the IoT. This scheme effectively protects the secure communication between nodes with limited resources in the IoT. Unfortunately, all abovementioned research only provides a signcryption scheme that may be applicable to the IoT scenario but does not give a complete entity authentication scheme. Besides, there are still many research on the applications of certificateless schemes in the IoT scenario, which will not be repeated here. The signcryption scheme was first proposed by [27]. At the same time, the author pointed out that not all messages need to be encrypted and signed at the same time, that is, the encryption-only mode and the signature-only mode. We know that encryption is not indispensable in the key agreement process. Usually, the signature-only mode is needed to ensure the integrity of data. Therefore, we consider using the certificateless signature scheme in our scheme during the mutual authentication stage and key agreement stage.


## 2.1. Certificate-Based Schemes

Due to the resource limitation of wireless sensor networks, security solutions based on the elliptic curve are often used in wireless sensor networks. Several implicit certificate schemes for wireless sensor networks were introduced [10, 11]. In addition, the applications in IoT scenario of ECQV implicit certificate schemes have been well studied. By combining Elliptic Curve Diffie-Hellman (ECDH) key exchange mechanisms and ECQV implicit certificate scheme, a key management protocol suitable for mobile and IIoT systems was proposed [12]. For robust key negotiation, lightweight node authentication, fast key reset, and effective replay attack protection, the ECQV implicit certificate scheme was used to make a lightweight security association suitable for IoT devices [13]. Considering the deficiency of the PAuthKey protocol, it does not clearly point out how to share the network key between IoT devices, and CA only authenticates each authorized device based on the network key rather than a single key. The authors propose a new ECQV implicit certificate-based protocol, which solves the problem of the PAuthKey protocol. The first nontrivial identity-based authentication (IBI) scheme [14] with implicit authentication is given by using the ECQV implicit certificate scheme. Compared with the traditional identity-based scheme, the method based on implicit certificates can resist key escrow. All the above research studies pay attention to authentication in the single-domain. Besides, there are also some research studies based on the ECQV implicit certificate scheme in IoT cross-domain scenarios. To maintain the reliable connection and accessibility of IoT devices distributed in different domains, the authors of [15] proposed an authentication mechanism based on the ECQV implicit certificate scheme. This two-stage authentication protocol allows sensor nodes and end-users to make mutual authentication and establish a secure connection. For realizing efficient and dynamic certificate distribution at a lower cost in the vehicle cloud network, the authors of [16] designed an effective certificate distribution mechanism based on the ECQV implicit certificate scheme in the vehicle cloud network. These schemes only make the research on cross-domain authentication in the distributed IoT architecture. Strictly speaking, the management domains in their study are not independent. Besides, they need to store implicit certificates and add additional storage overhead. The authors of [17] proposed a certificate-based scheme for cross-domain IoT, which is a lightweight authentication scheme based on consortium blockchain and designed a cryptocurrency-like digital token to build trust. This scheme has obvious advantages in computation and communication overhead, but it only realizes one-way authentication and provides additional overhead for certificate storage.


## 2.2. Identity-Based Schemes

Considering the advantages of identity-based cryptography (IBC), many identity-based authentication schemes have been proposed. An identity-based mutual authentication scheme for power line communication (PLC) was developed [18]. Similarly, the authors of [19] proposed an identity-based authentication scheme for cloud computing, which is considered more effective than the SSL authentication protocol. However, this scheme does not consider the mutual authentication of terminal devices. The authors of [9] proposed a blockchain-assisted entities authentication mechanism BASA for IIoT cross-domain. Specifically, the authors utilized a consortium blockchain to realize decentralization and build trust between different factory domains. Besides, identity-based signature (IBS) was used for identity authentication, and ECDHE was adopted to negotiate the session key. In their work, cross-domain identity authentication was completed under the cooperation of key generation center (KGC), authentication agent server (AAS), and blockchain agent server (BAS), which needs a lot of executions and interactions among the coordination elements and causes a large communication overhead. In the IIoT scenario, the authors of [20] proposed a cloud-based cross-domain data sharing platform based on multiple security gateways. These security gateways store information in a centralized cloud with the aid of blockchain. In this scheme, recent technologies such as blockchain, machine learning, ECDHE, IBS, and cloud computing are used to realize the trust of cross-domain communication between entities. But it is not secured for sharing data, and the authors only verify the user or organization to exchange the data. By combining the IoT platform and the Hyperledger Fabric framework, the authors of [21] proposed a framework sash for IoT data sharing. In this framework, the blockchain was used to store access control policies and make access control decisions. At the same time, identity-based encryption is used to provide encryption mandatory access control. The authors have not defined how to distribute the encryption key to decrypt the obtained data, and the use of the encryption key distribution agencies has brought the problems of centralized networks and reliance on authority. The authors of [22] built a secure, lightweight, and blockchain-based IoT cross-domain access control system by integrating licensed blockchain, attribute-based access control, and identity-based signature. The authors of [23] proposed a decentralized IoT authentication scheme A2chain, which is based on IBC. This scheme uses edge computing to disperse the processing of authentication requests and eliminate the burden of authentication and uses blockchain and sidechain technology to securely share authentication information. But this scheme only provides mutual authentication between the terminal device in domain A and the edge authentication server in domain B and not between the terminal device, and there is no session key negotiation. All abovementioned schemes utilize the blockchain technology to achieve decentralization, but the inherent key escrow problem of IBC can lead to KGC to decrypt any ciphertext of any user and forge a signature on any message. Therefore, IBC seems to be only applicable to small private networks with low-security requirements and inevitably faces some security challenges in cross-domain communication.


## 2.3. Certificateless-Based Schemes

To solve the inherent problem of key escrow in IBC, Al-Riyami and Paterson proposed the CL-PKC. The certificateless signature scheme is one of the several feasible methods to provide data integrity and user identity security for the devices with limited resources. In the current research, the applications of the certificateless schemes in the IoT scenario are often combined with signcryption schemes. The authors of [24] proposed a short signcryption scheme S-ECSC based on the elliptic curve cryptosystem for the IoT scenarios, which provides confidentiality and unforgeability and ensures secure data storage and transmission. The wireless body area network (WBAN) is one of the emerging technologies of the IoT. The authors of [25] designed a lightweight and provable secure cross-domain access control scheme for WBAN. This scheme adopts a certificateless signcryption scheme on the application provider and an identity-based signcryption scheme on the WBAN. For the security and efficiency of data transmission, the authors of [26] constructed a secure and lightweight hybrid signcryption scheme for the IoT. This scheme effectively protects the secure communication between nodes with limited resources in the IoT. Unfortunately, all abovementioned research only provides a signcryption scheme that may be applicable to the IoT scenario but does not give a complete entity authentication scheme. Besides, there are still many research on the applications of certificateless schemes in the IoT scenario, which will not be repeated here. The signcryption scheme was first proposed by [27]. At the same time, the author pointed out that not all messages need to be encrypted and signed at the same time, that is, the encryption-only mode and the signature-only mode. We know that encryption is not indispensable in the key agreement process. Usually, the signature-only mode is needed to ensure the integrity of data. Therefore, we consider using the certificateless signature scheme in our scheme during the mutual authentication stage and key agreement stage.


## 3. Preliminaries

In this section, we introduce some basic knowledge. The list of the key notations used in this article is represented in Table1.Table 1
Description of notations.
NotationDescriptionGA cyclic group of orderqPThe generator of groupGeBilinear mapH⋅Hash functionSign⋅Signature functionparamThe system public parametersPk/SkThe public/private key of entity orKGCUVThe entity of domainIDUnique identificationPIDThe anonymous identity of entityKGCThe key generation center of domainBASThe blockchain agent server of domainLetp be a prime number greater than 3; a nonsingular elliptic curve E defined on the finite field Fp is composed of points satisfying the equation y2=x3+ax+bmodp and a point representing infinity denoted by O, where a,b∈Fp and 4a3+27b2≠0modp. Let G be the set of all points on the elliptic curve, namely,(1)G=x,y:y2=x3+ax+bmodp∪O.


### 3.1. Bilinear Pairing

LetG1 be an additive cyclic group generated by P, whose order is prime q, and G2 is a multiplicative cyclic group with the same order. Bilinear pairing e:G1×G1⟶G2 satisfies the following properties:(1)
Bilinearity: for anyP,Q,R∈G1, we have eP+R,Q=eP,QeR,Q and eP,Q+R=eP,QeP,R. Especially, given any a,b∈Zq∗, we have(2)eaP,bP=eP,Pab=eP,abP=eabP,P.(2)
Nondegeneracy: there existsP,Q∈G1, such that eP,Q≠1.(3)
Computability: given anyP,Q∈G1, there exists a polynomial-time algorithm to compute eP,Q∈G2.


### 3.2. Complexity Assumptions

G is an additive cyclic group generated by P, and its order is q. The difficult assumption of the ECCDH states that, for randomly chosen a,b∈Zq∗, given P,aP,bP, it is not feasible to compute abP for any polynomial-time algorithm with nonnegligible probability.


## 3.1. Bilinear Pairing

LetG1 be an additive cyclic group generated by P, whose order is prime q, and G2 is a multiplicative cyclic group with the same order. Bilinear pairing e:G1×G1⟶G2 satisfies the following properties:(1)
Bilinearity: for anyP,Q,R∈G1, we have eP+R,Q=eP,QeR,Q and eP,Q+R=eP,QeP,R. Especially, given any a,b∈Zq∗, we have(2)eaP,bP=eP,Pab=eP,abP=eabP,P.(2)
Nondegeneracy: there existsP,Q∈G1, such that eP,Q≠1.(3)
Computability: given anyP,Q∈G1, there exists a polynomial-time algorithm to compute eP,Q∈G2.


## 3.2. Complexity Assumptions

G is an additive cyclic group generated by P, and its order is q. The difficult assumption of the ECCDH states that, for randomly chosen a,b∈Zq∗, given P,aP,bP, it is not feasible to compute abP for any polynomial-time algorithm with nonnegligible probability.


## 4. Certificateless Signature and Security Model

In this section, we briefly introduce the generic construction of the certificateless signature, security model, and our anonymous certificateless short signature scheme.


### 4.1. Generic Construction of Certificateless Signature

CL-PKS scheme involves three entities, namely, KGC, user/signer, and verifier. Generally, it consists of the following PPT algorithms: Setup, Partial-Private-Key-Extract, Set-Secret-Value, Set-Secret-Key, Set-Public-Key, Sign, and Verify.Setup: KGC takes the security parameters as the input and returns the master keys and the system parameter param.Partial-Private-Key-Extract: KGC takes the system parametersparam, s, and user ID as inputs. Then, KGC generates the partial private key DID and sends it to the user through a secure channel.Set-Secret-Value: the user randomly chooses a secret valuerID.Set-Secret-Key: the user takes the partial private keyDID and its secret value rID as inputs and then returns its complete private key SkID.Set-Public- Key: the user takesparam and its complete private key SkID as inputs and returns its public key PkID.Sign: the signer/user takesparam, message m, and its complete private key SkID as inputs. Then, it generates a signature σ of the message m.Verify: the verifier takesparam, public key PkID, message m, user’s ID, and signature σ as inputs and returns True or False to indicate the validity of the signature.


### 4.2. Security Model

Al-Riyami and Paterson [4] proposed the concept of the certificateless public key signature (CL-PKS) and defined the first security model. In their model, the security evaluation of CL-PKS considers two types of adversaries, namely, type I adversary and type II adversary. Type I adversary is an external attacker who can replace any legitimate public key with the public key chosen by it. This adversary simulates the ability of the adversary to deceive the user to verify the signature with the public key chosen by it. Type I adversaries should not hold the partial private key of the user. While, the Type II adversary models a malicious KGC, which holds the secret master key. Thus, it means that it can obtain the partial private key of any user. However, the type II adversary cannot replace the public key of the target user. After that, some researchers studied the formal security model definition of the CL-PKS schemes. Especially, according to the attack ability of potential adversaries in the certificateless signature, Huang et al. [28] divided the adversaries into three new types adversaries for the first time, that is, normal adversary, strong adversary, and super adversary (in the order of attack power from low to high). By combining the type I adversary and type II adversary previously defined in the CL-PKS, the authors defined the security of the CL-PKS under different adversary scenarios. Here, we adopt the formal security model introduced by Huang et al. [28] and prove that our certificateless short signature scheme satisfies the existential unforgeability security for the super adversary under the random oracle model. Next, we show the detailed description of the security model. It is formalized through two games between the challengers and a super type I or type II adversary.


#### 4.2.1. Game I

A challengerℬI runs the algorithm, CL.Setup, to generate the master key s and the public parameters param. Then, it sends the param to the super type I adversary AI and keeps master key s secret. After that, AI makes polynomial times queries for the following oracles to ℬI.CreateUser: for some query on an identityID, if this ID has already been created, ℬI returns ID,PID,PkID to AI. Otherwise, ℬI calls the algorithms Cl.Partial-Private-Key-Extract, CL.Set-User-Value, Set-User-Key, and Set-Public-Key, respectively, to obtain ID,PID,PIDID,DID,rID,PkID and returns ID,PID,PkID to AI.Partial-Private-Key-Extract: when receiving this query onID,RID, ℬI returns the partial key DID to AI.Public-Key-Replace: when receiving this query onID,rID′,PkID′, ℬI uses PkID′ to replace the original public key PkID.Secret-Value-Extract: when receiving this query onID, ℬI returns rID to AI. If Public-Key-Replace query has been issued without providing a corresponding rID′, we require that it is not permitted to query Secret-Value-Extract with ID.Super-Sign: when receiving this query onID,PIDID,m, ℬI calls the algorithm, CL.Sign, and returns a signature σ that satisfies CL.Verify (param,PIDID, PkID, m, σ) = true to AI. Note that PkID is the latest public key.After making all the queries,AI submits a forged signature σ∗ on the message m∗ as the target identity ID∗. AI is said to succeed in Game I if the following conditions are satisfied:(1)
CL.Verify (ID∗,param,PIDID∗, PkID∗, m∗, σ∗) = true(2)
AI did not make Super-Sign query with ID∗,PIDID∗,m∗(3)
AI did not make Partial-Private-Key-Extract query with ID∗,RID∗


#### 4.2.2. Game II

This game is executed between a super type II adversaryAII and a challenger ℬII. This game proceeds as follows: a challenger ℬII runs the algorithm CL.Setup to generate the master key s and the public parameters param. Then, it sends param to the super type II adversary AII and keeps master key s secret. After that, AII issues CreateUser, Partial-Private-Key-Extract, Public-Key-Replace, Secret-Value-Extract, and Super-Sign oracles as described in the Game I, and ℬII makes the corresponding responses in the same way as ℬI in the Game I.After making all the queries,AII submits a forged signature σ∗ on the message m∗ as the target identity ID∗. AII is said to succeed in Game II if the following conditions are satisfied:(1)
CL.Verify(ID∗,param,PIDID∗, PkID∗, m∗, σ∗) = true(2)
AII did not make Super-Sign query with ID∗,PIDID∗,m∗(3)
AII did not make Partial-Private-Key-Extract query with ID∗,RID∗(4)
AII did not make Public-Key-Replace query with ID∗,rID∗′,PkID∗′Definition 1.
A CL-PKS scheme is existentially unforgeable against adaptively chosen message attacks (EUF-CMA), if for any polynomial-time super adversary (super type I or super type II), the advantage of super adversary is negligible.


### 4.3. Our Certificateless Signature Scheme

In this section, we embed the anonymity into the generic certificateless signature scheme and give a certificateless short signature scheme with anonymity. Here is our certificateless scheme.CL.Setup1k:(1)
Select an elliptic curveE:y3=x2+ax+b, which is defined in a prime field Fp. Generate G1,G2,e, where G1 is an additive group of order q, whose generator is P; G2 is a multiplicative group of order q; bilinear pair e:G1×G1⟶G2.(2)
Randomly choose a numbers∈Zq∗ as the master key. Then, compute the master public key Ppub=sP.(3)
Select three collision resistance hash functionsH1,H2:0,1∗⟶Zq∗, H3:0,1∗⟶G1.(4)
Output the system parameterparam=G1,G2,e,q,P,Ppub,H1,H2,H3.CL.Set-User-Value (IDU, Ppub):(1)
Randomly chooserU∈Zq∗ and compute RU=rUP(2)
OutputRU,rUCL.Extract-Partial-Key(IDU, Ppub, RU, s):(1)
Randomly selectk∈Zq∗ and compute PU=kP, PIDU=H1IDU,PU,RUP, DU=sPIDU.(2)
LetPkU=RU and output PIDU,DU.CL.Set-User-Key (IDU, Ppub,PIDU, DU, rU):(1)
SavePIDU as anonymous identity, and let SkU=DU,rUCL.Set-Public-Key (IDU, Ppub, PIDU, RU):(1)
LetPkU=RUCL.Sign (param,PIDU, SkU, m):(1)
Computeh2=H2PIDU,Ppub,PkU,m, h3=H3PIDU,Ppub,PkU,m(2)
Generate signatureσ=h2DU+rUh3CL.Verify (param,PIDU, PkU, m):(1)
Computeh2=H2PIDU,Ppub,PkU,m, h3=H3PIDU,Ppub,PkU,m(2)
Verifyeσ,P=eh2PIDU,Ppubeh3,PkU, if it holds, the signature σ is acceptedCorrectness: if the anonymous identity isPIDU, public key PkU and signature σ are generated according to the above signature scheme. The following equation ensures the correctness of the signature scheme, that is,(3)eσ,P=eh2DU+rUh3,P=eh2DU,PerUh3,P=eh2PIDU,Ppubeh3,PkU.


## 4.1. Generic Construction of Certificateless Signature

CL-PKS scheme involves three entities, namely, KGC, user/signer, and verifier. Generally, it consists of the following PPT algorithms: Setup, Partial-Private-Key-Extract, Set-Secret-Value, Set-Secret-Key, Set-Public-Key, Sign, and Verify.Setup: KGC takes the security parameters as the input and returns the master keys and the system parameter param.Partial-Private-Key-Extract: KGC takes the system parametersparam, s, and user ID as inputs. Then, KGC generates the partial private key DID and sends it to the user through a secure channel.Set-Secret-Value: the user randomly chooses a secret valuerID.Set-Secret-Key: the user takes the partial private keyDID and its secret value rID as inputs and then returns its complete private key SkID.Set-Public- Key: the user takesparam and its complete private key SkID as inputs and returns its public key PkID.Sign: the signer/user takesparam, message m, and its complete private key SkID as inputs. Then, it generates a signature σ of the message m.Verify: the verifier takesparam, public key PkID, message m, user’s ID, and signature σ as inputs and returns True or False to indicate the validity of the signature.


## 4.2. Security Model

Al-Riyami and Paterson [4] proposed the concept of the certificateless public key signature (CL-PKS) and defined the first security model. In their model, the security evaluation of CL-PKS considers two types of adversaries, namely, type I adversary and type II adversary. Type I adversary is an external attacker who can replace any legitimate public key with the public key chosen by it. This adversary simulates the ability of the adversary to deceive the user to verify the signature with the public key chosen by it. Type I adversaries should not hold the partial private key of the user. While, the Type II adversary models a malicious KGC, which holds the secret master key. Thus, it means that it can obtain the partial private key of any user. However, the type II adversary cannot replace the public key of the target user. After that, some researchers studied the formal security model definition of the CL-PKS schemes. Especially, according to the attack ability of potential adversaries in the certificateless signature, Huang et al. [28] divided the adversaries into three new types adversaries for the first time, that is, normal adversary, strong adversary, and super adversary (in the order of attack power from low to high). By combining the type I adversary and type II adversary previously defined in the CL-PKS, the authors defined the security of the CL-PKS under different adversary scenarios. Here, we adopt the formal security model introduced by Huang et al. [28] and prove that our certificateless short signature scheme satisfies the existential unforgeability security for the super adversary under the random oracle model. Next, we show the detailed description of the security model. It is formalized through two games between the challengers and a super type I or type II adversary.


### 4.2.1. Game I

A challengerℬI runs the algorithm, CL.Setup, to generate the master key s and the public parameters param. Then, it sends the param to the super type I adversary AI and keeps master key s secret. After that, AI makes polynomial times queries for the following oracles to ℬI.CreateUser: for some query on an identityID, if this ID has already been created, ℬI returns ID,PID,PkID to AI. Otherwise, ℬI calls the algorithms Cl.Partial-Private-Key-Extract, CL.Set-User-Value, Set-User-Key, and Set-Public-Key, respectively, to obtain ID,PID,PIDID,DID,rID,PkID and returns ID,PID,PkID to AI.Partial-Private-Key-Extract: when receiving this query onID,RID, ℬI returns the partial key DID to AI.Public-Key-Replace: when receiving this query onID,rID′,PkID′, ℬI uses PkID′ to replace the original public key PkID.Secret-Value-Extract: when receiving this query onID, ℬI returns rID to AI. If Public-Key-Replace query has been issued without providing a corresponding rID′, we require that it is not permitted to query Secret-Value-Extract with ID.Super-Sign: when receiving this query onID,PIDID,m, ℬI calls the algorithm, CL.Sign, and returns a signature σ that satisfies CL.Verify (param,PIDID, PkID, m, σ) = true to AI. Note that PkID is the latest public key.After making all the queries,AI submits a forged signature σ∗ on the message m∗ as the target identity ID∗. AI is said to succeed in Game I if the following conditions are satisfied:(1)
CL.Verify (ID∗,param,PIDID∗, PkID∗, m∗, σ∗) = true(2)
AI did not make Super-Sign query with ID∗,PIDID∗,m∗(3)
AI did not make Partial-Private-Key-Extract query with ID∗,RID∗


### 4.2.2. Game II

This game is executed between a super type II adversaryAII and a challenger ℬII. This game proceeds as follows: a challenger ℬII runs the algorithm CL.Setup to generate the master key s and the public parameters param. Then, it sends param to the super type II adversary AII and keeps master key s secret. After that, AII issues CreateUser, Partial-Private-Key-Extract, Public-Key-Replace, Secret-Value-Extract, and Super-Sign oracles as described in the Game I, and ℬII makes the corresponding responses in the same way as ℬI in the Game I.After making all the queries,AII submits a forged signature σ∗ on the message m∗ as the target identity ID∗. AII is said to succeed in Game II if the following conditions are satisfied:(1)
CL.Verify(ID∗,param,PIDID∗, PkID∗, m∗, σ∗) = true(2)
AII did not make Super-Sign query with ID∗,PIDID∗,m∗(3)
AII did not make Partial-Private-Key-Extract query with ID∗,RID∗(4)
AII did not make Public-Key-Replace query with ID∗,rID∗′,PkID∗′Definition 1.
A CL-PKS scheme is existentially unforgeable against adaptively chosen message attacks (EUF-CMA), if for any polynomial-time super adversary (super type I or super type II), the advantage of super adversary is negligible.


## 4.2.1. Game I

A challengerℬI runs the algorithm, CL.Setup, to generate the master key s and the public parameters param. Then, it sends the param to the super type I adversary AI and keeps master key s secret. After that, AI makes polynomial times queries for the following oracles to ℬI.CreateUser: for some query on an identityID, if this ID has already been created, ℬI returns ID,PID,PkID to AI. Otherwise, ℬI calls the algorithms Cl.Partial-Private-Key-Extract, CL.Set-User-Value, Set-User-Key, and Set-Public-Key, respectively, to obtain ID,PID,PIDID,DID,rID,PkID and returns ID,PID,PkID to AI.Partial-Private-Key-Extract: when receiving this query onID,RID, ℬI returns the partial key DID to AI.Public-Key-Replace: when receiving this query onID,rID′,PkID′, ℬI uses PkID′ to replace the original public key PkID.Secret-Value-Extract: when receiving this query onID, ℬI returns rID to AI. If Public-Key-Replace query has been issued without providing a corresponding rID′, we require that it is not permitted to query Secret-Value-Extract with ID.Super-Sign: when receiving this query onID,PIDID,m, ℬI calls the algorithm, CL.Sign, and returns a signature σ that satisfies CL.Verify (param,PIDID, PkID, m, σ) = true to AI. Note that PkID is the latest public key.After making all the queries,AI submits a forged signature σ∗ on the message m∗ as the target identity ID∗. AI is said to succeed in Game I if the following conditions are satisfied:(1)
CL.Verify (ID∗,param,PIDID∗, PkID∗, m∗, σ∗) = true(2)
AI did not make Super-Sign query with ID∗,PIDID∗,m∗(3)
AI did not make Partial-Private-Key-Extract query with ID∗,RID∗


## 4.2.2. Game II

This game is executed between a super type II adversaryAII and a challenger ℬII. This game proceeds as follows: a challenger ℬII runs the algorithm CL.Setup to generate the master key s and the public parameters param. Then, it sends param to the super type II adversary AII and keeps master key s secret. After that, AII issues CreateUser, Partial-Private-Key-Extract, Public-Key-Replace, Secret-Value-Extract, and Super-Sign oracles as described in the Game I, and ℬII makes the corresponding responses in the same way as ℬI in the Game I.After making all the queries,AII submits a forged signature σ∗ on the message m∗ as the target identity ID∗. AII is said to succeed in Game II if the following conditions are satisfied:(1)
CL.Verify(ID∗,param,PIDID∗, PkID∗, m∗, σ∗) = true(2)
AII did not make Super-Sign query with ID∗,PIDID∗,m∗(3)
AII did not make Partial-Private-Key-Extract query with ID∗,RID∗(4)
AII did not make Public-Key-Replace query with ID∗,rID∗′,PkID∗′Definition 1.
A CL-PKS scheme is existentially unforgeable against adaptively chosen message attacks (EUF-CMA), if for any polynomial-time super adversary (super type I or super type II), the advantage of super adversary is negligible.


## 4.3. Our Certificateless Signature Scheme

In this section, we embed the anonymity into the generic certificateless signature scheme and give a certificateless short signature scheme with anonymity. Here is our certificateless scheme.CL.Setup1k:(1)
Select an elliptic curveE:y3=x2+ax+b, which is defined in a prime field Fp. Generate G1,G2,e, where G1 is an additive group of order q, whose generator is P; G2 is a multiplicative group of order q; bilinear pair e:G1×G1⟶G2.(2)
Randomly choose a numbers∈Zq∗ as the master key. Then, compute the master public key Ppub=sP.(3)
Select three collision resistance hash functionsH1,H2:0,1∗⟶Zq∗, H3:0,1∗⟶G1.(4)
Output the system parameterparam=G1,G2,e,q,P,Ppub,H1,H2,H3.CL.Set-User-Value (IDU, Ppub):(1)
Randomly chooserU∈Zq∗ and compute RU=rUP(2)
OutputRU,rUCL.Extract-Partial-Key(IDU, Ppub, RU, s):(1)
Randomly selectk∈Zq∗ and compute PU=kP, PIDU=H1IDU,PU,RUP, DU=sPIDU.(2)
LetPkU=RU and output PIDU,DU.CL.Set-User-Key (IDU, Ppub,PIDU, DU, rU):(1)
SavePIDU as anonymous identity, and let SkU=DU,rUCL.Set-Public-Key (IDU, Ppub, PIDU, RU):(1)
LetPkU=RUCL.Sign (param,PIDU, SkU, m):(1)
Computeh2=H2PIDU,Ppub,PkU,m, h3=H3PIDU,Ppub,PkU,m(2)
Generate signatureσ=h2DU+rUh3CL.Verify (param,PIDU, PkU, m):(1)
Computeh2=H2PIDU,Ppub,PkU,m, h3=H3PIDU,Ppub,PkU,m(2)
Verifyeσ,P=eh2PIDU,Ppubeh3,PkU, if it holds, the signature σ is acceptedCorrectness: if the anonymous identity isPIDU, public key PkU and signature σ are generated according to the above signature scheme. The following equation ensures the correctness of the signature scheme, that is,(3)eσ,P=eh2DU+rUh3,P=eh2DU,PerUh3,P=eh2PIDU,Ppubeh3,PkU.


## 5. Our CL-BASA Scheme

In this section, we will introduce our authentication and key agreement scheme CL-BASA for IIot devices cross-domain communication and describe its main structure.


### 5.1. The Layered Design of CL-BASA Scheme

Here, we employ the layered architecture proposed in [9]. The difference is that considering that the servers in the agent layer are still the nodes in domain, we put the entity layer and the agent layer in [9] together as the entity layer. Our layered architecture is as follows:As shown in Figure1, in our CL-BASA scheme, IIoT devices, key generation center (KGC), and blockchain agent server (BAS) are all in the entity layer. The blockchain layer is used as a public security platform for sharing domain-specific information, which includes domain identifier, its binding value is composed of the uniform resource identifier (URI), and the hash value is calculated on the actual domain-specific data. The URI points to the actual files stored in the storage layer. The following is a brief introduction to the functions of each layer:Figure 1
Layered architecture of our CL-BASA scheme.The entity layer includes IIoT devices, KGC, and BAS. IIoT devices are manufacturing facilities that are responsible for specific tasks. KGC generates the anonymous identity and the partial private key for each device in its domain and cooperates with BAS to update the information of the device (including anonymous identity and public key) to the consortium blockchain;BASA and BASB represent blockchain agent servers (such as edge servers) in domain A and domain B, respectively. Their functions include the following: updating the devices information on the consortium blockchain in cooperation with KGC and responding to the requests for domain-specific information of other domains.The functions of the blockchain in our scheme are the same with [9], so we make a brief introduction. For a detailed introduction, please refer to [9]. The blockchain layer represents the consortium blockchain used underneath. It is a globally distributed ledger, which is composed of blocks encapsulating transactions. These blocks carry domain-specific information related to different management domains. This information is shared between each domain and used for cross-domain authentication. The global ledger is maintained by a preselected set of nodes, and each node represents the BAS of a management domain. The format of domain-specific information written into the ledger is shown in Figure 2.Figure 2
Data fields indicating domain-specific information encapsulated into transaction [9].IDdomain represents the unique identifier of a domain, which is used to distinguish other domains. The URI here points to a file hosted on the cloud service, which stores the details of domain-specific information. The hash value is calculated according to the actual file of specific-domain information. It is used to verify the integrity of the actual specific-domain information file, for preventing it from being modified by malicious adversaries or cloud service providers.What the storage layer stores are the files that the URI in the blockchain layer points to and is hosted in the cloud server outside the blockchain. The file contains the following information: domain name, domain master public key, domain system parameters, anonymous identity, and public key list of the domain entities.


### 5.2. Our CL-BASA Scheme

In this section, based on our anonymous certificateless short signature designed in Section4 and ECDHE key exchange mechanism, we show a two-stage cross-domain authentication and key agreement scheme CL-BASA with the aid of blockchain. The proposed scheme is shown in Figure 3. U and V represent two cross-domain IIoT entities; KGCA represents the key generation centers of domain A (KGCB in domain B, respectively); BASA represents blockchain agent servers (such as edge servers) in domain A (BASB in domain B, respectively).Figure 3
The authentication process of our CL-BASA scheme.Our CL-BASA scheme consists of two stages, namely, registration stage and authentication and key agreement stage. These two stages are described in detail as follows.


#### 5.2.1. Registration Stage

Devices in each domain perform this phase via a secure channel when they are deployed. Then, the user and KGC perform the key generation process of our short signature scheme (see Figure4) and generate the anonymous identity and public/private key pair for each user. During this process, with the cooperation of KGC, BAS updates the user’s anonymous identity and public key on the consortium blockchain.Figure 4
The registration process of our CL-BASA.Taking userU as an example, first, U randomly generates the public key RU. Then, Usends U,RU to KGCA through a secure channel to request registration. KGCA generates PU randomly after receiving U,RU, generates U′s anonymous identity PIDU and partial private key DU, and saves RU as the public key PkU of U. KGCA sends an update request to BASA and receives an update response. After BASA updates the information of user U in the blockchain, KGCA sends PIDU,DU to user U through a secure channel. After receiving PIDU,DU, U saves PIDU as its anonymous identity and generates the complete private key SkU.Anonymous identity management mechanism: taking userU as an example. In our proposed scheme, the anonymous identity of user U is maintained and controlled by KGCA. During user registration, KGCA sets a time window for each user’s anonymous identity. The expire-time of the user’s anonymous identity is the current time plus the corresponding time window. When the anonymous identity expires, KGCA sends a reregistration request to U (step 0 in Figure 3). After receiving the reregistration request sent by KGCA, U executes the registration phase again (steps 1–4 in Figure 3). KGCA selects the random PU after receiving the registration request of U and calculates the new anonymous identity and some partial private key for user U. Then, after cooperating with BASA to update the information of U in the blockchain, KGCA sends the anonymous identity and the partial private key of U to user U, and KGCA sets an expiration time for the new anonymous identity of U. PU reserved here is to facilitate the maintenance and management of U′s anonymous identity by KGCA, which can be regarded as the coding of the expire time of user U′s anonymous identity on the elliptic curve E.


#### 5.2.2. Authentication and Key Agreement Stage

In this section, we introduce the authentication and key agreement process of our scheme in detail. We assume that the user’s anonymous identity is valid. Otherwise, the user re-executes the registration phase. When userU in domain A needs to communicate with user V in domain B, user U first interacts with BASA to obtain the domain-specific information of domain B and the public information of user V, that is, steps 5 and 6 in Figure 3.In our authentication mechanism, the certificateless signature of Section4 is used. When requesting authentication, an entity needs to provide the following information: the information of the signature private key corresponding to the claimed public key; the authenticity of identity and public key. The former can be reflected by using the claimed public key to verify the validity of the signature, while the latter is realized through the domain-specific information of each domain shared in the consortium blockchain.Assuming the initiator of authentication is the userU, the mutual authentication of U and V needs to be completed before cross-domain communication. The mutual authentication process is shown in Figure 5. The format of Token is as follows:(4)TokenUV=NUIDdomainAPIDUTextU‖SignSkUNUIDdomainAPIDUTextU,TokenVU=NVIDdomainBPIDVTextV‖SignSkVNVIDdomainBPIDVTextV,where NU is the nonrepeated random number randomly selected by U; SignSkUX is the signature of message X by U through the signature private key; TextU is an extended field.Figure 5
Mutual authentication model.Next, we show the authentication and key agreement process. During the authentication process, we utilize the Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key exchange mechanism to negotiate the session key, and the ECDHE key exchange mechanism is shown in Figure6. See Figure 7 for the detailed authentication and key agreement process.Figure 6
ECDHE key exchange mechanism.Figure 7
The authentication and key agreement process of our CL-BASA scheme.We assume that the authentication process is initiated byU in domain A. If the anonymous identity of U expires, U will re-execute the registration phase. Otherwise, U will send a request PIDU,reqinfA to BASA through a secure channel to obtain the system parameters of domain B and the anonymous identity and public key information of V. Here, IDdomainB represents the unique identifier of domain B, descripV indicates the function of the device V in domain B, and TSA represents the timestamp of domain A. After receiving the information request, BASA will verify the validation of TSA and PIDU. If they are valid, BASA will search the public information of domain B in the consortium chain and send IDBASA,respinfA to U through a secure channel. respinfA contains the system parameters of domain B, the anonymous identity and public key information of V. Then, after receiving the information response, U randomly selects the nonrepeated random number NU and rU′ and then calculates PkU′=rU′P as the ephemeral public key. U generates the message mU=NUIDdomainAPIDUPkU′ and uses the private key SkU to generate the signature σU of message mU by the signature algorithm. U sends mU,σU to V in domain B.After receiving the messagemU,σU, according to the plaintext information in mU, V will send mU to BASB through a secure channel to request the system parameters of domain A and the public key information of U and make a request for verifying the anonymous identity of U. If PIDU is valid, BASB returns the verification result, the system parameters of the domain A and the public key of U to V through a secure channel. This process is similar to the communication between U and BASA. After receiving the response from BASB, V uses U′s public key to verify the signature σU according to the signature verification algorithm. If the signature σU is valid, V accepts the message mU,σU. Then, V randomly selects the nonrepeated random number NV and rV′ and calculates the ephemeral public key PkV′=rV′P. V generates the message mV=NVIDdomainBPIDV‖PkV′ and uses the private key SkV to generate the signature σV of message mV by the signature algorithm. Then, V sends mV,σV to U and calculates the session key SkUV=rV′PkU′=rV′rU′P.After receiving the messagemV,σV, U verifies the authenticity of V′s anonymous identity. If the verification passes, U uses V′s public key to verify the signature σV according to the signature verification algorithm. If the signature σV is valid, U accepts the message mV,σV. Then, U calculates the session key SkUV=rU′PkV′=rU′rV′P.


## 5.1. The Layered Design of CL-BASA Scheme

Here, we employ the layered architecture proposed in [9]. The difference is that considering that the servers in the agent layer are still the nodes in domain, we put the entity layer and the agent layer in [9] together as the entity layer. Our layered architecture is as follows:As shown in Figure1, in our CL-BASA scheme, IIoT devices, key generation center (KGC), and blockchain agent server (BAS) are all in the entity layer. The blockchain layer is used as a public security platform for sharing domain-specific information, which includes domain identifier, its binding value is composed of the uniform resource identifier (URI), and the hash value is calculated on the actual domain-specific data. The URI points to the actual files stored in the storage layer. The following is a brief introduction to the functions of each layer:Figure 1
Layered architecture of our CL-BASA scheme.The entity layer includes IIoT devices, KGC, and BAS. IIoT devices are manufacturing facilities that are responsible for specific tasks. KGC generates the anonymous identity and the partial private key for each device in its domain and cooperates with BAS to update the information of the device (including anonymous identity and public key) to the consortium blockchain;BASA and BASB represent blockchain agent servers (such as edge servers) in domain A and domain B, respectively. Their functions include the following: updating the devices information on the consortium blockchain in cooperation with KGC and responding to the requests for domain-specific information of other domains.The functions of the blockchain in our scheme are the same with [9], so we make a brief introduction. For a detailed introduction, please refer to [9]. The blockchain layer represents the consortium blockchain used underneath. It is a globally distributed ledger, which is composed of blocks encapsulating transactions. These blocks carry domain-specific information related to different management domains. This information is shared between each domain and used for cross-domain authentication. The global ledger is maintained by a preselected set of nodes, and each node represents the BAS of a management domain. The format of domain-specific information written into the ledger is shown in Figure 2.Figure 2
Data fields indicating domain-specific information encapsulated into transaction [9].IDdomain represents the unique identifier of a domain, which is used to distinguish other domains. The URI here points to a file hosted on the cloud service, which stores the details of domain-specific information. The hash value is calculated according to the actual file of specific-domain information. It is used to verify the integrity of the actual specific-domain information file, for preventing it from being modified by malicious adversaries or cloud service providers.What the storage layer stores are the files that the URI in the blockchain layer points to and is hosted in the cloud server outside the blockchain. The file contains the following information: domain name, domain master public key, domain system parameters, anonymous identity, and public key list of the domain entities.


## 5.2. Our CL-BASA Scheme

In this section, based on our anonymous certificateless short signature designed in Section4 and ECDHE key exchange mechanism, we show a two-stage cross-domain authentication and key agreement scheme CL-BASA with the aid of blockchain. The proposed scheme is shown in Figure 3. U and V represent two cross-domain IIoT entities; KGCA represents the key generation centers of domain A (KGCB in domain B, respectively); BASA represents blockchain agent servers (such as edge servers) in domain A (BASB in domain B, respectively).Figure 3
The authentication process of our CL-BASA scheme.Our CL-BASA scheme consists of two stages, namely, registration stage and authentication and key agreement stage. These two stages are described in detail as follows.


### 5.2.1. Registration Stage

Devices in each domain perform this phase via a secure channel when they are deployed. Then, the user and KGC perform the key generation process of our short signature scheme (see Figure4) and generate the anonymous identity and public/private key pair for each user. During this process, with the cooperation of KGC, BAS updates the user’s anonymous identity and public key on the consortium blockchain.Figure 4
The registration process of our CL-BASA.Taking userU as an example, first, U randomly generates the public key RU. Then, Usends U,RU to KGCA through a secure channel to request registration. KGCA generates PU randomly after receiving U,RU, generates U′s anonymous identity PIDU and partial private key DU, and saves RU as the public key PkU of U. KGCA sends an update request to BASA and receives an update response. After BASA updates the information of user U in the blockchain, KGCA sends PIDU,DU to user U through a secure channel. After receiving PIDU,DU, U saves PIDU as its anonymous identity and generates the complete private key SkU.Anonymous identity management mechanism: taking userU as an example. In our proposed scheme, the anonymous identity of user U is maintained and controlled by KGCA. During user registration, KGCA sets a time window for each user’s anonymous identity. The expire-time of the user’s anonymous identity is the current time plus the corresponding time window. When the anonymous identity expires, KGCA sends a reregistration request to U (step 0 in Figure 3). After receiving the reregistration request sent by KGCA, U executes the registration phase again (steps 1–4 in Figure 3). KGCA selects the random PU after receiving the registration request of U and calculates the new anonymous identity and some partial private key for user U. Then, after cooperating with BASA to update the information of U in the blockchain, KGCA sends the anonymous identity and the partial private key of U to user U, and KGCA sets an expiration time for the new anonymous identity of U. PU reserved here is to facilitate the maintenance and management of U′s anonymous identity by KGCA, which can be regarded as the coding of the expire time of user U′s anonymous identity on the elliptic curve E.


### 5.2.2. Authentication and Key Agreement Stage

In this section, we introduce the authentication and key agreement process of our scheme in detail. We assume that the user’s anonymous identity is valid. Otherwise, the user re-executes the registration phase. When userU in domain A needs to communicate with user V in domain B, user U first interacts with BASA to obtain the domain-specific information of domain B and the public information of user V, that is, steps 5 and 6 in Figure 3.In our authentication mechanism, the certificateless signature of Section4 is used. When requesting authentication, an entity needs to provide the following information: the information of the signature private key corresponding to the claimed public key; the authenticity of identity and public key. The former can be reflected by using the claimed public key to verify the validity of the signature, while the latter is realized through the domain-specific information of each domain shared in the consortium blockchain.Assuming the initiator of authentication is the userU, the mutual authentication of U and V needs to be completed before cross-domain communication. The mutual authentication process is shown in Figure 5. The format of Token is as follows:(4)TokenUV=NUIDdomainAPIDUTextU‖SignSkUNUIDdomainAPIDUTextU,TokenVU=NVIDdomainBPIDVTextV‖SignSkVNVIDdomainBPIDVTextV,where NU is the nonrepeated random number randomly selected by U; SignSkUX is the signature of message X by U through the signature private key; TextU is an extended field.Figure 5
Mutual authentication model.Next, we show the authentication and key agreement process. During the authentication process, we utilize the Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key exchange mechanism to negotiate the session key, and the ECDHE key exchange mechanism is shown in Figure6. See Figure 7 for the detailed authentication and key agreement process.Figure 6
ECDHE key exchange mechanism.Figure 7
The authentication and key agreement process of our CL-BASA scheme.We assume that the authentication process is initiated byU in domain A. If the anonymous identity of U expires, U will re-execute the registration phase. Otherwise, U will send a request PIDU,reqinfA to BASA through a secure channel to obtain the system parameters of domain B and the anonymous identity and public key information of V. Here, IDdomainB represents the unique identifier of domain B, descripV indicates the function of the device V in domain B, and TSA represents the timestamp of domain A. After receiving the information request, BASA will verify the validation of TSA and PIDU. If they are valid, BASA will search the public information of domain B in the consortium chain and send IDBASA,respinfA to U through a secure channel. respinfA contains the system parameters of domain B, the anonymous identity and public key information of V. Then, after receiving the information response, U randomly selects the nonrepeated random number NU and rU′ and then calculates PkU′=rU′P as the ephemeral public key. U generates the message mU=NUIDdomainAPIDUPkU′ and uses the private key SkU to generate the signature σU of message mU by the signature algorithm. U sends mU,σU to V in domain B.After receiving the messagemU,σU, according to the plaintext information in mU, V will send mU to BASB through a secure channel to request the system parameters of domain A and the public key information of U and make a request for verifying the anonymous identity of U. If PIDU is valid, BASB returns the verification result, the system parameters of the domain A and the public key of U to V through a secure channel. This process is similar to the communication between U and BASA. After receiving the response from BASB, V uses U′s public key to verify the signature σU according to the signature verification algorithm. If the signature σU is valid, V accepts the message mU,σU. Then, V randomly selects the nonrepeated random number NV and rV′ and calculates the ephemeral public key PkV′=rV′P. V generates the message mV=NVIDdomainBPIDV‖PkV′ and uses the private key SkV to generate the signature σV of message mV by the signature algorithm. Then, V sends mV,σV to U and calculates the session key SkUV=rV′PkU′=rV′rU′P.After receiving the messagemV,σV, U verifies the authenticity of V′s anonymous identity. If the verification passes, U uses V′s public key to verify the signature σV according to the signature verification algorithm. If the signature σV is valid, U accepts the message mV,σV. Then, U calculates the session key SkUV=rU′PkV′=rU′rV′P.


## 5.2.1. Registration Stage

Devices in each domain perform this phase via a secure channel when they are deployed. Then, the user and KGC perform the key generation process of our short signature scheme (see Figure4) and generate the anonymous identity and public/private key pair for each user. During this process, with the cooperation of KGC, BAS updates the user’s anonymous identity and public key on the consortium blockchain.Figure 4
The registration process of our CL-BASA.Taking userU as an example, first, U randomly generates the public key RU. Then, Usends U,RU to KGCA through a secure channel to request registration. KGCA generates PU randomly after receiving U,RU, generates U′s anonymous identity PIDU and partial private key DU, and saves RU as the public key PkU of U. KGCA sends an update request to BASA and receives an update response. After BASA updates the information of user U in the blockchain, KGCA sends PIDU,DU to user U through a secure channel. After receiving PIDU,DU, U saves PIDU as its anonymous identity and generates the complete private key SkU.Anonymous identity management mechanism: taking userU as an example. In our proposed scheme, the anonymous identity of user U is maintained and controlled by KGCA. During user registration, KGCA sets a time window for each user’s anonymous identity. The expire-time of the user’s anonymous identity is the current time plus the corresponding time window. When the anonymous identity expires, KGCA sends a reregistration request to U (step 0 in Figure 3). After receiving the reregistration request sent by KGCA, U executes the registration phase again (steps 1–4 in Figure 3). KGCA selects the random PU after receiving the registration request of U and calculates the new anonymous identity and some partial private key for user U. Then, after cooperating with BASA to update the information of U in the blockchain, KGCA sends the anonymous identity and the partial private key of U to user U, and KGCA sets an expiration time for the new anonymous identity of U. PU reserved here is to facilitate the maintenance and management of U′s anonymous identity by KGCA, which can be regarded as the coding of the expire time of user U′s anonymous identity on the elliptic curve E.


## 5.2.2. Authentication and Key Agreement Stage

In this section, we introduce the authentication and key agreement process of our scheme in detail. We assume that the user’s anonymous identity is valid. Otherwise, the user re-executes the registration phase. When userU in domain A needs to communicate with user V in domain B, user U first interacts with BASA to obtain the domain-specific information of domain B and the public information of user V, that is, steps 5 and 6 in Figure 3.In our authentication mechanism, the certificateless signature of Section4 is used. When requesting authentication, an entity needs to provide the following information: the information of the signature private key corresponding to the claimed public key; the authenticity of identity and public key. The former can be reflected by using the claimed public key to verify the validity of the signature, while the latter is realized through the domain-specific information of each domain shared in the consortium blockchain.Assuming the initiator of authentication is the userU, the mutual authentication of U and V needs to be completed before cross-domain communication. The mutual authentication process is shown in Figure 5. The format of Token is as follows:(4)TokenUV=NUIDdomainAPIDUTextU‖SignSkUNUIDdomainAPIDUTextU,TokenVU=NVIDdomainBPIDVTextV‖SignSkVNVIDdomainBPIDVTextV,where NU is the nonrepeated random number randomly selected by U; SignSkUX is the signature of message X by U through the signature private key; TextU is an extended field.Figure 5
Mutual authentication model.Next, we show the authentication and key agreement process. During the authentication process, we utilize the Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key exchange mechanism to negotiate the session key, and the ECDHE key exchange mechanism is shown in Figure6. See Figure 7 for the detailed authentication and key agreement process.Figure 6
ECDHE key exchange mechanism.Figure 7
The authentication and key agreement process of our CL-BASA scheme.We assume that the authentication process is initiated byU in domain A. If the anonymous identity of U expires, U will re-execute the registration phase. Otherwise, U will send a request PIDU,reqinfA to BASA through a secure channel to obtain the system parameters of domain B and the anonymous identity and public key information of V. Here, IDdomainB represents the unique identifier of domain B, descripV indicates the function of the device V in domain B, and TSA represents the timestamp of domain A. After receiving the information request, BASA will verify the validation of TSA and PIDU. If they are valid, BASA will search the public information of domain B in the consortium chain and send IDBASA,respinfA to U through a secure channel. respinfA contains the system parameters of domain B, the anonymous identity and public key information of V. Then, after receiving the information response, U randomly selects the nonrepeated random number NU and rU′ and then calculates PkU′=rU′P as the ephemeral public key. U generates the message mU=NUIDdomainAPIDUPkU′ and uses the private key SkU to generate the signature σU of message mU by the signature algorithm. U sends mU,σU to V in domain B.After receiving the messagemU,σU, according to the plaintext information in mU, V will send mU to BASB through a secure channel to request the system parameters of domain A and the public key information of U and make a request for verifying the anonymous identity of U. If PIDU is valid, BASB returns the verification result, the system parameters of the domain A and the public key of U to V through a secure channel. This process is similar to the communication between U and BASA. After receiving the response from BASB, V uses U′s public key to verify the signature σU according to the signature verification algorithm. If the signature σU is valid, V accepts the message mU,σU. Then, V randomly selects the nonrepeated random number NV and rV′ and calculates the ephemeral public key PkV′=rV′P. V generates the message mV=NVIDdomainBPIDV‖PkV′ and uses the private key SkV to generate the signature σV of message mV by the signature algorithm. Then, V sends mV,σV to U and calculates the session key SkUV=rV′PkU′=rV′rU′P.After receiving the messagemV,σV, U verifies the authenticity of V′s anonymous identity. If the verification passes, U uses V′s public key to verify the signature σV according to the signature verification algorithm. If the signature σV is valid, U accepts the message mV,σV. Then, U calculates the session key SkUV=rU′PkV′=rU′rV′P.


## 6. Security Analysis

We use certificateless signature to realize the mutual authentication of entities. We prove that our certificateless public-key signature scheme satisfies EUF-CMA. Appendix A can be seen for the detailed security proof. In addition, the tamper-proof feature of blockchain provides an effective way to ensure the authenticity of anonymous identities and public keys. As for the establishment of the session key, we use the ECDHE key agreement mechanism, which satisfies PFS. The combination of the certificateless signature and ECDHE can resist man-in-the-middle attacks. The privacy security of the entity identity depends on the hash function, which generates the anonymous identity.


## 7. Security Verification

In order to further illustrate the security of our CL-BASA, we make security verification by the formal analysis tool, Tamarin [29]. Tamarin is a powerful tool for symbolic modeling and analysis of security protocols. It supports a variety of algebraic properties, including encryption and decryption operations, operation combination laws, Diffie-Hellman power operations, and bilinear operations, and has built-in support for equational theories such as the one modeling Diffie-Hellman Key exchanges. For more information, please refer to references [29, 30]. The formal analysis results of our scheme can be seen in Figure 8.Figure 8
The formal analysis results of our CL-BASA.In the authentication and key agreement phase, we take confidentiality, weak agreement, perfect forward security, noninjective agreement, and injective agreement as the security goals for the formal verification. These security attributes have been verified. However, it should also be noted that we simplify our certificateless signatureσ=h2DU+rUh3 to σ=rU⋅h3 in our formal verification. The reason why we make this modification is that Tamarin tool cannot effectively handle the addition operation, which is also clearly pointed out in [31]. In addition, it depends on Tamarin’s improvement for more accurate modeling.


## 8. Performance Evaluation

We theoretically compare our CL-BASA scheme withBASA [9], A2Chain [22], ES3A [32], CPAL [33], and LCCH [34]in terms of communication overhead, computational overhead, and storage overhead. For comparison purposes, we use the same cryptographic parameter settings, namely, the prime256v1 elliptic curve.


### 8.1. Communication Overhead

We evaluate the communication overhead of these schemes by accumulating all key payloads during the authentication process between the IoT device and the server. The size of entityID, signature, timestamp, random number, and cryptographic key is denoted as SID, SSig, STS, SN, and SKey. The values of SID, STS, and SN are 32, 4, and 4 bytes, respectively. While, the values of SSig and SKey should be determined according to the specific scheme.In our evaluation, since the same elliptic curve is considered, the domain public parameterparam is not considered in the message payload. In addition, we assume that the field descrip occupies 8 bytes. In our scheme, U sends a 76-byte information request to BASA to obtain the anonymous identity and public key of V. BASA returns a 140-byte information response. U sends a 160-byte authentication request to V. After receiving this request, V sends a 140-byte information request to BASB for verifying the anonymous identity of U and obtaining the public key of U. BASB returns a 140 bytes information response. Then, after verifying the signature of U, V sends a 160 bytes authentication response to U. The communication bandwidth cost for authentication and key agreement achieves 816 bytes. Therefore, compared with BASA [9], A2chain [22], ES3A [32], CPAL [33], and LCCH [34] whose communication cost is 1344 bytes, 1232 bytes, 1336 bytes, 1232 bytes, and 2016 bytes, respectively, the communication overhead of our scheme is much smaller. Here, we need to point out that the 1232 bytes of A2chain [22] is the communication overhead to realize the mutual authentication.


### 8.2. Computational Overhead

In order to evaluate the computational overhead, we count cryptographic operations, including point multiplication in a group, point addition in the point group of the elliptic curve, scalar multiplication, exponential operation, bilinear pairing operation, and AES encryption/decryption operations, which are denoted by PM, PA, SM, EXP, BP, and AES, respectively. In our comparison, we no longer distinguish in detail the groups of those operations but make a simple comparison from the perspective of the number of corresponding operations. As for other operations, such as hash operation, integer addition, and multiplication, they cost little time, so they are not considered here. The result is shown in Table2.Table 2
Comparison of the computational overhead.
AU + KNBASA [9]18SM + 4PA + 8Exp + 4BPA2chain [22]8SM + 2PA + 4EXP + 4BPES3A [32]36SM + 4AES + 5Exp + 15BPCPAL [33]27PM + 46EXP + 14BPLCCH [34]41PM + 71EXP + 22BPOur CL-BASA14SM + 2PA + 6BPWhen the elliptic curve parameters are determined, in [35], the authors show the cost of the basic operations in relation to that of elliptic curve scalar multiplication. If SM is used as the benchmark, the cost of BP is about 150 times that of SM and the cost of EXP is about 36 times that of SM. In addition, we assume that the cost of PA is less than that of SM, and the cost of PM is also less than that of SM.As can be seen from Table2, since our CL-BASA scheme requires slightly more bilinear pairing operations than BASA [9] and A2Chain [22], it may be inferior to the BASA [9] in computational overhead. However, compared with ES3A [32], CPAL [33], and LCCH [34], it still has great advantages. Compared with A2chain [22], it is worth noting that the cryptographic operations in Table 2 are that the cost of one-way authentication. If A2chain [22] realizes the mutual authentication of the IoT devices in the way, our scheme has obvious advantages in terms of the computational overhead. In addition, the reason why BASA [9] has lower computational overhead is that the bilinear pairing eP1,Ppub−s (in their Algorithm 1 and Algorithm 2) is precomputed when the system is initialized and transmitted to IIoT devices, namely, the bilinear pairing eP1,Ppub−s is only computed and stored as a constant value in IIoT devices. A2chain [22] has a similar situation.


### 8.3. Storage Overhead

In terms of storage overhead, we only count in the most necessary data that should be stored in local device for authentication, such as identity, anonymous identity, public key, private key, and other information that needs to be stored in addition to system public parameters. In our scheme, we have the size of identitySID=32 bytes, anonymous identity SPID=32 bytes, public key SCLPk=32 bytes, and private key SCLSk=64 bytes. The total storage overhead of our scheme, BASA [9], A2chain [22], ES3A [32], CPAL [33], and LCCH [34] are shown in Table 3.Table 3
Comparison of the storage overhead.
SchemeTotal costTotal rough cost (bytes)BASA [9]SID+SPID+2SSk+Sc160A2chain [22]SID+SSk+Sc+SSig192ES3A [32]SID+SPk+SSk+SCert653CPAL [33]SID+SPk+SSk96LCCH [34]SID+SPID+SPk+SSk128Our CL-BASASID+SPID+SPk+SCLSk160As shown in Table3, compared with CPAL [33] and LCCH [34], our CL-BASA has slightly higher storage overhead; our scheme has the same storage overhead as BASA [9] and has an obvious advantage over A2chain [22] and ES3A [32] in terms of storage overhead. Sc represents the storage overhead of the bilinear pairing eP1,Ppub−s stored in IIoT devices, and it occupies 32 bytes. SSig is the storage overhead of the signature stored in IoT devices, which occupies 96 bytes. SCert is the cost of storing certificate, which occupies 557 bytes [17].


## 8.1. Communication Overhead

We evaluate the communication overhead of these schemes by accumulating all key payloads during the authentication process between the IoT device and the server. The size of entityID, signature, timestamp, random number, and cryptographic key is denoted as SID, SSig, STS, SN, and SKey. The values of SID, STS, and SN are 32, 4, and 4 bytes, respectively. While, the values of SSig and SKey should be determined according to the specific scheme.In our evaluation, since the same elliptic curve is considered, the domain public parameterparam is not considered in the message payload. In addition, we assume that the field descrip occupies 8 bytes. In our scheme, U sends a 76-byte information request to BASA to obtain the anonymous identity and public key of V. BASA returns a 140-byte information response. U sends a 160-byte authentication request to V. After receiving this request, V sends a 140-byte information request to BASB for verifying the anonymous identity of U and obtaining the public key of U. BASB returns a 140 bytes information response. Then, after verifying the signature of U, V sends a 160 bytes authentication response to U. The communication bandwidth cost for authentication and key agreement achieves 816 bytes. Therefore, compared with BASA [9], A2chain [22], ES3A [32], CPAL [33], and LCCH [34] whose communication cost is 1344 bytes, 1232 bytes, 1336 bytes, 1232 bytes, and 2016 bytes, respectively, the communication overhead of our scheme is much smaller. Here, we need to point out that the 1232 bytes of A2chain [22] is the communication overhead to realize the mutual authentication.


## 8.2. Computational Overhead

In order to evaluate the computational overhead, we count cryptographic operations, including point multiplication in a group, point addition in the point group of the elliptic curve, scalar multiplication, exponential operation, bilinear pairing operation, and AES encryption/decryption operations, which are denoted by PM, PA, SM, EXP, BP, and AES, respectively. In our comparison, we no longer distinguish in detail the groups of those operations but make a simple comparison from the perspective of the number of corresponding operations. As for other operations, such as hash operation, integer addition, and multiplication, they cost little time, so they are not considered here. The result is shown in Table2.Table 2
Comparison of the computational overhead.
AU + KNBASA [9]18SM + 4PA + 8Exp + 4BPA2chain [22]8SM + 2PA + 4EXP + 4BPES3A [32]36SM + 4AES + 5Exp + 15BPCPAL [33]27PM + 46EXP + 14BPLCCH [34]41PM + 71EXP + 22BPOur CL-BASA14SM + 2PA + 6BPWhen the elliptic curve parameters are determined, in [35], the authors show the cost of the basic operations in relation to that of elliptic curve scalar multiplication. If SM is used as the benchmark, the cost of BP is about 150 times that of SM and the cost of EXP is about 36 times that of SM. In addition, we assume that the cost of PA is less than that of SM, and the cost of PM is also less than that of SM.As can be seen from Table2, since our CL-BASA scheme requires slightly more bilinear pairing operations than BASA [9] and A2Chain [22], it may be inferior to the BASA [9] in computational overhead. However, compared with ES3A [32], CPAL [33], and LCCH [34], it still has great advantages. Compared with A2chain [22], it is worth noting that the cryptographic operations in Table 2 are that the cost of one-way authentication. If A2chain [22] realizes the mutual authentication of the IoT devices in the way, our scheme has obvious advantages in terms of the computational overhead. In addition, the reason why BASA [9] has lower computational overhead is that the bilinear pairing eP1,Ppub−s (in their Algorithm 1 and Algorithm 2) is precomputed when the system is initialized and transmitted to IIoT devices, namely, the bilinear pairing eP1,Ppub−s is only computed and stored as a constant value in IIoT devices. A2chain [22] has a similar situation.


## 8.3. Storage Overhead

In terms of storage overhead, we only count in the most necessary data that should be stored in local device for authentication, such as identity, anonymous identity, public key, private key, and other information that needs to be stored in addition to system public parameters. In our scheme, we have the size of identitySID=32 bytes, anonymous identity SPID=32 bytes, public key SCLPk=32 bytes, and private key SCLSk=64 bytes. The total storage overhead of our scheme, BASA [9], A2chain [22], ES3A [32], CPAL [33], and LCCH [34] are shown in Table 3.Table 3
Comparison of the storage overhead.
SchemeTotal costTotal rough cost (bytes)BASA [9]SID+SPID+2SSk+Sc160A2chain [22]SID+SSk+Sc+SSig192ES3A [32]SID+SPk+SSk+SCert653CPAL [33]SID+SPk+SSk96LCCH [34]SID+SPID+SPk+SSk128Our CL-BASASID+SPID+SPk+SCLSk160As shown in Table3, compared with CPAL [33] and LCCH [34], our CL-BASA has slightly higher storage overhead; our scheme has the same storage overhead as BASA [9] and has an obvious advantage over A2chain [22] and ES3A [32] in terms of storage overhead. Sc represents the storage overhead of the bilinear pairing eP1,Ppub−s stored in IIoT devices, and it occupies 32 bytes. SSig is the storage overhead of the signature stored in IoT devices, which occupies 96 bytes. SCert is the cost of storing certificate, which occupies 557 bytes [17].


## 9. Conclusion

Considering the resource constraints of IoT devices, the research of cross-domain authentication and key agreement scheme in the IoT scenario has always been a subject of great concern. Based onBASA [9], in this article, we first design a secure and efficient certificateless short signature scheme with anonymity. Then, we propose a new secure authentication and key agreement mechanism CL-BASA for IIoT cross-domain, by combining our certificateless short signature and the ECDHE key exchange mechanism. Specifically, we avoid the inherent problem of key escrow in IBS by utilizing certificateless short signatures. In addition, with the aid of blockchain, we use the consortium jointly maintained by BASA in each domain to ensure the authenticity of entity anonymous identity and public key. Finally, we combine our certificateless short signature and the ECDHE key exchange mechanism to negotiate the session key. The evaluation demonstrates that our CL-BASA may have a slight disadvantage in storage overhead, but it has obvious advantages than competitor schemes in terms of communication overhead and computational overhead.



---

*Source: 3693748-2022-10-17.xml*