移动社交网络中的“社交发现”服务，因其允许用户通过分享自己的个人属性信息，去寻找周边区域中和自己兴趣特点相近的潜在朋友，而越来越受到广大用户的欢迎。然而，由于用户的属性信息中通常包含大量的个人隐私内容，且用户私人资料与用户位置往往又深度结合，如果没有进行有效的防护，攻击者可以很容易地把用户信息和周边某个具体用户联系起来，非法获取一些用户的真实身份和社会关系，造成大面积隐私泄露的严重后果^[1]。因此，有一些研究者关注社交发现的隐私保护方案^[2-5]，这些方案可使用户双方比较它们之间敏感的个人资料而又不互相泄露彼此的隐私信息。

现有的社交发现隐私保护方案，通常分为两大类：第1类，其社交发现不依靠服务器，方案安全性由用户端点对点地提供保证^[6]，或者服务器仅协助管理密钥^[7]。这类方案中所有比较和发现的过程均在用户端执行，如果周边同时响应社交发现服务用户的数目过多，用户端的计算压力将会非常大，很容易造成服务质量严重下降。另外，用户端由于缺乏必要监管，安全性较低，更易被攻击者攻破。第2类，社交发现基于可信服务器，方案安全性有服务器提供保证^[8]。服务器承担绝大部分计算任务，社交发现过程将在服务器集中执行。这类方案很大程度上减轻了用户端的负担，检索用户范围大，服务响应时间短，便于大范围部署。但由于服务器参与全部发现过程，有可能存在其被攻破或者服务器自身出于各种目的试图非法获取用户敏感资料的危险。因此，本文关注的焦点是如何使得服务器既能有效地进行社交发现服务，又尽可能少地掌握用户个人的隐私信息。

目前，已有一些针对可信服务器的社交发现隐私保护方案，比如，Guo等^[9]把用户待比较的属性信息度量化，用以比较其中的相似程度；Zhu等^[10]将用户个人属性信息转换为带有权重的向量，进行细粒度控制使得比较结果更精确；Naini等^[11]提出运用加密技术，加密用户个人属性信息的思想；Niu等^[12]构建了一个混淆矩阵，将用户个人属性信息转换成密态再进行匹配；Li等^[13]对社交网络中每一个节点的度与索引进行比较。通过研究，以上方案都存在两方面隐患：1）大多没有从实际应用角度考虑，社交发现过程缺乏对用户身份的认证机制，攻击者容易通过窃听信道，发起中间人攻击，或者假冒身份进行欺骗攻击；2）为了提高整个社交发现的效率，服务器获得用户个人属性资料信息过多，很难抵御攻击者与服务器的共谋风险。

针对以上安全隐患，本文提出了一种基于密钥协商判定性迪菲–赫尔曼和身份匿名（Diffie–Hellman and Identity anonymity，DH–IA）技术的安全防护方案，下文简称为DH–IA方案。首先，给出一种基于身份访问权限认证技术和密钥协商相结合的双重认证机制，提高社交发现服务中用户认证的安全性，防止合法用户身份泄露和恶意攻击者进行伪造身份攻击；然后，给出一种综合运用双线性对、不可逆哈希函数、随机密钥、对称及非对称加密技术的保护机制，防止恶意攻击者伪造和破解社交发现服务中用户的隐私属性信息。

1 DH–IA方案的系统模型与设计目标 1.1 系统模型

在移动社交网络服务中，用户到达一个新的地点后，经常会有搜索周边潜在朋友的需求。用户使用这样的服务前，首先初始化关于自己隐私属性信息的文件。该文件包括很多不同的属性值，比如，反映用户兴趣爱好的信息（如电影、足球、旅游等）。系统会把这些属性值抽象成对应的特征集合，表示为 $T = \left\{ {{p_1},{p_2}, \cdots ,{p_n}} \right\}$ 。其中： $T$ 为用户的个人属性集； $ {p_i}( i = $ $ 1,2, \cdots ,n)$ 为一整数，对应属性集T中的一个具体的属性值，并且它们互不相等。对于某一具体用户，当发出社交发现服务请求前，也必须首先设定好自己的个人属性信息文件。例如，用户A的兴趣点是电影、钓鱼、古典音乐，那么，抽象成的属性集可能为 ${T_{ A}} = $ $\left\{ {24,\;37,\;53} \right\}$ 。本文所提出的DH–IA方案系统架构如图1所示，主要包含3部分：用户A、用户B和服务器。其中服务器承担搜索周边区域陌生人的查询任务。

