# An Efficient Scheme for Industrial Internet of Things Using Certificateless Signature

Authors: Ali Muhammad; Noor Ul Amin; Insaf Ullah; Ahmed Alsanad; Saddam Hussain; Suheer Al-Hadhrami; M. Irfan Uddin; Hizbullah Khattak; Muhammad Asghar Khan
Journal: Mathematical Problems in Engineering
 (2021)

---

## Abstract

Currently, hyperelliptic curve cryptography (HECC) got attractions towards low power devices such as Industrial Internet of Things (IIoT). As we all know, it has the capability of utilizing low key size, which can be suitable for IIoT environment. Inspired by the aforementioned property of HECC, we proposed an efficient scheme for IIoT using certificateless signature with the help of HECC. The presented approach is proven to be unforgeable against the challenges of type I and type II attackers. We tested the security of the designed approach through Automated Validation of Internet Security Protocols and Applications (AVISPA). We also performed the computational and communicational cost comparisons with already existed schemes, and it is observed from our analysis that our scheme is computationally efficient and needs low communication cost.


---

## Body

## 1. Introduction

Internet of Things (IoT) is a network of physical interconnected devices, which incorporate embedded technologies such as RFID, sensors, and other smart devices [1, 2], networked together for communicating with the external environments via the Internet [3, 4]. On the other hand, IoT is growing its scope through linking cities to mature smart systems. These smart systems are designed to combine our routine items with smart devices to create a fully automated intelligent system (AIS) that has the potential to reduce human effort. According to a recent Ericsson report, about 18 billion smart IoT devices will be connected to the Internet by 2022 [5]. This new innovative trend has paved the way for integrating these innovative technologies into various fields such as healthcare, data mining, transportation, and commerce [6–10]. Since its first proposal [11], IoT has attained considerable admiration among the research community in both pedagogy and industries [12].Recently, IoT has been used in the industry to enhance and modernize the industrial progression by integrating with cyberphysical systems (CPS) termed as Industrial Internet of Things (IIoT). The purpose behind the introduction of IIoT is to maximize the flow of production within the industry and to equip smart machines with sensors and wireless connectivity [13]. Though, the continuous expansion of IIoT with cloud storage that shines through remote access service, low cost, high data availability, and extended and high data storage is becoming more popular among both individuals and enterprises [12]. A general picture of IIoT with a cloud server environment is shown in Figure 1, where the enterprises can monitor the condition of deployed devices. It can collect the relevant data throughout the industrial production system and send it to the controller. However, additional information can be collected using the services of sensors. The collected data are then forwarded to the cloud server by the controller over the Internet. Cloud servers have the potential to address the serious challenges of data storage, data processing, and data classification through data-based services to improve the reliability of IIoT environment [14]. Besides the positive aspects, the cloud servers can easily be intercepted where frequent sensitive data and information can be easily disclosed and leaked.Figure 1
A general picture of IIoT connected to the cloud server.Despite the constant development and research in the IIoT technology, security risks still fail its comprehensive applications [15–19]. Consider the generic IIoT scenario in which the application sends collected data through a public channel. In such case, due to the open nature of the channel contact, an attacker can carry out multiple attacks, such as injecting, intercepting, responding, and modifying. By doing so, the attacker could damage the repute and assets of data owners and data consumers [20–24].To preserve a strategic distance from the above results, a significant number of studies have been conducted to confirm the integrity of the IIoT data for structural information [25–28]. Though, in the IIoT infrastructure [15, 21, 29], digital signature-based cryptography (DSBC) is considered to be efficient and reliable cryptography to achieve data integrity. Using DSBC, sensitive information can be easily authenticated in a nonreversible manner for the entire transmission phase period [30].A certificateless signature approach is an auspicious contender that reduces the overhead of certificate managing and solves the key escrow that comes with identity-based signing approaches. The certificateless signature cryptography is based on a third party termed as the key generation center (KGC) which has a master secret key. Additionally, KGC also offers users a partial private key (PPK) that can be computed from each user’s identity. The receiver user has a selected secret value that combines the secret value and PPK to create its own private key [31]. Next, the user associates the public parameter set with a secret value for generating their public key. Taking advantage of the above discussion, several schemes have been devised to prevent data authentication in IIoT structural information [32–37]. However, the mentioned schemes sustain high communication and computing costs.Normally, to provide efficient and strong security with minimal computational and communicational overheads, the most common techniques used are RSA, bilinear pairing (BPG), elliptic curve cryptosystem (ECC), and hyperelliptic curve cryptosystem (HECC), respectively [38–44]. Among them, the HECC gives the same security with fewer key and parameter sizes [45, 46]. Therefore, the HECC is considered as an appropriate and efficient cryptographic mechanism that offers an improved performance in contrast to RSA, BPG, and ECC. Furthermore, the HECC uses 80 bits keys with efficient and strong security that can suit the IIoT environments.


### 1.1. Motivation and Contribution

