# A Lightweight Proxy Re-Encryption Approach with Certificate-Based and Incremental Cryptography for Fog-Enabled E-Healthcare

Authors: Junaid Hassan; Danish Shehzad; Insaf Ullah; Fahad Algarni; Muhammad Umar Aftab; Muhammad Asghar Khan; M. Irfan Uddin
Journal: Security and Communication Networks
 (2021)

---

## Abstract

Cloud computing aims to provide reliable, customized, and quality of service (QoS) guaranteed dynamic computing environments for end-users. However, there are applications such as e-health and emergency response monitoring that require quick response and low latency. Delays caused by transferring data over the cloud can seriously affect the performance and reliability of real-time applications. Before outsourcing e-health care data to the cloud, the user needs to perform encryption on these sensitive data to ensure its confidentiality. Conventionally, any modification to the user data requires encrypting the entire data and calculating the hash of the data from scratch. This data modification mechanism increases communication and computation costs over the cloud. The distributed environment of fog computing is used to overcome the limitations of cloud computing. This paper proposed a certificate-based incremental proxy re-encryption scheme (CB-PReS) for e-health data sharing in fog computing. The proposed scheme improves the file modification operations, i.e., updation, deletion, and insertion. The proposed scheme is tested on the iFogSim simulator. The iFogSim simulator facilitates the development of models for fog and IoT environments, and it also measures the impact of resource management techniques regarding network congestion and latency. Experiments depict that the proposed scheme is better than the existing schemes based on expensive bilinear pairing and elliptic curve techniques. The proposed scheme shows significant improvement in key generation and file modification time.


---

## Body

## 1. Introduction

Health monitoring has become a leading issue in modern paradigms all over the world. According to the United Nations report [1], by 2050, the world’s 22% population will consist of vulnerable people who can be victims of various diseases. Nowadays, many devices are being developed to monitor vital signs such as human blood pressure, glucose level, heartbeat, and oxygen level. Readings are collected from the medical devices and then shared with the authorized health teams. These medical devices generate a large amount of data, and managing those data using traditional hardware or software has become a huge challenge [2, 3]. Since the advent of COVID-19, medical big data (MBD) has become important for the effective health monitoring systems. MBD by now has become irresistible because of its diversity and volume [4–7]. People suffer from many diseases in the world but Parkinson’s disease (PD) is a serious neurodegenerative disorder. Some recent studies have suggested different techniques for diagnosing Parkinson’s disease [8, 9]. These studies have improved the automated Parkinson’s disease detection using neural network techniques.Over time, in healthcare, electronic health records (EHR) have replaced the paper record system, so that data can be handled and maintained efficiently. It further improves the availability, sharing, and cost of data maintenance. A hybrid machine learning framework is proposed to predict mortality in paralytic ileus patients using (EHRs) [10]. Previously, if a person wanted to be treated by another doctor, he had to bring his report to the doctor in paper format. The EHR system has saved people from this hassle because it is abysmal to save paper reports for a long time. Now, the patient record is stored on a centralized cloud database from which all the doctors can check the patient’s medical reports and history. Therefore, the patient no longer needs to bring his reports to the doctor in paper form. All the users who register to a healthcare application can share their medical reports with all the healthcare authorities, i.e., doctors, physicians, pharmacists, and laboratory technicians.The widespread adoption of IoT devices in business and healthcare has raised serious concerns about evaluating IoT architectures regarding data communication, storage, security, and processing. In the healthcare field, a large number of IoT devices and sensors are currently being used producing a vast amount of data [11]. Therefore, we required an infrastructure that can process, store, and analyze this large amount of data.Across the world, cloud infrastructure is used to process a large variety of data. Currently, cloud infrastructure is the only feasible option for managing and communicating between IoT devices in the healthcare field [12, 13]. All computational heavy and battery drain works are being offloaded from IoT devices to cloud infrastructure to reduce the load on IoT devices, which increases the battery life of IoT devices [14].Healthcare IoT devices require minimum communication latency to gain expected performance. On the other hand, healthcare devices produced a massive amount of data. This large amount of data leads to high data traffic that causes network congestion and further delays. Healthcare-sensitive data becomes inadequate and meaningless for end-users due to large hop counts and large data transmission between IoT devices and cloud servers; as a result, we face two-way delays. Real-time data are required for time-sensitive healthcare applications. End users and healthcare IoT devices expect minimal latency delays, but cloud servers cannot meet these expectations. All kinds of delays, such as network delays, connection delays, and computational delays, need to be minimized during data transformation among healthcare IoT devices. The fog computing paradigm has emerged to address the challenges mentioned earlier. Fog computing has a fog node layer between IoT devices and cloud servers, as shown in Figure1. Distributed fog devices can also contribute to cloud scalability by reducing centralized communication and processing. Compared to the cloud, fog nodes in the edge network are much closer to end devices and have lower latency [15]. The 20% percent user response time is reduced in fog computing, and 90% of data traffic between cloud and end devices is reduced. The fog computing can minimize response latency for real-time applications by up to 50% [16]. While fog computing can serve IoT devices and applications more efficiently, data protection remains a critical issue in fog computing [17].Figure 1
Cloud, fog, and end-device architecture.Risk problems become even more critical as IoT devices share sensitive data because they are directly connected to the Internet [18]. Many research articles on fog computing and the Internet of things have focused on infrastructure and application development issues without providing adequate support for privacy and security protection mechanisms [19]. However, more complex and intricate security mechanisms cannot be performed on resource-constrained IoT devices, which shorten the device’s battery life and lead to high computational costs and significant delays in real-time applications that require an immediate response [20]. We avoid this by offloading these complex security tasks to fog rather than resource-limited IoT devices. When the user’s private data are stored on a fog node, they have no physical control over their data and face numerous privacy and security attacks. We cannot consider fog nodes as reliable storage. Fog computing can perform some security operations while transmitting and retrieving data to address IoT security and privacy concerns. We can achieve data privacy and confidentiality by encrypting our data. But encryption is a very complex and heavy function that requires more computation time and power. Therefore, we offload these cryptographic functions on fog nodes to achieve efficiency. However, fog nodes must also provide convenient, manageable, and easy communication and accurate access control.Some incremental cryptographic schemes for the limited resource devices are proposed in [21]. Because there is a lot of literature out there that is useful for data sharing. Still, our best research shows that certificate-based incremental proxy re-encryption is the most important and secure scheme. This paper proposes a certificate-based incremental proxy re-encryption scheme (CB-PReS) for e-healthcare data sharing in fog computing. The key escrow problem is also eliminated in certificate-based proxy re-encryption. In contrast, a key escrow problem is present in the identity-based proxy re-encryption scheme [22]. The efficiency and security hardness of certificate-based proxy re-encryption and identity-based proxy re-encryption scheme (IB-PRE) is based on the standard cryptosystems such as bilinear pairing (BP), elliptic curve (EC), and Rivest, Shamir, and Adleman (RSA). The 1024-bit key is used in RSA, while 160-bit key is used in ECC. The experimental results show that the bilinear pairing is 13.65 ms worse than that of Rivest, Shamir, and Adleman (RSA) as well as 13.93 ms worse than E.C. [23], and Rivest, Shamir, and Adleman (RSA) is 14.42 ms worse than the hyperelliptic curve [24]. The proposed scheme uses a hyperelliptic curve (HEC), and the 80-bit key is used in HEC to provide the same level of security and low communication and computational cost.


### 1.1. Motivation

There are some serious concerns about the security and privacy of IoT devices. Given these concerns, security measures need to be taken immediately. IoT devices are very resource-constrained devices, and the implementation of resource-intensive and complex security tasks on these devices is not feasible. This usually shortens the device’s battery life and leads to higher computational costs and significant delays in real-time applications that require immediate response [20]. Therefore, we can avoid these problems by offloading these complex security tasks to the fog instead of processing them on resource-constrained IoT devices. The communication and computational cost of the traditional crypto system is very high because of the use of traditional cryptographic functions such as RSA that uses a 1024-bit key size. The bilinear pairing scheme is 13.65 times worse than RSA, and RSA is 14.42 times worse than the hyperelliptic curve [23]. When we need to share encrypted data with multiple participants, we can achieve significant performance by using the proxy re-encryption scheme. In some cases, when we update the EHR data, we need to calculate the hash value from scratch to reflect the updation. If we want a minor update to a large amount of EHR data, then the entire hash must be recalculated from scratch, which is not a good thing in practice. Therefore, there is a need to implement incremental cryptography that reduces the overhead of hash value recalculation from scratch.


### 1.2. Contribution

The contribution of our proposed scheme is listed in the following steps:(i)
We have proposed a certificate-based incremental proxy re-encryption scheme for E-healthcare data sharing on fog computing, which deals with the problem of overhead and delay of previously proposed PRE schemes(ii)
Our scheme reduces the commutation cost and communication overhead of the resource-constraint IoT devices(iii)
Our scheme is based on the hyperelliptic curve, which uses the 80-bit key instead of elliptical curves, and bilinear pairing, which uses a 160-bit key and 1024-bit key, respectively(iv)
Our scheme provides block base data modification by using the concept of incremental cryptography(v)
Our scheme also fixes the key escrow problem by using the certificate-based proxy re-encryption(vi)
We have also provided a security model and security analysis of our scheme(vii)
Our scheme provides some security services such as integrity, confidentiality, unforgeability, and antireplay attack, respectively


## 1.1. Motivation

There are some serious concerns about the security and privacy of IoT devices. Given these concerns, security measures need to be taken immediately. IoT devices are very resource-constrained devices, and the implementation of resource-intensive and complex security tasks on these devices is not feasible. This usually shortens the device’s battery life and leads to higher computational costs and significant delays in real-time applications that require immediate response [20]. Therefore, we can avoid these problems by offloading these complex security tasks to the fog instead of processing them on resource-constrained IoT devices. The communication and computational cost of the traditional crypto system is very high because of the use of traditional cryptographic functions such as RSA that uses a 1024-bit key size. The bilinear pairing scheme is 13.65 times worse than RSA, and RSA is 14.42 times worse than the hyperelliptic curve [23]. When we need to share encrypted data with multiple participants, we can achieve significant performance by using the proxy re-encryption scheme. In some cases, when we update the EHR data, we need to calculate the hash value from scratch to reflect the updation. If we want a minor update to a large amount of EHR data, then the entire hash must be recalculated from scratch, which is not a good thing in practice. Therefore, there is a need to implement incremental cryptography that reduces the overhead of hash value recalculation from scratch.


