Received March 6, 2019, accepted March 26, 2019, date of publication April 10, 2019, date of current version

April 16, 2019.

Digital Object Identifier 10.1109/ACCESS.2019.2908265

BPTM: Blockchain-Based Privacy-Preserving

Task Matching in Crowdsourcing
YIMING WU1 , SHAOHUA TANG 1, (Member, IEEE), BOWEN ZHAO1 , AND ZHINIANG PENG2
1 School of Computer Science and Engineering, South China University of Technology, Guangzhou 510640, China
2 Qihoo 360 Core Security, Beijing 100000, China

Corresponding author: Shaohua Tang (shtang@ieee.org)

This work was supported in part by the National Natural Science Foundation of China under Grant 61632013, in part by the Guangdong
Provincial Natural Science Foundation under Grant 2014A030308006, and in part by the Guangdong Provincial Project of Science and
Technology under Grant 2016B090920081.

ABSTRACT Task matching in crowdsourcing is designed to provide convenient task information retrieval
and has been extensively explored. In general, the task matching process is required to be reliable and to meet
privacy requirements. However, most existing privacy-preserving task matching solutions for crowdsourcing
focus on privacy issues but ignore the reliability of the process. In this paper, we propose a blockchain-
based task matching scheme for crowdsourcing with a secure and reliable matching. Instead of utilizing a
centralized cloud server, we employ smart contracts, an emerging blockchain technology, to provide reliable
and transparent matching. In this way, data confidentiality and identity anonymity are achieved effectively
and efficiently. The extensive privacy analysis and performance evaluation show that our solution is secure
and feasible.

INDEX TERMS Crowdsourcing, task matching, blockchain, smart contract, privacy-preserving.

I. INTRODUCTION These sensitive information may be exposed due to the unre-

Crowdsourcing [1] has emerged as an efficient task distri-
bution mechanism, which is usually used to execute high
complexity or wide coverage tasks, such as large scale trans-
lation, specific information collection and high-resolution
image acquisition. Over the past few years, there have been
many crowdsourcing platforms, such as Amazon Mechanical
MTurk1 and CrowdFlower2 . In these platforms, task match-
ing service is especially important when retrieving a large
and growing number of tasks. The efficiency and quality of
task matching services can not only influence the enthusiasm
of participants, but also be an important factor judging the
availability of a crowdsourcing platform.
Task matching in crowdsourcing has caught the attention of
many researchers. In current research, schemes [2], [3], [4]
focus on the association between workers and tasks in
task matching. The process of establishing associations
often involves task requirements and workers’ preferences,
while requirements and preferences are sensitive information.
The associate editor coordinating the review of this manuscript and
approving it for publication was Mamoun Alazab.
1 https://www.mturk.com/mturk/welcome
2 https://www.crowdflower.com
2169-3536
2019 IEEE. Translations and content mining are permitted for academic research only.
VOLUME 7, 2019 Personal use is also permitted, but republication/redistribution requires IEEE permission.
See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
liability and vulnerability of crowdsourcing platforms.
Recently, many researches on privacy-preserving crowd-
sourcing platform have emerged, and most of them focus
only on the privacy of workers, e.g., identity [5], location [6],
and preference [7]. However, the content of tasks and queries
can also reveal the sensitive information of workers and
requesters. Specifically, the crowdsourcing platform can infer
the identity and preferences of workers by combining queries
and task requirements, which means that malicious platforms
may disclose the sensitive data in order to earn extra profits.
Thus, the crowdsourcing platform is required to protect the
privacy of tasks and workers during task matching.
In order to protect privacy, tasks are usually encrypted
before being submitted to the platform. Searchable encryp-
tion (SE) seems to provide a good solution to match
encrypted tasks in crowdsourcing. Most of SE schemes, such
as [8], [9], only support individual data owners to make their
own queries. However, a large number of requesters and
workers simultaneously exist in crowdsourcing. Intuitively,
a single-user SE scheme cannot be directly applied to task
matching in crowdsourcing. There are some extended SE
schemes [10], [11], [12] based on proxy re-encryption tech-
nology, which can be applied to crowdsourcing scenarios
45605
 Y. Wu et al.: BPTM: Blockchain-Based Privacy-Preserving Task Matching in Crowdsourcing
with multiple workers or multiple requesters. In the
proxy-based scheme, the relationship between workers and
re-encryption keys is inevitably determined. Since a query
from workers is required to be re-encrypted on the platform,
a malicious platform may learn the identity information of
workers and requesters by analyzing the association between
re-encryption keys and search history. After the identity infor-
mation is obtained by the malicious platform, the information
may be sold to a third party, resulting in a wider disclosure.
Therefore, it is necessary to achieve the identity anonymity
in crowdsourcing.
When using searchable encryption to construct a matching
scheme, the designer needs to make some assumptions about
the crowdsourcing platform. Most SE solutions consider the
platform to be honest-but-curious or even trusted. However,
there may be some dishonest behavior on the platform in the
task matching service in crowdsourcing. In particular, when a
worker submits a query, malicious platforms may not perform
operations or provide incorrect results in order to save com-
putation cost. The incorrect results reduce the availability of
platforms and affect the enthusiasm of workers. Scheme [11]
has the ability to validate the matching results but requires
additional computations at the worker side, which greatly
reduces the service efficiency. Consequently, how to ensure
the reliable matching of crowdsourcing platforms is a very
challenging issue. It is desirable to a task matching scheme
providing privacy-preserving and reliable matching.
In this paper, we design a blockchain-based privacy-
preserving task matching scheme for crowdsourcing,
called BPTM, which focuses on three issues: (1) privacy-
preserving task matching, where workers’ preferences and
task requirements are well protected; (2) identity anonymity,
where the identity information of workers and requesters will
not be revealed during task matching; (3) reliable matching,
where the returned tasks are corresponding to the worker’s
preferences.
Considering the centralized crowdsourcing platform is vul-
nerable to internal or external attacks and may maliciously
modify the matching results, using traditional centralized
platforms for task matching cannot address these potential
issues. In BPTM, we apply the Ethereum blockchain to build
an autonomous, accurate decentralized platform, which can
be used to replace the potentially dishonest and vulnerable
platform. To achieve the privacy-preserving task matching,
we construct a searchable encryption scheme to protect task
requirements and workers’ preferences. Then we use the
blockchain-based platform to store the encrypted index in
order to provide matching services. By combining smart
contracts with searchable encryption, identity anonymity and
reliable matching can be effectively achieved. Moreover,
we demonstrate that BPTM is secure and feasible through
privacy analysis and performance evaluation. The main con-
tributions of this paper can be summarized as follows:
• This paper systematically analyzes the privacy and util-
ity of task matching in crowdsourcing and also defines
a set of privacy and utility requirements.
45606
• Compared with the proxy-based or blockchain-based
solutions, the BPTM provides identity anonymity to
further protect privacy in crowdsourcing.
• Compared with the solutions that rely on the centralized
platform, the BPTM achieves reliable task matching and
prevents malicious behavior from the adversary.
The rest of the paper is organized as follows. Section II
presents the related work and Section III provides the pre-
liminaries. In Section IV, we formulate the problem of task
matching in crowdsourcing with the system model, threat
model and design goals. In Section V, we describe the
detailed construction of BPTM and also analyze its security.
In Section VI, we implement the BPTM and make a detailed
performance analysis in comparison with the related work
theoretically and experimentally. Finally, we conclude the
paper in Section VII.
II. RELATED WORK
There are two topics related to our research: task matching in
crowdsourcing and searchable encryption. They are discussed
separately below.
A. TASK MATCHING IN CROWDSOURCING
With the growing development and popularity of crowdsourc-
ing, many researches on task matching have emerged. Task
matching in crowdsourcing usually establishes the associa-
tion between workers and tasks through interest [2], loca-
tion [13], or reputation [14]. Considering the security and
privacy issues for crowdsourcing, some studies have focused
on protecting the privacy of workers, such as [5] based on
k-anonymity, [6] based on differential privacy, [7] based on
homomorphic encryption. Furthermore, schemes [15], [16]
based on searchable encryption can simultaneously protect
the characteristics of workers and the requirements of tasks,
which meet the privacy requirements of task matching. How-
ever, all these schemes rely on an honest-but-curious crowd-
sourcing platform ignoring the malicious behavior from the
platform. In fact, crowdsourcing platforms may not be honest,
where malicious platforms can modify matching results for
additional benefits [18]. Specifically, although the privacy of
workers and tasks is protected, the malicious crowdsourcing
platform can modify the matching results through the identity
information of workers and requesters. The incorrect results
hinder further development of crowdsourcing. Therefore,
the existing solutions cannot guarantee the correctness of the
matching results due to the potential threat of centralized
platforms.
B. SEARCHABLE ENCRYPTION
Searchable encryption supports us to implement a secure
matching scheme, enabling workers to retrieve the cor-
responding encrypted tasks. Song et al. [21] first pro-
posed a symmetric searchable encryption mechanism.
Boneh et al. [22] proposed the first searchable encryp-
tion scheme for the public setting. Since the popularity
of cloud storage systems, a lot of schemes have been put
VOLUME 7, 2019
Y. Wu et al.: BPTM: Blockchain-Based Privacy-Preserving Task Matching in Crowdsourcing

