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

[AI-2] ゼロ知識証明とその応用 (4) 分散型アイデンティティにおける応用 山本 暖 (株式会社インターネットイニシアティブ) 2025年3月28日 / IEICE 2025年総合大会 企画セッション

目次 n分散型アイデンティティとは n分散型アイデンティティとゼロ知識証明 n実用化に向けた課題 1

分散型アイデンティティとは

アイデンティティとは ISO/IEC 24760-1:2019 [ISO19] によると: 実体に関する属性の集合 (a set of attributes related to an entity) 実体 (人、組織、もの) 属性の集合 マイナンバー: メールアドレス: 氏名: 住所: 勤務先: 所属部署: 資格: 123456789012 [email protected] 山本 暖 神奈川県横浜市 IIJ (2021-) セキュリティ本部 英検3級 [ISO19] ISO/IEC 24760-1:2019, IT Security and Privacy — A framework for identity management — Part 1: Terminology and concepts 3

アイデンティティの証明は一人では難しい ユーザ番号 0001です パスワードは abc です おかえりなさい ユーザ0001さん ユーザ パス 番号 ワード 0001 abc … … 山本といいます IIJで働いています 英検3級です 本当か? 一度知りあった相手に 「私はあなたの知っている◯◯だ」 と証明すること(当人認証) は自分だけでも可能だが… アイデンティティ(属性の集合)の 証明は自分一人では難しい → 信頼された第三者が必要 4

第三者によるアイデンティティの保証 第三者に直接保証してもらう 彼は山本さんです IIJで働いています あなたが言うなら 信じよう アイデンティティ連携 第三者の発行書類で保証してもらう 社員証を発行 この社員証の持ち主は 山本さんです IIJで働いています 社員証が 確からしいので 信じよう デジタル証明書 分散型アイデンティティはこちら 5

アイデンティティ連携 IdP (Identity Provider) OpenID Connect, SAML ü ユーザはブラウザだけあれば使える (秘密鍵や証明書の管理は不要) 彼は山本さんです メールアドレスは [email protected] です RP (Relying Party) ユーザ ü RPに提示される内容はユーザがIdP上でコ ントロールできる (メールアドレスは出すが氏 名は隠す、など) ü 産学官民、個人法人問わず広く普及 (例: Google, Apple, Microsoft, LINE, Yahoo! Japan, デジ庁認証アプリ, GBizID, 学認) û IdPには高可用性(24/365等)が要求される û ユーザのRPへのアクセス状況が逐一IdPに 把握される Googleが言うなら 信じよう û ユーザ、IdP、RPは互いに通信可能でないと いけない (オンライン利用が前提) 6

PKI, Verifiable Credentials, ISO mDL, SD-JWT デジタル証明書 署名付きの 証明書を発行 Issuer ü Issuerは証明書発行時だけ稼働していれば 良い (24/365不要) ü Issuer-Verifier間の通信は不要 (オフライン 利用が可能) ユーザ (Holder) この証明書の持ち主は 山本さんです IIJで働いています Verifier 証明書が 確からしいので 信じよう ü ユーザのVerifierへのアクセス状況が Issuerに把握されにくい ü IdPやIssuerへの過度な信用・依存を減ら せる û サービス提供者だけでなく、ユーザ側にも鍵 や証明書を安全に保持・運用する仕組みが 必要 (例: ICカードやデジタルIDウォレット) û 従来型デジタル証明書は ユーザのプライバシに課題あり (後述) 7

従来型デジタル証明書の発行 Issuer 署名前の証明書 発行者 有効期間 ユーザ公開鍵 氏名 部署 IIJ ～2026/3 fed987… 山本 暖 セキュリティ ユーザ Issuerの署名鍵 標準的署名 (ECDSA等) 証明書 発行者 有効期間 ユーザ公開鍵 氏名 部署 デジタル署名 IIJ ～2026/3 fed987… 山本 暖 セキュリティ 345def… 8

