A Secure and Verifiable Outsourced Access Control Scheme in Fog-Cloud Computing

With the rapid development of big data and Internet of things (IOT), the number of networking devices and data volume are increasing dramatically. Fog computing, which extends cloud computing to the edge of the network can effectively solve the bottleneck problems of data transmission and data storage. However, security and privacy challenges are also arising in the fog-cloud computing environment. Ciphertext-policy attribute-based encryption (CP-ABE) can be adopted to realize data access control in fog-cloud computing systems. In this paper, we propose a verifiable outsourced multi-authority access control scheme, named VO-MAACS. In our construction, most encryption and decryption computations are outsourced to fog devices and the computation results can be verified by using our verification method. Meanwhile, to address the revocation issue, we design an efficient user and attribute revocation method for it. Finally, analysis and simulation results show that our scheme is both secure and highly efficient.


Related Work
In 2007, Bethencourt et al. [11] put forward the first CP-ABE scheme. Over the last decade, many CP-ABE schemes [12][13][14][15][16][17] were proposed. However, most of them are time-consuming and lack efficiency. To improve the efficiency and reduce the overhead of users, several schemes which support outsourced computation and revocation are proposed:

Outsourced Computation
Green et al. [18] proposed an outsourcing decryption ABE scheme. In their scheme, the traditional private keys are divided into user keys and transformation keys. Thus, complex decryption computations are outsourced to the cloud server, and users only need one exponentiation operation to recover the plaintext. However, their scheme cannot be applied to multi-authority systems. Based on this method, Yang et al. [19,20] put forward two multi-authority CP-ABE schemes which support outsourced decryption. Li et al. [21] also proposed an outsourced ABE scheme which supports both outsourced key-issuing and decryption. However, they did not consider the correctness of results from the cloud server.
To solve this problem, Lai et al. [22] introduced the verifiability of ABE and proposed a verifiable outsourced decryption ABE scheme. But in their scheme, both the length of the ciphertext and the computational of encryption are doubled. Later, Li et al. [23] presented an outsourcing ABE scheme with checkability which supports both outsourced key-issuing and decryption. However, the length of ciphertext and the amount of expensive pairing computations grow with the number of attributes.
To address this problem, two ABE schemes [24,25] in which the length of ciphertext is constant are put forward. However their constructions cannot be applied to ABE schemes with Linear Secret Sharing Schemes (LSSS). Mao et al. [26] proposed a generic construct of attribute-based encryption with verifiable outsourced decryption. Their CPA-secure construct has more compact ciphertext and

Revocation
Ostrovsky et al. [27] first proposed a fine-grained user revocation scheme based on CP-ABE that supports negative clauses. With the help of a semi-trusted service provider, Ibraimi et al. [28] put forward a CP-ABE scheme which achieved immediate attribute revocation for the first time, but their construct cannot be applied to an outsourcing environment. Yu et al. [29] presented a CP-ABE scheme where proxy encryption technology was introduced. The scheme achieves immediate attribute revocation, at the same time, the proxy server also share the authority job, hoowever, the proxy server needs to be online all the time. Another CP-ABE scheme with fine-grained attribute revocation was put forward by Hur et al. [30]. They use attribute group keys to re-encrypt the ciphertext, but their scheme cannot prevent collusion attacks. Another revocable CP-ABE scheme was proposed by Xie et al. [31]. In their scheme, the key update computations are greatly reduced. Later, Yang et al. [32] put forward a proxy-assisted CP-ABE scheme which provides efficient cloud data sharing and user revocation.

