基于区块链的软件定义网络数据帧安全验证机制

陈何雄，罗宇薇，韦云凯*，郭威，杭菲璐，毛正雄，张振红，何映军，罗震宇，谢林江，杨宁

（1.云南电网有限责任公司 信息中心，昆明 650011；2.电子科技大学 长三角研究院（衢州），浙江 衢州 324003；3.电子科技大学 信息与通信工程学院，成都 611731）

0 引言

随着大数据、物联网等技术的发展，人们对网络性能及其灵活性有了更高的要求，而在传统网络中，由于网络控制逻辑和数据转发无法分离，使得网络的管理维护日益复杂，难以适应多样化的场景应用。软件定义网络（Software Defined Network，SDN）通过分离控制平面和数据平面提升网络部署的灵活性［1］，提供了一种新的方式来设计、建立和管理通信网络，简化了网络管理［2］。开放式网络基金会发布的软件定义网络白皮书［3］规定，SDN 分为三层结构：应用层、控制层和数据层。其中，控制层分别通过北向接口、南向接口与应用层、数据层进行数据交互。处于控制层的控制器提供了网络的全局视图，使得网络运营商和管理者可以依据应用层功能需求以编程的方式配置网络对网络交换设备下发控制策略，数据层则根据所接收到的执行指令进行数据转发、存储、上传等工作［4］。因此，SDN 能够在控制层的配合下自动、快速、动态地配置和优化网络资源，有利于实现异构网络互连、网络管理、资源动态管控等相关业务［5］；从而，SDN技术被广泛应用于车联网、电力行业、银行行业等领域［6］。与此同时，SDN 的广泛应用也吸引了更多的攻击行为，重要方式之一是伪造或篡改数据帧以消耗网络资源、破坏正常通信、威胁业务安全。为了增强SDN 的通信安全，进而保障网络所承载的业务安全，必须对其中传输的数据帧实施有效的安全验证，以构建安全高效的网络环境。

目前，针对SDN 提出的验证机制主要包括对数据帧的源地址可靠性验证、数据帧完整性验证、转发路径正确性验证等。文献［7-9］采取了集中式的验证与密钥信息维护架构，其中，文献［7］由终端使用密钥生成属性标识来保证源地址可靠性，实现访问控制，但并未为数据帧内容完整性提供保障；文献［8］由终端用户使用与控制器共享的密钥对数据报文生成消息验证码（Message Authentication Code，MAC）作为验证标识保障数据的真实性和完整性；文献［9］结合MAC 与交换机的流量统计值对数据帧源地址、内容与转发路径实施随机认证，但是在集中式的验证架构下，验证操作及验证信息维护都将增加中心节点的负担，且当中心节点被攻击失效，该架构下的验证有效性与密钥信息安全都将受到极大影响。文献［10-12］采取分布式验证与集中式密钥维护架构，在文献［10］中，数据帧的转发交换机基于流表信息向该帧添加验证标识，并进行路径验证，以保证转发策略的正确执行；文献［11］中提出由控制器设置对称密钥与交换机共享，由交换机对数据帧内容完整性与转发路径进行验证，其中，数据帧的入网、出网交换机分别负责添加、移除验证标识，但上述两种方案均不能保证数据帧源地址可靠性；文献［12］中的控制器负责与用户协商共享对称密钥，将验证功能下放给SDN交换机来实施基于密码标识转发验证以保证数据帧源地址可靠性与内容完整性，但是对称密钥在分发和存储时存在泄露或被篡改的安全威胁。因此，集中式验证架构将面临单点故障问题，而在密钥信息的集中式维护下，即使采取分布式的验证架构，也难以避免由于验证设备受恶意控制而导致的验证体系失效问题。

本文结合区块链的分布式特性，提出基于区块链的软件定义网络数据帧安全验证机制，简称为基于区块链的帧验证（BlockChain-based Frame Verification，BCFV）机制。该机制在不可信网络环境、单点故障等情况下，都可保持对SDN数据帧的有效验证。本文主要工作如下：

1）利用区块链防篡改、可追溯等特性，建立基于区块链的数据帧安全验证机制，在网络与设备不可信情况下，实现分布式、可靠的数据帧安全验证。

2）结合SDN 特征及设备的资源限制，设计了基于帧转发证明（Proof of Frame Forwarding，PoFF）的轻量型共识算法，实现极低开销的区块链系统维护，降低验证机制中引入区块链对系统带来的资源压力。