用户A和用户B均为移动社交网络服务的注册用户，它们之间的位置距离在查询范围之内。一个完整的社交发现验证过程是：1）用户A发起查询周边潜在好友请求，同时，将自己的兴趣属性集 ${T_{ A}}$ 上传至服务器。2）服务器接到请求后，向符合条件的用户B发出邀请，获得同意后用户B也将自己的兴趣属性集 ${T_{ B}}$ 上传至服务器。3）服务器进行比较，若比较成功则向用户A发送匹配成功信息，并建立用户A与B的联系，然后，转向规定距离内下一个符合条件的注册用户继续比较，直到全部比较完成。

服务器可以由移动社交网络服务商部署，也可以租用其他公司的专业服务器。因此，服务器是一个不完全可信的第三方服务器，用户不能将其兴趣属性集不加防护地直接发送给服务器，必须先经过可靠的安全防护机制进行处理。

1.2 威胁模式

在移动社交网络社交发现服务的过程中，存在两种可能的威胁模式：

1）本方案设定服务器和参加社交发现过程的其他用户，都是“诚实但好奇”（honest but curious）的，它们均能如实地按照规则的要求进行查询服务，返回正确的比较结果，但是它们也会出于某种目的，试图从自己获得的信息中，分析并推测出其他用户更多的敏感资料。

2）恶意攻击者有可能监听用户和服务器之间、用户之间的通信信道，窃取通信信息，进行暴力破解攻击，或者篡改、伪造信息发起中间人攻击及重放攻击^[14]。恶意攻击者还有可能伪造或盗用其他用户身份，试图假冒他人与用户联系，非法获得用户个人属性集的信息。

1.3 设计目标

针对上述威胁模式，DH–IA方案应在满足移动用户社交发现的服务功能前提下，不泄露用户的个人隐私信息。一方面，恶意攻击者和服务器及其他移动用户都不能通过各种手段，获取用户的个人属性信息文件的具体内容。在DH–IA方案执行过程中，执行社交发现过程的每一个参与者，无论是服务器还是用户，都只能获得比较的结果即“匹配成功”或者“匹配失败”，不能获得其他任何参与比较的属性信息。另一方面，DH–IA方案应有相应的保护机制，使得恶意攻击者即使窃听通信信道获得比较双方交互的信息，也无法将其识别。对于恶意攻击者的欺骗攻击和重放攻击，用户和服务器应能迅速发现，能够快速确定所获得的信息在传输过程中是否完整、是否被恶意篡改。

2 预备知识

DH–IA方案为了阻止攻击者通过窃听信息、暴力破解等手段，非法破解用户个人属性信息文件，使用Diffie–Hellman密钥协商机制构建加密方法，使得在用户密态数据可以准确比较的前提下，可以保证恶意攻击者无法破解，提升方案的整体安全性。同时，DH–IA方案为了识破攻击者伪造用户身份的欺骗攻击，综合运用了不可逆哈希函数、密钥认证等技术手段，构建安全的用户身份认证机制，保护合法用户的隐私信息安全。

其中，不可逆哈希函数是一组哈希函数；公钥加密算法采用RSA（Rivest，Shamir，Adleman）；D–H密钥协商机制基于椭圆曲线上的双线性对（bilinear pairing）构造。

假设 $G$ 和 ${G_T}$ 为大素数 $p$ 阶的循环群，则存在椭圆曲线群上的双线性映射 $e:G \times G \to {G_T}$ 满足以下性质：

1）双线性。对于任意群元素 $g,h \in G$ 及整数 $x {\text{、}}\!\!y$ 均有 $e({g^x},{h^y}) = e{(g,h)^{xy}}$ 。

2）非退化性。存在任意群元素 $g,h \in G$ ，使得 $e(g,h) \ne 1$ ，其中1为群 ${G_T}$ 的单位元。