Inspired from the abovementioned discussion, a new certificateless signature scheme has been proposed for IIoT infrastructure. The proposed scheme is primarily based on HECC categorized by its smaller key length. The main contribution of this work is listed.(i)
A cost-effective certificateless signature scheme is constructed for IIoT environment using HECC(ii)
We provide a proper algorithm for the proposed scheme that avoids key escrow problems and guarantees the security assets of unforgeability, man-in-the-middle attack, and antireplay attack(iii)
We validated the designed approach using a widely accepted validation tool (AVISPA) by using the popular backend protocols, i.e., on-the-fly model checker (OFMC) and constraint logic-based Attack Searcher (AtSe)(iv)
We also give the AVISPA code and simulation results that are available in the simulation study (Appendix) in Section8(v)
In the end, a comprehensive comparative analysis against relevant schemes have been given which shows how our proposed scheme is better in terms of both communication and computation costs from them


### 1.2. Road Map of the Article

The article is arranged as follows: Section2 discusses literature presented for IIoT environment. Section 3 discusses the threat model and the preliminaries of our proposed certificateless signature construction (CLSC) scheme. Similarly, Section 4 describes the proposed network model for certificateless signature. Section 5 includes the proposed algorithm. In Section 6, we described the informal security analysis for CLSC scheme. In Section 7, we compared the CLSC scheme against relative existing certificateless signature schemes. In Section 8, we give the simulation study (Appendix), and in Section 9, we concluded our proposed scheme.


## 1.1. Motivation and Contribution

Inspired from the abovementioned discussion, a new certificateless signature scheme has been proposed for IIoT infrastructure. The proposed scheme is primarily based on HECC categorized by its smaller key length. The main contribution of this work is listed.(i)
A cost-effective certificateless signature scheme is constructed for IIoT environment using HECC(ii)
We provide a proper algorithm for the proposed scheme that avoids key escrow problems and guarantees the security assets of unforgeability, man-in-the-middle attack, and antireplay attack(iii)
We validated the designed approach using a widely accepted validation tool (AVISPA) by using the popular backend protocols, i.e., on-the-fly model checker (OFMC) and constraint logic-based Attack Searcher (AtSe)(iv)
We also give the AVISPA code and simulation results that are available in the simulation study (Appendix) in Section8(v)
In the end, a comprehensive comparative analysis against relevant schemes have been given which shows how our proposed scheme is better in terms of both communication and computation costs from them


## 1.2. Road Map of the Article

The article is arranged as follows: Section2 discusses literature presented for IIoT environment. Section 3 discusses the threat model and the preliminaries of our proposed certificateless signature construction (CLSC) scheme. Similarly, Section 4 describes the proposed network model for certificateless signature. Section 5 includes the proposed algorithm. In Section 6, we described the informal security analysis for CLSC scheme. In Section 7, we compared the CLSC scheme against relative existing certificateless signature schemes. In Section 8, we give the simulation study (Appendix), and in Section 9, we concluded our proposed scheme.


## 2. Related Work

In order to minimize data management overhead due to the popularity and introduction of IIoT into modern digitization, most organizations are outsourcing their respective data on the cloud server. However, this revolution requires and needs to create some low overhead data authentication schemes.For this purpose, Karati et al. [32] proposed a novel scheme for IIoT environment in certificateless settings. The authors claim that their scheme is safe against type I and type II adversaries under the standard model. Later, the scheme of Karati et al. [32] was found unsafe by [33, 34], against both type I and type II adversaries. Also, the security of Karati et al. scheme is on BPG. Naturally, BPG has the worst performance in terms of computing and communication resources and therefore does not correspond to the resource-limited setting of IIoT.Zhang et al. [33] broke the scheme mentioned in [32] by showing that their scheme cannot resist type I and type II adversaries. However, the authors in [33] did not construct a new scheme for the claimed statements. Later in 2019, Zhang et al. [34] also improved the scheme of [32] by constructing a robust technique for IIoT in certificateless settings. The authors in [34] utilized the ECC algorithm to reduce the cost consumption of IIoT. Unfortunately, ECC works on 160 bits key size, which needs to be reduced further to suit the resource-constrained devices of IIoT. In the same year, Yang et al. [35] claim that the scheme of [34] is not secure against the public key replacement attack. According to Yang et al., an invader can effortlessly forge a valid signature utilizing a fake public key. However, the authors in [35] did not construct a new scheme for the claimed statements.In 2019, Xiong et al. [36] presented a key-insulated signature scheme for IIoT using certificateless signature. The authors utilized the ECC algorithm under the random oracle model (ROM) to reduce the cost consumption of IIoT. As mentioned, ECC works on 160 bits key size that needs to be reduced further for resource-limited devices. Later, Rezaeibagha et al. [37] also improved the scheme of [32] by proposing a more concrete certificateless signature scheme under the standard model. The authors claim that their scheme is safe against type I and type II adversaries. However, Shim [47] proved the invalidity of the designed scheme against the type I adversary. Also, the security of [37] is based on BPG which does not correspond to the resource-limited setting of IIoT due to heavy pairing operations.


### 2.1. Outcomes of the Literature

