Hyperledger Fabric MSP
MSP
Membership Service Providerの略
TL;DR
ネットワーク内で証明書の発行や検証、ユーザ認証を行うコンポーネント
組織の作成、追加時にはgenesis blockに書き込み、チャネルの作成時にはchannelのgenesis blockに追加する
ネットワークに参加する Peer、Orderer は 必ずMSP を所持している必要があり、Peer、Orderer はMSP によってクライアントの検証やそれぞれの署名 (Endorsing Peer の署名や Orderer の署名) の検証を行う。
MSP 概要
MSP ID
MSP のインスタンスは一意な MSPID と紐付けられ る。MSP IDは必ずユニークでなければならない。これは最終的に組織の区別はgenesis blockに記されたMSM IDで行われるため。
MSP の設定方法(2つ)
1. Cryptogenツールを使う
2. openssl を使う
→いずれもMSP を構成するのに必要な各組織のルート証明書等を作成
MSP構成(9要素)
Root CAs
MSP の要素の中で一番重要な要素です。この MSP を定義する組織のルート証明書が格納されています。
MSP を構成するために必ず 1つ以上の CA の証明書が必要です。
Intermediate CAs
中間 CA の証明書が格納されています。
オプションなのでこの要素がなくても MSP は構成されます。
組織単位ではなく、組織の部門ごとに CA を立てる時等に利用されます。
OUs (Organization Units)
この MSP によりネットワークへの参加が許可されている組織のメンバーのリストが定義されています。
この証明書を持つユーザは MSP の構成変更等を行うことができます。
複数組織で 1つのルート証明書や中間証明書を使っている場合に利用するオプション機能です。
Administrator
この MSP の管理者権限を持つ administrator の証明書が格納されています。
通常の MSP の構成では 1 つ以上の administrator の証明書が格納されています。
Revoked Certificates
失効した証明書の情報が格納されています。組織の証明書を管理している CA で証明書を Revoke させると この Revoked Certificates フォルダにデータが移入されます。
こちらもオプション機能で Revoked Certificates がなくても MSP を構成することができます。
Node Identity
Node Identity にはノード自体の証明書が格納されています。Channel MSP には利用されません。
トランザクションの検証の際に Endorsement Policy が充足しているかどうかを検証する時に、 秘密鍵と合わせて、正しい Peer が改ざんなく、トランザクションに署名したことを検証することができます。
keystore
クライアントや Peer、Orderer の各ノードの署名用の秘密鍵が格納されています。
クライアントは作成したトランザクションに署名する際に秘密鍵を利用します。
Orderer や Peer はクライアントから送信されたトランザクションに署名をする際に利用されます。
TLS Root CA
Peer と Orderer 間等の通信で TLS 通信をするための組織の証明書が格納されています。
TLS Intermediate CA
TLS 通信をするための中間組織の証明書が格納されてます。
Intermediate CAs 同様、こちらもオプション機能です。
MSPの役割
作成した MSP のインスタンスは一意な MSPID と紐付けられ、Orderer や Peer の各ノードにこの対応する MSP ID を指定します。 各ノードで持つ MSP を Local MSP と言います。 例えば Org 1 組織の MSP ID を Org1MSP として設定する場合、Org1 で作成する Peer は MSP ID に Org1MSP を指定する必要があります。
Hyperledger Fabric のネットワークを立ち上げる際に作成した MSP の情報がジェネシスブロックに組み込まれます。 MSP ID は必ず一意である必要があり、重複しているとネットワークを起動する際にエラーになります。Hyperledger Fabric のネットワークを構築する時に作成するジェネシスブロックに MSP の情報が組み込まれることで、ブロックチェーンネットワークの参加者の認証を行い、許可制ブロックチェーンネットワークを実現します。
組織の追加
ブロックチェーンネットワークの初回構築後、新しく組織を追加する場合は、その組織用の暗号鍵やルート証明書を Cryptogen ツールや openssl を使って作成し、その組織の Peer に MSP の設定をする必要があります。また新たに参加する組織の情報をジェネシスブロックに追加する必要もあります。
チャネルはそのチャネルに参加する全ての組織の MSP の情報 (Orderer の MSP 含む) を持っています。これを ChannelMSP と言います。 Channel MSP によって各 Peer がチャネルに参加できるかどうかを制御できます。チャネルの MSP の情報はチャネルの構成ファイルを定義する際に設定ファイルに参加する組織の MSP の情報を設定する必要があります。
MSP Configuration
MSP セットアップ (peer & orderer)
administratorは6つのフォルダと1つのファイルを含むフォルダを作る (e.g. $MY_PATH/mspconfig)
admincerts administratorの証明書に対応したPEM ファイルを持つ
cacerts root CAの証明書に対応したPEM ファイルを持つ
(optional) intermediatecerts 中間CAの証明書に対応したPEM ファイルを持つ
(optional) config.yaml to configure the supported Organizational Units and identity classifications (see respective sections below).
(optional) crls CRLを持つ
keystore ノードの署名鍵の入ったPEM ファイルを持つ (RSAは非対応)
signcertsノードのX.509証明書の入ったPEM ファイルを持つ
(optional) tlscacerts TLS root CAの証明書に対応したPEM ファイルを持つ
(optional) tlsintermediatecerts TLS中間CAの証明書に対応したPEM ファイルを持つ
ノードのconfigurationファイル(peer: core.yaml、orderer: orderer.yaml )でmspconfigフォルダとへのPATHとノードのMSP IDを指定する必要がある。
Organization設定
config.yamlでOrganizationの設定を行う。
OrganizationalUnitIdentifiers:
- Certificate: "cacerts/cacert1.pem"
OrganizationalUnitIdentifier: "commercial"
- Certificate: "cacerts/cacert2.pem"
OrganizationalUnitIdentifier: "administrators"
Identity 分類
デフォルトのMSPだとorganizationをさらにidentitieをclient、admin、peer、ordererに分類することが可能。config.yamlで設定を行う。
Identityの分類を行うためにはNodeOUs.Enableをtrueに設定して置く必要がある。trueにした上でNodeOUs.ClientOUIdentifier, NodeOUs.AdminOUIdentifier, NodeOUs.PeerOUIdentifier, NodeOUs.OrdererOUIdentifierを設定することで分類が可能になる。
NodeOUs:
Enable: true
ClientOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "client"
AdminOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "admin"
PeerOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "peer"
OrdererOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "orderer"
Certificate
検証されるCAあるいは中間CAへのPATH。
OrganizationalUnitIdentifier
x509証明書が必要とする OU 値
Best Practices
参考
そぼぎ
endorsment peer は何を検証しているのか
1. クライアントがTxを発行して自身のPeerに送る
2. Endorsement Policyを満たすだけの署名を集めるため、Endorsement PeerにTxを送る
3. 十分な署名が集まったらOrdererへ送信
ordererは組織ごとに持つのか?複数ある場合のコンセンサスは?
#WIPHyperledger_Fabricのコンセンサスアルゴリズム