3）可计算性。对于任意群元素 ${u_1},{u_2},v \in {G_T}$ ，存在多项式时间复杂度内的有效算法，能够计算出一个双线性对的值 $e({u_1}{u_2},v) = e({u_1},v)e({u_2},v)$ 。

3 DH–IA方案设计

本文设定在一个完整的社交发现过程中，通信双方分别为用户A和用户B，其中，用户A是查询服务请求者，B是查询服务响应者。DH–IA方案共包含用户注册、身份认证、查询和用户建立联系4个部分。

3.1 用户注册

服务器选择一个随机的安全系数，生成素数p阶群的双线性映射参数 $(p,g,G,{G_T},e)$ ，通过其产生公开的系统参数 $S$ 与服务器公私钥 $Pubs$ 和 $Pris$ ，其中：

$\begin{aligned}[b] & S = (p,g,e,e{(g,g)^x},G,{G_T}), \\ & x \in Z_p^*,g,{h_1},{h_2} \in G \end{aligned} $

(1)

在每个用户首次使用社交发现服务之前，都需要在服务器上完成注册。以用户A为例，注册时先生成随机数 ${a_{{A}}},{u_{{A}}},{v_{{A}}}$ $ \in Z_p^*$ ，使用服务器公钥 $Pubs$ 加密传送给服务器，服务器收到后生成用户A的认证号 ${I_{{A}}}$ 返回给该注册用户，其中：

$\begin{aligned}[b] & {I_{{A}}} = ({g^{x + {a_{{A}}}{u_{{A}}}}},{g^{{u_{{A}}}}},{g^v},h_1^{{u_{{A}}}}h_2^{{v_{{A}}}}), \\ &{a_{{A}}},{u_{{A}}},{v_{{A}}}\in Z_p^*,g,{h_1},{h_2} \in G \end{aligned} $

(2)

其他用户以类似用户A的方式完成注册。

3.2 身份认证

在每个用户每次使用社交发现服务之前，都需要先在服务器上完成相应的身份认证^[15-17]，如图2所示，以确定用户的合法性。

当用户A向服务器提出查询请求时，需先进行身份验证。用户A选择一随机数 $y \in Z_p^*$ ，并利用注册时生成的保密随机数 ${a_{{A}}}$ 与系统参数 $S$ ，计算得到验证值 ${U_{{A}}} = e{(g,g)^{xy}}$ 以及验证参数集（ ${C_1} = {g^y}$ ， ${C_2} = {g^{{a_{{A}}}y}}h_1^{ - y}$ ， ${C_3} = h_2^{ - y}$ ），上传至服务器，发起验证。服务器通过验证参数集来计算 $U_{{A}}'$ ，并与 ${U_{{A}}}$ 进行比较，以判断用户的身份。如果该用户合法，则有：

$\begin{aligned} U_{{A}}' =& \frac{{e({C_1},{g^{x + {a_{{A}}}{u_{{A}}}}})}}{{e({g^{{u_{{A}}}}},{C_2})e({g^{{v_{{A}}}}},{C_3})e(h_1^{{u_{{A}}}}h_2^{{v_{{A}}}},{C_1})}} = \\ & \frac{{e({g^y},{g^{x + {a_{{A}}}{u_{{A}}}}})}}{{e({g^{{u_{{A}}}}},{g^{{a_{{A}}}y}}h_1^{ - y})e({g^{{v_{{A}}}}},h_2^{ - y})e(h_1^{{u_{{A}}}}h_2^{{v_{{A}}}},{g^y})}} = \\ & \frac{{e({g^y},{g^x})e({g^y},{g^{{a_{{A}}}{u_{{A}}}}})}}{{e({g^{{u_{{A}}}}},{g^{{a_{{A}}}y}})e({g^{{u_{{A}}}}},h_1^{ - y})e({g^{{v_{{A}}}}},h_2^{ - y})e(h_1^{{u_{{A}}}}h_2^{{v_{{A}}}},{g^y})}} = \\ & \frac{{e({g^y},{g^x})}}{{e{{(h_1^{{u_{{A}}}}h_2^{{v_{{A}}}},{g^y})}^{ - 1}}e(h_1^{{u_{{A}}}}h_2^{{v_{{A}}}},{g^y})}} = \\ & \quad\quad e{(g,g)^{xy}} = {U_{{A}}} \end{aligned} $