TABLE 1. Comparison in utility and security.

forward according to actual needs, including fuzzy key- TABLE 2. Notations used in this paper.
word search [23], ranked search [24] and multi-keyword
search [25]. However, all these schemes only support queries
from data owners, which is not suitable for encrypted data
matching in the multiple participant setting. In order to con-
struct a multi-owner and multi-user model, [26] and [19]
utilize broadcast encryption to generate distinct keys to each
worker based on the public master key, enabling workers
to query encrypted data. However, the broadcast encryp-
tion scheme cannot provide convenient worker registration
and revocation. Once the worker needs to be added or
revoked, the broadcast encryption scheme is required to be
re-initialized. Alternatively, Dong et al. [11], Bao et al. [10]
and Shu et al. [15] achieve the multi-user setting by using
proxy re-encryption. In proxy-based schemes, the proxy
server needs to re-encrypt the information of requesters or
workers with the corresponding re-key, which means that the
proxy server may infer the identity by analyzing the retrieval
behavior.
With the emergence of blockchain technology, some schol-
ars have tried to combine blockchain technology with the
searchable encryption. Different from the previous searchable
encryption scheme based on a centralized cloud storage plat- record of workers will be recorded on the blockchain, which
form, blockchain-based searchable encryption ensures data may result in the disclosure of identity information. Besides
owners control their data against the honest-but-curious plat- the above conventional blockchain-based SE schemes, other
forms. Li et al. [20] proposed the first searchable encryp- schemes of combining blockchains have been studied, such
tion scheme based on Bitcoin system. In their setting, as attribute-based matching [31] and authentication-based
the encrypted data and encrypted indexes are split and stored matching [32], [33]. However, these schemes cannot meet the
at a set of bitcoin transactions. However, as the amount needs of task matching in terms of scalability and efficiency
of data grows, the blockchain needs to maintain a large in crowdsourcing.
number of transactions, which has a high overhead but low This paper intends to achieve utility and security goals as
efficiency. Cai et al. [18] combines an efficient dynamic shown in Table 1. The above existing schemes cannot fully
searchable encryption scheme with blockchain, and estab- possess these features, so they cannot be directly applied to
lishes a trustworthy keyword search scheme in decentralized the task matching in crowdsourcing.
storage. Although this scheme improves the efficiency of the
system, it only supports single data owner to manage the data. III. PRELIMINARIES
Do and Ng [28] and Peng et al. [29] focus on the imple- In this section, we review some background knowledge
mentation of distributed data storage, trying to use smart before going to the details of our construction. All the nota-
contract to manipulate and authorize data. In these distributed tions in the following description can be referred in Table 2.
storage schemes, search permissions depend on the search
authorization from data owners, which is not applicable to A. BLOCKCHAIN TECHNOLOGY AND ETHEREUM
public task matching in crowdsourcing. By leveraging the 1) BLOCKCHAIN TECHNOLOGY
smart contract in Ethereum, Hu et al. [30] propose a decen- Blockchain is the core supporting technology of Bitcoin [34]
tralized privacy-preserving search scheme to build up a fair Ethereum [35] and other cryptocurrency system. The essence
data purchase service, but their construction only supports of the blockchain is a public distributed ledger that allows
upload by a single data owner. In addition, the purchase anyone to participate in. In this way, the failure of a

VOLUME 7, 2019 45607

 Y. Wu et al.: BPTM: Blockchain-Based Privacy-Preserving Task Matching in Crowdsourcing