3）提出了半随机选择验证模式，结合网络实时负载与安全等级，灵活调整传输路径上的转发设备对于数据帧的验证概率，实现验证有效性与系统开销两者间的兼顾。

1 相关工作

本文验证机制针对软件定义网络中的数据安全问题提出，主要应用数字签名、区块链等技术手段，保证数据来源可靠性与内容完整性、验证信息维护的安全性，进而保障网络承载业务的安全，下面分别对数字签名、区块链及共识算法进行简要介绍。

1.1 数字签名

数字签名技术最早由Diffie等［13］在1976 年提出，旨在尽量减少对安全密钥分发的途径并提供相当于书面签名的标识，基本原理是任何人都可以很容易地识别出签名的真实性，但除了合法签名者之外，没有人能生成它，这种单向身份验证技术提供了防止第三方伪造的保护。随后，RSA（Rivest，Shamir，Adleman）数字签名算法［14］、Merkle 数字签名算法、Elgamal 数字签名算法［15］等被相继提出。数字签名算法允许实体验证签名数据的完整性和签名者的身份，适用于电子数据交换、数据存储以及其他需要数据完整性保证和数据源认证的应用场景。

根据数字签名实现的方法，可以将数字签名分为采用对称加密算法的数字签名和采用公钥加密算法的数字签名两种［16］。在公钥密码学中，密钥是由公钥和私钥组成的密钥对，由于无法从公钥推导出私钥，公钥密钥外泄的可能性远低于对称密钥外泄的可能性，故基于公钥的签名在密钥分发和管理上面临更少的风险。

1.2 区块链及共识算法

区块链技术最早由Nakamoto［17］在比特币中提出并应用，具有防篡改、可追溯等特点［18］。该技术使用哈希指针将数据区块按时间顺序链接成特定数据结构，利用加密链式区块结构来验证与存储数据，利用分布式节点共识算法来生成和更新数据，以密码学方式保证数据不可篡改和不可伪造［19］，为中心化机构普遍存在的高成本、低效率和数据存储不安全等问题提供了解决方案，被广泛应用于数据存储、数据鉴证、数据保护等场景中［20-21］。

在区块链系统中，各节点共享信息，所有参与节点必须对这些信息的合法性达成一致认识，决定共识如何达成的算法就是共识算法，这是区块链系统中的核心机制［22］。其中，比特币采用的是基于工作量证明（Proof of Work，PoW）的共识算法，节点通过不断计算来搜索得到符合系统难度要求的哈希值，以此竞争获得产生有效区块的权力；但是这种共识算法存在算力浪费问题，不利于推广。King等［23］在2012 年提出了基于权益证明（Proof of Stake，PoS）的PPCoin，其权益体现为节点对持有货币的数量与币龄的乘积，这种共识算法在一定程度上解决了PoW 的算力浪费问题并缩短了达成共识的时间。Dziembowski等［24］提出了基于空间证明（Proof of Space，PoSp）的共识算法，要求节点必须出具一定数量的磁盘空间来竞争出块权，以贡献磁盘空间的方式换取算力消耗的减少。然而，不论是算力资源还是磁盘空间的消耗，都会给SDN 中的相关设备带来沉重的资源压力。

2 基本思路与整体框架

SDN 中的各种设备都存在被恶意攻击或者控制的风险，其数据平面存在虚假数据帧注入、数据帧篡改等安全威胁。针对SDN 面临的这些风险，本文设计了基于区块链的数据帧安全验证机制，该机制采用公钥加密算法，基于数据帧内容及随帧随机数构建数字签名，并采用区块链技术维护公钥加密中的关键验证信息。

如图1 所示，基于区块链的数据帧安全验证机制主要由两个部分组成：数据帧验证与信息维护算法和基于帧转发证明的共识算法。其中，数据帧验证与信息维护算法利用区块链防篡改、可追溯等特性实现对验证信息的可靠维护，并在此基础上实现在网络设备不可信情况下的分布式可靠数据帧验证。而基于帧转发证明的共识算法充分考虑SDN 特征及设备的资源限制，实现以极低开销对区块链系统进行维护，降低验证机制中引入区块链对系统带来的资源压力。

