1.   引言

因其操作的灵活性以及功能的多样性，无人机在民用和军事领域都有广泛的应用^[1,2]，如环境监测、应急通信、联合搜救等。无人机与地面控制站(Ground Control Station, GCS)、卫星等共同构成了无人机网络^[3]，它具有动态拓扑性、高机动性、能快速部署等特点^[4]，可以分为两种结构：平面结构与分层结构^[5]。平面的无人机网络可扩展性不强，组织较为简单，不适用于大规模的任务执行。分层结构通过分簇^[6]的方法可以将多个无人机节点划分为若干个簇，多个簇头与多个簇成员间构成了一种分层的无人机网络。它的可扩展性更强，更适用于大规模作业^[7]。

在分层无人机网络中，由于无人机信道的固有开放性，其中的通信面临着很多安全问题^[8]。在此场景下，群组密钥(即簇密钥)作为保障无人机簇内部以及簇间安全通信的第1道防线显得尤为重要，而群组密钥管理机制作为保障群组通信安全的关键技术，在分层无人机网络中也扮演着重要的角色。因此，设计一个安全有效的群组密钥管理方案成为当下亟待解决的重要问题。

现有的群组密钥管理方案主要分为3类^[9]。第1类是集中式的群组密钥管理方案^[10-13]。这类方案存在两个问题：(1) 群组控制器必须是持续可用的，否则容易造成单点故障；(2) 跨域密钥传输时延比较大、密钥管理较为复杂。第2类是去中心的群组密钥管理方案^[14]。这类方案的优点是每个子组使用独立的群组密钥，当某个子组遭受威胁时不会影响其他组成员；缺点是组成员必须要完全信任群组控制器，这容易带来安全风险。第3类是分布式的群组密钥管理方案^[15-18]。文献[17]提出一种动态的分布式群组密钥协商协议，该方案中每个组成员为计算群组密钥时都会传输较多的密钥材料，因此会造成较高的通信开销。异步棘轮树(Asynchronous Ratchet Tree, ART)^[18]是一个多方可以共同派生一个群组密钥的分布式协议。该协议的群组密钥可以在多个组成员并不同时在线的情况下，由一个发起方成员进行预部署，再由其余组成员对该密钥进行异步计算。相较于上述的群组密钥协商协议来说，ART是基于树的协议，因此通信开销会相对较小；其异步计算机制使大多数组成员可以不用同时在线而自主计算群组密钥，从而解决群组成员离线导致整个群组无法计算、及时更新组密钥的问题。但是ART的异步计算机制也有一个缺点：在派生群组密钥过程中大多数的组成员都会完全信任预部署组密钥的成员，从而增加了安全风险。

区块链^[19]作为一种去中心化的分布式数字分类账技术被广泛应用于分布式网络中以记录交易数据，并能保证该数据可追溯且不可篡改。文献[20]采用了区块链的去中心化技术减少自组网中每个参与者的计算与通信开销，由于缺少参与者自主更新密钥的过程，不适用于动态的分层无人机网络。文献[21]基于区块链提出了一种适用于资源受限设备的动态群组密钥协商协议，该协议将参与者计算组密钥时的通信和验证密钥材料的开销迁移到区块链网络，减轻了计算负担。文献[22]提出了基于区块链的非对称的群组密钥协商协议，其中每个组成员计算群组密钥时都会有较大的通信开销，且未实现动态的密钥更新过程。这些方案虽都以区块链去中心的特性解决了单点故障问题，但成员离线造成群组密钥无法及时更新的问题仍然存在。

上述提及的群组密钥管理方案都各有优缺点。将这些方案应用到分层无人机网络场景下进行分析，其中集中式的方案易造成GCS单点故障、密钥管理复杂等问题；去中心的方案可能会产生对簇头无人机的信任问题；分布式方案中存在簇成员无人机离线时导致整个簇无法计算、及时更新组密钥的问题，虽ART在其中表现优异，但也存在信任问题。区块链的出现刚好能弥补这一缺陷，但上述基于区块链的方案或是没有动态的密钥更新过程，抑或是存在和分布式方案相同的问题，都不适用于分层无人机网络。为解决这些问题，本文结合区块链技术与ART协议提出了面向分层无人机网络的去中心群组密钥管理方案。首先，利用簇头无人机作为区块链网络中的对等节点共同管理群组密钥，以区块链的去中心特性解决了GCS的单点故障问题；以委托权益证明(Delegated Proof Of Stake, DPOS)共识机制^[23]解决了信任问题。其次，利用簇头无人机作为ART的发起方实现对群组密钥的预部署，以实现簇成员无人机对群组密钥的异步计算、自主更新。最后，性能评估表明，与同类方案相比，本方案具有较低的计算、通信开销，交易处理时间。

2.   去中心群组密钥管理方案

如图1所示，本文方案包含3个参与实体：GCS，簇头无人机，簇成员无人机。

图 1  群组密钥管理系统模型

下载: 全尺寸图片 幻灯片

