Cloudflareでは、すべてのインターネットユーザーに便益をもたらす新しいプライバシー保護テクノロジーをサポート・開発する事業に取り組んでいます。2017年11月に当社は学術界との共同研究により開発されたプライバシーパスプロトコルのサーバー側サポートを発表いたしました。プライバシーパスとは、要約すると、その信用が供与された場所と時期を明らかにすることなく、クライアントが自らの信用証明を提供することを可能にする技術のことです。そのプロトコルの目的は、あるユーザーがあるサーバーによって信用が付与されていることを任意の人に証明することにあります。その際、任意の人がその割り当てられた信用情報を経由して当該サーバーから当該ユーザーを追跡することができないことが要件となります。

技術的には、プライバシーパスクライアントはサーバーから将来に引き換え可能な認証トークンを受け取ります。このトークンは、サーバーがクライアントを信用できると判断した場合に提供されます。たとえば、ユーザーがサービスにログインしたときや、固有の特性を証明したときなどです。この引換トークンは、サーバーが最初に提供した認証を暗号技術を使用してリンク不能にするため、クライアントに関する情報は一切晒されることはありません。

プライバシーパスを使用するために、クライアントはChromeまたはFirefoxからオープンソースブラウザー拡張機能をインストールする必要があります。プライバシーパスの個別ダウンロード件数は現在世界中で150,000件を超えています。Chromeからは約130,000件、Firefoxからは20,000件超です。この拡張機能はCloudflareによってサポートされており、ウェブサイトへのアクセスをより容易にしています。このことは、Torブラウザーのユーザーのアクセシビリティを向上させるために開発されたCloudflareオニオンサービスの投入などを含めたCloudflareが従前から行っているサービスを補完しています。

最初のリリースは2年近く前です。そしてそれは2018年度プライバシー強化技術シンポジウム(最優秀学生論文賞を受賞)で発表された研究出版により継承されています。以来、Cloudflareはより広範なコミュニティと協働し、初期設計の構築およびプライバシーパスの改善に携わってきました。それではこれよりプロトコル自体の内容はもとより、既に実装済み案件の開発にあたり当社が行ってきた実務作業について説明していきます。

拡張機能v2.0

リリース以来当社は多くの新機能追加に取り組んで参りました。本日は、初期リリース以降初となる拡張機能バージョン2.0のアップデ―トサポートを発表できることを誠にうれしく思います。引き続き、この拡張機能はChromeおよびFirefoxで使用可能です。ブラウザーが自動更新を無効にしている場合、ウェブストアからv2.0をマニュアルでダウンロードする必要があります。

依然としてこの拡張機能は活発に開発中であるため、当社はこれを未だにベータ段階としてサポートを提供しております。またさらに、プロトコルのドラフト仕様が広範なコミュニティとの共同作業で作成されている限り、当社はこれを引き続きベータ段階として取り扱います。

新たな統合

クライアント実装では、WebRequest APIを使用し、特定の種類のHTTP要求を検索します。この要求が認められると、プライバシーパスプロトコルが要求する一定の暗号化データを含むように書き換えられます。これにより、このデータを受け取ったプライバシーパスプロバイダーは、当該ユーザーのアクセスを承認することが可能となります。

たとえば、ユーザーはある一定のサーバーセキュリティチェックを通過するためにプライバシーパストークンを受け取ることがあります。このトークンはブラウザー拡張機能により格納されます。そして、将来同様のセキュリティクリアランスが必要となる要求が発生したとき、その要求テキスト上に格納されているトークンが追加HTTPヘッダーとして追加記載されます。その後、サーバーはクライアントトークンを検証し、クライアントがこれを実行するための真正な権限を有していることを承認します。

Cloudflareは特定の種類の要求フローをサポートしていますが、異なるサービスプロバイダーが完全に合致するインタラクション特性に準拠することはおそらく不可能でしょう。拡張版v2.0の主要変更点の 1 つは、中央コンフィグレーションファイルを使用することなく、技術的書き換えで対処することです。拡張機能のソースコードでコンフィグレーションが規定されているため、プライバシーパスアクションを開始する際に要求されるブラウジング特性の変更をより簡易にすることが可能となります。これにより、新規プロバイダー用にこのコンフィグレーションを単に複製して適用することで、まったく異なる新しい要求フローを追加することが可能になりました。

