A Novel Blockchain-Based Encryption Model to Protect Fog Nodes from Behaviors of Malicious Nodes

Abstract

The world has experienced a huge advancement in computing technology. People prefer outsourcing their confidential data for storage and processing in cloud computing because of the auspicious services provided by cloud service providers. As promising as this paradigm is, it creates issues, including everything from data security to time latency with data computation and delivery to end-users. In response to these challenges, the fog computing paradigm was proposed as an extension of cloud computing to overcome the time latency and communication overhead and to bring computing and storage resources close to both the ground and the end-users. However, fog computing inherits the same security and privacy challenges encountered by traditional cloud computing. This paper proposed a fine-grained data access control approach by integrating the ciphertext policy attribute-based encryption (CP-ABE) algorithm and blockchain technology to secure end-users’ data security against rogue fog nodes in case a compromised fog node is ousted. In this approach, we proposed federations of fog nodes that share the same attributes, such as services and locations. The fog federation concept minimizes the time latency and communication overhead between fog nodes and cloud servers. Furthermore, the blockchain idea and the CP-ABE algorithm integration allow for fog nodes within the same fog federation to conduct a distributed authorization process. Besides that, to address time latency and communication overhead issues, we equip each fog node with an off-chain database to store the most frequently accessed data files for a particular time, as well as an on-chain access control policies table (on-chain files tracking table) that must be protected from tampering by rogue fog nodes. As a result, the blockchain plays a critical role here because it is tamper-proof by nature. We assess our approach’s efficiency and feasibility by conducting a simulation and analyzing its security and performance.

1. Introduction

Cloud computing is a thriving paradigm due to the enormous on-demand services to end-users over the internet. Cloud computing has provided customers with innovative features, such as availability, scalability, and economy, that help to satisfy the substantial demand for storage and computation resources [1]. End-users outsource their data to the core network on the cloud for processing and storage. However, there are many obstacles facing data owners. First, the response time between users and the cloud is high because the data are stored far away from the data owners. Second, the end-users’ data security and privacy are susceptible to violation because the semi-trusted third party controls the cloud. The research community has studied data security and privacy issues in cloud computing by adopting and applying advanced cryptographic techniques, as described in [2,3,4,5,6]. However, the demand to invent a new technology to resolve the cloud latency issue is still present [7,8].

Fog computing was introduced in 2012 [9] to reduce the time latency between the cloud and end-users’ devices [7,8] and to provide new services and applications to end-users. The fog computing paradigm is where small clouds are deployed close to end-user’s devices, which allows for customers to utilize the computing and storage services at the edge of the network [9]. More specifically, fog computing comprises multiple fog nodes that provide services to end-users [10]. The fog computing paradigm has supported end devices with distinguishing features, such as mobility, location awareness, and a low time latency [11]. Due to the fact that fog computing is deemed to be an extension of the cloud computing paradigm, it inherits some of the security and privacy obstacles in cloud computing [12]. In particular, a fog computing paradigm is susceptible to different threats, such as malicious attacks and technical issues. In this context, the end-users’ data traveling through fog computing nodes to the cloud is vulnerable to different violations, such as data integrity violation [13]. Therefore, it is necessary to design an approach to protect end-users’ data confidentiality, availability, and integrity by ousting the rogue fog nodes. One reason for these vulnerabilities is that end-users outsource sensitive data to the nearby fog node for processing, and then to the cloud for further processing and storage. Due to the fact this fog node is seen as a connector between end-users and the cloud, it is challenging to protect other fog nodes and the cloud from malicious attacks. End-users’ data security is difficult to defend if the fog node providing services in terms of storage and computation is compromised or goes rogue. We have been motivated by these issues to protect customers’ private data from being compromised. Furthermore, a method to secure communication among fog nodes is required in order to exchange encrypted data to reduce the time latency to retrieve it from the far cloud.

In general, threats in the context of fog computing take two forms. (1) Data modification: if an adversary obtains hands-on end-users’ private data, they might violate their confidentiality and integrity. Therefore, introducing a security approach is necessary to prevent data confidentiality and integrity violation among fog nodes, and between fog nodes and the cloud. (2) Unauthorized access: when an adversary compromises a fog node, they can obtain unauthorized access to the end-users’ private data. Besides, data availability is in danger of malicious violation in this way. Therefore, it is essential to introduce a security approach to protect against rogue fog nodes and oust them off the network while maintaining the low latency feature fog computing provides. Additionally, it is vital to enable the fog nodes to carry on a distributed authorization process and communicate in a trust-less environment.

Attribute-based encryption (ABE) is a cryptographic primitive that enables one-to-many encryption. It comprises two types: ciphertext policy attribute-based encryption (CP-ABE) [14] and key policy attribute-based encryption (KP-ABE) [15]. CP-ABE was introduced by Bethencourt et al. [14], and is deemed as one of the most significant algorithms to provide fine-grained data access control.

Blockchain has attracted the attention of researchers since it was introduced in late 2008 [16]. Blockchain is a shared distributed ledger, which is secured, immutable, and transparent, that helps in processing and tracking resources without depending on a centralized trusted third party [17]. With this promising technology, peer-to-peer nodes can communicate and exchange resources where the decision is carried on in a distributed manner by the majority of the network’s nodes rather than a single centralized trusted third party.

The use of blockchain technology offers a variety of potential applications in the struggle against malicious behavior. It may be used to optimize cloud data storage and perform as a reliable data tracker. In this study, we concentrate on the data tracking application, since the blockchain enables data collection and reporting to be both trustworthy and traceable. To avoid the spread of new malicious behaviors, it is critical to establish a blockchain platform that can track and trace data packet movement.

Table 1. A comparison of using a centralized platform against a blockchain platform.

Characteristics	Traditional Platforms		Blockchain Platforms
Authority	The administrator is in charge (centralized)	×	Distributed even in private blockchains (decentralized)	✓
Data management	Read, delete, create, and update operations supported.	×	Only read and write operations are offered.	✓
Data integrity	Information can be manipulated	×	Information is unchangeable and verifiable.	✓
Data privacy	High probabilities of malevolent intrusion attacks.	×	Low probabilities of malevolent intrusion attacks due to cryptographic technology.	✓
Fault tolerance	High possibility of failure of single point.	×	Low possibility of failure of single point because distributed ledger is fault-tolerant.	✓
Quality assurance	Administrator must authenticate the data (data attribution not applicable)	×	The origin of data can be tracked and traced.	✓
Transparency	Databases do not have any transparency.	×	Data are stored in a network that is distributed.	✓
Performance	Fast (many operations completed per second) and scalable.	✓	Can only process a few transactions per second, and scalability is a problem because the blockchain is still in its early stages.	×
Cost	Because it is an old technology, it is simple to implement and maintain.	✓	Costs of operation and maintenance are uncertain.	×

highlights the advantages of using a blockchain-based system over a traditional unified platform in a variety of areas, including data processing, reliability, and performance assessment.

In terms of data transmission and trust processing, blockchains can enhance and influence the efficiency of an intrusion detection system. Blockchain technology, on the other hand, is a technology with certain drawbacks, such as a high energy consumption and computational capabilities. The absence of security and privacy in blockchain applications has been highlighted. As a result, it is a desirable target for cyber-criminals. It is exposed to various assaults, such as the distributed denial of service attacks and excessive delay in transaction completion, which create a great deal of uncertainty for transaction participants. Through smart contracts, blockchain technology provides a decentralized consensus and expands the contractual area. As a result of this scenario, it becomes necessary to secure smart contract access security and privacy and a certification of trust information creation [18,19].

In [20], authors proposed an approach to oust rogue (malicious) fog nodes and to minimize the communication overhead between the cloud service provider (CSP) and fog nodes (FNs) by integrating the CP-ABE algorithm and blockchain technology. Blockchain is adopted as a medium to store on-chain tracking tables to verify the identity of each fog node using the smart contract before they can access the encrypted data on the CSP. The blockchain immutability feature prevents fog nodes from maliciously changing the on-chain tracking table; if such a change is detected, the FN that issues the request is reported as a rogue fog node. This paper extends the previous work in [20]. Furthermore, this paper provides a modification on the system approach in [20].

The rest of this paper is organized as follows: Section 2 reviews the literature. Section 3 articulates the motivations and contributions of this research. Section 4 states the preliminaries required to accomplish this research. Section 5 and Section 6 explain, in detail, the proposed approach, assumptions, and the designed algorithms. In Section 7, we provide the performance evaluation and security analysis of our proposed approach. After that, we provide a discussion and the expected applications of this approach in Section 8 and Section 9. Finally, we conclude this paper in Section 10.

2. Literature Review

The main objectives of this paper are to propose a new approach to allow fog nodes (FNs) to communicate in a trust-less environment in order to maintain end-users’ data security and to reduce the time latency and communication overhead between the CSP and the FNs by adopting and integrating the CP-ABE and blockchain. Therefore, we summarize the overview of any related state-of-the-art works in this section with a brief literature review about access control, rogue fog nodes, and fog nodes communication.

Table 2. Symbols and definitions.

