ゼロ知識証明だけではユーザーのプライバシーを守れない理由

ゼロ知識証明は、プライバシーへの完全な答えとして語られることがあります。市民技術の文脈では、その約束はとくに魅力的です。人は、身分証明書の中身をすべて明かすことなく、参加資格があること、一意の人物であること、一定年齢以上であること、あるいは特定の地域の住民であることを証明できます。

この約束は本物です。ただし、聞こえ方よりも範囲は狭いです。

ゼロ知識証明が守るのは証明です。ユーザーのIPアドレス、ブラウザ指紋、電話番号、メールアドレス、ウォレット実装、デバイス、OS、そして証明の周囲で作られる多くのタイムスタンプや行動シグナルを自動的に守るわけではありません。周辺レイヤーが慎重に設計されていなければ、検証者は依然としてユーザーが誰なのかを知ることができます。

この記事は、2024年9月にNGI TrustChain向けに行ったプレゼンテーションをもとにしています。中心的な主張はシンプルです。ゼロ知識証明は、プライベートな市民参加のための重要な部品ですが、ユーザーのプライバシーはフルスタックの性質です。

なぜ市民プラットフォームにアイデンティティが入るのか

すべてのオンライン空間に本人確認が必要なわけではありません。純粋に仮名的なコミュニティには正当な用途があります。そこでは、正式な資格情報ではなく、継続的なハンドルネームと評判によって人々が参加します。

市民参加プラットフォームは別の問題に直面します。意味のある公共意見を集め、スパムに耐え、計算機的プロパガンダを減らし、一人一票に近いプロセスを支えるなら、何らかのシビル耐性が必要です。実際には、参加者が実在する人物であること、関連コミュニティに属していること、市民的な資格条件を満たすことを確認する必要があるかもしれません。

シビル耐性には複数の方法がありますが、それぞれトレードオフがあります。

生体認証は一意性を提供できますが、プライバシーと安全性に大きなリスクを生みます。
ソーシャルグラフ型の仕組みは一部の文脈で有用ですが、スケールしにくく、強いプライバシー保証を持たないことが多いです。
ハイブリッドなweb of trustは特定のコミュニティで機能し得ますが、通常は弱い一意性しか提供しません。
政府や機関の資格情報は強い保証を提供できますが、監視レイヤーになってはいけません。

ここで、自己主権型アイデンティティとゼロ知識証明が魅力的になります。必要以上の個人データを公開させずに、資格を確認する方法を示しているからです。

ゼロ知識証明が得意なこと

単純化した資格情報フローには3つの主体があります。

発行者は、ある人について何かを確認し、資格情報を発行します。
保有者は、その資格情報を保存し、いつ使うかを決めます。
検証者は、その資格情報から導かれた証明を確認します。

ゼロ知識技術により、保有者は基礎となる資格情報を明かさずに特定の主張を証明できます。たとえば、誕生日を明かさずに18歳以上であることを証明したり、資格情報の全内容を公開せずに信頼された発行者から資格情報を受け取ったことを証明したりできます。

このパターンを支える技術はいくつかあります。BBS+資格情報は選択的開示とリンク不能な証明を可能にします。別のアプローチでは、リンクされやすい資格情報形式をMerkle化し、ZK-SNARKsを使ってよりプライバシー保護的にします。汎用zkVMは、既存のセキュリティ重視の資格情報についての証明を将来的に容易にするかもしれません。

これらのツールが価値を持つのは、証明レベルで発行者リンク不能性を提供できるからです。つまり、発行者は資格情報がどこで使われたかを知るべきではなく、同じ資格情報の複数の利用が証明そのものによって簡単に結び付けられるべきではありません。

これは重要な問題を解決します。しかし、すべてのプライバシー問題を解決するわけではありません。

脅威モデル：保有者を最初に考える

市民参加では、プライバシーモデルは保有者の視点から始めるべきです。資格情報を使う本人が、何を誰に明かすかを制御し続けなければなりません。

そのためには、今日の多くのソーシャルプラットフォームより厳しい脅威モデルが必要です。