Cloudflare以外の他のサービスとの間でこのような統合が可能となったことは、CAPTCHAプロバイダーのhCaptchaによってサポートされるまったく新しいバージョンの拡張機能が間もなく展開されることで明らかになることでしょう。hCaptchaが要求する一時的な課題に対処する際、ユーザーは、他のhCaptchaの顧客サイトで引き換え可能なプライバシー保護トークンを受けとり、それに対処することが可能になります。

“「hCaptchaはユーザーのプライバシーに焦点を当てます。そして、プライバシーパスをサポートすることは当社事業領域の自然な延長線上にあります。当社はCloudflareおよびその他のベンダーとの協働により、これを一般的で広範な業界標準にすることを目標に掲げております。また、当社では現在別のアプリケーション開発にも注力しているところです。グローバルに展開しているサービスにプライバシーパスを実装することは比較的直接的で実直な試みです。当社はCloudflareチームとの充実した協働により、オープンソースのChromeブラウザー拡張機能を改善し、当社のユーザー向けに最高のエクスペリエンスを提供することが可能となりました。」 - エリ＝シャドゥル・ケドゥリ、hCaptcha 創設者”

— Eli-Shaoul Khedouri, founder of hCaptcha

プライバシーパスブラウザー拡張機能をめぐるこのhCaptcha統合の事例は、新規サービスのサポートを確立する際の概念実証事例と言えるでしょう。新規参入のプロバイダーがプライバシーパスブラウザー拡張機能との統合をしたいときも、単にオープンソースリポジトリにPRを実行することで実現できます。

向上した暗号化機能

拡張版v1.0がリリースされたとき、その時点では実装されていない機能がありました。サーバーが常に同じコミットされたキーを使用していることを検証するために使用する、適切なゼロ知識証明の検証機能もその一つでした。v2.0ではこの機能が完成しました。これにより、悪意のあるサーバーが要求ごとに異なるキーを使用してユーザーを非匿名化しようと試みるとき、確実な防護が可能となりました。

プライバシーパスに要求される暗号化操作は、楕円曲線暗号化（ECC）を使用して実行します。現在この拡張機能にはNIST P-256曲線が使用されています。同拡張機能には当社が一定の最適化プログラムを挿入しています。その一つ目として当社は、楕円曲線点を圧縮データ形式および非圧縮データ形式で格納することを可能にしました。これによりブラウザーのストレージを50%削減でき、また、サーバーの応答容量も縮小することができます。

二つ目は、現在進行中の「楕円曲線のハッシュ化のエンコード標準化」ドラフト（https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-03）で指定された「Simplified Shallue-van de Woestijne-Ulas」（SSWU）方式を使用して、P-256曲線へのハッシュサポートを追加いたしました。この実装にあたっては、同ドラフトが指定する「P256-SHA256-SSWU-」暗号スイート仕様に準拠しております。

これらの変更には二重の利点があり、まずP-256 hash-to-curve仕様のドラフト仕様書の準拠を確実にしていることです。もう一つは、この暗号スイートを使用することでhash-and-incrementなどの確率的方法を使用する必要性を排除できることです。hash-and-increment方式には無視できないほどの失敗の可能性があり、また、実行時間の長短は隠れたクライアント入力に大きく依存することになります。現時点ではタイミング攻撃ベクトルを悪用する方法は明らかではありませんが、SSWU 方式を使用することにより、実装の攻撃可能性とクライアント入力情報の漏洩リスクを軽減することが期待できます。

キーのローテーション

前述のように、サーバーが常に同じキーを使用していることを確認するのは、クライアントのプライバシーを保護する上で重要です。これでサーバーは、インターアクトするクライアントごとに各々異なるシークレットキーを使用することになり、したがいユーザーベースを分離することができず、また、ユーザーのプライバシー漏洩リスクを軽減することが可能になります。サーバーは、クライアントがアクセスできる場所にパブリックキーのコミットメントを告知することで、常に同じキーを使用していることを保証します。

