CN104168563A - 一种基于本地信誉存储的k-匿名激励机制 - Google Patents

Abstract

本发明公开了一种基于本地信誉存储的K-匿名激励机制，当用户请求需要隐私保护的LBS时，以广播的形式向附近用户发出参与形成匿名区的请求，通过返回的消息获得服务提供者列表；通过第三方云服务器，双方向对方发送新生成的信誉证书并取得验证，并由服务提供者验证服务请求者的所有的旧证书；验证全部通过后，匿名区形成；查询服务结束后，双方互相进行评价，将接收的对方的信誉证书附上自身公钥并签名后发回给对方保存，从而达到信誉值的累积。本发明基于分布式K-匿名引入了激励机制，将每个节点的信誉以信誉证书的形式保存在本地，通过为邻居节点提供匿名服务获得信誉并不断累积，在以后的交易中，节点只有达到了一定的信誉阈值才能获得匿名服务。

Description

一种基于本地信誉存储的K-匿名激励机制

技术领域

本发明涉及一种通信技术，具体涉及一种基于本地信誉存储的K-匿名激励机制。

背景技术

随着带有定位服务的移动电子设备的爆炸式增长，LBS(LocationBased Service，基于位置的服务)变得越来越流行。其中较为成功的案例有Foursquare，Google Latitude，Where等。基于位置服务(LBS)即是基于移动设备的地理位置信息而提供的一种信息和娱乐等服务。以其中最为流行的Foursquare为例，用户可以通过提供自己当前的位置，以签到的方式获得商家提供的优惠券或者游戏奖励等。调查资料显示，在18岁以上的成人用户中74％的智能手机用户通过手机获得LBS服务。然而，在该技术的广泛应用给人们的生活带来便利的同时，人们的位置隐私信息也面临着前所未有的威胁。例如，当一个用户经常查询距离自己最近的医院时，该用户可能泄露了自己的健康状况信息，当一个用户经常查询某条线路上的商家信息时，该用户可能泄露了自己的行为轨迹信息等等。

为了应对这些挑战，许多学者在基于位置服务的隐私保护方面做了大量研究，其中K-匿名技术——将用户的精确位置扩展为包含其它K-1个用户的匿名区域，以包含K个用户的匿名区域发起LBS请求，是LBS中实现用户位置隐私保护的一项重要技术，其中主要可分为基于可信第三方(TTP)的集中式K-匿名方案和无可信第三方的分布式K-匿名方案。本文主要关注的分布式K-匿名是LBS请求者与附近其他K-1个真实用户交互，共同形成匿名区。然而，通过Iachello等人的调查发现，人们在使用某些不涉及敏感信息的LBS服务时很少关心他们的隐私问题，而在某些特定场合请求LBS服务时又会要求保护隐私。Krumm的调查结果显示，有接近80％的用户有些时候并不在意他们的GPS位置数据。加之当用户不需要LBS隐私保护但却加入到匿名组中时意味着需要与LBS请求者进行信息交互，为其提供匿名保护，从而消耗资源却得不到任何利益。这使得这些用户不需要隐私保护时并不会为其他用户提供服务，同理这些用户希望保护隐私时其他节点亦不会为这些用户提供服务，因此形成恶性循环。使得迄今为止的众多研究成果都无法在实际环境中得以实现。

激励机制在各个领域都有着广泛的应用，针对P2P网络近年来国内外相关学者做了大量研究。根据核心思想划分，激励机制大致分为：基于直接互惠、基于微支付以及基于信誉三种激励模型。

目前，文献“Truthful Incentive Mechanisms for K-AnonymityLocation Privacy”将基于直接互惠的激励机制引入到了LBS场景中，该机制的基本思想是：网络中提供服务的节点在为其他节点提供服务后能得到某种直接的利益、优惠等。该文献借鉴Levin D等人提出的拍卖模型提出的方案是首次且唯一将基于互惠的激励机制引入LBS隐私保护的方案，该方案的最大优点是实时性高，仅保存节点当前会话信息，只考虑本次交易直接互惠。然而由于其不考虑两次交易的关联，因此仅适合单次交易持续时间长、交易双方相对固定场合应用。在LBS中，节点频繁移动，并不存在相对固定且持续交易的节点，因此该机制并不适合在LBS场景下应用，可见该文献将该机制引入LBS隐私保护有待改进。

