Membership Service Providers (MSP)

本文将介绍有关MSPs的设置和最佳实践的详细方案。

Membership Service Providers (MSP)是一个旨在提供成员操作体系结构抽象的组件。

尤其是MSP抽象出发布和验证证书的所有加密机制、协议以及用户身份验证。MSP可以自定义身份概念,以及这些身份被管理的规则(身份验证)和认证加密(签名生成和验证)。

一个Hyperledger Fabric区块链网络可以由一个或多个MSPs管理。这提供了成员操作的模块化,以及跨不同成员标准和体系结构的相互操作性。

在本文的其余部分中,将会详细介绍由Hyperledger Fabric支持的MSP实现的设置,并讨论了有关其使用的最佳实践。

MSP配置

要设置MSP的一个实例,在所有的peer和orderer(启用peer和orderer签名)的本地需指定它的配置,并在channel上启用peer、orderer和客户端的身份验证,并为通过和channel中所有成员分别签名验证(鉴定)。

首先,为了在网络中引用MSP(例如msp1、org2和org3.divA),每个MSP都需要指定一个名称。这个名称是被一个channel所使用的属于MSP的成员规则(配置)可能是一个集团、机构或是机构部门采用的名称。这也被称为MSP标识符或MSP ID。MSP标识符必须是唯一的每个MSP实例。例如,如果在系统channel检测时发现到两个MSP实例,那么orderer的设置将会失败。

在MSP的缺省实现中,需要指定一组参数来允许身份(证书)验证和签名验证。这些参数由RFC5280推导出来,包括如下:

  • 一个自签署的(X.509)证书列表来构成信任的根
  • 把一个表示为中间CAs的X.509证书列表作为提供者的证书验证;这些证书应当由信任的根证书中的一个证书进行认证;中间CAs是可选参数
  • 一个(X.509)证书的列表和授信的根证书集的证书路径作为MPS的管理员,这些证书的所有者被授权请求对MSP配置进行更改(例如,根ca,中间CAs)
  • 这个MSP的有效成员应该包含在他们的X.509证书中,这是一个可选的配置参数,例如用在多个组织使用相同的信任根和中间CAs,并为其成员预留了一个OU( Organizational Units/组织单元)字段。.
  • 证书撤销列表集(CRLs——certificate revocation lists)中的每一个列表都对应一个列出的(中间或者根)MSP证书颁发机构;这是一个可选参数
  • 一个自签署的(X.509)证书列表构成了授信TLS证书的TLS根
  • 提供者考虑一个表示为中间TLS  CAs的X.509证书列表,这些证书应该由授信的TLS根证书中的一个证书进行认证,中间CAs是可选参数

为了满足以下条件,需要使用这个MSP实例的有效身份:

  • 它们以证书的形式存在,并具有可验证的证书路径,以完全信任证书的根
  • 不包括在任何证书撤销列表(CRLs——certificate revocation lists)中
  • 在证书结构的OU( Organizational Units/组织单元)字段中列出了MSP配置的一个或多个组织单元

除了验证相关的参数之外,为了使MSP能够在实例化的节点上进行签名或验证,还需要做出如下指定:

  • 用于在节点上签署的签名键(目前仅支持ECDSA键)
  • 节点的X.509证书,在MSP的验证参数下是一个有效的身份

重要的是要注意到MSP的身份永远不会过期;只有将它们添加到相应的证书撤销列表(CRLs——certificate revocation lists)中才能撤销它们。此外,目前还没有对强制撤销TLS证书的支持

如何生成MSP证书及其签名密钥?

为了生成用于提供其MSP配置的X.509证书,应用程序可以使用Openssl。在Hyperledger Fabric中没有包括对RSA密钥在内的证书的支持。

另一种方法是使用密码工具(cryptogen tool),在Hyperledger Fabric 1.0 从零开始(八)——Fabric多节点集群生产部署详细介绍了如何使用该工具生成证书配置文件

还可以使用Hyperledger Fabric CA来生成配置MSP所需的密钥和证书

MSP设置peer和orderer