数据帧验证与信息维护算法包含两部分：低开销弹性数据帧验证过程和基于区块链的验证信息维护过程。在低开销弹性数据帧验证过程中，本文采用基于公钥的数字签名技术作为验证手段，由主机生成数字签名作为验证标识随帧传输，由数据帧的转发交换机实施分布式验证，以抵御由验证主体受控引起的验证失效问题。在此基础上，进一步考虑兼容验证准确性和系统开销的半随机选择验证，通过设定验证概率并结合转发路径，以半随机方式选择交换机实施验证，从而避免逐跳验证带来的巨大负担。其中，验证概率可结合网络实时负载与安全等级灵活调整，在较低的开销代价下，保证验证系统高效运行。在基于区块链的验证信息维护过程中为保证密钥的新鲜性，主机将根据伪随机数定期生成密钥，对包含新密钥的验证信息将应用区块链技术进行维护。交换机作为区块链运行的载体，依据基于帧转发证明共识算法的规则将通过确认的验证信息写入区块链，从而保证验证信息真实且不可篡改。

为构建上述用于数据帧安全验证的区块链系统，本文设计了基于帧转发证明的共识算法，将SDN 交换机在对数据帧执行转发验证时获得的数字签名作为帧转发证明，在利用哈希运算与签名值的随机性保证出块随机性的同时，使得网络关联度和活跃度越高的交换机越具有竞争优势。该算法主要包含三个阶段：证明收集阶段、出块权竞争阶段、区块共识阶段。交换机作为区块链运行载体，在证明收集阶段中按共识算法规则验证并保存签名及相关信息；在出块权竞争阶段来临时，利用在证明收集阶段获得的最小签名参与出块权竞争；在区块共识阶段中，全网最小签名的记录者获得出块权，发布新区块，未获得出块权的交换机则等待确认新区块。经过上述阶段，网络交换机达成对区块链更新数据的共识。基于帧转发证明的共识算法将出块权的竞争转化为获得最小签名值的竞争，改变了PoS、PoSp 等共识算法为降低PoW 算力浪费所基于的资源，通过结合SDN 特征及其交换设备的行为特征降低区块链维护开销，为构建轻量型区块链系统提出了新的解决方案。

在上述数据帧验证与信息维护算法和基于帧转发证明的共识算法的作用下，本文所提出的BCFV 机制具有如下优势：

1）解决了集中式验证架构的单点故障问题。在BCFV机制中，SDN 控制器主要负责适时更新验证概率与周期下发伪随机数。若控制器失效或被恶意控制，将导致验证概率发送与伪随机数发送出现延迟，此时系统延续上一轮次的验证概率与伪随机数。这对系统效率与安全性虽然有一定影响，但基于区块链的去中心、不可篡改特性，上述异常行为可被及时发现并采取维修措施。不仅如此，仿真结果表明，即使在维修期间系统仍可保持良好的验证性能与效率。

2）规避了由于密钥泄露可能导致的验证体系失效问题。BCFV 机制利用区块链对密钥信息实施分布式可靠维护，防止了密钥信息遭伪造或篡改，并应用基于帧转发证明的共识算法，关联验证设备与区块链载体，防范异常设备在区块链维护过程中传播错误密钥。

3）在合理的通信代价与资源开销下，构建可信的网络环境。在BCFV 机制中，应用了基于帧转发证明的共识算法，以极低开销维护区块链系统，减轻引入区块链对系统带来的资源压力；设计了半随机选择验证模式，可灵活调节验证概率以实现对验证效率与资源开销的兼顾。

本章简要介绍了基于区块链的数据帧安全验证机制的基本思想、整体架构和特有优势。为了便于叙述，本文后续内容中，将先介绍基于帧转发证明的共识算法，再在此基础上说明数据帧验证与信息维护算法。

3 基于帧转发证明的共识算法

考虑到作为区块链载体的SDN 交换机算力有限，为降低区块链维护的开销，本文设计了基于帧转发证明的共识算法作为构建轻量型区块链系统的基础。

3.1 系统模型

鉴于交换机无法刻意伪造主机生成的数字签名，同时为避免同一签名被多台转发交换机收集，交换机将收集其直连主机生成的签名作为帧转发证明。在SDN中，将交换机集合表示为S，交换机数量为m(m∈N+)，则S={s1，s2，…，sm}；将主机集合表示为H，主机数量为n(n∈N+)，则H={h1，h2，…，hn}。将交换机si与主机hj之间的链路表示为则si与hj的连接关系如式（1）所示：