基于微支付的激励机制作为网络中一种可靠的机制激励在P2P网络中得到了一定的应用。根据网络中各节点不同的贡献值进行不同的反馈，从而激励节点积极参与网络合作。Golle等人最早将该思想引入到网络中，运用博弈论方法分析证明了该机制对网络激励的有效性。然而该机制需要一个中央服务器负责虚拟货币的发行、分配以及流通，因此存在服务器性能以及安全瓶颈问题，可行性较差。不适于LBS场景中的应用。目前也没有将微支付应用于LBS隐私保护方面的研究。

基于信誉值的激励机制最早应用是在P2P文件共享系统KaZaA中，其基本思想是：节点根据自身的历史行为获取历史信誉值，交易完成后，交易双方通过互相评价的方式获得新的信誉值，在以后交易中，节点间通过信誉值高低给予不同服务，从而促进用户积极参与交易，累计信誉值。由此可见，基于信誉的激励机制适用于网络规模较大、节点动态性较强、节点间重复交易不频繁的应用环境，而且可累计信誉的特点正好契合LBS下节点频繁移动的场景，该机制目前研究热点主要集中在信誉存储及获取方式方面。

发明内容

针对现有技术的不足，本发明将基于信誉值的激励机制引入LBS位置隐私保护中，提出一种基于本地信誉存储的K-匿名激励机制。用户每次交易产生的信誉信息会以证书的形式保存在本地，由客户端自行维护和更新。每次交易前LBS请求发起者将自己的信誉证书交由其他用户验证完整性，通过引入半可信的第三方云服务器，确保了信誉证书的连续性。提供服务的用户仅通过该用户和云服务器就可以得到其他用户对该用户的全面的评价信息。

为了达到上述目的，本发明采取如下技术方案：

一种基于本地信誉存储的K-匿名激励机制具体包括如下实施步骤：

步骤1，服务请求者发起基于位置服务查询，并向周围其它节点请求形成K-匿名组；

步骤2，所述服务请求者通过返回的信息获得有意愿加入K-匿名组的用户列表，其中，有意愿加入K-匿名组的用户称为服务提供者；

步骤3，所述服务请求者为本次交易生成一个新的信誉证书，所述新的信誉证书中包含本次交易号；所述服务请求者用自身私钥签名所述新的信誉证书后连同证书头直接发送给所述服务提供者，同时还将签名后的新的信誉证书连同证书头通过第三方云服务器再转发一次给所述服务提供者；

步骤4，所述服务提供者同样为本次交易生成一个包含本次交易号的新的信誉证书，并生成一个随机数Nonce作为挑战，然后将随机数Nonce连同新的信誉证书以及证书头用自身私钥签名后一并直接发送给服务请求者，同时还将已签名的新的信誉证书和证书头通过所述第三方云服务器转发给所述服务请求者，此次转发中不包含随机数Nonce；

步骤5，所述服务请求者和服务提供者分别对由对方直接发送和所述第三方云服务器转发的两个信誉证书中的交易号进行比较验证；

需要说明的是，交易双方均需要相互验证，实现对对方的信誉证书的完整性验证。如果任何一方在验证的过程中发现对方是不可靠的，都可以通知对方及第三方云服务器终止协议。

步骤6，验证通过后，所述服务请求者将其存储的所有旧证书连同Nonce应答一并签名并发送给所述服务提供者；与此同时，所述服务请求者将之前接收的服务提供者的新的信誉证书附上自身公钥并签名发给第三方云服务器，由第三方云服务器暂存；

步骤7，所述服务请求者首先验证Nonce应答，再对旧证书进行验证；验证通过后，所述服务提供者清点所述服务请求者所有旧证书中的角色标志位，计算服务请求者的信誉值；符合加入条件的，服务提供者将之前接收的服务请求者的新的信誉证书附上自身公钥并签名后发给所述第三方云服务器暂存；

步骤8，服务提供者加入服务请求者的K-匿名组形成并完成所述服务请求者发起的基于位置服务查询；

步骤9，基于位置服务查询完毕后，双方互相评价该次交易，所述第三方云服务器将其所存的相应节点最近一次交易的交易号加一，并将暂存双方的新的信誉证书分别发送至相应的一方，由交易双方自行保存在旧证书库，从而达到信誉值的累积。

需要说明的是，所述机制有如下假设：服务请求者和服务提供者均不可信，并且服务请求者和服务提供者可能共谋攻击；所述第三方云服务器为半可信，即所述第三方云服务器会忠实执行所述机制但其会对用户的隐私内容感兴趣。

