JP2022525137A - データに基づく行為を実施するための方法および装置 - Google Patents

Abstract

コーディネートネットワーク要素は、当該コーディネートネットワーク要素が、受信された、プロトコルに準拠した要求の基礎を少なくとも部分的になすデータ内容に実質的にアクセスすることを阻止するプロトコルを管理する。１つの手法によると、これらの教示は、プロトコルに準拠した要求の中にトークン化された形態で含まれているデータ情報への実質的なアクセスを防止できるようにし、トークンは、少なくともそのうち１つがコーディネートネットワーク要素には入手不可能である秘密を使用して生成される。

Description

関連出願
本出願は、２０１９年３月１３日に出願された米国仮出願番号第６２／８１８，０１４号、２０１９年３月１８日に出願された米国仮出願番号第６２／８２０，１５１号、２０１９年３月２０日に出願された米国仮出願番号第６２／８２１，０２１号、２０１９年８月１２日に出願された米国仮出願番号第６２／８８５，７２９号、２０１９年１１月８日に出願された米国仮出願番号第６２／９３２，７３０号、および２０２０年３月１２日に出願された米国仮出願番号第６２／９８８，７６０号の利益を主張し、これらの各出願はその全体が参照により本明細書に援用される。

これらの教示は、概してデータにアクセスすることに関し、より詳しくはプライバシーの維持に関する。

現代のデータ通信システムは、各種の情報を迅速かつ確実に移送することに長けている。場合によっては、これは、例えば経路情報を暗号化するための暗号化技術を使用して、そのような情報を安全に移送できるようにすることも含む。

多くの場合、前述の情報の提供は、情報の最初のソースまたは情報の直接のソースのいずれかを識別する情報を含む。ソースが誰であるのかを知ることは、情報自体の正しさに対する対応する信頼を有するために、場合によっては重要であることがある。しかし、ソースが受信者に対して知られないままでいることを望み得る場合がある。従来技術は身元情報を隠すことができるようにするが、そのような手法は、ソースを信頼するための根拠を欠くため、受信した情報への信頼を犠牲にしてその結果を実現している傾向がある。

そのため、現在のデータ通信技術は、いかにして身元情報を保護しつつ、同時に情報ソースの正しさを受信者に保証するか？という難題を呈する。

上記の必要性は、特に以下の図面と併せて考察されるときに、以下の詳細な説明に記載されるデータに基づく行為を実施するための方法および装置の提供を通じて、少なくとも部分的に満たされる。

これらの教示の様々な実施形態により構成されたブロック図である。 これらの教示の様々な実施形態により構成された流れ図である。 これらの教示の様々な実施形態により構成されたブロック図であり、アテスター（attester）またはリクエスターとしての関係者が関与する、第３者によって管理されるプロトコルを介した関係者間のブラインドされた情報／データの交換または確証の概要を説明するブロック図である。 これらの教示の様々な実施形態により構成された流れ図であり、証明行為の一部としての預け入れおよび要求行為の一部としての取出しのための中継者との通信を含む、確証を可能にするための証明および要求を説明する流れ図である。図４に描かれた送信は、明示的には図示されない、後に解読される暗号化などのオーバーレイを含み得る。 これらの教示の様々な実施形態により構成された流れ図であり、図４の中継者で使用するためにコーディネータによって関係者クライアントに提供される権限付与を説明する流れ図である。図５に描かれた送信は、明示的には図示されない、後に解読される暗号化などのオーバーレイを含み得る。 これらの教示の様々な実施形態により構成された流れ図であり、証明行為の一部としての預け入れおよび要求行為の一部としての取出しのための中継者との通信を含む、データの移送を可能にするための証明および要求を説明する流れ図である。図６に描かれた送信は、明示的には図示されない、後に解読される暗号化などのオーバーレイを含み得る。 本発明の様々な実施形態により構成された流れ図であり、図６の中継者で使用するためにコーディネータによって関係者クライアントに提供される権限付与を説明する流れ図である。図７に描かれた送信は、明示的には図示されない、後に解読される暗号化などのオーバーレイを含み得る。 これらの教示の様々な実施形態により構成された流れ図であり、サーバＳが、正しく振舞っている関係者Ｐに、「疑陽性」、すなわち偽の一致の指示を送付するために、データ確証プロトコルのそのバージョンの不適切性を悪用する「疑陽性を起こしやすいプロトコル」を説明する流れ図である。図８に描かれた送信は、明示的には図示されない、後に解読される暗号化などのオーバーレイを含み得る。 本発明の様々な実施形態により構成された流れ図であり、サーバＳと関係者Ｐの両方が予想されるように振舞う、データ確証のための「基本プロトコル」を説明する流れ図である。図９に描かれた送信は、明示的には図示されない、後に解読される暗号化などのオーバーレイを含み得る。 これらの教示の様々な実施形態により構成された流れ図であり、関係者ＰがサーバＳに対して両者が同じデータ値のカプセル化を共有していることを証明する、データ確証のための「後続プロトコル、オプション１」を説明する流れ図である。図１０に描かれた送信は、明示的には図示されない、後に解読される暗号化などのオーバーレイを含み得る。 これらの教示の様々な実施形態により構成された流れ図であり、関係者Ｐが、自身のデータ値のカプセル化ｃ’をサーバＳに開示し、サーバＳが、ｃ’の真正性を検証し、ｃ’を自分自身のデータ値のカプセル化ｃと比較する、データ確証のための「後続プロトコル、オプション２」を説明する流れ図である。図１１に描かれた送信は、明示的には図示されない、後に解読される暗号化などのオーバーレイを含み得る。 これらの教示の様々な実施形態により構成された流れ図であり、ＴＯＫＥＮ生成の実施形態を説明する流れ図である。図１２（ａ）は、２つのバックエンドによる双方向のカスケード式処理を伴い、各バックエンドは、他方と、および後続トランスレータのものと異なる秘密値を利用する。 これらの教示の様々な実施形態により構成された流れ図であり、ＴＯＫＥＮ生成の実施形態を説明する流れ図である。図１２（ｂ）は、２つのバックエンドによる一方向のカスケード式処理を伴い、各バックエンドは、他方と、および後続トランスレータのものと異なる秘密値を利用する。 これらの教示の様々な実施形態により構成された流れ図であり、ＴＯＫＥＮ生成の実施形態を説明する流れ図である。図１２（ｃ）は、２つのバックエンドによる単独に独立した処理を伴い、バックエンドは後続トランスレータのものとは異なる同じ秘密値を利用する。図１２（ａ）、図１２（ｂ）、および図１２（ｃ）に描かれた送信は、明示的には図示されない、後に解読される暗号化などのオーバーレイを含み得る。 これらの教示の様々な実施形態により構成された流れ図であり、関係者によって導入されるブラインドファクタ（blinding factor）が、トランスレータではなく関係者によって後に除去されるという点で図１２（ａ）、図１２（ｂ）および図１２（ｃ）のものとは異なるＴＯＫＥＮ生成のさらなる実施形態を説明する流れ図である。図１３に描かれた送信は、明示的には図示されない、後に解読される暗号化などのオーバーレイを含み得る。 これらの教示の様々な実施形態により構成された流れ図であり、不正行為属性トークン（ＦＡＴＯＫＥＮ）生成の一実施形態を説明する流れ図である。図１４に描かれた送信は、明示的には図示されない、後に解読される暗号化などのオーバーレイを含み得る。 これらの教示の様々な実施形態により構成された流れ図であり、ＴＯＫＥＮおよびＦＡＴＯＫＥＮの生成に適する、混合型実施形態の高水準の概要を説明する流れ図である。図１５に描かれた送信は、明示的には図示されない、後に解読される暗号化などのオーバーレイを含み得る。 これらの教示の様々な実施形態により構成された流れ図であり、楕円曲線Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎ暗号動作の実例の通信および処理を説明する流れ図である。 これらの教示の様々な実施形態により構成された流れ図であり、一方向楕円曲線Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎ暗号動作の実例の通信および処理を説明する流れ図である。 これらの教示の様々な実施形態により構成された流れ図であり、完全楕円曲線Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎ暗号プロセスの実例の通信および処理を説明する流れ図である。 これらの教示の様々な実施形態により構成された流れ図であり、ワンパス楕円曲線Ｄｉｆｆｉｅ－Ｈｅｌｌｍａｎ鍵交換の実例の通信および処理を説明する流れ図である。 これらの教示の様々な実施形態により構成された流れ図であり、楕円曲線Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎまたはワンパス楕円曲線Ｄｉｆｆｉｅ－Ｈｅｌｌｍａｎの受信者側の実例の、２パーティションプロセッサによる通信および処理を説明する流れ図である。 これらの教示の様々な実施形態により構成された流れ図であり、楕円曲線Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎまたはワンパス楕円曲線Ｄｉｆｆｉｅ－Ｈｅｌｌｍａｎの受信者側の実例の、ｋパーティションプロセッサによる通信および処理を説明する流れ図である。 これらの教示の様々な実施形態により構成された流れ図であり、バックエンドプロセッサタイプのプロセッサが複数あり、各プロセッサがパーティションペアを備える場合におけるバックエンド鍵生成を説明する流れ図である。図２２は、プライベート鍵、公開鍵、および内部の（すなわち、プロセッサパーティションがその対応プロセッサパーティションと通信する）ハッシュに基づくメッセージ認証コード（ＨＭＡＣ）鍵の生成を描いた図である。この図は、トランスレータプロセッサタイプについての鍵生成も同様に表している。 これらの教示の様々な実施形態により構成された流れ図であり、バックエンドまたはトランスレータによる一切の処理の前にＴＯＫＥＮを要求する際の関係者の最初のプロセスを説明する流れ図である。Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎ暗号およびワンパスＤｉｆｆｉｅ－Ｈｅｌｌｍａｎのイニシエータのステップを用いる処理に関するＩＮＦＯの不可視化を表している。 これらの教示の様々な実施形態により構成された流れ図であり、トークン化プロセスにおけるバックエンドの役割を説明する流れ図である。これは、ワンパスＤｉｆｆｉｅ－Ｈｅｌｌｍａｎの受信者側およびＰｏｈｌｉｇ－Ｈｅｌｌｍａｎプロセスのバックエンド部分を含む。 これらの教示の様々な実施形態により構成された流れ図であり、バックエンドによる処理とトランスレータによる処理との間の関係者のプロセスを説明する流れ図である。これは、関係者のＰｏｈｌｉｇ－Ｈｅｌｌｍａｎ解読と、ワンパスＤｉｆｆｉｅ－Ｈｅｌｌｍａｎのイニシエータのステップとを反映している。 これらの教示の様々な実施形態により構成された流れ図であり、トークン化プロセスにおけるトランスレータの役割を説明する流れ図である。これは、ワンパスＤｉｆｆｉｅ－Ｈｅｌｌｍａｎの受信者側およびＰｏｈｌｉｇ－Ｈｅｌｌｍａｎプロセスのトランスレータ部分を含む。この例では、これはＴＯＫＥＮの作成における最終ステップである。

図中の要素は、単純性および明瞭性のために図示されており、必ずしも実際の縮尺で描かれていない。例えば、図中の要素の一部の寸法および／または相対的配置は、本教示の様々な実施形態の理解を向上する助けとして、他の要素に対して誇張されていることがある。また、商業的に実施可能な実施形態において有用または必要である一般的であるがよく理解されている要素は、本教示のそれら様々な実施形態の図の邪魔にならないようにするために、多くの場合描かれない。ある動作および／またはステップは、特定の発生順序で記載または図示されることがあるが、当業者は、順番に関するそのような特定性は実際には必要とされないことを理解するであろう。本明細書で使用される用語および表現は、異なる特定の意味が別途本明細書に述べられている場合を除き、上記で述べられたように当分野における当業者によるそのような用語および表現に一致させた通常の技術的意味を有する。本明細書で使用される場合、単語「または」は、特段断らない限り、接続構造ではなく離接構造を有するものと解釈されるべきである。

概して、これらの様々な実施形態に従うと、コーディネートネットワーク要素が、受信された、プロトコルに準拠した要求の基礎を少なくとも部分的になすデータ内容に当該コーディネートネットワーク要素が実質的にアクセスすることを阻止するプロトコルを管理する。１つの手法によると、これらの教示は、プロトコルに準拠した要求の中にトークン化された形態で含まれるデータ情報への実質的なアクセスを防止できるようにし、トークンは秘密を使用して生成され、秘密の少なくとも１つはコーディネートネットワーク要素には入手不可能である。

そのようなプロトコルに準拠した要求は、例えば、アテスターの役割内で動作しているネットワーク要素を含む要求元ネットワーク要素から、またはリクエスターの役割内で動作している２次ネットワーク要素として働く要求元ネットワーク要素から、受信され得る。プロトコルに準拠した要求自体は、例えば、参照されるデータ内容、参照されるデータタイプ、参照される初期データ情報ソース、および初期データソースに関連付けられたデータ情報、の少なくとも１つを含むデータ情報に関係し得る。

１つの手法によると、要求元ネットワーク要素が、上述のアテスターの役割内で動作しているネットワーク要素である場合、これらの教示は、要求元ネットワーク要素を介して調達されたデータを、データに基づく処理のために非同期に入手可能にする権限を要求元ネットワーク要素に付与することを、少なくとも部分的には上述のプロトコルを介して容易にできるようにする。データが間接的なデータとして調達される場合、調達することは、初期データソースから要求元ネットワーク要素によって受信されたデータからの導出を伴い得る。そのような場合、２次ネットワーク要素の身元を要求元ネットワーク要素からブラインドし、それにより、それらに関するプライバシーを維持することができる。

１つの手法によると、上述の権限を付与することは、アテスターの役割内で動作している要求元ネットワーク要素が、中継者からアクセス可能なストレージに内容を記憶する権限を付与されることを中継者に通知する、検証可能な許可を生成することを少なくとも部分的に含み得、内容は、データの移動および確証のうち少なくとも一方を可能にするために有用である、暗号パラメータ、データ、およびメタデータ、の少なくとも１つを含む。１つの手法によると、上述の中継者からアクセス可能なストレージに内容を記憶することは、内容の一部を、平文形態および暗号化された形態の少なくとも一方で記憶することを含む。

内容自体は、例えば解読トークンならびに／または暗号パラメータおよびメタデータとして働くことができる、記憶された値を含むことができる。そのような解読トークンは、アテスターの役割内で動作しているときに要求元ネットワーク要素によって生成された暗号文および暗号パラメータのうち少なくとも１つを表す働きをすることができる。上述の暗号パラメータおよびメタデータは、比較トークンを構成するためにデータと共に適用され得る。この場合、アテスターの役割内で動作している要求元ネットワーク要素によって与えられたデータの処理の結果を表す比較トークンに対して、記憶された値を使用して処理された候補データを表す比較トークンの一致があるかどうかに関する判定を行うことができる。

上述の判定は、リクエスターの役割内で動作している要求元ネットワーク要素によって受信された誤った応答に起因して比較トークンの一致がある場合に、リクエスターの役割内で動作している要求元ネットワーク要素により偽って判定を行うことができないように構成することができ、すなわち、偽陽性を回避することができる。上述の判定はさらに、リクエスターの役割内で動作している要求元ネットワーク要素から供給される公開鍵と併せて、暗号化を支援する加法およびスカラー乗法準同型を利用することができ、公開鍵は、リクエスターの役割内で動作している要求元ネットワーク要素により、リクエスターの役割内で動作している要求元ネットワーク要素によって生成された比較トークンの関数に適用され、また、コーディネートネットワーク要素により、リクエスターの役割内で動作している要求元ネットワーク要素に応答する際にアテスターの役割内で動作している要求元ネットワーク要素からコーディネートネットワーク要素によって受信される比較トークンに適用される。

別の手法によると、前述に代えて、またはそれと組み合わせて、上述の内容は、シェアの群であって、閾値数のそのようなシェアが内容の再構成を可能にするようなシェアの群を含み得る。１つの手法によると、それらのシェアは、アテスターの役割内で動作している要求元ネットワーク要素によって複数の中継者に分散される。

１つの手法によると、上述のデータに基づく処理は、証明済みのデータ内容の移動、および以前に証明済みのデータ内容に対するデータ内容の確証、のうち１つまたは複数を含み得る。上述のデータ内容の確証は、次いで、リクエスターの役割内で動作している要求元ネットワーク要素からデータを調達することを少なくとも部分的に含み得、そのデータが間接的なデータとして調達される場合、調達することは、初期データソースから要求元ネットワーク要素によって受信されたデータからの導出を伴う。リクエスターの役割内で動作している要求元ネットワーク要素が、間接的なデータとして調達されたデータを使用する場合、参照される初期データソースの身元と、初期データソースに関連付けられたデータ情報から導出されたいずれかのトークンとは、リクエスターの役割またはアテスターの役割内で動作することが可能な他のネットワーク要素にとって実質的にアクセス不可能にすることができる。

別の手法によると、ここでも前述に代えて、またはそれと組み合わせて、要求元ネットワーク要素がリクエスターの役割内で動作している２次ネットワーク要素である場合、これらの教示は、以前に別の要求元ネットワーク要素から調達されたデータを処理するための２次ネットワーク要素の権限付与を、少なくとも部分的には上述のプロトコルを介して容易にすることができるようにする。この場合、これらの教示は、別の要求元ネットワーク要素の身元が２次ネットワーク要素からブラインドされ、それにより前者のプライバシーを保護することができるようにする。上述の権限を付与することは、要求元ネットワーク要素に代わって、その要求元ネットワーク要素がアテスターの役割内で動作しているときに関与した１つまたは複数の以前の証明に対する撤回を許可することを含み得、それにより、特に、データを処理するための上述の２次ネットワーク要素の権限付与の一部として考慮されることからそれらを除去する効果を有する。

１つの手法によれば、上述の権限付与は、リクエスターの役割内で動作している要求元ネットワーク要素が、中継者からアクセス可能なストレージから、暗号パラメータ、データ、およびメタデータのうち少なくとも１つを含む内容を、平文形態または暗号化された形態で取り出す権限を付与されることを少なくとも１つの中継者に通知する、検証可能な許可の生成を少なくとも部分的に含み得る。

プロトコルに準拠した要求の中にトークン化された形態で含まれているデータ情報への実質的なアクセスを防止することに関して、ここで、トークンは、少なくともそのうち１つがコーディネートネットワーク要素には入手不可能である秘密を使用して生成され、別の手法によれば、またここでも前述に代えて、またはそれと組み合わせて、秘密は、それぞれ別個のタイプの複数のプロセッサにおいて互いに離して保持することができ、各タイプの少なくとも１つのプロセッサが、トークンの生成に関与する。好ましくは、少なくとも１つのプロセッサタイプは、コーディネートネットワーク要素により制御されず、また実質的にアクセス可能でもない。トークンを生成するために集合的に使用されるそれらの秘密の各々は、別個のタイプの複数のプロセッサの各々によって独立して生成されるか、またはセットアップ時に、関連するプロセッサタイプをカバーする複数のプロセッサに分散され得、後者の機構は、負荷平衡および動作の回復を可能にするために、各タイプのプロセッサの複製を複数個確立することと整合する。

１つの使用事例は、初期データソースに関連付けられた情報のトークン化であり、ここで、トークンの生成を求める要求は、上述の初期データソースによってデータが供給される要求元ネットワーク要素によって開始される。そのようなトークンは、コーディネートネットワーク要素が、リクエスターの役割内で動作しているネットワーク要素に応答するときに、アテスターの役割内で動作しているネットワーク要素によって完了された以前の証明に関する情報を検索できるようするために使用することができ、そのようなトークンは、初期データソースに関連付けられたデータ情報として組み込まれる。一部の事例では、そのようなトークンは、初期データソースへの参照として働き得る。

