An Efficient Privacy-Preserving Incentive Scheme without TTP in Participatory Sensing Network

by   Jingwei Liu, et al.
Xidian University
NetEase, Inc

Along with the development of wireless communication technology, a mass of mobile devices are gaining stronger sensing capability, which brings a novel paradigm to light: participatory sensing networks (PSNs). PSNs can greatly reduce the cost of wireless sensor networks, and hence are becoming an efficient way to obtain abundant sensing data from surrounding environment. Therefore, PSNs would lead to significant improvement in various fields, including cognitive communication. However, the large-scale deployment of participatory sensing applications is hindered by the lack of incentive mechanism, security and privacy concerns. It is still an ongoing issue to address all three aspects simultaneously in PSNs. In this paper, we construct an efficient privacy-preserving incentive scheme without trusted third party (TTP) for PSNs to motivate user-participation. This scheme allows each participant to earn credits by contributing data privately. Using blind and partially blind signatures, the proposed scheme is proved to be secure for privacy and incentive. Additionally, the performance evaluation in terms of computation and storage indicates that the proposed scheme has higher efficiency.



There are no comments yet.


page 1

page 2

page 3

page 4

page 5

page 6


EPDA: Enhancing Privacy-Preserving Data Authentication for Mobile Crowd Sensing

As a popular application, mobile crowd sensing systems aim at providing ...

When Crowdsensing Meets Federated Learning: Privacy-Preserving Mobile Crowdsensing System

Mobile crowdsensing (MCS) is an emerging sensing data collection pattern...

A Large-scale Concurrent Data Anonymous Batch Verification Scheme for Mobile Healthcare Crowd Sensing

