匿名憑証：図解入門（第 2 部）

本稿は、匿名クレデンシャル（匿名資格証明書）に関する連載記事の第 2 弾です。その第 1 部はこちらからご覧いただけます。

前回の投稿で、「匿名クレデンシャル」という概念をご紹介しました。これは、ユーザーがウェブサイトへの認証を実行しつつも、プライバシーを損なうことなく行うことを可能にする技術です。

念のため、匿名クレデンシャルシステムにはいくつかの関連当事者が関与します。発行体（Issuer）は資格証明書を配布し、リソース（Resources）とは複数のウェブサイトやその他サービス指します（一部のケースでは、これらの主体が同一人物であることもあります）。そして、多数の利用者（Users）が存在します。利用者は発行体からクレデンシャルを取得し、その際に発行体は通常、匿名性を伴わない方法でユーザーの身元を確認します。クレデンシャルを保持したユーザーは、いつでもリソース（例えばウェブサイト）へのアクセスを行うためにこのクレデンシャルを「提示」することができます。ここで重要なのは「提示（show）」というプロセスです：適切に実装された場合、どの関係者も（リソース側也罢発行体側が各自単独でや共同してであっても）、その特定の「提示」行為とユーザーに交付された特定のクレデンシャルの間にリンクをたてることができず、これが匿名性の源泉となります。

また、匿名クレデンシャルシステムにおいて有用であるいくつかの特徴についてもお触りしました：

• 最も重要な特徴の一つは、一つのクレデンシャルの有効性を制限する仕組みです。例えば、「提示できる回数を制限」することなどが挙げられます。これは、ハッカーや悪意のあるユーザーがクレデンシャルを盗み、多数のコピーを作成して「ボット」アカウントなどを運用するようなクレデンシャル複製攻撃を防ぐために必要です。匿名クレデンシャルシステムにおいて、クレデンシャルは元々特定のユーザーに追跡可能ではないため、単一の盗まれたクレデンシャルが無検知のまま無制限に複製されてしまう恐れがあり、極めて危険な脅威となります。前回の投稿では、この問題に対するいくつかの解決策を提示したばかりです。
• 次に、クレデンシャルをより表現力豊かにするための方法についても言及しました。例えば、運転免許証（匿名性を持たないクレデンシャル）は、年齢や扱える車両の種類、居住する州など多様な主張を示すことを可能にします。同様に、表現力豊かな匿名クレデンシャルを用いることで、ユーザーはこのデータに対して多種多様な主張を立証できますが、主張することのできる事実を超えて有用な情報を漏洩させることはありません。

前回の投稿は大局的な概要として意図されており、議論は主に理論的なレベルに留めておきました。しかし、当ブログは暗号化エンジニアリングをテーマにしたものです。つまり、今日は理論から離れ、実際の運用についてお話しします。具体的には、現実の世界で実際に採用されている 2 つのクレデンシャルシステムを解説します。最初のシステムは「Privacy Pass」であり、Cloudflare や Apple その他多くの企業によって広く採用されています。次に検討するのは、Google が標準化を進めている新しい匿名年齢認証のための提案です。

Privacy Pass

Privacy Pass は、世界で最も広く展開されている匿名クレデンシャルの規格です。

名前の呼び方は様々あれど、インターネット全体にわたって Privacy Pass が利用されており、特に大規模なテクノロジー企業によって採用されています。その中で最も有名なのは Cloudflare で、同社の研究者は、CAPTCHA やその他の嫌がらせ的な反悪用対策を回避する方法としてこの規格の策定に関与しました。しかし、同等のプロトコルは Apple（「Private Access Tokens」と名付けました）、Google（「Private State Tokens」と名付けました）、Brave ブラウザ、そしていくつかの他のプロジェクトでも展開されています。Privacy Pass はそれほどまでに普及しており、Microsoft の Edge ブラウザですらこれを採用しています。なお、Microsoft はプライバシーを重視するとは言えません。

Privacy Pass はいくぶんも予想されるように、大規模なクレデンシャルの導入としては驚くほどシンプルです。思い描けるほど単純に設計されています。プロトコルは古典的な使い捨て型の「リストバンド式」クレデンシャルを提供しており、これはクレデンシャルが単一のビットの情報——すなわち「私は資格証明書を保有している」ということを表します——を運ぶものです。使用される技術は非常にシンプルであり、1980 年代に書かれた学術論文を読んでいくつかの創造的なパフォーマンス向上の工夫を取り入れるだけで、Privacy Pass の本質を理解できるほどです。真に革新的なのは、実際に人々がこれを採用・利用している点にあります。