The above schemes are constructed on the notion of BPG and ECC and hence withstand high computing and communication costs. Furthermore, the schemes mentioned in [33, 35] are unable to provide proper schemes for the claimed statements. Additionally, none of the previous schemes are validated by proper formal security tools such as AVISPA. For this reason, we suggest a lightweight certificateless signature scheme for IIoT using HECC.


## 2.1. Outcomes of the Literature

The above schemes are constructed on the notion of BPG and ECC and hence withstand high computing and communication costs. Furthermore, the schemes mentioned in [33, 35] are unable to provide proper schemes for the claimed statements. Additionally, none of the previous schemes are validated by proper formal security tools such as AVISPA. For this reason, we suggest a lightweight certificateless signature scheme for IIoT using HECC.


## 3. Preliminaries

### 3.1. Hyperelliptic Curve Discrete Logarithm Problem (HDLP)

LetϑE1,2,3,4,5,…,q−1 and ℒ=ϑ⋅D; then, finding ϑ from the given equation is called HDLP.


### 3.2. Threat Model

The most well-known Dolev–Yao threat model was used for this study’s certificateless signature scheme [48]. In this model, an adversary can intercept any open channel communications between two parties, which creates the possibility of eavesdropping, exchanging, and modifying messages. Given the use of wireless communications in IIoT environments, adversaries can contribute to sensitive data leakages.Type IA1 and type II A11 challenges were considered for security clarification of the CLE scheme [49]. A description of these challenges is given as follows:Type IA1: A1 is a malicious adversary, frequently regarded as an external attacker without master key accessType IIA11: A11 is frequently regarded as an internal attacker (also a malicious KGC) with master key access but without the ability to replace public keysConcerning the purpose ofA1 and A11 adversaries, these produce fake digital signatures for the scheme of core certificateless signature.


## 3.1. Hyperelliptic Curve Discrete Logarithm Problem (HDLP)

LetϑE1,2,3,4,5,…,q−1 and ℒ=ϑ⋅D; then, finding ϑ from the given equation is called HDLP.


## 3.2. Threat Model

The most well-known Dolev–Yao threat model was used for this study’s certificateless signature scheme [48]. In this model, an adversary can intercept any open channel communications between two parties, which creates the possibility of eavesdropping, exchanging, and modifying messages. Given the use of wireless communications in IIoT environments, adversaries can contribute to sensitive data leakages.Type IA1 and type II A11 challenges were considered for security clarification of the CLE scheme [49]. A description of these challenges is given as follows:Type IA1: A1 is a malicious adversary, frequently regarded as an external attacker without master key accessType IIA11: A11 is frequently regarded as an internal attacker (also a malicious KGC) with master key access but without the ability to replace public keysConcerning the purpose ofA1 and A11 adversaries, these produce fake digital signatures for the scheme of core certificateless signature.


## 4. Network Model

The proposed scheme consists of entities comprised of application provider (AP), data owner (DO), cloud server (CS), and data clients as shown in Figure2. The detailed descriptions of their role are given.AP: it plays the role of KGC. The AP is accountable for selecting the master secret key and master public key. Moreover, it is also answerable for issuing mathematical parameters in the entire network. Additionally, it is answerable for producing a partial private key for all the participants.DO: it is accountable for producing its respective private key and certificateless signature data of IIoT. Later, after signing, the DO sends the signed IIoT data to the CS, while the CS then sends the signed data to the intended clients, respectively.CS: the CS is a potential service for both short-term and long-term data storageData clients: the data client is responsible for verifying the intended received data using his/her own private key.Figure 2
Designed network model for IIoT.


## 5. Proposed Certificateless Signature Scheme

### 5.1. Certificateless Signature Construction (CLSC) Scheme

Consisting of the following four phases, the signature component is extracted from [50]: first, setup; second, key generation; third, signature; and fourth, verification. These phases lead to the practical formulation of a novel certificateless signature for real-world IIoT settings. Prior to beginning the algorithm’s process, it is worth consulting the notation presented in Table 1.Table 1
Symbols of the proposed algorithm.
SymbolDescriptionAPApplication providersIduIdentity of any participating userQKGC master private keyDHyperelliptic curve divisorNPrime no. with sizen = 280RKGC master public keyPPKPartial private keyKGCKey generation centerQDCSecret values of data consumersQDOSecret values of data ownersΩDOData user private keyΩDCData consumer private keyDOData ownersDCData consumersA1Type I attackerA11Type II attacker∥Concatenation


#### 5.1.1. Setup

A series of initial tasks are undertaken by an application provider (AP), which carries out the role of KGC. These tasks are as follows:(i)
AP chooses a prime numberQ to serve as a master private key, where Q≼1≼n−1(ii)
AP generates the master public key by computingR=Q⋅D(iii)
Public parameter set param = (R, D, n = 280, hEC) is selected(iv)
The chosen master private keyQ is kept in AP storage memory, while param and R are issued in the entire network.


#### 5.1.2. Key Generation

