PaperlayerView exact revision on arXiv

Source-linked AI summary

Enabling Strong Privacy Preservation and Accurate Task Allocation for Mobile Crowdsensing

Jianbing Ni, Kuan Zhang, Qi Xia, Xiaodong Lin, Xuemin Shen

arXiv:1806.04057v1cs.CR

TL;DR

Mobile crowdsensing needs trustworthy task allocation based on users’ locations and credit while protecting sensitive user and customer information. SPOON combines randomized location matching, cryptographic protection, anonymous proofs, and decentralized credit management to preserve privacy during allocation and reporting. The paper concludes that it can support location- and credit-based selection while preserving identities, locations, tasks, reports, and credit points without a trusted third party for credit management.

  • Problem

    Mobile crowdsensing must recruit suitable users and select trustworthy reports without exposing users’ sensitive locations, identities, or credit information.

  • Method

    SPOON combines randomized matrix-based location matching, proxy re-encryption, BBS+ signatures, and privacy-preserving credit management for anonymous allocation and reporting.

  • Results

    SPOON preserves identities, locations, credit points, sensing tasks, and reports during task allocation and report selection while supporting credit management without a trusted third party.

  • Takeaways & Limitations

    The scheme balances privacy preservation with location-based task allocation and credit-based sensing-report selection within mobile crowdsensing services.

Abstract

from arXiv · show

Mobile crowdsensing engages a crowd of individuals to use their mobile devices to cooperatively collect data about social events and phenomena for special interest customers. It can reduce the cost on sensor deployment and improve data quality with human intelligence. To enhance data trustworthiness, it is critical for service provider to recruit mobile users based on their personal features, e.g., mobility pattern and reputation, but it leads to the privacy leakage of mobile users. Therefore, how to resolve the contradiction between user privacy and task allocation is challenging in mobile crowdsensing. In this paper, we propose SPOON, a strong privacy-preserving mobile crowdsensing scheme supporting accurate task allocation from geographic information and credit points of mobile users. In SPOON, the service provider enables to recruit mobile users based on their locations, and select proper sensing reports according to their trust levels without invading user privacy. By utilizing proxy re-encryption and BBS+ signature, sensing tasks are protected and reports are anonymized to prevent privacy leakage. In addition, a privacy-preserving credit management mechanism is introduced to achieve decentralized trust management and secure credit proof for mobile users. Finally, we show the security properties of SPOON and demonstrate its efficiency on computation and communication.

I. INTRODUCTION

Mobile crowdsensing improves data collection but must reconcile privacy protection with accurate recruitment and task allocation. SPOON addresses this tension through privacy-preserving location matching, protected sensing data, anonymized participation, and decentralized credit management.

  • Motivation: Mobile crowdsensing uses mobile devices and human intelligence to collect environmental data while reducing collection costs and improving trustworthiness.Applications include air-quality measurement, noise detection, and dam water-release warnings.
  • Motivation: Privacy leakage is a first-order concern because sensing data can reveal users’ locations, movements, social relations, health status, and activities.Greater participation and richer contributions increase the probability of exposing sensitive information.
  • Research challenge: Accurate task allocation requires recruiting suitable users, but reputation-based methods risk linking anonymous users while geography-based methods can expose location information.User selection directly affects sensing-data quality because data trustworthiness depends on users’ intelligence and behavior.
  • Proposed approach: SPOON supports location-based task allocation, decentralized trust management, and simultaneous privacy preservation for mobile users and customers.Its design aims to preserve locations, identities, credit points, tasks, and reports without disabling task allocation, data filtering, or trust management.
  • Proposed approach: A randomized matrix-multiplication mechanism lets service providers determine whether users are in task areas without learning the users’ locations or customers’ interested areas.The mechanism reveals the location-matching result while hiding the underlying geographic information.
  • Proposed approach: SPOON extends proxy re-encryption and BBS+ signatures to protect tasks and reports while enabling anonymous capacity and trust-level proofs.A trusted authority can detect greedy users and trace their identities when they submit excessive reports.
  • Proposed approach: Its privacy-preserving credit mechanism lets users prove trustworthiness without exposing credit points or relying on centralized servers.Credit points can receive positive or negative updates, and multiple service providers can maintain a unique shared trust evaluation.

B. Threat Model