若想要设置一个本地MSP(peer或是排序节点),管理员应该创建一个文件夹(例如$mypath/mspconfig),它包含六个子文件夹和一个文件:

  1. 一个admincerts文件夹,其中包含每个对应于管理员证书的PEM文件
  2. 一个cacerts文件夹,其中包含了每个对应于根CA证书的PEM文件
  3. 一个intermediatecerts文件夹(可选),其中包含对应每个中间CA的证书的PEM文件
  4. 一个config.yaml文件(可选),其中配置了所有的OUs(组织单元)信息,OUs也就是yaml文件中定义的OrganizationalUnitIdentifier(组织单元ID)数组的集合,即OrganizationalUnitIdentifiers。其中需要考虑到如何证实成员们属于组织成员,证书授权配置了的证书的相对路径(例如,/cacerts/cacert.pem),并且在X.509证书的OU( Organizational Units/组织单元)字段中将出现OrganizationalUnitIdentifier代表的实际的字符串(例如“COP”)。
  5. 一个crls文件夹(可选),其中包含了被考虑的CRLs
  6. 一个keystore文件夹,其中包含了一个带有节点签名密钥的PEM文件;官方强调当前的RSA密钥不受支持
  7. 一个signcerts文件夹,其中包含了一个带有节点的X.509证书的PEM文件
  8. 一个tlscacerts文件夹(可选),其中包含了对应于每个TLS根CA证书的PEM文件
  9. 一个tlsintermediatecerts文件夹(可选),其中包含了对应于每个TLS中间CA证书的PEM文件

在节点的配置文件中(用于peer的core.yaml文件和orderer的orderer.yaml文件),需要指定mspconfig文件夹的路径,以及节点MSP的MSP标识符。mspconfig文件夹的路径将与 FABRIC_CFG_PATH相关联,并提供给peer中mspConfigPath参数以及orderer中LocalMSPDir参数的值。节点的MSP的标识符作为参数的值提供给peer的localMspId和orderer的LocalMSPID。这些变量可以通过当前环境使用CORE前缀赋给peer(例如:CORE_PEER_LOCALMSPID)以及使用ORDERER前缀赋给orderer(例如:ORDERER_GENERAL_LOCALMSPID)来重写。注意,对于orderer设置,需要生成,并向orderer提供系统channel的创世区块。

下面将详细介绍创世区块的MSP配置需求。

目前对于“local”MSP的重新配置只能手动进行,并且需要重新启动peer或orderer的进程。在随后的版本中,官方的目标是提供在线/动态重新配置(例如,不需要使用节点管理的系统链代码来停止节点)。

补充一点,当我们使用Hyperledger Fabric 1.0 从零开始(八)——Fabric多节点集群生产部署中的方案,即生成msp中述说的第二种方案生成对应证书后,在peerOrganizations\xxx.xxx.com\peers\peer0.xxx.xxx.com\msp的目录中可以发现上述所介绍的相关目录,以此可以进一步加深本步的了解。

MSP Channel设置

在系统的生成过程中,需要指定网络中出现的所有MSPs的验证参数,并包含在系统通道的创世区块中。回看一下前文中提到MSP的验证参数包括MSP标识符、信任证书的根、中间CA和管理证书,以及OU规范和CRLs。系统创世区块在设置阶段提供给orderers,并允许他们对channel创建请求进行身份验证,如果后者包含两个带有相同标识的MSPs,那么Orderers将会拒绝系统创世区块,并因此导致网络引导失败。

对于应用程序channels,只有管理channel的MSPs的验证组件需要驻留在channel的创世区块中。官方强调,应用程序的责任是确保正确的MSP配置信息包含在一个channel的创世区块(或最近的配置块)中,在一个或多个peer加入channel之前。

当使用configtxgen工具来引导创建一个channel时,可以通过在mspconfig文件夹中包含MSP的验证参数来配置channel的MSPs,并在configtx.yaml中的相关部分设置该路径。

在channel上重新配置MSP,包括与MSP的CAs相关联的证书撤销列表的声明,这是通过MSP的一个管理员证书的所有者通过创建一个config_update对象来实现的。由admin管理的客户端应用程序将向存在此MSP的channel发布更新。

最佳实践

下文将详细介绍在常见的场景中MSP配置的最佳实践。

1)组织/公司和MSPs之间的映射