また、サーバーがクライアントにプライバシーパストークンを発行するたびに、正しいキーを使用してトークンを作成したことを証明するゼロ知識証明を発行します。

拡張機能では、トークンを格納する前に、まず、それが認識しているコミットメントに対する証明を検証します。以前は、このコミットメントは拡張機能のソースコードに直接格納されていました。つまり、サーバーがキーをローテーションする際に常に拡張機能の新しいバージョンをリリースすることが必要となり、それは運用を不必要に困難にしていました。拡張機能にはコミットメントが信頼できる場所に格納できるように変更が加えられました。その場所はクライアントがサーバーの応答を確認する必要があるときにアクセス可能な場所です。現在この場所は、分離されたプライバシーパスGitHubリポジトリです。興味のある方のために、新しいコミットメントフォーマットに係る詳細説明を記載した付録Aをこの記事の末尾に添付いたしました。

Workersのサーバー側サポートの実装

ここまでは、クライアント側のアップデートについて焦点を当て、説明いたしました。拡張機能v2.0 のサポートの一環として、Cloudflareが使用するサーバー側のサポートに関し、いくつかの大きな変更を展開しています。バージョン1.0では、サーバーサポートにGo実装を使用しました。v2.0 では、Cloudflare Workersプラットフォームで実行することが可能な新たなサーバー実装を採用します。このサーバーの実装は、プライバシーパスのv2.0リリースとのみ互換性があるため、ブラウザーで自動更新をオフにしている場合は、拡張機能の更新を手動で行う必要があります。

当社のサーバーはhttps://privacypass.cloudflare.comで実行されます。そして、Cloudflareエッジに送信されるすべてのプライバシーパス要求は、このドメインで実行されるWorkerスクリプトによって処理されます。当社の実装はJavascriptを使用して書き換えられます。その際、Cloudflare Workersの動力源であるV8エンジン上で暗号化操作が実行されます。つまり、高度に効率的で定数時間性に優れた暗号化操作を実行することができます。またさらに、コードをWorkersプラットフォームで実行することで得られる高度化されたパフォーマンスをユーザーに最大限近接した場所で発揮するメリットを活かしています。

WebCryptoのサポート

おそらく、最初にCloudflare Workersがどのようにして暗号化操作を実装するのかという疑問を持つ人がいることでしょう。現状では、暗号化操作実行のサポートはWebCrypto APIを介してWorkersプラットフォームで提供されています。このAPIを使用することで、ユーザーはECDSAシグネチャーなどのより複雑な操作と平行して、暗号化ハッシュなどの機能を処理することができます。

その詳細はこの後すぐに説明いたしますが、プライバシーパスプロトコルでは、主要な暗号化操作はverifiable oblivious pseudorandom function（VOPRF）として知られる検証可能な擬似ランダム関数によって実行されます。このプロトコルを使用することで、クライアントは、実際の入力内容をサーバーに晒すことなく、サーバーが処理した関数出力を取得することが可能となります。「検証可能」とは、サーバーがユーザーに提出する評価が真正であることを（公的に検証可能な方法で）証明する必要があることを意味します。このような関数は疑似ランダムです。その理由はサーバー出力がランダムなバイトシーケンスと区別がつかないからです。

VOPRF機能はその要件として、サーバーが未だ現時点ではWebCrypto API が明確に規定していない低レベルのECC操作を実行することを要求しています。当社はこれに対し、可能な限りこの要件を回避できる方法で対処しました。まず、試験的にWebCrypto APIを標準外の手法で使用することを試みました。このとき、必要となるスカラー乗算を実行する方法としてEC Diffie-Hellmanキー交換を使用しました。また、すべての操作に純粋JavaScriptを使用することを試みました。残念ながら、どちらの方法もそれが大規模な外部暗号化ライブラリとの統合を試行していることを意味している点、あるいは高いパフォーマンスのインターネット設定で使用するには遅延が大きすぎるという点から不適切でした。

