JP2022546470A - トランスポート層セキュリティおよび他のコンテキストでのデータの検証のための非集中型技術 - Google Patents

Abstract

一実施形態での検証器デバイスは、１つ以上のネットワークを介して、クライアントデバイスおよびサーバデバイスと通信するように構成されている。検証器デバイスは、クライアントデバイスおよびサーバデバイスとの三者ハンドシェイクプロトコルに参加し、検証器デバイスおよびクライアントデバイスは、サーバデバイスとのセキュアなセッションのセッション鍵のそれぞれのシェアを取得する。検証器デバイスは、クライアントデバイスから、サーバデバイスとのセキュアなセッションに関連するコミットメントを受信し、コミットメントの受信に応答して、クライアントデバイスに対して以前はアクセス可能でなかった、セキュアなセッションに関連する追加の情報をクライアントデバイスに公開する。検証器デバイスは、コミットメントおよび追加の情報に少なくとも部分的に基づいて、セキュアなセッションの一部として、サーバデバイスからクライアントデバイスによって取得されたデータの少なくとも１つの特徴付けの正確性を検証する。【選択図】図１

Description

関連出願の相互参照
本出願は、２０１９年８月３０日に出願された、“ＤＥＣＯ：Ｄｅｃｅｎｔｒａｌｉｚｅｄ Ｏｒａｃｌｅｓ ｆｏｒ ＴＬＳ”という名称の、米国仮特許出願第６２／８９４，０５２号の優先権を主張し、その全体は、参照により本明細書に組み込まれる。

政府支援の声明
本発明は、国立科学財団（ＮＳＦ）の助成番号ＣＮＳ－１５１４１６３、ＣＮＳ－１５６４１０２、ＣＮＳ－１７０４６１５、およびＣＮＳ－１９３３６５５、ならびに陸軍研究局（ＡＲＯ）の助成番号Ｗ９１１ＮＦ１６１－０１４５の下で、米国政府の支援を受けてなされた。米国政府は、本発明において特定の権利を有する。

本分野は、一般に、例えば、データが特定のソースからのものであることを証明するための、または別様には、トランスポート層セキュリティ（ＴＬＳ）のコンテキストで、および他のコンテキストで取得されたデータの正確性を検証するための技術を含む、情報セキュリティに関する。

ＴＬＳの広範な展開のおかげで、ユーザは、エンドツーエンドの機密性および完全性を有するチャネルを介して非公開データにアクセスすることができる。しかしながら、ユーザが行うことができないことは、そのようなデータの起源、すなわち、それが特定のウェブサイトを真に出所とすることを第三者に対して証明することである。既存の手法は、望ましくない信頼の仮定を導入するか、またはサーバサイドの修正を必要とする。その結果、ユーザの非公開データの価値は、発信源に閉じ込められる。

例示的な実施形態は、データが特定のソースからのものであることを証明する必要があるか、または別様には望ましい、ＴＬＳのための、および多数の他のアプリケーションでの非集中型オラクルを提供する。

例えば、いくつかの実施形態は、ユーザが、ＴＬＳを介してアクセスされるデータの部分が特定のウェブサイトを出所とすることを証明することと、任意選択で、そのようなデータに関するステートメントをゼロ知識で証明して、データそのものを秘密に保持することと、を可能にする、本明細書では例示的にＤＥＣＯと呼ばれる、非集中型オラクルを提供することによって、既存の手法の上述した欠点を克服する。したがって、ＤＥＣＯは、集中型ウェブサービスサイロからデータを解放し、広範なアプリケーションにとってこのデータをアクセス可能にすることができる。有利なことに、例示的な実施形態でのＤＥＣＯは、信頼できるハードウェアまたはサーバサイドの修正なしに機能する。

一実施形態では、装置は、プロセッサ、およびプロセッサに結合されたメモリを含む検証器デバイスを備える。検証器デバイスは、１つ以上のネットワークを介して、クライアントデバイスおよびサーバデバイスと通信するように構成されている。検証器デバイスは、クライアントデバイスおよびサーバデバイスとの三者ハンドシェイクプロトコルに参加し、検証器デバイスおよびクライアントデバイスは、サーバデバイスとのセキュアなセッションのセッション鍵のそれぞれのシェアを取得する。検証器デバイスは、クライアントデバイスから、サーバデバイスとのセキュアなセッションに関連するコミットメントを受信し、コミットメントの受信に応答して、クライアントデバイスに対して以前はアクセス可能でなかった、セキュアなセッションに関連する追加の情報をクライアントデバイスに公開する。検証器デバイスは、コミットメントおよび追加の情報に少なくとも部分的に基づいて、セキュアなセッションの一部として、サーバデバイスからクライアントデバイスによって取得されたデータの少なくとも１つの特徴付けの正確性を検証する。

前述の配置は単なる例であり、多数の代替構成が可能であることを理解されたい。

本発明のこれらのおよび他の実施形態は、限定されないが、システム、方法、装置、処理デバイス、集積回路、およびソフトウェアプログラムコードが内部で具現化されたプロセッサ可読記憶媒体を含む。

例示的な実施形態における、ＴＬＳのための非集中型オラクルを実装した情報処理システムを示す。 例示的な実施形態における、ＴＬＳのための非集中型オラクルを実装するためのプロセスのフロー図である。 例示的な実施形態における、非集中型オラクルの機能性の例を示す。 例示的な実施形態における、サーバデバイス、証明器デバイス、および検証器デバイスを備える非集中型オラクル実装態様でのデバイスインタラクションの複数の段階を例示している。 例示的な実施形態における、選択的開示およびコンテキスト完全性攻撃を実証するために使用される銀行ステートメント情報を含む例示的なデータを示す。 例示的な実施形態における、非集中型オラクルプロトコルの１つの可能な実装態様の詳細図を示す。 例示的な実施形態における、非集中型オラクルを実装する際に利用される三者ハンドシェイクプロトコルの詳細な例を示す。 例示的な実施形態における、鍵共有を確立する際に証明器デバイスと検証器デバイスとの間で実行されるプロトコルを示す。 例示的な実施形態における、分散化オラクルの実装態様と併せて利用されるプロトコルの追加の例を示す。 例示的な実施形態における、分散化オラクルの実装態様と併せて利用されるプロトコルの追加の例を示す。 パーティのうちの１つが非集中型オラクルを利用して、スマートコントラクトに提供される情報を取得する、２つのパーティを含むスマートコントラクトの実施形態を示す。 例示的な実施形態における、１つ以上の非集中型オラクルそれぞれの明示モードおよび黒塗りモードを使用して処理された例示的なデータを示す。 例示的な実施形態における、１つ以上の非集中型オラクルそれぞれの明示モードおよび黒塗りモードを使用して処理された例示的なデータを示す。 例示的な実施形態における、一意鍵文法の２段階の構文解析のための擬似コードを示す。

本発明の実施形態は、例えば、コンピュータネットワーク、またはネットワーク、クライアント、サーバ、処理デバイス、および他の構成要素の他の配置を含む、情報処理システムの形態で実装され得る。そのようなシステムの例示的な実施形態が、本明細書に詳細に記載される。しかしながら、本発明の実施形態は、より一般的に、多種多様な他のタイプの情報処理システム、および関連付けられたネットワーク、クライアント、サーバ、処理デバイス、または他の構成要素に適用可能であることを理解されたい。よって、本明細書で使用される「情報処理システム」という用語は、これらのおよび他の構成を包含するように広く解釈されることが意図されている。

図１は、例示的な実施形態での、ＴＬＳのための非集中型オラクルを実装した情報処理システム１００を示す。システム１００は、ネットワーク１０５を介して通信するように構成されている複数のクライアントデバイス１０２－１、１０２－２、．．．１０２－Ｎおよび検証器デバイス１０４を備える。クライアントデバイス１０２のうちの所与の１つは、例えば、ラップトップコンピュータ、タブレットコンピュータもしくはデスクトップパーソナルコンピュータ、携帯電話、または別のタイプのコンピュータもしくは処理デバイス、ならびに複数のそのようなデバイスの組み合わせを備えることができる。検証器デバイス１０４は、同様に、少なくとも１つのプロセッサと、少なくとも１つのプロセッサに結合された少なくとも１つのメモリと、を各々が含む、様々なタイプの処理デバイスを備えることができる。

ネットワーク１０５は、例えば、インターネットなどのグローバルコンピュータネットワーク、ワイドエリアネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、衛星ネットワーク、電話もしくはケーブルネットワーク、３Ｇ、４Ｇ、もしくは５Ｇネットワークなどのセルラネットワーク、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＷｉＦｉ（登録商標）もしくはＷｉＭＡＸ（登録商標）などの無線プロトコルを使用して実装された無線ネットワーク、またはこれらの、および他のタイプの通信ネットワークの様々な部分もしくは組み合わせを例示的に含むことができる。

システム１００は、それぞれの保護されたデータソース１０８と関連付けられた複数のＴＬＳサーバ１０６をさらに備える。ＴＬＳサーバ１０６は、これらのＴＬＳサーバのそれぞれの保護されたデータソース１０８へのアクセスを制御するように例示的に構成されている。保護されたデータソース１０８の少なくともサブセットが、それぞれのＨＴＴＰＳ対応ウェブサイトを例示的に含み、ＨＴＴＰＳは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）の拡張であるハイパーテキスト転送プロトコルセキュアの表記である。多種多様な追加のまたは代替のデータソースを他の実施形態で使用することができることを認識されたい。システム１００の保護されたデータソース１０８は、これらのデータソースにＴＬＳサーバ１０６のうちの少なくとも１つを通してＨＴＴＰＳを介してセキュアにアクセスすることができるという意味で保護される。他のデータソースは、この特定の方法でアクセス可能である必要はなく、追加のまたは代替のアクセス制御機構を実装することができ、かつ／または他のタイプのセキュアプロトコルを使用して公的にアクセス可能であり得る。

また、本明細書の例示的な実施形態は、ＴＬＳサーバ１０６などの特定のタイプの１つ以上のサーバを利用するが、他のタイプのセキュアなプロトコルを他の実施形態で使用することができ、他のタイプのサーバデバイスに実装することができることを認識されたい。したがって、本明細書で使用される「サーバデバイス」という用語は、広く解釈されることが意図されており、ＴＬＳサーバにいかなるようにも限定されると見なされるものではない。

いくつかの実施形態でのクライアントデバイス１０２は、検証器デバイス１０４またはシステム１００の他のゼロ知識証明（ＺＫＰ）オラクルノード１１０に対する、それぞれの証明器デバイスとして動作する。したがって、検証器デバイス１０４を、システム１００のＺＫＰオラクルノードと見なしてもよい。したがって、その用語が本明細書で広く使用される所与の「検証器デバイス」は、例えば、システム１００などの非集中型オラクルシステムのオラクルノードのセットの特定のオラクルノードを含むことができる。

システム１００のデバイスおよび他の構成要素の特定の数、タイプ、および配置は、例示的な例としてのみ提示され、他の実施形態では変わり得る。例えば、この実施形態では、単一の検証器デバイス１０４のみが示されるが、他の実施形態は、他のＺＫＰオラクルノード１１０がそれぞれの検証器デバイスとして動作する配置でのように、複数の検証器デバイスを含むことができる。また、ＴＬＳサーバ１０６のうちの１つ以上が各々、保護されたデータソース１０８のうちの複数のものへのアクセスを制御するように構成され得る。多数の他の非集中型オラクル配置が可能である。

検証器デバイス１０４は、三者ハンドシェイクモジュール１１２、ポストハンドシェイクインタラクションモジュール１１４、および証明検証モジュール１１６を備える。これらのモジュールは、以下でより詳細に記載されるように、本明細書ではＤＥＣＯプロトコルとも呼ばれる、非集中型オラクルプロトコルのそれぞれの個別のプロトコルを実装している。

本実施形態の検証器デバイス１０４は、プロセッサ１２０、メモリ１２２、およびネットワークインターフェース１２４をさらに備える。プロセッサ１２０は、図に示される簡略化された例示的相互接続を介してメモリ１２２に、およびネットワークインターフェース１２４に、動作可能に結合されるものする。

プロセッサ１２０は、例えば、マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、中央処理ユニット（ＣＰＵ）、グラフィック処理ユニット（ＧＰＵ）、算術論理ユニット（ＡＬＵ）、デジタル信号プロセッサ（ＤＳＰ）、または他の同様の処理デバイスコンポーネント、ならびに他のタイプおよび配置の処理回路機構を、任意の組み合わせで含んでもよい。本明細書に開示される所与の処理デバイスによって提供される非集中型オラクルの機能性の少なくとも一部分を、そのような回路機構を使用して実装することができる。

メモリ１２２は、処理デバイスの機能性の一部分を実装する際に、プロセッサ１２０による実行のためのソフトウェアプログラムコードを記憶する。例えば、モジュール１１２、１１４、および１１６の機能性の少なくとも一部分を、メモリ１２２に記憶されたプログラムコードを使用して実装することができる。

対応するプロセッサによる実行のためのそのようなプログラムコードを記憶する所与のそのようなメモリは、本明細書で、より一般に、プログラムコードが内部で具現化されたプロセッサ可読記憶媒体と呼ばれるものの例であり、例えば、ＳＲＡＭ、ＤＲＡＭ、もしくは他のタイプのランダムアクセスメモリ、読み取り専用メモリ（ＲＯＭ）、フラッシュメモリ、磁気メモリ、光学メモリ、または他のタイプの記憶デバイスなどの電子メモリを、任意の組み合わせで含んでもよい。

そのようなプロセッサ可読記憶媒体を備える製造物品は、本発明の実施形態と見なされる。本明細書で使用される「製造品」という用語は、一過性の伝播信号を除外すると理解されるものである。

プロセッサ可読記憶媒体を備える他のタイプのコンピュータプログラム製品を、他の実施形態で実装することができる。

加えて、本発明の実施形態を、クライアントデバイス１０２、検証器デバイス１０４、ＴＬＳサーバ１０６、および他のＺＫＰオラクルノード１１０のうちの１つ以上と関連付けられた処理動作を実施するように構成された処理回路機構を備える集積回路の形態で実施してもよい。

ネットワークインターフェース１２４は、検証器デバイス１０４がネットワーク１０５を介して他のシステム要素と通信することを可能にするように構成されており、１つ以上の従来の送受信機を備え得る。

動作において、例示的な実施形態における検証器デバイス１０４は、クライアントデバイス１０２－１などのクライアントデバイス１０２のうちの所与の１つ、およびＴＬＳサーバ１０６のうちの所与の１つとともに、三者ハンドシェイクプロトコルに参加するように構成されている。そのような参加は、検証器デバイス１０４の三者ハンドシェイクモジュール１１２によって、例示的に制御される。三者ハンドシェイクプロトコルの実行と併せて、検証器デバイス１０４およびクライアントデバイス１０２－１は、所与のＴＬＳサーバとのセキュアなセッションのセッション鍵のそれぞれのシェアを取得する。セキュアなセッションは、ＴＬＳセッションを例示的に含む。

検証器デバイス１０４は、クライアントデバイス１０２－１から、所与のＴＬＳサーバとのセキュアなセッションに関連するコミットメントを受信する。コミットメントの受信に応答して、検証器デバイス１０４は、クライアントデバイス１０２－１に対して以前はアクセス可能でなかったセキュアなセッションに関連する追加の情報をクライアントデバイス１０２－１に公開する。コミットメントに関連するこれらの動作は、ポストハンドシェイクインタラクションモジュール１１４の制御下で例示的に実行される。

検証器デバイス１０４は、コミットメントおよび追加の情報に少なくとも部分的に基づいて、セキュアなセッションの一部として、所与のＴＬＳサーバからクライアントデバイス１０２－１によって取得されたデータの少なくとも１つの特徴付けの正確性を検証する。そのような検証は、証明検証モジュール１１６の制御下で例示的に実行される。

いくつかの実施形態では、検証器デバイス１０４は、所与のＴＬＳサーバからクライアントデバイス１０２－１によって取得されたデータの少なくとも１つの特徴付けの正確性の検証に応答して、１つ以上の自動化されたアクションを開始するようにさらに構成されている。例えば、検証器デバイス１０４は、検証情報または他の関連情報をクライアントデバイス１０２－１に返すことができる。

例として、セキュアなセッションに関連するコミットメントは、セキュアなセッションの一部として、所与のＴＬＳサーバからクライアントデバイス１０２－１によって取得されたクエリ応答データへのコミットメントを含んでもよい。

別の例として、セキュアなセッションに関連するコミットメントは、クライアントデバイス１０２－１によって、三者ハンドシェイクプロトコルと併せて確立されたが、検証器デバイス１０４に対して以前にアクセス可能でない証明器鍵へのコミットメントを含んでもよい。他のタイプのコミットメントを他の実施形態で使用することができる。

いくつかの実施形態での、コミットメントの受信に応答してクライアントデバイス１０２－１に公開された追加の情報は、三者ハンドシェイクプロトコルと併せて検証器デバイス１０４によって確立されたが、クライアントデバイス１０２－１に対して以前にアクセス可能でない検証鍵を含む。

他の実施形態では、検証器デバイス１０４は、クライアントデバイス１０２－１と所与のＴＬＳサーバとの間のインタラクションと併せて、クライアントデバイス１０２－１に対するプロキシとして動作するようにさらに構成されており、これにより、検証器デバイス１０４は、プロキシとして動作する検証器デバイス１０４を介したセキュアなセッションの一部としてクライアントデバイス１０２－１と所与のＴＬＳサーバとの間で交換される暗号文を自動的に取得する。そのような実施形態は、本明細書では「プロキシモード」配置と呼ばれる。

いくつかの実施形態での検証器デバイス１０４は、セキュアなセッションの一部として、所与のＴＬＳサーバからクライアントデバイス１０２－１によって取得されたデータを特徴付ける１つ以上のステートメントをクライアントデバイス１０２－１から受信するようにさらに構成されている。

例えば、１つ以上のステートメントのうちの所与の１つは、セキュアなセッションの一部として、所与のＴＬＳサーバからクライアントデバイス１０２－１によって取得されたクエリ応答データの選択的に明示されたサブストリングを例示的に含む。

別の例として、１つ以上のステートメントのうちの所与の１つは、多段階構文解析プロトコルの利用を通じてコンテキスト完全性を提供するように例示的に構成されており、セキュアなセッションの一部として、所与のＴＬＳサーバからクライアントデバイス１０２－１によって取得されたクエリ応答データは、クライアントデバイス１０２－１によって前処理されて、クライアントデバイス１０２－１によって検証器デバイス１０４に送信される所与のステートメントの生成と併せて、クライアントデバイス１０２－１によって続いて解析される低減されたデータを生成する。

セキュアなセッションの一部として、所与のＴＬＳサーバからクライアントデバイス１０２－１によって取得されたデータを特徴付ける多種多様な他のタイプのステートメントを、他の実施形態で使用することができる。

いくつかの実施形態では、三者ハンドシェイクプロトコルと併せて、クライアントデバイス１０２－１および検証器デバイス１０４は、所与のＴＬＳサーバとともに１つ以上の共有セッション鍵を合同で確立し、クライアントデバイス１０２－１は、１つ以上の共有セッション鍵のうちの所与の１つの第１のシェアを有し、検証器デバイス１０４は、所与の共有セッション鍵の第２のシェアを有し、所与のＴＬＳサーバは、第１および第２のシェアを組み合わせる複合セッション鍵を有する。

追加的にまたは代替的に、三者ハンドシェイクプロトコルと併せて、クライアントデバイス１０２－１は、所与のＴＬＳサーバから、検証器デバイス１０４に対してアクセス可能でない暗号鍵を受信する。

いくつかの実施形態では、検証器デバイス１０４およびクライアントデバイス１０２－１は、所与のＴＬＳサーバとのセキュアなセッションのセッション鍵のそれらのそれぞれのシェアを使用して共同して、所与のＴＬＳサーバがクライアントデバイス１０２－１にデータを送信することを要求するためにクライアントデバイス１０２－１によって所与のＴＬＳサーバに提供されるクエリを生成する。

検証器デバイス１０４およびクライアントデバイス１０２－１は、同様に、所与のＴＬＳサーバとのセキュアなセッションのセッション鍵のそれらのそれぞれのシェアを使用して共同して、クエリに応答して、所与のＴＬＳサーバによってクライアントデバイス１０２－１に提供される応答を確証することができる。

いくつかの実施形態では、三者ハンドシェイクプロトコルと併せて、クライアントデバイス１０２－１および検証器デバイス１０４は、それぞれの証明器および検証器鍵を確立する。そのような実施形態では、セキュアなセッションの一部として、所与のＴＬＳサーバからクライアントデバイス１０２－１によって取得されたデータの少なくとも１つの特徴付けの正確性を検証することは、クライアントデバイス１０２－１によって検証器デバイス１０４に提供された証明を検証することを例示的に含む。証明は、クライアントデバイス１０２－１によって、（ｉ）三者ハンドシェイクプロトコルと併せてクライアントデバイス１０２－１によって確立された証明器鍵、（ｉｉ）三者ハンドシェイクプロトコルと併せて検証器デバイス１０４によって確立された検証器鍵、および（ｉｉｉ）パスワードまたはパスコードなどの、クライアントデバイス１０２－１の秘密情報に少なくとも部分的に基づいて、例示的に生成される。

いくつかの実施形態では、セキュアなセッションの一部として、所与のＴＬＳサーバからクライアントデバイス１０２－１によって取得されたデータの少なくとも１つの特徴付けの正確性を検証することは、セキュアなセッションの少なくとも１つの暗号文の少なくとも一部分から導出されたデータを取得することと、クライアントデバイス１０２－１によって、そのデータの少なくとも１つの特徴付けの正確さを検証することと、を例示的に含む。本明細書のこの文脈および他の場所で使用される「暗号文」という用語は、広く解釈されることが意図されており、任意の特定の暗号プロトコルの使用を必要とすると見なされるものではない。

図１に示される構成要素および他のシステム要素の特定の配置、ならびに上述したそれらの関連付けられた処理動作は、例示的な例としてのみ提示され、多数の代替実施形態が可能であることを認識されたい。