需要说明的是，所述证书头的格式包括节点公钥证书PKC和第一个交易号的前驱号TID₀：所述证书头包括节点的基本信息，每个节点拥有唯一的公私钥对PK和SK，用于信誉证书的签名和验证；所述公私钥对向可信的证书颁发机构CA申请，代表了节点的唯一身份，因为各个节点的公钥是不同的，所以不同节点不同次交易的的交易号是不同的。私钥SK由节点本地私密存储，公钥PK以公钥证书PKC的形式包含在证书头中；除了公钥证书PKC之外，所述证书头还包含一个字段：节点第一个交易号TID₁的前驱号TID₀，所述前驱号TID₀的作用为防止节点恶意删除本地存储的信誉证书；

需要说明的是，所述信誉证书包含每次交易的信息，节点每进行一次交易生成一个信誉证书，其中包含该次交易的交易号TID_n、角色标志位RF、节点自身对所述该次交易的交易号TID_n和角色标志位RF的签名signature₁、交易对方公钥PK以及对方的签名signature₂；所述角色标志位RF代表节点在该次交易中的角色为服务请求者或服务提供者，所述对方的签名signature₂由交易对方在验证完旧证书队列准备开始基于位置服务交互前完成。

进一步需要说明的是，所述交易号TID_n由两部分组成：前缀prefix(TID_n)和后缀postfix(TID_n)，所述前缀prefix(TID_n)由节点的公钥PK哈希产生prefix(TID_n)＝Hash(PK)，所述后缀postfix(TID_n)由系统生成连续的编码。

进一步需要说明的是，当所述角色标志位所代表的是服务请求者时，其值设置为1；当所述角色标志位所代表的是服务提供者时，其值设置为0。

需要说明的是，在步骤3和步骤4中，所述第三方云服务器存储有每个节点的最近一次交易的交易号值，当所述服务请求者和服务提供者通过所述第三方云服务器转发其新的信誉证书给对方时，所述第三方云服务器会先确认新的信誉证书中的交易号是否为相应节点最近一次交易的交易号加一，确认后再进行转发。

需要说明的是，所述步骤7中，所述服务提供者清点所述服务请求者所有旧证书中的角色标志位，根据下式计算并判断信誉值D_C是否满足加入条件：

其中，∑(RF＝0)为所述服务请求者的所有旧证书中角色标志位为服务提供者的总次数，∑(RF＝1)为所述服务请求者的所有旧证书中角色标志位为服务请求者的总次数，而则是考虑到服务请求者有可能是首次接入服务的情况所作出的修正；当所述服务提供者验证所述服务请求者的角色标志位比值达到提供服务的阈值λ时，所述服务提供者加入所述服务请求者的K-匿名组。

本发明的有益效果在于：

1、将基于信誉的激励机制引入K-匿名中，增加了用户参与到K-匿名集合中的积极性，并且信誉多次交易可累计，达到了持续激励的效果，使广泛研究的基于分布式K-匿名的LBS保护方案切实可用，并通过限制为低信誉用户提供匿名服务，避免了搭便车行为；

2、能够抵抗伪装、重放、共谋等各种典型攻击，且需借助半可信第三方云服务器即可完成工作，其中云服务所需完成的工作量很小，并且不涉及任何用户隐私，避免了可信第三方带来的性能瓶颈及安全问题，提高了匿名系统的整体性能和隐私水平。

附图说明

图1为本发明的系统模型示意图；

图2为本发明交互过程的示意图；

图3为本地循环队列结构存储的信誉证书示意图；

图4为可行性实验的拓扑示意图；

图5为可行性实验中不同的K值对应的十次匿名区形成时间；

图6为可行性实验中服务请求节点的额外通信量示意图；

图7为可行性实验中服务提供节点的额外通信量示意图；

图8为可行性实验中第三方云服务器的额外通信量示意图；

图9为可行性实验中通信量与本地信誉证书的个数的大小关系。

具体实施方式

以下将结合附图对本发明作进一步的描述，需要说明的是，本实施例以本技术方案为前提，给出了详细的实施方式和实施步骤，但并不限于本实施例。

本机制中，包含了服务请求者C、服务提供者S和半可信第三方云服务器Cloud，三者的所构成的模型如图1所示。

如图2所示，所述一种基于本地信誉存储的K-匿名激励机制的交互过程如下：

服务请求者C即将发起一次LBS查询，并向周围其他节点请求形成K-匿名组，记C即将进行第n+1次交易，服务提供者S即将进行第m+1次交易。交易过程的协议符号说明如下(以服务请求者C为例，其中＝为定义，||为连接符)：

证书头：RCH_C＝PKC_C||TID_C,0；