## 1.2. Contribution

The contribution of our proposed scheme is listed in the following steps:(i)
We have proposed a certificate-based incremental proxy re-encryption scheme for E-healthcare data sharing on fog computing, which deals with the problem of overhead and delay of previously proposed PRE schemes(ii)
Our scheme reduces the commutation cost and communication overhead of the resource-constraint IoT devices(iii)
Our scheme is based on the hyperelliptic curve, which uses the 80-bit key instead of elliptical curves, and bilinear pairing, which uses a 160-bit key and 1024-bit key, respectively(iv)
Our scheme provides block base data modification by using the concept of incremental cryptography(v)
Our scheme also fixes the key escrow problem by using the certificate-based proxy re-encryption(vi)
We have also provided a security model and security analysis of our scheme(vii)
Our scheme provides some security services such as integrity, confidentiality, unforgeability, and antireplay attack, respectively


## 2. Related Work

In this part, we will review some of the publications that are related to our proposed work. In [25], the integrity-enforcement scheme is proposed that takes advantage of trusted computing and incremental cryptographic primitive and ensures the integrity of electronic health records for mobile device users stored in the cloud computing database. However, this scheme ignores data confidentiality. The proxy re-encryption (PRE) scheme is proposed by Blaze et al. in 1998 [26], various PRE schemes have been introduced in the literature so far. Proxy re-encryption scheme may be divided into two different classes, namely, bidirectional and unidirectional. In the unidirectional PRE schemes, there are further different types of PRE schemes, i.e., (1) identity-based PRE, (2) conditional PRE, (3) attribute-based PRE, and (4) time-based PRE. In the bidirectional scheme, there are also two types of PRE schemes, i.e., (1) threshold-based PRE and (2) type-based PRE) [27]. The re-encryption scheme can provide different kinds of features, such as key optimality, collusion resistance, proxy invisibility, nontransferability, noninteractivity, and unidirectionality, and this has been debated extensively in the literature [28]. Based on a set of these features, advanced proxy re-encryption schemes with advanced features were developed. Based on the presence of these features, the proxy re-encryption schemes are evaluated.Fine-grain access control is provided on the user’s private data in the attribution-based PRE (AB-PRE) [29, 30]. In AB-PRE, user A’s ciphertext is transformed under some certain set of attributes into user B’s ciphertext under some other set of attributes. Conditional PRE (C-PRE) is proposed in [31]. In the C-PRE scheme, the ciphertext is only transformed into another ciphertext by the proxy when it fulfils certain conditions. In the paper [32], the author defines another type of conditional PRE in which a ciphertext is transformed into another ciphertext by a proxy that has been received from a specific sender. Identity-based encryption (IB-PRE) is defined by the author [33] in which the proxy under Alice identity transforms the ciphertext into another ciphertext under Bob's identity. Later another type of identity-based encryption is defined by the author [34] without random oracles. An extended type of IB-PRE is defined in [35], which facilitates the conditional re-encryption features. This conditional re-encryption feature protects the user’s data from conditional attacks and also from identity chosen-ciphertext attacks. First time collusion-resistant unidirectional IB-PRE scheme is proposed in [36] which is secure from quantum attacks. The author in [37] proposed a type-based proxy re-encryption scheme in which ciphertexts of every delegator are associated with a specific type, and proxy transformed the ciphertext only when the public key of a delegate has the same type and through which the owner of the data gains proper delegation control. Another version of proxy re-encryption with certificate-based encryption is suggested in [38], which provides resistance to chosen-ciphertext attacks. Keyword search-based PRE scheme is proposed in [39], in which a proxy transforms the ciphertext if the ciphertext contains some keywords that match with specific information about the re-encryption key. In the paper [40], the author proposed a group-based PRE scheme in which a ciphertext is transformed by a proxy to be broadcast to a group. Therefore, all users belonging to the group can decrypt this ciphertext. Another scheme, proposed in [41], relies on conditional broadcast PRE. In this scheme, users are dynamically added to a group at runtime, and there is no need to change the public key for encryption every time.However, many existing schemes for secure data sharing and communication in cloud computing have limitations, i.e., delays between user requests and responses from the cloud due to a drastic increase in data volume. A large number of users are involved in outsourcing and cryptographic operations [42, 43]. The purpose of fog computing is to solve cloud computing-related problems by offloading expensive computational tasks to the network’s edge. Fog computing is also used to perform costly computational tasks that have reduced the computational overhead required on resource-constrained devices. However, some of the studies only focus on the privacy and security of fog computing [44]. Security issues and threats to fog computing are discussed in [16]. The PRE schemes proposed in the fog computing literature are the same ones that have been addressed in the cloud computing literature. Ciphertext-policy attribute-base-encryption (CP-ABE) is proposed in the literature [42, 45, 46] that provides secure access control to data encrypted in fog computing, which allows the data owner to define access policy to one of the features that the user needs to decrypt the ciphertext. Privacy-preserving proxy re-encryption scheme for access control is proposed by [47] which secures against chosen-plaintext attack (IND-CP-CPA). An improved version of proxy re-encryption scheme is proposed [48] in which at every hop ciphertext is transformed into a different ciphertext. We can secure the sensitive data with the usage of secure technologies mentioned in [49] such as access control, steganography, watermarking, and cryptography.The main disadvantage of using ID-based encryption, attribute-based encryption, and CP-ABE schemes in fog computing is the expensive computational cost of the decryption, which includes the complexity of the policy as well as various pairing operations [42, 46]. The first improved scheme for Internet of Vehicles is proposed [50] in which all the vehicles communicate with each other securely. Dynamic and simultaneous data communication between IoT devices occurs in fog computing. Due to the limited resources of fog computing and IoT networks, public-key encryption and traditional key management practices to secure communications between connected devices are incompatible with fog computing. Traditional encryption mechanisms require extensive computing resources for most objects and do not meet the operational requirements of the Internet of Things in real time [43].In [44], the authors proposed a scheme that is based on the random oracle model and uses bilinear paring cryptography. In 2013, the authors [51] proposed a random oracle-based CCA-secure proxy re-encryption scheme. In 2018, Bhatia et al. [45] proposed a certificateless proxy re-encryption scheme which is better that the scheme in [44] in computational cost because it uses elliptic curve cryptographic techniques. Another CL-PRE scheme is proposed by Xu and Chang [46] in 2012. This scheme is based on the key management and encryption-based access control for the data distributed using cloud infrastructure. Another single hope certificateless proxy re-encryption and CCA-secure unidirectional scheme is proposed in [52]. The first pairing-free certificateless proxy re-encryption scheme is proposed in 2014 by Lee and Han [53]. In 2015, another CL-PRE scheme for data distribution in cloud is proposed by Qin et al. [54]. This scheme does not provide any kind of security analysis.Distributed secure accessibility in mobile cloud computing is proposed in [55]. Some incremental cryptographic schemes, such as sharing-based scheme (ShS), coding-based scheme (CoS), and encryption-based scheme (EnS) [56], are proposed in [21] for the limited resource devices. To ensure data security, the mobile user enters a password that is converted into a key, and then, we encrypt the data through this key. More mobile resources are used in the process of encrypting and uploading complex and heavy tasks. The incremental proxy re-encryption scheme (I-PReS) is proposed in [56]. I-PReS is a block-based data sharing scheme [57]. This I-PReS improve the file modification operations that provide data integrity and confidentiality by using advanced cryptographic functions.The industry did not accept the incremental hash functions due to the following flaws. Firstly, a certain level of security is achieved through the use of a large number of expensive pairing operations by using known incremental hash functions [58, 59] (for example, 2128 or 2256), which can degrade their performance with respect to hash function. Secondly, hash value size is disproportionate to the incremental hash functions security level, which is calculated in several thousand bits, unlike SHA_1 producing 160-bit message digest output [60], SHA_2 producing 512-bit message digest output [61], and SHA_3 producing 512-bit message digest output [62]. Incremental hashing is proposed in [63], which requires all hash values of intermediate nodes to be stored. Recently, the authors of [64] proposed a CL-IPRE scheme for the healthcare system based on the elliptic curve improved version of [56]. In the CL-IPRE scheme, the author compares the results of the block modification with the previous scheme and uses an elliptical curve algorithm instead of bilinear pairing for key generation.


## 3. Materials and Methods

### 3.1. Preliminaries

Hyperelliptic curve (HEC) is a family of public-key cryptosystems, and its structure is based on algebraic curves. That is why, it is also called a special class of algebraic curves and can also be seen as a generalized form of elliptic curve cryptography (ECC) [65]. HEC differs from ECC in terms of obtaining curve points from the group as shown in Figure 2. The additive abelian group is obtained from the devisor and computed by the HEC. We use a divisor class group of the curve, and there is no group law on the points of the HEC. HEC can implement all major operations of the public-key cryptosystem, such as signature, encryption, decryption, and key exchange. It is also called a successor of the RSA cryptosystem because HEC has the same security level as RSA and uses a smaller signature and key. It also provides a fast signature and fast key generation.Figure 2
Hyperelliptic curve with genus = 2 [65].The hyperelliptic curve is defined over a finite fieldFq (where q is a prime and q > 3). We can also denote the field Fq as F2m (where the q = 2m); this means that field size is q × q, and it is a square matrix, and curve points are limited to integer coordinates. When we perform any algebraic operation such as addition or multiplication, then as a result, we get another point on the curve within the field. The genus of the curve over the Fq field is denoted by “g,” and the curve of genus one is called elliptic curve with the field Fq having the following values |Fq|g. log2 q ≈ 2160 and the genus two curve is called the hyperelliptic curve with the field Fq having the following values |Fq|g. log2 q ≈ 280.HEC is a special type of projective and nonsingular curve. Hyperelliptic curve over the fieldFq with the points (U, V) ∈ Fq satisfies the following equation:(1)V2+hUV=fU,where f and h both are polynomial in the field Fq with deg (f) = 2g + 1 and deg (h) ≤ g. It also satisfies both equation (1) and partial derivative equation h′U = 0 and h′UV+f′U=0.