官方建议组织(organization)和MSPs之间存在一对一的映射。如果选择了一种不同的映射类型,则需要考虑以下问题:

  • 一个使用各种MSPs的组织。这与一个组织的情况相对应,其中包括由其MSP所代表的各种不同的部门,或者出于管理独立的原因,或者出于隐私方面的原因。在这种情况下,一个peer只能由一个MSP拥有,并且不能识别来自其他MSPs相同组织的其他成员的身份。它的含义是,peers可以通过gossip organization-scoped的数据与一组相同细分的成员共享,而不是由构成实际组织的全部提供者组成。
  • 多个组织使用一个MSP。这与一个由类似的成员架构管理联盟组织的情况相对应。这里需要知道的是,peers可以将组织范围的消息广播给在相同的MSP下具有相同身份的peers,而不管它们是否属于同一个实际的组织。这是MSP定义的粒度限制,使用and/or来配置。

2)一个组织有不同的部门(比如组织下各单位),它想要授予访问不同channel的权限

有两种方案可以实现这个目的:

  • 定义一个MSP给所有组织成员提供成员身份。MSP的配置将包括一个根CAs、中间CAs和管理证书的列表,并且成员身份将包括一个成员所属的组织单位(OU),然后可以定义策略以通知特定OU的成员,这些策略可能构成一个channel的读/写策略或chaincode的背书策略。这种方法的一个局限性是,gossip peers将默认在本地MSP下所属peers的成员身份都作为同一组织成员,并且gossip peers因此也将组织范围内的数据进行散播(例如:它们的状态)。
  • 定义一个MSP来表示每个部门。这将为每个涉及的指定部门设置并提供包含根CAs、中间CAs和管理员证书等一组证书,这样就没有跨MSPs的重叠认证路径,举例来说明其含义,即每个细分部门都有一个不同的中间CA。这个方案的缺点是要管理多个MSPs,而不是一个MSPs,但是这绕过了第一个方案中出现的问题。还可以通过利用MSP配置的OU扩展来为每个部门定义一个MSP。

3)将客户端从相同组织的peers中分离

在许多情况下,身份的“类型”是可以从身份本身中获取的(例如,可能需要拥有peers的派生而不是客户端或者单独的节点orderers来保证背书)。

对这些要求的背书是有限的。

允许这种分离的一种方法是为每个节点类型创建一个单独的中间CA——一个用于客户端,另一个用于peers/orderers,并配置两个不同的MSPs——一个用于客户端,另一个用于peers/orderers。该组织在访问的channel需要同时包含两个MSPs,而背书策略只会影响peers引用的MSP。

Gossip不会受到太大的影响,因为同一组织的所有peers仍然属于一个MSP。peers可以将某些系统chaincode的执行限制在本地MSP的策略中。例如,如果请求是由作为客户端(用户应该发起该请求的最终起点)的本地MSP的管理员签署的,peers才会执行“joinChannel”请求。如果我们认可仅客户端作为peer/orderer MSP的成员,也为该MSP的管理员,那么我们可以绕过这种不一致的地方。

此方法的另一个要点是,peers在本地MSP中基于请求发起者的成员资格授权事件注册请求。显然,由于请求的发起者是一个客户端,请求发起者总是注定要属于一个不同的MSP,而不是请求的peers,而peers会拒绝这个请求。

4)管理员和CA证书

设置MSP管理证书与任意一个被视为该MSP的信任根或中间CAs证书不同是很重要的。这是一种常见的(安全)实践,可以将成员组件的管理职责与新证书的颁发和/或现有证书的验证分离开来。

5)中间CA黑名单

正如前面所提到的,MSP的重新配置是通过重新配置机制实现的(本地MSP实例的手动重新配置,以及通过正确构造一个channel的MSP实例的config_update消息)。有两种方法可以确保在MSP中考虑到的中间CA不再被认为是MSP的身份验证。

  1. 重新配置MSP,考虑到的中间CA证书不再包括在可信的中间CA证书列表中。对于本地配置的MSP意味着该CA证书将从intermediatecerts文件夹中删除。
  2. 重新配置MSP,以包含由信任根产生的CRL,该CRL会对所提到的中间CA证书执行废弃。

在当前的MSP实现中,官方只支持方法(1),因为它更简单,不需要将不再考虑的中间CA列入黑名单。

6)CAs 与 TLS CAs

需要在不同的文件夹中声明MSP标识的根CAs和MSP TLS证书的根CAs(以及相对中间的CAs)。这是为了避免不同级别的证书之间的混淆。在MSP标识和TLS证书中重用相同的CAs是不被禁止的,但是最佳实践建议在生产中避免这种情况。

05-02 18:15