Symbol	Definition
FN	Fog Node
FF	Fog Federation
EF	Encrypted File
FFPK	Fog Federation Public Key
FFMK	Fog Federation Master Key
FNSK	Fog Node Secret Key
SK	Secret Key
SS	Shared Storage
TAS	Trusted Authority Server
SC	Smart Contract
IPFS	Inter-Planetary File System
SMK	System Master Key
SPK	System Public Key
USAT	Universal Set of Attributes
FFL	Fog Federation List
FF${}_{ID}$	Fog Federation Identification
ABE	Attribute-Based Encryption
CP-ABE	Ciphertext Policy Attribute-Based Encryption
KP-ABE	Key Policy Attribute-Based Encryption
TAN	Trusted Authority Node
CSP	Cloud Service Provider
MITM	Man-in-the-Middle Attack

presents the notations and symbols used in this paper and their definition.

2.1. Access Control

Sahai et al. [21] proposed an ABE scheme that uses the identity-based encryption algorithm [22]. Its two variants are the KP-ABE and CP-ABE [14,15]. ABE encryption and decryption processes are based on users’ attributes, so the scheme was first adopted in cloud computing to help data owners overcome obstacles such as data security and data access control when outsourcing data to the cloud.

The concept of access control has been well researched in cloud computing, but more investigations into fog computing are still needed. Recently, the research community has studied access control issues in this area and has started to adopt ABE in the environment, with the objective of providing fine-grained data access control and guaranteeing data security.

ABE has been applied to internet of things (IoT) devices to resolve data access control issues. Yu et al. [10] presented the fine-grained data access control issues arising in a wireless server network, proposing an FDAC scheme in which each sensor node was assigned a set of attributes and each user was assigned an access structure to specify access rights.

Huang et al. [23] proposed a CP-ABE scheme to support data security and fine-grained data access control, using features such as ciphertext updating and computation outsourcing for fog computing with IoT devices. As Zuo et al. [24] also found, their scheme’s main problem is that it was only suitable with an AND-gate encryption predicate. Xiao et al. [25] proposed a hybrid fine-grained search and access authorization scheme for fog computing, based on a CP-ABE cryptographic primitive. Their scheme was a hybrid, as it supported both index encryption and data encryption. This, too, however, supported only AND-gate predicates. Mao et al. [26] proposed the construction of a CPA-secure and RCCA-secure scheme; it was based on an ABE approach with the possibility of outsourced encryption verification. Dsouza et al. [27] proposed a scheme to support secure data sharing and communication in fog computing. This scheme is no more than a policy management framework, as it lacks details on building the policy repository and users’ identities, as well as on making decisions and protecting users’ identities and data privacy. Stojmenovic et al. [11] studied authorization and authentication issues among fog devices and between the fog and cloud. They based their study on the ABE algorithm and argued that end-users could still be authenticated and authorized to fog devices even in the presence of a vulnerable connection between the fog and the cloud. Li et al. [28] proposed a approach to collect smart devices’ attributes as dynamic attributes, incorporating them with the ABE algorithm to verify the access authority in real time. Mollah et al. [29] proposed a lightweight cryptographic approach to provide access control and data sharing; in this approach, all security operations are offloaded to nearby fog servers.

2.2. Rogue Fog Nodes

A rogue fog node is a fog node that pretends to be legitimate, deceiving end devices, other fog nodes, or the cloud into communicating with it. Its malicious hidden intent is to violate owners’ data security and privacy. Having compromised a fog node, an attacker can violate the security and privacy of end-users’ data in transit to the cloud through the fog nodes. The research community has not broadly addressed this problem.

Stojmenovic et al. [30] proposed a scheme to show the feasibility of a man-in-the-middle attack in which the gateway is either being compromised or substituted by a fake. Han et al. [31] proposed a measurement-based scheme to help users to avoid connecting to fake access points. Their scheme discovers the rogue AP by calculating the round-trip time between end-users and the DNS server. Mohammed et al. [32] proposed an encryption-based approach to protect fog computing from rogue fog nodes based on the CP-ABE algorithm. In this scheme, fog nodes cannot exchange data unless they fully trust each other. Therefore, letting the fog nodes carry out a distributed authorization process is an outstanding idea.

2.3. Communication among Fog Nodes

Arwa et al. [33] proposed an attribute-based encryption scheme to maintain fog communication security. Designed to provide authentic confidential communications among a group of fog nodes, it made use of a key-exchange protocol based on the CP-ABE algorithm. The researchers have not widely addressed this issue.

Recently, researchers have started using blockchains to develop secure applications, benefiting customers in various fields. Christidis et al. [34] summarized the blockchain use cases built into the IoT. They reviewed the integration of a blockchain smart contract into the IoT. Kamanashis et al. [35] proposed a multi-layered security scheme to create a secure communication platform in smart cities by integrating blockchains with smart devices. Researchers use the blockchain as a distributed database to store heterogeneous data related to the smart city, such as traffic and the location. These data need to be shared among smart cities’ components. The main issues dealt with by this scheme are scalability and reliability in smart cities. In [36], authors proposed a blockchain-based scheme consisting of distributed data storage in order to enable data sharing in IoT environments. The aim of using blockchains was to enable data access control and data storage. In their scheme, the authors separated data store from data management, then used blockchains to verify the separation and to decentralize the access control.

The fog computing layer occupies the middle ground between cloud servers and end-users’ devices and is, therefore, more susceptible to an attack than other layers. Data owners can find their data damaged or leaked by a rogue fog node. Since one of the primary fog computing features is to increase the network reliability, fog nodes need a protection method against malicious attacks. Protecting the nodes will defend the data owners’ security and privacy.

Based on surveying the literature, no previous schemes have addressed the proposed issues in the way this approach did. Therefore, there is no scheme to compare our approach against in terms of performance efficiency. However, we have compared our proposed approach against current schemes in the literature in terms of security features in Section 8.

3. Motivation and Contributions

3.1. Motivation

Fog computing provides multiple crucial services to end-users, such as music, adults’ entertainment, kids’ entertainment, emergency vehicle response, and health data collection at a low latency time [9]. Although fog computing provides great services, it is susceptible to many security issues. Malfunctioning fog nodes can violate individuals’ and organizations’ security and privacy. Therefore, it is essential to protect individuals’ and organizations’ security against any types of malicious entities, such as rogue fog nodes. The approach provided in this paper was motivated by the idea of protecting customers’ data security from the behaviour of rogue fog nodes.

For example, in the health care sector, healthcare providers outsource patients’ sensitive data to the close FN for processing and then upload it to the cloud for permanent storage. In the future, suppose the FN responsible for these data are compromised; this FN could breach these end-users’ data to attackers. Moreover, end-users would not be able to access their original data, as the FN in charge of providing this service is comprised. Hence, users need to be forwarded to another trusted fog node for data retrieving from the cloud.

This paper focuses on preventing the security threats where rogue fog nodes cause the system to breach both end-users encrypted data and the time latency to delivering the data from the cloud to the fog node. Moreover, we leverage blockchain technology to enable fog nodes to provide authorization in a distributed manner. Thus, we argue that this would help in recognizing rogue fog nodes. Specifically, an adversary can either take over the fog node or intercept data flown from the fog nodes to the cloud and vice versa. Based on the literature review, no previous scheme has addressed the issue of protecting the fog nodes from rogue nodes by combining cryptographic primitives, such as CP-ABE, with the blockchain. Hence, there is a need for an efficient and secure approach that considers these security challenges and time latency.

3.2. Our Contributions

To the best of our knowledge, no previous work has adopted and integrated the blockchain technology with the CP-ABE algorithm to form a fog federation (FF) and to address the problem of rogue fog nodes in fog computing. Based on [14,17], we proposed a secure approach in [20] in the context of fog computing, and, in this paper, we extend our proposed approach to provide the following features: (1) to detect and prevent rogue fog nodes from violating end-users’ data confidentiality and, besides, to minimize the communication overhead between the cloud server and the fog nodes; (2) to enable the fog nodes to communicate in a trust-less environment; (3) to enable the fog nodes to perform the authorization process in a distributed manner; (4) to maximize end-users’ data availability; (5) to extend [20] by providing detailed algorithms and simulation parts to prove our approach feasibility; (6) to focuses on the communication among fog nodes and between fog nodes and the cloud. We assume that the medium between the end-users’ devices and the fog nodes is secured for now.

4. Preliminaries

In this section, we reviewed the literature of the cryptographic and technological primitives we exploited in this paper.

4.1. Attribute-Based Encryption (ABE) Algorithms

We start with the ABE scheme, as we adopted the CP-ABE algorithm in our approach.

ABE was introduced by Sahai and Wates in 2005 as an amendment of the identity-based encryption [22] scheme. In this scheme, every user who accesses the system has a set of attributes assigned to them. This scheme aims to support users and owners in sharing or distributing confidential data with others depending on the access policies they provide. Encryption is usually undertaken depending on the receivers’ attributes, which makes ABE algorithms broadly applied to perform multiple encryption processes.