旧证书队列(前n次交易的证书)：RC_C-Old队列＝RC_C,1||RC_C,2||...||RC_C,n；

为第n+1次交易生成的新的信誉证书：

${\mathrm{RC}}_{C-\mathrm{New},n+1}={\mathrm{TID}}_{C,n+1}\left|\right|{\mathrm{RF}}_{C,n+1}\left|\right|{\mathrm{Sign}}_{{\mathrm{SK}}_C}\left({\mathrm{TID}}_{C,n+1}\right|\left|{\mathrm{RF}}_{C,n+1}\right);;$

第n+1次交易成功后保存在本地的证书：

${\mathrm{RC}}_{C,n+1}={\mathrm{RC}}_{C-\mathrm{New},n+1}\left|\right|{\mathrm{PK}}_S\left|\right|{\mathrm{Sign}}_{{\mathrm{SK}}_S}\left({\mathrm{RC}}_{C-\mathrm{New},n+1}\right|\left|{\mathrm{PK}}_S\right);$

对于服务请求者节点C

当C请求服务时，首先以广播的形式向周围用户发起查询请求，获得有意愿加入匿名组的用户集。C生成一个新的信誉证书RC_C-new,n+1准备进行第n+1次交易，其中本次交易号TID_C,n+1是本次交易的唯一标识，交易号由两部分组成：前缀prefix(TID_C,n+1)由节点的公钥PK_C哈希产生，prefix(TID_C,n+1)＝Hash(PK_C)，后缀postfix(TID_C,n+1)由系统生成连续的编码。角色标志位RF_C,n+1为服务请求者，其值设置为1。

为保证本地存储的信誉证书的可靠性与机制的健壮性，交易号的连续性是需要着重考虑的一个问题。为此，半可信第三方云服务器Cloud，为每个节点存储一个最近一次交易的交易号，因为各个节点的公钥是不同的，所以不同节点不同次交易的交易号是不同的。C将证书头RCH_C连同用自身私钥签名的新信誉证书RC_C-new,n+1一起直接发送给S，该证书头及签名后的新的信誉证书同时经过Cloud转发，由Cloud验证证书中的TID_C,n+1是否是当前存储的最近一次交易的交易号加一，确认后转发给S端。

对于服务节点S：

如果S接受C的请求，S同样生成一个新的信誉证书RC_S-new,m+1准备进行第m+1次交易；角色标志位RF_S,m+1为服务提供者，其值设为0；另外，S还生成一个随机数Nonce。S将随机数Nonce连同新的信誉证书RC_S-new,m+1以及证书头RCH_S一起用自身私钥签名后形成{RCH_S‖RC_S-New,m+1‖Nonce}sig_S直接发送给C，同时亦将该证书头及新证书RCH_S‖RC_S-new,m+1通过第三方云服务器Cloud转发一次，同样地，第三方云服务器Cloud将对新的信誉证书RC_S-new,m+1进行验证，确认该证书中的本次交易号TID_S,m+1为Cloud所存储的该节点最近一次交易的交易号加一后，再转发给C。此次转发不包含所述随机数Nonce。

C和S均会对收到的两个新的信誉证书中本次交易号进行比较验证；双方均验证通过后，C会应S的要求将其存储的所有旧证书连同Nonce应答一并签名形成{RC_C-Old队列‖Nonce}sig_C发送给S；与此同时，C将之前接收的S的新的信誉证书附上自身公钥并签名形成RC_S,m+1发给第三方云服务器，由第三方云服务器暂存；

S收到C发来的旧证书后，首先验证Nonce应答，再对旧证书采用批验证的方式一次性对所有旧证书的合法性进行验证；验证通过后，服务提供者将之前接收的服务请求者的新的信誉证书附上自身公钥并签名后形成RC_C,n+1发给所述第三方云服务器暂存；

以上所有验证通过后，S清点C所有旧证书中的角色标志位，计算信誉值D_C：

但是考虑到当C初次接入本服务时，本地存储的旧证书为0，这样上式就不再适用的情况，受贝叶斯理论启发，将上式修正为如下形式，S根据下式计算并判断C的信誉值D_C是否满足加入条件：

当S验证C的角色标志位比值达到提供服务的阈值λ时，S加入C的K-匿名组。

当此次LBS查询结束后，C、S针对本次交易进行评价，Cloud将其所存储的相应节点最近一次交易的交易号加一，并将暂存的信誉证书RC_C,n+1和RC_S,m+1分别发送给所述服务请求者和所述服务提供者自行保存在本地的旧证书库，本次交易结束。