SPOON models honest-but-curious service providers, potentially malicious users, and external attackers, then defines privacy, confidentiality, allocation, credit-management, and tracing goals. Its cryptographic design combines bilinear maps, BBS+ signatures, and proxy re-encryption.

  • Threat model: The service provider is honest-but-curious: it performs services honestly but may seek additional information or violate data-protection policies.Customers are fully trusted, while external attackers include eavesdroppers and hackers.
  • Threat model: Mobile users may seek other participants’ or customers’ information and may submit excess reports to obtain unfair credit points.The model therefore includes privacy threats and greedy-user behavior by participating users.
  • Security goals: SPOON allocates tasks by location while hiding task areas and preventing users outside those areas from learning task information.Users learn only whether they are inside a sensing area.
  • Security goals: The design protects task and report contents and prevents entities or colluding parties from linking them to customers or mobile users.It also aims to prevent attackers from determining whether two reports or tasks came from the same source.
  • Security goals: Privacy-preserving credit management lets the provider select reports and award credit without learning users’ exact credit points, while preventing forged balances.A trusted authority can recover the identities of users who submit multiple reports for one task and reporting period.
  • Cryptographic basis: SPOON comprises five phases built from matrix multiplication, BBS+ signatures, and proxy re-encryption.The underlying preliminaries include bilinear maps, whose pairing is bilinear, non-degenerate, and efficiently computable.
  • Cryptographic basis: BBS+ signatures support zero-knowledge proofs of message-signature possession, while proxy re-encryption converts ciphertexts for another recipient without revealing plaintext.These properties support anonymous authentication and protected task or report sharing.

B. High-Level Description

SPOON organizes service setup, registration, task allocation, reporting, and credit assignment around anonymous credentials and protected data flows. Randomized location matching selects eligible users, while encrypted reports and credit proofs support private report selection and updates.

  • Setup and registration: During setup, the trusted authority publishes parameters, creates keys, and defines the service provider’s geographic region.Registration assigns an initial credit point and anonymous credentials for service access and credit management.
  • Task allocation: For task allocation, the provider matches randomized task-area and user-location matrices to identify users inside the sensing area without learning either underlying location.It then re-encrypts the protected task so selected users can decrypt it.
  • Data reporting: Users encrypt collected data and submit reports containing identifiers, a double-reporting tag, a claimed credit threshold, a reporting slot, and a proof of credit ownership.The tag enables the trusted authority to recover the identity of an anonymous user who submits duplicate reports.
  • Report selection: The provider selects w sensing reports using users’ claimed thresholds and forwards the selected reports to the customer.Users’ proof material supports threshold-based selection while preserving precise credit values.
  • Credit assignment: After the customer evaluates report trustworthiness, the provider computes awarded credit points and sends an update that users apply to their anonymous credentials.A user updates its balance as P′_i = P_i + θ_i.

C. The Detailed SPOON

SPOON establishes the service infrastructure, geographic representation, and anonymous registration needed for privacy-preserving crowdsensing. The setup combines a matrix-based service region with anonymous credentials and credit initialization.

  • Service setup: The service provider represents its covered geographic region as an m×n matrix whose entries correspond to small sensing-region grids.The Ontario example can be represented using 208 × 154 or, more precisely, 2075 × 1534 grids.
  • Anonymous registration: Customers and mobile users register with the trusted authority to obtain anonymous credentials before participating in crowdsensing.Each registrant receives a unique system identity, which may be a telephone number or mailing address in practice.
  • Credit initialization: The trusted authority evaluates each registrant’s initial credit point from its credit record and returns credential material through secure channels.The initial credit point is denoted P0, while the authority stores the identity, initial credit, and a commitment-related value.
  • Credential completion: Registrants combine authority-provided randomness with their own values, verify the resulting credential, and store it secretly on the mobile device.The device stores credential, identity, credit, and related key material in read-only memory.

3) Task Allocation:

SPOON allocates tasks by matching randomized representations of task areas and user locations while protecting task contents and geographic privacy. Encrypted task details are released only after location matching and user-side task evaluation.

  • Task formulation: A sensing task specifies its content, expiration, area, maximum trust level, and required number of reports.The customer encrypts the task content and creates a randomized matrix representing the target sensing region.
  • Task-area protection: The customer masks the sensing area with random matrix multiplication before sending it to the service provider.Non-zero entries must be distinct; otherwise, the service provider may learn the sensing region from the randomized matrix.
  • Location protection: Mobile users similarly transform their locations with random invertible matrices and submit the transformed locations with zero-knowledge proofs.Users keep the random value used for task decryption secret while sending the transformed location representation to the service provider.
  • Location matching: The service provider multiplies the randomized task-area and location matrices, treating a non-zero result as evidence that the user matches the task.If no task matches the user, the service provider responds with failure.
  • User participation: Matched users decrypt the task, then choose whether to participate based on the task’s stated benefits and costs.Users perform sensing only after accepting the task.
  • Report preparation: Users collect and preprocess sensing data, encrypt reports, and submit them periodically with the collection time, sensing location, and content.The reporting periods are defined by the customer.

