为了账号安全,请及时绑定邮箱和手机立即绑定

超级账本 Fabric 新特性之细粒度隐私保护

2018.07.08 02:41 908浏览

echFirst 超级账本 Fabric 新特性之细粒度隐私保护

超级账本 Fabric 社区自 1.1 版本开始,关于增强通道内隐私保护的新特性引发不少讨论,如 FAB-1151、 FAB-2961、 FAB-4976、FAB-8718。本文将总结该特性设计过程的来龙去脉,以供后续开发者更好地理解最初的设计意图和核心思想。

隐私保护问题

超级账本 Fabric 1.x 系列版本中在增强隐私性方面做了很大改进,1.0 版本中一个重要特性就是多通道(Multiple-channel)的支持。使用该特性,账本网络中若干成员可以协商构建一个专属通道与外部隔离,通道外的节点无法看到其中的账本和交易数据,极大地提高了隐私性。

然而,在有些场景下单纯使用通道来保护数据安全仍然存在不足:

  • 虽然外部 Peer 节点无法看到通道内交易数据,但排序(Ordering)服务可以看到所有通道的所有数据

  • 通道内的 Peer 节点能看到通道内所有数据,即使跟自己无关的交易,即粒度还是比较粗

  • 为了保护任意多方之间的隐私,需要构建大量(O(n^2)量级)的通道,而通道是比较重的资源,而且目前还不支持删除操作

  • 某些时候,成员对数据的访问控制需要一定的动态性,通道机制无法满足。

总之,需要一些更灵活的方案,来实现更细粒度的数据安全保护。

现状剖析

首先来看下,当前 Fabric 对交易的处理流程中,哪些环节有可能进一步改进隐私性。

  • 背书过程:客户端将交易提案发送给相关的 Peer 节点,Peer 节点利用链码进行模拟执行,对结果的读写集合进行签名,返回给客户端。在这个过程中,客户端可以选择将需要保护的私有提案只发给选中的若干节点(授权组)进行背书。但节点可能会动态加入或退出授权组,并且客户端无法保证实时获知授权组的变化,因此授权组内的节点之间要能相互传播私有数据。

  • 排序过程:客户端根据背书结果构造合理的交易请求(带有读写集),发送给排序服务,排序服务对交易进行排序和打包成块。在这个过程中,排序节点显然其实不需要访问交易内容。为了增强隐私性,客户端不能将私有交易的内容直接发给排序服务。

  • 提交过程:通道内的 Peer 们经由 Leader Peer 获取到排序后的交易信息,在各自本地账本进行再次验证,最后提交。这一环节中,完成交易提交的节点必须能获知交易的读写集明文。为了避免所有节点看到明文,需要本地建立隔离的状态数据库和链结构来专门存放私有交易数据。

增强排序环节隐私性

首先来看相对独立的排序环节。

为了避免排序服务看到明文交易数据,很自然地,可以将交易数据提前进行保护处理,让排序服务只拿到处理后的结果。但这个结果对于授权的部分节点来说,必须还要能对应回原先的交易数据,不然无法完成最终的提交操作。

最基本的两种手段是加密和 Hash,主要的差异如下表所示。

比较加密处理Hash 处理
恢复可以恢复理论上无法恢复
额外数据(如密钥)需要密钥加密无需(加盐除外)
破解算法保证,一般较难破解理论上除了穷举碰撞很难破解

无论是哪种方案,都可以保证排序服务无法直接看到交易明文。从安全性上来看,采用 Hash 方法会更难破解。

注意:简单 Hash 机制无法抵挡基于统计的破解,但实现中很容易通过结合加盐或 HMAC 等机制来提高抗破解强度。

思考:实际上,映射表机制也可以满足增强排序环节隐私性的需求,然而需要额外维护和存放表结构,并不比 Hash 机制更加安全。

增强背书环节隐私性

由于在背书过程,Peer 节点需要通过提案计算读写集,并通过签名证实背书通过,这意味着:

  • 执行背书的 Peer 节点应能看到交易明文,只有这样才能进行交易逻辑的模拟执行,并将结果返回客户端;

  • 客户端拿到的节点返回的消息中,必须包含对处理(加密 or Hash)后结果进行的签名,这是因为客户端无法也不应该替 Peer 节点进行签名。

下面分别讨论采用加密或 Hash 机制。

采用加密机制的设计

采用加密机制,客户端发送明文的提案给背书 Peer,背书 Peer 验证后执行提案,获得结果读写集,对读写集使用某个密钥加密,签名并返回客户端。客户端要比对不同的背书结果,因此,要么能解密所有的响应结果(难实现),要么所有背书节点采用同一密钥加密(意味着密钥需要由客户端产生)。

注意,只有授权的 Peer 节点可以访问明文读写集(彼此通过 Gossip 传播),并最终提交结果到本地的私有状态数据库。

整个过程中最关键的还是密钥的分发和管理。

为了提高安全性,客户端可以将加密密钥通过授权 Peer 的公钥进行加密后再传播;为了避免关联性,客户端可以对于不同的交易采用不同的密钥,当然这会增加网络中加解密处理的计算量。授权 Peer 节点之间可以通过某种方式(如 Gossip)主动进行组内的密钥分发。

一个不太好解决的问题是,交易处理完成后,密钥是否需要保存?如果保存,可能将来会造成泄露;如果不保存,后来授权的 Peer 可能无法根据公开的区块链结构同步结果到私有状态数据库。另外,保存在客户端还是 Peer 节点。这些都是比较难解决的问题。

采用 Hash 机制的设计

采用 Hash 机制,客户端发送明文的提案给背书 Peer,背书 Peer 验证后执行提案,获得结果读写集,对读写集计算 Hash 值,签名并返回客户端。

在这个过程中,只要背书节点的 Hash 过程一致,对于相同读写集,客户端可以容易验证结果的一致性。

同样,明文读写集可以通过 Gossip 传播在授权组内传播。

这也是 1.1 版本开始支持的 sideDB 特性的基本实现思路

增强提交环节隐私性

提交环节需要将读写集内容写到本地状态数据库,并记录交易到区块链结构中。因此,对于授权组内节点来说必须要能获知明文的读写集。

sideDB 中除了新的私有状态数据库、私有区块链结构之外,还额外创建一个临时的本地私有数据库,保存在背书环节中读写集明文以及到对应 Hash 值之间的映射关系。当对应交易提交时,将读写集明文内容更新到私有的状态数据库和区块链结构中,将 Hash 后的交易更新到公共结构中。

授权管理

授权组是静态情况下,可以通过对链码进行实例化时指定;当授权组需要支持动态增删时,则要复杂的多。

一个典型的问题是,是否允许新加入的节点访问之前的私有数据?

另外,授权组的策略如何在网络中同步?如何保证 Peer 能拿到最新的授权策略,而不至于将私有数据发给了过期的邻居?

这些都是一些开放的问题,预计将在 1.2 版本中初步解决。

总结

超级账本 Fabric 引入了 sideDB 机制,通过 Hash 处理和私有数据结构,在通道内部实现了更细粒度的隐私保护。Hash 后的交易内容仍然会发送到排序节点,并提交到公共的数据库和账本结构中。而授权组的 Peer 节点则在本地维护私有的状态数据库和区块链结构,保存交易的明文内容。这就保证了通道内其他节点无法看到授权组的交易内容。




点击查看更多内容
0人点赞

若觉得本文不错,就分享一下吧!

评论

相关文章推荐

正在加载中
意见反馈 邀请有奖 帮助中心 APP下载
官方微信

举报

0/150
提交
取消