デプロイメントモデル

このページでは、Privacy Pass のデプロイメントの構造を説明します。4 つのロールを誰が運用するか、詳細なデプロイメントモデルの例、顧客のニーズごとにどのモデルが合うか、ほかの製品の一部としての Privacy Pass です。

Privacy Pass トークンは、ブラインド署名と大きな匿名集合によって暗号的な保護を提供します。それでも、プライバシー保証を満たすには、ロールを十分に分離して割り当てる必要があります。一般的な Cloudflare のデプロイメントは、次のように構成します。

最も重要なのは、Client に関する情報を分割し、単一のロールがすべてを知らないようにすることです。これを非連結性（unlinkability）とも呼びます。デプロイメントモデルによって、誰が何を知るかは変わりますが、非連結性は、Client が誰であるかと、どこへ向かっているかの両方を誰も知らないことを保証します。一般に、情報は次のように分かれます。

• Attester — Client が誰であるかと、attestation 段階で共有された識別可能な情報は知りますが、Origin の身元は知りません。
• Issuer — Client が attestation 済みであり、署名済みトークンを受け取る資格があることだけを知ります。（これはデプロイメントによります。Attester と Issuer が同一の主体である場合、Issuer は身元情報を知る可能性がありますが、Origin の身元は隠れたままです。）
• Origin — Client が検証済みであることだけを知ります。

Privacy Pass が提供する、トークン発行と redemption の間の非連結性は、ロールの分離に一部だけ依存することに注意してください。意味のあるプライバシーを提供するには、匿名集合、つまり同じデプロイメント構成に属する Client のグループも大きく保つ必要があります。Client ごとに異なる構成が見える要因は、グループを小さく分割し、匿名性を縮小します。

詳細は、Privacy Pass RFC の ガイドライン ↗ を参照してください。

主な構造上の選択は、Attester、Issuer、Origin の運用主体が重なるか、完全に分けるかを決めることです。完全に分けたモデルが最も安全ですが、ユースケースによっては特定の主体を兼務する利点もあります。ほかに可能なモデルとして、Attester と Issuer の兼務、Issuer と Origin の兼務があります。追加のガイドライン ↗ に従う限り、プライバシー保証は壊れません。

Apple が作成した PAT ↗ は、Safari および参加アプリとサードパーティブラウザー上の iOS 16 以降のユーザーについて、CAPTCHA チャレンジをほぼ完全に回避するためのものです。このデプロイメントでは、Apple はハードウェアプロバイダーとしての立場を活かし、CAPTCHA ではなく、有効な Apple ID やデバイス整合性チェックなどのシグナルでデバイスの正当性を attestation します。ロールの分離は次のとおりです。

このデプロイメントは 完全分離 モデルです。すべてのロールを、共謀しない主体が運用します。Apple にとっては、ハードウェア / インフラストラクチャプロバイダーとしての仕事が Attester ロールに自然に合うため、分離モデルが理想的です。一方、Origin として運用する顧客にとっては、このモデルは使いづらいことがあります。Attester として第三者を入れるか、3 つのロールがすべて運用されるように Cloudflare と顧客の間でロールをまとめる必要があるためです。

アプリケーション開発者は、サービスの利用者がサブスクライバーであることや一定の年齢を超えていることを確認したい一方で、その情報をアカウントと並べて永続保存したくない場合があります。そのようなユースケースでは、ロールの分離は次のようになります。

このデプロイメントは Attester と Issuer の兼務モデル です。Cloudflare が Issuer と Attester の両方を運用します。顧客が Origin として動作する場合、一般に Attester も運用すべきではありません。Origin と Attester を兼ねると、ユーザーの身元と宛先の両方を知る主体になり、プライバシーの保証が大幅に難しくなります。Issuer と兼務して Cloudflare が運用すれば、まったく新しい第三者を導入せずに済みます。必須ではありません。ロールが逆で、顧客が ID 権限者（例: エンタープライズ IdP / SSO プロバイダー）であり、自社の Origin 向けに非公開の検証を提供したい場合にも、Attester と Issuer の兼務モデルは有用です。

Privacy Pass は、既存の Cloudflare 製品も支えています。最も確立した例は Privacy Proxy です。シングルホップ（Microsoft Edge Secure Network ↗）とダブルホップ（Apple Private Relay ↗）のデプロイメントで使われ、Privacy Pass はクライアントとプロキシ（ダブルホップでは最初のプロキシ）の間の初期認証を担当します。ユースケースが既存製品に合う場合、それが最も簡単な道です。プロキシレベルの構成は、Privacy Proxy のデプロイメントモデル を参照してください。

• Privacy Pass Protocol
• Production Deployment Testing — これらのモデルの 1 つを Cloudflare と一緒にデプロイしたときの様子です。
• Replace CAPTCHAs with Private Access Tokens (Apple WWDC22) ↗ — Apple の Private Access Token デプロイメントの概要です。