概述

Hyperledger是一個旨在推動跨行業應用區塊鏈技術的開源項目，由Linux基金會在2016年主導發起。Hyperledger Fabric是最初引入的兩個項目之一，也是目前應用最爲廣泛的企業級聯盟鏈技術。 區塊鏈本質上是一個分佈式共享賬本，在實際應用中，它通常承載着諸如資產和交易之類的敏感數據，因此安全和隱私保護是兩個非常重要的問題。Fabric作爲聯盟鏈的代表技術給出的解決方案如下：

在安全方面的措施是：

■確保通信的安全性，節點間的通信都支持用TLS來確保傳輸層的安全。

■對賬本進行隔離，讓賬本只在參與共同記賬的組織之間共享，而其他組織無權訪問賬本。

■區分參與實體(節點和應用程序客戶端)的角色，爲訪問資源的操作設置嚴格的權限控制。

在隱私保護方面的措施是：

■實現私有數據(Private Data)的機制，解決在一個擁有多個參與組織的賬本中允許某些隱私數據只在小部分組織間共享的問題。

■通過身份混淆(Identity Mixer)機制，實現交易發起者的匿名性以及不可追蹤性(unlinkability)。

"不可追蹤性"是指：當一個用戶發送多筆交易時，無法從揭示出這些交易是發送自同一個用戶。

任何技術的採用都是用來解決某類實際問題的，筆者力圖將研究官網資料時那些感覺跳躍和晦澀的技術點解釋清楚，做到知其然還知其所以然。限於篇幅，本文主要深入分析安全方面的解決方案，關於隱私保護方面的內容留將給下一篇文章來闡述。另外，文中難免有所疏漏和錯誤，歡迎各位讀者指正。

01

通信的安全性

一個Fabric區塊鏈網絡的例子如下圖所示。該區塊鏈由Org1和 Org2兩個組織的節點組成。兩個組織都有Orderer節點，提供排序和出塊服務。Peer節點有多種職責，在圖中Org1的Peer1和Org2的Peer1承擔了Endorser、Leader、Committer和Anchor這四種職責，Org1的Peer2和Org2的Peer2僅承擔Committer職責。在節點之間會發生以下通信：

1. 應用程序客戶端發起交易時先訪問若干個Endorser Peer節點去做背書。

2. 然後應用程序客戶端將背書結果封裝成交易提交給任意一個Orderer進行交易排序、出塊。

3. 每個組織的Leader Peer從Orderer節點取回區塊，經驗證後寫入本地賬本。

4. 組織內的其他Peer節點(Commiter)與Leader Peer節點進行賬本同步，也是先驗證再寫本地賬本。

5. 組織間通過Achor peer進行數據同步(包括賬本信息、節點信息、私有數據等)。

以上1～4步是有關交易的處理步驟。其中1、2、3步是基於gRPC協議進行通信；第4、5步是基於Gossip協議，其底層協議還是走gRPC協議。Fabric使用TLS(Transport Layer Security)協議來確保gRPC通信時傳輸層的安全性。具體原理如下：

■每個組織都有自己的TLS Root CA證書，這與其數據層的組織Root CA證書獨立開來。

■每個節點(Orderer和Peer)都有自己的server TLS 證書，是由它所在組織的TLS Root CA簽發出來的。

那麼問題來了，Org1的參與實體(節點或應用程序客戶端)如何與Org2的節點完成TLS握手呢？當Org2的節點把它的server TLS證書發送給Org1的實體時，接收方如何驗證該證書？

答案是：Fabric會讓所有參與通道的實體，都能共享到所有通道成員組織的TLS Root CA證書(以及Intermediate CA證書)。這就是所謂的Channel MSPs機制(請看Channel MSPs章節)。因此，Org1的實體獲得了Org2的組織TLS Root CA證書，所以就能驗證Org2節點的server TLS證書了。

