An Efficient Blockchain-Based Bidirectional Friends Matching Scheme in Social Networks

In social networks, the personal attributes or hobbies of the users are exposed to the server to establish the relationships. Service providers may store these information for commercial purpose or statistical analysis. Furthermore, the server may expose to external attacks, which may disclose users’ privacy information. In this paper, we present a hierarchical blockchain-based attribute matching scheme, which realizes privacy-preserving attribute matching under multiple semi-trusted servers. The scheme employs CP-ABE and bloom filter to satisfy the requirements of the users to make friend discovery, and reduces the computation cost of users by outsourcing decryption of CP-ABE. Besides, the hierarchical blockchain only implements the consensus and storage of matching results on the blockchain, while the complex calculations and a large amount of data storage are off-chain, which reduces the consumption of the blockchain and improves the operation efficiency. Finally, we prove the scheme can resist single point failure, collusion attack, internal attack and external attack, the experimental results demonstrate the proposed scheme is feasibility and efficiency.


I. INTRODUCTION
Social social networking provides an online platform to people to build social relationships with others, who have similar personal attributes such as age, home address, education background, etc. However, there is a risk of privacy leakage. Social network platforms may use user attributes for statistical, advertising or profit-making purposes [1], [2]. Such behavior will compromise users' privacy, which affect users' real life [3], [4]. For example, more than 25 gigabytes user information of an extramarital affair platform named Ashley Madison was leaked, including real name, home address and other information, and many users feared being publicly shamed [5], [6].
The associate editor coordinating the review of this manuscript and approving it for publication was Yunchuan Sun. The basic idea of friend discovery in social networks is to compare the similarity of attributes between two users without leaking users' information. There are three categories to address the problem. The first category uses a set of attributes to summarize user's information, and employs Private Set Intersection(PSI) or Private Set Intersection Cardinality(PSI-CA) to execute attribute matching [5], [7]- [9]. The second category employs vectors to represent user's information, and the vector distance is calculated by dot product calculation to represent social distance [10]- [12]. The third category takes advantage of Ciphertext Policy Attribute-Based Encryption(CP-ABE) and access control to achieve friend discovery [13]- [18]. Nevertheless, there are some issues in existing schemes: • Secure Multiparty Computing(SMC), homomorphic encryption or vector-based dot product calculation are employed to execute the friend discovery. But these methods either consume massive computing resources or are vulnerable to statistical analysis attacks.
• The schemes just considers the requirements of the initiator rather than the needs of both, which is not in line with the actual situation of making friends.
• The existing schemes do not consider that social network platforms collude with some users to steal the privacy of others.
Additionally, most of the above solutions are based on point-to-point implementation. The server can reduce the computation cost of users during friend discovery, but the server is semi-trusted [19]. Blockchain has attracted much attention from scholars because of its characteristics of decentralized, immutable and traceable. In recent years, it has been widely used in Internet of Thing, social network, crowdsourcing, vehicle network and other fields [20]- [24].
To solve the problems of friend matching in social network, we propose an efficient and privacy-preserving friend matching based on blockchain in social networks. The contributions of the paper are summarized as follows: • We proposed an attribute matching mechanism based on the hierarchical blockchain and outsourcing CP-ABE for friend discovery in social networks, which can achieve the attribute matching in semi-honest social network platforms and reduce computing consumption of users.
• The scheme satisfies the needs of the users by using CP-ABE and bloom filter, which is more appropriate to the actual situation of making friends.
• A novel blockchain architecture is proposed to achieve the decentralization and auditability of friend matching in social network, which reduce storage consumption of the blockchain.
The rest of this paper is organized as follows. Section II discusses related work. Section III provides detailed system model, new blockchain architecture and threat model. The preliminaries are introduced in Section IV. And the proposed scheme is elaborated in Section V. Section VI and Section VII provides security analysis and performance evaluation for our scheme, respectively. In Section VIII, we summarize our research and future work.