blockchain node does not affect other nodes. The consensus
mechanism between blockchain nodes maintains the entire
blockchain network, which allows each blockchain node to
obtain a complete copy of the database. Therefore, blockchain
system can only be modified in accordance with strict rules
and consensus.
Blocks and transactions are the main components of the
blockchain network. Each block stores transaction informa-
tion in a certain organization. Each transaction records a
specific set of operations. The cryptographic hash algorithm
and the merkle tree [36] structure ensure that the data cannot
be tampered.
2) ETHEREUM
Smart Contract, first proposed by Nick [37] in 1995, is a
computer program that can be executed automatically accord-
ing to its contents. Ethereum is a programming platform that
enables developers to build distributed applications based
on smart contracts. Specifically, Ethereum can be used for
protocol programming, behavioral assurance and trading,
such as voting, financial transactions, company management,
and signing agreements. Compared to the Bitcoin system,
Ethereum has an innovative feature that enables programs to
be executed on the blockchain. Once the smart contract is
deployed, it can execute the contract without relying on any
central authority. Ideally, the smart contract runs exactly as
programmed, so the results are accurate and verifiable.
FIGURE 1. The structure of smart contract.
We briefly describe the basic principles of smart contracts,
as shown in Fig. 1. The complete smart contract is stored
in a block. When deploying the smart contract, it is neces-
sary to preset the trigger condition and the corresponding
response rule. The relevant status and values are recorded
in the deployed smart contract. Each action from the calling
node will be executed. Only the actions that modify the states
45608
or values of the contract will eventually be recorded in the
blockchain and other actions will not be disclosed.
B. SEARCHABLE ENCRYPTION
Searchable encryption is an effective way to achieve match-
ing of encrypted data. A SE scheme mainly contains three
entities: data owner, data user and the matching server. The
entire definition of SE model can be defined as a tuple SE =
(Setup, Encrypt, Match, Decrypt), shown as follows:
• K ← Setup(1λ ). It is a probabilistic algorithm that is run
by the data owner to setup the service. It takes a security
parameter λ as input and outputs a secret key K .
• (CT , Iw ) ← Encrypt(K , D, w). It is a probabilistic algo-
rithm that is run by the data owner to encrypt tasks.
It takes a task description D, a keyword w and the secret
key K as input, and outputs a keyword ciphertext Iw and
the encrypt tasks CT .
• CT 0 ← Match(K , Iw , w0 ). It is a deterministic algorithm
that is run by the server or the data user U . It takes the
secret key K , query keyword w0 as input, and computes
the trapdoor Tw0 . Then, it takes the trapdoor Tw0 as input,
matches Iw with calculations, and outputs CT 0 .
• D0 ← Decrypt(K , CT 0 ). It is a deterministic algorithm
that is run by the user U . It takes secret key K and the
encrypt tasks CT 0 as input, and outputs the original task
description D0 .
An SE scheme is effective if for all K ← Setup(1λ ), for
all w ∈ {0, 1}∗ , (CT , Iw ) ← Encrypt(K , D, w), CT 0 ←
Match(K , Iw , w0 ), D0 ← Decrypt(K , CT 0 ), we do have D0 =
D if w0 = w.
C. BILINEAR PAIRINGS
G1 , G2 and GT are all multiplicative cyclic groups of prime
order p. Let gi denotes a generator of Gi . A bilinear map e :
G1 × G2 → GT has the following properties:
• Bilinearity: for all u ∈ G1 , v ∈ G2 , and a, b ∈ Z∗ p,
e(u , v ) = e(u, v) .
a b ab
• Non-degeneracy: e(g1 , g2 ) 6 = 1.
• Computability: it is efficient to compute e for any input.
This article will use the following assumption for bilinear
pairing:
Bilinear Decisional Diffie-Hellman Variant (BDHV)
assumption. The BDHV problem is stated as follows: given
1/a 1/a
two tuple (ga1 , gb2 , g2 , gc1 , e(g1 , g2 )abc ) and (ga1 , gb2 , g2 ,
R
gc1 , R) where gi is a generator of Gi , R ←− GT , a, b, c ∈ Z∗p
are chosen randomly. We say that the BDHV assumption
holds if all probabilistic polynomial time machine have a
negligible advantage to distinguish.
IV. PROBLEM FORMULATION
A. SYSTEM MODEL
In our work, we consider a blockchain-based crowdsourc-
ing system that uses smart contracts instead of untrusted
servers for task matching calculations. Task requesters upload
encrypted tasks by interacting with smart contracts so that
VOLUME 7, 2019
Y. Wu et al.: BPTM: Blockchain-Based Privacy-Preserving Task Matching in Crowdsourcing
only authorized workers can match tasks through their inter-
ests. For a matching request, the smart contract will return
the corresponding matching results based on the established
logic and the input from workers. Based on the consensus,
the Ethereum network guarantees that the status of the con-
tract and the returned results are not tampered with, thus
achieving the reliability of task matching.
FIGURE 2. System model of our scheme.
As shown in Fig. 2, there are four entities in the crowd-
sourcing system: a key manager (KM), an Ethereum plat-
form, multiple task requesters and multiple workers. The KM
performs system initialization and provides registration for
requesters and workers. Initially, KM generates the system
parameters and deploys smart contracts on the Ethereum
platform. After obtaining the secret key, the task requester
interacts with the smart contract to upload the encrypted
index. In order to retrieve the related tasks, the workers regis-
ter on KM to obtain trapdoors that meet their characteristics.
When receiving the retrieval request, the Ethereum platform
authenticates the worker address and returns the relevant tasks
through matching calculations. Note that this paper is not
concerned with the storage problem. Encrypted task content
can be stored in the cloud or any distributed storage as long
as the pointer to the task content is recorded in the smart
contract.
B. THREAT MODEL
In this work, KM performs registration and key delivery but
does not store any task information. Thus, the KM is consid-
ered completely trusted and the interaction with KM requires
a secure channel. Both the requesters and the workers are
considered honest in this scenario. It means that the requesters
and the workers would not reveal their secret information,
including their secret keys, trapdoors, identities.
Ethereum is an open platform, so the encrypted task index
stored on the platform is open to all. A blockchain node
is curious to obtain the additional information from the
encrypted index and trapdoors. Besides, the identity informa-
tion and query records are also very sensitive. The adversary
can launch linking attacks to establish a link between query
records and the identities. If the linking attacks are successful,
VOLUME 7, 2019
the adversary can easily determine the identity of workers
by analyzing query records and some external knowledge.
Moreover, a malicious node could be compromised by the
other entity and then return incorrect results to the work-
ers [38]. Similar to the existing blockchain-based crowd-
sourcing applications, such as [39], our structure relies on
Proof-of-Work (PoW) security, where no entity in the system
can gather more than 50% of the processing power [40].
C. DESIGN GOALS
According to the above model, the design goals of our system
are as follows:
• Privacy-preservation. This property requires that the
BPTM should protect the privacy of workers and tasks,
which means that it is impossible for a malicious node
to obtain secret key and task information through the
encrypted data during matching.
• Anonymity. Anonymity protects the identity informa-
tion of workers and requesters, and is required by most
crowdsourcing platforms. Specifically, for a query from
a worker, the identity information cannot be determined;
for a task submission from a requester, no one node
can establish the relationship between the task and the
requestor.
• Soundness. This property is to ensure that the service
provider cannot deviate from the protocol. In general,
the existing work achieves this goal through a series of
validations. In this paper, we extend this notion to claim
that the corresponding search result is reliable, and the
service provider cannot forge or return partial results.
Also, the correct result can be verified by most nodes
in the blockchain.
In addition, considering the use of SE to crowdsourcing,
the following properties should be achieved.
• Efficiency. The computational overhead should be low
enough to ensure that the smart contract is able to pro-
vide matching services. Specifically, the computational
cost of the matching function cannot exceed the gas
limit, and the time overhead should be acceptable.
• No Proxy. A proxy-based SE scheme may reveal identity
privacy. Moreover, the vulnerability of the proxy and
interaction costs result in proxy-based solutions that are
not suitable for task matching.
V. OUR PROPOSED BPTM SCHEME
In this section, we introduce the overview of BPTM, describe
the construction in detail and discuss the security properties.
A. OVERVIEW
In BPTM, we applied the Ethereum blockchain to build
an autonomous, accurate decentralized platform. Specifi-
cally, the blockchain platform is responsible for the release
of crowdsourcing tasks and supports matching calculations
for legitimate workers. However, there are some security
risks associated with using the open Ethereum platform to
implement user management [41]. To solve this dilemma,
45609
 Y. Wu et al.: BPTM: Blockchain-Based Privacy-Preserving Task Matching in Crowdsourcing
