個人データを保護するCloudflareの取り組み (ECH、OPAQUE、ODoH、KEMTLS)

TL;DR

「Schrems II」事件の判決により、個人データを保護を実施することが義務化

Cloudflareの取り組みとして以下を紹介

TLSをよりセキュアにするEncrypted Client Hello

パスワード認証用プロトコルOPAQUEの開発

DNSクエリをよりセキュアにするOblivious DNS-over-HTTPS

量子耐性のあるTLSに関するKEMTLSの実験

本文

2020年からCOVID-19によるインターネットへの常時接続が増加し、個人データに関する保護がより重要さを増している。データ保護法に関する活動も世界中で活発化しており、2020年7月EU司法裁判所が「Schrems II」事件に関して、プライバシー・シールドを無効とする判決を下した。プライバシー・シールドは2016年に米国とEUの間で締結された取り決めで、協定に参加する米国企業がEUのプライバシー原則を遵守する旨を米商務省に登録すればEU域外へ個人データを持ち出すことができるとしたもの。この判決によって、EU域内の個人データを米国のデータ処理者に持ち出す場合、プライバシー・シールドのみを根拠とすることはできず、GDPR同等のデータ保護手段（移転先と標準契約条項を締結する等）を確実に実施する義務が明確化された。

本ポストでは、このような情勢に対するCloudflareのプライバシー強化技術に関する取り組みとして、DNSクエリをよりセキュアにするEncrypted Client Hello (ECH)とOblivious DNS-over-HTTPS (ODoH) 、パスワード認証用プロトコルOPAQUEが紹介されている。

TLSの拡張仕様にServer Name Indication (SNI) があり、TLS handshake時にClientHelloにアクセスするホスト名を含めることで、アクセス先に応じて証明書を使い分けることを可能にする仕様だ。しかし、SNIを用いた検閲が発生したこともあり、SNIを暗号化するEncrypted SNIの導入が進められていた。ECHは暗号化範囲をSNIに限定せず、ClientHello全体を暗号化する取り組みだ。経路上の盗聴はEncrypted SNIによって軽減されてはいたたが、ClientHello全体を暗号化することでよりセキュアなTLSを実現する。Cloudflareでは標準化プロセスの取り組みを進めている。

OPAQUEは、パスワード違反の発生を少なくするパスワード認証用のプロトコルだ。パスワードについては、安全な保管の難しさや頻繁な漏洩が課題であり、ブルートフォース攻撃にも繋がっている。OPAQUEは非対称パスワード認証鍵交換プロトコルであり、サーバにソルトパスワードハッシュを保存する代わりに、ユーザのパスワードとランダムな秘密鍵（サーバのみが知る）によってロックされたユーザに紐付いたprivate envelopeを保存する。ここで秘密鍵はサーバのみが知っている。ログインに際しては、クライアントが暗号学的交換を開始し、envelope keyがクライアントのみに公開される（サーバは知らない）。サーバはこのenvelopeをクライアントに送信し、クライアントは暗号化されたkeyを取得する。このkeyがアンロックされ、AKEのパラメタとして利用され、将来の通信を暗号化する秘密鍵を確立する。すでにGoでのリファレンス実装とデモTLSの統合が行われており、近々TypeScriptの実装も公開されるそうだ。

DNSクエリには予想より多くの情報が含まれている。具体的には、送信元および送信先のアドレス、日時、ドメインとサブドメイン、誰かが特定のサイトに滞在した期間に関するタイムスタンプ情報が挙げられる。DNS-over-HTTPS (DoH) でもこの問題に対処していたが、Oblivious DoH (ODoH) ではIPアドレスに関するプライバシー保護を達成する。クライアントとリゾルバの間にプロキシを挟み、DNSクエリからIPアドレスを分離し、単一の主体が両方を同時に見ることができない設計だ。プロキシはDNSクエリの内容を把握できず、リゾルバはクライアントのIPアドレスを把握できない。運営主体を分離するためパートナーが必要であるが、すでに取り組みは開始されており、現状はPCCW、SURF、Equinixの名前が挙がっている。