This phase consists of the following tasks:(i)
Partial private key generation (PPK): for a user with an identityIdu, an AP undertakes the onward process for PPK. This involves the following steps: choosing ru, where ru≼1≼n−1; computing Xu=ru⋅D; concatenating Lu=Idu‖Xu; computing Vu=ru+Q⋅Lu; and last, the AP sending Vu,Xu to the users. Together, the DC and DO calculate Vu⋅D=Xu+Lu⋅R, at the receiving end, thereby confirming a receiving PPK pair Vu,Xu.(1)Vu⋅D=?Xu+Lu⋅R=Vu⋅D=ϒu+Q⋅Lu⋅D,whereVu=ϒu+Q⋅Lu=ϒu⋅D+Q⋅Lu⋅D=Xu+Lu⋅R,whereXu=ϒu⋅DandR=Q⋅D.(ii)
Secret value generation: the secret valueQu is chosen randomly by the users (DO and DC), where Qu≼1≼n−1(iii)
Private key generation: the users (DO and DC) generate the private key by computingΩu=Vu,Qu(iv)
Public key generation: the users (DO and DC) generate the associated public key in the following way: computingWu=Qu⋅D, concatenating uu=Idu‖Wu, computing Pu=Xu‖uu⋅Wu, and at last, setting the public key by concatenating βu=Xu‖u.


#### 5.1.3. Signature

To generate a signature, the DO undertakes the following:(i)
Choosew, where w≼1≼n−1, compute N=w⋅D.(ii)
Calculatez=mIdDoτ, where Id Do denotes identity DO(iii)
Calculateδ=QDo+VDo+w⋅Z,QDo,VDo is DO’s private key pair(iv)
Calculate the DC signature asΦ=N,δ


#### 5.1.4. Verification

The DC validates the signature through the following computations:(i)
To begin, computeG=XDo+R⋅IdDoXDoDo,whereΧDo‖Do is DO’s public key(ii)
Acceptϕ, if δ⋅D=G+N⋅hmIdDoτ+hmIdDoτ


#### 5.1.5. Consistency

Here, DC acceptsϕ upon successful computation.(2)δ⋅D=G+N⋅mIdDoτ+Wu⋅mIdDoτ=QDo+VDo+w⋅Z⋅D=QDo+VDo+w⋅mIdDoτ⋅D,whereZ=mIdDoτ=QDo+VDo⋅mIdDoτ+w⋅mIdDoτ⋅D=WDO+VDo⋅D⋅mIdDoτ+w⋅D⋅mIdDoτ,whereWDO=QDO⋅D.


## 5.1. Certificateless Signature Construction (CLSC) Scheme

Consisting of the following four phases, the signature component is extracted from [50]: first, setup; second, key generation; third, signature; and fourth, verification. These phases lead to the practical formulation of a novel certificateless signature for real-world IIoT settings. Prior to beginning the algorithm’s process, it is worth consulting the notation presented in Table 1.Table 1
Symbols of the proposed algorithm.
SymbolDescriptionAPApplication providersIduIdentity of any participating userQKGC master private keyDHyperelliptic curve divisorNPrime no. with sizen = 280RKGC master public keyPPKPartial private keyKGCKey generation centerQDCSecret values of data consumersQDOSecret values of data ownersΩDOData user private keyΩDCData consumer private keyDOData ownersDCData consumersA1Type I attackerA11Type II attacker∥Concatenation


### 5.1.1. Setup

A series of initial tasks are undertaken by an application provider (AP), which carries out the role of KGC. These tasks are as follows:(i)
AP chooses a prime numberQ to serve as a master private key, where Q≼1≼n−1(ii)
AP generates the master public key by computingR=Q⋅D(iii)
Public parameter set param = (R, D, n = 280, hEC) is selected(iv)
The chosen master private keyQ is kept in AP storage memory, while param and R are issued in the entire network.


### 5.1.2. Key Generation

This phase consists of the following tasks:(i)
Partial private key generation (PPK): for a user with an identityIdu, an AP undertakes the onward process for PPK. This involves the following steps: choosing ru, where ru≼1≼n−1; computing Xu=ru⋅D; concatenating Lu=Idu‖Xu; computing Vu=ru+Q⋅Lu; and last, the AP sending Vu,Xu to the users. Together, the DC and DO calculate Vu⋅D=Xu+Lu⋅R, at the receiving end, thereby confirming a receiving PPK pair Vu,Xu.(1)Vu⋅D=?Xu+Lu⋅R=Vu⋅D=ϒu+Q⋅Lu⋅D,whereVu=ϒu+Q⋅Lu=ϒu⋅D+Q⋅Lu⋅D=Xu+Lu⋅R,whereXu=ϒu⋅DandR=Q⋅D.(ii)
Secret value generation: the secret valueQu is chosen randomly by the users (DO and DC), where Qu≼1≼n−1(iii)
Private key generation: the users (DO and DC) generate the private key by computingΩu=Vu,Qu(iv)
Public key generation: the users (DO and DC) generate the associated public key in the following way: computingWu=Qu⋅D, concatenating uu=Idu‖Wu, computing Pu=Xu‖uu⋅Wu, and at last, setting the public key by concatenating βu=Xu‖u.


