2020 IEEE/ACM 28th International Symposium on Quality of Service (IWQoS)
PFcrowd: Privacy-Preserving and Federated
Crowdsourcing Framework by Using Blockchain
Chen Zhang† , Yu Guo† , Hongwei Du‡ , and Xiaohua Jia†
† Department
of Computer Science, City University of Hong Kong, Hong Kong, China
‡ School of Computer Science and Technology, Harbin Institute of Technology (Shenzhen), Shenzhen, China
c.zhang@my.cityu.edu.hk, {y.guo, csjia}@cityu.edu.hk, hwdu@hit.edu.cn
Abstract—Crowdsourcing is a promising computing paradigm
that utilizes collective intelligence to solve complex tasks. While it
is valuable, traditional crowdsourcing systems lock computation
resources inside each individual system where tasks cannot
reach numerous potential workers among the other systems.
Therefore, there is a great need to build a federated platform
for different crowdsourcing systems to share resources. However,
the security issue lies in the center of constructing the federated
crowdsourcing platform. Although many studies are focusing on
privacy-preserving crowdsourcing, existing solutions require a
trusted third party to perform the key management, which is
not applicable in our federated platform. The reason is that it is
difficult for a third party to be trusted by various systems.
In this paper, we present a secure crowdsourcing framework
as our initial effort toward this direction, which bridges together
the recent advancements of blockchain and cryptographic tech-
niques. Our proposed design, named PFcrowd, allows different
crowdsourcing systems to perform encrypted task-worker match-
ing over the blockchain platform without involving any third-
party authority. The core idea is to utilize the blockchain to assist
the federated crowdsourcing by moving the task recommendation
algorithm to the trusted smart contract. To avoid third-party
involvement, we first leverage the re-writable deterministic hash-
ing (RDH) technique to convert the problem of federated task-
worker matching into the secure query authorization. We then
devise a secure scheme based on RDH and searchable encryption
(SE) to support privacy-preserving task-worker matching via the
smart contract. We formally analyze the security of our proposed
scheme and implement the system prototype on Ethereum.
Extensive evaluations of real-world datasets demonstrate the
efficiency of our design.
Index Terms—Federated Crowdsourcing, Re-writable Deter-
ministic Hashing, Searchable Encryption, Blockchain.
I. I NTRODUCTION
With the development of the internet and sharing-economy,
crowdsourcing [1] has emerged as a compelling computing
paradigm, which utilizes the collective intelligence to solve
complex tasks, such as sentiment analysis [2] and data col-
lection [3]. Nowadays, an increasing number of companies
choose crowdsourcing as a problem-solving method and many
well-known platforms such as Upwork [4], UBER [5], and
Amazon Mechanical Turk [6] are active in our lives.
Despite their advantages, crowdsourcing systems have some
serious security concerns. In current crowdsourcing systems,
the crowdsourcing platforms (called brokers) perform task-
worker matching based on the plaintext of task requirements
978-1-7281-6887-6/20/$31.00 ©2020 IEEE
Authorized licensed use limited to: University of Liverpool. Downloaded on November 13,2020 at 11:53:08 UTC from IEEE Xplore. Restrictions apply.
and interests submitted by task-requesters and workers, respec-
tively. These submitted task requirements and interests contain
a lot of sensitive information, such as business secrets and
the location of workers. The privacy of these task-requesters
and workers may be compromised when exposing sensitive
information to brokers.
To address the privacy concern, several privacy-preserving
solutions for crowdsourcing have been proposed. Shu et al.
[7]–[9] first proposed a secure task-worker matching scheme
for crowdsourcing using proxy cryptography and later ex-
tended it to SybSub which supports expressive task subscrip-
tion with sybil detection. Unfortunately, since these schemes
rely on central servers, they are weak in traditional trust-
based models, such as single point of failure. Moreover, they
are vulnerable to distributed denial of service (DDoS). To
solve these issues, CrowdBC [10] devised a blockchain-based
decentralized framework for crowdsourcing without relying on
any third-party trusted institution. This system enhances the
security of users and the availability of service. However, all
the existing schemes work for a paradigm which only exists
a single broker. The task-requesters and workers are locked
inside a single and isolated system. The task-requesters cannot
reach numerous potential workers outside the boundary of the
system and the workers have no access to the tasks published
in other platforms, which significantly limits the power of the
open market of crowdsourcing systems.
This motivates us to investigate a privacy-preserving and
federated crowdsourcing system. Our research aims at de-
signing a privacy-preserving and federated framework that
interconnects the existing independent brokers to form a
loosely coupled federation without relying on any third-party
authority. In such a framework, each broker can keep its own
autonomy while being able to use potential resources (tasks
and workers for crowdsourcing) in other brokers if autho-
rized by them. Inspired by the immutability and verifiability
of blockchain, we utilize the blockchain as the underlying
platform for building the federation of crowdsourcing systems.
Existing solutions of using blockchain for crowdsourcing [10]–
[12] assume the existence of a trusted authority that can
faithfully perform key management. The trusted authority can
assign different types of secret keys to participants so that
the ciphertexts of the same keyword encrypted by different
keys can be transformed into the same format. However, in
our federated platform, there is no such trusted authority. It
is difficult to perform authorized task-worker matching over
ciphertext encrypted by different brokers. Moreover, to allow
workers to search for tasks across platforms, brokers need to
generate task indexes and publish them on the blockchain. The
indexes posted by all brokers are visible to everyone since the
blockchain is transparent. Hence, it is difficult to guarantee the
on-chain matching of workers and tasks is privacy-preserving,
and the on-chain task indexes posted by one broker can only
be accessed by authorized brokers.
In this paper, we propose PFcrowd, the first federated
framework for privacy-preserving crowdsourcing by using
blockchain techniques. PFcrowd enables different brokers
to form a federation where authorized task-requesters can
reach out to potential workers in other brokers and workers
can have more choices of tasks matching their interests.
To implement task recommendations across multiple brokers
over the blockchain network, we propose a new scheme via
recent advancements on query authorization and searchable
encryption (SE) schemes. Specifically, our design first utilizes
the re-writable deterministic hashing (RDH) technique [13]
to build the secure authorization list for federated brokers
within the smart contract. RDH is a well-studied algorithm in
which authorized requests can be hashed into the same format
without sharing keys. By treating RDH values as keywords,
it is possible to support authorized search over the federated
datasets. However, directly applying RDH to our design cannot
fully meet the security requirements, because RDH is a deter-
ministic algorithm and it can reveal the frequency of keywords.
To address this issue, we propose to leverage the idea of
random masking and embed RDH values into random masks
via SE schemes [14], so that the matching results can be found
only after comparisons. We implement the system prototype
on Ethereum and provide a formal security analysis. Extensive
experiments demonstrate the practicality of the design. The
main contributions of this paper can be summarized as follows:
• We introduce PFcrowd, a privacy-preserving and feder-
ated crowdsourcing framework. It utilizes the blockchain
technology to enable brokers to recommend and workers
to take tasks across multiple crowdsourcing platforms.
• We design an encrypted task-worker matching scheme
without involving any third-party authority. It can sup-
port authorized task-worker matching over on-chain task
indexes posted by multiple brokers.
• We implement the PFcrowd framework and evaluate it
on Ethereum. Security analysis and experimental results
confirm that our proposed scheme is secure and efficient.
The rest of this paper is organized as follows: Section II
introduces the preliminaries. Section III presents the system
model, threat model, and design goals. In section IV, we
describe the details of our PFcrowd. The security analysis is
conducted in Section V, and performance evaluation is shown
in Section VI. Section VII introduces the related work. Finally,
we conclude this paper in Section VIII.
Authorized licensed use limited to: University of Liverpool. Downloaded on November 13,2020 at 11:53:08 UTC from IEEE Xplore. Restrictions apply.
Block Block Block Block
Blockchain
Nodes
Broker Nodes
Broker Broker
Task Answer Search Recommend
Task-requesters Workers
Fig. 1: The Architecture of PFcrowd
II. PRELIMINARIES
Re-writable deterministic hashing: RDH scheme can be
considered as an enhanced one-way function with re-writing
ability, which operates on plaintexts, ciphertexts, and tokens.
This scheme includes three algorithms: Func, GenToken and
Apply, which are combined by the re-writing property. The
re-writing attribute can be modeled as:
Apply(Func(A, B), GenToken(B, C)) = Func(A, C) (1)
where A, B, and C are plaintexts. The algorithm Func is
an enhancement of a two-argument hash function, which
produces a ciphertext from a pair of symmetrical plaintexts.
The algorithm GenToken can produce a token from a pair of
plaintexts that are ordered. The algorithm Apply takes input
as a ciphertext and a token generated by Func and GenToken,
respectively and returns a ciphertext.
Searchable encryption: SE supports untrusted servers to
directly search over encrypted data without server-side de-
cryption. It consists of three algorithms: KGen, Enc, and Dec.
The key generation algorithm KGen takes input as a security
parameter k and outputs a secret key K. The encryption
algorithm Enc takes input as a key K and a value m ∈ {0, 1}∗
and outputs a ciphertext c. The decryption algorithm Dec takes
input as a key K and a ciphertext c and outputs m.
III. PROBLEM FORMULATION
A. System Model
As shown in Fig. 1, the system model of PFcrowd con-
tains four parties: task-requesters, brokers, workers, and the
blockchain. Table I includes the notations used in this paper.
• Task-requesters are a collection of users, identified by
R, who interact with their individual crowdsourcing plat-
forms to publish encrypted tasks.
• Workers are a collection of users, identified by W , who
interact with their individual crowdsourcing platforms to
submit search queries including their interests.
 2020 IEEE/ACM 28th International Symposium on Quality of Service (IWQoS)