例えば、システム１００の検証器デバイス１０４は、メモリに結合されたプロセッサを備える単一の処理デバイスとして例示的に示されているが、他の実施形態での検証器デバイスは、検証器デバイス１０４の機能性が複数の個別の処理デバイスにわたって分散された分散型検証器デバイスを備えることができる。そのような実施形態では、本明細書に開示される様々なプロトコルにおける検証器の役割を、マルチパーティプロトコルを実行する複数の個別のパーティにわたって分散させ、各々のそのようなパーティを、分散型検証器デバイスの複数の処理デバイスのうちの異なる１つと関連付けることができる。したがって、本明細書で使用される「デバイス」という用語は、メモリに結合されたプロセッサを備える少なくとも１つの処理デバイス、したがって、分散型検証器デバイスの場合でのような複数のそのような処理デバイスを包含するように、広く解釈されることが意図されている。

図２は、検証器デバイス１０４がＴＬＳサーバ１０６のうちの１つによって制御されるデータに関して証明器としてのクライアントデバイス１０２のうちの１つとインタラクトすることによって、少なくとも部分的に例示的に実装された、例示的なプロセスを示す。この特定のプロセスは単なる例であり、追加のまたは代替のプロセスを、他の実施形態で、証明器、検証器、およびサーバエンティティによって、少なくとも部分的に実行することができることを理解されたい。

この実施形態では、プロセスは、ステップ２００～２０８を例示的に含む。上記に述べたように、これらのステップの少なくとも一部分は、検証器デバイス１０４が、クライアントデバイス１０２のうちの１つとインタラクトし、かつＴＬＳサーバ１０６のうちの１つをさらに伴うことによって、少なくとも部分的に実行されるものとする。これらの構成要素は、図２プロセスのコンテキストでは、それぞれ検証器、証明器、およびサーバとも呼ばれる。

ステップ２００では、検証器は、クライアントおよびサーバとの三者ハンドシェイクプロトコルに参加し、クライアントは証明器として機能する。

ステップ２０２では、三者ハンドシェイクプロトコルと併せて、検証器および証明器は、サーバとのセキュアなセッションのセッション鍵のそれぞれのシェアを取得する。

ステップ２０４では、検証器は、証明器から、サーバとのセキュアなセッションに関連するコミットメントを受信する。

ステップ２０６では、コミットメントの受信に応答して、検証器は、証明器に対して以前はアクセス可能でなかったセキュアなセッションに関連する追加の情報を証明器に公開する。

ステップ２０８では、検証器は、コミットメントおよび追加の情報に少なくとも部分的に基づいて、セキュアなセッションの一部として、サーバから証明器によって取得されたデータの少なくとも１つの特徴付けの正確性を検証する。

本明細書に開示されるような非集中型オラクルの実装態様と関連して、多数の他の技術を使用することができる。

よって、図２のフローチャートと併せて記載される特定の処理動作および他の機能性は、例示的な例としてのみ提示され、いかなるようにも本発明の範囲を限定すると解釈されるものではない。代替実施形態は、検証器デバイス、証明器デバイス、およびサーバデバイスを伴う他のタイプの処理動作を使用することができる。例えば、プロセスステップの順序を、他の実施形態で変えてもよく、または特定のステップを、連続的ではなく互いに同時に実行してもよい。また、プロセスの複数のインスタンスを、それぞれの証明器、検証器、およびサーバデバイスの異なるセットのために、システム１００内で互いに並列に実行してもよい。よって、システム１００は、本明細書に開示される技術を使用して、多数の非集中型オラクルを同時に実装することができる。

ここで、例示的な実施形態のさらなる態様を、図３～図１４を参照して記載する。

ＴＬＳの広範な展開により、ユーザは、エンドツーエンドの機密性および完全性を有するチャネルを介して非公開データにアクセスすることができる。しかしながら、従来の慣行の下でユーザが容易に行うことができないことは、そのようなデータの起源、すなわち、それが特定のウェブサイトを真に出所とすることを第三者に対して証明することである。既存の手法は、望ましくない信頼の仮定を導入するか、またはサーバサイドの修正を必要とする。

その結果、ユーザの非公開データは、発信源に閉じ込められる。ユーザは、現在のデータ所有者からの助力および許可なしには、完全性が保護された方法でユーザのデータを他のアプリケーションにエクスポートすることができない。

本明細書における例示的な実施形態は、ＤＥＣＯ（非集中型オラクルの略）と称される技術を提供して、これらのおよび他の問題に対処する。ＤＥＣＯは、ＴＬＳを介してアクセスされた一データが特定のウェブサイトを出所とすることをユーザが証明し、任意選択で、そのようなデータに関するステートメントをゼロ知識で証明して、データ自体を秘密に保持することを可能にする。有利なことに、例示的な実施形態でのＤＥＣＯを、信頼できるハードウェアまたはサーバサイドの修正を必要とせずに実装することができる。

ＤＥＣＯは、集中型ウェブサービスサイロからデータを解放し、広範なアプリケーションに対してこのデータをアクセス可能にすることができる。ＤＥＣＯのパワーを実証するために、それなしには以下を達成することが厳しい３つのアプリケーションを実装する：スマートコントラクトを使用した非公開金融商品、レガシークレデンシャルの匿名のクレデンシャルへの変換、および価格差別に対する検証可能な請求。

本明細書におけるＤＥＣＯへのこれらのおよび他の参照が例示的な実施形態を指し、それらの実施形態の特定の特徴、機能性、利点および他の詳細がいかなるようにも限定されると解釈されるものではないことを認識されたい。代替実施形態は、ＴＬＳおよび他のコンテキストにおけるデータソースを検証するための追加のまたは代替の技術を実装することができる。

上記に示したように、ＴＬＳは、ユーザが、機密の、完全性が保護されたチャネルを介してウェブデータにアクセスすることを可能にする、強力で広範囲に展開されたプロトコルである。しかし、ＴＬＳは、ユーザがアクセスした一データが特定のウェブサイトを真正に出所とすることを第三者に対して証明することができないという、深刻な制限を有する。その結果、データの使用は、しばしばその発信源に限られ、ＧＤＰＲなどの最近の規制によって認められている権利であるユーザによるデータ可搬性を縮小する。

具体的には、ユーザがＴＬＳを介してオンラインでデータにアクセスする場合、現在のデータ所有者からの助力（それゆえ許可）なしには、セキュアにデータをエクスポートすることができない。したがって、膨大な量の非公開データが、意図的に、または意図せずに、公にアクセス可能でないウェブの一部である、「ディープウェブ」に閉じ込められる。

この問題をよりよく認識するために、アリスが１８歳以上であることをボブに対して証明したい例を考える。現在、年齢検証サービスは、ユーザがＩＤおよび詳細な個人情報をアップロードすることを必要とし、それにより、プライバシー問題が生じる。しかし、会社の給与記録またはＤＭＶウェブサイトなどの、様々なウェブサイトは、原則として検証された生年月日を記憶し、提供する。アリスは、そのようなサイトから彼女の生年月日のスクリーンショットを送信し得るが、これは、容易に偽造される。スクリーンショットが本物であることが何らかの形で証明されたとしても、彼女が１８歳以上であることだけでなく、彼女の正確な生年月日を明示する情報が漏洩するであろう。

オンラインデータの起源をスマートコントラクトに対して証明するために最初に提案されたオラクルは、ＴＬＳによって保護されたデータを起源および完全性の保証を有して他のシステムにエクスポートすることに向けたステップである。しかしながら、既存のスキームは、深刻な技術的制限を有する。これらの既存のスキームは、非推奨のＴＬＳバージョンでのみ機能し、オラクル（例えば、ＴＬＳＮｏｔａｒｙ）からプライバシーを提供しないか、または信頼できるハードウェア（例えば、Ｔｏｗｎ Ｃｒｉｅｒ）に依存し、それらに対して、最近、様々な攻撃が現れている。別のクラスのオラクルスキームは、サーバサイドの協調を前提としており、サーバがＴＬＳ拡張機能をインストールするか、またはアプリケーション層ロジックを変更することを義務付ける。サーバによって推進されるオラクルスキームは、２つの基本的な問題に見舞われている。まず、これらのスキームは、レガシー互換性を破り、広い採用に重大な障壁を生じさせる。その上、ウェブサーバが、どのデータをエクスポートすることができるかを判定する唯一の決定権を有し、かつエクスポート試行を任意に検閲することができるため、そのようなソリューションは、条件付きエクスポート可能性を提供するに過ぎない。ユーザがアクセス権を有する任意のデータをエクスポートできるようにするメカニズムであれば、現在実現できないアプリケーションのホスト全体が可能になるであろう。

上記の問題に対処するために、本明細書に開示される例示的な実施形態は、ＴＬＳのための非集中型オラクルである、ＤＥＣＯと呼ばれる配置を提供する。ウェブサイトごとのサポートを必要とするオラクルスキームとは異なり、ＤＥＣＯは、例示的にソース非依存であり、標準のＴＬＳを実行する任意のウェブサイトをサポートする。ウェブサイトの参加に依存するソリューションとは異なり、ＤＥＣＯは、サーバサイドの協調を必要としない。したがって、ＤＥＣＯの単独のインスタンスは、誰でも任意のウェブサイトのオラクルになることを可能にし得る。

ＤＥＣＯは、スマートコントラクトなどのインターネットにアクセスすることができないアプリケーションを含む幅広いアプリケーションに対して、豊富なインターネットデータを、真正性およびプライバシーを保証してアクセス可能にする。ＤＥＣＯは、非公開データデリバリに、第三者への転送または公開リリースのためのオプションを提供することによって、今日のウェブデータ拡散モデルを根本的にシフトさせ得る。この技術的能力は、将来の潜在的な法的および規制上の課題を際立たせるが、同時に、魅力的な新しいサービスの創出および提供を見込むものである。重要なことに、ＤＥＣＯは、いくつかの代替手法とは異なり、信頼できるハードウェアを必要としない。

いくつかの実施形態では、高レベルでは、証明器は、一データＤにコミットし、検証器に、ＤがＴＬＳサーバＳ、および任意選択でＤに関するステートメントπ_Ｄを出所とすることを証明する。年齢を証明する例を再び参照すると、ステートメントπ_Ｄは、属性「Ｄ＝ｙ／ｍ／ｄは、アリスの誕生日であり、現在の日付－Ｄは、少なくとも１８年である」であり得る。

非公式に、ＤＥＣＯは、真正性を達成する－すなわち、検証器は、Ｄに関するアサートされたステートメントが真であり、かつＤがＴＬＳサーバＳから実際に取得された場合にのみ確信する。ＤＥＣＯはまた、検証器がＳから取得されたいくつかのＤのためにステートメントπ_Ｄが持続することを学習するに過ぎない点で、プライバシーを提供する。

レガシーＴＬＳ互換プリミティブを使用しながら、必要とされるセキュリティおよび実用的な性能を有するＤＥＣＯを設計することは、いくつかの重要な技術的課題を導入する。１つの課題は、ＴＬＳが、クライアント（例えば、ＤＥＣＯの証明器）およびウェブサーバによって共有される対称暗号鍵および認証鍵を生成するということから起こる。したがって、クライアントは、有効な認証鍵でデータに署名するという意味で、任意のＴＬＳセッションデータを偽造することができる。

この課題に対処するために、ＤＥＣＯは、一ＴＬＳセッションデータＤに検証器に対する証明器による非偽造可能なコミットメントを作成する、証明器、検証器、およびウェブサーバの間の新規な三者ハンドシェイクプロトコルを導入する。検証器は、ＤがＴＬＳサーバを真正に出所とすることを確認することができる。証明器の観点から、三者ハンドシェイクは、悪意のある検証器の存在下で、ＴＬＳのセキュリティを維持する。

効率的な選択的開示。Ｄにコミットした後、証明器は、コミットメントに関するステートメントを証明する。任意のステートメントを理論的にサポートすることができるが、検証器への応答のサブストリングのみを明示することを、最も一般的なアプリケーションである可能性が高いものについて最適化する。そのようなステートメントを、選択的開示と呼ぶ。細粒状の選択的開示は、ユーザが機密情報を秘匿することを可能にし、後続の証明への入力長を低減する。

ナイーブソリューションであれば、包括的なゼロ知識証明（ＺＫＰ）を使用したＴＬＳレコードの高価で検証可能な復号化を伴うであろうが、本明細書の例示的な実施形態は、ＴＬＳレコード構造を利用することによって、オーダオブマグニチュードの効率改善を達成する。例えば、ＴＬＳレコードの検証可能な復号化の直接的な実装態様であれば、１０２４ ＡＥＳ呼び出しの回路の正しい実行をゼロ知識で証明することを伴うであろう一方、ＣＢＣ－ＨＭＡＣのＭＡＣ後暗号化（ＭＡＣ－ｔｈｅｎ－ｅｎｃｒｙｐｔ）構造を活用することによって、本明細書における例示的な実施形態は、３つのＡＥＳ呼び出しのみで同じことを遂行することができる。

コンテキスト完全性。選択的開示は、証明器がサーバの応答ＤのサブストリングＤ’のみを明示することを可能にする。ただし、サブストリングは、このサブストリングが現れる時に応じた異なるものを意味し得、悪意のある証明器であれば、コンテキスト外の引用によって不正行為を行い得る。したがって、Ｄ’がＤに現れるだけでなく、Ｄ’が想定されるコンテキストに現れる、すなわち、Ｄ’がＤに関してコンテキスト完全性を有することを証明する必要がある（このことはプライバシー理論における「コンテキスト完全性」とは異なることに留意されたい）。

コンテキスト完全性攻撃を、セッションコンテンツが構造化されており、かつ構文解析できる場合に、阻止することができる。幸いなことに、ほとんどのウェブデータは、この形式を採用している（例えば、ＪａｖａＳｃｒｉｐｔ（登録商標）オブジェクト表記（ＪＳＯＮ）またはハイパーテキストマークアップ言語（ＨＴＭＬ））。包括的なソリューションは、セッション全体を構文解析し、明示された部分が構文解析木の必要な分岐に属することを証明することである。しかし、ウェブデータが一般に満たす特定の制約の下では、セッション全体を解析することは、必須ではない。本明細書で開示されるいくつかの実施形態は、証明器がセッションコンテンツを前処理し、かつ通常はるかに小さい結果のみを構文解析する、新規な２段階構文解析スキームを提供する。プログラミング言語理論で使用されるように、プログラムの等価性の定義から、２段階構文解析スキームのセキュリティに関して推論するための正式なフレームワークを構築することが引き出される。本明細書に開示される例示的な実施形態は、特定の文法のためのいくつかの実用的な実現を提供する。当定義および構成は、他のオラクルにも一般化される。例えば、コンテンツ隠蔽攻撃の包括的バージョンを防止し得る。

例示的な実施形態の実装態様および評価に関して、ＤＥＣＯを完全なエンドツーエンドシステムとして設計し、実装した。システムのパワーを実証するために、次の３つのアプリケーションを実装した。１）スマートコントラクトを使用した機密性保存する金融商品、２）レガシークレデンシャルの匿名クレデンシャルへの変換、および３）価格差別に対する検証可能な請求。

これらのアプリケーションでの実験は、ＤＥＣＯが高度に効率的であることを示す。例えば、ＷＡＮ設定でのＴＬＳ１．２について、三者ハンドシェイクを実行するためのオンライン時間は、２．８５ｓであり、２ＰＣクエリ実行については、２．５２ｓである。上述したアプリケーションに対してゼロ知識証明を生成するには、約３秒～１３秒かかる。より詳細な詳細は、本明細書の他の箇所で提供される。

以下に詳細に記載される例示的な実施形態と併せて開示されるＤＥＣＯは、有利なことに、証明可能にセキュアな非集中型オラクルスキームを提供する。いくつかの実施形態でのＤＥＣＯは、信頼できるハードウェアまたはサーバサイドの修正を必要としない最新のＴＬＳバージョンのためのオラクルスキームを提供する。

また、以下では、ＤＥＣＯを使用してゼロ知識で効率的に証明できるＴＬＳレコードの幅広いクラスのステートメントについて詳細に記載する。そのようなステートメントは、ユーザがセッションデータコミットのサブストリングのみをオープンすることを可能とする。最適化は、包括的なＺＫＰよりも大幅な効率改善を達成する。

コンテキスト完全性攻撃および緩和に関して、プライバシー保存するオラクルに普遍的な新しいクラスのコンテキスト完全性攻撃を識別し、新規な効率的な２段階構文解析スキームを伴う当緩和アプローチについて記載する。

トランスポート層セキュリティ（ＴＬＳ）
ここで、ＤＥＣＯが例示的な実施形態で構築されるＴＬＳハンドシェイクおよびレコードプロトコルに関するいくつかの背景を提供する。

ＴＬＳは、２つの通信アプリケーション間のプライバシーおよびデータ完全性を提供するプロトコルのファミリーである。大まかに言えば、このファミリーは、２つのプロトコルで構成されている：非対称暗号を使用してセッションをセットアップし、次のプロトコルであるレコードプロトコルのための共有のクライアントおよびサーバ鍵を確立するハンドシェイクプロトコル、レコードプロトコルでは、対称暗号を使用して機密性および完全性保護を伴ってデータが送信される。

ハンドシェイク。ハンドシェイクプロトコルでは、サーバおよびクライアントは、暗号アルゴリズムのセット（暗号スイートとしても知られている）に最初に合意する。次いで、サーバおよびクライアントは、互いに認証し（クライアント認証は任意選択）、最後に、後続のレコードプロトコルに使用される共有シークレットをセキュアに計算する。

例示的な実施形態でのＤＥＣＯは、一時的秘密（ＥＣＤＨＥ）を用いる楕円曲線ディフィーヘルマン（ＤＨ）鍵交換を利用するが、これは限定ではなく一例である。

レコードプロトコル。ＴＬＳでアプリケーション層データ（例えば、ＨＴＴＰメッセージ）を伝送するために、レコードプロトコルは、まず、アプリケーションデータ

を、固定サイズの平文レコード

に断片化する。各レコードは、通常、複数のブロック（例えば、１２８ビット）にパディングされる。次いで、レコードプロトコルは、任意選択で、データを圧縮し、ＭＡＣを適用し、結果を暗号化し、伝送する。受信されたデータは、復号化され、検証され、展開され、再構成され、次いで、上位レベルのプロトコルにデリバリされる。特定の暗号化操作は、ネゴシエートされた暗号スイートに依存する。ＤＥＣＯは、一般的に使用される２つのモードで高度暗号化標準（ＡＥＳ）暗号をサポートする：ＣＢＣ－ＨＭＡＣおよびＧＣＭであって、ＣＢＣ－ＨＭＡＣは、Ｃｉｐｈｅｒ Ｂｌｏｃｋ Ｃｈａｉｎｉｎｇ－Ｈａｓｈ－ｂａｓｅｄ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅの表記であり、ＧＣＭは、Ｇａｌｏｉｓ／Ｃｏｕｎｔｅｒ Ｍｏｄｅの表記である。ＴＬＳのこれらのおよび他の態様に関する追加の詳細は、例えば、Ｔ． Ｄｉｅｒｋｓ ａｎｄ Ｅ． Ｒｅｓｃｏｒｌａ，“Ｔｈｅ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ（ＴＬＳ） Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ １．２，” ＲＦＣ ５２４６，２００８に見出すことができ、これは、参照により本明細書に組み込まれる。ここでも、他の実施形態で他のプロトコルを使用することができる。

ＴＬＳ１．２と１．３との差異。本明細書におけるいくつかの実施形態では、ＴＬＳ１．２に焦点を当て、後で、当技術をＴＬＳ１．３に一般化する方法について記載する。ここでは、これらの２つのＴＬＳバージョン間の主な差異について簡単に書き記す。ＴＬＳ１．３は、レガシー非ＡＥＡＤ暗号のサポートを除外する。また、ハンドシェイクフローが、再編されている。ここでは、ＳｅｒｖｅｒＨｅｌｌｏ後のすべてのハンドシェイクメッセージが、暗号化される。最後に、異なる鍵導出関数が、使用される。追加の詳細を、Ｅ．Ｒｅｓｃｏｒｌａ，“Ｔｈｅ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ（ＴＬＳ）Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ １．３，” ＲＦＣ ８４４６，２０１８に見出すことができ、これは、参照により本明細書に組み込まれる。

マルチパーティ計算
各々がいくつかの秘密ｓ_ｉを保持する、パーティ

のグループを考える。セキュアなマルチパーティ計算（ＭＰＣ）は、これらのパーティが、ｆの出力以外のいかなる情報も漏洩することなく、すなわちＰ_ｉが、ｓ_ｊ≠ｉについて何も知得せずに、

を合同で計算することを可能とする。ＭＰＣプロトコルのセキュリティは、一般に、ｔ個のプレイヤを損なわせ、かつ正直なプレイヤの非公開情報を知得しようとする敵を考慮する。２パーティ計算（２ＰＣ）は、ｎ＝２、かつｔ＝１の特殊な場合を指す。

２ＰＣプロトコルに対する２つの一般的な手法がある。ガーブル回路プロトコルは、ビット演算（例えば、ＳＨＡ－２５６）に最も適した手法であるブール回路としてｆを符号化する。他のプロトコルは、閾値秘密分散を活用し、算術演算に最適である。しかしながら、２ＰＣを使用するいくつかの実施形態で計算する関数は、ビット演算と算術演算との両方を含む。これらの関数を２つのコンポーネントに分離し、ビット演算には最適化されたガーブル回路プロトコルを使用し、算術演算には秘密分散ベースのＭｔＡプロトコルを使用する。例示的な実施形態で使用される例示的な最適化されたガーブル回路プロトコルに関する追加の詳細は、Ｘｉａｏ Ｗａｎｇ，Ｓａｍｕｅｌ Ｒａｎｅｌｌｕｃｃｉ，ａｎｄ Ｊｏｎａｔｈａｎ Ｋａｔｚ，“Ａｕｔｈｅｎｔｉｃａｔｅｄ Ｇａｒｂｌｉｎｇ ａｎｄ Ｅｆｆｉｃｉｅｎｔ Ｍａｌｉｃｉｏｕｓｌｙ Ｓｅｃｕｒｅ Ｔｗｏ－Ｐａｒｔｙ Ｃｏｍｐｕｔａｔｉｏｎ，” ｉｎ ＡＣＭ ＣＣＳ，２０１７に見出すことができ、これは、参照により本明細書に組み込まれる。例示的な実施形態で使用される例示的な秘密分散ベースのＭｔＡプロトコルに関する追加の詳細は、Ｒｏｓａｒｉｏ Ｇｅｎｎａｒｏ ａｎｄ Ｓｔｅｖｅｎ Ｇｏｌｄｆｅｄｅｒ，“Ｆａｓｔ ｍｕｌｔｉｐａｒｔｙ ｔｈｒｅｓｈｏｌｄ ＥＣＤＳＡ ｗｉｔｈ ｆａｓｔ ｔｒｕｓｔｌｅｓｓ ｓｅｔｕｐ，” ｉｎ ＡＣＭ ＣＣＳ，２０１８に見出すことができ、これは、参照により本明細書に組み込まれる。これらは単なる例であり、他の実施形態で他のタイプのプロトコルを使用することができる。