According to Hohenberger and Waters [37], ABE, guided by available users’ attributes, allows for users to encrypt and decrypt messages. ABE is one of the cryptographic schemes that ensure fine-grain data access control in cloud computing. One of those ABE schemes is CP-ABE. The ABE is an advanced cryptographic primitive that can be utilized to run multiple encryption systems. In ABE systems, the ciphertext can be encrypted to multiple recipients depending on the predefined attributes of the recipients [14]. In this cryptographic system, for example, ABE, the private keys assigned to users, and ciphertext are related to a predefined formation of attributes or an arrangement of policies over attributes [38]. Users that fulfill the attributes associated with the ciphertext have the right to access the ciphertext.

There are two variants of the ABE system: ciphertext policy attribute-based encryption (CP-ABE) [14] and key policy attribute-based encryption (KP-ABE) [15]. The CP-ABE variant has been further explored and described below.

4.1.1. Bilinear Mapping

As described in [22], let $G_1$ and $G_2$ be cyclic mathematical groups, multiplicative, of large prime order p, with g as a generator. Furthermore, let e be a bilinear map: $e:G_{1}X{G}_1\to G_2$, such that $G_2$ is the output space of the bilinear mapping. Therefore, bilinear map e must comply with the following conditions:

• Bi-linearity: ∀$u,vs.\in G_1,e(u^a,v^b)=e{(u,b)}^{ab}$ where $a,b$ ∈ $Z_p^{*}$;
• Non-degeneracy: No pair in $e:G_{1}X{G}_1$ is mapped to the element of identity;
• Computability: This means that the bilinear map $e(u,v)$ must be efficiently computable.

4.1.2. Access Structure

With reference to [39], let the set $\{P_1,P_2,\dots ,P_n\}$ be a set of parties. We can say that collection {A} $\subseteq 2^{(P_1,P_2,\cdots ,P_n)}$ is monotone if ∀$B\in A$, and if $B\subseteq C$ then $C\in A$. In this scenario, the collection A of the non-empty subsets of $\{P_1,P_2,\dots ,P_n\}$ is considered as a monotone access structure. ∀ sets $\in A$, they can be referred to as authorized sets, whereas the parties $\notin A$ are the unauthorized parties. As this is the same as provided in [14], our approach also represent the parties with attributes; all fog nodes with the same attributes will produce a FF. Therefore, as described further in Section 5.1, the fog nodes with similar attributes were categorized into fog federation subgroups.

4.1.3. CipherText-Policy Attribute Based Encryption (CP-ABE)

Ciphertext-policy attribute-based encryption is a system that provides complex access control on data to limit compromising of the data in the cloud storage. In CP-ABE, users’ private keys are linked with a set of attributes, whereas ciphertext is linked with an access structure constructed over the predefined attributes. Encryption occurs depending on the credentials described by users; therefore, users are identified using their specified attributes, making it hard for malicious users whose attributes are not described to access data. Therefore, users are unable to gain access to encrypted data unless their attributes mathematically align with the access structure. CP-ABE fundamentally comprises four algorithms:

• Setup: It takes a security parameter as an input to produce a public key and a master key $(PK,MK)$;
• Encrypt: The inputs are described as attributes, public parameters, and the message, whereas its outputs are ciphertext $CT$. No user can decrypt $CT$ unless their inputted attributes fulfill the requirements of the access structure A in the policy. The ciphertext implicitly contains A;
• KeyGen: In this algorithm, the inputs comprise the master key and a set ‘S’, a block of attributes that are descriptive of the key. A private secret key (SK) is generated;
• Decrypt: It takes the public parameters $PK$, the Ciphertext $CT$, and the private key as inputs. The output is the message (e.g., plaintext) generated if the inputted user attributes meet the requirements of the access structure A attached to $CT$.

4.2. Blockchain Technology

Blockchain technology has shown a promising and flourishing future for applications, especially for recording data such as transactions. The history of the blockchain shows that many non-financial applications are adopting it besides the cryptocurrency [40]. For example, blockchains have been used in healthcare, agriculture, the food industry, and many other applications. A blockchain fundamentally allocates a record database for all transactions implemented and shared among contributing parties [41]. Every transaction in the public register is substantiated by the consensus favored by the majority of the parties in the system. When information is entered and proofed, it cannot be erased or changed. Blockchain has been developed to be a widely available infrastructure for the expansion of decentralized applications. Those applications constructed on the blockchain can attain components such as immutability, integrity, transparency, and non-repudiation [17].

Smart Contract

Blockchain assists users in applying parts of software, usually known as smart contracts. The blockchain technology comprises three generations that enhance their operations and include: money transaction, assets, and a smart contract. Blockchain was first published by Satoshi Nakamoto [16], but, at that time, it was focused on money transactions only. Thereafter, it began focusing on exchanging assets among different parties [42]. Blockchain has been enhanced by introducing the smart contract concept [43]. These pieces of software are usually seen by everyone in the network, as described in [43], and must be controlled by the network parties.

Smart contracts work through a self-execution of contracts, whereby users use codes on their contracts that are found on a blockchain [44]. Through smart contracts, transactions are made safe for users, such as in banks, through their applications. Smart contracts, therefore, store valuable data safely and can be retrieved. However, the issue of security is present due to the fact that most blockchain systems are in the public domain; therefore, it is susceptible to malicious attacks [44]. In this paper, we adopted the smart contract concept. For further reading about blockchains and smart contracts, read through [45,46].

4.3. Fog Computing Services and Characteristics

This subsection summarizes fog computing services and the associated characteristics for organizations and individual users.

4.3.1. Services

Due to the significant distance between the cloud data center and the end-users’ devices, cloud computing suffers from end-to-end delay, traffic congestion, and communication overheads [47]. Cloud computing cannot be used for activities such as real-time activities, e.g., gaming; therefore, fog computing becomes relevant. Fog computing gets its name from fog, which is a cloud that is usually located near the ground. It is applied in smart home applications, which are becoming more common, especially when a wide variety of services are needed in one application, such as home security systems, which involve numerous aspects, such as alarms, cameras and recorders, motion sensors, and aspects such as key-in-lock systems or even face recognition sensors. Fog computing also provides services in data management, especially in the healthcare industry [48]. This is because of the sensitivity that surrounds medical records and related data. Each provider, therefore, will possess a fog node that has medical data for that specific patient, and this can be stored in a smartphone.

4.3.2. Characteristics

Fog computing was formerly initiated by CISCO to provide the following characteristics [9,49]:

• Supports end-users’ devices mobility;
• Real-time applications rather than group processing to ensure timely service;
• Low time latency between the far cloud providers and end-users. Latency in the form of execution time, offloading time for a task, and the speed of decision making;
• Provides location awareness and distribution.

Due to immense support from big information technology companies, such as CISCO, Dell, Microsoft Corp., Cloudlet, and Intelligent Edge, fog computing has a promising future.

4.4. Idea behind Using Blockchain as Fog Federation

This paper exploited the Ethereum blockchain smart contract as an intermediary among FNs that belong to the same FF. We constructed each FF as a private blockchain in which the FF’s members can perform an authorization process in a distributed manner using the smart contract (SC) concept. In addition, this approach deploys the on-chain tracking table (see

Table 3. On-chain tracking table.

IPFS Index	FN${}_{\mathit{ID}}$	EF${}_{\mathit{ID}}$	FN${}_{\mathit{sign}-\mathit{att}}$	FFPK	Attributes Set	Encrypted(SK)	File Hash	Off-Chain Database
0x64EC...	FN${}_1$	EF${}_1$	6*R!@MN	fNJk3u	Movies and CL	!!@3DSx	*EFC!...	EF${}_3$
0x7B502...	FN${}_2$	EF${}_3$	5*R*!WE	KLJk3J@	Health and AR	@@!!NB4	MNC!...	0
	...	...	...	...	...	...	...	...
07x0B62...	FN${}_n$	EF${}_7$	9TR!!NQ	@3EFJJL@	Education and AR	ms!!uB*	!67jK*...	0

), which has to be protected from being tampered with by rogue FNs. This is attributed to the tamper-proof nature of blockchain technology. Therefore, this was the main reason for exploiting the concept of blockchain technology. Furthermore, this table is used, as an access control table smart contract is used to verify the FN (requestor) identity in order to return the stored encrypted file credentials to the FN to retrieve the file from the inter-planetary file system (IPFS).

Our approach allows for the fog node that originates from the encrypted data to encrypt it only to the other FNs in the same FF. This approach precisely detects and blocks malicious/rogue FNs from retrieving encrypted data either from the shared storage (SS) or from other FF members (FN).

This approach must efficiently achieve the approach security objectives in the sense that the consumption gas that takes a smart contract to perform the approach’s functions should be affordable to FNs. One of the essential features of this approach is detecting and ousting the rogue fog nodes, which would positively improve the security of encrypted data stored in the shared storage.

4.5. A Blockchain-Encryption-Based Approach Objectives

This subsection presents the main objectives of our proposed approach:

4.5.1. Confidentiality