最終的に当社は、Cloudflare V8 Javascriptエンジンの内部WebCryptoインターフェイスにプライバシーパスに要求される機能を付加するというソリューションに到達しました。このアルゴリズムは、ECDSAなどのシグネチャーアルゴリズムが提供するsign/verifyインターフェースを模倣しています。要約すると、sign() 関数を使用して、クライアントにプライバシーパストークンを発行します。verify()は、クライアントが引き換えたデータをサーバーが検証する際に使用することが可能です。これらの関数はV8層に直接実装されるため、純粋なJS代替関数に比較し、はるかにパフォーマンスとセキュリティに優れます（たとえば、定数時間で実行されます）。

このプライバシーパス WebCryptoインターフェイスは、現在一般に公開していません。もし、Workers プラットフォームでこの追加アルゴリズムを使用することに十分な関心が向けられたら、当社はこれを公開することを検討いたします。

アプリケーション

近年、VOWFは多くの暗号化ツールを確立する際に非常に有用な基礎として認知されています。プライバシーパスとは別に、たとえばOPAQUEなどのパスワードで認証されたキー交換プロトコルを構築する際にも不可欠です。また、プライベートセットインターセクション、パスワード保護されたシークレット共有プロトコル、並びにプライベートデータストレージ用のプライバシー保護アクセス制御の設計にも使用されています。

パブリック引換API

Cloudflare Workersでサーバーを作成するということはつまり、当社がパブリックドメインでプライバシーパスのサーバー側サポートを提供することを意味します。当社はトークンを信頼できるクライアントに発行するのみですが、その後、任意の第三者は誰でも、https://privacypass.cloudflare.com/api/redeemで当社のパブリック引換 API を使用してトークンを引き換えることができます。当社は世界中でサーバー側コンポーネントを展開しているので、世界中の誰しもがこのAPIとインターアクトし、ブラウザー拡張機能に依存せずCloudflareプライバシーパストークンを検証することが可能です。

つまり、すべてのサービスプロバイダーは、Cloudflareがクライアントに発行したプライバシーパストークンを受け入れ、そしてそれをCloudflare引換API経由で検証することが可能です。外部サービスプロバイダーは、APIによって提供された結果を使用し、 Cloudflareが過去にそのユーザーを承認したかどうかを確認することができます。

このことにより他のサービスプロバイダーにメリットが生じます。つまり、彼らはCloudflareからの承認の証明を、クライアントのプライバシーを犠牲にすることなく、独自の意思決定プロセスに利用できるようになります。私たちはこのエコシステムがさらに成長し、できる限り多くのサービスが独自のパブリック引換APIを提供することを切に願います。より多様な発行者群が出現することで、この証明メカニズムはより有益なものとなることでしょう。

パブリックドメインで当社サーバーを稼働することはすなわち、当社は事実上のCloudflare Workers製品の顧客として位置付けられます。つまり、当社もまたWorkers KVを活用することで悪意のあるクライアントから当社を防御することができるわけです。特に、サーバーは、クライアントが引き換え段階にトークンを再利用していないことを確認する必要があります。読み取りデータ分析で発揮されるこの Workers KVの能力は、グローバルな二重支払いリスクを回避するための有効な選択肢となるでしょう。

パブリック引換 API の使用をご検討する際には https://privacypass.github.io/api-redeemから使用方法手引き書をご参照ください。また、当記事の末尾に付録B「要求と応答の事例」を添付いたしました。

標準化と新しいアプリケーション

現在当社はプライバシーパスのサポートに係る最近のエンジニアリング活動と並行して、より広範なコミュニティと協働し、基礎となるVOPRF機能とプロトコル自体の両方の標準化に取り組んでいます。oblivious pseudorandom functions (OPRFs) の標準化プロセスは既に1年以上にわたって実行されていますが、一方でプライバシーパスプロトコルを標準化する取り組みは、ほんの数か月前の非常に最近のアプリケーションによって推進されているのが現状です。