Recently, with the rapid development of big data, Internet of Things (Io...

Towards Explainable Multi-Party Learning: A Contrastive Knowledge Sharing Framework

Multi-party learning provides solutions for training joint models with d...

Incentives for Privacy Tradeoff in Community Sensing

Community sensing, fusing information from populations of privately-held...

Enabling Strong Privacy Preservation and Accurate Task Allocation for Mobile Crowdsensing

Mobile crowdsensing engages a crowd of individuals to use their mobile d...

Privacy-preserving Sensory Data Recovery

In recent years, a large scale of various wireless sensor networks have ...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

In recent years, mobile phones have made great progress in processing power, storage capacities, embedded sensors (e.g., accelerometer, GPS, microphone), and communication capabilities. The rapid penetration of mobile phones not only changed the traditional internet service model, but also increased the diversity of applications. One of the applications is based on the data collected by the sensors in the powerful mobile phones, the emerging application—participatory sensing networks (PSNs) [1]

. PSNs are greatly helpful to the improvement of cognitive communication that combines perception, information processing, artificial intelligence and machine learning together.

Fig. 1: A Basic framework of PSNs

A PSN system is essentially a wireless sensor network (WSN) formed by ubiquitous sensors. However, compared with traditional WSNs, sensors are no need to pre-distributed in PSNs, which reduces setup cost. Moreover, people-centric PSNs provide better spatial and temporal coverage. A basic framework of PSNs is shown in Fig. 1. Participants collect sensing data through the sensors embedded in smart terminals and upload these information to a cloud server. The server integrates and analyzes all the sensing data, then shares the results with the corresponding customers. Therefore, participants are not only the data providers in PSNs, but also the consumers and ultimate beneficiaries.

Since the concept of PSN was initially presented in 2006, it has been widely applied to environmental monitoring [2], traffic route navigation [3], health care [4], etc. In addition, PSNs have made a greater contribution in participatory cognitive radio networks [5]. However, in various of application scenarios, PSNs have to face to many security challenges [6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]. Although there are some methods [20, 21, 22, 23], the critical challenge that the contradiction between privacy preservation and incentive mechanism, which hinders the large-scale deployment of mobile sensing applications. Without reasonable and secure reward, participants may not be willing to spend time, effort or money on any sensing task. Therefore, an appropriate incentive mechanism is necessary to stimulate participants’ enthusiasm and persistence. However, the identities and other sensitive information of participants may be abused by the cloud server in the incentive scheme. Therefore, in this paper, we propose an efficient privacy-preserving incentive scheme to meet requirement of security and privacy preservation in PSNs.

Although there have been plenty of research efforts on privacy preservation in PSNs [24, 25, 26], most of them do not consider incentive mechanisms for participants. Cristofaro et al. [25] proposed a secure framework of participant-sensing instead of the detailed algorithm. Kapadia et al. [26] proposed a scheme to gather sensing data anonymously, named AnonySense. Nevertheless, in these schemes, it is still an open issue that there is few appropriate incentives involved in the sensing task to attract more users’ participation.

In addition, many studies of incentive mechanisms in PSNs have appeared gradually. In [27], Lee et al. proposed a reverse auction scheme based on dynamic price, named RADP. Yang et al. [28] presented two incentive models based on the games and auctions from the perspective of data requestors and participants separately. Nonetheless, there are no privacy-preserving measures in these schemes, so the users’ privacy is likely to be leaked. It may cause unnecessary troubles.

Until now, the joint-design on the above two issues still has not attracted sufficient research attention. They urgently need to be considered for adapting the extensive applications of PSNs. For instance, one of the most effective solutions, the pseudonym, is used to conceal a participant’s real identity in PSNs. In this scheme, each participant generates his/her tokens and commitments in cooperation with the server using blind and partially blind signature to protect privacy against the attacks by any third party. In this paper, we propose an efficient privacy-preserving incentive scheme without trusted third party (TTP) through a credit-based approach, which allows each user to earn credits by contributing sensing data without leaking his/her privacy.

The rest of this paper is organized as follows. In section II, we briefly introduce some preliminaries including the system model, threats models, cryptographic primitives, etc. In section III, we describe the proposed scheme in detail and analyze its security properties. In section IV, the performance is evaluated. Finally, we conclude the paper in section V.

Ii Preliminaries

Ii-a System Model

Recently, some models have been proposed for data collection or processing [29, 30]. In this paper, we propose a people-centric model for the privacy-preserving incentive scheme, as shown in Fig. 2. We define three different entities that are identified as follows:

  • Sensing Data Requestor (SDR): The SDRs send queries to the sensing server for the desired statistics and context data. As customers of PSN services, they need to indicate which types of data they are interested in obtaining.

  • Sensing Participant (SP): The SPs are responsible for collecting the relevant data with sensors and uploading them to the sensing server via 3G/4G or Wi-Fi.

  • Sensing Server (SS): The SS manages the PSN services to facilitate effective sharing of data between SPs and SDRs. The SS collects sensing reports from the SPs and answers the SDRs based on analysis results on the collected data.

The basic workflow is described as follows. When an SDR requires some data, it needs to send a query to the SS. The SS transforms the query into one or more tasks and publishes them to a task queue. If the SP decides to take part in a certain task, he/she will collect sensing data in accordance with the task requirements and summarize a report with a random pseudonym. Then, he/she submits the report to the SS using a new pseudonym. Accordingly, the SS pays a certain number of credits to the corresponding SP. After obtaining enough data reports, the SS integrates and analyzes all reports, then sends feedback to the SDR.

Fig. 2: System model

Ii-B Threat Models

1) Threats to incentive

With respect to incentive, we assume that the SS is honest. On receiving valid virtual credits from SPs, the SS will not repudiate to pay. Otherwise, it would affect SPs’ enthusiasm to participate in the sensing task in the future. In this case, we assume there exist two types of threats to the incentive mechanisms: firstly, a dishonest SP may upload the same data report repeatedly or reuse expired credit tokens in an attempt to obtain more credits than allowed; secondly, a malicious SP may compromise the other SPs for their credit tokens, or forge the tokens to earn more credits.

2) Threats to privacy

