TLS 1.3を使用したコミットとゼロ知識証明：DiStefanoプロトコル

Q: 私たちのプロトコルに興味がありますか?

もし私たちのプロトコルを試してみたい場合、私たちはC++で _DiStefano_ の[完全なプロトタイプ](https://github.com/brave-experiments/distefano)を実装しています。 BoringSSL上で直接構築されているので、Chromiumベースのブラウザで簡単に統合できます。 実際私たちの今後の研究の1つは、この実装をBraveブラウザに直接統合することで、このプロトコルを活用してユーザビリティを低下させることなく、詐欺行為の検出（ボットの検出など）や人間性の証明を行えるようにすることです。

今回の記事では、Sebastian Angel (University of Pennsylvania)、Sofía Celi (Brave)、Alex Davidson (NOVA LINCS & DI, FCT, Universidade NOVA de Lisboa)、Hamed Haddadi (Brave Software & Imperial College London)、Shai Levin (University of Auckland)、Elizabeth Margolin (University of Pennsylvania)、Gonçalo Pestana (Hashmatter)、Joe Rowell (Royal Holloway, University of London)、Jess Woods (University of Pennsylvania)による共同研究を紹介します。この投稿は、Braveのセキュリティ・リサーチャー、Sofía Celiによって書かれた記事の日本語訳です。

DiStefanoは、特定のあるもの(外部認証用TLSデータ)を別の場所で使用することからDECOと同じようにアルゼンチン人でありながらプロ生活のほとんどをスペインで過ごしたサッカー選手 DiStefanoにちなんで名付けられました。 (画像は一部AIが生成したもの)

トランスポート・レイヤー・プロトコル(Transport Layer Protocol/TLS)は、インターネット上で最も普及しているデータを安全に転送するためのプロトコルの1つです。このプロトコル（特にバージョン1.3）は、インターネット上のクライアントとサーバの間に 暗号化 と認証が行われたチャンネルを提供し、広範に使用されていることにより、転送中のデータが安全でプライベートであることが保証されます。このようなチャンネルは一般的に、年齢確認、社会保障ステータス、銀行口座情報、購入情報のようなクライアントの背景となるユーザーに関する信用に値する情報を送信します。

様々なアプリケーションがこのようなデータポイントから学習することは有益ではありますが、重大なプライバシーの懸念が生じます。そのような情報は暗号化され、認証されたチャネルを介して送信されるため、プライベートで匿名のクレデンシャルとしてエクスポートすることは困難です。一方、法令（GDPRなど）や標準化団体（W3Cなど）の両方が、プライバシーを保護するデータクレデンシャルの使用を優先事項としています。したがって、ユーザーが自分のデータの一部を選択でき、かつ同意したうえでエクスポートできる方法を開発することが重要です。これによりプライバシーを損なうことなく、特定のステートメントを証明したり、データが特定のWebサイトなどの信頼できるソースから発信されたものであることを認証したりできるようになります。

問題を説明するために、アリスがあるサービスに対して自分が18歳以上であることを証明するケースを考えてみます（Webサイトはそのような証明を要求することがあります）。現在、ほとんどの年齢確認サービスでは、利用者は広範な個人情報を含む身分証明書をアップロードする必要があり、プライバシーに関する重大な懸念があります。アリスが身分証明書を共有しないことを選択した場合、年齢条件を満たしているにもかかわらず、サービスへのアクセスが拒否されることもあります。一方、会社の給与システムや陸運局のポータルサイトなど、多くのWebサイトでは、すでに確認済みの生年月日を保存し、提供しています。理論的には、アリスはこれらのサイトの一つから生年月日のスクリーンショットを共有することができますが、このアプローチには大きな欠点が2つあります。一つはスクリーンショットは簡単に偽造できること。もう一つは何らかの方法でそのデータが正しいものであると保証されたとしても、単に18歳以上であることを証明するだけでなく、アリスの正確な生年月日など必要以上の情報を明らかにしてしまうことです。この状況は、データが正しいものであることを証明する（偽造されていないことを保証する）ことと、追加的な詳細を開示することなくデータに関する特定の記述（例えば、アリスが18歳以上であること）を証明すること、という2つの目的を達成するメカニズムの必要性を浮き彫りにしています。このようなソリューションは、信憑性の証明とステートメントの証明の両方を可能にし、ユーザーがプライバシーを損なうことなくサービスにアクセスし、信頼を確保することを可能にします。このようなタイプの証明は、例えば不正防止チェックに活用できます。（詳細については後述します）。

このBlog記事では、TLSを活用して信憑性の証明とステートメントの証明の両方を作成し、この問題の解決策を探ります。このアプローチでは、ユーザーは自分のデータについてゼロ知識証明を合意に基づいて作成することができるようになり、プライバシーを守りながら様々なサービスに安全にアクセスできるようになります。

DCTLSプロトコル

指定コミットメントTLS(Designated-Commitment TLS/DCTLS) プロトコルは、スリーパーティハンドシェイク(hree-party handshake/3PH)プロトコルまたはZKTLSとしても知られ、TLSチャンネルで交換されたデータに関する特定のステートメントを、指定された検証者(信頼できるパーティ)に安全にエクスポートできるように、TLSハンドシェイクを変更できるようにします。これらのプロトコルは、クライアントと検証者の間でプライベートセッションデータを秘密共有し、MPCの一種である2パーティ計算（two-party computation/2PC）を使用してTLSのハンドシェイクと記録層のフェーズを計算します。 DCTLSプロトコルの有名な例としては、DECO、TLSNotary/PageSigner、TownCrier、Garble-then-Prove、Janusなどがあります（同様の技術は、例えばクライアントのトラフィックが企業のブラウジングポリシーを遵守していることを証明するためのゼロ知識ミドルボックスの作成や、マルチパーティTLSクライアント/サーバの考案にも使用されています）。

これらのプロトコルは実用性が主張されているにも関わらず、広範なアダプションにおいては大きな課題を抱えています。

TLS 1.3がサポートされていない： 2020年12月にはすでに、TLS 1.3がTLSの主流バージョンとなっているにもかかわらず、リストアップされたプロトコルのどれもが安全なTLS 1.3を明確にサポートしていません。 Cloudflare Radarによると、現在TLS 1.3は安全なネットワークトラフィックの63%を占めているのに対し、TLS 1.2はわずか8.7%に過ぎません。 TLS 1.3のサポートは極めて重要です。 TLS 1.3がサポートされている場合でも、既存のプロトコルでは厳密なセキュリティ分析が行われていなかったり、安全が疑われる2PCのプロトコルステップやTLS 1.3の暗号スイートの実装などの懸念に対して十分に対応できていないことがあります。
セキュリティの限界：現在のセキュリティの議論は、特定の静的なプロトコル、暗号スイート、2PCプリミティブに限定されており、柔軟性に欠けます。例えば、DECOで使用されているプリミティブはすでに安全でないことが示されています。さらに、クライアントのプライバシーはしばしば見過ごされ、プロトコルはクライアントが通信したサーバを検証者に公開するため、機密性の高いブラウジング履歴が漏れてしまう可能性があります。
デプロイ可能性の課題：強力なセキュリティ保証と一般的なインターネット・ブラウジング・ツールの相互運用性を兼ね備えた、DCTLSプロトコルの完全な機能を備えたオープンソース実装は存在しません。この不在が、実用的な採用と広範な展開を妨げています。

これら全ての問題を解決するために、私たちは DiStefano を提案します。しかし、私たちのプロトコルを説明する前に、DCTLSプロトコルがどのように機能するかを見てみます。

DCTLSの詳細

ハンドシェイク、クエリ、コミットフェーズを示したDiStefanoプロトコルの概要

DCTLSプロトコルは、クライアントがサーバと通信したTLSセッションデータに対するコミットメントを生成し、指定されたサードパーティ検証者に送信できるようにします。 DCTLSプロトコルは以下のフェーズで構成されます。1. (検証者アシスト)ハンドシェークフェーズ、 2. (検証者アシスト)クエリー実行フェーズ、 3. コミットメントフェーズ。 TLS 1.3では (1-RTTで証明書ベース認証があるTLS 1.3の非公式な記述によると)、これらのフェーズは以下のようになります。

ハンドシェークフェーズ このフェーズでは(以下に示すように)、サーバは標準的なTLS 1.3と同じ秘密セッション・パラメーターを学習し、クライアントと検証者は、通常クライアントのみが学習するセッションパラメーターの共有を学習します。これらは、一連の2PC機能を使って、コアTLS 1.3プロトコルに関与します。つまり、セッションデータを秘密裏に共有し、セッション秘密鍵に到達するのです。

レコード・レイヤー - クエリ実行フェーズ レコード・レイヤーでは、クライアントとサーバ間で暗号化された通信を行います（下図参照）。クライアントは、検証者のサポート受けて、暗号化されたクエリ（HTTPSリクエストなど）をサーバに送信します。セッション秘密鍵は秘密裏に共有されるので、クライアントと検証者は、2者間計算 (two-party computation/2PC)を使用して、これらのクエリの暗号化を共同で計算します。同様に、サーバからの暗号化されたレスポンス(例えばHTTPSレスポンス)も、同じ共同手順で復号化できます。次のフェーズで説明しますが、これらの対応はまずコミットされなければなりません。

レコード・レイヤー - コミットフェーズ 暗号化されたクエリが送信され、暗号化された応答が受信された後、クライアントは暗号文(暗号化された応答、など)を検証者に転送することで、セッションをコミットします(図1ボックス3参照)。それと引き換えに、検証者はクライアントにセッション秘密鍵を共有します。これによりクライアントは、サーバの応答の完全性を検証し、後でサーバから派生したステートメントを検証者に証明することができるようになります。例えば、現在検証者が保持しているコミットされた暗号化レスポンスを使用して、クライアントは特定のステートメントが真であることをゼロ知識で証明することができます。(HTTPSレスポンスに年齢を表すフィールドがありその年齢が18歳以上であることを証明する、など)。

見てわかるように、DCTLSプロトコルは単純です。信頼できる第三者（検証者）がハンドシェイクに参加し（2PCのオペレーションを実行することによって）、検証者が暗号化されたデータにコミットすることを可能にします。このデータは、後にゼロ知識証明を作成するために使用することができます。ゼロ知識証明にはこのコミットが必要です。あるステートメントを証明しようとするデータは、その不変性を保証するためにコミットされなければなりません。ただし、クライアントが平文データを公開することを選択しない限り、検証者が平文データを知ることはありません。検証者は完全なセッション秘密鍵の共有のみを保持し、完全なセッション秘密鍵が知られない限り、暗号化されたデータを復号化することはできません。

DiStefano: 信頼できる暗号化された事実のみを共有する分散型インフラストラクチャ

すべてのDCTLSは同様のアプローチなのですが、私たちのプロトコルである DiStefano では、それを次のように改良します。

前のセクションで説明したように(詳細は論文に掲載しています)、TLS 1.3ですべてを機能するようにします。
完全なセキュリティモデルの提供：悪意のある攻撃者が存在してもセキュリティを確保する、モジュール式の独立したセキュリティフレームワークを提供します。
プライバシー保証の向上: ハンドシェイクフェーズにおいてサーバが証明書メッセージをクライアントに送信する際、検証のためにそれらのメッセージを検証者に中継すると、クライアントの閲覧履歴が長期間にわたって開示されることになります。これはサーバの証明書にそのIDが含まれているからなのですが、クライアントの行動が知られてしまう可能性があります。 DiStefano は、これを防ぎます。その代わりに、TLS交換中に生成された署名に対して、有効な署名の知識に関するゼロ知識証明（ZKPVS）を使用します。この方式では、自分の鍵ペアによって発行された有効な署名を保持し、検証者は有効な公開鍵のセットを保持します。目的は特定の公開鍵を開示することなく、署名がこの集合に関して有効であることを証明することです。このようにすることで証明者の身元が秘匿され、クライアントのプライバシーが保たれます。この目的のために、我々のCDLSスキームはEC-DSA署名と共に使用することができます。

暗号化されたデータにコミットするにはPedersen Commitmentsのような伝統的なコミットメント方式を使うこともできます。しかし、我々はTLS 1.3プロトコルが提供する既存の機能を活用することを選択しました。これは、AES-GCM（データを暗号化するためにTLS 1.3でサポートされているアルゴリズム）をコミットメントスキームとして機能させるものです。 AES-GCMはAEAD設定で使用される場合、非コミット型サイファーとして機能するため、コミット型にするための修正を導入しました。具体的には、暗号文に関連するタグを検証しています。我々のアプローチの包括的な説明については、我々の論文をご参照ください。

このように DiStefano はTLS 1.3内で安全に動作するDCTLSプロトコルであり、あるべきセキュリティ保証を提供し、クライアントのプライバシーを保証します。また、実用的なシナリオでのパフォーマンスを評価するWAN実験を通じて実証されたように、非常に効率的です。その結果、実行時間の増加は、回路の前処理とGCMのシェア導出によるわずかな偏差はあるものの、導入されたレイテンシに比例することが示されました。回路の前処理は実行時間を増加させますが、オフラインで償却可能なコストです。 GCM共有の導出は、プロトコルのマルチラウンドトリップの性質を反映し、一貫して1秒未満です。これらの要因を考慮しても、総オンラインコストは、通常10秒から20秒の間で設定可能な一般的なTLSハンドシェイクのタイムアウトよりも大幅に低いままです。さらに、待ち時間の増加の影響は非線形であるようで DiStefano が様々なブラウジングシナリオにおいて高い効率性と実用性を維持することを示唆しています。

DiStefanoは、さまざまなブラウジングシーンで高い効率性と実用性を維持します

では、他に何ができるでしょうか? DiStefano はTLS 1.3で暗号化されたデータに対するコミットメントを与えてくれるかなり完全なプロトコルですが、そのデータに対するゼロ知識証明はまだ与えてくれません。では、さらに詳しく見てみましょう。

ゼロ知識証明

TLSで送信されるデータは、アプリケーションによってさまざまな形式をとることができます。一般的なフォーマットには、WebページのHTMLやAPIのJSONなどがありますが、XML、バイナリデータ、独自プロトコルなど、その他のフォーマットもTLS上で安全に送信することができます。つまり、私たちがステートメントを証明しようとするデータは、これらのフォーマットで構造化されていることが多いのです。例えば年齢フィールドを含むJSON blobを見てみましょう。

{
  "name": "DiStefano Protocol",
  "version": "1.0",
  "description": "A DCTLS protocol over TLS 1.3.",
  "age": 2,
  "features": {
    "security": "Proven fully secure",
    "privacy": "Maintains client privacy",
    "efficiency": "Highly efficient"
  },
  "performance": {
    "runtimeImpact": "Proportional to latency",
    "gcmShareDerivationTime": "Less than a second",
    "totalOnlineCost": "Below typical TLS handshake timeout"
  },
  "latencyImpact": "Sublinear"
}

このデータがクライアントのリクエストに対するサーバの応答としてTLS 1.3上で送信される場合、DiStefano を使用して暗号化されたデータにコミットすることができます。一旦コミットされると、フィールド「age」が1より大きい値を持つことを証明したい場合（ステートメントの証明）、以下のことを証明する必要があります。

JSONはオブジェクト、配列、文字列、数値、その他のコンポーネントのルールを規定する正式な文脈自由文法によって定義されています。例えば、オブジェクトは中括弧{}で囲まれ、カンマで区切られたキーと値のペアで構成されなければなりません。この文法に準拠していることを確認することで、データが有効なJSONであることが保証されます。
フィールド “age” がトップレベルに存在すること： JSON文法では、キーは文字列でなければならず、ルートオブジェクトの直接の子として “age” キーの存在は、他のオブジェクトや配列の中に入れ子になっていないことを検証する必要があります。
“age" に関連する値は、整数の文法規則にマッチする： JSONは、整数や浮動小数点数を含む数値を定義しており、 ”age" の値が整数であることを証明する必要があります。
“age" の値は意味的制約を満たす：文法は構造的な妥当性を扱います。“age” の値が1より大きいことを証明するには、文法規則を超えた意味的なチェックが必要です。

私たちはこれらの課題を解決するための研究に積極的に取り組んでいます。例えば1については、Reefプロトコルをベースに、文脈自由文法を扱えるように拡張しています。これにより、コミットされたJSONデータが、与えられた正規表現にマッチするか、マッチしないかを証明することができます。 3と4については、TLS 1.3でサポートされている2つの主要な暗号スイートであるAES-GCMとChaCha20-Poly1305の証明を生成できるカスタムゼロ知識証明システムを設計しており、近日中にブログ記事や論文を掲載する予定です！

なぜこれらが有用なのか?

このブログ記事の前半で、TLS 1.3の暗号化データを活用して証明書やステートメントの証明書を作成することが、ユーザーが追加サービスにアクセスできるようにするために有益であることを説明しましたが、これはその可能性の一例に過ぎません。

この種の証明は、不正防止チェックにも有効です。例えば、ユーザーが複数の認可された銀行のうちのひとつに口座を持っていることを（どの銀行かは明かさずに）ゼロ知識で証明することができます。このような証明は、ユーザーがボットではないことを示すシグナルとして機能し、プライバシーを守りながらサービスにアクセスすることを可能にし、ボットとして誤認されることを防ぐことができます。また、これらの証明を使ってデータの出所と信頼性を確認するステートメントを作成し、それが人工知能（AI）によって生成されたものではないことを証明することで「現実の」イベントであることを検証することもできます。しかしながら、DCTLSプロトコルは、特に人間が関与しない自動化されたある種のアプリケーションにおいて、クライアントのトラフィックを監視または検閲する、悪影響を及ぼすツールになる可能性があることに注意することも重要です。 DiStefano のようなツールの導入は、そのような状況において慎重に検討されなければなりません。

私たちのプロトコルに興味がありますか?

もし私たちのプロトコルを試してみたい場合、私たちはC++で DiStefano の完全なプロトタイプを実装しています。 BoringSSL上で直接構築されているので、Chromiumベースのブラウザで簡単に統合できます。実際私たちの今後の研究の1つは、この実装をBraveブラウザに直接統合することで、このプロトコルを活用してユーザビリティを低下させることなく、詐欺行為の検出（ボットの検出など）や人間性の証明を行えるようにすることです。

私たちの研究にさらにご興味がおありでしたら、論文をご覧ください。また、この論文が発表されるNDSS2025シンポジウムでもぜひお声がけください。