II. RELATED WORKS
The most existing schemes consider users' profiles as sets of attribute and measure similarity by calculating the intersection of attributes. The Private Set Intersection(PSI) technique for achieving attribute matching was first proposed by Li et al. [7], which is based on Secure Multi-party Computing(SMC). Yi et al. [5] proposed a profiles matching scheme based on homomorphic encryption in multiple social networks, which provides profile privacy-preserving. The basic idea is to judge whether the dissimilarity of two users is less than the threshold given by the user.
The other methods regards user's attributes as a vector, and the server calculates the dot product of two attribute vectors to obtain their similarity. Gao et al. [11] presented a multiple keys profile-matching protocol based on additive homomorphism to calculate the dot product of two vectors. Then, some dot product schemes were proposed which abandon homomorphic encryption and have lower computing costs. Luo et al. [10] set weight for each attribute, i.e., the attribute set is represented as a matrix, and then used a lightweight confusion matrix transformation algorithm to protect user information. And Li et al. [25] mixed the each attribute vector with random noise to realize attribute matching.
CP-ABE has been widely used in social networks [26]- [28]. Bethencourt et al. [29] first proposed CP-ABE in 2007. Waters [30] proposed a more efficient implementation of CP-ABE. Luo et al. [31] designed a friend discovery architecture based on CP-ABE and multiple attributed authority, which uses Shamir's scheme to store the master key distributedly. Li et al. [32] proposed a point-to-point pre-matching scheme, using Bloom filter to reduce the computational load of users performing decryption of CP-ABE, and they elaborated how to establish a verifiable secure communication channel between matched users. Based on this, Cui et al. [16] designed a receiver anonymous attribute matching scheme using CP-ABE and bloom filter. Qi et al. [15] combined searchable encryption with CP-ABE and proposed a friend discovery protocol with hidden attributes and fine-grained access control.
Considering the unreliability of the centralized server, the researchers applied the blockchain technology to social networks architecture. Jiang and Zhang [33] and Gu et al. [34] proposed social network architectures that use the blockchain and smart contracts instead of centralized servers to provide social networking services. They mainly take advantage of the immutability of traditional blockchain and the fairness of smart contracts.

III. SYSTEM OVERVIEW AND THREAT MODEL
In this section, we formalize the system model, the hierarchical blockchain architecture and the threat model.

A. SYSTEM MODEL
As depicted in Figure 1, the proposed system model consists of five entities, Trusted Authority(TA), Social Networking Platform(SNP), Users, Consortium Blockchain(BC), Proxy Cloud Computing Server(PCCS).
• TA: A trusted third party is responsible for key generation.
• SNP: It's a social networking platform with storage and computing capabilities such as Twitter and Facebook. It is the consensus node in the blockchain, which is called the miner in traditional blockchain networks. Under the chain, it provides social networking services and information storage services.
• Users: The users would like to find friends in social networks, which has the similarly attributes. The initiator Alice and the responder Bob are two users, who want to establish the social relationship each other.
• BC: SNPs constitute the blockchain consensus nodes. Users have blockchain accounts, which do not participate in the consensus and storage. Smart contract on BC determines whether two users can become friends.
• PCCS: PCCS is selected from SNPs periodically via smart contract. It is responsible for partial decryption of CP-ABE to reduce users' computation consumption. In the system, each user has two attribute sets S and R, S is representing his/her private attributes, and R is representing his/her requirements for making friends. To solve that people have same attributes which describe them differently, for example, Alice and Bob both like to sing, but Alice inputs ''sing'' and Bob inputs ''I like to sing''. Therefore, we provide attribute space A. The elements in S and R are the hash values of the elements selected from A, i.e., S = {s 1 , . . . , s n }, R = {r 1 , . . . , r m }, ∀s i , r j ∈ A{h(att 1 ), . . . , h(att z )} In our scheme, friend matching in the social network should meet the following two conditions.
1) The percentage of attribute similarity between two users is greater or equal to a certain threshold given by the user. 2) Both parties' attributes meet each other's requirements. In addition, SNPs do not anything about the users' attribute sets during the process of friend matching.