将基于帧转发证明的共识算法周期表示为Tfull，则Tfull=Tcol+Tcmp+Tcon。其中：Tcol为证明收集周期；Tcmp为出块权竞争周期；Tcon为区块共识周期。在Tcol内，将网络中所有主机产生的数字签名所构成集合表示为G，数字签名数量为a(a∈N+)，则G={g1，g2，…，ga} 。将主机hj和数字签名gk之间的关联表示为，则hj与gk的生成关系如式（2）：

由于主机直连的交换机有且仅有一台，因此，在i≠j时，必然有=∅。将共识周期内的最小数字签名表示为gmin，则交换机si获得出块权的概率如式（4）所示：

由式（3）～（4）可知，交换机收集到的数字签名总量取决于直连主机数量与直连主机产生的签名数量，而由于数字签名是随数据帧传输的，故交换机转发的数据帧总量越大，在出块权的竞争中具有更大优势。这种优势在某一次具体的出块过程中是随机的，从而保证每一轮出块权的随机性；同时，在长期运行过程中的统计概率上这种优势是确定的，保证网络关联度、活跃度更高的交换机可获得更多的出块权。因此，基于帧转发证明的共识算法保证了出块权竞争公平性的同时又结合了交换机的正常转发工作，不会给交换机带来过多的额外开销。

3.2 共识流程

共识算法的具体流程如图2 所示，基于帧转发的共识算法流程可分为证明收集阶段、出块权竞争阶段和区块共识阶段。将交换机si在证明收集阶段新收到的来自直连主机hj的数字签名表示为将si在证明收集阶段结束后保存的局部最小签名表示为记录时间表示为；si在出块权竞争阶段结束后保留的最小签名表示为，记录时间表示为；将新区块表示为B；tcol、tcmp、tcon分别为证明收集阶段、出块权竞争阶段、区块共识阶段的计时变量，当计时变量被置0时，表明相应阶段的开始，当计时达到或超过对应阶段的给定周期，则表示该阶段结束，准备进入下一阶段或下一共识周期。设定act_flag是收集与转发标识，当其被置0 时进入证明收集阶段，置1 时进入出块权竞争阶段；con_flag是区块共识标识，当其被置0 时进入区块共识阶段，置1 时准备进入下一个共识周期。

3.2.1 证明收集阶段

交换机si在该阶段收集直连主机发送的数据帧上的数字签名，为出块权竞争做准备。证明收集算法流程如下。

算法1 证明收集算法。

输出si的局部最小签名。

证明收集阶段开始时，将tcol、act_flag初始化为0，随后，si在收到来自直连主机的数据帧时，对该帧进行验证，若验证通过，则将该帧的签名及其相关信息按算法规则进行保存。如此，在证明收集阶段结束后，si得到局部最小数字签名。其中，记录签名时间是为了给si在出块权竞争阶段中遇到同值数字签名时提供判断依据。

3.2.2 出块权竞争阶段

基于最小签名记录者获得当前共识周期出块权的竞争原则，在出块权竞争阶段，网络中所有交换机利用此前得到的局部最小签名来竞争出块权，并对全网最小签名记录者（即出块权获得者）达成一致认识。出块权竞争算法流程如下。

算法2 出块权竞争算法。

输入 局部最小签名，计时变量tcmp。

输出 全网最小签名。

出块权共识阶段开始时，将tcmp、初始化为0，交换机si向其他交换机sk发送及相关信息的同时，接收并验证，然后按照算法规则更新。如此，在出块权共识阶段结束后，各交换机对全网最小签名记录达成一致认识，全网最小签名的记录者获得当轮出块权。

3.2.3 区块共识阶段

区块共识阶段来临时，出块权获得者发布新区块，未获得出块权的交换机则等待接收并确认新区块。区块共识算法如下。

算法3 区块共识算法。

输入 全网最小签名。

输出 新区块B。

在区块共识阶段开始时，将tcon、con_flag初始化为0，若si获得出块权，则发布新区块B；若si未获得出块权，则等待接收新区块B，并对收到的新区块B进行确认。其中，si对新区块B的确认包括有效性确认与合法性确认，有效性确认是通过检验新区块发布者与当前共识周期中最小签名记录的一致性来实现，目的在于确认区块发布者是否为的记录者，合法性是指对区块包含的验证信息真实性的确认。si在等待新区块B时，可以主动向获得出块权的sk请求新区块B。当con_flag被置1，意味着交换机完成当轮区块链的同步，准备进入下一个共识周期。

4 数据帧验证与信息维护算法

