IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ プリビター リミテッドの特許一覧

特表2024-535885トークン化されたデータにデジタルウォーターマークを埋め込むためのプロセス
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-10-02
(54)【発明の名称】トークン化されたデータにデジタルウォーターマークを埋め込むためのプロセス
(51)【国際特許分類】
   G06F 21/16 20130101AFI20240925BHJP
【FI】
G06F21/16
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2024517449
(86)(22)【出願日】2022-09-22
(85)【翻訳文提出日】2024-03-18
(86)【国際出願番号】 GB2022052401
(87)【国際公開番号】W WO2023047114
(87)【国際公開日】2023-03-30
(31)【優先権主張番号】2113485.3
(32)【優先日】2021-09-22
(33)【優先権主張国・地域又は機関】GB
(81)【指定国・地域】
(71)【出願人】
【識別番号】524103807
【氏名又は名称】プリビター リミテッド
(74)【代理人】
【識別番号】100123858
【弁理士】
【氏名又は名称】磯田 志郎
(72)【発明者】
【氏名】メラー,ポール
(72)【発明者】
【氏名】ムラコンダ,サシ クマール
(57)【要約】
トークン化されたデータ内にデジタルウォーターマークを埋め込むためのコンピュータ実装プロセス。コンピュータ実装プロセスは、入力データセットからトークンを生成するステップであって、トークンが決定論的暗号化スキームを使用して生成される、生成するステップと、生成されたトークンセット内にデジタルウォーターマークを埋め込むステップと、を含む。
【選択図】図4
【特許請求の範囲】
【請求項1】
トークン化されたデータ内にデジタルウォーターマークを埋め込むためのコンピュータ実装プロセスであって、前記プロセスが、
(a)入力データセットからトークンを生成するステップであって、トークンが決定論的暗号化スキームを使用して生成される、生成するステップと、
(b)生成されたトークンセット内に前記デジタルウォーターマークを埋め込むステップと、を含む、プロセス。
【請求項2】
前記デジタルウォーターマークが、前記生成されたトークンセット内のトークンの選択を通して確率的に埋め込まれるパターンを含む、請求項1に記載のプロセス。
【請求項3】
前記デジタルウォーターマークが、前記暗号化スキーム、又は前記入力データセット上で使用される任意の他の処理の事前知識なしで再構築され得る、請求項1又は2に記載のプロセス。
【請求項4】
前記デジタルウォーターマークが、前記生成されたトークンセットに埋め込まれ、任意のメタデータ又は冗長データには埋め込まれない、先行請求項のいずれか一項に記載のプロセス。
【請求項5】
前記決定論的暗号化スキームが、フォーマット保持暗号化サイファーに基づく擬似ランダム置換スキームなどの、擬似ランダム置換スキームである、先行請求項のいずれか一項に記載のプロセス。
【請求項6】
前記プロセスが、
(a)前記入力データセットに対応する入力空間を走査又は観察するステップと、
(b)ウォーターマークトークンにマッピングされるべき前記入力を決定又は識別するステップと、を含む、先行請求項のいずれか一項に記載のプロセス。
【請求項7】
ウォーターマークトークンにマッピングされるべき前記入力が、前記入力空間及び前記入力空間が表すものの知識から推測される、請求項6に記載のプロセス。
【請求項8】
ウォーターマークトークンにマッピングされるべき前記入力が、出現又は遭遇する可能性が低い前記入力である、請求項6又は7に記載のプロセス。
【請求項9】
前記プロセスが、入力空間を「非ウォーターマーク入力部分空間」及び「ウォーターマーク入力部分空間」という2つの互いに素な部分空間に分割するステップを含み、前記非ウォーターマーク入力部分空間の前記入力が、非ウォーターマークトークンにマッピングされ、前記ウォーターマーク入力部分空間の前記入力が、ウォーターマークトークンにマッピングされる、先行請求項のいずれか一項に記載のプロセス。
【請求項10】
各入力部分空間の前記暗号化が、独立して達成される、請求項9に記載のプロセス。
【請求項11】
アルゴリズムが、FPE(フォーマット保持暗号化)などの2つの決定論的暗号化スキームを含む、先行請求項のいずれか一項に記載のプロセス。
【請求項12】
FPEが、前記非ウォーターマーク入力部分空間を暗号化するように構成されており、別のFPEが、前記ウォーターマーク入力部分空間を暗号化するように構成されている、請求項9~11のいずれか一項に記載のプロセス。
【請求項13】
前記2つの決定論的暗号化スキームが、各々、秘密鍵に基づく、請求項9~12のいずれか一項に記載のプロセス。
【請求項14】
前記デジタルウォーターマークパターンが、ウォーターマークトークン内に埋め込まれ、前記ウォーターマークトークンは、それらのトークンがハッシュ空間の所定の範囲内に収まる値にハッシュするように割り当てられるか、又は決定される、先行請求項のいずれか一項に記載のプロセス。
【請求項15】
前記トークンのハッシュが、秘密ウォーターマーキング鍵に基づいた暗号学的ハッシュ関数を使用して行われるため、攻撃者は、トークンがどの部分空間内に存在するかを学習することができない、請求項14に記載のプロセス。
【請求項16】
前記プロセスが、前記ハッシュ空間のビンが値を含まないか、又はゼロに近い値を含むように、前記ウォーターマークトークンが決して又はめったに返されないように、前記ウォーターマークトークンをマッピングするように試みるステップを含む、請求項6~15のいずれか一項に記載のプロセス。
【請求項17】
前記ウォーターマークトークンが、トークン空間全体をブルートフォース検索する必要性を回避するために、実行時に動的に割り当てられるか、又は決定される、請求項6~16のいずれか一項に記載のプロセス。
【請求項18】
前記ウォーターマークトークンを決定することが、
(i)前記トークン空間をセグメントにセグメント化するステップと、
(j)セグメントごとにウォーターマークトークンを割り当てるステップと、を含む、請求項6~17のいずれか一項に記載のプロセス。
【請求項19】
ウォーターマークトークンが、セグメントを走査して、前記所定の範囲内の値にハッシュする前記セグメント内の第1のトークンを見つけることによって割り当てられる、請求項18のいずれか一項に記載のプロセス。
【請求項20】
各セグメントを走査するための開始インデックスが、セグメントインデックスとともにシードされた擬似乱数生成器(PRNG)を使用して選ばれる、請求項18に記載のプロセス。
【請求項21】
ウォーターマークトークンを見つけることなく前記開始インデックスに到達した場合、前記セグメントの最終インデックスが、前記ウォーターマークトークンとして選ばれる、請求項20に記載のプロセス。
【請求項22】
前記セグメントのサイズは、各セグメントが、ウォーターマーク範囲にハッシュする1つ以下のトークンを含んで、意図された入力以外の入力のためにこれらのトークンを返す必要性を回避することになる高い確率を与えるように選ばれる、請求項18~21のいずれか一項に記載のプロセス。
【請求項23】
前記プロセスが、ウォーターマーク付きデータリリースを生成するステップを含み、前記デジタルウォーターマークが、前記データリリースのパラメータに基づいて選ばれるか、又は選択される、先行請求項のいずれか一項に記載のプロセス。
【請求項24】
前記デジタルウォーターマークが、(a)1つ以上のハッシュ関数を使用してウォーターマーク付きデータリリース内の前記トークンをハッシュすることと、(b)前記ハッシュ空間のハッシュ頻度のヒストグラムを構築することと、(c)前記デジタルウォーターマークに対応する前記ビンを決定することと、によって再構築される、先行請求項のいずれか一項に記載のプロセス。
【請求項25】
複数のハッシュ関数が使用されているとき、前記プロセスが、前記ハッシュ関数の全てにわたって各ビンのハッシュ数を合計するステップを含む、先行請求項のいずれか一項に記載のプロセス。
【請求項26】
各ハッシュ関数が、異なる鍵を含む、請求項25に記載のプロセス。
【請求項27】
前記プロセスは、特定のビンにおいて、前記ウォーターマーク付きデータリリースが前記特定のビンに対応する前記デジタルウォーターマークを含まないときに、観察されたハッシュ数以下を得る確率を計算するステップを含む、請求項24~26のいずれか一項に記載のプロセス。
【請求項28】
前記プロセスが、特定のビンにおいて、その特定のビンに対するウォーターマークの不存在で、観察されたハッシュ数を得る確率を計算するステップを含み、前記確率が所定の閾値よりも低いとき、前記プロセスは、ウォーターマーク付きデータリリースが前記特定のビンに対応する特定のデジタルウォーターマークを含むことを推測する、請求項24~27のいずれか一項に記載のプロセス。
【請求項29】
前記プロセスが、ウォーターマーク付きデータリリースのサブセットのみに対して前記デジタルウォーターマークの再構築を可能にする、先行請求項のいずれか一項に記載のプロセス。
【請求項30】
前記プロセスが、ウォーターマーク付きデータリリースの行の追加又は除去などの、ノイズを取り扱うことができる、先行請求項のいずれか一項に記載のプロセス。
【請求項31】
前記デジタルウォーターマークの抽出が、(a)前記トークン化されたデータにおけるウォーターマークの存在の可能性と、(b)トークンハッシュカウントのヒストグラム内の過小評価されたビンがハッシュビンに対応する可能性とに関連する信頼性スコアと関連付けられている、先行請求項のいずれか一項に記載のプロセス。
【請求項32】
前記プロセスが、デジタルウォーターマークを再構築するために必要とされるトークンの数を推定するステップを含む、先行請求項のいずれか一項に記載のプロセス。
【請求項33】
前記トークンの数が、前記トークン化されたデータにおける所与の信頼水準及び存在するノイズの量に対して推定される、請求項32に記載のプロセス。
【請求項34】
前記プロセスが、データリリースを生成するステップを含み、前記デジタルウォーターマークが、前記データリリースの前記パラメータに基づいて選ばれるか、又は選択される、先行請求項のいずれか一項に記載のプロセス。
【請求項35】
前記デジタルウォーターマークが、前記データリリースの受信者に基づいて選ばれるか、又は選択される、先行請求項のいずれか一項に記載のプロセス。
【請求項36】
前記デジタルウォーターマークが、前記データリリースの意図される用途に基づいて選ばれるか、又は選択される、先行請求項のいずれか一項に記載のプロセス。
【請求項37】
前記デジタルウォーターマークが、日付であって、それまでに前記データリリースが削除されなければならない、日付に基づいて選ばれるか、又は選択される、先行請求項のいずれか一項に記載のプロセス。
【請求項38】
トークン化された同じ入力データセットに対応する各データリリースが、異なるデジタルウォーターマークを含む、先行請求項のいずれか一項に記載のプロセス。
【請求項39】
前記デジタルウォーターマークが、一意のIDであるパターンを表す、先行請求項のいずれか一項に記載のプロセス。
【請求項40】
前記デジタルウォーターマークが、トークン化された入力データのタイプに基づいて選ばれるか、又は選択される、先行請求項のいずれか一項に記載のプロセス。
【請求項41】
前記デジタルウォーターマークが、使用される前記決定論的暗号化スキームに基づいて選ばれるか、又は選択される、先行請求項のいずれか一項に記載のプロセス。
【請求項42】
前記プロセスが、前記ハッシュ関数を更新することによって、可能性のあるウォーターマーク付きデータリリースの数を動的にスケーリングするステップを含む、請求項14~41のいずれか一項に記載のプロセス。
【請求項43】
前記プロセスが、前記トークン空間を別のハッシュ関数でハッシュすることによって、可能性のあるウォーターマーク付きデータリリースの数を動的にスケーリングするステップを含む、請求項14~42のいずれか一項に記載のプロセス。
【請求項44】
デジタルウォーターマークをトークン化されたデータ内に埋め込むように適合されたコンピューティングデバイス又はコンピューティングシステムであって、前記デバイス又はシステムが、プロセッサを備え、前記プロセッサが、
(a)入力データセットからトークンを生成することであって、トークンが決定論的暗号化スキームを使用して生成される、生成することと、
(b)生成されたトークンセット内に前記デジタルウォーターマークを埋め込むことと、を行うように構成されている、コンピューティングデバイス又はコンピューティングシステム。
【請求項45】
請求項1~43のいずれか一項に記載のプロセスを実装するようにプログラムされた、請求項44に記載のコンピューティングデバイス又はコンピューティングシステム。
【発明の詳細な説明】
【背景技術】
【0001】
1.発明の分野
本発明の分野は、トークン化されたデータ内にデジタルウォーターマークを埋め込むためのコンピュータ実装プロセス、並びに関連するシステム及び装置に関する。
【0002】
本特許文献の本開示の一部分は、著作権保護の対象となる資料を含んでいる。著作権者は、特許商標庁の特許ファイル又は記録に表示されるように、特許文書又は特許開示のいずれかによる完全複写に何ら異議を唱えないが、それ以外の全ての著作権を留保する。
【0003】
2.先行技術の説明
トークン化は、個人のクレジットカード番号又は社会保障番号などのプライベート識別子の、ユーザ指定の形式に適合するように生成され、元のプライベート識別子と1:1の関係を有するトークンとの置換を伴う。この同じトークンは、常に、同じ識別子の代わりに使用され、いかなる他の識別子にも決して使用されない。
【0004】
デジタルウォーターマーキングは、デジタルコンテンツの機能を維持しながら、デジタルウォーターマークと呼ばれる情報をデジタルコンテンツに埋め込むプロセスに関する。
【0005】
WO2017/093736(A1)は、データ匿名化及びデジタルウォーターマーキングを組み合わせることによって元のデータセットを変更するプロセスを開示している。特に、元のデータセットの匿名化は、トークン化技術を使用して達成され得、トークン化された値は、正規表現で生成される。しかしながら、正規表現は、ウォーターマークの抽出時に既知でなければならない。更に、使用されるトークン化技術は、高スループットニーズ、又は遠隔場所で値を一貫してトークン化する要件を有する顧客に問題を引き起こし得る中央ヴォールトを含む。
【0006】
データをトークン化するために使用された正規表現の知識なしで、デジタルウォーターマーキングがトークン化されたデータに適用されるプロセスに対する必要性が存在する。加えて、任意の数のデータリリースに個別にウォーターマークを入れることができるようにスケーリングするシステムが必要である。
【0007】
WO2017/093736(A1)が参照され、その内容は参照により組み込まれる。
【発明の概要】
【0008】
本発明の実施態様は、トークン化されたデータ内にデジタルウォーターマークを埋め込むためのコンピュータ実装プロセスであって、
(a)入力データセットからトークンを生成するステップであって、トークンが決定論的暗号化スキームを使用して生成される、生成するステップと、
(b)生成されたトークンセット内にデジタルウォーターマークを埋め込むステップと、を含む、プロセスである。
【0009】
本発明は、トークン化されたプライベートデータの多数のウォーターマーク付きデータリリースを提供することができるスケーラブルコンピュータ実装プロセスを提供する。使用されるトークン化は、トークンデータベース又はヴォールトを必要とせずにトークンが生成される、ヴォールトレストークン化である。これは、データリリースが高いスループットで生成されることを必要とし、値を一貫してトークン化する要件を有する解決策に有益であり得る。決定論的トークン化を使用する解決策を提供することによって、プロセスはまた、より短い待ち時間を達成し得る。
【0010】
デジタルウォーターマーキングを決定論的トークン化と組み合わせることによって、ウォーターマーク付きトークンはまた、生データが平文で送信されることなく、世界中で効率的に共有され得る。対照的に、世界中に分散されているヴォールトベースのトークン化は、生データがトークンと一緒にトークンヴォールトに送信されることを必要とし、これは、両方が集中型ヴォールトに記憶されなければならないためである。しかし、ある管轄区域から別の管轄区域への生の識別子のこの送信は、多くの場合、法令又は規制に反する。
【図面の簡単な説明】
【0011】
ここで、本発明の態様が、例として、以下の図面を参照して説明され、図面の各々が本発明の特徴を示す。
【0012】
図1】各ビン内のトークンカウントのヒストグラムを示す。
図2】可能性のある入力の空間を表す図を示す。
図3】トークン空間全体に均一に分散されたウォーターマーク付きトークンを有するトークン空間を表す図を示す。
図4】2つの暗号化スキームに基づいて入力空間をトークン空間にマッピングするアルゴリズムを例示する図を示す。
図5】サイズ400のトークン空間にわたって分散された53個のウォーターマークトークンを含む図(5A)、及び53個のセグメントに分割されたトークン空間を含む別の図(5B)を示す。
図6】1つが実際のウォーターマークトークンを含み、1つが含まない、2つの例示的なセグメントに対するプロセスを例示する図を示す。
図7】入力空間及びトークン空間を例示する図を示す。
図8】入力空間内の値のインデックスを決定するためのステップを例示する図を示す。
図9】部分空間インデックスの暗号化を例示する図を示す。
図10】入力がマッピングするトークン空間セグメントを見つけるやり方を例示する図を示す。
図11】所望のトークンを見つけるためにセグメントを検索するやり方を例示する図を示す。
図12】最終トークン序数を有する出力を例示する図を示す。
図13】等幅のビンに分割されたハッシュ空間を例示する図を示す。
図14】ウォーターマークを抽出するプロセスを例示する図を示す。
図15】複数のハッシュ関数が使用されるときのウォーターマークを抽出するプロセスを例示する図を示す。
図16】並列ハッシュアレイセット上のウォーターマークを抽出するプロセスを例示する図を示す。
図17】アルゴリズムのパラメータを例示する図を示す。
図18】「純粋な」ウォーターマーク(18A)、ノイズを含むウォーターマーク(18B)、及び2つの混合ウォーターマークの場合についての各ビン内のトークンカウントの3つのヒストグラムを示す。
図19】データリリースの数が増加する際の抽出トークンカウント要件を例示する図を示す。
図20】入力ノイズのパーセンテージの関数として、必要とされるトークンのプロットを示す。
図21】データリリースの数が増加する際の抽出トークンカウント要件を例示する図を示す。
図22】入力ノイズのパーセンテージの関数として、必要とされるトークンのプロットを示す。
図23】ウォーターマーク埋め込みのための正規化された計算時間のプロットを示す。
図24】ウォーターマーク抽出のための正規化された計算時間のプロットを示す。
図25】抽出で処理されるトークンの数が増加する際の、95%の信頼水準で実施されるウォーターマーク抽出の最終的な結果を示す。
図26】99.9%の信頼水準で実施されたウォーターマーク抽出の結果を示す。
図27】ランダムノイズが漸進的に追加されているウォーターマーク抽出の結果を示す。
図28】同じ実験の偽陽性発生率をプロットする図を示す。
図29】信頼性を達成するために必要とされるトークンの数を例示する図を示す。
図30】2つのデータリリースウォーターマークを一緒に混合した実験の結果を示す。
図31】3つのデータリリースウォーターマークを一緒に混合した実験の結果を示す。
図32】複数のハッシュ関数が使用され、データリリースのための各ハッシュ関数内の異なるビンが使用されるときの、ウォーターマークを抽出するプロセスを例示する図を示す。
【発明を実施するための形態】
【0013】
本発明の実施態様は、決定論的トークン化に加えてデジタルウォーターマーキングを組み込むコンピュータ実装プロセスを提案する。
【0014】
我々は、説明全体を通して以下の用語を参照し得る。
【0015】
入力空間-トークン化されることを必要とされ得る元のデータセットからの全ての可能性のある入力の空間。入力空間は、正規表現を使用して説明され得る。例えば、クレジットカード番号をトークン化するとき、単純な入力空間の定義は、「[0-9]{16}」-16桁の10進数であり得る(この例では、全てのプレフィックスが有効であるとは限らない複雑さ、及びLuhn桁チェックなどを無視する)。
【0016】
トークン空間-上記と同様に、これは、返され得る全ての可能性のあるトークンの空間である。
【0017】
トークン化されたデータ-入力値がトークンによって置換されたデータ。
【0018】
データリリース-概して、特定の目的のための特定の受信者へのトークン化されたデータの任意のリリースを指す。したがって、各データリリースは、それ自体のデジタルウォーターマークと関連付けられている。デジタルウォーターマークは、メタデータと一緒にウォーターマークレジストリに記憶される数又は他の「ID」であり得る。したがって、リリースからウォーターマークを抽出することによって、データリリースと関連付けられた任意のメタデータもまた、取得され得る。メタデータは、例えば、データリリースを受信することが可能にされた1つ以上の受信者、データリリースの目的又は意図された用途、1つ以上の受信者がデータを保持することが合法的に可能にされる期間、誰とデータを共有することが可能にされるかを含み得る。
【0019】
ウォーターマークトークン-以下の説明で明らかになるように、使用されるハッシュベースのウォーターマーキングスキームは、ウォーターマークビン内に収まる値にハッシュするいかなるトークンも返さないことによって機能し、これらのトークンは、ウォーターマークトークンと呼ばれる。したがって、トークン空間は、ウォーターマークトークン(ウォーターマークビンにハッシュするトークン)及び非ウォーターマークトークン(他のビンにハッシュするトークン)で構成される。
【0020】
ウォーターマーク入力-決定論的トークン化では、全ての入力から全てのトークンへの1:1のマッピングが固定されなければならない。したがって、これらの入力の一部は、ウォーターマークトークンにマッピングされることになるが、これらのトークンを返すことは望んでいない。したがって、スキームの核心は、ウォーターマークトークンが、発生する可能性がないと思われる入力にマッピングされるように、我々がマッピングに影響を与えることであり、我々は、これらの入力をウォーターマーク入力と呼ぶ。例として、我々が、上記に説明された正規表現を使用してクレジットカード番号をトークン化している場合、我々は、0000で開始する番号となるように我々のウォーターマーク入力を選ぶことができ、これは、それらの番号が実際のクレジットカード番号には使用されず、我々がそれらの番号に遭遇しないためである。以下で説明されるように、トークンへの入力のマッピングは、アルゴリズムによってオンザフライで実施される。
【0021】
ウォーターマーキング
WO2017/093736(A1)に開示されるような、先行するウォーターマーキング技術は、パターンがトークンの中に埋め込まれるように、これらのトークンの生成が制御されることを可能にする。このパターンは、データリリースごとに変化させることができ、リリースの一意の識別子がデータ自体の内部及び全体に埋め込まれることを可能にする。この識別子は、データリリースに関するメタデータの任意のストアへのポインタとして使用され得る-リリースの意図された受信者及び目的、それに適用されたプライバシー処理を含むその系統、日付であって、それまでにデータが削除されなければならない、日付など。この埋め込まれたパターンは、確率的であり、任意の個々のトークンに依存するのではなく、生成されたトークンのサンプルから抽出可能であるため、依然として、十分に大きいデータリリースのサブセットから抽出可能である。
【0022】
棄却サンプリングベースのアルゴリズムは、いくつかのパターンに従って潜在的なトークンを棄却する(かつ代わりに別のトークンを生成する)ことによって機能し、次いで、ウォーターマーク付きデータのコーパスが走査されて、パターンを再構築し、したがって、ウォーターマークを学習する。アルゴリズムによって埋め込まれたパターンは、トークンのハッシュに基づく-ハッシュ空間がビンに分割され、ビンの各々がデータリリースに割り当てられ、次いで、データリリースをウォーターマーキングするときに、我々は、現在のデータリリースのハッシュビン内に収まる値にハッシュするいかなるトークンも棄却することを望む(各データリリースには、ハッシュ空間の異なるスライスが割り当てられている)。次いで、図1に示されるように、我々が、ウォーターマーク付きデータを走査し、トークンをハッシュし、各ビン内にトークンカウントのヒストグラムを構築する場合、我々は、空のビン、したがって、ウォーターマークが属するデータリリースを識別することができる。
【0023】
ヴォールトベース対決定論的(ヴォールトレス)トークン化
上記に説明されるプロセスは、我々が入力に割り当てるトークンを、その入力をトークン化する時点で選ぶ機会があるため、ヴォールトベースのトークン化を用いて機能する。我々が、可能性のあるトークンよりも少ない入力に遭遇する限り、我々は、全てのトークンを返す必要はなく、我々は、ウォーターマークビンにハッシュするそれらのトークンを決して返さないように選ぶことができる。
【0024】
したがって、棄却サンプリングは、必要なフォーマットに一致するトークンをランダムに生成し、生成されたトークンを永続的データストア(「トークンヴォールト」)に記憶する、トークン化システムを用いて達成されている。トークンを生成する時点では、棄却されるべき候補値が生成された場合、別の候補値が単純に生成され得る。しかしながら、中央トークンヴォールトに対するこの依存は、高スループットニーズ、又は遠隔場所で値を一貫してトークン化する要件を有する顧客に問題を引き起こし得る。
【0025】
このため、アルゴリズム的であり(例えば、フォーマット保持暗号化サイファーに基づく)、したがって、完全に決定論的である、トークン化スキームを使用することが好ましい場合がある。そのようなスキームの下では、全ての可能性のある(すなわち、定義されたフォーマットに一致する)入力に対して、マッピングされたトークンが存在する-したがって、このシステムで棄却サンプリングウォーターマーキングを実施することは不可能であると仮定され、棄却されるべきトークンにマッピングされる入力に遭遇した場合、そのトークンをリリースする以外の選択肢がない。これは、他のトークンが異なる入力に1:1でマッピングされ、これが最終的にトークン化スキームを破壊することになるため、別のトークンを選ぶことができないという事実に起因する。この問題に対する解決策が以下の段落に提示される。
【0026】
ウォーターマーキング決定論的トークン化
本発明の実施態様は、決定論的トークン化に加えて棄却ベースのウォーターマーキング作業を行うための方法である。それは、多くの場合、特定の入力に遭遇する確率が入力空間にわたって均一でないという観察を使用し、それらのトークンを、遭遇する可能性が最も低いそれらの入力に割り当てることを試みる。これは、2つのフォーマット保持暗号化サイファーの組み合わせを使用して達成される-1つは、最も一般的に遭遇しない入力を「棄却された」トークン又はウォーターマークトークンにマッピングするものであり、もう1つは、残りの(大部分の)入力を他のトークン又は非ウォーターマークトークンにマッピングするものである。
【0027】
有利には、デジタルウォーターマークが、生成されたトークンセット内に埋め込まれ、任意のメタデータ又は冗長データには埋め込まれない。
【0028】
決定論的トークン化によると、名前が暗示するように、我々は、トークン化が開始される前に、各入力に対してどのトークンが返されることになるかの事前決定されたマッピングを有する。返されることになるトークン及び遭遇することになる入力の両方を表す定義された単一の正規表現が存在し、このマッピングは、この表現の観点から定義される-例えば、表現[A-Z]によると、入力序数5(すなわち、E)がトークン序数10(すなわち、J)にマッピングされ得る。
【0029】
入力をトークン化する時点で、我々は、我々が空のままにしたいハッシュビン内にトークンが収まるか否かにかかわらず、マップされたトークン以外の任意のトークンを選ぶ柔軟性を有していない。
【0030】
完璧なウォーターマークを埋め込むために、我々は、データリリースに割り当てられたビンとして指定されたハッシュ空間のスライス内に収まる値にハッシュするトークンを返すことを絶対に回避することを必要とする。しかし、ウォーターマーキング抽出アルゴリズムは、ある程度のレベルのランダムノイズの追加に耐性がある。そのようなノイズは、ウォーターマーク照会について報告された信頼性のレベルを低下させ、これは、必要とされる信頼性に達する前に、より多くのトークンが走査されることを要求する結果となるが、正常な抽出を妨げるものではない(ノイズと信頼性閾値に到達するために必要とされるトークンの数との関係がよく理解されている)。
【0031】
したがって、ウォーターマークを埋め込むには、我々は、次の2つの基準を満たすことを必要とする。
1.他の値よりも少ない頻度で遭遇する、いくつかの可能性のある値であることを必要とする(相対頻度の差は、最終的なウォーターマークのノイズレベルを決定することになる-データ内に実際には決して出現しない入力空間内の十分な値が存在する場合、完璧なウォーターマークを返すことができるが、そうでなければ、ある程度のノイズレベルが存在することになる)。
2.ウォーターマークトークンをこれらの入力に割り当てる(又は、同等に、非ウォーターマークトークンを出現する入力に割り当てる)何らかのやり方を必要とする。
【0032】
トークンヴォールトを使用するとき、これらの基準が満たされる-我々は、データに存在する入力を自然に発見し(我々は、決して出現しない入力をトークン化するように決して求められない)、我々は、トークン化の時点で入力に割り当てるトークンを選ぶことができる。決定論的トークン化でウォーターマーキングを機能させるために、我々は、それらを保持するためのやり方も設計することを必要とする。
【0033】
ヴォールトレストークン化は、多くの場合に集中型ヴォールトを呼び出すことができない分散型デプロイメントなどの、数個の利点を有する。対照的に、世界中に分散されているヴォールトベースのトークン化は、生データがトークンと一緒にトークンヴォールトに送信されることを必要とし、これは、両方が集中型ヴォールトに記憶されなければならないためである。しかし、ある管轄区域から別の管轄区域への生の識別子のこの送信は、多くの場合、法令又は規制に反する。
【0034】
図2は、可能性のある入力の空間(各可能性のある入力は、400の可能性の合計空間内の序数を表す小さい正方形である)を表す図を示しており、入力のうちのいくつか(ライトグレーで示されている)は、観察される可能性が低いものとして識別されているため、ウォーターマークトークンにマッピングされるべきである。
【0035】
我々は、これらの入力(我々がウォーターマーク入力と呼ぶ)を、データリリースウォーターマークビン(ウォーターマークトークン)内に収まる値にハッシュするそれらのトークンにマッピングすることを望む。ウォーターマーキングアルゴリズム内で使用される暗号学的ハッシュ関数(秘密「ウォーターマーキング鍵」に基づく)は、ハッシュ空間全体に均一にハッシュを分散することになる。これは、ハッシュ空間の範囲内に収まるハッシュが、値空間全体から均一に描かれた値からのものであること-すなわち、図3に示されるように、ウォーターマークトークンがトークン空間全体に均一に分散されることになることを暗示する。
【0036】
しかしながら、入力からそのトークンへのマッピングは、基礎となるフォーマット保持暗号化サイファーによって決定され、ランダムとは区別できない置換である-サイファーへのハードワイヤマッピングは可能ではない(少なくとも、自身の非標準かつ必然的に安全ではない暗号化サイファーを考案しない限り)。入力空間のサブセットがトークン空間のサブセットにマッピングされるスキームを実現するために、我々は、部分空間を独自の別個の暗号化サイファーを有する別個の空間として取り扱わなければならない。値を暗号化するために、我々は、これらのステップに従う。
1.別個の部分空間のうちのどれが値を含むかを決定する。
2.その空間に対するサイファーを使用して値を暗号化し、結果として、同じ空間内に別のインデックスをもたらす。
3.この出力インデックスをグローバルトークン空間にマッピングして、結果のトークンを見つける。
【0037】
この解決策を実装するために、我々は、2つの問題を解決することを必要とする。
1.どの入力が、ウォーターマークトークンにマッピングされるべきウォーターマーク入力であるかを決定する
2.どのトークンが、ウォーターマークトークンであるかを決定する(すなわち、ウォーターマークビン内の値にハッシュする)
【0038】
図4は、これらのステップを例示する。
【0039】
したがって、各フォーマット保持暗号化サイファーは、秘密鍵を使用する。更なる秘密鍵-ウォーターマーキング鍵-が、トークンがウォーターマークトークンであるか否かを攻撃者が学習することを防止するために、暗号学的ハッシュ関数によって使用される。
【0040】
入力値分布のモデリング
入力データセット内に出現する値の分布を利用するには、我々は、まず、この分布が何であるかを知る必要がある-この情報を使用して、我々は、どの入力がめったに、又はまったく出現されないかを把握し、ウォーターマークトークンをそれらの入力に割り当てるように試みることができる。これに対するアプローチの例が次に説明される。
【0041】
データの説明
いくつかの状況では、決して遭遇することのない入力空間の領域を説明するために使用され得る入力データの構造のいくつかの先験的知識が存在する。例えば、最初の桁のグループに666又は900~999を含む番号が決して割り当てられないため、社会保障番号の構造に準拠する全ての番号が実際の社会保障番号であるとは限らない。
【0042】
データについての仮定を設ける
データが、いくつかの外部的な意味-例として、名前、電子メールアドレス、給与が挙げられるーを有する場合、ウォーターマークトークンをどこに割り当てるかに関する知識や経験に基づく推測を我々が行うために使用し得るデータに関するいくつかの一般的な経験則に適合する可能性がある。例えば、英語テキストでは、二重字「th」は、「qz」よりもはるかに頻繁である可能性が高く、多くの数値分布では、確率密度関数は、多くの場合、範囲の上限で低い。
【0043】
我々は、これを使用してウォーターマークトークンを割り当てることができる-例えば、[A-Z][a-z]{1,9}の正規表現が提示されている場合、我々は、(Qz|Jq|Jx|Qx)[a-z]{0,8}などの範囲を定義して、我々が最も少ない頻度で出現する(又は決して出現しない)と予想するそれらの入力を捕捉することができる。
【0044】
ベンフォードの法則は、多くの数値データセットでは、先頭桁が小さい可能性が高く、特定の桁が先頭桁である確率は、桁が増加するにつれて対数的に低下することを示している。ベンフォードの法則は、概して、対数正規分布を有するデータセットに適用されるため、その直接的な使用法は、おそらく十分に一般的ではないが、我々は、いくつかの定義された範囲内に収まる数値データの場合、確率密度関数が、多くの場合、範囲の上限で低くなるという一般化を行うことができる。これは、ベンフォードの法則を満たす数桁にまたがる対数正規分布、並びに正規分布(例えば、高さ)、ロングテールを伴う分布(例えば、給料)、及び単調に増加する値(例えば、データベースシーケンスから引き出される識別子)に当てはまる。したがって、単純に、ウォーターマークトークンを数値範囲の上限に割り当てることは、多くのデータセットで良好な結果を与えると予想され得る。
【0045】
データの走査
入力分布について事前に何も知られておらず、前のセクションの仮定が当てはまらない場合、データを走査してそれを観察することによって入力分布を推測することが可能であり得る。しかしながら、構成が、現在のデータの走査から確定されなければならないが、将来のデータが同じ分布を有することになるという保証がないため、これは、以前の技術よりも弱い解決策であり得ることに留意されたい。例えば、データが均一な確率で空間内からランダムに引き出された場合、我々は、ウォーターマークトークンを割り当てる値のない空間内の領域を見つけることができるかもしれないが、将来の値は、これらの範囲内に収まる可能性がある(それに対して、社会保障番号に特殊な数字が決して含まれず、ベンフォードの法則に従うデータは、将来もそのように継続することになる)。
【0046】
ウォーターマークトークンの識別
ウォーターマークトークンは、ウォーターマークビン内に収まる値にハッシュするトークンとして定義される。ハッシュ関数は、一方向の関数であるため、ウォーターマークビンのハッシュ値を受け取り、それらにハッシュすることになるトークンを見つけるやり方がない。トークンのハッシュがビン内に収まるかどうかを見つける唯一のやり方は、それをハッシュして見つけ出すことであり、ウォーターマークトークンの全てを見つけるためにトークン空間全体をブルートフォースしようと試みることは、非常に少数のトークン空間を除く全てに関して現実的ではない。代わりに、我々は、ウォーターマークトークンがトークン空間全体に均一に分布することになるという事実を使用する。これは、我々がトークン空間をセグメントに分割する場合、平均して、これらのセグメントが等しい数のウォーターマークトークンが含むことになることを意味する-例えば、我々が空間をウォーターマークトークンが存在するのと同じ数のセグメントに分割する場合、平均して、各セグメントは、単一のウォーターマークトークンを含むことになる(いくつかのセグメントは何も含まない可能性があり、いくつかは、複数のセグメントを含むことになるが、平均して、各セグメントは、単一のウォーターマークトークンを含むことになる)。例として、図5Aは、サイズ400のトークン空間にわたる53個のウォーターマークトークンの分布を有する図を示す。図5Bは、セグメントを区切るために異なるパターンで満たされた53個のセグメント(サイズ8の29個、及びサイズ7の24個)に分割されたトークン空間を示している(ウォーターマークトークンは、より太い線で強調表示されたセグメント内にある)。これは、正確に1つのウォーターマークトークンを含む37個のセグメント、2つのウォーターマークトークンを含む8つのセグメント、及びウォーターマークトークンを含まない8つのセグメントを我々に与える。
【0047】
我々は、入力空間を、我々が通常のトークンにマッピングすることを望むそれらの入力と、我々がウォーターマークトークンにマッピングすることを望むものとに分割したため、我々は、ウォーターマーク入力があるのと同じ数のセグメントを我々に与えるセグメントサイズを定義することができる。我々は、次いで、我々がウォーターマーク入力に割り当てることになる正確に1つの指定されたトークンを各セグメントが含むことを定義する。我々は、真のウォーターマークトークン(すなわち、ウォーターマークビンにハッシュするトークン)を指定したいが、我々は、これがセグメント内のどのトークンであるかは事前にわからない(セグメントが実際にウォーターマークトークンを含むかどうかさえもわからない)。我々が指定されたトークンを選ぶことを必要とするとき、我々は、セグメント内で真のウォーターマークトークンである最初のトークンを見つけるためにセグメントを検索する(いずれもない場合、セグメント内の最後のトークンを返すことにフォールバックする)。
【0048】
我々が指定されたトークンを選ぶことを必要とするとき、我々は、次のプロセスを使用してセグメントを検索する。
1.セグメント内の開始点を決定する-我々は、これが決定論的であるが(我々が毎回セグメントに対して同じ答えを得るように)、セグメントごとに異なることを望む。これを行うために、我々は、セグメントインデックスを有する擬似乱数生成器(PRNG)をシードし、それを使用してセグメント内のインデックスのうちの1つを選ぶ。
2.この開始インデックスでトークンを検定して、それがウォーターマークトークンであるかどうか(すなわち、それがウォーターマークビン内に収まる値にハッシュするかどうか)を確認する。そうである場合、これは、セグメントの指定されたトークンになる。
3.トークンがウォーターマークトークンではなかった場合、次のトークンの検定に進む。我々がウォーターマークトークンを見つけるか、又は我々が再び開始点に到達するまで、このプロセスを続ける(セグメントの最後でループする)。
4.我々がウォーターマークトークンを見つけることなく再び開始点に到達した場合、我々は、我々がセグメントで検定した最終トークンを指定する(すなわち、我々が循環によってセグメント内の全てのトークンをトラバースした後に遭遇した最後のトークン)。これは、我々がセグメントごとに異なる開始点を選ぶ理由である-我々がセグメントごとに同じポイントで開始した場合、我々は、セグメントごとのセグメント化に対して同じトークンを返す(すなわち、指定されたトークンは、トークンスペース内で定期的に間隔を有することになる)。
【0049】
図6は、1つが実際のウォーターマークトークンを含み、1つが含まない、2つの例示的なセグメントに対するプロセスを例示する図を示す。
【0050】
このシステムが不完全なウォーターマーク入力→ウォーターマークトークンマッピングにつながり得、非ウォーターマーク入力→非ウォーターマークトークンマッピングにつながり得る、2つのやり方が存在し得ることに留意されたい。
1.セグメントが複数の実際のウォーターマークトークン(ウォーターマークビンにハッシュするトークン)を含む場合、それらのうちの1つのみがウォーターマーク入力に割り当てられることになり、他のトークンは、非ウォーターマーク入力に返されることになる。これは、結果的に、ウォーターマークに追加されるノイズをもたらすことになる。
2.セグメントがウォーターマークトークンを含まない場合、ウォーターマーク入力は、実際にはウォーターマークトークンではないトークンを割り当てられることになる。これは、無害であることに留意されたい-そもそも、ウォーターマーク入力は、(定義上)めったに遭遇しない可能性があり、非ウォーターマークトークンを返すことは、いかなるノイズも導入しない。
【0051】
見てわかるように、最初の結果は、埋め込まれたウォーターマークを弱め、我々が少な過ぎるウォーターマーク入力を宣言するときに発生する可能性が高くなる。我々が宣言するウォーターマーク入力の数は、我々が考慮する指定されたトークンの数を決定するが、これは、実際に存在するウォーターマークトークンの数とは独立している。ウォーターマークトークンの数は、ハッシュビンの数及びトークン空間サイズに依存する。ウォーターマーク入力の数がウォーターマークトークンの数よりも少ない場合、このシナリオが発生することは明らかである。
【0052】
第2の結果は、その発生が第1の結果の発生も暗示しない限り、無害である-例えば、宣言されたウォーターマーク入力の数が実際のウォーターマークトークンの数と正確に一致する場合、セグメント化は、不完全な結果を与えることになり、いくつかのセグメントが結果2を生成するという事実は、他のセグメントが結果1を生成しなければならないことを意味する。
【0053】
最適な戦略は、複数のウォーターマークトークンを含むセグメントの確率が小さいほど十分にセグメントが小さいように、ウォーターマーク入力の数がウォーターマークトークンの数を十分なマージンによって超過するときに達成される。しかし、これは、ウォーターマークトークンを他の入力よりも実際にはめったに遭遇しない入力に割り当てること(したがって、ウォーターマークトークンの頻繁なリリースを通じてウォーターマークにノイズを導入すること)につながり得るため、ウォーターマークインプットの数を人為的に膨らませることによって達成されるべきではない。
【0054】
セキュリティ
特定のトークンがウォーターマークトークンであると攻撃者が決定することができた場合、攻撃者は、対応する入力が、あまり頻繁に遭遇しない入力の空間内から引き出されていることを知ることになる-許容できない情報漏洩。しかしながら、アルゴリズムは、ウォーターマークを埋め込む(暗号学的ハッシュ関数を使用して)ときに、秘密ウォーターマーキング鍵を使用するため、この種の推論は、この鍵にアクセスせずには不可能であり、攻撃者は、ヴォールトベースの解決策と比較したときに、トークンからそれ以上のことを学習することができない。
【0055】
ここで、完全なアルゴリズムを例示するために、実施例を説明する。
【0056】
実施例
このセクションは、ウォーターマーク入力領域に収まる入力及びそうではない入力の2つのシナリオの完全なアルゴリズムのステップを同時に実行する。我々は、上記に論じられたものと同じ例示的なシナリオを使用する。図7は、入力空間及びトークン空間を例示する図を示す。左ペインは、宣言されたウォーターマーク入力72を有する、入力空間71を示す。右ペインは、トークン空間73を示し、ウォーターマークトークンの分布もまた、より明るいグレースケールカラー74で示される(ただし、これはアルゴリズムには知られていないことに留意されたい)。我々の例は、強調表示された非ウォーターマーク入力75(序数123の入力)、及び強調表示されたウォーターマーク入力76(序数356の入力)をトークン化することになる。
【0057】
ステップ1:入力空間内の値のインデックスを決定する
入力ごとに、我々は、最初に、それがどの部分空間に含まれているかを決定し、次いで、その空間内のそのインデックスを決定する。図8は、入力空間内の値のインデックスを決定するためのステップを例示する図を示す。
【0058】
我々の例では、入力75(序数123の入力)は、インデックス117を有する非ウォーターマーク入力部分空間内に収まり、入力76(序数356の入力)は、インデックス9を有するウォーターマーク入力部分空間内に収まる。
【0059】
ステップ2:部分空間インデックスを暗号化する
ここで、我々は、その部分空間内の入力を暗号化する-この空間内のインデックスを受け取り、フォーマット保持暗号化方法を使用して、同じ空間内の別のインデックスを取得する。図9は、部分空間インデックスの暗号化を例示する図を示す。
【0060】
我々のシナリオでは、入力75は、サイズ347の部分空間内にインデックス117を有する-この例では、これは、インデックス226に暗号化される。入力76は、インデックス23に暗号化される、サイズ53の部分空間内のインデックス9を有する。
【0061】
ステップ3:これらの入力がマッピングされているトークン空間セグメントを見つける
ここで、我々は、これらの部分空間インデックスがマッピングされているトークン序数を見つけることを必要とする。定義上、我々は、セグメントごとに1つの指定されたトークンを有する-合計53個のウォーターマーク入力が存在するため、これは、我々が53個のセグメントを定義することを意味する。我々は、可能な限りこれらのセグメントのサイズのバランスをとるように努めているため、我々は、サイズ8の29個のセグメント、及びサイズ7の24個のセグメントを作成する。
【0062】
図10は、入力がマッピングするトークン空間セグメントを見つけるやり方を例示する図を示す。
【0063】
セグメントごとに1つの指定されたトークンが存在するため、インデックス23の指定されたトークンは、明らかに23番目のセグメントにある。インデックス226(スペース内の226番目の非ウォーターマークトークン)を有する非ウォーターマークトークンを見つけるために、我々は、我々が225個の他の非ウォーターマークトークンを渡すまで、セグメントをスキップすることを必要とする。最初の29個のセグメントは、各々、8つのトークンを含み、そのうちの1つは、指定されたトークンであり、そのため、我々がこれらの全てをスキップすると、我々は、203個の非ウォーターマークトークンを渡している。残りのセグメントは、7つのトークン(それらのうちの6つは非ウォーターマークトークンである)を含み、そのため、我々は、これらのうちの更に3つをスキップして、合計221個の非ウォーターマークトークンにすることを必要とする。したがって、我々は、インデックス226を有する非ウォーターマークトークンが、33番目のセグメントの5番目の非ウォーターマークトークンであると言うことができる。
【0064】
ステップ4:セグメントを検索して、所望のトークンを見つける
場合ごとに正しいセグメントを見つけると、次いで、我々は、その中に関連するトークンを見つけることを必要とする。
【0065】
図11は、所望のトークンを見つけるためにセグメントを検索するやり方を例示する図を示す。入力111について、我々は、インデックス226を有する非ウォーターマークトークンを検索しており、我々が計算したのは、33番目のセグメントの5番目の非ウォーターマークトークンである。このセグメントに対する我々のランダムであるが決定論的な開始点は、トークン6であり、我々は、これを検定し、ウォーターマークトークンではないことを確認する。次いで、我々は、次のトークンを検定し、このトークンがウォーターマークトークンであること、そして、指定されたトークンもウォーターマークトークンであることを発見する。したがって、我々は、5番目の指定されていないトークンを見つけるために、我々は、このトークンを過ぎて更に4つのトークンを走査しなければならないことを知っている。セグメントの最後で折り返すと、これは、我々が必要とするトークンがセグメント内の3番目のトークンであることを我々に教える。
【0066】
入力112について、我々は、セグメント23内で指定されたトークンを見つけることを必要とする。我々のこのセグメントの開始点は、インデックス3であり、我々は、我々がセグメントの7番目のトークン(我々が検定する5番目のトークン)がウォーターマークトークンであり、したがって、指定されたトークンであることを発見するまで、各トークンを前方検定しなければならない。
【0067】
ステップ5:最終トークン序数を返す
ここで、残っていることは、最終トークン序数を含む出力を例示する図12に示されるように、我々が見つけたセグメントトークンを、トークン空間全体内のそれらの序数にマッピングすることである。
【0068】
ここで最終的に、我々は、序数123を有する入力111が序数256を有するトークンにトークン化され、序数356を有する入力112が序数184を有するトークンにトークン化されることがわかる。
【0069】
ウォーターマーキングスキームは、ヴォールトレストークン化と組み合わせたときに説明されているが、ヴォールトベースのトークン化と組み合わせるように拡張することもできる。ヴォールトスキームによると、特定の入力に遭遇したときにウォーターマーク付きトークンが出力されないようにシステムが構成され得るため、ウォーターマーキングは、典型的には、解決し易い問題である。しかしながら、ヴォールトスキームは、非ウォーターマークトークンが存在するよりも多くの入力が見られると、動作を停止する。これは、その場合、ウォーターマークトークンが返されなければならないためである。しかしながら、説明されたプロセスはまた、ウォーターマーキングをヴォールトベースのトークン化と組み合わせるときに、この問題を回避することになる解決策を提供する。
【0070】
ここで、アルゴリズムに関する更なる詳細が提供される。
【0071】
アルゴリズム構成単位
ハッシュベースのウォーターマーク
トークン(どのように生成されたか未知である)のみからウォーターマークが抽出されることを可能にするために、トークンのハッシュを使用してパターンが埋め込まれる。この文書では、一貫性のあるトークン化操作の出力であると理解されている「トークン」の用語でプロセスを論じているが、同じウォーターマーキング方法論は、いくつかの擬似ランダム性を含む出力を生成する任意のプロセスに適用されることに留意されたい。例えば、数値のぼかしの出力がハッシュされ、同じプロセスに供され得る。
【0072】
ハッシュ空間は、等幅ビンに分割されることになり、各ビンは、異なるデータリリースに割り当て可能となる(したがって、ウォーターマークを入れられ得るデータリリースの数は、ビンの数に等しい)。図13に示される図は、符号なし32ビット出力及び128(2)データリリースウォーターマークビン(0~127)を与えるハッシュ関数についてこれを図示する。(ビンの数が2の累乗に等しいため、ハッシュ空間がビン全体で正確に分割可能であり、ビンごとのハッシュの数に差がないことに留意されたい)。
【0073】
データリリースのウォーターマークを埋め込むために、我々は、そのデータリリースのウォーターマークビン内に収まる値にハッシュするいかなるトークンも棄却する。したがって、このスキームで棄却されたトークンの割合は、1/Nであり、Nは、データリリースウォーターマークビンの数である。
【0074】
ウォーターマークを抽出するプロセスが図14に例示される。我々は、我々が遭遇するトークンをハッシュし、ハッシュが内部に収まるビンに対して値のカウントを増分する(図では、ビンは、その中に少なくとも1つのハッシュを有するとき、黒くなる)。我々が単一の空のビン141を残されると、ビンインデックスがウォーターマーク141を与える。
【0075】
このアルゴリズムの欠点は、別個のデータリリース(ビン)の数が増加するにつれて、ウォーターマークを抽出するために必要とされるレコードの数も増加することである。ウォーターマークを見つけるために、我々は、他N-1個のビンの全てが少なくとも1つの値を含むことを必要とする。これは、データリリースの数に応じて悪くスケールする。
【0076】
複数のハッシュへの拡張:ハッシュアレイ
ブルームフィルタからアイデアを得て、我々は、複数のハッシュ関数を使用し、それらをハッシュアレイ構造で連携させることができる。ウォーターマークを埋め込むために、我々は、ハッシュ関数のうちのずれかに対して、ウォーターマークビン内に収まるいかなるトークンも棄却する(検定されたが、最終的に棄却されたこの構成を使用する代替的な方法については、以下を参照されたい)。次いで、ウォーターマークを抽出するとき、我々は、アレイのハッシュ関数ビンの1つごとに空である単一のビンインデックス見つける-我々は、ハッシュ関数ごとに空のビンを見つけ、図15に示されるように、これらのセットの共通部分を得る。この共通部分が単一の空のビン151のみを有するとき、我々は、ウォーターマークを見つけているが、この時点では、アレイ内のヒストグラムの各々は、それ自体、依然として、図に例示されるように、2つ以上の空のビンを有する(この図では、対角線パターンで満たされたビンは、現在のハッシュ関数に対して空であるが、他のハッシュ関数のうちの少なくとも1つに対してハッシュ-黒色のビン-を含む)。
【0077】
これは、ここで、トークンが棄却される複数の機会が存在するため、より高いトークン棄却率(同じ数のビンと単一のハッシュ関数と比較したとき)を我々に与えることに留意されたい。
【0078】
データリリースの動的スケーリング:マルチハッシュアレイ
ハッシュアレイ構造は、我々が、ビンの数及びハッシュ関数の数を調整して、サポートされたデータリリースの数及びトークン棄却率のバランスをとることを可能にする。しかしながら、構成は、事前に決定されなければならず、これは、我々に、事前にサポートすることを望むデータリリースの数を決定し、有限のウォーターマークのプールを作成することを強いる。しかし、ハッシュアレイ構造の新しいインスタンス(各々がその独自のハッシュ関数鍵を含む)を作成し、データリリースの異なる部分を各々に割り当てることによって、ウォーターマーク付きデータリリースの数を動的にスケーリングすることができる。我々は、この構造をマルチハッシュアレイ(Multi Hash Array)と呼び、それは、次の特性を有する。
●最初に、マルチハッシュアレイは、単一のハッシュアレイインスタンスのみを含むため、最大N個のデータリリース(Nは、ハッシュアレイビンの数である)のウォーターマーキングをサポートする。
●N個のウォーターマークが割り当てられると、次のN個のデータリリースのウォーターマーキングを取り扱うために、第2のハッシュアレイインスタンスが作成される。この新しいインスタンスは、第1のインスタンスとは異なるハッシュ関数鍵が与えられるため、いずれかのアレイによって埋め込まれた任意のパターンは、他のインスタンスに対してランダムノイズとしてのみ出現する。
●ウォーターマークを埋め込むことは、単一のハッシュアレイインスタンス(ウォーターマークが埋め込まれているデータリリースを含むインスタンス)が使用されることだけを必要とするため、追加のデータリリースがウォーターマークを入れられるにつれて、計算の複雑さが増加することはない。
●トークン棄却率は、単一のハッシュアレイ内のビン及びハッシュ関数の数のみに依存するため、サポートされたデータリリースの数とともに増加することはない。
●追加のハッシュアレイインスタンスは、無期限に追加され得、各新しいインスタンスは、結果的に、ウォーターマークを抽出するために必要とされる行の数のわずかな増加をもたらすだけである(後の分析を参照)。
【0079】
ウォーターマークを抽出するとき、我々は、並列ハッシュアレイ抽出セットを実施する-依頼されたインスタンスごとに1つ。上述のように、各インスタンスがその独自のハッシュ関数鍵を有するため、ウォーターマークパターンは、単一のインスタンスのみに出現することになり、他のインスタンスは、ハッシュの均一な分布(ランダムノイズとして出現する)を観察するだけである。これは、2つのそのようなインスタンスを用いた抽出を示す図16に例示されており、そのうちの一方は、ウォーターマークビン161を見つけているが、他方は、ウォーターマークを確認していない。
【0080】
この構造が付与するデータリリースのパーティショニングは、追加の機能上の利点も提供し得る。
●我々は既に、データリリースウォーターマークを埋め込むことが、データリリースのハッシュアレイインスタンスが使用されることだけを要求するが、同じことが、所与のデータリリースウォーターマークが存在するかどうかを確認するためにデータのストリームを「スニッフィング」する関数についても真であることを確認している。
●未知のウォーターマークの抽出のみが、ハッシュアレイインスタンスの全ての使用を要求する。しかしながら、この構造はまた、漏洩したデータがデータリリースのサブセットからに違いないことが知られている場合、ウォーターマーク検出の範囲(したがって必要な行数)を絞り込むことを可能にする(おそらく、問題のデータセットがデータリリースの一部にのみ公開されたため)。
●古いデータリリースが終了し、考慮対象外に遷移した場合、それらのデータリリースのみを含むハッシュアレイインスタンスは、抽出から除外され得る。
【0081】
個々のハッシュアレイ鍵の各セットは、多くの異なる導出鍵への単一のマスター鍵の拡張を可能にするHKDF(HMACメッセージ認証コードに基づく単純な鍵導出関数KDF)のようなスキーム(及び入力鍵材料内の鍵の「ID」を提供することによって特定の鍵を効率的に取得する能力)を使用して生成される。しかしながら、鍵のより細かい制御(ハッシュアレイのトランシェごと、又は個々のハッシュアレイごとに異なるマスター鍵)を有することも可能であり、これは、2つのセキュリティ上の利点も有し得る。
●パーミショニング:どのウォーターマークがどこで読み取られ得るかのより細かい制御を有する機能。ウォーターマークスニッフィング関数はまた、ウォーターマークが存在することを検証し、ウォーターマークなしのデータが通過することを防止するために使用され得、これらの遠隔実行点の各々が、それが期待するウォーターマークを含むインスタンスの鍵のみを取得する能力を有し、任意のウォーターマークを単に読み取る能力を有していないことは、魅力的な特徴である。
●鍵ローリング:各新しいハッシュアレイがその独自の鍵を有する場合、任意の単一のハッシュアレイ鍵は、その中のデータリリースがオープンかつアクティブである限り使用される(ただし、古い鍵バージョンは、それらを使用して生成されたウォーターマークを抽出することができることを我々が望む限り保持されなければならない)。
【0082】
サポートされているウォーターマークの数及びトークン棄却率
埋め込まれ得る一意のウォーターマークの数と、棄却されたトークンの割合(トークン棄却率)とは、アルゴリズムの以下の構成パラメータに依存する。
●b-各ハッシュアレイインスタンス内のデータリリースビンの数
●h-各ハッシュアレイインスタンスで使用するハッシュ関数の数
●m-現在マルチハッシュアレイを含むハッシュアレイインスタンスの数
図17は、アルゴリズムのパラメータを例示する図を示す。
【0083】
各データリリースには1つのビンが使用されるため、サポートされているデータリリースの数が次式で与えられることが明らかである。
N=m×b
データリリースのウォーターマークを埋め込むために、我々は、ハッシュ関数のうちのいずれかに対するそのデータリリースのウォーターマークビン内に収まる値にハッシュするいかなるトークンも棄却する。したがって、トークン棄却率は、次式で与えられる。
【数1】
【0084】
ウォーターマークの抽出
ノイズの取り扱い:抽出アルゴリズム要件
我々がウォーターマークを抽出しようと試みているデータセットは、ウォーターマークトークンなしの純粋なトークンの集合ではない場合があり、新しい合成行の追加によって修正された可能性があるか、数個のデータリリースからの出力の組み合わせである可能性があるか、又はウォーターマーク入力を割り当てるときにデータ形状について行われた仮定が完全に正しくなかった可能性がある)。ウォーターマークは、秘密鍵を使用して埋め込まれているため、この鍵にアクセスせずに(直接的又は間接的にウォーターマーク抽出関数を介して)任意の特定のビンにおいて過剰であるノイズを作成することはできず、我々は、ウォーターマークを消去しようとする誰にも入手することができないと仮定している。
【0085】
したがって、合成行の追加は、純粋なウォーターマークの上にノイズのベースラインレベルとして現れることになり、複数のデータリリースウォーターマークの組み合わせは、各々ベースラインレベルを下回るある程度の割合の数個のビンとして現れることになる。図18は、「純粋な」ウォーターマーク(18A)、ノイズを含むウォーターマーク(18B)、及び2つの混合ウォーターマークの場合についての各ビン内のトークンカウントの3つのヒストグラムを示す。
【0086】
したがって、我々は、我々の抽出アルゴリズムに次の要件を有する。
●ハッシュビンが正確に空ではない場合でも、ウォーターマークを抽出することができなければならない
●複数のそのようなビン(データが異なるデータリリースからのウォーターマークの混合であることを示す)を取り扱うことができなければならない
●データが特定のウォーターマークを含むことを我々がどの程度確信しているかの何らかの尺度をエンドユーザに示すことができなければならない。
【0087】
空のビンを見つけようと試みるいかなるアプローチも、ノイズを取り扱うために「空」の定義を緩めなければならず、これは、閾値を下回るとビンが空であり、閾値を上回ると空ではない、何らかの閾値割合/カウントを定義することによってのみ行うことができ、望ましくない恣意性の要素をアルゴリズムに導入する。
【0088】
これを回避するために、抽出方法は、「どのデータリリースビンが空であるか?」を決定することを試みない。代わりに、質問を、与えられたデータリリースに対して、「データがこのデータリリースビンに対するウォーターマークを含むことを我々が十分に確信しているか?」と問うように再構築し、ウォーターマークが存在せず、かつ我々がビンにおいてノイズのみを観察していた場合、我々がデータリリースビンにおいて現在のハッシュ数を観察することになる可能性がどの程度あるかを計算することによって答える。
【0089】
全てのデータリリースビンのこの質問を問うことによって、我々は、ウォーターマーク付きデータのソースであったと確信しているデータリリース(又は複数のデータリリース)を返すことができる(それらのビンにおいて観察されたハッシュ数がランダムノイズを原因とし得る可能性が十分に低いためである)。
【0090】
抽出アルゴリズムの概要
ウォーターマーク抽出アルゴリズムは、全てのビンにおける単純な仮説検定であり、これは、帰無仮説(データが現在のビンのウォーターマークを含んでいない)を棄却し、代替仮説を受け入れるのに十分な証拠が存在するか否かを決定する。これは、データがビンデータリリースに対するウォーターマークを含まなかった場合、現在のビンで観察されたハッシュ数又はそれ以下の数を取得する確率を計算することによって行われる。この確率が、ユーザが提供する信頼水準によって暗示される有意水準未満である場合、我々は、データリリースビンに対応するウォーターマークが存在しないという帰無仮説を棄却し、代わりに、そのようなウォーターマークの存在を宣言する。
【0091】
複数のハッシュ関数によると、我々は、ハッシュアレイ構造の複数のインスタンスを有する。ウォーターマークビンを考慮するとき、我々は、ハッシュ関数の全てにわたってビンに対するハッシュ(及びハッシュの総数)を合計する。
【0092】
データリリースビンの検定
帰無仮説が真であった場合、我々は、ハッシュが他のビンと同じくらい頻繁にビンに収まると予想する。しかしながら、ビンに対するウォーターマークが存在した場合、我々は、他のビンと比較して、そのビンにおけるはるかに低い割合のハッシュを観察することを予想する。
【0093】
p値は、帰無仮説が真であるときに、観察された結果と少なくとも同程度の結果を得る確率として定義される。我々の場合では、これは、データがビンに対応するウォーターマークを含まないときに、ビンで観察されたハッシュ数(又はそれ以下)を取得する確率である。
【0094】
p値を計算するために、我々は、異なるビンへのトークンのハッシュを二項分布としてモデル化し、ウォーターマークが存在しないとき、所与のビンにハッシュするトークンの確率が1/bである。
【0095】
データが異なるビンに対応するウォーターマークを有するとき、この確率は、1/b超となることに留意されたい。しかしながら、それらの場合、実際のp値は、常に1/bを用いて計算されたp値未満となるため、我々は、計算されたp値がアルファ未満である場合、帰無仮説を常に安全に棄却し得る。
【0096】
したがって、全体でn個のハッシュを観察した後にビン内でk個のハッシュを見る確率は、次式によって与えられる。
【数2】
したがって、全体でn個のハッシュを観察した後のk個のハッシュを含むビンに対するp値は、次式によって与えられる。
【数3】
このp値が小さいほど、ウォーターマークの存在を示す、我々が有する証拠が多くなる。
【0097】
信頼水準
抽出アルゴリズムは、ユーザ入力として信頼水準を受け取る。これは、1-αとして解釈され、αは、検定の統計的有意性、すなわち、そのようなウォーターマークが存在しないデータにおけるウォーターマークの存在を我々が誤って宣言することになる確率の境界である(したがって、有意水準は、偽発見率の境界を提供する)。
【0098】
ビンに対する計算されたp値が有意水準α未満である場合、我々は、帰無仮説を棄却し、ビンに対するウォーターマークの存在を宣言する。そうでない場合、我々は、帰無仮説を棄却することができず、ビンに対するウォーターマークがデータセット内に見つからないことを宣言する。
注意:この信頼水準は、我々が帰無仮説を棄却したときに実際にウォーターマークが存在する確率として解釈されるべきではない。
【0099】
複数のビンの比較の取り扱い
データから未知のウォーターマークを抽出するとき、我々は、全てのデータリリースビンを検定することを必要とし、プロセスを成功させるには、これらの検定の全てからの決定が正しくなければならない。ウォーターマークの存在について複数のビンを同時に検定することは、1つのビンに対する単一の検定の偽陽性率を超えて、全体の検定の偽陽性率が増加させる。この問題に対処するために、我々は、一連の検定の全体的な誤差が必要な誤差限界を下回って留まることを確保するホルム-ボンフェローニ法を使用する(一方で、標準的なボンフェローニ補正よりも高い統計処理能力を確保し、我々の文脈では、データセットに同時に混合された複数のウォーターマークの存在を検出する向上した能力を意味する)。これは、各検定に使用されるαの値を、検定するデータリリースビンの数である、実施される検定の数の係数で低減することによって行われる。
【0100】
プロセスは、最初にビンをp値によってソートし(昇順)、次いで、各ビンに対して異なる有意水準(α)を使用することである。最も低いp値を有するビンは、最初にα/bの有意水準で検定される。このデータリリースに対するp値が必要な有意水準未満である場合、次に低いp値を有するビンが検定され、今回は、α/(b-1)の有意水準を使用する。このプロセスは、p値がその対応する有意水準を超えるビンに我々が遭遇するまで継続する。したがって、データリリースウォーターマークの組み合わせを抽出するためのαの値は、次のようになる。
【数4】
【数5】
【数6】
...
【0101】
ウォーターマークを検出するために何個のトークンが必要とされるか?
追加のノイズなし
追加のノイズなしのウォーターマークが存在するとき、我々は、空のビンを有する。したがって、p値は、ちょうど、現在のビン以外のビンにハッシュする全てのn個のトークンの確率である。
【数7】
ウォーターマークを検出するために、計算されたp値が(ホルム-ボンフェローニ補正された)有意水準以下でなければならず、したがって、トークンの最小数は、次の点である。
【数8】
並べ替えると、ノイズなしのウォーターマークを抽出するために必要とされるトークンの数を計算するための方程式を与える。
【数9】
【数10】
【数11】
【0102】
インスタンスごとの複数のハッシュアレイインスタンス及び複数のハッシュへの拡張
複数のハッシュアレイインスタンスが存在する場合の上記の導出との唯一の違いは、bだけではなくm×b個の可能性のあるウォーターマークが存在することである。新しい数の検定で上記のステップを繰り返すことは、必要なトークンの数を次のように与える。
【数12】
最後に、必要なトークンの数は、ハッシュの数に反比例し、したがって、次のとおりである。
【数13】
【0103】
ノイズが存在するとき
ウォーターマークを抽出するために必要なトークンの数を計算するとき、我々は、次の結合確率の境界を必要とする。
A.一致するウォーターマークが存在する場合、ビンにおいて特定の数を超えるハッシュを確認する。
B.一致するウォーターマークが存在しない場合、そのハッシュ数以下を確認する。
【0104】
ノイズなしの場合、我々は、Aの確率がゼロであることがわかり(ノイズが存在しない場合、ウォーターマークビンにいかなるハッシュも存在しないことになる)、したがって、我々は、対応するウォーターマークが存在しないとき、ビンにおいてゼロハッシュを確認する確率を計算することのみを必要とした。しかし、ノイズが存在するとき、我々は、これらの確率の両方を考慮することを必要とする。
以下の新しい定義では、我々は、以前と同じ表記を使用する。
●H-ウォーターマークが存在しないという帰無仮説
●H-ウォーターマークが存在するという代替仮説
●p-ビンiにおけるハッシュの予想される割合
●n-ビンiにおけるハッシュ数
●f-ノイズの予想される割合
【0105】
ノイズの割合がfであるときの、ウォーターマークビン内のハッシュの予想される割合は、次のように与えられる。
【数14】
我々は、2つの事象の結合確率が、常に、個々の事象の確率の合計以下であることをわかっている。したがって、所与のノイズレベルでウォーターマークをリードバックするために必要なトークンの数を見つけることは、以下の不等式を満たすkが存在するようにnを解くことと等価である。
Pr(n≦k|H)+Pr(n≧k|H)≦α
式中
【数15】
【数16】
上記の式を満たすnの明示的な式を取得することは困難であり得、したがって、推定関数は、代わりに、上記の不等式を満たすトークンの数を見つけるために、n及びkに対してブルートフォース検索を実施し得る。
【0106】
行対一意のトークン
上記のモデリングは、ウォーターマークを抽出するために必要なトークンの数を計算するが、これは、ハッシュされてアレイビンに追加された各トークンが、トークン分布(したがって、その中に埋め込まれたウォーターマークパターン)に関する新しい情報の断片を我々に与えているという暗黙の仮定が存在するため、実際には一意のトークンの数である。ウォーターマークを埋め込むことができるのは、入力の十分な多様性に遭遇して、ハッシュ空間内の全てのビンに触れるトークンの範囲を我々が返すことを可能にする場合のみである-我々が単一の入力のみに遭遇する病的な場合では、我々は、単一のビンに投入されることになるトークンのみを返すことになる。
【0107】
したがって、遭遇した各トークンを抽出ハッシュビンに一度だけ追加するように試みることが重要である。これは、以前に遭遇したトークンの追跡し続けるために抽出プロセスを必要とするが、ブルームフィルタを使用してこれを行うことは容易である。我々は、我々がウォーターマークを抽出することができるようになることを予想する前に我々が追加することを必要とされる一意のトークンの数をわかっているため、我々は、フィルタを適切にサイズ決めし得る-100,000の値の限界(我々が必要であると予想する一意のトークンの数をはるかに上回る)及び10-9の偽陽性率を選択することは、約525kbのメモリしか必要としないフィルタを与える(抽出プロセスは、データリリースの数又はアルゴリズム構成パラメータにかかわらず、このフィルタの単一のインスタンスのみを必要とすることに留意されたい)。
【0108】
埋め込まれたウォーターマークの強度の報告
埋め込まれたウォーターマークの強度は、トークン化ジョブの一部としてユーザに報告され得る。この強度は、抽出が実施され得、かつウォーターマーク付きデータリリースを依然として正確に取得し得る最大信頼水準として解釈され得(出力ファイルがいかなるやり方でも修正されていないと仮定して)、処理されたデータがウォーターマークを担持するのに十分な一意のトークンを含むかどうかの容易に理解可能な要約を提供する。
【0109】
アルゴリズムパラメータを選ぶ
マルチハッシュアレイ:Mを動的に増加させる
上記に示されるように、トークン棄却率は、mとは独立しており、ウォーターマークを抽出するために必要なトークンの平均数は、mとともに対数的に増加する。したがって、mを動的パラメータとして扱うことは理にかなっている、-ちょうど単一のハッシュアレイインスタンスから開始し、追加のデータリリースウォーターマークとして、それが必要とされるときに追加する。このようにして、トークン棄却率は、一定のままとなり、ウォーターマークを抽出するために必要なトークンの数は、常に、必要とされるデータリリースの数に対して可能な最小値(約)であり、新しいデータリリースウォーターマークがリリースされるときにのみ増加する。
【0110】
ハッシュアレイ:B及びHを選ぶ
これまで見てきたように、b及びhの選択は、アルゴリズムの全ての態様に影響する-サポートされているデータリリースの数、トークン棄却率、及びウォーターマークを抽出するために必要なトークンの数。
【数17】
しかしながら、これらの量は、トークン棄却率方程式から始まり、並べ替えることによって、b及びhの選択にかかわらず、本質的に関連していることが示され得る。
【数18】
【数19】
【数20】
この関係、及びデータリリースの数についての方程式をトークンの数についての方程式に置換すると、数量間の基本的な関係が得られる。
【数21】
所与の抽出信頼水準について、この関係は、ウォーターマークを抽出するために必要なトークンの数が、トークン棄却率及びサポートされているデータリリースの数のみの関数であり、マルチハッシュアレイの構成とは無関係であることを我々に示している。
【0111】
必要なトークンの数は、より多くのトークンを棄却することによって低減され、許容可能なトークン棄却率が使用シナリオに依存するため、使用シナリオごとに1つずつ、我々が複数の異なる構成を必要とし得ることを暗示する。我々の目的のために、我々は、2つの一般的な使用シナリオを考慮する-バルクデータセットのトークン化、及びインタラクティブデータベースクエリからの結果のはるかに小さいセットのトークン化。
【0112】
バルクデータセット
バルクデータセットをトークン化する従来の使用事例では、許容可能なトークン棄却率は、1%が上限である。したがって、以下のパラメータを選ぶことによって、最適な構成に到達する。
●可能な限り上限値に近いトークン棄却率をもたらす
●より多くのデータリリースをサポートすることは、ウォーターマークを抽出するために必要なより多くのトークンのコストがかかるため、データリリースの数を最小化する。上記のセクションで論じられたように、我々は、常に、より多くのデータリリースをサポートするためにmを動的に増加させ得るが、我々は、b未満のデータリリースをサポートすることができない-したがって、最初のパフォーマンスを低くするのではなく、パフォーマンスが最初に最適であり、より多くのデータリリースが必要とされるにつれて徐々に低下するように、bを最小化することは理にかなっている。
【0113】
したがって、このシナリオのための提案された構成は、次のとおりである。
●b=1024
●h=10
これは、わずか0.97%を超えるトークン棄却率を与える。図19は、データリリースの数が増加する際の抽出トークンカウント要件を例示する図を示す。
【0114】
図20は、入力ノイズのパーセンテージの関数として、第1のハッシュアレイインスタンス(最大1024個のデータリリースをサポートする)に対する99.9%の信頼性でウォーターマークを抽出するために必要なトークンのプロットを示す。
【0115】
小さいデータセット
データセットのプレビューとして、又は選択的なSQLクエリの結果として、データセットの小さいサンプルを取得する使用事例では、我々は、はるかに高いトークン棄却率を許容し得るが(我々は、トークンを必要とする多くのより少ない数を有することになるため)、我々は、はるかに小さいデータセットに抽出可能なウォーターマークを埋め込むことができることを必要とすることになる。したがって、このシナリオのための提案された構成は、次のとおりである。
●b=256
●h=50
【0116】
これは、約17.8%のトークン棄却率を与える。図21は、データリリースの数が増加する際の抽出トークンカウント要件を例示する図を示す。
【0117】
図22は、入力ノイズのパーセンテージの関数として、第1のハッシュアレイインスタンス(最大256個のデータリリースをサポートする)に対する99.9%の信頼性でウォーターマークを抽出するために必要なトークンのプロットを示す。
【0118】
スケーラビリティ
計算時間
アルゴリズムの計算コストの最大の構成要素は、暗号学的ハッシュを計算することである。したがって、hが増加するにつれて、アルゴリズムの計算コストが著しく増加することになると思われ得る。しかしながら、Kirsch-Mitzenmacher最適化のおかげで、単一の64ビットハッシュを計算することのみが必要であり、次いで、これから、複数の32ビットハッシュが、いかなるランダム性も損わずに、乗算及び剰余演算によって安価に導出され得る。ハッシュの数を増加させることは、必要な計算量を増加させるが、合理的に控えめである(ベンチマークから、ウォーターマークを埋め込むときの50ハッシュの計算コストは、50倍ではなく、1ハッシュの計算コストの約1.7倍である)。
【0119】
各ハッシュアレイインスタンスがその独自のベース鍵を有するため、我々がmを増加させると、この最適化が適用されない場合がある。したがって、計算時間は、mと直線的にスケーリングされる。しかしながら、これは、ウォーターマークを抽出するときに異なるハッシュアレイインスタンスにわたって我々がハッシュを計算することを必要とするときのみ、懸念される。ウォーターマークを埋め込むとき(これは、トークン化クリティカルパス上の唯一の操作である)、我々は、単一のハッシュアレイインスタンス(我々がウォーターマークを埋め込むデータリリースを含むインスタンス)のみを検定することを必要とするため、埋め込みの計算時間は、mとは独立している。
【0120】
図23及び図24は、これらの主張を確認するベンチマーク実行の結果を示す。図23は、ウォーターマーク埋め込みのための正規化された計算時間をプロットし、図24は、ウォーターマーク抽出のための正規化された計算時間をプロットする。各グラフでは、絶対値が環境に依存して異なることになり、我々が関心のある全てがトレンドであるため、垂直軸の値は、その特定の検定の範囲内で正規化されていることに留意されたい。
【0121】
メモリ
ウォーターマークを抽出することは、データがトラバースされている間にビンがメモリに保持されることを必要とし、ビンカウントを増分する(我々はまた、h、b、及びmの値にかかわらず、少量のメモリを必要とする単一のブルームフィルタも使用する)。h又はmを増加させることは、結果的に、メモリ内にあるビンアレイのより多くのコピーをもたらすことになり、bを増加させることは、結果的に、各コピーにおいてより大きいビンアレイをもたらすことになる。b及びhの値は、我々のシナリオでは固定されており、ハッシュアレイインスタンスごとに多くのメモリを使用するには小さ過ぎる。しかしながら、ウォーターマークを抽出するために必要なメモリは、埋め込まれたウォーターマークの数が増加するにつれて(すなわち、mが増加するにつれて)増加することになる。メモリ使用量が問題になるのに十分な数にmが到達した場合、データを複数回通過し、それらにわたってmの値をパーティショニングする必要がある場合がある。
【0122】
ウォーターマークを埋め込むことは、メモリに状態が記憶される必要がないため、影響されない。
【0123】
結果
要約
このセクションは、提案されたスキームの挙動の様々な態様を検証するために、提案されたスキームに対して実行された実験の結果を提示する。要約すると、これらの結果は、我々に次のことを示す。
●抽出可能なウォーターマークを埋め込むことは、予想されるトークンの数を必要とする
●抽出によって返される偽陽性一致率は、信頼水準によって制限されるため、任意に低くなるように調整され得る
●抽出は、ノイズが多い場合、より多くの行を必要とするコストを払ってランダムノイズに耐え、行の要件は、モデル化されたように上昇する
●複数のデータリリースウォーターマークの混合は、結果的に、追加のランダムノイズの存在があっても、個々のウォーターマークの全てが抽出されることをもたらす。
【0124】
注記:このセクションで提示された全ての結果は、同様のバルクデータセット構成(b=1024及びh=10)を使用して取得された。しかしながら、観察はまた、上記の議論で予測されたやり方でスケーリングされた絶対数だけで、任意の他の構成を有するデータセットにも適用される。
【0125】
抽出結果
図25は、抽出で処理されるトークンの数が増加する際の、95%の信頼水準で実施されるウォーターマーク抽出の最終的な結果を示す。各データポイントは、10,000回の実験の平均値であり、結果が返されなかった、正しいデータリリースのみが返された、正しいデータリリース及び誤ったデータリリースが返された、の3つの相互に排他的な可能性にわたる結果の分割を示している(誤ったデータリリースのみが返される理論的な第4の結果が存在するが、これは起こらなかったことに留意されたい)。
【0126】
ここでは、我々は、信頼水準パラメータの効果を明確に確認し、これは、偽陽性が返される率を制限することである(我々が95%の信頼性でウォーターマークを抽出することを必要とすることになることを我々のモデリングが我々に示すトークンカウント-1017個のトークン-に我々が達すると、我々は、常に、正しいデータリリースを取得するが、それは、我々の信頼性によって暗示されるアルファレベルを超えることが決してない率における偽陽性結果によって達成される)。
【0127】
上記のグラフは、このパラメータの効果が簡単に視覚化され得るように、95%の信頼水準の使用を実証しているが、ウォーターマーク抽出では、偽陽性は、望ましくない事象であり-状況によっては、結果的に、無実の受信者がデータ漏洩の原因であると非難されることになる可能性がある-したがって、5%の偽陽性率は、実際の使用には高過ぎる。しかし、信頼水準は、偽陽性の頻度を所望のレベルまで低減するための容易に理解可能な機構を我々に与える-ユーザが99.9%の信頼水準を指定した場合、0.1%以下の場合に偽陽性が返されることになることが確保され得る。そして、真陽性データリリースのスコアは、トークンの数とともに非常に急速に増加するため、この追加の正確性、実際のウォーターマークを抽出するために必要とされるトークンの数にわずかなコストのみをもたらす。これは、上記の実験を99.9%の信頼水準で繰り返す図26に示される。
【0128】
ノイズ許容度
上記の実験を繰り返したが、増加するレベルのランダムノイズを徐々に追加した。図27のグラフは、我々が正しいウォーターマーク付きデータリリースのみを取得する回数のパーセンテージが、ノイズレベル及び抽出が実施されたトークンの数によってどのように変動するかを示している(繰り返しになるが、効果が明確に確認されることを可能にするために信頼水準95%で)。グラフは、予想されるように、指定された信頼水準で正しい結果を取得するために必要とされるトークンの数が増加することを示す。
【0129】
図28は、同じ実験に対する偽陽性発生率を示す(ここでは、正しいデータリリースも返されたかどうかにかかわらず、少なくとも1つの誤ったデータリリースが返されるたびに、偽陽性が記録される)。
【0130】
ここでは、我々は、偽陽性率が、提供された信頼水準によって制限されていること(そして、それがノイズのレベルに依存しないこと)を明確に確認することができる。
【0131】
信頼性を達成するために必要なトークンの数
ウォーターマーク抽出アルゴリズムの上記の議論は、所与の信頼水準及び入力データセットに追加されたノイズの量に対してウォーターマークを抽出するために必要とされるトークンの数を推定するための方法を提示する。これの正確性を検定するために、95%の信頼性でウォーターマークを抽出するために必要なトークンの数を様々なノイズレベルに対して計算し、次いで、これらの各々に対して実験を実行し、このサイズのデータセット上でウォーターマークを10,000回抽出し、結果を記録することを試みた。この実験の結果が図29に示される(正しいデータリリースのみが返された時間のパーセンテージを表すエリア、及び正しいデータリリースも返されたかどうかにかかわらず、少なくとも1つの誤ったデータリリースが返された回数のパーセンテージを表すエリアであり、右手のy軸を使用する線は、そのノイズレベルに対する抽出が実施された行の数を示している)。
【0132】
このグラフから、我々は、必要なトークンの数に対する推定が正確であることを確認することができる-我々は、抽出の成功率が、予想される信頼水準を良好に追跡していることがわかる(そして、例によって、偽陽性率が予想される5%を決して超えない)。
【0133】
混合データリリースウォーターマーク
図30及び図31は、抽出関数への入力が、一緒に混合された複数のデータリリースウォーターマークを含むデータセットであった実験の結果を示し、徐々に高いレベルのランダムノイズの追加を伴っている。図30は、2つのデータリリースウォーターマークが一緒に混合された実験を示し、図31は、3つのデータリリースウォーターマークの混合を示す。全てのインスタンスで、ウォーターマークは、ランダムノイズが追加された後に残ったトークン全体で均等に共有された(例えば、40%ノイズの結果は、図30において、40%ノイズ/30%データリリース1/30%データリリース2を含み、図31において、40%ノイズ/20%データリリース1/20%データリリース2/20%データリリース3を含む)。全ての実験を95%の信頼水準で実行した。
【0134】
ここでは、我々は、ランダムノイズの追加を伴っても、複数のウォーターマークが正しく分離されていることを確認することができる。予想されるように、より多くのトークンが、より多くのウォーターマークを抽出するために必要とされる(ウォーターマークビンのうちの1つの観点から、他のウォーターマークを担持するデータは、単にランダムノイズとして出現するため、上記のセクションに示されるやり方でそのウォーターマークの抽出を遅くする)。
【0135】
偽陽性率は、上記のグラフには示されていないが、予想されるように5%に制限されている。
【0136】
代替的なデータリリース表現
提案されたスキームは、各ハッシュアレイのデータリリースに同じビンを使用する。しかし、代替的なスキームは、データリリースに対する各ハッシュ関数で異なるビンを使用し、ハッシュ関数+ビンのペアのセット(各ハッシュ関数に1つ)としてデータリリースを表す-任意の所与のハッシュ関数のビンは、複数のデータリリースに使用されることになるが、ハッシュ関数にわたるビンの組み合わせは、そのデータリリースに一意になる。図32に示されるように、この構成は、従来の場合よりも多くのデータリリースを我々に与えるが、ハッシュ関数は、もはや一緒に機能しないため、直接的に、より多くのトークンがウォーターマークを抽出するために必要とされる(我々の元の構成では、ハッシュ関数のいずれかのビンに出現するトークンハッシュは、そのビンが全てのハッシュ関数で考慮されないことを規則化するのに十分であったが、この代替的なスキームでは、そうではなくなり、各ハッシュ関数は、独立して機能する)。しかしながら、これは、依然として単一のハッシュ関数構造よりも少ないトークンを必要とすることになる-追加される各トークンは、ハッシュ関数の各々におけるビンを排除し、データリリースのビンに対するハッシュ関数の全てにわたる値の全ての合計が、より少ないトークンでより高い信頼性スコアに我々が到達することを可能にする。
【0137】
この構成によると、サポートされているウォーターマークの数は、次式によって与えられる。
N=m×b
しかし、データリリースのこの指数関数的な増加は、最終的にこの構成が棄却された理由であった。我々が見てきたように、ウォーターマークを抽出するために必要なトークンの数と、所与のトークン棄却率に対してサポートされ得るデータリリース数との間には基本的な関係が存在する-したがって、ある程度逆説的に、我々が、トークン棄却率を許容される1%の境界に可能な限り近づけ、したがって、必要なトークンの最小数に可能な限り近づけることができるように、データリリースの数の増加がより遅いスキームを有することが実際には有利である。
【0138】
付録A-ウォーターマーキング決定論的トークン化
この付録は、主な特徴A~Dを要約する。列記されている各特徴は、任意の他の特徴A~Dと組み合わせられ得る。以下に定義されている各任意選択の特徴は、任意の特徴及び任意の他の任意選択の特徴と組み合わせられ得る。
【0139】
主な特徴A:決定論的トークン化に加えてデジタルウォーターマーキングを組み込むプロセス。
トークン化されたデータ内にデジタルウォーターマークを埋め込むためのコンピュータ実装プロセスであって、
(a)入力データセットからトークンを生成するステップであって、トークンが決定論的暗号化スキームを使用して生成される、生成するステップと、
(b)生成されたトークンセット内にデジタルウォーターマークを埋め込むステップと、を含む、プロセス。
【0140】
主な特徴B:デジタルウォーターマークが、生成されたトークンセット内のトークンの選択を通して確率的に埋め込まれる、決定論的トークン化に加えてデジタルウォーターマーキングを組み込むプロセス。
トークン化されたデータ内にデジタルウォーターマークを埋め込むためのコンピュータ実装プロセスであって、
(a)入力データセットからトークンを生成するステップであって、トークンが決定論的暗号化スキームを使用して生成される、生成するステップと、
(b)生成されたトークンセット内にデジタルウォーターマークを埋め込むステップと、を含み、
デジタルウォーターマークが、生成されたトークンセット内のトークンの選択を通して確率的に埋め込まれるパターンを含む、プロセス。
【0141】
主な特徴C:デジタルウォーターマークが、暗号化スキーム、又は入力データセット上で使用される任意の他の処理の事前知識なしで再構築され得る、決定論的トークン化に加えてデジタルウォーターマーキングを組み込むプロセス。
トークン化されたデータ内にデジタルウォーターマークを埋め込むためのコンピュータ実装プロセスであって、
(a)入力データセットからトークンを生成するステップであって、トークンが決定論的暗号化スキームを使用して生成される、生成するステップと、
(b)生成されたトークンセット内にデジタルウォーターマークを埋め込むステップと、を含み、
デジタルウォーターマークが、暗号化スキーム、又は入力データセット上で使用される任意の他の処理の事前知識なしで再構築され得る、プロセス。
【0142】
主な特徴D:決定論的トークン化に加えてデジタルウォーターマーキングを組み込むプロセスであって、可能性のあるウォーターマーク付きデータリリースの数が、動的にスケーリングされ得る、プロセス。
トークン化されたデータ内にデジタルウォーターマークを埋め込むためのコンピュータ実装プロセスであって、
(a)入力データセットからトークンを生成するステップであって、トークンが決定論的暗号化スキームを使用して生成される、生成するステップと、
(b)生成されたトークンセット内にデジタルウォーターマークを埋め込むステップと、
(a)データリリースを生成するステップであって、デジタルウォーターマークが、データリリースのパラメータに基づいて選ばれるか、又は選択される、生成するステップと、を含み、
可能性のあるウォーターマーク付きデータリリースの数が、動的にスケーリングされ得る、プロセス。
【0143】
任意選択の特徴
デジタルウォーターマークを埋め込むプロセス
●デジタルウォーターマークが、生成されたトークンセット内に埋め込まれ、任意のメタデータ又は冗長データには埋め込まれない。
●決定論的暗号化スキームが、フォーマット保持暗号化サイファーに基づく擬似ランダム置換スキームなどの、擬似ランダム置換スキームである。
●プロセスは、次のステップを含む。
(a)入力データセットに対応する入力空間を走査又は観察するステップ、
(b)ウォーターマークトークンにマッピングされるべき入力を決定又は識別するステップ。
●ウォーターマークトークンにマッピングされるべき入力が、入力空間及び入力空間が表すものの知識から推測される。
●ウォーターマークトークンにマッピングされるべき入力は、出現又は遭遇する可能性が低い入力である(出現する可能性が低いとは、我々が返すことを望まないトークンが、我々が遭遇すると予想しない入力にマッピングされるように、可能性のある入力値に遭遇する確率の分布を利用することを指す)。
●プロセスが、入力空間を「非ウォーターマーク入力部分空間」及び「ウォーターマーク入力部分空間」という2つの別個の又は互いに素な部分空間に分割するステップを含み、非ウォーターマーク入力部分空間の入力が、非ウォーターマークトークンにマッピングされ、ウォーターマーク入力部分空間の入力が、ウォーターマークトークンにマッピングされる。
●各入力部分空間の暗号化が、独立して達成される。
●アルゴリズムが、FPE(フォーマット保持暗号化)などの2つの決定論的暗号化スキームを含む。
●FPEが、非ウォーターマーク入力部分空間を暗号化するように構成されており、他方のFPEが、ウォーターマーク入力部分空間を暗号化するように構成されている。
●2つの決定論的暗号化スキームは、各々、秘密鍵に基づく。
●デジタルウォーターマークパターンが、ウォーターマークトークン内に埋め込まれ、ウォーターマークトークンは、それらのトークンがハッシュ空間の所定の範囲内に収まる値にハッシュするように割り当てられるか、又は決定される。
●トークンのハッシュが、秘密ウォーターマーキング鍵に基づいた暗号学的ハッシュ関数を使用して行われるため、攻撃者は、トークンがどの部分空間内に存在するかを学習することができない。
●プロセスが、ハッシュ空間のビンが値を含まないか、又はゼロに近い値を含むように、ウォーターマークトークンが決して又はめったに返されないように、ウォーターマークトークンをマッピングするように試みるステップを含む。
●ウォーターマークトークンが、トークン空間全体をブルートフォース検索する必要性を回避するために、実行時に動的に割り当てられるか、又は決定される。
●ウォーターマークトークンを決定することは、以下のステップを含む。
(i)トークン空間をセグメントにセグメント化するステップ、
(j)セグメントごとにウォーターマークトークンを割り当てるステップ。
●ウォーターマークトークンが、セグメントを走査して、所定の範囲内の値にハッシュするセグメント内の第1のトークンを見つけることによって割り当てられる。
●各セグメントを走査するための開始インデックスが、セグメントインデックスとともにシードされた擬似乱数生成器(PRNG)を使用して選ばれる。
●ウォーターマークトークンを見つけることなく開始インデックスに到達した場合、セグメントの最終インデックスが、ウォーターマークトークンとして選ばれる。
●セグメントのサイズは、各セグメントが、ウォーターマーク範囲(ハッシュ関数からの均一な分布を仮定する)にハッシュする1つ以下のトークンを含んで、意図された入力以外の入力のためにこれらのトークンを返す必要性を回避することになる、高い確率を与えるように選ばれる。
【0144】
データリリースからのデジタルウォーターマークの再構築又は抽出
●デジタルウォーターマークが、決定論的暗号化スキーム、又は入力データセット上で使用される任意の他のスキームの事前知識なしで再構築され得る。
●デジタルウォーターマークは、(a)1つ以上のハッシュ関数を使用してウォーターマークデータリリース内のトークンをハッシュすることと、(b)ハッシュ空間のハッシュ頻度のヒストグラムを構築することと、(c)デジタルウォーターマークに対応するビンを決定することと、によって再構築される。
●複数のハッシュ関数が使用されているとき、プロセスが、ハッシュ関数の全てにわたって各ビンのハッシュ数を合計するステップを含む。
●各ハッシュ関数は、異なる鍵を含む。
●プロセスは、特定のビンにおいて、ウォーターマーク付きデータリリースが特定のビンに対応するデジタルウォーターマークを含まないときに、観察されたハッシュ数以下を得る確率を計算するステップを含む
●計算された確率が、所定の閾値よりも低いとき、プロセスは、データリリースが特定のデジタルウォーターマークを含むことを推測する。
●プロセスが、データリリースのサブセットのみに対してデジタルウォーターマークの再構築を可能にする。
●プロセスが、データリリースの行の追加又は除去などの、ノイズを取り扱うことができる。
●デジタルウォーターマークの抽出が、(a)トークン化されたデータにおけるウォーターマークの存在の可能性、及び(b)トークンハッシュカウントのヒストグラム内の過小評価されたビンがハッシュビンに対応する可能性に関連する信頼性スコアと関連付けられている。(ウォーターマークがトークン化されたデータに実際に存在し、トークンハッシュカウントのヒストグラム内の過小評価されたビンが単なる偶然の産物ではないことを我々がどの程度確信できるか)
●プロセスが、デジタルウォーターマークを再構築するために必要とされるトークンの数を推定するステップを含む。
●トークンの数が、トークン化されたデータにおける所与の信頼水準及び存在するノイズの量に対して推定される。
【0145】
デジタルウォーターマークは、データリリースのパラメータに依存する
●コンピュータ実装プロセスが、データリリースを生成するステップを含み、デジタルウォーターマークが、データリリースのパラメータに基づいて選ばれるか、又は選択される。
●デジタルウォーターマークが、データリリースの受信者に基づいて選ばれるか、又は選択される。
●デジタルウォーターマークが、データリリースの意図される用途に基づいて選ばれるか、又は選択される。
●デジタルウォーターマークが、日付であって、それまでにデータリリースが削除されなければならない、日付に基づいて選ばれるか、又は選択される。
●トークン化された同じ入力データセットに対応する各データリリースが、異なるデジタルウォーターマークを含む。
●デジタルウォーターマークが、一意のIDであるパターンを表す。
●デジタルウォーターマークが、トークン化された入力データのタイプ(すなわち、ID、社会保障番号、高い、給与など)に基づいて選ばれるか、又は選択される。
●デジタルウォーターマークが、使用される決定論的暗号化スキームに基づいて選ばれるか、又は選択される。
●プロセスが、ハッシュ関数を更新することによって、可能性のあるウォーターマーク付きデータリリースの数を動的にスケーリングするステップを含む。
●プロセスが、トークン空間を別のハッシュ関数でハッシュすることによって、可能性のあるウォーターマーク付きデータリリースの数を動的にスケーリングするステップを含む。
【0146】
コンピュータデバイス又はシステム
デジタルウォーターマークをトークン化されたデータ内に埋め込むように適合されたコンピューティングデバイス又はシステムであって、デバイス又はシステムが、
(a)入力データセットからトークンを生成することであって、トークンが決定論的暗号化スキームを使用して生成される、生成することと、
(b)生成されたトークンセット内にデジタルウォーターマークを埋め込むことと、を行うように構成されているプロセッサを備える、コンピューティングデバイス又はシステム。
【0147】
注記
上記の参照された構成が本発明の原理の出願の単なる例示であることが理解されるべきである。本発明の趣旨及び範囲から逸脱することなく、多数の修正及び代替的な構成が考案され得る。本発明は、図面に示されており、本発明の最も実用的で好ましい例であると現在考えられているものに関連して特定的に、かつ詳細に上記に完全に説明されているが、本明細書に記載される本発明の原理及び概念から逸脱することなく、多数の修正がなされ得ることが当業者には明らかであろう。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18A
図18B
図18C
図19
図20
図21
図22
図23
図24
図25
図26
図27
図28
図29
図30
図31
図32
【国際調査報告】