(1)GCS：提供无人机节点的注册与身份认证，并将注册的无人机划分为$m$个簇，为每个簇分配一个任务区域。每个簇有$n$个节点，其中包括1个簇头无人机与$n - 1$个簇成员无人机。GCS可以通过无线链路向无人机发送指令或接收其采集到的数据信息。

(2)簇头无人机：具有较高的计算能力与存储能力，能够提前部署无人机簇，并计算群组密钥。簇头节点作为系统中的区块链共识节点，维护密钥管理区块链。簇头之间可以进行簇间通信。

(3)簇成员无人机：具有较强的能量限制，只能执行轻量级任务，并保持区块链的最新状态。每个簇内部的簇成员之间可以相互通信。

在本文讨论的系统模型中，假设上述3类参与实体都是诚实可靠的，并无内部攻击者。而外部攻击者会威胁系统安全，它们可以控制、截取或者篡改簇内部无人机之间的无线通信消息。此外，它们还可以伪装成为簇中的合法无人机，进行重放攻击。

在本方案中，所涉及计算群组密钥的公钥材料都得以由区块链妥善管理。具体而言，由无人机簇头节点作为区块链共识节点维护整个密钥管理区块链，存储公钥列表。

2.1   系统初始化

本阶段由GCS进行初始化，生成所有的系统参数并为后续阶段做准备。此过程是在一个安全环境下离线完成的。

设$p$和$q$都是大素数，且满足$p = 2q + 1$。首先，根据给定的一个安全参数$\lambda$，GCS生成一个素数阶为$q$的乘法循环群${G_q}$，$g$为循环群${G_q}$的一个随机生成元。然后，GCS随机选择${{{\rm{sk}}} _{{\rm{GCS}}}} \leftarrow Z_q^ *$作为主私钥，计算对应的系统公钥为${{{\rm{pk}}} _{{\rm{GCS}}}} = {g^{{\rm{s}}{{\rm{k}}_{{\rm{GCS}}}}}}{\rm mod} p$。与此同时，它将定义一个单向哈希函数$H( \cdot ):{\{ 0,1\} ^ * } \to Z_q^ *$。最后，GCS输出系统参数：$({G_q},p,q,g,{{{\rm{pk}}} _{{\rm{GCS}}}},H( \cdot ))$，并将${{{\rm{sk}}} _{{\rm{GCS}}}}$保密。

2.2   无人机注册

在该阶段，批量无人机与GCS进行交互并在其处注册，此交互过程均在安全信道完成。此阶段完成后，无人机将加入由GCS划分的分层无人机网络执行任务。

(1)无人机${{{\rm{Dr}}} _i}$将其身份标识${{{\rm{ID}}} _i}$通过安全信道发送给GCS。

(2)GCS对${{{\rm{ID}}} _i}$进行核验，检查${{{\rm{ID}}} _i}$是否已被注册。若尚未注册，即随机选择${{{\rm{ik}}} _i} \leftarrow Z_q^ *$作为每个无人机节点的长期身份私钥，并计算公钥${{{\rm{IK}}} _i} = {g^{{{{{\rm{ik}}} }_i}}} {\rm mod} p$，随后保存数据项。最后由安全信道返回$\{ {{{\rm{ID}}} _i},{{{\rm{ik}}} _i},{{{\rm{IK}}} _i}\}$。

(3)${{{\rm{Dr}}} _i}$收到注册密钥$\{ {{{\rm{ik}}} _i},{{{\rm{IK}}} _i}\}$并保存。

当每个无人机${{{\rm{Dr}}} _i}$在GCS完成注册等一系列操作后都将变成授权的节点并获得相关的身份密钥对，此时GCS将会记录每个无人机的注册数据项，其他无人机节点可以根据无人机ID检索其公钥。此外，每个无人机将会随机选择${{{\rm{ek}}} _i} \leftarrow Z_q^ *$作为临时私钥，对应地，生成临时公钥为${{{\rm{EK}}} _i} = {g^{{{{{\rm{ek}}} }_i}}}{\rm mod} p$，然后将其发送给GCS，该密钥由GCS统一保存并分发。此时，GCS所保存的数据项为$\{ {{{\rm{ID}}} _i},{{{\rm{ik}}} _i},{{{\rm{IK}}} _i},{{{\rm{EK}}} _i}\}$，值得注意的是， 一旦将无人机临时公钥分发出去，该公钥将会被GCS删除，后续阶段由区块链网络对该密钥进行管理。

批量无人机注册完成后，GCS将这些无人机节点根据其任务需求平均划分为$m$个簇，每个簇有$n$个节点，并执行相应的任务。无人机簇中有两种类型的无人机：簇头无人机节点${{{\rm{ID}}} _{x,0}}$以及簇成员无人机节点${{{\rm{ID}}} _{x,i}}$。完成划分后GCS将给每个无人机簇分配一个具有较高计算能力与存储能力的无人机作为该簇的簇头节点，此时第$x$个簇可以表示为${C_x} = \{ {{{\rm{ID}}} _{x,0}},{{{\rm{ID}}} _{x,1}}, \cdots ,{{{\rm{ID}}} _{x,n - 1}}\}$。