• Brokers are a collection of crowdsourcing platforms,
identified by B, that host tasks submitted by task-
requesters under their administrative domain in their local
database and upload their constructed task indexes and
authorization relationships to the blockchain.
• Blockchain serves as a hub to bridge the above three
parties. The smart contract deployed in it is designed
to search over on-chain task indexes and authorization
relationships posted by brokers and record task-worker
matching results on the blockchain. Note that the task
recommendation procedure is based on authorization,
which means that a broker can only access the tasks
posted by those brokers that authorize it to search. For
example, workers in broker bi ∈ B can get the matching
tasks uploaded by broker bj ∈ B on the blockchain only
if bi is authorized by bj .
To make operations non-repudiable and immutable, all
posted task indexes, operation histories, and authorization
information are recorded on the blockchain so that other
peers can verify the faithful execution of task recommendation
queries. From a high-level point of view, the workflow of
PFcrowd is shown below.
Authorization: During the system initialization phase, brokers
communicate with each other and each broker determines the
set of brokers which can access its uploaded tasks. Then
brokers upload their determined authorization relationship to
the smart contract and the smart contract generates the on-
chain authorization list based on the information received.
Task publication: To publish tasks to PFcrowd, the task-
requesters encrypt their tasks and upload the ciphertexts to the
brokers. After receiving a certain batch of tasks, each broker
aggregates its received tasks with the same task requirement
and forms the requirement-task indexes [7], which is beyond
the scope of this paper. Then brokers generate encrypted task
indexes based on these requirement-task indexes and post them
on the blockchain in the form of smart contract, making they
are available for workers and other brokers to search.
Task recommendation: To find tasks matching his interest,
a worker submits the encrypted interest to his broker bi ∈
B. Upon receiving the request, broker bi generates the search
token and uploads it to the smart contract. Then the smart
contract will search over the on-chain task indexes uploaded
by the brokers that authorize bi to access.
Task taking: After collecting all the tasks matching the
worker’s interest, the smart contract records the query result
on the blockchain and the worker can then ask for the tasks
from respective brokers. To confirm with one worker to take a
task, the broker will sign a task-contract with the worker and
record the contract on the blockchain.
B. Threat Model
Brokers: The brokers are considered as semi-honest. They
will honestly execute the pre-defined protocols but may be
curious about the sensitive information regarding received task
requirements and interests. Moreover, they also curious about
Authorized licensed use limited to: University of Liverpool. Downloaded on November 13,2020 at 11:53:08 UTC from IEEE Xplore. Restrictions apply.
TABLE I: Glossary
Symbol Definition
R, B, and W the set of task-requesters, brokers, and workers
keb , kb master keys of broker b ∈ B
skb secret key of broker b ∈ B
G1 , G 2 pseudo-random functions
Sb the set of brokers that authorize broker b to search
A on-chain authorization list
I on-chain task index
H(w) encrypted task-requirement/ interest
T set(H(w)) the set of task IDs corresponding to H(w)
T id task ID in T set
p the number of tasks in each block
S state table of encrypted task requirements
the set of brokers that are authorized to access
ACb
the tasks posted by broker b
Autb→b∗ the authorization relationship of broker b to b∗
the on-chain task indexes and try to access the tasks posted
by the brokers that do not authorize them.
Blockchain: The blockchain is trustworthy in terms of data
integrity and availability. All transactions recorded on it are
traceable. For the smart contract deployed on the blockchain,
it will run automatically without tampering. Moreover, all the
data submitted or recorded on the blockchain is visible to
everyone in the system.
Task-requesters and workers: The task-requesters and work-
ers are considered as honest in the sense that they will submit
valid task information and interests, respectively.
C. Design Goal
Based on the aforementioned system model and threat
model, the design goals of our proposed PFcrowd are sum-
marized as follows:
• Security: The confidentiality of task requirements and
interests submitted by task-requesters and workers should
be guaranteed. In addition, we require to ensure that
the on-chain matching process between searched interests
and the task indexes published by multiple brokers is
privacy-preserving.
• Correctness of service: The task recommendation pro-
cess is based on authorization. It should be guaranteed
that a broker can only search over the on-chain task
indexes posted by the brokers that authorize it.
• Federation: In PFcrowd, all brokers should be intercon-
nected and form a loosely coupled group. For the task
indexes posted by one broker, other authorized brokers
can access it by searching on the blockchain.
• Traceable: All operations, task indexes and authoriza-
tion relationships recorded on the blockchain should be
traceable. Additionally, the matching results of all task
recommendation queries are required to be recorded on
the blockchain.
IV. THE PROPOSED CONSTRUCTION
We aim to design a privacy-preserving and federated crowd-
sourcing framework, which interconnects existing independent
 2020 IEEE/ACM 28th International Symposium on Quality of Service (IWQoS)

crowdsourcing platforms into a loosely coupled federation. Algorithm 1: System Initialization