別の使用事例は、確証のためにデータ内容を参照する目的でのデータ内容のトークン化である。そのような使用事例では、アテスターの役割内で動作している要求元ネットワーク要素に権限を付与することは、要求元ネットワーク要素によりまたはプロキシによりサブミットされたトークンを、データ内容を表すものとしてコーディネートネットワーク要素が受け付けることを少なくとも部分的に伴う。そのようなプロキシは、トークンの生成に関与するプロセッサであり得る。さらに、そのような使用事例において、リクエスターの役割内で動作している要求元ネットワーク要素に権限を付与することは、リクエスターの役割内で動作している要求元ネットワーク要素によってまたはプロキシによってサブミットされたトークンを、コーディネートネットワーク要素が保持している、アテスターの役割内で動作している要求元ネットワーク要素によってサブミットされたものとして以前に受け付けられたトークンの値を比較するデータ内容を表すものとして、コーディネートネットワーク要素が受け付けることを少なくとも部分的に伴う。そのようなプロキシは、トークンの生成に関与するプロセッサであり得る。

さらに、初期データソースによりデータを供給される要求元ネットワーク要素によってトークン生成の要求が開始される場合の、上述の初期データソースに関連付けられたデータ情報のトークン化に関して、アテスターの役割またはリクエスターの役割内で動作するための前提条件として、またはすでにその役割内で動作している間に、要求元ネットワーク要素は、第１のプロセッサタイプの第１のプロセッサまたは集合的に第１のプロセッサタイプの第１のプロセッサとして設計されたサブプロセッサの組み合わせによる、次いで、別個にアドレス指定可能な、第２のプロセッサタイプの第２のプロセッサまたは集合的に第２のプロセッサタイプの第２のプロセッサとして設計されたサブプロセッサの組み合わせによる、トークン生成動作を連続的に要求することができ、このとき、第１のプロセッサに対して行われる要求内のデータ情報は、要求元ネットワークによるブラインドファクタの導入により、第１のプロセッサからブラインドされる。さらに、第１の秘密への集合的なアクセスに基づいて第１のプロセッサによって取られる動作は、要求元ネットワーク要素が、第２の秘密への集合的なアクセスに基づいて第２のプロセッサによって動作が取られることを要求する前に、第１のプロセッサによる動作の結果から自身が以前に導入したブラインドファクタを除去した後でも、第２のプロセッサからデータ情報をブラインドする働きをすることができ、その結果、要求元ネットワーク要素による実質的なアクセスからブラインドされたトークン値を生じることができる。第１の秘密および第２の秘密は、以前に生成されたトークンの有用性を無効にすることなく、新しい第１の秘密および新しい第２の秘密に更新されることが可能であり、ここで、好ましくはランダムに生成された修飾子または乗数が、第１のプロセッサによって第１の秘密に適用され、適宜算出された修飾子または乗数の逆数が、第２のプロセッサにより第２の秘密に適用される。互いから独立して考えられる第１のプロセッサおよび第２のプロセッサに関して、第１のプロセッサが、２つ以上のサブプロセッサの組み合わせからなる場合、第１のプロセッサのこれらのサブプロセッサは各々、自身が保持している第１の秘密の１つまたは複数の構成要素を更新することができ、第１の秘密は、その第１の秘密を変更することなく第１のプロセッサによって集合的にアクセス可能である。同様に、互いから独立して考えられる第１のプロセッサおよび第２のプロセッサに関して、第２のプロセッサが、２つ以上のサブプロセッサの組み合わせからなる場合、第２のプロセッサのこれらのサブプロセッサは各々、自身が保持している第２の秘密の１つまたは複数の構成要素を更新することができ、第２の秘密は、その第２の秘密を変更することなく第２のプロセッサによって集合的にアクセス可能である。

さらに、確証のためにデータ内容を参照する目的でのデータ内容のトークン化に関して、および適切なブラインドを実現するために、トークン生成方法は、トークン値のセットおよびトークン値の生成に対するプロセッサの寄与へのアクセスを与えられたとき、トークンを生成するために集合的に使用されたプロセッサ秘密のすべてへのアクセスが与えられたとしても、プロセッサ各々のどの寄与がセット内のどのトークン値に対応するのかを区別することが算出的に実行不可能となるように、設計することができる。

そのように構成されると、これらの教示は、情報ソースの１つまたは複数の身元を保護しつつ、それでもそのソースに関して情報受信者を安心させることのできる手法を介して、情報の提供（および／または情報の確証）を可能にするための堅固な基盤を提供する。これらの教示は、したがって、一般に利用可能なデータ通信技術に対する改良を含むものと理解される。さらに、これらの教示およびそれに対応する利益は、幅広い種々の応用環境において適用できることが認識されよう。いくつかの関連性のある例には、これらに限定されないが、医療サービスの提供およびそれに対応する医療記録の使用、医薬品の処理および分配、場所および／または条件に固有の監視（例えば、周囲および／または環境条件ならびに病気に関する兆候の監視を含む）、プラットフォーム間および／または代理店／支店間の、反テロリズム活動を含むセキュリティに関するデータの交換、これらに限定されないが、クレジットおよびローンの処理、詐欺の検出などを含む、経済／金融関係の目的が含まれる。これらに関して、当業者はさらに、各種のいわゆるモノのインターネットデバイスおよびサービスのいずれかを含む応用環境における使用に、これらの教示が容易に対処できることを認識するであろう。

これらおよび他の利点は、以下の詳細な説明をあますところなく検討および考察するとより明らかになろう。次いで図面、特に図１を参照して、上記教示の多くと両立性のある例示的な装置１００を提示する。

この特定の例では、イネーブリング装置１００は、コーディネートネットワーク要素１０１を含む。このコーディネートネットワーク要素は、対応するネットワーク１０５を介して、データに基づく行為を実施するように構成されている。本明細書においてより詳細に説明されるように、このコーディネートネットワーク要素１０１は、受信されたプロトコルに準拠した要求の基礎を少なくとも部分的になすデータ内容にコーディネートネットワーク要素１０１が実質的にアクセスすることを阻止するプロトコルを管理する。

この説明のための例では、コーディネートネットワーク要素１０１は、制御回路１０２を含む。「回路」であるため、制御回路１０２は、したがって、秩序付けられた方式で電気を伝える少なくとも１つの（通例は多くの）導電性の経路（銅や銀などの導電性金属からなる経路など）を含む構造を備え、この経路は通例、回路が上記教示の制御態様を実施することを可能にする、対応する電気構成要素（適宜、受動的（抵抗およびコンデンサなど）ならびに能動的（各種の半導体ベースのデバイスのいずれかなど）の両方）も含む。

そのような制御回路１０２は、目的が固定されたハードワイヤードのハードウェアプラットフォーム（これに限定されないが、特定用途集積回路（ＡＳＩＣ）（これは、汎用的な使用を意図されるのではなく、特定の用途のために設計によってカスタマイズされた集積回路である）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）等）を含むか、または、部分的もしくは完全にプログラム可能なハードウェアプラットフォーム（これらに限定されないが、マイクロコントローラ、マイクロプロセッサ等を含む）を含み得る。これらの構造に関するこれらのアーキテクチャ上の選択肢は、当技術分野ではよく知られ、理解されており、ここではこれ以上の説明を必要としない。この制御回路１０２は、本明細書に記載されるステップ、動作、および／または機能の１つまたは複数を実行するように（例えば、当業者によく理解されるように対応するプログラミングを使用することにより）構成される。

１つのオプションの手法によると、制御回路１０２は、メモリ１０３に動作可能に結合する。このメモリ１０３は、必要に応じて、制御回路１０２と一体であっても、または制御回路１０２から（全体がまたは一部が）物理的に別個であってもよい。このメモリ１０３はまた、制御回路１０２に対してローカルであっても（例えば両方が共通の回路板、シャーシ、電源、および／または筐体を共有する場合）、または制御回路１０２に対して部分的もしくは全体的にリモートであってもよい（例えば、メモリ１０３が制御回路１０２と比べて別の設備、別の都市区域、さらには別の国に物理的に位置する場合）。

本明細書に説明されるように他の情報を記憶することに加えて、このメモリ１０３は、例えば、制御回路１０２によって実行されたときに制御回路１０２を本明細書に記載されるように振舞わせるコンピュータ命令を非一時的に記憶する役割を果たすこともできる。（本明細書で使用される場合、この「非一時的に」の言及は、記憶媒体自体の揮発性ではなく、記憶内容にとって非一時的状態を指し（したがって記憶内容が単に信号または波を構成する場合を除外する）、したがって、不揮発性メモリ（読出し専用メモリ（ＲＯＭ））、ならびに揮発性メモリ（ダイナミックランダムアクセスメモリ（ＤＲＡＭ）など）の両方を含むものと理解される。

この例では、制御回路１０２は、ネットワークインターフェース１０４にも動作可能に結合する。そのように構成されているため、制御回路１０２は、ネットワークインターフェース１０４を介して他の要素（装置１００内およびその外部両方の）と通信することができる。より詳しくは、ネットワークインターフェース１０４は、１つまたは複数のネットワーク１０５を介した互換性のある通信を容易にする。多数の例が当技術分野で知られている。非網羅的な列挙には、ユニバーサルシリアルバス（ＵＳＢ）に基づくインターフェース、ＲＳ２３２に基づくインターフェース、Ｉ．Ｅ．Ｅ．Ｅ．１３９４（Ｆｉｒｅｗｉｒｅとも呼ばれる）に基づくインターフェース、イーサネットに基づくインターフェース、各種のいわゆるＷｉ－Ｆｉ（商標）に基づくワイヤレスインターフェースのいずれか、Ｂｌｕｅｔｏｏｔｈ（商標）に基づくワイヤレスインターフェース、セルラー電話技術に基づくワイヤレスインターフェース、近距離通信（ＮＦＣ）に基づくワイヤレスインターフェース、標準的な電話陸線に基づくインターフェース、ケーブルモデムに基づくインターフェース、およびデジタル加入者回線（ＤＳＬ）に基づくインターフェースが含まれ得る。そのようなインターフェースを選択的に用いて、制御回路１０２を、別のネットワーク要素に、ローカルエリアネットワークに、または各種のワイドエリアネットワークもしくはエクストラネット（これに限定されないがインターネットなど）のいずれかに、通信的に結合することができる。

以下の説明に関して、そのように構成されているため、コーディネートネットワーク要素１０１は、上述のプロトコルを介して、複数のネットワーク要素１０６（図１には第１のネットワーク要素から第Ｎのネットワーク要素として示される）のいずれとも互換的に通信することができる。下記でより詳細に説明するように、そのようなネットワーク要素１０６は、いわゆるアテスターの役割内で、またはいわゆるリクエスターの役割内で動作している２次ネットワーク要素として、動作している可能性がある。

所与の応用環境においてデータに基づく行為を実施する際に役割を果たし得る他の装置には、アテスターとしてもリクエスターとしても動作しないデータソース１０７、および／または１つまたは複数のいわゆる中継者１０８のような要素が含まれる。

次いで図２を参照すると、上述のコーディネートネットワーク要素１０１は、説明のための例として、図示されるプロセス２００を実行するものと仮定される。１つの手法によると、上記で説明した制御回路１０２は、上記の動作、行為、および機能を実行する。またこれも上記で説明したように、コーディネートネットワーク要素１０１は、本明細書に記載されるプロトコルに準拠した要求の基礎を少なくとも部分的になすデータ内容に当該コーディネートネットワーク要素１０１が実質的にアクセスすることをとりわけ阻止するプロトコル２０１を管理しながら、このプロセス２００を実行する。

ブロック２０２で、コーディネートネットワーク要素１０１が、上述のネットワーク１０５を介して、データ情報に関する、プロトコルに準拠した要求を受信する。このプロトコルに準拠した要求は、単一の独立したメッセージに含まれている場合も、または望まれる場合には、複数の別個のメッセージを含んでもよい。このプロトコルに準拠した要求は、アテスターの役割内で、またはリクエスターの役割内で動作している２次ネットワーク要素として動作している、要求元ネットワーク要素１０６から受信される。プロトコルに準拠した要求に対応するデータ情報は、各種のデータ項目のいずれかを構成するかまたは含むことができる。例には、これらに限定されないが、参照されるデータ内容、参照されるデータタイプ、初期データ情報ソースの参照、および初期データソース１０７に関連付けられたデータ情報が含まれる。

ブロック２０３で、コーディネートネットワーク要素１０１が、要求元ネットワーク要素１０６が、アテスターの役割内で動作しているネットワーク要素であるかどうかを判定する。当てはまる場合、ブロック２０４で、コーディネートネットワーク要素１０１は、要求元ネットワーク要素を介して調達されるデータを、データに基づく処理のために非同期に入手可能にする権限を要求元ネットワーク要素１０６に付与することを、少なくとも部分的には上述のプロトコルを介して容易にする。この例では、データは、間接的なデータとして調達され、初期データソース１０７から要求元ネットワーク要素によって受信されたデータからの導出を伴う。

重要な点として、また上述のプロトコルによれば、これらに関してリクエスターの役割内で動作している対応する２次ネットワーク要素の身元は、要求元ネットワーク要素からブラインドされる。

ブロック２０６で、以前に別の要求元ネットワーク要素から調達されたデータを処理するための、リクエスターの役割内で動作している２次ネットワーク要素の権限付与は、当該リクエスターの役割内で動作している要求元ネットワーク要素が、中継者からアクセス可能なストレージから、暗号パラメータ、データ、およびメタデータのうち少なくとも１つを含む内容を、平文形態または暗号化された形態で取り出す権限を付与されることを少なくとも１つの中継者１０８に通知する、検証可能な許可の生成を少なくとも部分的に含み得る。

前述のブロック２０４における、アテスターの役割内で動作している要求元ネットワーク要素を介して調達されるデータを、データに基づく処理のために非同期に入手可能にする権限を要求元ネットワーク要素に付与することは、アテスターの役割内で動作している要求元ネットワーク要素が、中継者からアクセス可能なストレージに内容を記憶する権限を付与されることを中継者１０８に通知する、検証可能な許可を生成することを少なくとも部分的に含み得、当該内容は、データの移動および確証のうち少なくとも一方を可能にするために有用である暗号パラメータ、データ、およびメタデータ、の少なくとも１つを含む。（これらの教示は、上述の内容の少なくとも一部を平文形態および暗号化された形態の少なくとも一方で記憶することにより、中継者からアクセス可能なストレージに上述の内容を記憶することに対処する。）

１つの手法によると、上述の内容は、解読トークンの少なくとも１つ、ならびに暗号パラメータおよび／またはメタデータの少なくとも１つとして働くように構成された記憶された値を含む。上述の解読トークンは、１つの手法によると、アテスターの役割内で動作している要求元ネットワーク要素によって生成された暗号文および暗号パラメータのうち少なくとも１つを表すことができる。これらの教示によって、コーディネートネットワーク要素１０１は、プロトコルに準拠した要求の中にトークン化された形態で含まれるデータ情報から阻止され、したがって実質的にそれにアクセスすることができないことに留意されたい。ここで、解読トークンは、少なくともそのうち１つがコーディネートネットワーク要素１０１には入手不可能である秘密を使用して生成される。例えば、そのような入手不可能性は、コーディネートネットワーク要素１０１が１つまたは複数の中継者１０８のストレージに実質的にアクセスできないことに起因し得る。

上述の暗号パラメータおよびメタデータは次いで、比較トークンを構成するためにデータと共に適用することができ、比較トークンは、アテスターの役割内で動作している要求元ネットワーク要素によって与えられたデータの処理の結果を表す比較トークンに対して、記憶された値を使用して処理された候補データを表す比較トークンの一致があるかどうかに関する判定を行うことができるように構成される。これらの教示によって、コーディネートネットワーク要素１０１は、プロトコルに準拠した要求内にトークン化された形態で含まれるデータ情報から阻止され、したがって実質的にそれにアクセスすることができないことに留意されたい。ここで、比較トークンは、少なくともそのうち１つがコーディネートネットワーク要素１０１には入手不可能である秘密を使用して生成される。例えば、そのような入手不可能性は、コーディネートネットワーク要素１０１が１つまたは複数の中継者１０８のストレージに実質的にアクセスできないことに起因し得る。

１つの手法によると、上述の内容は、シェアの群であって、閾値数のそのようなシェアが当該内容の再構成を可能にするようなシェアの群を含み得る。１つの手法によると、これらのシェアは、アテスターの役割内で動作している要求元ネットワーク要素によって複数の中継者１０８に分散される。

上述のように、コーディネートネットワーク要素１０１は、要求元ネットワーク要素を介して調達されるデータを、データに基づく処理のために非同期に入手可能にする権限を、アテスターの役割内で動作する要求元ネットワーク要素に付与することができる。１つの手法によると、このデータに基づく処理は、証明済みのデータ内容の移動、および以前に証明済みのデータ内容に対するデータ内容の確証、のうち少なくとも１つを含み得る。以前に証明済みのデータ内容に対するデータ内容のこの確証は、次いで、リクエスターの役割内で動作している要求元ネットワーク要素からデータを調達することを少なくとも部分的に含み得、データが間接的なデータとして調達される場合、調達することは、初期データソース１０７から要求元ネットワーク要素によって受信されたデータからの導出を伴う。

ブロック２０３で行われた判定が偽の場合、ブロック２０５で、コーディネートネットワーク要素１０１は、要求元ネットワーク要素が、リクエスターの役割内で動作している２次ネットワーク要素であるかどうかを判定する。それが該当しない場合、このプロセス２００は、必要に応じて各種の応答のいずれにも対応することができる。それらに関する一例として、このプロセス２００は、このプロセス２００の最初に戻り、それにより、別のその後受信されるプロトコルに準拠する要求を処理することに対応する。

当てはまる場合、ブロック２０６で、このプロセス２００は、以前に別の要求元ネットワーク要素から調達されたデータを処理するための２次ネットワーク要素の権限付与を、少なくとも部分的には上述のプロトコルを介して容易にする。この権限付与は、リクエスターの役割内で動作している要求元ネットワーク要素が、中継者からアクセス可能なストレージから、暗号パラメータ、データ、およびメタデータのうち少なくとも１つを含む内容を、適宜平文形態または暗号化された形態で取り出す権限を付与されることを少なくとも１つの中継者１０８に通知する、検証可能な許可の生成を少なくとも部分的に含み得る。

重要な点として、ここでも、別の要求元ネットワーク要素の身元は２次ネットワーク要素からブラインドされる。

そのように構成されているため、各種データタイプに関する各種エンティティからの要求は、それらの行為に関与する各種エンティティの身元を必ずしも明かすことなく、共有および／または証明することができる。このブラインドは、そのような情報の共有を容易にするコーディネートネットワーク要素１０１を含む。

様々な例示的な用途環境および実装の詳細を次いで提示する。これらの説明で提供される具体的な詳細は、説明の目的を果たすことが意図され、それら教示の適用を制約する制限的な例とは解釈すべきでなないことが理解されるべきである。

次いで図３を参照すると、関係者Ｐ_１３１０が、エンティティＥ_ｉ３２０から調達されたデータを取得し、アテスターの役割内で動作しており、そのソースデータから導出されたデータの証明をシステムに提供するために第３者によって管理されるプロトコル３５０を利用する。そのような導出は、ソースデータの正規化を伴ってよい。そのような証明は、データタイプを伴ってよい。そのような証明は、エンティティＥ_ｉ３２０に関連付けられたまたは関係する情報の表現を伴ってよく、その情報は、社会保障番号や誕生日などの、エンティティＥ_ｉ３２０を識別する情報を含んでよい。そのような表現は、ブラインドされたエンティティに関連する情報の形態であってよく、情報は、よって、プロトコル３５０に対して、したがってプロトコル３５０を実行する１つまたは複数のサーバに対して不透明である。そのような表現は、可能性としてはデータタイプと共に、ソースデータを分類するための機構として使用されてよい。プロトコル３５０を実行する１つまたは複数のサーバは、複数の当事者または会社間にそれらの運用／所有権が分散されていてよい。プロトコル３５０によりアクセスからブラインドすることの効果は、よって、共謀や危殆化行為に対する実際的な制限に依存し得る。