従来型デジタル証明書の検証 ユーザ Verifier Verifier Verifier 証明書 発行者 有効期間 ユーザ公開鍵 氏名 部署 デジタル署名 IIJ ～2026/3 fed987… 山本 暖 セキュリティ 345def… 発行者 有効期間 ユーザ公開鍵 氏名 部署 デジタル署名 IIJ ～2026/3 fed987… 山本 暖 セキュリティ 345def… Issuerの公開鍵 標準的 署名検証 (ECDSA等) ✔ 成功 ü デジタル署名が付くので改ざん困難 û ユーザ固有の情報がふんだんに含まれる (ユーザ公開鍵、デジタル署名) → Verifier 間でユーザの行動を容易にリンクできる 9

従来型デジタル証明書の検証 ユーザ Verifier Verifier Verifier 証明書 発行者 有効期間 ユーザ公開鍵 氏名 部署 デジタル署名 IIJ ～2026/3 fed987… 山本 暖 セキュリティ 345def… 発行者 有効期間 ユーザ公開鍵 氏名 部署 デジタル署名 アイデンティティ連携(OIDC等)では IdPがユーザの希望に沿って 情報の開示/非開示をしてくれていた (IdPを信用する限り) IIJ ～2026/3 セキュリティ Issuerの公開鍵 標準的 署名検証 (ECDSA等) ✘ 失敗 û 見せたくない固有情報を隠すと 署名検証に失敗してしまう (改ざんと区別できない) 10

分散型アイデンティティ: 新しいデジタル証明書 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年春に提供予定 11

新しい証明書の特徴(1): 選択的開示 Issuer 発行時の証明書 発行者 有効期間 ユーザ公開鍵 氏名 部署 デジタル署名 IIJ ～2026/3 fed987… 山本 暖 セキュリティ 345def... ü 選択的開示可能 特殊な署名方式を 使うことで、属性を一部 隠したままでも検証可能 Verifier 1 ユーザ Verifier 2 発行者 有効期間 ユーザ公開鍵 氏名 部署 デジタル署名 IIJ ～2026/3 fed987… セキュリティ 345def... 発行者 有効期間 ユーザ公開鍵 氏名 部署 デジタル署名 IIJ ～2026/3 fed987… 山本 暖 345def... 12

Issuer (CA) 課題: ユーザ公開鍵や署名を見れば、Verifier-Verifier間、 新しい証明書の特徴(1): 選択的開示 Verifier-Issuer間でユーザ属性の復元が可能 発行時の証明書 発行者 有効期間 ユーザ公開鍵 氏名 部署 デジタル署名 IIJ ～2026/3 fed987… 山本 暖 セキュリティ 345def... ü 選択的開示可能 特殊な署名方式を 使うことで、属性を一部 隠したままでも検証可能 Verifier 1 ユーザ Verifier 2 発行者 有効期間 ユーザ公開鍵 氏名 部署 デジタル署名 IIJ ～2026/3 fed987… セキュリティ 345def... 発行者 有効期間 ユーザ公開鍵 氏名 部署 デジタル署名 IIJ ～2026/3 fed987… 山本 暖 345def... 13

新しい証明書の特徴(2): リンク不可能 Issuer 発行時の証明書 発行者 有効期間 ユーザ公開鍵 氏名 部署 デジタル署名 IIJ ～2026/3 fed987… 山本 暖 セキュリティ 345def... ü 選択的開示可能 特殊な署名方式を 使うことで、属性を一部 隠したままでも検証可能 ü リンク不可能 公開鍵や署名を隠した ままでも検証可能 Verifier 1 ユーザ Verifier 2 発行者 有効期間 ユーザ公開鍵 氏名 部署 デジタル署名 IIJ ～2026/3 セキュリティ 発行者 有効期間 ユーザ公開鍵 氏名 部署 デジタル署名 IIJ ～2026/3 山本 暖 14

