2018-05-18 TechFirst 超级账本 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 节点则在本地维护私有的状态数据库和区块链结构，保存交易的明文内容。这就保证了通道内其他节点无法看到授权组的交易内容。