BPTM uses a trusted key manager (KM) to distribute keys
and grant permissions. In this way, the blockchain platform is
focused on providing non-tamperable storage and verifiable
task matching. To achieve the privacy-preserving task match-
ing, we construct a searchable encryption scheme to protect
task requirements and workers’ preferences. Since there are
multiple task requesters, we exploit session keys for each task
to achieve confidentiality. Furthermore, our keyword search
in the smart contract is based on the structure of the inverted
index to achieve less computational overhead. To protect the
identity information, the worker retrieves the task by calling
the read-only function of the blockchain, which indicates
that the query and results will not be revealed. Therefore,
the adversary cannot link to the specific worker by analyzing
the query requests. On the other hand, the task requester can
upload the task through an one-task-only blockchain address
to prevent the adversary from linking the identity information.
By combining smart contracts with searchable encryption,
identity anonymity and accurate matching can be effectively
achieved.
B. CONCRETE CONSTRUCTION
The BPTM consists of four phases: Service-Setup, Encrypt,
Match and Decrypt. The detailed BPTM is described below.
1) Service-Setup: This phase is run by the KM to boot-
strap task matching services. Given the security parameter λ,
the KM consider two bilinear groups G, GT of prime order
p with a mapping e : G × G → GT . Let g be a random
generator of group G together with two hash functions
H : {0, 1}∗ → G, G : {0, 1}∗ → {0, 1}λ .
Then KM defines a pseudorandom function
F : {0, 1}∗ × {0, 1}λ → {0, 1}λ .
(Enc, Dec) are the encryption and decryption algorithms
of a deterministic symmetric encryption scheme(e.g. AES
scheme). The KM randomly selects s ∈ Zp as its secret key.
R
For each task requester, KM random select rk ←− {0, 1}λ
and computes tk = gs/rk , then return rsk = (rk, tk) to the
task requester.
In order to ensure the security of the system, the KM
does not provide secret key to registered workers directly.
The trapdoor is generated by KM according to the interests
of worker in registration. In worker registration, the worker
provides a keyword set W = {w1 , w2 , ..., wn } to represent
his/her interests and provides his/her own Ethereum account
address for searching. For each keyword w, the KM computes
wk = H (w)s and returns to worker. Finally, KM adds the
worker account address to the authorized set on the smart
contract.
2) Encrypt: When a task requester R is willing to sub-
mit a task for some purpose, such as software development,
copywriting or engineering design, R generates a specific
crowdsourcing T = {D, tr }, indicating the description and the
requirement, respectively. R first chooses a random session
45610
R
key Ks ←− {0, 1}λ to compute
CT = Enc(Ks , D),
where Enc(Ks , D) denotes using AES algorithm to encrypt D,
the encryption key is Ks . Then, R uploads the ciphertext CT
to cloud or other distributed storage(e.g. IPFS3 ) and records
the task location l. After that, R calculates a temporary key
Krt = G(e(H (tr ), tk)rk ).
R encrypts tr by randomly picking a r ∈ Zp and a session key
R
Ks ←− {0, 1}λ to compute
C1 = F(tr , Krt ),
C2 = G(e(H (tr )r , tk)rk ) ⊕ l k Ks ,
C3 = gr .
Finally, R stores the encrypted index (C1 , C2 , C3 ) to smart
contract.
3) Match: Upon receiving WK = {wk1 , wk2 , ...wkn }
from KM, the worker U first chooses an encrypted keyword
wk ∈ WK to match. Then, U calculates a temporary key
Kut = G(e(wk, g)).
Then, the worker U computes the search trapdoor
t = F(w, Kut )
and invokes smart contract with t as arguments. After U
generates and submits the trapdoor, the smart contract first
judges whether U is an authorized worker. For a search
request from the authorized worker, the smart contract will
return the search result according to the trapdoor t
res = (C2 , C3 ).
For other illegal search requests, the smart contract will reject
the search.
4) Decrypt: Upon receiving res = (C2 , C3 ) from the smart
contract, the worker U first computes
d = G(e(wk, C3 )), l k Ks = C2 ⊕ d.
Then, the worker U downloads the encrypted task CT from l
and computes
D = Dec(Ks , CT ),
where Dec(Ks , CT ) denotes using AES algorithm to
decrypt CT , the decryption key is Ks . Finally U can recovery
original task description td .
We assume that a keyword is w, t is the worker search
key corresponding to w generated by KM, an encrypted index
C containing the keyword q and the results results returned
by the smart contract. We give the proof of the matching
correctness and decryption correctness as follows:
Theorem 1 (Matching Correctness): The task matching
service is correct. That is, c ∈ results if w = q.
3 https://ipfs.io/
VOLUME 7, 2019
Y. Wu et al.: BPTM: Blockchain-Based Privacy-Preserving Task Matching in Crowdsourcing

Proof: Suppose w = q and H is a hash function, we have Algorithm 1 addWorker

Input: newWorkerAddress
H (w) = H (q) Output: bool
⇔ e(H (w)s , g) = e(H (q), gs/rk )rk 1: if msg.sender is not contractOwner then
⇔ e(t, g) = e(H (q), tk)rk . 2: throw;
3: end if
Since G is a hash function, we have 4: if newWorkerAddress has exist then
G(e(t, g)) = G(e(H (q), tk)rk ) 5: return false;
6: else
⇔ Kut = Krt .
7: workerList[newWorkerAddress] = true;
Since F is a pseudo-random function, we have 8: return true;
9: end if
F(w, Kut ) = F(q, Krt ).
That is, Matching(C, t) = 1. This completes the proof. 
Theorem 2 (Decryption Correctness): Only authorized Algorithm 2 removeWorker
workers have the ability to decrypt ciphertexts and get the Input: oldWorkerAddress
correct task description. That is, tasks with a requirement Output: bool
w can only be decrypted by a worker who contains the 1: if msg.sender is not contractOwner then
corresponding search permission wt. 2: throw;
Proof: Suppose the worker has received the ciphertexts 3: end if
C2 , C3 . If the d = G(e(wk, C3 )) calculated by the worker is 4: if oldWorkerAddress hasn’t exist then
the same as the G(e(H (w)r , tk)rk ), the worker has the ability 5: return false;
to decrypt the task. Then we have 6: else
7: workerlist[oldWorkerAddress] = false;
d = G(e(H (w)r , tk)rk ) 8: return true;
⇔ G(e(wk, C3 )) = G(e(H (w)r , tk)rk ) 9: end if
⇔ G(e(H (w0 )s , gr )) = G(e(H (w)r , tk)rk ).
Since G is a hash function, we have
the collection through the relevant function interfaces of the
e(H (w0 ), gr ) = e(H (w), tk)rk
contract.
⇔ e(H (w0 ), gs ) = e(H (w), gs/rk )rk 3) The searchIndex variable of the mapping types, which
⇔ H (w0 ) = H (w). defines a collection from the encrypted keyword indexes to a
structure Index list. This collection is used to store encrypted
Since H is a hash function, we have w0 = w. This com-
tasks from task requesters. The encrypted keyword index is
pletes the proof. 
stored as a bytes type. The structure Index contains three
variables as follows:
C. CONTRACT CONSTRUCTION
The requesterAddr variable of address types, which
In this section we mainly introduce the design and deploy- defines the address of the requester.
ment of the smart contract. We use Ethereum as the exe- The ciphertext variable of a bytes types, which defines the
cution platform for the smart contract. In our construction, encrypted tasks.
smart contract is programmed and developed by solidity The tmp variable of the bytes types. And the value of this
language4 . Specifically, the matching contract used in this variable is used to decrypt the ciphertext.
paper includes five interfaces (addWorker, removeWorker, In addition, the matching contract mainly provides the
addIndex, removeIndex, taskMatching). Also, we use a following five function interfaces:
special variables msg.sender from the global namespace,
which represents the sender of a message or transaction. • addWorker(newWorkerAddress). This interface is
The matching contract deployment is part of the Service- only allowed to be called by the contract’s creator(KM).
Setup and is deployed by KM. The initialization process After the worker completes registration at KM, the KM
defines some variables required for the contract. updates the workerList variable by calling algorithm 1 to
1) The contractOwner variable of address types, which provide permission.
defines the address of the KM. • removeWorker(oldWorkerAddress). Corresponding
2) The workerList variable of the mapping types, which to addWorker, this removeWorker interface can only
defines a collection from address to a bool value, showing be executed by the contract’s creator (KM). When the
the search permission of workers. The KM can add or modify system needs to delete a worker, the KM uses this
function to remove worker from the authorized set. The
4 http://solidity.readthedocs.io/en/latest specific operation is as shown in algorithm 2.