The blockchain-encryption-based approach provides data confidentiality to the data stored in the SS. This approach integrates the CP-ABE algorithm with the Ethereum blockchain smart contract to reach the maximum level of protecting the confidential data. This approach assures data confidentiality by enabling the FN to encrypt data to the FF it belongs to, and, in the meantime, no FN can access this encrypted data unless being proofed by the smart contract. The FN (data encryptor) generates a random secret key to encrypt the file. Then, it uploads the encrypted file (EF) to the SS for storage. The SS returns the index-hash of the file to the FN (file owner). Then, the FN encrypts the SK using the fog federation public key (FFPK), and, after that, it uploads the encrypted SK and the index-hash (e.g., File-ID) to the smart contract of the FF. This approach does not allow the FNs to download the EF from the SS (e.g., IPFS in this approach) unless being verified by the smart contract to obtain the EF’s hash-index to be used to download the EF. In addition, when the SC verifies the FN (requestor) as legitimate, it returns the EF’s SK, which would be used by the FN for the decryption process upon downloading the EF from the IPFS. This means that the use of the Ethereum blockchain smart contract concept boosts data confidentiality in this approach, as it protects the on-chain tracking table from being tampered with and acts as a protection wall that prevents rogue FNs from accessing encrypted data stored in the IPFS.

4.5.2. Integrity

In addition to providing the confidentiality to the stored data, this approach maintains the integrity of the data stored in the SS. FNs calculate the hash of the files prior to the encryption process, and then post the encrypted files’ hashes to SC, along with the index-hashes returned by the SS (e.g., IPFS storage). When an authorized FN retrieves an EF from the SS using the hash-index, it is able to check the EF integrity after the decryption process. The mismatched hash(es) will verify the damaged of the EF, and, accordingly, the FN will post that to the SC to make it noticeable to other FNs in the same FF that this EF has been somehow modified. The SC would mark this EF as damaged.

4.5.3. Availability

Fog computing emerged with important features to be added to the current computing paradigms. Fog computing is considered as the middle level between cloud computing and end-users’ devices, such as IoT and mobile devices, because it filters and pre-processes data before being outsourced to the cloud. One of the FF concept motivations is to keep data available to end-users even when the fog node providing services to end-devices in a specific location is down or ousted for whatever reason. The end-users still could communicate with other FNs in the same FF to obtain the same services provided with the ousted FN. There is no doubt that the fog federation concept will greatly improve the data and nodes management in the fog computing paradigm.

5. Proposed Approach and Assumptions

5.1. Overview of the Proposed Approach

In this subsection, we describe the architecture of the proposed blockchain-encryption-based approach based on smart contracts. By referring to Figure 1, we first describe the entities that comprise our approach. This approach consists of the following entities:

• Shared storage (SS): In this approach, we used the IPFS as a SS to store the encrypted files (EFs) uploaded by the FNs. The IPFS returns the index-hash upon receiving the uploaded files;
• Fog nodes (FNs): FNs are the entities that provide services to end-users in the fog computing paradigm. FNs with the same attributes form a FF, which is considered to be a private blockchain. This means that if the FN providing services to end-users goes down or becomes rogue, the end-user can still obtain the same services from other FNs in the same FF. FNs in the same FF can verify each other by invoking the smart contact, i.e., the smart contract can check whether the FN that is requesting access to an encrypted file possesses the FF’s legitimate attributes or not;
• Trusted authority server (TAS): This server is assumed to be fully trusted in this approach. We used it to set up the system and to generate the required keys to operate the system. It is responsible for posting FFPK and FF’s attributes to the smart contract. It is a pre-verified authorized node on the Ethereum blockchain. It assigns attributes to FFs and adds new FNs to the FF;
• Smart contract: The Ethereum blockchain smart contract was exploited to enforce trust among FNs in the same FF. Furthermore, it is used to track the on-chain tracking table in order to prevent any unauthorized access to the encrypted data stored in the SS. It functions as miners to validate the requests generated by FN in the same FF. Through this paper, we use fog federation and private blockchain interchangeably.

Data delivery from cloud storage (e.g., SS in this approach) to end-user devices is hindered by time latency and communication overhead. Fog computing has emerged to address these issues. However, FNs are exposed to malicious attacks; consequently, the end-users’ data security might be violated. To maintain confidentiality, integrity, and availability for end-users’ data traveling through FNs to the SS, we exploit and integrate blockchain with the CP-ABE algorithm, an advanced cryptographic primitive that enforces fine-grained data access control to secure communication between FNs and the CSP. Using blockchain, FNs can perform the authorization process in a distributed manner. To solve the problem of high communication overhead, we deploy an access control policies table (on-chain files tracking table) on the Ethereum smart contract, as shown in Table 3, which must be protected from tampering conducted by malicious (rogue) FNs. Blockchain plays a vital role here, as it is tamper-proof by nature.

In this approach, after a TAS validates an FN for possessing a set of attributes, the TAS will issue a fog node identity (FN${}_{ID}$) and assign it to the corresponding FF based on its attributes, namely its location and services. This validation is carried out in the context of the smart contract.

Each FN in the same FF maintains an on-chain file tracking table to provide a fine-grained access control by using a smart contract. This allows other FNs in the same FF to access the encrypted data on the IPFS when their attributes satisfy the stored predicates in the on-chain files’ tracking table.

When a FN sends a query to the SC to access a specific EF, the SC checks whether any FN in the FF has the required file stored in its off-chain database. If so, it refers the requestor to obtain the file from the FN currently in possession of the file instead of sending the request to the IPFS. When the FN (data requestor) requests an EF from another FN in the same FF, the receiver will verify the requestor’s identity using the smart contract. This feature is a benefit of this approach, as it minimizes the communication overhead between the SS and the FF. When the FN obtains the index-hash of the EF stored in the IPFS, it can retrieve the desired encrypted file.

In fog computing, FNs collect data from end devices. They process those data and upload the results to the cloud for further processing and storage. We equip every FN with two databases: an off-chain and an on-chain database (DB). The off-chain DB stores the encrypted data that are most frequently accessed by end-users, which reduces the communication overhead between the SS and the FFs. FNs can retrieve data encrypted by FNs in the same FF. This feature helps us to maintain data availability when ousting an FN from the FF near end-users’ devices. Furthermore, the end-users would still obtain the same services provided by the FN close to them if this FN became ousted from another FN in the FF. The on-chain database is considered to be a digital ledger and is stored on the blockchain. It stores an on-chain file tracking table, as shown in Table 3, to verify the FF’s members’ identifications in the context of a smart contract. For the sake of clarity, we will consider the following example:

Suppose FN${}_1$ encrypts file F${}_1$ using a random SK. Next, it uploads the encrypted file (EF${}_1$) to the IPFS and obtains an index-hash from IPFS. After that, the FN${}_1$ queries the smart contract to obtain the FFPK to use it when encrypting the SK. Then, FN${}_1$ posts the index-hash, encrypted SK, and the file hash to the Ethereum blockchain smart contract. Now, suppose FN${}_2$, which is in the same FF as FN${}_1$, seeks to retrieve an EF${}_1$; there are three scenarios we have studied in this paper:

• First Scenario:
  FN${}_2$ intends to retrieve the EF${}_1$ in which no other FN in the same FF has an updated copy of the file in its off-chain DB. In this case, FN${}_1$ will query the smart contract in order to obtain the index-hash, file hash, and the encrypted SK. If FN${}_1$ is successfully verified by the smart contract, it will receive the index-hash, file hash, and the encrypted SK of the desired EF. Next, FN${}_2$ decrypts the SK using its own fog node secret key (FNSK). Next, it retrieves the encrypted file from the shared storage using the index-hash;
• Second Scenario:
  FN${}_2$ seeks to retrieve the EF${}_1$ in which FN${}_3$ in the same FF has an updated copy of the file. In this case, FN${}_2$ queries the SC to retrieve EF${}_1$. SC returns the required file credentials to FN${}_2$, plus FN${}_3$’s address. Further, FN${}_2$ will communicate with FN${}_3$ to obtain EF${}_1$. FN${}_3$ will validate FN${}_2$’s identity by invoking the smart contract. If the smart contract returns the information that FN${}_2$ is a member of the same FF, FN${}_3$ will return the file to FN${}_2$. This feature gives our approach credit in minimizing the communication overhead between the SS and the FFs. This is possible with the fog federation idea. For more details, read the approach’s description;
• Third Scenario:
  FN${}_2$ is not verified by the smart contract, so it will not pass the authorization process to obtain enough information to retrieve the encrypted data from the SS. Accordingly, the FN${}_2$ (data requestor) will be reported as a rogue FN and deleted from the FF.

An FN leaves the system for whatever reason, or could also go rogue after being compromised by a malicious attack. There has been a demand to take precautions against rogue FNs in order to ensure users’ data security, such as, namely, data confidentiality, data integrity, and availability. This approach efficiently acts as a protection layer against rogue FNs to prevent them from accessing the encrypted data stored on the SS. The on-chain file tracking table is stored on the Ethereum blockchain. Any FN that queries the blockchain with false information will be detected based on the data pre-stored on the tracking table. We utilize the blockchain in this approach to track the FNs in each FF and to prevent unauthorized and ousted FNs from accessing the data stored in the SS.