3.3 查询匹配

服务器接到用户A的查询请求，会先进行身份验证，如果 $U_{{A}}' \ne {U_{{A}}}$ ，则验证没有获得通过，用户A为非法用户，查询请求中断，同时向安全服务中心报告并记录；如果 $U_{{A}}' = {U_{{A}}}$ ，则用户A为合法用户，返回“OK”信息给用户A。

用户A接到“OK”信息后，首先构建用于查询比较的属性集。用户A可以选择自己全部的兴趣点属性集，也可以只选择其中一部分作为本次查询的对象。假设本次查询中用户A的属性集为 $I{P_{ A}} = \{ {m_1},{m_2}, \cdots , $ ${m_{na}} \}$ ，其中， $m_i$ 为某一个具体的兴趣点对应的值， $na$ 为本次查询用户A的属性集的总数。确定查询属性集后，用户A生成用于本次查询的不可逆哈希函数 $h( \cdot )$ ，并生成随机数 $r \in Z_p^*$ 。之后，A使用该 $h(\cdot)$ 与 $r$ 分别对查询属性集进行哈希操作，得到 $h\left( {I{P_{{A}}}} \right) = \{ h\left( {{m_1}||r} \right),$ $h\left( {{m_2}||r} \right), \cdots ,h\left( {{m_{na}}||r} \right) \}$ 。

然后，用户A利用双线性映射，生成自身密钥 $ke{y_{{A}}}$ 。其中，用户A从整数集合 $Z_p^*$ 中取一个随机数 $RA$ ，生成用户A的一次性密钥 $ke{y_{{A}}} = {g^{RA}}\left( {{\rm{ mod}}\; p} \right)$ 。

最后，用户A使用在身份认证过程中接收到的服务器公钥 $Pubs$ ，对以上信息进行加密，得到用户A的查询信息 $MA = {E_{Pubs}}\left( {h\left( {I{P_{{A}}}} \right),ke{y_{{A}}},temp} \right)$ ，发送给服务器。其中， $temp$ 为用于验证信息完整性的时间戳。

服务器接收到查询信息 $MA$ 后，使用自身的私钥Pris进行解密。首先，对时间戳 $temp$ 进行验证，如果有问题，则可能受到攻击者的重放攻击，服务器终止查询过程并上报安全服务中心；如果验证成功，服务器将保存用户A的 $h\left( {I{P_{{A}}}} \right)$ 和 $ke{y_{{A}}}$ 。

接下来，服务器对周边区域内符合条件的所有其他用户发出邀请，假设用户B收到邀请并回应同意，服务器将对用户B进行身份认证，具体过程同上。通过身份认证后，用户B利用双线性映射，生成自身密钥 $ke{y_{{B}}}$ 。其中，用户B从整数集合 $Z_p^*$ 中取一个随机数 $RB$ ，生成用户B的一次性密钥 $ke{y_{{B}}} = {g^{RB}}\left( {{\rm{ mod}}\; p} \right)$ 。用户B使用服务器公钥 $Pubs$ ，对 $ke{y_{{B}}}$ 进行加密，发送信息 ${E_{Pubs}}\left( {ke{y_{{B}}}} \right)$ 给服务器，服务器解密获得B的密钥 $ke{y_{{B}}}$ 。服务器使用密钥 $ke{y_{{A}}}$ 加密 $ke{y_{{B}}}$ 发送给用户A，使用密钥 $ke{y_{{B}}}$ 加密 $ke{y_{{A}}}$ 发送给用户B。用户A与B分别使用私有的保密参数 $RA$ 与 $RB$ 对 $ke{y_{{B}}}$ 和 $ke{y_{{A}}}$ 进行求幂运算，生成共同私钥 ${g^{RA \cdot RB}}$ 。用户A使用 ${g^{RA \cdot RB}}$ 加密 $h( \cdot )$ 与 $r$ 传递给用户B，用户B使用 ${g^{RA \cdot RB}}$ 解密 $h( \cdot )$ 与 $r$ ，并对自身全部属性集信息进行哈希操作，得到 $h\left( {I{P_{{B}}}} \right) = \{ h\left( {{m_1}||r} \right), $ $h\left( {{m_2}||r} \right), \cdots ,h\left( {{m_{nb}}||r} \right)\} $ ，其中， $m_i$ 为某个具体的兴趣点对应的值， $nb$ 为用户B的属性集总数。用户B继续使用服务器公钥 $Pubs$ ，将 $h\left( {I{P_{{B}}}} \right)$ 信息加密发送给服务器。