デジタル証明書の作り方 アプローチ 偽造 不可能 (a) デジタル署名のみ ✔ (b) デジタル署名 ＋ ソルト付き属性 ハッシュ (c) デジタル署名 ＋ ゼロ知識証明 ✔ ✔ 選択的 開示 リンク 不可能 ✔ ✔ ✔ 実装 容易 例 ★★★ PKI X.509 (成熟) ★★ ISO mDL (標準化済) SD-JWT (標準化中) ★ VC-DI-BBS(標準化中) JWP-BBS (標準化中) AnonCreds (OSS) Google案 (研究段階) ※アプローチと例は主要なもののみ記載 15

分散型アイデンティティとゼロ知識証明

ゼロ知識証明を使ったデジタル証明書 アプローチ (c) デジタル署名 ＋ ゼロ知識証明 偽造 不可能 選択的 開示 ✔ ✔ リンク 不可能 ✔ 実装 容易 例 ★ VC-DI-BBS(標準化中) JWP-BBS (標準化中) AnonCreds (OSS) Google案 (研究段階) (c1) 効率的プロトコル付きデジタル署名 (BBS署名, CL署名, PS署名) ＋ 用途特化型ゼロ知識証明 (Σプロトコル) (c2) 標準的デジタル署名 (ECDSA署名, RSA署名) ＋ 汎用的ゼロ知識証明 (zk-SNARKs) (c3) 耐量子 計算機 構成 VC-DI-BBS, JWP-BBS, AnonCreds Google案 [FS24] (本日は割愛) 17

ゼロ知識証明を使ったデジタル証明書 (c1) 効率的プロトコル付きデジタル署名 (BBS署名, PS署名, CL署名) ＋ 用途特化型ゼロ知識証明 (Σプロトコル) 18

(c1) 効率的プロトコル付きデジタル署名 ＋ 用途特化型ゼロ知識証明 (c1) 証明書発行 Issuer ユーザ 署名前の証明書 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 fed987… 氏名 山本 暖 部署 セキュリティ Issuerの署名鍵 効率的 プロトコル付き 署名 (BBS署名等) メッセージの配列に対して 署名 証明書 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 fed987… 氏名 山本 暖 部署 セキュリティ デジタル署名 987cba… 署名のサイズは変わらない 19

(c1) 証明書提示準備 (c1) 効率的プロトコル付きデジタル署名 ＋ 用途特化型ゼロ知識証明 ユーザ 証明書 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 fed987… 氏名 山本 暖 部署 セキュリティ デジタル署名 987cba… 一部秘匿した証明書 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 氏名 部署 セキュリティ デジタル署名 用途特化型ゼロ知識証明 (Σプロトコル+FS変換) 「効率的プロトコル付き署名の検証に通るような メッセージ列と署名値を知っている」 ことのゼロ知識証明 Verifierへ提示する証明書 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 氏名 部署 セキュリティ ゼロ知識証明 f1e2d3… 効率的プロトコル付き署名 を使ったおかげでこうしたゼロ知識 証明を効率よく(数msで)生成可能 (標準的な署名ではこうはいかない) 20

(c1) 効率的プロトコル付きデジタル署名 ＋ 用途特化型ゼロ知識証明 (c1) 証明書提示/検証 ユーザ Verifier Issuerの公開鍵 提示する証明書 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 氏名 部署 セキュリティ ゼロ知識証明 f1e2d3… 用途特化型 ゼロ知識証明 の検証 (Σプロトコル +FS変換) ✔ 成功 「効率的プロトコル付き署名の検証に通るような メッセージ列と署名値を知っている」 効率的プロトコル付き署名 ことの確認 を使ったおかげでこうしたゼロ知識 証明を効率よく(数msで)検証可能 (標準的な署名ではこうはいかない) 21