另外，細心的讀者可能會發現，在上圖中沒有畫出Kafka和Zookeeper節點。這是因爲它們不屬於區塊鏈節點，而只是排序服務的實現方式。但爲了提高安全性，Orderer到Kafka之間的通信可以配置成TLS，不過這套證書可以不是由組織的TLS Root CA來簽發。另外劇透一下，Fabric將來打算用Raft來替換Kafka，目前正在開發中。這無疑是件好事，因爲在生產級的部署中需要至少4個Kafka和3個Zookeeper，這實在是有點重了。

Fabric節點可以支持TLS單項認證和雙向認證，具體方法請參考以下鏈接https://hyperledger-fabric.readthedocs.io/en/release-1.3/enable_tls.html

02

賬本隔離

用通道來隔離賬本

Fabric區塊鏈是一個由不同的組織共同組成的聯盟鏈。在一條鏈上Fabric可以隔離出多個賬本。那麼是如何做到的呢？

如下圖所示，一個Fabric區塊鏈中多個不同的組織可以組成聯盟。在聯盟之下若干不同的組織建立了一個一個的通道，每個通道都有一個獨立的賬本，只有通道成員組織之間才能共享賬本。從這個角度來看，通道機制可以保證在成員組織之間形成一個專有的私密網絡，交易在其上以保密方式執行，而與外部的無關組織或個人隔離開來。

MSP

現在再來思考一下“只有通道成員組織之間才能共享賬本”具體意味着什麼？其本質上是指任意成員組織的應用程序客戶端可以訪問任意成員組織的Peer節點和Orderer節點來執行交易；以及，通道成員組織的節點之間可以同步賬本。

此外，當訪問Peer節點或Orderer提供的不同服務時，儘管訪問者屬於某個通道成員組織，但是針對不同的角色應有不同的訪問權限限制（比如：只有組織管理員才允許修改通道配置）。因此，Fabric需要有一種管理通道成員關係的能力，主要包括以下幾點：

1. 能夠認證和識別參與者的身份。

2. 以通道爲邊界建立信任域(Trust Domain)。這樣所有通道成員組織的各個參與實體（Principal, 即節點或應用程序客戶端）之間可以相互通信和訪問服務。

3. 能夠識別參與實體的角色。這樣可以針對訪問請求做相應的權限控制。

Fabric實現了MSP(Membership Service Provider)模塊來支持以上各項能力。具體做法是，MSP基於PKI體系爲通道成員組織和組織內的各個參與實體創建並管理了一組X.509證書和私鑰（如下圖所示），用它們來認證身份和角色，以及驗證成員資格。從這個角度來看，MSP的含義也是這組證書和私鑰的代稱。

Fabric實現了支持密碼算法可插拔的BCCSP模塊(blockchain crypto service provider)。MSP使用的非對稱加密算法是橢圓曲線數字簽名算法(ECDSA)，哈希算法是SHA-256。

■ 圖中左邊的Root CAs和Itermediate CAs表示數據層的組織CA證書，用於驗證消息體內的簽名者的身份，它與傳輸層的組織TLS CAs和TLS Itermediate CAs獨立開來。

■Administrators是組織內擁有管理員角色的用戶的證書。

■Keystore(Private Key)和Signing Certificate是由組織的Root CA簽發爲參與實體簽發的證書和私鑰，在這些信息只在實體的Local MSP中才有。

■想了解其他元素請參考以下鏈接https://hyperledger-fabric.readthedocs.io/en/release-1.3/enable_tls.html

Local MSP

Local MSP是指組織的參與實體(Peer節點、Orderer節點以及應用程序客戶端)存在於本地的MSP信息。它至少包含了組織的Root CAs證書、組織的TLS Root CAs、實體自己的證書和私鑰，以及組織的Administrators證書。通過Local MSP，當與其他節點通信時，實體可以用私鑰對發送的消息進行簽名以向對方節點表明自己的身份；也可以用來認證組織內的其他成員實體發送的消息，並對某些操作做權限控制。比如：Peer節點可以用Local MSP中的私鑰對背書響應結果進行簽名。再舉個例子，應用程序客戶端可以用組織管理員的身份在他的組織的Peer節點上安裝智能合約。