ここで、ＤＥＣＯの例示的な実施形態によって解決される問題を述べ、そのアーキテクチャの高レベルの概要を提示する。

問題のステートメント：非集中型オラクル
本明細書における例示的な実施形態は、「オラクル」、すなわちオンラインデータの起源および特性を証明することができるエンティティ、を構築するためのプロトコルを提供する。目標は、証明器Ｐが、一データが特定のウェブサイトＳを出所とすることを検証器Ｖに対して証明し、任意選択で、そのようなデータに関するステートメントをゼロ知識で証明し、データ自体を秘密に保持することを可能にすることである。データにアクセスすることは、Ｐからの非公開入力（例えば、パスワード）を必要とし得、そのような非公開情報もまた、Ｖから秘密に保持する必要がある。

例示的な実施形態では、インターネット上の広くデプロイされたセキュリティプロトコルスイートであるＴＬＳを実行するサーバに焦点を当てる。ただし、ＴＬＳは、単独ではデータ起源を証明しない。ＴＬＳは、認証に公開鍵署名を使用するが、各セッションの開始時に確立された共有セッション鍵を使用して、交換されたメッセージの完全性および機密性を保護するために、対称鍵プリミティブを使用する。それゆえ、この対称鍵を知っているＰは、暗号で認証されたＴＬＳデータに関するステートメントを第三者に対して証明することができない。

ウェブサーバ自体は、例えば単にデータに署名することによって、オラクルの役割を引き受け得る。ただし、サーバによって推進されるオラクルの場合、高い採用コストをもたらすだけでなく、ユーザを不利な状況に置き、ウェブサーバは、オラクルの能力に任意の制約を課し得る。データを提供するウェブサーバのような単一の中央制御点に依存する必要なく、誰でも自分がアクセスできるデータの起源を証明することができるスキームが興味の対象である。

例示的な実施形態では、信頼できるハードウェアまたはウェブサーバからの協調に依存しない「非集中型オラクル」と呼んでいるものを導入することによって、これらのおよび他の課題に対処する。この問題は、以前のオラクルよりもはるかに高度であり、それは、サーバがオラクルのコードを変更したり、新しいソフトウェアをデプロイしたりすること、または予測市場の使用を必要とするソリューションを排除すると同時に、データの任意の属性に対する証明をサポートすることによって、これらの以前の手法を超えているためである。

スマートコントラクトの認証済みデータフィード。本明細書で開示される例示的な実施形態の重要なアプリケーションは、スマートコントラクトのために、認証済みデータフィード（ＡＤＦ）、すなわち検証可能な起源および正確性を有するデータ、を構築することにある。遊離にも、多種多様な他のアプリケーションが、本明細書に開示される技術によってサポートされる。

ＡＤＦのコンテキストでは、スマートコントラクトは、２ＰＣプロトコルに参加することができないことから、スマートコントラクトは、オラクルノードに代わってＶとして参加するオラクルノードに依存しなければならない。したがって、いくつかの実施形態では、非集中型オラクルネットワークでＤＥＣＯをデプロイし、この場合に、独立して動作するオラクルのセットが、スマートコントラクトが使用するために利用可能である。ＤＥＣＯを実行するオラクルは、プライバシーのためではなく、完全性のためのみに信頼されることに留意されたい。スマートコントラクトは、複数のオラクルにクエリし、かつ例えば多数決の同意を必要とすることによって、完全性欠陥に対してさらにヘッジすることができる。ＤＥＣＯのプライバシーは、すべてのオラクルが危殆化されても維持されることを強調しておく。したがって、ＤＥＣＯは、オラクルから非公開データを秘匿しながら、非公開データから導出されたＡＤＦをスマートコントラクトに提供することを可能にする。

表記および定義
いくつかの実施形態では、Ｐを使用して証明器を、Ｖを使用して検証器を、またＳを使用してＴＬＳサーバを表す。太字の文字（例えば

）を使用してベクトルを表し、Ｍ_ｉを使用して

のｉ番目の要素を表す。

図３に例示されるように、理想的な機能性Ｆ_{Ｏｒａｃｌｅ}を使用してオラクルの本質的な特性をモデル化する。Ｆ_{Ｏｒａｃｌｅ}の並列実行を分離するために、すべてのメッセージに、ｓｉｄと表された一意のセッションｉｄでタグ付けする。追加のまたは代替的のオラクル特性を、他の実施形態で使用することができる。

図３に示されるように、本実施形態でのＦ_{Ｏｒａｃｌｅ}は、Ｐからの秘密パラメータθ_ｓ（例えば、パスワード）、クエリテンプレートＱｕｅｒｙ、およびＶからのステートメントＳｔｍｔを受け入れる。クエリテンプレートは、Ｐの秘密θ_ｓを取得し、かつＶによって指定された公開パラメータを含む完全なクエリを返す関数である。例示的なクエリテンプレートは、Ｑｕｅｒｙ（θ_ｓ）“ｓｔｏｃｋ ｐｒｉｃｅ ｏｆ ＧＯＯＧ ｏｎ Ｊａｎ． １ｓｔ，２０２０ ｗｉｔｈ ＡＰＩ ｋｅｙ＝θ_ｓ”であろう。証明器Ｐは、秘密を明示することなく、サーバに送信されたクエリが、うまく形成されている、すなわちテンプレートから構築されている、ことを後で証明することができる。ステートメントＳｔｍｔは、Ｖがサーバの応答時に評価したい関数である。前の例に従って、応答Ｒが数値であるため、以下のステートメントは、それを閾値と比較するであろう：Ｓｔｍｔ（Ｒ）＝“Ｒ＞＄１，０００”。

Ｐがクエリテンプレートおよびステートメントを確認した（「ｏｋ」およびθ_ｓを送信することによって）後、Ｆ_{Ｏｒａｃｌｅ}は、テンプレートから、構築されたクエリを使用してＳからの応答Ｒを取り出す。正直なサーバを想定しているため、Ｒは、グランドトゥルースである。Ｆ_{Ｏｒａｃｌｅ}は、Ｓｔｍｔ（Ｒ）およびデータソースをＶに送信する。

サーバサイドの修正または協調を必要としない、すなわちＳが未修正のＴＬＳプロトコルに従う、非集中型のオラクルにおいて、この実施形態での興味の対象である。より具体的には、ＴＬＳの非集中型オラクルプロトコルは、場合によってはアプリケーション層プロトコルとともに、１）ＰｒｏｔがＦ_{Ｏｒａｃｌｅ}を実現し、かつ２）Ｐｒｏｔ_Ｓが標準のＴＬＳであるような、三者プロトコル

である。

敵対者モデルおよびセキュリティ特性。例示的な実施形態では、静的で悪意のあるネットワーク敵対者Ａを考える。損なわれたパーティは、任意にプロトコルから逸脱し、これらのパーティの状態をＡに明示し得る。ネットワーク敵対者として、Ａは、ＴＬＳが長さを秘匿しないことから、Ｆ_{Ｏｒａｃｌｅ}からのメッセージ長を知得する。ＰおよびＶは、Ｓによって実行されるアプリケーション層プロトコルに従って、適切なクエリ（例えば、このクエリは、ほとんどのアプリケーションに対して冪等性であるはずである）およびステートメントを選定し、これらに合意するものとする。

所与のクエリＱについて、サーバの正直な応答をＳ（Ｑ）によって表す。ＰまたはＶのいずれかが損なわれている場合、セキュリティが持続することを必要とする。機能性Ｆ_{Ｏｒａｃｌｅ}は、以下のセキュリティ保証を反映する：

・証明器－完全性：悪意のあるＰは、コンテンツの起源を偽造することができず、Ｓに無効なクエリを受け入れさせたり、有効なクエリに誤って応答させたりすることもできない。具体的には、検証器が（Ｑｕｅｒｙ、Ｓｔｍｔ）を入力し、かつ（ｂ、Ｓ）を出力する場合には、Ｐは、ＴＬＳセッションでＱ＝Ｑｕｅｒｙ（θ_ｓ）をＳに送信し、ｂ＝Ｓｔｍｔ（Ｒ）のような応答Ｒ＝Ｓ（Ｑ）を受信しなければならない。

・検証器－完全性：悪意のあるＶは、Ｐに誤った応答を受信させることができない。具体的には、Ｐが（Ｑ、Ｒ）を出力する場合には、Ｒは、Ｐによって提出されたクエリＱに対するサーバの応答でなければならない、すなわち、Ｒ＝Ｓ（Ｑ）である。

・プライバシー：悪意のあるＶは、公開情報（Ｑｕｅｒｙ、Ｓ）およびＳｔｍｔ（Ｒ）の評価のみを知得する。

すり替えプロトコル
例示的な実施形態では、２つの広く使用される代表的なＴＬＳ暗号スイートに焦点を当てる：ＣＢＣ－ＨＭＡＣおよびＡＥＳ－ＧＣＭ。当技術は、他の暗号（例えば、Ｃｈａｃｈａ２０－Ｐｏｌｙ１３０５など）にも同様に一般化される。最初にＣＢＣ－ＨＭＡＣを使用して、特定の実施形態を例示し、後で、ＡＥＳ－ＧＣＭのための技術について記載する。

ＴＬＳは、通信の各方向に別個の鍵を使用する。明示的に指定されていない限り、２つを区別せずに、ｋ^Ｅｎｃおよびｋ^ＭＡＣを使用して両方向のセッション鍵を表記する。

ＤＥＣＯの例示的な実施形態を提示する際には、すり替えプロトコルから始めて、完全なプロトコルまで段階的に構築する。

（Ｐ，Ｖ）間でＦ_{Ｏｒａｃｌｅ}を実現するすり替えプロトコルは、以下の通りである。Ｐは、サーバＳにクエリし、サーバに送信されたメッセージおよびサーバから受信されたメッセージをすべて、それぞれ、

および

に記録する。

および

をセッション鍵とする。

次いで、彼女は、ゼロ知識で、１）各

が、

平文レコードおよびＭＡＣタグに復号化されることと、２）Ｒ_ｉについての各ＭＡＣタグσ_ｉが、ｋ^ＭＡＣに対して検証されることと、３）所望のステートメントが、応答時にｂ、すなわち

と評価されることを証明する。標準の表記を使用して、Ｐは、以下を計算する。

彼女はまた、

が、同様に証明ｐ_ｑで

としてうまく形成されていることを証明し、

をＶに送信する。

が、ＴＬＳセッションの真正なトランスクリプトであることを考えると、証明器－完全性特性は、持続するように見える。直感的には、ＣＢＣ－ＨＭＡＣ暗号文は、基礎となる平文に対して拘束性があり、したがって、

を、セッションデータに対するセキュアなコミットメントとして扱うことができる。すなわち、一意のメッセージに対してのみ、所与の

をオープンする（すなわち、復号化し、ＭＡＣチェックする）ことができる。拘束性は、サーバとの元のセッションとは異なるメッセージに対してＰが

をオープンすることを防止する。

残念ながら、この直感には欠陥がある。すり替えプロトコルは

の真正性を保証できないため、完全に失敗する。証明器Ｐは、セッション鍵を有し、したがって、任意のメッセージの暗号化を

に含めることができる。

その上、Ｐが構築する必要があるゼロ知識証明は、トランスクリプト全体を復号化し、ハッシュ化することを伴い、このことは、極めて高価であり得る。プロトコルを実用化するには、コストを大幅に低減する必要がある。

ＤＥＣＯの概要
上述のすり替え手法の重大な失敗は、Ｐが、Ｐがセッションにコミットする前にセッション鍵を知得することである。ＤＥＣＯの例示的な実施形態では、ＭＡＣ鍵は、ＰがコミットするまでＰに対して差し止められる。

ＰとサーバＳとの間のＴＬＳセッションは、機密性および完全性を提供しなければならない。その上、プロトコルは、ＴＬＳの要件を下回って性能を低下させ（例えば、タイムアウトをトリガーし）てはならない。

図４は、例示的な実施形態における、サーバデバイス、証明器デバイス、および検証器デバイスを備える例示的なＤＥＣＯ実装態様を示す。本実施形態でのＤＥＣＯは、３フェーズプロトコルとして実装されている。第１のフェーズは、証明器Ｐ、検証器Ｖ、およびＴＬＳサーバＳが、ＰとＶとの間で秘密分散されるセッション鍵を確立する、新規な三者ハンドシェイクプロトコルである。ハンドシェイクは、標準のＴＬＳプロトコルに従ってＰがサーバにアクセスするが、Ｖの助力を伴うクエリ実行フェーズである。Ｐがクエリおよび応答にコミットした後、Ｖは、彼女の鍵シェアを明示する。最後に、Ｐは、証明生成フェーズでの応答に関するステートメントを証明する。

三者ハンドシェイク。本質的に、ＰおよびＶは、合同でＴＬＳクライアントとして作用する。ＰおよびＶは、秘密分散された形態でＳと共有セッション鍵をネゴシエートする。このフェーズは、ＤＥＣＯの残りのものと同様に、Ｓに対して完全に透過的であり、サーバサイドの修正を必要としないことを強調しておく。

ＣＢＣ－ＨＭＡＣ暗号スイートについて、三者ハンドシェイクの最後に、ＰおよびＶは、それぞれ

および

を受信する一方、Ｓは、

を受信する。標準のハンドシェイクと同様に、ＰとＳとの両方が暗号鍵ｋ^Ｅｎｃを取得する。

三者ハンドシェイクは、前述のセッションデータのコミットメントを、以下のように非偽造可能にすることができる。セッションの最後に、Ｐは、最初に以前のように

のセッションにコミットし、次いで、Ｖは、彼女のシェア

を明示する。Ｖの観点から、三者ハンドシェイクプロトコルは、潜在的な悪意のある証明器の影響にも関わらず、あらゆるセッションに新鮮なＭＡＣ鍵（各方向に対して）が使用され、Ｐがコミットするまで鍵がＰに知られていないことを保証する。ＭＡＣ鍵の知識がなければ、Ｐは、セッションデータにコミットする前にセッションデータを偽造するか、または改ざんすることができない。したがって、ＤＥＣＯにおけるセッションデータのコミットメントの非偽造可能性は、ＴＬＳで使用されるＭＡＣスキームの非偽造可能性に低下する。

ＧＣＭなどの他の暗号スイートを、同様にサポートすることができる。ＧＣＭでは、暗号化とＭＡＣとの両方に（各方向に対して）単一の鍵が使用される。ハンドシェイクプロトコルは、同様に、ＰとＶとの間の鍵を秘密分散する。ＧＣＭのためのハンドシェイクプロトコルは、本明細書の他の箇所でより詳細に記載される。

クエリ実行。述べたように、セッション鍵は秘密分散されることから、ＰおよびＶは、対話型プロトコルを実行して、クエリを暗号化するＴＬＳメッセージを構築する。次いで、Ｐは、標準のＴＬＳクライアントとしてＳにメッセージを送信する。ＣＢＣ－ＨＭＡＣについて、ＰおよびＶは、クエリのＭＡＣタグを計算する一方、ＧＣＭは、認証された暗号化を実行する。クエリは、Ｐに対して非公開であり、Ｖに漏洩されるべきではないことに留意されたい。包括的な２ＰＣの場合、大きなクエリには高価であるため、代わりに、本明細書の他の箇所に記載されるように、包括的なソリューションよりも効率的なオーダオブマグニチュードであるカスタム２ＰＣプロトコルを導入する。

前に説明したように、Ｐは、Ｖの鍵シェアを受け取る前に、セッションデータ

にコミットし、コミットメントを非偽造可能にする。次いで、Ｐは、ここで記載するように、応答の完全性を検証し、そのことに関するステートメントを証明することができる。

証明生成。非偽造可能なコミットメントでは、Ｐがコミットメント

を完全に開く（すなわち、暗号鍵を明示する）場合には、Ｖは、復号化時にＭＡＣをチェックすることによって、

の真正性を容易に検証し得る。

ただし、

に対する暗号鍵を明示すれば、プライバシーに違反するであろうし、このことにより、ＰとＳとの間で交換されたすべてのセッションデータが明示されるであろう。理論的には、Ｐが、代わりに、

全体にわたる任意のステートメントＳｔｍｔをゼロ知識で（すなわち、暗号鍵を明示することなく）証明し得る。しかし、包括的なゼロ知識証明技術の場合、Ｓｔｍｔの多くの自然な選定にとって非常に高価であろう。

代わりに、ＤＥＣＯは、広範な一般的なクラスのステートメント、すなわち本明細書でＴＬＳセッショントランスクリプトの「選択的開示」と呼ばれるもの、についての効率的な証明をサポートするための２つの技術を導入する。選択的開示は、サブストリングをＶに明示するか、または黒塗りする、すなわち、サブストリングを削除し、それをＶから隠すか、のいずれかを伴う。

図５は、例示的な例として、証明器として作用するユーザボブのための簡略化されたＪＳＯＮ銀行ステートメントを示す。この例を使用して、選択的開示およびコンテキスト完全性攻撃を実証する。ボブ（Ｐ）が自分のチェッキング口座残高をＶに明示したいと仮定する。彼のＴＬＳセッションの復号化鍵を明示するとすれば、望ましくないであろうし、その場合は、彼のトランザクションを含むステートメント全体も明示されるであろう。代わりに、本明細書で開示される技術を使用して、ボブは、５～７行目のサブストリングのみを効率的に明示することができる。代替的に、彼がセービング口座残高を明示しても構わない場合、彼は、７行目以降の彼のトランザクションを黒塗りしてもよい。

サブストリングを明示し、黒塗りする、２つの選択的開示モードは、有用なプライバシー保護メカニズムである。これらの選択的開示モードはまた、後続のゼロ知識証明の前処理としても機能することができる。例えば、ボブは、実際の残高を明示せずに、１０００ドルを超える残高がある口座を有することを証明したい場合がある。その場合に、彼は、彼のチェッキング口座残高を含むサブストリング全体にわたる属性（「残高＞１０００ドル」）をゼロ知識で証明するであろう。

しかしながら、選択的開示単独では、多くの用途には不十分である。これは、サブストリングのコンテキストがこのサブストリングの意味に影響を与えるからである。コンテキスト完全性と呼ばれるものがなければ、Ｐは、不正行為を行い、Ｖへの請求を証明するように誤って見えるサブストリングを明示することができる。例えば、ボブは、１０００ドルを上回る残高を有していない場合がある。しかし、銀行ステートメントを見た後、彼は、同じＴＬＳセッションで「残高」：５０００ドルというサブストリングでカスタマーサービスにメッセージを投稿し、次いで、彼の保留中のメッセージを（リフレクション攻撃の形態で）映示し得る。次いで、彼は、このサブストリングを愚か者Ｖに明示し得る。

証明器によって供給されたＶへの入力に関する様々なサニタイズヒューリスティック、例えばセッショントランスクリプトの切り捨て、は、いくつかのそのような攻撃を潜在的に防止し得るが、他の形式のウェブアプリケーションの入力サニタイズと同様に、脆弱であり、攻撃されやすい。

代わりに、セッションデータを明示的に、しかも機密的に構文解析する厳密な技術を導入する。この技術を「ゼロ知識２段構文解析」と呼ぶ。この技術によれば、Ｐは、第１の段階で

を局所的に構文解析し、次いで、結果として生じるサブストリングに対する制約に関するステートメントをゼロ知識でＶに対して証明する。例えば、当銀行例では、銀行によって提供される鍵－値ストアを、識別される文字λとともに常に逸する場合には、ボブは、局所的な構文解析を介して、λが５０００ドルに先行するサブストリング「残高」を抽出し、かつＶに明示することによって、正しい残高を証明し得る。この２フェーズ手法は、非常に一般的なクラスのウェブＡＰＩ文法（一意の鍵）に対して、より包括的な技術よりもはるかに効率的な証明を生じさせることを示すことができる。

図６は、上記で紹介したＤＥＣＯプロトコルのより詳細な例示的な実装態様示す。この実施形態では、ＤＥＣＯプロトコルは、三者ハンドシェイクフェーズ、続く、クエリ実行フェーズのための２ＰＣプロトコル、および証明生成フェーズを含む。これらのフェーズの各々について、以下でより詳細に記載する。この実施形態の特定の詳細は、本明細書で開示される他の実施形態と同様に、例としてのみ提示され、いかなるようにも限定されるものと解釈されるものではないことを認識されたい。当業者は、追加的または代替的な技術が使用され得ることを認知するであろう。

三者ハンドシェイク
いくつかの実施形態では、三者ハンドシェイク（３Ｐ－ＨＳ）の目標は、サーバＳに対して完全に透過的に、サーバＳとのＴＬＳセッションで使用されるセッション鍵を、証明器Ｐと検証器Ｖとの間で秘密分散することである。まず、説明のためにＣＢＣ－ＨＭＡＣに焦点を当て、次いで、ＧＣＭをサポートするようにプロトコルを適合させる。

図７は、例示的な実施形態における、三者ハンドシェイクプロトコルの正式な仕様を示す。

図８は、いくつかの実施形態における、三者ハンドシェイクプロトコルの一部である例示的なＥＣｔＦプロトコルを示す。

