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.
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 on [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 the , 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 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 in , 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: Section 2 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 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 , 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 Table 1.
Let be a prime number greater than 3; a nonsingular elliptic curve defined on the finite field is composed of points satisfying the equation and a point representing infinity denoted by , where and . Let be the set of all points on the elliptic curve, namely,
3.1. Bilinear Pairing
Let be an additive cyclic group generated by , whose order is prime , and is a multiplicative cyclic group with the same order. Bilinear pairing satisfies the following properties:(1)Bilinearity: for any , we have and . Especially, given any , we have(2)Nondegeneracy: there exists , such that .(3)Computability: given any , there exists a polynomial-time algorithm to compute
3.2. Complexity Assumptions
is an additive cyclic group generated by , and its order is . The difficult assumption of the ECCDH states that, for randomly chosen , given , it is not feasible to compute 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 key and the system parameter . Partial-Private-Key-Extract: KGC takes the system parameters , , and user ID as inputs. Then, KGC generates the partial private key and sends it to the user through a secure channel. Set-Secret-Value: the user randomly chooses a secret value . Set-Secret-Key: the user takes the partial private key and its secret value as inputs and then returns its complete private key . Set-Public- Key: the user takes and its complete private key as inputs and returns its public key . Sign: the signer/user takes , message , and its complete private key as inputs. Then, it generates a signature of the message . Verify: the verifier takes , public key , message , 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 runs the algorithm, CL.Setup, to generate the master key and the public parameters . Then, it sends the to the super type I adversary and keeps master key secret. After that, makes polynomial times queries for the following oracles to . CreateUser: for some query on an identity , if this has already been created, returns to . Otherwise, calls the algorithms Cl.Partial-Private-Key-Extract, CL.Set-User-Value, Set-User-Key, and Set-Public-Key, respectively, to obtain and returns to . Partial-Private-Key-Extract: when receiving this query on , returns the partial key to . Public-Key-Replace: when receiving this query on , uses to replace the original public key . Secret-Value-Extract: when receiving this query on , returns to . If Public-Key-Replace query has been issued without providing a corresponding , we require that it is not permitted to query Secret-Value-Extract with . Super-Sign: when receiving this query on , calls the algorithm, CL.Sign, and returns a signature that satisfies CL.Verify (, , , ) = true to . Note that is the latest public key.
After making all the queries, submits a forged signature on the message as the target identity . is said to succeed in Game I if the following conditions are satisfied:(1)CL.Verify (, , , ) = true(2) did not make Super-Sign query with (3) did not make Partial-Private-Key-Extract query with
4.2.2. Game II
This game is executed between a super type II adversary and a challenger . This game proceeds as follows: a challenger runs the algorithm CL.Setup to generate the master key and the public parameters . Then, it sends to the super type II adversary and keeps master key secret. After that, issues CreateUser, Partial-Private-Key-Extract, Public-Key-Replace, Secret-Value-Extract, and Super-Sign oracles as described in the Game I, and makes the corresponding responses in the same way as in the Game I.
After making all the queries, submits a forged signature on the message as the target identity . is said to succeed in Game II if the following conditions are satisfied:(1)CL.Verify(, , , ) = true(2) did not make Super-Sign query with (3) did not make Partial-Private-Key-Extract query with (4) did not make Public-Key-Replace query with
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.Setup :(1)Select an elliptic curve , which is defined in a prime field . Generate , where is an additive group of order , whose generator is ; is a multiplicative group of order ; bilinear pair .(2)Randomly choose a number as the master key. Then, compute the master public key .(3)Select three collision resistance hash functions , .(4)Output the system parameter .
CL.Set-User-Value (, ):(1)Randomly choose and compute (2)Output
CL.Extract-Partial-Key(, , , ):(1)Randomly select and compute , , .(2)Let and output .
CL.Set-User-Key (, , , ):(1)Save as anonymous identity, and let
CL.Set-Public-Key (, , , ):(1)Let
CL.Sign (, , ):(1)Compute , (2)Generate signature
CL.Verify (, , ):(1)Compute , (2)Verify , if it holds, the signature is accepted
Correctness: if the anonymous identity is , public key and signature are generated according to the above signature scheme. The following equation ensures the correctness of the signature scheme, that is,
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 Figure 1, 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:
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; and 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.
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 Section 4 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. and represent two cross-domain IIoT entities; represents the key generation centers of domain A ( in domain B, respectively); represents blockchain agent servers (such as edge servers) in domain A ( in domain B, respectively).
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 Figure 4) 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.
Taking user as an example, first, randomly generates the public key . Then, sends to through a secure channel to request registration. generates randomly after receiving , generates anonymous identity and partial private key , and saves as the public key of . sends an update request to and receives an update response. After updates the information of user in the blockchain, sends to user through a secure channel. After receiving , saves as its anonymous identity and generates the complete private key .
Anonymous identity management mechanism: taking user as an example. In our proposed scheme, the anonymous identity of user is maintained and controlled by . During user registration, 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, sends a reregistration request to (step 0 in Figure 3). After receiving the reregistration request sent by , executes the registration phase again (steps 1–4 in Figure 3). selects the random after receiving the registration request of and calculates the new anonymous identity and some partial private key for user . Then, after cooperating with to update the information of in the blockchain, sends the anonymous identity and the partial private key of to user , and sets an expiration time for the new anonymous identity of . reserved here is to facilitate the maintenance and management of anonymous identity by , which can be regarded as the coding of the expire time of user anonymous identity on the elliptic curve .
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 user in domain A needs to communicate with user in domain B, user first interacts with to obtain the domain-specific information of domain B and the public information of user , that is, steps 5 and 6 in Figure 3.
In our authentication mechanism, the certificateless signature of Section 4 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 user , the mutual authentication of and needs to be completed before cross-domain communication. The mutual authentication process is shown in Figure 5. The format of is as follows:where is the nonrepeated random number randomly selected by ; is the signature of message by through the signature private key; is an extended field.
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 Figure 6. See Figure 7 for the detailed authentication and key agreement process.
We assume that the authentication process is initiated by in domain A. If the anonymous identity of expires, will re-execute the registration phase. Otherwise, will send a request to through a secure channel to obtain the system parameters of domain B and the anonymous identity and public key information of . Here, represents the unique identifier of domain B, indicates the function of the device in domain B, and represents the timestamp of domain A. After receiving the information request, will verify the validation of and . If they are valid, will search the public information of domain B in the consortium chain and send to through a secure channel. contains the system parameters of domain B, the anonymous identity and public key information of . Then, after receiving the information response, randomly selects the nonrepeated random number and and then calculates as the ephemeral public key. generates the message and uses the private key to generate the signature of message by the signature algorithm. sends to in domain B.
After receiving the message , according to the plaintext information in , will send to through a secure channel to request the system parameters of domain A and the public key information of and make a request for verifying the anonymous identity of . If is valid, returns the verification result, the system parameters of the domain A and the public key of to through a secure channel. This process is similar to the communication between and . After receiving the response from , uses public key to verify the signature according to the signature verification algorithm. If the signature is valid, accepts the message . Then, randomly selects the nonrepeated random number and and calculates the ephemeral public key . generates the message and uses the private key to generate the signature of message by the signature algorithm. Then, sends to and calculates the session key .
After receiving the message , verifies the authenticity of anonymous identity. If the verification passes, uses public key to verify the signature according to the signature verification algorithm. If the signature is valid, accepts the message . Then, calculates the session key .
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.
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 to 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 with [9], [22], [32], [33], and [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 entity , signature, timestamp, random number, and cryptographic key is denoted as , , , , and . The values of , , and are 32, 4, and 4 bytes, respectively. While, the values of and should be determined according to the specific scheme.
In our evaluation, since the same elliptic curve is considered, the domain public parameter is not considered in the message payload. In addition, we assume that the field occupies 8 bytes. In our scheme, sends a 76-byte information request to to obtain the anonymous identity and public key of . returns a 140-byte information response. sends a 160-byte authentication request to . After receiving this request, sends a 140-byte information request to for verifying the anonymous identity of and obtaining the public key of . returns a 140 bytes information response. Then, after verifying the signature of , sends a 160 bytes authentication response to . The communication bandwidth cost for authentication and key agreement achieves 816 bytes. Therefore, compared with [9], [22], [32], [33], and [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 [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 Table 2.
When 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 is used as the benchmark, the cost of is about 150 times that of and the cost of is about 36 times that of . In addition, we assume that the cost of is less than that of , and the cost of is also less than that of .
As can be seen from Table 2, since our CL-BASA scheme requires slightly more bilinear pairing operations than [9] and [22], it may be inferior to the [9] in computational overhead. However, compared with [32], [33], and [34], it still has great advantages. Compared with [22], it is worth noting that the cryptographic operations in Table 2 are that the cost of one-way authentication. If [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 [9] has lower computational overhead is that the bilinear pairing (in their Algorithm 1 and Algorithm 2) is precomputed when the system is initialized and transmitted to IIoT devices, namely, the bilinear pairing is only computed and stored as a constant value in IIoT devices. [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 identity bytes, anonymous identity bytes, public key bytes, and private key bytes. The total storage overhead of our scheme, [9], [22], [32], [33], and [34] are shown in Table 3.
As shown in Table 3, compared with [33] and [34], our CL-BASA has slightly higher storage overhead; our scheme has the same storage overhead as [9] and has an obvious advantage over [22] and [32] in terms of storage overhead. represents the storage overhead of the bilinear pairing stored in IIoT devices, and it occupies 32 bytes. is the storage overhead of the signature stored in IoT devices, which occupies 96 bytes. 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 on [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.
Appendix
A Security Proof of Our CL-PKS Scheme
Next, we prove that our certificateless signature (CL-PKS) scheme proposed in Section 4 satisfies the existential unforgeability security according to the security model proposed in Section 4.2. Specifically, we show that our scheme can resist super type I adversary and super type II adversary through Lemma a1 and Lemma a2. Theorem a1 shows that our CL-PKS scheme satisfies the existential unforgeability security.
Lemma A1. In the random oracle model, if there is a super type I adversary , which successfully breaks our CL-PKS scheme in polynomial-time with negligible probability . Then, there is a polynomial-time challenger successfully solving CDH problem, and the advantage of successfully solving CDH problem is as follows:where , , , , and denote the number of adversary querying to oracles , , , Create-User, and Partial-Private-Key-Extract, respectively.
Proof of Lemma A1. Let be a super type I adversary who can break our CL-PKS scheme, and its probability of success is . acts as the simulator (challenger); we construct by the forgery of to solve the CDH problem. Note is a random example of CDH problem as the input of . Next, we show how can be used by to solve the CDH problem. maintains a list for user . The anticollision hash functions are simulated as the random oracles , , and . At the same time, maintains the lists , , and to record the adversary queries to oracles , , and . All lists are initialized to be empty. The game between and is as follows:
Setup: randomly chooses a target identity , where . Then, sends system parameter to .
Oracles: queries the following oracles with polynomial time and receives the corresponding response from .
Create-User: when makes a query to this oracle on , first checks list . If there is an entry for this query, returns to . Otherwise, creates a new entry and adds it into the list as the following. If , randomly chooses , , , and computes , , , , and . Then, adds the entry into the list and returns . If , randomly chooses , and computes , , , , and . Then, adds the entry into the list and returns .
Oracle : when makes a query to this oracle on , we use the proof technique of Coron [28] to answer this query, namely, if the is not created, returns to . Otherwise, flips a coin , , . If , checks . If there is an entry corresponding to , returns the corresponding value to . Otherwise, looks up , adds to and returns to . If and , executes the same operations as the case of . If and , let , where , adds into and returns to to . If there is an entry in the and , returns to and aborts the game.
Partial-Private-Key-Extract: when queries this oracle , if the is not created, returns to . Otherwise, if , queries and returns to ; if , returns to and aborts the game.
Public-Key-Replace: when queries this oracle , if the is not created, returns to . Otherwise, uses to replace the original public key and updates the entry , where may be .
Secret-Value-Extract: when queries this oracle on , if the is not created, returns to . Otherwise, queries and returns to . If has issued Public-Key-Replace query without providing a corresponding , we require that is not permitted to query Secret-Value-Extract with .
Oracle : when queries this oracle , if the is not created, returns to . Otherwise, looks up list . If there is a corresponding entry, returns the previously defined value to . If there is no corresponding entry, randomly selects and then returns to and adds into the list .
Oracle : when queries this oracle , if the is not created, returns to . Otherwise, looks up list . If there is a corresponding entry, returns the previously defined value to . If there is no corresponding entry, randomly selects and then returns to and adds into the list .
Super-Sign: when queries this oracle , if the is not created, returns to . Otherwise, looks up list , , , and and performs the following operations:(1)If , returns the signature to (2)If and , returns the signature to (3)If and , returns to and aborts the gameForgery: through the above queries, outputs a signature forgery . Assuming is a valid signature, then wins the game. If , returns to and aborts the game. Otherwise, performs the following:(1) checks list ; if , returns and aborts the game.(2)If , solves the CDH problem by relying on the forgery of . Due to is a valid signature, the following formula holds:So, we can get . Finally, solves the CDH problem by relying on forger , that is, .
Next, for a random example . We analyze the probability of the challenger outputting the correct solution of CDH problem. The conditions for challenger success are as follows:(1): does not abort the game(2): is a valid signature on The advantage of isAssuming that the super type I adversary successfully breaks our CL-PKS scheme with probability , we can get . Next, we analyze the probability of event occurring. When the following events occur at the same time, challenger will not abort the game.(1)In the Create-User query, there is no collision during the query of . The probability of this event occurrence is at least .(2)The adversary does not query to Partial-Private-Key-Extract with . The probability of this event occurrence is .(3)In the Super-Sign query, the event does not happen. The probability is .(4)In the Forgery query, does not happen. The probability is .(5)Both and are found in and . Due to the randomness of the random oracle, if is a valid forgery, then the probability of existing and is at least .So, we can get the following:Through the above analysis, we have the following:Therefore, if there is a polynomial-time super Type I adversary that breaks our CL-PKS scheme, we can find an attacker successfully solving the CDH problem.
Lemma A2. In the random oracle model, if there is a super type II adversary , which successfully breaks our CL-PKS scheme in polynomial-time with negligible probability . Then, there is a polynomial-time challenger successfully solving the CDH problem, and the advantage of successfully solving CDH problem is as follows:where , , , , and denote the numbers of adversary querying to oracle , , , Create-User, Public-Key-Replace, and Secret-Value-Extract, respectively.
Proof of Lemma A2. Let be a super type II adversary breaking our CL-PKS scheme, and its probability of success is . acts as the simulator (challenger) we construct by the forgery of to solve the CDH problem. Note is a random example of CDH problem as the input of . Next, we show how can be used by to solve the CDH problem. maintains a list for user . The anticollision hash functions are simulated as the random oracles , , and . At the same time, maintains the lists , , and to record the adversary queries to oracles , , and . All lists are initialized to be empty. The game between and is as follows:
Setup: randomly chooses randomly chooses as the master secret key and calculates the master public key . Then, randomly chooses a target identity , where . Then, sends system parameter to .
Oracles: queries the following oracles with polynomial time and receives the corresponding response from .
Create-User: when makes a query to this oracle with , we use the proof technique of Coron [28] to answer this query. flips a coin , , . first checks list . If there is an entry corresponding to this query, returns to . Otherwise, creates a new entry and adds it into the list as the following: if , randomly chooses , , and computes , , , , where . Let . Then, adds the entry into the list and returns to . If and , performs the same operations just as the case of and returns to . If and , randomly chooses , , and computes , , , , where . Let . adds the entry into the list and returns to .
Oracle : when makes a query to this oracle with , if the is not created, returns to . Otherwise, checks . If there is an entry corresponding to , returns the corresponding value to . Otherwise, looks up and adds to and returns to .
Partial-Private-Key-Extract: when queries this oracle , if the is not created, returns to . Otherwise, looks up and returns to .
Public-Key-Replace: when queries this oracle , if the is not created, returns to . Otherwise, if , returns to and aborts the game. If , uses to replace the original and updates the entry , where the may be .
Secret-Value-Extract: when queries the oracle , if the is not created, returns to . Otherwise, if , queries and returns to . If , returns to and aborts the game.
Oracle : when queries this oracle , if the is not created, returns to . Otherwise, looks up list . If there is a corresponding entry, returns the previously defined value to . If there is no corresponding entry, randomly selects and then returns to and adds into the list .
Oracle : when queries this oracle , if the is not created, returns to . Otherwise, looks up list . If there is a corresponding entry, returns the previously defined value to . If there is no corresponding entry, randomly selects and then returns to and adds into the list .
Super-Sign: when queries this oracle , if the is not created, returns to . Otherwise, looks up list , , , and and performs the following operations:(1)If , returns the signature to (2)If and , returns the signature to (3)If and , returns to and aborts the gameForgery: through the above queries, outputs a signature forgery . Assuming is a valid signature, wins the game. If , returns to and aborts the game. Otherwise, performs the following:(1) checks list , if , returns and aborts the game.(2)If , solves the CDH problem by relying on the forgery of . Due to is a valid signature, the following formula holds:So, we can get . Finally, solves the CDH problem by relying on forger , that is, .
Next, for a random example . We analyze the probability of the challenger outputting the correct solution of CDH problem. The conditions for challenger success are as follows:(1): does not abort the game(2): is a valid signature on The advantage of is as follows:Assuming that the super type II adversary successfully breaks our CL-PKS scheme with probability , we can get . Next, we analyze the probability of event occurring. When the following events occur at the same time, challenger will not abort the game.(1)In the Create-User query, there is no collision during the query of . The probability of this event occurrence is at least .(2)The adversary does not query to Public-Key-Replace with . The probability of this event occurrence is .(3)The adversary does not query to Secret-Value-Extract with . The probability of this event occurrence is .(4)In the Super-Sign query, the event does not happen. The probability is .(5)In the Forgery query, does not happen. The probability is .(6)Both and are found in , . Due to the randomness of the random oracle, if is a valid forgery, then the probability of existing and is at least .So, we can get the following:Through the above analysis, we have the following:Therefore, if there is a polynomial-time super type II adversary that that breaks our CL-PKS scheme, we can find an attacker successfully solving the CDH problem.
From Definition 1, Lemma a1, and Lemma a2, we know that our certificateless short signature CL-PKS scheme satisfies the EUF-CMA secure, that is, the following Theorem A1 holds.
Theorem A1. Assuming that the CDH difficulty assumption is true, our proposed CL-PKS scheme satisfies EUF-CMA against any polynomial-time super adversary (type I or super type II) in the random oracle model.
Data Availability
There are no data supporting the results of this study.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
The authors thank the students and teachers around them for their concerns. They provided a great help for the work of this article.