[2018|FGCS]Secure intelligent traffic light control using fog computing

【论文笔记】随着车辆数量的快速增加，安全、高效的通行效率成为关注的重点问题，一批智能交通系统也快速发展。本篇论文聚焦于车联网中交通信号灯的控制，提出了基于雾计算的两套安全智能交通信号灯控制机制，其安全性分别依托于计算Diffie-Hellman难题和哈希碰撞难题的困难程度，并进一步分析两种机制之间的性能表现。本篇论文重点关注车辆、交通信号灯、可信机构三者之间的认证安全性实现和通信效率、复杂度等，对于具体信号灯调度算法不做详细讨论。

【论文作者】Jian Liu, Jiangtao Li, Lei Zhang, Feifei Dai, Yuanfei Zhang, Xinyu Meng, Jian Shen

【论文链接】https://www.sciencedirect.com/science/article/pii/S0167739X17302157

文章创新点

• 可抵抗恶意汽车的攻击
• 可抵抗单点攻击
• 提出的改进机制是雾设备友好型

当前存在的问题

现存2种智能交通信号灯控制策略有如下问题：

固定时间响应(fixed-time one)

利用过往数据流量分析，对每天不同时间段提前预置固定的信号灯变换时间间隔。

• 非实时
• 无法应对如交通事故或紧急情况引起的突然变化

流量响应(traffic-responsive)

根据实时流量响应的控制策略，核心在于预测(获取)驶来的车辆情况。当下主要有4种情况：

1. pavement loop detectors
   • 使用、部署非常笨重
2. video-based traffic detection systems
   • 人工监控：需要大量人力投入
   • automated vision-based approaches：视频识别技术不够成熟，易受环境因素影响
3. wireless sensor networks(WSNs)
   • 需要大量传感器结点，运维成本巨高
   • 安全性无法保证
4. vehicular ad hoc network(VANET)
   • 安全性无法保证，可能存在恶意汽车传送假数据
   • 大量信号灯和同一个控制器(cloud or server)频繁的通信造成大延迟，单点破坏会造成整个系统崩溃 => 中心化

文章所做的具体工作

​ 本文研究了基于雾计算的VANET智能交通灯控制。

雾计算中用户利用协作的终端用户客户端或近用户边缘设备来执行计算和存储操作。

​ 本篇文章所提出的控制机制中是将交通信号灯看作雾设备，它可以和邻近信号灯以及汽车交互，并在信号灯侧执行调度算法，首先解决了上述现存机制的高延迟问题，免去了和同一个服务端通信的传输、拥堵造成的时延，后续不再赘述。文章共提出两个安全机制：Basic Scheme 和 Improved Scheme。

​ 机制中主要需要解决的问题：

1. 安全性：在实际背景下如何能防止一辆汽车伪造大量汽车的情况，防止DoS攻击
2. 认证性：如何让只有在该交通信号灯周边的汽车纳入统计，进而进行调度控制，而远离该信号灯的汽车无法干扰

Basic Scheme

在防御DoS攻击的机制下进行的扩展，核心安全性体现在计算Diffie-Hellman难题，认证核心体现在LBE。

1. 系统初始化：TA生成参数$(\gamma, q, G, g, f, \epsilon_{ssk}(·)/D_{ssk}(·))$并广播给所有汽车和交通信号灯

2. 信号灯生成公钥$(u_1,u_2,u_3…)$，其中$u_\omega = g^{y_{\omega}}$，$\omega$代表状态数(每辆车可能发生的行为数，如右转、直行等)，$y_{\omega}$即Diffie-Hellman中的信号灯私钥，最后广播该公钥

3. TA生成信号灯和其公钥绑定的相关证书发送给信号灯，信号灯定期广播供汽车验证公钥合法性

4. 信号灯为附近每辆汽车生成puzzle：$P_i=(g_{i,\tau}, r_{i,\tau})$，$g_{i,\tau}=g^{f(a_i,\tau)}$，$\gamma$用在了此处$a_{i,\tau}$的均匀随机选取上，$\gamma$越大意味着$a_{i,\tau}$的空间越大，暴力破解的难度越大

   如何知道有多少辆汽车？不是需要根据返回的proof进行验证？<= 已解决，文章后续提到汽车会持续广播他们的伪造身份id以便信号灯知道哪些车在其附近，当然这也带来了一定的通信代价。

