0 引言

近年来，随着滴滴、优步等网约车公司的迅猛发展，网约车用户数量剧增.借助网约车平台和智能手机，乘客打车、司机接单都更加方便，网约车在人们生活中扮演着越来越重要的角色^[1].与传统的出租车服务相比，网约车平台可更容易地收集到大规模数据，包括乘客的敏感信息如真实身份、出行位置和时间等.伴随着平台扩张，乘客的隐私泄露问题不断增多.

面向交通领域隐私保护的研究成果主要集中在公共交通.RFID (radio frequency identification)作为非接触的自动识别技术，被广泛地应用在交通领域.Heydt-Benjamin等^[2]针对公交系统提出了加密的RFID支付方案.Arfaoui等^[3]采用近场通信NFC(near field commucation)技术，设计了隐私保护的电子售票方案.Isern-Deya等^[4]设计了匿名的根据入站和出站口自动计算票价的检票系统.文献[2~4]是面向公共交通领域的隐私保护方案.当乘客选择公共交通出行时，如公交车、地铁、飞机等，对于在相同时段进入或离开相同地点的乘客，他们的位置是不可区分的，因此其隐私得到了保护.由于上车、下车地点比较单一，公共交通服务对于乘客具有位置混淆的特点.因此，该领域在隐私方面面临的挑战不是十分严峻.针对基于位置的服务，Troncoso^[5]提出收取车辆保险费的隐私方案，安全性依赖于车辆上安全设备的数据不可篡改.目前，针对网约车隐私保护研究较少，相较于传统的公共交通领域，网约车提供个性化服务，用户的位置隐私更加容易泄露，因此，其面临的隐私挑战更加严峻.Friginal等^[6]利用社交网络提出一种以用户为中心的分布式隐私保护解决方案，方案要求用户能够进行点对点通信.但是，点对点的通信方式与已有服务的通信框架不同，难以部署在现有平台上.Pham等^[7]给出隐私增强方案，司机与乘客借助于网约车平台建立安全通道，在该通道上交换数据，使乘客的身份和位置不可关联.文献[7]使用了电子现金，未提及电子现金可分，这意味着用户每次乘车都需要申请新的电子现金, 而且仅电子现金提取、建立安全通道两个阶段，方案就需要至少4次通信，其通信开销较大.

本文采用匿名电子现金和可认证的Hash链，设计了面向网约车服务的隐私保护方案，其主要特点是：1)电子现金具有可分性、份额不可重用性、不可伪造以及部分盲性，确保了支付的方便、安全、匿名; 2)改变现有第三方转账的支付模式为乘客支付电子现金，并结合Hash链节点的认证方法，确保支付时乘客身份、兑换时平台身份的可信性，乘客位置与身份的不可关联性; 3) Hash链验证是轻量级的计算，开销小，适合应用在智能手机中.同时，该方案的业务流程与已有服务的流程基本一致，可方便地部署在现有平台上.

1 安全模型 1.1 系统框架

为实现乘客匿名，采用电子现金支付，构建隐私增强的网约车服务框架，包括的实体如下：

1) 乘客(passenger, P)：乘客拥有智能手机并能访问网络.其身份、公钥、私钥、公钥证书分别是ID_P, PK_P, SK_P和Cert_P.

2) 司机(driver, D)：在任何时候，希望提供网约车服务的司机都必须在线，并将自己位置信息不断地发送给平台.其身份、公钥、私钥、公钥证书分别是ID_D, PK_D, SK_D, Cert_D.

3) 网约车平台(online transportation network platform, OTN)：乘客将请求信息、司机将位置信息发送给平台，平台进行匹配，把乘客附近车辆分配给他，并负责计算乘车费用等.其身份、公钥、私钥、公钥证书分别是ID_OTN, PK_OTN, SK_OTN和Cert_OTN.

4) 电子现金中心(e-cash authority, ECA)：ECA是电子现金的发放、转账、清算中心，银行可充当ECA.所有网约车用户在ECA上拥有账号，利用该账户可进行存钱、取现等操作.具体的，乘客在ECA上存钱购买并提取e-cash，司机、网约车平台与ECA进行清算、兑换电子现金.ECA的身份、公钥、私钥、公钥证书分别是ID_ECA, PK_ECA, SK_ECA和Cert_ECA.