If an FN issues an update and is not passed by most of the SC, the issuer would be considered a rogue FN and then excluded from the FF. When a rogue FN is detected in the FF, it is decoupled from the FF. Accordingly, this feature enhances the approach’s ability to protect against rogue FNs.

5.2. The Threat Approach

In this paper, we focused on three threat approaches, as follows:

5.2.1. Rogue Fog Nodes

In this approach, we define a rogue fog node as a fog node that retrieves encrypted data stored in the SS for malicious intent. It could also maliciously modify the encrypted data. These incidents would violate the security of the end-users’ data stored in the SS. For instance, when a rogue FN becomes able to download encrypted data from the SS or other FF’s members, the data confidentiality and data integrity of end-users’ confidential data are compromised.

5.2.2. Man-in-the-Middle (MITM) Attack

In our approach, the man-in-the-middle (MITM) attack is defined as when a third party intercepts the encrypted data traveling between the FNs and the SS or among the FNs in the same FF to violate credential data maliciously. If this malicious third party manages to modify the traveled data, FNs will not detect this modification unless counting on a robust method to prevent and detect that. In addition, if a MITM attacker manages to intercept the encrypted data, its would cause the end-users’ data confidentiality to be violated.

5.2.3. Curious Cloud Storage Service Provider

In any developed system that is meant to be secure, it is not smart to consider the third party providing the storage service as fully trusted. End-users care about their confidential data, which are outsourced to the fog nodes to be protected while being stored in the SS. If the SS service provider discovers the uploaded encrypted data, it will violate the data confidentiality.

6. Design of the Approach’s Algorithms

This section presents the description of our approach based on the integration of the CP-ABE algorithm and Ethereum blockchain smart contract. We exploited the access tree approach presented in [14] as an access structure A, as shown in Figure 2. To satisfy the access tree conditions, we follow the same methods in [14,22]. For more information about the access tree approach, read through [14,22]. Next, we provide the algorithms and smart contracts needed for our approach. Algorithms 1–4 are implemented on the external environment from the Ethereum blockchain. The rest of the algorithms in this approach are smart contracts that we implemented in solidity.

Algorithm 1 is based on [14]. It is executed by TAS to start the system. It receives a security parameter as an input; then, it outputs a system master key ($SMK$) and a system public key ($SPK$). These keys assist in generating keys for FFs and FNs. It builds a universal set of attributes (USAT), and their FF classification is based on our approach; USAT = FN’s location and FN’s services.

Algorithm 1 Setup ($\lambda$).

1: Choose bilinear cyclic group $G_1$ of prime order p with generator $g_1$; 2: Randomly generates exponents $\alpha ,\beta \in$$G_p^{*}$; 3: Random oracle H: $USAT\to$ {0,1}${}^{*}$ // to map each att in USAT into random element $\in G_1$; 4: Compute $SMK$ and $SPK$ as: 5: $\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}SMK$ = $\{\beta ,g_1^{\alpha }\}$; 6: $\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}SPK$ = $\{G_1,g_1,g_1^{\beta },e{(g_1,g_1)}^{\alpha }\}$; 7: The $SPK$ is public to all FNs, but $SMK$ is private for TAS.

Algorithm 2 is executed by an FN that aims to join the system to provide a service for end-users. It contacts the TAS; then, the TAS checks the pre-stored fog federation list (FFL). The FFL is a list of FFs, along with the FNs in them. The TAS, accordingly, assigns the FN to the corresponding FF if its attributes are verified. If the FN is verified but no FF${}_{att}$ matches its attributes, the TAS creates a new FF and adds the new FN to it. After that, the TAS invokes (adding FN to the FF smart contract) in order to add the new FN’s credentials to the smart contract. However, if the FN is not verified, the connection will be refused. The details of how to verify and authenticate the FN’s attributes are outside the limits of our scope for now.

Algorithm 2 Join (FN${}_{att}$).

1: New FN contacts TAS to join the system; 2: TAS verifies the FN (requestor); 3: if not verified then 4:     Declined; 5: else 6:     Check the FFL; 7:     if FF${}_{att}$ == new-FN${}_{att}$ then 8:         Assign new-FN${}_{att}$ to the corresponding FF${}_{ID}$, and assign ID to the new FN; 9:         TAS posts the FN${}_{ID}$, and attributes by invoking adding FN to the FF smart contract; 10:     end if 11: end if

Algorithm 3 is also executed by the TAS. It generates a FFPK and a fog federation master key (FFMK). The FFPK is public to all FNs in the FF, whereas the FFMK is private to the TAS. It also generates a distinct FNSK for each FN in the FF. Then, the TAS securely shares the FFPK and FNSK with the new FN. TAS posts the FFPK to the smart contract and maps the FFPK to FF’s attributes. This can be accomplished by invoking the fog federation creation smart contract.

Algorithm 4 is executed by authorized FNs in a given FF. This algorithm was executed separately from the Ethereum smart contract, as the current Ethereum platform does not support ABE algorithms. The FN intending to encrypt a file generates a SK and uses it to encrypt data. Next, the FN encrypts the SK using the FFPK to enable every FN in the same FF to decrypt the encrypted SK when needing to retrieve the encrypted file from the SS. Finally, the FN (data owner) uploads the EF to the SS, where, here, we use the IPFS. Then, the data owner uploads the file hash, the encrypted file index-hash returned by the IPFS, and the encrypted SK to the smart contract by invoking the adding file and encrypted SK smart contract.

Algorithm 3 Generating $FNSK$ ($SPK,SMK,S,F{N}_{ID}$).

1: TAS receives request from new FN to join the system; 2: Choose bilinear cyclic group $G_1$ of prime order p with generator $g_1$; 3: Randomly generates exponents ${\alpha }_1,{\beta }_1\in$$G_p^{*}$; 4: Random oracle H: $USAT\to$ {0,1}${}^{*}$ // to map each att in USAT into random element $\in G_1$; 5: Compute $FFPK$ and $FFMK$ as: 6: $\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}FFPK$ = $\{{\beta }_1,g_1^{{\alpha }_1}\}$; 7: $\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}FFMK$ = $\{G_1,g_1,g_1^{{\beta }_1},e{(g_1,g_1)}^{{\alpha }_1}\}$; 8: Post the FFPK to the smart contract by invoking addFogFederationMember() algorithm in smart contract; 9: Generate random $r\in Z_p^{*}$; 10: for every $at{t}_i\in S$ do 11:     Generate random $r_i\in Z_P^{*}$; 12: end for 13: for each new FN${}_i\in FF$ do 14:     Compute $FNSK$ as follows; 15:     $FNSK=(D=g^{({\alpha }_1+r)/{\beta }_1},\forall i\in USA:D_i=g^r.H{\left(F{N}_{ID}\right)}^{{\alpha }_{1_{ver}}}.H{\left(i\right)}^{r_i},D_i^{\prime }=g^{r_i}.H{\left(F{N}_{ID}\right)}^{{\alpha }_{1_{ver}}})$; 16:     send $FNSK$ to FN${}_i$. 17: end for

Algorithm 4 Data encryption (M, T, $SPK$, $FFPK$).

1: SK = gen.DEC-Key; 2: Encrypted file (EF) = encrypt (M, SK) //M is the message to encrypt; 3: A is set of atts represented by monotone access structure tree T; 4: for each node x in T do 5:     Set a polynomial; 6:     if node x is root node in T then 7:         Set $q_{\left(0\right)R}$ = s // s is random value $\in Z_P^{*}$; 8:     else 9:         $q{\left(0\right)}_x$ = $q_{parent\left(x\right)}\left(index\left(x\right)\right)$; 10:         Then, choose $d_x$ = $k_x$ − 1 as polynomial degree to interpolate with $q_x$; 11:     end if 12: end for 13: for each y ∈ Y do //Y is the set of leaf nodes in T 14:     $C_y=g^{q_y\left(0\right)}$; 15:     $C_y^{{}^{\prime }}=H{\left(att\left(y\right)\right)}^{q_{y\left(0\right)}}$; 16: end for 17: Compute: $C=g^{\beta s}$; 18: for each $S{K}_i\in SK$ do 19:     Compute $C_{{ver}_i}=S{K}_i.e{(g,g)}^{\alpha s}$; 20: end for 21: Upload [EF] to the shared storage (IPFS); 22: post the encrypted file hash, index-hash, and the encrypted SK to smart contract by invoking addFile() function in the smart contract.

Algorithm 5 is executed by the TAS to deploy the smart contract to the Ethereum blockchain. The deployment process returns the contract address in which the fog nodes in fog federations make contact in order to be served. The TAS sends the contract address to every new FN upon joining the fog federation groups. The essential function of this smart contract is to keep track of which FNs have which files in the off-chain DB. In this case, we can minimize the communication overhead between the SS and the FFs. No FN can retrieve the EF or perform any operation unless it becomes authorized by the smart contract, and this is attributed to the blockchain tamper-proof feature. When an FN intends to retrieve an encrypted file from the SS or another FN in the same FF, FNs could authenticate the FN (requestor) using the smart contract. This approach prevents FNs in the FF from falsifying information about the files’ tracking table or accessing the EF in the CSP. This feature strengthens our approach robustness.

Algorithm 5 Smart contract deployment.