2.3   创世区块生成

当系统中现有的批量无人机节点密钥生成完成后，GCS将为第$x$个簇生成对应的无人机节点的身份公钥列表${{\rm{IKL}} _x} = \{ {{\rm{IK}} _{x,0}},{{\rm{IK}} _{x,1}}, \cdots ,{{\rm{IK}} _{x,n - 1}}\}$、临时公钥列表${{\rm{EKL}} _x} = \{ {{\rm{EK}} _{x,0}},{{\rm{EK}} _{x,1}}, \cdots ,{{\rm{EK}} _{x,n - 1}}\}$，并将包含这两类列表的消息${{{\rm{msg}}} _0} = \{ {{\rm{Init}}} ,{{\rm{pk}} _{\rm{GCS}}}, {\left( {{{{\rm{IKL}} }_x},{{{\rm{EKL}} }_x}} \right)_m}, {{\rm{Sign}} _{{\rm{s}}{{\rm{k}}_{\rm{GCS}}}}}(H({{\rm{pk}} _{\rm{GCS}}},{\left( {{{{\rm{IKL}} }_x},{{{\rm{EKL}} }_x}} \right)_m}))\}$ 发送给见证者节点${{\rm{ID}} _{w,0}}$，其中${\rm{Sign}} ( \cdot )$表示签名算法，$H( \cdot )$表示单向哈希函数。${{\rm{ID}} _{w,0}}$接收到该消息便使用之前GCS发布的公钥${{\rm{pk}} _{\rm{GCS}}}$验证消息中的${{\rm{pk}} _{\rm{GCS}}}$与签名。若验证失败，则丢弃此消息；若验证成功，它将在DPOS共识机制下由${{\rm{ID}} _{w,0}}$打包成一个初始交易${{{\rm{Tx}}} _{{\rm{Init}}}}({{\rm{Init}}} ,{{\rm{ID}} _{w,0}},{{\rm{IK}} _{w,0}},{{\rm{pk}} _{\rm{GCS}}}, ({{\rm{IKL}} _x}, {{\rm{EKL}} _x})_m,T, {{\rm{Sign}} _{{\rm{s}}{{\rm{k}}_{\rm{GCS}}}}}(H({({{\rm{IKL}} _x},{{\rm{EKL}} _x})_m},T)))$，其中$T$表示当前时间戳。${{\rm{ID}} _{w,0}}$将其写入一个新的区块${{\rm{Block}} _0}$后，该见证者将会立即广播该区块。当区块链中有超过50%的共识节点对这个区块验证通过时，就表明${\left( {{{{\rm{IKL}} }_x},{{{\rm{EKL}} }_x}} \right)_m}$已经被记录到了区块链上。第1次产生的区块${{\rm{Block}} _0}$也叫创世区块，该区块存储了$\{ {B_n}({{\rm{Block}} _0}),{{\rm{IK}} _{w,0}},{R_0},{\rm{MTR}} ,{{\rm{Sign}} _{{\rm{i}}{{\rm{k}}_{w,0}}}} ({M_0})\}$：其中${B_n}({{\rm{Block}} _0}) = 0$表示区块的序列号，${R_0}$表示${{\rm{ID}} _{w,0}}$在有限域上选择的一个随机数，${\rm{MTR}}$表示默克尔树根，记录存储在当前区块所有交易的哈希值，此时${\rm{MTR}} = H({{\rm{Tx}}} ({\left( {{{{\rm{IKL}} }_x},{{{\rm{EKL}} }_x}} \right)_m},T))$, ${M_0} = {B_n}({{\rm{Block}} _0})||{{\rm{IK}} _{w,0}}||{R_0}||{\rm{MTR}}$。

2.4   群组密钥生成

当创世区块验证通过并被部署到区块链上后，每个簇的${{\rm{ID}} _{x,0}}$将会提前部署群组密钥${{{\rm{GK}}} _x}$，其余无人机能对其进行异步计算，该密钥将会用于此无人机簇内的安全通信。${{\rm{ID}} _{x,0}}$作为群组内的通信发起方，负责ART的构建，其余簇成员无人机${{\rm{ID}} _{x,i}}$在簇中满足动态的成员关系变化：簇成员无人机的动态加入或者退出。每次簇中的无人机动态的成员关系变化都会形成一个新的无人机簇，所涉及的簇的群组密钥也将随之更改，以保证簇内的安全通信。

以簇${C_1}$为例，假设该簇中的无人机节点为${C_1} = \{ {{\rm{ID}} _{1,0}},{{\rm{ID}} _{1,1}}, \cdots ,{{\rm{ID}} _{1,5}}\}$，由${{\rm{ID}} _{1,0}}$负责ART的构建，对应的树根节点的密钥即为群组密钥。在该密钥树创建之前，${{\rm{ID}} _{1,0}}$将使用从GCS接收到的临时公钥列表${{\rm{EKL}} _1} = \{ {{\rm{EK}} _{1,0}},{{\rm{EK}} _{1,1}}, \cdots ,{{\rm{EK}} _{1,5}}\}$用以构建ART，使用身份公钥列表${{\rm{IKL}} _1} = \{ {{\rm{IK}} _{1,0}},{{\rm{IK}} _{1,1}}, \cdots , {{\rm{IK}} _{1,5}}\}$用于各个无人机节点构建ART时对其身份的认证。密钥树的构建可归结为群组密钥的计算，每个无人机对应于二叉树的叶节点。图2展示了簇${C_1}$群组密钥${{{\rm{GK}}} _1}$的生成过程。