Under the framework, brokers can efficiently recommend tasks Input: secure PRF G1 ; B; IDb , ∀b ∈ B.
to workers based on encrypted on-chain task indexes posted Output: On-chain authorization list A, g.
by multiple brokers without revealing the sensitive information 1 Randomly select (g, G) ← GG(1 );
λ
submitted by task-requesters and workers. In this section, 2 for each broker b ∈ B do
we first introduce the design rationale of PFcrowd. Then we 0 $
present the proposed framework in detail. Finally, an example 3 − {0, 1}λ ;
Select three master keys keb , kb , kb ←
is provided to illustrate the on-chain matching process. 4 fb ← G1 (keb , IDb );
F
5 Fb1 ← G1 (kb , IDb );
0
A. Design Rationale 6 Fb2 ← G1 (kb , IDb );
In our design, the blockchain serves as the platform to 7 Initialize set Sb ← ∅;
record task indexes posted by brokers and the history of 8 Put [ Ffb : Sb ] to index A;
interactions with other parties. To protect privacy, brokers must 9 Send A to the smart contract;
encrypt their generated task indexes before publishing them on 10 Pairwise authorization between brokers
the blockchain. In PFcrowd, each broker has its own autonomy 11 for each broker b ∈ B do
and can access the task indexes posted by other brokers on the 12 for each broker b∗ ∈ ACb do
blockchain if being authorized. When broker b1 ∈ B submits Connect with b∗ and get Fb2∗ and F
13 b∗ offline;
g
a task recommendation query, the smart contract will only F 1
/F 2

n b→b∗ ← g o ;
Set Aut b b ∗
14
search over the encrypted on-chain task indexes posted by the
brokers authorizing b1 , and then record the matching tasks 15 Send Fb∗ , Autb→b∗ to the smart contract;
g
on the blockchain. However, brokers encrypt their uploaded
task indexes with their secret key and no trusted third-party 16 Smart contract
n build on-chain
o authorization list
exists in our platform. It is a challenging issue to perform 17 for each Fb∗ , Autb→b∗ received from broker b do
g
authorization-based task recommendations over task indexes 18 Add Autb→b∗ in A[F
gb∗ ];
encrypted by different brokers without a trusted party.
To solve this problem, we resort to the RDH [13] technique.
The core idea of it is to convert the search tokens uploaded by
brokers into on-chain search trapdoors based on the authoriza- Algorithm 2: Build Encrypted On-chain Task Index
tion relationship among brokers. For two brokers b1 , b2 ∈ B, Input: secure PRFs {G1 , G2 }; symmeric encryption
the authorization of b1 to b2 is denoted as g b1 /b2 , which is function Enc; states s; encrypted requirement
stored in the authorization relationship set of b2 . The on-chain H(w); B; task ID set T set.
search trapdoor for matching task indexes posted by b1 about Output: On-chain task index I, table S.
interest H(w) is g H(w)·b1 . When b2 searches for H(w), b2 1 for each broker b ∈ B do
generates search token H(w) · b2 and uploads it to the smart 2 for each encrypted requirement H(w) do
contract. When receiving the search token, the smart contract
l m
3 Set α ← |T set(H(w))|
p , where p denotes the
first gets the authorization relationship set of b2 and computes
number of tasks that can be packed;
on-chain search trapdoors. For the authorization value g b1 /b2 ,
4 Divide T set(H(w)) into α blocks;
one on-chain search trapdoor can be computed by the smart
5 Pad the last block to p entries if needed, s ← 0;
contract as: 1
6 Set trap ← g H(w)·Fb ;
(g b1 /b2 )H(w)·b2 = g H(w)·b1 (2)
7 for each block in T set(H(w)) do
which is equal to the on-chain search trapdoor pre-defined by 8 T
g id ← T id1 ||T id2 || · · · ||T idp ;
b1 about interest H(w). Hence b2 can get the tasks uploaded by 9 label ← G1 (trap||s);
b1 . Note that, if b1 does not authorize b2 to search, the smart 10 C ← Enc(k, T gid);
contract cannot generate the right on-chain search trapdoor 11 P ← G2 (trap||s) ⊕ C;
which can return matching tasks posted by b1 successfully. 12 Put [label : P] to index I, s++;
In this way, we realize the authorization-based task-worker
13 Put [H(w) : s] to table S;
matching without involving any third-party authority.
14 send I to the smart contract;
However, as RDH is a deterministic algorithm, the labels
of on-chain task indexes about the same keyword posted by
the same broker are identical. Therefore, it leaks the relation
between queried interests and task indexes to peer nodes
before searching. To solve this problem, we introduce the state broker uploads a task index about one requirement, the state
variable and utilize SSE technology to enhance security. Each variable corresponding to the requirement is incremented by
broker maintains a local state table, in which each encrypted one. In this way, the relation between task requirements and
task requirement corresponds to a state variable. Whenever one tasks is preserved.

Authorized licensed use limited to: University of Liverpool. Downloaded on November 13,2020 at 11:53:08 UTC from IEEE Xplore. Restrictions apply.
 2020 IEEE/ACM 28th International Symposium on Quality of Service (IWQoS)

Algorithm 3: Task Recommendation 1-9 of Algorithm 1. Specifically, given the secure parameter
Input: secure PRFs {G1 , G2 }; search interest H(w); λ and get the parameter g from the group G, which is used
on-chain task index I; on-chain authorization to generate the on-chain authorization list and task indexes.
list A; broker b ∈ B. Each broker b ∈ B randomly selects three master keys
0 $
Output: Matching task ID set T . − {0, 1}λ , and then computes F
keb , kb , kb ← fb , F 1 , and F 2
b b
1 Broker b generates search token via secure PRF G1 . IDb represents the unique ID number of
2 Set Tb,w ← H(w) · Fb ;
2 broker b, such as the public key. Sb denotes the set of brokers
n o authorizing broker b to access their uploaded task indexes. It
3 Send Tb,w , Ffb to blockchain;
is initialized to empty and added to the authorization list A
4 Smartn contract
o search reply in the smart contract. After that, brokers communicate with
5 Get Tb,w , Fb received from broker b;
f each other to determine the authorization relationship among
6 T ← ∅; them, and then the smart contract generates the authorization
list A according to their constructed relationship. In specific,
7 for each Aut in A[F fb ] do
Tb,w broker b ∈ B first connects with each broker b∗ ∈ ACb and
8 ct=Aut , c ← 0;
obtains Fb2∗ and F g b∗ offline. ACb denotes the set of brokers
9 while G1 (ct||c) ∈ I do
that are authorized to access the tasks posted by broker b.
10 C = I[G1 (ct||c)] ⊕ G2 (ct||c), c++;
Broker b computes Autb→b∗ , which is an encrypted value
11 T ← T + C; ∗
indicating then authorizationo relationship of broker b to b and
12 Record T on the blockchain; then sends Fb∗ , Autb→b∗ to the smart contract. Finally, the
g
13 Decryption smart contract adds received Autb→b∗ to A[F b∗ ].
g
14 Read T on the blockchain; Encrypted on-chain task index design: After initializing
15 Request session keys from corresponding brokers and the system, brokers will analyze their local requirement-
decrypt T to get the matching tasks; task indexes and build on-chain task indexes. The building
procedures of encrypted on-chain task indexes are presented
Algorithm 4: Post New On-chain Task Index in Algorithm 2. For a given encrypted requirement H(w),
Input: secure PRFs {G1 , G2 }; newly added encrypted broker b ∈ B first computes the on-chain search trapdoor trap
task requirement H(w); newly added task ID and divides T set(H(w)) into α blocks. T set(H(w)) is the
set T set∗ ; on-chain task index I; table S. set of tasks corresponding to H(w) in the current batch of
Output: Newly generated on-chain task index I ∗ . tasks. p denotes the number of tasks in each block, which is
a parameter chosen by brokers. Then, for each block, broker
1 Broker b posts new tasks
b packages the task IDs in it into one through concatenation
2 for each encrypted requirement H(w) do
1 and generates the label via computing G1 (trap||s). s denotes
3 trap ← g H(w)·Fb ; the state of H(w), which increments by 1 each time. We use s
4 if H(w) not in S then to ensure that peer nodes cannot distinguish whether multiple
5 s ← 0; on-chain task indexes posted by the same broker correspond
6 Put [H(w) : s] to table S; to the same requirement. By traversing all states, we can get
7 else all task indexes about H(w) posted by broker b. After that,
8 s ← S[H(w)]; we compute G2 (trap||s) and use it as an overlay to protect
l ∗
m the ciphertexts C. Finally, broker b maintains the state table
9 Set α ← |T set (H(w))| ;
p S locally and sends index I to the smart contract.
∗
10 Divide T set (H(w)) into α blocks and pad the Task recommendation protocol: Based on the constructed
last block to p entries if needed; on-chain task indexes and authorization list, Algorithm 3
11 for each block in T set∗ (H(w)) do presents the task recommendation protocol. To find the tasks
12 Tgid ← T id1 ||T id2 || · · · ||T idp ; matching his interest, a worker submits a search request to its
13 C ← Enc(k, T gid); broker b, containing the encrypted interest H(w). When n broker
o
14 label ← G1 (trap||s); b receives H(w), it generates the search token Tb,w , F fb ,
15 P ← G2 (trap||s) ⊕ C; and sends it to the blockchain in the form of smart contract.
16 Put [label : P] to index I ∗ , s++; After receiving the search token, the smart contract first
17 S[H(w)] ← s; gets the authorization relationship set A[F fb ] of broker b. For
18 send I ∗ to the smart contract; each element Aut in A[Fb ], which denotes the authorization
f
relationship of broker b∗ ∈ Sb to broker b, the smart contract
computes on-chain search trapdoor ct. Then the smart contract
B. Protocol Details calculates all labels G1 (ct||c) and gets the encrypted matching
task IDs C in each block posted by broker b∗ via computing
System initialization: In the system initialization phase, bro-
I[G1 (ct||c)] ⊕ G2 (ct||c). After traversing all elements in
kers first generate their corresponding parameters, as shown in