### 3.2. Complexity Assumptions

In this section, we have made some assumption as follows:(i)
We can denote the fieldFq as F2m (where q = 2m); this means that field size is q x q, and it is a square matrix.(ii)
D is denoted as a divisor of the curve, and it is a formal sum of the points P ∈ HEC as shown in the following equation:(2)D=∑p€HECnip,where ni ∈ Fq.Definition 1.
We have ∂,φ ϵ {1, 2, 3, 4, …., q−1}, and ∂, φ picks a random value from the given range, and then we calculate the value of N using the following equation:(3)N=∂.D,where D is a divisor from the Jacobian group.
After that, we find the value of Λ from the following equation:(4)Λ=φ.D,where D is a divisor from the Jacobian group.
The probability of computing the values of ∂ andφ from equations (3) and (4) is negligible due to the Hec–Deffie–Hellman problem (HEC-DHP).Definition 2.
We haveE´ ϵ {1, 2, 3, 4, …., q−1}, and E´ picks a random value from the given range, and then we calculate the value of N from the following equation:(5)N=E´.D,where D is a divisor from the Jacobian group.
The probability of computing the values ofE´ from equation (5) is negligible due to the Hec-discrete-logarithm problem (HEC-DLP).


### 3.3. Syntax of Certificate-Based Incremental Proxy Re-Encryption Scheme

Our proposed scheme is an extension of Khan et al. [56] and Bhatia et al. [64]. Our certificate-based incremental proxy re-encryption scheme consists of seven phases that are (system setup, public and private key generation, certificate generation, proxy re-encryption key generation, encryption, proxy re-encryption, and decryption). The basic symbols which are used in the construction of the proposed scheme are given in Table 1. All these phases are explained as follows.Table 1
Notations of the proposed scheme.
Serial no.NotationDescription1IDUUnique identity of user2ESecurity parameter3CACertificate authority4QIt is a large prime number5δGenerator point6δMaster secret key7MPkMaster public key8ΨSet of public parameters9CertUUser certificate10α, β, γRandom values11SDigital signature12HP UPublic key hash13KUPrivate key14PUPublic key15RA⟶BRe-encryption key16HERElectronic health record17ZTotal number of blocks of a file18Bkkth block of the FILE19DjSize of thejth block20FSTotal size of the FILE21CkCiphertext ofkth block22CCiphertext of entire file23CAA numberχ PKA24CBA numberχ PKB25MACkMAC value ofBk block26MACfinalFinal mac value of allz blocks27BupdateCiphertext of updated block28CupdateBlock that user want to update29h1Hash function30KCertACertificate authority private key


#### 3.3.1. Setup

In this phase, the certificate authority sets public parametersψ, then randomly selects a master secret key δ, and computes a master public key MPk.


#### 3.3.2. Public and Private Key Generation

In this phase, each participant (sender, receiver, and certificate authority) first randomly selects three numbers such asα, β, and γ and calculates X = α + β, ξ = α. (γ-α) and η = γ. (β + γ). After that, each participant further computes public and private key pair (PU, KU).


#### 3.3.3. Certificate Generation

In this phase, CA takes the participant identityIDU, participant public key PU, and the public parameters ψ as input and generates a certificate for each participant (sender and receiver) and sends to each participant.


#### 3.3.4. Re-Encryption Key Generation

This algorithm is executed by the sender to generate re-encryption key such asRA⟶B = Kb/Ka and send to the resident fog proxy server without revealing any secret information about any user.


#### 3.3.5. Encryption

In this phase, the user outsources a fileF on the fog node. The user divides the file F into z blocks and encrypts each block using his public key PU. The user chooses a random number χ ∈ {1, 2, . . .. . .., q-1} to encrypt the file with his public key PU. To achieve integrity, the user applies the SHA-3 algorithm on each block of the FILE such as MACk = HSHA-3 (Bk), where 1 ≤ k ≤ z. Then again, the hash function is applied to the concatenated hash values to get a final single hash value that verifies the integrity of the file as MACfinal = HSHA-3 ‖k=1z (MACk), where 1 ≤ k ≤ z.


#### 3.3.6. Proxy Re-Encryption

In this phase, the proxy server transformed the first level ciphertext of the sender (CA ∈ Csender) to the second level ciphertext of the receiver (CB ∈ Creceiver). Proxy checks the access policy control list, if user B has access rights to the uploaded file, and then the proxy server re-encrypts that file and allows user B to download it.


#### 3.3.7. Decryption

In this phase, the receiver downloads the final hash value (MACfinal), second-level ciphertext (C, CB), and total numbers of blocks ‘z’ and decrypts each block by using his private key KB. After decrypting all the blocks, the receiver concatenates all the blocks to get the original file and checks the integrity of the FILE by calculating the hash of the FILE and matching the calculated hash with MACfinal.


## 3.1. Preliminaries

Hyperelliptic curve (HEC) is a family of public-key cryptosystems, and its structure is based on algebraic curves. That is why, it is also called a special class of algebraic curves and can also be seen as a generalized form of elliptic curve cryptography (ECC) [65]. HEC differs from ECC in terms of obtaining curve points from the group as shown in Figure 2. The additive abelian group is obtained from the devisor and computed by the HEC. We use a divisor class group of the curve, and there is no group law on the points of the HEC. HEC can implement all major operations of the public-key cryptosystem, such as signature, encryption, decryption, and key exchange. It is also called a successor of the RSA cryptosystem because HEC has the same security level as RSA and uses a smaller signature and key. It also provides a fast signature and fast key generation.Figure 2
Hyperelliptic curve with genus = 2 [65].The hyperelliptic curve is defined over a finite fieldFq (where q is a prime and q > 3). We can also denote the field Fq as F2m (where the q = 2m); this means that field size is q × q, and it is a square matrix, and curve points are limited to integer coordinates. When we perform any algebraic operation such as addition or multiplication, then as a result, we get another point on the curve within the field. The genus of the curve over the Fq field is denoted by “g,” and the curve of genus one is called elliptic curve with the field Fq having the following values |Fq|g. log2 q ≈ 2160 and the genus two curve is called the hyperelliptic curve with the field Fq having the following values |Fq|g. log2 q ≈ 280.HEC is a special type of projective and nonsingular curve. Hyperelliptic curve over the fieldFq with the points (U, V) ∈ Fq satisfies the following equation:(1)V2+hUV=fU,where f and h both are polynomial in the field Fq with deg (f) = 2g + 1 and deg (h) ≤ g. It also satisfies both equation (1) and partial derivative equation h′U = 0 and h′UV+f′U=0.


## 3.2. Complexity Assumptions

In this section, we have made some assumption as follows:(i)
We can denote the fieldFq as F2m (where q = 2m); this means that field size is q x q, and it is a square matrix.(ii)
D is denoted as a divisor of the curve, and it is a formal sum of the points P ∈ HEC as shown in the following equation:(2)D=∑p€HECnip,where ni ∈ Fq.Definition 1.
We have ∂,φ ϵ {1, 2, 3, 4, …., q−1}, and ∂, φ picks a random value from the given range, and then we calculate the value of N using the following equation:(3)N=∂.D,where D is a divisor from the Jacobian group.
After that, we find the value of Λ from the following equation:(4)Λ=φ.D,where D is a divisor from the Jacobian group.
The probability of computing the values of ∂ andφ from equations (3) and (4) is negligible due to the Hec–Deffie–Hellman problem (HEC-DHP).Definition 2.
We haveE´ ϵ {1, 2, 3, 4, …., q−1}, and E´ picks a random value from the given range, and then we calculate the value of N from the following equation:(5)N=E´.D,where D is a divisor from the Jacobian group.
The probability of computing the values ofE´ from equation (5) is negligible due to the Hec-discrete-logarithm problem (HEC-DLP).


## 3.3. Syntax of Certificate-Based Incremental Proxy Re-Encryption Scheme

Our proposed scheme is an extension of Khan et al. [56] and Bhatia et al. [64]. Our certificate-based incremental proxy re-encryption scheme consists of seven phases that are (system setup, public and private key generation, certificate generation, proxy re-encryption key generation, encryption, proxy re-encryption, and decryption). The basic symbols which are used in the construction of the proposed scheme are given in Table 1. All these phases are explained as follows.Table 1
Notations of the proposed scheme.
Serial no.NotationDescription1IDUUnique identity of user2ESecurity parameter3CACertificate authority4QIt is a large prime number5δGenerator point6δMaster secret key7MPkMaster public key8ΨSet of public parameters9CertUUser certificate10α, β, γRandom values11SDigital signature12HP UPublic key hash13KUPrivate key14PUPublic key15RA⟶BRe-encryption key16HERElectronic health record17ZTotal number of blocks of a file18Bkkth block of the FILE19DjSize of thejth block20FSTotal size of the FILE21CkCiphertext ofkth block22CCiphertext of entire file23CAA numberχ PKA24CBA numberχ PKB25MACkMAC value ofBk block26MACfinalFinal mac value of allz blocks27BupdateCiphertext of updated block28CupdateBlock that user want to update29h1Hash function30KCertACertificate authority private key


### 3.3.1. Setup

In this phase, the certificate authority sets public parametersψ, then randomly selects a master secret key δ, and computes a master public key MPk.


### 3.3.2. Public and Private Key Generation

In this phase, each participant (sender, receiver, and certificate authority) first randomly selects three numbers such asα, β, and γ and calculates X = α + β, ξ = α. (γ-α) and η = γ. (β + γ). After that, each participant further computes public and private key pair (PU, KU).


### 3.3.3. Certificate Generation

In this phase, CA takes the participant identityIDU, participant public key PU, and the public parameters ψ as input and generates a certificate for each participant (sender and receiver) and sends to each participant.


### 3.3.4. Re-Encryption Key Generation

This algorithm is executed by the sender to generate re-encryption key such asRA⟶B = Kb/Ka and send to the resident fog proxy server without revealing any secret information about any user.


### 3.3.5. Encryption

In this phase, the user outsources a fileF on the fog node. The user divides the file F into z blocks and encrypts each block using his public key PU. The user chooses a random number χ ∈ {1, 2, . . .. . .., q-1} to encrypt the file with his public key PU. To achieve integrity, the user applies the SHA-3 algorithm on each block of the FILE such as MACk = HSHA-3 (Bk), where 1 ≤ k ≤ z. Then again, the hash function is applied to the concatenated hash values to get a final single hash value that verifies the integrity of the file as MACfinal = HSHA-3 ‖k=1z (MACk), where 1 ≤ k ≤ z.