基于电子现金交易的主要流程如图 1所示.

① 乘客先从ECA获取足够的电子现金.

② 乘客打车时，以匿名的方式，登陆OTN，将请求消息(上、下车地点)发送给OTN.OTN返回乘车价格给用户.乘客接受该价格，确认打车，发送少量电子现金作为定金；否则，退出应用.

③ OTN根据上车地点选择附近车辆，发送请求给司机，直到找到同意服务的司机为止.

④ OTN向乘客返回司机身份、电话号码、车牌号、可能到达时间等信息.

⑤ 乘客根据电话号码联系司机，根据车牌号确认司机.一旦上车，司机通知OTN，OTN开始计费.

⑥ 目的地到达，司机发送结束消息给OTN.

⑦ 根据实际的上下车地点、时间等，OTN计算扣除定金后的剩余费用发送给乘客.乘客确认后，支付电子现金，对司机服务进行评价.

⑧ 在电子现金的有效期限内，OTN将电子现金和对应司机身份发送给ECA，请求兑换.当通过检验，按照约定比例，ECA向OTN账号存管理费，向司机账号存服务费.

上述过程中，步骤②和步骤⑦的两次支付过程相似，只是金额不同，我们称之为支付协议.之所以采用两次支付，是为保护乘客的身份和交易的公平性.本方案中，OTN把司机电话号码发送给乘客，由乘客联系司机，保护了乘客隐私，但是，如果乘客一直没有联系司机，这对司机、OTN是不公平的.因此，在步骤2发送少量电子现金作为定金，如果乘客不联系司机，定金不返还，从某种程度上确保乘客执行后续步骤.

1.2 安全攻击

目前主流的网约车支付是由第三方支付平台从用户账户扣除费用，账号对应惟一标识.打车时平台将乘客电话号码发给司机，将司机电话号码发给乘客.这种支付模式下的网约车平台会发生以下安全威胁：1)平台掌握乘客和司机的身份、位置和电子现金账号等用户隐私，可能跟踪乘客、司机；从位置数据，平台能推断出更多的个人敏感信息，以获得自身更大的利润.2)外部攻击者可能窃听用户的通信，冒充用户进行消费，伪造位置信息，发布假消息等^{[8, 9]}.

1.3 安全需求

考虑到实际应用背景，我们假设平台是诚实的、好奇的，能够通过数据分析获得用户隐私.平台从自身企业发展角度上，不会发起主动攻击.因为司机要实时共享位置信息，接送乘客，参与利润分成，司机不匿名.

在本文的通信框架下，乘客与ECA、ECA与OTN、乘客与OTN、OTN与司机、司机与乘客之间都存在通信.当乘客从ECA提取电子现金以及向OTN请求服务时，他会担心自己身份和位置隐私的泄露.当乘客结算费用时，期望OTN能够提供方便、安全的支付方式.对于OTN，他担心乘客是否进行有效支付.对于司机，他担心自己的服务收益是否获得.对于ECA，他担心向他申请电子现金的用户是否可信，向他兑换电子现金的OTN是否可信.

因此，为抵抗已有的安全攻击，需要确保以下的安全需求：

1) 抗窃取.外部攻击者大规模收集乘客和司机的信息在计算上是不可行的.

2) 匿名.无论是ECA，还是OTN，推算乘客身份在计算上不可行.通过匿名，阻断ECA和OTN对乘客的位置跟踪.

3) 身份真实性.冒充合法用户申请e-cash，冒充合法乘客进行虚假支付，冒充合法OTN兑换电子现金，这些在计算上是不可行的.

4) 不可伪造性.无论是乘客、OTN，还是其他恶意用户，要伪造出电子现金，计算上不可行.

5) 不可关联性.无论是ECA，还是OTN，推断车程与乘客身份的关系在计算上不可行.

6) 可追责性.OTN能够在司机的协助下撤销违法乘客的匿名, 但撤销必须在一定条件下执行.

1.4 密码学原语