以下将进行对本机制的安全性分析和实现分析。

安全性分析：

所述机制的每次交易中的实体共三种：服务请求者C与服务提供者S均不要求可信，并且C与S可能共谋，第三方云服务器Cloud为半可信。针对来自不同实体的攻击，所述机制的应对策略如下：

一、参与三方单方面攻击的情形：

(1)当攻击者为C时，C通过删除自身的请求服务的信誉证书删除自己不良信誉。本机制中，在第三方云服务器存储有每个节点最近一次交易的交易号，每次交易前，C需先将新的信誉证书发送给第三方云服务器，由第三方云服务器比较其存储的C的最近一次交易的交易号和新证书中的交易号的连续性。一次交易完成后，第三方云服务器将C最近一次交易的交易号增一。通过交易号的连续性可以检测出C的信誉证书完整性，并且信誉证书中有交易双方的签名，通过验证签名也可以检测出C的信誉证书是否存在修改的现象。

当攻击者为服务提供者节点S时，服务提供者节点通过伪造节点提供服务的证书的方式增加自身提供服务的次数。本机制采用信誉证书，由于每个节点的公钥证书由CA颁发，公钥是无法伪造的，通过验证信誉证书上交易双方签名，可以有效防止伪造证书情况的发生。

二、参与三方任意两方共谋攻击的情形：

由于在方案中假设第三方云服务器Cloud能够忠实执行方案，因此两方共谋攻击为C和S的共谋。当服务请求者节点C与服务提供者节点S共谋攻击时，双方通过一方帮助另一方伪造提供服务证书的方式达到双方互利的目的。本机制中引入第三方云服务器保证交易号的连续性后，若一方为服务提供者节点，另一方为服务请求者节点，则在交易完成后，服务提供者节点的提供服务次数增一，服务请求者节点的享用服务次数增一。即不可能出现互利现象，一方的盈利必然建立在一方利益受损的基础之上。因此，鉴于付出代价的问题，本机制中不会出现节点间的共谋攻击。

三、重放攻击：

由于云端存储了每个节点最近一次交易的交易号，因此防治了攻击者重放一次完整的交易而发起重放攻击。为了防止攻击者窃听交易开始之后、交易号增加之前的消息并截获递增交易号及之后的消息的重放攻击，将挑战应答机制引入其中，确保了消息的新鲜性，有效的抵抗了重放攻击。

四、搭便车行为：

为了防治恶意节点的搭便车行为，即请求其他节点为自己提供服务后而抵赖的行为，在形成匿名组之前即将双方信誉证书签名并暂存在Cloud中，LBS服务结束后，由C节点向Cloud发送确认消息，之后Cloud再将信誉证书转发给对方，这样就有效遏制了节点在接受完服务后拒绝签名的搭便车行为。

本机制通过证书的方式，交易双方互相签名验证防止了伪装攻击；引入挑战应答机制防止了重放攻击；并通过半可信第三方云服务器的协助确保交易号的连续性，防止了共谋攻击、持续激励效果更佳显著，安全性更高，是一种更加适合无线移动环境下LBS隐私保护场景的激励机制方案。

实现分析：

一、本地历史信誉存储：

由于本机制中采用的是本地自行维护更新信誉证书的方式管理自身信誉值，因此证书的维护是需要重点考虑的问题。本机制中采用循环队列存储证书，队列中包含证书头和证书体，证书体为每次交易所产生的信誉证书。队列长度N固定。当队列未满时，存储如图3(a)所示，节点通过验证TID₀到TID_n的连续性确保信誉证书的完整性；当队列已满时，存储如图3(b)所示，根据循环队列FIFO的特点，依次删除最先进入队列的证书，当节点验证旧证书时，若证书个数达到了队列的最大值N时，仅需验证该N个证书中交易号的连续性，无需验证TID₀与最先进队的证书的交易号的连续性；若证书个数未达到队列最大值N时，需要验证TID₀以及所有证书中交易号的连续性，若TID₀与最先进队的证书的交易号不连续，亦可判断证书不完整。

二、历史旧信誉证书的批验证：

为了减少验证旧证书所需的时间和能量消耗，本机制中采用的是基于椭圆曲线的签名机制，既可在第一步中单个验证新证书中签名的有效性，又可在第二步中批验证不同用户的不同签名，从而达到一次性快速验证旧证书的目的。该算法批验证的速度与验证单个签名的速度在一个量级范围内，效率很高，并且该算法安全强度高。