B. HIERARCHICAL BLOCKCHAIN ARCHITECTURE
One of our major contributions is proposed a hierarchical blockchain architecture. The performance of blockchain can be obviously improved by the hierarchical design [35]. Figure 2 shows the consortium blockchain architecture. The architecture divides the consortium blockchain into three parts: platform layer, user layer and off-chain.
The platform layer is composed of various SNPs and performs friend matching by smart contracts. All SNPs are consensus on the matching results and these records are stored in the blockchain. And smart contract periodically select a PCCS from SNPs to perform outsourcing encryption of CP-ABE.
A large number of users make up the user layer, which allows users to communicate casually with others, and they can make friends who meet specific attributes via the platform layer.
Off-chain stores the data that means each platform has private databases to store users' information. It indicates the blockchain stores matching records instead of all the users' information to reduce storage consumption of each consensus node. Additionally, to improve the efficiency of smart contracts, complex cryptographic calculations are also under off-chain. Each operation on the blockchain is lightweight and low storage consumption which can effectively solve the issues of low efficiency of smart contract execution and large storage burden in the blockchain.

C. THREAT MODEL
In our system, we consider the following threat models: • Single Point Failure: Some SNPs' servers may be failure and stop providing services, or even be hijacked by attackers, which may cause system paralysis or users' information leakage.
• External Attack: The communication of each entity in the system may be subject to external attacks, such as replay attack, tampering attack, etc.
• Internal Attack: Assume that entity is honest but curious, but they want to infer the users' attribute information from the obtained data. Besides, the SNP may give the wrong execution result and cause the match to fail.
• Collusion Attack: SNPs may collude with some users to obtain other users' personal information. Based on the above threat model, our system design goals are listed as follows: • Data Confidentiality: Data privacy-preservation is the main purpose of the scheme. The users' attribute information should not be obtained by anyone under the above attacks.
• Data Integrity: The data integrity should be provided in the communication between entities.
• Low Storage Cost for Blockchain: The data in the blockchain is constantly added and cannot be deleted, and the data occupies the same amount of storage space of all consensus nodes. That is, if there are k consensus nodes, the storage consumption is k times of the traditional scheme, so the amount of data on the blockchain should be as small as possible.
• Low Computation Cost for Blockchain: Since the smart contract cannot be modified once it is deployed, and it is executed by all nodes, the algorithm in the smart contract should be simple, and the computation cost should be as low as possible.
• Low Computation Cost for Users: Due to the low computing power of users, the system should have the low computation cost on the users' side.

IV. PRELIMINARIES
In this section, we introduce the related cryptographic technique and background knowledge.

A. BILINEAR MAPS
We define G 1 as a multiplicative cyclic groups of prime order p, and the generator of G 1 is g. Let a bilinear map, e : And it has the following properties: • Bilinear: for all x, y ∈ G 1 and a, b ∈ Z p , we have e(x a , y b ) = e(x, y) ab .
• Computability: for all x, y ∈ G 1 , there exists an algorithm to compute e(x, y).

B. LINEAR SECRET SHARING SCHEMES(LSSS)
A secret sharing scheme in multiple entities P is called linear if: • The shares for each entity form a vector based on Z p . • The share-generating matrix M for scheme has rows and n columns. And there is a function ρ that associates the ith row of M to a party ρ(i) and i is from 1 to . If we want share a secret value s ∈ Z p , we choose random numbers r 2 , .., r n ∈ Z p to generate a vector v = (s, r 2 , . . . , r n ). Then we can get the vector −→ Mv with shares of the secret value s according to scheme .
The secret s can be recovered as follows: Suppose that is an LSSS according to access structure A. Define the authorized set S, and let I ⊂ {1, 2, . . . , } be defined as Then s recovered as s = i∈I ω i λ i . And s cannot be obtained for the unauthorized set S / ∈ A.

