CP-ABE Based Privacy-Preserving User Profile Matching in Mobile Social Networks.

Privacy-preserving profile matching, a challenging task in mobile social networks, is getting more attention in recent years. In this paper, we propose a novel scheme that is based on ciphertext-policy attribute-based encryption to tackle this problem. In our scheme, a user can submit a preference-profile and search for users with matching-profile in decentralized mobile social networks. In this process, no participant's profile and the submitted preference-profile is exposed. Meanwhile, a secure communication channel can be established between the pair of successfully matched users. In contrast to existing related schemes which are mainly based on the secure multi-party computation, our scheme can provide verifiability (both the initiator and any unmatched user cannot cheat each other to pretend to be matched), and requires few interactions among users. We provide thorough security analysis and performance evaluation on our scheme, and show its advantages in terms of security, efficiency and usability over state-of-the-art schemes.

Introduction

Discovering and interacting with people within a certain distance according to personal preferences is a crucial service provided by mobile social networks (MSN), which is helping us to stay connected better than ever. Let us imagine the following two scenarios. (1) At the airport, a passenger wants to discover and connect with the nearby passengers who come from the same university. (2) In the hospital, a patient wants to find similar patients according to their disease symptoms and medications for physical or mental support. In MSN, all such requirements can be satisfied by user profile matching very quickly and accurately.

Generally speaking, user profile is a set of attributes generated by users to describe themselves for special friending purpose when they join social networks. For example, in the first scenario, the user profile of a passenger may include his/her age, sex, university from which he/she graduated, company in which he/she is working and his/her destination, etc. In the second scenario, the user profile of a patient may include his/her disease symptoms, medications being taken and his/her doctor, etc. The meaning of “matching” can be defined from different perspectives. For instance, if we consider the user profile as an attribute set, two profiles are matched when the number of their common attributes exceeds a certain threshold. If we consider the user profile as an attribute vector, the meaning of “matching” can be defined as that the distance of the two attribute vectors is less than a certain threshold.

Nowadays, a lot of exciting mobile applications based on user profile matching have been generated. Small-talks [1] connects proximate users based on their common interests. Color [2] allows people in close proximity (within 50 meters) to share photos automatically based on their similarity. MagnetU [3] can automatically match one with nearby users who have the similar profile.

However, such systems also raise a number of privacy concerns. Obviously, directly exchanging the user profiles without any protection may open a door to a variety of attacks. Let us take the aforementioned two scenarios for example. In the first scenario, if an adversary can access the preference-profile submitted by the initiator, he/she may pretend to be the matched one, make contact with the initiator and implement further deception. In the second scenario, if the profiles of patients are directly exchanged with each other, it will facilitate user profiling where that sensitive and private information can be easily collected by a nearby user, either in an active or passive way.

Therefore, the demand for privacy protection motivates people to find privacy-preserving profile matching schemes which make the friending in MSN more secure. The most direct solution is to take advantage of a trusted central server to collect information from individual users, compute and disseminate the matching results on demand [4][5][6]. However, this solution may be unsuitable for MSN. First, it requires the user to access the mobile Internet. But, in practice the mobile Internet may not always be available, and it may incur a high expense. Second, the central server may become a bottleneck when a failure or attack occurs. For these reasons, the distributed solution in which users are able to well protect their personal information without the help of a trusted central server is more suitable for MSN, especially for MSN based on short-range wireless technologies such as WiFi and Bluetooth [7][8].

Several distributed solutions of the privacy-preserving profile matching problem have been proposed in recent years. They are mainly based on secure multi-party computation (SMC), and can be divided into two mainstreams. The first category treats user profile as attribute set and computes the similarity between two users based on private set intersection (PSC) and private cardinality of set intersection (PSCI) [9][10]. The second category describes user profile as an attribute vector and measures the similarity by secure dot-product computation[11][12][13]. These methods rely on public-key cryptosystem and homomorphic encryption, which results in expensive computation cost. Multiple rounds of interactions are required to perform the presetting and profile matching between each pair of users, which means higher communication cost. In these methods, both matched users and unmatched users are required to take on nearly the same expensive computation and communication cost. Furthermore, most of these methods are unverifiable, which means some malicious adversaries may forge their profiles or return the false calculation results to deceive the initiator.

In this paper, we propose a novel privacy-preserving profile matching scheme which can overcome the above disadvantages. Our scheme is based on ciphertext-policy attribute-based encryption (CP-ABE). Its basic idea is simple. When an initiator wants to search for nearby users who meet his/her preference, he/she generates a ciphertext using CP-ABE at first. His/her preference-profile is taken as the ciphertext access policy and embedded into the ciphertext. This ciphertext is sent to nearby users. Only the matched user whose profile includes the preference-profile can decrypt the ciphertext correctly. Then he/she can choose to communicate with the initiator.

Despite a simple solution, there are two main challenges that should be carefully addressed.

First, there are a lot of CP-ABE constructions, but most of them cannot be applied to our scheme. The most important reason is that the ciphertext access policies in these constructions are accessible to anyone. However, in our application context, the ciphertext access policy (preference-profile) should be hidden for privacy-preserving. In addition, in most CP-ABE constructions, both the size of ciphertext and decryption time increase linearly with the number of user attributes, which cannot satisfy the requirements in terms of communication and computation efficiency in our application context. Therefore, considering the security and efficiency, we have to find out a CP-ABE construction that provides receiver anonymity through hidden access policy while ensuring the constant size of ciphertext and constant decryption time. Facing this challenge, in our work, a special CP-ABE construction [14] with hidden access policy, constant length of ciphertext and constant decryption time is chosen as the foundation of our privacy-preserving profile matching scheme. It builds on the prime order group, and relies on asymmetric decision bilinear diffie-hellman (DBDH) assumption. It was shown to be fully secure with respect to the standard model.