ここでも、これらのプロトコルの特定の詳細は、例にすぎず、いかようにも限定するものではない。例えば、証明器、検証器、およびサーバを伴う多種多様な他のタイプの三者ハンドシェイクプロトコルを、他の実施形態で使用することができる。したがって、本明細書で使用される「三者ハンドシェイクプロトコル」という用語は、広く解釈されることが意図されている。

標準のＴＬＳハンドシェイクと同様に、３Ｐ－ＨＳは、２つのステップを含む：第一に、ＰおよびＶは、ＴＬＳ互換鍵交換プロトコルを通じてサーバと共有される秘密

の加法的シェアを計算する。ここではＥＣＤＨＥが推奨され、これに焦点が当てられているが、他の技術を使用してシェアを計算することができ、第二に、ＰおよびＶは、ＴＬＳ－ＰＲＦを、入力としてのＺのＰおよびＶのシェアでセキュアに評価することによって秘密分散されたセッション鍵を導出し、ここで、ＰＲＦは、擬似ランダム関数を表す。以下では、理解のために正式な仕様書を必要としないように、テキストの説明を与える。

ステップ１：鍵交換。

で、ＥＣＤＨＥで使用されるＥＣ群を表し、Ｇで、その生成子を表す。

証明器Ｐは、定期的なＴＬＳハンドシェイク要求およびランダムなノンスｒ_ｃをＳに（ＣｌｉｅｎｔＨｅｌｌｏメッセージで）送信することによって、ハンドシェイクを開始する。証明書、サーバノンスｒ_ｓ、およびＳからの署名された一時的なＤＨ公開鍵Ｙ_Ｓ＝ｓ_Ｓ・Ｇを（Ｓｅｒｖｅｒ－ＨｅｌｌｏおよびＳｅｒｖｅｒＫｅｙＥｘｃｈａｎｇｅメッセージで）受信すると、Ｐは、証明書および署名をチェックし、それらをＶに転送する。同じチェックを実行した後、Ｖは、秘密ｓ_Ｖをサンプリングし、ＤＨ公開鍵Ｙ_Ｖ＝ｓ_Ｖ・Ｇの彼女の部分をＰに送信し、次いで、Ｐは、別の秘密ｓ_Ｐをサンプリングし、組み合わされたＤＨ公開鍵Ｙ_Ｐ＝ｓ_Ｐ・Ｇ＋Ｙ_ＶをＳに送信する。

サーバＳは標準のＴＬＳを実行することから、Ｓは、ＤＨ秘密を、Ｚ＝ｓ_Ｓ・Ｙ_Ｐ・Ｐ（およびＶ）がＺのそのシェアをＺ_Ｐ＝ｓ_Ｐ・Ｙ_Ｓ（およびＺ_Ｖ＝ｓ_Ｖ・Ｙ_Ｓ）として計算するように計算する。なお、Ｚ＝Ｚ_Ｐ＋Ｚ_Ｖであり、＋は、

の群演算である。選定された群で離散対数問題が難しいと仮定すると、Ｚは、いずれのパーティにも知られていない。

ステップ２：鍵導出。ＰおよびＶがＺの加法的シェアを（ＥＣポイントの形態で）確立したため、ＰおよびＶは、先へ進んで、Ｚのｘ座標で鍵を付けたＴＬＳ－ＰＲＦを評価することによって、セッション鍵を導出する。

ここでの技術的課題は、算術演算（すなわち、

の加算）を２ＰＣでのビット演算（すなわち、ＴＬＳ－ＰＲＦ）と調和させることである。ブール回路が大きい体の算術にあまり適していないことは、周知である。具体的な推定として、ｘ座標のみをもたらすＥＣ点加算は、４つの減算、１つのモジュラー反転、および２つのモジュラー乗算を伴う。高度に最適化された回路に基づくＡＮＤ複雑さの推定は、減算、乗算、およびモジュラー還元のためだけの９００，０００を超えるＡＮＤゲートをもたらし、回路内で拡張ユークリッドアルゴリズムを実行する必要がある反転さえ含まない。

ブール回路にＥＣポイントを追加するという法外なコストに起因して、ＰおよびＶは、図８に示されるＥＣｔＦプロトコルを使用して、

におけるＥＣポイントの加法的シェアを、

におけるこのＥＣポイントのｘ座標の加法的シェアに変換する。次いで、ブール回路は、

に２つの数字を追加することのみを伴い、このことを、約３｜ｐ｜のＡＮＤゲート、すなわちｐが２５６ビットである当実装態様では約７６８のＡＮＤゲート、のみで行うことができる。

ＥＣｔＦを使用するシェア変換。ＥＣｔＦプロトコルは、

のシェアを

のシェアに変換する。ＥＣｔＦプロトコルへの入力は、Ｐ_ｉ＝（ｘ_ｉｙ_ｉ）で表される２つのＥＣポイント

である。

と仮定し、ここで、

は、ＥＣ群演算であり、プロトコルの出力は、α＋β＝ｘ_ｓのような

である。具体的には、考えている曲線について、ｘ_ｓ－λ^２－ｘ_１－ｘ_２であり、式中、λ＝（ｙ_２－ｙ_１）／（ｘ_２－ｘ_１）。ｙ_ｓのシェアを同様に計算することができるが、ＴＬＳはｘ_ｓのみを使用することから、それを省略する。

ＥＣｔＦは、乗法的－加法的（ＭｔＡ）シェア変換プロトコルをビルドブロックとして使用する。α，β：＝ＭｔＡ（α，ｂ）を使用して、アリスとボブとの間のＭｔＡの実行を、それぞれ入力αおよびｂで表す。実行の最後に、アリスおよびボブは、ａ・ｂ＝α＋βのようなαおよびβを受け取る。このプロトコルを一般化して、通信の複雑さを増大させることなく、ベクトル入力を処理することができる。すなわち、ベクトル

について、

の場合には、

ここで、ＥＣｔＦのプロトコルについて記載する。ＥＣｔＦは、２つの主な成分を有する。［α］で、αの２アウトオブ２共有を表す、すなわち、［α］＝（α_１，α_２）で、ｉ∈｛１，２｝について、パーティｉがα_ｉを有すると同時に、α＝α_１＋α_２となる。第１の成分は、シェア反転である：［α］が与えられると、［α^－１］を計算する。これを以下のように行うことができる：パーティｉは、ランダム値ｒ_ｉをサンプリングし、ＭｔＡを実行して、δ_１，δ_２：＝ＭｔＡ（（α_１，ｒ_１），（ｒ_２，α_２））を計算する。なお、δ_１＋δ_２＝α_１・ｒ_２＋α_２・ｒ_１。パーティｉは、ｖ_ｉ＝δ_ｉ＋α_ｉ・ｒ_１を公開し、したがって、両パーティは、ｖ＝ｖ_１＋ｖ_２を知得する。最後に、パーティｉは、β_ｉ＝ｒ_ｉ・ｖ^－１を出力する。プロトコルは、β_１＋β_２＝α^－１であるため、α^－１の正しい共有を計算する。その上、ＭｔＡがセキュアであると仮定して、プロトコルは、αをどのパーティにも漏洩しない。実際、パーティｉのビューは、（α_１＋α_２）（ｒ_１＋ｒ_１）からなり、ｒ_ｉが一様にランダムであることから、これは、一様にランダムである。

第２の成分は、シェア乗算である：［α］、［ｂ］が与えられると、［αｂ］を計算する。［αｂ］を、ＭｔＡを使用して次のように計算することができる：パーティは、ＭｔＡを実行して、α_１＋α_２＝α_１・ｂ_２＋α_２・ｂ_２のような、α_１，α_２を計算する。次いで、パーティｉは、ｍ_ｉ＝α_ｉ＋α_ｉ・ｙ_ｉを出力する。プロトコルのセキュリティおよび正確性を、上記と同様に議論することができる。

ＴＬＳ－ＰＲＦのセキュアな評価。Ｚのｘ座標のシェア、ＥＣｔＦにおけるＴＬＳのいわゆるプレマスタシークレットを計算すると、ＰおよびＶは、２ＰＣにおけるＴＬＳ－ＰＲＦを評価してセッション鍵を導出する。知られているＳＨＡ－２５６回路を使用して、ＴＬＳハンドシェイク回路を手動で最適化し、合計７７９，２１３のＡＮＤ回路の複雑さをもたらす。

ＧＣＭをサポートするための適合。ＧＣＭでは、暗号化とＭＡＣとの両方に（各方向に対して）単一の鍵が使用される。上記のプロトコルをＴＬＳ１．２のＧＣＭをサポートするように適合させることは、直截的である。ＧＣＭ鍵がより短いため、第１のステップは、同一のままであろう一方、第２のステップの出力は、切り捨てる必要がある。

ＴＬＳ１．３への適合。ＴＬＳ１．３をサポートするためには、３Ｐ－ＨＳプロトコルを、新しいハンドシェイクフローおよび異なる鍵導出回路に適合させなければならない。特に、ここでは、ＳｅｒｖｅｒＨｅｌｌｏ後のすべてのハンドシェイクメッセージが、暗号化される。ナイーブ戦略の場合、それらを２ＰＣにおいて復号化するであろうし、このことは、証明書が通常大きいため、コストがかかるであろう。しかしながら、ＴＬＳ１．３の鍵独立性特性のおかげで、本明細書の他の箇所に記載されるように、ＴＬＳ１．２の場合と同様の複雑さを有する３Ｐ－ＨＳプロトコルを構築することができる。

クエリ実行
ハンドシェイク後、証明器Ｐは、標準のＴＬＳクライアントとして彼女のクエリＱをサーバＳに送信するが、検証器Ｖの助力を伴う。具体的には、セッション鍵が秘密分散されることから、２つのパーティは、インタラクトし、２ＰＣプロトコルを実行して、Ｑを暗号化するＴＬＳレコードを構築する必要がある。包括的な２ＰＣであれば、理論的には十分であろうが、大きなクエリには高価であろう。代わりに、より効率的なオーダオブマグニチュードであるカスタム２ＰＣプロトコルを導入する。

まず、何らかの応答を受け取る前にＰがＳにすべてのクエリを送信するワンラウンドセッションに焦点を当てる。ＤＥＣＯのほとんどのアプリケーション、例えばＨＴＴＰ ＧＥＴを介して取得されたコンテンツの起源を証明すること、は、ワンラウンドである。ＤＥＣＯを拡張してマルチラウンドセッションをサポートすることは、本明細書の他の箇所に記載される。

ＣＢＣ－ＨＭＡＣ。ＰおよびＶがＭＡＣ鍵のシェアを保持する一方、Ｐは暗号鍵を保持することを思い起こされたい。Ｐに対して潜在的に非公開のＱを暗号化するＴＬＳレコードを構築するために、２つのパーティは、まず、２ＰＣプロトコルを実行して、ＱのＨＭＡＣタグτを計算し、次いで、Ｐは、Ｑ｜｜τをローカルで暗号化し、Ｓに暗号文を送信する。

ＨでＳＨＡ－２５６を表す。鍵ｋを用いたメッセージｍのＨＭＡＣが以下であることを思い起こされたい。

ｉｐａｄおよびｏｐａｄという用語は、ＨＭＡＣアルゴリズムにおいて利用されるそれぞれの「内部」および「外部」の値を表す。２ＰＣではクエリ全体をハッシュして内部ハッシュを計算する必要があるため、直接的な２ＰＣの実装態様というのは、大規模なクエリには高価であろう。このことは、有利なことに、例示的な実施形態では、Ｐに対して局所的な（すなわち、２ＰＣなしで）内部ハッシュの計算をすることによって、回避される。Ｐが

を知っているとすれば、彼女は、内部ハッシュを計算することができる。しかし、単にＰに

を与えることは、彼女が次いでｋを知得してＭＡＣを偽造し得るため、できない。

当最適化は、ＳＨＡ－２５６のＭｅｒｋｌｅ－Ｄａｍｇａｒｄ構造を利用する。ｍ_１およびｍ_２が、２つの正しいサイズのブロックであると仮定する。次いで、

を

として計算し、ここで、ｆ_Ｈは、Ｈの一方向性圧縮関数を表し、ＩＶは初期ベクトルを表す。

図９は、ＣＢＣ－ＨＭＡＣのポストハンドシェイクプロトコルを示す。

三者ハンドシェイク後、ＰおよびＶは、単純な２ＰＣプロトコルを実行して、

を計算し、それをPに明示する。メッセージmの内部ハッシュを計算するために、Pは、単にｓ_０をＩＶとして使用して、ｍのハッシュを計算する。ｆ_Ｈが一方向性であるものとしているため、ｓ_０を明示することにより、ｋ^ＭＡＣは明示されない。ＨＭＡＣ（ｋ，ｍ）を計算するために、次いで、内部ハッシュに対する２ＰＣでの、はるかに短いメッセージである外部ハッシュを計算することを伴う。したがって、包括的な２ＰＣを用いた各レコードの最大２５６のＳＨＡ－２ブロックとは対照的に、クエリ長に関わらず、２ＰＣの計算量が、数ブロックにうまく低減される。

ＡＥＳ－ＧＣＭ。ＧＣＭについて、ＰおよびＶは、Ｑの認証された暗号化を実行する。２ＰＣ－ＡＥＳは、最適化された回路では直截的であるが、大規模なクエリのためのタグを計算することは、各レコードについて大規模な体における長い多項式を評価することを伴うため、高価である。最適化された当プロトコルは、本明細書の他の箇所により詳細に記載されるように、事前計算により局所的な多項式評価を行う。２ＰＣ－ＧＣＭがタグ作成だけでなく、ＡＥＳ暗号化も伴うことから、そのことにより、ＣＢＣ－ＨＭＡＣよりも高い計算コストおよびレイテンシが発生する。

本明細書に開示される他の実施形態は、追加の信頼仮定を有する、ポストハンドシェイク２ＰＣプロトコルを完全に回避する、プロキシモードプロトコルと呼ばれる非常に効率的な代替プロトコルを利用する。

図６に示される完全なＤＥＣＯプロトコルに例示されるように、サーバにクエリし、かつ応答を受信した後、Ｐは、Ｖに暗号文を送信することによってセッションにコミットし、ＶのＭＡＣ鍵シェアを受信する。次いで、Ｐは、応答の完全性を検証し、それに関するステートメントを証明することができる。図６は、ＣＢＣ－ＨＭＡＣのための完全なＤＥＣＯプロトコルを特定している。ＧＣＭのためのＤＥＣＯプロトコルは、同様であり、本明細書の他の箇所に記載されている。

明確にするために、ゼロ知識証明の詳細を理想的な機能性Ｆ_ＺＫで抽象化する。ｘおよびｗがそれぞれ非公開証人および公開証人であるＰから受信する（「証明する」、ｘ、ｗ）と、Ｆ_ＺＫは、ｗおよび関係π（ｘ，ｗ）∈｛０，１｝（以下に定義される）をＶに送信する。具体的には、ＣＢＣ－ＨＭＡＣについて、ｘ、ｗ、πは、以下として定義される：

および

関係π（ｘ，ｗ）は、（１）

（および

）が鍵ｋ^Ｅｎｃ、ｋ^ＭＡＣの下でＱ（およびＲ）のＣＢＣ－ＨＭＡＣ暗号文であり、（２）Ｑｕｅｒｙ（θ_ｓ）＝Ｑ、かつ（３）Ｓｔｍｔ（Ｒ）＝ｂの場合にのみ、１を出力する。それ以外の場合は、０を出力する。

セキュアな２ＰＣおよびＺＫＰの機能性を前提にすると、図６に例示されるなＰｒｏｔ_ＤＥＣＯは、悪意のある敵対者に対して図３のＦ_{Ｏｒａｃｌｅ}をＵＣセキュアに実現することを示すことができる。

より具体的には、三者ハンドシェイクで使用されるグループでは個別的なログ問題が難しく、ｆ（ＳＨＡ－２５６の圧縮関数）がランダムなオラクルであるものとすると、Ｐｒｏｔ_ＤＥＣＯは、中止を伴う静的な悪意のある敵対者に対して、（Ｆ_２ＰＣ、Ｆ_ＺＫ）ハイブリッド世界のＦ_{Ｏｒａｃｌｅ}をＵＣセキュアに実現する。

ＧＣＭのプロトコルは、同様のフローを有する。三者ハンドシェイクおよびクエリ構築プロトコルのＧＣＭ変形例について上述した。

図１０は、タグを検証し、ＧＣＭ変形例でのレコードを復号化するための２ＰＣプロトコルを示す。これらは、ＧＣＭのポストハンドシェイクプロトコルとも呼ばれる。

ＣＢＣ－ＨＭＡＣとは異なり、ＧＣＭは、コミットしていない：鍵ｋで暗号化された所与の暗号文Ｃについて、ｋを知っている者は、完全性チェックをパスしながら、Ｃを異なる平文に復号化するｋ’≠ｋを効率的に見つけることができる。そのような攻撃を防止するために、Ｐが、Ｖの鍵シェアを知得する前に、彼女の鍵シェアｋ_Ｐに対してコミットすることを必要とする。証明生成フェーズでは、ＱおよびＲに関するステートメントを証明することに加えて、Ｐは、

および

を復号化するために使用されるセッション鍵がｋ_Ｐへのコミットメントに対して有効であることを証明する必要がある。ＧＣＭ変形例のセキュリティの証明は、ＣＢＣ－ＨＭＡＣの証明と同様である。

証明生成
証明器Ｐが、ＴＬＳセッションの暗号文

に対してコミットし、平文

が特定の特性を満たすことをＶに対して証明することを思い起こされたい。一般性を失うことなく、

および

は、１つのＴＬＳレコードのみを含むものとし、以後、それらを暗号文レコードおよび平文レコードと呼ぶ。マルチレコードセッションを、各レコードに対してプロトコルを繰り返すことによって、処理することができる。

の起源のみを証明することは、容易である：暗号鍵を明示するだけである。しかし、このことは、プライバシーを犠牲にする。代替的に、Ｐは、一般のゼロ知識技術を使用すれば、

に関する任意のステートメントを証明することができる。しかし、そのような証明は、多くの場合、高価である。

以下の説明では、例示的なアプリケーションに最適化された２つのクラスのステートメントを提示する：応答のサブストリングのみを、その起源を証明しながら明示すること（「選択的開示」）、または明示されたサブストリングがＶによって想定されるコンテキストに現れることをさらに証明すること（「２段階構文解析によるコンテキスト完全性」）。

選択的開示。例示的な実施形態は、Ｐが平文内のサブストリングを効率的に明示するか、または黒塗りすることを可能にする、本明細書で「選択的開示」と呼ばれる技術を実装している。平文レコードがチャンク

で構成されていると仮定する（チャンクの詳細については以下で議論される）。選択的開示は、Ｐが、

の残りの部分を明示することなく、

のｉ番目のチャンクがＢ_ｉであることを証明することを可能にする：これを明示モードと呼ぶ。

は、

と同じであるが、チャンクが除去されていることを証明することもできる。これを黒塗りモードと呼ぶ。両モードとも単純であるが、実用的なプライバシー目標に有用である。選択的開示の粒度は、ここで議論する暗号スイートに依存する。

ＣＢＣ－ＨＭＡＣ。証明生成のために、Ｐは、暗号鍵ｋ^ＥｎｃとＭＡＣ鍵ｋ^ＭＡＣとの両方を保持する一方、Ｖは、ＭＡＣ鍵ｋ^ＭＡＣのみを保持することを思い起こされたい。当性能は、ＳＨＡ－２５６およびＡＥＳ－１２８を用いる暗号スイートを前提とし、この暗号スイートは、当実装態様と一致するが、これらの技術は、他のパラメータに適用可能である。ＭＡＣ後暗号化が使用されることを思い起こされたい：平文レコード

は、最大１０２４のＡＥＳブロックのデータと３ブロックのＭＡＣタグσを含み、このことを、

として表し、式中、

である。

は、

のＣＢＣ暗号化であり、同数のブロックからなる：

の式中、

である。

ＴＬＳレコードの明示。

がｋ^Ｅｎｃを明示することなく

を暗号化することを証明するナイーブな方法は、ＺＫＰで各ＡＥＳブロックの正しい暗号化を証明することである。ただし、これには、ＺＫＰで最大１０２７のＡＥＳの呼び出しが必要となり、実用的でない性能をもたらすであろう。

ＭＡＣ後暗号化構造を活用して、ＺＫＰでＡＥＳの３つの呼び出しのみを使用して同じことを行うことができる。このことは、

の最後の数ブロックがタグσを暗号化することを証明することと、平文を直接明示することと、を例示的に伴う。具体的には、Ｐは、

を計算し、

をＶに送信する。次いで、Ｖは、πを検証し、

全体にわたってＭＡＣタグをチェックする（ＶはＭＡＣ鍵を知っていることに留意されたい）。そのセキュリティは、ＨＭＡＣの基礎となるハッシュ関数の衝突耐性に依存し、すなわち、Ｐは、同じタグσを有する

を見つけることができない。

黒塗りされたブロックを有するレコードの明示。ｉ番目のブロックが、Ｐが黒塗りしたい機密情報を含むと仮定する。直接的な戦略は、

および

が、以下を計算することによって、

によって暗号化された平文のプレフィックスおよびサフィックスを形成することを証明することである。

このことは、ＺＫＰで３回のＡＥＳおよび２５６回のＳＨＡ－２５６圧縮を伴うことになるため、高価である。

ＳＨＡ－２５６のＭｅｒｋｌｅ－Ｄａｍｇａｒｄ構造を活用すると、いくつかの最適化が可能である。ｆで、ＳＨＡ－２５６の圧縮関数を表し、ｓ_ｉ－１で、

にｆを適用した後の状態を表す。まず、例えばＢ_ｉがＡＰＩ鍵などの高エントロピーデータを含む場合に、ｓ_ｉ－１とｓ_ｉとの両方を明示することができる場合、上記の目標を、ＺＫＰでただ１回のＳＨＡ－２５６を使用して達成することができる。そするために、Ｐは、

を計算し、

をＶに送信し、Ｖは、１）ｓ_ｉ－１を、

から再計算することによってチェックし、２）πを検証し、３）ＭＡＣタグσを、ｓ_ｉおよび