服务器完成上述准备工作后，对获得的 $h\left( {I{P_{{A}}}} \right)$ 和 $h\left( {I{P_{{B}}}} \right)$ 进行比较，记录其中交集的个数，且设为 ${F_{{{AB}}}}$ 。依照同样的步骤，服务器将分别对其他符合条件的用户，均进行上述比较操作，得到一个交集的个数集合 $F = \left\{ {{F_{{{AB}}}},{F_{{{AC}}}}, \cdots } \right\}$ ，从中选取出最大值。假设 ${F_{{{AB}}}} $ 是其中的最大值，则说明用户B是本次社交发现过程中，用户A的最佳选择。当然，最佳选择者可能不止一个，服务器应将这些用户的社交身份 $ID$ 全部推荐给用户A，由用户A自己进行选择。全部查询比较过程如图3所示。

3.4 用户建立联系

完成比较工作后，被服务器推荐成为朋友的双方，开始进行联系。假设用户A被推荐的最佳选择是用户B，在用户A和用户B对话之前，为了防止可能的攻击者使用伪造用户B的身份欺骗攻击，非法篡改数据，有必要进行用户身份确认，识别可能的危险，建立安全的联系。

用户A与用户B建立联系，也即把用户B在移动社交网络上的身份标志 $I{D_{{B}}}$ 安全地传递给用户A，使得用户A可以通过服务器向用户B提出交友请求。用户B首先使用 ${\left( {ke{y_{{A}}}} \right)^{RB}}$ （即 ${g^{RA\cdot RB}}$ ）与自身在服务器上注册的唯一身份标志 $I{D_{{B}}}$ 异或，生成匿名身份 $ID_{{B}}'$ ，即 $ID_{{B}}' ={\left( {ke{y_{{A}}}} \right)^{RB}}$ $ \oplus I{D_{{B}}}$ 。然后，用户B使用不可逆哈希函数 $h( \cdot )$ ，将自身 $I{D_{{B}}}$ 进行哈希运算，得到 $h(I{D_{{B}}})$ 。最后，用户B使用key_A加密 $h(I{D_{{B}}})$ ，得到验证消息 $VM$ ，发送给用户A：

$ VM = {E_{ke{y_{{A}}}}}(ID_{{B}}',h(I{D_{ B}})) $

(3)

用户A接收到 $VM$ 后，首先利用自身的密钥 $ke{y_{{A}}}$ 解密，获得 $ID_{{B}}'$ 和 $h(I{D_{{B}}})$ 。然后，使用 ${\left( {ke{y_{{B}}}} \right)^{RA}}$ （即 ${g^{RA \cdot RB}}$ ）将 $ID_{{B}}^{'}$ 还原，具体过程如下：

$ ID_{{B}}' \oplus {\left( {ke{y_{{B}}}} \right)^{RA}} = {\left( {ke{y_{{A}}}} \right)^{RB}} \oplus I{D_{{B}}} \oplus {\left( {ke{y_{{B}}}} \right)^{RA}} $

(4)

显然经过两次异或后，式（4）的结果为 $I{D_{{B}}}$ 。然而这个 $I{D_{{B}}}$ 并不一定为真，因为信息在传输过程中有可能被恶意攻击者截获并篡改，故还需要第二次握手验证。用户A使用不可逆哈希函数 $h( \cdot)$ ，将刚获得的 $I{D_{{B}}}$ 进行哈希运算得到 $h'(ID_{{B}})$ ，并与解密获得的 $h(I{D_{{B}}})$ 进行比较。如果相等，则 $I{D_{{B}}}$ 是正确的，即用户A能够获得与其兴趣爱好最相近的用户B在服务器上的联系方式，双方可以开展进一步交流。如果不等，那么，验证消息已被恶意攻击者进行了伪造，原所获 $I{D_{{B}}}$ 是虚假身份，用户A应删除并中止查询，报告安全服务中心。用户A重复同样的验证步骤，可以获得所有与之匹配潜在好友的 $ID$ 信息。全部用户联系过程如图4所示。