5. 信号灯对$P={P_1,P_2,…}$进行LBE后分发$(c_1,c_2)$

   • 生成对称加密密钥$sk_{\tau}$

   • 如下计算GeoLock值

     LBE加密算法，该算法相比于普通数据加密核心在于GeoLock mapping Function，将时间和用户地理位置转换成一个GeoLock值从而限制只有用户在一个特定的区域内方能解密数据，该值的转换如下实现：

     1. $(x_0,y_0)$是位置参数，T是时间间隔

     2. 地理位置$(x_0,y_0)$会被划分成一个可自定义的解密区域(如100mx100m的正方形)，并输出必要部分

     3. 该输出会和时间间隔一起进行多路复用(Mux)计算，输出一个值

     4. 对该值施加哈希函数得到最终的GeoLock Value。

     一个用户只有满足这个时间和限制的解密区域中方能产生一个相同的GeoLock值。=> 文章假设GPS是可信的

   

   • 加密流程：$c_1 = GeoLockValue \oplus sk_{\tau}$，$c_2=\epsilon_{sk_\tau}(P)$

6. 汽车侧只有在进入了制定的信号灯附近解密区域后首先能计算出相应的GeoLock Value，将该值和广播分发得到的$c_1$进行异或得到对称加密密钥，进而解密得到puzzle。随后汽车通过暴力破解puzzle，得到$\widehat a = a_{i,\tau}$，从而生成proof$(id_i,u_\omega^{f(\widehat a)}, \omega)$发送给交通信号灯

   首先由于汽车侧计算和存储能力有限，面对Diffie-Hellman的离散对数难题，虽然本文的搜索空间可调控，但在规定的协商时间内仍最多只能解出一个puzzle，因此可以有效防止一个汽车伪装成多个汽车，防止了恶意汽车情况。

7. 信号灯侧对proof进行验证，主要验证等式是否成立：$u_\omega^{f(\widehat a)}\overset{?}{=}g_{i,\tau}^{y_\omega}$ => 类似于共享密钥思想，满足即说明该汽车能获取到puzzle，而能够获取说明他是在指定区域的(否则LBE无法解密获得)，完成真实周边车辆认证及数量的统计。

8. 根据汽车数量信号灯侧进行调度

​ 进一步，作者考虑到了如果信号灯侧的汽车数量非常大时，为每辆汽车生成一个puzzle代价也是非常大的，因此提出了puzzle共享，同一个puzzle在一定区间内可以复用进行缓解。

​ 通过上述分析，该机制能在实现实时调度的基础上满足防止恶意汽车进行伪装，同时汽车每进入一个新的监控区域(新的交通信号灯附近)就会更改伪造身份id，实现了隐私保护。

Improved Scheme

​ 相比于基础机制，改进机制主要考虑到信号灯需要分发的puzzle数量和汽车数量之间是线性增长的关系，对于信号灯侧来说其要生成的puzzle和验证的proof所需的计算和通信代价还是非常大的(不是雾设备友好型)且对于汽车的具体信息、位置、方向仍不知，因此提出了使用哈希碰撞难题构造，无论附近多少车，在每个时间间隙一个信号灯只需生成一个puzzle进行。

​ 在初始化时，TA会选定一个哈希函数(制造哈希碰撞的难度体现在了哈希函数输出空间的大小上)，交通信号灯侧准备生成puzzle时会均匀随机选取一个k位随机种子$\eta_\tau$，并使用LBE加密后分发。汽车侧收到分发的密文后通过LBE解密获得$\eta_\tau$，随后通过暴力破解找到一对哈希碰撞值$(\zeta_i,\zeta_i’)$满足$SH(\eta_\tau||status_i||\zeta_i)=SH(\eta_\tau||status_i||\zeta_i’)$，其中$status_i$为汽车状态信息，最后将proof$(status_i,\zeta_i,\zeta_i’)$发送给交通信号灯，信号灯只需验证$SH(\eta_\tau||status_i||\zeta_i)\overset{?}{=}SH(\eta_\tau||status_i||\zeta_i’)$是否成立，若成立则代表该汽车是在合法区域内，否则他无法获取$\eta_\tau$也就无法构造出哈希碰撞，完成认证的同时根据汽车状态信息进行算法调度控制。