### 5.1.3. Signature

To generate a signature, the DO undertakes the following:(i)
Choosew, where w≼1≼n−1, compute N=w⋅D.(ii)
Calculatez=mIdDoτ, where Id Do denotes identity DO(iii)
Calculateδ=QDo+VDo+w⋅Z,QDo,VDo is DO’s private key pair(iv)
Calculate the DC signature asΦ=N,δ


### 5.1.4. Verification

The DC validates the signature through the following computations:(i)
To begin, computeG=XDo+R⋅IdDoXDoDo,whereΧDo‖Do is DO’s public key(ii)
Acceptϕ, if δ⋅D=G+N⋅hmIdDoτ+hmIdDoτ


### 5.1.5. Consistency

Here, DC acceptsϕ upon successful computation.(2)δ⋅D=G+N⋅mIdDoτ+Wu⋅mIdDoτ=QDo+VDo+w⋅Z⋅D=QDo+VDo+w⋅mIdDoτ⋅D,whereZ=mIdDoτ=QDo+VDo⋅mIdDoτ+w⋅mIdDoτ⋅D=WDO+VDo⋅D⋅mIdDoτ+w⋅D⋅mIdDoτ,whereWDO=QDO⋅D.


## 5.1.1. Setup

A series of initial tasks are undertaken by an application provider (AP), which carries out the role of KGC. These tasks are as follows:(i)
AP chooses a prime numberQ to serve as a master private key, where Q≼1≼n−1(ii)
AP generates the master public key by computingR=Q⋅D(iii)
Public parameter set param = (R, D, n = 280, hEC) is selected(iv)
The chosen master private keyQ is kept in AP storage memory, while param and R are issued in the entire network.


## 5.1.2. Key Generation

This phase consists of the following tasks:(i)
Partial private key generation (PPK): for a user with an identityIdu, an AP undertakes the onward process for PPK. This involves the following steps: choosing ru, where ru≼1≼n−1; computing Xu=ru⋅D; concatenating Lu=Idu‖Xu; computing Vu=ru+Q⋅Lu; and last, the AP sending Vu,Xu to the users. Together, the DC and DO calculate Vu⋅D=Xu+Lu⋅R, at the receiving end, thereby confirming a receiving PPK pair Vu,Xu.(1)Vu⋅D=?Xu+Lu⋅R=Vu⋅D=ϒu+Q⋅Lu⋅D,whereVu=ϒu+Q⋅Lu=ϒu⋅D+Q⋅Lu⋅D=Xu+Lu⋅R,whereXu=ϒu⋅DandR=Q⋅D.(ii)
Secret value generation: the secret valueQu is chosen randomly by the users (DO and DC), where Qu≼1≼n−1(iii)
Private key generation: the users (DO and DC) generate the private key by computingΩu=Vu,Qu(iv)
Public key generation: the users (DO and DC) generate the associated public key in the following way: computingWu=Qu⋅D, concatenating uu=Idu‖Wu, computing Pu=Xu‖uu⋅Wu, and at last, setting the public key by concatenating βu=Xu‖u.


## 5.1.3. Signature

To generate a signature, the DO undertakes the following:(i)
Choosew, where w≼1≼n−1, compute N=w⋅D.(ii)
Calculatez=mIdDoτ, where Id Do denotes identity DO(iii)
Calculateδ=QDo+VDo+w⋅Z,QDo,VDo is DO’s private key pair(iv)
Calculate the DC signature asΦ=N,δ


## 5.1.4. Verification

The DC validates the signature through the following computations:(i)
To begin, computeG=XDo+R⋅IdDoXDoDo,whereΧDo‖Do is DO’s public key(ii)
Acceptϕ, if δ⋅D=G+N⋅hmIdDoτ+hmIdDoτ


## 5.1.5. Consistency

Here, DC acceptsϕ upon successful computation.(2)δ⋅D=G+N⋅mIdDoτ+Wu⋅mIdDoτ=QDo+VDo+w⋅Z⋅D=QDo+VDo+w⋅mIdDoτ⋅D,whereZ=mIdDoτ=QDo+VDo⋅mIdDoτ+w⋅mIdDoτ⋅D=WDO+VDo⋅D⋅mIdDoτ+w⋅D⋅mIdDoτ,whereWDO=QDO⋅D.


## 6. Security Analysis

### 6.1. Theorem A (Unforgeability)