图 2  簇${C_1}$的群组密钥生成

下载: 全尺寸图片 幻灯片

${{{\rm{ID}}} _{1,0}}$完成密钥树ART的构建后，将会向群组内的簇成员无人机发送它们各自的位置索引、${{{\rm{ID}}} _{1,0}}$的临时公钥、该群组的${{\rm{IKL}}}$、密钥树中对应某一节点的辅助路径公钥以便它们能对该群组密钥进行异步计算。为保证群组密钥计算的安全性，${{{\rm{ID}}} _{1,0}}$在发送完密钥后将清除其余簇成员无人机叶节点的私钥。以${{{\rm{ID}}} _{1,2}}$为例，它将会接收到：$\{ 1,2,{{{\rm{IKL}}} _1},{{{\rm{EK}}} _{1,0}}, {g^{{\alpha _{1,3}}}},{g^{l({\alpha _{1,0}}{\alpha _{1,1}})}},{g^{l({\alpha _{1,4}}{\alpha _{1,5}})}}\}$。当${{{\rm{ID}}} _{1,2}}$接收到该消息时，会根据此信息重新计算群组密钥，以减少群组密钥的传输。

类似地，簇头无人机之间也需建立一个群组密钥以维护簇间的群组通信，此时由生成创世区块的见证者节点${{{\rm{ID}}} _{w,0}}$对簇间群组密钥进行预部署，后续计算步骤同上所述，此处将不再赘述。

2.5   群组密钥更新

为了应对无人机的动态变化事件，本节需要提供一种密钥更新的方法来保障无人机簇内部的安全通信。本方案支持以下几种事件的密钥更新操作：

(1)动态加入：一个新的无人机节点加入某一个簇；

(2)动态离开：簇成员无人机从某一个簇中离开；

(3)周期性密钥更新：某一时间范围内，无人机节点既没有加入也没有离开，群组密钥将会更新。

应当注意的是，当无人机加入或者离开某一簇时，该簇的簇头无人机将会更新密钥树以得到最新的群组密钥，且需要通知其他簇的簇头无人机(即区块链共识节点)以更新临时公钥列表，并由见证者节点将这一状态变化交易和修改的列表写入区块链。

2.5.1   无人机动态加入

当新无人机${{{\rm{Dr}}} _{j,1}}$欲加入簇${C_1}$，它需要向GCS发送相关信息以请求注册：身份标识${{{\rm{ID}}} _{j,1}}$、请求加入的无人机簇的标识等。GCS接收到此消息后将会验证其是否合法，若不合法则忽略该请求；若为合法的无人机将会为其生成身份公私钥对$({{{\rm{ik}}} _{j,1}},{{{\rm{IK}}} _{j,1}})$，${{{\rm{ID}}} _{j,1}}$将会自主生成一对临时密钥$({{{\rm{ek}}} _{j,1}},{{{\rm{EK}}} _{j,1}})$然后发送给GCS，并由GCS统一分发给${{{\rm{ID}}} _{1,0}}$。

${{{\rm{Dr}}} _{j,1}}$注册完毕后，GCS将会发送一条${{{\rm{ID}}} _{j,1}}$请求加入消息给该区块链中所对应簇${C_1}$中的共识节点${{{\rm{ID}}} _{1,0}}$: ${{{\rm{msg}}} _1} = \{ {{\rm{JOIN}}} ,{C_1},{{{\rm{ID}}} _{j,1}},{{{\rm{IK}}} _{j,1}},{{{\rm{EK}}} _{j,1}},T,{{{\rm{Sign}}} _{{\rm{s}}{{\rm{k}}_{{\rm{GCS}}}}}} (H({C_1},{{{\rm{ID}}} _{j,1}},{{{\rm{IK}}} _{j,1}},{{{\rm{EK}}} _{j,1}},T))\}$。

${{{\rm{ID}}} _{1,0}}$接收到该消息后将会基于以下规则验证该消息是否有效合法：

(1)检查${{{\rm{IK}}} _{j,1}}$是否属于列表${{{\rm{IKL}}} _x}$，${{{\rm{EK}}} _{j,1}}$是否属于列表${{{\rm{EKL}}} _x}$，若不属于列表则将${{{\rm{ID}}} _{j,1}}$标识为新无人机；

(2)使用之前GCS发布的公钥${{{\rm{pk}}} _{{\rm{GCS}}}}$验证消息中的签名，以检查${{{\rm{ID}}} _{j,1}}$的身份是否有效。