プロトコルと機能を標準化することは、インターネット上でプロトコルを実行するために欠かすことのできない相互運用性、セキュリティ、高いパフォーマンスを提供する上で重要な要素です。標準化により、開発者はこの複雑な機能を独自仕様の実装としてより簡易に記述することが可能となります。また、このプロセスは、コミュニティ専門家からの有用なピアレビューが反映され、すべての実装において極力軽減すべき潜在的セキュリティリスクをより適切に表面化することが可能となります。その他の利点として、すべてのアプリケーション開発において、最も信頼性が高くスケーラブルで高パフォーマンスのプロトコル設計に関するコンセンサスが形成されるということが挙げられます。

Oblivious pseudorandom functions

Oblivious pseudorandom functions（OPRFs）とは、サーバーが機能を正しく評価したことを証明することを要求しないVOPRFsの一般化のことです。当社は2019年7月より、Internet Research Task Force（IRTF）のCrypto Forum Research Group（CFRG）と協働し、prime-order groupsで動作するOPRFプロトコル標準化のためのドラフト作成に取り組んでいます。これは楕円曲線によって提供される設定の一般化です。これはプライバシーパスプロトコルによって最初に指定されていたものとまったく同じVOPRF構造であり、それはまた、Jarecki氏、 Kiayias氏、Krawczyk氏らが提出した元のプロトコル設計仕様書に大部分準拠しています。

このドラフトに最近加えた変更の 1 つは、サーバー側でOPRF操作を実行することになると想定されるキーのサイズを増やしたことです。既存の調査結果によると、特定のクエリを作成し、少量のキーを漏洩させることが可能であることが報告されています。128ビットのセキュリティのみを提供するキーの場合、このことは問題となる可能性があります。漏洩ビット数があまりにも多いとき、現在容認されているレベルを逸脱してセキュリティが低下する可能性があるからです。これに対処するために当社は最小キーサイズを192ビットに増やしました。これにより、いかなる実用的な方法を使用しても、この漏洩が攻撃対象とならないように防御できます。この攻撃に関しては、後ほどVOPRF開発の将来計画について説明する際に、さらにその詳細を議論する予定です。

最近のアプリケーションとプロトコルの標準化

最初にプライバシーパスをサポートしたときに示したアプリケーションは、常にプロトコルの概念実証として意図されたものでした。この数ヶ月間に、これまで想定されていた範囲をはるかに超える領域で、多くの新たな可能性が生じています。

たとえば、ウェブインキュベーターコミュニティグループによって開発された信用トークンAPIは、プライバシーパスを使用するためのインターフェイスとして提案されています。このアプリケーションは、ユーザーが一連の中央発行者から信用証明を受け取っているかどうかをサードパーティベンダーが確認することを可能にします。これにより、ベンダーは、ユーザーのIDに付随したユーザープロファイルを照会することなく、ユーザーの真正さに関する判断を行うことが可能となります。その目的は、中央発行者が信用を供与しないユーザーを特定し、その人が不正行為を働くことを事前に防御することにあります。中央発行者に対し信用の証明を確認する行為は、当社が導入した引換APIに類似の方法を使用することで代替が可能です。

Facebookが行っている別の手法が不正行為を防御する類似のアプリケーションを詳述しています。また、この手法はプライバシーパスプロトコルとの互換性もあります。最後に、プライベートストレージへのアクセスを提供するという新領域向けに別のアプリケーションが登場しています。これは広告確認という領域におけるセキュリティとプライバシーモデルの確立を志向しています。

新しいドラフト

上記のアプリケーションを念頭に置いて、当社は最近新しいIETFドラフトに係る共同作業を開始いたしました。その仕様書には、プライバシーパスプロトコル技術が全体として提供する機能が明確に規定されています。当社の目的は、より広範な産業パートナーや学術コミュニティと共に、プライバシーパスプロトコルの機能仕様を開発することにあります。当社はこれを遂行することにより、何らかの簡易型の承認を必要とする広範なアプリケーションに対し、暗号化プリミティブとして使用可能なベースレイヤプロトコルを設計することを企図しています。当社の計画では、来月シンガポールで開催されるIETF 106会議で、このドラフトの最初のバージョンを発表する予定です。

