Hyperledger Indy / Aries / Ursaについてまとめた

この記事の内容

デジタルアイデンティティ特化のブロックチェーン基盤であるHyperledger Indyと、関連するライブラリのHyperledger Aries/Ursaについてお勉強した内容を整理していきます。

目次

1. はじめに
2. Hyperledger各プロジェクト概要
3. Blockchainレイヤー（Indy）
4. Agentレイヤー（Aries）
5. 暗号化関連（Ursa）
6. まとめ

はじめに

前回の記事で自己主権型アイデンティティの概念・アーキテクチャ的なところについてまとめたので、今回は具体的な実装プラットフォームについて整理していきます。まずは現在勉強中＆業務でも開発検証をやっているHyperledger Indy/Aries/Ursaについてまとめました。MicrosoftのIONやEthereum系など、他のプラットフォームもありますがそれは今後勉強していこうと思います。

Hyperledger各プロジェクトの概要

出所：Hyperledger

始めに、各プロジェクトの位置づけについて整理します。
Hyperledger Indyは分散型アイデンティティ実装のためのブロックチェーン基盤で、汎用型のFabricなどとは異なり目的特化型の基盤という位置づけになります。Hyperledger Aries、Hyperledger Ursaはライブラリに属します。
Hyperledgerプロジェクトは開発段階をステータスで表現しており、Proposal⇒Incubation⇒Activeと変化しますが、Hyperledger IndyはActive、Hyperledger Aries/UrsaはまだIncubationという状態です。

Hyperledger Indy

・2017年にローンチ
・アイデンティティに特化したフレームワーク
・もともとEvernym社が開発していたものがSovrin Foundationを経てHyperledgerプロジェクトになった
・主要コンポーネントはVerifiable Credentials、DID、エージェント開発用のSDK、分散台帳実装用のSDKなど
・分散台帳レイヤー以外のコンポーネントについてはAres,Ursaへ移行を進めている

Hyperledger Aries

・2018年にローンチ
・Hyperledger Indyの中からエージェント（クライアント）機能に関する部分を切り出したライブラリ
・Verifiable Credentials・DIDの操作や、エージェント間のメッセージングの機能
・Indyとのインターフェースを持つが、Indy以外の分散台帳との連携も視野に入れている（Fabric・Ethereum等）
・Hyperledger Ursaのライブラリに対応している

Hyperledger Ursa

・2019年にローンチ
・Hyperledger Indyの中から暗号化技術に関する部分を切り出した共通ライブラリ
・暗号化技術に詳しくない一般のエンジニアでも利用できるように改良されている
・デジタル署名、鍵交換、ゼロ知識証明（SNARKs）などの機能を提供
・未だIndyから移行されていない部分もあり進行中

各プロジェクト誕生の経緯としては、元々分散型アイデンティティ基盤を開発していたEvernym社が、Sovrin Networkを立ち上げると同時にソースコードをHyperledgerに提供したものがHyperledger Indyということになります。Sovrin Networkというのは現在Indyのノードが稼働している商用ネットワークす。その後、Indyからスピンアウトした形でAriesとUrsaが誕生しました。

前回の記事で最後に紹介したTrust Over IPスタックに各プロジェクトのカバー範囲を当てはめたものが下の図です。

出所：Evernym

IndyがBlockchainレイヤー（DIDの管理など）、Ariesはその上のAgentレイヤー（peer間通信やクレデンシャル交換）をカバーします。
もう少し細かい技術スタックが下図です。Ursaは各コンポーネントから共通で呼ばれる暗号化ライブラリとして位置づけされており、おそらくIndy/Ariesだけでなく、他のHyperledgerプロジェクトでも利用される想定なのだと思います。

出所：hyperledger.org

次にBlockchain、Agent、暗号化の各領域別に詳細を整理していきます。

Blockchainレイヤー（Indy）

特徴

よくあるBlockchain分類の4象限におけるHyperledger Indyの位置づけは、「Public-Permissoned」になります。台帳のデータは一般公開されていますが、ノードの運営はSovrin Networkへ参加を許可された複数の企業により運営されています。

出所：decentralized-id.com

