1 引言

在物联网发展迅速的今天, 物联网设备早已遍布人们日常生活的周围. 物联网设备通常使用低功耗的嵌入式智能设备, 用于执行一些特定的任务, 比如发送、传输以及处理一些在环境中所获得的数据^[1], 从而构成了物联网系统, 以此提高整个网络的运行速度和服务质量.

由于嵌入式物联网设备的低成本, 大量的物联网设备应用于日常生活中, 但其内存、计算能力等方面都存在限制, 特别是缺乏安全机制^[2]. 从而导致嵌入式设备系统容易成为网络攻击的目标, 如Mirai^[3], 将僵尸程序传播至网络, 感染在线设备, 从而形成僵尸网络, 导致很多网络服务功能瘫痪, 无法进行正常工作, 从而造成无法挽回的损失.

而远程证明能够证明设备完整性这一特性, 恰好可以用于解决嵌入物联网设备的安全问题. 利用远程证明基于证明者提供的可信度建立起一个安全的交互式协议^[4]. 目前学术界已经提出了很多的远程证明协议, 大体可以分为3类: (1) 基于软件的证明, 无需硬件支持, 但往往基于实践中难以实现的假设, 如SAKE^[5]、VIPER^[6]; (2) 基于硬件的证明, 由于其昂贵且复杂的特性, 对于资源受限的嵌入式物联网设备不太实用, 如TrustVisor^[7]、Flicker^[8]; (3) 混合证明, 旨在提供最小化的硬件支持来弥补纯软件证明的安全性不足, 实现与基于硬件相似的安全保护, 如TrustLite^[9]、TyTAN^[10].

本文提出了一种基于信誉机制和Merkle树的安全集群证明及修复方案, 主要贡献如下:

(1) 本文方法使用信誉机制实现了多对一的证明协议, 能有效解决单点故障, 消除了固定的验证设备, 可以从设备触发验证, 使得证明更加及时, 并且适用于半动态网络.

(2) 引入Merkle树进行度量, 能够快速精确地判断出被恶意软件感染的代码块, 再形成定制的补丁进行恢复, 不仅减少数据传输, 还能高效地修复受损设备.

(3) 本文还对提出的集群证明方法进行了安全性分析和性能评估, 结果表明, 本文集群证明在提高了安全性的同时所导致的性能开销是可以接受的.

本文结构如下: 第2节介绍集群证明的相关工作; 第3节给出本文基于的系统模型与假设; 第4节详细给出本文提出的集群证明协议与修复机制; 第5节对本文提出的协议进行安全性分析; 第6节为性能评估, 包括计算、通信、内存、运行时间以及能源开销方面的分析、本方案与ESDRA^[11]及HEALED^[12]的安全性对比以及仿真模拟的实验结果; 第7节对本文工作进行总结.

2 相关工作

集群证明. 纵观集群证明的发展历程, 随着第一个集群证明协议SEDA^[13]提出至今, 不少集群证明的方案呈现在公众的视野中. 大多数都是以SEDA为基础的一对多证明协议. 这些证明协议以验证者为根构造生成树, 从根往下进行证明, 最后不断将证明结果汇聚至验证者, 这也就意味着这类协议只能应用于静态网络. 比如, SeED^[14]在SEDA的基础上增加了抵抗DoS攻击, 从而形成了非交互式的拒绝服务攻击的认证方案. 在2019年, ESDRA提出了第一个多对一的集群证明协议, 通过设备端发起的证明, 从而可以适用于半动态的网络. POSTER^[15], SALAD^[16]都是基于设备的自身认证, 积累个体验证报告, 最后共享至整个网络, 从而实现适用于动态网络的认证协议.

安全修复. 目前大多数协议只提出了证明方案, 对于后续的修复没有详细的介绍.已有的修复协议方案, 如HEALED, 利用集群相同软件配置的可信设备对其进行修复, 从而将受损设备回滚至可信状态.

3 系统模型与假设

在大规模的集群 $ S $ 中包含着软硬件配置不同的异构设备, 并且在通信过程中, 能耗随距离增加而急剧增加. 面对着无处不在的各式攻击, 如果让管理者一一验证, 不仅存在验证不及时的风险, 并且验证者的性能将成为整体认证方案效率的瓶颈. 为了提高验证效率以及降低功耗, 我们将集群 $ S $ 中的每个设备按照通信距离分成若干个簇, 每个簇都有一个簇头节点. 在簇内, 各个设备节点之间相互证明从而构建出集群的可信环境. 此外, 检测到受损设备应当给予修复的机会, 若是修复不了, 即可判定修复成本大于他自身的价值, 可以进行移除操作. 当然, 为了识别集群中由于遭受物理攻击而探测不到的设备, 实施在线探测及时识别可能受到攻击的设备, 并进行隔离验证.