このドラフトは未だ開発の初期段階にあります。当社ではプロトコル仕様の策定に関心のある人材を積極的に募集しております。このプロセスに対するご支援ご鞭撻のほど、よろしくお願い申し上げます。ドキュメントの最新バージョンは、GitHubリポジトリをご参照ください。

未来の道程

最後に、当社は現在さまざまな経路から積極的に挑んでいるところですが、このプロジェクトの未来の方向性は依然として未知数です。当社が未だに考えもつかない多くのアプリケーションが、世界のいたるところに存在していると信じています。だからこそ当社はこのプロトコルが将来どこでどのように使用されるかをこの目で確かめる日が来ることを、心から楽しみにしています。ここでは当社が考える将来的に追求する価値があると思われる、新しいアプリケーションやセキュリティプロパティに関するアイデアをいくつかご紹介いたします。

パブリックに検証可能なトークン

VOPRFを使用する際の欠点の1つは、引換トークンが発行元サーバーによってのみ検証可能であることです。仮に引換トークンのパブリック検証を可能にする基礎的プリミティブを使用したならば、誰もが発行元サーバーが特定のトークンを発行したという事実を確認することができるようになります。このようなプロトコルは、Blind RSAなどの、いわゆるブラインドシグネチャスキームの上に構築することが可能になります。残念ながら、現在のブラウザー環境下でブラインドシグネチャースキームを使用することには、パフォーマンスとセキュリティ上の懸念が存在しています。既存のスキーム（特にRSAベースのバリアント）を使用した場合、VOPRF プロトコルで使用された構造と比較すると、それははるかに重厚な暗号化計算が要求されることになります。

ポストクォンタムVOPRFの代替

現在のVOPRFの構造は、唯一プリクォンタム設定によります。それは、通常不連続ログ仮定などのグループ設定における既知の問題の難解度に基づいています。VOPRF構造では量子計算アルゴリズムを実行できる敵対者に対して、セキュリティで保護することが不可能であると一般に知られています。つまり、プライバシーパスプロトコルのみが、従来のハードウェア上で実行されている敵対者の攻撃に対して、セキュリティで保護できると考えられています。

最近の動向は、量子コンピューティングが以前考えられていたよりも早く実現できることを示唆しています。そのような状況下で、当社は現在の暗号ツールキットに実用的なポストクォンタム代替を構築する可能性を調査することは、当社自身並びにより広範なコミュニティにとって非常に重要な課題であると考えています。つまり、VOPRF構築に向けた高パフォーマンスのポストクォンタム代替を考案することは重要な理論的進歩に相当します。つまり、最終的に、ポストクォンタムが実現した世界においても、プライバシーパスプロトコル技術が引き続きプライバシー保護承認サービスを牽引していることでしょう。

VOPRFセキュリティとより大規模なの暗号スイート

前述のとおり、VOPRF（または単にOPRF）は、キー内での少量のデータ漏洩に対し脆弱であることに言及いたしました。ここでは、実際の攻撃の実態について簡単に説明し、データ漏洩を軽減するためのより高いセキュリティ暗号スイートを実装する計画についてその詳細を説明して参ります。

具体的に言うと、悪意のあるクライアントはVOPRFとインターアクトし、q-Strong-Diffie-Hellman（q-sDH）サンプルと呼ばれるものを作成します。このサンプルは、数学的グループ（通常は楕円曲線設定）で作成されます。どのグループにも、すべてのDiffie-Hellmanタイプオペレーションの中央にパブリックエレメント g と、これとともに、通常同グループからランダムに生成された番号として翻訳されるサーバーキー K が存在します。q-sDH サンプルのフォームは次のとおりです。

( g, g^K, g^(K^2), … , g^(K^q) )

そして、悪意のある敵対者に対し、(g^(1/(s+K)),s)を満足する要素ペアを作成するように要求します。VOPRF プロトコルのクライアントは、以前の VOPRF 評価結果を単にサーバーに提出するだけで q-SDH サンプルを作成することができます。