Channel MSPs

那麼如何通過MSP建立以通道爲邊界的信任域呢？

答案是：Fabric讓各個通道成員組織的節點和應用程序客戶端共享一個全局的Channel MSPs，它是所有通道成員組織的MSP的集合。每個通道成員組織的MSP中主要包括：組織的Root CAs, TLS CAs和Administrators證書。通過Channel MSPs，各個參與實體可以驗證其他成員組織的參與實體的身份和角色，以及驗證通道成員資格。

共享Channel MSPs的機制如下：

當通道創建成功後，Channel MSPs會被寫入通道配置中(即賬本的創始塊)。當通道成員組織的Peer節點加入通道時會得到通道配置，因而獲得了Channel MSPs。如下圖所示。

Peer加入通道的過程實際上是由應用程序客戶端以管理員身份先從Orderer取得賬本的通道配置，然後傳給該Peer節點。

圖中沒有提及的是應用程序客戶端如何獲得Channel MSPs，其實是通過Fabric SDK在初始化本地的Channel實例時，會連接到Peer節點獲取通道配置，從中提取Channel MSPs。

身份驗證

通過Local MSP和Channel MSPs，通道內的各個節點和應用程序客戶端在傳輸層和數據層都可以相互驗證身份。而來自通道以外的其他訪問請求，因爲無法通過通道成員身份驗證而被拒之門外。以應用程序客戶端請求Endoser Peer節點進行背書的過程爲例(如下圖所示)，其發送的gRPC消息結構是一個SignedProposal類型，消息中包含對payload(即ProposalBytes)的簽名(即Signature)，在Proposal->Header->SignatureHeader中包含了用戶證書信息。Endoser Peer用Channel MSPs中某個組織的Root CA證書來驗證簽名頭中的用戶證書，然後用用戶證書來驗證消息的簽名，從而確定其用戶身份以及是否具有通道成員資格。

03

訪問權限控制

訪問權限控制是Fabric中十分重要的功能，主要解決誰在某個場景下是否允許訪問某些資源的問題。用戶在與Fabric進行交互時，實際上是訪問用戶智能合約、系統智能合約或者是Event Stream Source（Eventing Peer提供的事件服務）等服務，這些服務都被視爲資源。Fabric主要通過策略(Policy)來控制各種場景下訪問這些資源的權限限制。Fabric實現了兩種類型的Policy來滿足不同的場景需求：

■Signature Policy: 用於明確指定哪些參與實體(Principal)必須簽名，才能滿足該策略。它支持AND, OR, 以及 NOutOf這樣的策略組合。比如："必須Org1和Org2的成員都簽名"，或者“在20個組織管理員中至少有11個人的簽名”。

應用場景是：背書策略、智能合約實例化策略等。

■ImplicitMeta Policy: 它不像Signature Policy那麼靈活，而是組合了多條子策略評估的結果，只有組合的結果滿足給定規則(Rule)，才能滿足該策略。這種策略的描述形式是: "<rule> <sub_policy>"。默認支持的Rule有：ANY, ALL, MAJORITY。比如："超過半數的通道內組織的管理員簽名"（Rule則是：超過半數，子策略是：組織的管理員簽名）。

應用場景是：用於配置管理相關的操作比如：通道創建策略、通道配置策略等，以及從Orderer讀取通道配置的策略，或者訪問Peer獲取區塊的策略等等。

關於Policy的官方介紹請參考以下鏈接

https://hyperledger-fabric.readthedocs.io/en/release-1.3/policies.html

現在拿背書策略和通道配置策略來分別舉例說明。

背書策略

背書策略(Endorsement Policy)是一個典型的Signature Policy，Peer節點中的系統智能合約VSCC用它來檢查交易中包含的背書籤名否滿足策略的要求。