不正行為属性レジストリなどの特定の使用事例では、証明は、ブラインドされたエンティティに関係する情報も、ブラインドされていないエンティティに関係する情報も備えない。この理由は、そのような証明は、その後そのデータを証明したシステムの関係者にデータを調達したすべてのエンティティにわたって、リクエスターがデータの確証または照合を試みることを可能にするために使用されるためである。そのようなエンティティは、不正を働いている、または詐称者であり得る。そのようなデータは、部分的もしくは全体が合成されたものであり得、または、正当なデータと、偽造されたもしくは悪用されたデータとの組み合わせを伴うことがあり、または、そのようなデータもしくはそのようなエンティティは、不正を働いているもしくはその他の形で不適正であることが、証明を行う関係者によって疑われ得る。

提出された証明を介して転送または確証することが可能な状態にされたデータは、ブラインドされた、よってプロトコル３５０にとって不透明なデータの形態で表され得る。リクエスターの役割内で動作する関係者Ｐ_２３３０は、証明されたデータの転送を受信するため、または関係者Ｐ_２３３０がエンティティＥ_ｊ３４０から取得したデータから導出されたデータの確証を試みるために、プロトコル３５０を利用する。そのような証明はデータタイプを伴うことがある。そのような証明は、エンティティＥ_ｊ３４０に関連付けられた、または関係する情報の表現を伴ってよく、そのような表現はブラインドされてよい。好ましくは、要求元の関係者Ｐ_２３３０と証明を行う関係者Ｐ_１３１０は、互いの真の身元も、さらには各自の偽名の身元すら知ることがない。好ましくは、関係者Ｐ_１３１０は、エンティティＥ_ｊ３４０がエンティティＥ_ｉ３２０と同じである場合でも、少なくともシステムによって実施される可能性のあるいくらかの遅延の前には、エンティティＥ_ｉ３４０を知ることがない。そのような遅延は、例えば、時間または周期またはトランザクション量で測定されてよい。

次いで図４を参照し、また必要に応じて図５も参照すると、上半分に、関係者により、または１つまたは複数の関係者の代わりに操作されるコンピュータ、ソフトウェア、および／またはハードウェアとしてのクライアント４１０（Ｃ）（例えば、第３者によって管理されるプロトコルを実行する１つまたは複数のサーバへのクライアントゲートウェイとしての）を伴う、証明動作シーケンスが示される。下半分には、関係者により、または１つまたは複数の関係者の代わりに操作されるコンピュータ、ソフトウェア、および／またはハードウェアとしてのクライアント４５５（Ｃ’）（例えば、第３者によって管理されるプロトコルを実行する１つまたは複数のサーバへのクライアントゲートウェイとしての）を伴う要求動作シーケンスが示される。中継者のセット４１５は、証明および証明に対する要求にわたって共通である。中継者ストレージへのデータもしくは情報の預け入れ、または中継者ストレージからの取出しは、複数の中継者４１５を介した、それぞれクライアント４１０またはクライアント４５５が関与する通信を伴い得る。

証明：データソース４０５が、ＤＡＴＡのセット４２０をクライアント４１０に提供する。クライアント４１０は、４２５で、ｒａｎｄｏｍと表される値をランダムまたは疑似ランダムに生成し、４３０で、可能性としてはメタデータなどの他のパラメータと共に、それを分割し、その結果得られた分割を中継者４１５に送信する。関与する各中継者が自身に送られた分割を受け付けるための前提条件として、そのような中継者は、図５の５３５でクライアント４１０に対して入手可能にされる適当な権限付与を必要とすることがある。４３０で、クライアント４１０は、ＤＡＴＡおよびｒａｎｄｏｍの関数ｆを算出し、ここで、ｒａｎｄｏｍは、４２５で生成された、好ましくはランダムまたは疑似ランダムに生成された値を表す。一例として、ＤＡＴＡはｒａｎｄｏｍと連結され、次いでその結果に一方向性ハッシュ関数が適用されてよい。別の例として、ｒａｎｄｏｍが、ＨＭＡＣ関数を引数としてＤＡＴＡに適用するＨＭＡＣ鍵として使用されてよい。他の鍵付きハッシュ関数がＨＭＡＣの代わりに使用されてもよい。関数ｆは、ＤＡＴＡに適用される正規化関数を組み込んでよい。そのような正規化は、証明に対する要求を介してデータを確証または照合することを試みる際に、偽陰性を回避するために有用であり得る。関数ｆは、ＤＡＴＡおよびｒａｎｄｏｍに加えて、メタデータなどの引数を組み込んでもよい。４３０における算出の結果は、４４０として送信されて、図５のコーディネータ５１０への図５の送信５１５の少なくとも一部をなす。

要求：データソース４５０は、ＤＡＴＡ’のセット４６０をクライアント４５５に提供する。４６５で、クライアント４５５は、中継者４１５にｒａｎｄｏｍの分割を要求する。証明を行う関係者によって以前に提出された関連する証明にわたって、データタイプおよびＴＯＫＥＮの同じ値に対応するｒａｎｄｏｍの値が複数あり得、そのデータタイプ値およびＴＯＫＥＮ値に対応する証明当たりｒａｎｄｏｍの値が１つある。各証明に組み込まれるＤＡＴＡ要素は、互いと一致する場合もしない場合もある。関与する各中継者が以前に証明を介して記憶された分割を供給するための前提条件として、そのような中継者は、図５の５６０でクライアント４５５に対して入手可能にされる適当な権限付与を必要とすることがある。権限付与が成功すると、関与する各中継者は、クライアント４５５に応答４７０を送信する。クライアント４５５は、４７２で、可能性としてはメタデータなどの他のパラメータと共に、ｒａｎｄｏｍを再構成する。４８０で、クライアント４５５は、証明の時に適用されたと考えられるものと同じ、ＤＡＴＡ’値およびｒａｎｄｏｍの値の関数ｆを算出する。ｆは、詳細には、ＤＡＴＡ’値の正規化を伴ってよい。メタデータなど、ｆの追加的な引数があってよい。４８０の結果は、何らかの形態４８５で送信され、これは、図５の５６５を介して何らかの関数ｈをコーディネータ５１０に適用することを伴い得る。例えばシャミア秘密共有方式などの閾値方式が、４３０におけるｒａｎｄｏｍの分割に使用されてよい。一例として、３ ｏｕｔ ｏｆ ４方式を使用することが可能であり、その場合、４つのシャード（shard）のうちの任意の３つが、４７２におけるｒａｎｄｏｍの再構成を可能にする。

次いで図５を参照する。

証明：クライアント５０５は、５１５で、データタイプ、ｇ（ＴＯＫＥＮ）およびｆ（Ｄａｔａ，ｒａｎｄｏｍ）をコーディネータ５１０に送信し、ここでｆ（Ｄａｔａ，ｒａｎｄｏｍ）は、図４の４４０で送信されたものである。ｇ（ＴＯＫＥＮ）は、関係者クライアント５０５に以前供給されたＴＯＫＥＮの形態に対応し得る。一例として、トランスレータが、コーディネータ５１０と共通に保持されている鍵を使用し、かつ１回使用の初期化ベクトルを使用して、ＴＯＫＥＮを一意に暗号化していることがあり、その結果、暗号文および可能性としては認証タグが生じ、それが初期化ベクトルと共にクライアント５０５またはクライアント５０５の代理に送付されている。５１５は、ｒａｎｄｏｍの関数を追加的に含んでよく、それが最終的にブロックチェーンに提出され、要求の役割にある関係者クライアント５４０によって取り出され、図４の４７２の再構成されたｒａｎｄｏｍと照合して検証され得る。そのような関数は、メタデータなどの追加的な引数を含んでよい。そのような関数は、一方向性ハッシュ関数を伴ってよい。コーディネータ５１０は、５２０で、自身のデータベースの管理で使用するためのアドレスを作成する。５２５で、コーディネータ５１０は、データタイプ、ＴＯＫＥＮ、ｆ（ＤＡＴＡ，ｒａｎｄｏｍ）およびアドレス、またはそれらの何らかの形態もしくは関数を記憶する。５２５の処理は、以前にＴＯＫＥＮに適用された関数ｇの効果を逆にする、または除去することを含んでよい。５３０で、コーディネータ５１０は、５３５でクライアント５０５に送信される１つまたは複数の権限付与を生成する。そのような権限付与は、図４の４４５で、図４で４１０として表される証明を行うクライアントから１つまたは複数の中継者４１５に送信される。

要求：クライアント５４０は、５４５で、データタイプおよびｇ（ＴＯＫＥＮ）をコーディネータ５１０に送信する。ｇ（ＴＯＫＥＮ）は、関係者クライアント５４０に以前供給されたＴＯＫＥＮの形態に対応し得る。一例として、トランスレータが、コーディネータ５１０と共通に保持されている鍵を使用し、かつ１回使用の初期化ベクトルを使用して、ＴＯＫＥＮを一意に暗号化していることがあり、その結果、暗号文および可能性としては認証タグが生じ、それが初期化ベクトルと共にクライアント５４０またはクライアント５４０の代理に送付されている。５５０で、コーディネータ５１０は、データタイプおよびＴＯＫＥＮに基づいて１つまたは複数のアドレスを引き出す。５５０の処理は、以前にＴＯＫＥＮに適用された関数ｇの効果を逆にする、または除去することを含んでよい。５５５で、コーディネータ５１０は権限付与を作成する。図４の４４５で証明を行うクライアントによってどのようにｒａｎｄｏｍの分割が中継者４１５に分散されたかによって、要求元クライアント５４０によって検査される証明ごとに複数の権限付与があることもあり得、その場合、そのような各権限付与は、図４の要求４６５において中継者４１５の少なくとも１つと共に使用されることが意図される。これらの権限付与は、５６０でクライアント５４０に送信される。図４のシーケンス４６５、４７０、４７２、および４８０の結果、ｆ（ＤＡＴＡ’，ｒａｎｄｏｍ）が構築され、これをさらに処理して、図４の参照符号４８５に描かれるようにｈ（ｆ（ＤＡＴＡ’，ｒａｎｄｏｍ））を生成し、それが５６５でコーディネータ５１０に送信されてよい。関数ｈの詳細は、結果として５７５のＲＥＳＰＯＮＳＥを生じさせるコーディネータ５１０による処理、およびＤＡＴＡに対するＤＡＴＡ’の確証状態を判定する５８０におけるクライアント５４０による処理からなる、下位プロトコルの詳細に依存し得る。５１５が、最終的にブロックチェーンに提出されるｒａｎｄｏｍの関数、および可能性としてはメタデータなどの追加的な引数を含む場合、それをクライアント５４０により取り出して、図４の４７２の再構成されたｒａｎｄｏｍと照合して検証することができる。

次いで図６を参照する。

証明：データソース６０５は、ＤＡＴＡのセット６２０をクライアント６１０に提供し、そのようなセットの１つまたは複数の要素は、図７の７１５でコーディネータに送信され、その結果、７３５の権限付与および権限付与識別子ＡＩがクライアント６１０に入手できる状態になり、そのため、６２５で証明識別子ＡＩを使用して初期化ベクトルＩＶを生成することができ、６３５の分割された鍵および認証タグならびに分散された暗号文を、６４０で中継者６１５に提供することができる。６３０の処理の結果、機密性のための暗号文、ならびに可能性としてはデータ完全性のための認証タグが得られる。Ｅ_ＫＥＹ（ＤＡＴＡ）によって表される鍵を使用したＤＡＴＡの暗号化は、メタデータならびにＤＡＴＡの暗号化を含んでよい。

要求：６５５で、クライアント６５０は、分割された鍵および認証タグならびに分散された暗号文チャンクからなる暗号材料構成要素を中継者６１５に要求する。証明を行う関係者によって以前に提出された関連する証明にわたって、データタイプおよびＴＯＫＥＮの同じ値に対応するこれらの値が複数あり得、そのデータタイプ値およびＴＯＫＥＮ値に対応する証明当たり、値が１つある。暗号化されて各証明に取り込まれた平文のＤＡＴＡ要素は、互いと一致する場合もしない場合もある。関与する各中継者が以前に証明を介して記憶された暗号材料を供給するための前提条件として、そのような中継者は、図７の７６０でクライアント６５０に入手可能にされる適当な権限付与を必要とすることがある。権限付与が成功すると、関与する各中継者は、クライアント６５０に応答６６０を送信する。クライアント６５０は、６６５で、暗号材料を再構成し、これは後に６７５でＤＡＴＡを回復および検証するために使用される。例えばシャミア秘密共有方式などの閾値方式が、６３５における鍵および認証タグの分割に使用されてよい。一例として、３ ｏｕｔ ｏｆ ４方式を使用することが可能であり、その場合、４つのシャードのうちの任意の３つが、６６５における鍵および認証タグの再構成を可能にする。

次いで図７を参照する。

証明：クライアント７０５は、７１５で、データタイプ、ｇ（ＴＯＫＥＮ）およびｌｅｎｇｔｈ（ＤＡＴＡ）をコーディネータ７１０に送信し、ここでＤＡＴＡ要素のセットは、図６の６２０を介してクライアントによって受信されたものである。ｇ（ＴＯＫＥＮ）は、関係者クライアント７０５に以前供給されたＴＯＫＥＮの形態に対応し得る。一例として、トランスレータが、コーディネータ７１０と共通に保持されている鍵を使用し、かつ１回使用の初期化ベクトルを使用して、ＴＯＫＥＮを一意に暗号化していることがあり、その結果、暗号文および可能性としては認証タグが生じ、それが初期化ベクトルと共にクライアント７０５またはクライアント７０５の代理に送付されている。コーディネータ７１０は、７２０で、自身のデータベースの管理で使用するためのアドレスを作成する。７２５で、コーディネータ７１０は、データタイプ、ＴＯＫＥＮ、およびアドレス、またはそれらの何らかの形態もしくは関数を記憶する。７２５の処理は、以前にＴＯＫＥＮに適用された関数ｇの効果を逆にする、または除去することを含んでよい。７３０で、コーディネータ７１０は、７３５でクライアント７０５に送信される１つまたは複数の権限付与を生成する。そのような権限付与は、図６の６４０で、図６で６１０として表される証明を行うクライアントから中継者６１５の１つまたは複数に送信される。

要求：クライアント７４０は、７４５で、データタイプおよびｇ（ＴＯＫＥＮ）をコーディネータ７１０に送信する。ｇ（ＴＯＫＥＮ）は、関係者クライアント７４０に以前供給されたＴＯＫＥＮの形態に対応し得る。一例として、トランスレータが、コーディネータ７１０と共通に保持されている鍵を使用し、かつ１回使用の初期化ベクトルを使用して、ＴＯＫＥＮを一意に暗号化していることがあり、その結果、暗号文および可能性としては認証タグが生じ、それが初期化ベクトルと共にクライアント７４０またはクライアント７４０の代理に送付されている。７５０で、コーディネータ７１０は、データタイプおよびＴＯＫＥＮに基づいて１つまたは複数のアドレスを引き出す。７５０の処理は、以前にＴＯＫＥＮに適用された関数ｇの効果を逆にする、または除去することを含んでよい。７５５で、コーディネータ７１０は権限付与を作成する。図６の６４０で証明を行うクライアントによってどのように暗号材料構成要素が中継者６１５に分散されたかによって、要求元クライアント７４０によって受け取られる証明ごとに複数の権限付与があることもあり得、その場合、そのような各権限付与は、図６の要求６５５において中継者６１５の少なくとも１つと共に使用することが意図される。これらの権限付与は、７６０でクライアント７４０に送信される。証明識別子（ＡＩ）は、ブロックチェーンに提出されてよい。要求元クライアント７４０は、その場合、図６の動作６７５を行うために必要とされるＩＶを生成するために、そのブロックチェーンからＡＩを取り出すことができる。代替または追加として、ＡＩは７６０で送信されてもよい。７１５および７６０におけるｌｅｎｇｔｈ（ＤＡＴＡ）は、オプションのフィールドである可能性がある。暗号文が、例えば図６の６４０で中継者に分散された暗号文のチャンクの長さを均等にするために、証明を行うクライアント６１０によってＥ_Ｋｅｙ（ＤＡＴＡ）の結果に付加されたパディングを含む場合、そのようなパディングは、図６の６７５における解読の前に図６の６６５で要求元クライアント６５０によって除去されなければならない。図７の７６０で受信したｌｅｎｇｔｈ（ＤＡＴＡ）を使用して、要求元クライアントは、図６の６６０で受信されたものから再構成された暗号文のうちどの部分を図６の６７５における解読への入力として使用するかを判定することができる。図６の６３０で、メタデータなどの、ＤＡＴＡ以外の追加的なフィールドに暗号化が適用された場合、例えばｌｅｎｇｔｈ（ＤＡＴＡ）の代わりにｌｅｎｇｔｈ（ＤＡＴＡ｜｜ｍｅｔａｄａｔａ）を利用することによって、それが考慮に入れなければならず、ここで｜｜は連結を意味する。

次に、第１の関係者が、ある特定のエンティティに関連付けられているとされるそのエンティティの電話番号などのデータ値を、確証のために、すなわち、第２の関係者が当該データ値を前記特定のエンティティに関連付けられているとみなすかどうかを判定するために検査する使用事例に対する、全面的な解決法の求められる性質を考察する。ここで、検査はサーバとの双方向通信を伴う。

１．フィッシングへの耐性：第１の関係者は、第２の関係者のデータ値に対するサブミットされたデータ値の一致があるかどうかだけを知る。

２．サーバの無認識性：サーバは、第１の関係者がオプションの後続通信を送らない限り、かつその時まで、第１の関係者の問合せの基礎となるサブミットされたデータ値が第２の関係者のデータ値と一致するかの判定を実行することができない。

３．偽陽性の防止：暗号化前のデータ値をカプセル化する第１の関係者による可能な正当なサブミットの空間が、推量される可能性が低くなるのに十分に大きい限りにおいて、サーバが正当に働いているか否かに関係なく、第１の関係者が一致の偽陽性の指示を受け取る見込みが低い。

４．サブミットされたデータ値のプライバシー：第１の関係者とサーバとの間の通信の傍受者が、第１の関係者のデータ値の判定を実行することができない。

５．第２の関係者のデータ値のプライバシー：第１の関係者とサーバとの間の通信の傍受者が、第２の関係者のデータ値の判定を実行することができない。

オプションの後続通信：

好ましくは、サーバがプライベート鍵を所有し、かつ第１の関係者が対応する公開鍵の知識を有する、対称暗号化関数または公開鍵暗号化関数のいずれかを使用して、第１の関係者が、サーバが第１の関係者によって以前送られた問合せを複製するのを可能にするために必要な変数を、サーバに通信する。これは、以前に第１の関係者によって送られたデータ値が第２の関係者のデータ値と一致するかどうかをサーバが判定できるようにする１つの手段である。好ましくは、第１の関係者は、同じ問合せを生じさせるであろう第２のデータ値の判定を実行することはできない。

性質１だけを満たせば十分と考えられるシナリオでは、それは、問合せの中にカプセル化されているデータ値が第２の関係者に関連付けられたデータ値のカプセル化と一致するか否かにそれぞれ応じて、サーバＳに単に第１の関係者Ｐの問合せに対して肯定または否定の応答をさせることによって実現可能であることに留意されたい。

プロトコルは、第１の関係者Ｐが、自身が保持しているデータ値が、特定の第２の関係者によって保持されているものと一致するかどうかを検証することを可能にし、これは、Ｐが保持しているデータ値のカプセル化を、サーバＳに記憶されている、またはサーバＳによりアクセス可能なデータ値のカプセル化と比較することによって推定される。機密性のある情報の場合、そのようなカプセル化の暗号化されていない平文表現の露出を最小にすることが望ましい。したがって、プロトコルは、意図される受信側関係者Ｐへのそのような平文を回復する能力を制約する。さらに、プロトコルは、悪意ある関係者Ｐが、関係者Ｐによりその問合せの中でサブミットされたものとは別個のデータ値を反映する、悪意のないサーバＳのカプセル化されたデータ値にアクセスすることを阻止する。これは、そのようなカプセル化に対して確率的または非決定性の準同型演算を行うことによって実現される。さらに、Ｐが、Ｐの情報の肯定的な確証がそのような動作のリスクを低減する、またはそのような動作を引き受けることが及ぼし得る不利な影響の軽減を助けると考えられることに基づいて、リスクのあり得る動作を引き受けてもよいと考える場合がある。したがって、サーバＳが、特定の第２の関係者に関連付けられたカプセル化の中にあるものと実際には一致しないデータ値に基づいて、問合せに対して一致を模倣するように自身の挙動を操作することに成功するのをプロトコルが防止することは、有利であると考えられる。プロトコルは、よって、偽陽性に相当する応答の犯罪行為に対して耐性を有する。