在本文集群证明系统中, 主要的参与者包含: 网络管理者 $ M $ , 负责初始化以及修复集群中受损的设备节点; 簇头节点 $ {D_i} $ , 负责管理簇内设备; 组内普通节点 $ {D_{ij}} $ , 由簇头节点 $ {D_i} $ 进行管理.

本文方法基于以下几点假设:

(1) 假设所有节点都满足安全远程证明的最低硬件要求, 即只读存储器和简单的内存保护单元, 可以通过SMART^[17]等机制实现.

(2) 假设证明例程为原子程序运行, 并且证明代码无法被修改.

(3) 为了确保证明结果的可靠性, 假设每个节点应至少有3个邻居设备.

(4) 假设物理攻击会导致设备一段时间不可用, 从而攻击期间无法探测到设备.

(5) 由于DDoS攻击几乎不可能被完全抵抗, 与其他集群证明方案一样, 本文不考虑DDoS攻击.

4 系统方案

本方案提出一个多对一的集群证明及修复方案. 如图1所示, 方案可分为两个阶段: 离线阶段和在线阶段. 在离线阶段完成设备的初始化以及设备之间的连接过程, 从而构建出整个集群的网络. 而在线阶段主要完成对设备的验证以及发现受损设备后进行的修复协议. 此外, 在线阶段还加入了缺失探测机制, 可以及时发现因物理攻击导致不可达的节点, 将其隔离出集群, 再进行修复或者彻底移除操作. 表1定义了本文所用的符号及参数.

4.1 离线阶段

离线阶段包括设备的初始化( $ {\rm{initial}} $ 协议)以及设备连接( ${\rm{join}}$ 协议). 设备初始化过程中, 网络管理者对新增设备进行初始化工作; 设备连接过程是设备之间通过网络管理者提供的安全通道建立连接, 为后续证明及信息交流提供基础.

4.1.1 设备初始化

如图2所示, 当新设备 $ {D_7} $ 要加入网络时, 网络管理者 $ M $ 就会对 $ {D_7} $ 执行 $ {\text{initial}} $ 协议, 生成设备对应的配置信息, 其中包括: 私钥 $ s{k_7} $ , 公钥 $ p{k_7} $ , 身份证书 $ cert(p{k_7}) $ , 代码证书 $ cert({c_7}) $ , 网路管理员公钥 $ p{k_M} $ , 初始信誉值 $ {w_7} $ , 最后验证时间 $ {t_{{a_7}}} $ 以及唯一设备标识符 $ {d_7} $ , $ M $ 保存软件配置代码 $ {c_7} $ , 便于后续修复( $ {\text{heal}} $ )协议的使用. 对新设备的初始化可以表述为:

$ \begin{split} {{initial}}&({D_i}:{c_i}, {1^\ell };M:p{k_M}) \to \\ &({D_i}:s{k_i}, p{k_i}, cert(p{k_i}), cert({c_i}), p{k_M}, {w_i}, {t_{{a_i}}}, {d_i};M, {c_i}) \end{split} $

每个设备的公私钥对都是基于SM2 ECC密钥体制^[18]生成. 代码证书 $ cert({c_i}) $ 包含设备的可信散列代码 $ {c_i} $ 以及证书的公共信息. $ {t_{{a_i}}} $ 和 $ {t_e} $ 主要是在证明阶段提供可靠的标准, 当前时刻为 $ {t_{{a_i}}} + {t_e} $ 时, 就会对该设备执行设备证明( $ {\text{attest}} $ 协议). 由于触发验证条件在于设备本身, 集群内就可以并发执行 $ {\text{attest}} $ 协议. 此外, 每个设备的信誉值取决于它参与的每次证明例程. 在证明例程中, 任何一个节点没有权限为其他节点报告信誉值. 一旦发现某个节点是不可信的, 其信用值将被设置为 $- {w_{{\rm{max}}}}$ . 在我们的方案中, 信誉值更高节点在邻居节点的最终证明结果生成中拥有更大的权重.

4.1.2 设备连接