A certificateless signature scheme has the property of unforgeability if it is impossible for adversariesA1 and A11 to undermine the sender’s private key and produce a forged signature on data.Proof.
Initially in the design scheme, a sender generates a signature on plaintextδ=QDo+VDo+w⋅Z. With the public channel, the signature Φ=N,δ is forwarded to the receiver.Case 1
IfA1 tries to create a forge digital signature, then it needs to calculate w from QDo+VDo+w⋅Z, and to do so, it further requires w from N=w⋅D,wherew is not known and D is a divisor of HECC. Subsequently, it is not feasible for A1 to solve HCDLP. Hence it is proved from the mentioned discussion that the designed scheme meets the security requirements of unforgeability against an outside attacker.Case 2
IfA1 tries to forge a signature, it will need to calculate QDo from QDo+VDo+w⋅Z that further requires QDo from WDo=QDo⋅D, where QDo is a secret value of the DO and D is a divisor of HECC. Consequently, it is not achievable for A1 to solve HCDLP. Hence it is proved from the mentioned discussion that the designed scheme meets the security requirements of unforgeability against an outside attacker in case two.Case 3
In the given case, ifA1 tries to create a forge digital signature, it will need to calculate VDo from QDo+VDo+w⋅Z that furthers require VDo from VDo=ΥDo+Q⋅LDo,whereγDo is a private number of DO and Q is a master secret key of KGC. Consequently, it is not achievable for A1 to calculate unknown values from an equation. Hence, demonstrated from the mentioned discussion, the designed scheme meets the security requirements of unforgeability against an outside attacker in case three.


### 6.2. Theorem Unforgeability

Here, if theA11 tries to forge a signature, it needs to calculate VDo,w, and QDo from QDo+Do+w⋅Z as the key generation center only has VDo=ΥDo+Q⋅LDo, since VDo has been calculated by the key generation center.Case 1
IfA11 tries to create a forge digital signature, then it will need to calculate w from QDo+VDo+w⋅Z, and to do so, it further requires w from N=w⋅D,wherew is not known and D is a divisor of HECC. Subsequently, it is not feasible for A1 to solve HCDLP. Hence it is proved from the mentioned discussion that the designed scheme meets the security requirements of unforgeability against insider attackers.Case 2
IfA1 tries to forge a signature, it will need to calculate QDo from QDo+VDo+w⋅Z that further requires QDo from WDo=QDo⋅D, where QDo is a secret value of the DO and D is a divisor of HECC. Consequently, it is not achievable for A11 to solve HCDLP. Hence it is proved from the mentioned discussion that the designed scheme meets the security requirements of unforgeability against insider attack in case two.


### 6.3. Theorem of Antireplay Attack

A certificateless signature scheme is supposed to accomplish the security requirement of an antireplay attack, if there is no possible adversary that can capture some old communication messages and resent them again to the intended receiver.Proof.
In the proposed scheme, at first, the data consumer (DC) sends a request to the data owner (DO) with a fresh nonceτ. The DO then sends τ with the original signature computed by him. After the given process, the DO sends the signed message =QDo+Do+w⋅Z to the DC. Therefore, the DC checks the freshness of τ.


### 6.4. Theorem of Man-in-the-Middle Attack

A certificateless signature scheme is supposed to attain the security requirements of man-in-the-middle attack, if there is no possible adversary that can obtain the signature made by DO.Proof.
If the adversary tries to obtain the signature, it first needs to calculateVDo,w,andQDo from δ=QDo+VDo+wZ. Though, it has been demonstrated in the abovementioned Theorem 1. Hence, we can claim that the designed scheme is safe against the security issue of man-in-the-middle attack.


## 6.1. Theorem A (Unforgeability)

A certificateless signature scheme has the property of unforgeability if it is impossible for adversariesA1 and A11 to undermine the sender’s private key and produce a forged signature on data.Proof.
Initially in the design scheme, a sender generates a signature on plaintextδ=QDo+VDo+w⋅Z. With the public channel, the signature Φ=N,δ is forwarded to the receiver.Case 1
IfA1 tries to create a forge digital signature, then it needs to calculate w from QDo+VDo+w⋅Z, and to do so, it further requires w from N=w⋅D,wherew is not known and D is a divisor of HECC. Subsequently, it is not feasible for A1 to solve HCDLP. Hence it is proved from the mentioned discussion that the designed scheme meets the security requirements of unforgeability against an outside attacker.Case 2
IfA1 tries to forge a signature, it will need to calculate QDo from QDo+VDo+w⋅Z that further requires QDo from WDo=QDo⋅D, where QDo is a secret value of the DO and D is a divisor of HECC. Consequently, it is not achievable for A1 to solve HCDLP. Hence it is proved from the mentioned discussion that the designed scheme meets the security requirements of unforgeability against an outside attacker in case two.Case 3
In the given case, ifA1 tries to create a forge digital signature, it will need to calculate VDo from QDo+VDo+w⋅Z that furthers require VDo from VDo=ΥDo+Q⋅LDo,whereγDo is a private number of DO and Q is a master secret key of KGC. Consequently, it is not achievable for A1 to calculate unknown values from an equation. Hence, demonstrated from the mentioned discussion, the designed scheme meets the security requirements of unforgeability against an outside attacker in case three.


## 6.2. Theorem Unforgeability