加法ならびにスカラー乗法の準同型をサポートする暗号化／解読方式（Ｅ_ｐｋ，Ｄ_ｓｋ）の例の参考として：Ｐａｉｌｌｉｅｒ，Ｐａｓｃａｌ（１９９９），“Ｐｕｂｌｉｃ－Ｋｅｙ Ｃｒｙｐｔｏｓｙｓｔｅｍｓ Ｂａｓｅｄ ｏｎ Ｃｏｍｐｏｓｉｔｅ Ｄｅｇｒｅｅ Ｒｅｓｉｄｕｏｓｉｔｙ Ｃｌａｓｓｅｓ，” ＥＵＲＯＣＲＹＰＴ，Ｓｐｒｉｎｇｅｒ，ｐｐ．２２３－２３８，ｄｏｉ：１０．１００７／３－５４０－４８９１０－Ｘ＿１６；ｈｔｔｐｓ：／／ｃｒｙｐｔｏ．ｓｔａｃｋｅｘｃｈａｎｇｅ．ｃｏｍ／ｑｕｅｓｔｉｏｎｓ／３６９９８／ｅｑｕａｌｉｔｙ－ｃｈｅｃｋｉｎｇ－ｕｓｉｎｇ－ａｄｄｉｔｉｖｅ－ｈｏｍｏｍｏｒｐｈｉｃ－ｅｎｃｒｙｐｔｉｏｎ（このすべてはこの参照により本明細書に完全に取り込まれる）。

次いで「偽陽性を起こしやすいプロトコル」についての図８を参照すると、関係者Ｐ８０５が、８１０で、以下に定義されるような加法ならびにスカラー乗法準同型をサポートする何らかの暗号化／解読方式（Ｅ_ｐｋ，Ｄ_ｓｋ）のための公開鍵／秘密鍵のペア（ｐｋ，ｓｋ）を生成する（例えばＰａｓｃａｌ Ｐａｉｌｌｉｅｒの方式を利用することによって可能にされる）。加法準同型－ Ｄ_ｓｋ［Ｅ_ｐｋ（ｘ）＋^’Ｅ_ｐｋ（ｙ）］＝ｘ＋ｙとなるような演算＋^’が存在し、ここで、＋は平文の群の中で定義される加算であり、そして、スカラー乗法準同型－ Ｄ_ｓｋ［ｘ＊^’Ｅ_ｐｋ（ｙ）］＝ｘ＊ｙとなるような演算＊^’が存在し、ここで＊は平文の群の中で定義される乗算である。関数はここでは、＋^’および＊^’のみを使用して評価できる場合、ｈｏｍ－ｃｏｍｐｕｔａｂｌｅと表されることに留意されたい。関係者Ｐ８０５は、８１５で、サーバＳ８２０によって保持されているデータ値のカプセル化ｃに対するＰの問合せであるｃ’を暗号化し、ここで、ｃ’およびｃは、それぞれＰのデータ値およびＳのデータ値のカプセル化を表す。Ｐ８０５は、８２５で、ｐｋおよびＥ_ｐｋ（ｃ’）をサーバＳ８２０に送付し、秘密鍵ｓｋはプライベートに保たれる。Ｓ８２０は、８３０で、ｒを生成し、これは好ましくは、適度に大きい集合から均一にランダムに選択された整数である。通例、Ｓ８２０は、８３５で、自身のデータ値のカプセル化ｃを暗号化し、ｒ＊^’ｇ^’（Ｅ_ｐｋ（ｃ），Ｅ_ｐｋ（ｃ’））を算出し、ここで、ｇ^’は、Ｓ８２０とＰ８０５の両方に知られているｈｏｍ－ｃｏｍｐｕｔａｂｌｅ関数であり、＊^’は、Ｄ_ｓｋの下にある平文に対するスカラー乗算の原像である。ｇ^’の例として、ｇ^’（ｘ，ｙ）＝ｘ－^’ｙでは、－^’は、準同型加算の逆に類似し、ｇ^’（ｘ，ｙ）＝ｘ＋^’ｙでは、＋^’は上記のように定義される。しかし、図８は、Ｓが悪意を持って行動し、したがって自分自身のｃに代えて受信したＥ_ｐｋ（ｃ^’）を使用する事例を表している。Ｓ８２０は、８４０で、Ｐ８０５にｒ＊^’ｇ^’（Ｅ_ｐｋ（ｃ^’），Ｅ_ｐｋ（ｃ^’））を送る。関数ｇ、または平文の空間内でＤ_ｓｋ下にあるｇ^’の像が、交代性質を有さない場合（ただし、交代性質はすべてのｘについてｇ（ｘ，ｘ）＝０と定義される）には、進む。そうでない場合は、続く関数ｈの適用をスキップする。Ｓ８２０は、８４０でｈ（ｒ）を送信するか、または代替としてｈ（ｒ｜｜ｃ’）をＰ８０５に送り、ここで、ｈは、ＳとＰの両者によって効率的に算出可能な一方向関数であり、好ましくは、任意のサイズまたはビット長のデータを固定のサイズまたはビット長のデータにマッピングするものである（例えば暗号ハッシュ関数）。ｈの例として、ｈ（ｘ）＝Ｈ_{ＳＨＡ－２５６}（ｘ）およびｈ（ｘ）＝ＨＭＡＣ_{ＳＨＡ－２５６}（ｋｅｙ，ｘ）であり、ここで、ｋｅｙはＰ８０５とＳ８２０との間で共有される秘密であり、ＳＨＡ－２５６は、ＮＩＳＴ ＦＩＰＳ－ＰＵＢ １８０－４（セキュアハッシュ標準）に指定される通りである。Ｐ８０５は、８４５で、Ｄ_ｓｋ［ｒ＊^’ｇ^’（Ｅ_ｐｋ（ｃ’），Ｅ_ｐｋ（ｃ’））］＝ｒ＊ｇ（ｃ’，ｃ’）を算出し、ここで、ｇは平文の空間内でＤ_ｓｋ下にあるｇ^’の像と定義される。ｇが、すべてのｘについてｇ（ｘ，ｘ）＝０と定義される交代性質を有する場合は、８５０に進む。そうでない場合は、８５５に続く。Ｐ８０５は、８５０で、８４５からの結果が０に等しいことを検証する。Ｓは悪意を持って行動しているため、ｃ≠ｃ’であるが、Ｐ８１０はｃ＝ｃ’とみなす。通例、Ｐ８０５は次いで、８５５で（ｇ［ｃ，ｃ’］）^-１を算出し、続いてｒ’＝ｒ＊ｇ（ｃ，ｃ’）＊（ｇ［ｃ，ｃ’］）^－１を算出する。明らかなように、ｃ’＝ｃであれば、ｒ’＝ｒである。そうでない場合、Ｐ８０５は、ｒに等しくないランダム値を算出する。しかし、Ｓ８２０は悪意を持って行動しているため、それらは偽陽性を得、ｒ’＝ｒとみなすことになる。Ｐ８０５は、８６０で、８４０で送付されたｈ（ｒ）（または代替として実装の選択によっては、ｈ（ｒ｜｜ｃ））が、８５５で算出された値に適用されたｈ（可能性としてはｃ’と連結されている）と一致することを検証する。一致する場合は、Ｓ８２０が予想されるように振舞っていれば、ｃ＝ｃ’となる。そうでない場合は、Ｓが予想されるように振舞っていれば、ｃ≠ｃ’となる。しかし、Ｓは悪意を持って行動したため、Ｐは再び偽陽性を受け取り、一致があったとみなすことになる。ｇが、８４０で定義される交代性質を有さない場合は、ここで終了する。

次いで「基本プロトコル」についての図９を参照すると、関係者Ｐ９０５が、９１０で、加法ならびにスカラー乗法準同型をサポートする何らかの暗号化／解読方式（Ｅ_ｐｋ，Ｄ_ｓｋ）のための公開鍵／秘密鍵のペア（ｐｋ，ｓｋ）を生成する（例えばＰａｓｃａｌ Ｐａｉｌｌｉｅｒの方式を利用することによって可能にされる）。加法準同型：Ｄ_ｓｋ［Ｅ_ｐｋ（ｘ）＋^’Ｅ_ｐｋ（ｙ）］＝ｘ＋ｙとなるような演算＋^’が存在し、ここで、＋は、平文の群の中で定義される加算である。スカラー乗法準同型：Ｄ_ｓｋ［ｘ＊^’Ｅ_ｐｋ（ｙ）］＝ｘ＊ｙとなるような演算＊^’が存在し、ここで、＊は平文の群の中で定義される乗算である。関数はここでは、＋^’および＊^’のみを使用して効率的に算出できる場合、ｈｏｍ－ｃｏｍｐｕｔａｂｌｅと表されることに留意されたい。Ｐ９０５は、９１５で、ｆ_ｋ（ｃ’）を算出し、その結果を暗号化し、ここで、ｃ’は、Ｓ９２０のデータ値のカプセル化ｃに対するＰの問合せのデータ値のカプセル化であり、ｆ_ｋは、何らかの鍵付き関数であり、秘密ｋが、Ｐ９０５によって所有され、好ましくは適度に大きい集合から均一にランダムに選択され、それは一方向であり、Ｓ９２０およびＰ９０５の両方によって効率的に算出可能であり、暗号ハッシュ関数よりも好ましい。ｆ_ｋの例として、ｆ_ｋ：ｆ_ｋ（ｘ）＝Ｈ_{ＳＨＡ－２５６}（ｘ｜｜ｋ）およびｆ_ｋ：ｆ_ｋ（ｘ）＝ＨＭＡＣ_{ＳＨＡ－２５６}（ｋ，ｘ）である。Ｐ９０５は、９２５でｐｋをサーバＳ９２０に送付し、秘密鍵ｓｋはプライベートに保たれる。Ｐ９０５は、９２５で、Ｅ_ｐｋ［ｆ_ｋ（ｃ’）］をＳ９２０に送る。Ｓ９２０は、９３０で、ｒを生成し、これは好ましくは、適度に大きい集合から均一にランダムに選択された整数である。Ｓ９２０は、９３５で、第２の関係者に関連付けられたデータ値のカプセル化ｃを暗号化し、ｒ＊^’ｇ^’（Ｅ_ｐｋ（ｃ），Ｅ_ｐｋ［ｆ_ｋ（ｃ’）］）を算出し、ここで、ｇ^’は、Ｓ９２０とＰ９０５の両方に知られているｈｏｍ－ｃｏｍｐｕｔａｂｌｅ関数であり、＊^’は、Ｄ_ｓｋの下にある平文に対するスカラー乗算の原像である。ｇ^’の例として、ｇ^’：ｇ^’（ｘ，ｙ）＝ｘ－^’ｙであり、ここで－^’は準同型加算の逆に類似し、ｇ^’：ｇ^’（ｘ，ｙ）＝ｘ＋^’ｙであり、ここで＋^’は前と同様に定義される。Ｓ９２０は、９４０で、ｒ＊^’ｇ^’（Ｅ_ｐｋ（ｃ），Ｅ_ｐｋ［ｆ_ｋ（ｃ’）］）をＰ９０５に送る。Ｓ９２０は、９４０で、ｈ（ｒ）または代替としてｈ（ｒ｜｜ｃ）もＰ９０５に送り、ここで、ｈは、Ｓ９２０とＰ９０５の両方によって効率的に算出可能な一方向関数であり、好ましくは暗号ハッシュ関数である。ｈの例として、ｈ：ｈ（ｘ）＝Ｈ_{ＳＨＡ－２５６（ｘ）}およびｈ：ｈ（ｘ）＝ＨＭＡＣ_{ＳＨＡ－２５６}（ｋｅｙ，ｘ）であり、ここでｋｅｙは、Ｐ９０５とＳ９２０との間で共有される秘密である。Ｐ９０５は、９４５で、Ｄ_ｓｋ［ｒ＊^’ｇ^’（Ｅ_ｐｋ（ｃ），Ｅ_ｐｋ［ｆ_ｋ（ｃ’）］）］＝ｒ＊ｇ（ｃ，ｆ_ｋ（ｃ’））を算出し、ここでｇは平文の空間内でＤ_ｓｋ下にあるｇ^’の像である。Ｐ９０５は次いで、９５０で、（ｇ［ｃ’，ｆ_ｋ（ｃ’）］）^－１を算出し、続いてｒ’＝ｒ＊ｇ（ｃ，ｆ_ｋ（ｃ’））＊（ｇ［ｃ’，ｆ_ｋ（ｃ’）］）^－１を算出する。明らかなように、ｃ’＝ｃであれば、ｒ’＝ｒである。そうでない場合、Ｐ９０５は、ｒに等しくないランダム値を算出する。Ｐ９０５は、９５５で、９４０で送付されたｈ（ｒ）（または代替として、実装の選択によっては、ｈ（ｒ｜｜ｃ））が、ｈ（ｒ’）（可能性としてはｃ’と連結されている）と一致することを検証する。一致する場合は、確実にｃ＝ｃ’となる。そうでない場合は、Ｓ９２０が予想されるように振舞ったと仮定してｃ≠ｃ’となる。

次いで「事後プロトコル－オプション１」についての図１０を参照すると、１つの手法によれば、これは、準拠している関係者のｃ’が、サーバＳからの応答の基礎になるｃと一致するときにのみ実行されるべきである。関係者Ｐ１００５は、１０１５で、図９の９５０からのｒ’をサーバＳ１０１０に送る。Ｓ１０１０は、１０２０で、ｒ’を、図９の９３０で生成された自身のｒと比較する。それらの値が一致する場合、図９におけるＰ１００５の問合せは、結果として、Ｓ１０１０において第２の関係者に関連付けられたデータ値のカプセル化ｃに対するヒットを生じさせている。そうでない場合は、Ｐ１００５の問合せとデータ値のカプセル化ｃとの間の関係について何も判定することができず、Ｐ１００５は悪意のある挙動を示している。

次いで、どのようなシナリオでも実行されることが可能な「事後プロトコル－オプション２」についての図１１を参照する。サーバＳ１１０５は、１１１０で、可能性としてはｐｋ＊＝ｓｋ＊となるように、暗号化方式（Ｅ_ｐｋ＊，Ｄ_ｓｋ＊）を生成する。Ｓ１１０５は、１１２０で、ｐｋ＊を関係者Ｐ１１１５に送付する。Ｐ１１１５は、１１２５で、Ｅ_ｐｋ＊（ｃ’），Ｅ_ｐｋ＊（ｋ），Ｅ_ｐｋ＊（ｒ_１），．．．，Ｅ_ｐｋ＊（ｒ_ｎ）を算出し、ここでｃ’は図９の９１５と同様であり、ｋは、図９の９１５でｆ_ｋ（ｃ’）を算出するためにＰ９０５によって使用された鍵であり、ｒ_１，．．．，ｒ_ｎは、図９の９１５においてＥ_ｐｋ［ｆ_ｋ（ｃ’）］の算出に関与したすべてのランダム値である。ｒ_１，．．．，ｒ_ｎに対する算出は、Ｅ_ｐｋが確率的である場合にのみ関連する。Ｐ１１１５は、１１３０で、１１２５からのすべての算出結果をＳ１１０５に送る。Ｓ１１０５は、１１３５で、１１３０で受信されたすべての材料を、ｓｋ＊を使用して解読する。Ｓ１１０５は、１１４０で、関連する場合はｒ_１，．．．，ｒ_ｎを使用してＥ_ｐｋ［ｆ_ｋ（ｃ’）］を算出し、１１４５で、この値を、図９の９２５で受信された値と比較する。それらの値が一致する場合、１１３５における解読を介して算出されたｃ’が、Ｓ１１０５によって保持されているｃと等しい場合かつその場合に限り、図９におけるＰ９０５の問合せは正確であったことになる。そうでない場合は、Ｐ１１１５の問合せとデータ値のカプセル化ｃとの間の関係について何も判定することができず、Ｐ１１１５は悪意のある挙動を示している。

上述の初期データソースに関連付けられたデータ情報から導出されるトークン、または上述の初期データソースに関連付けられたデータ情報のトークン化に関して、すなわち、ＩＮＦＯをＴＯＫＥＮに変換することが可能なデータトークン化システムを介してこれを可能にすることは：関係者に、あるエンティティに関連付けられたデータへのアクセス権が付与され、ここで、データ、またはデータとデータへのエンティティの関連付けとの組み合わせがＩＮＦＯと表される。下記のトークン化の実施形態は、２つのサーバまたはプロセッサを考慮する使用事例のみをカバーするが、他の実施形態は、異なる数のサーバを利用することができる。

ＴＯＫＥＮを生成する全面的な解決法の求められる性質。ここで、用語「バックエンド」は第１のサーバまたはプロセッサを指し、用語「トランスレータ」は第２のサーバまたはプロセッサを指す。

１．所与のＩＮＦＯ値は、ＴＯＫＥＮ生成処理の最中またはその後に関係者の外部に露出されてはならない。

２．ＩＮＦＯ→ＴＯＫＥＮのマッピングは、（ａ）ＩＮＦＯ値で開始しようと、ＴＯＫＥＮ値で開始しようと、すべてのプロセッサ秘密へのアクセスなしには受動的な敵対者による再現が不可能でなければならず、（ｂ）１対１の対応関係でなければならず、（ｃ）バックエンドとトランスレータの組み合わせによって永続的に再算出可能でなければならない。

３．所与のＩＮＦＯ値について、ＴＯＫＥＮの表現は、関係者データベースにわたって相関してはならず、すなわち、追加的な情報なしでは、別々の関係者に記憶されたＴＯＫＥＮ表現のリスト間の交差を判定することが算出的に実現不可能でなければならない。

４．プロセッサの構成要素に関する危殆化は、構成要素の危殆化の時間と時間の間に敵対者によって連続性が維持されない限り、無効果でなければならない。そのようなプロセッサ構成要素は、プロセッサのパーティションの形態を取ることがあり、各パーティションは、それに対応するパーティションには入手不可能である暗号鍵材料を利用する。

５．敵対者がＩＮＦＯ→ＴＯＫＥＮの一致させたリストを作ることを防止することが好ましい。

６．ＩＮＦＯを「平文」と考え、ＴＯＫＥＮを「暗号文」と考えると、既知のまたは選択された平文攻撃に対する、ならびに既知のまたは選択された暗号文攻撃に対する回復性を保証することが好ましい。すなわち、いくつかのＩＮＦＯ－ＴＯＫＥＮペアを知ることが、別のＩＮＦＯ値をそのＴＯＫＥＮ値にマッピングする、または別のＴＯＫＥＮ値をそのＩＮＦＯ値に逆転する助けになってはならない。これは、最後から２番目の形態のＴＯＫＥＮが供給される、すなわち、一方向ハッシングがＴＯＫＥＮの作成で使用される場合にその値が一方向ハッシングの適用の直前にある場合でも、当てはまらなければならない。

７．どの関係者またはプロセッサも、ＩＮＦＯ値およびそれに対応するＴＯＫＥＮ値の両方へのアクセス権を有さないことを保証することが必要である。また、どの関係者またはプロセッサも、ＩＮＦＯ値と、そのＩＮＦＯに対応するＴＯＫＥＮを要求した関係者の身元または偽名との両方へのアクセス権を一方向に得ることができないことを保証することも必要である。

結果得られるＴＯＫＥＮ（これは各自のＩＮＦＯの原像を正確に表す）は、証明および証明に対する要求の目的のトランザクション処理を保証するために有用である。同じＩＮＦＯの再発生は、実際のトランザクション処理（コーディネータを伴う）の時点で一致させることができるが（ＩＮＦＯの露出なしに）、その他の場所で一致させることはできない（トランスレータを除く）。関係者に固有のＴＯＫＥＮの暗号化された先行値（predecessor）のみが、トランスレータおよび実際のトランザクション処理の外部に現れる。

