この記事はKyash Advent Calendar 2020の24日目の記事です。
こんにちは。株式会社KyashのCTOの椎野と申します。今年はコロナウィルスの蔓延があったり、そのため東京オリンピックが延期されたりと何かと大変な1年でした。そのような最中、フィンテック業界もいろいろな出来事がありました。外出が規制される中でオンライン決済が伸びることでキャッシュレス決済市場が世界的に伸長しましたが、その反面不正が増え、夏すぎに金融業界を揺るがす銀行-決済事業者の連携部分を狙った不正利用という事象が発生したりしました。利便性と堅牢性を如何に両輪で高めてゆけるかはIT業界全体のミッションでもありますが、お金を扱う私が現在属するフィンテック業界にとって非常に大きな関心事でもあります。
改めて浮き彫りになった課題
今年の夏過ぎに起こった銀行-決済事業者間の連携における不正の詳細や内容に関しては、様々なメディアや有識者が情報を提供しているのでここでは割愛しますが、多段的な認証技術の導入や利用時の**本人確認（Know Your Customer => KYC）**の強化が業界全体として求められています。
上記の対策により高い精度で連携時の不正対策が強化され、より高い堅牢性が実現できます。この堅牢性を実現するための開発や運用するコストは銀行や金融事業者がそれぞれで賄う必要があり、国としてのガイドラインはありつつも、業界内の各企業の自助努力ややり方で担保する形になります。いわば属会社的な形になる部分があり、そこを今後も狙われる可能性を残します。
インターネット上のユーザー認証の課題
日々技術は進化し、様々なことがデジタルに置き換えられ便利になりつつも、利便性が高まる中で仕組みを守るための技術がまだ追いついていないという課題があります。
1. そもそもデジタル認証技術はインターネット技術において昔から存在する困難な課題
現実世界における認証は財布の中の免許証を見せるなど、アナログですが非常にシンプルで不正が起きづらい（100%ということはないですが）のに対して、インターネットの世界では少なくとも同等の認証手段がまだ存在していない課題があります。つまり人間の判断以上の認証手段がまだ存在していないということになります。
2. デジタル認証における標準が存在しない
すでに様々なデジタル認証は存在しますが、インターネット業界全体を通じで統一されたフォーマット・標準がまだ存在していなく、また認証に用いる参照先のデータも統一されていない課題もあります。
3. デジタル署名の確認方法
Public Key Infrastructure(PKI)によるデジタル署名は解決方法の一つですが、手続きが面倒で、運用コストもかかり（証明書を取得するのにコストがかかるなど）、発行するCA（Certificate Authorities）が集中管理するという方法なので、万が一CAがデジタル署名確認を失敗したり、仮に悪意があるCAから発行されている証明書を利用した場合（中間者攻撃）に善意ある暗号化がされているという証明もできず、一気にセキュリティが崩壊する事態を招きます。
課題に対しての解決アプローチの考察
これらサービス運営や認証技術課題を解決するアプローチとしてBlockchainが注目されています。Blockchainを利用した認証を採用した場合のメリットは以下になると考えています。
1. 特定のプロバイダーによる集中管理ではなく、ネットワーク全体を信頼する形の分散管理
Blockchainの分散管理技術とコンセンサスアルゴリズム（ネットワーク全体の同意による認証）を用いることで認証方法の俗人化を排除をすることができるメリットがあります。
2. 俗人要素ベースとした信頼ロジックではなく、数学的アプローチによる信頼ロジック
1のブレークダウンになりますが、以下のBlockchainの特徴が挙げられます。
- それぞれのトランザクションが利用ユーザーのデジタルサインで署名がされている。
- Blockchainに格納されるそれぞれのトランザクションが、その前に作成されたブロックのハッシュ値でブロック化される。
- 検証された全てのトランザクションがコンセンサスアルゴリズムを通じてネットワーク参加している全てのマシンに複製される。
上記のBlockchainの特性を活かすことで情報の改竄耐性をあげることができ、非常に信頼性の高いネットワークの構築を可能としています。
3. 分散Public Key Infrastructure（Decentralized PKI）が構築可能
現状広く普及するCAが中央管理する仕組みがセキュリティ課題を生んでいることに対しての解決方法として、Decentralized PKIがあります。文字通りBlockchainのような分散台帳で分散管理されることで集中管理によるリスクを低減させることが可能です。
Self Sovereign Identity(自己主権型ID)とは
現在のインターネットにおけるこれら認証や証明の課題を解決する方法論の一つに**Self Sovereign Identity(自己主権型ID)**という概念があります。この概念全てを一つ一つ深く理解するには相応の時間が必要ですので、今回は全体感を網羅的に説明できたらと考えています。
Self Sovereign Identity（以後SSI)は特定のソフトウェアやフレームワークではなく、個人のIDやデータを利用する個人が管理するという考え方であり、その普及活動を指す場合もあります。SSIはユーザーの**アイデンディティ（ユーザー自身）**情報を取り扱う上での課題に対してのアプローチとなります。SSIを考察する上で重要なことは以下の２点だと考えています。
##1.マルチソースでのアイデンティティ管理
現在のインターネット上でのアイデンティティ情報は中央集権的に特定のサービスプロバイダからのみ提供されます。現実社会を考えるとこれとは異なり、様々な情報ソースから１ユーザーのアイデンティティは成立しています。（銀行口座情報であれば銀行、医療情報なら病院など。） SSIの世界観においては、以下のようにアイデンティティの所有者（Holder）の証明者（Issuer）がその情報が適切である（Credential）ことをサービス提供者が検証し（Verifier）信頼することで成り立ちます。
##2. 分散されたアイデンティティ管理
SSIにおいて考え方として重要なのは、ユーザー自身がIDを自由に生成・更新・削除が行えることで、特定のサービスプロバイダに依存しないことです。Blockchain技術や思想はこの分散アイデンティティ管理の思想に非常にマッチしていて、自分で作ったIDをBlockchainに書き込むことで自分以外がコントロールできない状態（非改竄性）になり、複数の分散台帳技術において横断的（Interoperability）に取り扱うことができる分散アイデンティティ（Distributed Identifier=DID）が実現します。このDIDはフォーマットが定義されていて、あらゆるBlockchainや他分散台帳技術でも共通で利用することができます。
//DIDのフォーマット
did:example:123456789abcdefghi
SSIの10原則
SSIには以下の10原則があります。
- Existence（存在）：ユーザーは独立した存在でアイデンティティの中心である。
- Control（コントロール）：ユーザー自身がアイデンティティをコントロールできる。
- Access（アクセス）：ユーザーは自身のアイデンティティ情報にアクセスできる。
- Transparency（透明性）：システムとアルゴリズムはオープンであるべきである。
- Persistence（永続性）：ユーザーが望む限りアイデンティティは永続化される。
- Portability（可搬性）：アイデンティティはユーザーが自由に移行可能である。
- Interoperability(相互運用性）：アイデンティティは境界を超えて利用が可能である。
- Consent（同意）：アイデンティティの利用には保有者の同意が必要である。
- Minimalization（最小化）：データの開示は必要最小限に抑えられるべきである。
- Protection（保護）：ユーザーの権利は保護されなければならない。
このような原則が打ち出され、2017年5月にDecentralized Identity Foundation (DIF)が設立され、このSSIを実運用レベルで推進しています。このBlockchainを利用した**分散アイデンティティ（Decentralized Identity）を推進するプロジェクトはいくつかありますが、私はSovrin**というプロジェクトのホワイトペーパーなどを読むことが比較的多いです。
Self Sovereign Identity構成要素の概要
以下の図はSSIを構成する全体図となります。
それぞれの役割と実際にサービスを利用するまでの流れを以下に記載します。
###上記図のユースケース
- HolderがVerifierのサービスにアクセスしてサービス提供を受ける。（例えばSNSなどのWebサービス）
- VerfierがHolderの個人情報を要求する。（例えば生年月日や電話番号など）
登場するアクター
- ユーザー（Hodler）：自分のアイデンティティの管理者→サービス利用ユーザー
- 信頼情報の発行者（Issure）：ユーザー情報の正当性を証明→公的団体、非営利・営利企業など
- サービス提供者など（Verifier）：ユーザーから受け取った証明を検証し何かしら（サービスなど）を提供する
フロー（流れ）
- HolderがDIDとそれに対応する秘密鍵と公開鍵を作成し、秘密鍵をWallet（利用端末などのセキュアなデータストレージ）に保存し、公開鍵をShared Ledger（Public Blockchain）に保存（正確にはDID Documentとして保存）する。
- ログイン時にVerifierがHolderのDIDを使ってShared Ledger（Public Blockchain）に登録されているPublic Keyを利用して認証を行います（Walletの秘密鍵で暗号化されたDIDに対する検証）。
- Verifierのサービスで個人情報の参照が必要で、HolderがDIDを利用して個人情報を管理しているIssuerにVerifiable Credentialの発行依頼をする。
- Issuerが必要な個人情報（生年月日や電話番号など）を含んだVerifiable Credentialを発行する。
- HolderがWalletにVerifiable Credentialを格納する。
- Verifiable CredentialからVerifiable Presentationを作成しVerifierに送信する。
- IssuerがShared Ledgerに登録してあるDIDを利用してVerifierが検証（登録しているPublic Keyで検証）して必要な個人情報を取得する。
このようにVerfierが直接Issuerに情報請求することなくVerfierの持つHolderの個人情報をHolderの認証を経由して受け渡すことができます。
Self Sovereign Identityを実現する上で扱う技術
ここから実際にフィンテックのユースケースを簡単に考えて、具体的に試してみる技術を見てゆこうと思います。おそらく手法は様々あると思いますが、ドキュメントとして非常に理解がしやすかったLinuxファンデーションが運営しているHyperledgerのプロジェクトで進められている技術を取り扱いたいと思います。
[Hyperledgerプロジェクト製品群]
参照:https://www.hyperledger.org/use
多数あるHyperledgerプロジェクト製品群のうち、今回SSIのユースケースで取り上げるのはIndy、Aries、Ursaの3つとなります。
###1. Indy：DIDを取り扱うPublic Blockchain
Public Blockchainは有名なBitcoinやEthereumなどがありますが、SSIに特化した**Hyperledger Indy**を取り上げたいと思います。
参照:hyperledger-archives/education
Hyperledger IndyはBlockchainや他の分散台帳技術でデジタルアイデンティティを提供するためのツール類、ライブラリ、コンポーネント群を提供していて、境界・ドメイン、アプリケーション、その他Blockchainプラットフォームなどを横断的に相互乗り入れ（Interoperability）できる仕組みが実現できます。
###2. Aries: Credentialの発行、通信、管理
Hyperledger AriesはSSIにおけるCredentialの発行、通信、管理をするためのライブラリです。Pubicで扱う際のBlockchainとの通信や、Peer-to-Peerの2者間の通信を行うためのインフラ的な役割を果たします。
###3. Ursa：データの暗号化
**Hyperledger Ursa**はIndyやAriesで利用する暗号化ライブラリです。鍵ペアの生成、データの暗号化・復号化、データの署名・検証、ハッシュの生成・検証、ゼロ知識証明書（ZKP）の取り扱いなどの機能が利用できます。
これらのベースの技術を利用して、次章のユースケースに適用してみます。
ユースケースの考察
SSIに実際に触れてみる上で、金融のユースケースを考えてみたいと思います。Hyperledgerのサイトやgithubで管理されている**Indy**のリポジトリでいくつかユースケースが提示されていますが、冒頭で話をした今年起きたフィンテックシステムの課題でもある本人確認や認証・データ管理周りのユースケースを考えてみて、簡単に実装をトライしてみたいと思います。
###1. 考えてみたユースケース
ここでは決済事業者と他金融機関との間でユーザーの本人情報の正当性の確認とやり取りを考えてみることにします。金融機関では、サービスを利用するために利用者が本当にその人物なのかを検証する本人確認（Know Your Customer => KYC）を事前に実施します。最近ではeKYCという顔写真付き書類とスマホ端末で撮影した顔写真との整合性で認証するようなデジタルソリューションなども普及し始めましたが、従来型としては免許証や保険証などの本人を証明する書類の提出（アップロード含む）などがあります。
ただし、各金融機関ごとにフォーマットがまちまちで、利用金融機関ごとにこのKYCを行う必要があったり、そもそも各金融機関で行っている本人確認情報とその情報の利用者の同一性を証明する方法が仕組みとして存在していないのが一部課題としてあると考えています。ここでは、まだ全ての実現は難しいのですが、将来的に期待される行政への動きも含め、SSIを適用してこの課題を解決するユースケースをざっと考えてみました。
[ユースケース図]
####ユースケース中のアクター
- ユーザー（利用端末含む）：サービス利用者、利用金融機関の口座保有を証明し、決済サービス利用を申し込む
- 金融機関：銀行や証券会社など
- 決済サービス：銀行や証券会社で管理されている資金を移動して決済できるサービス
- 行政サービス：役所など
ここでアクターとして行政サービスがありますが、ここは将来的にマイナンバーなどを利用した本人情報の確認を横断的に行えるようになる未来を含んでいます。Aliceなどカッコがきでアルファベットで書かれている名称は後のシミュレーションの際に利用する名称（識別子）となります。
####ユースケースのシミュレーション
本ユースケースにおけるシミュレーションは以下となります。
- ユーザーが行政から本人証明を取得
- ユーザーが金融機関に口座保有証明書の発行を申請
- 金融機関が申請者がユーザー本人か確認
- 金融機関が管理している口座状況を確認し、口座保有証明書を発行、送信
- ユーザーが受信した証明書の確認と保管
- ユーザーが決済サービスに証明書を提出
かなりラフではありますが、公的に認証されている本人情報を利用して、金融機関の口座情報が利用者本人のものと証明した上で、金融機関に接続する決済サービスに証明書を確認・保持してもらうことで、同一性の担保を行うシミュレーションを行います。
###2. ユースケースの検証の仕方
Ariesのリポジトリには動作検証ができるユースケースがありますが、本ユースケースをそのまま実現できるものはないので、時間の都合上と流れの把握を重視するため、既存のユースケース（The Alice/Faber Python Demo）を利用して、本ユースケースのシナリオに当てはめて話をしたいと思います。ちなみにThe Alice/Faber Python Demoでは大学院進学のための学位証明書取得と提出のユースケースとなっています。このユースケースを本ユースケースに見立てたものでシミュレーションを行います。
ユースケースのシミュレーション
本ユースケースの技術検証を行うにあたり、シミュレーションデモを紹介しますが、前述のユースケース図に記載した実線部分（プロセス②〜⑥）にフォーカスしてシミュレーションを進めます。なお、シミュレーションではAriesのPythonエージェントのリポジトリに付属しているデモを参考にしています。
シミュレーション方法
シミュレーション方法はインターネット上で用意されたインスタンスを利用するか、あるいは自分のローカル環境に用意して進めるかの２種類がありますが、より手軽に扱える用意されたインスタンスを使って話を進めます。本シミュレーションは簡易的なもので、SSIにおける詳細な処理の手続き部分に関しては今回省きます。より詳細な情報はgithub上のAriesのドキュメントが参考になります。
1. 環境準備
最初にPlay With Vonのサイトにブラウザ経由でアクセスします。表示がされたらStartボタンを押してください。
次にADD NEW INSTANCEをクリックしてください。
画面右側のコンソールを利用します。
2. 前準備：エージェントの起動及びエージェント間の接続の確立
以下のコマンドを実行して、最初に金融機関（Faber）のエージェントを起動します。
$ git clone https://github.com/hyperledger/aries-cloudagent-python
$ cd aries-cloudagent-python/demo
$ LEDGER_URL=http://dev.greenlight.bcovrin.vonx.io ./run_demo faber
起動したら、エージェントを起動したターミナルとは別のターミナルでユーザー（Alice）のエージェントを起動するためにADD NEW INSTANCEをクリックします。
node1が金融機関（Faber）、node2がユーザー（Alice）となります。
ユーザー（Alice）のエージェントを起動します。
$ git clone https://github.com/hyperledger/aries-cloudagent-python
$ cd aries-cloudagent-python/demo
$ LEDGER_URL=http://dev.greenlight.bcovrin.vonx.io ./run_demo alice
金融機関側のターミナルに戻り、Invitation Dataをコピーして、ユーザー側のターミナルのコンソールに貼り付けます。
[金融機関（Faber）のターミナル]
[ユーザー（Alice）のターミナル]
この段階で金融機関（Faber）とユーザー（Alice）のエージェントとの間での接続が確立します。
金融機関（Faber）
Faber | Connected
(1) Issue Credential
(2) Send Proof Request
(3) Send Message
(T) Toggle tracing on credential/proof exchange
(X) Exit?
[1/2/3/T/X]
ユーザー（Alice）
Alice | Connected
Connect duration: 0.34s
(3) Send Message
(4) Input New Invitation
(X) Exit?
[3/4/X]
###3. ユーザーから金融機関に対しての証明書発行依頼
プロセス２（ユーザーが金融機関に口座保有証明書の発行を申請）を実際に実行してみます。依頼するためにユーザー（Alice）のオプション３を選択します。
[3/4/X]： 3
Enter message: Request Credential
Alice | Received message: Faber.Agent received your message
金融機関（Faber）側で送信されたメッセージが受信できていることが確認できます。
Faber | Received message: Request Credential
ここではユースケースに沿って説明したいため、メッセージ機能を使って発行依頼を出していますが、このメッセージ機能は基本的にはフリーフォマットなので任意の文字列を送信できます。
4. 金融機関から口座保有証明書を発行（Credentialの発行）
プロセス３（金融機関が申請者がユーザー本人か確認）はエージェント間の接続時に何かしら担保できたと仮定し、プロセス4（金融機関が管理している口座状況を確認し、口座保有証明書を発行、送信）を実行してみます。
金融機関（Faber）のターミナルでコンソールに表示されたオプション1を選択すると口座保有証明書（Credential）がユーザー（Alice）に対して発行されます。
[1/2/3/T/X] 1
#13 Issue credential offer to X
Faber | Credential: state = offer_sent, credential_exchange_id = 6b9d01dc-5a5e-4c9c-8ebb-1d4bd171573b
Faber | Credential: state = request_received, credential_exchange_id = 6b9d01dc-5a5e-4c9c-8ebb-1d4bd171573b
#17 Issue credential to X
Faber | Credential: state = credential_issued, credential_exchange_id = 6b9d01dc-5a5e-4c9c-8ebb-1d4bd171573b
Faber | Credential: state = credential_acked, credential_exchange_id = 6b9d01dc-5a5e-4c9c-8ebb-1d4bd171573b
ユーザー（Alice）のターミナルのコンソールを確認すると口座保有証明書（Credential）が発行されたことが通知され、その後プロセス5(ユーザーが受信した証明書の確認と保管）を行います。
#15 After receiving credential offer, send credential request
Alice | Credential: state = request_sent , credential_exchange_id = 56eaa0d5-75db-458a-ab87-95b12e3c12ee
Alice | Credential: state = credential_received , credential_exchange_id = 56eaa0d5-75db-458a-ab87-95b12e3c12
ee
Alice | Credential: state = credential_acked , credential_exchange_id = 56eaa0d5-75db-458a-ab87-95b12e3c12ee
Alice | Stored credential c5f00117-ecc7-4ad5-92a3-3e3769f8720d in wallet
#18.1 Stored credential c5f00117-ecc7-4ad5-92a3-3e3769f8720d in wallet
Credential details:
{
"referent": "c5f00117-ecc7-4ad5-92a3-3e3769f8720d",
"attrs": {
"timestamp": "1608440665",
"age": "24",
"date": "2018-05-28",
"name": "Alice Smith",
"degree": "Maths" //ここはオリジナルのユースケースが在学証明なのででdegree（学位）になっています
},
"schema_id": "gVW9FAQrVELxwjyZdFbdL:2:degree schema:65.89.20",
"cred_def_id": "gVW9FAQrVELxwjyZdFbdL:3:CL:44799:Faber.Agent.degree_schema",
"rev_reg_id": null,
"cred_rev_id": null
}
Credential request metadata:
{
"master_secret_blinding_data": {
"v_prime": "5092108497562712315822585430042551697549836955597339875556352497122632182682021996609054301788140387484628915896681467209276997570207915498954956191118719382060641845940145175032999283523570893162610808791132003458546253480872796859386135041216406181014995606910828048589651818078604680846640073403153797599506153615930849615630542989602518372936057941109761289211330215735863018591809298543442923799360110931275951598463488683705282828332381942071365151514733408316679900546448478064277906635359088176961066557917621082802046254709171401505296457173385506899911384036666995679033363284445073493564825927823460421736373088281768012464475802",
"vr_prime": null
},
"nonce": "972183250393167076892841",
"master_secret_name": "alice.agent562615"
}
Alice | credential_id c5f00117-ecc7-4ad5-92a3-3e3769f8720d
Alice | credential_definition_id gVW9FAQrVELxwjyZdFbdL:3:CL:44799:Faber.Agent.degree_schema
Alice | schema_id gVW9FAQrVELxwjyZdFbdL:2:degree schema:65.89.20
###5. Proofの要求、提示
続いて、プロセス6（ユーザーが決済サービスに証明書を提出）を進めます。ここでは決済サービス（Faber'）に対して申し込みを行います。
決済サービス（Faber'）のエージェントでオプション２を選択するとユーザー（Alice）からProofを要求します。※便宜上同じFaberエージェントを利用します。
#20 Request proof of degree from alice ////ここはオリジナルのユースケースが在学証明なのででdegree（学位）になっています
Faber | Presentation: state = request_sent , presentation_exchange_id = 42cab524-6fe4-45c7-927a-02dc055fdbbe
Faber | Presentation: state = presentation_received , presentation_exchange_id = 42cab524-6fe4-45c7-927a-02dc
055fdbbe
#27 Process the proof provided by X
#28 Check if proof is valid
Faber | Presentation: state = verified , presentation_exchange_id = 42cab524-6fe4-45c7-927a-02dc055fdbbe
Faber | Proof = true
ユーザー（Alice）のエージェント側でProofを生成して、決済サービス（Faber'）に口座保有証明書が送信されました。
Presentation: state = request_received , presentation_exchange_id = 0e898d36-1449-4d4a-a465-ff42fb10fcc2
#24 Query for credentials in the wallet that satisfy the proof request
#25 Generate the proof
#26 Send the proof to X
Presentation: state = presentation_sent , presentation_exchange_id = 0e898d36-1449-4d4a-a465-ff42fb10fcc2
Presentation: state = presentation_acked , presentation_exchange_id = 0e898d36-1449-4d4a-a465-ff42fb10fcc2
これが本ユースケースにおける大まかな流れのシミュレーションとなります。
最後に
時間的な制約もあり、ユースケースを技術的に詳細まで検証できませんでしたが、引き続き詳細を掘り下げつつ検証を続けたいと思います。ここではBlockchainでの管理を想定して話を進めましたが、Blockchain以外での分散管理方法もあり、技術の進化ともに新しいセキュアで効率的な手法もこれからまだ生まれてくるものと思います。ここ数年でキャッシュレスをはじめとしたお金のデジタル利用が進み、過渡期を狙った不正も残念ながら後をたちません。各金融事業者は日々不正と向き合いつつ、根絶すべく様々な防御を施していますが、業界として一丸となって不正、セキュリティに対するスタンダードを技術レベルで策定・適用して、よりユーザーの利便性を各社が追求できる余地を大きくすることで、さらなるフィンテック業界の発展が進められればと考えています。