如果其中一条规则验证失败，该消息将会被丢弃；如果两条规则都验证通过，则接受该请求。随后${{{\rm{ID}}} _{1,0}}$将该请求消息打包成一个加入交易${{{\rm{Tx}}} _{Jn}}({{\rm{JOIN}}} , {{{\rm{ID}}} _{1,0}},{{{\rm{ID}}} _{w,0}},{C_1},{{{\rm{IK}}} _{j,1}},{{{\rm{EK}}} _{j,1}},T$, ${{{\rm{Sign}}} _{{{{{\rm{ik}}} }_{1,0}}}}(H({{{\rm{IK}}} _{j,1}}, {{{\rm{EK}}} _{j,1}}, {C_1},T)))$并放入交易池，当本轮见证者节点${{{\rm{ID}}} _{w,0}}$接收到该交易并对其有效性和合法性进行验证。若验证成功就将该交易打包成一个新的区块${{{\rm{Block}}} _1}$，该区块所包含的消息为$\{ H({{{\rm{Block}}} _0}), {B_n}({{{\rm{Block}}} _1}),{{{\rm{IK}}} _{w,0}},{R_1},{{\rm{MTR}}} ,{{{\rm{Sign}}} _{{\rm{i}}{{\rm{k}}_{w,0}}}}({M_1})\}$，其中${{\rm{MTR}}}$记录并存储了当前区块中所有交易的哈希值，${M_1} = H({{{\rm{Block}}} _0})||{B_n}({{{\rm{Block}}} _1})||{{{\rm{IK}}} _{w,0}}||{R_1}||{{\rm{MTR}}}$。

随后，${{\rm{ID}} _{w,0}}$将会广播此区块到整个区块链网络，当区块链中有超过50%的共识节点通过该区块的验证时，该区块就会被${{\rm{ID}} _{w,0}}$写入区块链。届时，${{\rm{ID}} _{1,0}}$在验证${{{\rm{Block}}} _1}$通过时，将会从中提取此前生成的交易并广播给簇中现有的簇成员无人机。${{\rm{ID}} _{1,0}}$会在原有的两个公钥列表中添加${{\rm{ID}} _{j,1}}$对应的公钥，每个簇成员无人机也会根据接收到的交易信息维护相应的${{\rm{IKL}}}$。区块链中的每个共识节点也都会将原来的公钥列表更新为${\left( {{{\rm{IK}}} {{{\rm{L}}'}_x},{{\rm{EK}}} {{{\rm{L}}'}_x}} \right)_m}$并同步到区块链上。图3展示了${{\rm{ID}} _{j,1}}$加入簇${C_1}$时群组密钥${{{\rm{GK}}} _2}$的更新过程。

图 3  无人机${{{\rm{ID}}} _{j,1}}$动态加入(实线框标注部分表示${{{\rm{ID}}} _{j,1}}$密钥更新)

下载: 全尺寸图片 幻灯片