この問題は解決が困難であると考えられていますが、過去の事例の中には、多くのグループの指摘に対抗し、同問題は解決が容易であるとしています(例えば、こことここを参照してください)。具体的に言うと、同グループが示めしたビットセキュリティは、最大log2(q) bitsまで減らすことが可能です。これは128ビットセキュリティのみを提供するグループに対してさえも即刻致命的となるわけではありませんが、それのもかかわらず、それはセキュリティの損壊にほかならず、もはや将来性はありません。結果として、P-256やCurve25519などの楕円曲線を使用してインスタンス化されたVOPRF機能を提供するすべてのグループは、推奨保証値よりも低いセキュリティを提供していることになります。

このことを念頭に置いて当社は最近次のような決定を下しました。つまり、当社は、標準として＞128 ビットのセキュリティを提供するOPRFの使用を推奨し、これを提供する暗号スイートのみをアップグレードの対象とするというものです。たとえば、Curve448は192ビットセキュリティを提供します。セキュリティを128ビット未満に抑える攻撃を開始するためには、2^(68) クライアントOPRFクエリを実行する必要があります。このことはすべての攻撃者にとって重要な障壁となります。したがい当社はOPRF機能をインスタンス化する際にこの暗号スイートを使用することは安全であると判断いたしました。

近い将来、プライバシーパスブラウザー拡張機能のサポート下で使用されている暗号スイートは、現在のVOPRFドラフトが推奨する仕様に沿ってアップグレードすることが要求されることになります。一般的に、リリースプロセスの頻度は高まり、またそれは標準化プロセスの最中に進化していくことが見込まれるため、当社としては、プライバシーパスの実装は常に最新のドラフト標準に準拠することを目指したいと考えています。

連絡を取り合いましょう。

Chrome またはFirefoxにプライバシーパス拡張機能v2.0 がインストールできるようになりました。

この拡張機能の開発に貢献を希望する人は、GitHubから実行することができます。あなたは拡張機能のサーバー側サポートを統合するサービスプロバイダーですか？そうであれば、是非あなたのご意見をお聞かせください。

当社は常にプロトコルの標準化開発に向けより広範なコミュニティとの協働を模索し続けます。既に開発済の利用可能なアプリケーションに接することで当社のモチベーションは向上します。当社は常に現状の境界を打破し、プライバシーパスエコシステムの発展に寄与する新しいアプリケーションとの連携を模索しています。

付録

ここでは上記で取り上げたトピックに関連する追加情報を記述しています。

A.キーローテーションのコミットメントフォーマット

サーバーがプライバシーパスプロトコルの最中に真正に動作していることを証明するためには、キーコミットメントが必要となります。プライバシーパスがv2.0リリースで使用しているコミットメントフォーマットは、以前のリリースのものとは若干異なります。

"2.00": {
  "H": "BPivZ+bqrAZzBHZtROY72/E4UGVKAanNoHL1Oteg25oTPRUkrYeVcYGfkOr425NzWOTLRfmB8cgnlUfAeN2Ikmg=",
  "expiry": "2020-01-11T10:29:10.658286752Z",
  "sig": "MEUCIQDu9xeF1q89bQuIMtGm0g8KS2srOPv+4hHjMWNVzJ92kAIgYrDKNkg3GRs9Jq5bkE/4mM7/QZInAVvwmIyg6lQZGE0="
}

まず、サーバーキーのバージョンは2.00です。サーバーは発行されたトークンが含まれたクライアントへの応答の中で、使用するバージョン情報をクライアントに通知する必要があります。これは、サーバーが送信するゼロ知識証明を検証する際に、クライアントが常に正しいコミットメントを使用できるようにするためです。

メンバー H の値は、サーバーが使用する秘密キーに対応するパブリックキーコミットメントに相当します。これは、H=kG フォームの base64 エンコード楕円曲線ポイントです。このとき、G は曲線の固定ジェネレーター、k はサーバーの秘密キーに相当します。離散対数問題の解決は困難だと言われる理由は、Hからkを導出することが困難だからです。メンバー有効期限の値は、使用されているコミットメントの有効期限に相当します。メンバー sig の値は、サーバーに関連付けられた長期署名キーを使用して評価されたECDSAシグネチャに相当します。そしてそれは、Hと有効期限の値を超過した値です。