提案されるトークン生成プロトコルの目標：正当なＩＮＦＯ値のセットを使い尽すことが算出的に実行可能であり得ることにもかかわらず、ＩＮＦＯを効果的にサニタイズすること。このトークン化を達成するために、トークン生成バックエンドプロセッサ、およびトランスレータと表されるコーディネータフロントエンドプロセッサを導入することができる。コーディネータは、ここに詳述される提案によって生成されるＴＯＫＥＮ値を利用するトランザクション処理を扱う役割を担う。

１つの好ましい実施形態では、所与のＩＮＦＯ値のそのＴＯＫＥＮ値へのマッピングは、バックエンドのペアになった２つのパーティションと、トランスレータのペアになった２つのパーティションとで保持されるＰｏｈｌｉｇ－Ｈｅｌｌｍａｎ鍵の累積的知識に依存する。より一般的には、互いと、および／または関係者と、および／またはトランスレータと通信する２つのバックエンドプロセッサなどの、所与のタイプのプロセッサが複数あり得る。

次いで図１２（ａ）を参照して、バックエンド１ １２０７およびバックエンド２ １２０９の２つのバックエンドプロセッサが、関係者１２０１によって提供された２つの別個の入力それぞれに対して異なるＰｏｈｌｉｇ－Ｈｅｌｌｍａｎ鍵を使用してそれぞれ動作する場合を考察する。例えば、バックエンド１ １２０７が、１２０３で受信されたｊＰに働きかけ、バックエンド２ １２０９が、１２０５で受信された（１－ｊ）Ｐに働きかけ、ここでＰはＩＮＦＯ値を表す。そして、バックエンド１ １２０７およびバックエンド２ １２０９は、１２１１におけるｂｂ_１ｊＰおよび１２１３におけるｂｂ_２（１－ｊ）Ｐからなる各自の中間結果を交換する。そして、各々が、前と同じＰｏｈｌｉｇ－Ｈｅｌｌｍａｎ鍵、すなわち、それぞれｂｂ_１およびｂｂ_２を再び使用して動作する。トランスレータ１２２０が、１２１９を介して、２つのバックエンドプロセッサの最終結果、すなわち、１２１５で関係者１２０１に送られたｂｂ_１ｂｂ_２（１－ｊ）Ｐおよび１２１７で関係者１２０１に送られたｂｂ_２ｂｂ_１ｊＰ、を受信した場合は、可能性としては自分自身のＰｏｈｌｉｇ－Ｈｅｌｌｍａｎ鍵ｔｔを適用する前に、トランスレータ１２２０は、１２２１でそれらを加えて、カスケード式にＰに働きかけた両方のバックエンドプロセッサの結果ｂｂ_１ｂｂ_２Ｐを導出することができ、ただし、Ｐはどちらのバックエンドプロセッサにも露出されることがない。また、１２２１に示されるように、トランスレータ１２２０は、１２２３で結果をコーディネータ１２２５に通信する前に、好ましくは一方向のハッシュ関数を適用することができる。バックエンド１ １２０７およびバックエンド２ １２０９の各々は、トランスレータ１２２０によるエンドツーエンドアクセスのために自身の最終結果を暗号化することができ、その場合、バックエンドからトランスレータ１２２０への通信が関係者１２０１を通過することによって行われても、関係者１２０１はそれら最終結果にアクセスしない。代替として、バックエンド１ １２０７およびバックエンド２ １２０９は、最終結果が関係者１２０１に伝送される際に暗号化される場合でも、関係者１２０１がそれらにアクセスする（そしてそれらを共に加える）ことができるようにして、最終結果を関係者１２０１に通信してもよい。さらに、バックエンド１ １２０７はバックエンド２ １２０９を介して通信できる（またはその逆）という意味で、バックエンド１ １２０７およびバックエンド２ １２０９は両方とも、関係者１２０１またはトランスレータ１２２０に直接通信する必要がないことに留意されたい。そのような場合、送信は、下にある結果／データ／メタデータが通過されるバックエンドからアクセス可能でないように、保護することができる。

次いで図１２（ｂ）を参照すると、ここに描かれるプロセスは、図１２（ａ）と同じ結果をもたらすが、ここではバックエンド２ １２３５が、バックエンド１ １２３１が１２２９を介して関係者１２２７からバックエンド１ １２３１により受信されたＰに直接働きかけた１２３３の中間結果ｂｂ_１Ｐに働きかけて、ｂｂ_２ｂｂ_１Ｐを生成し、それが１２３７で関係者１２２７に送信される。したがって、ここでは、図１２（ａ）とは異なり、Ｐはバックエンド１ １２３１に露出される。トランスレータ１２４０は、１２３９を介してｂｂ_２ｂｂ_１Ｐを受信し、１２４１でＴＯＫＥＮを生成する。ＴＯＫＥＮは、１２４３を介してコーディネータ１２４５に提供される。さらに、図１２（ａ）および図１２（ｂ）では、バックエンドおよびトランスレータの一方が同じ権限の下にあり得、その権限はＩＮＦＯ値もＰ値も知ることがないことに留意されたい。これは、図１２（ｃ）に描かれるように、逐次的な処理を回避するために２つのバックエンドが同じＰｏｈｌｉｇ－Ｈｅｌｌｍａｎ鍵を所有していた場合には該当しない。

次いで図１２（ｃ）を参照すると、関係者１２５９がｂｂｊＰおよびｂｂ（１－ｊ）Ｐの両方を暗号化されていない形態に回復することができ、よってそれらを共に足すことができる場合、トランスレータ１２６２は、１２６１を介してｂｂｊＰおよびｂｂ（１－ｊ）Ｐを受信するか、または可能性としては、それら２つの楕円曲線点の和、すなわちｂｂＰを受信し、１２６３でＴＯＫＥＮを生成する。ＴＯＫＥＮは、１２６５を介してコーディネータ１２６７に提供される。関係者１２５９は、１２４７でバックエンド１ １２５１にｊＰを提供した後、１２５５でバックエンド１ １２５１からｂｂｊＰを受信する。同様に、関係者１２５９は、１２４９でバックエンド２ １２５３に（１－ｊ）Ｐを提供した後、１２５７でバックエンド２ １２５３からｂｂ（１－ｊ）Ｐを受信する。関係者１２５９は、トランスレータ１２６２が最終的に使用するために意図される形態で値ｂｂｊＰおよびｂｂ（１－ｊ）Ｐのいずれかまたは両方を受信し得、この形態は関係者１２５９が実際の値を回復することを許容しない。

図１３、図１４、および図１５は、図１２（ａ）、図１２（ｂ）および図１２（ｃ）に描かれる実施形態と異なり、同じＰ値の複数のインスタンスを差異化する、ランダム化されたブラインドファクタが関係者によって除去される（ならびに開始される）実施形態を描いている。また、図１２（ａ）、図１２（ｂ）および図１２（ｃ）に描かれる実施形態と異なり、図１３には１つのみのバックエンドが描かれている。

次いでＴＯＫＥＮの生成の代替実施形態としての図１３を参照すると、エンティティまたはデータ所有者１３１０が、関係者１３１５に情報を提供し、その情報から、関係者１３１５は楕円曲線点Ｐを導出する。Ｐは、前に解説したようにＩＮＦＯを表し得る。関係者１３１５は、ブラインド／隠蔽ファクタｌを使用してＰをブラインドして、１３２０でバックエンド１３２５に送信されるｌＰを生成する。１３３０でバックエンド１３２５からｂｂｌＰを受信すると、関係者１３１５はブラインドファクタｌを除去し、その結果得られた値ｂｂＰを１３３５でトランスレータ１３４０に送信する。関係者１３１５は、１３４５で、トランスレータ１３４０からＥｎｃ＿ＴＯＫＥＮを受信する。Ｅｎｃ＿ＴＯＫＥＮはコーディネータ１３５０と併せて使用され得、ここで、好ましくは、Ｅｎｃ＿ＴＯＫＥＮからＴＯＫＥＮを回復するためにコーディネータ１３５０が備えられる。ＴＯＫＥＮは、１３４２でトランスレータ１３４０によって導出され、Ｅｎｃ＿ＴＯＫＥＮは、暗号化機構を介してＴＯＫＥＮからトランスレータ１３４０によって導出されることに留意されたい。１３３０により、ｂｂｌＰはインスタンスごとに一意であり、一方、１３３５により、ｂｂＰはそうでない。好ましくは、関係者１３１５がｂｂｌＰからｌを除去し、その結果ｂｂＰが得られた直後に、ｂｂＰは、１３３５でトランスレータ１３４０に送信するために一意に暗号化される。そのような暗号化されたバージョンは、関係者１３１５に関連付けられたデータベースに記憶されてよく、各関係者において異なって見える。そのような暗号化されたバージョンは、必要があれば、トランスレータ１３４０に再送されてよい。そのような必要性は、例えば、Ｅｎｃ＿ＴＯＫＥＮを作るためにトランスレータ１３４０によって使用された暗号鍵が更新された場合に発生することがある。１３４５のＥｎｃ＿ＴＯＫＥＮは、例えば、暗号鍵が再使用される場合でも一意の初期化ベクトルの使用に基づいて、トランスレータ１３４０によってインスタンスごとに一意に算出され得る。Ｅｎｃ＿ＴＯＫＥＮを作るために使用された暗号鍵、およびその鍵が更新された場合にはその後続値（successor）は、関係者１３１５には入手可能にされないまま、トランスレータ１３４０とコーディネータ１３５０との間で共有されてよい。トランスレータ１３４０およびコーディネータ１３５０が組み合わせられる（これは暗号化の流れおよび／または使用もしくは不使用に影響し得る）などの変形例が可能であることに留意されたい。

不正行為属性トークンであるＦＡＴＯＫＥＮに対する要件は、ＴＯＫＥＮに対するものとは異なるため、ＦＡＴＯＫＥＮは、逐次処理ではなく並列処理を介して生成することができる。何故ならば、関係者によるブラインドファクタｌの除去は、トークン生成手順またはプロトコルのセキュリティの確定されたレベルに悪影響を与えることなく、安全に遅らせることができるためである。この場合、図１３のＴＯＫＥＮ生成手順またはプロトコルと異なり、ＦＡＴＯＫＥＮの最終値の生成は、トランスレータではなく関係者で行われる。

次いでＦＡＴＯＫＥＮの生成についての図１４を参照すると、エンティティまたはデータ所有者１４１０が関係者１４１５にデータを提供し、このエンティティまたはデータ所有者１４１０は、データの所有者のふりをしている詐欺者であり得る。そのような受信データの１つまたは複数の要素を関係者１４１５によって使用して、Ｐ_１，．．．，Ｐ_ｋと表されるデータ属性を表すＰ値を生成することができる。１４２０を介して、関係者１４１５は、Ｐ_１，．．．，Ｐ_ｋのブラインドバージョン、すなわちｌＰ_１，．．．，ｌＰ_ｋを、まとめて１４２５と表されるバックエンドＸおよびバックエンドＹの両方に送る。バックエンドＸおよびバックエンドＹは、並列に動作して、それぞれ、１４３０で関係者１４１５に送信されるｂｂ_ＸｌＰ_１，．．．，ｂｂ_ＸｌＰ_ｋおよびｂｂ_ＹｌＰ_１，．．．，ｂｂ_ＹｌＰ_ｋを生成することができる。１４３５で、関係者１４１５は、ｉ＝１～ｋについてｂｂ_ＸｌＰ_ｉおよびｂｂ_ＹｌＰ_ｉの各ペアに対して算出を行って、ＦＡＴＯＫＥＮ値を生成する。バックエンドＸおよびバックエンドＹは、単独で動作しており、またブラインドファクタｌがそれらに未知のままであれば互いと共に動作することさえあるが、どちらも、１４３０でＦＡＴＯＫＥＮを自身の寄与に相関付ける能力を持たないことに留意されたい。ＦＡＴＯＫＥＮは、関係者１４１５によりレジストリ１４４０と併せて使用されてよく、レジストリ１４４０は、この文脈では不正行為属性レジストリとみなされてよい。そのような使用の１つは、関係者１４１５がＦＡＴＯＫＥＮを証明する、または要求することを伴う。要求の処理中に、レジストリ１４４０は、リクエスターの役割内で動作する要求元ネットワーク要素によって行われた要求の一部としてサブミットされたＦＡＴＯＫＥＮ値の、アテスターの役割内で動作する要求元ネットワーク要素によりまたはその代わりに以前にサブミットされた証明を介した、確証を示す情報を戻してよい。図５および図７に描かれる証明および要求と異なり、要求はここでは、ＴＯＫＥＮ値のどのような関数も組み込む必要はないことに留意されたい。さらに、ここでのデータタイプは、ラベル付きまたはラベルなしとして指定されてよい。

次いで、混合型のトークン生成手順または混合型のトークン生成プロトコルについての図１５を参照すると、ＴＯＫＥＮの生成とＦＡＴＯＫＥＮの生成の両方が対応される。１５１０は、正当なエンティティもしくはデータ所有者に対応する場合も、または不正を働いている、すなわち詐欺者として動作している可能性のあるものに対応する場合もある。関係者１５１５は、ＴＯＫＥＮを取得または使用することに関与するものとしての関係者を表し、一方、関係者１５２０は、ＦＡＴＯＫＥＮを取得または使用することに関与するものとしての関係者を表している。１５３５および１５４０は、プロセッサがそれぞれ図１３のバックエンド１３２５または図１４の１４２５におけるバックエンドＸとして動作することを表している。１５６０および１５４０は、プロセッサがそれぞれ図１３のトランスレータ１３４０または図１４の１４２５におけるバックエンドＹとして動作することを表している。１５７０および１５７５は、プロセッサがそれぞれ図１３のコーディネータ１３５０または図１４のレジストリ１４４０として動作することを表している。１５２５および１５５５は、ＴＯＫＥＮの生成に関する関係者からの送信を表し、一方、１５３０は、ＦＡＴＯＫＥＮの生成に関する関係者からの送信を表す。１５４５および１５６５は、それぞれバックエンドまたはトランスレータとして動作する発信元プロセッサからのＴＯＫＥＮの生成に関する送信を表す。１５５０は、バックエンドＸまたはバックエンドＹとして動作する発信元プロセッサからのＦＡＴＯＫＥＮの生成に関する送信を表す。

以下の解説は、ＴＯＫＥＮの生成により詳細に着目する。しかし、主要な原理は、ＦＡＴＯＫＥＮの生成にも適用可能である。Ｄｉｆｆｉｅ－ＨｅｌｌｍａｎまたはＰｏｈｌｉｇ－Ｈｅｌｌｍａｎのプライベート鍵を介して作用されることになる値の受信者は、ＮＩＳＴ Ｓｐｅｃｉａｌ Ｐｕｂｌｉｃａｔｉｏｎ ８００－５６Ａｒ３仕様に従った適当な公開鍵の有効性確認ルーチンを実行する。１つの手法によれば、公開鍵の有効性確認は、マシンが、外部ソースから（例えばプロセッサパーティションからプロセッサパーティションへ、関係者からプロセッサへ、またはプロセッサから関係者へ）、そうであるとされる楕円曲線点を受信し（可能性としてはローカルでの解読の後に）、スカラー乗算を介してそれに働きかけることを意図するたびに、行われなければならない。ここで検討される文脈では、Ｐ－２５６の仕様を理由として、必要とされる唯一の検査は、受信された値が特定の意図される曲線上の点に対応することを確かめることである（楕円曲線はここでは例として使用される）。ＥＣＤＳＡデジタル署名の受信者は、好ましくは、ある関係者から発信されたとされる（例えば要求タイプによって示される）要求に対する動作を取る前に、その署名と署名者の主張される権限とを検証する。一例として、あるプロセッサパーティションが、信頼できるルートまでつながっている公開鍵証明書を検証し得、ここで、その公開鍵証明書は現在有効であり、対象の公開鍵を、ある関係者によって所有されているものと識別し、その対象の公開鍵が要求の署名を検証するために使用される。ＨＭＡＣ値が受信されたときには必ず、その値が、ローカルで算出されたＨＭＡＣ値と一致するかどうか単独で検査される。ＨＭＡＣ（Hashed Message Authentication Code）は、データの完全性および、ＨＭＡＣ鍵の知識を有するものとしてのエンティティの認証を検証するための、対称鍵に基づく機構例である。トークン生成プロトコルは、プロセッサパーティション間（または仲介ゲートウェイを通る）、および／または関係者とトークン生成者間（プロセッサまたはフロントエンドからプロセッサとしての）、および／または関係者とコーディネータまたはレジストリとの間の直接のトランスポートレベルのセキュリティ（存在する場合）だけに依拠しないように、徹底したセキュリティを提供しようとするものである。Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎ暗号およびワンパスＤｉｆｆｉｅ－Ｈｅｌｌｍａｎ鍵交換が、下記で最も優先的に使用される。トークン生成プロトコル全体を通じて、達成される必要がある性質のため、ランダム化された動作と決定的動作との組み合わせが採用される。ＴＯＫＥＮ生成の場合、目標は、各ＩＮＦＯが毎回同じＴＯＫＥＮを生じさせるようにトークン生成プロトコルの全体的な効果が決定的なものになるようにすることである。しかし、ランダム化は次の理由から採用される。すなわち、ＩＮＦＯをバックエンドから隠すため（バックエンドパーティションによる変形の後にそのようなランダム化を除去することが安全になるまで）、パーティション間の通信を傍受者から不可視化するため、パーティション間の鍵確認鍵の知識を、プロセッサパーティションの１回限りの危殆化を介しては入手できないランダマイザ出力の知識に依存させるため、である。パーティション間通信の傍受者は、以前に処理された入力の処理を、これまでに一度も処理されたことのない入力の処理から区別することができない。関係者によるＩＮＦＯのランダム化された隠蔽は、バックエンドに、それが以前に「見られた」ＩＮＦＯを処理しているか否かを認識させないためにも有用である可能性がある。例えば、バックエンドによる、差のある結果を生じさせる同じＩＮＦＯの処理は、監査時に異常としてフラグが立てられてよい。一般に、各プロセッサは、一体構造である場合も、または２つ以上のパーティションに分割されている場合もある。ここで、プロセッサ（バックエンドおよびトランスレータ）をそれぞれ２つのパーティションに分割することができ、ここで、パーティションは好ましくは、セットアップ時に対応するパーティションとペアにされた、それぞれ独立してセキュリティが確保されたモジュールである。悪意のない事例では、両方のパーティションが同じ結果を生成する。これは、サービス品質に関して検査され得る。しかし、このことは、関係者が必ずしもデータのコピーを２つ受信することを示唆するものではない。実装が２つのプロセッサ、すなわちバックエンドおよびトランスレータを伴う場合、所与のＩＮＦＯのそのＴＯＫＥＮへのマッピングは、バックエンドのペアにされた２つのパーティションおよびトランスレータのペアにされた２つのパーティションで保持されているＰｏｈｌｉｇ－Ｈｅｌｌｍａｎ鍵の累積的知識に依存し得る。

楕円曲線Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎ暗号を使用して、アリスは、公開楕円曲線上の所与の（平文）楕円曲線点Ｐを最終的にボブに通信したい。次いで図１６を参照すると、アリスとボブが共有秘密ｌを有しており、ここで、ｌは、１とｎ－１との間の整数（両端の数を含む）であり、ｎは、Ｐの素数位数である。これはアリスとボブの間で共有秘密を必要とするため、Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎは対称鍵暗号であるが、楕円曲線Ｄｉｆｆｉｅ－Ｈｅｌｌｍａｎ（ＥＣＤＨ）鍵一致や楕円曲線デジタル署名アルゴリズム（ＥＣＤＳＡ）などの非対称／公開鍵暗号アルゴリズムに共通の楕円曲線スカラー乗算を利用する。１６１０で、アリスがＰを選択し、Ｑ＝ｌＰを算出し、その値をボブに送る。１６２０で、ボブがｌ^－１ ｍｏｄ ｎを適用することにより、受信した値Ｑを解読して、Ｐを回復する。