Second, in the CP-ABE constructions applied in our work, the size of access policy is required to be equal to the size of user attributes. However, in our application context, the length of the preference-profile is not necessarily equal to the length of profile of matching user. In fact, the meaning of “matching” in our scheme is “including”. That is to say, the profile of the matched user must include all the attributes in the preference-profile. Therefore, we have to design a mechanism to enable the original CP-ABE construction to satisfy such a requirement. In order to overcome this barrier, we modify the original key generation algorithm, design a data structure named reminder vector, and design the corresponding algorithm to achieve fast matching.

In summary, the main contributions of this paper are as follows. We design a CP-ABE based privacy-preserving user profile matching scheme. In addition to the capability of privacy-preserving, our method has the following advantages compared with existing related methods. First, it provides verifiability, which means any participant cannot cheat the initiator with the wrong matching result. Second, it can help the matched pair to establish a secure communication channel, which is ignored by most related works. Moreover, the unmatched user can be ruled out very quickly. Furthermore, only a few interactions between the initiator and matching user are required because the matching user can determine the matching result without the help of the initiator, which is significant for decreasing the computation and communication cost.

The rest of this paper is organized as follows. Section Preliminaries presents some preliminaries of CP-ABE. Section System Model and Problem Definition gives the system model and problem definition. Section Our Design describes the protocol design in detail. Section Security and Performance Analysis presents the security proof and efficiency analysis. The experiment results are shown in section Performance Analysis. The comparison with related works is presented in section Related Works and Comparison. Finally, we conclude our works in section Conclusion.

Preliminaries

Since the CP-ABE construction is the foundation of our work, we introduce the basic knowledge about it in this section. We first give a brief review of attribute-based encryption. Then we describe the syntax of CP-ABE. Finally, we briefly present how to prove the security of a CP-ABE construction.

Attribute-Based Encryption

The traditional public-key encryption (PKE) [15] is a powerful mechanism to ensure the confidentiality of data storage and transmission. It can work effectively in the scenario that the user who encrypts the sensitive data knows exactly the identity and public key of the recipient. However, in a large complex distributed network environment users often cannot get the public keys and identities from all the recipients. In such a scenario, it is often imperative that user who encrypts sensitive data establishes a specific access control policy on who can decrypt this data. Such requirement led to the evolution of the identity-based encryption (IBE) [16] and then to the attribute-based encryption (ABE) as pioneered in [17]. Using ABE, user can specify a certain policy based on attributes of the recipients, and only the recipient whose attributes meet the policy can decrypt the ciphertext. Since we always manage people or things or thing by their attributes in real life, the ABE is realistic for the real environment.

There are two flavours of ABE defined, i.e. key-policy attribute-based encryption (KP-ABE) [18] and ciphertext-policy attribute-based encryption (CP-ABE) [19]. In KP-ABE, each ciphertext is associated with a set of attributes, and each user secret key is associated with a threshold access structure (i.e. access policy) on attributes. Decryption is enabled if and only if the ciphertext attribute set satisfies the access structure of the user secret key. In CP-ABE the situation is reversed: attributes are associated with user secret keys and access structures with ciphertexts.

Our solution is based on CP-ABE. Although there are a lot of CP-ABE constructions, most of them cannot be applied to our scheme for the reason mentioned in section Introduction. In this paper, we choose a special CP-ABE construction proposed by Xie Li et al. [14]. It can provide receiver anonymity by hiding the access policy. Moreover, the length of ciphertext and decryption time in it are constant. Its details are presented in section Our Design.

The Syntax of CP-ABE

In general, a CP-ABE construction consists of the following four algorithms.

Setup(1) → PK, MK. This algorithm takes the security parameter k as input and generates a public key PK and a master key MK.

Key Generation(MK, L) → SK. This algorithm takes the master key MK and a set of attributes L as input and outputs the user’s private key SK associated with L. In other words, the user’s attribute set L describes his private key SK and determines his right for decryption.

Encrypt(PK, M, W) → CT. The user uses public key PK, and ciphertext access policy W to encrypt message M, and outputs the ciphertext CT. Only the user whose attributes meet W can decrypt CT correctly.

Decrypt(PK, CT, SK) → M. In this algorithm, the user uses public key PK, his/her private key SK, and his/her own attribute set L to decrypt CT. He/She can decrypt CT correctly when and only when his/her attribute set L meets the access policy contained in CT.

The details of the CP-ABE construction used in our protocol can be seen in section Our Design.

Bilinear Maps and Complexity Assumptions

Bilinear Maps

We give the definition of bilinear map here.

Definition 1. (Bilinear Map). Assume G, and G are three multiplicative cyclic groups of the same prime order p. A bilinear map is a deterministic function, which takes as input one element from G, and one element from , and outputs an element in group G , which satisfies the following criteria:

Bilinearity: For all x ∈ G, ,a, b ∈ Z, e(x, y) = e(x, y).

Non degeneracy: where g and are generators of G and .

e must be computed efficiently.

If , we call it a symmetric bilinear map, otherwise it is a asymmetrical bilinear map. Our CP-ABE construction is based on the asymmetrical bilinear map.

Decisional Bilinear Diffie-Hellman (DBDH) Assumption

DBDH [20] is a complexity assumption which is a cornerstone of the security of ABE. The security of our CP-ABE construction is based on asymmetric DBDH assumption [21] which is extended from the DBDH assumption to asymmetric bilinear groups.

Assume is a asymmetrical bilinear map, where the order of and G are all prime p. g and are the generators of G and respectively. Consider such a game: the challenger chooses a, b, c at random and then flips a fair binary coin β and outputs the tuple (g, g, g, , , , Z). If β = 1, , otherwise, Z is randomly chosen from G. The adversary in this game must then output a guess β′ of β.

The advantage ϵ of a adversary to win this game is defined as: The DBDH problem now is considered as a NP problem, which means currently there are no probabilistic polynomial-time algorithms to win such a game with a non-negligible advantage.

Definition 2. The (t,ϵ) asymmetric DBDH assumption holds in ( ) if there is no t-time algorithm can solve it with advantage at least ϵ.

Security Definitions of CP-ABE

Now we describe the definition of semantic security against passive adversaries for our CP-ABE. Consider the following challenger-adversary game:

Setup: The challenger runs the algorithm Setup to generate a public key PK and a mast key MK, then gives PK to the adversary.

Phase 1: The adversary is allowed to make a series of queries adaptively for private keys associated with attribute lists L1, L2, …, L, 1 ≤ i < q. In response, The challenger generates private keys SK1, SK2, …, SK, and sends them to the adversary.

Challenge: The adversary submits two equal length massages M0, M1 and two access policies W0, W1 which are not allowed to be satisfied by any attribute list L queried by adversary in phase 1. Then the challenger randomly chooses r, e ∈ {0,1}, generates the ciphertext T = Encrypt(PK, M, W) and sends it to the adversary as challenger ciphertext.

phase 2: Phase 1 is repeated with the restriction that the queried attribute lists L, L, …, L can not satisfy W0, W1.

Guess: The adversary submits a guess r′ of r, and e′ of e and wins this game if r′ = r and e′ = e.

Definition 3. Let ϵ be the advantage of the adversary to win the game mentioned above, . A CP-ABE construction with hidden access policy is (t, q, ϵ)-semantically secure if all t-time adversaries making at most q private key queries have at most an ϵ in breaking the construction.

System Model and Problem Definition

System Model

User Profile

In general, each user in a MSN system has a profile, which is the description of himself/herself. In this paper, the user profile is a set of attributes. Table 1 shows a simple example of the profile of user Bob. The first column shows the attribute category names, and the second column shows the corresponding values. Formally, let be the attribute space consisting of n attribute categories, . Each has m candidate values, A = {a, a, …, a}. A user profile, which is called attribute list hereafter, is generated by two steps. In step one, choose the attribute categories. Next, choose a specific value for each category. The attribute list of user u can be represented as . Each comes from different attribute categories. That is to say, for and , j1 ≠ j2 if k1 ≠ k2. The number of attributes is not necessary the same for different users. Notably, elements in the attribute list are sorted according to the order of the corresponding attribute categories in , which is vital for profile matching in our scheme.

Table 1

Bob’s profile.

Attribute Category	Attribute Value
Age	22
Sex	male
Blood Type	A
Zodiac Sign	Virgos
Home Town	Xi’an
University	NPU
Profession	teacher
Interest	Basketball

Profile Matching

Let L be an attribute list sent by an initiator u who wants to search for friends in our system, and L be the attribute list of the user u who is in physical proximity to u. The profile matching between u and u can be formally described as a function matching: That is to say, if the query attribute list L is a subset of u’s attribute list L, then the matching operation will be successful.

Our System Model

Fig 1 shows our system model. There are five different roles in it. Attribute authority is the trusted central server which can be accessed by all users. Remarkably, the access to it only occurs in the initial phase where the user creates his/her own profile, submits registration information and gets the attribute private key. The process of profile matching does not need the server involvement. Initiator is the user who sends out the query attribute list. A matched user is one whose attribute list matches the initiator’s query attribute list. An unmatched user is one whose attribute list cannot match the query attribute list. The adversary is a malicious unmatched user who wants to guess the content of query attribute list and even make a further deception. In our system model, we assume that each user controls just one mobile device.

Fig 1

Our System Model.

In our system model, users have to download the mobile application based on our protocol from the Internet and set it up on their smart phone. When the application runs for the first time, each user has to create his/her attribute list by choosing attributes from a given attribute space, then submit it to the attribute authority for registration. After that, the attribute authority generates the attribute private key according to the attribute list and sends it together with the public key PK back to the user. In addition to that, each user has to generate a pair of keys according to certain predefined public key encryption algorithm.

When an initiator wants to find matched user according to his/her preference in a particular circumstance such as bar, airport or hospital, he/she first generates a query attribute list, and takes it as the access policy to generate a ciphertext which contains his/her own public key. This ciphertext is sent to nearby users. Only the matched user can decrypt the ciphertext correctly. Then, the matched user can choose to communicates with the initiator, and send back a shared communication key encrypted by the initiator’s public key. Remarkably, this process do not need any help of the attribute authority server.

Adversary Model

In our system, only the matched user is able to learn the content of the query attribute list. If each participant honestly follows our protocol, any unmatched user cannot infer any information from the ciphertext sent by the initiator. However, out of some illegal purpose, the adversary may implement a series of malicious attacks for getting the private information of legitimate users. In this work, we mainly consider the following two powerful malicious attacks.

Dictionary profiling. The adversary tries to determine the query attribute list by enumerating or guessing all combinations of attributes.

Cheating. In the process of profile matching, the adversary may cheat by deviating from the agreed protocol, e.g., cheat the initiator with a wrong matching result.

In addition to these two attacks, the adversary may eavesdrop on the conversation between the initiator and the matched user. All these attacks should be well prevented in our scheme.

Preserving the privacy of user profile. Only the matched user is able to learn the initiator’s query attribute list. Others cannot infer any information from the query package. Especially, the dictionary profiling attack can be well prevented.

Providing verifiability. Any user is unable to forge a matching result, which means the cheating attack cannot be implemented successfully.

Providing secure communication channel. A secure communication channel can be established between the matched pair, which can effectively thwart the eavesdropping attack.

Efficiently filtering. Since the number of potential friends is usually much smaller than the total number of users in the network, we should efficiently filter out most of the unmatched users so as to speed up the matching process and decrease the computation and communication cost.

Fewer interactions. Most of the related schemes need multiple rounds of interactions in the profile matching process for privacy-preserving, which causes high computation and communication costs. Therefore, we should try to reduce the number of interactions as much as possible.

Our Design

Overview

The main idea of our work is to use the query attribute list L as the parameter W of the CP-ABE algorithm Encrypt(PK, M, W) to encrypt a message, and sent out to users in physical proximity. Only the user whose attribute list L matches L (L ⊆ L) can decrypt the message correctly, and then can establish a secure communication channel with the initiator by using the information recovered from the encrypted message. The CP-ABE construction adopted in our work has two characteristics. First, it is receiver anonymous, which means the query attribute list (as the access policy) is hidden in a ciphertext and only the matched user can learn its content. Second, both the length of ciphertext and decryption time in it are constant.