选取椭圆曲线ed-25519，基点B≠(0,1)满足集合：

E＝{(x,y)∈F_q×F_q:-x²+y²＝1+dx²y²}；

且lB＝0，其中F_q为椭圆曲线域，非平方数由Edwards加法定律可以得知，集合E形成包含0＝(0,1)的组，本机制采用将数据编码的方式压缩数据。节点的私钥为b比特字符串k，计算公钥A(A压缩后记为A)的过程如下所示：

H(k)＝(h₀,h₁,...,h_2b-1)；

$a=2^{b-2}+\underset{3\≤i\≤b-3}{\mathrm{\Σ}}{2}^i{h}_i\∈\{2^{b-2},2^{b-2}+8,...,2^{b-1}-8\};$

A＝aB；

其中，H(k)表示关于私钥k的哈希函数。

节点需要进行签名的消息为M，签名sig计算过程如下式所示：

r＝H(h_b,...,h_2b-1,M)；

R＝rB；

S＝(r+H(R,A,M)a)modl；

sig＝(R,S)；

h_b,...,h_2b-1为私钥哈希之后的b到2b-1位，sig＝(R,S)表示签名sig等于R和S压缩后连接而成的字符串。

当服务提供者节点与服务请求者节点收到对方的新证书时，验证证书的有效性，此时为单个证书的验证，只需若验证下式成立，则签名验证通过：

R＝SB-H(R,A,M)A；

当服务提供者节点收到服务请求者节点的旧证书时，批验证所有旧证书是否成立，只需验证下式是否成立：若下式成立，则所有旧证书全部验证通过：

H_i＝H(R _i,A _i,M_i)

$(-\underset{i}{\mathrm{\Σ}}{z}_i{S}_i\mathrm{mod}l)B+\underset{i}{\mathrm{\Σ}}{z}_i{R}_i+\underset{i}{\mathrm{\Σ}}\left(z_i{H}_i\mathrm{mod}l\right)A_i=0;$

其中z_i为随机数。

现对本机制的可行性进行实验分析：

一、实验硬件及环境

实验中三类节点C、S、Cloud均采用了相同的硬件配置：HP台式机(3.00GHz Core(TM)2 Duo CPU和2.00G内存)，配备了TP-LINKTL-WN822N Ver:2.0高增益802.11N无线USB网卡，搭载了MicrosoftWindows7 32位Service Pack 1旗舰版操作系统。在Cloud节点的无线网卡设置模拟虚拟AP，C、S及Cloud均与AP连接形成无线局域网环境。本方案实验代码均采用C/C++语言编写。

实验中为了实现多用户，采用多线程编程，在S端虚拟出K-1个提供服务的节点，三类节点通过同一个AP连接，采用的拓扑图如图4所示，图4中节点均为上述配置的搭载了无线网卡的HP台式机。

实验中所用签名验证算法Ed25519-SHA-512，各参数设置如下：b＝256，H为散列算法SHA-512，q为素数2²⁵⁵-19，255比特的F_q为小端编码的{0,1,…,2²⁵⁵-20}，d＝-121665/121666∈F_q，素数l^[21]＝2²⁵²+27742317777372353535851937790883648493，B＝(x,4/5)∈E，其中x>0，椭圆曲线在域F_q中方程为：V²＝u³+486662u²+u。

二、实验数据及性能分析

(1)形成匿名区的时间分析：

在搭建的Wi-Fi环境下，首先变换需要形成的不同的匿名组大小K值，调节K值分别为5、10、20、30以及40，经过大量实验，在C端，用RawCap抓取通数据包，用Wireshark分析获得的数据，从每个不同的K值情况下分别随机选取10组实验数据，获得的数据情况如图5所示，每条折线代表不同K值情况下10次不同的实验得到的匿名区形成时间。由图5可见不同的K值情况下时间T基本维持在某个固定值。通过计算不同K值情况下10次形成匿名区的时间的平均值，得到的形成不同大小匿名区的时间如表1所示。

表1

表1给出了匿名区的平均形成时间随K值增长的关系，由此可见，随着需要形成的K-匿名集合大小的增长，形成K-匿名组时间T总体成缓慢增长趋势。

(2)形成匿名区的通信量分析：

通过Wireshark对抓取的网络数据包进行分析，得到C、S以及Cloud端网络通信对流量消耗的数据分析。其中各端均为测量10次后取均值后的值。