为保护隐私数据、认证数据的安全传输，消息需要加密和签名.考虑到智能手机是网约车服务的主要客户端，由于其资源受限，复杂算法和协议不适合.由于椭圆曲线密码在相同安全强度下，具有短密钥和出色的时间性能，因此选取有限域GF(p)上椭圆曲线E：y²=x³+ax+b mod p，满足4a³+27b²≠0 mod p. (p, a, b, q, G)为椭圆曲线E的公共参数，G为椭圆曲线上阶为q的点，E构成q阶循环群.在E上定义函数：Enc(PK, m)表示用公钥PK加密消息m；Dec(SK, c)表示用私钥SK解密密文c；Sign(SK, m)表示用私钥SK对消息m签名；Ver(PK, m, σ)表示用公钥PK对消息m的签名σ进行验证.进一步，考虑到低功耗的Hash函数具有单向免碰撞特点^[10]，定义Hash函数

2 乘客隐私增强方案

方案采用的电子现金由ECA颁发，可多次使用，具有可分的特点，通常电子现金的可分方案复杂度高、计算量大^[11]，我们采用可信Hash链构造电子现金，只要e-cash面额没有用完，即可继续使用，计算开销较小.

2.1 电子现金

首先选取随机数r_N, 计算r_N-1=H₁(r_N), r_N-2=H₁(r_N-1), …, r₁=H₁(r₂), r₀=H₁(r₁)，生成Hash链r_N→ r_N-1→r_N-2→…→r₁→r₀.

进一步构造电子现金，包含：Hash链根节点r₀、网约车平台标识ID_OTN、面额N、兑换截止日期T以及ECA对前面数据的签名.这里ID_OTN能防范乘客将电子现金支付给多个用户，以及非法商家窃取电子现金进行兑换.发行方签名能确保电子现金内容可信.

首次支付的凭证为e-cash ‖r_i‖i，其中r_i是与花销i对应的链节点，当满足生成规则H₁ⁱ(r_i)= r₀，则r_i为有效的链节点.再次支付的凭证为e-cash‖k‖r_j，其中j = i+ k，r_j为本次消费链节点，i为上次消费节点编号，当满足j≤N且H₁^j-i(r_j)= r_i，则r_j为有效链结点.特别当j=N，表明电子现金使用完毕. “‖”表示两个比特串的级联.

因而，一次有效的支付需满足：1)电子现金在有效期内，即支付时间不超过T; 2)发行方对电子现金签名正确; 3) Hash链有效，即支付出示的链节点有效.

2.2 方案构成

方案包括的协议簇如下：1)各实体的注册与密钥获取(初始化)；2)从ECA提取电子现金(提取电子现金)；3)请求用车、联系司机、上车、下车(乘车)；4)将电子现金交给OTN(支付)；5) OTN请求ECA兑换，ECA按比例把收入分配给平台和司机(入账与分账)；6)乘客也可选择下次乘车时再次消费未使用完的电子现金(多次消费)；7)当发生争议事件时，OTN联系司机追踪恶意乘客，或乘客出示相关凭证进行维权(身份恢复)；8)乘客还可选择高匿名需求的支付.以上共有8个协议，后3个协议根据消费需求和安全需求进行选择.其中，提取电子现金、支付、入账协议见图 2.

1) 初始化

所有实体(乘客、司机、网约车平台、电子现金中心)必须在数字证书中心进行注册，获得公钥和私钥.而且乘客、司机、OTN需要在ECA注册, 同时，司机还需要在OTN注册，注册时需提供有效的身份、车牌号、电话号码等信息.在ECA上，乘客通过自己的账号付钱后，采取部分盲签名，获取电子现金.OTN在结账时，向ECA兑换电子现金并分别存入OTN、司机账号.其他阶段都是乘客、司机与OTN之间的交互，包括支付时，乘客向OTN发送e-cash，此时无需ECA参与.

2) 提取电子现金

当乘客想从ECA的账户提取电子现金，需执行提取协议.假设公共消息m₁，隐私消息m₂，其中m₁是乘客与ECA协商好消息，包括电子现金面值N、有效期T、支付对象ID_OTN；即m₁=ID_OTN‖N‖T.

步骤1  ECA随机选取k₁, k₂∈Z_q^*，计算k₁G+k₂H₃(m₁)Q发送给乘客.其中Q=dG是ECA公钥PK_ECA，d为ECA私钥SK_ECA.

步骤2  乘客向ECA发送盲化后的隐私消息