ブロックチェーン上の情報は公開されていますので、当然プライベートな情報は一切記録されていません。Indy ScanなどのWebサイトで覗いてみても対象を特的できない形のDIDやトランザクションの種類など、一般的な公開情報しかわかりません。スマートコントラクトや価値交換の機能などは基本非搭載です。（運営用途で、書き込み費用など管理のためのトークン機能はあるようです）。コンセンサスはPlenumというEvernym社が開発したBFTアルゴリズムを用いています。対障害性があり他のBFTよりも障害時の性能劣化が少なく、性能は100TPS程度のようです。FabricやCordaなど他の汎用基盤と比べるとずいぶん低いように感じますが、アイデンティティ管理用途であればこのぐらいで大丈夫という事なのかもしれません。

ノード構成

IndyのノードはSovrin Foundationの運営するSovrin Network上で稼働しており、ValidatorノードとOvserverノードで構成されています。

出所：sovrin.org

・Validatorノード
トランザクションの参照・検証・書き込みを実施します。
通常は25台構成のようです。先に述べたPlenumのコンセンサスプロトコルによれば、N=3F+1（Nが台数、FがNGノード）となっており、障害ノードや悪意あるノードが8台までであればコンセンサスが取れ機能することになります。

・Observerノード
参照専用のノードで通常はNWを監視しています。Validatorノードとレプリケーションしており、いざというときはValidatorノードに昇格させて使うことも想定されています。

ガバナンスなど

これらのノードを運用している企業はStewardsと呼ばれており、金融機関・大学・法律事務所・テック企業など約70社が参加しているそうです。少し前のニュースで、Cordaを提供しているR3社もStewardsに参加したという話がありました。StewrardsはSovrin Foundationの定めるガバナンスフレームワークに則りノードを運用しています。
ガバナンスフレームワークと言えば、前回記事の最後に紹介したTrust Over IPスタックではガバナンススタックということで表現されていました。SovrinにおいてもこのToIPモデルに則る形で運用におけるガバナンスが規定されていて、要するにステークホルダー間でアイデンティティ情報の取り扱い、認証、認可等をどういうルールでやっていくかを決めているという事だと思います。ガバナンスを担保する方策の１つとして、トランザクション発行者向けの使用許諾契約みたいな情報がトランザクションの中に埋め込まれています。またネットワークの濫用やDoSを防止する目的で、トランザクション書き込みやクレデンシャル発行に対する課金が予定されています。

Blockchain上に記録する情報

IndyのBlockchainノードには次のような公開情報が記録されます。

1. Public DID
   　- Credentialを発行するIssuerのDID
   　- 誰が発行したCredentialなのかをVerifierが検証する為に必要
   　
2. Schemas
   　- Credentialを構成する属性名のリスト
   　- Issuerが作成してもよいし、既存のものを利用する事も出来る
   　
3. Credential Definitions
   　- Credentialの定義
   　- IssuerのDID、利用するSchema、署名に使う公開鍵のセットなどの情報
   　
4. Revocation Registries（オプション）
   　- Credentialを無効化する際にIssuerが書き込む情報（パラメータ）
   　- 無効化されるとそれがHolderのProofに反映され、Verifierが検証した際にNGとなる

4.のRevocation Registriesは利用必須ではないですが、本人証明などの用途での実運用を想定すると必要になると思います。例えばブラックジャックみたいな医者が失効した医師免許で闇営業をする、みたいな事が防止できる世界の実現に役立ちます。

主要コンポーネント

最後に、Indyには大きく分けてindy-nodeとindy-sdkという２つのコンポーネントがあり、ざっくり以下のような事をしています。

indy-node

・ノードにPythonで実装されているブロックチェーンコンポーネント
・ノードはValidator/Observerとしての機能を持ち、台帳へデータを書き込む

indy-sdk

1. 台帳クライアント機能
   　- トランザクションの読み書き操作
   　- ノード管理系操作（ノード追加・削除、アクセス権管理など）
   　- クエリ系機能は弱く、検索性を高めるにはRDBへのコピーなどで対処が必要
   　- 言語はPython, Java, C#, Node.jsに対応