### 3.3.6. Proxy Re-Encryption

In this phase, the proxy server transformed the first level ciphertext of the sender (CA ∈ Csender) to the second level ciphertext of the receiver (CB ∈ Creceiver). Proxy checks the access policy control list, if user B has access rights to the uploaded file, and then the proxy server re-encrypts that file and allows user B to download it.


### 3.3.7. Decryption

In this phase, the receiver downloads the final hash value (MACfinal), second-level ciphertext (C, CB), and total numbers of blocks ‘z’ and decrypts each block by using his private key KB. After decrypting all the blocks, the receiver concatenates all the blocks to get the original file and checks the integrity of the FILE by calculating the hash of the FILE and matching the calculated hash with MACfinal.


## 3.3.1. Setup

In this phase, the certificate authority sets public parametersψ, then randomly selects a master secret key δ, and computes a master public key MPk.


## 3.3.2. Public and Private Key Generation

In this phase, each participant (sender, receiver, and certificate authority) first randomly selects three numbers such asα, β, and γ and calculates X = α + β, ξ = α. (γ-α) and η = γ. (β + γ). After that, each participant further computes public and private key pair (PU, KU).


## 3.3.3. Certificate Generation

In this phase, CA takes the participant identityIDU, participant public key PU, and the public parameters ψ as input and generates a certificate for each participant (sender and receiver) and sends to each participant.


## 3.3.4. Re-Encryption Key Generation

This algorithm is executed by the sender to generate re-encryption key such asRA⟶B = Kb/Ka and send to the resident fog proxy server without revealing any secret information about any user.


## 3.3.5. Encryption

In this phase, the user outsources a fileF on the fog node. The user divides the file F into z blocks and encrypts each block using his public key PU. The user chooses a random number χ ∈ {1, 2, . . .. . .., q-1} to encrypt the file with his public key PU. To achieve integrity, the user applies the SHA-3 algorithm on each block of the FILE such as MACk = HSHA-3 (Bk), where 1 ≤ k ≤ z. Then again, the hash function is applied to the concatenated hash values to get a final single hash value that verifies the integrity of the file as MACfinal = HSHA-3 ‖k=1z (MACk), where 1 ≤ k ≤ z.


## 3.3.6. Proxy Re-Encryption

In this phase, the proxy server transformed the first level ciphertext of the sender (CA ∈ Csender) to the second level ciphertext of the receiver (CB ∈ Creceiver). Proxy checks the access policy control list, if user B has access rights to the uploaded file, and then the proxy server re-encrypts that file and allows user B to download it.


## 3.3.7. Decryption

In this phase, the receiver downloads the final hash value (MACfinal), second-level ciphertext (C, CB), and total numbers of blocks ‘z’ and decrypts each block by using his private key KB. After decrypting all the blocks, the receiver concatenates all the blocks to get the original file and checks the integrity of the FILE by calculating the hash of the FILE and matching the calculated hash with MACfinal.


## 4. Construction of the Proposed Algorithm

In this paper, we have proposed a certificate-based incremental proxy re-encryption data sharing scheme for fog computing. Our scheme deals with the computation and communication problem of previous PRE schemes due to the use of expensive cryptographic functions and cloud computing. In our scheme, to reduce the overhead of resource constraints IoT devices, complex and resource-intensive cryptographic functions are offloaded on fog nodes. We show that our scheme has less communication cost as compared to previous PRE schemes that are necessary for real-time devices. Therefore, each fog node is considered as a proxy node, and all the resource-intensive tasks involved in the process of re-encryption are performed on fog nodes. The structure of our proposed scheme is shown in Figure3.Figure 3
Proposed scheme architecture for secure data sharing in fog computing.Our proposed certificate-based incremental proxy re-encryption data sharing scheme for fog computing is in [64].


### 4.1. System Setup

Certificate authority (CA) runs this algorithm, and it chooses a security parameterE and hyperelliptic curve (HEC) over a finite field Fq of order q. CA selects an integer ℘ as a divisor that is the generator point of order q on the curve. Then, CA randomly selects a master secret key δ ∈ {1, 2, . . . . . . ., q-1} and further calculates the master public key as MPk = δ.℘. Finally, CA announces some public parameters for encryption, decryption, and proxy re-encryption such as ψ = {CertU, Fq, IDU, ℘, MPk, h1, h2, h3}.


### 4.2. Public and Private Key Generation

In this phase, each participant (sender, receiver, and certificate authority) executes this algorithm, the participant first randomly selects three numbers such asα ∈ {1, 2, . . . . . . ., q−1}, β ∈ {1, 2, ..., q−1}, and γ ∈ {1, 2, ..., q−1}, and then calculates X = α + β, ξ = α.(γ−α), and η = γ.(β + γ). The participant with identity IDU computes the public and private key pair (PU, KU). Each participant computes its private key such as KU = β. (ξ−η) + MPk, after computing private key each participant further computes its public key such as PU = KU. ℘. The public key of each participant is publicly announced.


### 4.3. Certificate Generation

In this phase, CA takes the participant identity IDU, participant public key PU, and the public parameters ψ as an input (IDU, PU, ψ) and generates a certificate (CertU) for each participant (sender and receiver) and sends to each participant. CA generates the certificate through the following process: first, CA takes participant public key PU and calculates hash of the PU such as HPU = h1 (PU||IDU) + MPk after computing the hash of PU, and CA digitally signs HPU with its private key such as S  = KCertA (HPU).


### 4.4. Re-Encryption Key Generation

If user A wants to share data with user B, then user A runs this algorithm to generate a re-encryption key such asRA⟶B = Kb/Ka using a two-party secure integer division algorithm [65] and sends it to the resident fog proxy server without revealing any secret information about the Ka and Kb.


### 4.5. Encryption

In this phase, when a user wants to outsource a fileF on the fog node, first, he divides the file F into z blocks, and each block has a constant size of d bits except the last block. To achieve confidentiality, the user encrypts each block using his public key PU. The following condition should be satisfied while dividing the file F into z blocks as follows:(6)FILE=k=1zBk,(7)Dj=FSZ,where 1 ≤ j ≤ z–1 and(8)Dz=FS−FSZ∗z−1,where Bk represents the k th block of the file, Dj represents the size of the jth block of the file, FS denotes the total size of the file, FS/Z represents the mathematical floor function that removes the fraction part, and Dz denotes the size of the last block of file. Before outsourcing file on the fog node, the user encrypts all the file blocks with his public key PU to achieve confidentiality. The user chooses a random number χ ∈ {1, 2, ... , q−1} to encrypt the FILE with his public key PU. Equations (9) and (10) depict the encryption process.(9)CA=χ.PA,CK=BK+χ.℘,(10)C=k=1zCk,where 1 ≤ k ≤ z.To achieve integrity, the user applies the recently proposed algorithm SHA-3 on each block of the file. Afterwards, hash values of all the blocks are concatenated together. Then again, the hash function is applied to the concatenated hash values to get a final single hash value that verifies the file integrity as follows.(11)MACk=HSHA−3Bk,where 1 ≤ k ≤ z, and(12)MACfinal=HSHA−3k=1zMACk,where 1 ≤ k ≤ z.The hash value of each block (MACk), the encrypted file (C, CA), total number of blocks “z,” and the final hash value (MACfinal) are stored on the fog node. Only the total number of blocks “z” and the file’s name are saved on the local storage. The user saves the local information (z, filename) for every file.


### 4.6. Proxy Re-Encryption

User B requests the proxy server for the re-encryption process to get the file uploaded on the fog node by user A. In the re-encryption process, the proxy server transforms the first level ciphertext of user A (CA ∈ C1) to the second level ciphertext of user B (CB ∈ C2) and also chooses a fresh nonce. The proxy first checks the access control list if user B has access rights to the uploaded file, then the proxy server re-encrypts that file and attached a Nonce value with the file as depicted in equations (13) and (14), and then allows user B to download it.(13)CB=CARA⟶B=χ.Ka.℘KbKa=χ.Kb.℘,Ck=Bk+χ.℘,(14)C=k=1zCkNonce,where 1 ≤ k ≤ z.The proxy server transfers the final hash value (MACfinal), second-level ciphertext (C, CB), and the total numbers of blocks “z” to user B for checking the integrity of the file and decryption.


### 4.7. Decryption

User B downloads the final hash value (MACfinal), second-level ciphertext (C, CB), and the total numbers of blocks “z.” Then, user B decrypts the file by using CB and his private key KB as shown in the following equation:(15)Bk=Ck−1KBCB,where 1 ≤ k ≤ z.User A can decrypt the file by usingCA and his private key KA as shown in the following equation:(16)Bk=Ck−1KACA,where 1 ≤ k ≤ z.After decrypting all the blocks, userB concatenates all the blocks to get the original file. User B checks the integrity of the file depicted as follows:(17)FILE=k=1zBk,where 1 ≤ k ≤ z,(18)MACk=HSHA−3Bk,where 1 ≤ k ≤ z, and(19)MACfinal=HSHA−3k=1zMACk,where 1 ≤ k ≤ z.If the value of the calculated hash function is equal to the value of the final hash function (MACfinal), then the FILE integrity is confirmed; otherwise, the original file is changed by some intruder.


## 4.1. System Setup

Certificate authority (CA) runs this algorithm, and it chooses a security parameterE and hyperelliptic curve (HEC) over a finite field Fq of order q. CA selects an integer ℘ as a divisor that is the generator point of order q on the curve. Then, CA randomly selects a master secret key δ ∈ {1, 2, . . . . . . ., q-1} and further calculates the master public key as MPk = δ.℘. Finally, CA announces some public parameters for encryption, decryption, and proxy re-encryption such as ψ = {CertU, Fq, IDU, ℘, MPk, h1, h2, h3}.


## 4.2. Public and Private Key Generation

