Abstract
Mobile crowdsensing enables people to collect and process a massive amount of information by using social resources without any cost on sensor deployment or model training. Many schemes focusing on the problems of task assignment and privacy preservation have been proposed so far. However, the privacy-preserving of requesters and task access control, which are vital to mobile crowdsensing, is barely considered in the literature. To address the aforementioned issues, a fine-grained task access control system for mobile crowdsensing is proposed. In particular, the requester can decide the group of task performers who can access the task by utilizing attribute-based encryption technology. T he untrusted crowdsensing platform cannot obtain any sensitive information concerning the requester or the task, while the qualified task performers are capable of retrieving tasks within 0.85 ms. Security analysis and experimental results are presented to show the feasibility and efficiency of the proposed system.
1. Introduction
The evolution of mobile device promotes a new sensing paradigm called mobile crowdsensing. Integrated with a set of powerful sensors (e.g., camera, recorder, and GPS), the mobile device is capable of collecting different kinds of information for specific purposes [1]. Formally, mobile crowdsensing refers to a group of mobile users being coordinated to perform large-scale sensing tasks over urban environments by using their mobile devices [2]. Figure 1 shows a typical workflow of mobile crowdsensing. As we can see, there are three kinds of participants: the requester, the crowdsensing platform, and the task performer. The process of mobile crowdsensing consists of eight stages: design task, release task, scan task, choose task, resolve task, submit result, accept/refuse, and integration. If a requester wants to launch a task, he needs to submit his requirement about the task to the crowdsensing platform. The task performers in the crowdsensing platform scan the tasks and choose appropriate ones. After accomplishing the task, the task performers submit the results back to the platform, and the requester can decide whether the results are qualified. If yes, all the results are integrated, and the task is finished [3].
Due to the convenience of deployment and communication, mobile crowdsensing has been applied in a large number of scenarios such as smart transportation, environmental monitoring, and data labelling [4–7]. Although mobile crowdsensing provides an unprecedented solution for data collecting and processing, it brings many new challenges as well. Privacy preservation is one of the main problems that need to be considered when designing a mobile crowdsensing scheme. Most of the previous studies focus on protecting task performers [8, 9]. That is, they mainly consider how to preserve the privacy of task performers in the stage of submit result. For some specific tasks, the privacy leakage may also occur in the stage of release task since the platform is not fully trusted. The platform may deduce the privacy of requesters according to their tasks. Besides, task access control is another problem that needs to be addressed. In mobile crowdsensing, the tasks are stored on the platform. Anyone in the system can access and accept the task. For the tasks that require users with specific conditions, it may lead to poor quality of task results if task performers are not qualified. Moreover, task access control can efficiently prevent the task information from been obtained by irrelevant entities (e.g., the crowdsensing platform). Thus, task access control is vital to mobile crowdsensing.
Attribute-based encryption (ABE) [10–12] is a promising data-sharing tool that provides fine-grained access control over the encrypted data. There are mainly two branches: ciphertext policy ABE (CP-ABE) [11] and key policy ABE (KP-ABE) [10]. In CP-ABE, the user secret key is associated with an attribute set, and the ciphertext is associated with an access policy. Only when the attribute set satisfies the access policy can the ciphertext be decrypted [13]. In KP-ABE, the situation is reversed. The user secret key and ciphertext are associated with an attribute set and access policy, respectively. Apparently, data owners in CP-ABE can decide the access policy, which makes CP-ABE more suitable for mobile crowdsensing. However, there still exist some problems if it is directly used in mobile crowdsensing [14].
A Motivating Story. Consider a researcher who would like to collect the heart rate record of people in region A for research. To achieve the purpose, he decides to issue his requirement to a crowdsensing platform. To encourage task performers in the system, everyone who contributes to this task will get some allowance. The researcher needs to encrypt the task with ABE technology, and the corresponding access policy is {“region A” AND “male”}. Thus, only male users in region A can accept this task. As the platform is not fully trusted, the access policy should not be included in the ciphertext. Otherwise, the platform may deduce the privacy of the researcher or task performers who accepted this task.
The crowdsensing platform is public, which contains a variety of task performers. Generally speaking, the more the task performers take part in the task, the better the result is. However, the requester may get a contrary result without a selecting mechanism for task performers. To address this problem, many task allocation algorithms have been proposed [2, 3, 15, 16]. Most of them let the crowdsensing platform perform the task allocation. Since the crowdsensing platform is not fully trusted, it may collect the attributes of the task and thus deduce the privacy of the requester or task performers who are qualified to accept this task. Therefore, we need to design a better solution that achieves fine-grained task access control without loss of confidentiality by using ABE technology. However, the following two issues arise.
By employing ABE technology, the content of the task is unknowable to the crowdsensing platform. However, the encrypted information is also difficult for task performers to browse. A task performer may need to download all the ciphertexts and try to decrypt them one by one, which is inefficient especially in the scenario of mobile crowdsensing where the devices are resource-limited [17]. How can we let the task performers get the appropriate tasks efficiently when the tasks are encrypted? Besides, in ABE, the access policy embedded in the ciphertext is sent to the crowdsensing platform. Since it is directly connected to the task, the crowdsensing platform may deduce the privacy of requesters and task performers from it. To protect the content of the ciphertext, ABE schemes supporting hidden access policy are needed.
1.1. Contributions
In this paper, we propose a fine-grained task access control system for mobile crowdsensing called FGTAC. The contributions are summarized as follows:(1)Fine-Grained Task Access Control. Considering the situation that the requester needs to recruit a group of users with specific attributes for his task, a fine-grained task access control mechanism is needed. By employing ABE technology, the tasks are encrypted under the access policy defined by requesters. Only users with appropriate attributes can retrieve the encrypted task. In FGTAC, an AND-gate access policy with a wildcard is employed. Every attribute in the access policy has three kinds of possible values: positive, negative, and wildcard. As a result, the proposed system can achieve both fine-grained access control and flexibility.(2)Privacy Preservation. One of the main purposes of our system is to preserve the privacy of requesters and task performers. To the best of our knowledge, barely of the existing literature pay attention to preserve the privacy of requesters. However, the crowdsensing platform is not fully trusted. If tasks are sent to the crowdsensing platform without any protection, the crowdsensing platform may deduce the information about requesters and thus threaten their privacy. To address this problem, we employ ABE technology in our system. Nevertheless, the access policy in ABE is sent to the crowdsensing platform together with the ciphertext, which may help the crowdsensing platform deduce the content of the task. Thus, we employ ’s formulas [18] to hide access policy in the ciphertext.(3)Task Search. As the tasks are encrypted and the access policies are hidden, the task performers cannot search the tasks as usual [19]. In our FGTAC system, an efficient search function is provided. The keyword is encrypted and stored in the ciphertext. Before the search algorithm is performed, the user keyword is transferred into the trapdoor. As a result, the crowdsensing platform cannot obtain any useful information from it. Moreover, the search algorithm only costs two bilinear pairing operations, which can be performed within 9 ms. The predecryption algorithm is performed once search algorithm finishes.(4)Ciphertext Predecryption. In the scenario of mobile crowdsensing, devices cannot afford the high computational overhead of bilinear pairing operations. To reduce their computational overhead, we design the function of ciphertext predecryption in FGTAC. On the user side, the decryption algorithm only costs two exponentiation operations in , which can be performed efficiently by mobile devices.
1.2. Related Works
Task assignment and privacy-preserving are the two main problems in mobile crowdsensing [20, 21]. In task assignment, the crowdsensing platform needs to determine who is suitable to perform the task. To find the appropriate performers, many solutions are proposed in the literature [15, 22, 23]. Wu et al. [15] proposed two approximate task assignment algorithms for sweep coverage. Different from the schemes valuing the point of interest, they designed a model that weighs the quality of coverage from the perspective of the area. In Ref. [22], Karaliopoulos et al. employed opportunistic networking technology in choosing performers for crowdsensing tasks. In Ref. [23], the authors designed a crowdsensing system that mainly considers the location and profits of performers. However, the crowdsensing platform is hard to trust in reality. It may threaten the security of task performers and requesters if the crowdsensing platform obtains private information. Wang et al. [24] enabled the performers to select the personal privacy level so that they do not need to upload their true location to the crowdsensing platform. Ni et al. [16] introduced a strong privacy-preserving scheme for mobile crowdsensing called SPOON. Specifically, proxy re-encryption and BBS + signature are used to protect the tasks and results. Sei et al. [9] proposed a data collecting scheme, which is anonymized, by improving the traditional randomized response scheme. Unfortunately, none of the aforementioned schemes is designed to protect the privacy of requesters. In the workflow of mobile crowdsensing, both the privacy of performers and requests can be obtained by the crowdsensing platform through the task information and thus threaten their security.
To handle the problems above, ABE technology, which was firstly proposed by Sahai and Water [25], is a promising tool. As a well-known data-sharing tool, many ABE schemes aiming at settling the challenges of confidentiality and flexibility in data access control have been proposed [26–30]. To enable the users to search on the encrypted files, Sun et al. [26] proposed a fine-grained keyword search scheme. With the technologies of lazy re-encryption and proxy re-encryption, the expensive computation cost of ABE is delegated to other entities. As the access policy may leak the privacy, a partially hidden access policy ABE scheme is proposed in Ref. [27]. The access policy in their scheme only consists of the attribute names, and the corresponding values are not provided. Further in Ref. [28], a fully hidden access policy ABE scheme is introduced. Compared with Ref. [27], the scheme in Ref. [28] is more secure. To handle the expensive computation in ABE, Ning et al. set a secret value for users to protect ciphertexts in Ref. [29]. In the stage of decryption, the cloud server performs the decryption algorithm to generate the transformed ciphertext. The cloud server cannot get any useful information from the transformed ciphertext, while users can retrieve the encrypted data efficiently.
1.3. Organization
In Section 2, we state the preliminaries, including notations, bilinear map, complexity assumption, ’s formulas, access structure, and the definition of CP-ABE. The system model, definition, and security model are outlined in Section 3. Section 4 gives detailed construction and the security analysis of FGTAC. Section 5 evaluates the proposed system in terms of feature comparison, theoretical analysis, and experimental analysis. A brief conclusion is presented in Section 6.
2. Preliminaries
2.1. Notations
Some frequently used notations are given in Table 1.
2.2. Bilinear Map
Let and be two cyclic groups with prime order , be the generator of , and be a bilinear map. has the following properties:(1)Bilinearity: and , the equation holds.(2)Nondegeneracy: .(3)Computability: , the computation of bilinear pairing can be performed efficiently.
2.3. Complexity Assumption
We use decisional -bilinear Diffie-Hellman inversion (-BDHI) problem in our scheme. A challenger selects two groups and . Let be a generator of and . Given the tuple as input, it must be difficult for adversaries to distinguish from . An algorithm has advantage in breaking it if .
Definition 1. (-BDHI). The decisional -BDHI assumption holds if all probabilistic polynomial-time (PPT) algorithms have at most a negligible advantage in breaking it.
2.4. Viete’s Formulas
Consider two vectors and . Vector contains both alphabets and wildcards, and vector only contains alphabets. Let denotes the positions of wildcards in vector . Let , where are the coefficients, then we have if for . To hide the computation, we can choose a random group element and put as the exponents of . Then, the above equation becomes By using ’s formulas, we can construct the coefficient in aforementioned equation by where .
2.5. Access Structure
Let be an AND-gate access policy. Every attribute has three kinds of states. stands for positive, stands for negative, and stands for wildcard. If a user wants to join the system. An attribute set will be assigned to him, where . Similar to the access policy, every attribute has two kinds of states. stands for positive and stands for negative. The notation means that satisfies .
2.6. CP-ABE definition
There are four algorithms in a basic ciphertext policy attribute-based encryption scheme: Setup, KeyGen, Encrypt, and Decrypt.(1)Setup: It takes the secure parameter as input and outputs the public key and the master secret key .(2)KeyGen: It takes and and an attribute set as input and outputs the user secret key .(3)Encrypt: It takes , an access policy and a message as input and outputs the ciphertext .(4)Decrypt: It takes , , and as input and outputs if . Otherwise, the algorithm outputs .
3. System Model and Security
In this section, we give out the system model, definition, and security model of FGTAC.
3.1. System Model
In Figure 2, we show the system model of FGTAC. It consists of four entities: the key generation center (KGC), the crowdsensing platform, the requester, and task performers.(1)KGC needs to generate the system parameters and distribute secret keys for task performers in FGTAC. As the core management entity, KGC is trusted by other entities.(2)Crowdsensing Platform is responsible for storing the tasks and receiving the sensing data. When a task performer queries for a task, the crowdsensing platform will perform the predecryption algorithm to relieve his computational overhead. It is semitrusted in the sense that the crowdsensing platform may collect private information for its own interest.(3)Requester is the entity that issues crowdsensing tasks via the crowdsensing platform to collect sensing data. Since the requester is able to issue tasks at will, we assume the requester has sufficient computation ability. In addition, the requester may have some special requirements on task performers and do not hope the crowdsensing platform knows the content of his task. Thus, the requester needs to encrypt his tasks with ABE technology.(4)Task Performers are workers in FGTAC. They would like to accomplish the requesters’ tasks to get the allowance. The tasks are encrypted by ABE technology. All the task performers in the system are assigned a set of attributes. Only task performers whose attribute set satisfies the access policy can retrieve the task in the crowdsensing platform. The task performers are untrusted for they may collude to get the tasks that they are not qualified to obtain.
3.2. Definition
According to the system model, the definition of the proposed system is designed as follows:(1)Setup: The setup algorithm is run by KGC. It takes a secure parameter as input and outputs the public key and the master secret key . KGC keeps private and publishes .(2)UserReg: The user registration algorithm is run by task performers. It takes as input and outputs the user public key and the user master secret key . The task performers keep private and publish .(3)KeyGen: The key generation algorithm is run by KGC. It takes , and , and an attribute set as input, outputs the user secret key . KGC distributes to corresponding task performers in the system.(4)Encrypt: The encryption algorithm is run by the requester. It takes , an access policy , a message , and the keyword defined by the requester as input and outputs the ciphertext . Note that all the ciphertexts are transferred to the crowdsensing platform for storage.(5)Trapdoor: The trapdoor generation algorithm is run by task performers. It takes and the user keyword as input and outputs the trapdoor .(6)Search or : The search algorithm is run by the crowdsensing platform. It takes , , and as input and outputs 1 if matches . Otherwise, the algorithm outputs 0.(7)PreDecrypt or : The predecryption algorithm is run by the crowdsensing platform. It takes , and as input and outputs the predecrypted ciphertext if the attribute set in satisfies in . Otherwise, the algorithm outputs .(8)Decrypt: The decryption algorithm is run by task performers. It takes , , and as input and outputs the message .
3.3. Security Model
According to the system model in Section 3.1, we say that KGC is fully trusted, the crowdsensing platform is semitrusted, and requesters and task performers are untrusted. We define the security of FGTAC by the security games as follows:
3.3.1. Chosen-Plaintext Attack Security
The security game of chosen-plaintext attack (CPA) is designed between a challenger and an active adversary (malicious user) . The interaction is as follows: Initialization: declares the challenge access policy , challenge user public key , and sends them to . Setup: first runs the Setup algorithm to get the public key and the master secret key . After that, is sent to . Query Phase 1: Let be an empty set and be an integer counter. launches queries as follows: Generate.SK: sets . It runs the UserReg algorithm to get the tuple of user public key and user secret key , and runs the KeyGen algorithm with attribute set and to get the user secret key . stores to . Besides, the situation that is not allowed. Corrupt.SK: checks whether contains . If it is, returns to . Otherwise, returns . Challenge: declares two equal-length plaintexts and sends them to . randomly selects and runs the Encrypt algorithm to get challenge ciphertext . It sends to . Query Phase 2: adaptively queries as in Query Phase 1. Guess: outputs a guess for .
The probability for to win the security game is .
Definition 2. (CPA security). The proposed system is CPA secure if all PPT adversaries have at most a negligible probability in breaking CPA security game.
3.3.2. Chosen Keyword Attack Security
The security game of chosen keyword attack (CKA) is designed between a challenger and an active adversary (malicious user) . The interaction is as follows: Setup: first runs the Setup algorithm to get the public key and the master secret key . Then, returns to . Query Phase 1: Let be two empty sets, be an integer counter. launches queries as follows: Generate.Trapdoor: sets . It runs the Trapdoor algorithm with keyword to get the trapdoor . stores to . Corrupt.Trapdoor: checks whether contains . If it is, returns to and sets . Otherwise, returns . Challenge: declares two equal-length keywords and sends them to . Note that . randomly selects and runs the Encrypt algorithm to get challenge ciphertext . It returns to . Guess: outputs a guess for .
The probability for to win the security game is .
Definition 3. (CKA security). The proposed system is CKA secure if all PPT adversaries have at most a negligible probability in breaking CKA security game.
3.3.3. Secret Key Exposure Attack Security
The security game of secret key exposure attack is designed between a challenger and an active adversary (semitrusted crowdsensing platform) . The interaction is as follows: Initialization: declares the challenge access policy and sends it to . Setup: first runs the Setup algorithm to get the public key and the master secret key . returns to . Query Phase 1: Let be two empty sets, be two integer counters. launches queries as follows: Generate.SK: sets . It runs the UserReg algorithm to get , and runs the KeyGen algorithm with attribute set and to get the secret key . It stores to . Besides, the situation that is not allowed. Generate.CT: sets . It runs the Encrypt algorithm to get the ciphertext . It stores to . Besides, the situation that is not allowed. Corrupt: checks whether contains and contains . If it is, returns the tuple to . Otherwise, returns . PreDecrypt: runs the PreDecrypt algorithm to get the predecrypted ciphertext . Challenge: declares two equal-length plaintexts to . randomly selects and runs the Encrypt algorithm to get ciphertext . runs the UserReg algorithm and KeyGen algorithm to get . It sends to , and performs PreDecrypt algorithm to get the challenge predecrypted ciphertext . Query Phase 2: adaptively queries and as in Query Phase 1. Guess: outputs a guess for .
The probability for to win the security game is .
Definition 4. (Secret key exposure attack security). The proposed system is secure against secret key exposure attack if all PPT adversaries have at most a negligible probability in breaking the secret key exposure attack security game.
3.3.4. Collude Attack Security
The security game of collude attack is designed between a challenger and an active adversary (malicious user) . The interaction is as follows: Initialization: declares the challenge access policy and sends it to . Setup: first runs the Setup algorithm to get the public key and the master secret key . returns to . Query Phase: Let be an empty set, be an integer counter. launches queries as follows: Generate.SK: sets . It runs the UserReg algorithm to get the tuple of user public key and user secret key , and runs the KeyGen algorithm with attribute set and to get the user secret key . stores to . Besides, the situation that is not allowed. Corrupt.SK: checks whether contains . If it is, returns to . Otherwise, returns . Forgery: output a forged secret key for the challenge access policy .
Definition 5. (Collude attack security). The proposed system is collude attack secure if all PPT adversaries have at most a negligible probability in breaking the collude attack security game.
4. The Proposed System
4.1. Construction
The attribute universe contains attributes. For each of the attributes, there are three kinds of states. stands for positive, stands for negative, and stands for wildcard. Let be the three upper bounds defined as follows: is the maximum number of the wildcard ; is the maximum number of positive attributes ; is the maximum number of negative attributes . The detailed construction of the proposed system consists of the following eight algorithms: Setup. The setup algorithm is run by KGC. It takes secure parameter as input, generates a bilinear pairing group and sets . It randomly selects . For , the algorithm selects randomly and calculates and . is a hash function. The public key and the master secret key are set as UserReg. The user registration algorithm is run by task performers in system. A task performer randomly selects and calculates . The user public key and the user master secret key are set as KeyGen : The key generation algorithm is run by KGC. A task performer needs to submit his attribute set to KGC to get his user secret key. Let the attribute set contains positive attributes and negative attributes. and represent the positions of positive attributes and negative attributes, respectively. According to ’s formulas, for the positive attribute position set and negative attribute position , it sets The algorithm creates vectors and as The key generation algorithm randomly selects , and computes . For , it sets , , , and . The user secret key is set as follows: Encrypt: The encryption algorithm is run by the requester. Let the access policy contains wildcards, positive attributes and negative attributes. , , and represent the positions where , , and attributes are, respectively. According to ’s formulas, the algorithm computes the coefficients as It computes as follows: The vector is set as The encryption algorithm randomly selects and computes . For , it computes , , and . According to the keyword , the algorithm calculates The ciphertext is set as follows: Trapdoor: The trapdoor generation algorithm is run by task performers. The trapdoor is used to search the tasks about the keyword specified by task performers. The algorithm randomly selects and computes , and . The trapdoor is set as follows: Search or : The search algorithm is run by the crowdsensing platform. On receiving , the crowdsensing platform checks if holds. If yes, the crowdsensing platform performs the PreDecrypt algorithm. PreDecrypt or : The predecryption algorithm is run by the crowdsensing platform. If embedded in satisfies the in, the algorithm returns the predecrypted ciphertext . Otherwise, it returns . The computing process is as follows: Decrypt: The decryption algorithm is run by task performers. To retrieve the predecrypted ciphertext , the algorithm performs the following operations:
Note that the proposed system supports multikeyword search if in Encrypt and in Trapdoor consist of a set of keywords.
4.2. Security Analysis
4.2.1. Chosen-Plaintext Attack Security
Theorem 1. The proposed system is chosen-plaintext attack secure for PPT adversaries (malicious users).
Proof. Let be a PPT adversary who attacks the FGTAC system. The security game is played between and a simulator as follows: Initialization: declares the challenge access policy , challenge user public key , and sends them to . Setup: sets and randomly selects , . Then, it selects and calculates where . is a hash function. The public key is and the master secret key is . is sent to . Query Phase 1: Let be an empty set, be an integer counter. launches queries as follows: Generate.SK: sets . It runs the UserReg algorithm to generate and . Then, runs the KeyGen algorithm to get the corresponding user secret key according to the attribute set and . It stores to . Besides, the situation that is not allowed. Corrupt.SK: checks whether contains . If it is, sends to . Otherwise, returns . Challenge: declares two equal-length plaintexts and sends them to . randomly selects and runs the Encrypt algorithm to get challenge ciphertext . It sends to . Query Phase 2: adaptively queries as in Query Phase 1. Guess: outputs a guess for . wins the game if is the same as . Since the distribution of , , , and are identical to that in the real world, the advantage of the adversary to win this game is ignorable.
4.2.2. Chosen Keyword Attack Security
Theorem 2. The proposed system is chosen keyword attack secure for PPT adversaries (malicious users).
Proof. Let be a PPT adversary who attacks FGTAC system. The security game is played between and a simulator as follows: Setup: sets and randomly selects , . Then, it selects and calculates where . is a hash function. The public key is and the master secret key is . Then, returns to . Query Phase 1: Let be two empty sets, be an integer counter. launches queries as follows: Generate.Trapdoor: sets . It randomly selects and computes and . is set as . stores to . Corrupt.Trapdoor: checks whether contains . If it is, returns to and sets . Otherwise, returns . Query Phase 2: adaptively queries as in Query Phase 1. Challenge: declares two equal-length keywords and sends them to . Note that . randomly selects and runs the Encrypt algorithm to select and get the challenge ciphertext to . Guess: outputs a guess for . wins the game if is the same as . Since the distribution of , , and are identical to that in the real world, the advantage of adversary to win this game is ignorable.
4.2.3. Secret Key Exposure Attack Security
Theorem 3. The proposed system is secret key exposure attack secure for a PPT adversary (semitrusted crowdsensing platform).
Proof. Let be a PPT adversary who attacks the FGTAC system. The security game is played between and a simulator as follows: Initialization: The adversary declares the challenge access policy and sends it to . Setup: sets and randomly selects , . Then it selects and calculates where . is a hash function. The public key is and the master secret key is . Then, sends to . Query Phase 1: Let be two empty sets, be two integer counters. launches queries as follows: Generate.SK: sets . It runs the UserReg algorithm to get the user public key and the user secret key . Then, runs the KeyGen algorithm to get the corresponding user secret key according to the attribute set and . It stores to . Besides, the situation that is not allowed. Generate.CT: sets . It runs the Encrypt algorithm to get the ciphertext . It stores to . Besides, the situation that the access policy is not allowed. Corrupt: checks whether contains and contains . If it is, returns the tuple to . Otherwise, returns . PreDecrypt: runs the PreDecrypt algorithm to compute and set the predecrypted ciphertext . Challenge: declares two equal-length plaintexts and sends them to . randomly selects and runs the Encrypt algorithm to get . runs the UserReg algorithm and KeyGen algorithm to get . sends to , and performs PreDecrypt algorithm to get the challenge predecrypted ciphertext . Query Phase 2: adaptively queries and as in phase 1. Guess: outputs a guess for . wins the game if is the same as . Since the distribution of , , , and are identical to that in the real world, the ciphertext is protected by the and the adversary cannot obtain any sensitive information.
4.2.4. Collude Attack Security
Theorem 4. The proposed system is colluding attack secure for PPT adversaries (malicious users).
Proof. Let be a PPT adversary who attacks the FGTAC system. The security game is played between and a simulator as follows: Initialization: declares the challenge access policy and challenge user public key and sends them to . Setup: sets and randomly selects , . Then, it selects and calculates where . is a hash function. The public key is , and the master secret key is . After that is sent to . Query Phase: Let be an empty set, be an integer counter. launches queries as follows: Generate.SK(S): C sets . It runs the UserReg algorithm to generate and . Then, runs the KeyGen algorithm to get the corresponding user secret key according to the attribute set and . It stores to . Besides, the situation that is not allowed. Corrupt.SK (i): checks whether contains . If it is, sends to . Otherwise, returns . Forgery: output a forged secret key for the challenge access policy .wins the game if the forged secret key is valid. Since all the secret keys in are randomized by the random number . The advantage for the adversary to forge a valid secret key is ignorable.
5. Performance Evaluation
5.1. Feature Comparison
The performance evaluation is performed among Ref. [26, 28, 30–32] and our system. We mainly consider the following features in Table 2: hidden access policy, ciphertext search, predecryption, and access structure. Although ABE technology, which provides fine-grained access control, is employed in all the aforementioned schemes, only Ref. [28, 30, 32] and our system support hiding the access policy. Malicious users in Ref. [26, 31] may deduce sensitive information about the ciphertext from the access policy. Compared with Ref. [28, 30, 31], [26, 32], and our system enables users to search specific ciphertexts according to the keyword they provide (ciphertext search). To achieve lightweight computation, predecryption is provided in Ref. [30] and our system. As a result, task performers in both of the two systems can decrypt the ciphertext with their mobile devices efficiently. Moreover, the access structure in Ref. [26, 28] and our system are the same, while the other schemes use “And-Gate” or the “Tree” structure, which explains why we only compare our system with Ref. [26, 28] in Tables 3 and 4.
5.2. Theoretical Analysis
As mentioned above, Table 3 gives the comparison between Ref. [26, 28] and our system. Five objects are selected to be compared. Specifically, the size of the public key in our system is the smallest among all three schemes when . When , Ref. [26] outperforms our system. When, Ref. [28] outperforms Ref. [26]. The size of the master secret key in our system is , which is superior to that in Ref. [26, 28] when . The size of the secret key in Ref. [28] and our system are almost the same. It is less than that in Ref. [26]. For the size of ciphertext , our system is superior to Ref. [28]. We do not list in Ref. [26] for the reason that Ref. [26] only provides an algorithm to generate an encrypted index for a file waiting to be outsourced. The size of the trapdoor in Ref. [26] grows linearly with the number of attributes , while in our system, is constant . To sum up, the storage overhead in our system is significantly reduced compared to Ref. [26, 28].
Table 4 compares the computation overhead of, and. Note that Ref. [26] only generates a secure index in the encryption algorithm, the function of decryption is not provided. The overhead of in our system is similar to that in Ref. [26], and Ref. [28] contains and which is expensive compare to our system. Both the overhead of in our system and Ref. [26] are less than that in Ref. [28]. In Ref. [26], the computational overhead of grows every time the attribute increases, while it is in our system. We allow the crowdsensing platform to perform the algorithm such that the computational overhead on the user side in our system is only. However, in Ref. [28], the overhead is .
5.3. Experimental Analysis
We implement the scheme in Ref. [26, 28] and our system with java pairing-based cryptography 2.0.0 (JPBC) [33] to evaluate their performance. Type A curves predefined in JPBC is used. The experimental environment we used is a MacBook Prolaptop with Intel Core i7 2.7 GHz processor and 16 GB RAM. To provide a fair condition for comparison, the access policies of ciphertexts are defined in the form of , where represent the position of wildcards, positive attributes, and negative attributes, respectively. Each kind of attributes in the access policy increases from 3 to 27, which means the total attributes increase from 9 to 81 in the experiment. To make the experiment results convincing, we repeat all the algorithms 50 times and take the average.
Figure 3 presents the time cost of algorithms in Ref. [26, 28] and our system. As we can see, the time cost of Setup, KeyGen, and Encrypt, in Figures 3(a), 3(c), and 3(d), of all the three schemes, grow linearly with the number of policy attributes. Although Ref. [26] is 100 ms faster in the beginning, the time cost of KeyGen tends to the same afterward. In Figure 3(b), the time cost of UserReg in FGTAC is 8.5 ms on average, which is independent of the number of attributes. Similarly, the time cost of Trapdoor and Search in Figures 3(e) and 3(f) are both constant (about 16 ms and 9 ms, respectively). However, in Ref. [28], the time cost becomes unacceptable when the number of attributes is large. We give out the time cost of Decrypt in Figure 3(g). The time cost of Predecrypt in our system is the same as the Decrypt in Ref. [28]. However, the time cost for Decrypt on the user side in our system is about 0.56 ms on average, which can be performed efficiently by mobile devices. According to the experimental results, we demonstrate that our system achieves ciphertext search and predecryption without increasing computational overhead comparing to other schemes.
(a)
(b)
(c)
(d)
(e)
(f)
(g)
6. Conclusions
We have designed a fine-grained access control system called FGTAC in the scenario of mobile crowdsensing with an awareness of protecting the privacy of requesters. Specifically, the content of the task is encrypted by CP-ABE technology and only can be obtained by task performers who have appropriate attributes. In other words, the requester can decide the group of users who can access his task independently. To prevent the semitrusted crowdsensing platform from deducing the privacy of the requester and task performers, the access policy of the encrypted task is fully hidden in our system. For task performers, an efficient task search function, which can be conducted within approximately 9 ms, is provided. Moreover, considering the devices of task performers may be resource-limited, we also developed the function of ciphertext predecryption. According to the analysis in Section 4.2, the proposed system is CPA secure, CKA secure, secret key exposure attack secure, and collude attack security. The experiment results demonstrate that the computational overhead of our system is efficient. In our future work, we will design the mobile crowdsensing system supporting audit and user tracking without yielding expensive computational overhead such that a feedback mechanism for the task performers can be achieved.
Data Availability
All data included in this study are available from the corresponding author upon request.
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this paper.
Acknowledgments
This work was supported by the National Natural Science Foundation of China (nos. 61472343 and 61972094) and the Young Talent Promotion Project of Fujian Science and Technology Association.