步骤2.1  选取随机数r_N∈Z_q^*生成Hash链r_N→r_N-1 →r_N-2→…→r₁→r₀，满足H₁(r_i)=r_i-1 (i=N, N-1, …, 1)，r₀为Hash链的根结点，是e-cash的匿名标识.

步骤2.2  随机选取盲因子α和β，令m₂=r₀，计算

(1)

步骤2.3  计算

(2)

步骤2.4  盲化c

(3)

步骤2.5  将提取电子现金请求c′、请求者签名Sign(SK_P, c′)及证书Cert_P发送给ECA，即：

(4)

步骤3  ECA确认Cert_P有效后，进一步验证签名是否正确.如正确，则确认乘客的支付账户的余额是否大于N；如满足，则ECA从乘客的支付账户减去N，嵌入公共消息m₁，进行部分盲签

(5)

并发送给乘客.否则，终止协议.

步骤4  乘客脱去盲因子得

(6)

(m₁, m₂)的部分盲签名结果为(c, s)，如果该签名结果正确，乘客最终获得

(7)

与签名结果对应的验证式是：

(8)

其中m₁=ID_OTN‖N‖T, m₂=r₀.

3) 乘车

① 乘客将上车地点L_1P和下车地点L_2P发送给平台.

② 平台返回估算价格给用户.

③ 如乘客接受，发送少量电子现金作为定金(当协议正常执行，定金可冲抵车费；如果乘客不联系司机，定金不返回)；否则，退出应用.

④ 平台确认司机并返回其联系方式.

⑤ 乘客电话联系并确认司机，一旦上车，司机通知平台实际的上车地点L_1D、上车时间t_1D.

⑥ 当目的地到达，司机给平台发送行程结束消息：下车地点L_2D、下车时间t_2D等.

⑦ 平台扣除已付定金，计算实际仍需支付的乘车费用i并发送给乘客.

4) 支付

① 乘客确认支付后，用OTN公钥PK_OTN及椭圆曲线加密算法Enc加密电子现金、费用i、链节点r_i后发送给网约车平台OTN，即

(9)

② OTN解密得到数据项，检查电子现金的日期和签名是否有效，如有效，验证

(10)

如满足则表明支付成功，记录(e-cash, r_i, i).当e-cash过期，则该记录无效，可删除.

③ 乘客对司机服务进行评价.

5) 入账

① 在电子现金兑换的有效期限内，OTN对e-cash、链节点、费用、平台身份、司机身份进行签名加密后发送给ECA，即

(11)

其中，m=e-cash‖ r_i‖ i‖ID_OTN‖ID_D.

② ECA解密，验证OTN签名的有效性，如验证通过，检查e-cash的有效性，如认证通过，将(r₀, r₀, 0)更新为(r₀, r_i, i)；按照约定比例，向OTN和司机账号存钱.

6) 多次消费

由于电子现金没有使用完，下次乘车可再次消费，当消费金额是k，将支付环节修改为：乘客向OTN发送c=Enc(PK_OTN, e-cash‖r_j‖k)，其中j=i+ k，i为上次消费到达节点的序数.OTN在判断Hash链节点时，要确保j≤N，此时

(12)

更新(e-cash, r_i, i)为(e-cash, r_j, j).当j=N，表明电子现金使用完毕.如果本次支付的余额不够，乘客可申请新的电子现金，从新电子现金中取出缺少的金额提交，与本次合并，完成支付.

7) 身份恢复

匿名会导致一些问题，如乘客不付钱，OTN如何追踪?网约车平台计算错误造成乘客的经济损失，乘客如何取回多付的钱？在争议发生时，乘客的身份是需要恢复的.

当乘客出现问题，因为司机与乘客曾经直接联系，通过司机，OTN可以寻找到乘客，进行追责.

当OTN出现问题，乘客可以进行申诉.他可以将乘车的匿名订单、e-cash‖ r_j‖ k、真实身份、乘车路线等相关证据发送给OTN，然后OTN进行判断.若的确是OTN问题，OTN联系ECA，请求将多收的钱款转还给乘客.此时，由于乘客要追回钱款，其身份会被泄露.

当司机出现问题，一方面乘客可通过给司机打分，给出信誉值评价; 另一方面，可联系OTN，提供被侵权证据、司机电话，进而对该司机进行投诉.