In this phase, each participant (sender, receiver, and certificate authority) executes this algorithm, the participant first randomly selects three numbers such asα ∈ {1, 2, . . . . . . ., q−1}, β ∈ {1, 2, ..., q−1}, and γ ∈ {1, 2, ..., q−1}, and then calculates X = α + β, ξ = α.(γ−α), and η = γ.(β + γ). The participant with identity IDU computes the public and private key pair (PU, KU). Each participant computes its private key such as KU = β. (ξ−η) + MPk, after computing private key each participant further computes its public key such as PU = KU. ℘. The public key of each participant is publicly announced.


## 4.3. Certificate Generation

In this phase, CA takes the participant identity IDU, participant public key PU, and the public parameters ψ as an input (IDU, PU, ψ) and generates a certificate (CertU) for each participant (sender and receiver) and sends to each participant. CA generates the certificate through the following process: first, CA takes participant public key PU and calculates hash of the PU such as HPU = h1 (PU||IDU) + MPk after computing the hash of PU, and CA digitally signs HPU with its private key such as S  = KCertA (HPU).


## 4.4. Re-Encryption Key Generation

If user A wants to share data with user B, then user A runs this algorithm to generate a re-encryption key such asRA⟶B = Kb/Ka using a two-party secure integer division algorithm [65] and sends it to the resident fog proxy server without revealing any secret information about the Ka and Kb.


## 4.5. Encryption

In this phase, when a user wants to outsource a fileF on the fog node, first, he divides the file F into z blocks, and each block has a constant size of d bits except the last block. To achieve confidentiality, the user encrypts each block using his public key PU. The following condition should be satisfied while dividing the file F into z blocks as follows:(6)FILE=k=1zBk,(7)Dj=FSZ,where 1 ≤ j ≤ z–1 and(8)Dz=FS−FSZ∗z−1,where Bk represents the k th block of the file, Dj represents the size of the jth block of the file, FS denotes the total size of the file, FS/Z represents the mathematical floor function that removes the fraction part, and Dz denotes the size of the last block of file. Before outsourcing file on the fog node, the user encrypts all the file blocks with his public key PU to achieve confidentiality. The user chooses a random number χ ∈ {1, 2, ... , q−1} to encrypt the FILE with his public key PU. Equations (9) and (10) depict the encryption process.(9)CA=χ.PA,CK=BK+χ.℘,(10)C=k=1zCk,where 1 ≤ k ≤ z.To achieve integrity, the user applies the recently proposed algorithm SHA-3 on each block of the file. Afterwards, hash values of all the blocks are concatenated together. Then again, the hash function is applied to the concatenated hash values to get a final single hash value that verifies the file integrity as follows.(11)MACk=HSHA−3Bk,where 1 ≤ k ≤ z, and(12)MACfinal=HSHA−3k=1zMACk,where 1 ≤ k ≤ z.The hash value of each block (MACk), the encrypted file (C, CA), total number of blocks “z,” and the final hash value (MACfinal) are stored on the fog node. Only the total number of blocks “z” and the file’s name are saved on the local storage. The user saves the local information (z, filename) for every file.


## 4.6. Proxy Re-Encryption

User B requests the proxy server for the re-encryption process to get the file uploaded on the fog node by user A. In the re-encryption process, the proxy server transforms the first level ciphertext of user A (CA ∈ C1) to the second level ciphertext of user B (CB ∈ C2) and also chooses a fresh nonce. The proxy first checks the access control list if user B has access rights to the uploaded file, then the proxy server re-encrypts that file and attached a Nonce value with the file as depicted in equations (13) and (14), and then allows user B to download it.(13)CB=CARA⟶B=χ.Ka.℘KbKa=χ.Kb.℘,Ck=Bk+χ.℘,(14)C=k=1zCkNonce,where 1 ≤ k ≤ z.The proxy server transfers the final hash value (MACfinal), second-level ciphertext (C, CB), and the total numbers of blocks “z” to user B for checking the integrity of the file and decryption.


## 4.7. Decryption

User B downloads the final hash value (MACfinal), second-level ciphertext (C, CB), and the total numbers of blocks “z.” Then, user B decrypts the file by using CB and his private key KB as shown in the following equation:(15)Bk=Ck−1KBCB,where 1 ≤ k ≤ z.User A can decrypt the file by usingCA and his private key KA as shown in the following equation:(16)Bk=Ck−1KACA,where 1 ≤ k ≤ z.After decrypting all the blocks, userB concatenates all the blocks to get the original file. User B checks the integrity of the file depicted as follows:(17)FILE=k=1zBk,where 1 ≤ k ≤ z,(18)MACk=HSHA−3Bk,where 1 ≤ k ≤ z, and(19)MACfinal=HSHA−3k=1zMACk,where 1 ≤ k ≤ z.If the value of the calculated hash function is equal to the value of the final hash function (MACfinal), then the FILE integrity is confirmed; otherwise, the original file is changed by some intruder.


## 5. Incremental Block Modification

In this phase, we use incremental cryptographic technique shown in Figure4. The block modification operations are performed by using the incremental cryptographic technique. The block modification consists of three phases: (1) block deletion, (2) block updation, and (3) block insertion. Dividing the FILE into blocks and calculating the hash value of each block increases the overhead, but this overhead can be overcome by using the incremental cryptographic technique during the block modification operation. There is no need to calculate the hash value from scratch while performing the block modification operations. Different phases of block modification are given in [56].Figure 4
Workflow of the incremental cryptographic scheme [66].


### 5.1. Block Deletion Operation

In this phase, the user wants to delete some blocksr of the uploaded file from different locations Idx. The user downloads hash values of all blocks (MACk) of the corresponding file from the fog node. The user can delete the required blocks from the file by updating the final hash value. Final hash is updated by computing the hash of the concatenated hashes of the remaining blocks as depicted in (20).(20)MACfinal=HSHA−3k=1Idx−1MACkL=Idx+rzMACL.The user sends the location information (Idx) of the deleted blocks and updates the final hash value (MACfinal), total number of deleted blocks r, with delete request to the proxy server. The proxy server updates the final hash value MACfinal and deletes all the requested blocks from the file given in (20) and (21).(21)MACfinal=k=1Idx−1MACkL=Idx+rzMACL,(22)C=k=1Idx−1MACkL=Idx+rzCL.The proxy server also updates all the values into the fog storage, and the value of the total number of blocks is also changed fromz to z = z-r.


### 5.2. Block Modification Operation

In this phase, if the user wants to modify some blocksr of the corresponding file at different locations Idx, the user downloads the hash value of all the blocks (MACk) and the encrypted file (C, CU) from the fog node. The user then encrypts all the blocks that need to be modified using the following process: (23)Bupdatek=Cupdatek+1KACA,where 1 ≤ k ≤ z.The user also calculates the hash values of all the modified blocks, and afterwards, the user calculates the final hash value MACfinal as follows:(24)MACupdate=HSHA−3Bupdate,(25)MACfinal=k=1Idx−1MACkL=IdxIdx+rMACupdateLM=Idx+rzMACM.The user sends the location information (Idx) of the modified blocks and the final hash value (MACfinal) obtained by applying hash function on the concatenated hash values of all the blocks, total number of modified blocks r, with modification request to the proxy server. The proxy server updates the final hash value MACfinal and updates all the requested blocks of the FILE as follows:(26)MACfinal=k=1Idx−1MACkL=IdxIdx+rMACupdateLM=Idx+rzMACM,(27)Cfinal=k=1Idx−1CkL=IdxIdx+rCupdateLM=Idx+rzCM.The proxy server updates all the values into the fog storage, and the value of the total number of blocksz remains same.


### 5.3. Block Insertion Operation

In this phase, if the user wants to insert some new blocksr at different locations Idx of the corresponding file. Then, the user downloads the hash value of all the blocks (MACk) and encrypted file (C, CU) from the fog node. The user then encrypts all the new blocks that need to be inserted in the file using the following procedure:(28)Cnew=χ⋅PACU=Bnew⋅χ⋅℘.The user also calculates the hash values of all the newly inserted blocks in the file, and afterwards, the user calculates the final hash value MACfinal using the following equations:(29)MACinsert=HSHA−3Binsert,(30)MACfinal=k=1Idx−1MACkL=IdxIdx+rMACupdateLM=Idx+rzMACM.The user sends the location information (Idx) of the newly inserted blocks in the file and final hash value (MACfinal) obtained by applying hash function on all the concatenated hash values of all old and new blocks, total number of newly inserted blocks r, with insertion request to the proxy server. The proxy server updates the final hash value MACfinal and all the newly inserted blocks in the file using the following procedure:(31)MACfinal=k=1Idx−1MACkL=IdxIdx+rMACupdateLM=Idx+rzMACM,(32)Cfinal=k=1Idx−1CkL=IdxIdx+rCupdateLM=Idx+rzCM.The proxy server updates all the values into the fog storage, and the value of the total number of blocks also changes fromz to z = z + r.


## 5.1. Block Deletion Operation

In this phase, the user wants to delete some blocksr of the uploaded file from different locations Idx. The user downloads hash values of all blocks (MACk) of the corresponding file from the fog node. The user can delete the required blocks from the file by updating the final hash value. Final hash is updated by computing the hash of the concatenated hashes of the remaining blocks as depicted in (20).(20)MACfinal=HSHA−3k=1Idx−1MACkL=Idx+rzMACL.The user sends the location information (Idx) of the deleted blocks and updates the final hash value (MACfinal), total number of deleted blocks r, with delete request to the proxy server. The proxy server updates the final hash value MACfinal and deletes all the requested blocks from the file given in (20) and (21).(21)MACfinal=k=1Idx−1MACkL=Idx+rzMACL,(22)C=k=1Idx−1MACkL=Idx+rzCL.The proxy server also updates all the values into the fog storage, and the value of the total number of blocks is also changed fromz to z = z-r.


## 5.2. Block Modification Operation

In this phase, if the user wants to modify some blocksr of the corresponding file at different locations Idx, the user downloads the hash value of all the blocks (MACk) and the encrypted file (C, CU) from the fog node. The user then encrypts all the blocks that need to be modified using the following process: (23)Bupdatek=Cupdatek+1KACA,where 1 ≤ k ≤ z.The user also calculates the hash values of all the modified blocks, and afterwards, the user calculates the final hash value MACfinal as follows:(24)MACupdate=HSHA−3Bupdate,(25)MACfinal=k=1Idx−1MACkL=IdxIdx+rMACupdateLM=Idx+rzMACM.The user sends the location information (Idx) of the modified blocks and the final hash value (MACfinal) obtained by applying hash function on the concatenated hash values of all the blocks, total number of modified blocks r, with modification request to the proxy server. The proxy server updates the final hash value MACfinal and updates all the requested blocks of the FILE as follows:(26)MACfinal=k=1Idx−1MACkL=IdxIdx+rMACupdateLM=Idx+rzMACM,(27)Cfinal=k=1Idx−1CkL=IdxIdx+rCupdateLM=Idx+rzCM.The proxy server updates all the values into the fog storage, and the value of the total number of blocksz remains same.


