1.身份(Identity)
区块链网络中的不同参与者,包括peers、orderers、管理员等,都有一个封装在X.509电子证书中的身份。这个身份非常重要,因为他决定了区块链网络中的参与者对资源和信息的访问权限。
电子身份还会衍生出其主体(principal),类似id,但是更加灵活,因为它可以包含参与者身份的其他属性,如组织、角色、甚至参与者特有的身份,当讨论主体的时候,实际上是在讨论他所拥有的权限。
为了让身份可验证,它必须来源于一个可行的权威机构。一个MSP(membership service provider)就可以担任这样的角色,MSP是一个定义管理组织内有效身份规则的组件。fabric中默认的MSP使用X.509证书来标识身份,采用了传统的PKI(公钥基础设施)层模型。
PKI与MSP一同为身份的使用提供了便利,简单来说,PKI提供了一个身份的列表,类比于发行信用卡的机构,而MSP来决定网络中的哪些组织可以参与网络中的交易处理,类比于商店中给出的说明哪些信用卡可以在本店使用的公告。MSP将验证的身份变成了区块链网络中的成员。
PKI是一个提供网络安全通信的互联网技术的集合,因为区块链并不只是一个用于交流的网络,它需要一定的安全机制,来确保信息发送者真的是他的信息所宣称的主体,而PKI就提供了这些技术,而不用自己去想办法重新实现一遍了。
PKI有四种元素
- 电子证书
- 公私钥
- 证书发行权威机构
- 证书撤回列表(让发行的证书作废)
电子证书含有其持有者的相关属性,比较常用的是X.509标准,如其国家、签名方式等,其中主体是最关键的属性。证书中含有公钥,不含有私钥。只要信任证书的签发着(CA),就可以信任证书持有者,而持有者通过私钥来证明他对证书的所有权(通过加密算法验证公私钥是否对应)。而有了公私钥之后就可以用于传递加密信息以及验证身份了,其中公钥加密,私钥解密用于传输秘密数据,而私钥加密公钥解密用于签名,保证某个数据确实是证书拥有者所发出的,以及消息没有篡改。因此电子证书就可以在区块链中证明一个参与者的身份。
因为CA对身份有着重要的意义,Fabric中也有CA的自定义实现,他不能提供那种用于常规认证的SSL证书,但足以在fabric网络中使用,也可以采用通用的CA来作为fabric中的CA。
CA有一个证书撤回列表(CRL),在验证证书的时候,首先会去证书签署CA查看CRL,确认这个证书仍然是可用的。
2.MSP(Membership Service Provider)
MSP的存在是由Fabric是联盟链的性质决定的,需要MSP来选择有哪些身份可以加入这个联盟。在实现上,MSP中包含了联盟参与者的公钥,联盟参与者会使用私钥对交易进行签名背书,MSP可以通过验证签名的方式来确保交易背书者是联盟参与者,由此将一个身份转化成一个角色或一种权限,也是fabric的基础能力,它让组织、节点、通道都可以建立自己的MSP来决定谁能参与到其中。
为了成为fabric网络中的一个成员,需要如下四个步骤
- 由网络信任的CA签发证明身份的证书。
- 成为一个被网络所认识与批准的组织的成员,具体实现就是通过加入成员的证书到组织的MSP中。
- 将该MSP添加到通道中。
- 确保MSP被包含在了网络的安全策略定义中。
MSP的本质是一个被添加到网络配置中的文件夹集合,MSP定义了哪些根CA或者中间CA可以签署的证书可以被接受,MSP除了列出这些CA之外,还可以通过验证权限将身份转换为角色。
在区块链网络中MSP有两种作用域:
- local MSP
- 为了客户端和orderer或peer节点使用,定义哪些用户是节点管理员或者参与者等
- 每一个节点都必须有一个local MSP定义
- localMSP仅包含在文件系统中定义的节点或用户。
- 逻辑和物理上每个节点都只有一个local MSP。
- channel MSP
- 在通道级别上,定义哪些用户是节点管理员或者参与者等
- 通道中的每一个组织都必须有一个MSP来定义它。
- channel MSP包含通道中的所有组织,peer、orderer等都包含。
- 逻辑上,一个通道只有一个MSP,物理上,通道中的每一个节点都有一个channel MSP的副本,通过共识达成一致。
OU(Organizational Units)可以看作一种更细粒度的MSP,可以理解为一个公司的不同部门,可以通过基于属性的访问权限控制用于限制对智能合约的访问权限,否则,就只能为每个组织创建多个MSP来实现了。OU字段存在于证书的属性中。
实践中可以用如下的配置方式来使用:
NodeOUs:
Enable: true
ClientOUIdentifier:
Certificate: cacerts/ca.org2.example.com-cert.pem
OrganizationalUnitIdentifier: client
PeerOUIdentifier:
Certificate: cacerts/ca.org2.example.com-cert.pem
OrganizationalUnitIdentifier: peer
AdminOUIdentifier:
Certificate: cacerts/ca.org2.example.com-cert.pem
OrganizationalUnitIdentifier: admin
OrdererOUIdentifier:
Certificate: cacerts/ca.org2.example.com-cert.pem
OrganizationalUnitIdentifier: orderer
- config.yaml:用于定义Fabric身份类型(Node OU)与可接受角色等。
- cacerts:包含此MSP代表组织的信任根CA自签名X.509证书列表,其中至少有一个CA证书,它标识了根CA,其他证书必须由该CA派生,才能试作该组织成员,由此形成信任链。
- intermediatecerts:保存信任链上的中间CA的自签名证书,此文件夹可能为空。
- admincerts:已废弃
- keystore(private key):仅对peer和order的local MSP有用(channel MSP只需要验证身份,不需要签署数据,所以没有),包含节点的私钥,用于签署数据,比如签署交易用于提议。该文件夹只能包含一个私钥。应当配置只有管理员身份的人可以访问这个文件夹。
- signcert:仅对peer和order的local MSP有用(channel MSP只需要验证身份,不需要签署数据,所以没有),包含CA签署的证书,证明节点的身份,可以让其他节点用这张证书的副本来验证该节点的签名,因为要证明节点的身份,因此该文件夹下只有一个公钥。应当配置只有管理员身份的人可以访问这个文件夹。
- tlscacerts:包含若干该组织信任的根CA的自签证书,主要用于节点间的安全通信,类比于HTTPS,文件夹下至少应当有一张证书。
- tlsintermediatecerts:包含中间CA证书列表,用于节点间的安全通信。
- operationscert:包含与Fabric 操作服务通信所需证书。
channel MSP还包括Revoked Certificated:用于存放移除出channel的参与者的证书,来表示将某个身份移除出channel。
3.策略(Policies)
策略决定了谁可以做什么,是一个规则的集合,比如保险公司的保险策略定义了条件、限制等,这些都是被策略制定者和保险公司一起同意的,说明了各方的权利和义务。
在fabric中,策略是一种作为基础设施的机制。描述了fabric网络中成员如何对某一个智能合约、通道等的改变的同意或者拒绝达成共识。策略是在通道刚刚创建配置的时候就被通道中各成员同意的,但是也可以在通道随后的演化中进行修改。
策略也是让Fabric区别于以太坊比特币等的特征之一,它让对交易的验证者是可变的,而不是写死的内容,比如策略可以评估目前是否收集到了足够多的签名来确认某个交易已经达成了共识。
策略的应用:
-
访问控制列表:用于限制哪些人可以访问哪些资源。
-
智能合约背书策略:指定需要多少个peer进行了验证和执行才能让一个交易被认定为是有效的。
-
修改策略:定义了如何对配置进行修改的策略。
fabric中策略的写法:
- 签名语法:
AND
,OR
和NOutOf
如AND('Org1.member', 'Org2.member')
- 隐式元语法:仅在通道配置的上下文下有效,基于分层层次结构,会将最终用签名语法策略定义的策略聚合起来,因此其叶子节点为签名语法的策略。
图中Type3用的就是和签名语法完全不一样的隐式元语法 "<ANY|ALL|MAJORITY> <SubPolicyName>"
如:MAJORITY sub policy: Admins
会去匹配以下全部带有Admins的子域,好处在于,当添加一个新的Admin组织到通道中时,不需要更新通道策略,因此具有很大灵活性。
以下配置来源于test-network下的configtx.yaml
- &Org1
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: Org1MSP
# ID to load the MSP definition as
ID: Org1MSP
MSPDir: ../organizations/peerOrganizations/org1.example.com/msp
# Policies defines the set of policies at this level of the config tree
# For organization policies, their canonical path is usually
# /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
Policies:
Readers:
Type: Signature
Rule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')"
Writers:
Type: Signature
Rule: "OR('Org1MSP.admin', 'Org1MSP.client')"
Admins:
Type: Signature
Rule: "OR('Org1MSP.admin')"
Endorsement:
Type: Signature
Rule: "OR('Org1MSP.peer')"
以上文件定义了通道中的成员角色,每个项目都包含两项,type表示策略类型,rule表示策略的具体内容。
################################################################################
#
# SECTION: Application
#
# - This section defines the values to encode into a config transaction or
# genesis block for application related parameters
#
################################################################################
Application: &ApplicationDefaults
# Organizations is the list of orgs which are defined as participants on
# the application side of the network
Organizations:
# Policies defines the set of policies at this level of the config tree
# For Application policies, their canonical path is
# /Channel/Application/<PolicyName>
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
LifecycleEndorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"
Endorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"
以上文件定义应用通道中很多行为的执行者,这些策略会指向每个组织的具体子策略,也就是上一个配置文件中的定义,由他们去具体解析,由此达到了隐式元语法树状结构的效果。
其中LifecycleEndorsement为Fabric新加入的特性,可以让各个组织投票来决定如何让链码部署到通道上,谁需要对链码的定义进行批准。
Endorsement则定义了链码的背书策略,谁需要对交易进行验证和执行,背书策略的默认值为"MAJORITY Endorsement",即需要大多数人进行,如果需要指定具体的哪些组织可以使用签名语法来对策略进行定义。