次いで図１７を参照すると、アリスは、暗号文Ｑをボブに通信したいが、ボブに平文Ｐを回復してほしくない。ここで、整数ｋは、アリスだけが知っている秘密である。１７１０で、アリスはＰを選択し、Ｑ＝ｋＰを算出し、Ｑをボブに送る。１７２０で、ボブは値Ｑを受信するが、ｋの知識を持っていないため、Ｑを解読することはできない。

次いで図１８を参照すると、３つの行為者、すなわち、関係者、バックエンド、およびトランスレータがいる。これら３つの行為者は、ＴＯＫＥＮを作成または生成するために相互と対話することができる。関係者は、図１６の楕円曲線Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎ暗号を適用し、１８１０では選択、生成、または導出されたＰの値に対する暗号化の役割を果たし、１８３０では１８２０の結果に対する解読の役割を果たす。バックエンドとトランスレータは両方とも、図１７の一方向楕円曲線Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎ暗号を適用し、それを１８２０では１８１０の結果に、１８４０では１８３０の結果にそれぞれ適用する。関係者における暗号化および解読動作の効果は、ＩＮＦＯを表すものとしてのＰを、その値に最終的に影響することなく、バックエンドからブラインドすることである。すなわち、１８１０、１８２０、および１８３０からなる３部の動作を、同じ関係者によってまたは複数の関係者にわたってその都度独立して開始される特定のＩＮＦＯ値に複数回実行すると、結果として、バックエンドだけがＩＮＦＯ値に直接働きかけたかのように、同じ値が生じる。一方向楕円曲線Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎを使用してＩＮＦＯ値からＴＯＫＥＮを作成することにより、元となったＩＮＦＯ値を、対応するＴＯＫＥＮから発見することが実行不可能であることを保証する。

アリスとボブは、互いとの間に共有秘密を確立したい。ボブが最初に動作して、公開鍵を作成し、それを公開する。この時点の後の任意の時に、アリスは、このプロセスの結果を使用して、ワンパス楕円曲線Ｄｉｆｆｉｅ－Ｈｅｌｌｍａｎ鍵交換を介して２人の間の共有秘密を作成することができる。次いで図１９を参照して、ワンパス楕円曲線Ｄｉｆｆｉｅ－Ｈｅｌｌｍａｎをより具体的に説明すると、１９１０で、ボブが、比較的静的なプライベート鍵－公開鍵のペア［ｎ_Ｂ，ｎ_ＢＧ］を設定する。１９２０で、アリスが、一時的プライベート鍵－公開鍵のペア［ｎ_Ａ，ｎ_ＡＧ］を算出し、ｎ_Ａをボブの公開鍵に適用して、ボブとの間で共有される秘密を算出する。１９３０に描かれるようにボブが共有秘密を回復するための仕組みは、ボブがアリスの一時的公開鍵にｎ_Ｂを適用するものである。図１９に示されていないのは、アリスが、信頼される機構を通じてボブの公開鍵を受け取ることがあり得、よってそれが実際にボブに関連付けられていることが分かり、またボブは、アリスに関連付けられているとされる一時的公開鍵が実際にそうであることを確信し得ることである。ボブがその確信を得るためのそのような機構の１つは、アリスが、アリスに関連付けられていることがボブによって信頼される署名検証公開鍵に関連付けられた比較的静的な署名生成プライベート鍵を使用して、一時的公開鍵に署名するものである。トークン生成プロトコルの間、プロセッサが、図１９のボブとして動作し、セットアップ中にそれらの公開鍵を作成する。関係者は、プロセッサとの共有秘密を利用して、プロセッサに情報をセキュアに通信し、プロセッサからセキュアに情報を受信するための鍵を導出または移送するために、図１９のアリスとして動作する（ここで、関連付けられた初期化ベクトルと併せて、機密性保護のための暗号文に加えて完全性検証のために認証タグが利用されてもよい）。そのような情報の例には、関係者からバックエンドプロセッサに送られるＩＮＦＯのブラインドバージョンと、関係者からトランスレータプロセッサに送られるバックエンドからの情報として関係者によって受信される中間ＴＯＫＥＮ値の非ブラインドバージョンとを含む楕円曲線点が含まれ、トランスレータプロセッサは、エンドツーエンド暗号化の意図される対象に関係するトランザクション処理のために後に関係者が使用するようにエンドツーエンド暗号化されているＴＯＫＥＮ値からなる情報をもって、関係者に応答する。この意図される対象は、例えば、コーディネートネットワーク要素の役割内で動作するコーディネータであり得る。好ましくは検証可能な解読の結果、関係者によって回復される中間ＴＯＫＥＮ値は、好ましくは検証可能に関係者から発信されるものとしてトランスレータに的を絞って送付するために暗号化される前に、例えばブラインドファクタを除去するために処理されてよい。

ランダム化共有秘密導出（ＲＳＳＤ）アルゴリズムは、Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎの算出を行うときに必ず、またはパーティションされたバックエンドもしくはトランスレータにおけるワンパスＤｉｆｆｉｅ－Ｈｅｌｌｍａｎの受信者側で使用される。

・このアルゴリズムは、ＲＳＳＤ［ｘ；Ｑ；２］と表される。

・アルゴリズムを実行するプロセッサ（バックエンドまたはトランスレータ）は、２つのパーティションに分割される。

・各パーティションｉは、

を生成する。

・各パーティションｉはｘ_ｉを所有し、ｘ＝（ｘ_１，ｘ_２）である。

・曲線Ｅ上の点Ｑが利用される。

次いで図２０を参照すると、プロセッサが２つのサブプロセッサに区分される場合におけるＲＳＳＤのステップが示される。２０２０で、各パーティションｉは、２０１０の自身のｒ_ｉをＱに適用し、その結果を他方のパーティションに渡す。２０３０で、各パーティションｉは、２０２０から受信した値に自身のｘ_ｉを適用し、その結果を他方のパーティションに渡す。２０４０で、各パーティションｉは、２０３０から受信した値に自身の

をプライベートに適用する。負荷平衡および／またはシステム回復能力の事例に、同じプロセッサタイプが、各々が所与のタイプのプロセッサを備える複数のパーティションペアを有する場合、各パーティションペアは関連付けられた番号を有さなければならないことに留意されたい。プロセッサパーティションは、そのパーティション番号｛１｝または｛２｝と、それが属するパーティションペア番号とからなるＩＤで識別される。

ＲＳＳＤを実行してプロセッサ内での通信を保護するときに、以下のプロセスを使用することができる。渡されるデータにヘッダが追加され、ヘッダは、プロセッサパーティションＩＤおよびパスタイプ（Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎの場合はＰＨ、Ｄｉｆｆｉｅ－Ｈｅｌｌｍａｎの場合はＤＨ）と、パス番号（例えば｛ＰＨ２｝または｛ＤＨ１｝）とを含む。これは、このプロセッサの内部で現在のｈ鍵を使用してＨＭＡＣ処理される。この結果は、データと共に渡されるＨＭＡＣタグ：（データ，ＨＭＡＣ_{ｈ－ｋｅｙ}（データ｜｜プロセッサパーティションＩＤ｜｜ＰＨまたはＤＨ，およびパス＃））である。例えば、パーティション１からパーティション２に送られるＰｏｈｌｉｇ－Ｈｅｌｌｍａｎ算出の２回目のパスは次のようになる：（ｘ_１ｒ_２Ｑ，ＨＭＡＣ_{ｈ－ｋｅｙ}（ｘ_１ｒ_２Ｑ｜｜｛１｝｜｜｛ＰＨ２｝））。

上記の例は、同じプロセッサタイプのパーティションペアがいくつも存在しないことを仮定している。パーティションが、別のパーティションからそれに与えられるまたは関係者によって提供される任意の点に作用する前に、パーティションは公開鍵の有効性確認を行わなければならず、それは、この場合、その点が楕円曲線上にあることの検査のみを必要とする。

ｒ_１およびｒ_２によってここで提供される通信のブラインド（ならびに、後に解説するように構造ｒ_１ｒ_２Ｑを使用して鍵確認ＨＭＡＣ鍵を作る際のｒ_１およびｒ_２の使用）の効果を最大にするために、ｒ_１値およびｒ_２値は各々、ライブエントロピーソースの一貫した使用を通じて予測耐性を提供するランダムビットジェネレータ（ＲＢＧ）の出力であるべきである。

ＲＳＳＤアルゴリズムは、要約すると以下のように特徴付けることができる。静的な受信者側ワンパスＤＨまたは静的なＰＨ暗号化を達成するセキュアマルチパーティコンピュテーション（ＳＭＣ）方法。それにより、各パーティションは、（１）一時的Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎ暗号化を行い、それに続いて、（２）静的で一時的なＤｉｆｆｉｅ－Ｈｅｌｌｍａｎ通信の静的な側を行い、それに続いて、（３）同時に適用される一時的Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎの解読および静的で一時的なＤｉｆｆｉｅ－Ｈｅｌｌｍａｎ共有秘密導出の静的な側を行う。（３）では、この共同の算出が、例えばｘ_２ｒ_１Ｑのスカラー乗数としてｒ_１ ^－１ ｘ_１ ｍｏｄ ｎを使用することによって最も効率的に行われることから、Ｐｏｈｌｉｇ－ＨｅｌｌｍａｎとＤｉｆｆｉｅ－Ｈｅｌｌｍａｎが「同時に適用される」。２つのスカラーのモジュラー乗算は、楕円曲線点のスカラー乗算よりも算出的に大幅に効率的である（ただし（ｒ_１ ^－１ ｘ_１ ｍｏｄ ｎ）（ｘ_２ｒ_１Ｑ）＝ｒ_１ ^－１（ｘ_１（ｘ_２ｒ_１Ｑ）））。

バックエンドまたはトランスレータのｋ個のパーティションを扱う一般化されたランダム化共有秘密導出アルゴリズムを利用することができる。実装において：

・このアルゴリズムへの入力は、ＲＳＳＤ［ｘ；Ｑ；ｋ］と表される。

・アルゴリズムを実行するプロセッサ（バックエンドまたはトランスレータ）は、ｋ個のパーティションに分割される。

各パーティションｉは、

を生成する。

各パーティションｉはｘ_ｉを所有し、ｘ＝（ｘ_１，ｘ_２，．．．，ｘ_ｋ）である。

・曲線Ｅ上の点Ｑが利用される。

次いで図２１を参照すると、プロセッサがｋ個のサブプロセッサにパーティションされる場合におけるＲＳＳＤのステップが示される。２１２０で、各パーティションｉは、２１１０の自身のｒ_ｉをＱに適用し、その結果をパーティションｉ＋１ ｍｏｄ ｋに渡す。２１３０で、各パーティションｉは、２１２０から受信した値に自身のｘ_ｉを適用し、その結果をパーティションｉ＋１ ｍｏｄ ｋに渡す。これに続いて、以下がｋ－２回反復される：各パーティションｉは、２１３０から受信した最後の値に自身のｘ_ｉを適用し、その結果をパーティションｉ＋１ ｍｏｄ ｋに渡す。２１４０で、各パーティションｉは、２１３０から受信した最後の値に自身の

をプライベートに適用する。

ＴＯＫＥＮまたはＴＯＫＥＮのバッチが生成されるたびに行われるトークン生成プロトコルのステップを説明する前に、システムセットアップのための算出について以下で説明する。

次いで図２２を参照すると、バックエンド２２３０の場合、初期の鍵材料、すなわち、好ましくはランダムまたは疑似ランダムに選択されたｂ＝（ｂ_１，ｂ_２）およびｂｂ＝（ｂｂ_１，ｂｂ_２） ｍｏｄ ｎ（ここでペアの各値は［１，ｎ－１］の要素とみなされる）は、２２１０で、好ましくはセキュアに生成され、２２２０で、制御された環境内でプロセッサパーティションを実施してそれらをペアリングする際に使用するために、好ましくはセキュアに保持される。そのような制御された環境は、例えば通信が局地化されるシナリオなどにおいて、物理的なセキュリティ措置および／または多人数制御を要し得る。そのような制御された環境は、代替または追加として、例えば、セットアップ通信が可能性としてはオープンチャネルを通じて遠隔から行われる場合に、事前に設置された鍵の使用を要することもある。パーティション自体に共同して初期鍵材料を生成することをさせない図２２に描かれる事例は、ＴＯＫＥＮ値へのＩＮＦＯ値の一意のマッピングを犠牲にすることなく、複数のパーティションペアが、各々が所与のプロセッサタイプのプロセッサとして独立して動作できることから、負荷平衡を可能にし、入手可能性および回復可能性を保証するために有用である（図２２でバックエンドのプロセッサタイプを描いているところでは、トランスレータのプロセッサタイプが同じように扱われ得ることを理解している）。分散ステップは、自身の鍵を回復させることを必要としない単一のパーティションペアしか存在しない場合には不必要とみなされてよい。関係者は、どのパーティションペアが実際に各自の要求を処理するかを認識しないままでいることができる。パーティションのセキュリティのために、各パーティションペアは、２２４０でＲＳＳＤ［ｅ；Ｇ；２］を実行してプロセッサペアの内部共有秘密を作成することができ、ここで、ｅ＝（ｅ_１，ｅ_２）は、ランダムに選択された、各々が［１，ｎ－１］内にある一時的値ｅ_１およびｅ_２からなる。退化型のＲＳＳＤ［ｅ；Ｇ；２］が使用される場合、すなわちｒ_１＝１およびｒ_２＝１の場合は、それらパーティションがそのパスをなくすようにプログラムされていれば、ｒ_ｉＧは通信される必要がない。２２５０で、各パーティションにおいてこの共有秘密からＨＭＡＣ鍵ｈ－ｋｅｙを導出する（例えば、標準的な抽出および展開法を使用することによる）。これは、プロセッサ内のエンティティ認証およびペアにされたパーティション間でのデータ完全性のために規則的に更新され、使用されることになる内部ＨＭＡＣ鍵である。抽出および展開法は、２２６０におけるｂ_１、ｂ_２、ｂｂ_１、およびｂｂ_２を更新するためのセットアップ時にも使用され得る。この更新プロセスが、図２４の２４４０に描かれる。単一のパーティションペアしかない場合には、２２６０で以下が起こり得る。各パーティションｉが、［１，ｎ－１］の中で選択されたランダムなｂ_ｉを生成し、回復のために必要とされるのに備えて、ｂ_ｉがバックエンドのｉ番目のパーティションによってセキュアなオフラインストレージに保存され、それらのｂ_ｉは、後に変更されるためにローカルに保持され、積ｂ_１ｂ_２ ｍｏｄ ｎを変更されないままに保ち、バックエンドパーティションペアのｉ番目のペアは、２２６０で［１，ｎ－１］の中で選択されたプライベート鍵ｂｂ_ｉも生成し、保持する。これらのｂｂ_ｉは、Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎ暗号化を行うために使用される。これらをセキュアに保存することにより、ＴＯＫＥＮ値の過去の生成との整合性が維持されるべき場合は、必要に応じて、システム回復時にＰｏｈｌｉｇ－Ｈｅｌｌｍａｎ暗号文の複製が可能になる。任意のバックエンドパーティションペア（１つのみでも複数でも）が、２２７０でＲＳＳＤ［ｂ；Ｇ；２］を実行して、公開鍵Ｂ＝ｂ_１ｂ_２Ｇを生成することができる。この公開鍵は、ワンパスＤｉｆｆｉｅ－Ｈｅｌｌｍａｎ鍵交換のためにイニシエータによって使用される。注：ｂは、共有秘密を再構成するために、ワンパスＤｉｆｆｉｅ－Ｈｅｌｌｍａｎの受信者側で使用される。上記で一時的共有秘密の生成に関して説明したように、退化型のＲＳＳＤ［ｂ；Ｇ；２］がここで適用されてよい。バックエンドの公開鍵Ｂ＝ｂ_１ｂ_２Ｇは、標準的な公開鍵証明書または、この責任を負うことを依拠側パーティによって認められた機関によって署名されたサブミットされたトランザクションを伴うブロックチェーン上での公開などの、他の機構を使用して公開される。図２２は、適正な鍵生成のためにトランスレータの事例でも適用されてよい。

次いで図２３を参照すると、関係者２３１０は、２３２０で、以下のようにして楕円曲線Ｅ上でＩＮＦＯから点Ｐを生成する。（１）ＩＮＦＯを取り込む。（２）ＩＮＦＯの後に、すべて０で開始する１６ビットのパッドを付加し、すなわち、（ＩＮＦＯ｜｜Ｐａｄ）＝（ＩＮＦＯ｜｜００００００００ ００００００００）とする。（３）２５６ビットのハッシュ値を算出して、ｘ_０＝ｈａｓｈ（ＩＮＦＯ｜｜Ｐａｄ）を作成する。（４）

が平方剰余、例えばｙ^２ ｍｏｄ ｐであるかどうかを判定する。そうでない場合は、パッドに１を足し、このステップを繰り返す。（５）有効なｘ_０が見つかったら、ｘ_＊＝ｘ_０を定義する。

個の平方剰余がある（０を含む）。したがって、ｘ_０が試されるたびに、ｘ_０が平方剰余をもたらす

の見込みがある。ｘ_０が平方剰余をもたらすおよそ

の確率があるため、このループは長大なものにはならないはずである。平方剰余を見つける前にすべての１６ビットを使い果たすことが起きた場合は、ｈａｓｈをｈａｓｈ（ｈａｓｈ）に置き換えて、（ｃ）および（ｄ）を再実行する。可能性としては反復的であるこの技法（例えばｈａｓｈ（ｈａｓｈ（ｈａｓｈ（ＩＮＦＯ｜｜Ｐａｄ）））の使用に代えて、パッドのビットサイズを、例えば３２ビットのパッドなど、より大きくすることができる。（６）バイアスを回避するために以下の追加的な検査が追加されるべきである。モジュロｐのラップアラウンドを伴う候補のｘ座標値があればそれを拒否する、すなわち、それについては２^２５６＞ｈａｓｈ（ＩＮＦＯ｜｜Ｐａｄ）＞ｐ－１である（またはそれについては、反復的なハッシングが必要である場合、２^２５６＞ｈａｓｈ（ｈａｓｈ（ｈａｓｈ（ＩＮＦＯ｜｜Ｐａｄ）））＞ｐ－１）。このバイアス回避技法が、算出時間に対して与える影響は無視できる。何故ならば、

であるためである。（７）