VOLUME 7, 2019 45611

 Y. Wu et al.: BPTM: Blockchain-Based Privacy-Preserving Task Matching in Crowdsourcing
Algorithm 3 addIndex
Input: keywordIndex, encryptedTask, tmpParameter
Output: bool
1: set Index[] res = searchIndex[keywordIndex];
2: get res length len
3: for i ∈ [1, len] do
4: if msg.sender = res[i].requersterAddr then
5: throw;
6: end if
7: end for
8: set Index tmpI ;
9: set tmpI.requesterAddr = msg.sender;
10: set tmpI.ciphertext = encryptedTask;
11: set tmpI.tmp = tmpParameter;
12: add tmpI to searchIndex[keywordIndex];
13: return True;
Algorithm 4 removeIndex
Input: keywordIndex, tmpParameter
Output: bool
1: set Index[] res = searchIndex[keywordIndex];
2: get res length len
3: for i ∈ [1, len] do
4: if msg.sender = res[i].requersterAddr then
5: if tmpParameter = res[i].tmp then
6: delete searchIndex[keywordIndex][i];
7: end if
8: end if
9: end for
10: return True;
• addIndex(keywordIndex, encryptedTask, tmpPa-
rameter). The task requester can upload the encrypted
task through this interface. For a specific task, only
his owner can modify and delete it. According to the
construction described above, when a requester wants to
publish a task, he selects the keywords from the task and
builds the corresponding encrypted index (C1 , C2 , C3 )
represents the input keywordIndex, encryptedTask
and tmpParameter, respectively. Taking as input the
requester address and encrypted index, the matching
contract performs as Algorithm 3 to store the task
information.
• removeIndex(keywordIndex, tmpParameter). This
interface is open to the task owner. When the task
has been completed or canceled, the task requester can
delete the encrypted index by uploading keywordIndex
and tmpParameter to the smart contract. The smart
contract performs Algorithm 4 to delete the task.
• taskMatching(trapdoor). This interface can be called
by any authorized worker. According to the construc-
tion described above, when a worker wants to retrieve
the related tasks, he computes the search trapdoor
45612
Algorithm 5 taskMatching
Input: trapdoors
Output: results, tmpParameters
1: if msg.sender not in workerList then
2: throw;
3: end if
4: set a list results;
5: set a list tmpParameters;
6: for t ∈ trapdoors do
7: set Index[] res = searchIndex[t];
8: get res length len;
9: for i ∈ [1, len] do
10: add res[i].ciphertext to results;
11: add res[i].tmp to tmpParameters;
12: end for
13: end for
14: return list results and list tmpParameters;
set represents the input trapdoors. Then, the worker
uploads the trapdoors to this interface for task retrieval.
Taking as input the worker address and the search trap-
doors, the matching contract performs as Algorithm 5 to
returns the matching results.
The four interfaces (addWorker, removeWorker, addIn-
dex, removeIndex) mentioned above will change the state
of the smart contract, which means that the process con-
sumes the property of the caller’s account. Since the requester
uploads the task based on a one-task-only blockchain address,
the addIndex interface does not verify the address. The
taskMatching interface is identified by the keyword view,
indicating that this process does not change the state. Inter-
faces that do not change state will not incur any cost and will
not be recorded on the blockchain.
D. SECURITY ANALYSIS
As defined by the privacy requirements in Section IV, the pro-
posed scheme achieves Privacy-preservation, Anonymity and
Soundness as follows:
Privacy-Preservation: Based on the security definitions
proposed in [30], if F is a pseudorandom function and G is a
collision resistant hash function, then our matching construc-
tion has the same security as [30]. Furthermore, our decrypt
construction can be proven secure in the random oracle model
under variants of the BDHV assumptions. Thus, the adver-
sary cannot distinguish the difference between two arbitrary
encrypted indexes. This means that the secret key and task
information will not be revealed even though the index is
public. In addition, the matching process is performed by
the static interface that does not change the blockchain state.
In this way, the search process and the results are not stored
publicly on the blockchain, which avoids the passive attacks.
Therefore, the proposed scheme provides the security of
encrypted indexes and protects the privacy during the task
matching.
VOLUME 7, 2019
Y. Wu et al.: BPTM: Blockchain-Based Privacy-Preserving Task Matching in Crowdsourcing
Anonymity: Anonymity requires that the privacy informa-
tion of workers and requesters cannot be explored by link-
ing their behavior [42]. Workers’ anonymity represents the
query unlinkability between retrieval and worker identity.
Similarly, requesters’ anonymity can be understood as the
submission unlinkability between task submission and iden-
tity information. For our construction, worker identity infor-
mation is replaced by a random blockchain address and the
retrieval operation is performed on a trusted node (e.g. local
node); requester identity information is also replaced by
an address, but task submission will be recorded on the
blockchain because the status of the smart contract has
changed. To obtain the identity information, an adversary can
associate the blockchain address with a worker/requester, or
link to a specific worker/requester by the authentication infor-
mation. Because the workers do not reveal any interaction,
an adversary can neither detect the retrieval behavior nor link
to a specific worker, even though he corrupts an registered
task requester and owns all the information on the blockchain
platforms. Since the encrypted indexes is independent of the
blockchain address, each task requester can interact with a
new randomly blockchain address. And because the identity
address is random and the encrypted tasks is indistinguish-
able, the adversary cannot establish a link between the task
and the requester.
Soundness: Generally, the correct results depend on an
honest service provider. In our scheme, the matching process
is achieved through the smart contract on Ethereum. As long
as the security of Ethereum is guaranteed, our scheme can
achieve soundness. This is because smart contracts perform
calculations based on the current state and response logic on
Ethereum. And each miner in Ethereum uses the proof of
work (POW) algorithms to achieve consensus, which means
that illegally modifying the state in the smart contract requires
over half resources of the entire network. Therefore, the pro-
posed scheme with the correct state and execution logic will
provide the correct matching for authorized workers.
Extension: Compared with the previous blockchain-based
solutions that only support simple search, e.g., the single-
setting or single-keyword matching, our proposed scheme
has a good extensibility. By constructing smart contracts,
our solutions support effective worker revocation and can be
adapted to provide various matching services by combining
existing SE solutions. For example, the BPTM can inte-
grate fuzzy matching [25], pattern matching [43] and ranked
search [24] to support more plentiful functions. In general,
task matching in crowdsourcing is required to have extensi-
bility in order to meet the increasingly diverse matching needs
of workers.
VI. EXPERIMENTAL EVALUATION
In this section, we implemented the proposed BPTM scheme
to evaluate performance, and compare it to two related
schemes (SEMEKS [19] and pMatch [16]).
VOLUME 7, 2019
A. EXPERIMENTAL SETTING
In this section, we implemented a prototype to evaluate
the practical performance of BPTM. Since BPTM combines
blockchain and searchable encryption, we use two different
implementation environments for different entities:
• Ethereum platform: We implement it on the Ubuntu
14.04 virtual machine with a single core at 2.93GHZ
and 2GB RAM in solidity with Ethereum. Then,
we deployed the smart contract on the Ethereum offi-
cial test network Rinkeby for storing encrypted indexes
and matching. When we conducted the experiment,
the gasPrice was set to 2Gwei, where 1Gwei =
109 wei = 10−9 ether. At the time of writing this paper,
the exchange rate between ether and the USD is 1 ether =
250 USD.
• KM, requester and worker: These three entities mainly
perform the calculation and transmission of searchable
encryption. We implement it on the Ubuntu 14.04 virtual
machine with a single at 3.6GHZ and 4GB RAM in
Python 3.4 with the Pairing-Based Cryptography (PBC)
library with version 0.5.14.
In the comparison of searchable encryption program,
we realize SEMEKS, pMatch and the part of PBTM based
on SS512(|G| = 512 bits, |GT | = 1024 bits), which is a sym-
metric elliptic curve with base field 512-bit and embedding
degree 2. The hash function H is the function in PBC library,
the hash function G and the pseudorandom function F are
based on SHA256.
B. EVALUATION RESULT
Table 1 lists the major differences of our BPTM from
the comparison schemes in terms of utility and security.
Compared with the previous multi-user searchable encryp-
tion schemes (MSDE and MuED), BPTM supports identity
anonymity to meet privacy needs in crowdsourcing. Com-
pared with the crowdsourcing solution requiring an hon-
est service platform (PPTR and pMatch), PBTM supports
privacy-preservation while matching correctness is guaran-
teed by the smart contract. Compared with some blockchain-
based scheme (BC-SE and TPSE), BPTM focuses on
functional requirements in crowdsourcing scenarios such as
multi-owner setting, revocable setting. Meanwhile, we ana-
lyze each algorithm in three different schemes in terms of
computation complexity in Table 3. In our scheme, the time
complexity of the matching algorithm is O(1), so in Table 3,
we analyze the complexity of matching and decryption
together. Next, we perform a detailed performance evaluation
for each entity as follows.
1) ETHEREUM PLATFORM
The costs on the Ethereum platform in BPTM are mainly
from the smart contract. The gas overhead results of the
smart contracts measured by experiments are as follows.
In Table 4, the gas costs of contract create, addWorker and
45613
 Y. Wu et al.: BPTM: Blockchain-Based Privacy-Preserving Task Matching in Crowdsourcing