4 安全性分析

本文提出的DH–IA方案设定了响应的用户对象和服务器都是“诚实但好奇”的，它们均能如实按照规则的要求进行服务。它们也不会相互勾结，但都试图从自己获得的信息中，分析并推测出查询用户的更多个人属性资料信息。同时，还有可能存在恶意攻击者窃听通信信道，伪造虚假身份，企图暴力攻破用户的个人属性集，非法获得用户更多敏感数据。下面针对这两个主要威胁进行安全性分析，证明DH–IA方案是安全的。

定理1 　本方案中服务器和响应用户能够成功推测出查询用户个人属性集的概率是可忽略的。

证明：对服务器而言，它确实可以获得由查询用户A提交的，经过单向的不可逆哈希函数 $h( \cdot)$ 与保密参数 $r$ 处理过的查询属性哈希值的集 $h\left( {I{P_{{A}}}} \right)$ 。但由于该哈希函数 $h( \cdot)$ 是不可逆的，服务器无法把 $h\left( {I{P_{{A}}}} \right)$ 恢复为属性集 $I{P_{{A}}}$ 。另外，服务器也无法通过建立有用的属性集哈希值函数库去匹配属性哈希值，从而获悉用户A的属性集。因为用户A进行哈希运算时，附加有随机数r，该随机数对服务器是保密的。故对于任一属性，服务器无法构造出与用户相同的属性哈希值。因此，服务器既不能还原用户属性集，也不能通过属性匹配操作收集到用户属性集。

对响应对象用户B而言，在本方案的全部比较过程中，由于只有服务器进行匹配计算，用户B不能获得任何与其他用户个人属性集有关的信息，只从服务器端接收到是否有匹配成功的消息。因此，响应用户B不能推测出查询用户A的个人属性集。

由此，服务器和响应用户成功推测出查询用户个人属性集的概率是可忽略的。定理得证。

定理2 　本方案可以阻止恶意攻击者的中间人攻击和重放攻击。

证明：攻击者有可能通过窃听不安全的通信信道，截获用户发送给服务器的查询请求，发起中间人攻击或者重放攻击。本方案中服务器对于每一次的查询请求，都必须先进行身份认证，其安全性可以规约到双线性映射的安全性，故攻击者发起的中间人攻击无法成功。另外，DH密钥协商过程中，用户A、B与服务器的通信，使用了服务器的公钥进行加密。因此，密钥协商过程中，攻击者也无法发起中间人攻击。同时，用户在每次查询信息中加入了时间戳 $temp$ ，服务器在每次比较之前都会先检查时间戳的合法性和连续性，这也有效地阻止攻击者的重放攻击。定理得证。

定理3 　本方案可以阻止恶意攻击者的伪造身份攻击。

证明：攻击者有可能在比较成功后，拦截用户联系信息，伪造被匹配者用户B的身份，企图冒名顶替与查询者用户A建立联系。本方案中用户进行交友前，采取针对用户B的社交网络标志 $I{D_{{B}}}$ 的匿名身份认证，攻击者无法通过认证 $ID_{{B}}' \oplus $ ${\left( {ke{y_{{B}}}} \right)^{RA}}$ 还原出用户B的真实身份 $I{D_{{B}}}$ ，因为用户A进行第二次握手验证时会识破攻击者的伪造身份，这有效地阻止攻击者的伪造身份攻击。定理得证。

定理4 　本方案可以阻止恶意攻击者的暴力破解攻击。

证明：攻击者有可能通过窃听通信数据，利用获得的背景知识，构造攻击字典，进行暴力破解攻击。本方案中用户的个人属性集发送前，要经过附有随机数的不可逆哈希函数的处理和公钥加密，攻击者暴力破解的难度相当于攻破这两个密码学机制，这显然是非常困难的。而且，当用户每次发起新的查询服务时，都会更换新的随机安全参数，生成新的不可逆哈希函数，这意味着攻击者无法窃取到足够的样本进行分析，有效地阻止攻击者的暴力破解攻击。定理得证。

综上所述，与同类方案^{[3–4,9–13]}相比，DH–IA方案在安全性上取得了以下进步：