Fig 2 shows the main process of our privacy-preserving profile matching scheme. For easy understanding, Table 2 lists and explains the notations used in Fig 2. Initially, each user gets PK and SK′ from the attribute authority. Here, SK′ is the user’s attribute private key, which is generated and assigned by the attribute authority according to user’s attribute list L. Meanwhile, a pair of keys KU (public key) and KR (private key) are generated by themselves according to the same public key encryption algorithm such as RSA. This key pair will be used for establishing a secure communication channel between the matched users.

Fig 2

Main process of our scheme.

Table 2

Table of notations.

Lr	Query attribute list, a set of ordered attributes, used for describing the initiator’s preference profile.
RLr	Reminder vector, generated according to Lr and used for fast filtering.
PK	Attribute public key, generated by attribute authority and used by initiator for encrypting message according to CP-ABE scheme.
KU, KR	User key pair. KU (public key) and KR (private key) is a pair of keys generated by each user according to certain public key encryption algorithm such as RSA. They are used for establishing a secure communication channel between the matched users.
N	Temporary interactive number. N is a random number generated by initiator. It is used for authenticated key exchange when the match is successful.
CT	Ciphertext, generated by encrypting KU and N according to CP-ABE scheme.
L	Attribute list, a set of ordered attributes used for describing user’s profile.
L_can	Candidate attribute list set. It is the result of fast filter. Each component of L_can is an subset of L (called candidate attribute list) which is potentially equal to Lr.
SK′	User’s attribute private key, generated and assigned by attribute authority according to user’s attribute list L.
SKcan	Candidate user’s private key. The matching user generates a set of SKcan according to L_can and SK′. Only one SKcan can decrypt the CT correctly.
KS	Shared communication key, generated by the matched user. The initiator and the matched user can use it for a further secure communication.

The initiator starts the matching process by creating a preference-profile. Then, it is converted to a query attribute list L and a reminder vector R which is used for fast filtering in the following steps. After that, the initiator generates a random number N which will be used for authenticated key exchange when the match is successful. Next, the algorithm Encrypt using L and PK as parameters is called to encrypt the message which contains KU and N. It outputs the ciphertext CT. Finally, a query package, which contains R, CT and KU, is generated and sent out for profile matching.

When a user in physical proximity to the initiator receives the query package, he/she first makes a fast filtering computation according to R contained in received message and his/her own attribute list L, and outputs a set of candidate attribute lists . Each component of is an subset of L (called candidate attribute list) which is potentially equal to L. If is null, the profile matching fails. Otherwise, using and SK′ as input, a set of candidate private keys are figured out. Each candidate private key SK in this set is used by the matching user to try to decrypt the ciphertext CT. In order to confirm the correctness of the decryption result, KU′, which is gained by decrypting CT, is compared with KU. The decryption result is correct if these two keys are equal, which means the matching successful. After that, the matched user can choose to communicate with the initiator. Specifically, he/she can generate a shared secret key, encrypt it together with N using KU, and send it back to the initiator. When the initiator gets the shared communication key KS, a secure pair-wise secure communication channel can be established between the matched pair by using certain symmetric encryption scheme. The details can be seen in protocol 1.

The CP-ABE Construction

As we can see in Fig 2, an appropriate CP-ABE construction is the core of our method. Literature [14] provides such a CP-ABE construction, where the ciphertext length is constant and the access policy is hidden. Therefore, we adopt it in our work with a modification in terms of the key generation algorithm. Its formal description is described as follows.

Setup(1): In the phase of system initialization, the attribute authority chooses two different groups G, with the same prime order p according to the security parameter 1. let denotes the bilinear map and g, be the generators of G, respectively. Then, the attribute authority chooses secrets , , and gets values , , g2 = g, , f = g. The symbol “∈” means “randomly choose from”.

Let be the attribute space, . Each is a attribute category, which consists of a set of attributes, A = {a, a, …, a}. For each attribute a ∈ A, the attribute authority chooses , computes . Let , the public key PK is The master private key MK is

KeyGeneration(MK, L): Let L = {l1, l2, …, l} be an attribute list that consists of a set of attributes. Each l in L comes from a certain attribute category, i.e., l ∈ A. A private key for L is generated as follows. First, a random is chosen. Then compute The private key is SK = {D0, D1}.

Notably, we assume for ∀L, L′(L ≠ L′), ∑ ψ ≠ ∑ ψ. If there exist L and L′(L ≠ L′) such that ∑ ψ = ∑ ψ, a user with attribute list L′ can decrypt a ciphertext associated with access police W, where L′ ⊭ W and L ⊨ W. Remark that the assumption holds with overwhelming probability , where . Therefore, if each secret key ψ is chosen at random from , then our assumption is natural [22].

However, this key generation algorithm cannot be applied in our setting directly. In order to illustrate the reason, consider the following example. Assume the attribute list of the user u is L = {a1,2, a2,6, a3,3, a4,7, a5,1}, a ∈ A. Now assume the query attribute list is L = {a1,2, a3,3}. Given a ciphertext encrypted by L, although L ⊂ L, the user u cannot decrypt the ciphertext by SK. The reason is ∑ ψ ≠ ∑ ψ. In order to address this problem, we modify the original key generation algorithm. We decompose the original algorithm KeyGeneration into two steps which run on the attribute authority side and the user side respectively. These two steps are:

KeyGenA(MK, L)→SK′. This algorithm runs on the attribute authority side, and its input parameters is the same as that of the original algorithm KeyGeneration. It outputs a private key SK′ containing three parts. . In that,

KeyGenU(SK′, L)→SK. This algorithm runs on the user side. It takes the output of keyGenA and a candidate attribute list L = {l, l, …, l}(L ⊆ L) as input, outputs the candidate private key SK which contains two components. SK = {D0, D}. In that,

Now let us continue to consider the example. According to our modified algorithm, , , , , , . When the user u chose L = {a1,2, a3,3} as the candidate attribute list according to the hint provide by the reminder vector, he can use D0, , , to generate the candidate key. Here, ∑ ψ = ∑ ψ. Therefore, SK is able to be used to decrypt the ciphertext correctly.

