Cloud computing is the most popular computing paradigm that offers its resources over the Internet. Cloud computing provides many advantages to end users, such as lower cost, high reliability, and greater flexibility. However, it has some drawbacks, which include a high latency, necessitating Internet connecti- vity with high bandwidth and security  .
During the last few years, a new trend of Internet deployments emerged called the Internet of Things (IoTs) that envisions having every device connected to the Internet. Its applications include ehealthcare, a smart grid, etc. Those applications require low latency, mobility support, geo-distribution, and user location awareness. Cloud computing appears to be a satisfying solution to offer services to end users, but it cannot meet the IoTs’ requirements. As a result, a promising platform called fog computing is needed to provide the IoTs’ requirements; fog computing was proposed by Cisco in 2012  .
Fog computing is a concept that extends the paradigm of cloud computing to the network edge, allowing for a new generation of services  . Fog computing has an intermediate layer located between end devices and the cloud computing. This leads to a model with a three-layer hierarchy: Cloud-Fog-End Users  . The goal of fog computing is to offer resources in a closer vicinity to the end users. As in Figure 1, each fog is located at a specific building and offers services to those inside the building  . Fog computing supports low latency, user mobility, real-time applications, and a wide geographic distribution. In addition, it enhances the quality of services (QoS) for end users. These features make the fog an ideal platform for the IoTs  .
Support of location awareness is the key difference between the cloud environment and the fog environment. Cloud computing serves as a centralized global model, so it lacks location awareness. In contrast to cloud computing, fog devices are physically situated in the vicinity of end users  .
Data sharing has great importance for many people, and it is an urgent need for organizations that aim to improve their productivity  . Currently, there is an urgent need to develop data sharing applications, especially for mass com-
Figure 1. The fog is situated between the cloud and the edge.
munications, where the data owner is responsible for delivering shared resources to a large group of users. This one (data owner) to many (users) method needs special care, taking into consideration the challenges related to such applications. The main problems for such applications are issues related to security and privacy  .
Like cloud computing, fog computing faces several security threats for data storage; to meet them, there are security features that were provided in the cloud environment. These security features are the enforcing of fine-grained access control, data confidentiality, user revocation and collusion resistance between entities  .
We present a novel architecture for data sharing a fog environment. We explore the benefits brought by fog computing to address one-to-many data sharing application. Such architecture is sought to outperform the cloud-based architecture and ensure further enhancements to system performance, especially from the perspective of security. Our proposed framework provides high scalability and sharing of data in real time with low latency.
2. Related Work
We will provide a detailed overview of prior studies on secure data sharing in cloud environments.
Yu et al.  proposed a data-sharing scheme designed to provide fine-grained data access control, data confidentiality, and scalability. However, it requires updating all users’ secret keys and re-encrypting all the files, thus reducing the efficiency of the user revocation operation.
Wu et al.  presented a novel technique for sharing media, especially in large distributed systems. Unfortunately, the decryption operation in low-end devices is slow, and user revocation is not addressed.
Liu et al.  designed a framework for sharing data based on the time concept. It is a better fit for an environment in which the data owner is offline and periodic user revocation occurs. However, the proposed scheme requires efficient shared time periods for all the user-related attributes.
Tu et al.  proposed a secure data-sharing framework that is secure against chosen-ciphertext attacks. Unfortunately, the proposed framework places heavy computation overhead on the process of user revocation.
Yang and Zhang  designed a generic scheme for sharing data. The scheme does not need to require the redistribution of keys. However, it has not addressed the scenario in which a revoked user rejoins the group with new access rights.
Hur  proposed a secure data-sharing scheme featuring rapid user revocation. Its major drawback is that it suffers from low scalability and high calculative complexity.
Samanthula et al.  proposed a framework with effective user revocation. Unfortunately, the proposed scheme puts a heavy burden on the cloud servers by requiring the data owner to create a token in each record for every user, which
Table 1. The main features schemes.
increases the complexity of the system and reduces scalability.
From the previous discussion, it is evident that the previous schemes have failed to find an overall solution to achieving the previous goals, as shown in Table 1. Most of these desired features are realized in  , so we will apply it in a fog environment with some enhancement to achieve all our design goals. Our proposed framework rests on a combination of previous approaches that provide secure data sharing in cloud computing, such as Attribute-Based Encryption (ABE) and Proxy Re-Encryption (PRE) techniques    .
Unlike the previous system  , the proposed revocation mechanism does not necessitate the re-encryption of all system files and updating of all secret keys. Our proposed system provides real-time data sharing to group members. Our work will focus on providing an ideal environment for secure data sharing in a fog environment to overcome the disadvantages of a cloud-based data sharing system, which includes a high latency, requiring Internet connectivity with high bandwidth and lacking location awareness.
3. Fog Based Data Sharing Architecture
3.1. Fog Based Data Sharing Model
There are four parties in the proposed system: Data Owner, Cloud Servers, many Fog Nodes and Data users.
・ Data Owner (DO) has the right to access and alter the data. He encrypts the data with the attributes of a specific group and generates the decryption keys for users. Then, he uploads the encrypted data to the cloud servers.
・ Cloud Server (CLD) is responsible for data storage and deploys the data to the fog nodes.
・ Fog Nodes (FNs) are responsible for data storage and for addressing users’ requests. They are considered as a semi-trusted party. They execute operations of user revocation phase.
・ Data Users (Us) are those who request data access when they have the rights to access data. This means, only when the user’s access policy satisfies the data attributes.
The fog environment scenario is shown in Figure 2, where a DO encrypts a data file and then outsources it to a CLD for storage. Then, the CLD deploys the
Figure 2. Fog-based data sharing model.
data file to the specific fog node via the data distribution protocol, as will be shown later. Fog nodes are geographically distributed within a specific domain, and they have fixed locations. The user can be moving, and he is requesting the data from the fog node closest to him. The fog node receives the user’s request and delivers the file to the user. The DO can delegate most of the tasks to the home fog nodes, as shown in the following section. In fog-based data sharing model, fog nodes and the data owner both can be connected with the cloud via the Internet. The fog nodes are connected to each other via a wired network over Internet. The users can be connected with the fog node using a wireless connection technique such as Wi-Fi, as shown in Figure 2.
This model consists of groups of users, and each group has a set of attributes and a basic location. Each group has many users who share the same attributes. One of the group attributes refers to its location, and group members connect with a fog that has the same location. The data owner assigns many files to each group on the basis of the attributes and needs of its members.
Each fog node serves one group, and is independent in its operation, so it is not affected when a user is revoked from another group. Therefore, the proposed revocation mechanism requires the re-encryption of the affected files and the updating of the secret keys, only for a one group.
3.2. Data Distribution Protocol
Two types of fog in the data distribution architecture are defined:
・ Home Fog (HF): the fog has the same location as the user’s original location, where users are most likely to be found. It stores the user’s data and manages the processes.
・ Foreign Fog (FF): the fog is located away from the user’s original location, where the user is currently residing, as shown in Figure 3.
・ The proposed system is comprised of two kinds of data centers:
・ Cloud data centers (which includes the data centers for each group).
・ Local fog data centers.
Each fog node is considered the “Home Fog” for the group that has the member’s same location, while it is considered the “Foreign Fog” for the other groups.
A local data center is a fog storage that holds copies of secret files. It is preloaded with the data required by fog users. The fog nodes maintain communication with the cloud. The data sharing between the cloud data center and each fog node data center is performed through immediate synchronization based on the unicast method.
When the user requests a file from the fog node, if the fog is the user’s HF, the fog node directly sends the file to the user. If the user is away from his/her HF, the case is processed, as shown in Figure 4.
1) Using authentication, a user logs to the fog node closest to him. He requests to join to it and identifies the period of the joined fog node through the registration process.
Figure 3. Data distribution architecture.
Figure 4. Data distribution protocol.
Table 2. Fog1’s users locations.
2) The FF recognizes the user’s home by the system user list (the cloud updates this list whenever a user is added or removed, and sends it to all fog nodes via broadcasting after each update. This list includes the user’s ID and its own HF. (Note: the HF of each user is fixed).
3) The FF sends the joining message with the specified period to the user’s HF.
4) The HF sends an acceptance reply to acknowledge the joining.
5) The FF accepts the user as a visitor, updates its visitor list, and then synchronizes the list with the cloud.
6) The HF updates the location of its own users in the Table 2 by changing the user’s location to the FF’s location and synchronizing it with the cloud. This table does not include the visitor’s users; it is only for its group members.
7) The HF sends the user’s secret data to the FF.
8) The FF stores the data in its data center.
If the time expires and the user is still at the FF, he must join the FF again. When the user returns to his HF, he will send a de-joined request to the HF and inform it that he is at his HF. The FF updates the current location table and synchronizes the table with the cloud.
4. The Proposed System
4.1. Technique Preliminaries
1) Key Policy Attribute-Based Encryption (KP-ABE)
In KP-ABE, data have a set of attributes linked to data by encryption with the public key. Each user has an access structure that is an access tree associated with data attributes. The user’s secret key is a reflection of the user’s access tree; therefore, the user can decrypt a ciphertext if the data attributes match his or her access tree   .
2) Proxy Re-Encryption (PRE)
PRE is a cryptographic primitive that allows a semi-trusted proxy to transform the cipher text of the encrypted data under the data owner’s public key into a different ciphertext under the group member’s public key. The semi-trusted proxy server needs a re-encryption key sent by the data owner for a successful conversion process, and it is unable to discover the underlying plaintext of the encrypted data. Only an authorized user can decrypt the ciphertext  .
4.2. Design Goals
The design goals are as follows:
・ Data confidentiality: Unauthorized users (including the fog and cloud servers) are not allowed to access the data  .
・ Fine-grained access control: The data owner can determine the access structure for each user  .
・ User revocation: Revoked users cannot access the data again.
・ Scalability and efficiency: The system must maintain both efficiency and scalability, even when the number of users increases  .
・ Collusion resistance: which prohibits unauthorized parties from cooperating in order to find out the contents of sensitive data  .
・ Real-time data sharing.
4.3. Assumptions and Security Models
In the proposed framework, the data sharing system is one to many. The fog nodes have fixed locations. It may be assumed that the target user is a laptop or other mobile device. Also, that the data owner and users have already the public/ private key pairs, where the public keys can be easy to get by other entities. Using the security protocols, the communication channels are secured between the data owner/cloud server and fog nodes, such as SSL. Also, the communication channel is assumed to be secured between fog nodes and users. In order to connect between the user and the fog nodes, the existing protocols such as CoAP, are used which are considered to be the promising protocol for IoTs  , in addition to authentication the users at the fog node.
4.4. Definition and Notation
In order access control, the data owner must assign meaningful attributes to each file. The file’s attributes are the same as the one group’s attributes. To update the attributes, each attribute has a version number, which will be shown later. Fog servers have a copy of a group attribute history list (GAtH), as we will see later
The GAtH contains the attributes’ evolution history and the PRE keys used. A PRE-key allows the data owner to assign re-encryption operations to the fog node without revealing the data contents. Additionally, one virtual attribute, denoted by AttV, must be determined for the key’s management. AttV is the basic attribute in every data file’s attributes and user’s access structure, and is will not be updated. The user has a completely secret key, while the fog and cloud have a partially user’s secret key because they lack a secret key component corresponding to a virtual attribute, where that AttV is unknown for the fog and cloud. The goal of AttV is to enable the fog to update the secret key without revealing it.
Each user has an access structure represented as an access tree  . The access tree has interior nodes, which are the threshold gates, and leaf nodes associated with the file’s attributes. The root node must be an AND gate, with one of the child nodes associated with the virtual attribute, while the other child nodes are the threshold gates, as shown in Figure 5.
Figure 5. The simple explain of the access system.
Each group file has the same group attributes, where the members of group have the right to access the group files. Each member has a subset of the group attributes. Each member has a different secret key that reflects his or her access structure. Moreover, CLD has the system users list (UL), which includes the IDs, HF of all the authorized users. Table 3 shows the notation of the proposed system with a simple description.
4.5. System Description
The proposed framework consists of six main phases, the following subsections show details of these phases.
1) Group Creation
The DO creates groups of the system and generates its parameters.
1) The DO assigns a unique , name, , and specific location for the new group.
2) A security parameter is chosen by the DO, and then is run, which produces and .
3) The DO signs components.
4) DO sends the group information and the to the CLD.
5) CLD stores them in data center.
6) The CLD sends to group’s HF.
7) The group’s HF store , each FN serves one group as the HF.
2) Add and Encrypt File
In this phase, the data owner processes the file before uploading as follows.
1) The DO assigns a unique ID for the new file.
Table 3. Notation of the scheme.
Figure 6. The data format.
2) The DO chooses a random data symmetric encryption key ,where refers to the key space.
3) The DO encrypts the file using .
4) DO specifies the group that needs this file.
5) The DO specifies the attributes for this file.
6) The DO encrypts , by calling , which outputs the ciphertext .
7) The DO uploads the encrypted file with the group’s to the CLD.
8) CLD stores them in its data center.
9) The CLD sends the encrypted file to the group’s fog node.
10) The group’s fog node stores the encrypted file in format, as shown in Figure 6.
3) Enroll New User
The data owner performs the following processes to grant the access right to the system.
1) The DO defines a user unique identity w, an access structure and the group, where he belongs.
2) The DO runs the , which produces referring to the secret key of .
3) The tuple is encrypted with the user’s public key by the DO (preloaded); where the ciphertext is denoted as .
4) The DO sends the tuple to the CLD, where (from the third step) and is .
5) The CLD verifies the signature, then stores in the .
6) The CLD sends the and to the user’s HF.
7) The FN stores in its .
8) Then FN sends the to U.
9) The U decrypts the with his or her private key, verifies the signature, and accepts .
4) Delete File
This operation is performed at the DO’s request
1) The DO sends the with his signature to the CLD.
2) The CLD verifies the signature, then removes the file.
3) The CLD sends the to all FNs.
4) FNs remove the file in case it was found in their data centers.
5) Revoke user
Based on the revocation method in  , the proposed system’s revocation operation works as follows.
1) To revoke user ,the DO defines the attributes’ minimal set of:
where pol is v’s access structure.
2) The and components of all these involved attributes are updated accordingly.
3) The DO generates the corresponding PRE keys, for each attribute a in ,
4) The DO sends the user , the updated attributes, the PRE keys, group , andthe updated components to the CLD.
5) The CLD removes the revoked user from the and records the updated in the group’s table.
6) The CLD records the last version of the PRE key in only to the updated attribute (at group’s data center in cloud).
7) The CLD sends the user’s ID, the updated attributes, the PRE keys, andthe updated to the user’s HF.
8) HF store them and remove the revoked user.
9) With , the FN will find one PRE key that can update the attribute to the latest version.
10) For each member of the group, the FN updates this user’s components to the latest version; for each attribute, ;
11) The FN re-encrypts each file’s using the latest version, then stores it; for each attribute ;
12) The FN sends the USKs to users.
13) If it has an away user, HF sends the data and to the user’s FF. Then FF stores the data.
14) The FF sends the to the user.
6) Download and Decrypt File
1) In this operation, fog node receives the user’s access request to the data file.
2) Then FN verifies if the user is a valid user. If the user is not of its members, verifies if the user in its visitor list.
3) The FN sends the C of the requested file to the U.
4) The U checks if each attribute is the latest version of the current version he knows.
5) The U verifies if each components is correct. If the verification is successful, (U) replaces each of his secret key with and updates with .
6) The U runs to decrypt the SEK’s.
7) The U decrypts the file using the SEK’s.
5. Implementation and Evaluation
5.1. Test Environment
The proposed system was implemented on a machine running 64-bit Windows 10 with a 2.4 GHz Intel CoreTM CPU and 6 GB of memory. The system’s implementation is based on a pairing-based cryptography (PBC) library, a standard symmetric key algorithm (AES), key-policy attribute-based encryption, and proxy re-encryption techniques. Our system calls the ABE- and PRE-required functions from libraries developed using the Java language, as we will show the results later. First, we built the main functions of the system: Group creation, Encryption, Key Generation, and Decryption. Then, we designed the user revocation functions: Update the master key and public key, Re-encrypt the files, and Regenerate the secret keys.
5.2. Performance Evaluation
Our performance evaluation is based time analysis in order to appreciate both the suggested protocols dealing with specific security issue “revocation” and the benefits the fog computing brings to the problem. Therefore, we have built our own simulation methods and used available packages.
Figure 7. Time factors of the revocation phase.
first propagation delay ( ). This delay depends on the length of the link and the speed of propagation. The time difference ( ) corresponds to the processing time ( ), which is the time required for the fog node to execute user revocation operations. The second propagation delay ( ). is determined by another time difference ( ).
1) System Response Time
Fast response time is important for improving the quality of service and users’ experience, it is directly related to the distance between the server and user. Fog nodes are located on the network edge, in close proximity to the users, and therefore the system has a fast response time. We can calculate the response time using the following equation:
The term “Propagation Time” refers to the amount of time a packet needs to arrive at its destination. It depends on the distance between the server and user and on propagation speed. Processing time can be broadly defined as the total time that a fog node requires to address a user revocation request after it is received.
In order to appreciate the impact of fog computing on response time, we build a simulation scenario that assumes the fog and cloud computing scenarios have the same resources. Naturally, in the fog computing scenario, we assume that fog resources are placed nearer to users than in the cloud. Those scenarios were implemented using the Cloud Analyst toolkit. The simulation results show that our system responds more quickly to user requests than classical cloud systems, as shown in Figure 8.
In the simulation environment, the data center responds to user requests in order according to their location. The simulation identifies response time as minimum, average, or maximum. In the figure below, we can see that the fog system’s response time is 84% less than that of the cloud system; the average response time was 300 ms in cloud-based systems and 50 ms in fog-based systems.
Regarding processing time, the results in Figure 9 show that the time required to perform an encryption operation (whether in the cloud or a fog) depends directly on the number of attributes that are used, as explained in previous section.
Figure 8. The simulationresults.
Figure 9. KP-ABE encryption.
The figure above shows that processing time for KP-ABE operations increases as the number of attributes increases. Our system groups users according to their attributes; thus, each group has a set of attributes that other groups do not have. There are not many attributes associated with each group. There is a direct relationship between a group’s attributes and processing time. Thus, the number of attributes can be optimized to achieve optimal execution time. In addition, the propagation delay is significant compared to processing time, and therefore the impact of fog computing can be easily appreciated.
2) User Revocation Processing Time
The user revocation process was explained in Section IV. In this section, we will show the impact of group size per fog node on the execution time for the parameters concerned with the revocation process. We can calculate the time required for the user revocation phase as follows:
The process requires that the fog node regenerate secret keys and re-encrypt files during each revocation process. Therefore, we will vary the number of users assigned to each fog node as a percentage of the overall number of users in the system.
First, we assume that there are 50,000 system users and 5000 system files. We also executed these operations on more than size of the fog node (e.g., 5%, 10%, 15%, and 20% of users) as shown in Figure 10 and Figure 11.
It has been shown that as the number of assigned users per fog node decreases, the processing time for key regeneration and file re-encryption decreases significantly in an order of about 25% as we move from one fog size to the next lesser one.
Although the reduction is significant but this could be translated in real life as adding more fog nodes at user’s vicinity which could be considered as a trade off problem. In addition, our comparison of key regeneration time and file re-en- cryption time clearly shows that regeneration requires more processing time than re-encryption, which emphasizes that key regeneration is the dominant factor in the revocation process.
To compare our system to a cloud -based data-sharing system, we set up an experiment. The data in Table 4 shows that our system reduced the processing time required for key regeneration compared to the cloud system by about 80% (based on our setup) thanks to the fog computing architecture.
Figure 10. Secret keys updating on fog node.
Figure 11. The re-encryption of files on fog node.
Table 4. Secret key updating.
Table 5. The files re-encryption.
Table 6. Revocation time.
To further demonstrate the benefit of our system, we compare the performance of cloud and fog setups with respect to the maximum number of reencryption operations per group. It is obvious that we get a better re-encryption time, as the number of the group files reduced in the fog architecture comparing to the entire cloud system files, as shown in Table 5. This is a direct result of the file distribution strategy suggested in Section 3.
3) Overall Delay Estimation Due to Revocation
Revocation time refers to the time required to regenerate secret keys and re-encrypt files during each revocation process. Based on the tables and equation above, we can calculate and compare the total time required for the revocation operation in fog and cloud systems. Table 6 shows that we achieved better revocation time compared to the cloud system; the results indicate that our system was 80% better.
Our system responds to user requests more quickly than do classical cloud systems. As we have proven previously, the response time of a fog system is 84% less than that of a cloud system because the fog is located close to the users. The findings demonstrated the feasibility of our system, as the computation-related complexity of the system’s operations does not depend on the number of users in the system, but on the number of system attributes, and is thus scalable.
The experimental results show that our revocation mechanism outperforms cloud-based systems as this phase is at the fog level in our system and thus does not affect the entire system. Also, our system requires 80% less processing time for key regeneration compared to the cloud system due to the fog computing architecture.
When comparing the performance between cloud and fog setups with respect to the maximum number of re-encryption operations, it is obvious that we get a better re-encryption time, as the number of the group files reduced in the fog architecture comparing to the entire cloud system files. Further, our system has 80% better revocation time compared to the cloud-based system.
Based on the previous discussion, our revocation mechanism outperforms cloud-based systems, and the proposed framework is a promising solution for data sharing in the emerging fog computing environment.
6. Security Analysis
We first analyze security of our framework in terms of the security features as formulated below.
6.1. Data Confidentiality
The data owner assigns the management of the data to the fog nodes and CLDs, which are considered the main adversaries against data confidentiality. They are a bigger threat than unauthorized users because of their adversarial capabilities. The fog nodes have the encrypted data and the responses to the authorized users from addressing their requests.
To achieve data confidentiality, the data owner encrypted the file using by AES algorithm, and is encrypted using KP-ABE, before uploading it. Thus, fog nodes cannot have access to plaintext. In addition, they have only a partial copy of the user’s secret keys and lack the SEK key. To achieve data confidentiality in transmission, the communication channels are secured between the data owner/cloud server and the fog nodes using SSL/TLS protocol to overcome network attacks  .
6.2. Fine-Grained Access Control
The data owner must have access control over his or her secret data, meaning that a valid user cannot obtain unauthorized data. The enforcement of fine-grained access control is achieved using (KP-ABE), which provides a flexible access structure for each user based on data attributes  .
6.3. User Revocation
When an authorized user is revoked, his access right is dropped, and he is considered an outsider. The revocation operation requires the re-encryption of the files and a re-distribution of the new keys at one fog  .
The proposed user revocation process is achieved by using the PRE technique. This reduces the data owner’s burden and assigns most of the tasks to the fog node, which permits the fog node to re-encrypt the data automatically without discovering the file’s contents.
6.4. Collusion Resistance
To protect against collusion, parties must not be permitted to access the data without authorization from the data owner. To prevent collusion between servers and any party, the system must protect the users’ access privilege information against the cloud and fog nodes by encrypting the user’s access structure before sending it.
To prevent collusion between users, the system is a set of groups, and each group has a different public key ( ); thus, users of different groups cannot combine their secret keys and decrypt files they should not be allowed to access  .
7. Conclusions and Future Work
The aim of the present study was to design a secure data sharing framework for a fog environment. This framework achieved fine-grained access control, data confidentiality, user revocation, and collusion resistance. Our proposed framework rests on a combination of KP-ABE and PRE-techniques. The contribution of the study was the confirmation that our system outperformed the cloud-based data sharing architecture. Our framework provides high scalability and data sharing in real time and with low latency.
The findings of this study indicate that our system outperforms cloud-based data sharing systems with its faster processing time. The simulation results also show that our system responds faster to user requests than classical cloud systems. Further, the experimental results show that our system also outperforms cloud-based systems in the user revocation phase. In this paper, we proved that our proposed framework provides a promising solution to securing data sharing in the emerging fog computing environment. A future study addressing a many-to-many data sharing application in a fog environment would thus be interesting.