C. CIPHERTEXT POLICY ATTRIBUTE-BASED ENCRYPTION
Ciphertext Policy Attribute-Based Encryption (CP-ABE) is typical asymmetric encryption method which can provide fine-grained access control [29]. In CP-ABE, there is one trusted authority who is responsible for generation of a public key PK and a master key MK . The user can encrypt data based on PK and the designed access structure A. If the attribute sets of some users satisfy the above A, they can decrypt it with their private keys which are generated by trusted authority based on their attribute sets and MK .

D. BLOCKCHAIN
As the critical technology of Bitcoin, blockchain has the characteristics of distributed, immutable and traceable [36], [37]. The blockchain composed of many nodes, maintaining the same database. There are mainly four concepts in the blockchain as shown below: • Transaction: It is an operation that changes the state of the blockchain.
• Block: A block records a certain amount of transactions over a period of time. It represents the state change of the blockchain during this time.
• Consensus: All nodes verify whether a transaction is valid and then reach an agreement.
• Chain: Each block stores both the hash value of the previous block and the hash value of the current block. By this means, each block has a close association with the previous block and the latter block and form a chain. VOLUME 8, 2020

E. SMART CONTRACT
Smart contract is an immutable program running on the blockchain, which is called ''chaincode'' in Fabric, for consistency we use ''smart contract'' to represent chaincode in the paper. Once the smart contract is invoked, it is executed by a consensus node, and the execution result will be checked by all consensus nodes. After being successful deployed, the smart contract is not controlled by anyone, and is viewed by everyone via a unique address. Therefore, smart contract can be trusted by users, thereby supersede the traditional central server.

V. THE PROPOSED SCHEME
In this section, we present the proposed scheme. Table 1 illustrate the frequently used notations in the scheme.

A. SYSTEM INITIALIZATION
In the system initiation phase, TA generates various keys for the system, and transmits them to the corresponding entities via secure channel. The asymmetrical key (PU bc , PR bc ) are generated for blockchain consensus nodes to communicate with users. Then TA generates the master key MK and the public key PK . Transformation key TK and secret key SK are generated for each user based on their attribute sets S. The outsourcing decryption of CP-ABE is constructed based on scheme [38]. In addition, the smart contract for periodically selecting PCCS from SNPs is deployed on the blockchain.

1) CP-ABE INITIALIZATION
TA selects a security parameter λ and generates a universe description U = {0, 1} * . Then it chooses a bilinear group G 1 of prime order p, a generator g. TA then selects two random numbers α, β ∈ Z p . Besides, it needs to choose a hash function F that maps U to G 1 . After that, the public key is published: TA secretly stores the master key MK = (PK , g α ) and exposes PK to SNPs and users, respectively.

2) USER REGISTRATION
The system sets the attribute space A that contains a large amount of attribute information such as gender, income, age, sports preference, education background, etc. When a new user joins the system, he/she first selects his/her attribute sets S and R from the attribute space A, then uploads S to TA to get transformation key TK and secret key SK .
TA picks a random number t ∈ Z p to create a temp key as: Then it chooses another random number z ∈ Z p and sets t = t /z. Then it generates the transformation key TK as: The TK is sent to the PCCS. The private key SK = {z, TK } is sent to the user. Noted that when the user's personal attribute set changes, TK and SK should be regenerated.

3) SMART CONTRACT DEPLOYMENT
In the system initialization phase, the rules for electing PCCS need to be written into the smart contract. The PCCS is periodically elected from SNPs. The election algorithm is depicted in Figure 3. The smart contract containing the election algorithm is deployed on the blockchain, and all SNPs comply with the smart contract.

B. USERS COMMUNICATION
As demonstrated in Figure 4, when the initiator Alice wants to make friend discovery, she needs to execute three steps: matching preparation, smart contract initialization and data upload. The blockchain first checks the data. Then PCCS partially decrypts the data, and send it to the users who meet the requirement. If the receiver Bob also wants to execute friend discovery, he performs two steps: simple decryption and smart contract invocation.