Here, if theA11 tries to forge a signature, it needs to calculate VDo,w, and QDo from QDo+Do+w⋅Z as the key generation center only has VDo=ΥDo+Q⋅LDo, since VDo has been calculated by the key generation center.Case 1
IfA11 tries to create a forge digital signature, then it will need to calculate w from QDo+VDo+w⋅Z, and to do so, it further requires w from N=w⋅D,wherew is not known and D is a divisor of HECC. Subsequently, it is not feasible for A1 to solve HCDLP. Hence it is proved from the mentioned discussion that the designed scheme meets the security requirements of unforgeability against insider attackers.Case 2
IfA1 tries to forge a signature, it will need to calculate QDo from QDo+VDo+w⋅Z that further requires QDo from WDo=QDo⋅D, where QDo is a secret value of the DO and D is a divisor of HECC. Consequently, it is not achievable for A11 to solve HCDLP. Hence it is proved from the mentioned discussion that the designed scheme meets the security requirements of unforgeability against insider attack in case two.


## 6.3. Theorem of Antireplay Attack

A certificateless signature scheme is supposed to accomplish the security requirement of an antireplay attack, if there is no possible adversary that can capture some old communication messages and resent them again to the intended receiver.Proof.
In the proposed scheme, at first, the data consumer (DC) sends a request to the data owner (DO) with a fresh nonceτ. The DO then sends τ with the original signature computed by him. After the given process, the DO sends the signed message =QDo+Do+w⋅Z to the DC. Therefore, the DC checks the freshness of τ.


## 6.4. Theorem of Man-in-the-Middle Attack

A certificateless signature scheme is supposed to attain the security requirements of man-in-the-middle attack, if there is no possible adversary that can obtain the signature made by DO.Proof.
If the adversary tries to obtain the signature, it first needs to calculateVDo,w,andQDo from δ=QDo+VDo+wZ. Though, it has been demonstrated in the abovementioned Theorem 1. Hence, we can claim that the designed scheme is safe against the security issue of man-in-the-middle attack.


## 7. Performance Analysis

Here, we analyze the performance of the designed approach in contrast to Zhang et al. [34], Karati et al. [32], Rezaebagha et al. [37], and Xiong et al. [36]. Moreover, we will also discuss the efficiency of the proposed scheme over the previous schemes in terms of computation cost and communication overhead.


### 7.1. Computational Cost

For performance efficiency in terms of computation cost, we compared our proposed scheme with Zhang et al. [34], Karati et al. [32], Rezaebagha et al. [37], and Xiong et al. [36]. The results of the comparison are given in Table 2. Though, previous schemes utilized BPG and ECC very expensive for a resource-limited environment. Therefore, we used the HECC to reduce the computation cost for the IIoT.Table 2
Comparison in terms of costly operations.
Reference no.Signing phaseVerification phaseTotal computation costCiphertext size in bits[32]2ℳE2ℳE+ℬp4ℳE+ℬp2G[34]pℬpℳℬp+pℬpℳ1ℬp+2pℬℳp2G[36]1ℰppℳ6ℰppℳ7ℰppℳ3q[37]ℳE2ℬp1ℳE+2ℬp2GProposed scheme2ℋℰppℳ4ℋℰppℳ6ℋppℳ2nFrom [41, 51], we observed the timing of the major observations used in the comparative analysis in terms of computation cost. According to [41, 51], a single bilinear pairing ℬp operation will take 14.90 ms, paring-based point multiplication pℬℳ will take 4.31 ms, scalar point multiplication ℰppℳ will take 0.97 ms, and modular exponentiation ℳℰ will take 1.25 ms, respectively. Similarly, a single hyperelliptic curve divisor multiplication ℋℰppℳ will take 0.48 ms [52, 53]. For measuring the efficiency, we take the MIRACL library with the given specifications: Intel Core i74510 CPU with 2.0 GHz processor, 8 GB RAM, and OS of 64 bits Windows 7 [41].Similarly, we also compare the designed scheme with the scheme of Zhang et al. [34], Karati et al. [32], Rezaebagha et al. [37], and Xiong et al. [36] in terms of communication overhead. For our comparative analysis, we take the variables and their size as 1024 bits for bilinear pairing, 160 bits for elliptic curves, and 80 bits for the hyperelliptic curve. Moreover, the communication overhead of all the related schemes and the proposed scheme is given in Table 2.The findings of the comparative analysis are shown in Table3, Figures 3 and 4. Furthermore, Tables 4 and 5 show a clear improvement in both communication overhead and computation cost.Figure 3
Computational cost analysis.Figure 4
Communication cost analysis.Table 3
Computational cost analysis in milliseconds.
Reference no.Signature generationSignature verificationTotal[32]2.517.419.9[34]4.3119.2123.52[36]0.975.826.79[37]1.2529.831.05Proposed scheme0.961.922.88Table 4
Reduction of total computational cost.
Reference no.Computational cost (x)Computational cost (y)Computational cost reduction (z) in percentage[32]19.92.8885.52[34]23.522.8887.75[36]6.792.8857.58[37]31.052.8890.72Percentage change =x−y/x∗100.Table 5
Communicational overhead reduction.
Reference no.Communication cost (x)Communication cost (y)Cost reduction in % (z)[32]204816092.18[34]204816092.18[36]48016066.66[37]204816092.18