2. ストレージ機能
   　- DID、Verifiable Credentials、秘密鍵等をセキュアなKMS(key management service)に格納
   　- DBはSQLite（Default）、PostgreSQL（Enterprise向け）に対応し、Key/Value型
   　- データは全て暗号化され、Verifiable Credentialsは他のアプリデータと分けて別領域で管理される

3. Verifiable Credentialsコントロール機能
   　- Issuer向け機能：　Verifiable Credentialsの作成
   　- Holder向け機能：　Verifiable Presentation作成（Credentialを組み合わせ、Proofを付加したもの）
   　- Verifier向け機能：　受領したPresentationの検証など

2と3はAriesへの移行対象になっています。移行後にIndyから削除されるのかどうかはわかっていません。

Blockchainノードにの仕組みについて詳しく知りたい方は、このへんの資料が参考になりそうです。
wiki.hyperledger.org：Hyperledger Indy Public Blockchain(pdf資料)

Agentレイヤー（Aries）

Hyperledger Ariesは主にエージェント間通信レイヤの機能を提供するライブラリとして、元々indyで持っていたindy-sdkのコンポーネントを内包する形で提供されています。

Agentの分類

最初にAriesを適用できるAgentの種類ですが、Agentはそもそもコンシューマが使うデジタルウォレットアプリだけを指すのではなく、Issuer/Holder/Verifierになり得る主体間でPrivate DIDを用いた暗号化通信をするためのソフトウェアという位置づけです。
以下のような分類がされています。
・Personal Agent
　　個人が利用する。モバイルアプリやデスクトップアプリ、ブラウザを介したクラウドアプリなどの形態。
・Enterprise Agent
　　企業などの組織が主にIssuer/Verifierの役割としてサーバーアプリケーションとして実装するなど。
・Device Agent
　　IoTデバイスに組み込み、センサーのデータに基づきCredentialを発行するなど。
・Cloud Agent（Routing Agent）
　　異なるタイプのAgent間を仲介するエージェント。相手Agentがオフラインの場合にメッセージをプールしておいたりできる。

Blockchainのノード構成のところで触れた図を再掲します。Personal AgentやEnterprise Agent、Device Agentなどの間の通信をCloud Agentが仲介しているイメージです。

出所：sovrin.org

主要コンポーネント

Ariesのコンポーネントは大きく４つに分類されます。

Key Management Service(KMS)

KMSはエージェントのデータ格納用DBです。DID、鍵、CredentialなどAgentが扱うデータを保管します。当然高いセキュリティが要求される為、データの暗号化／復号化キーは生体認証＋HSMなどで管理されます。
Personal Agent向けだとSQLite、Enterprise Agentなどサーバで稼働するAgentにはPostgreSQLが使われます。

Agent Messaging Interface

DID Commという暗号化通信プロトコルを使いAgent間の通信の処理をするコンポーネントです。通信はHTTP/HTTPsがベースですが、Web Socket、SMTP、XMPPなど広く対応しているようです。

Ledger Interface

台帳にアクセスインターフェース部分です。従来のIndyのLedger InterfaceはIndy基盤にしか対応しませんでしたが、AriesはBlockchain-Agnosticがコンセプトであり、Indy以外の台帳基盤とも互換性があります。機能としてはAriesの秘密鍵を使った台帳への書き込み、Verifiable Credentialsの発行やProofの提示などを行います。また、DIDに対応するDID Documentを返すためのDID Resolverの機能があります。このDID ResolverはSovrin Network上のDIDにしか対応していませんが、今後外部のUniversal DID Resolverと連携する予定となっています。

ちなみにUniversal DID ResolverはDecentralized Identity Foundation(DIF)というSSIの標準化を推進する団体が開発を進めており、AWSとIBM Cloud上でインスタンスが稼働している（実験段階）というブログ記事を7月頃に見かけました。複数のDIDプロトコル間のインターオペラビリティを実現する重要な仕組みであり、商用でのローンチを期待したいところです。

Controller

Controllerはメッセージング処理のビジネスロジックを定義する部分です。Ariesのアプリケーション開発において開発者がコーディングする要素は基本的にこの部分だけになります。

メッセージングプロトコル

