Abstract
The increase of mobile device use for social interaction drives the proliferation of online social applications. However, it prompts a series of security and existence problems. Some common problems are the authenticity of social contacts, the privacy of online communication, and the lack of physical interaction. This work presents mobile private matchmaking protocols that allow users to privately and immediately search the targets which match their planning purposes via mobile devices and wireless network. Based on social networks, the relationships of targets can be unlimited or limited to friends or friends of friends. It considers the privacy of users and the authenticity of friendships. The privacy means that no private information, except chosen targets, is leaked and the authenticity that signifies no forgery relationships can be successfully claimed. It applies to many applications such as searching for a person to talk to, to dine with, to play games with, or to see a movie with. The proposed scheme is demonstrated to be secure, effective, and efficient. The implementation of the proposed algorithms on Android system mobile devices allows users to securely find their target via mobile phones.
1. Introduction
Recently, online social networks (OSN) have received a great deal of attention. They provide online communities of users for information sharing. They also change the way people communicate and interact. Facebook, LinkedIn, Myspace, Flicker, Plurk, and Twitter, for instance, are successful applications of social networking services.
However, personal information in OSN is shared among group contacts. Due to the private nature of the shared information, data privacy is an indispensable security requirement in OSN applications. For solving the privacy-related problem, scholars use some valuable methods such as oblivious transfer (OT) [1], identity-based encryption (IBE) [2], searchable encryption [3], privacy-preserving profiles searching (PPPS) [4], access-right revocable scheme [5], middleware for mobile social networking [6], privacy-preserving matchmaking protocol [7], and decentralization-based scheme [8].
Beside privacy consideration, authentication [9] is also an important issue for matchmaking schemes, and authentication protocols, such as password-based authentication schemes [10, 11], are required. However, prior to password authentication, key establishment and key agreement [12–16] are needed as well. The first unauthenticated key agreement protocol based on asymmetric cryptographic techniques was proposed by Diffie and Hellman [17, 18]. Later, some authenticated key agreement [19–24] and anonymous key agreement [25, 26] protocols were developed and proposed.
MobiClique [6], a mobile social networking middleware, let users’ smartphones broadcast beacons to nearby devices to show their owners' information. MobiClique users download their profile information from Facebook to their devices and send this information to any Bluetooth device nearby for performing a matching. This approach reveals personal private information to anyone.
Meet Gatsby [27] and Loopt [28] are interesting websites which can find nearby people with shared interests. They require a trusted server that participates in each matchmaking operation. The server knows the interests and current location of each user and performs matchmaking based on this information. This approach allows the server to track users.
However, almost all of the applications are centralized and a trusted server is necessary. This centralized deployment results in some limitations. The users have to connect to the server to use the being controlled data. This brings inconvenience because accessing Internet is not always allowable for all users. All private information of a user is stored in the server, so there is the risk of private information leakage. In addition, each user is only authenticated to the sever, so a user has no capability to verify the information provided by another user. As a result, the issues of centralized deployment lead to inconvenience for mobile usage, leakage of private information, and lack of information authenticity between users.
A decentralization-based scheme [8], for privacy issue, suggests a peer-to-peer architecture solution to avoid centralized control for the existing online centralized architecture. It is based on hop-by-hop trust relationships.
FindU [29] is a privacy-preserving personal profile matching schemes for mobile social networks. An initiating user can find the one, from a group of users, whose profile best matches with his/her. Only necessary and minimal information about the private attributes of the participating users is exchanged to limit the risk of privacy exposure.
Xie and Hengartner [7] proposed another privacy-preserving matchmaking scheme for mobile social networking. They extended AgES [30], which uses commutative encryption, to provide the private matching function. The users' interest items are hashed and then compared for achieving privacy preservation. Therefore, a potentially malicious user learns only the interests that he has in common with a nearby user. Although their protocol does not require a trusted server in matchmaking phase, they need a personal interest signer (in interest signing phase) to sign personal interests in advance. Wang et al. [31] proposed another privacy-preserving matchmaking scheme for mobile social networking to enhance the computational performance of [7]. However in their schemes [7, 31], trusted third parties, identity signer and personal interest signer, are required to issue identity certificates and create interests signatures, and social networking friendships cannot be proved directly.
Chiou and Huang [32] and Chiou et al. [33] propose a social-network-based common-friend discovery application which is noncentralized and provides privacy preservation and information authentication. The application aims to find common friends of two users via their personal devices, such as cell phones or PDA, directly, wirelessly and privately.
In this paper, we propose a mobile private matchmaking scheme based on social connection. The special advantage and the novelty is that the proposed scheme is non-centralized and provides privacy preservation, mutual authentication, friendship relation verification, and friendship ownership certification, which guarantee that the matchmaking target is a friend of friend. Via mobile devices, users can use Wi-Fi Direct [34] and free personal area network (PAN) such as Bluetooth [35, 36] or Infrared Data Association (IrDA) [37] to communicate with each other without Internet access requirement. The application keeps personal information private. After executing the application, the only information that users share is their common friend. Furthermore, it authenticates the exchanged information and avoids forging problems. In addition, we implement a simulation prototype based on our proposed scheme on mobile phones running under the Android operating system.
The rest of this paper is organized as follows. In Section 2, we explain terms related to private matching, data ownership certificate, and replay attack resistance. In Section 3, we review related studies. A technical description and construction details for the proposed protocol are, respectively, presented in Sections 4 and 5. Security, efficiency, and performance analysis for the proposed protocol and property comparison between our scheme and related protocols are given in Section 6. Our implementation is described in Section 7, and we provide conclusions and directions for future work in Section 8.
2. Preliminaries
This section reviews terminology related to private matching, including Private Matching, Data Ownership Certificates, Asymmetric Exchange, and Replay Attack Resistance.
2.1. Private Matching
Freedman et al. [38] defined a private matching (PM) scheme as a two-party protocol between a client (chooser) and a server (sender) . The inputs of and are sets drawn from the same domain. At the conclusion of the protocol, determines which special inputs are shared by both and . Li et al. [39] also define the security requirement of PM as follows.
Definition 1 (security requirements of PM). Assuming there are two databases, and , one is query and one is matching protocol which computes . The scheme is secure and preserves privacy if it satisfies the following requirements.(1)Privacy. Each party can only know and its input to the matching protocol. Aside from this information, no other information is available to either party.(2)Nonspoof. The items in databases and are authorized by their respective owners. This means that the user can only query if the owner of the specific query item authorizes the item to the user. In other words, the user cannot generate the query item without authorization from the item owner. In addition, the user is required to present proof of this authorization.
2.2. Data Ownership Certificate (DOC)
Li et al. [39] define a Data Ownership Certificate (DOC) as an authorization token, which enables a user to prove his or her legitimate ownership of particular data. The DOC can attest to the data's ownership, provide verifiable element authorization, and prevent spoofing. If the user does not possess the DOC corresponding to the data in question, he or she cannot make queries for the data and convince another person that he or she is a legitimate owner of this data. The DOC can be used with a variety of matching protocols. Two requirements for the security properties of the DOC [39] are defined as follows.
Definition 2 ((DOC) security requirements). Assume Alice and Bob run a matching protocol to obtain information . The scheme provides security properties from DOC if it satisfies the following requirements.(1)Confidentiality. If Bob is not an authorized owner of , Bob should not be able to learn that Alice possesses by running a matching protocol directly with Alice.(2)Authenticity. If Bob is not an authorized owner of but Alice is an authorized owner of , Bob should not be able to pollute Alice’s matching result; that is, Bob cannot introduce into the matching result.
Note that confidentiality is difficult to achieve cryptographically since we have to consider both privacy and authenticity. Designs that reveal partial information are not acceptable, and schemes that require precomputation by a third party are not desirable. Therefore, sometimes the goal of DOC is referred to as the reduced confidentiality requirement.
2.3. Asymmetric Exchange
Assume that Alice and Bob play a private matching game to exchange their lists and and, after the game, learn the answer . Asymmetric exchange (of a private matching game) means that, for both parties to learn the answer , we must trust one party (e.g., Alice) to send a correct matching result to the other party (e.g., Bob), where Alice is assumed to be the party to make a final pass to send an important result to Bob. In symmetric exchange both parties simultaneously identify their common items through the matching protocol. When the two parties play an asymmetric private matching game, they are assumed to honestly report their friend lists and the corresponding computational results. (The HP [39], AgES [30], and FNS [38] schemes are categorized as asymmetric information exchanges.)
2.4. Replay Attack Resistance
A replay attack is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed [40]. In private matching protocols, replay attack resistance means that an adversary (or the originator) who intercepts or eavesdrops data and retransmits it is unable to effectively obtain private information or to successfully pose as a party running a private matching protocol.
3. Related Work
We present representative private matching protocols and friend discovery schemes in this section. The private matching protocols include Hash Protocol (HP) [39], AgES's commutative encryption protocol [30], FNP's polynomial-based protocol [38], and Data Ownership Certificate (DOC) [39], which can be combined with the private matching protocols to prevent spoofing; friend discovery schemes [32] include friend discovery scheme (FDS) and replay attack resistant friend discovery scheme (RR-FDS).
3.1. Private Matching Protocols
In Hash Protocol (HP) [39], a person who wants to query the common items in the other's database computes hash values of items in his own database and so does the person who is queried. Then they exchange these hash values. By this way, they can find the common items without revealing the information of the unmatched items. On the other hand, Agrawal et al. [30] proposed AgES which uses commutative encryption, instantiating as , to privately match items.
Also, Freedman et al. [38] proposed a polynomial-based private matching scheme. They use the property of homomorphic encryption provided by Paillier cryptosystem [41] to achieve stronger privacy. A variant of their scheme, set cardinality private matching, let know only the set cardinality of , , but the actual items in this set. It’s more applicable than previous schemes. After that, Kissner and Song [42] extend FNP scheme to support more functionality. However, these polynomial-based schemes usually have efficiency problem.
Moreover, HP, AgES, and Freedman et al.’s schemes are categorized to asymmetric exchange of information [39], different from symmetric exchange which both parties know the same information in the matching protocol.
Besides those, Li et al. [39] proposed Data Ownership Certificate (DOC) to ensure nonspoof. DOC provides the authorization of items. If a user does not obtain the item and the corresponding DOC, he cannot make the query and convince other users.
3.2. Friend Discovery Schemes
To find the common friends of two users, Chiou and Huang [32] proposed friend discovery protocols, friend discovery scheme (FDS), and replay attack resistant friend discovery scheme (RR-FDS) based on extending the HP and DOC [39] primitive to ensure privacy preservation and prevent mutual friendship spoofing, where RR-FDS adds the property of resistance to replay attacks. Two algorithms, CredentialExchange and FriendshipMatching, are defined in their protocol.
CredentialExchange(, ). Users and exchange credentials with each other. The credentials include friendship certificates to be used in FriendshipMatching.
FriendshipMatching(, ). Users and discover their common friends in a process which preserves privacy, achieves mutual authentication, certifies mutual friendship, and prevents mutual friendship spoofing.
Since our scheme is designed based on extending the RR-FDS, we now introduce FriendshipMatching of RR-FDS construction.
FriendshipMatching(, ). As shown in Figure 1, in this algorithm and privately match their common friends through the following steps.(1), where is a random number chosen by .(2), , , where , , and is a random number chosen by .(3) compares with to find the matching items , where and .(4), , , , , where , and is the signature of signed using ’s private key .(5) compares with to get the matching items .(6), , , .(7) verifies and verifies the signatures of the hash value for the identity of each common friend, concatenating ’s public key in .
Finally, and recognize their common friends .
4. Notations and Technical Preliminaries
4.1. Notations
Table 1 defines the notations used in our proposed protocol. In Table 1, “” denotes concatenation and is a fixed sufficient long secret string chosen by user , where “sufficient long” means the string is long enough to resist brute force or cryptographic attacks. In addition, in this scheme, knowing the secret implies friendship with user . Of course, it is not persuasive enough and advanced friendship has to be proven. Moreover, we define as True if and as False if not, where , . The symbol means target profiles, such as = “Job: undergraduate,” = “Gender: female,” = “Age: 18–28.” The symbol = means a personal profiles, such as = “Job: freshman,” = “Gender: female,” = “Marriage: unmarried,” = “Age: 19,” and = “Interest: watch movie.” In this case, = true.
4.2. Security Requirements
The security requirements of our proposed protocol are as follows.(1)Privacy Preservation. Users can only learn the identity of common friends and nothing else.(2)Mutual Authentication. Users can authenticate one another.(3)Mutual Friendship Certification. Users can prove their friendship to each other. (It is also named data authenticity.)(4)Mutual Prevention of Friendship Spoofing. Malicious users are prevented from manipulating these friendship certificates.(5)ReplayAttack Resistance. An adversary (or the originator), who intercepts or eavesdrops the data and retransmits it is prevented from successfully obtaining private information or posing as a party running a private matchmaking protocol.
5. Proposed Scheme
The proposed protocols, mobile private matchmaking (MPM), developed in this paper are based on extending the RR-FDS of Chiou and Huang protocol [32], primitive to ensure privacy preservation, prevent mutual friendship spoofing, and provide friendship discovery. The protocols are defined as three algorithms, Init, CredentialIssue, and AuthObjectMatching. We first describe the syntax of MPM with privacy and authenticity and then present the specification of our protocol.
5.1. Syntax of MPM with Privacy and Authenticity
MPM consists of three algorithms as follows.
InitAlgorithm. This algorithm is executed once by each user . On input of a security parameter , it initializes internal parameters, generates public key and private key , and clears ’s friendship certificate list, that is, (an empty set).
Credentiallssue(). This is credential issue protocol executed by users and . issues a personal credential to , and issues to . and are added to friendship certificate lists and , respectively. The credentials stand for the friendship between and . They are used in matching to show friendship and provide the friendship evidence. The inputs of and are (, , , ) and (, , , ), where is the identity of user , is the public key of user , is the private key of user , and is a fixed sufficient long string chosen by user .
AuthObjectMatching(). This is an authenticated object matching protocol executed by users and . In this protocol, and hope to find a matched object and their common friendship is also checked. It is designed as two-state mechanism such that is an and is a . The inputs of and are (, , , , , ) and (, , , , , ), where is ’s target profile which consists of the profiles of the target object and is ’s personal profile which consists of the profiles of user .
MPM allows users to find a matched object, recognize their common friends, and authenticate to each other. It proves friendship-credential ownership and replay attack resistance. The correctness and security of MPM are defined in Definitions 3 and 4.
Definition 3 (correctness of MPM). Assume that users and interact in a MPM protocol with input (, , , , , ) and (, , , , , ), respectively, and let and denote the corresponding sessions. By we denote the set of identities that appears in both and . MPM scheme is correct if (1) (find out a matched object) and complete in the same state, which is accepted if and only if or is rejected if or gets “not right object” information; (2) (friend discovery) both and learn ; (3) (mutual authentication) and can authenticate each other; (4) (friendship proof) and can prove their friendship of .
Definition 4 (security of MPM). Assume that users and interact in a MPM protocol with inputs (, , , , , ) and (, , , , , ), respectively. MPM scheme is secure if (1) (privacy preservation) and only learn and nothing else (i.e., learns nothing about and learns nothing about ); (2) (mutual authentication) and can authenticate to each other; (3) (mutual friendship ownership certification) and can prove their friendship to each other via the signatures of and signed using the private keys of their friends; (4) (mutual prevention of friendship spoofing) malicious users are prevented from manipulating these friendship credentials including and even if they obtain or ; and (5) (replay-attack resistance) an adversary, including and , who intercepts or eavesdrops the data and retransmits it, fails to obtain private information or to pose as a party or running a private matchmaking protocol.
5.2. The Protocol Specification
Based on Definitions 3 and 4, three algorithms Init, CredentialExchange, and AuthObjectMatching of MPM are presented as follows.
InitAlgorithm. The set-up routine run by each user mainly consists of the generation of safe RSA [43] parameters. Given security parameter , two -bit safe primes and are picked randomly. The RSA modulus is set to , and a pair is chosen such that (mod ). We denote is a public key and is a private key. (The underlying cryptosystem can also be ECC [44] or other cryptographic systems).
CredentialExchange ((,,, ), (,,, and )) . Users and generate personal credentials and for each other as follows.(1), where is the identity of and is the public key of . The underlying public key cryptosystem can use RSA [43], ECC [44], or other cryptosystems. Note that the key pair and is generated by each user, not by a trusted third party such as CA.(2) computes to prove his friendship ownership to , where is a cryptographic hash function, such as SHA1 [45] or MD5 [46], is the private key of , and represents the signature signed using key .(3), where is a sufficiently long string chosen by .(4) verifies . If is true, he computes . Else, send “fail” to and this algorithm fails.(5).(6) verifies . If is true, finish this algorithm successfully. Else, fail this algorithm.
Finally, adds in and adds in , where means friendship certificate list of .
An example of CredentialExchange(Alice, Bob) is shown in Figure 2. Note that and should be protected from eavesdropping in CredentialExchange. This algorithm can usually be performed via Bluetooth [35, 36], which provides a basic confidentiality service to thwart eavesdropping attempts on packet payloads exchanged between Bluetooth devices [47]. Otherwise, and can be encrypted using public keys, and , which can be authenticated via Bluetooth device authentication procedures [47].
AuthObjectMatching ((, , , , , ), (, , , , , )) . Users and hope to find a matched object via this protocol. It is designed that is the and is the . The protocol is shown as follows. (Also see Figures 3 and 4).(1), who chooses to be an , broadcasts , where is a random number chosen by .(2) (who chooses to be a ) , , , , , where .(3) gets and compares with to find the matching items , where . If , and have no friends in common. then sends a “no match” message and terminates the algorithm. Else, verifies, if is true. If it is true, the algorithm proceeds to the next step. Else, sends a “failure” message and terminates the algorithm.(4), , , , , .(5) compares with to get the matching items and then verifies and . If either or , is false, sends “failure”, and terminates this algorithm, where . Else, computes secret key and gets . If (,) true, which means is not the right object, sends a “not right object” message and terminates this algorithm, where is ’s personal profile. Else, the algorithm proceeds to the next step.(6), , .(7) verifies . If , is true, computes , where . Else, sends a “failure” message and terminates the algorithm. If (,) is false, which means is not the right object, sends a “not right object” message and terminates the algorithm. Else, the algorithm proceeds to the next step.(8). and find their target objects and and negotiate a time, location, and others confidentially.
and can recognize their common friends . In AuthObjectMatching, step 8 can be combined into steps 4 and 6 to reduce transmission times. Notice that no information aside from is disclosed. That is, does not learn any information about , and does not learn any information about . Moreover, observe that no trusted centralized server is needed in the proposed protocol.
6. Analysis of Proposed Scheme
6.1. Security Analysis
We analyze the security of our protocols according to the requirements defined in Definition 4.
Privacy Preservation. For , since each in is the hash values of , , and , or other persons do not know the meaning of unless he or she has the same pair of and , where . Therefore, the information of their noncommon friends is kept private. (Similar to , the information of his friends is kept private.)
Mutual Authentication. can authenticate from the response messages , and since is a random number chosen from , and is signed from in .
Mutual Friendship Ownership Certification. From , can prove her friendships of to , because signed the in and can verify the signature using the public keys of .
Mutual Prevention of Friendship Spoofing. Since users and have to provide the signatures (, ) and (, ) to each other to prove they are the person who is the friend of , no one can spoof the friendship without ()’s signature and his/her own private key.
Replay Attack Resistance. transmits to using time and transmits to using the chosen number . Since the values and change, the values and are different in different matching. Therefore, MPM can resist replay attacks.
6.2. Protocol Efficiency and Performance
In this subsection, we analyze the performance of our proposed methods and compare them with other protocols. Table 2 summarizes the symbols used in the comparison. MPM costs are then examined, with communication cost and computational cost, respectively, compared in Table 3. For CredentialExchange, the communication cost is , the computational cost is , and the total transaction number is 3.
The communication costs of and are and + + , and the total transaction number is 4, where means the length of Target Profile. Here we ignore the costs (initial broadcast), and (the negotiation between and encrypted using the session key ).
Both the computational costs of and are approximately since , , and cost much time comparing and . Assume each of , , and is about 1ms and then the computational time of and are approximately 6 ms, which is efficient in both computation.
6.3. Property and Performance Comparison
The properties and performances of the proposed protocol MPM are compared with Xie and Hengartner’s protocol [7] and Wang et al.'s protocol [31] in Tables 4–6. Comparing Tables 3, 4, and 5, we can see the performance of the proposed scheme is much better in all aspects, where represents the number of common interests or attributes, // stands for the length of an interest or attribute/a confirm message/the size of intersection set, and represents the trusted third party Verification Server. All these schemes provide privacy preservation, mutual authentication, and replay attack resistance. However, the schemes of Xie and Hengartner [7] and Wang et al. [31] need thrusted third parties, identity signer, and personal interest signer, to issue identity certificates and create interests signatures. In addition, only our scheme provides the functions of friendship relation and friendship ownership certification, which guarantee that the matchmaking target is a friend of friend.
7. Implementation
In this work, we implement a simulation prototype based on our proposed schemes, including CredentialExchange (as shown in Figure 2) and AuthObjectMatching (as shown in Figures 3 and 4), on mobile phones running the Android operating system.
To implement our proposed scheme, we use two cell phones for each mobile system. The transmission interface is Wi-Fi. According to our proposed scheme, the prototype has two primary capabilities, credential exchange and mission matching. We assume CredentialExchange is finished via the implementation of Chiou and Huang [32]. In this phase, any two persons can exchange their credential to each other by using their cell phones. We implement AuthObjectMatching of MPM scheme. Anyone can recognize their common friends with other persons by using the credentials exchanged in CredentialExchange and find their matched target with each other by using the profile setup in AuthObjectMatching.
Figure 5 shows the Android mobile phone screens of our implementing prototype. We use JAVA program language to implement them. The types of equipment are Samsung Nexus S, which use Android 2.3 professional operation system. The technological specifications of the equipment are 16 GB ROM, 512 MB RAM, and Cortex-A8 1 GHz CPU, with WiFi network function.
(a) Splash screen
(b) Meal matchmaking
First of all, the splash screen is shown in Figure 5(a), where we can see that it has the function to find a person to have meal with, to play game with, to see a movie with, or to do some other activities with. Clicking the button Meal proceeds to the next screen shown in Figure 5(b), where Server (CF)/Client (CF) denotes a server (initializer)/client (responder) choice with common friend function, and Server (NCF)/Client (NCF) stands for a server (initializer)/client (responder) choice without common friend function.
Assume there are two persons who are going to find a person to have meal with via their mobile devices (as shown in Figure 5(a)). After clicking the button Meal from the splash screen (as shown in Figure 5(b)), they can choose to be an initializer (or server) or responder (or client) with or without common friend function. Let the left device be a server by clicking Server (CF) button and the right one be a client by clicking Client (CF). Then, the screens of the two devices are shown in Figure 6(a). (If other buttons Server (NCF)/Client (NCF), instead of Server (CF)/Client (CF), are chosen, the scheme directly proceeds to set up personal and target profiles, as shown in Figure 7.)
(a) Server sends message
(b) Client returns message
(a) Server sends target profile
(b) Client sends target profile
The two users then click Create Match Data to create their match data . After that, client clicks Listen Message to wait for the data-matching message from server and server clicks Send Message to send his message to client. After receiving the message, client clicks Check Common Friends button to check whether they have common friends.
After that, as shown in Figure 6(b), server clicks Listen Message to wait for the response of client, and client clicks Return Message to return its data-matching message to server. After that, server clicks Check Common Friends button to check whether they have common friends. If they have common friends, as shown in Figures 7(a) and 7(b), they can then set up their Personal Profile and Target Profile to see whether they find each other as their real target to have meal with.
As shown in Figure 7(a), client sets up his or her personal profile and clicks Listen Target Profile to see whether there is a response from server; server sets up his or her target profile and clicks Send Target Profile to send his/her target profile to client. If the personal profile and the target profile matche, server sets up his or her personal profile and clicks Listen Target Profile; client sets up his or her target profile and clicks Send Target Profile (as shown in Figure 7(b)).
If the target profile of client matches the personal profile of server, client then clicks Listen Message to wait for the message from server (as shown in Figure 8.) Server inputs some messages from Enter Message Here box and clicks Send Message to send the input message to client. Similarly, server clicks Listen Message to wait for the message from client. Client inputs some messages from Enter Message Here box and clicks Send Message to send the input message to server.
By using the message exchange, server and client can negotiate for the meal time and place. Moreover, the exchanged message can be encrypted by a session key which can be encrypted by public keys. When the meeting time comes, server and client can authenticate each other via message authentication by the session key or by their public/private keys.
8. Conclusions
In this paper, we present MPM, a mobile matchmaking scheme, which is used not only to find a matched object but also to check whether a common friend exists. In the proposed scheme, privacy preservation, mutual authenticity, mutual friendship ownership certification, mutual prevention of friendship spoofing, and replay attack resistance are considered. Comparisons with other approaches show that the proposed schemes provide improved security while performing efficiently in terms of computational and communication costs. The implementation of the proposed algorithms on Android system mobile devices allows users to securely find a matched object.
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.
Acknowledgments
This work was partially supported by the National Science Council under Grant NSC 101-2221-E-182-071. The authors also gratefully acknowledge the helpful comments and suggestions of the reviewers, which have improved the presentation.