8) 高匿名需求的支付

由于电子现金可分，只要电子现金没有使用完，都可继续使用.当重复使用该电子现金，平台虽然不知乘客身份，但是可将出行数据与相同r₀的e-cash关联.

对于隐私要求高的用户，设计只使用一次电子现金支付协议，将提取电子现金协议调整到支付协议前.首先，根据实际产生费用，申请电子现金N，在支付时，提供凭证e-cash‖ r_N‖ N.如通过有效期、签名、h^N(r_N)= r₀的验证，则支付成功，OTN记录(e-cash, r_N, N).

3 安全性分析

结论1  部分盲签名协议是正确的.

证  由电子现金的提取过程可知：

(13)

因此

故盲签名的验证式是正确的.

结论2  电子现金是可分的.

证  因为乘客第一次支付价值为i的费用时，发送e-cash‖ r_i‖i.此处i < N，剩余N-i个价值能够再次使用.当第二次支付价值为k的费用时，乘客出示e-cash‖r_j‖ k，j=i+k.类似的，e-cash可多次使用，直到j=N.

因此，电子现金是可分的.但是，从尽可能少地隐私泄露的角度，建议同一个e-cash使用次数不宜过多.

结论3  电子现金份额不可重用.

证  乘客每次支付使用一定的份额，如果乘客发送e-cash‖ r_j‖k给OTN，OTN会调用其存储数据(e-cash, r_i, i)进行判断，当份额重用会发现H₁^k(r_j)≠r_i，进而判断支付无效.

结论4  电子现金不可伪造.

证  要伪造电子现金，从乘客角度希望构造出假r₀或者调大N或从网约车平台竞争者的角度希望构造出假ID_OTN等，由于Hash函数的免碰撞性和离散对数求解的困难性，伪造电子现金是困难的.

在随机预言模型和椭圆曲线上离散对数难解的假设下，本文的盲签名协议在敌手自适应选择消息攻击下，不可伪造.

假设挑战者C收到离散对数问题的实例(G, Q=dG)，目标是找到d.假设攻击者A企图发现有效签名，C调用A求解离散对数问题.如果A以不可忽略的概率输出消息的有效签名，根据Forking引理^[12]，通过A对H₂询问进行重放，C可以获得两个有效签名(m₁, m₂, c₁, s₁)和(m₁, m₂, c₂, s₂).由签名过程可知：

故

即

所以

(14)

为离散对数问题的解.

结论5  攻击者冒充合法乘客是困难的.

证  1)申请电子现金的请求由乘客签名后发送给ECA，确保了申请者身份的真实性和消息的不可伪造性，故非法乘客无法冒充合法乘客获得电子现金.

2) 完整的Hash链仅由合法乘客惟一拥有，非法乘客都无法出示正确的e-cash‖ r_i‖i以及e-cash‖r_j‖ k完成支付.

3) 支付、兑换时采用了加密形式对e-cash、链节点进行保护，防止了凭证的泄露，非法乘客无法获取凭证通过认证.

结论6  面对OTP和ECA，乘客是匿名的.

证  1)电子现金具有部分盲性.考虑任意合法的盲签名(m₁, m₂, c, s)和任意中间变量(k₁G+k₂H₃(m₁)Q, c′, s′)间一定存在盲因子.由签名过程可知

(15)

(16)

(17)

根据(17)式知存在惟一的α=s(s′)^-1，因为s′=k₁+(k₂+c′)H₃(m₁)d，故α=s(k₁+(k₂+c′)H₃(m₁)d)^-1.

根据(16)式知存在惟一β=c′+α^-1c.故

表明存在α, β满足(15)式.所以任意一组签名发布过程中, 签名者私自保存的中间变量和任意合法的盲签名之间一定存在盲因子.这意味着电子现金发行过程中，ECA无法将中间变量和签名结果关联，无法获得签名与身份的关联关系.

2) e-cash提取、支付的匿名.乘客从ECA提取e-cash，将e-cash支付给OTN，因e-cash中没有乘客身份信息，避免了已有服务中ECA从乘客账号直接扣款，行驶数据易与账号关联的问题.另一方面，当电子现金重复被使用，OTN可关联同一e-cash支付下的出行数据，乘客是不完全匿名的.但是，方案也为隐私要求高的用户提供另一种选择，高匿名需求的支付协议要求乘客根据实际产生的打车费用，去申请相同数量电子现金，确保每次消费使用不同e-cash，乘客的匿名性增强.