から再計算することによってチェックする。Ｂ_ｉが高エントロピーであることを前提とし、ｆが一方向性であることから、ｓ_ｉー１およびｓ_ｉは、Ｂ_ｉから漏洩しないことを明示する。

一方、ｓ_ｉ－１とｓ_ｉとの両方をＶに対して明示することができない場合（例えば、Ｂ_ｉに対する総当たり攻撃が実行可能な場合）、ブロックＢ_ｉを含むレコードのプレフィックス（またはサフィックス）をＰに黒塗りさせることによって、コストを依然として低減することができる。その後発生するコストは、ＺＫＰでの２５６－ｉ回のＳＨＡ－２ハッシュである。追加の詳細は、本明細書の他の箇所で提供される。一般に、ＺＫＰコストは、レコードサイズに比例するため、ＴＬＳフラグメンテーションは、コストを一定の係数で低減することもできる。

サフィックスの黒塗り。サフィックス

が黒塗りされる場合、Ｐは、

を計算し、ｓ_ｉは、

にｆを適用した後の状態である。Ｐは、Ｖに

を送信する。次いで、検証器は、１）ｓ_ｉ－１を、

にｆを適用することによってチェックし、２）πを検証する。本質的に、このことのセキュリティは、ｆのプレイメージ耐性から得られる。その上、Ｖは、

がＶから秘密に保持されていることから、黒塗りされたサフィックスを知得しない。合計のコストは、ＺＫＰでの３回のＡＥＳおよび２５６－ｉ回のＳＨＡ－２ハッシュである。

プレフィックスの黒塗り。Ｐは、２つのＺＫＰを計算する：１）

Ｐは、Ｖに

を送信する。検証器は、１）ｓ_ｉ－１がπ_１を使用して正しいことをチェックし、次いで、

を計算して内部ハッシュｉｈを取得し、２）π_２は、計算されたｉｈを使用して検証される。発生するコストは、ＺＫＰでの３回のＡＥＳおよび２５６－ｉ回のＳＨＡ－２ハッシュである。

プレフィックス／サフィックスの黒塗りは、明示された部分が非公開のユーザデータを含まない場合にのみ意味があることに留意されたい。それ以外の場合、Ｐは、すべてのセンシティブブロックを含む最小のサブストリングを見つけ、上記と同様のプレフィックス／サフィックスのいずれかを黒塗りする必要があるであろう。

ＧＣＭ。ＣＢＣ－ＨＭＡＣとは異なり、ブロックを明示することは、ＧＣＭでは非常に効率的である。第一に、Ｐは、ＺＫでの正しさの証明を伴うＡＥＳ（ｋ，ＩＶ）およびＡＥＳ（ｋ，０）を明示し、Ｖが暗号文の完全性を検証することを可能にする。次いで、ｉ番目のブロックを明示するために、Ｐは、正確性の証明を伴うｉ番目のカウンタＣ_ｉ＝ＡＥＳ（ｋ，ｉｎｃ^ｉ（ＩＶ））の暗号化を明示するだけである。Ｖはｉ番目のブロックを

として複合することができる。ＩＶがセッションのパブリックな初期ベクトルであり、ｉｎｃ^ｉ（ＩＶ）は、ｉ回ＩＶを増分することを表す（ｉｎｃの正確な形式は重要でない）。ＴＬＳレコードを明示するために、各ブロックに対して上記のプロトコルを繰り返す。ここでも、追加の詳細は、本明細書の他の箇所で提供される。

まとめると、ＣＢＣ－ＨＭＡＣは、ＤＥＣＯのＴＬＳレコードレベルでの効率的な選択的明示とブロックレベルでの黒塗りとを可能にする一方、ＧＣＭは、ブロックレベルでの効率的な明示を可能にする。選択的開示はまた、後続のゼロ知識証明のための入力長を低減するための前処理として機能することができる。

２段階構文解析によるコンテキスト完全性。多くのアプリケーションに対して、検証器Ｖは、明示されたサブストリングが正しいコンテキストで現れることを検証する必要があり得る。この特性を「コンテキスト完全性」と呼ぶ。以下では、Ｖがコンテキストを指定するための技術と、Ｐがコンテキスト完全性を効率的に証明するための秘術と、を提示する。

説明を容易にするために、以下の当説明では、最初に、明示モード、すなわち、Ｐが、Ｖへのサーバの応答のサブストリングを明示することに焦点を当てる。次いで、黒塗りモードについて記載する。

コンテキストの指定。コンテキストを指定するための当技術は、所与のサーバＳとの間で送信されるＴＬＳ保護されたデータが、ＰとＶとの両方に知られている、明確に定義されたコンテキストフリーの文法Ｇを有するものとしている。表記のわずかな濫用では、Ｇで、文法と文法が指定する言語との両方を表記する。したがって、Ｒ∈Ｇは、Ｇによって与えられた、この言語におけるストリングＲを表す。Ｇは曖昧さがない、すなわちすべてのＲ∈Ｇが一意の関連付けられた構文解析木Ｔ_Ｒを有する、ものとする。ＪＳＯＮおよびＨＴＭＬは、これらの要件を満たす２つの広く使用される言語の例であり、ここでは当焦点である。

次いで、Ｐが、Ｓからのいくつかの応答ＲのサブストリングＲ_ｏｐｅｎを提示する場合、Ｒ_ｏｐｅｎがＶによって想定される特定の方法で生成されるならば、Ｒ_ｏｐｅｎはコンテキスト完全性を有すると言う。具体的には、Ｖは、彼女がＲで有効なサブストリングＲ_ｏｐｅｎを見ることを想定し得る位置のセットＳを指定する。当定義では、Ｓは、Ｇによって定義される構文解析木の根から内部ノードへの経路のセットである。したがって、許容経路と呼ぶｓ∈Ｓは、非終端のシーケンスである。ρ_Ｒで、Ｔ_Ｒ（ＧにおけるＲの構文解析木）の根を表す。Ｔ_Ｒが、葉がストリングＲ_ｏｐｅｎを生じさせる（すなわち、連結してこれを形成する）部分木を有する場合、ストリングＲ_ｏｐｅｎは、（Ｒ，Ｓ）に関してコンテキスト完全性を有し、かつρ_Ｒから当該部分木の根までの経路ｓ∈Ｓが存在する、という。

形式的には、属性ＣＴＸ_Ｇの観点からコンテキスト完全性を定義する。より具体的には、ＴＬＳ応答時の文法Ｇ、Ｒ∈Ｇ、ＲのサブストリングＲ_ｏｐｅｎ、許容経路のセットＳが与えられると、

から

までの経路ｓ∈Ｓを有するＴ_Ｒの部分木

が存在し、かつ

がＲ_ｏｐｅｎを生じさせる場合にのみ、

であるように、コンテキスト関数ＣＴＸ_Ｇをブール関数として定義し、

の場合に、Ｒ_ｏｐｅｎは、（Ｒ，Ｓ）に関してコンテキスト完全性を有すると言われる。

図５の例を再度参照して、その例に従ってＪＳＯＮストリングＪを考える。ＪＳＯＮは、（大まかに）以下のルールを含む。

その例では、Ｖは、鍵「チェッキングａ／ｃ」を有するペアρ_{ｃｈｅｃｋｉｎｇ}の値によって与えられたオブジェクト内の、鍵「残高」を有するペアρ_{ｂａｌａｎｃｅ}の導出を知得することに興味があった。これらの非終端の各々は、解析木Ｔ_Ｊ内のノードのラベルである。Ｔ_Ｊのルート開始からρ_{ｃｈｅｃｋｉｎｇ}までの経路は、開始→オブジェクト→ペアズ^＊→ρ_{ｃｈｅｃｋｉｎｇ}という形式のノードのシーケンスをトラバースする必要があり、ここで、ペアズ^＊は、ゼロ以上のペアズのシーケンスを表す。そのため、Ｓは、そのようなシーケンスのセットであり、Ｒ_ｏｐｅｎは、ストリング「チェッキングａ／ｃ」である。｛「残高」：＄２０００｝。

２段階構文解析。一般に、Ｒを直接明示することなく、Ｒ_ｏｐｅｎがコンテキスト完全性を有すること、すなわち

を証明することは、ＣＴＸ_Ｇを計算することが潜在的に長いストリングＲに対してＴ_Ｒを計算することを必要とし得ることから、高価である。しかしながら、ＴＬＳ保護されたデータが一般に満たす特定の前提の下で、ＰおよびＶによって合意された変換Ｔｒａｎｓを適用することによって、ＰにＲを前処理させることによって、オーバーヘッドの多くが、除去され得ること、およびＲ_ｏｐｅｎがＲ’（通常はるかに短いストリング）およびＳ’（ＳおよびＴｒａｎｓに基づいてＶによって指定される許容経路の集合）に関してコンテキスト完全性を有することを証明することが、観測された。

この観測に基づいて、Ｒ_ｏｐｅｎを効率的に計算し、かつ

を証明するための、２段階構文解析スキームを導入する。ＰおよびＶが、ウェブサーバで使用されている文法であるＧと、変換Ｔｒａｎｓと、について合意したと仮定する。Ｇ’をすべてのＲ∈Ｇに対するストリングＴｒａｎｓ（Ｒ）の文法とする。Ｔｒａｎｓに基づいて、Ｖは、許容経路Ｓ’と制約チェック関数ｃｏｎｓ_Ｇ，Ｇ’を指定する。第１の段階では、Ｐ：（１）Ｒを構文解析することによって、（

となるような）ＲのサブストリングＲ_ｏｐｅｎを計算する（２）別のストリングＲ’＝Ｔｒａｎｓ（Ｒ）を計算する。第２の段階では、Ｐは、（１）

および（２）

を、ゼロ知識でＶに対して証明する。公開パラメータＧ、Ｇ’、Ｓ、Ｓ’、Ｔｒａｎｓ、ｃｏｎｓ_Ｇ，Ｇ’に加えて、検証器は、Ｒに対するコミットメントのみを見、最後にＲ_ｏｐｅｎを見ることに留意されたい。

このプロトコルは、非検証可能な計算に対する実際の構文解析を延期することによって、ゼロ知識計算を大幅に非高価にする。言い換えると、

および

の計算は、

の計算よりもはるかに効率的であり得る。

２段階構文解析の正確性条件を、以下に与えられる操作意味論のルールで形式化する。ここで、（ｆ，σ）は、入力σに関数ｆを適用することを表す一方、

は、前提Ｐが真である場合には結論Ｃが真であることを表す。

文法Ｇ、コンテキスト関数および許容経路ＣＴＸ_Ｇ（Ｓ，・，・）、変換Ｔｒａｎｓ、文法Ｇ’＝｛Ｒ’：Ｒ’＝Ｔｒａｎｓ（Ｒ），Ｒ’∈Ｇ｝、コンテキスト関数および許容経路ＣＴＸ_Ｇ’（Ｓ’，・，・）、および関数ｃｏｎｓ_Ｇ，Ｇ’が与えられると、Ｒ’∈Ｇのようなすべての（Ｒ，Ｒ’，Ｒ_ｏｐｅｎ）について、ブーリアンｂが以下のルールを保持する場合、（ｃｏｎｓ_Ｇ，Ｇ’，Ｓ’）は、Ｓに関して正しいと言う。

以下では、ＤＥＣＯアプリケーションでの使用に好適な例示的な文法に焦点を当て、２段階構文解析スキームの具体的な構築を提示する。

鍵－値文法。ＪＳＯＮなどの幅広いクラスのデータ形式は、鍵－値ペアという概念を有する。したがって、それらは、ＤＥＣＯのいくつかの実施形態での当焦点である。

鍵－値文法Ｇは、開始、中間、および終了が区切り記号である「ペア→開始鍵中間値終了」というルールに従って、鍵－値ペアを生成する。そのような文法について、最適化の配列は、コンテキストを証明するための複雑さを大幅に低減することができる。そのような最適化について、以下で、本明細書の他の箇所で他の詳細を提供して議論する。

グローバルに一意の鍵に対する明示。鍵－値文法Ｇについて、経路のセットＳは、Ｒ∈Ｇについて、コンテキスト完全性を満たすサブストリングＲ_ｏｐｅｎが、Ｒ_ｏｐｅｎが、グローバルに一意の鍵Ｋを有する鍵－値ペアとして構文解析されることを必要とする場合、Ｒ_ｏｐｅｎは、単にＲのサブストリングであり、かつペアとして正しく構文解析される必要がある。具体的には、Ｔｒａｎｓ（Ｒ）は、所望の鍵を含むＲのサブストリングＲ’、すなわち、形式「開始Ｋ中間値終了」のサブストリングを出力し、Ｐは、Ｒ_ｏｐｅｎ＝Ｒ’を出力することができる。Ｇ’を、Ｓ_Ｇ’がＧ’の生成ルールにおける開始記号である場合に、ルールＳ_Ｇ’→ペアによって定義することができる。次いで、（１）ｃｏｎｓ_Ｇ，Ｇ’（Ｒ，Ｒ’）が、Ｒ’がＲのサブストリングであることをチェックし、（２）Ｓ’＝｛Ｓ_Ｇ’｝について、ＣＴＸ_Ｇ’（Ｓ’，Ｒ’，Ｒ_ｏｐｅｎ）が、（ａ）Ｒ’∈Ｇ’および（ｂ）Ｒ_ｏｐｅｎ＝Ｒ’であることをチェックする。グローバルに一意の鍵は、年齢に対する応答を選択的開示する場合などの、本明細書におけるいくつかのアプリケーションで発生する。

鍵－値文法における黒塗り。したがって、ここまで、２段階構文解析の当説明は、ＰがＲのサブストリングＲ_ｏｐｅｎをＶに対して明示し、かつＲ_ｏｐｅｎがＶによって指定された許容経路のセットに関してコンテキスト完全性を有することを証明する、明示モードを前提とする。黒塗りモードでは、プロセスは、同様であるが、Ｒ_ｏｐｅｎをクリアで明示する代わりに、Ｐは、前述した技術を使用してＲ_ｏｐｅｎに対するコミットメントを生成し、例えばその位置をダミー文字に置き換えることによって、Ｒ_ｏｐｅｎを除去して、Ｒを明示する。

アプリケーション
本明細書に開示されるＤＥＣＯを、任意のオラクルベースアプリケーションに使用することができる。このＤＥＣＯの汎用性を例示するために、その様々な能力を活用する３つの例示的なアプリケーションを実装し、評価した：１）スマートコントラクトによって実現される機密金融商品。２）レガシークレデンシャルの匿名クレデンシャルへの変換、３）プライバシー保存する価格差別報告。

機密金融商品。金融派生商品は、最も一般的に引用されるスマートコントラクトアプリケーションの一つであり、認証されたデータフィード（例えば、株価）の必要性を例示している。例えば、スマートコントラクトで実装するのが容易である人気のある金融商品は、バイナリオプションである。これは、指定された将来の時間、例えばＤ日の終わりに、いくつかの資産Ｎの価格Ｐ^＊が所定のターゲット価格Ｐに等しいか、またはそれを超える、すなわち、Ｐ^＊≧Ｐかどうかを賭ける２つのパーティ間のコントラクトである。このバイナリオプションを実装するスマートコントラクトは、結果を決定するためにオラクルＯを呼び出すことができる。

原理的に、Ｏは、チェーン上のバイナリオプションの基礎となる資産Ｎおよびターゲット価格Ｐを隠すことができる。Ｏは、単にオプションの詳細をオフチェーンで受け入れ、結果Ｓｔｍｔ：＝Ｐ^＊≧？Ｐを指定するビットのみを報告する。この手法は、Ｍｉｘｉｃｌｅと呼ばれる。

基本的なＭｉｘｉｃｌｅ構築の制限は、Ｏ自身が金融商品の詳細を知得することである。ＤＥＣＯの前には、信頼できる実行環境（ＴＥＥ）を使用するオラクルサービスのみがＯからのクエリを隠すことができた。ここで、ＤＥＣＯが金融商品の詳細、すなわちＮまたはＰを知得することなく、バイナリオプションの実行をどのようにサポートできるかを示す。この点で、属性方向≧？または≦？がランダム化され得ることに留意されたい。また、勝者および敗者の識別情報および支払い金額を隠すことができる。他のメタデータ、例えば正確な決済時間、を隠すために追加のステップを取ることができる。

この例示的なアプリケーションでは、オプションの勝者は、Ｐの役割を果たし、Ｖの役割を果たすＯからのＳｔｍｔの署名された結果を取得する。ここで、プロトコルおよびその実装態様について記載する。

｛ｓｋ_Ｏ，ｐｋ_Ｏ｝で、オラクルの鍵ペアを表す。この実施形態では、バイナリオプションは、資産名Ｎ、閾値価格Ｐ、および決済日Ｄによって指定される。証拠ｒ_Ｍを伴うＣ_Ｍ＝ｃｏｍ（Ｍ、ｒ_Ｍ）によって、メッセージＭのコミットメントを表す。

図１１は、機密性バイナリオプションを実行するアリスおよびボブの２つのパーティを例示している。アリスは、ＤＥＣＯを使用して株価ＡＰＩにアクセスし、彼女が勝利したことをＯに納得させる。要求および応答の例を右側に示し、図のこの部分の陰影付きテキストは、黒塗りされるべき機密情報である。

図１１に例示されるバイナリオプションプロセスは、以下のステップを含む：
１）セットアップ：アリスおよびボブは、バイナリオプション｛Ｎ，Ｐ，Ｄ｝に合意し、識別子ＩＤ_ＳＣを有するスマートコントラクトＳＣを作成する。このコントラクトは、パーティの住所、および両パーティに知られている証拠を有する、オプション｛Ｃ_Ｎ，Ｃ_Ｐ，Ｃ_Ｄ｝に対するコミットメントを含む。彼らはまた、公開パラメータθ_Ｐ（例えば、資産価格を取り出すためのＵＲＬ）についても合意する。

２）決済：アリスが賭けに勝つと仮定する。支払いを請求するために、彼女は、ＤＥＣＯを使用して、取り出された現在の資産価格が彼女のポジションと一致するＺＫＰを生成する。アリスおよびＯは、ＤＥＣＯプロトコルを（Ｏが検証器として機能して）実行して、θ_Ｐ（ターゲットＵＲＬ）から資産価格を取り出す。応答は、（Ｎ^＊，Ｐ^＊，Ｄ^＊）を含むものとする。起点θ_Ｐを証明するためのＤＥＣＯにおけるＺＫＰに加えて、アリスは、以下のステートメントを証明する：

証明検証が成功すると、オラクルは、コントラクトＩＤ、

を有する署名されたステートメントを返す。
３）支払い：アリスは、署名を検証し、かつ勝利パーティに支払う、署名されたステートメントＳをコントラクトに提供する。

アリスおよびボブは、プライバシーのためではなく、完全性のためにＯを信頼する必要がある。彼らは、本明細書の他の箇所で説明されるように、複数のオラクルを使用することによって、完全性欠陥に対してさらにヘッジすることができる。オラクルに対する信頼を非集中化することは、標準の、すでにデプロイされている技術である。ＤＥＣＯは、すべてのオラクルが悪意のあるものであっても、プライバシーを確保することを強調しておく。

上記に示したように、図１１は、株価ＡＰＩの要求および応答を示す。ユーザ（Ｐ）はまた、正しいＡＰＩエンドポイントへのアクセスを納得させるために、オラクル（Ｖ）に対するＨＴＴＰ ＧＥＴ要求の十分な部分を明示する必要がある。ＧＥＴ要求は、ＡＰＩエンドポイントのような明示されるいくつかのパラメータと、ストック名のような機密詳細および非公開ＡＰＩ鍵を有する他のパラメータと、を含む。Ｐは、本明細書に開示された技術を使用して機密パラメータを黒塗りし、残りをＶに明示する。ＡＰＩ鍵は、Ｖが機密パラメータを知得することを防止するのに十分なエントロピーを提供する。しかし、追加の注意を払うことなく、不正行為を行うＰは、ＧＥＴ要求のセマンティクスを改変し、余分のパラメータを黒塗りすることによって不正行為を隠すことができる。これが起こらないことを補償するためには、Ｐは、区切り記号「＆」および区切り記号「＝」が、黒塗りされたテキストに現れないことを証明する必要がある。

および

で、それぞれ応答暗号文と平文を表す。オプションを決済するために、Ｐは、Ｒが、前述した２段階構文解析スキームを使用して、オプションを獲得したというエビデンスを含むことをＶに対して証明する。第１の段階では、Ｐは、Ｒをローカルで構文解析し、Ｖを納得させることができるＲの最小のサブストリングを識別する。株価を伴う図１１の実施形態では、Ｒ_{ｐｒｉｃｅ}＝「０５．価格」：「１１５７．７５００」で十分である。第２の段階では、Ｐは、１）Ｒ_{ｐｒｉｃｅ}が

の復号化のサブストリングであり、２）Ｒ_{ｐｒｉｃｅ}が「０５．価格」で始まり、３）後続の文字が、浮動小数点数Ｐ^＊を形成し、そのＰ^＊≧Ｐ、かつ４）ｃｏｍ（Ｐ，ｒ_Ｐ）＝Ｃ_Ｐのように、（Ｒ_{ｐｒｉｃｅ}，Ｐ，ｒ_Ｐ）の知識をＺＫで証明する。

この２段階構文解析は、鍵が一意であり、かつ鍵「０５．価格」に価格が続くことを前提としていて、セキュアであり、上述したように、この応答の文法は、一意の鍵を有する鍵－値文法になる。同様に、Ｐは、Ｒに含まれる株式名および日付がコミットメントと一致することを証明する。ＣＢＣ－ＨＭＡＣ暗号スイートでは、ゼロ知識証明回路は、レコード全体（４０８バイト）の黒塗り、コミットメントの計算、およびストリング処理を伴う。

ＨＴＴＰ ＧＥＴ要求（およびＨＴＭＬ）は、特別な制限を有する：鍵と値との間の区切り（すなわち、中間）と、鍵－値ペアの開始（すなわち、開始）は、決して鍵または値のサブストリングではない。このことは、２つ以上の連続する鍵または値を黒塗りするためには、Ｐは、｛中間，開始｝の文字を黒塗りしなければならないことを意味する。そのため、ｃｏｎｓ_Ｇ，Ｇ’（Ｒ，Ｒ’）は、以下をチェックする：（１）