​ LBE保证车辆是在合法区域内，puzzle保证了车辆侧在协商时间内至多解决一个难题，无法实现类DoS的伪装攻击，由于发送的只是汽车状态，因此并不涉及隐私信息或进行追踪，最后由于交通信号灯只需要生成和验证一个puzzle，也不需要额外的传感器部署，因此该机制是雾设备友好型。

性能分析

​ 本篇论文作者对改进机制进行了测试，下图展示了哈希碰撞难题上的困难程度和解puzzle所需时间之间的关系，从图中展示解puzzle所需的时间随着哈希函数输出位数的增加(难题困难程度的增加)呈指数级上升。机制中的规定协商时间一般是略大于解puzzle时间。

​ 下图展示了信号灯周围车辆数量、哈希碰撞难题的困难程度以及验证proofs所需的平均延迟三者之间的关系。图中反映了信号灯周围的汽车数量对平均延迟影响并不大，即使车多也不会有过重的计算负担；平均延迟主要取决于解puzzle的时间，权衡低难度的噪声和高难度会浪费汽车计算资源二者，论文给出了一个推荐的困难程度，输出空间控制在16到25位。

结论

​ 本篇论文基于雾计算、LBE和密码学难题实现了安全的智能交通信号灯控制。作者将交通信号灯看作雾设备，提出了基于计算Diffie-Hellman难题的基础机制和基于哈希碰撞难题的改进机制。通过对改进机制的性能分析证明了其有很强的实用性。

阅读感想

​ 首先我觉得通过阅读本篇论文对如何应用Diffie-Hellman协议和构造哈希碰撞于实际中有了比较深刻和全新的认识，原先对Diffie-Hellman协议是停留在密钥交换而哈希碰撞还局限在生日攻击和区块链哈希函数需满足collision resistance，但是本文中作者是非常巧妙的利用二者的安全性(破解需耗费计算资源和延迟时间，困难性可控的特点)来作为车辆侧的防伪装保证，解puzzle非常类似于区块链中挖矿的思想，提升了整体系统机制的安全性，防止了恶意汽车的攻击，另LBE算法的引入也是非常方便的完成了汽车是否在信号灯周围的验证以及puzzle的保护，以防被恶意监听窃取puzzle并解出生成proof进行欺骗。

​ 自己在阅读过程中产生的疑惑：

• 基础机制中信号灯如何知道周围有多少辆汽车从而生成对应数量的puzzle？

  ==已解决：==文章后续提到汽车会持续广播他们的伪造身份id以便信号灯知道哪些车在其附近，当然这也带来了一定的通信代价。

• 系统初始化阶段会输入一个安全参数l，这个和选择的循环群G(阶为q)之间存在什么样的关系？通常是直接选取大素数q得到一个阶为q的素域$Z_q$，那l与q之间的关系是如何？

  ==思考：==素域只是最基础的，安全参数的作用是确保协议的安全性和防范离散对数问题的攻击。具体关系根据实际情况、选择的循环群而定？在后续改进机制中随机种子的长度也是依托于l(通常越长越难被爆破)。

• 汽车和交通信号灯之间是否需要增加轻量的认证过程？消息(Proof)是否需要进行签名来保证完整性？否则是否会造成虽然恶意用户无法窃取LBE加密后的puzzle，但是可以直接窃取传输的Proof，从而进行篡改，比如原来选择直行改成左转，从而干扰信号灯调度。

  ==思考：==根据返回的Proof构造来看$(id_i,u_\omega^{f(\widehat a)}, \omega)$和$(status_i,\zeta_i,\zeta_i’)$，前者首先用户会返回id来标记所对应的puzzle，由此attacker肯定不能直接拿它来当作自己的proof，要篡改方向等信息即从$u_1$变成$u_2$核心在于生成$u_\omega^{f(\widehat a)}$，生成的关键在于$f(\widehat a)$，从已知$\sigma=u_\omega^{f(\widehat a)}$来求$f(\widehat a)$是离散对数求解难题，安全性得以保证；后者同理，要篡改的部分是修改status，那就要同步修改$(\zeta_i,\zeta_i’)$以保证哈希的验证通过，但是由于$\eta$不知，则无法完成构造，即无法篡改。

​ 改进想法(暂时):

• 在所在机制的基础上设计优先车辆感知