4) Data Reporting:

SPOON anonymizes and encrypts sensing reports while allowing the service provider to detect duplicate submissions and select reports using claimed credit thresholds. The customer then decrypts the selected reports for trust evaluation.

  • Report submission: Each mobile user encrypts sensing data before periodically submitting a report identified by its task, time slot, and supporting proof values.The report includes encrypted data, randomized identifiers, a claimed credit threshold, and the reporting timestamp.
  • Credit-threshold proof: A user’s proof demonstrates that its claimed credit threshold is below its available credit point.The proof accompanies the encrypted report and related verification values.
  • Duplicate-report detection: The service provider checks proofs and detects a user submitting two reports with the same randomized identifier but different report values.This condition enables tracing of the greedy user’s identity through the registered credential value.
  • Report selection: The service provider selects the w reports with the highest claimed thresholds and releases them to the customer.Users whose reports are not selected may increase their thresholds in the next reporting slot.
  • Customer retrieval: The customer decrypts retrieved reports using its stored key before evaluating their trustworthiness.Decryption recovers the sensing message for subsequent trust assessment.

5) Credit Assignment:

SPOON assigns trust levels to reports and updates users’ privacy-preserving credit points, which users can prove and accumulate across service providers. Its security analysis includes location privacy, anonymity, confidentiality, credit balance, and greedy-user tracing.

  • Trust evaluation: The customer assigns each sensing report a trust level ϵi within [−γ, γ], with positive values indicating trustworthy reports.A non-positive trust level marks the report as incredible.
  • Credit update: The service provider converts the trust level and claimed threshold into an updated credit value for the mobile user.The update uses θi = INT(ϵiQi), where INT denotes the nearest-integer function.
  • Credential refresh: The mobile user verifies the updated credential and replaces its previous credit tuple when the verification succeeds.The updated credit point is stored in the device’s read-only memory for future participation.
  • Cross-provider credit: Users can prove ownership of their credit material across service providers and accumulate credit points earned from different providers.This supports credit proof during participation in services offered by multiple service providers.
  • Security analysis: SPOON’s security goals include location privacy, anonymity, data confidentiality, credit balance, and greedy-user tracing.These goals define the security properties examined in the paper.
  • Location privacy: Randomized task-area and user-location matrices let the provider detect overlap without exposing the exact sensing area or user location.The provider may learn that overlap exists in a column but cannot distinguish the specific overlapped location among the corresponding grid positions.

B. Data Confidentiality

SPOON protects sensing-task confidentiality through staged proxy re-encryption, so only matched users can recover tasks. Its anonymity proofs reduce user and customer privacy to standard cryptographic assumptions.

  • Task confidentiality: SPOON encrypts tasks in two stages so the service provider and unmatched users cannot recover their contents.The first stage encrypts under the trusted authority and service-provider keys; the second uses a temporary public key through proxy re-encryption.
  • Task confidentiality: The first-stage ciphertext remains confidential against service providers and mobile users under the simplified q−DBDHI assumption.The proof uses a challenge ciphertext and simulator to reduce distinguishing plaintexts to the simplified q−DBDHI problem.
  • Task confidentiality: Only mobile users whose locations match a sensing area can recover the corresponding second-stage sensing task.Unmatched users are prevented from learning task content through proxy re-encryption.
  • Anonymity: Mobile-user anonymity is protected unless the DDH assumption fails, while the corresponding proof reduces successful identification to solving DDH.The simulator handles location submissions, sensing reports, and zero-knowledge proofs for two candidate identities.
  • Anonymity: Customer anonymity is fully guaranteed because simulated zero-knowledge proof transcripts reveal no identity information.The proof argues that an adversary cannot distinguish an honest customer from two candidate customers.

D. Credit Balance