We assume that the SS may be curious about which tasks have been accepted or which reports have been submitted by SPs. Thus, there are also two types of threats to privacy of the SPs in this case. On one hand, the SS tries to link the identities of participants to some reports that may contain sensitive information. On the other hand, a malicious server may attempt to infer a certain participant’ real identity through multiple tasks requested by him/her.

Ii-C Cryptographic Primitives

Ii-C1 Pseudonym

Due to the pseudonym, no entity can link a submitted report to the actual participant. To the best of our knowledge, the pseudonym is an effective solution to protect SPs’ privacy. It is difficult for an adversary to establish a relationship between a participant and the data report from a randomized ID instead of the actual ID.

Ii-C2 Blind Signature

Blind signature was first introduced by D. Chaum in 1983, which can effectively protect the content of the messages that need to be signed. Due to properties of blindness, untraceability and unforgeability, blind signature is often used in electronic cash protocols to protect privacy.

Ii-C3 Partially blind signature

In partially blind signature, there is a part of common information should be pre-agreed upon (e.g., index of task). Similarly, the signer is not allowed to know the other part of information. Thus, he/she cannot link the signature to the communication session from which the signature is obtained.

Ii-D Assumptions

In this paper, we put forward following three assumptions:

  • Firstly, we assume that the SS and each SP have several pairs of public/private keys issued by a certified authority to authenticate each other.

  • Secondly, we suppose that each task can only be requested once by each participant.

  • Thirdly, we assume that users’ mobile phones should be kept securely.

Iii An Efficient Privacy-Preserving Incentive Scheme without TTP in PSNs

To solve the contradiction between privacy preservation and incentive mechanism, we propose an efficient privacy-preserving incentive scheme without TTP for PSNs. In the scheme, we combine three types of techniques: pseudonyms, blind signature and partially blind signature together to protect the privacy of SPs.

Iii-a Design Objectives

The proposed scheme should provide a reasonable incentive mechanism to maintain users’ enthusiasm for their participation, and ensure that attackers cannot get users’ sensitive information. In terms of incentive, SPs can obtain corresponding credits by completing the sensing tasks. In general, an SP can earn at most credits from the task published by the SS. With respect to privacy-preserving, when the SP requests multiple tasks, the SS is unable to link these tasks to it. Also, the SS cannot link the uploaded reports to it.

Iii-B Privacy-Preserving Incentive Scheme in PSNs

In PSNs, the SS may publish many tasks in batch in a certain time slot, namely task windows. In chronological order, various tasks are distributed in these windows. Without loss of generality, we consider the first task window. The tasks in this window are numbered . The SS needs to maintain a list of tokens for each task.

Notations Description
The public/private keys for blind RSA signature
The SS’s private keys for partially blind signature
The secure numbers of SP
The number of credits paid to SP for a task
Request token, report token, credit token
A cryptographic hash function
A timestamp
The real identity and pseudonym of an SP
TABLE I: Notations

In the proposed scheme, we use blind and partially blind signature in [31] to protect SPs’ sensitive information. The primary notations used in this paper are given in TABLE I. The SS generates the private/public key pair and for RSA signature and blind RSA signature, two private keys for partially blind signature. Each SP randomly selects three secure numbers: , and . These keys and numbers should be kept unchanged in different task windows. In addition, the SP also need to choose different pseudonyms and a one-way hash function .

Iii-B1 Task Request