${{{\rm{ID}}} _{j,1}}$在接收到来自${{{\rm{ID}}} _{1,0}}$发送的消息$\{ {{{\rm{ID}}} _{j,1}}, {{\rm{IK}}} {{\rm{L}}'_1},{{{\rm{EK}}} _{1,0}},{g^{{\alpha _{1,4}}}},{g^{{\alpha _{1,5}}}},{g^{{g^{l({g^{{\alpha _{1,0}}{\alpha _{1,1}}}})l({g^{{\alpha _{1,2}}{\alpha _{1,3}}}})}}}}\}$后，将对其身份进行验证，验证成功后，计算自身的叶密钥对以及其直接路径上的密钥，最终计算出群组密钥。

2.5.2   无人机动态离开

若某簇成员无人机${{{\rm{ID}}} _{x,l}}$由于其能源限制或任务需求等离开簇${C_x}$，${{{\rm{ID}}} _{x,l}}$将会发送离开请求消息给${{{\rm{ID}}} _{x,0}}$：${{{\rm{msg}}} _2} = \{ {{\rm{LEAVE}}} ,{{{\rm{ID}}} _{x,l}},{{{\rm{Enc}}} _{{{{{\rm{GK}}} }_x}}}\{ {{{\rm{EK}}} _{x,l}}, {C_x},T, {{{\rm{Sign}}} _{{{{{\rm{ik}}} }_{x,l}}}} (H({{{\rm{EK}}} _{x,l}},{C_x},T))\}$，其中${{{\rm{Enc}}} _{{{{{\rm{GK}}} }_x}}}( \cdot )$表示使用${{{\rm{GK}}} _x}$进行加密。此处以簇成员无人机${{{\rm{ID}}} _{1,5}}$离开簇${C_1}$为例。

${{{\rm{ID}}} _{1,0}}$接收到该消息后将会基于以下规则验证该消息是否有效合法：

(1)使用${{{\rm{GK}}} _2}$解密，检查${{{\rm{EK}}} _{1,5}}$是否存在于${{\rm{EK}}} {{\rm{L}}'_1}$中，若属于该列表，则检查通过；

(2)使用${{{\rm{IK}}} _{1,5}}$验证该消息中的签名，以检查${{{\rm{ID}}} _{1,5}}$的身份是否有效。

若其中某一条规则验证失败，则该消息将会被丢弃；若两条规则都验证通过，则接受该请求消息。随后，${{{\rm{ID}}} _{1,0}}$将该消息生成一个新的交易${{{\rm{Tx}}} _{{\rm{Le}}}} ({{\rm{LEAVE}}} , {{{\rm{ID}}} _{1,0}},{{{\rm{ID}}} _{w,0}}, {C_1}, {{{\rm{IK}}} _{1,5}}, {{{\rm{EK}}} _{1,5}},T$, ${{{\rm{Sign}}} _{{{{{\rm{ik}}} }_{1,5}}}} ( H ({{{\rm{IK}}} _{1,5}}, {{{\rm{EK}}} _{1,5}}, {C_1},T)))$并放入交易池，其交易验证以及新区块${{{\rm{Block}}} _2}$生成过程同2.5.1节。当${{{\rm{Block}}} _2}$被${{{\rm{ID}}} _{w,0}}$写入本地区块链后，${{{\rm{ID}}} _{1,0}}$会在原有的两个公钥列表中删除${{{\rm{ID}}} _{1,5}}$对应的公钥。区块链中的每个共识节点都会将原来的公钥列表更新为${\left( {{{\rm{IK}}} {{{\rm{L}}''}_x},{{\rm{EK}}} {{\rm{{L}}''}_x}} \right)_m}$并同步到区块链上，表明${{{\rm{ID}}} _{1,5}}$成功地离开簇${C_1}$。图4展示了簇${C_1}$群组密钥${{{\rm{GK}}} _3}$的更新过程。

图 4  基于图3中的${{{\rm{ID}}} _{1,5}}$动态离开

下载: 全尺寸图片 幻灯片

2.5.3   周期性密钥更新

若在某一时间范围内无人机簇中并未发生动态成员关系变化，为保证整个系统的安全性，无人机节点需要周期性更新它们的密钥。若某簇成员无人机由于网络连接不畅出现短暂离线，其他无人机也能自主更新组密钥。假设簇${C_x}$中某簇成员无人机节点${{{\rm{ID}}} _{x,i}}$要更新自身的临时公私钥对，它将随机选择一个新的私钥${{\rm{e}}} {{\rm{k}}'_{x,i}} \leftarrow Z_q^ *$，并计算${{\rm{E}}} {{\rm{K}}'_{x,i}} = {g^{{{\rm{e}}} {{{\rm{k}}'}_{x,i}}}}$。随后，它将把这一密钥更新请求发送给${{{\rm{ID}}} _{x,0}}$，以便簇内群组密钥的更新。这一请求消息具体表示为：${{{\rm{msg}}} _3} = \{ {{\rm{UPDATE}}} ,{{{\rm{ID}}} _{x,i}},{{{\rm{Enc}}} _{{{{{\rm{GK}}} }_x}}}({{{\rm{EK}}} _{x,i}},{{\rm{E}}} {{\rm{K}}'_{x,i}},T$, ${{{\rm{Sign}}} _{{{{{\rm{ik}}} }_{x,i}}}}(H({{\rm{E}}} {{\rm{K}}'_{x,i}},T)))\}$。

${{{\rm{ID}}} _{x,0}}$接收到该消息后的验证过程同上一节，此处不再赘述。

验证通过后，${{{\rm{ID}}} _{x,0}}$将该请求消息生成一个新的交易${{{\rm{Tx}}} _{{\rm{Upd}}}}({{\rm{UPDATE}}} ,{{{\rm{ID}}} _{x,0}},{{{\rm{ID}}} _{w,0}},{C_x},{{{\rm{IK}}} _{x,i}},{{\rm{E}}} {{\rm{K}}'_{x,i}},T, {{{\rm{Sign}}} _{{{{{\rm{ik}}} }_{x,i}}}}($$H({{{\rm{IK}}} _{x,i}},{{\rm{E}}} {{\rm{K}}'_{x,i}},{C_x},T)))$并放入交易池，其交易验证以及新区块${{{\rm{Block}}} _3}$生成过程同2.5.1节。当${{{\rm{Block}}} _3}$被${{{\rm{ID}}} _{w,0}}$写入本地区块链后，${{{\rm{ID}}} _{x,0}}$会在原有的临时公钥列表中更新${{{\rm{ID}}} _{x,i}}$对应的临时公钥。区块链中的每个共识节点都会将原来的临时公钥列表更新为${\left( {{{\rm{IK}}} {{\rm{L}}''_x},{{\rm{EK}}} {{\rm{L}}'''_x}} \right)_m}$并同步到区块链上，此时${{{\rm{ID}}} _{x,i}}$成功地完成了密钥更新。

图5展示了簇${C_1}$中${{{\rm{ID}}} _{1,4}}$更新密钥的过程。当簇内的其他无人机接收到${{{\rm{ID}}} _{1,4}}$发送的密钥更新消息并验证其真实性及有效性之后，便更新群组密钥为${{{\rm{GK}}} _4}$。同理，簇头无人机也会周期性更新簇间的群组密钥，其更新过程同上，以安全地维护系统中的安全通信。

图 5  无人机${{{\rm{ID}}} _{1,4}}$发起密钥更新(实线框标注部分)

下载: 全尺寸图片 幻灯片

群组密钥生成以及动态更新时各无人机节点参与ART构建的算法复杂度如表1所示。因为簇头无人机节点在初始构建密钥树ART时需要获取其余簇成员节点的信息并调整树结构，所以在初始群组密钥生成时其计算复杂度高于其他节点；而在群组密钥动态更新的过程中，各节点的操作都基于二叉树，所以它们的算法复杂度相同。

表 1  无人机节点构建ART的算法复杂度

操作	簇头无人机节点	簇成员无人机节点
初始群组密钥生成	$O(n{\log _2}n)$	$O({\log _2}n)$
加入	$O({\log _2}n)$	$O({\log _2}n)$
离开	$O({\log _2}n)$	$O({\log _2}n)$
更新	$O({\log _2}n)$	$O({\log _2}n)$

下载: 导出CSV 

| 显示表格

3.   安全性分析

针对本文提出的分层无人机网络中存在的安全问题，对本文方案进行安全性分析。

(1)前向保密性：在分层无人机网络中，簇内部无人机之间的通信由群组密钥进行对称加密。一旦簇成员无人机离开簇，它的身份就会被撤销，这就意味着它拥有的所有密钥都将会失效，所在无人机簇的无人机都将会更新群组密钥。因为其身份已被注销，所以密钥也被告知无效，因此离开的无人机无法通过以前的群组密钥与无人机密钥对后续的消息进行解密，以保证了方案的前向保密性。

(2)后向保密性：当有新的无人机加入簇时，簇头无人机会进行群组密钥的更新。由于新加入的无人机计算所得的群组密钥是更新后的群组密钥${{\rm{G}}} {\rm{K}}'$，无法解密之前群组中由${{\rm{GK}}}$加密的通信消息，以此保证了方案的后向保密性。

(3)抵抗伪装攻击：

(a)对于无人机簇中的簇头无人机来说，若有攻击者想要伪装该节点，它需要对该无人机簇的群组密钥${{\rm{GK}}}$进行计算，当无人机发生动态关系变化时能及时对群组密钥进行更新。在计算群组密钥之前区块链中的共识节点需使用该无人机的${{{\rm{IK}}} _{x,0}}$对其身份进行验证，由于该攻击者并没有使用正确的${{{\rm{ik}}} _{x,0}}$进行签名，身份验证将会失败。

(b)出于相同的理由，攻击者也无法伪装簇内的簇成员无人机。因为无论是簇头无人机还是簇成员无人机，在计算群组密钥之前区块链中的共识节点都会对其${{{\rm{IK}}} _{x,0}}$进行合法性验证，攻击者并没有合法的${{{\rm{ik}}} _{x,0}}$签名所以会验证失败。因此该文所提供的群组密钥管理方案能够抵抗伪装攻击。

(4)抵抗窃听、篡改与重放攻击：由于簇内无人机之间的通信是通过群组密钥进行加密的，能够保护无人机簇内部的通信免遭窃听。篡改攻击可以由区块链共识节点对无人机发送的签名消息进行验证，如果验证不通过将即刻检测到篡改攻击。因为在无人机发送给区块链共识节点的消息中附加了时间戳$T$，所以该消息将不会被第2次发送。一旦被检测到接收该消息时的时间戳$T'$与当前时间戳$T$的差值大于指定阈值$\Delta T$，则确定该消息为无效消息，并将其丢弃。因此，时间戳的添加防止了消息的重放攻击。

4.   性能分析

4.1   计算与通信开销

在计算开销方面，本文在笔记本电脑(联想，Intel(R) Core(TM) i5-7200U 2.50 GHz处理器和Windows 10操作系统)上使用Java编程语言在基于配对的密码学(Java Pairing-Based Cryptography, JPBC)库运行了如表2所示的密码原语操作，其运行时间为1000次测试的平均值。在此基础上，本文对比了其他受限设备场景下密钥协商协议^[17,20,22]中参与者的群组密钥平均计算开销，结果如表3所示，其中$n$表示参与者的数量，并取值$n = 5$。由文献[16]可知，基于二叉树协议的计算开销取决于密钥树的高度、平衡度、加入或离开节点在树中的位置。由于本文方案中的ART为左平衡二叉树^[18]，其最小高度为$h = \left\lfloor {{{\log }_2}n} \right\rfloor + 1$。

表 2  密码原语操作运行时间(ms)

操作原语	原语描述	PC端运行时间
${T_{\exp }}$	模幂操作时间	2.418
${T_h}$	SHA256操作时间	0.027
${T_{ {{\rm{bp}}} } }$	双线性配对操作时间	6.233
${T_{ {{\rm{mul}}} } }$	标量乘法操作时间	0.016
${T_{\text{pa-acc}} }$	椭圆曲线点加操作时间	0.0016
${T_{ {{\rm{inv}}} } }$	模逆操作时间	0.175
${T_{\text{pa-bp}} }$	双线性配对点加操作时间	0.073

下载: 导出CSV 

| 显示表格

表 3  群组密钥计算开销对比(ms)

方案	初始群组密钥计算	更新	加入	退出
文献[17]	$(5n + 5){T_{\exp }} = 72.540$	$(7 + 5n){T_{\exp }} = 77.376$	$23{T_{\exp }} = 55.614$	$(5n - 6){T_{\exp }} = 45.942$
文献[20]	$\begin{gathered} {T_{bp}} + 3{T_{{\rm{mul}} }} + {T_{\rm{inv}}} + 4{T_h} \\ (n + 1){T_{{text{{pa}-bp}}}} = 58.866 \\ \end{gathered}$	--	$4{T_{{\rm{bp}}} } + {T_{\rm{inv} } } = 25.107$	$4{T_{{\rm{bp}}} } + {T_{\rm{inv} } } = 25.107$
文献[22]	$\begin{gathered} 4{T_{{\rm{bp}}} } + 3{T_{{\rm{exp}}} } + (2n - 1){T_{ {\rm{mul} } } } \\ + {T_h} + 4{T_{{\text{pa-acc}}} } = 34.421 \\ \end{gathered}$	--	--	--
本文方案	$(2h - 1){T_{\exp }} = 12.090$	$(2h - 1){T_{\exp }} = 12.090$	$(2h - 1){T_{\exp }} = 12.090$	$(2h - 1){T_{\exp }} = 12.090$
(注：“--”表示不支持该操作)

下载: 导出CSV 

| 显示表格

由表3可以得出，在初始群组密钥计算阶段，本方案的每个簇成员无人机平均计算开销为12.090 ms，同文献[17,20,22]方案的参与者平均计算开销相比分别减少了约87.5%,79.5%,64.8%。在群组密钥动态更新阶段，本方案在密钥自主更新时的计算开销相较于文献[17]方案减少了约84.4%；在节点动态加入时群组密钥更新的计算开销同文献[17,20]方案相比分别减少了约78.3%, 51.8%；在节点动态离开时群组密钥更新的计算开销同文献[17,20]方案相比分别减少了约73.7%, 51.8%。综上所述，本方案在初始群组密钥计算阶段和群组密钥动态更新阶段，相较于文献[17,20]方案均有明显优势。

在通信开销方面，参考文献[16]中的元素、密钥长度设置，本文方案中认证加密的密钥长度为128 bit，通用哈希函数输出的长度为256 bit，$p$和$q$的长度为160 bit，循环群${G_q}$中的元素长度均为1024 bit，时间戳、身份标识均为32 bit，设置初始群组大小$n = 5$。

在文献[17]方案的每个节点参与群组密钥计算的过程中，总通信开销为n(n–1)/2×3 584=35 840 bit。在文献[20]方案的群组密钥计算过程中，总通信开销为33 600 bit。在文献[22]方案的群组成员进行组密钥计算过程中，总通信开销为32 960 bit。在本文方案中，进行初始群组密钥计算时，总通信开销为9 248 bit。因此，相较于上述方案，本文方案具有较低的通信开销。

4.2   区块链性能分析

本节主要考虑簇成员无人机发生动态拓扑变化会引发群组密钥更新，其中每次交易生成都会耗费一定时间。本节评估交易的平均处理时间与系统中无人机数量、动态事件数量的关系：当系统中无人机簇数量不变的情况下，每个簇中产生的动态请求事件越多，对应产生的交易数量就越多。本节使用Python实现了基于DPOS算法的简易区块链，并部署在内存为4 GB的Ubuntu20.04上运行。

由文献[24]可知，系统中产生的交易总数服从泊松分布，其均值为系统中的节点数量。不同交易数量下的处理时间，随着待认证交易数量的增加呈指数增长。本节通过实验对比了本方案与文献[20]方案的交易平均处理时间。在实验中，本方案中的系统无人机数量与文献[20]方案中的系统终端数量取值相同，本方案中的无人机分簇数为3(即簇头数量为3)。在节点数量固定的情况下，图6(a)对比了不同请求事件数量下的交易处理时间；在请求事件数量固定的情况下，图6(b)对比了不同节点数量下的交易处理时间，结果均显示本文方案更具优势。

图 6  不同请求数量或节点数量下的交易处理时间变化

下载: 全尺寸图片 幻灯片

5.   结束语

针对分层无人机网络中群组密钥管理方案面临的单点故障问题、无人机拓扑频繁变化引发的密钥更新问题以及成员离线导致群组其他成员无法及时更新组密钥的问题，本文提出了支持异步计算的去中心群组密钥管理方案。本文首先采用基于ART的群组密钥计算机制，实现了无人机节点对群组密钥的预部署，以及发生动态关系变化时群组密钥的安全更新；然后利用区块链去中心化的特性来解决现有大多数所提出的群组密钥管理方案过度依赖于GCS的问题，且能实现密钥更新交易溯源；最后，对提出的方案进行了安全性分析和性能比较。结果表明此方案适合应用于分层无人机网络环境。