(c1) まとめ (特にBBS署名を使った場合) (c1) 効率的プロトコル付きデジタル署名 ＋ 用途特化型ゼロ知識証明 ü 署名生成、提示、検証がいずれも高速 (数ms) ü Issuerの公開鍵がメッセージ数(証明書内の属性の数)によらず固定 (96B) ü 署名サイズは 112B, 証明サイズは (368+32𝑛)B (𝑛: 非開示メッセージ数) û 「ペアリング演算」が可能な特殊な楕円曲線 (例: BLS12-381曲線) が必要 → 現在のスマートフォンの Secure Element ではサポートされていない。 結果、ユーザの秘密鍵管理にハードウェアデバイスを利用できない 基本方式は約20年前から存在。 安全性解析も十分に行われており、 IETF/W3C/ISOでの標準化も進行中。 ハードウェアサポートさえ解決できれば 最適な選択肢と思われる。 著名な暗号学者らも推奨 → 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” 22

(c2) 標準的デジタル署名 ＋ 汎用ゼロ知識証明 (c2) 証明書発行 Issuer ユーザ 署名前の証明書 発行者 有効期間 ユーザ公開鍵 氏名 部署 IIJ ～2026/3 fed987… 山本 暖 セキュリティ Issuerの署名鍵 標準的署名 (ECDSA等) 証明書 発行者 有効期間 ユーザ公開鍵 氏名 部署 デジタル署名 IIJ ～2026/3 fed987… 山本 暖 セキュリティ 345def… Issuerは既存のインフラをそのまま利用できる 23

(c2) 証明書提示準備 (c2) 標準的デジタル署名 ＋ 汎用ゼロ知識証明 ユーザ 証明書 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 fed987… 氏名 山本 暖 部署 セキュリティ デジタル署名 987cba… 一部秘匿した証明書 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 氏名 部署 セキュリティ デジタル署名 汎用ゼロ知識証明 (zk-SNARK) 「標準的署名(例: ECDSA+SHA256) の検証に通るよう なメッセージ列と署名値を知っている」 ことのゼロ知識証明 Verifierへ提示する証明書 発行者 IIJ 有効期間 ～2026/3 ユーザ公開鍵 氏名 部署 セキュリティ ゼロ知識証明 f1e2d3… 愚直に作ると生成に1分以上かかる が、各種テクニックを駆使すること で数十〜数百msまで高速化。 ペアリングも不要 [FS24] 24

(c2) まとめ (c2) 標準的デジタル署名 ＋ 汎用ゼロ知識証明 ü 署名生成、提示、検証がいずれも実用に耐える速度 ü Issuerの公開鍵がメッセージ数(証明書の種類)に依存しない ü 「ペアリング演算」が不要で、標準的な楕円曲線 (例: P-256曲線) で十分 → 現在のスマートフォンの Secure Element で使える û ユーザとVerifierで共有するパラメータが証明書の構造に依存 (証明書の構造/種類ごとにパラメータの生成と共有が必要) → [Google24] では ISO mDL に限定して性能を出しているが、 証明書の構造/種類により多様性が求められる場合は未知数 û 標準化活動はまだこれから 25

実用化に向けた課題

実データとBBS署名の入力とのギャップ
{
"credentialSubject": {
"name": "Dan Yamamoto"
"worksFor": {
"name": "IIJ"
}
}

W3C Verifiable Credentials
データモデルに則った
デジタル証明書の例(一部)
[JSON-LDデータ]

}

?
𝑚!
𝑚"

9139018...
9139018...

𝑚#
𝑚&

7975413...
1106247...
BBS署名

𝑚$
𝑚%

1672531200
4937101...

効率的プロトコル付き署名
(BBS署名)が期待する入力
[BLS12-381曲線における
スカラーの配列]

...
27

ギャップを埋めるためのデータ変換処理
RDF Dataset Canonicalization
(直列化と正規化)

JSON-LDデータ
{
"credentialSubject": {
"name": "Dan Yamamoto"
"worksFor": {
"name": "IIJ"
}
}
}

_:c14n0
_:c14n1
_:c14n1
_:c14n2