となるように、ｙおよび－ｙ ｒｅｄｕｃｅｄ ｍｏｄ ｐのうち小さい方をｙ_＊によって表す。次いで点Ｐが（ｘ_＊，ｙ_＊）として定義される。関係者２３１０は、次いで２３３０で、［１，ｎ－１］の中でランダムなｌを生成し、Ｉ＝ｌＰを算出することにより、Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎ暗号を行う。ｌ^－１ ｍｏｄ ｎを算出し、それを、バックエンドからの応答に（解読後に）適用されるまで維持する。関係者２３１０は、２３４０で、ワンパスＤｉｆｆｉｅ－Ｈｅｌｌｍａｎにおけるイニシエータとして動作する。最初に、それらは、ワンパスＤｉｆｆｉｅ－Ｈｅｌｌｍａｎの算出のために次のステップで使用される一時的プライベート鍵用のランダムな整数ｒａｎｄ_Ｐを生成する。関係者２３１０は次いで、Ｂにｒａｎｄ_Ｐを乗算して、ｒａｎｄ_ＰＢ＝ｒａｎｄ_Ｐｂ_１ｂ_２Ｇを生成し、これが、ワンパスＤｉｆｆｉｅ－Ｈｅｌｌｍａｎの共有秘密［ｓｓ；Ｐａｒ⇔Ｂａｃｋ］となる。関係者２３１０は次いで、Ｇにｒａｎｄ_Ｐを乗算して、ｒａｎｄ_ＰＧを生成し、これが、ワンパスＤｉｆｆｉｅ－Ｈｅｌｌｍａｎのために使用される公開鍵［ｐｋ；Ｐａｒ⇔Ｂａｃｋ］である。これはバックエンドに通信されて、バックエンドが共有秘密を算出することを可能にする。関係者２３１０は、２３５０で、［ｓｓ；Ｐａｒ⇔Ｂａｃｋ］を使用して暗号化する。それらは、［ｓｓ；Ｐａｒ⇔Ｂａｃｋ］に抽出および展開を行って、［ｋｅｙ；Ｐａｒ→Ｂａｃｋ］および［ｋｅｙ；Ｂａｃｋ→Ｐａｒ］にする。その鍵の［ｋｅｙ；Ｐａｒ→Ｂａｃｋ］を使用して、ＡＥＳ－ＧＣＭモードでＩを暗号化する。［ｋｅｙ；Ｂａｃｋ→Ｐａｒ］鍵は、バックエンドが情報を戻すときにバックエンドからの材料を解読するために使用される。ＡＥＳ－ＧＣＭモードのＩＶは、暗号化で使用するためにランダムに生成され、バックエンドによる解読で使用するために送信される。代替として、ＩＶ値は、好ましくは同じ鍵を使用して後続のメッセージを暗号化するために同じＩＶ値を使用しないことが保証される限り、抽出および展開を介して生成することもできる。［ｓｓ；Ｐａｒ⇔Ｂａｃｋ］、［ｋｅｙ；Ｐａｒ→Ｂａｃｋ］および一時的プライベート鍵ｒａｎｄ_Ｐは、破棄されるべきである。関係者２３１０は、２３６０で、自身のＥＣＤＳＡ署名生成プライベート鍵を使用して、Ｐａｃｋａｇｅ_{Ｐａｒ→Ｂａｃｋ}＝（Ｅｎｃ_{［ｋｅｙ；Ｐａｒ→Ｂａｃｋ］；ＩＶ}（Ｉ）；［ｐｋ；Ｐａｒ⇔Ｂａｃｋ］；ＩＶ）に署名して、Ｓｉｇ_{Ｐａｒ→Ｂａｃｋ}を生成する。関係者２３１０は、（Ｐａｃｋａｇｅ_{Ｐａｒ→Ｂａｃｋ}；Ｓｉｇ_{Ｐａｒ→Ｂａｃｋ}）を図２４のバックエンド２４１０に送る。

次いで図２４を参照すると、バックエンド２４１０は、２４２０で、Ｓｉｇ_{Ｐａｒ→Ｂａｃｋ}が有効な署名であることを検証する。バックエンド２４１０は、２４３０で、ワンパスＤｉｆｆｉｅ－Ｈｅｌｌｍａｎにおける受信者として動作する。最初に、それらは、ｒａｎｄ_ＰＧが楕円曲線上にあることを検査することにより、公開鍵の有効性確認を行わなければならない。バックエンド２４１０は次いで、ＲＳＳＤ［ｂ；ｒａｎｄ_ＰＧ；２］を実行して、ｒａｎｄ_ＰＢ＝ｒａｎｄ_Ｐｂ_１ｂ_２Ｇを回復し、これはワンパスＤｉｆｆｉｅ－Ｈｅｌｌｍａｎで使用するための共有秘密［ｓｓ；Ｐａｒ⇔Ｂａｃｋ］である。このアルゴリズムの間に検出可能なエラーが発生した場合は、このアルゴリズムを再度開始する。バックエンドおよびトランスレータにおける持続的なエラーが、選択された最大エラーを超えて発生するときには必ず、そのＴＯＫＥＮの処理が終了され、もう一度試すようにエラーメッセージが関係者に送られる。バックエンド２４１０は、２４４０で、［ｓｓ；Ｐａｒ⇔Ｂａｃｋ］を抽出および展開して［ｋｅｙ；Ｐａｒ→Ｂａｃｋ］、［ｋｅｙ；Ｂａｃｋ→Ｐａｒ］、［ｋｅｙ；Ｐａｒ→Ｂａｃｋ］_Ｈとし、ｍ_１、ｍ_２・ｍ_１、ｍ_２が、プライベート鍵ｂおよびｂｂの更新に使用される。この結果、ｂ_１、ｂ_２、ｂｂ_１、およびｂｂ_２が更新され、上述したバックエンド２４１０に関連付けられた秘密、特にＰｏｈｌｉｇ－Ｈｅｌｌｍａｎの集合的にアクセス可能な秘密ｂｂ_１ｂｂ_２ ｍｏｄ ｎ、への集合的なアクセスに影響を及ぼすことはない。［ｋｅｙ；Ｐａｒ→Ｂａｃｋ］_Ｈは、バックエンド２４１０内で内部ＨＭＡＣ鍵を更新するために使用される。両方のパーティションが、新しい内部ＨＭＡＣ鍵である、

を生成する。パーティション１は、ｂ_１ ^＊≡ｍ_１ ｂ_１ ｍｏｄ ｎおよびｂｂ_１ ^＊≡ｍ_２ｂｂ_１ ｍｏｄ ｎを算出する。パーティション２は、

および

を算出する。パーティション１およびパーティション２は、次のように、プライベート鍵のモジュロｎの積を不変に保つために、同時に（ソフト）更新する：パーティション１ － ｂ_１→ｂ_１ ^＊；ｂｂ_１→ｂｂ_１ ^＊、およびパーティション２ － ｂ_２→ｂ_２ ^＊；ｂｂ_２→ｂｂ_２ ^＊。バックエンド２４１０は、２４５０で、［ｋｅｙ；Ｐａｒ→Ｂａｃｋ］を使用して、Ｄｅｃ_{［ｋｅｙ；Ｐａｒ→Ｂａｃｋ］；ＩＶ}（Ｅｎｃ_{［ｋｅｙ；Ｐａｒ→Ｂａｃｋ］；ＩＶ}（Ｉ））を行うことにより解読して、Ｉを回復する。バックエンド２４１０は、２４６０で自身のＰｏｈｌｉｇ－Ｈｅｌｌｍａｎを行う。最初に、それらは、Ｉが楕円曲線上にあることを検査することにより、公開鍵の有効性確認を行わなければならない。バックエンド２４１０は次いで、ＲＳＳＤ［ｂｂ；Ｉ；２］を実行して、Ｉ^＊＝ｂｂ_１ｂｂ_２Ｉを生成する。このアルゴリズムの１回目のパスの間にエラーが発生した場合、これは、ＨＭＡＣタグが拒否されたためであることを意味し得る。これが当てはまる場合は、ソフト更新セクションで行われたすべての動作を元に戻し、再度Ｄｉｆｆｉｅ－Ｈｅｌｌｍａｎを行う。２回目のパスの間にエラーが発生した場合は、Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎを再度開始する（アルゴリズムのこの実行）。バックエンド２４１０は次いで、２４７０で鍵確認を実行する。これを行うために、それは、鍵確認およびＩＶ生成：ＫのためにＩ^＊からＨＭＡＣ鍵を抽出および展開しなければならない。バックエンド２４１０は、１回使用の鍵確認ＨＭＡＣ鍵である、ｈ－ｋｅｙ_ｃｏｎｆ＝ＨＭＡＣ_Ｋ（ｈ－ｋｅｙ_ｎｅｗ｜｜ｒ_１ｒ_２Ｉ｜｜０１）を生成し、ここで、ｒ_１ｒ_２Ｉは、Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎ、すなわちＲＳＳＤ「ｂｂ；Ｉ；２］のために使用されたＲＳＳＤプロセス中に交換されるｒ_２Ｉおよびｒ_１Ｉから算出可能であり（ｒ_１を使用してパーティション１により、およびｒ_２を使用してパーティション２により）。ＩＶ’＝ＨＭＡＣ_Ｋ（ｈ－ｋｅｙ_ｎｅｗ｜｜ｒ_１ｒ_２Ｉ｜｜１０）を生成する。ＩＶ’を所望ビット数に切り捨てて、使用される実際のＩＶを形成する。バックエンド２４１０におけるパーティションは、上記からの前回の成功したＤｉｆｆｉｅ－Ｈｅｌｌｍａｎおよび前回の成功したＰｏｈｌｉｇ－Ｈｅｌｌｍａｎのトランスクリプトに対して鍵確認手順を実行する。鍵確認が拒否された場合は、Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎアルゴリズムを再度開始する。これが確認されたら、２４４０のソフト更新をハード変更にする。バックエンド２４１０は次いで、２４８０で、鍵の［ｋｅｙ；Ｂａｃｋ→Ｐａｒ］および新しく生成されたＩＶを使用して、ＡＥＳ－ＧＣＭで（Ｉ^＊）を暗号化する。バックエンド２４１０は、Ｐａｃｋａｇｅ_{Ｂａｃｋ→Ｐａｒ}＝（Ｅｎｃ_{［ｋｅｙ；Ｂａｃｋ→Ｐａｒ］；ＩＶ}（Ｉ^＊）；ＩＶ）を図２５の関係者２５１０に送る。

次いで図２５を参照すると、関係者２５１０は、２５２０で、［ｋｅｙ；Ｂａｃｋ→Ｐａｒ］を使用して、関連付けられたＩＶおよび認証タグを解読する。Ｄｅｃ_{［ｋｅｙ；ｂａｃｋ→Ｐａｒ］；ＩＶ}（Ｅｎｃ_{［ｋｅｙ；Ｂａｃｋ→Ｐａｒ］；ＩＶ}（Ｉ^＊））を行って、Ｉ^＊を回復する。関係者２５１０は、２５３０で自身のＰｏｈｌｉｇ－Ｈｅｌｌｍａｎを行う。最初に、それらは、Ｉ^＊が楕円曲線上にあることを検査することにより、公開鍵の有効性確認を行わなければならない。関係者２５１０は次いで、Ｉ^＊＊＝ｌ^－１Ｉ^＊＝ｌ^－１ｂｂ_１ｂｂ_２ｌＰ＝ｂｂ_１ｂｂ_２Ｐを算出する。これがＰｏｈｌｉｇ－Ｈｅｌｌｍａｎ解読プロセスである。この結果は、トランスレータに対して暗号化される。関係者２５１０は、２５４０でワンパスＤｉｆｆｉｅ－Ｈｅｌｌｍａｎにおけるイニシエータとして動作する。最初に、それらは、ワンパスＤｉｆｆｉｅ－Ｈｅｌｌｍａｎの算出のために次のステップで使用される一時的プライベート鍵用のランダムな整数ｒａｎｄ_Ｐを［１，ｎ－１］内で生成する。関係者２５１０は次いで、トランスレータのＤｉｆｆｉｅ－Ｈｅｌｌｍａｎ公開鍵Ｔにｒａｎｄ_Ｐを乗算して、ｒａｎｄ_ＰＴ＝ｒａｎｄ_Ｐｔ_１ｔ_２Ｇを生成し、これが、ワンパスＤｉｆｆｉｅ－Ｈｅｌｌｍａｎの共有秘密［ｓｓ；Ｐａｒ⇔Ｔｒａｎｓ］となる。関係者２５１０は次いで、Ｇにｒａｎｄ_Ｐを乗算して、ｒａｎｄ_ＰＧを生成し、これが、ワンパスＤｉｆｆｉｅ－Ｈｅｌｌｍａｎに使用される公開鍵［ｐｋ；Ｐａｒ⇔Ｔｒａｎｓ］となる。これはトランスレータに通信されて、トランスレータが共有秘密を算出することを可能にする。関係者２５１０は、２５５０で、［ｓｓ；Ｐａｒ⇔Ｔｒａｎｓ］を使用して暗号化する。それらは、［ｓｓ；Ｐａｒ⇔Ｔｒａｎｓ］に抽出および展開を行って、［ｋｅｙ；Ｐａｒ→Ｔｒａｎｓ］および［ｋｅｙ；Ｔｒａｎｓ→Ｐａｒ］にする。その鍵の［ｋｅｙ；Ｐａｒ→Ｔｒａｎｓ］を使用して、ＡＥＳ－ＧＣＭモードでＩ^＊＊を暗号化する。［ｋｅｙ；Ｂａｃｋ→Ｐａｒ］鍵は、トランスレータが情報を戻すときトランスレータからの材料を解読するために使用される。ＡＥＳ－ＧＣＭモードのＩＶは、暗号化で使用するためにランダムに生成され、トランスレータによる解読で使用するために送信される。ｐｒｅ－ＴＯＫＥＮ＝（Ｅｎｃ_{［ｋｅｙ；Ｐａｒ→Ｔｒａｎｓ］；ＩＶ}（Ｉ^＊＊）；［ｐｋ；Ｐａｒ⇔Ｔｒａｎｓ］；ＩＶ）を、Ｅｎｃ＿ＴＯＫＥＮが更新される必要があるときに必ず使用するために、関係者データベースに記憶する。［ｓｓ；Ｐａｒ⇔Ｔｒａｎｓ］、［ｋｅｙ；Ｐａｒ→Ｔｒａｎｓ］、および一時的プライベート鍵ｒａｎｄ_Ｐは、破棄されるべきである（関係者の不変の中間ＴＯＫＥＮ値Ｉ^＊＊のローカルでの露出を可能にしないために）。関係者２５１０は、２５６０で、自身のＥＣＤＳＡ署名生成プライベート鍵を使用して、Ｐａｃｋａｇｅ_{Ｐａｒ→Ｔｒａｎｓ}＝Ｅｎｃ_{［ｋｅｙ；Ｐａｒ→Ｔｒａｎｓ］；ＩＶ}（Ｉ^＊＊）；［ｐｋ；Ｐａｒ⇔Ｔｒａｎｓ］；ＩＶ）に署名して、Ｓｉｇ_{Ｐａｒ→Ｔｒａｎｓ}を生成する。関係者２５１０は、（Ｐａｃｋａｇｅ_{Ｐａｒ→Ｔｒａｎｓ}；Ｓｉｇ_{Ｐａｒ→Ｔｒａｎｓ}）を、図２６のトランスレータ２６０５に送る。

次いで図２６を参照すると、トランスレータ２６０５は、２６１０で、Ｓｉｇ_{Ｐａｒ→Ｔｒａｎｓ}が有効な署名であることを検証する。トランスレータ２６０５は、２６１５で、ワンパスＤｉｆｆｉｅ－Ｈｅｌｌｍａｎにおける受信者として動作する。最初に、それらは、ｒａｎｄ_ＰＧが楕円曲線上にあることを検査することにより、公開鍵の有効性確認を行う。トランスレータ２６０５は次いで、ＲＳＳＤ［ｔ；ｒａｎｄ_ＰＧ；２］を実行して、ｒａｎｄ_ＰＴ＝ｒａｎｄ_Ｐｔ_１ｔ_２Ｇを回復し、これはワンパスＤｉｆｆｉｅ－Ｈｅｌｌｍａｎで使用するための共有秘密ｓｓ；Ｐａｒ⇔Ｔｒａｎｓ］である。このアルゴリズムの間に検出可能なエラーが発生した場合は、このアルゴリズムを再度開始する。バックエンドおよびトランスレータにおける持続的なエラーが、選択された最大エラーを超えて発生するときには必ず、そのＴＯＫＥＮの処理が終了され、もう一度試すようにエラーメッセージが関係者に送られる。トランスレータ２６０５は、２６２０で、［ｓｓ；Ｐａｒ⇔Ｔｒａｎｓ］を抽出および展開して、［ｋｅｙ；Ｐａｒ→Ｔｒａｎｓ］、［ｋｅｙ；Ｔｒａｎｓ→Ｐａｒ］、［ｋｅｙ；Ｐａｒ→Ｔｒａｎｓ］_Ｈとし、ｍ_１、ｍ_２・ｍ_１、およびｍ_２が、プライベート鍵ｔおよびｔｔの更新に使用される。［ｋｅｙ；Ｐａｒ→Ｔｒａｎｓ］_Ｈは、トランスレータ２６０５内で内部ＨＭＡＣ鍵を更新するために使用される。両方のパーティションが、新しい内部ＨＭＡＣ鍵である、

を生成する。パーティション１は、ｔ_１ ^＊≡ｍ_１ｔ_１ ｍｏｄ ｎおよびｔｔ_１ ^＊≡ｍ_２ｔｔ_１ ｍｏｄ ｎを算出する。パーティション２は、

および

を算出する。パーティション１およびパーティション２は、次のように、プライベート鍵のモジュロｎの積を不変に保つために、同時に（ソフト）更新する：パーティション１ － ｔ_１→ｔ_１ ^＊；ｔｔ_１→ｔｔ_１ ^＊、およびパーティション２ －ｔ_２→ｔ_２ ^＊；ｔｔ_２→ｔｔ_２ ^＊。トランスレータ２６０５は、２６２５で、［ｋｅｙ；Ｐａｒ→Ｔｒａｎｓ］を使用して、Ｄｅｃ_{［ｋｅｙ；Ｐａｒ→Ｔｒａｎｓ］；ＩＶ}（Ｅｎｃ_{［ｋｅｙ；Ｐａｒ→Ｔｒａｎｓ］；ＩＶ}（Ｉ^＊＊））を行うことにより解読して、Ｉ^＊＊を回復する。トランスレータ２６０５は、２６３０で、自身のＰｏｈｌｉｇ－Ｈｅｌｌｍａｎを行う。最初に、それらは、Ｉ^＊が楕円曲線上にあることを検査することにより、公開鍵の有効性確認を行わなければならない。トランスレータ２６０５は次いで、ＲＳＳＤ［ｔｔ；Ｉ^＊＊；２］を実行して、Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎ暗号文である、ｔｔ_１ｔｔ_２Ｉ^＊＊＝ｔｔ_１ｔｔ_２ｂｂ_１ｂｂ_２Ｐを生成する。このアルゴリズムの１回目のパスの間にエラーが発生した場合、これは、ＨＭＡＣタグが拒否されたためであることを意味し得る。これが当てはまる場合は、ソフト更新セクションで行われたすべての動作を元に戻し、再度Ｄｉｆｆｉｅ－Ｈｅｌｌｍａｎを行う。２回目のパスの間にエラーが発生した場合は、Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎを再度開始する（アルゴリズムのこの実行）。トランスレータ２６０５は次いで、２６３５で、鍵確認を実行する。これを行うために、それは、鍵確認およびＩＶ生成：Ｋのために、ｔｔ_１ｔｔ_２ｂｂ_１ｂｂ_２ＰからＨＭＡＣ鍵を抽出および展開しなければならない。トランスレータ２６０５は、１回使用の鍵確認ＨＭＡＣ鍵である、ｈ－ｋｅｙ_ｃｏｎｆ＝ＨＭＡＣ_Ｋ（ｈ－ｋｅｙ_ｎｅｗ｜｜ｒ_１ｒ_２Ｉ^＊＊｜｜０１）を生成し、ここで、ｒ_１ｒ_２Ｉ^＊＊は、Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎに使用されるＲＳＳＤプロセスから算出可能である。ＩＶ_１’＝ＨＭＡＣ_Ｋ（ｈ－ｋｅｙ_ｎｅｗ｜｜ｒ_１ｒ_２Ｉ^＊＊｜｜１０）を生成する。ＩＶ_１’を所望ビット数に切り捨てて、使用される実際のＩＶ_１を形成する。ＩＶ_２’＝ＨＭＡＣ_Ｋ（ｈ－ｋｅｙ_ｎｅｗ｜｜ｒ_１ｒ_２Ｉ^＊＊｜｜１１）を生成する。ＩＶ_２’を所望ビット数に切り捨てて、使用される実際のＩＶ_２を形成する。トランスレータ２６０５のパーティションは、上記からの前回の成功したＤｉｆｆｉｅ－Ｈｅｌｌｍａｎおよび前回の成功したＰｏｈｌｉｇ－Ｈｅｌｌｍａｎのトランスクリプトに対して鍵確認手順を実行する。鍵確認が拒否された場合は、Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎアルゴリズムを再度開始する。これが確認されたら、２６２０のソフト更新をハード変更にする。最後に、トランスレータ２６０５は、２６４０でハッシュを行い、ここで、ハッシュ関数は、楕円曲線点から導出されたビット列に適用される：ＴＯＫＥＮ＝Ｈａｓｈ（ｔｔ_１ｔｔ_２ｂｂ_１ｂｂ_２Ｐ）。トランスレータ２６０５は、２６４５で、コーディネータＣとの間で共有される対称鍵を使用して、かつＩＶ_１を使用して、ＡＥＳ－ＧＣＭモードでＴＯＫＥＮを暗号化する：