## 5.3. Block Insertion Operation

In this phase, if the user wants to insert some new blocksr at different locations Idx of the corresponding file. Then, the user downloads the hash value of all the blocks (MACk) and encrypted file (C, CU) from the fog node. The user then encrypts all the new blocks that need to be inserted in the file using the following procedure:(28)Cnew=χ⋅PACU=Bnew⋅χ⋅℘.The user also calculates the hash values of all the newly inserted blocks in the file, and afterwards, the user calculates the final hash value MACfinal using the following equations:(29)MACinsert=HSHA−3Binsert,(30)MACfinal=k=1Idx−1MACkL=IdxIdx+rMACupdateLM=Idx+rzMACM.The user sends the location information (Idx) of the newly inserted blocks in the file and final hash value (MACfinal) obtained by applying hash function on all the concatenated hash values of all old and new blocks, total number of newly inserted blocks r, with insertion request to the proxy server. The proxy server updates the final hash value MACfinal and all the newly inserted blocks in the file using the following procedure:(31)MACfinal=k=1Idx−1MACkL=IdxIdx+rMACupdateLM=Idx+rzMACM,(32)Cfinal=k=1Idx−1CkL=IdxIdx+rCupdateLM=Idx+rzCM.The proxy server updates all the values into the fog storage, and the value of the total number of blocks also changes fromz to z = z + r.


## 6. Security Analysis

In this phase, we present the security analysis is of our certificate-based incremental proxy re-encryption scheme. In this security analysis, we ensure various security requirements such as integrity and confidentiality.


### 6.1. Confidentiality

Data confidentiality means that sensitive data are protected from unauthorized users and blocks unauthorized users’ access to sensitive data.


#### 6.1.1. Level-1 Encryption

In our method, if an intruder wants to steal our sensitive data, then he must know about the level-1 encryption sender private key. An intruder can get the sender’s private key by performing the following steps:Step 1: the intruder can get a level-1 encryption sender private key if he computes equation (33). For this, the intruder needs to find the value of β, and it is not feasible due to the hyperelliptic curve discrete logarithm problem:(33)KU=β⋅ξ−η.Step 2: if in any way the intruder gets the value ofβ, then next it wants to find the value of ξ and η from equations (34) and (35). For this, the intruder needs to find the value of α and γ, and it is also not feasible due to the hyperelliptic curve discrete logarithm problem. In fact, to get the level-1 encryption sender private key, the intruder will have to solve the hyperelliptic curve discrete logarithm problem three times, which is not feasible.(34)ξ=α⋅γ−α,(35)η=γ⋅β+γ.


#### 6.1.2. Level-2 Encryption

In the level-2 encryption phase, we analyse the confidentiality of the proxy re-encrypted data. In this phase, there are two cases, one for the intruder.Case 1: in the first case, the intruder wants to get the sensitive data. For this, he must know about the level-2 encryption receiver private key. An intruder can get the receiver’s private key by performing the following steps:Step 1: the intruder can get a level-2 encryption receiver private key if he computes equation (33). For this, the intruder needs to find the value of β, and it is not feasible due to the hyperelliptic curve discrete logarithm problem.Step 2: if in any way the intruder gets the value ofβ, then next it wants to find the value of ξ and η from equations (34) and (35). For this, the intruder needs to find the value of α and γ, and it is also not feasible due to the hyperelliptic curve discrete logarithm problem.


### 6.2. Integrity

Data integrity means the overall reliability, completeness, and accuracy of the data. This means that the recipient receives the same data which is sent by the sender, and we use the hash function to ensure integrity. The sender applies the hash function on each data block and then applies final hash on the concatenated hash value shown as follows.(36)MACk=HSHA−3Bk,where 1 ≤ k ≤ z, and(37)MACfinal=HSHA−3k=1zMACk,where 1 ≤ k ≤ z.If the attacker has made any changes in the ciphertext, then C is converted to C’, and after decrypting C’, we get the message M’, and the MAC value of M’ is not equal to MACfinal. So, we’ will find out if the ciphertext has changed. Therefore, our proposed scheme verifies the integrity of the data.


### 6.3. Replay Attack

In our scheme, every time the proxy server generates a Nonce value Nonce when it re-encrypts the blocks and attached this Nonce value to every block such asFILE=‖k=1zBk,Nonce. Nonce value Nonce is the identity of each block. The Nonce value is attached with each block to avoid the replay attack. If an intruder tries to send the previous block to the recipient, the recipient easily knows that it is the previous block, by the Nonce value, because the Nonce value is renewed in each session. In this regard, we can say that our scheme is safe from the replay attack.


## 6.1. Confidentiality

Data confidentiality means that sensitive data are protected from unauthorized users and blocks unauthorized users’ access to sensitive data.


### 6.1.1. Level-1 Encryption

In our method, if an intruder wants to steal our sensitive data, then he must know about the level-1 encryption sender private key. An intruder can get the sender’s private key by performing the following steps:Step 1: the intruder can get a level-1 encryption sender private key if he computes equation (33). For this, the intruder needs to find the value of β, and it is not feasible due to the hyperelliptic curve discrete logarithm problem:(33)KU=β⋅ξ−η.Step 2: if in any way the intruder gets the value ofβ, then next it wants to find the value of ξ and η from equations (34) and (35). For this, the intruder needs to find the value of α and γ, and it is also not feasible due to the hyperelliptic curve discrete logarithm problem. In fact, to get the level-1 encryption sender private key, the intruder will have to solve the hyperelliptic curve discrete logarithm problem three times, which is not feasible.(34)ξ=α⋅γ−α,(35)η=γ⋅β+γ.


### 6.1.2. Level-2 Encryption

In the level-2 encryption phase, we analyse the confidentiality of the proxy re-encrypted data. In this phase, there are two cases, one for the intruder.Case 1: in the first case, the intruder wants to get the sensitive data. For this, he must know about the level-2 encryption receiver private key. An intruder can get the receiver’s private key by performing the following steps:Step 1: the intruder can get a level-2 encryption receiver private key if he computes equation (33). For this, the intruder needs to find the value of β, and it is not feasible due to the hyperelliptic curve discrete logarithm problem.Step 2: if in any way the intruder gets the value ofβ, then next it wants to find the value of ξ and η from equations (34) and (35). For this, the intruder needs to find the value of α and γ, and it is also not feasible due to the hyperelliptic curve discrete logarithm problem.


## 6.1.1. Level-1 Encryption

In our method, if an intruder wants to steal our sensitive data, then he must know about the level-1 encryption sender private key. An intruder can get the sender’s private key by performing the following steps:Step 1: the intruder can get a level-1 encryption sender private key if he computes equation (33). For this, the intruder needs to find the value of β, and it is not feasible due to the hyperelliptic curve discrete logarithm problem:(33)KU=β⋅ξ−η.Step 2: if in any way the intruder gets the value ofβ, then next it wants to find the value of ξ and η from equations (34) and (35). For this, the intruder needs to find the value of α and γ, and it is also not feasible due to the hyperelliptic curve discrete logarithm problem. In fact, to get the level-1 encryption sender private key, the intruder will have to solve the hyperelliptic curve discrete logarithm problem three times, which is not feasible.(34)ξ=α⋅γ−α,(35)η=γ⋅β+γ.


## 6.1.2. Level-2 Encryption

In the level-2 encryption phase, we analyse the confidentiality of the proxy re-encrypted data. In this phase, there are two cases, one for the intruder.Case 1: in the first case, the intruder wants to get the sensitive data. For this, he must know about the level-2 encryption receiver private key. An intruder can get the receiver’s private key by performing the following steps:Step 1: the intruder can get a level-2 encryption receiver private key if he computes equation (33). For this, the intruder needs to find the value of β, and it is not feasible due to the hyperelliptic curve discrete logarithm problem.Step 2: if in any way the intruder gets the value ofβ, then next it wants to find the value of ξ and η from equations (34) and (35). For this, the intruder needs to find the value of α and γ, and it is also not feasible due to the hyperelliptic curve discrete logarithm problem.


## 6.2. Integrity

Data integrity means the overall reliability, completeness, and accuracy of the data. This means that the recipient receives the same data which is sent by the sender, and we use the hash function to ensure integrity. The sender applies the hash function on each data block and then applies final hash on the concatenated hash value shown as follows.(36)MACk=HSHA−3Bk,where 1 ≤ k ≤ z, and(37)MACfinal=HSHA−3k=1zMACk,where 1 ≤ k ≤ z.If the attacker has made any changes in the ciphertext, then C is converted to C’, and after decrypting C’, we get the message M’, and the MAC value of M’ is not equal to MACfinal. So, we’ will find out if the ciphertext has changed. Therefore, our proposed scheme verifies the integrity of the data.


## 6.3. Replay Attack

In our scheme, every time the proxy server generates a Nonce value Nonce when it re-encrypts the blocks and attached this Nonce value to every block such asFILE=‖k=1zBk,Nonce. Nonce value Nonce is the identity of each block. The Nonce value is attached with each block to avoid the replay attack. If an intruder tries to send the previous block to the recipient, the recipient easily knows that it is the previous block, by the Nonce value, because the Nonce value is renewed in each session. In this regard, we can say that our scheme is safe from the replay attack.


## 7. Experimental Results

Our scheme is evaluated on the bases of turnaround time for the different file size that is given in Table2. We have divided our file into eight blocks. Then, we performed four experiments on the given data set, and in the first experiment, we update only one block and compare the results with the previously proposed schemes by Guo et al. [51], Khan et al. [21], Khan et al. [56], and Bhatia et al. [64]. Proxy re-encryption scheme proposed in [51] does not use the incremental cryptographic technique; therefore, it encrypts, decrypts, and computes the hash value for a complete file from scratch. The schemes in [21, 56] use the bilinear paring technique which uses a 256-bit key, and [64] uses the elliptic curve technique with 160-bit key. Our certificate-based incremental proxy re-encryption scheme (CB-PReS) uses the hyperelliptic curve technique with 80-bit key.Table 2
Parameters for all scenarios.
File size in bytesTotal files51 20050102,40050153,60050204,80050256,00050