Canonical N-Quadsデータ
credentialSubject _:c14n1
name
"Dan Yamamoto"
worksFor
_:c14n2
name
"IIJ"
分割

BBS入力用のスカラー配列

バイト配列

𝑚!

𝑚#

𝑚$

_:c14n0

credentialSubject

_:c14n1

𝑚"

𝑚&

𝑚%

_:c14n1

name

"Dan Yamamoto"

𝑚'

𝑚)

𝑚*

_:c14n1

worksFor

_:c14n2

𝑚!(

𝑚!!

𝑚!#

_:c14n2

name

"IIJ"

Hash-to-Field
[RFC9380]

28

早稲田大学 佐古研究室との共同研究

W3C勧告化に貢献 [LKY24]

RDF Dataset Canonicalization
(直列化と正規化)

JSON-LDデータ
Canonical N-Quadsデータ
{
"credentialSubject": {
_:c14n0
credentialSubject _:c14n1
"name": "Dan Yamamoto"
_:c14n1
name
"Dan Yamamoto"
"worksFor": {
_:c14n1
worksFor
_:c14n2
"name": "IIJ"
_:c14n2
name
"IIJ"
}
}
データ変換も考慮に入れた
分割
}
安全性分析 [YSS22]
BBS入力用のスカラー配列
バイト配列
𝑚$
𝑚!
𝑚#
_:c14n0
credentialSubject _:c14n1
𝑚"

𝑚&

𝑚%

_:c14n1

name

"Dan Yamamoto"

𝑚'

𝑚)

𝑚*

_:c14n1

worksFor

_:c14n2

𝑚!(

𝑚!!

𝑚!#

_:c14n2

name

"IIJ"

Hash-to-Field
[RFC9380]

29

プロトタイプ実装 デモ https://playground.zkp-ld.org/ アプリ zkp-ld-playground (online demo) JSON-LD 処理 jsonld-proofs TS/Rust ブリッジ rdf-proofs-wasm RDF処理 rdf-proofs 暗号処理 docknetwork/crypto オープンソース https://github.com/zkp-ld/ web-wallet (not published yet) rdf-canon 30

• https://github.com/zkp-ld/
• https://playground.zkp-ld.org/

その他の技術的課題 n 正規化を使わないデータ変換 (JSON Web Proof向け) n 仮名 (同じコンテキスト・ドメイン内ではユーザを一意に特定) n 鍵管理ハードウェアデバイスとの処理分担 n 発行者情報の秘匿 (Issuer-Hiding Credentials) n ユーザプライバシを保護したまま証明書の失効を確認 n 述語証明 (生年月日を隠したまま成人であることを示す、等) n 量子計算機への耐性 n… 31

社会実装に向けて: 分野横断的な議論の重要性 OpenID, SAML, OAuth Verifiable Credentials 分散型識別子(DID) アイデン ティティ 匿名化/仮名化 差分プライバシ 証明書運用 トラスト管理 デジタル署名 ゼロ知識証明 耐量子計算機暗号 PKI 暗号 プライバシ その他 ブロックチェーン セマンティックWeb 32

参考資料: 論文 [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 33

• https://github.com/user-attachments/files/15904122/cryptographers-feedback.pdf
• https://www.jstage.jst.go.jp/article/essfr/18/1/18_42/_article/-char/ja

参考資料: 標準仕様、技術レポート、他 [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-linkability01, 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-bbssignatures-08, March 2025 [eudi25a] eudi-doc-architecture-and-reference-framework, “Topic G: Zero-Knowledge Proof”, https://github.com/eudigital-identity-wallet/eudi-doc-architecture-and-reference-framework/discussions/408 [山本21] 山本 暖, "フォーカス・リサーチ(1) Verifiable CredentialとBBS+署名", Internet Infrastructure Review (IIR) Vol.52, 2021/09/30 34

• https://www.w3.org/TR/rdf-canon/
• https://www.iij.ad.jp/dev/report/iir/052/02.html