3) 入账匿名.由于ECA采用部分盲签名协议颁发e-cash给用户，所以当OTN发送e-cash给ECA请求入账时，ECA无法将e-cash与乘客身份关联.

结论7  乘客的身份与行程不可关联.

分析: 1)对于一般的支付协议，在一次车程中，虽然OTN知道行驶数据，但乘客与OTN、OTN与ECA的通信中都没有乘客身份，因此单次车程中乘客身份与位置难以被关联.

2) 对于高匿名需求的支付协议，因为e-cash只能使用一次，故不同车程选用不同的e-cash，OTN无法利用e-cash去推断多次车程是否属于同一个乘客，无法进行位置跟踪.

结论8 当发生争议，乘客身份能够被恢复.

分析: 1)当OTN与司机联合，司机知道乘客的联系方式，其身份是可恢复的.如果出现恶意乘客，通过身份恢复协议可帮助机构追查违法者.

2) 为解决与OTN、司机之间的争议事件，乘客提供自己真实身份，请求申诉，提供证据，争取合法利益.

本文方案和面向网约车服务的Friginal方案^[6]、Pham方案^[7]的安全、隐私性比较见表 1.

三个方案都满足抗窃取、匿名、不可关联性.Friginal方案没有使用e-cash，也不具备在一定条件下可追踪的功能. Pham方案和我们方案中OTN与司机联合，都可追踪非法乘客，而且都使用了电子现金，但Pham方案未提及现金可分.

4 性能分析

考虑到初始化发生在乘客注册阶段，而乘车协议与现有的业务流程大体一致，因此我们主要讨论e-cash申请、支付、入账3个阶段协议性能.

1) 通信开销.在这3个协议中，首先乘客向ECA提交申请，ECA产生电子现金并颁发.乘客将加密的电子现金发给OTN进行支付.OTN将加密的电子现金及分账请求发给ECA进行兑换.以上过程涉及3个实体的5次通信.

2) 计算开销.在以上通信中，我们需要椭圆曲线上的2次签名、3次验证、2次加密、2次解密、9次点乘，(N+2i+8)次Hash运算，其中N是电子现金面额，i是本次消费数量.

我们方案和Pham方案的性能比较见表 2.Pham方案使用盲签名颁发电子现金，并使用DH密钥交换建立乘客和司机之间的安全通道，仅申请电子现金、建立安全通道两个环节，至少需要4次通信，至少4次点乘、4次对称加密、4次对称解密、1次盲签名、1次盲验证.

在通信开销方面，本方案的通信开销要小于Pham方案.因为我们方案的5次通信，面向e-cash提取、支付、入账3个协议，而Pham至少需要4次通信面向e-cash提取、建立安全通道两个阶段，不包括支付、入账协议，Pham未给出这两个协议的细节.

在计算开销方面，本方案中，Hash运算的次数较多，但是N次Hash运算是第一次申请e-cash需要的，之后使用e-cash就无需这部分运算，而且Hash运算是轻量级操作，与签名验证等操作相比，通常可忽略.另一方面，为防止电子现金及凭据被窃取，本方案采用公钥加密.Pham方案使用对称加密传输消息，对称加解密开销相对小，但是为建立安全通道，增加了密钥协商的开销.Pham方案未给出具体盲签名算法和协议，故盲签名T_BS和盲验证T_BV未知.即使Pham方案总计算开销要小于本文方案，但是本文方案具有电子现金可分的特点，由此设计的多次消费协议使整个方案功能增多，实用性增强.

5 结论

基于Hash链签名，给出采用电子现金的网约车隐私保护方案.方案由初始化、提取电子现金、乘车、支付、入账、多次消费、身份恢复和高匿名需求支付共8个协议组成.安全性分析表明：构造的电子现金具有可分、不可伪造性，方案具有抗窃取、匿名、不可关联性等安全属性.性能分析表明：方案具有较少的通信开销, 而且除了电子现金支付等模块，方案业务流程与已有服务框架基本一致，能够方便地部署在已有应用上.