1: TAS deploy the smart contract into the Ethereum blockchain; 2:  return contract${}_{address}$; 3: TAS securely save the contract${}_{addrees}$ to be distributed to the FF members.

Algorithm 6 is a smart contract created by the TAS and deployed on Ethereum. TAS uses this part of the smart contract to issue fog federations and maps these FFs to FFPKs and FF${}_{attributes}$. It takes, as inputs, the FFPK, FF${}_{attributes}$ (e.g., location and services), and members (e.g., FNs to be added to the FF).

Algorithm 6 Fog federation creation smart contract.

1: struct FogFederation{ 2:   string FFPK; 3:   string attribute1; 4:   string attribute2; 5:   string[ ] members; 6:   string[ ] fogFederationFiles; 7:   } 8: mapping(string ⇒ string) public fogNodeFFPK; // map FN to FFPK, FN ⇒ FFPK 9: mapping(string ⇒ bool) public setFFPK; // check for uniqueness of FFPK, if FFPK1 is given then set to true, 10: string[] fogFederationsList; // list of fog federations 11: mapping(string ⇒ FogFederation) public mapFFPK; // FFPK ⇒ FF 12: event Fog-Federation-Event(string FFPK, string attribute1, string attribute2, string[] members, string[ ] files); 13: function createFogFederation (string ffpk, string att1, string att2) public returns(string FFPK, string attribute1, string attribute2, string[] members, string[] files){ 14:    require(msg.sender == TAN${}_{address}$, “You are not allowed”); 15:    require(setFFPK[ffpk] == false &&keccak256(abi.encodePacked (mapFFPK[ffpk].FFPK)) ==keccak256(abi.encodePacked(“”)), “FFPK already have attributes”); 16:    setFFPK[ffpk] = true; 17:    mapFFPK[ffpk].FFPK = ffpk; 18:    mapFFPK[ffpk].attribute1 = att1; 19:    mapFFPK[ffpk].attribute2 = att2; 20:    fogFederationsList.push(ffpk); 21:    emit GroupEvent(ffpk,mapFFPK[ffpk].attribute1, mapFFPK[ffpk].attribute2, mapFFPK[ffpk].members, mapFFPK[ffpk].fogFederationFiles); 22:    return(ffpk, mapFFPK[ffpk].attribute1, mapFFPK[ffpk].attribute2, mapFFPK[ffpk].members, mapFFPK[ffpk].groupFiles);}

Algorithm 7 is a smart contract that adds FNs to the FF and is deployed on Ethereum. It is invoked upon a new FN joining the FF group. This smart contract maps the new FN to the FF to the FFPK and FF’s attributes. This smart contract also maps the FN to the encrypted files to the FF where this FN belongs. The FN, accordingly, can retrieve the encrypted file credentials stored on the smart contract. FNs that are not part of the smart contract cannot access the encrypted data stored in the SS.

We developed a smart contract to enable FNs in the same FF to add encrypted file credentials and encrypted SK to the smart contract, as shown in Algorithm 8. This smart contract allows for FNs to add encrypted file credentials to the smart contract as follows: the file hash, index-hash, and encrypted (SK). The smart contract verifies whether the FN’s (requestor) credentials match the FF’s credentials or not. The FN is incapable of adding encrypted file credentials to the smart contract if the FN credentials do not match the FF’s credentials. In addition, this smart contract connects the encrypted file index-hash in the SS, encrypted (SK), and the encrypted file’s hash with the fog federation’s attributes.

Algorithm 7 Adding FN to the FF smart contract.

1: event FFmemberEvent( stirng FFPK, string attribute1, string attribute2, string[ ] members, string[ ] files) 2: function addFN (string memory FFPK, string memory FN${}_{ID}$) public returns(string memory FFPK, string memory attribute1, string memory attribute2, string[ ] memory members, string[ ] memory files) { 3:   require(msg.sender == TAN${}_{address}$, “You are not allowed”); 4:   require(setFFPK[ffpk] == true && keccak256( abi.encodePacked(mapFFPK[ffpk].ffpk)) == keccak256(abi.encodePacked(ffpk)), “FFPK not available”); 5:   require(keccak256(abi.encodePacked( memberFFPK[FNid])) == keccak256(abi.encodePacked(“”)), “Member already added in FF”); 6:   mapFFPK[ffpk].members.push(FNId); 7:   memberFFPK[FNid] = FFPK; 8:   emit MemberEvent(ffpk, mapFFPK[ffpk].attribute1, mapFFPK[ffpk].attribute2, mapFFPK[ffpk].members, mapFFPK[FFPK].groupFiles); 9:   return(ffpk, mapFFPK[ffpk].attribute1, mapFFPK[ffpk].attribute2, mapFFPK[ffpk].members, mapFFPK[ffpk].groupFiles); }

Algorithm 8 Adding file and encrypted secret key (SK).

1: event UploadEvent (stirng FFPK, string attribute1, string attribute2, string[ ] members, string[ ] files) 2: function uploadFileHashAndSK (string FFPK, string sender${}_{ID}$,string filehash, string fileIndex, string EncryptedSK) public returns (string FFPK, string attribute1, string attribute2,string [ ] members, string [] files){ 3:   require (memberFFPK [sender${}_{ID}$] == FFPK); 4:   require (fileInFF [fileIndex][filehash] == “ “); 5:   require (fileMapHash [fileIndex][filehash] == “ “); 6:   require (fileMapHashMapMember [filIndex][EncryptedSK] == “ “); 7:   fileInFF[filehash] = FFPK; 8:   mapFFPK[FFPK].groupFiles.push(fileHash); 9:   fileMapHash[fileHash][fileIndex] = EncryptedSK; 10:   memberFiles[sender${}_{ID}$].push(fileHash); 11:   memberFiles[sender${}_{ID}$].push(fileIndex); 12:   fileMapHashMember[fileHash][EncryptedSK]= sender${}_{ID}$; 13:   emit UploadEvent (FFPK,mapFFPK [FFPK].attribute1, mapFFPK [FFPK].attribute2, mapFFPK [FFPK].members, mapFFPK[FFPK].groupFiles); 14:   return(FFPK, mapFFPK[FFPK].attribute1, mapFFPK[FFPK].attribute2, mapFFPK[FFPK].members, mapFFPK[FFPK].groupFiles); 15: }

Algorithm 9 introduces the file-retrieving smart contract. When an FN seeks to retrieve an encrypted file from the SS, the FN starts by invoking the file-retrieving smart contract. This approach has introduced two scenarios for encrypted data retrieving. First scenario: an FN intends to retrieve an encrypted file while another FN in the same FF has an updated copy of the encrypted file. The FN (requestor) sends a request to the SC to obtain the EF credentials. The SC will return the FN currently in possession of the encrypted file. Then, the FN queries the EF from the returned FN; next, the request receiver verifies the data requestor by executing the smart contract. If the smart contract returns the information that the FN (requestor) is a legitimate FF member, the FN(receiver) will send the encrypted file to the data requestor. Second scenario: the encrypted file is in the SS. The FN (requestor) invokes the smart contract to retrieve the following encrypted file credentials: file hash, file index-hash, and the encrypted SK. The smart contract verifies whether the FN (requestor) identity is authentic or not. If the FN becomes authorized, the smart contract will return the corresponding file hash, file index-hash, and the encrypted SK of the encrypted file.

One of the crucial contributions of this research is to prevent rogue FNs from accessing the encrypted data stored either in the SS or in other FN in the same FF. Algorithm 10 shows the smart contract in order to remove the rogue FN from the FF, where it cannot retrieve the encrypted file credentials from the smart contract.

Algorithm 9 File-retrieving smart contract.

Case 1: Another FN ∈ same FF has copy of the encrypted file (EF) 1: FN receives address of the FN that has the EF in its off-chain DB, and the file index-hash plus encrypted SK from SC 2: FN (requestor) sends a request to the FN holding the EF; 3: FN (reciever) invokes the smart contract to verify the FN (requestor) identity; 4: if FN(requestor) is not verified then decline; 5: else send the EF to the requestor 6: end if    Case 2: Encrypted file is stored in the shared storage (SS) 7: FN (requestor) invoke the smart contract to obtain the file hash and the encrypted SK 8: if FN (requestor) attributes and ID are not verified then decline; 9: else return (file hash in the SS and the encrypted SK) 10: end if 11: FN downloads the EF from the SS using the file hash 12: FN decrypt the encrypted SK using its FNSK, then decrypt the retrieved EF

Algorithm 10 Rogue fog node removing.

1: function removeFN(String FFPK, string FN) public{ 2:   require(msg.sender == TAN$\_address$); 3:   require(memberFFPK[FN]==FFPK); 4:   memberFFPK[FN] = “ ”; 5:   emit removeFN(FFPK, FN${}_{ID}$); }

7. Performance Evaluation and Security Analysis

In this section, the experiment design and the experimental evaluation are provided. We evaluate the cost of creating the smart contract followed by the execution cost of their functions to achieve the blockchain-encryption-based approach’s proposed objectives. In particular, we exploited the Ethereum smart contract technology to oust and prevent the rogue FNs from accessing the encrypted data stored in the SS or in other FNs’ off-chain storage. We start with providing a security analysis of our approach followed by the implementation details.