かつ（２）

｛中間，開始｝または

のいずれか（Ｄは、所定位置の黒塗りを行うために使用されるダミー文字）。次いで、ＣＴＸ_Ｇ’をチェックすることは、必須ではない。

レガシークレデンシャルから匿名クレデンシャルへ：年齢証明。ユーザクレデンシャルは、多くの場合、サービスプロバイダの環境外ではアクセス可能でない。いくつかのプロバイダは、ＯＡｕｔｈトークンを介して第三者のＡＰＩアクセスを提供するが、そのようなトークンはユーザ識別子を明示する。ＤＥＣＯは、既存のシステムにクレデンシャル（「レガシークレデンシャル」と呼ぶ）を保持しているユーザが、それらに関するステートメントを第三者（検証器）に対して匿名で証明することを可能にする。したがって、いくつかの実施形態でのＤＥＣＯは、ユーザが、サーバサイドのサポートまたは信頼できるハードウェアなしで、任意のウェブベースのレガシークレデンシャルを匿名クレデンシャルに変換することを可能にする。

図１２は、このアプリケーションの例を示し、ここでは、大学ウェブサイトに格納されているクレデンシャル（人口統計学的詳細）を使用して、彼女／彼の年齢が１８歳以上であることを証明する。学生は、運転免許証を発行している州または医療検査の同意を求めている病院などの、任意の第三者に、この年齢の証明を提供することができる。この例を、ＡＥＳ－ＧＣＭ暗号スイートと、一意の鍵に基づく最適化を用いる２段階構文解析を使用して、実装する。

図１２の例では、大学ウェブサイトに格納された学生の人口統計学的詳細は、とりわけ、名前、生年月日、学生ＩＤを含む。強調表示されたテキストは、学生の年齢を含む。明示モードは、２段構文解析とともに使用される。証明器は、生年月日を含む６～７個のＡＥＳブロックを構文解析し、彼女の年齢が１８歳を超えていることをＺＫで検証器に対して証明する。他の例と同様に、生年月日を囲む一意のＨＴＭＬタグに起因して、これも、一意の鍵を有する鍵－値文法である。バイナリオプションアプリケーションと同様に、この例は、日付および計算時間を構文解析するための追加のストリング処理を必要とする。

価格差別。価格差別は、同じ製品またはサービスを、異なる購入者に異なる価格で販売することを指す。ユビキタスな消費者追跡は、オンラインショッピングおよび予約ウェブサイトが、精緻化された価格差別、例えば顧客の郵便番号に基づいて価格を調整すること、を使用することを可能にする。価格差別は、経済的効率につながり得るため、既存の法律下では広く許容されている。

ただし、米国では、ＦＴＣは、価格差別が競争上の傷害につながる場合、価格差別を禁止している一方、ＧＤＰＲなどの、ヨーロッパの新しいプライバシー重視の法律は、この慣行の合法性に再び焦点を当てている。どのような場合でも、消費者は、一般に、価格差別を受けることを嫌う。しかしながら、現在のところ、ユーザがオンラインで価格差別を報告する信頼できる方法はない。

図１３は、このアプリケーションの例を示し、ここでは、名前および住所などの機密情報を秘匿しながら、商品の広告価格が閾値よりも高いことを証明することによって、ＤＥＣＯが、認識された価格差別について購入者が検証可能な主張を行うことを可能にする。ＴＬＳセッションに好適なＡＥＳ－ＧＣＭ暗号スイートを使用してこの例を実装し、必要な注文の詳細および要求ＵＲＬを含む２４個のＡＥＳブロックを明示する。

図１３に例示されるように、ショッピングサイト（例えば、アマゾン）のＨＴＭＬでの注文請求書ページの一部は、購入者の名前および住所などの個人詳細を含む。購入者は、特定の日付の特定の製品の請求価格について第三者（検証器）を説得したいと考えている。この例では、ＡＥＳ－ＧＣＭ暗号化スイートおよび表示モードを使用して、注文請求書ページの上部に必要なテキストを明示するが、陰影付きの購入者の名前、住所、および都市を含む、下部部分の陰影付きの機密テキストは、秘匿される。応答から明示されたＡＥＳブロックの数は、２０（長い製品名に起因する）である。加えて、要求からの４つのＡＥＳブロックを明示して、正しいエンドポイントにアクセスしていることを証明する。コンテキスト完全性は、周囲の固有のストリング、例えば商品価格の近くにあるストリング「＜ｔｒ＞注文合計：」、を明示することによって、保証され、応答全体で１回だけ現れる。

実装態様および評価
ここで、ＤＥＣＯおよび３つのアプリケーションの実装態様詳細および評価結果について記載する。

三者ハンドシェイクおよびクエリ実行。約４７００行のＣ＋＋コードで、ＴＬＳ１．２の三者ハンドシェイクプロトコル（３Ｐ－ＨＳ）とクエリ実行プロトコル（２ＰＣ－ＨＭＡＣおよび２ＰＣ－ＧＣＭ）と、を実装した。合計７７９，２１３のＡＮＤ複雑さを有する、手動最適化されたＴＬＳ－ＰＲＦ回路を構築した。また、知られているＡＥＳ回路の変形例を使用した。当実装態様は、Ｐａｉｌｌｉｅｒ暗号システムにＲｅｌｉｃを、また悪意に対してセキュアな２ＰＣプロトコルにＥＭＰツールキットを使用する。

エンドツーエンドのシステムを構築するために、三者ハンドシェイクプロトコルおよび２ＰＣ－ＨＭＡＣプロトコルを、ポピュラーなＴＬＳ実装態様であるｍｂｅｄＴＬＳと統合した。２ＰＣ－ＧＣＭは、より多くのエンジニアリング努力によるのと同様に、ＴＬＳに統合することができる。２ＰＣ－ＧＣＭの性能を別途評価した。統合の性能への影響は、無視できるはずである。ＴＬＳ１．３用には３Ｐ－ＨＳを実装しなかったが、回路の複雑さが同様であることから、性能は、ＴＬＳ１．２用と同等であるはずであると考えられる。

ＬＡＮとＷＡＮとの両方の設定でＤＥＣＯの性能を評価した。証明器と検証器との両方は、８個のｖＣＰＵコアおよび１６ＧＢのＲＡＭを有するｃ５．２ｘｌａｒｇｅ ＡＷＳノード上で動作する。２つのノードをＬＡＮ設定のために同じ地域（ただし、異なる可用性ゾーン）に位置させたが、ＷＡＮ設定では２つの個別のデータセンタ（ＯｈｉｏおよびＯｒｅｇｏｎ）に位置させた。ＬＡＮおよびＷＡＮでの２つのノード間の往復時間は、それぞれ約１ｍｓおよび６７ｍｓであり、帯域幅は約１Ｇｂｐｓである。

以下の表１は、ＴＬＳセッション中のＤＥＣＯプロトコルの実行時間をまとめたものである。５０個のサンプルを使用して、平均および平均の標準誤差（括弧内）を計算した。使用したＭＰＣプロトコルは、オフラインの前処理に依存して、性能を改善する。オフラインフェーズが入力およびターゲットに依存しないことから、オフラインフェーズをＴＬＳセッションの前に行うことができる。オンラインフェーズのみが、枢要な経路上にある。

表１に示されるように、ＤＥＣＯプロトコルは、ＬＡＮ設定で非常に効率的である。三者ハンドシェイク終了させるのに、０．３７秒かかる。クエリ実行について、２ＰＣ－ＨＭＡＣは、レコードサイズに関わらず、２ＰＣで１つのＳＨＡ－２評価のみを伴うため、効率的である（レコードごとに０．１３ｓ）。２ＰＣ－ＧＣＭは、クエリ全体にわたって２ＰＣ－ＡＥＳを伴うため、一般により高価であり、コストはクエリ長に依存する。ＨＴＴＰ ＧＥＴ要求に見られる典型的なサイズである２５６Ｂ～２ＫＢの範囲のクエリで、２ＰＣ－ＧＣＭの性能を評価した。ＬＡＮ設定では、性能は、効率的であり、２ＰＣ－ＨＭＡＣと同等である。

ＷＡＮ設定では、ＭＰＣが多往復の通信を伴うため、実行時間は、ネットワークレイテンシによって支配される。それにもかかわらず、考慮するほとんどのアプリケーションでＤＥＣＯが定期的に使用される可能性が高いことを考えると、性能は、依然として許容可能である。

証明生成。ｌｉｂｓｎａｒｋの標準的な証明系で、ゼロ知識証明をインスタンス化した。効率的に証明可能なステートメントテンプレートを考案したが、ＤＥＣＯのユーザは、これらのテンプレートを特定のアプリケーションに適合させる必要がある。ＳＮＡＲＫコンパイラは、高水準言語でそのような適合を可能にし、開発者から低レベルの詳細を隠す。ｘｊｓｎａｒｋおよびそのＪａｖａ（登録商標）様高水準言語を使用して、ステートメントテンプレートおよびｌｉｂｓｎａｒｋ互換回路を構築した。

ｌｉｂｓｎａｒｋを選定する当理由は、その比較的成熟したツーリングサポートである。ｌｉｂｓｎａｒｋによって生成された証明は、一定サイズであり、検証するのに非常に効率的であり、欠点は、回路ごとの信頼できるセットアップである。ＤＥＣＯを、信頼できるセットアップを必要としないが、大きな証明時間および検証時間を有する、例えばＢｕｌｌｅｔｐｒｏｏｆを使用するように適合させることができる。

証明器時間（証明を生成するための時間）、検証器時間（証明を検証するための時間）、証明器サイズ、回路での算術制約の数、および証明生成中のピークメモリ使用量という、各例に対する５つの性能メトリックを測定する。

以下の表２は、その結果をまとめたものである。５０個のサンプルを使用して、平均およびその標準誤差を計算した。効率的なステートメントテンプレートおよび２段階構文解析を使用することで、ＤＥＣＯは、非常に実用的な証明器性能を達成する。ｌｉｂｓｎａｒｋが低検証オーバーヘッドに最適化されることから、検証器時間は、無視できる。余分なストリング構文解析ルーチンに起因して、制約の数（および証明器時間）は、バイナリオプションアプリケーションに対して最も多い。ピークメモリ使用量を低減するために、各アプリケーションで複数の証明を使用する。最も複雑なアプリケーションについて、メモリ使用量は、１．７８ＧＢである。ｌｉｂｓｎａｒｋ証明は、一定サイズの２８７Ｂであるため、示される証明サイズは、それの倍数である。

エンドツーエンド性能。ＤＥＣＯエンドツーエンド性能は、利用可能なＴＬＳ暗号スイート、非公開データのサイズ、およびアプリケーション固有の証明の複雑さに依存する。ここでは、バイナリオプションという、実装した３つのアプリケーションのうちで最も複雑なアプリケーションのエンドツーエンド性能を提示する。プロトコルを終了させるのに約１３．７７秒かかり、これには、非偽造可能なコミットメント（０．５０秒）の生成、２段階構文解析の第１の段階の実行（０．３０秒）、およびゼロ知識証明の生成（１２．９７秒）にかかる時間が含まれる。これらの数値は、ＬＡＮ設定で計算されており、ＷＡＮ設定では、ＭＰＣプロトコルは、より時間がかかり（５．３７ｓ）、エンドツーエンド時間を１８．６４ｓに押し上げる。

比較すると、Ｔｏｗｎ Ｃｒｉｅｒは、ＴＥＥを使用して同様のアプリケーションを約０．６秒で、すなわちＤＥＣＯよりもおよそ２０倍速く、実行するが、信頼仮定が追加される。ＤＥＣＯがほとんどのアプリケーションで定期的にのみ使用される可能性が高いことから、暗号強度セキュリティ保証を達成するためのＤＥＣＯのオーバーヘッドは、合理的と思われる。

法的およびコンプライアンス問題
ユーザは、ウェブサイトから自分のデータを取り出し済みである可能性があるが、ＤＥＣＯは、ユーザが自分の明示的な承認またはさらには認識を伴わずに、完全性証明とともにデータをエクスポートすることを可能にする。ここで、結果として生じる法的およびコンプライアンス上の考慮事項について簡単に議論する。

ただし、肝心なことであるが、ＤＥＣＯユーザは、完全性保証とともにデータを一方的に第三者にエクスポートすることはできず、この目的で検証器としてのオラクルに依存する。ＤＥＣＯはユーザデータを非公開に保持するが、オラクルは、ユーザがアクセスするウェブサイトおよびデータ型を知得する。したがって、オラクルは、例えば著作権侵害をもたらす可能性があるトランザクションを拒否して、適切なデータ使用を強制することができる。

ユーザとオラクルとの両方は、それらがアクセスするデータについて法的責任を負う。しかしながら、最近のコンピュータ詐欺および濫用防止法（ＣＦＡＡ）に関する判例法は、ウェブスクラップの犯罪化からの転換を示しており、連邦裁判所はウェブサイトの利用規約に違反すること自体は犯罪行為ではないと判断している。ウェブサイトの利用規約（「クリックラップ」など）に違反するユーザおよびオラクルは、代わりに民事罰のリスクがある。ＤＥＣＯが所与のサイトの利用規約に準拠していることは、サイト固有の、およびアプリケーション固有の問題である。

オラクルは、スマートコントラクトおよび他のエコシステム内で信頼できるものとして確立するインセンティブを有する。評判の良いオラクルは、オラクルが発行する特定の証明書とオラクルが許可するターゲットウェブサイトとのメニューをユーザに提供するものであり、これらのオプションを精査して、セキュリティを最大化し、責任を最小限に抑え、場合によってはターゲットサーバに通知または協力することを想定している。

誤ったデータに基づく誤った証明の法的な、性能への、およびコンプライアンスへの影響もまた、重要である。しかし、現在のインターネットサービスは、複雑なマルチサイトデータ依存性があるため、これらの問題はＤＥＣＯ固有のものではない。オラクルサービスは、正確性を確保するのに役立つ複数のデータソースにすでに依存している。オラクルサービス全般は、オンラインでのチェッキングおよび失効能力、ならびに異なる階層のセキュリティを含む、証明書のためのインフラストラクチャのようなインフラストラクチャを最終的に生み出す可能性がある。

本明細書で開示される例示的な実施形態でのＤＥＣＯは、信頼できるハードウェアまたはサーバサイドの修正を必要としない、最新のＴＬＳバージョンのためのプライバシー保存する非集中型オラクルスキームである。ＤＥＣＯは、証明器がＴＬＳセッションに対する非偽造可能なコミットメントを生成し、セッションコンテンツに関するステートメントを効率的に証明することを可能にする。いくつかの実施形態は、新規な２段階構文解析スキームを利用して、プライバシー保存するオラクルに普遍的であるコンテキスト完全性攻撃を軽減する。ＤＥＣＯは、集中型ウェブサービスサイロからデータを解放し、広範なアプリケーションに対してこのデータをアクセス可能にすることができる。ＤＥＣＯの実用性は、３つの例示的なアプリケーションとともに、完全に機能的な実装態様を通じて本明細書で実証される。

ＧＣＭのプロトコルの詳細
ＧＣＭは、追加のデータ（ＡＥＡＤ）暗号を用いる認証された暗号化である。暗号化するために、ＧＣＭ暗号は、タプル

：秘密鍵、初期ベクトル、複数のＡＥＳブロックの平文と、完全性保護に含まれる追加のデータと、を入力として取り、暗号文

およびタグＴを出力する。復号化は、プロセスを反転させる。復号化暗号は、入力（ｋ，ＩＶ，Ｃ，Ａ，Ｔ）として、まず、再計算されたタグをＴと比較することによって暗号文の完全性をチェックし、次いで、平文を出力する。

暗号文は、カウンタモードで計算される：

式中、ｉｎｃ^ｉは、ＩＶをｉ回増分することを表す（ｉｎｃの正確な形式は重要ではない）。

タグ

は、以下のように計算される。ベクトル

が与えられると、関連付けられたＧＨＡＳＨ多項式

は、

で加算および乗算を行う

として定義される。一般性を失うことなく、

および

が適切にパディングされると仮定する。ｌ_Ａおよびｌ_Ｃで、それらの長さを表す。ＧＣＭタグは、以下である。

式中、ｈ＝ＡＥＳ（ｋ，０）。

ＴＬＳでＧＣＭを使用する場合、各平文レコードＤは、以下のように暗号化される。一意のノンスｎが選定され、追加のデータκは、シーケンス番号、バージョン、およびＤの長さの連結として計算される。ＧＣＭ暗号化は、Ｍ＝ｎ｜｜ＧＣＭ（ｋ，ｎ，Ｄ，κ）としてペイロードレコードを生成するために呼び出される。

ＧＣＭに関する追加の詳細を、例えば、Ｍｏｒｒｉｓ Ｊ Ｄｗｏｒｋｉｎ，ＳＰ ８００－３８ｄ，“Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ ｆｏｒ ｂｌｏｃｋ ｃｉｐｈｅｒ ｍｏｄｅｓ ｏｆ ｏｐｅｒａｔｉｏｎ：Ｇａｌｏｉｓ／ｃｏｕｎｔｅｒ ｍｏｄｅ （ＧＣＭ） ａｎｄ ＧＭＡＣ，”Ｔｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ，２００７に見出すことができ、これは、参照により本明細書に組み込まれる。

クエリ実行
タグ作成／検証。ＧＣＭタグを計算すること、または検証することは、２ＰＣにおける上記の式（１）を評価することを伴う。課題は、式（１）が、算術計算（例えば、

における多項式評価）、ならびにバイナリ計算（例えば、ＡＥＳ）の両方を伴うことである。バイナリ回路で大きな体で乗算を実行することはコストがかかる一方、

において（ＧＦ（２^８）で定義される）ＡＥＳを計算することは、高いオーバーヘッドを発生させる。計算が何らかの形で２つの回路に分離できたとしても、各レコードに対して

においておよそ１，０００回の乗算を要する多項式だけを評価すると、過度に高価になる。

当プロトコルは、多項式評価の必要性を除去する。実際の２ＰＣプロトコルは、バイナリ演算のみを伴い、したがって、単一の回路で行える。その上、レコードごとの計算は、２ＰＣ－ＡＥＳの１回の呼び出しのみに低減される。

このことは、セッションの開始時に前処理フェーズで｛ｈ^ｉ｝のシェア（２ＰＣプロトコルでの）を計算することによって達成される。前処理のオーバーヘッドは、続くすべてのレコードに同じｈが使用されるため、セッション全体にわたって償却される。｛ｈ^ｉ｝のシェアがあれば、ＰおよびＶは、多項式評価のシェア

をローカルで計算することができる。彼らはまた、２ＰＣでＡＥＳ（ｋ，ＩＶ）を計算し、

のシェアを得る。合計で、各レコードのタグをチェックするために必要とされる際の２ＰＣ－ＡＥＳの呼び出しは１回のみである。

Ｖが同じＩＶに複数回応答することは決してないことが枢要であり、そうでなければ、Ｐはｈを知得するであろう。具体的には、各応答において、Ｖは、

の形態で彼女のシェア｛ｈ_Ｖ，ｉ｝の目隠しされた線形結合を明示する。｛ｈ_Ｖ，ｉ｝の単一の目隠しされない線形結合であれば、Ｐがｈを解くことを可能にするため、値がＡＥＳ（ｋ，ＩＶ）によって目隠しされることが重要である。したがって、Ｖが同じＩＶに２回応答する場合、２つの応答（

での）を加算することによって、目隠しを除去することができる：

このことは、ＧＣＭのノンス一意性要件に従う。

レコードの暗号化／復号化。タグが適切にチェックされると、レコードの復号化は、直截的である。ＰおよびＶは、２ＰＣ－ＡＥＳを用いたｉｎｃ’（ＩＶ）のＡＥＳ暗号化を単に計算する。細かい注意事項は、Ｖが、暗号化されるカウンタが以前にＩＶとして使用されていないことをチェックしなければならないことである。そうでなければ、Ｐは、上記に概説したような様式で、Ｐに対するｈを知得するであろう。

証明生成
ブロックの明示。Ｐは、ＡＥＳブロックＢ_ｉが、暗号化されたレコードｒｅｃのｉ番目のブロックであることをＶに納得させたい。証明戦略は、以下の通りである：１）ＡＥＳブロックＢ_ｉが暗号文ブロック

に暗号化されていることを証明し、２）タグが正しいことを証明する。正しい暗号化を証明することは、ＺＫＰで１回のみのＡＥＳを必要とする。ナイーブに行われると、正しいタグを証明することは、ＺＫＰにおける次数５１２のＧＨＡＳＨ多項式と、２回のＡＥＳブロック暗号化と、を評価することに陥る。

Ｐが２つの暗号化されたメッセージＡＥＳ（ｋ，ＩＶ）およびＡＥＳ（ｋ，０）をＶに明示することを可能にし、したがって、Ｖがタグを検証することを可能にする（式（１）を参照）ことによって、はるかに効率的な証明をうまく達成する。Ｐは、暗号化の正確性をＺＫで証明し、使用される鍵がコミットメントに対応していることを証明するだけでよく、２回のＡＥＳおよび１回のＳＨＡ－２を必要とする（Ｐは、鍵のハッシュを明示することによってｋ_Ｐに対してコミットする）。したがって、合計のコストは、ＺＫＰでの３回のＡＥＳおよび１回のＳＨＡ－２である。

ＴＬＳレコードの明示。証明技術は、上記のケースからの単純な拡張である。Ｐは、レコードｒｅｃ全体を明示し、すべてのＡＥＳブロックの正しいＡＥＳ暗号化を証明し、ＺＫＰでの合計５１４回のＡＥＳおよび１回のＳＨＡ－２をもたらす。

ブロックを除くＴＬＳレコードの明示。上記の場合と同様に、Ｐは、１つを除くレコード内のすべてのブロックの暗号化を証明し、ＺＫＰでの合計５１３回のＡＥＳおよび１回のＳＨＡ－２をもたらす。