1) MATCHING PREPARATION
In the preparation phase of matching, Alice first uses symmetric key K a to encrypt each element of her private attribute set S a to get S a .
S a = {s a1 , . . . , s an | ∀s ai ∈ S a , s ai = E K a (s ai )} Then she encrypts her social network address P a , P a = E K a (P a ). Additionally, Alice constructs the Bloomer filter. She first initializes an array B of m bits with 0, and selects k hash functions {h 1 , h 2 , . . . , h k }. Alice uses these k hash functions to hash each value of S a . The hash value of s ai is its position in the array B, and the value of this bit in array B is set to 1. Figure 5 shows the procedure of Bloom filter when k = 3.

2) SMART CONTRACT INITIALIZATION
Alice initiates a transaction that creates a smart contract for friend matching. The smart contract is created here but not performed, so we elaborate its details in Section V-C. Note that the smart contract indicates that Alice is looking for friends. Alice needs to upload the following data to the platform layer including the instruction I , the ciphertext of the attribute set S a , the Bloom filter B, the ciphertext of the contact address P a , and the number of friends max_num.
Hence, the data transmitted from Alice to the platform layer to create smart contract is as follows: After the smart contract is successfully deployed, Alice will get a unique address P sc . other users invoke the smart contract via P sc .

3) DATA UPLOAD
The data is uploaded to the PCCS including three components: P sc , K a and M. P sc is the access address of smart contract, K a is the symmetric secret key of AES, M is Alice's self-introduction or any other information that allows Bob to make a preliminary decision whether he is willing to make friends with Alice. So the data needs to be encrypted by CP-ABE as M = M K a P sc .
Then Alice converts the R a into LSSS access structure (M , ρ). M is an × n matrix, and ρ is a function, in which the rows of M is associated with attributes. Alice first generates a random vector v = (s, y 2 , . . . , y n ) ∈ Z n p , which is used to share the encryption s. For i = 1 to , λ i = v · M i , and the ith row of M is the vector Mi. Besides, Alice generates another a random sequences {r 1 , . . . r ∈ Z p }. Then the ciphertext CT ab is calculated as C = M e(g, g) αs , C = g s , along with a description of (M , ρ). Then Alice sends CT apc to the platform layer instead of directly to PCCS.

4) DATA VERIFICATION
After receiving message from Alice, SNPs in the platform layer decrypts CT apc with PR bc to get C apc and check data integrity and availability with T and hash values. Then, the blockchain checks whether the data is legal, i.e. whether there are symmetric secret key or plaintext of access policies in CT apc .
After verification, the current PCCS performs partial decryption of CP-ABE offline.

5) CP-ABE PARTIAL DECRYPTION
The PCCS uses users' transformation key TK to decrypt CT ab in C apc to get the partially decrypted data CT ab . If a user does not satisfy the requirements of Alice, that is, his/her S and TK does not meet the access structure(M , ρ), the decryption fails. Suppose that S meets the access structure and let I ⊂ {1, 2, 3, . . . , } be defined as I = {i : ρ(i) ∈ S}. Then, let {ω i ∈ Z p } i∈I be a set of constants such that if {λ i } are valid shares of any secret s according to M , then s can be computed as i∈I ω i λ i = s. Therefore, the PCCS can computes: = e(g, g) sα/z e(g, g) βst /( i∈I e(g, g) tβλ i ω i ) = e(g, g) sα/z Then the PCCS obtains partially decrypted data CT ab = (C, e(g, g) sα/z ). It sends CT pcb to Bob.
The PCCS will repeat the above process until Alice makes max_num new friends.

6) SIMPLE DECRYPTION
Bob checks T and the hash value to confirm whether the data has been replayed or modified. After that, he computes simple decryption: C/(e(g, g) sα/z ) z = M · e(g, g) αs /e(g, g) sα = M (10)