検証者、つまり証明を要求するプラットフォームは、盲目的に信頼されるべきではありません。システムがそれを困難かつ監査可能にしない限り、検証者はユーザーの再識別を試みる可能性があります。
発行者は保有者を識別し有効な資格情報を発行するためには信頼されますが、その資格情報が後にどこで、いつ、なぜ使われたかを知るためには信頼されるべきではありません。
発行者と検証者が共謀して、証明提示からユーザーを識別できてはいけません。
プロプライエタリなクライアントコード、ウォレットコード、検証者フロントエンドは、オープンソースで検査可能、理想的には監査済みでない限り、リスク面として扱うべきです。

これは、プラットフォームが個人データを責任を持って扱うと信頼する既存のソーシャルメディアモデルとは大きく異なります。オンラインプラットフォームの歴史は、その信頼を疑う理由を十分に示しています。

プライバシーという氷山の残り

最も簡単な誤りは、ゼロ知識証明をプライバシーシステム全体とみなすことです。実際には、証明は一つのレイヤーにすぎません。

過剰開示

証明がゼロ知識で生成されても、検証者は細かすぎる、多すぎる、または珍しすぎる属性を要求できます。ユーザーが完全な身分証を見せていなくても、属性の組み合わせだけで識別されることがあります。

たとえば、小さなコミュニティでは、正確な年齢、都市、職業、会員資格を同時に証明するだけで個人を特定できるかもしれません。プライバシー保護システムは、粗い述語と最小限の開示を優先すべきです。

ネットワークメタデータ

検証者は、IPアドレス、ブラウザ指紋、デバイスメタデータ、リクエスト時刻から、証明とユーザーを結び付けようとすることができます。識別的なログインやメール確認と同じブラウザセッションから証明が送られるなら、証明の数学的プライバシーは意味を失うかもしれません。

ゼロ知識はネットワーク層をデフォルトで隠しません。通信のプライバシー、プロキシ、ログ方針、セッション分離が重要です。

Cookieとデータブローカー

サードパーティCookie、分析スクリプト、広告ID、購入データはすべて、証明のプライバシーを損ないます。検証者が証明フローの周囲にトラッキングコードを埋め込めば、匿名証明を既知のWebアイデンティティと相関させられるかもしれません。

市民プラットフォームでは、証明フローからサードパーティトラッカーを完全に排除すべきです。周囲のWebページが通常のWebインフラで身元を漏らしているなら、暗号プロトコルだけにプライバシーを任せることはできません。

メール、電話番号、アカウント復旧

メールアドレスと電話番号は便利ですが、強力な識別子でもあります。検証者がそれらをゼロ知識証明と関連付けると、証明はより広いアイデンティティプロファイルの一部になり得ます。

これは、市民プラットフォームがメールや電話を決して使えないという意味ではありません。可能な限り証明イベントから隔離し、必要なときだけ使い、明確な保持ポリシーで管理すべきだという意味です。

永続識別子

同じ永続識別子が証明の周囲に現れるなら、ゼロ知識証明でもリンクされる可能性があります。ウォレットアドレス、DID、資格情報主体ID、デバイスID、安定したアカウントIDはいずれも相関の取っ手になります。

仮名性が必要なシステムでは、普遍的識別子ではなく、文脈ごとまたは相手ごとの識別子を使うべきです。ユーザーが関係のない市民空間の間で同じ痕跡を持ち歩くべきではありません。

時刻による相関

識別子が隠れていても、時刻は関係を明かします。検証者は、証明が生成された瞬間を、ログイン、通知クリック、ページ読み込みなど別のリクエストと相関させることができます。

設計者はタイムスタンプを敏感な情報として扱うべきです。バッチ処理、遅延送信、ログ最小化、認証と証明提示の分離は、相関リスクを下げます。

ウォレット、デバイス、サプライチェーン

証明が暗号学的に正しくても、ウォレットやクライアントが機密データを漏らすことがあります。プロプライエタリなウォレットはテレメトリを送るかもしれません。侵害されたSDKは属性を漏らすかもしれません。悪意あるフロントエンドは、ユーザーが理解している以上の情報を要求するかもしれません。