プロトコル拡張
ＴＬＳ１．３サポートへの適合。ＴＬＳ１．３をサポートするためには、３Ｐ－ＨＳプロトコルを、新しいハンドシェイクフローおよび異なる鍵導出回路に適合させなければならない。特に、ここでは、ＳｅｒｖｅｒＨｅｌｌｏ後のすべてのハンドシェイクメッセージが、暗号化される。ナイーブ戦略の場合、それらを２ＰＣにおいて復号化するであろうし、このことは、証明書が通常大きいため、コストがかかるであろう。ただし、ＴＬＳ１．３の鍵独立性特性のおかげで、ＰおよびＶは、最終セッション鍵の秘密性に影響を与えることなく、ハンドシェイク暗号鍵をセキュアに明示することができる。終了したメッセージは、さらに別の独立した鍵を使用してハンドシェイクを認証するため、ハンドシェイク完全性が保存される。

したがって、最適化された３Ｐ－ＨＳは、以下のように機能する。ＰおよびＶは、以前と同じＥＣＤＨＥを実行する。次いで、彼らは、２ＰＣ－ＨＫＤＦを実行することによってハンドシェイク鍵とアプリケーション鍵を導出し、ハンドシェイク鍵をＰに明示して、Ｐがローカルで（すなわち、２ＰＣなしで）ハンドシェイクメッセージを復号化することを可能にする。２ＰＣ回路は、ＴＬＳ１．２のものに匹敵する、合計およそ７０ｋのＡＮＤゲートとなるＳＨＡ－２５６のおよそ３０回の呼び出しを伴う。最後に、ＣＢＣ－ＨＭＡＣがＴＬＳ１．３によってサポートされていないことから、ＤＥＣＯを、ＧＣＭモードでのみ使用することができる。

クエリ構築は任意選択である。クエリに対する応答を拘束するアプリケーションについて、例えば取引価格とともにストックティッカーを含める場合、２ＰＣクエリ構築プロトコルを、完全に回避することができる。ＴＬＳが通信の各方向に対して別個の鍵を使用することから、クライアントからサーバへの鍵を、ＰがＶとインタラクトすることなくサーバにクエリすることができるように、ハンドシェイク後にＰに対して明示することができる。

マルチラウンドセッションのサポート。ＤＥＣＯを、以前の応答に応じてＰがさらなるクエリを送信するマルチラウンドセッションをサポートするように拡張することができる。各ラウンド後、Ｐは、ＭＡＣ検証および作成が対称であることから、上記と同様の２ＰＣプロトコルを実行して、到来する応答のＭＡＣタグを検証する。ただし、ＰがＭＡＣ検証を悪用してタグを偽造することを防止するためには、追加のコミットメントが必要とされる。

ＴＬＳでは、サーバからクライアントへの通信と、クライアントからサーバへの通信とで、異なるＭＡＣ鍵が使用される。マルチラウンドセッションをサポートするために、ＰおよびＶは、２ＰＣを実行して、前者のタグを検証し、後者に対する新鮮なメッセージのタグを作成する。本明細書における前の説明は、プロトコルを指定して、ＭＡＣタグを作成（および検証）した。ここで、マルチラウンドセッションの追加のセキュリティ考慮事項について議論する。

サーバからクライアントへのメッセージのタグをチェックする場合、Ｐがサーバから発せられたメッセージではないメッセージのタグを偽造することができないことを保証しなければならない。ＰがメッセージＭのタグＴを検証したいと仮定する。Ｐに、まずＴに対してコミットさせ、次いで、ＰおよびＶが２ＰＣプロトコルを実行して、メッセージＭのタグＴ’を計算する。Ｐは、Ｖに対するコミットメントをオープンするように要求され、Ｔ≠Ｔ’の場合、Ｖは、プロトコルを中止する。ＰがＭＡＣ鍵を知らないことから、Ｐは、サーバからではないメッセージのタグを計算し、これに対してコミットすることができない。

クライアントからサーバへのメッセージに対するタグを作成する場合、Ｖは、ＴＬＳによって要求される通りに、シーケンス番号が増加したメッセージにＭＡＣタグが作成されることを確認する。これにより、どのメッセージがサーバに送信されたかをＶが区別する方法がないため、悪意のあるＰが同じシーケンス番号の２つのメッセージを作成することを防止することもできる。

代替のＤＥＣＯプロトコル：プロキシモード。表１に示されるように、ＤＥＣＯのＨＭＡＣモードは、非常に効率的であり、２ＰＣでＨＭＡＣタグを作成し、検証する実行時間は、レコードサイズとは独立している。ＧＣＭモードは、前処理を用いる小さい要求には効率的であるが、大規模なレコードには高価であり得る。ここで、ポストハンドシェイク２ＰＣプロトコルを完全に回避する、非常に効率的な代替形態を提示する。

この代替形態では、検証器Ｖは、証明器ＰとＴＬＳサーバＳとの間のプロキシとして機能し、すなわち、Ｐは、Ｖを通してＳに／からのメッセージを送信／受信する。ＤＥＣＯプロトコルの修正されたフローは、以下の通りである：三者ハンドシェイク後、Ｐが、鍵シェアｋ_Ｐに対してコミットし、次いで、Ｖが、ｋ_ＶをＰに対して明示する。したがって、Ｐは、ここで、セッション鍵ｋ＝ｋ_Ｐ＋ｋ_Ｖ全体を有する。Ｐはｋを使用してサーバとのセッションを続行するため、Ｖは、プロキシトラフィックを記録する。セッションが終了した後、Ｐは、録音されたセッションに関するステートメントが以前と同じであることを証明する。

そのような実施形態では、三者ハンドシェイクは、非偽造可能性を提供する。ＣＢＣ－ＨＭＡＣとは異なり、ＧＣＭは、コミットしない：鍵ｋで暗号化された所与の暗号文およびタグ（Ｃ、Ｔ）について、ＧＣＭ ＭＡＣに衝突耐性がないため、同じタグを計算しながら、Ｃを異なる平文に復号化するｋ’≠ｋを見つけることができる。そのような攻撃を防止するために、上記のプロトコルは、Ｐが、セッション鍵を知得する前に、鍵シェアに対してコミットすることを必要とする。

ここで、プロキシモードプロトコルに関連するセキュリティ特性およびネットワーク前提について記載する。悪意のあるＶがＴＬＳの完全性およびプライバシーを破ることはできないため、検証器完全性およびプライバシー特性は、明確である。

しかし、証明器完全性について、プロキシがセッション全体を通じてＳに確実に接続することができるものとする必要がある。まず、プロキシが、プロキシが確実にＳと接続されていることを確認することができるものとする。その上、セッション鍵を知っており、したがって、セッションコンテンツを修正し得るＰが、プロキシとＳとの間で送信されるメッセーを改ざんすることはできないものとする。

三者ハンドシェイク中、Ｖは、（標準のＴＬＳで）新鮮なノンスを介してサーバの署名をチェックすることによって、サーバの識別情報を確認することができる。ただし、ハンドシェイク後、Ｖは、ＩＰアドレスなどのネットワーク層インジケータに依存しなければならない。したがって、実際には、Ｖは、正しい最新のＤＮＳレコードを有していなければならず、Ｖとサーバとの間のネットワーク（例えば、それらのＩＳＰおよびバックボーンネットワーク）は、例えばボーダーゲートウェイプロトコル（ＢＧＰ）攻撃を通した、トラフィック注入に対して適切に保護されなければならない。盗聴は、例示的な実施形態では、一般に、問題ではない。

これらの前提は、ＢＧＰ攻撃が実際にマウントするのは困難であるため、同様のプロキシ設定で他のシステムによって受け入れられている。検証器ノードを地理的に分散することによって、トラフィック傍受に対する当プロトコルをさらに強化することができる。その上、様々な知られている検出技術を、検証器によってデプロイすることができる。多くの場合、ＢＧＰ攻撃は、事実の後に文書化され、したがって、該当する場合、ＤＥＣＯのアプリケーションを強化して、影響を受けるセッションの失効をサポートすることができる（例えば、識別情報システムでＤＥＣＯを使用してクレデンシャルを発行する場合）。

この代替プロトコルは、異なる性能セキュリティ間のトレードオフを表す。これは、ハンドシェイク後に集中的な暗号化が発生しないため、非常に効率的であるが、ネットワークに関する追加の前提を必要とし、したがって、より弱いネットワーク敵対者にしか耐えられない。

鍵－値文法および２段階構文解析
準備および表記。コンテキストフリー文法（ＣＦＧ）をＧ＝（Ｖ，Σ，Ｐ，Ｓ）と表し、ここで、Ｖは、非終端記号のセットであり、Σは、終端記号のセットであり、Ｐ：Ｖ→（Ｖ∪Σ）^＊は、生成またはルールの集合であり、Ｓ∈Ｖは、開始記号である。ＣＦＧの生成ルールを、「－」を使用してマイナスのセットを表し、「．．」を使用して範囲を表す、標準の表記で定義する。ストリングｗについて、構文解析器は、ｗの構文解析木を構築することによってｗ∈Ｇかどうかを判定する。構文解析木は、セマンティクスを抽出するために後で使用できる一連の生成ルールを表す。

鍵－値文法。これらは、鍵－値ペアの概念を有する文法である。これらの文法は、ほとんどのＡＰＩコールおよび応答が実際には鍵－値文法であることから、ＤＥＣＯにとって特に興味深い。

Ｇは、文法Ｈが存在する場合の鍵－値文法であると言われ、これにより、与えられた任意のｓ∈Ｇ、ｓ∈Ｈ、およびＨを、以下の規則によって定義することができる：
Ｓ→オブジェクト（Ｓ→ｏｂｊｅｃｔ）
オブジェクト→ノーペアズストリング オープン ペア ペアズ クローズ（ｏｂｊｅｃｔ→ｎｏＰａｉｒｓＳｔｒｉｎｇ ｏｐｅｎ ｐａｉｒ ｐａｉｒｓ ｃｌｏｓｅ）
ペア→開始 鍵 中間 値 終了（ｐａｉｒ→ｓｔａｒｔ ｋｅｙ ｍｉｄｄｌｅ ｖａｌｕｅ ｅｎｄ）
ペアズ→ペア ペアズ｜“”（ｐａｉｒｓ→ｐａｉｒ ｐａｉｒｓ｜””）
鍵→文字列（ｋｅｙ→ｃｈａｒｓ）
値→文字列｜オブジェクト（ｖａｌｕｅ→ｃｈａｒｓ｜ｏｂｊｅｃｔ）
文字列→文字 文字列｜“”（ｃｈａｒｓ→ｃｈａｒ ｃｈａｒｓ｜””）
文字→Ｕｎｉｃｏｄｅ－エスケープ化｜エスケープ エスケープ化｜追加文字列（ｃｈａｒ→Ｕｎｉｃｏｄｅ － ｅｓｃａｐｅｄ｜ｅｓｃａｐｅ ｅｓｃａｐｅｄ｜ａｄｄｅｄＣｈａｒｓ）
特別→開始特殊｜中間特殊｜終了特殊（ｓｐｅｃｉａｌ→ｓｔａｒｔＳｐｅｃｉａｌ｜ｍｉｄｄｌｅＳｐｅｃｉａｌ｜ｅｎｄＳｐｅｃｉａｌ）
開始→非エスケープ化_ｓ 開始特殊（ｓｔａｒｔ→ｕｎｅｓｃａｐｅｄ_ｓ ｓｔａｒｔＳｐｅｃｉａｌ）
中間→非エスケープ化_ｍ 中間特殊（ｍｉｄｄｌｅ→ｕｎｅｓｃａｐｅｄ_ｍ ｍｉｄｄｌｅＳｐｅｃｉａｌ）
終了→非エスケープ化_ｅ 終了特殊（ｅｎｄ→ｕｎｅｓｃａｐｅｄ_ｅ ｅｎｄＳｐｅｃｉａｌ）
エスケープ化→特殊｜エスケープ｜．．．（ｅｓｃａｐｅｄ→ｓｐｅｃｉａｌ｜ｅｓｃａｐｅ｜．．．）

上記では、Ｓは、開始非端末（Ｈの文章を表す）であり、非端末開閉は、鍵－値ペアのセットの開閉を区切り、開始、中間、終了は、鍵－値ペアの開始、鍵と値との間の分離、およびペアの終了を区切る特殊なストリングである。

特殊な文字、すなわち文法を構文解析する際に特殊な意味を有する文字、構文解析する際に曖昧さを除去するために、特殊な非終端エスケープが使用される。例えば、ＪＳＯＮでは、鍵は、前に「空白の二重引用符」（“）が付いており、かつ後に二重引用符が付いている場合に、構文解析される。鍵または値の式自体が二重引用符を含まなければならない場合、それらは、前にバックスラッシュ（＼）が付く、すなわちエスケープ化しなければならない。上記のルールでは、特殊文字の前で非エスケープ化した非終端は、それらを特殊文字として構文解析することができることを意味する。そのため、前進して、鍵－値ペアの生成には曖昧さがないことを前提とすることができる。そのため、鍵－値文法ＧにおけるストリングＲのサブストリングＲ’がペアとして構文解析する場合、Ｒ’は、Ｒの構文解析木におけるペアに対応しなければならない。

上記の鍵－値文法では、中間は、空のストリングを導出することができず、すなわち、値から鍵を構文解析することを可能にするためには、空でないストリングが中間をマークしなければならない。ただし、開始および終了の一方は、一方のペアの値の間の分離を次のペアの鍵から区切るのみであることから、空の導出を行うことができる。最後に、いくつかの実施形態では、鍵－値文法のための２段階構文解析では、選択的開示されたストリング、Ｒ_ｏｐｅｎがペアに対応するという要件を有する許容経路を考慮するに過ぎないことに留意されたい。

ローカルに一意の鍵の２段階構文解析。多くの鍵－値文法は、一定の範囲内で鍵の一意性を強制する。例えば、ＪＳＯＮでは、オブジェクト間で重複する鍵がある可能性があっても、鍵は、ＪＳＯＮオブジェクト内で一意であるものとすることができる。そのような文法のための２段階構文解析は、サブストリングを構文解析することに還元することができる。具体的には、Ｔｒａｎｓは、Ｒ’内であってもペアの範囲を正しく判定することができるように、連続的なサブストリングＲ’をＲから抽出する。例えば、ＪＳＯＮでは、Ｒ’がＲのプレフィックスである場合に限ってｃｏｎｓ_Ｇ，Ｇ’（Ｒ，Ｒ’）が真を返す場合には、Ｒ_ｏｐｅｎを生じさせる部分木を生成するまでＲ’をＪＳＯＮとして構文解析するだけで、ストリングＲ_ｏｐｅｎがＲ中の正しいコンテキストに対応するかどうかを判定するのに十分である。

一意の鍵を用いる文法。鍵－値文法Ｇが与えられると、ｕ_Ｇと表される、鍵の一意性をチェックする関数を定義する。開始 ｋ 中間として構文解析できるｓのサブストリングが最大でも１つ存在する場合に限り、ストリングｓ∈Ｇおよび別のストリングｋ，ｕ_Ｇ（ｓ，ｋ）＝真が与えられる。ｓ∈Ｇであることから、このことは、ｓの任意の構文解析木に、ノード鍵および導出ｋを有する最大で１つの分岐が存在することを意味する。Ｐａｒｓｅｒ_Ｇを、入力が文法Ｇ内にある場合に真を返す関数とする。文法Ｇは、すべての可能な鍵ｋ，ｕ_Ｇ（ｓ，ｋ）＝真、すなわちすべてのストリングＲ，Ｃについて、以下の場合に、一意の鍵を有する鍵－値文法であると言う：

一意の鍵文法の具体的な２段構文解析。Ｕを、上記に与えられる一意の鍵文法とする。Ｕは、ＬＬ（１）であるものとする。このことは、前述した興味のある例示的な文法に当てはまる。一般的なＬＬ（１）構文解析アルゴリズムが、知られている。

ＴがＵのストリングのペアへの許容経路を含むように、設定Ｔのためのコンテキスト関数ＣＴＸ_Ｕをインスタンス化する。加えて、ＣＴＸ_Ｕが補助的な制限として鍵ｋ（Ｐの出力Ｒ_ｏｐｅｎで指定された鍵）を取ることを可能にする。タプル（Ｔ，ｋ）は、ＳおよびＣＴＸ_Ｕ（Ｓ，・，・）ＣＴＸ_Ｕ，Ｓと表される。

Ｐを、ルールＳ_Ｐ→ペアによって与えられた文法であるとし、ここで、ペアは、Ｕの生成ルールの非終端であり、Ｓ_Ｐは、Ｐの開始記号である。Ｐａｒｓｅｒ_Ｐ，ｋを、ストリングｓがＰにあるかどうか、およびもしそうである場合、ｓの鍵がｋに等しいかどうかを決定する関数として定義する。入力Ｒ、Ｒ_ｏｐｅｎがあると、ＣＴＸ_Ｕ，Ｓは、以下のことをチェックする：（ａ）Ｒ_ｏｐｅｎは、Ｐａｒｓｅｒ_Ｐ，ｋを実行させることによる鍵ｋを有する有効な鍵－値ペアである（ｂ）Ｒ_ｏｐｅｎは、ＬＬ（１）構文解析アルゴリズムを実行してＲを構文解析することによって、Ｒにおける鍵－値ペアとして構文解析する。

図１４は、鍵－値文法ＵでのストリングＲを解析し、かつ特定の鍵－値ペアＲ_ｏｐｅｎの生成を探索するための関数ＣＴＸ_Ｕ，Ｓに対する例示的な擬似コードを示す。ここで、ＵのＬＬ（１）構文解析表であるＰＴａｂｌｅは、ＣＴＸ_Ｕ，Ｓにハードコード化されている。

長いストリングＲ上のＣＴＸ_Ｕ、Ｓの高価な計算を回避するために、要件に従ってＲ’＝Ｒ_ｏｐｅｎであるような、ＲのサブストリングＲ’を抽出するために、変換Ｔｒａｎｓを導入する。

また、ストリングｓ，ｔについて、ｔがｓのサブストリングである場合に真を返す関数ｓｕｂｓｔｒｉｎｇ（ｓ，ｔ）と、ｓ＝ｔの場合に真を返すｅｑｕａｌ（ｓ，ｔ）と、を定義する。以下のルールを用いるｃｏｎｓ_Ｕ，Ｐ：

と、Ｓ’＝｛Ｓ_Ｐ｝と、を定義する。つまり、ｅｑｕａｌ（Ｒ’，Ｒ_ｏｐｅｎ）およびルール

が、すべてのストリングＲ’，Ｒ_ｏｐｅｎに対して持続する場合にはいつでも、ＣＴＸ_Ｐ（Ｓ，Ｒ’，Ｒ_ｏｐｅｎ＝真。

Ｓに関して（ｃｏｎｓ_Ｕ，Ｐ，Ｓ’）が正しいことを示すことができる。より具体的には、Ｒ’がＲのサブストリングである場合、鍵－値ペアＲ_ｏｐｅｎは、Ｐａｒｓｅｒ_Ｐによって解析され、次いで、同じペアがＵのサブストリングになっていなければならない。Ｕにおける鍵のグローバルな一意性に起因して、そのようなペアＲ_ｏｐｅｎは１つのみ存在し、ＣＴＸ_Ｕ（Ｓ，Ｒ，Ｒ_ｏｐｅｎ）は真でなければならない。

本明細書の他の箇所に記載されたものと同様に、上記の追加のプロトコルの詳細は、例示的な例としてのみ提示され、いかなるようにも限定することは意図されていない。他の実施形態は、本明細書に開示される非集中型オラクルを実装する際に、代替プロトコル取り決めを利用することができる。

上記に示したように、本明細書に開示される非集中型オラクルの例示的な実施形態を、多種多様な異なるアプリケーションに実装することができる。

例えば、ＤＥＣＯを使用して、ユーザが自分の個人データを管理し、販売する個人データ市場を実装することができる。ウェブサービスはユーザデータを収益化することで利益を得ていることは周知である。本明細書に開示される技術を使用して実装された個人データ市場は、ユーザがオープン市場でデータを販売することを可能にすることによって、このデータ独占を妨害する可能性がある。ＤＥＣＯは、例示的な実施形態では、個人データ市場の鍵となるイネーブラーであり、それは、ＤＥＣＯが、購入者がウェブサイトからのデータの起点および完全性を検証することを可能にするからである。ＤＥＣＯはまた、販売者が不正行為を行うことを防止しながら、プライバシー保護のために機密情報を黒塗りするなど、販売者がデータを前処理することを可能にする。いくつかの実装態様では、ＤＥＣＯを利用して価格差別に対する検証可能な請求を提供する。

別の例として、ＤＥＣＯを使用して、金銭的な支払能力の証明を提供することができる。このタイプの取り決めのより具体的な例示として、ＤＥＣＯを用いて、アリスは、ボブに対して、彼女の特定の銀行の残高が５０００ドルを超えていることを証明することができる。この単純な証明は、アリスの金銭的な弁済能力だけでなく、口座開設の能力も示す（例えば、銀行がマネーローンダリング防止（ＡＭＬ）スクリーニングを実施する際に、アリスが制裁リスト上にないこと）。重要なことに、ＤＥＣＯは、彼女の残高が実際の残高または識別情報ではなく、５，０００ドルを超えているという事実だけを明示することによって、アリスのプライバシーを保護する。

さらなる例として、ＤＥＣＯを使用して、アカウント所有権の証明を提供することができる。そのような取り決めの一例では、ＤＥＣＯを用いて、匿名でアカウント、例えば電子メールアカウント、ソーシャルメディアアカウント、の所有権を証明することができる。例えば、アリスは、アカウント名がどのようなものであるかを明示することなく、彼女が＠ｅｘａｍｐｌｅ．ｏｒｇで終わる電子メールアカウントを所有していることをボブに対して証明することができる。これにより、アリスが特定の組織に所属していることが証明され、例えば、内部告発、匿名の苦情などに有用である。

