はじめに
3回にわたり、Hyperledger Fabric v0.6とv1.0の違いを技術的に解説しています。
v1.0ではv0.6がもつスケーラビリティとプライバシーにかかわる課題解決のため以下変更が実施されました。
- 第1回: スケーラビリティ
- v0.6では全ノードが合意形成とChaincode実行を実施
- v1.0ではChaincodeの実行管理をする「Peer」と、トランザクションの順序整列をする「Orderer」に分類、トランザクションの並列/分散処理を実現
- 第2回: プライバシー
- v0.6では全ノードが全Chaincodeを閲覧可能
- v1.0ではどのノードでどのChaincode実行に関与するかを制御可能
- 第3回:認証(authentication)・権限認可(authorization)
- 上記実現のため、認証・権限認可およびID管理が変更
第3回は上記認証(authentication)・権限認可(authorization)について解説します。本記事は、過去にコンセンサス・ベイスが主宰していたオンラインサロンの記事です。記事は2017年~2018年にかけて執筆されたため、一部は、既に古くなっている可能性があります。あらかじめご了承ください。
MSPとFabric-ca
v1.0では、スケーラビリティとプライバシーの変更を実現するため、Identity管理について以下の機能を追加しました。
- パーミッションド・ブロックチェーンの前提となるユーザーIDの管理とネットワーク参加者の会員認証
- アクセス・コントロール・リストによる特定のネットワーク操作に対する権限認可
- メンバーはお互いが会員であることは知っているが(identity)、お互いが何をしているかはわからない(privacy and confidentiality、匿名性)
これらの機能はMSPとFabric-caにより実装されます。
Membership Service Provider (MSP)
MSPはクライアントとpeerがFabircネットワークに参加するための証明を与える論理的コンポーネントです。クライアントはこの証明によりトランザクションの認証を得ることができ、Peerはこの証明によりトランザクション実行結果の認証(endorsement)をすることができます。トランザクション処理と密に結びついていますが、会員管理サービスの追加実装はトランザクション処理のコア部分を変更することなく実施できるよう設計されています。
具体的には、PKIベースでMSPを実装したものがMembership Serviceで、パーミッションド・ブロックチェーンにおいて認証、権限認可、ID管理を行います。PeerとOrdererで動作するプログラムによりブロックチェーン操作の認証・権限認可を実施します。
Fabric-ca
Fabric-caはデフォルトCAコンポーネントであり会員管理を実装したもので、PKIベースの入会証明書(eCert)とトランザクション証明書(tCert)の発行と取り消しを行います。入会証明書は長期の証明であり、トランザクション証明書は匿名かつリンク不能な短期の証明です。特定の属性をトランザクション証明書(tCert)に含めアクセス・コントロールに利用することも可能です。
また、v1.0ではFabric-caを複数設置できるようにしました。これにより単一障害点の問題は回避できましたが、単一信頼点の問題(検証したい証明書から信頼関係を順にたどり、信頼している認証局(検証者)まで結んだ認証パス上で、信頼点(認証者)が二重化されていないこと)については検討する必要があります。またv1.0では、ネットワーク全体の操作性を損ねることなく会員・Peer・Ordererの追加/削除が可能となりました。
上記のMSPとFabric-caが連携することで以下のような仕組みでIdentity管理を実現する。
- Member(企業、組織など)に所属する指定されたユーザーにたいして入会証明書(eCert)を発行
- ユーザーは入会証明書(eCert)を利用してクライアントにログイン
- クライアントは必要に応じて発行されるトランザクション証明書(tCert)を利用してトランザクション処理をPeerに申請(propose)
- Peerはトランザクション証明書(tCert)を利用してトランザクションを署名(endorsement)
参考として、
図1にFabric-caから発行される2種類の証明書の利用モデル
図2に証明書を利用したトランザクション・フロー
を以下に紹介します。
図1:Hyperledger Fabricでの証明書利用のモデル
(エンタープライズ・ブロックチェーンに求められるセキュリティ要件とIBMの取組みより抜粋)
図2:Hyperledger Fabricのセキュリティを考慮したトランザクション・フロー
(エンタープライズ・ブロックチェーンに求められるセキュリティ要件とIBMの取組みより抜粋)
参考資料:
・Docs » Welcome to Fabrichttp://hyperledger-fabric.readthedocs.io/en/latest/index.html
・Hyperledger Fabric V1 – Meetup
http://files.meetup.com/19726545/HyperledgerMeetupDec6.2016.pdf
・Hyperledger Fabric 1.0 概要、第1回Hyperledger Tokyo Meetup 2017年3月16日講演
株式会社日立製作所 山田仁志夫、Hitachi America 大島訓
・エンタープライズ・ブロックチェーンに求められるセキュリティ要件とIBMの取組み
2017年6月27日講演 日本IBM株式会社 野村幸平
免責事項
本記事に掲載されている記事の内容につきましては、正しい情報を提供することに務めてはおりますが、提供している記事の内容及び参考資料からいかなる損失や損害などの被害が発生したとしても、弊社では責任を負いかねます。実施される際には、法律事務所にご相談ください。
技術・サービス・実装方法等のレビュー、その他解説・分析・意見につきましてはblock-chani.jp運営者の個人的見解です。正確性・正当性を保証するものではありません。本記事掲載の記事内容のご利用は読者様個人の判断により自己責任でお願いいたします。
会社紹介
弊社(コンセンサス・ベイス株式会社)は、2015年設立の国内で最も古いブロックチェーン専門企業です。これまでに、大手企業の顧客を中心に、日本トップクラスのブロックチェーンの開発・コンサルティング実績があります。ブロックチェーンに関わるビジネスコンサル・システム開発・教育・講演などご希望でしたら、お気軽にお問い合わせください。
会社ホームページ
https://www.consensus-base.com/