7) SMART CONTRACT INVOCATION
If Bob wants to make new friends after he obtains the message M sent by Alice, he should make sure whether Alice satisfies his requirements for making friends. Firstly, Bob encrypts his social network contact address P b as P b = E K a (P b ). Then he uses K a to encrypt the attribute sets S b and R b to get S b and R b , respectively.
Furthermore, Bob sets the minimum percentage of attribute similarity between them to min_percent. Bob sends data to the platform layer as follows: Bob initiates a transaction to send the CT bsc to the smart contract via the address P sc .

C. ATTRIBUTE MATCHING
After the transaction initiated by Bob is received, the consensus nodes first confirm the validity and the data integrity by T and hash value. After that, smart contract is executed by SNP, which mainly verifies whether Alice satisfies Bob's requirements via a bloom filter. If all elements of R b are in Bloom Filter B, it proves that Alice meets Bob's needs for making friends. Besides, the smart contract also needs to calculate whether the percentage of attribute similarity between Alice and Bob is greater or equals to the threshold required by Bob.
Algorithm 1 illustrates the attribute matching algorithm, which verifies whether Alice and Bob can be friends and matches up to max_num friends for Alice. If the match is successful, a communication channel will be established between Alice and Bob. In addition, because the smart contract will be invoked by multiple responders, bloom filter is more efficient than traversal S a and R b . The matching records will be stored in the blockchain. Note that we store the hash value of the input parameters instead of the original data, which can achieve matching transparency while protecting user privacy. If original parameters are stored Send P a and P b to Bob and Alice respectively 27: Hash values of all input parameters are stored in the blockchain 28: return True 29: end if directly, Alice or Bob can decrypt them with the symmetric secret key K a to obtain other users' personal information. Moreover, matching records in the blockchain will not be deleted or modified by anyone, which can be managed by users.

VI. SECURITY ANALYSIS
In this section, we present the security of the proposed scheme under the threat model in Section III-C.

A. SINGLE POINT FAILURE
During the entire matching process, if an SNP loses response or is hijacked by malicious attackers, the system will not be affected and user attribute information will not be disclosed.
Challenge: SNP gets data CT abc , CT apc and CT bsc from users. We Assume that an SNP server is broken down or hijacked by attackers. If the entire system crash or the attackers can get the user attribute information from CT abc , CT apc and CT bsc , the attackers will have succeeded.
Proof : • The system will not crash. Owning to the consensus mechanism, the blockchain will not be effected by one single SNP failure. For example, Practical Byzantine Fault Tolerance(PBFT) can hand up to 1/3 malicious consensus nodes [39]. Besides, if the PCCS crashes, as shown in Section V-A3, the smart contract will reelect a new PCCS.
• User privacy will not be disclosed. Assuming that the attacker can obtain blockchain node's public key PU bc and private key PR bc , it is also impossible to obtain any user information. Because as shown in Section VI-C, even the SNP cannot obtain user information.

B. EXTERNAL ATTACK
External attackers are entities that eavesdrop or tamper with data during the communication. Our scheme can protect user attribute information from various external attacks. Challenge: The communication data in the system includes CT abc , CT apc , CT pcb and CT bsc . If external attackers can obtain users' information or change the matching result by replaying or tampering with these data, the attackers will have succeeded.
Proof : The data flow of the proposed scheme is depicted in Figure 4. The all data has been encrypted via the public key of the corresponding entity, so external attackers without corresponding private key cannot decrypt the transmitted data. Except that CT pcb is encrypted by PR bc , external attackers can use PU bc to obtain C and CT ab . However, attackers are unable to tamper with CT ab and cannot get the users' information.
• Attackers is unable to tamper with CT ab . Because the CT pcb = E PR bc (C pcb H (C pcb )), which contains the hash value of the C pcb . It means Bob can calculate the hash value of C pcb and compare it with H (C pcb ). If they are not equal, it indicates the data has been tampered. Bob will destroy the data and report it to the platform layer.
• Attackers cannot get the user information. CT ab = (C, e(g, g) sα/z ), C = M e(g, g) αs . And z is Bob's private key, so the attackers cannot decrypt C to get M or any other information.