Our Contribution
In this paper, we propose a verifiable outsourced multi-authority access control scheme, named VO-MAACS. In our construct, most of the encryption and decryption computation is outsourced to fog devices and the computation results can be verified by using our verification method. Meanwhile, to address the revocation issue, we design an efficient user and attribute revocation method for it. Our contributions can be summarized as follows: (1) We propose the verifiable outsourced multi-authority access control scheme (VO-MAACS), which is secure against collusion attacks. Most of the encryption and decryption computation is outsourced to fog devices, which greatly reduces the computation on the user side. (2) We provide a verification method for the outsourced encryption and decryption. If a fog device returns incorrect results, users can notice it immediately by running the corresponding verification algorithm. (3) We design an efficient user and attribute revocation method for our scheme. During the process of attribute revocation, most of the update and re-encryption operations are outsourced to the cloud server, and only a few components which are associated with the revoked attribute need to be updated, while the other components are not changed. (4) We provide a security and performance analysis of our scheme, which shows that our scheme is both secure and highly efficient.

Organization
The remainder of this paper is organized as follows: we first give some preliminaries in Section 2. Then, we give the definition of the system model and framework in Section 3. In Section 4, we propose our VO-MAACS construct. Section 5 describes the security and performance analysis of our scheme. Finally, the conclusions are given in Section 6.

Bilinear Maps
(3) Computability: there is an efficient algorithm to compute e(g 1 , g 2 ) for any g 1 ∈ G 1 and g 2 ∈ G 2 .

Access Structure
Definition 2. (Access Structure [33]). Let {P 1 , P 2 , · · · , P n } be a set of parties. A collection A ⊆ 2 {P 1 ,P 2 ,··· ,P n } is monotone if ∀B, C: if B ∈ A and B ⊆ C then C ∈ A. An access structure (respectively, monotone access structure) is a collection (respectively, monotone collection) A of non-empty subsets of {P 1 , P 2 , · · · , P n }, i.e., A ⊆ 2 {P 1 ,P 2 ,··· ,P n } \{φ}. The sets in A are called the authorized sets, and the sets not in A are called the unauthorized sets.

Linear Secret Sharing Schemes
Definition 3. (Linear Secret-Sharing Schemes (LSSS) [33]). We recall the description of LSSS as follows [33]. Let Π be a secret sharing scheme over a set of parties P with realizing an access structure A. We say that Π is a linear secret sharing scheme over Z p if: (1) The piece for each party forms a vector over Z p .
(2) During the generation of the pieces, the dealer chooses independent random variables, denoted r 2 , · · · , r n , each one distributed uniformly over Z p . Each coordinate of the piece of every party is a linear combination of r 2 , · · · , r n and the secret s. That is, let M denotes a matrix with l rows and n columns.
For the vector → v T = (s, r 2 , · · · , r n ) and any authorized set, there exist constants w i ∈ Z p i∈I such that, if {λ i } are valid shares of any secret s according to Π, then ∑ i∈I

System Model and Framework
In this section, the system model and framework of our scheme are described.

System Model
A simple three level hierarchy is adopted in our fog-cloud system as illustrated in Figure 1. In this framework, each terminal device is connected to a nearby fog device. Fog devices are interconnected and each of them is linked to the cloud.

Linear Secret Sharing Schemes
Definition 3. (Linear Secret-Sharing Schemes (LSSS) [33]). We recall the description of LSSS as follows [33]. Let Π be a secret sharing scheme over a set of parties  with realizing an access structure  . We say that Π is a linear secret sharing scheme over p  if: (1) The piece for each party forms a vector over p  .
(2) During the generation of the pieces, the dealer chooses independent random variables, denoted

System Model and Framework
In this section, the system model and framework of our scheme are described.