。Ｃは、好ましくは少なくとも２^３２回使用されるたびに変更されることに留意されたい。トランスレータ２６０５は次いで、２６５０で、［ｋｅｙ；Ｔｒａｎｓ→Ｐａｒ］およびＩＶ_２を使用して、ＡＥＳ－ＧＣＭでＥｎｃ＿ＴＯＫＥＮを暗号化する：

。これが関係者に送られる。関係者は、解読を行ってＥｎｃ＿ＴＯＫＥＮを回復する。これは、関係者のデータベースに記憶され、コーディネータがトランザクションまたは要求内でＴＯＫＥＮを要することを望む場合には必ず、コーディネートネットワーク要素としてのコーディネータにサブミットされる。Ｅｎｃ＿ＴＯＫＥＮに関して、先に述べられた図に関して：図１３の１３４５に描かれるように、関係者が、トランスレータからＥｎｃ＿ＴＯＫＥＮ（ＥＣＤＨ共有秘密の抽出および展開から対称鍵を使用して暗号化されている）を受信し、Ｅｎｃ＿ＴＯＫＥＮは、それぞれ図５の５１５および図７の７１５におけるｇ（ＴＯＫＥＮ）に対応する。

ＴＯＫＥＮを求めるバッチ化された要求を行う関係者に関して、図２３、図２４、図２５、および図２６に描かれた手順を以下のように行うことができる。

関係者が、各ＩＮＦＯを表す点を作成するために処理したいＩＮＦＯごとに図２３の２３２０を通過する。関係者は、図２３の２３３０のように、毎回ランダムに選択される同じｌを使用して、あらゆる点Ｐに自身のＰｏｈｌｉｇ－Ｈｅｌｌｍａｎ暗号を行う。関係者は、図２３の２３４０、２３５０、２３６０に概説されるプロセスを通過する。１つのＤｉｆｆｉｅ－Ｈｅｌｌｍａｎ共有秘密が作成され、Ｉのバッチ全体を共に暗号化するために使用される。暗号化されたバッチは、署名され、バックエンドに送られる。バックエンドは、図２４の２４２０、２４３０、２４４０、２４５０に概説されるプロセスを通過する。解読されたバッチは、Ｉのリストである。バックエンドは、図２４の２４６０に概説されるように、すべてのＩに対して公開鍵の有効性確認を通過する。バックエンドは、Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎプロセスに進む。バッチ化する際、図２４の２４６０におけるＰｏｈｌｉｇ－ＨｅｌｌｍａｎのためのＲＳＳＤは、以下のように実行される。（１）各パーティションにおいてランダムに選択されたｒ_ｉが、ＲＳＳＤの実行全体にわたって使用される。（２）各パス中にバッチ全体が通過され、対応するパーティションにまとめて送られる。（３）結果：所与のＩごとに、生成されたＩ^＊がある。図２４の２４７０に概説される鍵確認は、Ｉ^＊のリスト全体に対して行われる。バックエンドは、図２４の２４８０に概説されるように、共有秘密から導出された暗号鍵でバッチを暗号化する。関係者は、図２５の２５２０のようにバッチを解読する。関係者は、自身の公開鍵有効性確認およびＰｏｈｌｉｇ－Ｈｅｌｌｍａｎ暗号の解読を図２５の２５３０のように、バッチ中のすべてのＩ^＊に行う（同じｌ^－１を使用して）。関係者は、図２５の２５４０、２５５０、２５６０に概説されたプロセスを通過する。１つのＤｉｆｆｉｅ－Ｈｅｌｌｍａｎ共有秘密が作成され、Ｉ^＊＊のバッチ全体を共に暗号化するために使用される。暗号化されたバッチは、署名され、トランスレータに送られる。この暗号化されたバッチは、図２５の２５５０で、単一のｐｒｅ－ＴＯＫＥＮが記憶されるように関係者データベースに記憶されることはない。トランスレータは、図２６の２６１０、２６１５、２６２０、２６２５に概説されるプロセスを通過する。解読されたバッチは、Ｉ^＊＊のリストである。トランスレータは、図２６の２６３０に概説されるように、すべてのＩ^＊＊について公開鍵の有効性確認を通過する。トランスレータは、Ｐｏｈｌｉｇ－Ｈｅｌｌｍａｎプロセスに進む。バッチ化する際、Ｐｏｈｌｉｇ－ＨｅｌｌｍａｎのためのＲＳＳＤは、以下のように実行される。（１）各パーティションにおいてランダムに選択されたｒ_ｉが、ＲＳＳＤの実行全体にわたって使用される。（２）各パス中にバッチ全体が通過され、まとめて対応するパーティションに送られる。（３）結果：所与のＩ^＊＊ごとに、非ハッシュ化されたＴＯＫＥＮが生成されている。図２６の２６３５に概説される鍵確認は、非ハッシュ化されたＴＯＫＥＮのリスト全体に対して行われる。トランスレータは、すべてのＴＯＫＥＮを異なるＩＶで暗号化するのに十分なＩＶ_１を図２６の２６３５のように生成する。単一のＴＯＫＥＮの事例で使用されるＩＶ_１の末尾に連結されたビットは、処理されるＴＯＫＥＮの数に対処するために延長される必要がある。このビットフィールドに挿入される値は、すべてのＩＶ_１ならびに鍵確認ＨＭＡＣ鍵およびＩＶ_２について別個でなければならない。トランスレータは、非ハッシュ化されたＴＯＫＥＮごとに、図２６のそれぞれ２６４０および２６４５のようにＴＯＫＥＮおよびＥｎｃ＿ＴＯＫＥＮを作成する。トランスレータは、図２６の２６５０に概説されるように、共有秘密を用いて関係者のためのバッチを暗号化する。関係者は、バッチを解読し、Ｅｎｃ＿ＴＯＫＥＮを自身のデータベースに記憶する。データベース中のＥｎｃ＿ＴＯＫＥＮのリストは、それらが獲得された順序を隠蔽するためにスクランブル処理され得る。関係者からのトランザクション処理要求に対するコーディネータ応答が認証タグの失敗を示す場合、関係者は、関連付けられたＩＮＦＯを個別に再処理するか、またはそれを将来のバッチ要求に組み込むかのいずれかを行い得ることに留意されたい。この選択は、シナリオに固有の実装戦略によって制約されることがある。そのような認証タグの失敗は、トランスレータとコーディネータとの間で共有される対称暗号鍵の更新に起因することがある。

より具体的に、バッチ化される事例におけるバックエンドのパーティション１での鍵確認に関する例として、Ｉ^＊のセットを使用して抽出および展開を使用して、鍵確認鍵および初期化ベクトル値を導出するためにｒ_１ｒ_２Ｉ楕円曲線点値の和と共に使用される鍵を生成する。パーティション１は、最初に、Ｐｏｈｌｉｇ－ＨｅｌｌｍａｎのＲＳＳＤプロセスの実行中にパーティション２から受信するｒ_２Ｉ楕円曲線点値の和を算出し、次いで自分自身のｒ_１値を使用することによってその中間和にスカラー乗算を適用することにより、この和を構築することができることに留意されたい。パーティション２も同様の動作を行う。

エンティティ認証およびプロセッサ内（パーティション間）の通信パスのデータ完全性に対処するための代替の機構に関して：

以下の方法は、非対称デジタル署名の生成および検証に依拠し、よって、ＨＭＡＣの対称的な使用よりも高い処理コストを有する。しかし、危殆化されたパーティションが他方のパーティションとして署名するのに必要とされる鍵にアクセスできないことから、１つのプロセッサペア中の一方のパーティションの危殆化が、他方のパーティションに上手くなりすますのに必要な情報を漏洩させないという利点を提供する。２つのパーティション間で確立された共有秘密に対する抽出および展開を通じて初期ＨＭＡＣ鍵が生成される方式と同様に、そのような抽出および展開を使用して、追加的にまたは代わりに、パーティション１により使用される初期ｐｒｉｖ_１署名生成プライベート鍵およびパーティション２により使用される初期ｐｒｉｖ_２鍵を生成することができる。パーティション１は、ｐｒｉｖ_２に対応する公開鍵ｐｒｉｖ_２Ｇ（すなわちｐｕｂ_２）を生成し、パーティション２は、ｐｒｉｖ_１Ｇ＝ｐｕｂ_１を生成する。ＥＣＤＳＡなどのデジタル署名方式の使用下で、ｐｒｉｖ_１、ｐｒｉｖ_２、ｐｕｂ_１およびｐｕｂ_２の更新は以下のように行われる：算出された共有秘密（関係者を発信元とする共有秘密から導出されるものなど）の抽出および展開の結果、ｍｏｄｉｆｉｅｒ_１およびｍｏｄｉｆｉｅｒ_２が得られる。そして、ｐｒｉｖ_１ｎｅｗ＝ｍｏｄｉｆｉｅｒ_１＊ｐｒｉｖ_{１ｃｕｒｒｅｎｔ} ｍｏｄ ｎ、およびｐｕｂ_１ｎｅｗ＝ｍｏｄｉｆｉｅｒ_１＊ｐｕｂ_{１ｃｕｒｒｅｎｔ}となる（またｐｒｉｖ_２ｎｅｗおよびｐｕｂ_２ｎｅｗについても同様）。この方法の例示的な１つのインスタンス化は、前と同様にプロセッサ内通信のためにＨＭＡＣを使用し続けるものであるが、鍵確認の構築を、それぞれ

および

によって置き換えるものであることに留意されたい。この鍵確認の策定は、例えばパーティション１を秘密裡に危殆化し、よってパーティション１のランダムビットジェネレータＲＢＧ１の完全な状態を知った敵対者にとって、後続のｒ_１ｒ_２Ｑが入手不可能であることへの依存性を持たない（少なくとも、ＲＢＧ１が、パーティション１を「退出」した後には敵対者にとって入手不可能なライブエントロピーソースを有効利用するまで）。

当業者は、本発明の範囲から逸脱することなく、様々な変更、改変、および組み合わせが上記で説明された実施形態に関してなされ得、そのような変更、改変、および組み合わせは、本発明の概念の範囲内にあるとみなされるべきであることを認識するであろう。

Claims (20)

1. ネットワークを介してデータに基づく行為を実施するための方法であって、
   プロトコルを管理するコーディネートネットワーク要素により、
   － アテスターの役割内で動作しているネットワーク要素、および
   － リクエスターの役割内で動作している少なくとも１つの２次ネットワーク要素、
   の１つを含む要求元ネットワーク要素から、
   前記ネットワークを介して、
   － 参照されるデータ内容、
   － 参照されるデータタイプ、
   － 参照される初期データソース、および
   － 初期データソースに関連付けられたデータ情報、
   の少なくとも１つを含むデータ情報に関する、プロトコルに準拠した要求を受信するステップであって、
   前記プロトコルは、前記コーディネートネットワーク要素が、前記プロトコルに準拠した要求の基礎を少なくとも部分的になすデータ内容に実質的にアクセスすることを阻止する、ステップと、
   前記要求元ネットワーク要素が前記アテスターの役割内で動作しているネットワーク要素である場合、前記要求元ネットワーク要素を介して調達されるデータを、データに基づく処理のために非同期に入手可能にする権限を、前記要求元ネットワーク要素に付与することを、少なくとも部分的には前記プロトコルを介して容易にするステップであって、前記データが間接的なデータとして調達される場合、前記調達することは、初期データソースから前記要求元ネットワーク要素によって受信されたデータからの導出を伴い、前記２次ネットワーク要素の身元は前記要求元ネットワーク要素からブラインドされる、ステップと、
   前記要求元ネットワーク要素が前記リクエスターの役割内で動作している２次ネットワーク要素である場合、以前に別の要求元ネットワーク要素から調達されたデータを処理するための前記２次ネットワーク要素の権限付与を、少なくとも部分的には前記プロトコルを介して容易にするステップであって、前記別の要求元ネットワーク要素の身元は前記２次ネットワーク要素からブラインドされる、ステップと、を含む方法。
2. 前記データに基づく処理が、
   証明済みのデータ内容の移動、および
   以前に証明済みのデータ内容に対するデータ内容の確証、
   のうち少なくとも１つを含む、請求項１に記載の方法。
3. 以前に証明済みのデータ内容に対するデータ内容の前記確証が、前記リクエスターの役割内で動作している要求元ネットワーク要素からデータを調達することを少なくとも部分的に含み、前記データが間接的なデータとして調達される場合、前記調達することが、初期データソースから前記要求元ネットワーク要素によって受信されたデータからの導出を伴う、請求項２に記載の方法。
4. 前記プロトコルに準拠した要求が、複数の別個のメッセージを含む、請求項１に記載の方法。
5. 前記権限を付与することは、前記アテスターの役割内で動作している前記要求元ネットワーク要素が、中継者からアクセス可能なストレージに内容を記憶する権限を付与されることを中継者に通知する、検証可能な許可を生成することを少なくとも部分的に含み、前記内容は、データの移動および確証のうち少なくとも一方を可能にするために有用である、暗号パラメータ、データ、およびメタデータ、の少なくとも１つを含む、請求項１に記載の方法。
6. 前記中継者からアクセス可能なストレージに前記内容を記憶することが、前記内容の一部を、
   平文形態、および
   暗号化された形態、
   の少なくとも一方で記憶することを含む、請求項５に記載の方法。
7. 前記内容は、
   前記アテスターの役割内で動作している前記要求元ネットワーク要素によって生成された暗号文および暗号パラメータのうち少なくとも１つを表す解読トークン、ならびに
   比較トークンを構成するためにデータと共に適用される暗号パラメータおよびメタデータであって、前記比較トークンは、前記アテスターの役割内で動作している前記要求元ネットワーク要素によって与えられたデータの処理の結果を表す比較トークンに対して、記憶された値を使用して処理された候補データを表す比較トークンの一致があるかどうかに関する判定を行うことができるように構成される、暗号パラメータおよびメタデータの少なくとも１つ、
   のうち少なくとも一方として働くように構成された前記記憶された値を含む、請求項５に記載の方法。
8. 前記内容が、シェアの群であって、閾値数のそのようなシェアが前記内容の再構成を可能にするようなシェアの群を含み、前記シェアは、前記アテスターの役割内で動作している前記要求元ネットワーク要素によって複数の中継者に分散される、請求項５に記載の方法。
9. 前記権限付与は、前記リクエスターの役割内で動作している前記要求元ネットワーク要素が、中継者からアクセス可能なストレージから、暗号パラメータ、データ、およびメタデータのうち少なくとも１つを含む内容を、平文形態または暗号化された形態で取り出す権限を付与されることを少なくとも１つの中継者に通知する、検証可能な許可の生成を少なくとも部分的に含む、請求項１に記載の方法。
10. 前記コーディネートネットワーク要素が、前記プロトコルに準拠した要求の中にトークン化された形態で含まれているデータ情報にアクセスすることが実質的にできず、前記トークンは、少なくともそのうち１つが前記コーディネートネットワーク要素には入手不可能である秘密を使用して生成される、請求項１に記載の方法。
11. ネットワークを介してデータに基づく行為を実施するように構成された装置であって、
    ネットワークインターフェースと、
    コーディネートネットワーク要素として構成された制御回路と、を備え、前記コーディネートネットワーク要素は、
    前記ネットワークインターフェースを介して、
    － アテスターの役割内で動作しているネットワーク要素、および
    － リクエスターの役割内で動作している少なくとも１つの２次ネットワーク要素、
    の１つを含む要求元ネットワーク要素から、
    － 参照されるデータ内容、
    － 参照されるデータタイプ、
    － 参照される初期データソース、および
    － 初期データソースに関連付けられたデータ情報、
    の少なくとも１つを含むデータ情報に関する、プロトコルに準拠した要求を受信することであって、
    前記プロトコルは、前記コーディネートネットワーク要素が、前記プロトコルに準拠した要求の基礎を少なくとも部分的になすデータ内容に実質的にアクセスすることを阻止する、ことと、
    前記要求元ネットワーク要素が前記アテスターの役割内で動作しているネットワーク要素である場合、前記要求元ネットワーク要素を介して調達されるデータを、データに基づく処理のために非同期に入手可能にする権限を前記要求元ネットワーク要素に付与することを、少なくとも部分的には前記プロトコルを介して容易にすることであって、前記データが間接的なデータとして調達される場合、前記調達することは、初期データソースから前記要求元ネットワーク要素によって受信されたデータからの導出を伴い、前記２次ネットワーク要素の身元は前記要求元ネットワーク要素からブラインドされる、ことと、
    前記要求元ネットワーク要素が前記リクエスターの役割内で動作している２次ネットワーク要素である場合、以前に別の要求元ネットワーク要素から調達されたデータを処理するための前記２次ネットワーク要素の権限付与を、少なくとも部分的には前記プロトコルを介して容易にすることであって、前記別の要求元ネットワーク要素の身元は前記２次ネットワーク要素からブラインドされる、ことと、
    によって前記プロトコルを管理する、装置。
12. 前記データに基づく処理が、
    証明済みのデータ内容の移動、および
    以前に証明済みのデータ内容に対するデータ内容の確証、
    のうち少なくとも１つを含む、請求項１１に記載の装置。
13. 以前に証明済みのデータ内容に対するデータ内容の前記確証が、前記リクエスターの役割内で動作している要求元ネットワーク要素からデータを調達することを少なくとも部分的に含み、前記データが間接的なデータとして調達される場合、前記調達することが、初期データソースから前記要求元ネットワーク要素によって受信されたデータからの導出を伴う、請求項１２に記載の装置。
14. 前記プロトコルに準拠した要求が、複数の別個のメッセージを含む、請求項１１に記載の装置。
15. 前記権限を付与することは、前記アテスターの役割内で動作している前記要求元ネットワーク要素が、中継者からアクセス可能なストレージに内容を記憶する権限を付与されることを中継者に通知する、検証可能な許可を生成することを少なくとも部分的に含み、前記内容は、データの移動および確証のうち少なくとも一方を可能にするために有用である、暗号パラメータ、データ、およびメタデータ、の少なくとも１つを含む、請求項１１に記載の装置。
16. 前記中継者からアクセス可能なストレージに前記内容を記憶することが、前記内容の一部を、
    平文形態、および
    暗号化された形態、
    の少なくとも一方で記憶することを含む、請求項１５に記載の装置。
17. 前記内容は、
    前記アテスターの役割内で動作している前記要求元ネットワーク要素によって生成された暗号文および暗号パラメータのうち少なくとも１つを表す解読トークン、ならびに
    比較トークンを構成するためにデータと共に適用される暗号パラメータおよびメタデータであって、前記比較トークンは、前記アテスターの役割内で動作している前記要求元ネットワーク要素によって与えられたデータの処理の結果を表す比較トークンに対して、記憶された値を使用して処理された候補データを表す比較トークンの一致があるかどうかに関する判定を行うことができるように構成される、暗号パラメータおよびメタデータの少なくとも１つ、
    のうち少なくとも一方として働くように構成された前記記憶された値を含む、請求項１５に記載の装置。
18. 前記内容が、シェアの群であって、閾値数のそのようなシェアが前記内容の再構成を可能にするようなシェアの群を含み、前記シェアは、前記アテスターの役割内で動作している前記要求元ネットワーク要素によって複数の中継者に分散される、請求項１５に記載の装置。
19. 前記権限付与は、前記リクエスターの役割内で動作している前記要求元ネットワーク要素が、中継者からアクセス可能なストレージから、暗号パラメータ、データ、およびメタデータのうち少なくとも１つを含む内容を、平文形態または暗号化された形態で取り出す権限を付与されることを少なくとも１つの中継者に通知する、検証可能な許可の生成を少なくとも部分的に含む、請求項１１に記載の装置。
20. 前記コーディネートネットワーク要素が、前記プロトコルに準拠した要求の中にトークン化された形態で含まれているデータ情報にアクセスすることが実質的にできず、前記トークンは、少なくともそのうち１つが前記コーディネートネットワーク要素には入手不可能である秘密を使用して生成される、請求項１１に記載の装置。
    

Images