7.1. Security Analysis

In this subsection, we state the security issues that the blockchain-encryption-based approach provides the solution for. The proposed solutions focused on: rogue FNs, a MITM attack, and a curious storage service provider. Based on our proposed approach in Section 5, we discuss each of these issues as follows.

7.1.1. Security against Rogue Fog Nodes

In this approach, we consider the FN to be a rogue one whenever it submits false credentials to the smart contract, and, accordingly, the SC removes the FN from the FF by decoupling it from the SC. Then, the FN cannot be authorized by the SC. When a FN encrypts a file, it encrypts it using a random generated SK, and then uploads the encrypted file to the shared storage (e.g., IPFS in this approach). IPFS returns an index-hash of the location of the file in the IPFS. Then, the FN encrypts the SK using the FFPK already posted on the SC and uploads it, along with the index-hash of the file, to the SC. This means that no FN can download this file unless providing the correct index-hash. Any FN has to be verified using the SC to obtain the EF credential to retrieve it from the SS. This means that the FN would not be able to obtain the index-hash, encrypted SK, and the hash of the encrypted file stored in the SS. This feature has been accomplished using the smart contracts, as shown in Algorithms 8 and 9, respectively. If the FN fails to obtain authorization through the SC, it is reported as a rogue FN and is consequently deleted from the FF, as shown in SC (Algorithm 10). These features make our approach efficient in protecting end-users’ data confidentiality.

7.1.2. Security against MITM Attack

In this approach, the FN computes the file’s hash before the encryption process, and the hash is uploaded to the SC along with the encrypted file and encrypted SK. All of these are bonded to the FFPK and the FF’s attributes. Later, in the future, if another FN goes through the authorization process via the SC and downloads the EF from the SS, the FN (data requestor) would be capable of verifying the EF integrity after the decryption process. In addition, every FN in the FF has a FNSK that is different from the others but related to the FFPK. This means that any party, not an authorized FF member, would not have an FNSK paired to the FFPK. Therefore, they will not be able to access the encrypted data; however, if it does happen, the FNs that retrieve the encrypted data would be able to discover the damaged files by checking their hashes. In short, this approach is subtle regarding the damaged/corrupted files detection.

7.1.3. Security against a Curious Shared Storage Provider

In this solution, the FN (e.g., considered data owner) does not need a third party to distribute the encrypted (SK) used to encrypt data to the other FNs in the FF. It also does not need to outsource the SK with the EF to the SS provider. FNs encrypt the SK of each EF with the FFPK and upload it to the blockchain smart contract; therefore, the SS provider cannot obtain the SK. Moreover, the SS service provider does not have a copy of the FFPK, as it is only public to the FF members. It is evident that, as long as the Ethereum blockchain smart contract and the FNs’ credentials are safe, this approach is secure against the curiosity of the storage service provider.

7.2. Implementation Details

This subsection presents the implementation details. Our proposed approach combines the CP-ABE technique and the Ethereum blockchain to fulfill the proposed approach’s objectives. The Ethereum blockchain enables developers to program their smart contracts and to deploy them on the Ethereum platform. Moreover, since our work is novel, and no equivalent work has been developed in this context, we could not provide a comparative evaluation. Therefore, in this research, we prove the applicability of our proposed scheme. Besides, in order to conduct the experiments, we simulated five fog nodes, and we measured the transaction cost and the execution cost; however, we excluded the time latency and communication overhead among FNs.

7.2.1. Blockchain-Encryption-Based Experiment Design

This experiment evaluates the proposed smart contracts’ feasibility and performance in terms of the amount of gas consumed by the smart contracts’ functions. In the blockchain-encryption-based approach experiment design, we classify the FNs into FFs based on their attributes, namely, the locations and services they provide to end-users. FNs in the same FF can access and share encrypted data stored on the SS by invoking the smart contract. We used the Ethereum blockchain smart contract for the following reasons: (1) to enable FNs in the same FF to carry on a distributed authorization process; (2) to store an on-chain access control table, called an encrypted files tracking table, which must be protected from being tampered with by rogue FNs. As this approach aims to minimize the communication overhead between the SS and FNs when an FN seeks to retrieve encrypted data from the SS, it must query the smart contract first; the smart contract would check whether there is an FN in the same FF that has an updated copy of the requested file or not. If that is the case, the smart contract directs the FN (requestor) to obtain the required encrypted file from the FN currently in possession of the EF. In this case, exploiting the Ethereum smart contract technology makes our approach robust against falsifying the encrypted files tracking table.

We implemented a prototype of this approach to study its feasibility and performance. The experimental environment’s configuration is macOS Mojave 10.14 with an Intel Core i7 CPU 2.2 GHz processor. The RAM is 16 GB. We used the Solidity programming language to write the smart contracts and the Java programming language to execute the CP-ABE program. This library provides pairing-based cryptosystems in Java.

At the time of this research, the Ethereum solidity does not support ABE algorithms; therefore, we used the smart contract to monitor the encrypted files tracking table and executed the algorithms related to the ABE algorithm externally in the Java programming language. Algorithms 1–4 are implemented on Java, but do nothing with the smart contracts. In the CP-ABE program, we used the Java pairing-based cryptography (JPBC) library used in [50]. Algorithms 5–10 are the smart contracts of this approach, which we developed using the Solidity programming language.

We used a lightweight Java library called web3j [51] for client integration on the Ethereum network. Developers use web3j to evaluate the time it takes to publish the smart contract.

We also used Ganache, which is a blockchain-based emulator used to simulate a personal Ethereum blockchain. It is used for testing solidity smart contracts [52].

7.2.2. The Blockchain Encryption Approach Setup

The inter-planetary file system (IPFS) is used as the SS. The FNs are simulated as clients grouped into FFs by their attributes. One of these FNs is nominated as a trusted authority node (TAN) in each FF. Algorithms 1–4 are simulated on Java. We developed Algorithms 5–10 as smart contracts and deployed them on a private Ethereum blockchain.

The smart contract stores the following credentials of each fog federation: fog node identity (FN${}_{ID}$), EF${}_{ID}$, attribute set, FN${}_{att-sig}$, and the off-chain database content of each FN. It also maintains the cryptographic keys of each FF, such as FFPK, and maintains a set of encrypted files that the FF’s members can access.

In addition, the smart contract comprises a set of credentials about each EF upon being uploaded to the SS. These credentials are the returned hash address of the SS, the hash of the EF before being encrypted, and the secret key used in the encryption process by the FN in an encrypted format. All of this information is protected from being tampered with by being stored on the Ethereum smart contract.

This approach tries to minimize the communication overhead between the SS and the FNs. Therefore, we equipped the smart contract with a list of FNs and what EF they currently have in their off-chain DB. The smart contract checks the list upon receiving a request from an FN to retrieve a specific EF, and returns both the EF’s credentials and the FN currently in possession of the EF. The smart contract considers the EF in the off-chain DB to be valid only for a period of time. This is because the approach cannot guarantee the prevention of the FNs from going rogue and then poisoning the EF that they currently possess. On the other hand, if the smart contract verifies the FN (requestor), but no FN in the same FF has an updated copy of the requested EF currently, the smart contract is programmed to return the EF’s credentials, as the FN (requestor) can download the required EF from the SS. However, as fog computing was introduced to minimize the time latency and communication overhead between the cloud and end-devices, this approach satisfies less communication between the SS and FNs by construction.

When a FN (data requestor) does not pass the smart contract verification process, it is considered a rogue FN. Then, the smart contract decouples this FN from the FF, as it becomes incapable of accessing the encrypted files anymore. FNs that belong to other FFs or provide mistaken request inputs to the smart contract will not be able to circumvent the blockchain smart contract.

7.2.3. The Blockchain Encryption Approach Experimental Evaluation

At the time of simulating this approach’s SC, the 1-ether price was equal to USD 191. The gas price was equal to two Gwei, where one Gwei = 10${}^{-9}$ ether. The cost of our smart contracts executing the intended functions is given in

Table 4. Smart contract and functions test cost).

SC/Function	Gas Used	Cost in (Ether)	USD
SC Deployment	4,153,581	0.1661432	57.81
Fog Federation Creation	1,949,796	0.0779918	27.14
Adding FN to FF	847,139	0.0338856	11.79
Add File Index and SK	2,136,909	0.0854764	29.74
Add File Hash	2,037,800	0.081512	28.36
Getting SK and file index	927,240	0.0370896	12.90
Remove FN from FF	806,318	0.0322527	11.22
Verifying FN by attribute	952,460	0.0409558	14.25

. The transaction cost refers to the required amount of gas to post the data on the blockchain network. The execution cost refers to the function execution computational fee.

The Ethereum platform does not support ABE algorithms at the time of this research. Therefore, we executed Algorithms 1–4 in an external environment. In this approach, we merely use the smart contract to manage encrypted data access policies among FNs in the same FF.

