ゼロ知識証明とその応用: (4) 分散型アイデンティティにおける応用

電子情報通信学会 2025年総合大会 企画セッション AI-2 ゼロ知識証明とその応用

2025年3月28日

Transcript

1. (4) 分散型アイデンティティにおける応用 山本 暖 (株式会社インターネットイニシアティブ) 2025年3月28日 / IEICE 2025年総合大会 企画セッション [AI-2] ゼロ知識証明とその応用
2. 目次 1 n分散型アイデンティティとは n分散型アイデンティティとゼロ知識証明 n実用化に向けた課題
3. 分散型アイデンティティとは
4. アイデンティティとは 3 ISO/IEC 24760-1:2019 [ISO19] によると: 実体に関する属性の集合 (a set of attributes related to an entity) 実体 (人、組織、もの) 属性の集合 マイナンバー: 123456789012 メールアドレス: dan@iij.ad.jp 氏名: 山本 暖 住所: 神奈川県横浜市 勤務先: IIJ (2021-) 所属部署: セキュリティ本部 資格: 英検3級 [ISO19] ISO/IEC 24760-1:2019, IT Security and Privacy — A framework for identity management — Part 1: Terminology and concepts
5. アイデンティティの証明は一人では難しい 4 山本といいます IIJで働いています 英検3級です 本当か? アイデンティティ(属性の集合)の 証明は自分一人では難しい → 信頼された第三者が必要 ユーザ番号 0001です パスワードは abc です おかえりなさい ユーザ0001さん ユーザ 番号 パス ワード 0001 abc … … 一度知りあった相手に 「私はあなたの知っている◯◯だ」 と証明すること(当人認証) は自分だけでも可能だが…
6. 第三者によるアイデンティティの保証 5 彼は山本さんです IIJで働いています あなたが言うなら 信じよう 社員証が 確からしいので 信じよう アイデンティティ連携 デジタル証明書 第三者に直接保証してもらう 第三者の発行書類で保証してもらう この社員証の持ち主は 山本さんです IIJで働いています 社員証を発行 分散型アイデンティティはこちら
7. アイデンティティ連携 6 彼は山本さんです メールアドレスは yamdan@gmail.com です Googleが言うなら 信じよう IdP (Identity Provider) RP (Relying Party) ユーザ ü ユーザはブラウザだけあれば使える (秘密鍵や証明書の管理は不要) ü RPに提示される内容はユーザがIdP上でコ ントロールできる (メールアドレスは出すが氏 名は隠す、など) ü 産学官民、個人法人問わず広く普及 (例: Google, Apple, Microsoft, LINE, Yahoo! Japan, デジ庁認証アプリ, GBizID, 学認) û IdPには高可用性(24/365等)が要求される û ユーザのRPへのアクセス状況が逐一IdPに 把握される û ユーザ、IdP、RPは互いに通信可能でないと いけない (オンライン利用が前提) OpenID Connect, SAML
8. デジタル証明書 7 ü Issuerは証明書発行時だけ稼働していれば 良い (24/365不要) ü Issuer-Verifier間の通信は不要 (オフライン 利用が可能) ü ユーザのVerifierへのアクセス状況が Issuerに把握されにくい ü IdPやIssuerへの過度な信用・依存を減ら せる û サービス提供者だけでなく、ユーザ側にも鍵 や証明書を安全に保持・運用する仕組みが 必要 (例: ICカードやデジタルIDウォレット) û 従来型デジタル証明書は ユーザのプライバシに課題あり (後述) 証明書が 確からしいので 信じよう この証明書の持ち主は 山本さんです IIJで働いています 署名付きの 証明書を発行 Issuer Verifier ユーザ (Holder) PKI, Verifiable Credentials, ISO mDL, SD-JWT
9. 従来型デジタル証明書の発行 8 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 fed987… 氏名 山本 暖 部署 セキュリティ 標準的署名 (ECDSA等) Issuerの署名鍵 署名前の証明書 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 fed987… 氏名 山本 暖 部署 セキュリティ デジタル署名 345def… 証明書 Issuer ユーザ
10. 従来型デジタル証明書の検証 9 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 fed987… 氏名 山本 暖 部署 セキュリティ デジタル署名 345def… 標準的 署名検証 (ECDSA等) Issuerの公開鍵 ✔ 成功 ユーザ 証明書 Verifier 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 fed987… 氏名 山本 暖 部署 セキュリティ デジタル署名 345def… ü デジタル署名が付くので改ざん困難 û ユーザ固有の情報がふんだんに含まれる (ユーザ公開鍵、デジタル署名) → Verifier 間でユーザの行動を容易にリンクできる Verifier Verifier
11. 従来型デジタル証明書の検証 10 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 fed987… 氏名 山本 暖 部署 セキュリティ デジタル署名 345def… 標準的 署名検証 (ECDSA等) Issuerの公開鍵 ✘ 失敗 ユーザ 証明書 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 氏名 部署 セキュリティ デジタル署名 û 見せたくない固有情報を隠すと 署名検証に失敗してしまう (改ざんと区別できない) アイデンティティ連携(OIDC等)では IdPがユーザの希望に沿って 情報の開示/非開示をしてくれていた (IdPを信用する限り) Verifier Verifier Verifier
12. 分散型アイデンティティ: 新しいデジタル証明書 11 n 近年「分散型アイデンティティ」コンセプトのもと ユーザのプライバシーを強化したり、JSON/CBOR等のより現代的なデータ形式をもつような 新しいデジタル証明書の検討や標準化が進む Ø W3C: 2014年から新たなデジタル証明書に関する議論が始まり、2019/11に Verifiable Credential (VC) データモデル標準v1を標準化。2022/3にv1.1に更新。現在v2.0の作業中 Ø ISO: 2021/9に ISO mDL (モバイル運転免許証) の標準を公開 (ISO/IEC 18013-5)。プライ バシ保護属性クレデンシャルの検討も開始 (ISO/IEC PWI 24843) Ø IETF: 証明書の一部を秘匿できる SD-JWT VC や JWP (JSON Web Proof) の標準化作業中 Ø Hyperledger: プライバシ強化型証明書のオープンソース実装 AnonCreds を開発 Ø 欧州: eIDAS2.0指令に基づく EU Digital Identity Wallet (EUDIW) の設計と実装を推進 中。SD-JWT VC を使ったデジタル証明書を採用し、2026年までに各国で1つ以上のウォレット を用意する予定。並行してGaia-X, Catena-XなどデータスペースでのVC利用も検討 Ø 日本: 産学官民連携のTrusted Web推進協議会でデジタル証明書の活用を検討。デジタル 庁では ISO mDL を使ったマイナンバーカードのiPhone版を2025年春に提供予定
13. 新しい証明書の特徴(1): 選択的開示 12 Issuer Verifier 1 ユーザ 発行時の証明書 Verifier 2 ü 選択的開示可能 特殊な署名方式を 使うことで、属性を一部 隠したままでも検証可能 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 fed987… 氏名 山本 暖 部署 セキュリティ デジタル署名 345def... 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 fed987… 氏名 部署 セキュリティ デジタル署名 345def... 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 fed987… 氏名 山本 暖 部署 デジタル署名 345def...
14. 新しい証明書の特徴(1): 選択的開示 13 Issuer (CA) Verifier 1 ユーザ Verifier 2 ü 選択的開示可能 特殊な署名方式を 使うことで、属性を一部 隠したままでも検証可能 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 fed987… 氏名 山本 暖 部署 デジタル署名 345def... 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 fed987… 氏名 山本 暖 部署 セキュリティ デジタル署名 345def... 発行時の証明書 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 fed987… 氏名 部署 セキュリティ デジタル署名 345def... 課題: ユーザ公開鍵や署名を見れば、Verifier-Verifier間、 Verifier-Issuer間でユーザ属性の復元が可能
15. 新しい証明書の特徴(2): リンク不可能 14 Issuer Verifier 1 ユーザ Verifier 2 ü 選択的開示可能 特殊な署名方式を 使うことで、属性を一部 隠したままでも検証可能 ü リンク不可能 公開鍵や署名を隠した ままでも検証可能 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 氏名 山本 暖 部署 デジタル署名 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 fed987… 氏名 山本 暖 部署 セキュリティ デジタル署名 345def... 発行時の証明書 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 氏名 部署 セキュリティ デジタル署名
16. デジタル証明書の作り方 15 アプローチ 偽造 不可能 選択的 開示 リンク 不可能 実装 容易 例 (a) デジタル署名のみ ✔ ★★★ PKI X.509 (成熟) (b) デジタル署名 ＋ ソルト付き属性 ハッシュ ✔ ✔ ★★ ISO mDL (標準化済) SD-JWT (標準化中) (c) デジタル署名 ＋ ゼロ知識証明 ✔ ✔ ✔ ★ VC-DI-BBS(標準化中) JWP-BBS (標準化中) AnonCreds (OSS) Google案 (研究段階) ※アプローチと例は主要なもののみ記載
17. 分散型アイデンティティとゼロ知識証明
18. ゼロ知識証明を使ったデジタル証明書 17 (c1) 効率的プロトコル付きデジタル署名 (BBS署名, CL署名, PS署名) ＋ 用途特化型ゼロ知識証明 (Σプロトコル) (c2) 標準的デジタル署名 (ECDSA署名, RSA署名) ＋ 汎用的ゼロ知識証明 (zk-SNARKs) VC-DI-BBS, JWP-BBS, AnonCreds Google案 [FS24] (c3) 耐量子 計算機 構成 アプローチ 偽造 不可能 選択的 開示 リンク 不可能 実装 容易 例 (c) デジタル署名 ＋ ゼロ知識証明 ✔ ✔ ✔ ★ VC-DI-BBS(標準化中) JWP-BBS (標準化中) AnonCreds (OSS) Google案 (研究段階) (本日は割愛)
19. ゼロ知識証明を使ったデジタル証明書 18 (c1) 効率的プロトコル付きデジタル署名 (BBS署名, PS署名, CL署名) ＋ 用途特化型ゼロ知識証明 (Σプロトコル)
20. (c1) 証明書発行 19 Issuerの署名鍵 署名前の証明書 証明書 Issuer ユーザ 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 fed987… 氏名 山本 暖 部署 セキュリティ 効率的 プロトコル付き 署名 (BBS署名等) 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 fed987… 氏名 山本 暖 部署 セキュリティ デジタル署名 987cba… メッセージの配列に対して 署名 署名のサイズは変わらない (c1) 効率的プロトコル付きデジタル署名 ＋ 用途特化型ゼロ知識証明
21. (c1) 証明書提示準備 20 証明書 ユーザ 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 fed987… 氏名 山本 暖 部署 セキュリティ デジタル署名 987cba… 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 氏名 部署 セキュリティ デジタル署名 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 氏名 部署 セキュリティ ゼロ知識証明 f1e2d3… 一部秘匿した証明書 用途特化型ゼロ知識証明 (Σプロトコル+FS変換) 「効率的プロトコル付き署名の検証に通るような メッセージ列と署名値を知っている」 ことのゼロ知識証明 Verifierへ提示する証明書 効率的プロトコル付き署名 を使ったおかげでこうしたゼロ知識 証明を効率よく(数msで)生成可能 (標準的な署名ではこうはいかない) (c1) 効率的プロトコル付きデジタル署名 ＋ 用途特化型ゼロ知識証明
22. (c1) 証明書提示/検証 21 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 氏名 部署 セキュリティ ゼロ知識証明 f1e2d3… 提示する証明書 Verifier 用途特化型 ゼロ知識証明 の検証 (Σプロトコル +FS変換) 「効率的プロトコル付き署名の検証に通るような メッセージ列と署名値を知っている」 ことの確認 Issuerの公開鍵 ✔ 成功 ユーザ 効率的プロトコル付き署名 を使ったおかげでこうしたゼロ知識 証明を効率よく(数msで)検証可能 (標準的な署名ではこうはいかない) (c1) 効率的プロトコル付きデジタル署名 ＋ 用途特化型ゼロ知識証明
23. (c1) まとめ (特にBBS署名を使った場合) 22 ü 署名生成、提示、検証がいずれも高速 (数ms) ü Issuerの公開鍵がメッセージ数(証明書内の属性の数)によらず固定 (96B) ü 署名サイズは 112B, 証明サイズは (368+32𝑛)B (𝑛: 非開示メッセージ数) û 「ペアリング演算」が可能な特殊な楕円曲線 (例: BLS12-381曲線) が必要 → 現在のスマートフォンの Secure Element ではサポートされていない。 結果、ユーザの秘密鍵管理にハードウェアデバイスを利用できない 基本方式は約20年前から存在。 安全性解析も十分に行われており、 IETF/W3C/ISOでの標準化も進行中。 ハードウェアサポートさえ解決できれば 最適な選択肢と思われる。 著名な暗号学者らも推奨 → (c1) 効率的プロトコル付きデジタル署名 ＋ 用途特化型ゼロ知識証明 Cryptographers’ Feedback on the EU Digital Identity’s ARF (2024年6月)[Bau+24]: EUDIWの検討内容に対して 提出された改善要求(フィードバック) “Our specific recommendation is to use the BBS family of anonymous credentials”
24. (c2) 証明書発行 23 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 fed987… 氏名 山本 暖 部署 セキュリティ 標準的署名 (ECDSA等) Issuerの署名鍵 署名前の証明書 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 fed987… 氏名 山本 暖 部署 セキュリティ デジタル署名 345def… 証明書 Issuer ユーザ Issuerは既存のインフラをそのまま利用できる (c2) 標準的デジタル署名 ＋ 汎用ゼロ知識証明
25. (c2) 証明書提示準備 24 証明書 ユーザ 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 fed987… 氏名 山本 暖 部署 セキュリティ デジタル署名 987cba… 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 氏名 部署 セキュリティ デジタル署名 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 氏名 部署 セキュリティ ゼロ知識証明 f1e2d3… 一部秘匿した証明書 汎用ゼロ知識証明 (zk-SNARK) 「標準的署名(例: ECDSA+SHA256) の検証に通るよう なメッセージ列と署名値を知っている」 ことのゼロ知識証明 Verifierへ提示する証明書 愚直に作ると生成に1分以上かかる が、各種テクニックを駆使すること で数十〜数百msまで高速化。 ペアリングも不要 [FS24] (c2) 標準的デジタル署名 ＋ 汎用ゼロ知識証明
26. (c2) まとめ 25 ü 署名生成、提示、検証がいずれも実用に耐える速度 ü Issuerの公開鍵がメッセージ数(証明書の種類)に依存しない ü 「ペアリング演算」が不要で、標準的な楕円曲線 (例: P-256曲線) で十分 → 現在のスマートフォンの Secure Element で使える û ユーザとVerifierで共有するパラメータが証明書の構造に依存 (証明書の構造/種類ごとにパラメータの生成と共有が必要) → [Google24] では ISO mDL に限定して性能を出しているが、 証明書の構造/種類により多様性が求められる場合は未知数 û 標準化活動はまだこれから (c2) 標準的デジタル署名 ＋ 汎用ゼロ知識証明
27. 実用化に向けた課題
28. 実データとBBS署名の入力とのギャップ 27 9139018... 7975413... 1672531200 4937101... 9139018... 1106247... ... 𝑚! 𝑚" 𝑚# 𝑚$ 𝑚% 𝑚& BBS署名 { "credentialSubject": { "name": "Dan Yamamoto" "worksFor": { "name": "IIJ" } } } ? W3C Verifiable Credentials データモデルに則った デジタル証明書の例(一部) [JSON-LDデータ] 効率的プロトコル付き署名 (BBS署名)が期待する入力 [BLS12-381曲線における スカラーの配列]
29. ギャップを埋めるためのデータ変換処理 _:c14n0 credentialSubject _:c14n1 _:c14n1 name "Dan Yamamoto" _:c14n1 worksFor _:c14n2 _:c14n2 name "IIJ" _:c14n0 _:c14n1 _:c14n1 _:c14n2 credentialSubject name worksFor name _:c14n1 "Dan Yamamoto" _:c14n2 "IIJ" JSON-LDデータ Canonical N-Quadsデータ { "credentialSubject": { "name": "Dan Yamamoto" "worksFor": { "name": "IIJ" } } } 𝑚! 𝑚" 𝑚' 𝑚!( 𝑚# 𝑚& 𝑚) 𝑚!! 𝑚$ 𝑚% 𝑚* 𝑚!# BBS入力用のスカラー配列 Hash-to-Field [RFC9380] 分割 RDF Dataset Canonicalization (直列化と正規化) 28 バイト配列
30. 早稲田大学 佐古研究室との共同研究 _:c14n0 credentialSubject _:c14n1 _:c14n1 name "Dan Yamamoto" _:c14n1 worksFor _:c14n2 _:c14n2 name "IIJ" _:c14n0 _:c14n1 _:c14n1 _:c14n2 credentialSubject name worksFor name _:c14n1 "Dan Yamamoto" _:c14n2 "IIJ" JSON-LDデータ Canonical N-Quadsデータ { "credentialSubject": { "name": "Dan Yamamoto" "worksFor": { "name": "IIJ" } } } 𝑚! 𝑚" 𝑚' 𝑚!( 𝑚# 𝑚& 𝑚) 𝑚!! 𝑚$ 𝑚% 𝑚* 𝑚!# BBS入力用のスカラー配列 Hash-to-Field [RFC9380] 分割 RDF Dataset Canonicalization (直列化と正規化) 29 バイト配列 W3C勧告化に貢献 [LKY24] データ変換も考慮に入れた 安全性分析 [YSS22]
31. プロトタイプ実装 jsonld-proofs rdf-proofs-wasm rdf-proofs zkp-ld-playground (online demo) docknetwork/crypto アプリ JSON-LD 処理 RDF処理 暗号処理 30 TS/Rust ブリッジ web-wallet (not published yet) オープンソース https://github.com/zkp-ld/ rdf-canon デモ https://playground.zkp-ld.org/
32. その他の技術的課題 31 n 正規化を使わないデータ変換 (JSON Web Proof向け) n 仮名 (同じコンテキスト・ドメイン内ではユーザを一意に特定) n 鍵管理ハードウェアデバイスとの処理分担 n 発行者情報の秘匿 (Issuer-Hiding Credentials) n ユーザプライバシを保護したまま証明書の失効を確認 n 述語証明 (生年月日を隠したまま成人であることを示す、等) n 量子計算機への耐性 n …
33. 社会実装に向けて: 分野横断的な議論の重要性 32 暗号 その他 アイデン ティティ プライバシ PKI デジタル署名 ゼロ知識証明 耐量子計算機暗号 証明書運用 トラスト管理 OpenID, SAML, OAuth Verifiable Credentials 分散型識別子(DID) 匿名化/仮名化 差分プライバシ ブロックチェーン セマンティックWeb
34. 参考資料: 論文 33 [Bau+24] C. Baum, O. Blazy, J. Camenisch, J-H. Hoepman, E. Lee, A. Lehmann, A. Lysyanskaya, R. Mayrhofer, H. Montgomery, N.K. Nguyen, B. Preneel, A. Shelat, D. Slamanig, S. Tessaro, S. E. Thomsen, C. Troncoso, “Cryptographers’ Feedback on the EU Digital Identity’s ARF,” June 2024, https://github.com/user-attachments/files/15904122/cryptographers-feedback.pdf [FS24] M. Frigo, A. Shelat, “Anonymous Credentials from ECDSA,” Cryptology ePrint Archive, Paper 2024/2010 [Sla25] D. Slamanig, “Privacy-Preserving Authentication: Theory vs. Practice,” arXiv:2501.07209, March 2025 [TZ23] S. Tessaro, C. Zhu, “Revisiting BBS Signatures,” EUROCRYPT 2023, April 2023 [YSS22] D. Yamamoto, Y. Suga, and K. Sako, “Formalising linked-data based verifiable credentials for selective disclosure,” in 2022 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW), 2022, pp. 52–65. [鈴木ら24] 鈴木 茂哉, 安田 クリスチーナ, 富士榮 尚寛, 阿部 涼介, "Decentralized Identifiers (DID) と Verifiable Credentials (VC) の現況", 電子情報通信学会 基礎・境界ソサイエティ Fundamentals Review, 2024, 18 巻, 1 号, p. 42-55, 2024/07/01
35. 参考資料: 標準仕様、技術レポート、他 34 [ETSI24] ETSI TR 119 476 V1.2.1, “Electronic Signatures and Trust Infrastructures (ESI); Analysis of selective disclosure and zero-knowledge proofs applied to Electronic Attestation of Attributes”, July 2024 [ISO19] ISO/IEC 24760-1:2019, IT Security and Privacy — A framework for identity management — Part 1: Terminology and concepts [KB25a] V. Kalos, G.M. Bernstein, “BBS per Verifier Linkability,” Internet-Draft, draft-irtf-cfrg-bbs-per-verifier-linkability- 01, March 2025 [KB25b] V. Kalos, G.M. Bernstein, “Blind BBS Signatures,” Internet-Draft, draft-irtf-cfrg-bbs-blind-signatures-01, March 2025 [LKY24] D. Longley, G. Kellogg, and D. Yamamoto, “RDF Dataset Canonicalization,” W3C Recommendation, May 2024, https://www.w3.org/TR/rdf-canon/ [Loo+25] T. Looker, V. Kalos, A. Whitehead, M. Lodder, “The BBS Signature Scheme,” Internet-Draft, draft-irtf-cfrg-bbs- signatures-08, March 2025 [eudi25a] eudi-doc-architecture-and-reference-framework, “Topic G: Zero-Knowledge Proof”, https://github.com/eu- digital-identity-wallet/eudi-doc-architecture-and-reference-framework/discussions/408 [山本21] 山本 暖, "フォーカス・リサーチ(1) Verifiable CredentialとBBS+署名", Internet Infrastructure Review (IIR) Vol.52, 2021/09/30