当设备 $ {D_i} $ 初始化或者更新后, 通过网络管理者 $ M $ 提供的安全通道, 与邻居设备进行配置信息的交换. 如图2所示, $ {D_7} $ 初始化后, 与邻居设备 $ {D_4} $ 和 $ {D_5} $ 进行连接. 在连接过程中, 它们双方交换自身的公钥 $ p{k_i} $ 、身份证书 $ cert(p{k_i}) $ 、代码证书 $ cert({c_i}) $ 、当前信誉值 $ {w_i} $ 、最后验证时间 $ {t_{{a_i}}} $ 以及唯一设备标识符 $ {d_i} $ . 设备的配置信息存储在受硬件保护的内存之中, 这就意味着设备节点无法虚报配置信息. 通过已认证的密钥协商协议生成基于双方私钥的会话密钥 $ k $ , 在本文中使用非相邻形式椭圆曲线Diffie-Hellman密钥交换协议^[19]. 在后面的证明和修复过程中, $ k $ 是双方进行数据交流的保证. 设备连接过程可描述为:

$ \begin{split} {{join}}&[{D_i}:s{k_i}, {D_j}:s{k_j}, *:cert(p{k_i}), cert(p{k_j}), cert({c_i}),\\ &cert({c_j}), {d_i}, {d_j}, {w_i}, {w_j}] \to [{D_i}:{k_{ij}}, {D_j}:{k_{ij}}] \end{split} $

网络管理者 $ M $ 会周期性地根据簇头选择算法来选取簇头, 使得簇头的分布能覆盖整个集群, 本文采用基于最佳簇半径的无线传感器网络分簇路由算法^[20]. 簇头节点通过信息的传输形成了以 $ M $ 为根节点的树形结构, 其他普通设备节点以传输距离为参照连接到对应的簇, 从而形成集群. 普通设备保存簇头的公钥 $ p{k_M} $ , 便于后期提交证明报告. 对于网络管理者 $ M $ , 存储集群中所有设备当前的信誉值, 在每次证明例程后会更新对应设备的信誉值. 当簇头发现不可信的设备节点时, 其信誉值将被设为 $ - {w_{\rm{max}}} $ , 将 $ {w_i} $ 以及 $ {d_i} $ 发送给 $ M $ , 然后 $ M $ 对其进行隔离, 再执行 $ {\text{heal}} $ 协议或者移除网络等操作.

4.2 在线阶段

在线阶段包括对设备进行验证( $ {\text{attest}} $ )、对设备的修复( $ {\text{heal}} $ )以及缺失探测3个子协议. 一旦有设备 $ {D_i} $ 触发验证条件, 邻居设备就会对其执行 $ {\text{attest}} $ 协议, 每个邻居生成临时的证明结果上传至簇头, 由簇头生成最终的验证结果, 最后将 $ {D_i} $ 的最新信誉值上报网络管理者 $ M $ . $ M $ 接收到 $ {D_i} $ 的最新信誉值, 若等于信誉值最大值 $ - {w_{\rm{max}}} $ , $ M $ 就会对 $ {D_i} $ 执行 $ {\text{heal}} $ 协议, $ {D_i} $ 将最终修复结果反馈 $ M $ . 在缺失探测中采用心跳协议来进行, $ M $ 广播心跳请求, 由簇头节点负责收集反馈, 找出不可达节点, 从而对其进行修复或移除等操作.

在此, 我们引入Merkle树对设备当前的软件状态进行度量. 由于Merkle树能够自下而上计算度量值, 从而汇聚到根节点. 因此, 在证明阶段, 邻居设备仅需验证根节点的度量值即可形成临时验证报告. 在修复阶段, 如图3所示, 证明设备 $ {D_i} $ 将待证明的代码分成 $ \omega $ 段等长的部分: $ {c_1}, {c_2}, \cdots , {c_\omega } $ , 并对应计算哈希值: $ {h_i}[\omega + 1], {h_i}[\omega + 2], \cdots , {h_i}[2\omega ] $ , 然后以这些哈希值为叶子节点, $c'_i$ 为根, 构造Merkle哈希树, 其中, $ 2\omega $ 表示Merkle hash tree (MHT)中除根节点之外的节点数. 受恶意软件感染的代码段会导致沿着根路径生成错误的哈希值. 通过这种方式, 可以确认受恶意软件感染的代码段.

4.2.1 设备证明

每当设备 $ {D_i} $ 的信誉值 ${w_i} < {w_{{\rm{min}}}}$ 或者到达验证时刻, 邻居设备 $ {D_j} $ 就会对 $ {D_i} $ 发出挑战, 并记录发送时间, 挑战包含随机数 $ {N_{ij}} $ . $ {D_i} $ 结合挑战和自身当前状态 $c'_i$ 以及会话密钥 $ {k_{ij}} $ 生成消息验证码 $ {\mu _{ij}} $ 来报告其软件状态, 在此采取基于MHT进行度量, 最终度量为以 $c'_i$ 为根节点的树. $ {D_j} $ 接收到结果后, 通过连接阶段保存的 $ {c_{ij}} $ 以及密钥 $ {k_{ij}} $ 验证 $\; {\mu _{ij}} $ 的正确性, 若 $ \;{\mu _{ij}} $ 验证成功, 则 $ {D_j} $ 生成临时验证结果 $ {b_{ij}} = 1 $ , 反之则推断 $ {D_i} $ 受到攻击, 即 $ {b_{ij}} = - 1 $ , 而当 $ {D_i} $ 无响应, 即为超时, 则 $ {b_{ij}} = 0 $ . 形式化为:

$ \begin{split} {\textit{attest}}&[{D_i}:c'_i, cert({c_i}), {k_{ij}};{D_j}:{N_{ij}}, {c_{ij}}, {k_{ij}}, *: - ] \to\\ &[{D_i}:{\mu _{ij}}, {D_j}:b] . \end{split} $

簇头接收所有邻居节点的临时证明结果后, 通过信誉机制进行最终验证结果, 每个邻居设备的信誉值代表着其参与生成最终验证结果的权重. 最后广播 $ {D_i} $ 的唯一设备标识 $ {d_i} $ 以及当前的信誉值 $ {w_i} $ . 对于邻居设备 $ {D_j} $ , 簇头会将最终验证结果 $ f $ 与各邻居节点的临时证明作对比, 做出相对应的奖惩措施. 最终验证结果及新信誉值计算公式如下:

$ f = \left\{ {\begin{array}{*{20}{c}} {1, }&{\frac{{\displaystyle\sum\nolimits_{j = 1}^x {({b_{ij}}{w_j})} }}{{\lambda {w_{{\rm{med}}}}}} \geqslant 1} \\ { - 1, }&{\frac{{\displaystyle\sum\nolimits_{j = 1}^x {({b_{ij}}{w_j})} }}{{\lambda {w_{{\rm{med}}}}}} < 1} \end{array}} \right. $

$ {w_i} = \left\{ {\begin{array}{*{20}{l}} {({w_{{\rm{max}}}} - {w_{{\rm{min}}}})\frac{{\displaystyle\sum\nolimits_{j = 1}^x {({b_{ij}}{w_j})} }}{{{w_{{\rm{med}}}}}} + {w_{{\rm{min}}}}, }&{f = 1} \\ { - {w_{{\rm{max}}}}, }&{f = - 1} \end{array}} \right. $

其中, $ x $ 为 $ {D_i} $ 邻居数量, ${w_{{\rm{med}}}}$ 为邻居节点信誉值中位数, 它能够对于高信誉值的设备起到制衡作用, $ \lambda $ 为调和参数, 且 $ \lambda \in (0, 1] $ , 随 $ \lambda $ 增加验证的条件越是严格. $ {\text{attest}} $ 协议流程如算法1所示.

算法1. 邻居设备 $\scriptstyle {D_j} $ 对 $\scriptstyle {D_i} $ 的 $\scriptstyle {\text{attest}} $ 算法

输入: $\scriptstyle {N_{ij}} $ ; $\scriptstyle c'_i$ ; $\scriptstyle {c_{ij}} $ ; $\scriptstyle {k_{ij}} $

输出: $\scriptstyle b $

1:　 // $\scriptstyle {D_j} $ 运行程序

2: 　发送 $\scriptstyle re{q_{ij}} = {mac} ({k_{ij}};{N_{ij}}) $ , $\scriptstyle {N_{ij}} $ 给 $\scriptstyle {D_i} $ ;

3:　 $\scriptstyle {startTimer} () $ ;

4:　 if $\scriptstyle {Timerout} () = 1 $ then $\scriptstyle {b_{ij}} = 0 $ ;

5: 　 else if $\scriptstyle {Vermac} ({k_{ij}};{N_{ij}}||{c_{ij}}, {\mu _{ij}}) = 1 $ then $\scriptstyle {b_{ij}} = 1 $ ;

6: 　 else $\scriptstyle {b_{ij}} = - 1 $ ;

7: 　 end if

8: 　将 $\scriptstyle {b_{ij}} $ 发送至簇头

9:　 // $\scriptstyle {D_i} $ 运行程序

10: if $\scriptstyle {Vermac} ({k_{ij}};|re{q_{ij}}) = 1 $ then

11: 　　 $\scriptstyle {\mu _{ij}} = {mac} ({k_{ij}};{N_{ij}}||c'_i)$

12: end if

4.2.2 设备修复

网络管理者 $ M $ 接收簇头上报证明结果, 包括证明设备 $ {D_i} $ 的更新信誉值 $ {w_i} $ 以及唯一设备标识符 $ {d_i} $ . 当 ${w_i} = - {w_{{\rm{max}}}}$ , $ M $ 对 $ {D_i} $ 执行heal协议. 具体流程如下.

由于每个设备都有 $ M $ 的公钥, 因此 $ M $ 可以在集群中与任意设备进行通信, $ M $ 向 $ {D_i} $ 发送一个请求信息 $ re{q_i} $ . $ {D_i} $ 接收后将其软件配置 $ c'_i $ 和一个新的随机数 $ {N_i} $ 利用MHT算法度量后用 $ M $ 的公钥加密后发送给 $ M $ . $ M $ 将自己保存的软件配置 $ {c_i} $ 以同样方式度量进行MHT的遍历, 直到到达叶子节点. 最后, $ M $ 为每个异常的叶子节点添加一个代码段 $ l $ , 用自身私钥 $ s{k_M} $ 对 $ l $ 进行签名生成补丁 $ \Gamma $ , 并将其发送回 $ {D_i} $ . 一个代码段 $ l = \left\{ {s, e, p} \right\} $ 包含其起始地址 $ s $ 、结束地址 $ e $ , 其代码 $ p $ . $ {D_i} $ 进行补丁修复, 修复成功输出 $ r = 1 $ . 否则, 输出 $ r = 0 $ . $ {\text{heal}} $ 过程可以通过如下公式表述为:

$ \begin{split} &{{heal}}[M:s{k_M}, {c_i}, \{ {h_M}[0], \cdots , {h_M}[2\omega ]\} ;{D_i}:p{k_M}, c'_i, \\ &\{ {h_i}[0], \cdots , {h_i}[2\omega ]\} ;*: - ] \to [M, {N_i}, \Gamma ;{D_i}:r] \end{split} $

$ {D_i} $ 可以谎报修复结果来躲避补丁修复, 因此, 当 $ {\text{heal}} $ 结束后, 将 $ {D_i} $ 的信誉值设置为0, 这样 $ {D_i} $ 就会触发 $ {\text{attest}} $ 协议, 对 $ {D_i} $ 进行再次证明, 若证明可信, 则说明 $ {D_i} $ 已经恢复正常的软件配置. 反之, $ {D_i} $ 的信誉值将被设置为 $- {w_{{\rm{max}}}}$ , 从而需要进行再次修复, 直到其配置正常. 此外, 为了避免同一设备 $ {\text{attest}} $ 与 $ {\text{heal}} $ 反复执行, $ M $ 记录设备执行 $ {\text{heal}} $ 的时间, 如果出现连续3次执行 $ {\text{heal}} $ 失败, 将直接移除该设备. $ {\text{heal}} $ 协议的算法流程如算法2所示.

算法2. 网络管理者 $\scriptstyle M $ 对 $\scriptstyle {D_i} $ 的 $\scriptstyle {\text{heal}} $ 算法

输入: $\scriptstyle {N_i} $ ; $\scriptstyle c'_i$ ; $\scriptstyle \{ {h_i}[0], \cdots , {h_i}[2\omega ]\} $ ; $\scriptstyle p{k_M} $ ; $\scriptstyle {c_i} $ ; $\scriptstyle \{ {h_M}[0], \cdots , {h_M}[2\omega ]\} $

输出: $\scriptstyle r $

1:　 // $\scriptstyle M $ 运行程序

2:　 发送 $\scriptstyle re{q_i} = {Sign} (s{k_M};{N_i}) $ 给 $\scriptstyle {D_i} $ ;

3:　 $\scriptstyle {wait} () $ //等待接收反馈

4:　 if $\scriptstyle {decrypt} (s{k_M};d'_i) = 1$ then

5:　　　 while ( $\scriptstyle k < 2\omega $ ) then

6: 　　　　 if ( $\scriptstyle {h_i}[k]! = {h_M}[k] $ ) then

7:　　　　　　 $\scriptstyle k = 2k + 1 $ ;

8: 　　　　 else

9:　　　　　　 $\scriptstyle k + + $ ;

10:　　　　 end if

11: end if

12: $\scriptstyle l = \left\{ {s, e, p} \right\} $ ;

13: 将 $\scriptstyle \Gamma = {Sign} (s{k_M};l) $ 发送至 $\scriptstyle {D_i} $

14: $\scriptstyle {wait} () $ //等待 $\scriptstyle {D_i} $ 回复后

15: if $\scriptstyle r = 0 $ then

16: 　　　 $\scriptstyle {attest} () $ ;

17: end if

18: // $\scriptstyle {D_i} $ 运行程序

19: if $\scriptstyle {VerSign} (p{k_M};{N_i}||re{q_i}) = 1 $ then

20: 　　　 $\scriptstyle {d_i} = {MHT} (c'_i)$ ;

21: 　　　将 $\scriptstyle d'_i = {encrypt} (p{k_M};{d_i})$ 发送至 $\scriptstyle M $

22: end if

23: $\scriptstyle {wait} () $ //等待接收补丁

24: if $\scriptstyle {\textit{VerSign}} (p{k_M};\Gamma ) = 1$ then

25: 　　　 $\scriptstyle {DoPatch} (\Gamma ) $ ;

26:　　　 $\scriptstyle r = 1 $ ;

27: else

28:　　　 $\scriptstyle r = 0 $ ;

29: end if

30: 将 $\scriptstyle r $ 加密后发往 $\scriptstyle M $

4.2.3 在线探测

在线探测阶段负责对整个集群设备进行定期的探测, 监测设备的运行状态. 本文采用基于多级心跳协议^[21], 由网络管理者定期给簇头节点发出心跳信息, 簇头节点在组内广播心跳信息, 并收集组内普通节点的心跳信息, 形成一个alive-node消息, 发给网络管理者. 若在规定的时间未接收到节点设备的心跳信息, 利用多级心跳协议增加和删除节点的便利性, 将其从集群的拓扑网络中删除, 经过验证为可信后, 再重新连接进入集群中.

5 安全性分析

我们将这个过程形式化为一个安全实验 $ EX{P_{ADV}} $ 敌手 $ ADV $ 可以与其相连的设备进行通信, 至少修改一个设备 $ {D_i} $ 的软件配置, $ ADV $ 可以篡改、窃听或删除所有通过 $ {D_i} $ 传输的信息. 经过一个多项式步骤后, $ {D_i} $ 被验证簇头最终验证为1, 即为证明成功. 也就是敌手成功攻破 $ {D_i} $ .

定义1. 安全集群证明. $ F $ 是一个关于 $ {\ell _N}, {\ell _{{\text{sign}}}}, {\ell _{{\text{hmac}}}} $ 的多项式函数. 受损设备通过证明的概率为 $ Pr [f = 1|EX{P_{ADV}}({1^\ell }) = b] $ 在 $ \ell = F({\ell _N}, {\ell _{{\text{sign}}}}, {\ell _{{\text{hmac}}}}) $ 中被认为是可以忽略的, 则证明和修复方案是安全的.

定理1. 如果底层签名、加密和MHTMAC方案是选择性防伪的, 则本方案是一个安全的集群证明方案.

证明: $ ADV $ 可以通过欺骗邻居节点返回 $ b = 1 $ 或欺骗网络管理者返回 $ r = 1 $ 来破坏本方案的安全. 下面通过两种情况来分析:

(1) $ ADV $ 攻击 $ {attest} $ : $ ADV $ 想要使得 $ b = 1 $ 来通过邻居节点的验证可以使用以下策略: 1) 使用基于原始代码的先前的HMAC ${\mu _{{\rm{old}}}}$ ; 2) 计算出基于新挑战的HMAC $ {\mu '} $ ; 3) 入侵多个邻居节点, 影响最终的证明结果.

对于策略1), 每次的挑战 $ N $ 都是新的随机值, 当且仅当 $N = {N_{{\rm{old}}}}$ 时, 验证可以通过. 然而 $N = {N_{{\rm{old}}}}$ 的概率为 $ {2^{ - {\ell _N}}} $ . 所以通过验证的概率可以忽略. 对于策略2), 一旦软件配置发生改变生成的HMAC无法通过邻居节点的验证, 因此 ${\mu '}$ 通过验证的概率也可以忽略. 对于策略3), 对于单个节点而言, $ Pr [f = 1|EX{P_{ADV}}({1^\ell }) = b] $ 是可以忽略的, 而同时攻破 $ k $ 个节点概率为 $(Pr [f = 1|EX{P_{ADV}}({1^\ell }) = b])^k$ , 也是可以忽略的.

(2) $ ADV $ 攻击 $ {\rm{heal}} $ : $ {\text{heal}} $ 协议由网络管理者 $ M $ 对受损设备 $ {D_i} $ 进行修复, $ ADV $ 可以以下策略来逃避 $ {\text{heal}} $ 协议: 1) 伪造 $ r = 1 $ 返回给 $ M $ ; 2) 在 $ {D_i} $ 安装补丁前篡改补丁.

对于策略1), 虽然可以逃避补丁 $ \Gamma $ 安装, 但是在之后的证明例程依旧被检测出来, 超过3次将被移出集群. 对于策略2), 与 $ {\text{attest}} $ 类似, $ ADV $ 试图提取 $ \Gamma $ 中提取补丁代码再进行修改的概率是可以忽略的.

因此, $ ADV $ 通过攻击 $ {\text{attest}} $ 协议 $ {\text{heal}} $ 协议来攻破良性设备的概率在 $ {\ell _N}, {\ell _{{\text{sign}}}}, {\ell _{{\text{hmac}}}} $ 上可以忽略不计, 再加上在线探测阶段对物理攻击进行检测, 由此可证明本方案是一个安全的集群证明方案.

6 性能评估

本节将从计算开销、通信开销、内存开销、运行时间以及能源开销这几个方面对本协议进行分析, 此外我们还对本文集群证明协议进行了仿真, 并与其他几个类似方法进行了对比.

(1) 计算开销. 对于普通设备而言, 主要计算开销在于一些密码操作. 在证明阶段, 证明设备需要计算 $ {m_i} $ 个 $ {mac} () $ 并验证 $ {m_i} $ 个 ${\textit{Vermac}} ()$ , 其中 $ {m_i} $ 表示 $ {D_i} $ 邻居设备的数量. 邻居设备验证一个 ${\textit{Vermac}} ()$ 并计算一个 ${\textit{Sign}} ()$ . 对于簇头设备, 需要验证 $ {m_i} $ 个 ${\textit{VerSign}} ()$ 并计算2个 ${{{\textit{Sign}}()}}$ , 一个发往网络管理者 $ M $ , 一个广播到组内各个节点. 在修复阶段, 修复设备需计算2个 $ {encrypt} () $ 验证2个 $ {decrypt} () $ , 而 $ M $ 需要验证2个 ${{\textit{VerSign}}} ()$ 并计算2个 ${{\textit{Sign}}} ()$ .

(2) 通信开销. 我们使用SM3实现MHTMAC, 密钥协商算法和签名方案都是采用基于SM2的算法. 以 $ len(x) = 1 $ 表示 $ x $ 的长度为1 B. 因此, $ len({\text{MHTMAC}}) = 32\omega - 16 $ , 其中 $ \omega $ 为验证代码分割的段数, $ len({{Sign}}) = 64 $ , $ len(N) = 16 $ , $ len(\mu ) = 16 $ , $ len(w) = 4 $ , $ len(t) = 4 $ , $ len(d) = 4 $ , $ len(b) = 4 $ , $ len(r) = 4 $ . 证书的大小取决于密钥和签名, 所以 $ len(cert) = 48 $ . 因此, 在证明阶段, 证明设备而言, 需发送 $ (32\omega - 16){m_i} $ B以及接收 $ 16{m_i} $ B; 邻居设备而言, 需发送20 B以及接收 $ (32\omega - 16) $ B; 簇头节点需发送 $ (128 + 8{n_i}) $ B接收 $ 4{m_i} $ B; 网络管理者 $ M $ 接收64 B. 在修复阶段, 修复设备需接收36 B以及发送 $ (32\omega - 12) $ B, $ M $ 发送36 B以及接收 $ (32\omega - 12) $ B.

(3) 内存开销. 每个普通设备需要存储: 1)自己的密钥对 $ (s{k_i}, p{k_i}) $ 和设备标识符 $ {d_i} $ ; 2)邻居设备的设备标识符 $ {d_j} $ 及其信用值 $ {w_j} $ 、最近证明时间 $ {t_{{a_j}}} $ 、代码证书 $ cert({h_j}) $ 和会话密钥 $ {k_{ij}} $ ; 3) 簇头的公钥. 簇头设备还需要存储簇内所有节点的设备标识、相应的信用值和公钥. 因此, 普通节点需要 $ (52 + 80{m_i}) $ B的存储空间, 簇头节点需要 $ (52 + 80{m_i} + 24{n_i}) $ B的存储空间.