### 7.1. Case Scenario 1

In first case, we perform block modification operation in which we modify only one block of a file with different file sizes given in Table2, and then we compare our results with the previously proposed schemes [21, 51, 56, 64] based on the turnaround time while block deletion, block insertion, and block updation. We can evaluate the turnaround time as follows:(38)turn aroundtimeTT=trd+thash+ted,where trd represents the time that is required to read the file, thash represents the time that is required to compute the hash value, and ted represents the time that is required for encryption/decryption. Figure 5 shows the result in terms of turnaround time while modifying the block. The file size in bytes is shown along the x-axis with the total numbers of files, and the turnaround time is shown along the y-axis in milliseconds. In this experiment, every file is divided into eight blocks. The results of experiment 1 in Figure 5 clearly show that our scheme is more efficient as compared to the previously proposed schemes based on the turnaround time while block deletion, block insertion, and block updation.Figure 5
One block modification.


### 7.2. Case Scenario 2

In second case, we perform block modification operation in which we modify two blocks of a file with different file sizes, and then we compare the obtained results with the previously proposed schemes based on the turnaround time while block deletion, block insertion, and block updation. We can evaluate the turnaround time as shown in equation (38).The results of experiment 2 in Figure6 clearly shows that our scheme is more efficient as compared to the previously proposed schemes [21, 51, 56, 64] based on the turnaround time while block deletion, block insertion, and block updation.Figure 6
Two-block modification.


### 7.3. Case Scenario 3

In third case, three blocks are modified of a file with different file sizes, and then we compare the results with the previous proposed schemes. We can evaluate the turnaround time as shown in equation (38).The results of experiment 3 in Figure7 clearly shows that our scheme is more efficient as compared to the previous schemes.Figure 7
Three blocks modification.


### 7.4. Case Scenario 4

In fourth case, we update four blocks of a file with different sizes, and then we compare the results with the previously proposed schemes. We can evaluate the turnaround time as shown in equation (38).The results of experiment 4 in Figure8 clearly shows that our scheme is more efficient as compared to the previous proposed schemes.Figure 8
Four blocks modification.


## 7.1. Case Scenario 1

In first case, we perform block modification operation in which we modify only one block of a file with different file sizes given in Table2, and then we compare our results with the previously proposed schemes [21, 51, 56, 64] based on the turnaround time while block deletion, block insertion, and block updation. We can evaluate the turnaround time as follows:(38)turn aroundtimeTT=trd+thash+ted,where trd represents the time that is required to read the file, thash represents the time that is required to compute the hash value, and ted represents the time that is required for encryption/decryption. Figure 5 shows the result in terms of turnaround time while modifying the block. The file size in bytes is shown along the x-axis with the total numbers of files, and the turnaround time is shown along the y-axis in milliseconds. In this experiment, every file is divided into eight blocks. The results of experiment 1 in Figure 5 clearly show that our scheme is more efficient as compared to the previously proposed schemes based on the turnaround time while block deletion, block insertion, and block updation.Figure 5
One block modification.


## 7.2. Case Scenario 2

In second case, we perform block modification operation in which we modify two blocks of a file with different file sizes, and then we compare the obtained results with the previously proposed schemes based on the turnaround time while block deletion, block insertion, and block updation. We can evaluate the turnaround time as shown in equation (38).The results of experiment 2 in Figure6 clearly shows that our scheme is more efficient as compared to the previously proposed schemes [21, 51, 56, 64] based on the turnaround time while block deletion, block insertion, and block updation.Figure 6
Two-block modification.


## 7.3. Case Scenario 3

In third case, three blocks are modified of a file with different file sizes, and then we compare the results with the previous proposed schemes. We can evaluate the turnaround time as shown in equation (38).The results of experiment 3 in Figure7 clearly shows that our scheme is more efficient as compared to the previous schemes.Figure 7
Three blocks modification.


## 7.4. Case Scenario 4

In fourth case, we update four blocks of a file with different sizes, and then we compare the results with the previously proposed schemes. We can evaluate the turnaround time as shown in equation (38).The results of experiment 4 in Figure8 clearly shows that our scheme is more efficient as compared to the previous proposed schemes.Figure 8
Four blocks modification.


## 8. Performance Evaluation

In this phase, we compare our proposed scheme with the previously proposed schemes by Guo et al. [51], Khan et al. [21], Khan et al. [56], and Bhatia et al. [64] and then evaluate our scheme in terms of computation overhead of each block. All the specifications about hardware and software which we use to conduct the experiments are depicted in Table 3. For the development of the fog client application, we use iFogSim simulator [67]. The major operation, i.e., hyperelliptic curve divisor multiplication (HDM), cost is computed by using a GitHub library called libg2hec [68]. This library provides a divisor group operation in the Jacobian of genus 2 (imaginary) hyperelliptic curve. We need to install V. Shoup’s NTL library [69] before installing the G2HEC library. G2HEC library results have been tested with NTL 5.5 version on an x86_64 macOS big sur 11.4 operating system. The cost of the elliptic curve scalar multiplication (SM) operation is computed by using a standard cryptography library MIRACL [70] and bilinear paring modular exponential (MEXP), and bilinear paring operation (PBC) cost is computed by using the (pairing-based cryptography) library PBC [71]. PBC is built on the GMP library [72], and all the paring base mathematical operation such as bilinear paring modular exponential and pairing-based point multiplication are performed by using the GMP library. We can achieve 1024-bit RSA level security by using type A bilinear pairing over an elliptic curve with p = 512-bit prime and q = 160-bit prime number. We can also achieve the same level of security in ECC by using secp160r1 curve over a finite field Fq, and the equivalent level of security can also be achieved by using the genus two hyperelliptic curve over the finite field Fq with the following values |Fq |g. log2 q ≈ 280. To achieve the integrity of the data, we have used the SHA-3 algorithm, which is more resistant to collision and preimaging attacks than the previous SHA-2 algorithm.Table 3
Hardware and software specification.
Hardware and softwareSpecification/versionSystemMacBook pro-2015RAM16 GB 1600 MHz DDR3Processor2.2 GHz quad-core Intel Core i7Storage512 GBOSmacOS big sur 11.4ApplicationiFogSimiFogSim1.0libg2hec2.1NTL5.5MIRACL7.0.0PBC1.0GMP6.2.1


### 8.1. Computational Overhead

In this phase, we consider some major operations such as hyperelliptic curve divisor multiplication (HDM), elliptic curve scalar multiplication (SM), bilinear paring modular exponential (MEXP), and bilinear paring operation (PBC). The cost of the major operation in millisecond is given as follows: hyperelliptic curve divisor multiplication cost is 0.36 ms, elliptic curve scalar multiplication cost is 0.64 ms, bilinear paring modular exponential cost is 0.84 ms, and bilinear paring operation cost is 1.02 ms. It is clearly shown from the results that the hyperelliptic curve divisor multiplication cost is much lesser as compared to the remaining cryptographic major operations. Our proposed scheme uses hyperelliptic curve divisor multiplication operations. The cost of the all-cryptographic major operations is given in Figure9 and Table 4.Figure 9
Cryptographic major operation cost in millisecond.Table 4
Cryptographic major operation cost in millisecond.
Major operationsCost in millisecondsBilinear paring operation1.02Bilinear paring modular exponential0.84Elliptic curve scalar multiplication0.64Hyperelliptic curve divisor multiplication0.36Due to the use of hyperelliptic curve divisor multiplication, our proposed (CB-PRe) scheme shows significant improvement in the block(s) modification results compared to the previously proposed [21, 51, 56, 64] schemes. The result improvement depends on the number of block(s) modification operations. The comparison of result improvements between our proposed (CB-PRe) scheme and Guo et al.’s [51] scheme is given in Table 5; it shows that the average percentage turnaround time of our proposed (CB-PRe) scheme is 78.24% better than Guo et al.’s scheme while modifying one block, 70.47% better while the modification of two blocks, 62.73% better while modifying three blocks, and 54.54% better while the modification of four blocks. The computational overhead reduction formula is given as follows.(39)existingschemecost−proposedschemecostexistingschemecost∗100.Table 5
Result improvements of the proposed scheme in block(s) modification operations as compared to [51].
Number of blocks51200 × 50 (%)102400 × 50 (%)153600 × 50 (%)204800 × 50 (%)256000 × 50 (%)Average (%)175.5677.3578.679.5180.278.24269.6470.170.5270.8971.1870.47361.8962.2562.7463.0963.6962.73453.1253.6154.3555.4756.1654.54Table6 depicts the comparison of result improvements between our (CB-PRe) scheme and Khan et al.’s [21, 56] schemes. The average percentage turnaround time of our proposed scheme is 40.66% better than Khan et al.’s [21, 56] schemes, while modifying one block, 37.51% better while the modification of two blocks, 36.62% better while modifying three blocks, and 33.48% better while the modification of four blocks.Table 6
Result improvements of proposed scheme in block (s) modification operations as compared to [21, 56].
Number of blocks51200 × 50 (%)102400 × 50 (%)153600 × 50 (%)204800 × 50 (%)256000 × 50 (%)Average (%)138.8839.2240.4941.9842.7140.66236.0936.9137.4238.1239.0337.51334.9535.6136.2737.4138.8836.62431.0732.6233.8834.7335.1233.48The comparison of result improvements between our proposed scheme and Bhatia et al.’s [64] scheme is given in Table 7; it depicted that the average percentage turnaround time of our scheme is 25.67% better than Bhatia et al.’s scheme while modifying one block, 24.2% better while the modification of two blocks, 22.2% better while modifying three blocks, and 19.92% better while the modification of four blocks.Table 7
Result improvements of proposed scheme in block(s) modification operations as compared to [64].
Number of blocks51200 × 50 (%)102400 × 50 (%)153600 × 50 (%)204800 × 50 (%)256000 × 50 (%)Average (%)124.2125.0925.8726.3426.8325.67223.0123.6724.2224.7925.3124.2321.4721.8922.7822.5622.3122.2419.0919.7620.0120.4320.3219.92