1）同类方案在密钥交换过程中缺乏用户身份的认证机制，因此很容易遭到中间人攻击和重放攻击。DH–IA方案可有效防止恶意攻击者伪造身份的中间人攻击和重放攻击行为。

2）同类方案中用户一般采用真实身份发送匹配消息，因此恶意攻击者可以通过用户行为分析和暴力破解等技术，获取用户的信息之后能较准确地进行身份比对。DH–IA方案中，恶意攻击者无法获取用户身份信息。

3）同类方案中可信服务器被认为是“绝对可信”，掌握所有用户参与匹配的隐私属性信息的详细细节，存在着可信服务器被攻破或与恶意攻击者共谋的重大风险。DH–IA方案中，在保证可比较的前提下，使得用户隐私属性信息在可信服务器中依然处于加密状态，使得即便可信服务器出现一定的泄露风险，依然能保证用户隐私属性信息的安全。

5 性能评估

所有实验运行在一台具有2.4 GHz Intel CPU、4 GB内存、操作系统为Windows 8的PC上。模拟实验在Java环境下应用MyEclipse平台实现；实验数据集利用Brinkhoff提供的移动对象生成器。在DH–IA方案中，用户身份认证时采用的是判定性双线性迪菲–赫尔曼（decisional bilinear Diffie–Hellman，DBDH）机制；用户兴趣点属性值的隐藏采用不可逆的安全散列算法（secure hash algorithm，SHA）中的SHA1机制；密钥协商应用RSA加密算法；密钥长度为512位。模拟实验中应用开源密码算法库jPBC来实现以上算法。

目前，移动社交网络中社交发现的隐私保护的主要方案有Fine-grained^[3]、WAS^[12]等方法。为了便于与上述方案进行性能比较，设定每次实验都具有相同数目的虚拟用户，共生成1 000名实时在线用户同时参与朋友匹配；在不同实验中每个用户设定兴趣点属性总数也是固定的，变化范围为{10，20，30，40，50}。下面就每一种方案自身的保护机制，分别给出其时间开销如图5所示和通信开销如图6所示，两方面的情况进行对比。

由图5可见，在一个1 000人同时进行社交发现服务的高密度模拟环境中，本方案的时间开销最小。这是因为本方案（DH–IA）设计中，最大的时间消耗是使用512位密钥进行的加解密计算，其余计算采用的是复杂度较低的哈希运算和异或运算，相比于其他两个方案中，分别需要进行多次的512位和1 024位的求幂操作，显然更具优势。值得注意的是，本方案由于要对用户每个具体属性值进行逐一处理，增长幅度受属性值总数影响比较明显。由于在实际使用中，用户设定的兴趣点属性总数并不会太多，所以影响在可控范围之内。

由图6可见，在上述高密度模拟实验对比中，本方案的通信开销最小。这是因为本方案的用户属性是由向量表示，每一个属性都具体转化成一个数值，本身并不需要花费多大空间。本方案在运行中用户和服务器不需要频繁的交互数据，只需要服务器返回匹配是否成功的简单结果，这都使得本方案比同类方案^[3,12]在通信开销上有着很明显的优势。

6 结　论

本文提出了一种基于判定性D–H密钥协商和身份匿名技术的社交发现隐私保护方案。首先，系统对用户身份进行真伪认证；查询用户与响应用户通过身份认证后，开始进行属性匹配。用户属性哈希值集由基于查询用户随机选定的不可逆哈希函数与随机数生成，服务器负责计算所有响应用户与查询用户的属性哈希值集匹配值，根据值的大小向查询用户推荐好友。安全性分析表明，本方案能够防止“好奇的”服务器与用户获取其他查询用户的属性信息，能够抵御恶意攻击者的中间人攻击、重放攻击和伪造身份等多种攻击，有效地实现对用户身份和个人资料的隐私保护。性能测试实验表明，该方案提高了移动社交网络中潜在社会关系推荐的效率，使得有共同兴趣爱好的用户能够更快捷地匹配成功。本方案仍有需要持续改进的地方，例如：由于用户端使用加解密的方式，因此在计算开销上依然还有进一步降低的空间。在下一步工作中，将考虑引入权重计算的匹配方案，从而获得更准确的用户兴趣匹配结果。