本文验证机制采取基于公钥的数字签名作为验证手段，并进一步提出半随机选择验证以兼顾验证效率与系统开销；同时，设计了基于区块链的验证信息维护机制实现对验证信息的可靠维护。

4.1 数据帧验证

数据帧验证包括基本验证模式与半随机选择验证模式，下面将分别对这两种验证模式进行具体说明。

4.1.1 基本验证

将交换机si与主机hj之间的链路表示为，假定交换机si、su(i≠u)分别与主机hj、hv(j≠v)有单跳连接，将主机hj向主机hv发送的数据帧表示为f(i，j)-(u，v)。在基本验证模式下，数据帧的入网、出网交换机必须执行验证，而转发路径上的其余交换机不做验证。交换机将依据数据帧的源、目的地址与该帧的收、发端口上所连设备的匹配情况来判断当前是否为该帧的入网或出网交换机。结合式（1），则f(i，j)-(u，v)和f(u，v)-(i，j)的转发交换机sk的验证概率psk取值如式（5）所示：

如图3 所示，基本验证的实施过程如下：

1）验证标识生成。为实现对源地址可靠性和内容完整性的验证，保证验证标识的随机性，将f(i，j)-(u，v)包含的随机数（由主机hj生成）与源地址、数据内容等字段共同作为待验证数据表示为，主机hj的私钥表示为skj，公钥表示为pkj，则主机hj据式（6）得到f(i，j)-(u，v)上的签名g(i，j)。

2）转发验证执行。入网交换机si（出网交换机su的处理逻辑同si）首先从区块链中获得与数据帧源地址匹配的公钥pkj，然后据式（7）对f(i，j)-(u，v)进行验证。

其中：TRUE 表示验证通过，si将正常转发f(i，j)-(u，v)；FALSE 表示验证不通过，si将丢弃f(i，j)-(u，v)。

4.1.2 半随机选择验证

半随机选择验证由控制器与交换机协同实施。本文的半随机选择指的是对数据帧转发路径上的验证节点进行的选择，而非验证节点对数据帧的选择。结合式（1），在半随机选择验证下，f(i，j)-(u，v)与f(u，v)-(i，j)的转发交换机sk(k≠i≠u)的验证概率取值如式（9）：

在入网交换机上验证可以尽早过滤虚假数据帧以节省网络资源，在出网交换机上验证是为了保证交付给目的主机的数据帧是没有被篡改的，而途经交换机的验证则可以阻止受到篡改的数据帧在网络中进一步传播。

将网络用户可接受的最大平均延迟表示为D，网络的理论吞吐量为TPtheory，实际吞吐量为TPactual，则网络负载率L=TPactualTPtheory(0 ≤L≤1)。由于网络负载率L与转发延迟dload的关系将随网络规模、设备性能等硬件设备与转发规则等软件因素的变化而变化，故将L与dload之间的关系表示为Rlt1，将普通转发处理与排队等过程引入的转发延迟表示为dload，则dload=Rlt1(L)；将验证概率p与验证延迟dveri之间的关系表示为Rlt2，将验证处理引入的验证延迟表示为dveri，则dveri=Rlt2(p)。从而，验证概率p在取值时应满足式（10）：

通过结合数据帧转发路径对验证节点的半随机选择，以及对验证概率的灵活调整，实现对验证机制的系统开销和验证有效性的兼顾。

4.2 基于区块链的验证信息维护

基于区块链的验证信息维护利用区块链防篡改、可追溯的特点来保障验证信息的安全。

如图4 所示，为了增强验证机制的安全性，网络主机将使用由控制器周期下发的伪随机数更新密钥。出于对伪随机数有效性的考虑，由获得出块权的交换机负责生成伪随机数，控制器负责将伪随机数周期地发给网络主机。然后，主机结合伪随机数与自身信息更新密钥，交换机以区块链形式对验证信息进行维护。

将密钥更新周期表示为Tupd，验证信息更新的具体流程如下：

1）获得出块权的交换机在发布新区块的同时，将使用梅森旋转（Mersenne Twister）算法［25］生成伪随机数Rkey发给控制器，控制器接收并存储Rkey，并按照周期Tupd将Rkey以组播方式发给网络主机；

2）主机收到伪随机数Rkey后，结合自身信息完成密钥更新，将私钥保存在本地，将“主机新公钥”“主机MAC 地址”“主机旧公钥”“主机旧私钥数字签名”“时间t”按约定格式以组播方式发给网络中的交换机；