TABLE 3. Computation overhead.
TABLE 4. Smart contract cost test (gasprice=2 Gwei ,1 ether = 250 USD).
TABLE 5. Smart contract cost test under different number of task (gasprice=2 Gwei ,1 ether = 250 USD).
removeWorker of the smart contract are listed, and the cost of
performing these interfaces is almost unchanged. The match-
ing contract creates interface is only executed once by KM
to complete the initialization and the costs are $0.478. The
addWorker interface is executed by KM when the worker
completes the registration; The removeWorker interface is
required when KM needs to remove a worker from the autho-
rization set. The cost of these two interfaces being called
is $0.029 and $0.007. Then, we built the encrypted indexes
for five different numbers of tasks 1, 5, 10, 15, and 20,
respectively. Table 5 shows the gas overhead required for
addIndex and delIndex under different number of tasks. As
the number of tasks increases, the cost of these three inter-
faces being called increases accordingly. Specifically, the gas
overhead of addIndex increases linearly with the number
of tasks, and the cost of adding five encrypted indexes is
approximately $0.536. When performing the delIndex cost
evaluation, we delete the encrypted index in the correspond-
ing keyword. According to calculations, the cost of deleting
5 encrypted indexes is approximately $0.041. Although call-
ing the matching interface does not incur a fee, we also eval-
uate the gas cost for different number of matching operations
to assess the speed of task matching. Since the data structure
used by the taskMatching interface is a hash table and the
calculation of the index is adjusted by G or F, the cost of
the correct search is similar. As shown in the table, it takes
300,000 gas to search 5 times correctly. In our experimental
environment, the execution time of a 300000 gas operation
is no more than 1 second, so the matching process time is
acceptable.
45614
TABLE 6. The taskMatching cost test (gasprice=2 Gwei ).
2) KM
In the system initialization, the KM set up the system through
the Service-Setup. As analyzed in Table 3, the overall time
cost of system initialization in BPTM is linear with the num-
ber of participants and the computation complexity of secret
key generation is W · (H + E) for each worker, E for each
requester. First, we vary the different number of workers (n)
from 1,000 to 10,000 to measure the computation cost of
secret key generation for both schemes, as shown in Fig. 3(a).
Our BPTM slightly outperforms pMatch and far outperforms
SEMEKS. For example, when n = 10, 000, it takes about
85s for BPTM while SEMEKS requires 450s. Then, we addi-
tionally calculate the computational cost of BPTM under
different task requesters 100, 500, 1000 respectively. In the
crowdsourcing platform, the number of task requesters is
generally smaller than the number of workers, so setting the
1000 task requesters can meet the needs of most crowdsourc-
ing platforms. We observe that in the BPTM under different
requesters, as the number of task requesters becomes higher,
the corresponding time consumption is also slightly higher,
as shown in Fig. 3(b). For the most expensive BPTM-r1000,
it takes about 90 seconds to set up a system of 10,000 workers,
which is a one-time cost and acceptable for KM.
VOLUME 7, 2019
Y. Wu et al.: BPTM: Blockchain-Based Privacy-Preserving Task Matching in Crowdsourcing

FIGURE 3. The time cost of the KM. (a) Time cost of worker registration. FIGURE 4. The time and transmission cost of the requester. (a) Time cost
(b) Time cost of worker and requester registration. of task encryption. (b) Transmission cost of ciphertexts.