System Model
A simple three level hierarchy is adopted in our fog-cloud system as illustrated in Figure 1. In this framework, each terminal device is connected to a nearby fog device. Fog devices are interconnected and each of them is linked to the cloud. In general, a layer of fog is added between the cloud server and terminal devices so that some computations on the cloud server can be delegated to the fog devices which are closer to the terminal devices. Thus, different tasks from different regions can be executed by the corresponding fog devices In general, a layer of fog is added between the cloud server and terminal devices so that some computations on the cloud server can be delegated to the fog devices which are closer to the terminal devices. Thus, different tasks from different regions can be executed by the corresponding fog devices simultaneously, which greatly improves the efficiency. Fog devices are responsible for data transmission and data storage. Moreover, they are also in charge of part of the encryption and decryption computations. The cloud server is responsible for storing the ciphertext and the user proxy keys, as well as the ciphertext re-encryption operations and user proxy keys update operations when revocation occurs.
Our multi-authority fog-cloud system consists of six entities: a cloud service provider (CSP), fog devices (FDs), a global certificate authority (CA), attribute authorities (AAs), data owners (DOs) and data users (DUs), as shown in Figure 2. simultaneously, which greatly improves the efficiency. Fog devices are responsible for data transmission and data storage. Moreover, they are also in charge of part of the encryption and decryption computations. The cloud server is responsible for storing the ciphertext and the user proxy keys, as well as the ciphertext re-encryption operations and user proxy keys update operations when revocation occurs. Our multi-authority fog-cloud system consists of six entities: a cloud service provider (CSP), fog devices (FDs), a global certificate authority (CA), attribute authorities (AAs), data owners (DOs) and data users (DUs), as shown in Figure 2.  CA is a fully trusted global certificate authority in the system. It accepts the registration of all AAs and DUs in the system, and it is responsible for issuing a global unique identity uid for each DU and a unique identity aid for each AA. However, it does not participate in any attribute management and any generation of secret keys associated with attributes.
Each AA is an independent attribute authority that is responsible for issuing, revoking and updating users' attributes within its administration domain. In our scheme, each AA is responsible for generating a public attribute key x PK for each attribute it manages and a user private key which consists of user proxy key PxK and user secret key SK for each DU. Especially, PxK is stored at CSP and SK is kept by DU.
DOs define access control policies over attributes from multiple attribute authorities and then encrypts the data following those policies. After that, they upload the encrypted data to the CSP.
The CSP is responsible for storing the ciphertext and the user proxy keys, and provides data access service to DUs. It is also in charge of the ciphertext re-encryption operations and user proxy key update operations when revocation occurs.
FDs are responsible for data transmission and data storage. Moreover, they are also in charge of part of the encryption and decryption computations. They can help generate part of the ciphertext for DOs, as well as decrypt part of the ciphertext for DUs. Only for those DUs whose attributes satisfy the access policy will FDs decrypt the ciphertext with their proxy keys. After that, they send the partially decrypted data to the corresponding DUs.
DUs can request their secret keys from the relevant authorities. After downloading any encrypted data from the CSP, a DU first asks a FD to decrypt it with his proxy key. If the attribute set of the DU meets the access policy, then the FD decrypts the ciphertext and sends the partially CA is a fully trusted global certificate authority in the system. It accepts the registration of all AAs and DUs in the system, and it is responsible for issuing a global unique identity uid for each DU and a unique identity aid for each AA. However, it does not participate in any attribute management and any generation of secret keys associated with attributes.
Each AA is an independent attribute authority that is responsible for issuing, revoking and updating users' attributes within its administration domain. In our scheme, each AA is responsible for generating a public attribute key PK x for each attribute it manages and a user private key which consists of user proxy key PxK and user secret key SK for each DU. Especially, PxK is stored at CSP and SK is kept by DU.
DOs define access control policies over attributes from multiple attribute authorities and then encrypts the data following those policies. After that, they upload the encrypted data to the CSP.
The CSP is responsible for storing the ciphertext and the user proxy keys, and provides data access service to DUs. It is also in charge of the ciphertext re-encryption operations and user proxy key update operations when revocation occurs.
FDs are responsible for data transmission and data storage. Moreover, they are also in charge of part of the encryption and decryption computations. They can help generate part of the ciphertext for DOs, as well as decrypt part of the ciphertext for DUs. Only for those DUs whose attributes satisfy the access policy will FDs decrypt the ciphertext with their proxy keys. After that, they send the partially decrypted data to the corresponding DUs. DUs can request their secret keys from the relevant authorities. After downloading any encrypted data from the CSP, a DU first asks a FD to decrypt it with his proxy key. If the attribute set of the DU meets the access policy, then the FD decrypts the ciphertext and sends the partially decrypted data to the DU. Upon receiving the partially decrypted data from the FD, the DU can recover the data with his secret key.
In our multi-authority fog-cloud system, we assume that the CA is fully trusted in the system. Each AA is also trusted, but it can be corrupted by an adversary. The CSP and FDs are semi-trusted. They may leak the encrypted data to some malicious users, but will execute the tasks assigned by each authority. DUs are assumed dishonest and may collude to obtain unauthorized access to data.