(4) 运行时间. 我们使用 $ {t_h} $ 、 $ {t_p} $ 、 $ {t_{ca}} $ 、 $ {t_{tr}} $ 、 $ {t_s} $ 、 $ {t_v} $ 来表示计算或验证 MHTMAC、生成随机数、一跳访问信道并传输一个字节、签名或验证签名的时间. $ H $ 是群的生成树的高度. 因此, 总证明时间 $ {t_{{\text{attest}}}} $ 为:

$ \begin{split} {t_{{\text{attest}}}} \leqslant & {m_i}({t_h} + {t_p} + {t_{ca}}) + ((32\omega - 8){m_i} + 64H){t_{tr}} \\ &+ ({m_i} + 2){t_s} + ({m_i} + {n_i} + 1){t_v} . \end{split} $

总修复时间 $ {t_{{\text{heal}}}} $ 为:

$ {t_{{\text{heal}}}} \leqslant {t_{ca}} + {t_h} + {t_p} + (32\omega + 24)H{t_{tr}} + 4{t_s} + 4{t_v} $

(5) 能源开销. 我们分别使用 $ {E_s} $ 、 $ {E_r} $ 、 $ {E_p} $ 、 $ {E_h} $ 、 $ {E_{sg}} $ 、 $ {E_v} $ 表示发送 1 B、接收 1 B、生成随机数、计算或验证 MHTMAC 以及签名和验证或签名的能源开销. 在一个证明过程中, 簇头节点的最大能耗为:

$ E \leqslant (128 + 8({n_i} + 1){E_s}) + 4{m_i}{E_r} + 2{E_{sg}} + {t_v}{m_i}{E_v} $

证明设备的最大能耗为:

$ {E_i} \leqslant (32\omega - 16){m_i}{E_s} + 16{m_i}{E_r} + {m_i}{E_h} + {E_v} $

邻居设备的最大能耗为:

$ {E_j} \leqslant 20{E_s} + (32\omega - 16){E_r} + {E_p} + {E_{sg}} + {E_v} $

在一个修复过程中, 修复设备的最大能耗为:

$ {E_i} \leqslant (32\omega + 24){E_s} + (32\omega + 24){E_r} + {E_p} + {E_h} + 4{E_{sg}} + 4{E_v} $

本方案还与ESDRA、SEDA、SALAD在运行时间、平均能耗等方面进行比较, 具体数据展示如表2所示.

(6) 安全性对比. 我们将本方案与ESDRA、HEALED进行安全性对比. 如表3所示, 在我们的方案中, 增加了在线探测技术, 可以针对物理攻击造成探测不到的设备进行识别, 从而预防物理攻击. 在ESDRA中, 簇头与所有簇内设备公用一个会话密码, 存在会话密钥泄露的风险, 本方案改用簇头的公钥进行加密, 仅有簇头本身能够解密, 解决了会话密钥窃取的风险. 此外, 在ESDRA中, 证明设备的新信誉值计算存在高信誉值影响整个结果的风险, 一旦攻击者入侵高信誉值设备, 足以影响整个集群的安全性, 本方案引入中位数, 计算每个证明设备的邻居设备信誉值的中位数, 以此作为基准, 从而规避高信誉值设备“一票否定”的情况, 而在HEALED中, 利用传递性, 也同样存在高信任度的设备, 再加上证明节点的任意性, 很难快速找到受损设备.