3) REQUESTER
The overhead on each requester mainly includes the compu-
tation and transmission costs in the phase of Encrypt. The
computation complexity of keyword encryption in BPTM is
(H + F + P + 2G + 2E + Enc), which is slightly less than
(5E +H ) for pMatch and less than 9E for SEMEKS, as shown
in Table 3. In Fig. 4(a), we vary the different number of key-
words (k) in the task requirement to compare the efficiency
and find that BPTM is more efficient. We additionally carry
out the transmission overhead of interacting with the smart
contract. We vary the different number of encrypted indexes
from 1 to 20 to calculate the overhead and find that the FIGURE 5. The time cost of the worker.
transmission overhead is proportional to the gas consumption
of the smart contract. As illustrated in Fig.4(b), the overhead is (P + G + Dec), pMatch is (4E + H + 4P), and SEKEE
of uploading 20 ciphertexts to smart contracts is about 5.5kb, is (12E + 5P). Fig. 5 shows that the total time for different
and the corresponding cost of smart contracts is $1.7755. number of ciphertexts in BPTM is more efficient than that in
pMatch and SEMEKS. For example, it only takes about 1.2s
4) WORKER to match and decrypt 10 ciphertexts in BPTM while it takes
The overhead on each worker mainly includes the computa- almost 0.3s in pMatch, almost 0.5s in SEMEKS.
tion cost in the phase of Matching and Decrypt. Since the
trapdoor generation is based on the worker interest and is only VII. CONCLUSION
executed once, the trapdoor generation time is negligible. In this paper, we studied the privacy and utility issues in task
In this process, pMatch and SEMEKS have a cloud server matching for crowdsourcing and proposed the BPTM scheme
entity to assist the calculation, but we don’t have this entity, that supports multiple requesters and multiple workers by
so our comparison combines the process of matching and combining Ethereum blockchain and searchable encryption
decryption. Table 3 shows the computational cost of BPTM technology. In BPTM, we exploited the smart contract on

VOLUME 7, 2019 45615

 Y. Wu et al.: BPTM: Blockchain-Based Privacy-Preserving Task Matching in Crowdsourcing