本明細書に開示される非集中型オラクルのアプリケーションの追加の例として、クレデンシャル回復および非集中化された識別情報が上げられる。前者の例示として、ＤＥＣＯは、ＯＡＵＴＨの使用を回避するプライバシー保存する様式で、ユーザが、彼女が特定のウェブリソース、例えばＦａｃｅｂｏｏｋアカウントにアクセスできることを証明することを可能にすることができる。これにより、ユーザは、例えば鍵回復のために、既存のサービスを活用して、彼女の識別情報を証明することを可能にすることができる。後者の例示として、ＤＥＣＯはまた、ユーザが、第三者プロバイダによって主張されるような特定の特性を有する（例えば、彼女は１８歳以上である）ことを、プライバシー保存する様式で証明することを可能にすることができる。これは、本明細書では匿名の年齢証明とも呼ばれるものの例である。そのような証明を使用して、非集中型識別情報システムにおけるクレデンシャルを構築することができる。

前述の非集中型オラクルアプリケーションは、単なる例であり、いかなるようにも制限するものと解釈されるものではない。本明細書に開示される非集中型オラクルのこれらのおよび他の例示的なアプリケーションの実装態様に関する追加の詳細は、本明細書の他の箇所に見出すことができる。

本明細書に開示される１つ以上の非集中型オラクルを実装するように構成された情報処理システムの様々な要素間の通信は、１つ以上のネットワークを介して行われるものとする。所与のそのようなネットワークは、例えば、インターネット、ＷＡＮ、ＬＡＮ、衛星ネットワーク、電話またはケーブルネットワーク、３Ｇ、４Ｇ、もしくは５Ｇネットワークなどのセルラネットワーク、Ｂｌｕｅｔｏｏｔｈ、ＷｉＦｉ、もしくはＷｉＭＡＸなどの無線プロトコルを使用して実装された無線ネットワーク、またはこれらのおよび他のタイプの通信ネットワークの様々な部分または組み合わせを例示的に含むことができる。

本明細書に開示される非集中型オラクルの機能性の少なくとも一部分を実装する所与の処理デバイスは、プロセッサ、メモリ、およびネットワークインターフェースなどのコンポーネントを含むことができる。プロセッサは、メモリに、およびネットワークインターフェースに動作可能に結合されているものとする。メモリは、処理デバイスの機能性の一部分を実装する際に、プロセッサによる実行のためのソフトウェアプログラムコードを記憶する。

本明細書に図１～図１４と併せて示され、記載される特定の配置が単に例示的な例として提示され、多数の代替実施形態が可能であることを認識されたい。したがって、本明細書に開示される様々な実施形態は、いかなるようにも限定するものと解釈されるものではない。非集中型オラクルを実装するための多数の代替配置を、他の実施形態で利用することができる。例えば、当業者は、代替の処理動作および関連付けられたシステム実体構成を、他の実施形態で使用することができることを認知するであろう。したがって、他の実施形態は、例示的な実施形態のエンティティと比較して、追加のまたは代替のシステムエンティティを含み得ることが可能である。また、特定のシステムおよびデバイスの構成ならびに関連付けられた非集中型オラクルを、他の実施形態で変えることができる。

また、上述の情報処理システム配置は、例示的なものに過ぎず、他の実施形態では代替のシステム構成を使用することができることに留意されたい。

本明細書に記載される情報処理システムにおける所与のクライアント、サーバ、プロセッサ、または他のコンポーネントは、メモリに結合されたプロセッサを含む対応する処理デバイスを利用して例示的に構成されている。プロセッサは、処理動作および他の機能性の性能を制御するために、メモリに記憶されたソフトウェアプログラムコードを実行する。処理デバイスはまた、１つ以上のネットワークを介した通信をサポートするネットワークインターフェースを備える。

プロセッサは、例えば、マイクロプロセッサ、ＡＳＩＣ、ＦＰＧＡ、ＣＰＵ、ＧＰＵ、ＡＬＵ、ＤＳＰ、または他の同様の処理デバイスコンポーネント、ならびに他のタイプおよび配置の処理回路機構を、任意の組み合わせで備えてもよい。例えば、本明細書に開示される所与の処理デバイスによって提供される非集中型オラクルの機能性の少なくとも一部分を、そのような回路機構を使用して実装することができる。

メモリは、処理デバイスの機能性の一部分を実装する際に、プロセッサによる実行のためのソフトウェアプログラムコードを記憶する。対応するプロセッサによる実行のためのそのようなプログラムコードを記憶する所与のそのようなメモリは、本明細書で、より一般に、プログラムコードが内部で具現化されたプロセッサ可読記憶媒体と呼ばれるものの例であり、例えば、ＳＲＡＭ、ＤＲＡＭ、もしくは他のタイプのＲＡＭ、ＲＯＭ、フラッシュメモリ、磁気メモリ、光学メモリ、または他のタイプの記憶デバイスなどの電子メモリを、任意の組み合わせで備えてもよい。

そのようなプロセッサ可読記憶媒体を備える製造物品は、本発明の実施形態と見なされる。本明細書で使用される「製造品」という用語は、一過性の伝播信号を除外すると理解されるものである。

プロセッサ可読記憶媒体を備える他のタイプのコンピュータプログラム製品を、他の実施形態で実装することができる。

加えて、本発明の実施形態は、非集中型オラクルと関連付けられた処理動作、ならびに他の関連する機能性を実装するように構成された処理回路機構を備える集積回路の形態で実装され得る。

所与の実施形態における処理デバイスは、例えば、ラップトップ、タブレットもしくはデスクトップパーソナルコンピュータ、携帯電話、または他のタイプのコンピュータもしくは通信デバイスを任意の組み合わせで含むことができる。例えば、コンピュータまたは携帯電話を、本明細書に開示される非集中型オラクルと関連付けられた機能性の少なくとも一部分を実装するための処理デバイスとして利用することができる。それぞれのシステムエンティティと関連付けられた処理デバイスを備える情報処理システムの様々な要素間のこれらのおよび他の通信は、１つ以上のネットワークを介して行われ得る。

本明細書に開示される情報処理システムは、１つ以上の処理プラットフォーム、またはその一部を使用して実装され得る。

例えば、情報処理システムの少なくとも一部分を実装するために使用され得る処理プラットフォームの例示的な一実施形態は、物理インフラストラクチャ上で動作するハイパーバイザを使用して実装される仮想マシンを含むクラウドインフラストラクチャを備える。そのような仮想マシンは、１つ以上のネットワークを介して互いに通信するそれぞれの処理デバイスを備えてもよい。

そのような実施形態におけるクラウドインフラストラクチャは、ハイパーバイザの制御下で仮想マシンのそれぞれの仮想マシンで動作するアプリケーションの１つ以上のセットをさらに備え得る。少なくとも１つの基礎となる物理マシンを使用して、各々が仮想マシンのセットを提供する複数のハイパーバイザを使用することも可能である。１つ以上のハイパーバイザによって提供される異なるセットの仮想マシンは、情報処理システムの様々な構成要素の複数のインスタンスを構成する際に利用されてもよい。

本明細書に開示される情報処理システムの少なくとも一部分を実装するために使用され得る処理プラットフォームの別の例示的な実施形態は、少なくとも１つのネットワークを介して互いに通信する複数の処理デバイスを備える。処理プラットフォームの各処理デバイスは、メモリに結合されたプロセッサを備えるものとする。

ここでも、これらの特定の処理プラットフォームは、単なる例として提示され、情報処理システムは、追加のまたは代替の処理プラットフォーム、ならびに任意の組み合わせでの多数の個別の処理プラットフォームを含み得、そのような各プラットフォームは、１つ以上のコンピュータ、サーバ、記憶デバイス、または他の処理デバイスを備える。

例えば、本発明の実施形態を実装するために使用される他の処理プラットフォームは、仮想マシンを備える仮想化インフラストラクチャの代わりに、またはそれに加えて、異なるタイプの仮想化インフラストラクチャを備え得る。したがって、いくつかの実施形態では、システムコンポーネントは、Ｄｏｃｋｅｒコンテナを利用する仮想化インフラストラクチャ、またはＬｉｎｕｘ（登録商標）制御グループもしくは他の同様のメカニズムに基づくオペレーティングシステムレベルの仮想化を使用して実装される他のタイプのＬｉｎｕｘコンテナを含む、クラウドインフラストラクチャもしくは他のタイプの仮想化インフラストラクチャで少なくとも部分的に動作することが可能である。

したがって、他の実施形態では、追加の要素または代替の要素の異なる配置が使用され得ることを理解されたい。少なくとも、これらの要素のサブセットは、共通の処理プラットフォーム上に集合的に実装されてもよいし、各々のそのような要素が、別個の処理プラットフォーム上に実装されてもよい。

また、コンピュータ、サーバ、記憶デバイス、または他の構成要素の多数の他の構成が、情報処理システムにおいて可能である。そのような構成要素は、任意のタイプのネットワークまたは他の通信媒体を介して、情報処理システムの他の要素と通信することができる。

前に示したように、本明細書に開示されるシステムの構成要素を、少なくとも部分的に、メモリに記憶され、かつ処理デバイスのプロセッサによって実行される１つ以上のソフトウェアプログラムの形態で、実装することができる。例えば、システムの非集中型オラクルエンティティまたは関連するコンポーネントと関連付けられた特定の機能性を、少なくとも部分的にソフトウェアの形態で実装することができる。

本明細書に記載される情報処理システムの特定の構成は、例示的なものに過ぎず、他の実施形態では所与のそのようなシステムは、そのようなシステムの従来の実装態様に一般的に見られるタイプの１つ以上の要素を含む、具体的に示されるものに加えて、またはそれらの代わりに他の要素を含み得る。

例えば、いくつかの実施形態では、情報処理システムは、開示された技術を利用して、他のコンテキストで追加のまたは代替の機能性を提供するように構成され得る。

したがって、本明細書のいくつかの実施形態において、ＴＬＳのための非集中型オラクルを提供するというコンテキストにおいて例示される技術を、他のコンテキストにおいて使用するために、直截的な様式で適合させることができる。したがって、本発明の例示的な実施形態は、ＴＬＳまたはその関連付けられた処理コンテキストに限定されると見なされるものではない。

本明細書に記載される実施形態で使用される特定のプロセスステップは、例示的なものに過ぎず、他の実施形態が異なるタイプおよび配置の処理動作を利用することができることも認識されたい。例えば、例示的な実施形態で連続して実行されるように示される特定のプロセスステップを、他の実施形態では、互いに少なくとも部分的に並行して実行することができる。

本明細書に記載される本発明の実施形態が、単に例示的であることは、ここでも強調されるものである。本発明の他の実施形態を、本明細書に記載される特定の例示的な実施形態において、および多数の代替処理コンテキストにおいて利用されるものよりも多種多様な異なるタイプおよび配置の情報処理システム、ネットワーク、およびデバイスを利用して実装することができる。加えて、特定の実施形態について記載するコンテキストにおいて本明細書で行われる特定の仮定は、他の実施形態に適用される必要はない。これらのおよび多数の他の代替実施形態は、当業者には容易に明らかであろう。

Claims (25)

1. 装置であって、
   メモリに結合されたプロセッサを備える検証器デバイスを備え、
   前記検証器デバイスが、１つ以上のネットワークを介して、クライアントデバイスおよびサーバデバイスと通信するように構成されており、
   前記検証器デバイスが、
   前記クライアントデバイスおよび前記サーバデバイスとの三者ハンドシェイクプロトコルに参加することであって、前記検証器デバイスおよび前記クライアントデバイスが、前記サーバデバイスとのセキュアなセッションのセッション鍵のそれぞれのシェアを取得する、参加することと、
   前記クライアントデバイスから、前記サーバデバイスとの前記セキュアなセッションに関連するコミットメントを受信することと、
   前記コミットメントの受信に応答して、前記クライアントデバイスに対して以前はアクセス可能でなかった、前記セキュアなセッションに関連する追加の情報を、前記クライアントデバイスに公開することと、
   前記コミットメントおよび前記追加の情報に少なくとも部分的に基づいて、前記セキュアなセッションの一部として、前記サーバデバイスから前記クライアントデバイスによって取得されたデータの少なくとも１つの特徴付けの正確性を検証することと、を行うようにさらに構成されている、装置。
2. 前記検証器デバイスが、前記サーバデバイスから前記クライアントデバイスによって取得された前記データの前記少なくとも１つの特徴付けの前記正確性の前記検証に応答して、１つ以上の自動化されたアクションを開始するようにさらに構成されている、請求項１に記載の装置。
3. 前記検証器デバイスが、非集中型オラクルシステムのオラクルノードのセットの特定のオラクルノードを備える、請求項１に記載の装置。
4. 前記検証器デバイスが、前記検証器デバイスの機能性が複数の個別の処理デバイスにわたって分散される分散型検証器デバイスを備える、請求項１に記載の装置。
5. 前記サーバデバイスが、トランスポート層セキュリティ（ＴＬＳ）対応サーバデバイスを備え、前記セキュアなセッションが、ＴＬＳセッションを含む、請求項１に記載の装置。
6. 前記セキュアなセッションに関連する前記コミットメントが、前記セキュアなセッションの一部として、前記サーバデバイスから前記クライアントデバイスによって取得されたクエリ応答データに対するコミットメントを含む、請求項１に記載の装置。
7. 前記セキュアなセッションに関連する前記コミットメントが、前記三者ハンドシェイクプロトコルと併せて、前記クライアントデバイスによって確立されたが、前記検証器デバイスに対して以前にアクセス可能でない、証明器鍵へのコミットメントを含む、請求項１に記載の装置。
8. 前記コミットメントの受信に応答して前記クライアントデバイスに公開された前記追加の情報が、前記三者ハンドシェイクプロトコルと併せて、前記検証器デバイスによって確立されたが、前記クライアントデバイスに対して以前にアクセス可能でない、検証器鍵を含む、請求項１に記載の装置。
9. 前記検証器デバイスが、前記クライアントデバイスと前記サーバデバイスとの間のインタラクションと併せて、前記クライアントデバイスに対するプロキシとして動作するようにさらに構成されており、これにより、前記検証器デバイスが、前記プロキシとして動作する前記検証器デバイスを介した前記セキュアなセッションの一部として、前記クライアントデバイスと前記サーバデバイスとの間で交換される暗号文を自動的に取得する、請求項１に記載の装置。
10. 前記検証器デバイスが、前記セキュアなセッションの一部として、前記サーバデバイスから前記クライアントデバイスによって取得された前記データを特徴付ける１つ以上のステートメントを、前記クライアントデバイスから受信するようにさらに構成されている、請求項１に記載の装置。
11. 前記１つ以上のステートメントのうちの所与の１つが、前記セキュアなセッションの一部として、前記サーバデバイスから前記クライアントデバイスによって取得されたクエリ応答データの選択的に明示されたサブストリングを含む、請求項１０に記載の装置。
12. 前記１つ以上のステートメントのうちの所与の１つが、多段階構文解析プロトコルの利用を通じて、コンテキスト完全性を提供するように構成されており、前記セキュアなセッションの一部として、前記サーバデバイスから前記クライアントデバイスによって取得されたクエリ応答データが、前記クライアントデバイスによって前処理されて、前記クライアントデバイスによって前記検証器デバイスに送信される前記所与のステートメントの生成と併せて、前記クライアントデバイスによって続いて解析される低減されたデータを生成する、請求項１０に記載の装置。
13. 前記三者ハンドシェイクプロトコルと併せて、前記クライアントデバイスおよび前記検証器デバイスが、前記サーバデバイスとの１つ以上の共有セッション鍵を合同で確立し、前記クライアントデバイスが、前記１つ以上の共有セッション鍵のうちの所与の１つの第１のシェアを有し、前記検証器デバイスが、前記所与の共有セッション鍵の第２のシェアを有し、前記サーバデバイスが、前記第１および第２のシェアを組み合わせる複合セッション鍵を有する、請求項１に記載の装置。
14. 前記三者ハンドシェイクプロトコルと併せて、前記クライアントデバイスが、前記サーバデバイスから、前記検証器デバイスに対してアクセス可能でない暗号鍵を受信する、請求項１に記載の装置。
15. 前記検証器デバイスおよび前記クライアントデバイスが、前記サーバデバイスとの前記セキュアなセッションの前記セッション鍵のそれらのそれぞれのシェアを使用して共同して、前記サーバデバイスが前記クライアントデバイスに前記データを送信することを要求するために、前記クライアントデバイスによって前記サーバデバイスに提供されるクエリを生成する、請求項１に記載の装置。
16. 前記検証器デバイスおよび前記クライアントデバイスが、前記サーバデバイスとの前記セキュアなセッションの前記セッション鍵のそれらのそれぞれのシェアを使用して共同して、前記クエリに応答して、前記サーバデバイスによって前記クライアントデバイスに提供される応答を確証する、請求項１５に記載の装置。
17. 前記三者ハンドシェイクプロトコルと併せて、前記クライアントデバイスおよび前記検証器デバイスが、それぞれの証明器鍵および検証器鍵を確立する、請求項１に記載の装置。
18. 前記セキュアなセッションの一部として、前記サーバデバイスから前記クライアントデバイスによって取得されたデータの少なくとも１つの特徴付けの正確性を検証することが、前記クライアントデバイスによって前記検証器デバイスに提供された証明を検証することを含み、前記証明が、（ｉ）前記三者ハンドシェイクプロトコルと併せて、前記クライアントデバイスによって確立された前記証明器鍵、（ｉｉ）前記三者ハンドシェイクプロトコルと併せて、前記検証器デバイスによって確立された前記検証器鍵、および（ｉｉｉ）前記クライアントデバイスの秘密情報に少なくとも部分的に基づいて、前記クライアントデバイスによって生成される、請求項１７に記載の装置。
19. 前記セキュアなセッションの一部として、前記サーバデバイスから前記クライアントデバイスによって取得されたデータの少なくとも１つの特徴付けの正確性を検証することが、
    前記セキュアなセッションの少なくとも１つの暗号文の少なくとも一部分から導出されたデータを取得することと、
    前記クライアントデバイスによって、そのデータの少なくとも１つの特徴付けの正確性を検証することと、を含む、請求項１に記載の装置。
20. １つ以上のネットワークを介して、クライアントデバイスおよびサーバデバイスと通信するように構成された検証器デバイスによって実行される方法であって、
    前記クライアントデバイスおよび前記サーバデバイスとの三者ハンドシェイクプロトコルに参加することであって、前記検証器デバイスおよび前記クライアントデバイスが、前記サーバデバイスとのセキュアなセッションのセッション鍵のそれぞれのシェアを取得する、参加することと、
    前記クライアントデバイスから、前記サーバデバイスとの前記セキュアなセッションに関連するコミットメントを受信することと、
    前記コミットメントの受信に応答して、前記クライアントデバイスに対して以前はアクセス可能でなかった、前記セキュアなセッションに関連する追加の情報を前記クライアントデバイスに公開することと、
    前記コミットメントおよび前記追加の情報に少なくとも部分的に基づいて、前記セキュアなセッションの一部として、前記サーバデバイスから記クライアントデバイスによって取得されたデータの少なくとも１つの特徴付けの正確性を検証することと、を含み、
    前記方法を実行する前記検証器デバイスが、メモリに結合されたプロセッサを備える、方法。
21. 前記セキュアなセッションの一部として、前記サーバデバイスから前記クライアントデバイスによって取得されたデータの少なくとも１つの特徴付けの正確性を検証することが、
    前記セキュアなセッションの少なくとも１つの暗号文の少なくとも一部分から導出されたデータを取得することと、
    前記クライアントデバイスによって、そのデータの少なくとも１つの特徴付けの正確性を検証することと、を含む、請求項２０に記載の方法。
22. 前記検証器デバイスが、前記クライアントデバイスと前記サーバデバイスとの間のインタラクションと併せて前記クライアントデバイスに対するプロキシとして動作するようにさらに構成されており、これにより、前記検証器デバイスが、前記プロキシとして動作する前記検証器デバイスを介した前記セキュアなセッションの一部として前記クライアントデバイスと前記サーバデバイスとの間で交換される暗号文を自動的に取得する、請求項２０に記載の方法。
23. １つ以上のソフトウェアプログラムのプログラムコードを内部に記憶した非一時的プロセッサ可読記憶媒体を備えるコンピュータプログラム製品であって、前記プログラムコードが、１つ以上のネットワークを介して、クライアントデバイスおよびサーバデバイスと通信するように構成された検証器デバイスであって、メモリに結合されたプロセッサを含む検証器デバイスによって実行されると、前記検証器デバイスに、
    前記クライアントデバイスおよび前記サーバデバイスとの三者ハンドシェイクプロトコルに参加することであって、前記検証器デバイスおよび前記クライアントデバイスが、前記サーバデバイスとのセキュアなセッションのセッション鍵のそれぞれのシェアを取得する、参加することと、
    前記クライアントデバイスから、前記サーバデバイスとの前記セキュアなセッションに関連するコミットメントを受信することと、
    前記コミットメントの受信に応答して、前記クライアントデバイスに対して以前はアクセス可能でなかった、前記セキュアなセッションに関連する追加の情報を前記クライアントデバイスに公開することと、
    前記コミットメントおよび前記追加の情報に少なくとも部分的に基づいて、前記セキュアなセッションの一部として、前記サーバデバイスから前記クライアントデバイスによって取得されたデータの少なくとも１つの特徴付けの正確性を検証することと、を行わせる、コンピュータプログラム製品。
24. 前記セキュアなセッションの一部として、前記サーバデバイスから前記クライアントデバイスによって取得されたデータの少なくとも１つの特徴付けの正確性を検証することが、
    前記セキュアなセッションの少なくとも１つの暗号文の少なくとも一部分から導出されたデータを取得することと、
    前記クライアントデバイスによって、そのデータの少なくとも１つの特徴付けの正確性を検証することと、を含む、請求項２３に記載のコンピュータプログラム製品。
25. 前記検証器デバイスが、前記クライアントデバイスと前記サーバデバイスとの間のインタラクションと併せて前記クライアントデバイスに対するプロキシとして動作するようにさらに構成されており、これにより、前記検証器デバイスが、前記プロキシとして動作する前記検証器デバイスを介した前記セキュアなセッションの一部として前記クライアントデバイスと前記サーバデバイスとの間で交換される暗号文を自動的に取得する、請求項２３に記載のコンピュータプログラム製品。

Images