概述
Hyperledger是一個旨在推動跨行業(yè)應(yīng)用區(qū)塊鏈技術(shù)的開源項目，由Linux基金會在2016年主導(dǎo)發(fā)起。Hyperledger Fabric是最初引入的兩個項目之一，也是目前應(yīng)用最為廣泛的企業(yè)級聯(lián)盟鏈技術(shù)。 區(qū)塊鏈本質(zhì)上是一個分布式共享賬本，在實際應(yīng)用中，它通常承載著諸如資產(chǎn)和交易之類的敏感數(shù)據(jù)，因此安全和隱私保護(hù)是兩個非常重要的問題。Fabric作為聯(lián)盟鏈的代表技術(shù)給出的解決方案如下：
在安全方面的措施是：
■確保通信的安全性，節(jié)點間的通信都支持用TLS來確保傳輸層的安全。
■對賬本進(jìn)行隔離，讓賬本只在參與共同記賬的組織之間共享，而其他組織無權(quán)訪問賬本。
■區(qū)分參與實體(節(jié)點和應(yīng)用程序客戶端)的角色，為訪問資源的操作設(shè)置嚴(yán)格的權(quán)限控制。
在隱私保護(hù)方面的措施是：
■實現(xiàn)私有數(shù)據(jù)(Private Data)的機(jī)制，解決在一個擁有多個參與組織的賬本中允許某些隱私數(shù)據(jù)只在小部分組織間共享的問題。
■通過身份混淆(Identity Mixer)機(jī)制，實現(xiàn)交易發(fā)起者的匿名性以及不可追蹤性(unlinkability)。
"不可追蹤性"是指：當(dāng)一個用戶發(fā)送多筆交易時，無法從揭示出這些交易是發(fā)送自同一個用戶。
任何技術(shù)的采用都是用來解決某類實際問題的，筆者力圖將研究官網(wǎng)資料時那些感覺跳躍和晦澀的技術(shù)點解釋清楚，做到知其然還知其所以然。限于篇幅，本文主要深入分析安全方面的解決方案，關(guān)于隱私保護(hù)方面的內(nèi)容留將給下一篇文章來闡述。另外，文中難免有所疏漏和錯誤，歡迎各位讀者指正。
01
通信的安全性
一個Fabric區(qū)塊鏈網(wǎng)絡(luò)的例子如下圖所示。該區(qū)塊鏈由Org1和 Org2兩個組織的節(jié)點組成。兩個組織都有Orderer節(jié)點，提供排序和出塊服務(wù)。Peer節(jié)點有多種職責(zé)，在圖中Org1的Peer1和Org2的Peer1承擔(dān)了Endorser、Leader、Committer和Anchor這四種職責(zé)，Org1的Peer2和Org2的Peer2僅承擔(dān)Committer職責(zé)。在節(jié)點之間會發(fā)生以下通信：
應(yīng)用程序客戶端發(fā)起交易時先訪問若干個Endorser Peer節(jié)點去做背書。
然后應(yīng)用程序客戶端將背書結(jié)果封裝成交易提交給任意一個Orderer進(jìn)行交易排序、出塊。
每個組織的Leader Peer從Orderer節(jié)點取回區(qū)塊，經(jīng)驗證后寫入本地賬本。
組織內(nèi)的其他Peer節(jié)點(Commiter)與Leader Peer節(jié)點進(jìn)行賬本同步，也是先驗證再寫本地賬本。
組織間通過Achor peer進(jìn)行數(shù)據(jù)同步(包括賬本信息、節(jié)點信息、私有數(shù)據(jù)等)。
以上1～4步是有關(guān)交易的處理步驟。其中1、2、3步是基于gRPC協(xié)議進(jìn)行通信；第4、5步是基于Gossip協(xié)議，其底層協(xié)議還是走gRPC協(xié)議。Fabric使用TLS(Transport Layer Security)協(xié)議來確保gRPC通信時傳輸層的安全性。具體原理如下：
■每個組織都有自己的TLS Root CA證書，這與其數(shù)據(jù)層的組織Root CA證書獨立開來。
■每個節(jié)點(Orderer和Peer)都有自己的server TLS 證書，是由它所在組織的TLS Root CA簽發(fā)出來的。
那么問題來了，Org1的參與實體(節(jié)點或應(yīng)用程序客戶端)如何與Org2的節(jié)點完成TLS握手呢？當(dāng)Org2的節(jié)點把它的server TLS證書發(fā)送給Org1的實體時，接收方如何驗證該證書？
答案是：Fabric會讓所有參與通道的實體，都能共享到所有通道成員組織的TLS Root CA證書(以及Intermediate CA證書)。這就是所謂的Channel MSPs機(jī)制(請看Channel MSPs章節(jié))。因此，Org1的實體獲得了Org2的組織TLS Root CA證書，所以就能驗證Org2節(jié)點的server TLS證書了。
另外，細(xì)心的讀者可能會發(fā)現(xiàn)，在上圖中沒有畫出Kafka和Zookeeper節(jié)點。這是因為它們不屬于區(qū)塊鏈節(jié)點，而只是排序服務(wù)的實現(xiàn)方式。但為了提高安全性，Orderer到Kafka之間的通信可以配置成TLS，不過這套證書可以不是由組織的TLS Root CA來簽發(fā)。另外劇透一下，F(xiàn)abric將來打算用Raft來替換Kafka，目前正在開發(fā)中。這無疑是件好事，因為在生產(chǎn)級的部署中需要至少4個Kafka和3個Zookeeper，這實在是有點重了。
Fabric節(jié)點可以支持TLS單項認(rèn)證和雙向認(rèn)證，具體方法請參考以下鏈接https://hyperledger-fabric.readthedocs.io/en/release-1.3/enable_tls.html
02
賬本隔離
用通道來隔離賬本
Fabric區(qū)塊鏈?zhǔn)且粋€由不同的組織共同組成的聯(lián)盟鏈。在一條鏈上Fabric可以隔離出多個賬本。那么是如何做到的呢？
如下圖所示，一個Fabric區(qū)塊鏈中多個不同的組織可以組成聯(lián)盟。在聯(lián)盟之下若干不同的組織建立了一個一個的通道，每個通道都有一個獨立的賬本，只有通道成員組織之間才能共享賬本。從這個角度來看，通道機(jī)制可以保證在成員組織之間形成一個專有的私密網(wǎng)絡(luò)，交易在其上以保密方式執(zhí)行，而與外部的無關(guān)組織或個人隔離開來。
MSP
現(xiàn)在再來思考一下“只有通道成員組織之間才能共享賬本”具體意味著什么？其本質(zhì)上是指任意成員組織的應(yīng)用程序客戶端可以訪問任意成員組織的Peer節(jié)點和Orderer節(jié)點來執(zhí)行交易；以及，通道成員組織的節(jié)點之間可以同步賬本。
此外，當(dāng)訪問Peer節(jié)點或Orderer提供的不同服務(wù)時，盡管訪問者屬于某個通道成員組織，但是針對不同的角色應(yīng)有不同的訪問權(quán)限限制（比如：只有組織管理員才允許修改通道配置）。因此，F(xiàn)abric需要有一種管理通道成員關(guān)系的能力，主要包括以下幾點：
能夠認(rèn)證和識別參與者的身份。
以通道為邊界建立信任域(Trust Domain)。這樣所有通道成員組織的各個參與實體（Principal, 即節(jié)點或應(yīng)用程序客戶端）之間可以相互通信和訪問服務(wù)。
能夠識別參與實體的角色。這樣可以針對訪問請求做相應(yīng)的權(quán)限控制。
Fabric實現(xiàn)了MSP(Membership Service Provider)模塊來支持以上各項能力。具體做法是，MSP基于PKI體系為通道成員組織和組織內(nèi)的各個參與實體創(chuàng)建并管理了一組X.509證書和私鑰（如下圖所示），用它們來認(rèn)證身份和角色，以及驗證成員資格。從這個角度來看，MSP的含義也是這組證書和私鑰的代稱。
Fabric實現(xiàn)了支持密碼算法可插拔的BCCSP模塊(blockchain crypto service provider)。MSP使用的非對稱加密算法是橢圓曲線數(shù)字簽名算法(ECDSA)，哈希算法是SHA-256。
■ 圖中左邊的Root CAs和Itermediate CAs表示數(shù)據(jù)層的組織CA證書，用于驗證消息體內(nèi)的簽名者的身份，它與傳輸層的組織TLS CAs和TLS Itermediate CAs獨立開來。
■Administrators是組織內(nèi)擁有管理員角色的用戶的證書。
■Keystore(Private Key)和Signing Certificate是由組織的Root CA簽發(fā)為參與實體簽發(fā)的證書和私鑰，在這些信息只在實體的Local MSP中才有。
■想了解其他元素請參考以下鏈接https://hyperledger-fabric.readthedocs.io/en/release-1.3/enable_tls.html
Local MSP
Local MSP是指組織的參與實體(Peer節(jié)點、Orderer節(jié)點以及應(yīng)用程序客戶端)存在于本地的MSP信息。它至少包含了組織的Root CAs證書、組織的TLS Root CAs、實體自己的證書和私鑰，以及組織的Administrators證書。通過Local MSP，當(dāng)與其他節(jié)點通信時，實體可以用私鑰對發(fā)送的消息進(jìn)行簽名以向?qū)Ψ焦?jié)點表明自己的身份；也可以用來認(rèn)證組織內(nèi)的其他成員實體發(fā)送的消息，并對某些操作做權(quán)限控制。比如：Peer節(jié)點可以用Local MSP中的私鑰對背書響應(yīng)結(jié)果進(jìn)行簽名。再舉個例子，應(yīng)用程序客戶端可以用組織管理員的身份在他的組織的Peer節(jié)點上安裝智能合約。
Channel MSPs
那么如何通過MSP建立以通道為邊界的信任域呢？
答案是：Fabric讓各個通道成員組織的節(jié)點和應(yīng)用程序客戶端共享一個全局的Channel MSPs，它是所有通道成員組織的MSP的集合。每個通道成員組織的MSP中主要包括：組織的Root CAs, TLS CAs和Administrators證書。通過Channel MSPs，各個參與實體可以驗證其他成員組織的參與實體的身份和角色，以及驗證通道成員資格。
共享Channel MSPs的機(jī)制如下：
當(dāng)通道創(chuàng)建成功后，Channel MSPs會被寫入通道配置中(即賬本的創(chuàng)始塊)。當(dāng)通道成員組織的Peer節(jié)點加入通道時會得到通道配置，因而獲得了Channel MSPs。如下圖所示。
Peer加入通道的過程實際上是由應(yīng)用程序客戶端以管理員身份先從Orderer取得賬本的通道配置，然后傳給該P(yáng)eer節(jié)點。
圖中沒有提及的是應(yīng)用程序客戶端如何獲得Channel MSPs，其實是通過Fabric SDK在初始化本地的Channel實例時，會連接到Peer節(jié)點獲取通道配置，從中提取Channel MSPs。
身份驗證
通過Local MSP和Channel MSPs，通道內(nèi)的各個節(jié)點和應(yīng)用程序客戶端在傳輸層和數(shù)據(jù)層都可以相互驗證身份。而來自通道以外的其他訪問請求，因為無法通過通道成員身份驗證而被拒之門外。以應(yīng)用程序客戶端請求Endoser Peer節(jié)點進(jìn)行背書的過程為例(如下圖所示)，其發(fā)送的gRPC消息結(jié)構(gòu)是一個SignedProposal類型，消息中包含對payload(即ProposalBytes)的簽名(即Signature)，在Proposal->Header->SignatureHeader中包含了用戶證書信息。Endoser Peer用Channel MSPs中某個組織的Root CA證書來驗證簽名頭中的用戶證書，然后用用戶證書來驗證消息的簽名，從而確定其用戶身份以及是否具有通道成員資格。
03
訪問權(quán)限控制
訪問權(quán)限控制是Fabric中十分重要的功能，主要解決誰在某個場景下是否允許訪問某些資源的問題。用戶在與Fabric進(jìn)行交互時，實際上是訪問用戶智能合約、系統(tǒng)智能合約或者是Event Stream Source（Eventing Peer提供的事件服務(wù)）等服務(wù)，這些服務(wù)都被視為資源。Fabric主要通過策略(Policy)來控制各種場景下訪問這些資源的權(quán)限限制。Fabric實現(xiàn)了兩種類型的Policy來滿足不同的場景需求：
■Signature Policy: 用于明確指定哪些參與實體(Principal)必須簽名，才能滿足該策略。它支持AND, OR, 以及 NOutOf這樣的策略組合。比如："必須Org1和Org2的成員都簽名"，或者“在20個組織管理員中至少有11個人的簽名”。
應(yīng)用場景是：背書策略、智能合約實例化策略等。
■ImplicitMeta Policy: 它不像Signature Policy那么靈活，而是組合了多條子策略評估的結(jié)果，只有組合的結(jié)果滿足給定規(guī)則(Rule)，才能滿足該策略。這種策略的描述形式是: "<rule> <sub_policy>"。默認(rèn)支持的Rule有：ANY, ALL, MAJORITY。比如："超過半數(shù)的通道內(nèi)組織的管理員簽名"（Rule則是：超過半數(shù)，子策略是：組織的管理員簽名）。
應(yīng)用場景是：用于配置管理相關(guān)的操作比如：通道創(chuàng)建策略、通道配置策略等，以及從Orderer讀取通道配置的策略，或者訪問Peer獲取區(qū)塊的策略等等。
關(guān)于Policy的官方介紹請參考以下鏈接
https://hyperledger-fabric.readthedocs.io/en/release-1.3/policies.html
現(xiàn)在拿背書策略和通道配置策略來分別舉例說明。
背書策略
背書策略(Endorsement Policy)是一個典型的Signature Policy，Peer節(jié)點中的系統(tǒng)智能合約VSCC用它來檢查交易中包含的背書簽名否滿足策略的要求。
VSCC(Verification System Chaincode)除了驗證背書策略，它還檢查交易信息的讀集合中的每一個Key-Value Pair的數(shù)據(jù)版本是否發(fā)生了變化。
一個背書策略的例子如下所示：
OR(AND('Org1MSP.peer', 'Org2MSP.peer'), 'Org3MSP.peer')
其含義是只有當(dāng)Org1和Org2都進(jìn)行了背書簽名，或者Org3進(jìn)行了背書簽名，這筆交易才能被認(rèn)為有效。
在背書策略中有一個容易忽視的地方是：簽名者身份(Identity)的表示形式是"MSP.ROLE"，比如：'Org1.peer'。 那么是不是意味著，只認(rèn)可組織Org1的Endorser Peer節(jié)點對背書結(jié)果的簽名，而不認(rèn)可組織Org1的其他類型的實體(比如：應(yīng)用程序客戶端)對背書結(jié)果的簽名呢？
答案是：沒錯，'Org1.peer'表示只認(rèn)可組織Org1的Endorser Peer節(jié)點的背書簽名。
基于x.509證書的OUs屬性，F(xiàn)abric將簽名者身份的證書進(jìn)一步分為client和peer兩種類型。將那些可以進(jìn)行發(fā)起交易、查詢Peer節(jié)點等操作的參與實體的身份歸為client類型，比如應(yīng)用程序客戶端的用戶證書；將那些可以進(jìn)行背書或提交賬本等操作的參與實體的身份歸為peer類型，比如Endorser Peer節(jié)點和Committer Peer節(jié)點。
client類型的證書中的OU屬性等于'client'，而peer類型的證書中的OU屬性等于'peer'。以下截取了Org1的Endorser Peer節(jié)點證書片段。
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類型的證書，詳細(xì)內(nèi)容請參考以下鏈接
https://hyperledger-fabric.readthedocs.io/en/release-1.3/msp.html
。當(dāng)然，如果你是自己實現(xiàn)證書生成的功能并想做身份分類的話，請自行設(shè)置證書的OU為peer或者client。
■ Fabric v1.3還支持key-level的背書策略，它將覆蓋智能合約級別的背書策略，有關(guān)更多內(nèi)容請參考以下鏈接
https://hyperledger-fabric.readthedocs.io/en/release-1.3/endorsement-policies.html
通道配置策略
當(dāng)向一個已有的通道中新增組織時，需要符合設(shè)定的通道配置策略，它位于賬本的通道配置區(qū)塊中。
通道配置策略是一種典型的ImplicitMeta Policy，該類型的策略不會直接進(jìn)行簽名檢查，而是通過組合其配置層次中的子元素的策略（即子策略）來進(jìn)行檢查，然后根據(jù)Rule來判斷策略是否滿足。這里提到的配置層次可能讓人費解，直接來看一下通道配置的數(shù)據(jù)結(jié)構(gòu)吧，它構(gòu)成一個樹狀層次結(jié)構(gòu)，如下圖所示。所謂”配置層次“就是指這個樹狀層次結(jié)構(gòu)。
目前通道中已有了三個組織：Org1, Org2, Org3。通道配置策略的位置是：/Channel/Application/Admins。它是一個ImplicitMeta Policy類型的策略，Rule是"MAJORITY", sub_policy是"Admins"。它表示需要檢查所有組織下名為"Admins"的子策略，并且超過半數(shù)的子策略都須滿足。組織的"Admins"策略的位置是(以O(shè)rg1為例)：/Channel/Application/Org1/Admins。它是一個Signature Policy類型的策略，表示要求Org1的管理員角色簽名。此時，如果Org4要加入通道，那么要求3個組織中，至少有2個組織的管理員簽名才行。
Farbic v1.3已支持通過在configtx.yaml中設(shè)置訪問控制權(quán)限，有關(guān)更多內(nèi)容請參考以下鏈接
https://hyperledger-fabric.readthedocs.io/en/release-1.3/access_control.html
————————————————
原文鏈接：https://blog.csdn.net/w365904/article/details/100159932