The SS first publishes some tasks including the requirements, the deadline and a possible range of credit . If an SP decides to take part in the task (, he/she should communicate with the SS to request this task by using a pseudonym . Firstly, the SP negotiates the common information with the SS and requests RSA signature on the hash value of to prove his/her identity in the credit deposit phase. Secondly, if the SS agrees with the common information, it returns the signature in an approval message:


Then, the SP selects a random number and computes a request token identifier to ask for a partially blind signature on . The SS signs blinded with its private key and returns the signature to the SP. So the SP can obtain as the commitment and set as the request token. Note that the SP can only obtain one request token with for the task. Finally, the SP sends the request token to the SS:


On receiving the SP’s request token, the SS verifies the correctness of the signature . If it is valid, the SS sends the initial price to the SP. At the same time, the SS stores the used request token into its list to prevent the SP from reusing it.

Iii-B2 Report Submission

In order to obtain the report token, the SP does as follows:

  • Choose a random number and compute a credit token identifier , where ;

  • Select a random number and compute blind factor ;

  • Generate the blinded message . The report token identifier is ;

  • Request a partially blind signature on using another random pseudonym .

Upon receiving the request from the SP, the SS signs blinded with its private key and delivers the signature to the SP. After removing the blind factor, the SP obtains as the commitment. Therefore, the report token for this task is . Note that the SP can only get one report token with for the task. Then, the SP encrypts the data report with the SS’s public key . The SP submits the report for task , the report token, the blinded message and a timestamp:


Next, the SS verifies if holds. If it dose, the SS knows that has also been committed for task and then verifies signature . If the signature is valid, it means that has been committed for task . Therefore, the SS stores the legal report token into its list. Furthermore, the SS decides to deliver a certain amount of credit to the SP according to the task difficulty, data quality and other relevant factors. The SS signs with its private key:


Upon receiving , the SP removes the blinding factor to get blind RSA signature . In this way, the SP obtains credit tokens , . Without submitting the report, the SP cannot obtain any credit token.

Iii-B3 Credit Deposit

After getting these credit tokens , the SP can only submit one credit token at a time using his/her real identity . So, to mitigate timing attacks, all credit tokens need to be uploaded times in a random interval:


After receiving the credit token, the SS verifies if the timestamp is expired. If it is not, the SS does the following steps: 1) verify the signature with its public key ; 2) verify by extracting from . If two signatures are both valid, the SP’s credit account can be added by one. At the same time, the SS stores these credit tokens into its list to avoid replay attacks. The flow chart of the above phases is illustrated in Fig. 3.

Fig. 3: Program flow chart of the proposed scheme

Iii-B4 Token Renewal

For each task, the SS maintains a list of the used tokens to avoid reusing. When a task is completed, the corresponding request tokens and report tokens in the list should be released. However, the credit tokens will be released until all tasks in the same window have been finished or expired. Then, the SPs can request the following tasks whose indexes are if they are willing.

Iii-C Security Analysis

In this part, we analyze the security of the proposed scheme in terms of incentive and privacy. We first give the linkability between different tokens and objects in Fig. 4.

Iii-C1 Attacks on Incentive

Proposition 1. The proposed scheme can prevent dishonest SPs from earning more than their due credits.

Proof: Since the SP binds the commitment in each request or report token to the task index through partially blind signature, he/she cannot use the request or report token for another task. Although the SP does not bind the credit tokens to the task index, the credit tokens can not be reused for another task in this window. Because the used credit tokens have been stored in the SS’s list. Besides, the timestamp can resist replay attacks, so dishonest SPs can not reuse the credit tokens in the following task windows for more credits.

Proposition 2. The proposed scheme can prevent malicious SPs from compromising the other SPs or forging the credit tokens to earn more credits.

Proof: A malicious SP may compromise the other SPs for their credit tokens, but he/she still cannot earn any credit. Since each credit token is associated with the SP’s real identity , the SS will not offer the credit to the other SPs. Furthermore, it is impossible for the malicious SP to forge the signature , because the private key is kept secretly by the SS. Thus, the credit tokens cannot be forged.

Fig. 4: The linkability between different components

Iii-C2 Attacks on Privacy

Proposition 3. The SS cannot link tasks to the corresponding SP.

Proof: Since the SP requests tasks with different random pseudonyms in the task request phase, so the SS cannot distinguish if two different pseudonyms belong to the same SP. Thus, the SS is unable to link the tasks to the corresponding SP.

Proposition 4. The SS cannot link a report to the corresponding SP.

Proof: The SP uploads a report with a random pseudonym instead of his/her real identity in the report submission phase. Meanwhile, due to the untraceability of the partially blind signature, the SS cannot link the uploaded report to the corresponding SP’s real identity, as shown in Fig. 4.