VSCC(Verification System Chaincode)除了驗證背書策略，它還檢查交易信息的讀集合中的每一個Key-Value Pair的數據版本是否發生了變化。

一個背書策略的例子如下所示：

OR(AND('Org1MSP.peer', 'Org2MSP.peer'), 'Org3MSP.peer')

其含義是隻有當Org1和Org2都進行了背書籤名，或者Org3進行了背書籤名，這筆交易才能被認爲有效。

在背書策略中有一個容易忽視的地方是：簽名者身份(Identity)的表示形式是"MSP.ROLE"，比如：'Org1.peer'。 那麼是不是意味着，只認可組織Org1的Endorser Peer節點對背書結果的簽名，而不認可組織Org1的其他類型的實體(比如：應用程序客戶端)對背書結果的簽名呢？

答案是：沒錯，'Org1.peer'表示只認可組織Org1的Endorser Peer節點的背書籤名。

基於x.509證書的OUs屬性，Fabric將簽名者身份的證書進一步分爲client和peer兩種類型。將那些可以進行發起交易、查詢Peer節點等操作的參與實體的身份歸爲client類型，比如應用程序客戶端的用戶證書；將那些可以進行背書或提交賬本等操作的參與實體的身份歸爲peer類型，比如Endorser Peer節點和Committer Peer節點。

client類型的證書中的OU屬性等於'client'，而peer類型的證書中的OU屬性等於'peer'。以下截取了Org1的Endorser Peer節點證書片段。

Certificate:

... content ommited ...

Subject: C=CN, ST=Shanghai, L=Shanghai, OU=peer, CN=peer1.org1.aaa.com

... content ommited ...

■Fabric v1.3支持通過配置config.yaml來生成client和peer類型的證書，詳細內容請參考以下鏈接

https://hyperledger-fabric.readthedocs.io/en/release-1.3/msp.html

。當然，如果你是自己實現證書生成的功能並想做身份分類的話，請自行設置證書的OU爲peer或者client。

■ Fabric v1.3還支持key-level的背書策略，它將覆蓋智能合約級別的背書策略，有關更多內容請參考以下鏈接

https://hyperledger-fabric.readthedocs.io/en/release-1.3/endorsement-policies.html

通道配置策略

當向一個已有的通道中新增組織時，需要符合設定的通道配置策略，它位於賬本的通道配置區塊中。

通道配置策略是一種典型的ImplicitMeta Policy，該類型的策略不會直接進行簽名檢查，而是通過組合其配置層次中的子元素的策略（即子策略）來進行檢查，然後根據Rule來判斷策略是否滿足。這裏提到的配置層次可能讓人費解，直接來看一下通道配置的數據結構吧，它構成一個樹狀層次結構，如下圖所示。所謂”配置層次“就是指這個樹狀層次結構。

目前通道中已有了三個組織：Org1, Org2, Org3。通道配置策略的位置是：/Channel/Application/Admins。它是一個ImplicitMeta Policy類型的策略，Rule是"MAJORITY", sub_policy是"Admins"。它表示需要檢查所有組織下名爲"Admins"的子策略，並且超過半數的子策略都須滿足。組織的"Admins"策略的位置是(以Org1爲例)：/Channel/Application/Org1/Admins。它是一個Signature Policy類型的策略，表示要求Org1的管理員角色簽名。此時，如果Org4要加入通道，那麼要求3個組織中，至少有2個組織的管理員簽名纔行。

Farbic v1.3已支持通過在configtx.yaml中設置訪問控制權限，有關更多內容請參考以下鏈接

https://hyperledger-fabric.readthedocs.io/en/release-1.3/access_control.html

04

總結

通過深入瞭解，可以看到Fabric在通信傳輸層、賬本隔離以及權限控制方面都有非常嚴謹的設計和實現。不過，如果要完全支撐現實業務的需求，解決隱私保護的問題也非常重要，這一部分將在下一篇文章中介紹。很高興與大家一起學習交流。謝謝: )

查看原文 >>