Privacy Pass は IETF RFC 9576、9577、9578 で標準化されています。これらの規格には多数の実装オプションがありますが、コアのプロトコルは本質的に、前回の投稿で触れた Chaum の原始的な「盲番号」クレデンシャルの完璧な実現です。ここでこのクレデンシャルがどのように動作するかを簡潔に振り返りましょう：

• 利用者が使い捨てのクレデンシャルを取得することを望む場合、まずトークンタイプ（tokentype）を選択し、またオプションとしてユーザーがトークンに含めることのできるメタデータ（MD）という文字列を選びます。
• 次に、利用者は世界で一意である（と願うだけの）長いランダムなシリアル番号（SN）を生成します。
• 最後に、利用者と発行体は blind signature プロトコルを実行し、(tokentype, SN, MD) を構成するメッセージに署名を取得します。この際、利用者は署名 sig を取得しますが、発行体はその署名や署名対象のメッセージについて何も知りません。

こうして得られる 4 要素組 (tokentype, MD, SN, sig) が結果としてのクレデンシャルです。これをリソースに「提示（show）」する手順は以下の通りです：

• 利用者は (tokentype, MD, SN, sig) をリソースへ送信します。
• リソースは tokentype が有効な Privacy Pass トークンの種類かを確認し、メタデータ MD が含まれるトークンを承諾するか否かを決定します（その詳細については直後に説明します）。
• 次に、リソースは発行体の検証キーを使用して署名 sig を検証し（tokentype フィールドがどのように検証すべきかを示します）、データベースを検索して SN が以前に使用されていないことを確認します。これらすべてのチェックが成功した場合、SN はデータベースに登録されます。

これをピクトグラムとして視覚化したものが次のようになります：

[画像：基本的な Privacy Pass のフロー図]

ここで自然に思いつく疑問は、メタデータ MD とは何を指しているのか、というものです。

このメタデータ文字列は、特定のアプリケーション（例えばウェブサイト）に対してクレデンシャルを「紐付ける」ために使用できる追加のデータ塊です。例えば、私が 2026 年 3 月 31 日の火曜日にニューヨーク・タイムズにアクセスすることを計画している場合、MD = "nyt.com || 2026-03-31" というメタデータ文字列を含むクレデンシャルを要求できます。このクレデンシャルを提示すると、ウェブサイトはこの文字列を検証し、サービスを提供するかどうかを決められます。

重要なのは、発行体がこのメタデータ文字列を見ることができない点です。これはユーザーが自由に選択できるものですが、一度選択すれば変更することができません。このアプローチにより、ウェブサイトはトークンの有用性を制限することができます——例えば、特定のウェブサイトにのみ限定されたか、または特定の期間に限定されたようなものです。

Privacy Pass におけるメタデータの主な用途は、「セッション固有のクレデンシャル」を実現することです。これは、利用者がウェブサイトを訪問する前にではなく、アクセスを開始した後に発行体からクレデンシャル（例：Cloudflare で保護されているウェブサイトの場合）を取得するという異なる発行フローです。このフローは以下の通り動作します：

• 利用者がリソースへのアクセスを開始すると、リソース側はセッション固有の「チャレンジ」（ランダムな文字列など）をその利用者に送信します。
• 次に、利用者は発行体にクレデンシャルを要求し、メタデータ MD を「チャレンジャージ」に設定します（リアルタイムで行います）。
• 利用者がリソースに対してクレデンシャルを提示すると、リソースはステップ (1) で選択したチャレンジと一致するかどうかを検証します。

これをピクトグラムとして視覚化したものが次のようになります：

[画像：セッション固有の Privacy Pass フロー図]

この複合プロトコルの利点は、各クレデンシャルが利用者が既に開始した特定のセッションにのみ使用でき、他の用途には使用できないという点です。例えば、ユーザーはクレデンシャルを保存しておいて来週の別の機会に使うことはできません。これは Cloudflare などのサイトの運営にとっては有益であり得る利点です：リアルタイムでアクセスするユーザー数を一定の限度内に制御したい場合に適しているためです。

しかし、このアプローチにもいくつかの欠点があります。

その一つは、リアルタイムでのクレデンシャル発行には発行体が常時稼働している必要がある点です。発行体がいなくなると、リソースへのアクセスが事実上不可能になり、利用者は新しいクレデンシャルを取得できないためです（対照的に、従来の発行フローでは、利用者は先にいくつかのクレデンシャルを入手しておき、後で使うこともできました）。もう一つの欠点は、リアルタイム発行プロトコルが原則としてタイミング相関攻撃を引き起こす可能性があります。つまり、リソースと発行体がそれぞれのメッセージを受信した時刻のタイムスタンプを比較した場合、ユーザーのセッションとクレデンシャル発行要求をリンクできてしまう可能性があります。