Proposition 5. The SS cannot link the credit tokens to a certain report.

Proof: Though, in the credit deposit phase, the SP submits the credit tokens with his/her real identity , the SS cannot link the credit token to the corresponding report token, because the connection between and is covered by in blind RSA signature.

Within a short time, a task may be completed by one or a few SPs. In this case, if an SP deposits multiple credit tokens once, the SS may directly link the report to this SP. Thus, the SPs need to deposit one credit token at a time to prevent the SS from linking the credit tokens to the report.

Iv Performance Evaluation

In this section, we analyze the performance of the proposed scheme in terms of storage cast and computation overhead. For the experimental evaluation, the simulation environment is set up in Ubuntu 16.04 with an Intel(R) Core i5-4200U 1.60GHz 2 processor and 2.2GB memory. The proposed scheme will be run 100 times in order to compensate for the randomness of the results.

Iv-a Storage Cost

The SS needs to store a request token and a report token for one task until this task is finished. Also, it requires to store at most credit tokens until all tasks in one task window are completed. Hence, the storage overhead is not heavy for the SS. After submitting the report for the task, the SP is required to store credit tokens delivered by the SS. By contrast, in [32], each SP needs storing commitments for the next tasks, so our scheme achieves lower storage cost for the SP.

SS 13.887ms 5.037ms 3.421ms
SP 4.279ms 0.469ms 0.015ms
Task application Report submission Credit deposit Total time
SS 17.924ms 38.109ms 4.705ms 60.738ms
SP 4.793ms 11.698ms - 16.698ms
TABLE III: Time Consumption
Fig. 5: Total processing time of our scheme vs. the number of task execution

Iv-B Computation Overhead

In the simulation procedure, the computation overhead is primarily caused by several major cryptographic operations. Table II shows the running time of the cryptographic primitives. “” denotes a partially blind signature, “” denotes an RSA signature, and “” denotes a hash operation. Table III indicates the processing time of each phase in our scheme when and . On the SS side, the task request, report submission, and credit deposit phases only take several milliseconds. On the SP side, it just takes a short time for several one-way hash functions running in the terminal devices. Since the SP deposits one credit token each time in the credit deposit phase to protect participants’ privacy, the SS has to sign more credit tokens, which may lead to a little more computation burden in the report submission phase. However, the processing time can be reduced if more efficient signature scheme is deployed instead of RSA signature. With the increase of the number of PSN tasks, the time consumption in the SS is still reasonable, as shown in Fig. 5. Additionally, according to the rough test, the communication overhead is about one thousandth of the computation overhead, so we ignore the communication overhead in the performance evaluation. In summary, our scheme takes reasonable computational overhead to meet the privacy-preserving inventive requirements in PSNs.

V Conclusion

To facilitate the large-scale deployment of participatory sensing applications, we propose an efficient privacy-preserving incentive scheme without TTP to solve the conflict between participants’ privacy and incentive in the participatory sensing networks. By combining of timestamp and nonce tokens, it can prevents replay attacks effectively, so dishonest users cannot reuse different tokens. Also, a malicious SS cannot link the reports or tasks to the corresponding SP. Security analysis indicates that the proposed scheme meets the security and privacy-preserving requirements in PSNs. Finally, the performance evaluation shows that the proposed scheme achieves lower computation and storage cost.

Vi Acknowledgment