最後にメッセージングプロトコルについて触れます。Ariesのメッセージングプロトコルは総称してDID Commと呼ばれ、Envelope Protocolと呼ばれるメッセージの送受信方法自体を定義するプロトコル（対象のメッセージを選び、パッケージングして送信する）と、その他のプロトコル（メッセージ送受信と同時に何らかのアクションを実行するもの）があります。
この「その他のプロトコル」というのには多くの種類があり現在も開発が続いているのですが、一番多く使うであろうものは以下３つかと思います。

DID Exchange Protocol
Agent間で最初に通信を確立するためのプロトコルで、Invitation, Connection request、Connection responseなどの処理を通してお互いのDIDや公開鍵の受け渡しを行います。

Issue credential protocol
IssuerとなるAgentがVerifiable Credentialsを他のAgentに発行する為のプロトコルです。

Present proof protocol
VerifierとなるAgentと相手Agentの間でProofの要求やそれに対する提示を行うためのプロトコルです。

その他のプロトコル含め、Githubで詳細情報が確認できます。
https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0003-protocols/README.md

暗号化関連（Ursa）

Hyperledger Ursaは暗号化に関する機能をひとまとめにして、開発者が容易にアプリケーションから呼び出して利用できるようにしたライブラリです。ここはまだあまり深く勉強できていないのですが、主として以下のような機能があります。

・秘密鍵／公開鍵ペアの生成
・データ暗号化／復号化処理
・データの署名、検証
・ハッシュの生成、検証
・ゼロ知識証明（ZKP）技術全般（発行、生成、検証）

**ゼロ知識証明（ZKP）**についてはここで詳しい説明をすることは避けたいと思いますが、一言で言うなら「情報が真実であるということ以外の情報を相手に与えずに、その情報が実際に真実であることを証明する」でしょうか。
使いどころとしては、HolderがVerifierにProofを提示する際、発行者であるIssuerのDIDだけ公開し自分のDIDは秘匿するという部分で使われています。もし自分のユニークな識別子であるPublic DIDを毎回Verifierに晒していたら、Verifier側で本人を推測出来てしまう可能性があり、プライバシーの面で問題があります。
他にもUrsaでは以下のようなZKPをサポートしていますが、あまり詳しく内容を理解できていません。詳しい方がいらっしゃいましたらぜひ教えてください。

・Signature Proofs of Knowledge（電子署名の秘匿化？）
・Bulletproofs（データ量が小さく高速に処理できるZKPプロトコルの1類型？）
・Range proofs（範囲証明。生年月日を明かさずに年齢が30代である事を証明するなど。）
・Set Membership（グループに属する事の証明。パスポートを見せずにある国の国民であると証明するなど。）

少し話は逸れますが、Verifiable Credentialsの特性である選択的な情報開示（Credential丸ごとではなく必要なClaimだけでProofを構成できる）とこのZKPを組み合わせれば、非常にプライバシー性の高い認証が出来るようになります。個人的にはSSI技術の一番素晴らしい点はこのプライバシーByデザインな部分ではないかと思っています。現時点でZKPを組み込んでいる主要なSSIプラットフォームとしては私の知る範囲ではIndy/Aries/Ursaしか無い為、それを理由にIndy/Aries/Ursaで何かサービスを作ってみたいと思うようになりました。（実際に業務でIndy/Aries/Ursaを使ったサービスを企画検討中です）

まとめ

Hyperledger Indy/Aries/Ursaのプロジェクト概要、各フレームワークの特徴や主要コンポーネントについて整理してきました。まだ概要しか勉強出来ていませんが、特にAriesとUrsaについてはまだ登場したばかりで事例やサンプルの情報も少なく、開発の難易度は高そうだという印象を持ちました。しかし海外ではこれらの技術を使った商用プロダクトやPoC事例が実際に複数登場しており、国内でも富士通さんの基盤に採用されたりしていますので、引き続き勉強しつつSSIを使ったユースケースやサービスを考えていきたいと思います。

[参考]
この記事を作成するにあたっては、以下を参考にしました。
・GithubのIndy/Aries/Ursaの各repo
・Evernym社のブログ記事
・Linux FoundationのEラーニング（Introduction to Hyperledger Sovereign Identity Blockchain Solutions: Indy, Aries & Ursa）
など


[過去の記事]
自己主権型アイデンティティ（Self-Sovereign Identity）の概要