对于服务请求节点C，得到的数据如图6所示，从图6(a)中可以看出，针对不同K值大小的匿名组，服务请求节点的通信量随着本地存储信誉证书的个数N值的增加呈现单调递增的趋势。当N值的大小固定时，如图6(b)所示，服务请求节点的通信量随着需要形成的K-匿名组的大小的递增亦呈现单调递增的趋势。

对于服务提供节点S，得到的数据如图7所示，从图7(a)中可以看出，针对不同K值大小的匿名组，服务提供节点的通信量随着本地信誉证书的个数N值的增加呈现单调递增的趋势。从图7(b)可以看出，当固定N值的大小，服务提供节点的通信量随着需要形成的K-匿名组的大小的递增而处于恒定的状态，即服务提供节点的通信量不随着匿名组的大小K值发生变化，仅与本地存储的信誉证书的个数有关。

对于第三方云服务器Cloud，得到的数据如图8所示，从图8(a)可以看出，针对不同K值大小的匿名组，Cloud端的通信量随着本地存储信誉证书的个数N的递增处于一个恒定的值，即第三方云服务器的通信量不随着本地信誉证书的个数N值的变化发生变化。从图8(b)中可以得出，当本地证书的数量N值固定时，Cloud端的通信量随匿名组大小K值增大呈单调递增趋势。

通过以上对大量实验数据的分析可知，本方案引入的存储在本地的信誉证书的个数N值会对形成K-匿名集的通信量产生影响，随着N值的增大，C端和S端的通信量都会增加，但同时N值越大越能完整的反应节点的信誉信息。同时，由于本方案采用的验证旧证书的方式是基于椭圆曲线的批验证，因此，N值对形成匿名集的时间几乎没有影响，时间的消耗大多为通信消耗。所以，以下主要讨论如何选取N值使形成匿名组时的通信量和N值达到平衡。

由以上分析知，当K值为40时——该值为K-匿名的一个较大匿名组的值，形成匿名集的时间约为4.92秒，假定为能容忍的最大时延。当形成包含40个用户的匿名集时，C端、S端以及Cloud端，三端分别的通信量与N值的大小关系如图9所示。

Cloud端消耗的流量与N值大小无关，C与S端消耗的流量均与N值大小成正比，三端对于N值的不同而消耗的流量如表2所示。

表2

当N值为100时，C端消耗流量55.48KB，S端消耗21.86KB，Cloud端消耗14.10KB，为可接受范围，因此，本方案选定本地存储旧证书最大值N为100，当产生的旧证书数量大于100时，循环删除最早的旧证书，只保留100个旧证书。

通过实验数据分析，本方案选取本地存储最大旧证书个数为100个，当形成的匿名集合K的大小为40时，形成匿名集的时间为4.92秒，形成匿名区的时间随用户数量增加增长趋势缓慢且总体较低。并且本方案引入的额外通信量很少：请求匿名服务节点消耗的流量为55.48KB，提供匿名服务的节点消耗的流量为21.86KB。云服务节点消耗为14.10KB，且云服务器仅需比较新证书中的交易号与上次交易号的连续性，计算量很小。

对于本领域的技术人员来说，可以根据以上的技术方案和构思，给出各种相应的改变和变形，而所有的这里改变和变形都应该包括在本发明权利要求的保护范围之内。

Claims (8)

1.一种基于本地信誉存储的K-匿名激励机制，其特征在于，所述机制具体包括如下实施步骤：

步骤1，服务请求者发起基于位置服务查询，并向周围其它节点请求形成K-匿名组；

步骤2，所述服务请求者通过返回的信息获得有意愿加入K-匿名组的用户列表，其中有意愿加入K-匿名组的用户称为服务提供者；

步骤3，所述服务请求者为本次交易生成一个新的信誉证书，所述新的信誉证书中包含本次交易号；所述服务请求者用自身私钥将新的信誉证书签名后连同证书头直接发送给所述服务提供者，同时还通过第三方云服务器向所述服务提供者再转发一次；

步骤4，所述服务提供者同样为本次交易生成一个包含本次交易号的新的信誉证书，并生成一个随机数Nonce作为挑战，然后将随机数Nonce连同新的信誉证书以及证书头用自身私钥签名后一并直接发送给服务请求者，同时通过所述第三方云服务器将签名后的新的信誉证书连同证书头再转发一次给所述服务请求者，这次转发中不包含随机数Nonce；

步骤5，所述服务请求者和服务提供者分别对由对方直接发送和所述第三方云服务器转发的两个信誉证书中的本次交易号进行比较验证；