オープンソースはこれらのリスクを魔法のように消しませんが、クローズドソースは検査をはるかに難しくします。信頼が重要な市民システムでは、オープンソースクライアント、再現可能ビルド、独立監査、最小限のテレメトリを中核インフラとして扱うべきです。

行動推論

機械学習は、単体では無害に見えるパターンから身元を推測できます。文章スタイル、活動時間、デバイス動作、位置パターン、インタラクション履歴は、匿名集合を小さくします。

これも、プライバシーを証明だけに還元できない理由です。匿名参加には、不要な行動プロファイルを作らないためのプロダクト、モデレーション、データ保持の選択も必要です。

信頼できる匿名証明のためのよりよいアーキテクチャ

プライバシーを守る資格情報フローは、検証者が知るべきでないことまで知ろうとする、という前提で設計すべきです。

少なくとも、ゼロ知識証明を使う市民プラットフォームは次の原則を検討すべきです。

市民要件を満たす最も粗い証明だけを要求する。
証明提示を識別的なアカウントフローと組み合わせない。
本当に必要な場合を除き、電話番号、メール、ウォレットアドレス、永続DIDを証明イベントに結び付けない。
サードパーティCookie、分析、トラッカーを証明フローから排除する。
IPアドレス、タイムスタンプ、リクエストメタデータを中心にログを最小化する。
継続的な参加が必要な場合は、文脈固有の仮名を使う。
検証者フロントエンド、証明要求ロジック、ウォレット統合、SDKをオープンソースかつ監査可能にする。
ユーザーが、何を証明し何を明かしていないかを理解できる証明要求にする。
発行者が資格情報の利用場所を知ることができるコールバックなどの仕組みを防ぐ。

目標は匿名証明だけではありません。目標は信頼できる匿名性です。ユーザー、監査者、市民社会が、プラットフォームのプライバシー主張と実際の動作が一致しているかを確認できるシステムです。

未解決の課題

まだ難しい仕事が残っています。

第一に、ユーザー体験は十分ではありません。多くの人は、資格情報スキーマ、選択的開示、証明要求、発行者リンク不能性、相関攻撃を理解できません。安全なプロダクトは、ユーザーに暗号学者になることを求めずに、プライバシー特性を説明しなければなりません。

第二に、資格情報エコシステムは断片化しています。BBS+、SD-JWT、モバイル運転免許、パスポートチップ、Merkle化資格情報、zkVMベースの証明はそれぞれ異なるトレードオフを持ちます。市民プラットフォームには相互運用性が必要ですが、最もプライバシーの弱い共通分母に落ち込んではいけません。

第三に、シビル耐性とプライバシーには緊張があります。強い一意性はしばしば強い身元証明を要求します。課題は、必要なことだけを確認し、その確認が汎用的なアイデンティティグラフにならないようにすることです。

第四に、悪用防止は監視を再生産してはいけません。匿名または仮名の空間にも、モデレーション、レート制限、責任メカニズムが必要です。ただし、それらは全員を静かに再識別しないように設計されるべきです。

最後に、オープンソースは必要ですが十分ではありません。公開コードは役立ちますが、再現可能ビルド、独立監査、明確なガバナンス、そして検査したコードが実際に使われているコードであるというデプロイ時の保証も必要です。

結論

ゼロ知識証明は強力です。基礎データを明かさずに事実を証明でき、発行者が資格情報の利用場所を追跡することを防げます。

しかし、証明はプライバシーシステム全体ではありません。検証者は、属性、メタデータ、Cookie、メール、電話番号、永続識別子、時刻、ウォレット、デバイス、行動パターンといった周辺レイヤーを攻撃できます。

市民技術では、この区別が重要です。デジタルアイデンティティが公共参加の一部になるなら、それが市民を監視する別の方法になってはいけません。ゼロ知識証明は答えの一部になり得ますが、それはデータ最小化、リンク不能性、オープンソース監査可能性、ユーザー制御を備えたより広いアーキテクチャの中に置かれる場合だけです。

実践的な教訓は明確です。ゼロ知識を使う。ただし、そこで止まらないことです。