3）交换机收到来自主机发布的验证信息后，通过验证“主机旧私钥数字签名”对验证信息进行完整性确认，通过从区块链的历史信息中搜索满足“主机新公钥”为当前验证信息中的“主机旧公钥”的信息，对验证信息进行合法性确认；

4）通过确认的验证信息将被交换机保存并等待被写入区块链，未通过确认的验证信息将被丢弃。

在密钥更新过程中，存在密钥同步的时间差问题，体现在两个方面：在新密钥写入区块链之前使用新密钥生成签名，在新密钥写入区块链之后仍使用旧密钥生成签名。这两种情况均会造成正常数据帧的验证失误，影响网络正常通信。其中，第一种情况可以通过设置主机新密钥启用间隔时间Tsta(Tsta＜Tupd)来解决，以保证新密钥在写入区块链后才能被启用；第二种情况可以通过设置密钥有效周期Teff来解决，以保证主机启用的密钥与交换机验证时使用的公钥是匹配的。其中，密钥更新周期Tupd、密钥启用间隔Tsta和密钥有效周期Teff的具体数值应根据网络规模、负载状态及安全等级等实际因素进行调整。

5 仿真与结果分析

5.1 仿真设置

本文仿真设定使用Aurora 420 交换机［26］相关参数，交换机存储空间大小为64 GB，处理器为英特尔凌动C2558，包转发率为14.48 Mpps。仿真拓扑结构为二元胖树拓扑，包含4台边缘、4 台聚合、2 台核心交换机与8 台终端主机，最大网络负载为1 071 Mpps。为了对本文验证机制的性能进行评估，设定该网络拓扑下每条链路的流量均相等。分别从转发延迟、验证可靠性、算力占用角度，将本文所提机制与基于哈希链的验证机制［11］进行了对比，并针对BCFV 机制在存储需求方面随网络规模变化的情况进行了分析说明；同时，从SDN控制器单点故障的角度切入，对比本文所提机制与集中式验证架构机制［8］的验证性能。

5.2 可靠性验证

本节通过分析验证机制下的漏检概率来评估所提机制的验证可靠性。将漏检概率定义为虚假的或遭篡改的数据帧顺利到达目的主机的概率，交换机在受恶意控制状态下不会对数据帧进行验证，但仍然执行正常转发工作。以1∶1 的比例向网络注入虚假数据帧和篡改数据帧，分析在受恶意控制交换机占比提高情况下，基于哈希链的验证模式与本文BCFV 模式在不同验证概率下的漏检概率，结果如图5所示。

在基于哈希链的验证模式中，数据帧的入网交换机负责将数据帧消息告知控制器，并根据控制器下发的随机数计算消息验证码插入数据帧，若入网交换机受到恶意控制，则该验证模式将失效。由于该模式下的验证不包括对数据帧的源地址可靠性的验证，故即使交换机均正常工作，也未能识别虚假数据帧，因此，基于哈希链的验证模式的漏检概率较高。

在本文所提的验证机制下，交换机的验证处理相对独立，不会因为个别交换机被恶意控制而导致验证体系失效，且在数据帧转发路径上任一台交换机执行验证都可以对数据帧来源可靠性与内容完整性进行识别。因此，在BCFV 模式下，随着受恶意控制交换机占比增加，BCFV 模式（p=0）的漏检概率总是低于基于哈希链的验证模式的漏检概率，且验证概率p越高，BCFV 模式的漏检概率越低。其中，在受控交换机占比40%时，这种降低更为显著，此时采用BCFV 模式（p=0）的漏检概率低于32%，而辅助以半随机验证后，BCFV 模式（p=0.5）与BCFV 模式（p=1）的漏检概率分别降低到15%和7%，均远低于基于哈希链的验证模式72%的漏检概率，综上，本文验证机制的验证可靠性高于基于哈希链的验证模式。

5.3 转发延迟

往仿真拓扑中的每条链路上均等注入流量，通过改变网络负载，分析数据帧在无验证的普通转发模式、基于哈希链的验证模式以及BCFV 模式的不同概率下的平均转发延迟，结果如图6 所示。