Encrypt(PK, M, W): Parameter W is the access policy that determines who can decrypt the ciphertext. Let W = {w1, w2, …, w}. Each w in W comes from a certain attribute category, i.e., w ∈ A. For message M ∈ G, the encryptor chooses , then computes as follows: The algorithm outputs the ciphertext .

Decrypt(PK, CT, SK): In this algorithm, a decryptor computes (This computation is based on the original KeyGeneration algorithm. If the input parameter is SK, the ciphertext is computed as ). Its correctness is shown as follows:

If the bilinear map is symmetrical, which means , the adversary can guess the access policy W by DDH test. That is to say, the adversary randomly chooses an access policy W′, computes e(C0, f∏ Ψ) = e(g, f∏ Ψ), then determines whether it equals e(g, C1) = e(g, (f∏ Ψ)). The adversary can repeat such a computation until he finds the W′ which may be equal to W. However, in our scheme, , and the adversary cannot get . Therefore, the adversary cannot implement the DDH test mentioned here to guess the access policy W. That is why our CP-ABE scheme is able to hide the access policy and achieve receiver anonymity.

Filtering Out The Unmatched User

Obviously, the number of potential matched users is usually much smaller than the total number of users in a network. Based on this fact, we design a mechanism to fast filter out the unmatched user so as to improve the profile matching efficiency. The key data structure of this mechanism is the reminder vector, the components of which are reminders of the hash values of the corresponding attributes in the attribute list divided by λ. Such a reminder vector is sent to other users together with the query attribute list by the initiator. For users involved in matching, the first step after receiving the query package is to determine if he/she is the potential target of the initiator by comparing his/her own attribute list with the reminder vector. If not, the profile matching process ends. Otherwise, the further matching computation is implemented.

Reminder Vector

Assume that there are q attributes in the query attribute list . λ is a prime larger than q. Let Hash be a cryptographic hash function which yields n-bit length hash values. A reminder vector R consists of the reminders of all hash values of attributes in L divided by λ. For each l ∈ L, Let , then R = {r1, r2, …, r}. The following theorem is straightforward.

Theorem 1 Consider two attributes l, l, reminder r ≡ Hash(l) mod λ, r ≡ Hash(l) mod λ, if r ≠ r, then l ≠ l.

The Fast Filtering Algorithm

Algorithm 1 describes how to rule out the unmatched user quickly. It takes a reminder vector R, a user attribute list L and a prime λ as inputs, and outputs a candidate attribute list set . If , it means the user’s attribute list cannot match the query attribute list.

In our system model, the number of attributes is not necessary the same for different users. According to our definition of “matching”, for any potential matched user, the length of his/her attribute list must be greater than the length of the query attribute list. Lines 1 to 3 in algorithm 1 does such a check to rule out the users whose attribute list length cannot satisfy this requirement. In lines 4 to 14, for each r ∈ R, an attribute set H is constructed. Here ∀l ∈ H, r ≡ Hash(l) mod λ. In other words, let be the corresponding attribute of r ∈ R, each l ∈ H is likely to be equal to according to theorem 1. After that, if any is ∅, which means there is no equivalent attribute l ∈ L for the corresponding attribute , the user should be filtered out (lines 15 to 17). A candidate attributes list L is a combination of one element from each . For example, choosing l from H1, l from H2, …, l from H, L = {l, l, …, l} is such an candidate attribute list. Remarkably, In our system model, elements in an attribute list are sorted according to the index of their corresponding attribute categories in . Therefore a legal attribute list L should be ordered. This requirement can be formally described as follows: In line 18, the function Combine (as shown in Algorithm 2) figures out a set which consists of all possible candidate attribute lists.

Algorithm 1 FastFilter

Input:

1. Reminder vector R = [r1, r2, …, r]

2. User attribute list L = {l, l2, …, l}

3. Prime λ

Output:

1. The candidate attribute list set

()

1: if |R|>|L| then

2:  return ∅

3: else

4:

5:  for each do

6:   H = ∅

7:  end for

8:  for each r ∈ R do

9:   for each l ∈ L do

10:    if r = Hash(l) mod λ then

11:     H = H∪l

12:    end if

13:   end for

14:  end for

15:  if then

16:   return ∅

17:  else

18:    = Combine()

19:   return

20:  end if

21: end if

Algorithm 2 Combine

Input:

1.

Output:

1.

1: if then

2:

3:  for each do

4:

5:  end for

6:  return

7: else

8:  H = Pop()

9:   = Combine()

10:  if then

11:   return ∅

12:  else

13:

14:   for each do

15:    for each l ∈ H do

16:     if Index(l) < Index() then

17:

18:

19:     end if

20:    end for

21:   end for

22:   return

23:  end if

24: end if

Decryption and Confirmation

In order to determine if there exists a candidate attribute list L in that is equal to the query attribute list L (i.e., the user attribute list L matches the query attribute list L), for each L, we first use it to generate a candidate private key SK, then try to decrypt the ciphertext by it. The decryption will return a tuple which contains KU′ and N. If KU′ is equal to KU, the decryption result is correct, which means the profile match is successful. Then N is returned for subsequent steps.

Secure Communication Channel Establishment

If the match process is successful, the matched user can choose to respond to the request. First he/she generates a shared communication key KS. Then he/she encrypts KS and N using initiator’s public key KU, and send it back to the initiator. When the initiator gets the reply, he/she decrypts it by using his/her private key KR. By authenticating N, the initiator can confirm that this reply comes from the user whose attribute list matches the query attribute list, and establish a secure communication channel with the matched user by KS. This process can be seen in Fig 3.

Fig 3

The key exchange process.

Algorithm 3 CipherDecryption

Input:

1. Ciphertext CT

2. Attribute Public Key PK

3. Attribute Private Key SK′(generated by KeyGenA(MK, L))

4. Candidate Attribute Lists Set

5. Initiator’s Public Key KU

Output:

1. Temporary Interactive Number N

1: if then

2:  return NULL

3: end if

4: for each do

5:   SK = KeyGenU()

6:   (KU′, N) = Decrypt(PK, CT, SK)

7:   if KU′ = KU then

8:    return N

9:   else

10:    return NULL

11:   end if

12: end for

The Complete Privacy-Preserving Profile Matching Protocol

In this subsection, we describe the complete privacy-preserving profile matching protocol proposed in this paper. As we can see in protocol 1, the complete protocol consists of three phases. Remarkably, the communication between a user and the attribute authority only occurs in the setup phase. Once the communication is over, the user will no longer communicate with the sever unless special circumstances occur. In other words, the communication between a user and the attribute authority occurs only when the user generates or modifies his/her attributes list. Therefore, the profile matching operation among users is completely distributed.

Protocal 1 The Privacy-Preserving Profile Matching Protocol

Setup Phase

1. The attribute authority runs Setup(1) to generate PK, MK.

2. Every participant u generates his/her attribute list L based on attribute space .

3. Every participant u submits L to , and runs KeyGenA(MK, L) to generate , and send back PK, to u.

4. Every participant u generates a key pair (KU, KR) according to a certain public key encryption algorithm.

Profile Matching Phase

1. The initiator u generates query attribute list L to describe the user whom he wants to match.

2. u generates the reminder vector R (mod λ) for L.

3. u generates a random number N.

4. u runs Encrypt(PK, M, L) and generates the ciphertext CT. M = KU||N.

5. u sends out the tuple (R, KU, CT).

6. After receiving (R, KU,CT), the user u takes R, L, and prime number λ as the inputs of algorithm 1 (FastFilter) to figure out .

7. If , the profile matching process ends. Otherwise, u continues to run algorithm 3 (CipherDecryption).

Secure Communication Phase

1. If algorithm 3 (CipherDecryption) returns N, it means that L matches the query attribute list L. Then u generates a shared communication key KS, encrypt KS and N by KU, and then sends it back.

2. u decrypts the reply by his/her private key KR.

3. If N is correct, u and u make a further secure communication by KS using certain predefined symmetric cryptographic technique.

Security and Performance Analysis

Security Analysis

Let PS(L, u) be a decision function. If a user u can learn the content of the query attribute list L, PS(L, u) = 1; if not, PS(L, u) = 0. The goal of our scheme is: only for u whose attribute list can match L, PS(L, u) = 1.

The security of this CP-ABE construction adopted in our scheme provides the fundamental assurance of privacy-preserving. In order to achieve subset matching and improve the matching efficiency, we design the reminder vector and corresponding algorithm to achieve fast matching. However, such a efficiency improving design reduces the privacy security because the reminder vector reveals some information about the query attribute list. Theoretically, an adversary may take advantage of the reminder vector to implement dictionary profiling attack. In this subsection, we first present the security proof of the CP-ABE construction. Then we illustrate that our scheme can prevent the dictionary profiling attack by means of quantitative and qualitative analysis. Finally we show the verifiability and communication security of our scheme.

The CP-ABE Security

The security of the CP-ABE construction is the cornerstone of the entire system security proposed in this paper. In this subsection, we show that the CP-ABE construction adopted in this paper can provide ANON-IND-CPA security, which means the adversary cannot infer any information about the message M and the access policy W from the ciphertext. Formally, we give the following theorem.

Theorem 2. The CP-ABE scheme in our paper is (t, q, ϵ) secure assuming the asymmetric decisional (t+O(ϵ−2ln(ϵ−1)λ−1ln(λ−1)), ) BDH assumption holds, where .

proof. Suppose there exists a (t, q, ϵ)-adversary who tries to attack our CP-ABE construction. We construct a simulator to play the asymmetric DBDH game. Choose , , . Let g, be the generators of G, respectively. A fair binary coin β is fliped. If β = 1, then choose , otherwise, choose Z randomly from G. Give the tuple to the simulator to take asymmetric DBDH challenge. Then simulator runs by executing ANON-IND-CPA game, and finally gives out a guess β′ of β. By constructing such a simulator, the security problem of our CP-ABE is reduced to the asymmetric DBDH problem. Since the asymmetric DBDH problem is assumed to be NP hard, our CP-ABE construction provides ANON-IND-CPA security. For easy reading, we put the construction details of the simulator and the main proof steps in S1 Appendix.

Dictionary Profiling Attack Prevention

Now we consider the dictionary profiling attack, which seems to be the most threatening malicious attack against our protocol. In our scheme, although the adversary cannot infer any information about the query attribute list from the received ciphertext, he/she may take advantage of the reminder vector to implement dictionary profiling. A successful dictionary profiling attack depends on two steps. First, given a reminder vector, the adversary has to construct candidate attribute lists by enumerating the attribute combinations from attribute space . The reminder vectors of these candidate attribute lists should be equal to the given reminder vector. Second, the adversary has to communicate with the attribute authority to generate the private keys for each candidate attribute list, and then try to decrypt the ciphertext. In practice, such an attack is hard to work, and it can be effectively prevented in our scheme. In contrast to other existing schemes, the user profile in our scheme cannot be changed locally, which is the key mechanism for dictionary profiling prevention. Assume the number of attribute categories in is n, and each category has m attributes averagely. Given a reminder vector R with length q and prime λ, the number of candidate attribute lists generated by adverary will be . Obviously, this number will be larger if the attribute space is larger and λ is set properly. In order to prevent the adversary from getting private keys for each candidate attribute list from the attribute authority, we can restrict the private key generation frequency for the same user in the attribute authority by some simple methods. Therefore, our scheme can well address the dictionary profiling attack.

Verifiability

In our protocol, the initiator uses temporary interactive number N to verify the matching results. N is a random number and generated by the initiator. Only the matched user can get gain access to N by decrypting the query ciphertext. When the initiator receives the reply which comes from the so-called “matched user”, he/she decrypts it using his/her private key KR and verifies the N contained in the decryption result. If N is correct, the initiator can confirm that this reply comes from an authentic matched user. For an unmatched adversary, he/she cannot forge a reply which can pass the verification since he/she cannot get the correct N.