この最後の点については特に懸念されます：発行体とリソースの両方が同じ企業によって運用されている場合において深刻です。実際、Cloudflare の展開ではそのような状況にあります。幸運なことに、Cloudflare は秒間に実際に数億件もの取引を処理しており、その規模は巨大すぎてこのような相関攻撃を行うのは非常に困難でしょう（ sanity check として、Claude Code を使って素早く簡易な分析を行いました。結果は両論あり：こちらを参照してください）。

署名スキームとは何か、「トークンタイプ」は何を指すのかか

基本的なプロトコルフローについて記述した以上、Privacy Pass の説明における残る主な疑問は比較的シンプルなものです：盲番号是如何実装すればよいか、という点です。

Privacy Pass は、わずかに異なる暗号技術を使用する 2 つの標準化された「発行プロトコル」を定義しています。最初のものは、公開検証可能なトークンのための Privacy Pass のバリアントを説明します。これらは本質的に前回の投稿で触れた Chaumian クレデンシャルと同じものです：ここでは発行体は盲番号 RSA 署名を使用し、その手法は Chaum の 1980 年代の原始プロトコルとほぼ同一です。これらのトークンの利点は、リソース側が発行体の公開鍵を使ってトークンを検証できる点にあり、つまり発行体とリソースの間で秘密鍵材料を共有する必要がないことです。

RSA 盲番号署名の主な問題は、それらがサイズが大きく構築コストもやや高いことです。これは RSA が大規模な公開鍵を必要とするためであり、通常は対称暗号との同等性を約 112 ビットレベルに達させるために少なくとも 2048 ビット以上の鍵が必要となります。これにより署名自体が比較的大きくなり、署名処理もやや高コストとなります。

明らかな代替案としては楕円曲線（EC）primitive を使用すること——例えば Schnorr 署名や ECDSA—even などです。（後でポストア量子の代替案についても触れます。）このアプローチのもつまらない問題は、EC ベースの盲番号署名のツールの選択肢が限られていることです。要約すると：

• いくつかの古い「盲 Schnorr」プロトコルは、並行した発行を許可する場合（つまり攻撃者が多数の盲番号要求プロトコルを同時に実行できる場合）には著しく不安定であることが判明しました。これらの攻撃は悪質すぎて、合理的な計算機ハードウェア上で Schnorr 署名を偽造できてしまいます。
• これらのプロトコルを安全に動作させるには、一度に一つの署名セッションしか行わないようにする必要があります——つまり並行（同時）発行は不可能です。
• 最近のいくつかの論文はこの問題に対処しようとしましたが、結果としてのプロトコルは盲 RSA よりも遅くなります。

したがって、Privacy Pass は楕円曲線ベースの盲番号を一切サポートしていません。

代わりに、極めて高速な展開が必要な場合のために、Privacy Pass は二番目の発行プロトコル——つまり、私有検証可能なトークン用のものを定義しています。これらのトークンは、オブリビウス（不可知）擬似乱数関数を基にしたオブリビウスメッセージ認証コード（MAC）を使用します。私有検証可能トークンの利点は、EC ベースの primitive を使用しており、作成と検証が極めて高速である点にあります。デメリットは、検証者（この場合はリソース）が発行体の秘密鍵を所持しないとクレデンシャルを検証できない点です。

結論

Privacy Pass は、構築可能な匿名クレデンシャルプロトコルの中で最も驚くべきものが少ないものです。ユーザーにはシンプルで使い捨て型の「リストバンド式」クレデンシャルを提供し、極めて高速に動作するように最適化されています。プロトコルの背後にある基本的なアイデアはすべて 1980 年代に最終決定されましたが、現在は非常に迅速かつ実用的な何かに標準化されています。このプロトコルに関心を寄せる点はその技術そのものよりも、展開の規模にあります：Apple、Google、Cloudflare の間にいるユーザーたちは、毎日実際に数十億人が Privacy Pass を利用している——彼らがそれに気づいていなくても同様です。

同時に、Privacy Pass は非常に退屈な側面もあります。「トークンを取得して使用する」のみというリストバンド式クレデンシャルのモデルを提供しすぎず、年齢検証の問題に対する多くの有用な解決策を提供していない——私たちはウェブを毎回使うたびに発行体と継続的に通信しなければなりません。

次の投稿では、より強力な提案を議論します：Google の新しいゼロ知識クレデンシャルをサポートするための提案です。