物联网通常由低功耗、资源受限的无线设备组、传感器和控制器等通过互联网进行连接和通信, 被广泛应用在通信、医疗、交通等多个不同领域。预计到2020年底, 物联网连接设备的数量将达到300亿[1]。随着物联网的发展和提供服务的增多, 其受到网络攻击的风险也随之增加。物联网设备的隐私和通信安全问题受到人们的广泛重视, 由于现有的安全协议存在安全漏洞和高能耗等缺陷, 因此研究一种能保证物联网安全且不影响其通信效率的低功耗协议是目前急需解决的问题。
近年来, 研究人员针对物联网通信安全进行了大量研究。文献[2-3]分别提出入侵检测系统以监控恶意活动, 但由于入侵检测系统计算需求大, 无法应用到低功耗、低资源的设备中。目前, 有学者已经研究出许多其他方案, 如文献[4-5]提出的身份认证方案、文献[6-7]提出的通信数据加密方案等, 但是实施加密和身份验证方案并不会掩盖设备的地址, 从而给攻击者提供了查找和定位这些设备并进行攻击的机会。
采用地址跳变的移动目标防御技术(Moving Target Defense, MTD)可以限制攻击者查找和跟踪目标, 保护设备的位置隐私, 直接影响攻击者的攻击能力。文献[8]开发了一种移动目标IPv6网络防御(Moving Target IPv6 Defense, MT6D)协议, 该协议通过不断改变网络层和传输层地址, 成功地阻止了目标网络、主机跟踪和窃听等攻击, 保护了通信双方的隐私和安全[9]。文献[10-11]提出将MT6D用于保护物联网网络的安全, 并验证了其方案的可行性, 但未考虑物联网设备资源的有限性和通信设备之间的时钟差异导致丢包率较大的问题。文献[12]给出了uMT6D协议的概念, 即对MT6D协议在物联网上的应用进行优化, 并提出可以通过Contiki系统的cooja平台对其方案进行仿真测试, 但文献[12]仅提出相关概念而没有具体实现方法。
针对MT6D协议在物联网的实现计算开销较大和丢包率较高的问题, 本文提出L6HOP协议, 该协议采用轻量级哈希函数替代MT6D中计算量大的SHA256算法来降低CPU计算开销, 并引入滑动地址窗口减小通信设备之间的时钟误差, 以保证通信效率, 实现物联网设备的主动网络防御。
1 MT6D协议通常由于主机不经常更改网络地址或保持静态网络地址不变, 攻击者可以窃听通信双方的交互信息或攻击特定的主机。文献[8]针对上述问题并根据军事上无线通信中跳频思想提出MT6D协议, 以维护IPv6网络用户隐私并防范目标网络攻击。IPv6的引入能解决目前IPv4地址数量不足的问题, 但由于IPv6的无状态地址自动配置(Stateless Address Auto Configuration, SLAAC)[13]允许设备创建IPv6地址, 且其创建地址中的主机接口标识符IID[14](Interface ID)由MAC地址生成, 恶意用户可以通过IP地址识别设备监视和跟踪这些设备的通信[15-16]。跟踪和监视一个地址可以使攻击者在侦察阶段有足够的时间收集信息, 并最终规划出一个攻击策略。MT6D协议利用IPv6子网中巨大的地址空间动态改变设备IPv6地址, 通信双方均根据该协议不断改变本地主机地址, 并计算对方主机的IP地址以保持通信。该协议可以保护主机在公共互联网上相互通信时不受定向网络攻击以及保持通信主机的匿名性。其地址更改是通过改变主机接口标识符IID实现的, IID计算过程如式(1)所示:
$ {\rm{IID}}_{\mathit{X}(i)}^\prime = H{\left[ {{\rm{II}}{{\rm{D}}_X}\left\| {{K_S}} \right\|{t_i}} \right]_{0 \to 63}} $ | (1) |
其中, IID′X(i)表示主机X在ti时刻跳变后的IID, IIDX表示主机X当前时刻的IID, KS表示共享的对称密钥, ti表示第i次计算跳变IID的时间, H[·]表示进行哈希计算, 在该协议中哈希算法采用的是SHA256, H[·]0→63表示取哈希值的最左64位。IIDX初始值为主机X的初始接口标识符IID, 改变后的IID由哈希值最左边的64位(0位~63位)构造。MT6D通过将主机的子网前缀与IID′X(i)连接起来形成新的IPv6地址。该协议除了动态改变IID外, 还改变网络端口号, 并提供两种动态改变端口号的技术:一种是主机指定一个接近于正常网络流量的端口范围; 另一种是使用式(1)中哈希值未使用的位来改变端口号, 即若主机可用端口范围为0~65 535, 则使用式(1)中哈希值的第64位至第79位(共16位)来改变端口号。
MT6D协议使用式(1)在每次到达时间增量时重新计算每个通信对的发送方和接收方的地址, 文献[8]测试该协议的可行性, 为了便于流量的分析, 设置时间增量为10 s, 即该协议每隔10 s重新计算通信双方的IPv6地址。
2 L6HOP协议设计本文针对MT6D协议在物联网上应用时未考虑到通信双方设备存在时钟误差和低功耗设备资源受限的问题, 提出一种L6HOP协议。该协议选择轻量级的哈希函数Spongent[17]替代MT6D协议中的SHA256, 减少物联网设备计算开销, 并引入滑动地址窗口机制解决通信设备之间的时钟误差, 降低通信丢包率。
2.1 地址生成基于MT6D协议地址计算过程, 本文为增加攻击者破解地址跳变规律的难度, 保留了计算当前地址的完整哈希值hi, 同时为了避免通信双方主机时钟不同步, 不对时间戳参数ti进行哈希计算, 则有:
$ {{h_i} = H\left[ {{h_{i - 1}}\left\| {{K_s}} \right.} \right]} $ | (2) |
$ {{\rm{II}}{{\rm{D}}_{X(i)}} = {{\left( {{h_i}} \right)}_{0 \to 63}}, i = \{ 1, 2, \cdots \} } $ | (3) |
其中, hi表示ti时刻的哈希值, hi初始值h0为设备X的初始IID, IIDX(i)表示主机X在ti时刻跳变后的IID, (hi)0-63表示对数据hi进行取前64位操作, H[·]表示进行哈希计算。针对MT6D协议计算消耗较大的问题, 文献[18]提出可使用轻量级的哈希函数替代计算量大的SHA256。文献[19]针对轻量级哈希进行研究, 在ATMEL AVR ATtiny45 8位微控制器上实现SHA256、Spongent等不同哈希算法, 并对不同哈希函数的性能从代码大小和内存消耗方面进行比较, 实验结果表明, Spongent函数代码量大小约为SHA256的1/2, 内存消耗约为SHA256的1/3, 因此式(2)中的哈希计算采用Spongent函数替代MT6D协议采用的SHA256函数。在协议初始化过程中, 通信双方采用线下或内部网络传输的方式交换主机的初始IID和密钥KS, 避免攻击者窃听和篡改数据, 保证初始化过程的安全性。由此, 地址变化后的IPv6地址表示为Addri={子网前缀, IIDX(i)}, 定义IPv6地址链表为{Addr0, Addr1, Addr2, …}。通信双方根据该算法计算下一跳地址, 网络端口号可根据哈希值hi中未使用的位进行动态改变。
2.2 地址链表更新本文协议地址链表状态的更新由基于时间的计数器Nnow的更改触发, 计数器Nnow表示地址更改的次数。Nnow的计算公式如式(4)所示:
$ N_{\text {now }}=\left\lfloor\frac{T_{\text {now }}-T_{0}}{\Delta t}\right\rfloor $ | (4) |
其中, Tnow为实时时钟提供的当前时间, T0为通信设备初始连接的时间戳, Δt表示时间步长, 即地址跳变的时间间隔,
本文所有时间变量均以秒为单位进行度量。由于地址更新是根据时间间隔步长计算的, 因此在设定好时间步长Δt之后, 即便客户机上的T0值与服务器上的T0值不同, 也不会影响地址跳变的同步。
2.3 滑动地址窗口通信双方在通信过程中由于网络时延和时钟差异等, 可能会出现以下2种情况:1)设备节点的时钟较快, 而服务器时钟较慢, 此时设备节点已经跳转到下一地址, 导致服务器无法连接到设备跳变前的地址; 2)设备节点的时钟较慢, 而服务器时钟较快, 设备节点地址还未跳转, 导致服务器无法连接设备节点的下一地址。
为提高通信效率, 降低通信双方因时钟误差引起丢包率较大的问题, L6HOP协议引入滑动地址窗口机制, 如图 1(a)所示, 发送地址窗口大小为1, 定义一个大小为w的接收地址窗口并根据L6HOP会话的安全需求设置窗口w的大小, 地址窗口随着时间增长向前滑动。接收地址窗口即2.1节中所定义的地址链表, 地址链表长度由接收地址窗口大小决定。本文设置接收地址窗口大小为3, 则通信主机每次会话保存发送方地址链表中的3个地址。定义当前连接的地址为Addri, 保存的地址即为{Addri-1, Addri, Addri+1}。如图 1(b)所示, 在t4时刻, 当发送方由于时钟太快而先跳转到下一地址, 接收方会在接收窗口选择下一个地址与发送方保持通信; 如图 1(c)所示, 在t4时刻, 当接收方时钟太快而达到地址跳变条件, 不会立即改变通信地址, 而是保持当前连接的地址不变, 接收窗口向前滑动一次, 等待发送方的当前地址生命周期结束再跳转到下一个地址。滑动地址窗口机制的引入, 保证了每个L6HOP协议会话在前后一个时间步长大小范围内的小时钟漂移都能保持正常连接, 确保了连接的灵活性和连续IPv6地址之间的平稳过渡。
![]() |
Download:
|
图 1 滑动地址窗口 Fig. 1 Sliding address window |
L6HOP协议分别应用在服务器和每个物联网节点上, 物联网系统中服务器与物联网节点的通信为一对多通信, 所以本文只改变物联网节点的IP地址, 服务器地址保持不变。在初始化过程中将物联网节点的初始IID和密钥KS通过线下传输或者内部网络发送给服务器; 物联网节点的发送窗口大小为1, 无须设置接收窗口; 服务器分别为每个物联网节点设置一个大小为w的接收窗口, 无须设置发送窗口。当物联网节点计数器Nnow发生更改时达到地址跳变条件, 物联网节点利用该协议计算下一跳地址并更新地址链表, 由于发送窗口大小为1, 因此链表更新即实现设备IP地址的跳变。当服务器计数器Nnow更改时, 服务器利用该协议计算与其通信的物联网节点的下一跳地址, 更新地址链表, 并利用滑动地址窗口机制保持与节点的通信效率。
3 安全性分析文献[8-11]均设定地址跳变时间为10 s时对协议进行分析, 本文参考文献[8-11], 设定L6HOP协议以每隔10 s动态改变物联网设备的IPv6地址来分析其安全性。当节点设备地址随时间动态改变时, 攻击者无法从IPv6地址中获得设备的MAC地址或者其他静态标识来追踪设备的通信, 保证了物联网设备通信的匿名性, 能有效防止主机跟踪和窃听攻击, 从而实现对设备安全和数据隐私的保护。下文分别对L6HOP协议的抗流量截获分析能力和抗DOS攻击能力进行分析。
3.1 抗流量截获攻击能力IPv6地址后缀为64位, 它的子网地址为264个, 地址空间巨大, 远程攻击者想要准确地获取某个目标节点的IPv6地址进行攻击的可能性极低。即使攻击者在其最有利的位置, 即路由器处对设备的通信子网进行流量分析, 也无法确定目标节点的IP地址。设子网内通信节点的个数为L, 通信时长为S秒, 则在S秒内地址跳变总数为NTotal次, NTotal计算公式如式(5)所示。如图 2(a)所示, 子网内实际通信节点个数为L=3个, 地址跳变的时间间隔Δt=10 s, 则通信时长为S=100 s时攻击者探测的地址情况如图 2(b)所示, 得到的地址数为NTotal=30个, 攻击者截获的是分散的不同节点的通信流量, 无法确定截获的是否为目标节点的数据包。
$ N_{\text {Total }}=\frac{S}{\Delta t} \times L $ | (5) |
![]() |
Download:
|
图 2 L6HOP协议概念示意图 Fig. 2 Conceptual diagram of L6HOP protocol |
若攻击者希望通过截获数据包计算出地址跳变的规律, 必须计算出共享密钥和2个相邻地址生成的完整哈希值。攻击者通过截获的数据包分析得到2个连续的地址, 分析出其中某个地址64位地址后缀的完整哈希数和密钥, 需对相邻的两个地址进行计算并比较, 至少需要进行HTotal次哈希计算, 则有:
$ H_{\text {Total }}=2 \times m \times 2^{n-64} $ | (6) |
其中, n表示哈希计算生成的哈希值的位数, m表示攻击者计算共享密钥需要的计算次数。L6HOP协议的哈希值hi的位数为128位, 即使攻击者已知共享密钥也至少需要进行HTotal=2×2128-64次哈希计算。以目前计算机的计算能力无法计算出该协议的地址跳变规律。综上所述, 该协议能抵抗流量截获攻击。
3.2 抗DoS攻击能力在实际生活环境中, 攻击者可以通过DoS攻击达到消耗设备资源或者使设备陷入瘫痪的目的。设备加入L6HOP协议, 从而不断改变IP地址, 攻击者无法判断地址跳变规律, 不能通过正常的静态IP对目标节点进行DoS攻击。攻击者可以采用对目标网络的设备节点发送大量地址的数据包进行DoS攻击, 但是IPv6地址跳变的空间为264个, 要保持对节点DoS攻击百分之百的成功率, 每一时刻至少需要发送264个报文到目标网络的子网内。这需要庞大的分布式拒绝服务(Distributed Denial of Service, DDoS)攻击才能实现, 攻击代价远大于收益, 因此, L6HOP能有效抵抗DoS攻击。
4 实验结果与分析本文在Contiki3.0系统的cooja仿真平台和在32 KB RAM、512 KB flash的CC2538SF53芯片的开发板上均验证了跳变协议MT6D和L6HOP的可行性和有效性, 以Intel i7-7700 CPU、8 GB内存的个人电脑为服务器与动态地址跳变的6LoWPAN网络通信。由于RPL[20](Routing Protocol for Low-Power and Lossy Network)边界路由器是6LoWPAN[21]网络节点与互联网通信的唯一网关, 因此本文将一个节点设定为RPL边界路由器, 其他节点设定为普通地址跳变的节点。当普通节点地址跳变后只有将新的IPv6地址告知RPL边界路由器并将该地址加入路由表, 地址跳变后的节点才能与互联网正常通信。为避免新地址加入路由表产生延迟, 设定普通节点在每次地址跳变后发送一个RPL信息对象消息DIO(DODAG Information Object), 并禁用Contiki系统中设定的请求消息DIS(DODAG Information Solicitation)和确认消息DDA(DODAG Destination Advertisement)之间的延时函数。本文设定的网络前缀为bbbb:0000:0000:0000。
4.1 L6HOP协议的有效性验证通过以上环境设置分别测试服务器与cooja仿真的单个节点进行Δt为5 s、10 s和15 s的通信, 并在服务器上利用Wireshark流量分析软件对节点的网络进行流量分析, 记录其地址跳变情况, 结果如图 3所示。从图 3可以看出, 节点的地址随着通信时间的增加在不断改变, 不同Δt的地址跳变频率不同, Δt越小地址变化越快, 但同一节点的地址变化规律相同。实验结果表明, 目标节点通信被不同的地址有效分散, 证明了L6HOP协议能有效保护设备的隐私和通信安全。
![]() |
Download:
|
图 3 地址跳变结果 Fig. 3 Result of address hopping |
本文在Contiki3.0系统的cooja仿真平台实现地址跳变协议, 分别测试应用MT6D和L6HOP节点运行100 s、200 s和300 s时的CPU计算消耗, Δt设为10 s。记录不同个数的节点在不同运行时间内的CPU计算功率的平均值, 并将计算消耗转化成能量的形式, 结果如图 4所示。从图 4可以看出, 不同的运行时间内在节点相同的情况下, 由于L6HOP协议采用轻量级哈希函数Spongent, 其CPU计算消耗均低于MT6D协议, 更适合物联网中资源受限的设备。
![]() |
Download:
|
图 4 CPU计算能耗比较 Fig. 4 Comparison of CPU computing energy consumption |
为了验证通信双方在时间差异影响下丢包率大小的情况, 本文在cc2538芯片的节点上分别实现L6HOP和MT6D两个地址跳变协议, 通过服务器向每个节点每秒发送50个大小为10 B的数据包, 并通过Wireshark软件抓包分析2个不同协议的丢包率, Δt设为10 s。由于在实际环境中存在同一个个域网下有多个通信节点, 因此分别测试1个节点、2个节点和3个节点同时与服务器通信的丢包率情况, 结果如图 5所示。从图 5可以看出, 不同数量的节点与服务器通信对丢包率基本没有影响; MT6D协议随着通信时间的增长丢包率呈逐渐上升状态, 300 s内上升约4%;L6HOP协议能保持较低的丢包率, 随着通信时间的增长丢包率基本不变。由于设备节点时钟与服务器的时钟不一致导致服务器与设备节点在时间计算上存在差异, 且时间越长差异越大, 因为MT6D协议下一跳地址是根据时间增量触发, 时间差异会导致发送方和接收方地址跳变不同步, 时间越长丢包率越大。而L6HOP协议滑动地址窗口机制的引入能容忍时间差异, 降低丢包率, 保持通信效率。
![]() |
Download:
|
图 5 不同数量节点丢包率比较 Fig. 5 Comparison of packet loss rate of different number of nodes |
本文针对MT6D协议用于保护物联网安全时计算消耗较大和丢包率较高的问题, 提出一种基于低功耗无线个域网6LoWPAN的轻量级IPv6地址跳变协议(L6HOP)。通过使用轻量级哈希函数Spongent降低计算消耗, 并引入滑动地址窗口机制解决通信双方的时间差异问题。该协议限制攻击者成功识别IP地址从而在目标节点上启动恶意攻击的机会, 能够有效抵抗流量截获分析、主机跟踪、窃听攻击和DOS攻击等, 保护了物联网设备隐私和通信安全。在cc2358芯片上的实验结果表明, L6HOP协议在CPU计算开销和丢包率上相比于MT6D协议均具有优势。下一步将把该协议与轻量级身份认证技术进行融合, 以更全面地保护物联网安全。
[1] |
PENG Anni, ZHOU Wei, JIA Yan, et al. Survey of the Internet of things operating system security[J]. Journal on Communications, 2018, 39(3): 22-34. (in Chinese) 彭安妮, 周威, 贾岩, 等. 物联网操作系统安全研究综述[J]. 通信学报, 2018, 39(3): 22-34. |
[2] |
MUDGERIKAR A, SHARMA P, BERTINO E.E-spion: a system-level intrusion detection system for IoT devices[C]//Proceedings of the 2019 ACM Conference on Computer and Communications Security.New York, USA: ACM Press, 2019: 493-500.
|
[3] |
ARSHAD J, AZAD M A, ABDELLATIFM M, et al. COLIDE:a collaborative intrusion detection framework for IoT[J]. IET Networks, 2018, 8(1): 3-14. |
[4] |
AKBARZADEH A, BAYAT M, ZAHEDNEJAD B, et al. A lightweight hierarchical authentication scheme for Internet of things[J]. Journal of Ambient Intelligence and Humanized Computing, 2019, 10(7): 2607-2619. DOI:10.1007/s12652-018-0937-6 |
[5] |
SHARMA G, KALRA S. A lightweight multi-factor secure smart card based remote user authentication scheme for cloud-IoT applications[J]. Journal of Information Security and Applications, 2018, 42: 95-106. DOI:10.1016/j.jisa.2018.08.003 |
[6] |
MENG Qian, MA Jianfeng, CHEN Kefei, et al. Data comparable encryption scheme based on cloud computing in Internet of things[J]. Journal on Communications, 2018, 39(4): 167-175. (in Chinese) 孟倩, 马建峰, 陈克非, 等. 基于云计算平台的物联网加密数据比较方案[J]. 通信学报, 2018, 39(4): 167-175. |
[7] |
RAJESH S, PAUL V, MENON V G, et al. A secure and efficient lightweight symmetric encryption scheme for transfer of text files between embedded IoT devices[J]. Symmetry, 2019, 11(2): 293. |
[8] |
DUNLOP M, GROAT S, URBANSKI W, et al.Mt6d: a moving target IPv6 defense[C]//Proceedings of Military Communications Conference.Washington D.C., USA: IEEE Press, 2011: 1321-1326.
|
[9] |
DUNLOP M, GROAT S, URBANSKI W, et al. The blind man's bluff approach to security using IPv6[J]. IEEE Security and Privacy, 2012, 10(4): 35-43. |
[10] |
PREISS T, SHERBURNE M, MARCHANY R, et al.Implementing dynamic address changes in contikios[C]//Proceedings of IEEE International Conference on Information Society.Washington D.C., USA: IEEE Press, 2014: 222-227.
|
[11] |
SHERBURNE M, MARCHANY R, TRONT J.Implementing moving target IPv6 defense to secure 6LowPan in the IoT and smart grid[C]//Proceedings of the 9th Annual Cyber and Information Security Research Conference.New York, USA: ACM Press, 2014: 37-40.
|
[12] |
ZZITE K, CANTRELL M, MARCHANY R, et al.Designing a micro-moving target IPv6 defense for the IoT[C]//Proceedings of the 2nd IEEE/ACM International Conference on Internet-of-Things Design and Implementation.Washington D.C., USA: IEEE Press, 2017: 179-184.
|
[13] |
SHAH J L, PARVEZ J. Optimizing security and address configuration in IPv6 SLAAC[J]. Procedia Computer Science, 2015, 54: 177-185. DOI:10.1016/j.procs.2015.06.020 |
[14] |
CARPERTER B, JIANG S. Significance of IPv6 interface identifiers[J]. Internet Engineering Task Force, 2014, 65: 1-10. |
[15] |
DUNLOP M, GROAT S, MARCHANY R, et al.The good, the bad, the IPv6[C]//Proceedings of the 9th Annual Communication Networks and Services Research Conference.Washington D.C., USA: IEEE Press, 2011: 77-84.
|
[16] |
GRANJAL J, MONTEIRO E, SILVA J S. Security for the Internet of things:a survey of existing protocols and open research issues[J]. IEEE Communications Surveys and Tutorials, 2015, 17(3): 1294-1312. DOI:10.1109/COMST.2015.2388550 |
[17] |
NABEEL N, HABAEBI M, MUSTAPHA N C, et al. IoT light weight crypto functions[J]. International Journal of Interactive Mobile Technologies, 2019, 13(4): 117. DOI:10.3991/ijim.v13i04.10524 |
[18] |
ZEITZ K, CANTRELL M, MARCHANY R, et al. Changing the game:a micro moving target IPv6 defense for the IoT[J]. IEEE Wireless Communications Letters, 2018, 7(4): 578-581. DOI:10.1109/LWC.2018.2797916 |
[19] |
BALASCH J, EGE B, EISENBARTH T, et al.Compact implementation and performance evaluation of hash functions in attiny devices[C]//Proceedings of International Conference on Smart Card Research and Advanced Applications.Berlin, Germany: Springer, 2012: 158-172.
|
[20] |
YÜ Ke, WANG Huifeng. Research and Improvement of RPL Routing Protoco[J]. Computer Engineering, 2018, 44(3): 103-108. (in Chinese) 俞柯, 王慧锋. RPL路由协议的研究与改进[J]. 计算机工程, 2018, 44(3): 103-108. |
[21] |
PAI V, SHENOY U K K.6LowPan-performance analysis on low power networks[C]//Proceedings of International Conference on Computer Networks and Communication Technologies.Berlin, Germany: Springer, 2019: 145-156.
|