C. INTERNAL ATTACK
During the matching process, Alice, Bob, PCSS, SNP cannot know attribute information of the users. VOLUME 8, 2020 Challenge: If internal attackers are able to obtain the user attribute information from the transmitted data, the attackers will have succeeded.
Proof : Firstly, during the matching process, Alice only receives the matching result, and Bob receives CT pcb = Enc(M K a P sc ) and the matching result. Therefore, even if both parties decrypt the received data to get {M, K a , P sc }, they can not obtain any attribute information of the other users. Secondly, the PCCS can only know partially decrypted data, because z is Bob's private key. Additionally, SNPs on the blockchain cannot learn users information, either. Because all attribute sets are encrypted by K a , which is only known to Alice and Bob. Moreover, SNP can not learn anything from bloom filter B, because the attribute space A is large enough, and the SNP does not know the size of R a .

D. COLLUSION ATTACK
The proposed protocol can resist collusion attacks from multiple entities, and we mainly analyze the collusion between SNPs and users.
Challenge 1: SNPs on the blockchain get S and R from Alice and bob, which is encrypted by K a . We assume that a SNP and Alice collude to decrypt S b and R b with K a (the same as Bob).That is, Alice adds K a to the uploaded data. If they could obtain Bob's attribute set S b , R b , the collusion attack is successful.
Proof : Transactions in the blockchain are packaged into blocks by random consensus nodes. It means other SNPs may receive the symmetric key K a from Alice, in which case Alice will be punished and the system will no longer provide friend matching for Alice. In addition, even in some consensus algorithms, the designated consensus node receives transactions. The transaction will be confirmed by all the consensus nodes and it will be detected if the transaction contains K a .
Challenge 2: The PCCS gets CT apc from Alice. We Assume that the current PCCS colludes with Alice. And Alice sends the plaintext of access control structure or the symmetric secret key to the PCCS. If they obtain Bob's attribute information, the collusion attack is successful.
Proof : As described in Section V-B4, before the PCCS gets the CT apc , all SNPs have recorded the CT apc and confirm whether the CT apc is legal. If it contains K a or the plaintext of the access control structure, Alice's operation is rejected and the match is terminated.

VII. PERFORMANCE EVALUATION
In this section, we first introduce the simulation experiment environment, then we analyze the performance of the scheme based on Hyperledger Fabric. Finally, the function of our scheme is compared with the existing schemes.

A. SIMULATION EXPERIMENT PREPARATION
The simulation experiment is implemented in C/C++ on the Ubuntu 16.06 virtual machine under Windows 10 with Inter Inter(R) Core(TM) i5-7500 CPU @ 3.40GHz. Our experiment focused on the implementation of AES, out-souring decryption of CP-ABE and consortium blockchain. We ignore the underlying communication consumption between entities.
Firstly, the traditional AES with 128-bit key was implemented in C and the bloom filter was constructed in C++ based on Open Bloom Filter library. Afterwards, the outsouring decryption of CP-ABE was conducted based on Stanford Pairing-Based Crypto (PBC) library. It should be noted that the main computational consumption in CP-ABE is caused by bilinear operation, so we ignore the arithmetic operation on Z p . In addition, we deployed a consortium blockchain on Hyperledger Fabric which is constructed based on Go and Docker. We set all SNPs as endorsing peers. And the smart contract was implemented in Go.
We choose Fabric instead of Ethereum, the reasons are listed.
• Ethereum is a public blockchain, which is almost impossible for SNPs to trust it and use it.
• The transaction in Ethereum requires an additional fee called ''Gas'', which users are unwilling to bear.
• Ethereum's consensus mechanism leads to low transaction execution efficiency, which does not apply to friend matching in social networks.
We focus on the relationship between the performance of the scheme and the number of attributes, so we assume that Alice and Bob have private attributes and preference attributes, respectively. And = {5, 10, . . . , 95, 100}. The experimental results are depicted in Figure 6, all the data were the average of 20 experiments. Figure 6(a) shows the time consumed by AES encryption for different numbers of attributes. Each attribute in R and P is encrypted separately. It can be seen from the figure that the time consumption has not changed significantly with the increase of the number of attributes. Besides, we set the tolerable false positive probability of bloom filter as 0.0001. We can find that the bloom filter has extremely high efficiency, the time consumption is increasing with the number of attributes, but is not more than 0.2ms. Figure 6(b) presents the performance of outsouring decryption of CP-ABE. We use E G , E T , P to denote the average time to complete an exponentiation in G 1 , exponentiation in G T and a paring respectively. The average time they consume is 1.3953ms, 0.9876ms, and 0.1839ms. From the Section V, we know the encryption time consumption of CP-ABE is