Authorized licensed use limited to: University of Liverpool. Downloaded on November 13,2020 at 11:53:08 UTC from IEEE Xplore. Restrictions apply.
 2020 IEEE/ACM 28th International Symposium on Quality of Service (IWQoS)

Smart Contract
On-chain Authorization Index On-chain Search Label On-chain Task Index
Trapdoor
H(w): 1
(𝑔#!"/#!" ))(+) 2#!" → 𝒈𝑯 𝒘
" # # /𝑭𝟏𝒃𝟏 𝑮 𝒘 /𝑭𝟏𝒃𝟏 ||𝟎 𝟏 "
𝟏 𝒈𝑯 𝑮𝟏 𝒈𝑯 𝒘 /𝑭𝒃𝟏
||𝟎 : 𝐺& 𝑔) + /#!"
||0 ⨁𝐶(
Search Token " # " # " #
𝑭"
𝒃𝟏 : 𝑔#!" /#!" , 𝑔#!# /#!" ,𝑔#!$ /#!" 𝑮𝟏 𝒈𝑯 𝒘 /𝑭𝟏𝒃𝟏 ||𝟏
𝑮𝟏
𝟏
𝒈𝑯 𝒘 /𝑭𝒃𝟏 ||𝟏 : 𝐺&
"
𝑔) + /#!" ||1 ⨁𝐶& Broker b2
& , 𝑭"
H(w)∙𝐹%( 𝒃𝟏 #" /## #" /## #" /##
𝐹"
%& : 𝑔 !" !# , 𝑔 !# !# , 𝑔 !$ !#
𝟏 "
(𝑔#!#/#!" ))(+) 2#!" → 𝒈𝑯 𝒘
" # # /𝑭𝟏𝒃𝟐 𝑮 𝒘 /𝑭𝟏𝒃𝟐 ||𝟎
Broker b1 𝟏 𝒈𝑯 𝑮𝟏 𝒈𝑯 𝒘 /𝑭𝒃𝟐
||𝟎 : 𝐺& 𝑔) + /#!#
||0 ⨁𝐶'
" /## " # " #
H(w): 1 𝐹"
%' : 𝑔
#!" !$ , 𝑔 #!#/#!$ , 𝑔 #!$ /#!$
𝒘 /𝑭𝟏𝒃𝟐 ||𝟏 𝑮𝟏 𝒈𝑯
𝟏
𝒘 /𝑭𝒃𝟐
||𝟏 : 𝐺& 𝑔)
"
+ /#!#
||1 ⨁𝐶1
𝑮𝟏 𝒈𝑯 H(w): 0
𝟏
𝑯 𝒘 /𝑭𝒃𝟑 "
) + /#!$
))(+) 2 𝑮𝟏 𝒈 ||𝟎 : 𝐺& 𝑔 ||0 ⨁𝐶2
" /## #
(𝑔 #!$ !" #!" → 𝒈𝑯 𝒘 /𝑭 𝟏
𝒃𝟑 𝑮𝟏 𝒈𝑯 𝒘 /𝑭𝟏𝒃𝟑 ||𝟎
Broker b3

Fig. 2: Encrypted On-chain Task Recommendation Illustration

1
A[Ffb ], the smart contract will get the ID set of all tasks the task index label G1 (g H(w)·Fb2 ||2) is not in the existing on-
matching the searched interest. Eventually, broker b and the chain task indexes. It means all the tasks uploaded by broker
worker can read the matching result on the blockchain and ask b2 matching the searched interest have been found. Then the
for tasks from respective brokers. smart contract will choose another on-chain search trapdoor
Post new on-chain task index: After receiving a certain and repeat the above work until the IDs of all matching tasks
batch of new tasks uploaded by task-requesters, brokers will are returned.
generate new task indexes and submit them on the blockchain.
Algorithm 4 shows the process of posting new tasks. For V. SECURITY ANA LYSIS
an encrypted task requirement H(w), if broker b has not In this section, we provide formal security analysis to show
published tasks about it on the blockchain before, broker b will our proposed on-chain matching services are able to address
initialize its state s to 0. Otherwise, broker b gets the value the threats as mentioned in Section III-B. Firstly, we define
of s through S[H(w)] which is stored in broker b locally, as the setup leakage Lstep for a given task set T set as:
shown in line 4-8 of Algorithm 4. Then broker b packages
these task IDs into blocks and generates new on-chain task LStep = (|A|, h|L|, |P|im ),
indexes. Finally, broker b publishes these newly generated task where |A| is the size of the encrypted authorization list, and
indexes on the blockchain. h|L|, |P|im are ciphertext lengths of m label-task pairs. When
C. On-chain Task Recommendation Instantiation a broker b sends a search request w, the view of an adversary
is defined in the leakage LMatch as:
we use an example to illustrate how PFcrowd works to sup-
port privacy-preserving and authorized task-worker matching LMatch = ({Tb,w , F
fb }, hL, Piq ),
across multiple platforms. As shown in Fig. 2, there are three
brokers b1, b2, and b3 ∈ B in our federated crowdsourcing where {Tb,w , F
fb } are the query trapdoors and hL, Piq are
framework. Each broker is authorized to access the on-chain q matched task set. During the update operations, the leakage
task indexes posted by others. The on-chain authorization function LUpdate captured by an adversary is defined as:
list and task indexes constructed by brokers are shown in
LUpdate = (add, µ),
the orange rectangle part of the figure. To find the tasks
matching his interest, a worker submits H(w) to his broker where add represents insert operations and µ denotes the
b1. After receiving nthe encrypted interest,
o b1 calculates and number of newly added entries. Following the simulation-
2 f based security definition in [15], we give the formal security
sends search token H(w) · Fb1 , Fb1 to the smart contract.
definition as follows:
The smart contract gets the Ff b1 in search token and fetches the
authorization relationship between broker b1 and other brokers Definition 1. Let Ω = (Setup, Match, Update) be our scheme
by using A[Ff b1 ]. Then the smart contract uses each element for secure task-matching services, and let LStep , Lmatch and
in A[Ff 2
b1 ] together with received H(w) · Fb1 to calculate on- LUpdate be the leakage functions. We define the following
chain search trapdoors which are shown in the purple rectangle probabilistic experiments RealC (k) and IdealC,S (k) with a
part. We can see that each authorization relationship in A[Ff b1 ] probabilistic polynomial time (PPT) adversary C and a PPT
corresponds to one on-chain search trapdoor. For one on- simulator S:
1
chain search trapdoor, such as g H(w)·Fb2 , the smart contract RealC (k): C selects a task set T set and asks the broker to
1
calculates the first task index label by concatenating g H(w)·Fb2 build or update the real on-chain indexes via Setup or Update
with a variable c that starts at 0 and increments by 1 each time. algorithm with the private key k. Then C adaptively conducts
Then the smart contract traverses the on-chain task indexes and a polynomial number of queries via Match algorithm. Finally
obtains the corresponding ciphertext C1 . Similarly, the smart C returns a bit as the output.
1
contract obtains the ciphertext C2 by concatenating g H(w)·Fb2 IdealC,S (k): C selects a task set T set, and S simulates the
with c which equals 1. When the value of c is 2, we find that index for C based on LStep . From LUpdate , S performs the

Authorized licensed use limited to: University of Liverpool. Downloaded on November 13,2020 at 11:53:08 UTC from IEEE Xplore. Restrictions apply.
 2020 IEEE/ACM 28th International Symposium on Quality of Service (IWQoS)

update operations. Then C adaptively performs a polynomial TABLE II: Local Time Cost
number of queries. From the leakage LMatch in each task Task Index Posting Task
matching request, S simulates trapdoors and ciphertext, which Initialization New Tasks Recommendation
are processed over the simulated index. Finally, C returns a Number Time(ms) Number Time(ms) Number Time(ms)
bit as the output. 1000 103.2 100 82.1 50 5.34
1400 112.9 200 84.2 100 6.08
Ω is a (LStep , LMatch , LUpdate )-secure scheme, if for all
1800 133.1 300 86.6 150 6.92
PPT adversaries C, there exists a simulator S such that:
2200 143.8 400 89.8 200 7.63
P r[RealC (k) = 1] − P r[IdealC,S (k) = 1] ≤ negl(k), where
2600 150.1 500 91.7 250 8.35
negl(k) is a negligible function in k.
3000 166.2 600 94.1 300 9.14
Theorem 1. Ω is a (LStep , LMatch , LUpdate )-secure scheme
under the random-oracle model if {G1 , G2 } are secure PRFs. TABLE III: Local Authorization Latency
Number of Brokers 4 6 8 10 12 14
Proof. The objective is to prove that the adversary C cannot Time(ms) 11.2 25.1 43.2 71.7 102.9 135.2
distinguish between the real index and the simulated one as
defined in Definition 1. Given LStep , the simulator S generates
the simulated encrypted indexes, which is indistinguishable and Web3.keccak in the cryptography library4 of Python. The
from the real one. It contains |A|-bit random strings as the number of tasks p in each block for brokers is set to 2.
authorization list and m index entries with size |L| and |P|
bits. From LMatch , S can simulate the query and results. For B. Performance Evaluation
the simulated index, S randomly selects the same number q Local performance evaluation: To evaluate the performance
of entries as the query on the real index. The token is selected of PFcrowd, we first assess the local time cost of three types
by a random string T 0 , and the label can be simulated as of operations: task index initialization, posting new tasks, and
0 0
L0 = G01 (g F /T ), where F 0 is a random string from the task recommendation. As shown in Table II, the time cost
simulated list A and G01 is a random oracle. The result can be of task index initialization increases slowly with the growing
simulated as P 0 = G02 (L0 ) ⊕ γ, where G02 is a random oracle number of (r, t) pairs. Specifically, it only takes 166.2ms to
and γ is a random string. The bit length of corresponding initialize task indexes when processing 3000 index entries.
simulated indexes and the real one is the same, but S picks We also assess the incremental scalability by measuring the
random strings every time a previously unseen token is used. time latency for posting new tasks. The time cost of posting
For the update operation, S can add µ simulated entries new tasks includes both generating on-chain task indexes
from LUpdate just like mentioned in build procedures. Due and updating the local state table of brokers. For the task
to the pseudo-randomness of PRF and the semantic security recommendation operation, we test the relationship between
of symmetric encryption, C should not be able to distinguish the latency caused by searching one interest and the number of
the outputs of the real experiment RealC (k) and the simulated matching tasks. We can see that with the number of matching
one IdealC,S (k). tasks increases, the latency of task recommendation grows
steadily. Specifically, when the number of matching tasks
VI. IMPLEMENTATION AND EVALUATION and brokers are 300 and 6 respectively, the recommendation
latency is only 9.14ms, which is much less than the time cost
A. Prototype Implementation
of generating on-chain task indexes.
The goal of PFcrowd is to design a privacy-preserving Moreover, we analyze the change in local authorization
and federated crowdsourcing framework. We implement the latency with the number of brokers, which is shown in Table
prototype in python and use Solidity1 to construct the smart III. We can observe that as the number of brokers gains, the
contract of Ethereum, with about 2000 lines of codes2 . We authorization latency witness a significant increase. Specifi-
use TestRPC to test the smart contract of Ethereum and run cally, when the number of brokers rises from 4 to 14, the
PFcrowd on a laptop with 16 GB RAM, 2.4 GHz CPU, 4 Intel authorization latency increases about 12 times. This is because
cores i5, and a MAC 10.15.1 operating system. The interaction the authorization operation is pair to pair among brokers.
between brokers and Ethereum is based on web3.py3 . In this When one broker joins PFcrowd, it requires authorization from
experiment, we select the task requirements database from other brokers and grant access to other brokers. Therefore,
Upwork, a real-world crowdsourcing platform. We generate the authorization latency presents a non-linear increase as
(r, t) pairs for each broker in PFcrowd, where r and t the number of brokers rises, which is consistent with the
represent task requirements and task identifiers respectively. experimental result.
For cryptographic primitives, we implement the symmetric On-chain performance evaluation: To evaluate the efficiency
encryption and pseudo-random functions via functions AES and overhead of PFcrowd, we further assess its on-chain per-
formance from the perspective of task indexes, authorization,
1 Online at: https://solidity.readthedocs.io/en/develop/ task recommendation, and smart contract cost.
2 Online at: https://github.com/groupJia/IWQOS2020/
3 Online at: https://web3py.readthedocs.io/en/stable/ 4 Online at: https://cryptography.io/en/latest/

Authorized licensed use limited to: University of Liverpool. Downloaded on November 13,2020 at 11:53:08 UTC from IEEE Xplore. Restrictions apply.
 2020 IEEE/ACM 28th International Symposium on Quality of Service (IWQoS)

TABLE IV: Contract Cost Evaluation. The capital cost of smart contract
deployment, posting tasks, authorization and task recommendation are $0.236, 3.5 12
Task indexes initialization Authorization
$0.024, $0.029 and $0.948 respectively, with an exchange rate of 1ether =

Transaction confirmation time (s)

Transaction confirmation time (s)

3.0 10
USD $160.52 and gas price = 1 gwei at the time of writing.
8
Operation Deploy Tasks Posting Authorization Matching 2.5
6
Cost (gas) 1430617 150516 177600 5908513
2.0
4
1.5 2
Fig. 3(a) plots the transaction confirmation time of task 1.0 0
1000 1400 1800 2200 2600 3000 4 6 8 10 12 14
indexes initialization, with the varying number of tasks. From Number of tasks Number of brokers
the figure, we can observe that the transaction confirmation (a) Task indexes initialization (b) Authorization latency
time rises with the growing number of tasks. Specifically, It
only takes less than 3s to initialize the on-chain task indexes 6
Interest-1
4.0
Task-100
when the number of tasks required to be processed equals

Transaction confirmation time (s)

Transaction confirmation time (s)

5 Interest-2 3.5 Task-200
Interest-5 Task-300
3000, which is practical to use in real-life scenarios. 4
3.0
2.5
We further evaluate the transaction confirmation time of 3
2.0
authorization operation, which is shown in Fig. 3(b). It can 2
1.5
be seen that as the number of brokers raises, the transaction
1 1.0
confirmation time of generating the on-chain authorization
0 0.5
list increases gradually. In specific, the smart contract spends 50 100 150 200 250
Number of matching tasks
300 4 6 8 10
Number of brokers
12 14

about 10s to generate the authorization list for 14 brokers in
the system initialization phase. Moreover, when the number
of brokers is 12 and 2 new brokers join in PFcrowd, the time
cost of updating the authorization list is only a bit more than
2s, which is acceptable in real practice.
We also evaluate the recommendation latency of PFcrowd
within the blockchain network. Fig. 3(c) depicts the relation-
ship among transaction confirmation time of task recommen-
dation, the number of matching tasks, and the number of task
recommendation requests (searched interests). Note that the
transaction confirmation time includes the time to obtain the
task matching result and record the result on the blockchain.
We can observe that the transaction confirmation time for one
task recommendation request grows slowly with the increasing
number of matching tasks. As the number of matching tasks
increases from 50 to 300, the transaction confirmation time of
searching one interest only grows approximately one second.
However, when the number of matching tasks is the same,
searching for five interests takes much more time than search-
ing for one interest. Specifically, while the number of matching
tasks is 50, the recommendation confirmation time for five
interests is approximately four times the recommendation
confirmation time for one interest. We can conclude that for
task recommendation operation, the time cost on authorization
relationship computation is longer than other operations.
To gain a deeper understanding of the recommendation
performance, we further measure the time cost of task recom-
mendation for the varying number of brokers under different
numbers of matching tasks, as shown in Fig. 3(d). From the
figure, we can perceive that when the number of matching
tasks remains the same, the recommendation latency increases
with the growing number of brokers. The reason is that
the number of elements in each broker’s authorization set
increases with the growth of the number of brokers. When
one broker sends a task recommendation request, the smart
contract requires to traverse the authorization set of the broker
and generate corresponding on-chain search trapdoors. In this
(c) The recommendation latency vs. (d) The recommendation latency vs.
the number of matching tasks the number of brokers
Fig. 3: On-chain Performance Evaluation
process, the more the number of brokers, the more trapdoors
will be generated and thus the more transaction confirmation
time will be required. Furthermore, as shown in Fig. 3(d),
when the number of brokers remains the same, the time cost
on the task recommendation process rises as the number of
matching tasks gains. This is because when the number of
tasks matching the searched interest rises, increasing time is
required for the smart contract to compute all labels matching
the searched interest and record the task matching result on
the blockchain.
For the smart contract in PFcrowd, it is designed for three
purposes. First, it generates the authorization list for brokers
and records the list on the blockchain. Second, recording
the task indexes posted by brokers on the blockchain. Third,
when one broker submits a task recommendation request, it
recommends matching tasks uploaded by brokers authorizing
the broker to access and then records the matching results
on the blockchain. In PFcrowd, each broker is represented by
an address that is generated in the system setup stage. Only
registered brokers can post task indexes and send task recom-
mendation request on the blockchain. Note that we use gas to
evaluate the performance of our implemented smart contract
on Ethereum. Table IV shows the gas usage and capital cost
of contract deployment, task posting, authorization, and task
recommendation operation. We can see that the capital cost of
each operation is less than $1, which is practical to use.
VII. RELATED WORK
A. Crowdsourcing System
With the growing popularity of crowdsourcing applications,
an increasing number of people are paying attention to the

Authorized licensed use limited to: University of Liverpool. Downloaded on November 13,2020 at 11:53:08 UTC from IEEE Xplore. Restrictions apply.
 2020 IEEE/ACM 28th International Symposium on Quality of Service (IWQoS)
privacy issues that arise in task recommendations. Since the
data uploaded by task-requesters and workers often contains
sensitive information, such as health indicators [16] and
geographic locations [17], it should not be exposed to the
public and untrusted crowdsourcing platforms. To address this
concern, several secure crowdsourcing frameworks [17]–[19]
have been proposed. In [18], To et al. first studied the location
privacy for spatial crowdsourcing and proposed a privacy-
aware crowdsourcing scheme based on differential privacy
and geocasting. Under this scheme, the location privacy of
workers is preserved. Later Gong et al. [19] proposed a
task recommendation framework for mobile crowdsourcing
without violating the privacy of workers. This framework
used differential privacy and cloaking techniques to protect
worker statistics and location information, respectively. How-
ever, protecting privacy by using location cloaking is not a
good choice, as it is vulnerable to some attacks, such as
background knowledge attacks. To enhance security, Shu et
al. [7] proposed a privacy-preserving task recommendation
scheme. The proposed scheme realized multi-keyword match-
ing between multiple task requesters and multiple workers
by using proxy re-encryption and asymmetric scalar-product-
preserving encryption [20] techniques. However, due to the
adoption of proxy re-encryption, this scheme cannot protect
the identity privacy of workers. Liu et al. [21] utilized the dual-
server model and adopted Paillier and ElGamal cryptosystems
to protect the privacy of tasks and workers. Despite extensive
research on secure crowdsourcing, these prior works rely on
a centralized trusted authority for encryption key management
[22] and cannot be directly applied to our federated scenario.
B. Searchable Encryption
Searchable encryption [23]–[25] is a cryptographic prim-
itive that enables untrusted servers to directly search over
encrypted data without server-side decryption. It is recognized
as a fundamental component of building privacy-preserving
applications [26]–[28]. In [23], Song et al. first introduced the
concept of SSE. Subsequently, plenty of studies have been
exploited in this direction [29]–[33]. In [31], Curtmola et
al. introduced the formal security definition of SSE. Later
Cash et al. [30] presented the first SSE scheme supporting
conjunctive search and general boolean queries on encrypted
data. However, early studies of SSE focused on the single-user
setting [34]–[36], in which case the data owner with the secret
key can only search or update his own data. Due to the limi-
tation of the application scope of the single-user SE scheme,
the research of SE in the multi-user scenario [37]–[41] has
also attracted attention recently. In this setting, data users are
allowed to search over encrypted data outsourced by multiple
data owners. In [38], Blaze et al. first introduced the notion of
proxy re-encryption, which was later improved by Bao et al.
[39] to achieve SE in a multi-user scenario. Nevertheless, as
proxy re-encryption is a deterministic algorithm, the schemes
based on it are easy to suffer from statistical attacks [40].
To solve this problem, several studies [41] have been done to
transform different keys by introducing a trusted third-party as
Authorized licensed use limited to: University of Liverpool. Downloaded on November 13,2020 at 11:53:08 UTC from IEEE Xplore. Restrictions apply.
the key manager. However, it is difficult to find an authority
that can be trusted by various parties, and sometimes it may
not exist. Moreover, the above studies assumed that all users
have access to the same set of documents, which cannot realize
authorization-based access. To solve this problem, Popa et
al. [42] introduced a multi-key searchable encryption scheme
that supports searching for data encrypted by different keys.
However, Grubbs et al. [43] pointed out that this design cannot
support the revocation of sharing and its security notion is
insufficient in real settings. Later, Patel et al. [13] proposed
RDH, which can be viewed as an important start point in this
design space. However, RDH cannot be directly employed in
our federated framework, as its deterministic construction may
leak the relation between queried keywords and task indexes
submitted by multiple brokers.
C. Blockchain and Smart Contract
Due to the boom of cryptocurrencies, such as Bitcoin [44]
and Ethereum [45], the blockchain as their underlying technol-
ogy has attracted great attention. To make the blockchain more
powerful, the smart contract was introduced to blockchain
platforms such as Ethereum [45] and Hyperledger [46]. It is a
piece of pre-defined program that can be executed automati-
cally on the blockchain without involving any central authority.
Recently, some efforts [47]–[52] have been made to design
verifiable and blockchain-based search schemes. In [47], Hu et
al. constructed a decentralized financially-fair and privacy-
preserving search scheme by leveraging the smart contract.
In this scheme, all encrypted indexes were stored on top of
the smart contract, which greatly increases the storage cost
of the blockchain. Later, Cai et al. [48] proposed a light-
weight blockchain-based keyword search scheme, where the
files together with the constructed indexes are stored in the
server. In recent years, a few studies [10]–[12] have focused
on the integration of blockchain and crowdsourcing. CrowdBC
[10] developed a blockchain-based decentralized framework
for crowdsourcing, which does not rely on any third party.
This work mainly presented the design of system architecture
and the implementation of the smart contract. Lu et al. [11]
proposed a similar crowdsourcing framework, which aims to
ensure the privacy and anonymity of participants. In [12],
Wu et al. proposed a blockchain-based task matching scheme
for crowdsourcing, in which the task matching process is
transparent and reliable. However, these three solutions still
lock task-requesters and workers in an individual crowdsourc-
ing system and lack a federated crowdsourcing platform that
interconnects existing independent brokers, which is the focus
of this paper.
VIII. CONCLUSION
In this paper, we design and implement the PFcrowd, a
privacy-preserving and federated crowdsourcing framework.
We utilize the blockchain technology to interconnect the
existing crowdsourcing platforms with guaranteed security and
fairness. Specifically, we first devise a secure task recommen-
dation scheme by using our enhanced RDH scheme. We then
 2020 IEEE/ACM 28th International Symposium on Quality of Service (IWQoS)
leverage the structure of SSE and propose a customized design
of on-chain task indexes. We provide a thorough security
analysis to show security strengths. The extensive evaluations
of real-world datasets demonstrate the practicality of PFcrowd.
ACKNOWLEDGMENT
This work was supported by the National Natural Science
Foundation of China Project under Grant No. 61772154,
No. 61732022, and No. 61672195, and the Research Grants
Council of Hong Kong under Project No. CityU 11202419 and
CityU C1008-16G.
R EFERENCES
[1] J. Howe, “The rise of crowdsourcing,” IEEE Wired magazine, vol. 53,
no. 10, pp. 1–14, 2006.
[2] A. Fasoulis, M. Virvou, G. A. Tsihrintzis, C. Patsakis, and E. Alepis,
“Sensus vox: Sentiment mapping through smartphone multi-sensory
crowdsourcing,” in Proc. of IEEE ICTAI, 2018.
[3] S. Murata, H. Yanagida, K. Katahira, S. Suzuki, T. Ogata, and Y. Ya-
mashita, “Large-scale data collection for goal-directed drawing task with
self-report psychiatric symptom questionnaires via crowdsourcing,” in
Proc. of IEEE SMC, 2019.
[4] Upwork, Online at https://www.upwork.com, 2015.
[5] UBER, Online at https://www.uber.com, 2009.
[6] Amazon Mechanical Turk, Online at https://www.mturk.com, 2005.
[7] J. Shu, X. Jia, K. Yang, and H. Wang, “Privacy-preserving task recom-
mendation services for crowdsourcing,” IEEE TSC, 2018.
[8] J. Shu, X. Liu, K. Yang, Y. Zhang, X. Jia, and R. H. Deng, “Sybsub:
Privacy-preserving expressive task subscription with sybil detection in
crowdsourcing,” IEEE IoT-J, vol. 6, no. 2, pp. 3003–3013, 2019.
[9] J. Shu, K. Yang, X. Jia, X. Liu, C. Wang, and R. Deng, “Proxy-free
privacy-preserving task matching with efficient revocation in crowd-
sourcing,” IEEE TDSC, vol. PP, pp. 1–1, 2018.
[10] M. Li, J. Weng, A. Yang, W. Lu, Y. Zhang, L. Hou, J. Liu, Y. Xiang, and
R. H. Deng, “Crowdbc: A blockchain-based decentralized framework for
crowdsourcing,” IEEE TPDS, vol. 30, no. 6, pp. 1251–1266, 2019.
[11] Y. Lu, Q. Tang, and G. Wang, “Zebralancer: Private and anonymous
crowdsourcing system atop open blockchain,” in Proc. of IEEE ICDCS,
2018.
[12] Y. Wu, S. Tang, B. Zhao, and Z. Peng, “BPTM: blockchain-based
privacy-preserving task matching in crowdsourcing,” IEEE Access,
vol. 7, pp. 45 605–45 617, 2019.
[13] S. Patel, G. Persiano, and K. Yeo, “Symmetric searchable encryption
with sharing and unsharing,” in Proc. of ESORICS, 2018.
[14] D. Cash and S. Tessaro, “The locality of searchable symmetric encryp-
tion,” in Proc. of EUROCRYPT, 2014.
[15] D. Cash, J. Jaeger, S. Jarecki, C. S. Jutla, H. Krawczyk, M. Rosu, and
M. Steiner, “Dynamic searchable encryption in very-large databases:
Data structures and implementation,” in Proc. of NDSS, 2014.
[16] P. Créquit, G. Mansouri, M. Benchoufi, A. Vivot, and P. Ravaud, “Map-
ping of crowdsourcing in health: Systematic review,” J Med Internet
Res, vol. 20, no. 5, p. e187, 2018.
[17] Y. Shen, L. Huang, L. Li, X. Lu, S. Wang, and W. Yang, “Towards
preserving worker location privacy in spatial crowdsourcing,” in Proc.
of IEEE GLOBECOM, 2015.
[18] H. To, G. Ghinita, and C. Shahabi, “A framework for protecting worker
location privacy in spatial crowdsourcing,” PVLDB, vol. 7, no. 10, pp.
919–930, 2014.
[19] Y. Gong, L. Wei, Y. Guo, C. Zhang, and Y. Fang, “Optimal for mobile
crowdsourcing with privacy control,” IEEE IoT-J, vol. 3, no. 5, pp. 745–
756, 2016.
[20] W. K. Wong, D. W. Cheung, B. Kao, and N. Mamoulis, “Secure knn
computation on encrypted databases,” in Proc. of ACM SIGMOD, 2009.
[21] A. Liu, W. Wang, S. Shang, Q. Li, and X. Zhang, “Efficient task
assignment in spatial crowdsourcing with worker and task privacy
protection,” GeoInformatica, vol. 22, no. 2, pp. 335–362, 2018.
[22] K. Yang, K. Zhang, J. Ren, and X. Shen, “Security and privacy in mobile
crowdsourcing networks: challenges and opportunities,” IEEE Commun
Mag, vol. 53, no. 8, pp. 75–81, 2015.
Authorized licensed use limited to: University of Liverpool. Downloaded on November 13,2020 at 11:53:08 UTC from IEEE Xplore. Restrictions apply.
[23] D. X. Song, D. A. Wagner, and A. Perrig, “Practical techniques for
searches on encrypted data,” in Proc. of IEEE S&P, 2000.
[24] J. Yao, Y. Zheng, Y. Guo, and C. Wang, “Sok: A systematic study of
attacks in efficient encrypted cloud data search,” in Proc. of SBC, 2020.
[25] R. Curtmola, J. A. Garay, S. Kamara, and R. Ostrovsky, “Searchable
symmetric encryption: improved definitions and efficient constructions,”
in Proc. of CCS, 2006.
[26] Y. Guo, C. Wang, X. Yuan, and X. Jia, “Enabling privacy-preserving
header matching for outsourced middleboxes,” in Proc. of IEEE/ACM
IWQoS, 2018.
[27] Y. Guo, C. Wang, and X. Jia, “Enabling secure and dynamic deep packet
inspection in outsourced middleboxes,” in Proc. of ACM Asiaccs-SCC,
2019.
[28] Y. Guo, M. Wang, C. Wang, X. Yuan, and X. Jia, “Privacy-preserving
packet header checking over in-the-cloud middleboxes,” IEEE IoT-J,
2020.
[29] R. Bost, B. Minaud, and O. Ohrimenko, “Forward and backward private
searchable encryption from constrained cryptographic primitives,” in
Proc. of ACM SIGSAC, 2017.
[30] D. Cash, S. Jarecki, C. S. Jutla, H. Krawczyk, M. Rosu, and M. Steiner,
“Highly-scalable searchable symmetric encryption with support for
boolean queries,” in Proc. of CRYPTO, 2013.
[31] R. Curtmola, J. A. Garay, S. Kamara, and R. Ostrovsky, “Searchable
symmetric encryption: Improved definitions and efficient constructions,”
JCS, vol. 19, pp. 895–934, 2011.
[32] S. Kamara, C. Papamanthou, and T. Roeder, “Dynamic searchable
symmetric encryption,” in Proc. of ACM CCS, 2012.
[33] R. Kui, Y. Guo, J. Li, X. Jia, C. Wang, Y. Zhou, S. Wang, N. Cao, and
F. Li, “Hybridx: New hybrid index for volume-hiding range queries in
data outsourcing services,” in Proc. of IEEE ICDCS, 2020.
[34] H. Cui, Z. Wan, R. H. Deng, G. Wang, and Y. Li, “Efficient and
expressive keyword search over encrypted data in cloud,” IEEE TDSC,
vol. 15, no. 3, pp. 409–422, 2018.
[35] Y. Guo, X. Yuan, X. Wang, C. Wang, B. Li, and X. Jia, “Enabling
encrypted rich queries in distributed key-value stores,” IEEE TPDS,
vol. 30, no. 6, pp. 1283–1297, 2019.
[36] X. Yuan, Y. Guo, X. Wang, C. Wang, B. Li, and X. Jia, “Enckv: An
encrypted key-value store with rich queries,” in Proc. ACM AsiaCCS,
2017.
[37] W. Zhang, Y. Lin, S. Xiao, J. Wu, and S. Zhou, “Privacy preserving
ranked multi-keyword search for multiple data owners in cloud comput-
ing,” IEEE TC, vol. 65, no. 5, pp. 1566–1577, 2016.
[38] M. Blaze, G. Bleumer, and M. Strauss, “Divertible protocols and atomic
proxy cryptography,” in Proc. of EUROCRYPT, 1998.
[39] F. Bao, R. H. Deng, X. Ding, and Y. Yang, “Private query on encrypted
data in multi-user settings,” in Proc. of ISPEC, 2008.
[40] M. Naveed, S. Kamara, and C. V. Wright, “Inference attacks on property-
preserving encrypted databases,” in Proc. of ACM CCS, 2015.
[41] Q. Wang, Y. Guo, H. Huang, and X. Jia., “Multi-user forward secure
dynamic searchable symmetric encryption,” in Proc. of NSS, 2018.
[42] R. A. Popa and N. Zeldovich, “Multi-key searchable encryption,” IACR
Cryptology ePrint Archive, vol. 2013, p. 508, 2013.
[43] P. Grubbs, R. McPherson, M. Naveed, T. Ristenpart, and V. Shmatikov,
“Breaking web applications built on top of encrypted data,” in Proc. of
ACM CCS, 2016.
[44] The Bitcoin Project, Online at https://bitcoin.org/en, 2009.
[45] The Ethereum Project, Online at https://ethereum.org, 2014.
[46] The Hyperledger Project, Online at https://hyperledger.org, 2015.
[47] S. Hu, C. Cai, Q. Wang, C. Wang, X. Luo, and K. Ren, “Searching
an encrypted cloud meets blockchain: A decentralized, reliable and fair
realization,” in Proc. of IEEE INFOCOM, 2018.
[48] C. Cai, J. Weng, X. Yuan, and C. Wang, “Enabling reliable keyword
search in encrypted decentralized storage with fairness,” IEEE TDSC,
2018.
[49] C. Zhang, C. Xu, J. Xu, Y. Tang, and B. Choi, “Gemˆ2-tree: A gas-
efficient structure for authenticated range queries in blockchain,” in Proc.
of IEEE ICDE, 2019.
[50] C. Xu, C. Zhang, and J. Xu, “vchain: Enabling verifiable boolean range
queries over blockchain databases,” in Proc. of ACM SIGMOD, 2019.
[51] J. Yao, Y. Zheng, Y. Guo, C. Cai, A. Zhou, C. Wang, and X. Gui, “A
privacy-preserving system for targeted coupon service,” IEEE Access,
vol. 7, pp. 120 817–120 830, 2019.
[52] Y. Guo, C. Zhang, and X. Jia., “Verifiable and forward-secure encrypted
search using blockchain techniques,” in Proc. of IEEE ICC, 2020.