クライアントがコミットメントを取得するとき、サーバーは有効期限が切れていないことを確認します。そして、これに対応した拡張機能のコンフィグレーションに埋め込まれている検証キーを使用して、シグネチャーが検証を実行します。これらの確認が承認されると、Hを取得し、サーバーが送信した発行応答を検証します。以前のバージョンではこのコミットメントにはシグネチャーは含まれていませんでしたが、このシグネチャーは v2.0 以降は有効化されます。

サーバーがキーローテーションを実行するとき、サーバーは単に新しいキーk2を生成し、2.01などの新しい識別子を使用してk2に新しいコミットメントとして追加します。その後、k2はVOPRF操作のシークレットキーとしてを使用され、必要とする計算が実行されます。

B.引換 API 要求の事例

引換APIは、HTTPS経由で実行されます。そのときPOSTはhttps://privacypass.cloudflare.com/api/redeemに送信されます。このエンドポイントへの要求では、要求の本文に JSON-RPC 2.0 シンタックスを使用してプライバシーパスデータを指定する必要があります。要求の事例を見てみましょう。

{
  "jsonrpc": "2.0",
  "method": "redeem",
  "params": {
    "data": [
      "lB2ZEtHOK/2auhOySKoxqiHWXYaFlAIbuoHQnlFz57A=",
      "EoSetsN0eVt6ztbLcqp4Gt634aV73SDPzezpku6ky5w=",
      "eyJjdXJ2ZSI6InAyNTYiLCJoYXNoIjoic2hhMjU2IiwibWV0aG9kIjoic3d1In0="
    ],
    "bindings": [
      "string1",
      "string2"
    ],
    "compressed":"false"
  },
  "id": 1
}

上記の捕捉説明: params.data[0]は、発行段階でトークンを生成するために使用されるクライアント入力データです。params.data[1]は、サーバーが引換を検証するために使用する HMAC タグです。params.data[2] は、クライアントが使用するhash-to-curveのパラメータを指定する、文字列化されたbase64エンコードJSONオブジェクトです。たとえば、配列の最後の要素はオブジェクトに対応します。

{
    curve: "p256",
    hash: "sha256",
    method: "swu",
}

これはクライアントがcurve P-256を使用したことを示しています。このとき、ハッシュ関数はSHA-256であり、SSWU方式はhash to curveを使用しています。これにより、サーバーが真正な暗号スイートを使用し、トランザクションを検証をすることが可能とないります。クライアントは引換要求を一定の固定情報とバインドする必要があります。そこではparams.bindings配列に複数の文字列として格納されます。たとえば、HTTP要求のHostヘッダーと使用されたHTTPパス（これはプライバシーパスブラウザー拡張機能で使用されたもの）を送信することができます。最後に、params.compressedはオプションのブール値（デフォルトは false）です。その値はHMACタグが圧縮あるいは非圧縮ポイントエンコーディングのどちらで計算されたかを示します。

現在サポートされている暗号スイートは上記の事例のみです。または、hash-and-increment方式のインクリメントに等しい方式を除き、hashing to curveと同様の方式もサポートされています。これはプライバシーパスの v1.0で使用された元の方式です。またそれは、後方互換性のためだけにサポートされています。詳細については提供済ドキュメントをご参照ください。

応答の事例

要求が引換 API に送信され、正常に検証された場合、次の応答が返されます。

{
  "jsonrpc": "2.0",
  "result": "success",
  "id": 1
}

エラーが発生すると、次に類似するメッセージが返されます。

{
  "jsonrpc": "2.0",
  "error": {
    "message": <error-message>,
    "code": <error-code>,
  },
  "id": 1
}

ここで提供されているエラーコードはJSON-RPC 2.0コードを使用して指定されています。ここでは当社がAPI ドキュメントで使用しているエラータイプをドキュメント化しております。

Cloudflare ブログ

プライバシーパスプロトコル最新バージョンのサポート

最新のニュース