验证机制的引入在提高网络安全性的同时也增加了交换机在转发数据帧时的处理开销。基于哈希链的验证模式通过添加消息验证码与构建哈希链来实现数据帧转发路径与数据帧内容完整性的保证，将导致转发延迟的增加，且增加的延迟无法通过改变某个参数来调整；相较于无验证转发模式，本文所提的BCFV 模式下延迟增加的原因是添加了验证处理，保障了数据帧来源可靠性与内容完整性；而验证概率的设置使得引入的转发延迟可以被调整，便于适应不同负载的网络环境。

从图6 可知，各验证模式下的转发延迟总是高于无验证转发模式下的。相较于无验证转发模式，随着网络负载的增大，在基于哈希链的验证模式下，转发延迟平均增加了3.95 ms；在BCFV 模式下，当验证概率p分别取0、0.5、1时，平均转发延迟分别增加了约2.05 ms、3.14 ms、4.94 ms。结合图5 可知，由BCFV 模式（p=0.5）引入的平均延迟与基于哈希链的验证模式引入的平均延迟相近，但是具有更低的漏检概率，验证可靠性更高。

5.4 算力占用

在本文提出的BCFV 模式中，验证概率可根据实际网络规模和负载状态进行调整，考虑到BCFV 模式（p=0.5）与基于哈希链的验证模式有相近的延迟开销，故选择这两种验证模式来进行对比分析，分别计算在网络负载增加时，两种验证模式下的数据帧转发、数据帧验证等对交换机的算力占用情况，结果如图7 所示。

在网络负载从10%增大到80%的过程中，BCFV 模式（p=0.5）的算力占用从15%增加到约95%，基于哈希链的验证模式的算力占用从12%增加到约90%，这表明，相较于基于哈希链的验证模式，BCFV 模式（p=0.5）在具有更高验证可靠性的情况下，算力占用并未明显增加。

在BCFV 模式（p=0.5）下，用于数据帧转发的算力超过已用算力的60%，相较于转发数据帧带来的算力开销，数据帧验证与区块链维护两者共同所增加的算力增长平缓且较为平稳；另一方面，本文验证机制增强了网络环境安全性，区块链的应用通过为验证信息提供可靠维护保障了验证机制的有效运行，巩固了验证机制带来的安全性。综上，本文所提验证机制增加的算力开销在可接受范围内。

5.5 存储需求

区块链的存储需求与验证信息更新周期、区块共识周期、网络用户主机数等因素相关。考虑到4.2 节中提及的时间差问题，假定验证信息更新周期将随着用户主机数的增加而延长，初始验证信息更新周期Tupd为120 s，共识周期为60 s，区块链（1 年）的存储需求随网络规模扩大的变化如图8所示。

随着网络规模的扩大，用户主机数增加，区块链（1 年）的存储需求无明显增长趋势，这主要是由于在用户主机数量增加的同时，更新的验证信息与区块的传播时间随之增加，而验证信息更新周期会由于传播时间的增加而延长，在单位时间内产生的验证信息量会有所减少。

在共识周期一定的情况下，虽然单位时间内产生区块的数量稳定，但是单个区块的存储量减小了，从而单位时间内区块链整体存储需求变化较为稳定，不会因为网络规模扩大有明显增长。在网络用户主机数从500 到5 000 的变化过程中，区块链整体存储需求平均约为每年510 MB，考虑到目前的硬件设备性能不断提高，且可以通过定期对网络终端重新进行认证等方式将历史的区块链信息离线存储等手段，释放存储空间来减小交换机的存储压力，因此，区块链引入的存储需求尚在可接受范围内。

5.6 SDN控制器单点故障的影响

在BCFV 机制中，SDN 控制器主要负责周期下发伪随机数以供用户主机更新签名密钥，和适时更新验证概率以兼顾验证性能与效率。因此，在SDN 控制器出现失效、被恶意控制等单点故障情况下，将会导致伪随机数的发送异常与验证概率的更新异常。从而，本节分别针对这两种情况来分析SDN 控制器单点故障对BCFV 机制的影响。

1）伪随机数发送异常。

在BCFV 机制中，SDN 控制器以Tupd为周期下发伪随机数辅助密钥更新，以防止攻击者破解密钥来伪造或篡改数据帧。当SDN 控制器失效或被恶意控制时，将导致伪随机数不能及时更新，以采用brainpoolP160r1 椭圆曲线加密算法［27］与安全散列算法1（Secure Hash Algorithm 1，SHA 1）共同实现的数字签名、且伪随机数发送周期Tupd（即密钥更新周期）为120 s 为例。据文献［28］可知，该签名算法安全位数为80位，如果使用暴力破解方式，需要进行280次计算，在使用47 000 MH/s（即每秒47 000 百万次哈希计算，作为对比，NVIDIA GeForce RTX 3090 24G 的算力为122 MH/s）的计算机进行破解时，所需时间约为2×1013s（约6.34×105a）。密钥在一定故障时间内被破解的概率如表1 所示。