This work is supported by Natural Science Basic Research Plan in Shaanxi Province of China (No. 2016JM6057), the 111 Project (B08038) and Collaborative Innovation Center of Information Sensing and Understanding at Xidian University.


  • [1] J. A. Burke, D. Estrin, M. Hansen, A. Parker, N. Ramanathan, S. Reddy, and M. B. Srivastava, “Participatory sensing,” Center for Embedded Network Sensing, 2006.
  • [2] M. Mun, S. Reddy, K. Shilton, N. Yau, J. Burke, D. Estrin, M. Hansen, E. Howard, R. West, and P. Boda, “PEIR, the personal environmental impact report, as a platform for participatory sensing systems research,” in Proc. of the 7th International Conference on Mobile Systems, Applications, and Services, 2009, pp. 55–68.
  • [3]

    A. Thiagarajan, L. Ravindranath, K. LaCurts, S. Madden, H. Balakrishnan, S. Toledo, and J. Eriksson, “Vtrack: accurate, energy-aware road traffic delay estimation using mobile phones,” in

    Proc. of the 7th ACM Conference on Embedded Networked Sensor Systems, 2009, pp. 85–98.
  • [4] J. Hicks, N. Ramanathan, D. Kim, M. Monibi, J. Selsky, M. Hansen, and D. Estrin, “AndWellness: an open mobile system for activity and experience sampling,” in Proc. of Wireless Health 2010, 2010, pp. 34–43.
  • [5] V. S. S. Nadendla, S. Brahma, and P. K. Varshney, “An auction-based mechanism for dynamic spectrum allocation in participatory cognitive radio networks,” in Proc. of 2012 50th Annual Allerton Conference on Communication, Control, and Computing (Allerton), 2012, pp. 2120–2126.
  • [6] Y. Xiang, K. Li, and W. Zhou, “Low-rate ddos attacks detection and traceback by using new information metrics,” IEEE Transactions on Information Forensics and Security, vol. 6, no. 2, pp. 426–437, 2011.
  • [7] X. Du and F. Lin, “Maintaining differentiated coverage in heterogeneous sensor networks,” EURASIP Journal on Wireless Communications and Networking, vol. 2005, no. 4, pp. 565–572, 2005.
  • [8] Q. Xu, Z. Su, Q. Zheng, M. Luo, and B. Dong, “Secure content delivery with edge nodes to save caching resources for mobile users in green cities,” IEEE Transactions on Industrial Informatics, 2017.
  • [9] Y. Xiao, V. K. Rayi, B. Sun, X. Du, F. Hu, and M. Galloway, “A survey of key management schemes in wireless sensor networks,” Computer Communications, vol. 30, no. 11-12, pp. 2314–2341, 2007.
  • [10] X. Du, M. Guizani, Y. Xiao, and H. H. Chen, “Secure and efficient time synchronization in heterogeneous sensor networks,” IEEE Transactions on Vehicular Technology, vol. 57, no. 4, pp. 2387–2394, 2008.
  • [11] J. Liu and W. Sun, “Smart attacks against intelligent wearables in people-centric internet of things,” IEEE Communications Magazine, vol. 54, no. 12, pp. 44–49, 2016.
  • [12] X. Du, M. Guizani, Y. Xiao, and H. H. Chen, “A routing-driven elliptic curve cryptography based key management scheme for heterogeneous sensor networks,” IEEE Transactions on Wireless Communications, vol. 8, no. 3, pp. 1223–1229, 2009.
  • [13] H. Zhang, J. Li, B. Wen, Y. Xun, and J. Liu, “Connecting intelligent things in smart hospitals using nb-iot,” IEEE Internet of Things Journal, 2018.
  • [14] X. Du, Y. Xiao, M. Guizani, and H. H. Chen, “An effective key management scheme for heterogeneous sensor networks,” Ad Hoc Networks, vol. 5, no. 1, pp. 24–34, 2007.
  • [15] S. Yu, W. Zhou, S. Guo, and M. Guo, “A feasible ip traceback framework through dynamic deterministic packet marking,” IEEE Transactions on Computers, vol. 65, no. 5, pp. 1418–1427, 2016.
  • [16] X. Du, Y. Xiao, H. H. Chen, and Q. Wu, “Secure cell relay routing protocol for sensor networks,” Wireless Communications and Mobile Computing, vol. 6, no. 3, pp. 375–391, 2006.
  • [17] Y. Xiao, X. Du, J. Zhang, F. Hu, and S. Guizani, “Internet protocol television (iptv): the killer application for the next-generation internet,” IEEE Communications Magazine, vol. 45, no. 11, 2007.
  • [18] F. Hu, X. Cao, and C. May, “Optimized scheduling for data aggregation in wireless sensor networks,” in Proc. of 2005 IEEE International Conference on Information Technology: Coding and Computing(ITCC), vol. 2, 2005, pp. 557–561.
  • [19] X. Du and H. H. Chen, “Security in wireless sensor networks,” IEEE Wireless Communications, vol. 15, no. 4, 2008.
  • [20] S. Yu, W. Zhou, W. Jia, S. Guo, Y. Xiang, and F. Tang, “Discriminating ddos attacks from flash crowds using flow correlation coefficient,” IEEE Transactions on Parallel and Distributed Systems, vol. 23, no. 6, pp. 1073–1080, 2012.
  • [21] J. Zhang, Y. Xiang, Y. Wang, W. Zhou, Y. Xiang, and Y. Guan, “Network traffic classification using correlation information,” IEEE Transactions on Parallel and Distributed systems, vol. 24, no. 1, pp. 104–117, 2013.
  • [22]

    K. Manandhar, X. Cao, F. Hu, and Y. Liu, “Detection of faults and attacks including false data injection attack in smart grid using kalman filter,”

    IEEE Transactions on Control of Network Systems, vol. 1, no. 4, pp. 370–379, 2014.
  • [23] S. Yu, W. Zhou, R. Doss, and W. Jia, “Traceback of ddos attacks using entropy variations,” IEEE Transactions on Parallel and Distributed Systems, vol. 22, no. 3, pp. 412–425, 2011.
  • [24] A. Pingley, W. Yu, N. Zhang, X. Fu, and W. Zhao, “Cap: A context-aware privacy protection system for location-based services,” in Proc. of 2009 IEEE 29th International Conference on Distributed Computing Systems(ICDCS), 2009, pp. 49–57.
  • [25] E. D. Cristofaro and C. Soriente, “Short paper: PEPSI—privacy-enhanced participatory sensing infrastructure,” in Proc. of the 4th ACM Conference on Wireless Network Security, 2011, pp. 23–28.
  • [26] C. Cornelius, A. Kapadia, D. Kotz, D. Peebles, M. Shin, and N. Triandopoulos, “Anonysense: privacy-aware people-centric sensing,” in Proc. of the 6th International Conference on Mobile Systems, Applications, and Services, 2008, pp. 211–224.
  • [27] J. S. Lee and B. Hoh, “Sell your experiences: a market mechanism based incentive for participatory sensing,” in Proc. of 2010 IEEE International Conference on Pervasive Computing and Communications (PerCom), 2010, pp. 60–68.
  • [28] D. Yang, G. Xue, X. Fang, and J. Tang, “Crowdsourcing to smartphones: Incentive mechanism design for mobile phone sensing,” in Proc. of the 18th Annual International Conference on Mobile Computing and Networking, 2012, pp. 173–184.
  • [29] Q. Xu, Z. Su, B. Han, D. Fang, Z. Xu, and X. Gan, “Analytical model with a novel selfishness division of mobile nodes to participate cooperation,” Peer-to-Peer Networking and Applications, vol. 9, no. 4, pp. 712–720, 2016.
  • [30] J. Baek, Q. H. Vu, J. K. Liu, X. Huang, and Y. Xiang, “A secure cloud computing based framework for big data information management of smart grid,” IEEE Transactions on Cloud Computing, vol. 3, no. 2, pp. 233–244, 2015.
  • [31] F. Zhang, R. Safavi-Naini, and W. Susilo, “Efficient verifiably encrypted signature and partially blind signature from bilinear pairings,” in Proc. of Indocrypt, vol. 2904, 2003, pp. 191–204.
  • [32] Q. Li and G. Cao, “Providing efficient privacy-aware incentives for mobile sensing,” in Proc. of 2014 IEEE 34th International Conference on Distributed Computing Systems (ICDCS), 2014, pp. 208–217.