Communication Security

According to our protocol, the shared communication key KS generated by the matched user can be transmitted securely to the initiator, which depends on a specific public key encryption algorithm such as RSA. Then the matched pair can communicate with each other by using KS. Therefore, the adversary who is eavesdropping on the conversation cannot get any information.

Performance Analysis

The Time Complexity of CP-ABE

In the setup phase, a global public key and a master key are generated. In this process, for each attribute a in attribute space , the attribute authority needs to compute Ψ. So the total time complexity of Setup is ().

When generating the private key for a user with attribute list L, the attribute authority needs to run |L| addition operations in order to compute D1, so the time complexity of algorithm KeyGeneration is O(|L|).

In algorithm Encrypt, in order to compute C1, the user needs to run |W| multiplication operations. So the time complexity is O(|W|).

In algorithm Decrypt, only two bilinear operations are needed, so the time complexity is O(1).

The Time Complexity of FastFilter

The algorithm FastFilter contains two main steps. In the first step, is generated, which needs |R||L| loops. So the time complexity is O(|R||L|). In the second step, function Combine is called to generated . In the worst case, the number of loops in Combine is . Therefore, the worst time complexity of FastFilter is . Prime λ is an important parameter for FastFilter. Given a user with attribute list L and a remind vector R, let q = |R| and p = |L|, the probability of this user being ruled out before the second step (lines 15–16 in algorithm 1) is 1 − (1 − (1 − 1/λ)), and the expected value of H is p/λ. From these two formulas, we can easily see that the larger the λ, the higher the efficiency. Meanwhile, the larger λ will weaken the security due to the decreased difficulty of dictionary profiling. Therefore, choosing an appropriate value for λ is the key to achieving a balance between security and efficiency.

The Time Complexity of CipherDecryption

The final matching step is done by algorithm CipherDecryption. For each , it calls KeyGenU to generate a candidate private key, then calls Decrypt to decrypt the ciphertext. Since the time complexity of Decrypt is O(1), the time complexity of CipherDecryption is .

Simulation and Evaluation

We implement our protocol prototype on a laptop, which has Intel CORE i5 2.30 GHz Processor, 2GB RAM, Ubuntu 14.04 OS and Python 3.4.3. Thanks to CHARM [23], which is a python framework for rapidly prototyping advanced cryptosystems, we can easily implement the CP-ABE algorithm. In our experiment, we, firstly, test the performance of the CP-ABE algorithms. Secondly, we test the performance of FastFilter under different conditions. Finally, we test the performance of the complete profile matching protocol.

The Performance of CP-ABE

In order to evaluate the performance of our CP-ABE construction, we test the runtime of the core algorithms KeyGeneration, Encryt and Decrypt with different number of attributes (from 1 to 500). Fig 4 shows the test result. We can clearly see from Fig 4 that the key generation time and the encryption time increase with the number of attributes linearly, and the decryption time keeps constant. This result is in agreement with our time complexity analysis in section Security and Performance Analysis.

Fig 4

The performance of CP-ABE.

The Performence of FastFilter

It is hard to figure out the precise time complexity of algorithm FastFilter theoretically. According to our previous analysis, the efficiency of FastFilter is correlated with the parameter λ and the length of query attribute list. We choose the number of loops in function Combine (lines 14, 15) as the performance indicator and design an experiment to evaluate the practical efficiency.

In our experiment, we assume the length of the user attribute list is 10. We choose different values for λ and q. Here, q is the length of the query attribute list. For each value combination (λ, q), we randomly generate 2000 user attribute lists and 2000 correspongding query attribute lists, run algorithm FastFilter, and record the number of loops in Combine. Finally, we draw the violin plots to show the value distribution. Fig 5 shows the test results, from which we can see three facts clearly. First, the mean values under different (λ, q) condations are all smaller than 25. Most of the results are distributed around the mean value. This fact implies the actual time complexity of FastFilter is far less than . Second, larger λ can significantly reduce the number of loops (especially the max value), and thus improve the algorithm performance. Third, given λ, the larger the q, the more the number of loops. These two facts confirm our intuition. Since the time complexity of CipherDecrytion is , we also record the length of for each simulation in our experiment. The distribution can be seen in Fig 6.

Fig 5

The number of loops in funciton Combine.

Fig 6

The number of candidate keys.

Integrated Test

In order to evaluate the performance of the complete profile matching protocol, we test the time cost from a user beginning to run FastFilter until ultimately successful matching under different conditions. In our experiment, the length of user attribute list is assumed to be 10. Fig 7 shows the test result, from which we can clearly see the change of the runtime under different (λ, q). The test result is consistent with our anlaysis.

Fig 7

The integrated test result.

Related Works and Comparison

Related Works

Privacy-Preserving Profile Matching

In this subsection, we give a brief introduction of five related privacy-preserving profile matching schemes. Ming Li et al. in [9] proposed FindU (referred to as A hereafter), a set of privacy-preserving profile matching schemes for proximity-based MSN. In their schemes, each user own a set of attributes just like ours. An initiator searches for the best matched user by calculating the intersection of attributes between him/her and other users. For privacy preserving, FindU leverages secure multi-party computation (SMC) techniques to achieve PSI and PSCI.

Rui Zhang et al. in [13] proposed schemes (referred to as B hereafter) that can achieve fine-grained private matching for MSN. Their solutions feature fine-grained personal profiles in which each attribute is associated with a user-specific integer value indicating the corresponding user’s association with this attribute. The matching relationship between two users is determined by the similarity degree of their attribute vectors. Relating the computation of the similarity degree of two attribute vectors to secure dot-product computation (SDC) based on homomorphic encryption is their basic idea for privacy preserving.

The scheme (referred to as C hereafter) proposed by Vacha Dave et al. in [11] is also based on secure dot-product computation by using homomorphic encryption. In contrast to B, the user attribute vector in this scheme just consists of a number of specific attributes, which is coarser than the attribute vector in the scheme B. A distinctive feature of the scheme C is that it provides both privacy and verifiability, which means any participant cannot falsify the comparison result. To achieve this goal, each side of a matching pair has to compute the dot-product of their attribute vectors by using homomorphic encryption, which is computation expensive in practice.