表1 故障时间内密钥的破解概率Tab.1 Probability of key cracking during failure time

可见，即使伪随机数发送异常导致密钥无法正常更新，密钥在故障时间内被破解的概率仍然是极低的。此外，基于区块链的去中心、不可篡改特性，这类异常可被系统在短时间内及时发现，并采取维修措施。维修期间，虽系统安全性略有降低，但仍可保持正常运行。

2）验证概率发送异常。

在BCFV 机制中，SDN 控制器可据实际网络负载适时地调整验证概率，若SDN 控制器出现单点故障，验证概率将不再适时更新，BCFV 机制的转发延迟与检验准确率将受到影响。图9 展示了BCFV 机制下，SDN 控制器正常工作时（p据负载变化），以及SDN 控制器故障时（p分别取固定值0、0.5和1）的转发延迟变化。

SDN 控制器失效前，若BCFV 机制的验证概率p=1，则SDN 控制器单点故障后，验证概率将仍保持为p=1。随着网络负载的增加，转发延迟也将增加，BCFV 模式（p=1）相较于BCFV 模式（p据负载变化）的转发延迟平均增加了约1.5 ms，可见，此时系统效率略有降低，但仍在可接受范围内。而SDN 控制器失效后，BCFV 机制验证概率保持在p=0.5时，其转发延迟与BCFV 模式（p据负载变化）的转发延迟相近，可见，非极端情况下，验证概率的发送异常对BCFV 机制的影响较小。若SDN 控制器受到恶意控制，验证概率被设置为p=0，此时验证性能降低，但验证延迟随之降低，并未增加系统开销。

在以1∶1 的比例向网络注入虚假数据帧和篡改数据帧的情况下，绘制BCFV 模式（p=0）、BCFV 模式（p=0.5）、BCFV 模式（p=1）与BCFV 模式（p据负载变化）与集中式验证机制随网络负载增加的漏检概率变化，如图10 所示。

若SDN 控制器失效或受到恶意控制时，验证概率被设置为0 后不再更新，随着网络负载的增加，BCFV 模式（p=0）的漏检概率相较于BCFV 模式（p据负载变化）有较大幅度的恶化，但仍能保持一定的验证可靠性；若控制器单点故障时，验证概率p=0.5，此时相较于BCFV 模式（p据负载变化），BCFV 模式（p=0.5）的漏检概率仍能保持不高于30%；而在集中式验证机制中，当控制器单点故障时，其验证体系将无法识别对伪造或受篡改数据帧。另外，如果控制器单点故障时验证概率p=1，结合图9～10 可见，此时验证性能得到提升，但系统开销将有所增加。

综上，在SDN 控制器单点故障的情况下，验证概率发送机制可能出现异常，虽然会影响系统性能和验证效率，却无法中止系统的基本验证行为，整体验证系统仍可保持良好的验证性能与效率。因此，BCFV 机制解决了集中式验证机制中因单点故障导致整体验证失效的问题。

6 结语

本文提出了一种基于区块链的数据帧安全验证机制，利用数字签名技术实现对数据帧来源可靠性与内容完整性的验证，充分利用区块链可追溯、防篡改等特性实现对验证信息实施可靠维护，并设计基于帧转发证明的共识算法降低引入区块链的开销，同时，提出了可灵活调节的半随机选择验证模式，实现对验证有效性与系统开销的兼顾。最后的仿真结果表明，BCFV 机制较好地解决了集中式验证架构中的单点故障问题，在验证设备受到恶意控制时，本文提出的验证机制可在合理的开销代价下有效识别伪造与受篡改的数据帧，保持较低漏检概率，且引入的转发延迟、算力和存储开销均处于可接受范围内。在未来的工作中，一方面可结合应用环境的具体安全等级、网络负载和传输效率等多种因素分析验证概率与验证信息更新周期的优化策略，提高本文验证机制的适用性；另一方面，可以研究将BCFV 机制扩展应用于SDN 之外的其他分布式网络环境中，进行分布式、可信任的网络数据帧验证，扩大BCFV 机制的适用范围。