Definition 4. (VO-MAACS: Verifiable Outsourced Multi-Authority Access Control Scheme).
Global Setup (λ, U) → {GP, uid, aid} . The global setup algorithm is run by CA. On input the security parameter λ and attribute universe description U, it outputs the global parameter GP, the user identity uid and the authority identity aid.
Authority Setup (aid) → PK aid , SK aid , PK x k aid∈I A . The authority setup algorithm is run by each authority. On input of the authority identity aid, it outputs public attribute keys PK x k aid∈I A for all attributes issued by each authority and a pair of authority public key PK aid and authority secret key SK aid . Here I A denotes the involved authority set.
Encrypt_out (GP, PK x k aid∈I A ) → CT out . The outsourced encryption algorithm is run by the FD. On input of the global parameter GP and a set of public attribute keys PK x k aid∈I A , it outputs the partially encrypted ciphertext CT out .
Verify_enc (GP, CT out ) → b . The outsourced encryption verification algorithm is run by a DO. On input of the global parameter GP and a partially encrypted ciphertext CT out , it outputs a bit b ∈ {0, 1}, b = 1 indicates the FD outputs the correct result, b = 0 indicates the FD outputs the incorrect result.
Encrypt_user (GP, PK aid , PK x k aid∈I A , CT out , M, (A, ρ)) → CT . The user encryption algorithm is run by a DO. On input of the global parameter GP, a set of authority public keys PK aid , a set of public attribute keys PK x k aid∈I A , a partially encrypted ciphertext CT out , a message M and an access structure A, it outputs the ciphertext CT.
KeyGen (GP, uid, S uid,aid , SK aid , PK x k aid∈I A ) → PxK uid,aid , SK uid . The key generation algorithm is run by each authority. On input of the global parameter GP, the user identity uid, a set of user attributes S uid,aid , the authority secret key SK aid , and a set of attribute public keys PK x k aid∈I A , it outputs user proxy key PxK uid,aid and user secret key SK uid .
Decrypt_out (GP, CT, PxK uid,aid , PK x k aid∈I A ) → CT . The outsourced decryption algorithm is run by a FD. On input of the global parameter GP, the proxy keys PxK uid,aid and the ciphertext CT, it outputs the partially decrypted ciphertext CT .
Verify_dec (GP, CT, CT ) → b . The outsourced decryption verification algorithm is run by a DU. On input of the global parameter GP, the ciphertext CT and a partially decrypted ciphertext CT , it outputs a bit b ∈ {0, 1}, b = 1 indicates the FD has output the correct result, b = 0 indicates the FD has output the incorrect result.
Decrypt_user (CT, CT , SK uid ) → M . The user decryption algorithm is run by a DU. On input of the ciphertext CT, the partially decrypted ciphertext CT and the user secret key SK uid , it outputs the message M.
URev (uid, L PxK ) → L PxK . The user revocation algorithm is run by the CSP. On input of the revoked user identity uid and the proxy key list L PxK , it outputs the updated proxy key list L PxK .
ReKeyUpdate (uid, PxK uid,aid , v x k ) → VUK x k , PxUK x k . The key update algorithm is run by the involved authorities. On input of the uid of each non-revoked user, the proxy key PxK uid,aid and the current attribute version key v x k , it outputs the version update key VUK x k and the proxy update key PxUK x k .
CTUpdate (VUK x k , CT out ) → CUK x k . The ciphertext update algorithm is run by a DO. On input of the version update key VUK x k and the partially encrypted ciphertext CT out , it outputs the ciphertext update key CUK x k . PxKUpdate (uid, PxK uid,aid , PxUK x k ) → PxK * uid,aid . The proxy key update algorithm is run by the CSP. On input of the uid of each non-revoked user, the current proxy key PxK uid,aid and the proxy update key PxUK x k , it outputs a new proxy key PxK * uid,aid for each non-revoked user who has the attribute x k . ReEnc (CT, CUK x k ) → CT * . The re-encryption algorithm is run by the CSP. On input of the current ciphertext CT and the ciphertext update key CUK x k , it outputs a new ciphertext CT * .