(7) 仿真结果. 我们使用OMNet++^[22]对本文集群证明协议进行了仿真模拟, 并与ESDRA、SEDA、SALAD几个代表性工作进行了比较. 在仿真过程中, 我们使用嵌入式开发板上测得的密码算法性能数据^[23]进行仿真, 相关密码算法在嵌入式开发板上的数据如表4所示.

对于本方案, 我们设置初始信誉值为3, 最大信誉值 ${w_{{\rm{max}}}}$ 为5, 最小信誉值 ${w_{{\rm{min}}}}$ 为1, 调和参数 $ \lambda $ 为0.8, 奖励信誉值为1, 惩罚信誉值为2. 通过仿真模拟, 以上4个方案得出数据如图4、图5所示.

图4展现了本方案与ESDRA、SEDA以及SALAD关于证明设备不同邻居数量的验证时间. 相较于ESDRA, 由于本方案在上报临时验证结果是采用簇头的公钥进行加密, 并且后期广播证明设备的验证结果采用簇头签名, 因此运行时间有所增加, 但在总体看来, 为了提高协议的安全性, 这些性能牺牲还是在可以接收的范围内, 并且分布式证明的优势依旧可以体现. 图5描绘了本方案与ESDRA、SEDA以及SALAD关于不同的集群设备数量所进行的证明时间, 本方案对于集群数量的增大, 受影响的幅度较小.

7 总结

本文提出了一种基于信誉机制和Merkle树的安全集群证明及修复方案. 利用信誉机制实现了多对一的证明协议, 不仅能有效解决单点故障, 可以从设备触发验证, 并且适用于半动态网络. 引入Merkle树进行度量, 能够快速精确地识别被恶意软件感染的代码块, 并进行高效地恢复到可信状态. 通过对方案的安全性分析和性能评估, 结果表明, 本文集群证明在提高了安全性的同时导致的性能开销是可以接受的.