The smart contract is deployed by deploying Algorithm 5 to the Ethereum blockchain. The deployment process returns the smart contract address, which authorizes its use to FNs whenever to query the smart contract to perform any function. As shown in Table 4, the SC Deployment operation costs 0.1661432 ether, which equals USD 57.81.

For each FF, we externally generated the following: FFPK and attributes (e.g., FNs locations and services provided by the FN in the FF). Then, the TAN invokes the fog federation creation smart contract to perform the makeFF() function, which posts the FF credentials to the blockchain. In this work, we grouped the FFs by their attributes. Each set of attributes is paired to an FFPK. When a TAN invokes the smart contract to make a FF, this performed function costs 0.0779918 ether, which equals USD 27.14.

When a new FN joins the system, the TAN adds it to the corresponding FF by invoking adding FN to the FF smart contract. This smart contract performs an addFN() function. In this step, the smart contract stores the FN${}_{ID}$, the FF this FN belongs to, the FFPK, and the FF attributes. This function cost 0.0338856 ether, which equals USD 11.79.

This approach is invented to prevent rogue FNs from accessing the encrypted data stored in the SS. Suppose a FN has a file to be encrypted and uploaded to the SS. Let us consider that this FN became ousted for technical or malicious reasons. In this case, we are not benefiting from the fog computing features. Therefore, the fog federation idea plays a significant role here by maintaining data availability to the end-users. When a FN seeks to encrypt a file and upload it to the SS, it follows the following steps. First, it performs the hashing and encryption process externally by executing Algorithm 4. Then, the FN encrypts the SK used to encrypt the file using the FFPK. Next, it uploads the EF to the SS, which is the IPFS in this research. The IPFS returns the index-hash of the uploaded EF. Consequently, the FN invokes adding the file and encrypted (SK) smart contract in order to upload the encrypted file credentials to the blockchain as: (EF${}_{ID}$, encrypted (SK), file hash, index-hash). This smart contract executes the uploaded file index hash. Furthermore, it executes the SK function. This function costs 0.0854764 ether, which equals USD 29.74. In addition, it adds the file hash. This is carried out by executing the add file hash function, and this function costs 0.081512 ether, which equals USD 28.36.

When a FN in the FF seeks to retrieve an EF from the SS, the FN (requestor) invokes the file-retrieving smart contract. This SC checks whether another FN in the same FF has a copy or not. Suppose the FN (requestor) passes the SC identity validation check, and another FN in the same FF has an updated copy of the required EF. In that case, the SS returns the EF credentials that are encrypted (SK), the EF-hash, and the index-hash, plus the identity that the FN currently has of the EF in its off-chain-DB. When the FN (requestor) sends the requestor the FN, which has a copy of the EF, the FN (receiver) will query the SC to validate the FN (requestor) identity. On the other hand, if the required EF is not available in any of the FF’s member’s off-chain databases, the FN (requestor) will download the EF from the SS (the IPFS in this approach) using the index-hash received from the SC. The SC accomplishes this by performing the getting SK and index-hash function, which costs 0.0370896 ether, which equals USD 12.90. In addition, when the system verifies any FN (requestor), the verifying-FN function is provoked, which costs 0.0409558 ether, which equals USD 14.25.

In addition to the ability of this approach to verify FNs (data requestors) before putting hands on the encrypted data, it is capable of ousting the rogue/malicious FNs upon receiving incorrect credentials from the FN upon provoking any of the SC’s functions. When the FN does not pass the validation process (the verifying FN function), the SC instantaneously provokes the rogue-fog-node-removing smart contract, decoupling the rogue FN from the FF smart contract so that the smart contract is inaccessible to the rogue FN. Therefore, rogue FNs that are not authorized and authenticated by the SC requests are discarded. This is accomplished by performing the removeFN() function, which costs 0.0322527 ether, which equals USD 11.22.

8. Discussion

The security analysis in Section 7.1 shows our approach ability in providing a secure environment for end-users’ data that has traveled among FNs in the same FF and between FNs and SS providers. In particular, this approach provides the main objectives of information security: data confidentiality, data integrity, and data availability. In this approach, we exploited the Ethereum blockchain smart contract technology to store the on-chain file tracking Table 3 on the smart contract and to prevent both its registration and any modification of it performed by FN, unless being authenticated by the smart contract. In addition, the FNs in the same FF authenticate and verify each other using the smart contract, which is considered to be decentralization, as there is no third party we need to trust. The intention of this approach was not to develop a high-performance approach, but rather to show its feasibility and applicability by demonstrating its ability to protect data security by ousting rogue FNs. Therefore, this approach would not be suitable for time-sensitive applications, as the blockchain is very slow and time consuming. However, this approach would be effective in terms of detecting rogue fog nodes. In addition, as this approach focuses on the channel between the cloud storage and fog nodes, we considered the channels between end-devices and the fog nodes to be secure. Besides, in this approach, if a FN provides false information when querying the smart contract, it is considered to be a rogue one. Accordingly, it is removed from the smart contract, leading to it being incapable of accessing the encrypted data to the FF. Moreover, we have compared our proposed approach against current schemes in the literature in terms of security features; see

Table 5. Comparison between our approach and approaches from literature.

	Features
Schemes	FF	FFSG	Confidentiality	Integrity	Availability	Authentication Process	Access Control	Rogue Fog Node Detection and Ousting
[32]	✓	×	✓	✓	✓	Digital Signature	Fine-grained	Ousting
[53]	✓	✓	✓	✓	✓	Digital Signature	Fine-grained	Ousting
Proposed Approach	✓	×	✓	✓	✓	Decentralized using Ethereum Smart Contract	Fine-grained	Detection and Ousting
[33]	×	×	✓	×	×	Digital Signature	Fine-grained	×
[54]	×	×	✓	×	×	Authenticate nodes by hashing request message	Using Access Key	×
[55]	×	×	×	×	✓	Challenge-response Mechanism	×	×
[56]	×	×	✓	×	✓	Digital signature	Fine-Grained	Revoking Users’ Attributes
[57]	×	×	×	×	×	Challenge response technique and PKI method	×	Detecting rogue vehicle
[31]	×	×	×	×	×	×	×	Detecting rogue AP using round trip time
[29]	×	×	✓	✓	×	×	×	×
[58]	×	×	✓	×	×	Certificate	Fine-grained	Revoking users’ attributes
[23]	×	×	✓	×	✓	ABS	Fine-grained	×
[59]	×	×	✓	×	×	Multi-authority CP-ABE method	Fine-grained	×

.

9. Applications

This section illustrates some of the applications in which this approach could be exploited to protect end-users’ data security. We provide one example, which is as followed.

This approach could be exploited in hospitals, as follows. Suppose every hospital has multiple FNs (e.g., a fog node for each clinic) characterized by the attributes of the health service and hospital’s name. Those FNs are considered as a FF. Patients’ records would be stored in the SS. Doctors can outsource patients’ information to the FN of the clinic for processing and further outsource to the SS for storage. The FN holds the EF for a specific time after outsourcing it to the SS, in which, another FN could request it in the same FF. Every FN in the hospital is registered to the Ethereum blockchain smart contract. When a specific doctor requests certain private data from the clinic FN, the FN would query the smart contract for obtaining the required file address in the SS, its hash, and the encrypted (SK). If the smart contract verifies the FN, it will return the EF credentials to the FN. If another department FN in the same hospital has an updated copy of the EF, the smart contract returns the address of the FN that has the updated copy of the required file. Otherwise, the FN will obtain the EF from the SS. Exploiting the smart contract concept would help FNs in the same hospital to authenticate each other by tracking the actions provided by each FN. To illustrate, posting all activities on the blockchain smart contract would help to trace any malicious event caused by a FN. We believe that applying this approach to hospitals would increase patients’ data security level independently from a trusted third party.

10. Conclusions

Fog computing was introduced to solve the problem of time latency and communication overhead between the cloud data centers and end-users. However, it is possible for the fog nodes to go rogue, which would maliciously violate end-users’ data security. In this research, we proposed a novel approach to protect end-users’ data security from being breached by rogue FNs and to reduce the time latency and communication overhead between the FNs and the CSP. It also enables FNs to communicate in a trust-less environment and to perform authorization processes in a distributed manner to detect the rogue fog node.

A blockchain-encryption-based approach is an approach designed to oust rogue fog nodes and to minimize the communication overhead between the CSP and FNs by integrating the CP-ABE algorithm and blockchain technology. We adopted the blockchain in this approach as a medium to store an on-chain tracking table to verify the identity of each fog node in the fog federation using the smart contract before they could access the encrypted data on the CSP. In this approach, the blockchain helps to prevent the fog nodes from maliciously changing the on-chain tracking table; if such a change is detected, the FN that issues the request is reported as a rogue fog node. We used the IPFS as shared storage in this approach, and we simulated the blockchain using the Ethereum smart contract. In our experiment, we showed the feasibility and applicability of this approach by simulation. Then, we showed that this approach satisfied the proposed objectives because the gas consumption that the smart contract takes in order to perform the approach’s functions should be affordable to FNs.

Our approach in this paper focused on the cloud and fog computing levels. We will focus on providing a holistic approach to serve all levels (e.g., end-users’ devices’ fog cloud).