Lan Zhang et al. in [24] proposed a more lightweight privacy-preserving profile matching scheme (referred to as D hereafter). In contrast to these schemes mentioned above, D does not use any SMC techniques. It leverages the fact that the intersection of the request profile and the matching profile is a nature common secret shared by the initiator and the matched user. Its main idea is to use the request profile (a set of attributes) as a key to encrypt a message. Only the matched user, who shares the secret, can decrypt the message efficiently.

The scheme (referred to as E hereafter) which is the most similar to ours was proposed by Hongjuan Li et al. in [25]. It is also based on CP-ABE. In contrast, the CP-ABE construction used in this scheme is not receiver anonymous and Bloom filter is used for access policy hiding and fast filtering.

Establishing Secure Channel

The establishment of a secure communication channel is always a hot topic in network security research. Especially in recent years, a lot of authentication and key exchange protocols have been proposed for various kinds of wireless networks to establish secure communication channels between their entities. For example, literature [26] presented a smart-card based user authentication scheme for Wireless Sensor Networks. Literature [27] presented an authenticated key exchange protocol for Wireless Body Area Network. Literature [28] presented an authentication and key exchange protocol for Vehicular Networks. Although we mainly focus on privacy preserving profile matching in this paper, using our scheme, the shared key can be exchanged between the matched pair securely and authentically. Based on this, we will try to design an attribute based authentication and key exchange protocol and apply it in the wireless networks mentioned above in our further research.

Comparison

In this subsection, we compare our scheme with the five profile matching schemes mentioned above in terms of security, efficiency and usability.

Security

For the schemes A, B, the main security problem is the lack of verifiability. In the scheme A, the matching computation between two users needs assistance from extra 2t − 2 users. Due to the lack of verifiability, any assistant user can falsify the computation result so as to cause a wrong matching result. In the scheme B, it is also easy for an adversary to cheat the initiator with a false dot-product result. Although the scheme C provides verifiability, it needs each side of a matching pair to compute the dot-product of their attribute vectors by using homomorphic encryption, which means larger computation overhead. For the scheme D, due to the lack of the authentication of user’s attributes, any user can arbitrarily change their attribute lists locally and quickly. Therefore, the scheme D can not well defend the dictionary attack and collusion attack. In the scheme E, Bloom filter is used for access policy hiding and fast filtering. However, different from our reminder vector which only gives out a fuzzy hint about the preference profile, the adversary can determine that whether or not an attribute is in the preference-profile accurately duo to the low false-positive probability of Bloom filter. Therefore, the scheme E is also unable to defend the dictionary attack. Compared with these five schemes, our scheme provides implicit verifiability which do not need extra computation cost. Due to the security features of anonymous CP-ABE and reminder vector, our scheme can well defend the dictionary attack and collusion attack. In addition, our scheme can establish a secure communication channel between the pair of matched users in a natural way, which is ignored by schemes A, B and C.

Efficiency

For the schemes A, B and C, the matching result is determined by the initiator ultimately. In other words, the initiator has to further compute and make a decision according to the computation results sent back from other participants. When the number of participants becomes lager, the initiator may face a lager computation burden which will decrease the computation efficiency and increase the power consumption. In addition, whether or not matching the initiator’s profile, all participants have to take on nearly the same computation overhead and interact with the initiator at least two times. It is a reasonable inference that the overall network performance will be greatly affected when the number of initiators is larger. In contrast, in our scheme, the matching result can be determined by the users who receive the query package rather than the initiator. For a given initiator, most of the participants will be ruled out in the fast filtering phase quickly. Only a few candidates need to further generate the private keys and try to decrypt the ciphertext. That is why our scheme is more efficient.

Usability

In the first four schemes (A, B, C and D), users have to define a security parameter called threshold which directly affects the matching result. In our opinion, it is difficult for a normal user to intuitively understand the meaning of the threshold and assign value to it properly, which decreases the usability to a certain degree. In contrast, the only adjustable parameter in our scheme is λ, which is used to balance the security and efficiency. The value of λ has no affection on the matching result. Therefore, it can be preset as an default value. Normal users need not to care about it.

Table 3 summarizes the result of the comparison. Here, “Interaction Times” represents the communication times required for a successful profile matching between a pair of users, “Decider” represents the one who determines the profile matching result ultimately, and “Filterability” represents the scheme can provide a mechanism to fast exclude the unmatched users, which is significant for enhancing the overall performance.

Table 3

Comparison with related schemes.

Scheme	Key Idea	Interaction Times	Verifiability	Defending Dictionary Attack	Decider	Filterability
A [9]	PSI, PSCI	10(2t − 2)	No	No	Initiator	No
B [13]	SDC	2	No	No	Initiator	No
C [11]	SDC	5	Yes	No	Initiator	Yes
D [24]	SDC	2	Yes	No	Initiator	Yes
E [25]	CP-ABE	2	Yes	No	Initiator	Yes
Ours	CP-ABE	1	Yes	Yes	Matching User	Yes

Conclusion

In this paper, we design a novel CP-ABE based privacy-preserving profile matching scheme for MSN. As far as we know, it is the first time to use CP-ABE technique to address the privacy-preserving profile matching problem. Our scheme is based on a special CP-ABE construction which provides receiver anonymity. The length of ciphertext and the number of pairing computations are all constant. Meanwhile, we design a fast filter algorithm to make the original CP-ABE construction applicable in our application context and improve the matching efficiency. The theoretical analysis and experimental results show the security and the better efficiency of our scheme. Finally, we compare our scheme with other four related state-of-the-art solutions, which shows the distinctive features and advantages of our scheme in terms of security, efficiency and usability. Our scheme is also applicable to many scenarios beyond the motivation problem in this paper, for example, the patient matching in online healthcare social networks.

(PDF)

Click here for additional data file.