步骤6，验证通过后，所述服务请求者将其存储的所有旧证书并连同Nonce应答一并签名发送给所述服务提供者；与此同时，所述服务请求者将之前接收的服务提供者的新的信誉证书附上自身公钥并签名发给第三方云服务器，由第三方云服务器暂存；

步骤7，所述服务提供者首先验证Nonce应答，再对旧证书进行验证；验证通过后，所述服务提供者清点所述服务请求者所有旧证书中的角色标志位，计算其信誉值；所述服务请求者的信誉值符合条件的，服务提供者将之前接收的服务请求者的新的信誉证书附上自身公钥并签名后发给所述第三方云服务器暂存；

步骤8，服务提供者加入服务请求者的K-匿名组并完成服务请求者发起的基于位置服务查询；

步骤9，基于位置服务查询完毕后，双方互相评价该次交易，所述第三方云服务器将其所存储的相应节点最近一次交易的交易号加一，并将暂存双方的新的信誉证书分别发送至相应的一方，由交易双方自行保存在旧证书库，从而达到信誉值的累积。

2.根据权利要求1所述的一种基于本地信誉存储的K-匿名激励机制，其特征在于，所述机制有如下假设：服务请求者和服务提供者均不可信，并且服务请求者和服务提供者可能共谋攻击；所述第三方云服务器为半可信，即所述第三方云服务器会忠实执行所述机制但其会对用户的隐私内容感兴趣。

3.根据权利要求1所述的一种基于本地信誉存储的K-匿名激励机制，其特征在于，所述证书头的格式包括节点公钥证书PKC和第一个交易号的前驱号TID₀：所述证书头包括节点的基本信息，每个节点拥有唯一的公私钥对PK和SK，用于信誉证书的签名和验证；所述公私钥对向可信的证书颁发机构CA申请，代表了节点的唯一身份；私钥SK由节点本地私密存储，公钥PK以公钥证书PKC的形式包含在证书头中；除了公钥证书PKC之外，所述证书头还包含一个字段：节点第一个交易号TID₁的前驱号TID₀，所述前驱号TID₀的作用为防止节点恶意删除本地存储的信誉证书。

4.根据权利要求1所述的一种基于本地信誉存储的K-匿名激励机制，其特征在于，所述信誉证书包含每次交易的信息，节点每进行一次交易生成一个信誉证书，其中包含该次交易的交易号TID_n、角色标志位RF、节点自身对所述该次交易的交易号TID_n和角色标志位RF的签名signature₁、交易对方公钥PK以及对方的签名signature₂；所述角色标志位RF代表节点在该次交易中为服务请求者或者服务提供者，所述对方的签名signature₂由交易对方在验证完旧证书队列准备开始基于位置服务交互前完成。

5.根据权利要求4所述的一种基于本地信誉存储的K-匿名激励机制，其特征在于，所述交易号TID_n由两部分组成：前缀prefix(TID_n)和后缀postfix(TID_n)，所述前缀prefix(TID_n)由节点的公钥PK哈希产生，prefix(TID_n)＝Hash(PK)，所述后缀postfix(TID_n)由系统生成连续的编码。

6.根据权利要求4所述的一种基于本地信誉存储的K-匿名激励机制，其特征在于，当所述角色标志位所代表的是服务请求者时，其值设置为1；当所述角色标志位所代表的是服务提供者时，其值设置为0。

7.根据权利要求1所述的一种基于本地信誉存储的K-匿名激励机制，其特征在于，所述第三方云服务器存储有每个节点的最近一次交易的交易号，在步骤3和步骤4中，当所述服务请求者和服务提供者通过所述第三方云服务器转发其新的信誉证书给对方时，所述第三方云服务器会先确认信誉证书中的交易号是否为相应节点最近一次交易号加一，确认后再进行转发；如果交易号验证失败，所述云服务器拒绝服务请求者的请求并通知服务提供者终止服务。

8.根据权利要求1所述的一种基于本地信誉存储的K-匿名激励机制，其特征在于，步骤7中，所述服务提供者清点所述服务请求者所有旧证书中的角色标志，根据下式计算并信誉值D_C是否满足加入条件：

其中，∑(RF＝0)为所述服务请求者的所有旧证书中角色标志位为服务提供者的总次数，∑(RF＝1)为所述服务请求者的所有旧证书中角色标志位为服务请求者的总次数，而则是考虑到服务请求者有可能是首次接入服务的情况所作出的修正；当所述服务提供者验证所述服务请求者的角色标志位比值达到提供服务的阈值λ时，所述服务提供者加入所述服务请求者的K-匿名组。