PBFT时间敏感性以及攻击方法
2021-05-29

背景

Andrew Miller 设计了新的共识 HoneyBadgerBFT论文中提到了BFT共识严重依赖时序假设,所造成的脆弱性。
在论文的附录中,Andrew Miller 介绍了BFT的攻击方法,本文将对该方法进行翻译和介绍。

另外本文不再对BFT的时序脆弱性进行论证,详情可见英文论文或者 中文论文

正文

PBFT包括两个主要的工作流
1、网络环境良好情况下的正常工作模式(网络节点都同步 而且 leader运行正常)
2、用于更换崩溃leader的view-change模式

正常工作模式

其中模式一,包含三个子协议 Pre-Prepare,Prepare,Commit.
当leader收到客户端的transaction时,根据transaction广播pre-prepare消息。
收到pre-prepare消息的节点,广播prepare消息。
当节点收到2f个preprare消息时,广播commit消息。
当节点收到2f+1个commit消息时,处理transaction。

view-change模式

正常工作模式出现超时,共识发生停滞的时候。节点会更换至view-change模式。并将节点本地的view-number++,同时广播view-change消息
如果节点的正常工作模式没有出现超时,但是收到了f+1个view-change消息。也会切换到view-change模式,并将节点本地的view-number++,同时广播view-change消息。

view-change工作模式规定新的leader为 view-change消息的heightmod 节点总数N。因此新的leader的转换过程,是在节点集合中循环的。

当节点发现自己就是新的view的leader,而且收到了2f+1个view-change消息时,广播NEW_VIEW消息。收到的2f+1个view-change消息被组合起来作为NEW-VIEW消息的proof。

当节点接收到一个 number大于等于自己当前view-number的NEW-VIEW消息时,更新自己的view-number到NEW-VIEW消息的number。
如果节点收到的NEW-VIEWnumber小于自己的当前number,则忽略。

节点进入view-change模式后,维护一个timeout计时器。
每一次view-change工作模式的失败(例如超时,即在timeout时间内收不到NEW-VIEW消息)都会使timeout计时器的超时时间翻倍。

断断续续的正常工作模式将会阻碍PBFT

我们会设计一个恶意的proxy调度器。拦截并延迟发给leader的消息。

下图展示了攻击的整个过程
其中
〇 后面的消息是该列表示的节点向外发出的消息
• 后面的消息是该列表示的节点接受到的消息
❌表示收到的消息view已经过时,因而忽略。
红色区域表示 延时发送
粉色区域表示 延时接受
在每一格的右下角会标注该列节点所处的 view

在这里插入图片描述
从图中我们可以看出。
第一阶段
client向0,1,2,3四个节点发出Req。
作为leader节点的0 向外发出PP 准备挖矿
但是这个PP为攻击者抑制住了
所有节点在∆时间内 没有收到PP,便误认为是leader崩溃,进入view-change模式

第二阶段
节点0123进入view-change模式
节点0123向外发出V1,试图更换view,试图将leader更换为1
这时候,攻击者抑制节点1接受V1消息
使得节点023更新到了view1,同时leader也变成了节点1
只有节点1没有收到V1,于是等待大家推选出新的leader

第三阶段
节点1接收到了刚刚被攻击者抑制的V1消息,发现大家选了自己作为leader
于是向外宣布就职,发出消息N1PP1
节点023由于没有在阶段2的时间内收到N1PP1,以为节点1已经崩溃,无法胜任leader。故向外发送V2宣布,继续大选。
节点1收到了V2,发现自己错过了就职时间,很遗憾,只能附和V2.继续推选其他leader。
此时攻击者抑制节点2接受V2消息。
截止当前 节点013都认为节点2是新的leader
只有身为leader的节点2还不知情,继续等待大家选举leader

第四阶段
由于没有收到leader发出的就职消息,大家以为节点2已经崩溃。于是发起新的大选V3
节点2也在收到V2后又收到V3,发现自己已经错过了就职时间。很遗憾但是只能附和V3

不断循环上述过程,所有矿工都陷入无尽的大选循环当中,而不从事任何劳动。导致共识停滞。

总结

只要攻击者能抑制第一个leader发出PP,并顺次抑制其他leader接收Vn
整个网络中的共识就会永久停滞。