SPOON constrains users’ credit balances through BBS+ signatures and sound zero-knowledge proofs, while evaluating report trustworthiness from weighted similarity across sensing grids.

  • Credit balance: Credit balance requires each user’s final credit points to remain no greater than initial points plus awarded points.The security definition treats exceeding this bound as evidence of forged signatures or double-reporting.
  • Security proof: The credit-balance proof assumes zero-knowledge proofs PK1, PK2, PK3, and SPK are sound and extractable.Simulators use extraction algorithms and a signature oracle to analyze adversarial registration and reporting queries.
  • Credit balance: A user exceeding Pf > P0 + Σθj would need to forge a BBS+ signature or double-report sensing data.The proof relies on BBS+ security under q−SDH and soundness of the zero-knowledge proof.
  • Greedy-user tracing: Greedy-user tracing addresses both slandering honest users and hiding by greedy users.Sound proofs prevent slandering, while correctness of the pseudorandom function prevents greedy users from generating required tracing information.
  • Trust evaluation: Trust evaluation groups reports by sensing grids, assigns weighted similarities, and averages grid-level trust for reports spanning multiple grids.Significantly divergent reports receive negative similarity, while otherwise similar reports receive positive similarity.

B. Efficiency-enhanced Task Allocation

SPOON replaces heavier matrix transmission with BGN-based encrypted distance matching for circle-shaped sensing regions. The service provider learns matching task numbers without learning exact customer or user locations.

  • Matrix-based matching: SPOON represents task sensing areas and mobile-user locations as matrices, then randomizes them to hide geographic information.The matrix method supports location matching but requires both parties to transmit larger n×n matrices.
  • Efficiency-enhanced matching: BGN encryption reduces communication cost by enabling encrypted distance computation for location matching.The mechanism uses BGN’s homomorphic property and transmits shorter encrypted values instead of the larger matrix representations.
  • Location matching: A sensing region is a circle identified by center Lc = (Lcx, Lcy) and radius R, and a user matches when distance to the center is below R.The paper illustrates this criterion with user U1’s geographic location and the sensing circle.
  • Location matching: The service provider sends encrypted matching inputs to the trusted authority, which decrypts distances, checks di < R, and returns matching task numbers.The provider then releases the corresponding protected task ciphertext to the matched user.
  • Evaluation: The evaluation measures computational and communication overhead together with privacy and accuracy rates for credit management.The supplied evaluation passage states the measured dimensions but reports no numerical outcomes here.

A. Computational Overhead

SPOON’s computational evaluation counts major cryptographic operations and uses pre-processing to reduce bilinear-map costs. The reported execution time is below 300 ms per entity, while credit-threshold selection exposes a privacy–accuracy trade-off.

  • Computational measurement: SPOON’s computational overhead is measured using point multiplication, point addition, bilinear map, and GT exponentiation counts.Other operations are excluded because they are not comparable with these four operations.
  • Computational optimization: Pre-processing reduces computational burden by computing selected bilinear maps before later protocol phases.The TA pre-computes maps during setup, and mobile users can pre-compute a map during registration.
  • Execution time: Less than 300 ms per entity is reported for every SPOON phase, supporting deployment on mobile devices.The experiment uses notebook hardware for the TA and service provider and a Huawei smartphone for customers and mobile users.
  • Credit analysis: Claimed credit thresholds preserve precise credit-point privacy but can reduce report-selection accuracy.A threshold may exceed another user’s threshold even when its actual credit point is lower, creating the stated privacy–accuracy tension.
  • Credit analysis: The evaluation defines accuracy and privacy rates to study how threshold-selection strategies affect credit-based report selection.The rates are computed through Matlab simulations of mobile-user credit points and illustrated in Fig. 5.

APPENDIX

The appendix specifies SPOON’s cryptographic parameters and proof procedures. It describes pre-computed pairing values and Fiat–Shamir-style verification for registration, customer, and mobile-user proofs.

  • Credit proof: The mobile-user proof demonstrates that the credit point exceeds the claimed threshold without revealing the credit point itself.The protocol proves the non-negativity of P_i − Q_i using a zero-knowledge range proof.
  • Pre-computation: The TA and service provider pre-compute pairing values to reduce interactions and computational work in zero-knowledge proofs.These values are incorporated into released public parameters, while Fiat–Shamir transformation derives proof challenges through hashing.
  • Registration proof: Registration proofs let the TA verify that submitted commitments are formed consistently with the registrant’s hidden values.The registrant sends commitments and responses, and the TA accepts when the recomputed hash challenge matches.
  • Proof verification: Proof verification reconstructs challenge-dependent values and accepts only when the resulting hash equals the submitted challenge.This verification pattern is shown for customer and mobile-user proofs.
Loading 1806.04057v1…