## 7.1. Computational Cost

For performance efficiency in terms of computation cost, we compared our proposed scheme with Zhang et al. [34], Karati et al. [32], Rezaebagha et al. [37], and Xiong et al. [36]. The results of the comparison are given in Table 2. Though, previous schemes utilized BPG and ECC very expensive for a resource-limited environment. Therefore, we used the HECC to reduce the computation cost for the IIoT.Table 2
Comparison in terms of costly operations.
Reference no.Signing phaseVerification phaseTotal computation costCiphertext size in bits[32]2ℳE2ℳE+ℬp4ℳE+ℬp2G[34]pℬpℳℬp+pℬpℳ1ℬp+2pℬℳp2G[36]1ℰppℳ6ℰppℳ7ℰppℳ3q[37]ℳE2ℬp1ℳE+2ℬp2GProposed scheme2ℋℰppℳ4ℋℰppℳ6ℋppℳ2nFrom [41, 51], we observed the timing of the major observations used in the comparative analysis in terms of computation cost. According to [41, 51], a single bilinear pairing ℬp operation will take 14.90 ms, paring-based point multiplication pℬℳ will take 4.31 ms, scalar point multiplication ℰppℳ will take 0.97 ms, and modular exponentiation ℳℰ will take 1.25 ms, respectively. Similarly, a single hyperelliptic curve divisor multiplication ℋℰppℳ will take 0.48 ms [52, 53]. For measuring the efficiency, we take the MIRACL library with the given specifications: Intel Core i74510 CPU with 2.0 GHz processor, 8 GB RAM, and OS of 64 bits Windows 7 [41].Similarly, we also compare the designed scheme with the scheme of Zhang et al. [34], Karati et al. [32], Rezaebagha et al. [37], and Xiong et al. [36] in terms of communication overhead. For our comparative analysis, we take the variables and their size as 1024 bits for bilinear pairing, 160 bits for elliptic curves, and 80 bits for the hyperelliptic curve. Moreover, the communication overhead of all the related schemes and the proposed scheme is given in Table 2.The findings of the comparative analysis are shown in Table3, Figures 3 and 4. Furthermore, Tables 4 and 5 show a clear improvement in both communication overhead and computation cost.Figure 3
Computational cost analysis.Figure 4
Communication cost analysis.Table 3
Computational cost analysis in milliseconds.
Reference no.Signature generationSignature verificationTotal[32]2.517.419.9[34]4.3119.2123.52[36]0.975.826.79[37]1.2529.831.05Proposed scheme0.961.922.88Table 4
Reduction of total computational cost.
Reference no.Computational cost (x)Computational cost (y)Computational cost reduction (z) in percentage[32]19.92.8885.52[34]23.522.8887.75[36]6.792.8857.58[37]31.052.8890.72Percentage change =x−y/x∗100.Table 5
Communicational overhead reduction.
Reference no.Communication cost (x)Communication cost (y)Cost reduction in % (z)[32]204816092.18[34]204816092.18[36]48016066.66[37]204816092.18


## 8. Simulation Study (Appendix)

AVISPA [54], an industrial-grade security simulator, was used for security validation of the proposed scheme. The AVISPA simulator can be in one of two states: SAFE if the scheme is resistant to malicious attacks, and otherwise, UNSAFE (Figure 5).Figure 5
AVISPA basic structure.For GUI support, AVISPA is combined with SPAN, and the rule-oriented high-level protocol specification language (HLPSL) is available for specifying a scheme. Through intermediate format (IF) specifications, an HLP2IF translator is used to compile HLPSL into machine language [46, 48]. Regarding the role of these IF specifications, they serve as inputs to the backend checker, which can be the SAT-based model-checker (SATMC), on-the-fly-model checker (OFMC), tree-automata-based protocol analyzer (TA4SP), or CL-based attack searcher (CL-AtSe). Based on the proposed cryptographic scheme’s requirements, the functionality of every backend is distinctive [55]. DO and DC are the primary roles in the proposed scheme verification process, and the results indicate that the security of the scheme is grounded in CL-AtSe and OFMC. Information about the signature and verification codes and simulation results are presented in Figures 6–9 .Figure 6
Simulation results for on-the-fly model checker (OFMC).Figure 7
Signature using the HLPSL code.Figure 8
Verification using the HLPSL code.Figure 9
Simulation results for AtSe.


## 9. Conclusion

This study presents an efficient scheme for IIoT using certificateless signature with the help of the hyperelliptic curve cryptosystem (HCC). The presented approach is proven to be unforgeable against the challenges of type I and type II attackers. The security of the proposed work is tested through a popular tool “AVISPA.” A comprehensive comparative analysis against relevant schemes has been given which shows how our proposed scheme is better in terms of both communication and computation costs from them. Based on the above claims, we argue that the designed scheme will be the best option for the resource-limited devices in terms of cost consumptions.



---

*Source: 9960264-2021-07-20.xml*