the Ethereum to achieve task matching, ensuring that the
service provider cannot deviate from the protocol. We also
designed a privacy-preserving matching protocol to estab-
lish the association between workers and tasks, where the
interests of workers and the requirements of tasks are well
protected. Compared with the existing privacy-preserving
solutions, the BPTM further protects privacy by achieving
identity anonymity. Finally, we analyzed the performance of
the proposed scheme from both theoretical and experimental
aspects. The detailed performance evaluation demonstrates
the rationality and feasibility of our proposed scheme for the
practical use.
VIII. ACKNOWLEGMENT
Z. Peng was with the South China University of Technology,
and this work was done during his Ph.D. degree at SCUT.
REFERENCES
[1] J. Howe, ‘‘The rise of crowdsourcing,’’ Wired Mag., vol. 14, no. 6,
pp. 1–4, Jun. 2006.
[2] X. Yin, Y. Chen, and B. Li, ‘‘Task assignment with guaranteed quality for
crowdsourcing platforms,’’ in Proc. IEEE 25th Int. Symp. Qual. Service,
Jun. 2017, pp. 1–10.
[3] M. C. Yuen, I. King, and K. S. Leung, ‘‘Task matching in crowdsourcing,’’
in Proc. 4th Int. Conf. Internet Things Cyber, Phys. Social Comput.,
Oct. 2011, pp. 409–412.
[4] J. Zhang, F. Tang, L. Barolli, Y. Yang, and W. Xu, ‘‘Information gain based
maximum task matching in spatial crowdsourcing,’’ in Proc. IEEE 31st Int.
Conf. Adv. Inf. Netw. Appl., Mar. 2017, pp. 886–893.
[5] S. Wu, X. Wang, S. Wang, Z. Zhang, and A. K. Tung, ‘‘K-anonymity for
crowdsourcing database,’’ IEEE Trans. Knowl. Data Eng., vol. 26, no. 9,
pp. 2207–2221, Sep. 2014.
[6] H. To, G. Ghinita, L. Fan, and C. Shahabi, ‘‘Differentially private location
protection for worker datasets in spatial crowdsourcing,’’ IEEE Trans.
Mobile Comput., vol. 16, no. 4, pp. 934–949, Apr. 2017.
[7] Y. Shen, L. Huang, L. Li, X. Lu, S. Wang, and W. Yang, ‘‘Towards
preserving worker location privacy in spatial crowdsourcing,’’ in Proc.
IEEE Global Commun. Conf., Dec. 2015, pp. 1–6.
[8] D. Cash et al., ‘‘Dynamic searchable encryption in very-large databases:
Data structures and implementation,’’ in Proc. NDSS, vol. 14, Feb. 2014,
pp. 23–26.
[9] Z. Fu, K. Ren, J. Shu, X. Sun, and F. Huang, ‘‘Enabling personalized
search over encrypted outsourced data with efficiency improvement,’’
IEEE Trans. Parallel Distrib. Syst., vol. 27, no. 9, pp. 2546–2559,
Sep. 2016.
[10] F. Bao, R. H. Deng, X. Ding, and Y. Yang, ‘‘Private query on encrypted
data in multi-user settings,’’ in Proc. Int. Conf. Inf. Secur. Pract. Exper.,
Apr. 2008, pp. 71–85.
[11] C. Dong, G. Russello, and N. Dulay, ‘‘Shared and searchable encrypted
data for untrusted servers,’’ J. Comput. Secur., vol. 19, no. 3,
pp. 367–397, 2011.
[12] W. Zhang, Y. Lin, S. Xiao, J. Wu, and S. Zhou, ‘‘Privacy preserving ranked
multi-keyword search for multiple data owners in cloud computing,’’ IEEE
Trans. Comput., vol. 65, no. 5, pp. 1566–1577, May 2016.
[13] L. Kong, L. He, X. Y. Liu, Y. Gu, M. Y. Wu, and X. Liu, ‘‘Privacy-
preserving compressive sensing for crowdsensing based trajectory recov-
ery,’’ in Proc. IEEE 35th Int. Conf. Distrib. Comput. Syst., Jul. 2015,
pp. 31–40.
[14] L. Ma, X. Liu, Q. Pei, and Y. Xiang, ‘‘Privacy-preserving reputation
management for edge computing enhanced mobile crowdsensing,’’ IEEE
Trans. Serv. Comput., to be published. doi: 10.1109/TSC.2018.2825986.
[15] J. Shu, X. Jia, K. Yang, and H. Wang, ‘‘Privacy-preserving task recom-
mendation services for crowdsourcing,’’ IEEE Trans. Serv. Comput., to be
published. doi: 10.1109/TSC.2018.2791601.
[16] 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 Trans. Depend. Sec. Comput., to be published. doi:
10.1109/TDSC.2018.2875682.
[17] J. Shu, X. Liu, Y. Zhang, X. Jia, and R. H. Deng, ‘‘Dual-side privacy-
preserving task matching for spatial crowdsourcing,’’ J. Netw. Comput.
Appl., vol. 123, pp. 101–111, Dec. 2018.
45616
[18] C. Cai, X. Yuan, and C. Wang, ‘‘Towards trustworthy and private keyword
search in encrypted decentralized storage,’’ in Proc. IEEE Int. Conf. Com-
mun., May 2017, pp. 1–7.
[19] A. Kiayias, O. Oksuz, A. Russell, Q. Tang, and B. Wang, ‘‘Efficient
encrypted keyword search for multi-user data sharing,’’ in Proc. Eur. Symp.
Res. Comput. Secur., Sep. 2016, pp. 173–195.
[20] H. Li, H. Tian, F. Zhang, and J. He, ‘‘Blockchain-based searchable symmet-
ric encryption scheme,’’ Comput. Elect. Eng., vol. 73, pp. 32–45, Jan. 2019.
[21] D. X. Song, D. Wagner, and A. Perrig, ‘‘Practical techniques for searches
on encrypted data,’’ in Proc. IEEE Symp. Secur. Privacy, May 2000,
pp. 44–55.
[22] D. Boneh, G. Di Crescenzo, R. Ostrovsky, and G. Persiano, ‘‘Public
key encryption with keyword search,’’ in Proc. Int. Conf. Theory Appl.
Cryptograph. Techn., May 2004, pp. 506–522.
[23] Z. Fu, X. Wu, C. Guan, X. Sun, and K. Ren, ‘‘Toward efficient multi-
keyword fuzzy search over encrypted outsourced data with accuracy
improvement,’’ IEEE Trans. Inf. Forensics Security, vol. 11, no. 12,
pp. 2706–2716, Dec. 2016.
[24] N. Cao, C. Wang, M. Li, K. Ren, and W. Lou, ‘‘Privacy-preserving multi-
keyword ranked search over encrypted cloud data,’’ IEEE Trans. Parallel
Distrib. Syst., vol. 25, no. 1, pp. 222–233, Jan. 2014.
[25] B. Wang, S. Yu, W. Lou, and Y. T. Hou, ‘‘Privacy-preserving multi-
keyword fuzzy search over encrypted data in the cloud,’’ in Proc. IEEE
Conf. Comput. Commun., May 2014, pp. 2112–2120.
[26] C. Wang, N. Cao, J. Li, K. Ren, and W. Lou, ‘‘Secure ranked keyword
search over encrypted cloud data,’’ in Proc. IEEE 30th Int. Conf. Distrib.
Comput. Syst., Jun. 2010, pp. 253–262.
[27] Y. Yu, Y. Li, J. Tian, and J. Liu, ‘‘Blockchain-based solutions to security
and privacy issues in the Internet of Things,’’ IEEE Wireless Commun.,
vol. 25, no. 6, pp. 12–18, Dec. 2018.
[28] H. G. Do and W. K. Ng, ‘‘Blockchain-based system for secure data storage
with private keyword search,’’ in Proc. IEEE World Congr. Services,
Jun. 2017, pp. 90–93.
[29] J. Peng, F. Guo, K. Liang, J. Lai, and Q. Wen, ‘‘Searchain: Blockchain-
based private keyword search in decentralized storage,’’ J. Future Gener.
Comput. Syst., vol. 12, Sep. 2017. doi: 10.1016/j.future.2017.08.036.
[30] S. Hu, C. Cai, Q. Wang, C. Wang, X. Luo, and K. Ren, ‘‘Search-
ing an encrypted cloud meets blockchain: A decentralized, reliable and
fair realization,’’ in Proc. IEEE Conf. Comput. Commun., Apr. 2018,
pp. 792–800.
[31] S. Wang, Y. Zhang, and Y. Zhang, ‘‘A blockchain-based framework for data
sharing with fine-grained access control in decentralized storage systems,’’
IEEE Access, vol. 6, pp. 38437–38450, Jun. 2018.
[32] Y. Zhang, R. H. Deng, J. Shu, K. Yang, and D. Zheng, ‘‘TKSE: Trust-
worthy keyword search over encrypted data with two-side verifiability via
blockchain,’’ IEEE Access, vol. 6, pp. 31077–31087, Jun. 2018.
[33] Y. Zhao, Y. Li, Q. Mu, B. Yang, and Y. Yu, ‘‘Secure pub-sub: Blockchain-
based fair payment with reputation for reliable cyber physical systems,’’
IEEE Access, vol. 6, pp. 12295–12303, Jan. 2018.
[34] S. Nakamoto. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System.
[Online]. Available: https://bitcoin.org/
[35] G. Wood, ‘‘Ethereum: A secure decentralised generalised transaction
ledger,’’ Ethereum Project, Zug, Switzerland, Yellow Paper, 2014,
pp. 1–32, vol. 151. [Online]. Available: https://ethereum.org.
[36] R. C. Merkle, ‘‘A digital signature based on a conventional encryption
function,’’ in Proc. Conf. Theory Appl. Cryptograph. Techn., Aug. 1987,
pp. 369–378.
[37] S. Nick, ‘‘Formalizing and securing relationships on public networks,’’
First Monday, vol. 2, no. 9, pp. 1–2, Sep. 1997.
[38] X. Liu, G. Yang, Y. Mu, and R. Deng, ‘‘Multi-user verifiable searchable
symmetric encryption for cloud storage,’’ IEEE Trans. Depend. Sec. Com-
put., to be published. doi: 10.1109/TDSC.2018.2876831.
[39] M. Li et al., ‘‘CrowdBC: A blockchain-based decentralized framework for
crowdsourcing,’’ IEEE Trans. Parallel Distrib. Syst., to be published. doi:
10.1109/tpds.2018.2881735.
[40] A. Gervais, G. O. Karame, K. Wüst, V. Glykantzis, H. Ritzdorf, and
S. Capkun, ‘‘On the security and performance of proof of work
blockchains,’’ in Proc. Conf. Comput. Commun. Secur., Oct. 2016,
pp. 3–16.
[41] J. Wang, M. Li, Y. He, H. Li, K. Xiao, and C. Wang, ‘‘A blockchain based
privacy-preserving incentive mechanism in crowdsensing applications,’’
IEEE Access, vol. 6, p. 17545–17556, Mar. 2018.
[42] 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, Aug. 2015.
[43] D. Wang, X. Jia, C. Wang, K. Yang, S. Fu, and M. Xu, ‘‘Generalized pattern
matching string search on encrypted data in cloud systems,’’ in Proc. IEEE
Conf. Comput. Commun., May 2015, pp. 2101–2109.
VOLUME 7, 2019
Y. Wu et al.: BPTM: Blockchain-Based Privacy-Preserving Task Matching in Crowdsourcing
YIMING WU received the B.S. degree in software
engineering in the direction of information secu-
rity from the Wuhan University of Technology,
Wuhan, China, in 2017. He is currently pursuing
the M.S. degree with the South China University of
Technology. His research interests include infor-
mation security and blockchain technology.
SHAOHUA TANG (M’99) received the B.S. and
M.S. degrees in applied mathematics and the Ph.D.
degree in communication and information sys-
tem from the South China University of Technol-
ogy, China, in 1991, 1994, and 1998, respectively,
where he has been a Full Professor with the School
of Computer Science and Engineering, since 2004.
He was a Visiting Scholar with North Carolina
State University, USA, and a Visiting Professor
with the University of Cincinnati, USA. He has
authored or coauthored over 100 technical papers in journals and conference
proceedings. His current research interests include information security, data
security, and privacy preserving in cloud computing and big data. He is a
member of the IEEE Computer Society.
VOLUME 7, 2019
BOWEN ZHAO received the B.S. degree in infor-
mation security from the Hunan University of Sci-
ence and Technology, China, in 2014, and the M.S.
degree in information security from Guangxi Uni-
versity, China, in 2017. He is currently pursuing
the Ph.D. degree with the South China Univer-
sity of Technology. His research interests include
information security and privacy preserving in
cloud computing and big data.
ZHINIANG PENG received the B.E. degree in
materials science and the Ph.D. degree in cryptog-
raphy from the South China University of Technol-
ogy, in 2013 and 2017, respectively. He is currently
a Cybersecurity Researcher with Qihoo 360 Core
Security. His current research interests include
software security and applied cryptography.
45617