Encrypted Credentials with Symbol とは
Symbolブロックチェーン上のユーザーが持つ公開鍵・秘密鍵を用いることにより実現される暗号化クレデンシャルのPoCです。
いわゆるVerifiable CredentialsをSymbolブロックチェーン上で、クレデンシャルの発行・管理・検証を行います。
＃ Encrypted Credential上の登場人物
- 発行者（Issuer)
- 保有者（Holder）
- 検証者（Verifier）
- Symbolチェーン
発行者と検証者はユースケースによっては同一人物である場合があります。
発行者、保有者はsymbolブロックチェーン上のアカウントが必須となります。
検証者は任意となります。今回のデモでは使用しないケースを想定しています。
今回のデモは本システムを対面的に利用する場合を想定しており、クレデンシャルが第三者に漏れることを考慮しない場合を想定しています。
クレデンシャル情報を検証者へと送信する場合など、経路上で、生成したクレデンシャル情報が漏洩する危険性がある場合・その可能性を排除したい場合、検証者のアカウントに対してクレデンシャルを暗号化することにより、第三者に解読不可能なクレデンシャルを生成することが可能となります。
何が嬉しいか
特定の資格情報を信頼できる機関から発行されたものか、保有者から偽りの情報を送られていないかを検証することができる。
デモアプリケーション構成
本デモアプリケーションは、HolderはIssuerから資格証明を受け取り、Verifierへと対面的に資格情報を見せるといったシチュエーションとなっています。
Issuer Application
クレデンシャルの発行者が使用します。
クレデンシャルの発行とクレデンシャルのリンクを行うトランザクションのQRコードを生成します。
Holder Application
クレデンシャルを保有するユーザーが使用します。
実際の運用ではここはクレデンシャルを管理する機能を有するモバイルウォレットのような実装となります。
今回はデモなので普通にWebアプリケーションとして実装しています。
- QRコードを読み込むなどの方法でメタデータにリンクするトランザクションを読み込み、署名、アナウンスを行う機能
- 指定したKeyのクレデンシャルのQRコードを生成する機能
を持ちます。実際はQRとして読み込むことになりますが、今回はQRコードの中身を直接テキストでコピーアンドペーストします。
カメラはここの四角のボタンで閉じれます。
Verifier Application
クレデンシャルを検証するユーザーが使用します。
読み込んだクレデンシャルとHolderのアドレス、クレデンシャルの名前を入力することで、送られたクレデンシャルが正しいかを検証します。
クレデンシャルの生成
Issuer Applicationへと、以下の情報を入力します。
- クレデンシャル名
- Holderの公開鍵
- Issuerの秘密鍵 (今回はデモ用にWeb上に入力していますが実際はもっと安全な手法を取ってください)
作成ボタンを押下すると、暗号化されたクレデンシャルを刻むCredential Transaction (Transfer)とそのクレデンシャルのHashなどを刻むIndex Transaction (Transfer)のAggregateトランザクションを作成し、Issuerがアナウンスを行う。
そして、そのAggregateTransactionのハッシュ値をHolderのアカウントに刻むトランザクションを生成し、ペイロードからQRコードを生成する。(QRコードの右にあるのはQRコードの中身です。)
クレデンシャルのリンク
QRコードを読み込み、AccountMetadataTransactionを復元し、アナウンスを行う。
これで、Issuerが設定したクレデンシャル名から生成したメタデータキーにクレデンシャル情報のトランザクションのハッシュ値を刻むことができる。
実際のユースケースでは、クレデンシャルの送信先とメタデータをリンクしようとしているアカウントが同一のものであるか検証する必要があります。
QRコードを読み込む、または「MetadataTransaction Payload」の入力欄にペイロードを入力するとSSSが起動、署名が要求されます。
デモアプリではカメラの表示の下にある四角を押すとカメラが開いたり閉じたりします
メタデータを刻みます。
クレデンシャルのエクスポート
自身のアドレスとクレデンシャルキーからメタデータを取得し、そのメタデータに刻まれたハッシュ値のトランザクションを取得します。
そのトランザクションに刻まれた暗号化クレデンシャルをユーザーの秘密鍵とIssuerの公開鍵を用いて復号します。
そして、その復号したクレデンシャルをQRコードとしてエクスポートします。
SSSが起動します。
クレデンシャルを復号します。(タイポは直しておきます)
QRコードが生成されました
クレデンシャルの検証
検証者はQRコードを読み込み、クレデンシャルを取得します。このクレデンシャルが正しいものなのかをSymbolノードへと問い合わせを行います。
そして、そのクレデンシャルをsha3 256でハッシュ値を算出します。(Hash B)
「test」のハッシュ値は「36f028580bb02cc8272a9a020f4200e346e276ae664e45ee80745574e2f5ab80」ですね。
受け取ったクレデンシャルのハッシュ値は「56ea1559c67c23a0abef5f71203d62b119a65d24c773fc389fc76b92f0f69c27」ですね。
次に、Holderのアドレスとクレデンシャルの名前を指定し、チェーンに刻まれたクレデンシャル情報を照会します。
入力したアドレスとクレデンシャル名でメタデータを取得し、そのメタデータに刻まれたハッシュ値でクレデンシャルを刻んだトランザクションを検索します。
そして、Issuerが刻んだクレデンシャルのハッシュを取得し、手元にあるクレデンシャルのハッシュ値と比較し、ハッシュが一致した場合検証にクレデンシャルの検証に成功です。
Explorer
Index Tx + Credential Tx
https://testnet.symbol.fyi/transactions/0C1915176E02A5A3E6E702162DE5FDCE838EA818AB45013196D35CB37D3E50D3
Metadata Tx
https://testnet.symbol.fyi/transactions/69E727AAC19E0B9CE1006452CE55C573492689F3B5A9450876F47C2D3C529128
実際のユースケースでは、クレデンシャルを発行しているアカウント（発行者)によるトランザクションへの署名を既知の発行者アカウント情報と照会する必要があります。
プロトコルの流れ
- Credentialの作成
- Credentialのデータハッシュを算出
- Credentialを暗号化したトランザクション(Credential Tx)の作成
- Credentialのデータハッシュ等の付加情報をまとめるトランザクション(Index Tx)の作成
- Index Tx, Credential Txをアグリゲートしてアナウンス
- アグリゲートトランザクションのTxHashを保有者へリンクするトランザクションを作成し、QR生成
- 保有者はQRを読み込み署名・アナウンスを行い、クレデンシャルをアカウントにリンクする
ユースケース
- 資格証明の発行・検証(検証可能な履歴書)
- 連携したイベントへの参加を証明することによる実店舗での割引などのサービスの提供
DEMO APP
Issuer
https://brave-sand-06ce9cf00.2.azurestaticapps.net/
Holder
https://lively-sand-0a35c7f00.2.azurestaticapps.net/
Verifier
https://witty-cliff-0b56b1600.2.azurestaticapps.net/