VO-MAACS: Verifiable Outsourced Multi-Authority Access Control Scheme
In this section, we give the concrete construction of VO-MAACS which is based on [14], together with the verification method and revocation scheme.

Construction of VO-MAACS
Global Setup (λ, U) → {GP, uid, aid} . The global setup algorithm takes a security parameter λ and a small attribute universe description U as input. Let G 1 , G 2 and G T be the multiplicative groups with the same prime order p, and e : G 1 × G 2 → G T be the bilinear map. Let g 1 be the generator of G 1 and g 2 be the generator of G 2 . Let G : G T → Z p be a hash function and H : {0, 1} * → Z p be a hash function which maps attributes to an element in G 2 , such that the security will be modeled in the random oracle. CA then chooses a random number a ∈ Z p and sets the global parameter as GP = p, G 1 , G 2 , G T , e, g 1 , g 2 , g a 2 , H, G . Each authority, fog device and user should register itself with the global authority during the global setup process. CA then assigns a unique global authority identity aid to each legitimate authority and a unique global user identity uid to each legitimate user.
Authority Setup (aid) → PK aid , SK aid , PK x k aid∈I A . Let S A aid denote the set of all attributes managed by AA aid and I A denote the involved authority set. AA aid first chooses two random exponents α aid , β aid ∈ Z p . For each attribute x k ∈ S A aid , AA aid chooses an attribute version key as VK x k = v x k and generates the public attribute keys as PK x k aid∈I . Then it publishes PK aid = e(g 1 , g 2 ) α aid as its public key and keeps SK aid = {α aid , β aid } as its secret key.
Encrypt_user (GP, PK aid , PK x k aid∈I A , CT out , M, (A, ρ)) → CT . Let A be a l × n matrix, where l denotes the total number of all the attributes. The function ρ maps rows of the matrix A to attributes. DO first chooses a random secret exponent s ∈ Z p and a random vector → v = (s, y 2 , · · · , y n ) ∈ Z n p with s as its first entry, where y 2 , · · · , y n are used to share the secret exponent s. For i = 1, · · · , l, it computes where A i is the vector corresponding to the i-th row of A. After that, it randomly chooses γ 1 , γ 2 , · · · , γ l ∈ Z p and computes: C , C i,3 , C i,4 are used to correct the shares of s and randomize γ i .
C v is used to verify the result of outsourced decryption.
Then, it outputs the intact ciphertext KeyGen (GP, uid, S uid,aid , SK aid , PK x k aid∈I A ) → PxK uid,aid , SK uid . AA aid first assigns a set of attributes S uid,aid to each legal user, then chooses a random number z uid ∈ Z p for each user and let The proxy keys PxK uid,aid are sent to CSP who will add them in its proxy key list L PxK as L PxK = L PxK ∪ uid, PxK uid,aid , and the user secret keys are sent to the corresponding DUs.
Decrypt_out (GP, CT, PxK uid,aid , PK x k aid∈I A ) → CT . When a user queries the encrypted data in the system, CSP will first check his attribute set. If his attributes does not satisfy the access policy, CSP outputs ⊥. Otherwise, it sends the ciphertext and the corresponding proxy keys to FD. FD first chooses a set of constants w i ∈ Z p such that, if λ i are valid shares of the secret s according to A, then ∑ i∈I w i λ i = s, where I = {1, · · · , l}. Then it computes: After that, FD sends the partially decrypted ciphertext CT = e(g 1 , g 2 ) ∑ k∈I A α k s z j to the user.
Decrypt_user (CT, CT , SK uid ) → M . Upon receiving the partially decrypted ciphertext from FD, the user runs the user decryption algorithm to decrypt the ciphertext by using its secret key SK uid . It computes M as:

Verification Method
There exists such a situation that the FD may be "lazy". It may not follow the algorithm, only execute part of the computations or deliberately returns incorrect results. If this happens, a DO cannot notice the error, and large part of the computations will be affected. Therefore, we propose a verification method which can verify the result of outsourced encryption and outsourced decryption.
Our verification method includes two algorithms: Verify_enc (GP, CT out ) → b . Upon receiving the partially encrypted ciphertext CT out from FD, DO first verify whether C 0 = g s holds. If it does not holds, DO outputs b = 0, which indicates FD returns incorrect result. Otherwise, DO computes t i = (aλ i − v ρ(i) ·γ i − H(ρ(i))·γ i )modp and C i = , · · · , l}. Then, it picks a security parameter r, and randomly chooses s 1 , · · · , s l ∈ {0, 1} r . After that, it computes Here, we adopt the idea of [34]. We do not check the results in the ciphertext one by one. Instead, we use the batch verification algorithm to check C i,1 , C i,2 together. Obviously, our solution is much more efficient than the normal verification method.
Verify_dec (GP, CT, CT ) → b . Upon receiving the partially decrypted ciphertext CT from FD, the user computes G(CT z uid ), if G(CT z uid ) = C v holds, it outputs b = 1, which indicates FD returns the correct result. Otherwise, it outputs b = 0, which indicates that the FD has returned an incorrect result.

User Revocation
In our scheme, when user revocation happens, we do not need to re-encrypt the ciphertext and update other non-revoked users' secret keys. The only operation we need is to send a user revocation message which contains the uid of the revoked user to the CSP, and then let the CSP delete the revoked user's proxy key PxK uid,aid . Without the correct PxK uid,aid , the FD cannot perform the outsourced decryption algorithm for the revoked user. Thus, the revoked user cannot recover the original data. The user revocation algorithm is described as follows: URev (uid, L PxK ) → L PxK . When the CSP receives the user revocation message from a DO, it then deletes the proxy key PxK uid,aid corresponding to the uid from the list and outputs the updated proxy key list L PxK .

Attribute Revocation
There are two phases in attribute revocation: Key update and Ciphertext re-encryption. Phase 1: Key update The key update in turn includes three steps: RekeyUpdate, CTUpdate and PxKUpdate.
Let uid denotes all other non-revoked users except the revoked user with uid . The involved authority AA aid first generates a new attribute version key v x k . It then computes the version update key as VUK x k = v x k − v x k . After that, it applies VUK x k to compute the proxy update key as PxUK x k = g β aid z uid ·VUK x k 2 for each non-revoked user who has the attribute x k . Then AA aid updates the public attribute key of the revoked attribute as PK * x k = PK x k ·g VUK x k 2 , and broadcast a message for each DO such that they can get the updated public attribute key of the revoked attribute. After that, PxUK x k is sent to the CSP to update PxK uid,aid and VUK x k is sent to the DO.
Upon receiving the version update key VUK x k and the partially encrypted ciphertext CT out , DO computes the ciphertext update key as CUK x k = g −γ i ·AUK x k 2 . Then, CUK x k is sent to the CSP to update the ciphertext.
(3) PxKUpdate (uid, PxK uid,aid , PxUK x k ) → PxK * uid,aid . Upon receiving the proxy update key PxUK x k , CSP updates the corresponding proxy keys as K * x= x k ,uid = K x= x k ,uid ·PxUK x k for each non-revoked user who has the attribute x k . Then the proxy keys PxK uid,aid are updated as: Phase 2: Ciphertext re-encryption ReEnc (CT, CUK x k ) → CT * .
Upon receiving the ciphertext update key CUK x k , CSP updates the corresponding ciphertext as C * i,1 = C i,1 ·CUK x k . Then the new ciphertext CT * is published as: Apparently, we can conclude that most of the update and re-encryption work is outsourced to the CSP, which greatly reduces the overhead of DOs. Meanwhile, we do not need to update the entire ciphertext and user proxy keys. Only those components which are involved with the revoked attribute need to be updated. In this way, our scheme can greatly improve the efficiency of attribute revocation.