B. PERFORMANCE ANALYSIS
And the partial decryption time consumption is {(2+ )P+2 E G }. Most importantly, the local decryption time is E T , which does not change with the number of attributes increasing. Figure 6(c) depicts the relationship between the running time of the designed blockchain and the number of attributes, including the time that it takes to initiate a transaction to generate a smart contract, and the time that it takes to execute attribute matching. We record the full running time of  the transaction from initiation to store in the blockchain. Compared with the time consumed by the blockchain, the time consumption caused by the changes in the number of attributes can be negligible.
The total time consumption of each entity is shown in Figure 6(d). Alice performs encryption of CP-ABE, encryption of AES and Bloom filter generation. For Bob, he needs to complete local decryption of CP-ABE and encryption of AES. For the blockchain, it performs smart contract initialization and attribute matching. For PCCS, it performs outsourcing decryption of CP-ABE. From the figure, the blockchain operation and outsourcing decryption of CP-ABE take the most time. It demonstrates the necessity of transferring complex calculations from the blockchain to the off-chain, which can significantly reduce the computation cost on the blockchain. What's more, an initiator will have multiple responders, so the reduction of time spent by the responder can effectively decrease the consumption of the entire matching process. The experimental result in Figure 6(d) demonstrates that Bob's time consumption is negligible, which proves the effectiveness of our scheme.
In summary, experimental results show that the scheme is effective and feasible.

C. FUNCTIONAL COMPARISON OF SIMILAR SCHEMES
We compare the proposed scheme to some similar advanced schemes introduced in Section II, and the comparison results are demonstrated in Table 2. All the schemes can achieve privacy preservation, so it is not displayed in the table. To achieve privacy preservation, there are five key factors are considered: Fine-Grained Matching, Low User Consumption, Bidirectional Matching, Collusion Resistance and Blockchain-Based. The Y in the table indicates that this feature is available in this scheme and the N represents that it is not. And ⊥ means the scheme is a point-topoint attribute matching scheme, so collusion attack is not considered.
It can be concluded that we proposed a novel and complete friend matching protocol based on the new blockchain architecture with the above five characteristics.

VIII. CONCLUSION
In this paper, we present a privacy-preserving attribute matching scheme under multiple semi-trusted servers. In our scheme, we utilize CP-ABE and bloom filter to conduct bidirectional attribute matching and relieve the computation cost of users by outsourcing decryption. In addition, we design a novel hierarchical blockchain architecture, which massively reduces the storage consumption of the blockchain and improves operating efficiency. Security analysis and experiment results demonstrate that our scheme can resist single point failure attack, collusion attack, internal attack and external attack, and also provide effectively friend matching for users.
In the future, we consider using blockchain instead of the trusted third party to initialize CP-ABE, which is a challenge issue. In addition, we plan to analyze the security and efficiency of blockchain consensus and friend matching in practical application. ARWA ALRAWAIS (Member, IEEE) received the M.S. degree in computer science and the Ph.D. degree from the Department of Computer Science, The George Washington University, Washington, DC, USA, in 2011 and 2017, respectively. She holds a patent in system and method for remote authentication with dynamic usernames. Her current research interests include network security, wireless and mobile security, and algorithm design and analysis. She serves as a Professional Reviewer for several conferences and journals of the IEEE and ACM. VOLUME 8, 2020