DID、VCの仕組みのおさらい / DID and VC in quick

2024/4/11 Blockchain GIG#18 で喋った内容
過去資料から抜粋してDID/VCの基本をさらっと紹介。
元ネタ／より詳しい説明はこちら↓
https://www.kantei.go.jp/jp/singi/digitalmarket/trusted_web/2023seika/index.html

Transcript

1. DID/VCの仕組みのおさらい Blockchain GIG #18 中村 岳 日本オラクル株式会社 クラウド事業統括／クラウド・エンジニアリング統括／CoE本部／ソリューションアーキテクト部 2024/4/11
2. Copyright © 2024, Oracle and/or its affiliates 2 中村 岳 Twitter @gakumura はてなブログ @gakumura …主にHyperledger Fabric関連 • 現職：ソリューションエンジニア@日本オラクル • 担当：Oracle Blockchain Platform、 Blockchain Table • 前職：金融決済系SIerでパッケージ開発 • SWIFT、CLS、日銀ネット関連の銀行間決済システム
3. Copyright © 2024, Oracle and/or its affiliates 3 DID/VC理解の前提となる要素： 秘密鍵／公開鍵とデジタル署名
4. 秘密鍵／公開鍵 （※一部正確性よりもわかりやすさを優先） • 秘密鍵／公開鍵はペアで生成される • 秘密鍵は誰にも渡さず自身で管理する • 公開鍵は直接渡すか公開するかして相手が利用できるようにしておく 4 Copyright © 2024, Oracle and/or its affiliates Alice 秘密鍵／公開鍵ペア 生成 Alice Bob 私の公開鍵です 了解、保存しときます Alice Alice Bobがアクセスできる 公開鍵置き場に登録 Bob Aliceの公開鍵は あそこにあるな 直接渡すパターン 公開するパターン
5. 参考：RSA秘密鍵（左）と公開鍵（右）のサンプル -----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcnNh AAAAAwEAAQAAAYEA7ff6VyJ4T4Yb7jBnAx2n8r4OSaVRn+kXJk3xCi30t76cbXLJOkd+xuHdQe6 qMi89Fj8LXiq+0O/BJRLqviL6CNxVJGEiuHJZeZSW4bt2jj9zRt6/0H1NO1MgM723v92oDV1O+FVx GOPRFds50tKbm1QK+0mstccflpT2YNNhxQ0Ta+wEYA66B4apeCPjFTLW7QI8EyJ5DJi0MhrUmU wJX0m/VPdVpsobhZH4Jgl5njJ/QAHhapjybgC5NM/EoXX3fg2uMfdzFqDMX88WihWX4W7xcNaT ttIbyAx0GJU/ragec2j99cUxxokTgV98NPpLZJCGVbIt6ttAJb6sNvhGslE4RRK30m42/5m2R2GvF8C aKAF15XSJvi0e8uW7iq6HMTt5S3IutvnVmC07lK9m/i6J81q5vS2MWtb1bDSmCjILZ7MyBxTtJkuV Iwf+ueZRIxqswZ4jx1uHjKH14yyQ33AwmhYtEBim6RxoTLZG02ot2jLlc2bsWtkpgcRl5uv/AAAFkP7 4GhH++BoRAAAAB3NzaC1yc2EAAAGBAO33+lcieE+GG+4wZwMdp/K+DkmlUZ/pFyZN8Qot9Le+ nG1yyTpHfsbh3UHuqjIvPRY/C14qvtDvwSUS6r4i+gjcVSRhIrhyWXmUluG7do4/c0bev9B9TTtTIDO 9t7/dqA1dTvhVcRjj0RXbOdLSm5tUCvtJrLXHH5aU9mDTYcUNE2vsBGAOugeGqXgj4xUy1u0CPB MieQyYtDIa1JlMCV9Jv1T3VabKG4WR+CYJeZ4yf0AB4WqY8m4AuTTPxKF1934NrjH3cxagzF/PFo oVl+Fu8XDWk7bSG8gMdBiVP62oHnNo/fXFMcaJE4FffDT6S2SQhlWyLerbQCW+rDb4RrJROEUSt 9JuNv+ZtkdhrxfAmigBdeV0ib4tHvLlu4quhzE7eUtyLrb51ZgtO5SvZv4uifNaub0tjFrW9Ww0pgoyC 2ezMgcU7SZLlSMH/rnmUSMarMGeI8dbh4yh9eMskN9wMJoWLRAYpukcaEy2RtNqLdoy5XNm7F rZKYHEZebr/wAAAAMBAAEAAAGBAKHMydoVBdiMRtFc962WrGrP7scEMMuZoLPaqtlRBeMpJxM DyO5nTjvLtrTtoasdk1tc4k3UoolNevXKNvGwtnDv3rQtl33xwgR4k15IKAPwAGFfcuw/RhPgITUM+b Lq8yijGN6guZVC0RcbR+WgbUzfh9fz8ApoqYGpJxwOnZttmJb4ksD9Ql97oB6fx/bR6nCb5FzeQ4/ dBChNNeBFYtn3OrB6uzH8mVnoNeEm8BowG3VZ0fq4o51HwKW33uopWh4k35gwxwc0FF4Qljcc 0I0M68/UGmBZazEOFemj457FiS+05rR01ueZ2sNDe6mx9Nz/QxrIvMJFnUtEUMQLBJs0bG7rppC BQgUKjQvUAU+VYwB0+geKEeUsnIh7Wz3rBcKjHKEjk91b8fe4cqEYZKq1n9pF+pNiL7UoJa8KXn4 sn+dFYyhg5Gz1L/L6BSEif/CuzrWwpLriDY4ncQzCBBgzrfeFU6nXHBG6B4c1q0nF0x0WbC2Rr0gg BoCvQg8rgQAAAMAuEm4Nh8t/InPPO8F1OkCHC/2sfK8l+8L79RxcJyX3Pg3aMy54UcVJj9Y2LFl3 8ZsL9bXji19sFhdKgt9lSqp9wGd/bos9v151rUGRAR0Ze9NfOieyNk6PXLaXT2fm1EQrQGtzRVvaeY y+wDAUrIFpTtZ2GXYPlG/OlMh/orHlt4vQO4jxx2jr4e6bm68XuXorThFRbgcQoIsPuGcQl8uOrLtFR O5O2LPNVn1tyo3SbxFJaG6H4klVT4AFVIgoyxsAAADBAPiJwF9jz+xwis4g4GMMBH+tBBLbolnaxn 7UQmx0LZYzpNgswMAcX7sBPZmQ3WXaSXXuq6VH9Wrw7+6izoVdQxebUT7m/pmV814qAVis/ 2b4UrtYabnI5HF5b7k24L2jNZTf4k7mZRts8JPRkk53uExW+iX1IGMghMEkU8zHciCwZkg6r6/55Ld B7n3cOpATwqhv7CrfJ53smvVkNGdEleA71VwpGq7ouz7JjkC/M+ou2RV76kwMo8qjd0zef7O5uw AAAMEA9Rz9jtQrnyPfSw6FKQrRjkMGeu+T8iHThno+xc+Nby/bMkXDFbJQpAXwBxIBLkbl/oLIzH mHNnTuxiDxxsWGGK6wT9hR1T/YOw5Ztcz4SZvGPesroKmRuYuBU9XOzEXZ8Wz3kjE3cqWIhf+u Rm4RCEfUGahl0nxrkXjAMO/tujH15ixuOO6nSRxrrUtutGVBnWubJrKzHD/ncShAOA0FDKwYE0F7 okwbOsnWFkbBSdWXq5DH1sAO31uTUS020uCNAAAAFWdha3VAR05BS0FNVVItSkpYSExOMwE CAwQF-----END OPENSSH PRIVATE KEY----- ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDt9/pXInhPhhvuMGcDHafyvg 5JpVGf6RcmTfEKLfS3vpxtcsk6R37G4d1B7qoyLz0WPwteKr7Q78ElEuq+I voI3FUkYSK4cll5lJbhu3aOP3NG3r/QfU07UyAzvbe/3agNXU74VXEY49E V2znS0pubVAr7Say1xx+WlPZg02HFDRNr7ARgDroHhql4I+MVMtbtAjwTI nkMmLQyGtSZTAlfSb9U91WmyhuFkfgmCXmeMn9AAeFqmPJuALk0z8S hdfd+Da4x93MWoMxfzxaKFZfhbvFw1pO20hvIDHQYlT+tqB5zaP31xTHG iROBX3w0+ktkkIZVsi3q20Alvqw2+EayUThFErfSbjb/mbZHYa8XwJooAXX ldIm+LR7y5buKrocxO3lLci62+dWYLTuUr2b+LonzWrm9LYxa1vVsNKYKM gtnszIHFO0mS5UjB/655lEjGqzBniPHW4eMofXjLJDfcDCaFi0QGKbpHGh MtkbTai3aMuVzZuxa2SmBxGXm6/8= gaku@GNAKAMUR-JJXHLN3 5 Copyright © 2024, Oracle and/or its affiliates
6. デジタル署名とその検証 Copyright © 2024, Oracle and/or its affiliates 6 署名対象の内容 署名アルゴリズム デジタル署名 デジタル署名 秘密鍵を署名鍵として用い、デジタル署名アルゴリズムを使い、ある内容に対してのデジタル署名を生成する デジタル署名の検証 公開鍵を検証鍵として用い、署名された（はずの）内容とともに検証アルゴリズムにかけるとデジタル署名を検証できる 署名鍵＝秘密鍵 IN OUT 署名対象の内容 検証鍵＝公開鍵 検証アルゴリズム 検証結果 （OK or NG） OUT IN デジタル署名 IN IN IN
7. デジタル署名とその検証の仕組みの利用 7 Copyright © 2024, Oracle and/or its affiliates Alice Bob • 送信者から受信者に対してメッセージを送る際に、メッセージ内容（のハッシュ値）に対しての送信者のデジタル署名を セットで送信する • 受信者は送信者の公開鍵を用いたデジタル署名の検証によって、確かに送信者からのものであること、メッセージ内容 が経路上で改ざんされていないことを確認できる メッセージ内容 ↑に対する Aliceの署名 • 直接の受信者以外も、（送信者の公開鍵にアクセス可能であれば）デジタル署名を検証することで 後からでもメッセージの真正性を確認できる Bob Aliceがこんなこと 言ってるんですよ Charlie Aliceの署名が正しいから 本当だな… デジタル署名できる秘密鍵を 持っているのはAliceだけなので 確かにAliceからのメッセージだな Aliceの 公開鍵 Aliceの 公開鍵
8. 参考：ハッシュ値 • ハッシュ値：元になるデータから一定の計算手順（→ハッシュアルゴリズム）により求められた固定長の値 • データが同一で、用いるハッシュアルゴリズムが同一であれば、同一のハッシュ値が出力される • 弱衝突耐性、強衝突耐性を持ち、元データの同一性の確認のために用いられる • 弱衝突耐性：あるハッシュ値を出力する元のデータを狙って作ることが（実践的には不可能なほど）困難 • 強衝突耐性：別々の元データから出力したハッシュ値が同一になることが（実践的には無視できるほど）稀 • ハッシュ値自体は意味のない文字列であり、かつ、ハッシュ値から元のデータへの復元はできない 8 Copyright © 2024, Oracle and/or its affiliates 75867688ec572fbb9121f1ef8bd63044 5446e83fb59625d8018f292045ab009d 67e0623844433a34fbb8ee2caf3a1559 元データ ハッシュ アルゴリズム ハッシュ値
9. Copyright © 2024, Oracle and/or its affiliates 9 DID & VCの仕組み
10. DID（Decentralized Identifier） • 規格として識別子の形式および発行、登録、公開、検証などの運用方法が規定されている • DIDに関する規格、および実装（DID Methodと呼ばれる）は複数あるが、識別子の形式は共通の規格がある • DIDの具体的な例： • did:ion:EiCjHFpU1Fm6Qnq7XIj_Gt2QGCpnwQrrnUWoVrM4H9we1A • did:sov:WRfXPg8dantKVubE3HX8pw • DID Methodの例…それぞれ別々のレジストリにDIDが登録されている • ION…パブリックのBitcoinブロックチェーンをレジストリとして利用 • Sovrin…コンソーシアムのHyperledger Indyをレジストリとして利用 • Ethr…パブリックのEthereumブロックチェーンをレジストリとして利用 10 Copyright © 2024, Oracle and/or its affiliates
11. DIDの取得（生成と登録） DIDのセットアップはアイデンティティの所有者が自身で行う（⇔ IdPに発行してもらう） 1. ウォレットを用意 2. キーペア（秘密鍵／公開鍵）を生成 3. DIDを生成 4. レジストリにDID Documentを登録 • DIDと公開鍵が含まれる 11 Copyright © 2024, Oracle and/or its affiliates Wallet レジストリ DID Document 秘密鍵 DID 公開鍵 { "id": "did:example:123456789abcdefghi", "authentication": [{ "id": "did:example:123456789abcdefghi#keys-1", "type": "Ed25519VerificationKey2018", "controller": "did:example:123456789abcdefghi", "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" }] } 登録 Holder アイデンティティの 所有者 DID Documentの例 ！！個人のプロファイル情報は含まれない！！
12. DIDの認証 1. Holder（DIDとVCの所有者）がVerifier（資格情報を要求し、検証する者）に対して、DIDの認証をリクエスト 2. Verifierがランダムに生成したチャレンジコードをHolderに送り、デジタル署名を要求 3. Holderはチャレンジコードに対して自身の持つ秘密鍵でデジタル署名して返却 4. VerifierはDIDに対応するDID Documentに含まれる公開鍵を使い、デジタル署名を検証することで認証 12 Copyright © 2024, Oracle and/or its affiliates Wallet 秘密鍵 Holder わたしはdid:aaa:hogehogeです 本当にhogehogeなら チャレンジコード:XXXXXX…に署名してみてよ 署名したらxxxxxx…になりました hogehogeの公開鍵はこれだな 検証してみよう →署名が合ってるから本物だな or署名が合わないから偽物だな Verifier
13. 理解しておきたいポイント：レジストリの基盤と運用 • レジストリは誰かが運用しなければ存続しないが、そのコストを誰がどのように負担するかは実践上の課題 • パブリックブロックチェーンであれば、DID Documentを登録するときにトランザクション手数料（GAS代）を支払う • コンソーシアム型ブロックチェーンでは運用者が負担する？DID利用者から利用料を徴収する？ • レジストリにブロックチェーン（分散台帳）を用いることは仕様上必須ではない …DIDの”Decentralized”はレジストリにブロックチェーンを用いることを必ずしも要求してはいない • レジストリには常にアクセスでき、DID/VCが用いられる期間は存続し、都合よく削除改変されないことが期待され るため、ブロックチェーンの特性が有利に働く 13 Copyright © 2024, Oracle and/or its affiliates パブリック ブロックチェーン上の レジストリ コンソーシアム型 ブロックチェーン上の レジストリ 単一組織の データベース上の レジストリ
14. VC（Verifiable Credential） • あるデジタルアイデンティティについての情報の「検証可能なデジタ ル証明書」をVerifiable Credentialとして表現できる • ヒトの例：身分証、免許、学歴、職歴、試験のスコア • モノの例：品質鑑定結果、車検証、メンテナンス履歴 • 規格として証明書の形式および発行、保持、提示、検証などの 運用方法が規定されている • 以下のような項目を持つ • 誰が発行したのか（issuer） • 誰／何についてのどのような情報か（subject） • 誰／何：HolderのDID • どのような：資格情報の内容 • 発行者のデジタル署名 • 署名検証用の公開鍵の所在 14 Copyright © 2024, Oracle and/or its affiliates { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1", "https://w3id.org/security/suites/ed25519-2020/v1" ], "id": "http://example.edu/credentials/3732", "type": [ "VerifiableCredential", "UniversityDegreeCredential" ], "issuer": { "id": "did:example:76e12ec712ebc6f1c221ebfeb1f", "name": "Example University" }, "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "BachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "Ed25519Signature2020", "created": "2022-02-25T14:58:43Z", "verificationMethod": "did:example:76e12ec712ebc6f1c221ebfeb1f#key-1", "proofPurpose": "assertionMethod", "proofValue": "z2Xdmp6YDYz5RPKeRFDcPYorAmnERyr7aRNzv176oLMxwcW7GgKxAQT 45jUKwsMA1XvrmFT5Y8WCx7ZnkNTTHJnu9" } } Verifiable Credentialの例
15. VCの発行と保管 前提 • Issuer（VCの発行者）は自身のDIDを取得（DID Documentをレジストリに登録）しておく • 後のVCの検証にIssuer公開鍵が必要になるため • なお、公開鍵をDIDではないかたち（Webサイト等） で公開しておくやり方も取り得る • HolderのDIDは認証済 VCの発行プロセス 1. HolderがIssuerに対して自身のDIDに対してのVC発行を リクエストし、IssuerとHolderとの間で必要な確認プロセス （資格情報の内容によって様々）を実施 • 例：大学に出向いて本人確認の上で学位証明の VCをリクエスト 2. IssuerがHolderに対して自身の秘密鍵でデジタル署名し たVCを送付 3. HolderはVCを自身のウォレットに保管 15 Copyright © 2024, Oracle and/or its affiliates レジストリ HolderのDID Document DID 公開鍵 IssuerのDID Document DID 公開鍵 Holder Issuer Wallet 秘密鍵 Wallet 秘密鍵 VC ①VCリクエストと 必要な確認 ②Issuerが秘密鍵で 署名してVC送付 VC ③Holderが VCを保管 HolderとIssuerのDID Method（＝レジストリ）は 別でも良い！！
16. VCの提示と検証 （前提：HolderのDIDは認証済） 1. HolderはVerifierに対してVCを提示 2. VerifierはVCに示されるIssuerの公開鍵を使ってVC（のIssuerのデジタル署名）を検証したうえで、 VCに記載の資格情報の内容を受け入れ • ここでVerifierからIssuerへの問い合わせが生じない（HolderはIssuerに対してVerifierの提供するサービスを利用し ていることを知られない）で資格情報の検証が行えている点は重要なポイント…プライバシー、アクセシビリティ 16 Copyright © 2024, Oracle and/or its affiliates VC Holder Verifier レジストリ HolderのDID Document DID 公開鍵 IssuerのDID Document DID 公開鍵 Wallet 秘密鍵 VC VCの提示 Issuer署名の 検証
17. DID/VCまとめの図 Copyright © 2024, Oracle and/or its affiliates 17 Holder Wallet 秘密鍵 VC Issuer Wallet 秘密鍵 ブロックチェーンなどで 実装されたレジストリ HolderのDID Document DID 公開鍵 IssuerのDID Document DID 公開鍵 Verifier VCの提示 DIDで認証 DIDで認証 VCの発行 DID Documentを登録 DID Documentを登録 DIDの署名検証の ために参照 VCの署名検証の ために参照 DIDの署名検証の ために参照 サービス等の提供 ヒト／モノ DIDs VCs 1 n 1 n
18. VP（Verifiable Presentation） • Holder側での以下の（いずれかまたは両方の）操作によりVCからVP（Verifiable Presentation）を作成し、 Verifierに対してVCを直接するのではなくVPを提示することもできる • ひとつのVCに含まれる複数の資格情報の項目から提示する項目を取捨選択して抽出（→選択的開示） • 複数のVCから資格情報をまとめて抽出 • VPに対応するためには、VCが特定の形式（SD-JWT、BBS+など）でデジタル署名されている必要がある ※VCの標準によってはVerifiable Presentationの仕組みがないものもあるかも 18 Copyright © 2024, Oracle and/or its affiliates 元のVC（運転免許証） 選択的開示の例： 年齢確認のため免許証VCから生年月日のみをVPとして開示 氏名：鈴木 太郎 住所：千代田区1-2-3 生年月日：1999/10/1 種類：中型 etc. Holder 提示するVP 生年月日：1999/10/1 署名（SD-JWT） 署名（SD-JWT） VPを作成 Verifier VPの提示
19. 理解しておきたいポイント：Issuerの信頼性の判断 • VerifierはVCの内容自体はIssuerのデジタル署名により検証可能だが、そのIssuerが信頼に足るかどうかはVCを見 ていても判断がつかない • 不正の例：それっぽい名前でIssuerのDID Documentを適当に登録して都合の良いVCを濫造 19 Copyright © 2024, Oracle and/or its affiliates Issuer：did:aaa:jpgovernment subject: “hogehogeは弁護士です” sign: xxxxxxxx Verifier 署名検証はOKだけど、そもそも このIssuerは信頼できるのか…？ Holder VCの提示 ホワイトリストとのIssuerの照合や、 Webサイトなどを参照して 信頼性を判断することになりそう
20. Thank you Copyright © 2024, Oracle and/or its affiliates 20