### 8.2. Communication Overhead

In this section, we compared the communication cost of our scheme with the existing proposed schemes, i.e., Guo et al. [51], Khan et al. [21], Khan et al. [56], and Bhatia et al. [64]. Communication costs will increase if there are some extra bits with the original message. We suppose some terms as follows:(i)
|K | represents key size of bilinear pairing is equals to 256 bits, elliptic curve is 160 bits, and hyperelliptic curve is 80 bits(ii)
|M| represents ciphertext or plaintext size and equals 100 bits(iii)
MAC represents message digest size of hash function and equals 512 bits(iv)
CERT represents user certificate size and equals 256 bits in bilinear paring, 160 bits in elliptic curve, and 80 bits in hyper elliptic curve(v)
|B| block size is equal to 13 bits(vi)
RA⟶B re-encryption key size of bilinear pairing equals 256 bits, elliptic curve is 160 bits, and hyperelliptic curve is 80 bitsTable8 shows that our scheme is better than the existing related schemes, i.e., [21, 51, 56, 64] in terms of communication cost.Table 8
Communication cost in bits.
Guo et al. [51]2 (K) + 4 (M) + 4 (MAC) + 1 (RA⟶B)2 (256) + 4 (100) + 4 (512) + 1 (256) = 3216Khan et al. [21]2 (K) + 3 (M) + 4 (MAC) + 2 (B)2 (256) + 3 (100) + 4 (512) + 2 (13) = 2886Khan et al. [56]2 (K) + 2 (M) + 3 (MAC) + 1 (RA⟶B) + 2 (B)2 (256) + 2 (100) + 3 (512) + 1 (256) + 2 (13) = 2530Bhatia et al. [64]2 (K) + 2 (M  + 3 (MAC) + 1 (RA⟶B) + 2 (B)2 (160) + 2 (100) + 3 (512) + 1 (160) + 2 (13) = 2242Proposed methodK + 1 (CERT) + 2 (M) + 3 (MAC) + 1 (RA⟶B) + 2 (B)1 (80) + 1 (80) + 2 (100) + 3 (512) + 1 (80) + 2 (13) = 2002


### 8.3. Communication Cost Reduction

The communication cost reduction of our scheme from the existing schemes can be calculated by the following formula:(40)existingschemecost−proposedschemecostexistingschemecost∗100.Reduction from Guo et al.’s study [51] is(41)3216−20023216∗100=37.75%.Reduction from Khan et al.’s study [21] is(42)2886−20022886∗100=30.63%.Reduction from Khan et al.’s study [56] is(43)2530−20022530∗100=20.86%.Reduction from Bhatia et al.’s study [64] is(44)2242−20022242∗100=9.10%.


## 8.1. Computational Overhead

In this phase, we consider some major operations such as hyperelliptic curve divisor multiplication (HDM), elliptic curve scalar multiplication (SM), bilinear paring modular exponential (MEXP), and bilinear paring operation (PBC). The cost of the major operation in millisecond is given as follows: hyperelliptic curve divisor multiplication cost is 0.36 ms, elliptic curve scalar multiplication cost is 0.64 ms, bilinear paring modular exponential cost is 0.84 ms, and bilinear paring operation cost is 1.02 ms. It is clearly shown from the results that the hyperelliptic curve divisor multiplication cost is much lesser as compared to the remaining cryptographic major operations. Our proposed scheme uses hyperelliptic curve divisor multiplication operations. The cost of the all-cryptographic major operations is given in Figure9 and Table 4.Figure 9
Cryptographic major operation cost in millisecond.Table 4
Cryptographic major operation cost in millisecond.
Major operationsCost in millisecondsBilinear paring operation1.02Bilinear paring modular exponential0.84Elliptic curve scalar multiplication0.64Hyperelliptic curve divisor multiplication0.36Due to the use of hyperelliptic curve divisor multiplication, our proposed (CB-PRe) scheme shows significant improvement in the block(s) modification results compared to the previously proposed [21, 51, 56, 64] schemes. The result improvement depends on the number of block(s) modification operations. The comparison of result improvements between our proposed (CB-PRe) scheme and Guo et al.’s [51] scheme is given in Table 5; it shows that the average percentage turnaround time of our proposed (CB-PRe) scheme is 78.24% better than Guo et al.’s scheme while modifying one block, 70.47% better while the modification of two blocks, 62.73% better while modifying three blocks, and 54.54% better while the modification of four blocks. The computational overhead reduction formula is given as follows.(39)existingschemecost−proposedschemecostexistingschemecost∗100.Table 5
Result improvements of the proposed scheme in block(s) modification operations as compared to [51].
Number of blocks51200 × 50 (%)102400 × 50 (%)153600 × 50 (%)204800 × 50 (%)256000 × 50 (%)Average (%)175.5677.3578.679.5180.278.24269.6470.170.5270.8971.1870.47361.8962.2562.7463.0963.6962.73453.1253.6154.3555.4756.1654.54Table6 depicts the comparison of result improvements between our (CB-PRe) scheme and Khan et al.’s [21, 56] schemes. The average percentage turnaround time of our proposed scheme is 40.66% better than Khan et al.’s [21, 56] schemes, while modifying one block, 37.51% better while the modification of two blocks, 36.62% better while modifying three blocks, and 33.48% better while the modification of four blocks.Table 6
Result improvements of proposed scheme in block (s) modification operations as compared to [21, 56].
Number of blocks51200 × 50 (%)102400 × 50 (%)153600 × 50 (%)204800 × 50 (%)256000 × 50 (%)Average (%)138.8839.2240.4941.9842.7140.66236.0936.9137.4238.1239.0337.51334.9535.6136.2737.4138.8836.62431.0732.6233.8834.7335.1233.48The comparison of result improvements between our proposed scheme and Bhatia et al.’s [64] scheme is given in Table 7; it depicted that the average percentage turnaround time of our scheme is 25.67% better than Bhatia et al.’s scheme while modifying one block, 24.2% better while the modification of two blocks, 22.2% better while modifying three blocks, and 19.92% better while the modification of four blocks.Table 7
Result improvements of proposed scheme in block(s) modification operations as compared to [64].
Number of blocks51200 × 50 (%)102400 × 50 (%)153600 × 50 (%)204800 × 50 (%)256000 × 50 (%)Average (%)124.2125.0925.8726.3426.8325.67223.0123.6724.2224.7925.3124.2321.4721.8922.7822.5622.3122.2419.0919.7620.0120.4320.3219.92


## 8.2. Communication Overhead

In this section, we compared the communication cost of our scheme with the existing proposed schemes, i.e., Guo et al. [51], Khan et al. [21], Khan et al. [56], and Bhatia et al. [64]. Communication costs will increase if there are some extra bits with the original message. We suppose some terms as follows:(i)
|K | represents key size of bilinear pairing is equals to 256 bits, elliptic curve is 160 bits, and hyperelliptic curve is 80 bits(ii)
|M| represents ciphertext or plaintext size and equals 100 bits(iii)
MAC represents message digest size of hash function and equals 512 bits(iv)
CERT represents user certificate size and equals 256 bits in bilinear paring, 160 bits in elliptic curve, and 80 bits in hyper elliptic curve(v)
|B| block size is equal to 13 bits(vi)
RA⟶B re-encryption key size of bilinear pairing equals 256 bits, elliptic curve is 160 bits, and hyperelliptic curve is 80 bitsTable8 shows that our scheme is better than the existing related schemes, i.e., [21, 51, 56, 64] in terms of communication cost.Table 8
Communication cost in bits.
Guo et al. [51]2 (K) + 4 (M) + 4 (MAC) + 1 (RA⟶B)2 (256) + 4 (100) + 4 (512) + 1 (256) = 3216Khan et al. [21]2 (K) + 3 (M) + 4 (MAC) + 2 (B)2 (256) + 3 (100) + 4 (512) + 2 (13) = 2886Khan et al. [56]2 (K) + 2 (M) + 3 (MAC) + 1 (RA⟶B) + 2 (B)2 (256) + 2 (100) + 3 (512) + 1 (256) + 2 (13) = 2530Bhatia et al. [64]2 (K) + 2 (M  + 3 (MAC) + 1 (RA⟶B) + 2 (B)2 (160) + 2 (100) + 3 (512) + 1 (160) + 2 (13) = 2242Proposed methodK + 1 (CERT) + 2 (M) + 3 (MAC) + 1 (RA⟶B) + 2 (B)1 (80) + 1 (80) + 2 (100) + 3 (512) + 1 (80) + 2 (13) = 2002


## 8.3. Communication Cost Reduction

The communication cost reduction of our scheme from the existing schemes can be calculated by the following formula:(40)existingschemecost−proposedschemecostexistingschemecost∗100.Reduction from Guo et al.’s study [51] is(41)3216−20023216∗100=37.75%.Reduction from Khan et al.’s study [21] is(42)2886−20022886∗100=30.63%.Reduction from Khan et al.’s study [56] is(43)2530−20022530∗100=20.86%.Reduction from Bhatia et al.’s study [64] is(44)2242−20022242∗100=9.10%.


## 9. Conclusion

Secure EHR storage and sharing is a serious issue while using the cloud infrastructure. In certificateless cryptography, we cannot verify the public key of any user that is the major drawback of the certificateless cryptographic schemes. In this paper, we have proposed a lightweight certificate-based incremental proxy re-encryption for e-healthcare data sharing scheme in fog computing. In certificate-based schemes every user can verify the public key of other users. Recently proposed I-PRE schemes involve expensive bilinear pairing and elliptic curve operation which uses 256-bit key and 160-bit key, respectively. In this scheme, we use the hyperelliptic curve technique with 80-bit key and compare the block modification results on the basis of turnaround time with the previously proposed I-PRE schemes. Results clearly show that our scheme is more efficient as compared to the previously proposed schemes. Our scheme also provides data integrity and confidentiality and deals with the latency problem by using the fog computing paradigms. To reduce the overhead of resource constraints IoT devices, complex and resource-intensive cryptographic functions are offloaded on fog nodes. In the future, we will develop a group-based scheme that will be useful for multiple users.



---

*Source: 9363824-2021-11-19.xml*