Analysis of Our Scheme
In this section, a comprehensive analysis of VO-MAACS is provided, including security analysis and performance analysis.

Correctness
The correctness of our scheme can be easily proved by the following equations: When there is no attribute revocation: When the attribute x k is revoked from a user whose identity is uid: ,L uid,aid )·e((C i,2 ·g Therefore: Then: Therefore, VO-MAACS satisfies correctness.

Data Confidentiality
In our system, only for users whose attributes satisfy the access policy, will the FD decrypt the ciphertext for them by using their proxy keys. Users whose attributes do not satisfy the access policy, cannot receive the partially decrypted ciphertext from the FD. Thus, they are not able to recover the original data. When a user is revoked, his proxy key will be deleted by the CSP. Without the proxy key, he cannot obtain the partially decrypted ciphertext either. Therefore, for users whose attributes do not satisfy the access policy, our solution satisfies the data confidentiality.
In addition, although the CSP and FD can get user proxy keys, however, if they do not obtain the user secret keys, they still cannot decrypt the ciphertext. Similarly, they cannot collude with other users to recover the data either. Therefore, for the CSP and FD, our solution also satisfies the data confidentiality.

Collusion tolerance
In our system, each user is assigned with a unique identity uid, and each key issued by different AA is associated with a uid. Therefore, only the keys associated with the same uid can be used to decrypt the ciphertext. Other users cannot collude to decrypt the ciphertext. In addition, there exists a situation that some AAs may issue the same attributes. Since each AA has a unique identity aid, all attributes are distinguishable. Therefore, users cannot replace some of the components in the keys from the AA by using the component in the key from another AA.

Performance Analysis
We implement our scheme in Charm [35], a framework developed to facilitate the rapid prototyping of cryptographic schemes and protocols. It is based on the Python language which allows the programmer to write code similar to the theoretical implementations. Charm also provides routines for applying and using LSSS schemes needed for Attribute-Based systems. All our implementations are executed on an Intel ® Pentium ® CPU G630@270 GHz with 4.00 GB RAM running Ubuntu14.04 64-bit system and Python 2.7.
In our experiment, access policies are generated in the form of a 1 , a 2 , . . . , a n , where a i is an attribute. We set 20 distinct access policies in this form with N increasing from 20 to 200, and repeat each instance 20 times and take the average values as the experiment results. We simulate the computing time incurred in encryption and decryption. Since our scheme is based on Lewko's scheme [14], we compare our scheme with [14] in user encryption time and user decryption time. In our experiments, the number of attributes per authority is set to 10. The times for outsourced encryption are shown in Figure 3a In Figure 3a, the Encrypt_out time is approximately 0.1~1.4 s, and it increases almost linearly with the number of attributes. In Figure 3b, since major computations are outsourced to the FDs, only a few operations are left for DOs. Therefore, the Encrypt_user time in our scheme is much less than that in [14]. Similarly, Figure 4 describes the time for outsourced decryption and user decryption. In Figure 4a, the Decrypt_out time is approximately 0.3~3 s, and like the Encrpyt_time, it also increases linearly with the number of attributes. In Figure 4b, as major computations are outsourced to FDs, only a few operations are left for DUs, therefore, the Decrypt_user time in our scheme is much less than that in [14].  The computing cost for verification of outsourced encryption is shown in Figure 5. The time for Verify_enc is approximately 0.1~0.8 s and it increases almost linearly with the number of attributes. Figure 6 describes the comparison of computing cost of CSP, AA and DO in the attribute revocation process. In Figure 3a, the Encrypt_out time is approximately 0.1~1.4 s, and it increases almost linearly with the number of attributes. In Figure 3b, since major computations are outsourced to the FDs, only a few operations are left for DOs. Therefore, the Encrypt_user time in our scheme is much less than that in [14]. Similarly, Figure 4 describes the time for outsourced decryption and user decryption. In Figure 4a, the Decrypt_out time is approximately 0.3~3 s, and like the Encrpyt_time, it also increases linearly with the number of attributes. In Figure 4b, as major computations are outsourced to FDs, only a few operations are left for DUs, therefore, the Decrypt_user time in our scheme is much less than that in [14]. In Figure 3a, the Encrypt_out time is approximately 0.1~1.4 s, and it increases almost linearly with the number of attributes. In Figure 3b, since major computations are outsourced to the FDs, only a few operations are left for DOs. Therefore, the Encrypt_user time in our scheme is much less than that in [14]. Similarly, Figure 4 describes the time for outsourced decryption and user decryption. In Figure 4a, the Decrypt_out time is approximately 0.3~3 s, and like the Encrpyt_time, it also increases linearly with the number of attributes. In Figure 4b, as major computations are outsourced to FDs, only a few operations are left for DUs, therefore, the Decrypt_user time in our scheme is much less than that in [14].  The computing cost for verification of outsourced encryption is shown in Figure 5. The time for Verify_enc is approximately 0.1~0.8 s and it increases almost linearly with the number of attributes. Figure 6 describes the comparison of computing cost of CSP, AA and DO in the attribute revocation process. The computing cost for verification of outsourced encryption is shown in Figure 5. The time for Verify_enc is approximately 0.1~0.8 s and it increases almost linearly with the number of attributes. Figure 6 describes the comparison of computing cost of CSP, AA and DO in the attribute revocation process.
The computing cost for verification of outsourced encryption is shown in Figure 5. The time for Verify_enc is approximately 0.1~0.8 s and it increases almost linearly with the number of attributes. Figure 6 describes the comparison of computing cost of CSP, AA and DO in the attribute revocation process.  In fact, most computing overhead, such as proxy keys update and ciphertext re-encryption are outsourced to the CSP, and only a few computations are left for AAs and DOs. Therefore, the computing cost for DOs can be greatly reduced. Apparently, our scheme requires less time for both encryption and decryption than Lewko's scheme, and the computing cost for DOs in the attribute revocation process is greatly reduced. Therefore, we can conclude that our scheme's computation efficiency is much better than that of Lewko's scheme.

Conclusions
To realize data access control in fog-cloud computing system, we have proposed a verifiable outsourced multi-authority access control scheme, named VO-MAACS. In our construct, most encryption and decryption computations are outsourced to fog devices and the computation results can be verified by using our verification method. Meanwhile, to address the revocation issue, we designed an efficient user and attribute revocation method for this. Finally, the analysis and simulation results show that our scheme is both secure and highly efficient. In fact, most computing overhead, such as proxy keys update and ciphertext re-encryption are outsourced to the CSP, and only a few computations are left for AAs and DOs. Therefore, the computing cost for DOs can be greatly reduced. Apparently, our scheme requires less time for both encryption and decryption than Lewko's scheme, and the computing cost for DOs in the attribute revocation process is greatly reduced. Therefore, we can conclude that our scheme's computation efficiency is much better than that of Lewko's scheme.

Conclusions
To realize data access control in fog-cloud computing system, we have proposed a verifiable outsourced multi-authority access control scheme, named VO-MAACS. In our construct, most encryption and decryption computations are outsourced to fog devices and the computation results can be verified by using our verification method. Meanwhile, to address the revocation issue, we designed an efficient user and attribute revocation method for this. Finally, the analysis and simulation results show that our scheme is both secure and highly efficient.