JP2019518397A - データ変換システムおよび方法 - Google Patents

Abstract

種々の実施形態では、プロセッサに結合されるコンピュータ可読メモリ媒体が、開示される。メモリ媒体は、命令を記憶するように構成され、命令は、プロセッサに、シード値を読み出すことと、デジタルビットストリームを受信することと、シード値を擬似乱数生成器（ＰＲＮＧ）へのシードとして使用して、ランダムビットのストリームを生成することであって、ランダムビットのストリームは、少なくともデジタルビットストリームと同数のビットを含有する、ことと、ランダムビットのストリームのビットをシャッフルして、ランダムビットバッファを作成することと、第１の排他的ＯＲ（ＸＯＲ）をデジタルビットストリームおよびランダムビットバッファに適用することによって、難読化されたデジタルビットストリームを生成することと、難読化されたデジタルビットストリームを通信インターフェースに提供することとを行わせる。

Description

（関連出願への相互参照）
本出願は、２０１６年６月６日に出願された米国仮特許出願第６２／３４６，４５１号、２０１６年６月２４日に出願された米国仮特許出願第６２／３５４，６１５号、２０１６年８月１８日に出願された米国仮特許出願第６２／３７６，８７６号、２０１６年９月２９日に出願された米国仮特許出願第６２／４０１，６０９号、および２０１６年１２月２２日に出願された米国仮特許出願第６２／４３８，４４３号の優先権の利益を主張する、上記文献のそれぞれの全ての内容は、参照することによって本明細書において援用される。

（技術分野）
本開示は、概して、通信システムの分野に関し、特に、データを難読化し、データをサイバー攻撃から保護するように設計される、データ通信システムに関する。

（背景）
データを追跡の脅威からセキュア化することは、インターネットの開発の重要な部分となっている。例えば、ネットワークを横断して伝送されるクレジットカード番号またはログイン情報等の情報の隠蔽は、安全性の実感をエンドユーザに、完全性の実感を取引先に、およびセキュリティの実感をクレジットカード処理企業に提供することに役立つ。種々のデータ難読化技法が、隠蔽された情報が露見されるリスクを軽減することに役立つように開発されている。

情報の転送をセキュア化するための一般的難読化技法の必要に加え、特殊技法が、「知的デバイス」間の情報の転送に対して必要とされる。全て、ローカルで、またはインターネットを通して情報を交換し得る、１００億台を上回るマイクロコントローラの年間出荷数に伴って、多種多様ないわゆる「知的デバイス」が、有効にされている。これらのデバイスは全て、インターネットを経由してアクセスされることができ、結果として生じるネットワークは、一般に、モノのインターネット（ＩｏＴ）と称されている。例えば、ＩｏＴデバイスであり得る、大型デバイスは、インターネットに接続され、自宅所有者が牛乳を切らしそうになると、冷蔵庫が、自動的に、追加で牛乳を自宅に発注するように、その中のアイテムを追跡し得る、冷蔵庫であろう。その対極として、自宅所有者のアラームシステムの一部として、ドアまたは窓が開放される場合、それを検出するためのセンサのようなより小型のデバイスは、インターネットに接続され、自宅所有者に、ドアまたは窓が開放されたことをアラートし得る。別のＩｏＴデバイスは、インターネットと通信し、医師に、患者の心臓の関数状態に関するフィードバックを提供し、さらに、医師がペースメーカーの設定を遠隔場所から制御することを可能にし得る、ペースメーカーであり得る。

あらゆる様式のデバイスがともに接続されることを可能にする能力はまた、課題およびリスクも呈する。例えば、ペースメーカーの場合、認可されている個人のみがペースメーカーの設定に修正を行い得るような認証およびセキュリティが、非常に重要である。加えて、より小型のＩｏＴデバイスは、バッテリ電力で起動する傾向にあるため、かつそのサイズは、多くの場合、回路基板が小型でなければならず、したがって、大量の情報を記憶不可能であることを意味するため、エネルギーの保存およびＩｏＴデバイス上で起動するアルゴリズムのコンパクト性が、重要である。典型的ＩｏＴデバイスは、インターネット接続とともに、ローカル低電力無線接続を要求する。大部分のそのような用途およびソリューションに関して、ゲートウェイが、ある形態のローカルインフラストラクチャを介して、またはセルラー接続を使用して、センサをインターネットに接続するために要求される。

高度暗号化規格（ＡＥＳ）のようなＩｏＴデバイスのために使用される現在の認証およびセキュリティアルゴリズムは、多くの処理電力を要求し、したがって、デバイスの有用な寿命を低減させる。さらに、ＡＥＳを実装するための電力および空間要件に起因して、多くのデバイスは、単に、セキュリティおよび認証関数を全く実装しない。さらに、例えば、ＡＥＳ１２８の使用は、１６バイトブロックで作用するアルゴリズムを要求するが、ＩｏＴ用途における小ペイロードサイズに起因して、１６バイト境界へのパディングは、無駄である。さらに、小サイズのＩｏＴデバイスは、典型的には、それらがＡＥＳ実装を加速するハードウェア命令セットを欠いていることを意味する。最後に、ＡＥＳ等のアルゴリズムの実装は、多くのＣＰＵサイクルを要求し、これは、直接、有用なバッテリ寿命に影響を及ぼす。必要とされるのは、小占有面積、低電力使用、ならびに強力な認証およびセキュリティを有する、アルゴリズムの一部である、ＩｏＴデバイスの認証およびセキュリティを可能にする方法である。

（開示の要約）
本開示は、本分野における短所を克服するためのシステムおよび方法を提供する。例えば、開示されるシステムおよび方法は、より強力な難読化、より高速の処理時間、より低い電力消費、およびカスタマイズを提供する。

本開示の一実施形態は、データ部分およびヘッダ部分を含み、少なくとも２つの異なる難読化技法を使用することによって、着信デジタルビットストリームを難読化する、コンピュータ可読メモリ媒体に関する。第１の難読化技法は、着信デジタルビットストリームを難読化し、第２の難読化技法は、ヘッダ部分内の情報を難読化するために使用され、これは、データ部分が第１の難読化技法を使用して難読化された方法についての情報を含む。

本開示の別の実施形態は、難読化技法に関連する情報をポリシサーバから取得することに関する。

本開示のさらに別の実施形態は、デジタルビットストリームを付加的ビットでパドし、伝送をさらに難読化することに関する。

さらに別の本開示の実施形態は、低電力ＩｏＴコントローラとゲートウェイデバイスとの間でデータを転送するための方法に関し、本方法は、秘密をより低い電力のＩｏＴコントローラの内部メモリから読み出すことと、秘密に基づいて、テーブル分散キーを生成することと、第１のエンコードされたフレームをゲートウェイデバイスから受信することであって、第１のエンコードされたフレームは、第１のデータテーブルを備える、ことと、テーブル分散キーを使用して、第１のエンコードされたデータフレームをデコードし、第１のデータテーブルを読み出すことと、第１のデータテーブルを使用して、第２のエンコードされたデータフレームをエンコードすることと、第２のエンコードされたデータフレームをゲートウェイデバイスに伝送することと、第１のデータテーブルを修正し、第２のデータテーブルを作成することと、第３のエンコードされたデータフレームをゲートウェイデバイスから受信することであって、第３のエンコードされたデータフレームは、第２のデータテーブルを使用してエンコードされる、ことと、第２のデータテーブルを使用して、第３のエンコードされたデータフレームのデコーディングを試みることとを含む。

本開示のさらに別の実施形態によると、プロセッサに動作可能結合される非一過性コンピュータ可読メモリ媒体が、提供される。メモリ媒体およびプロセッサは、通信インターフェースをさらに含み得る、通信デバイスのコンポーネントであってもよい。メモリ媒体は、命令を記憶するように構成される。命令は、本明細書に開示される方法を実装するように構成される。命令は、プロセッサに、シード値を読み出させ、デジタルビットストリームを受信させ、デジタルビットストリームを受信させ、シード値を擬似乱数生成器（ＰＲＮＧ）へのシードとして使用して、ランダムビットのストリームを生成させてもよい。ランダムビットのストリームは、少なくともデジタルビットストリームと同数のビットを含有してもよい。命令はまた、プロセッサに、ランダムビットのストリームのビットをシャッフルし、ランダムビットバッファを作成させ、例えば、第１の排他的ＯＲ（ＸＯＲ）をデジタルビットストリームおよびランダムビットバッファに適用することによって、難読化されたデジタルビットストリームを生成させてもよい。難読化されたデジタルビットストリームは、デジタルビットストリームと同数のビットを有してもよい。加えて、命令は、プロセッサに、例えば、伝送のために、難読化されたデジタルビットストリームを通信インターフェースに提供させてもよい。ランダムビットのストリームは、２バイト数の乗数、例えば、２バイト、４バイト、８バイト、１６バイト、３２バイト等から成ってもよい。ランダムビットのストリームのビットのシャッフルは、最初に、ランダムビットバッファを初期化し、ランダムビットのストリーム内のビットをトラバースし、設定されるランダムビットのストリーム内のビットを識別することによって行われてもよい。設定されるランダムビットのストリーム内のビット毎に、宛先ビット場所が、計算されてもよく、ランダムビットバッファ内の対応するビットが、次いで、設定される。ランダムビットバッファの初期化は、ビットの全てを同一値に設定することを伴ってもよい。いくつかの実施形態によると、ランダムビットバッファの全てのビットは、ゼロに初期化されてもよい。宛先ビットの計算は、テーブルルックアップを使用して遂行されてもよい。

さらに別の実施形態では、命令はさらに、プロセッサに、第２のデジタルビットストリームを受信させ、第２のデジタルビットストリームおよびランダムビットバッファを用いて第２のＸＯＲを実施することによって、第２の難読化されたデジタルビットストリームを生成させるように構成される。一実施例では、第１のＸＯＲにおいて使用されないランダムビットバッファのビットのみが、第２のＸＯＲにおいて使用される。命令はさらに、プロセッサに、第２の難読化されたデジタルビットストリームが第２のデジタルビットストリームと同数のビットを有する場合、第２の難読化されたデジタルビットストリームを通信インターフェースに提供させてもよい。第２のＸＯＲが、ランダムビットバッファの終了に到達するが、全ての第２のデジタルビットストリームがＸＯＲされていない場合、命令はさらに、第２のランダムビットのストリームをＰＲＮＧから生成し、第２のランダムビットのストリームのビットをシャッフルし、ランダムビットバッファを補充し、第３のＸＯＲを第２のデジタルビットストリームおよびランダムビットバッファに適用することによって、第２の難読化されたデジタルビットストリームを生成し続けてもよい。第３のＸＯＲの第１のビットは、ランダムビットバッファの最初のビットであってもよく、第２のデジタルビットストリームの最後のビット後のビットは、第２のＸＯＲにおいて使用される。命令はさらに、プロセッサに、ルックアップテーブルを使用してランダムビットのストリームのビットをシャッフルし、スワップすべきビットを識別させ、ランダムビットのストリーム内の複数のビットに基づいて、ルックアップテーブル内の複数の値をスワップすることによって、シャッフルされたルックアップテーブルを生成させ、シャッフルされたルックアップテーブルを使用して第２のランダムビットのストリームのビットをシャッフルし、スワップすべきビットを識別させるように構成されてもよい。いくつかの実施形態では、シャッフルされたルックアップテーブルを生成することは、ルックアップテーブル内の値の素数、例えば、１７をスワップすることによって生じる。他の実施形態では、テーブル内の値をスワップするとき、テーブルの最後のスワップされたエントリは、テーブルが次にシャッフルされるとき、スワップがテーブル内の次のエントリから開始するであろうように維持される。

本開示のさらなる実施形態によると、さらなる方法、非一過性コンピュータ可読メモリ媒体、および通信デバイスが、提供される。通信デバイスは、通信インターフェースと、プロセッサと、プロセッサに動作可能に結合される、非一過性コンピュータ可読メモリ媒体とを含んでもよい。メモリ媒体は、プロセッサに、乱数を生成させ、デジタルビットストリームを受信させ、少なくともデジタルビットストリームを使用して、巡回冗長性検査（ＣＲＣ）値を計算させ、乱数をＰＲＮＧへのシードとして使用して、ランダムビットのストリームを生成させるように構成される、命令を記憶してもよい。ランダムビットのストリームは、デジタルビットストリーム内のビットおよびＣＲＣ値の組み合わせられた数と同数のビットを含有してもよい。命令はさらに、プロセッサに、（１）乱数および（２）ランダムビットのストリームの排他的ＯＲ（ＸＯＲ）を、デジタルビットストリームおよびＣＲＣ値の連結と連結することによって、ペイロードフレームを生成させ、ペイロードフレームのビットをシャッフルし、難読化されたペイロードフレームを作成させ、難読化されたペイロードフレームを通信インターフェースに提供させてもよい。乱数はまた、ＣＲＣ値の計算において使用されてもよい。乱数は、真乱数であってもよい。ランダムビットのストリームのビットのシャッフルは、最初に、ランダムビットバッファを初期化し、ランダムビットのストリーム内のビットをトラバースし、設定されるランダムビットのストリーム内のビットを識別すことによって行われてもよい。設定されるランダムビットのストリーム内のビット毎に、宛先ビット場所が、計算されてもよく、ランダムビットバッファ内の対応するビットが、次いで、設定される。ランダムビットバッファの初期化は、ビットの全てを同一値であるように設定することを伴ってもよい。いくつかの実施形態によると、ランダムビットバッファの全てのビットは、ゼロに初期化される。宛先ビットの計算は、テーブルルックアップを使用して遂行されてもよい。

図１Ａは、データを１つまたはそれを上回る送信機から１つまたはそれを上回る受信機に伝送するためのデータ通信システムの一実施形態のブロック図を図示する。図１Ｂは、難読化されたデータを記憶するためのデータ記憶システムの一実施形態のブロック図を図示する。 図２は、データ通信システムの１つまたはそれを上回る送信機のためのデータ変換モジュールの一実施形態のブロック図を図示する。 図３は、データ通信システムの１つまたはそれを上回る送信機のためのデータ変換モジュールの別の実施形態のブロック図を図示する。 図４は、データ通信システムの１つまたはそれを上回る受信機のためのデータ変換モジュールの一実施形態のブロック図を図示する。 図５は、データ通信システムの１つまたはそれを上回る受信機のためのデータ変換モジュールの別の実施形態のブロック図を図示する。 図６Ａは、送信機によって伝送されるためのデータのためのヘッダ情報を難読化する一実施形態のブロック図を図示する。図６Ｂは、受信機によって受信されたデータのためのヘッダ情報を難読化解除する一実施形態のブロック図を図示する。 図７は、送信機のためのデータ変換モジュールによって適用可能なヘッダデータのためのビットスワップアルゴリズムを図示する。 図８は、送信機のためのデータ変換モジュールによって図７のアルゴリズムをヘッダデータに適用する、ビットスワップ実施例を図示する。 図９は、受信機のデータ変換モジュールによって適用可能なビットスワップのスクランブリング解除を図示する。 図１０は、ヘッダデータマネージャによってヘッダ難読化モジュールに提供され得る、ヘッダ情報の例示的構造を図示する。 図１１Ａは、ヘッダ情報をエンコードするためのプロセスのフローチャートを図示する。図１１Ｂは、ヘッダ情報をデコードするためのプロセスのフローチャートを図示する。 図１１Ｃは、別の実施形態による、ヘッダ情報をエンコードするプロセスのフローチャートを図示する。図１１Ｄは、別の実施形態による、ヘッダ情報をデコードするためのプロセスのフローチャートを図示する。 図１２Ａは、送信機によって伝送されるための入力データを難読化する一実施形態のブロック図を図示する。図１２Ｂは、受信機によって受信されたデータのための入力データを難読化解除する一実施形態のブロック図を図示する。 図１３は、入力データ難読化のために使用され得る、順方向マッピングおよび逆方向マッピング関数を図示する。 図１４は、インデックス化されたソートを介して選定された順方向マッピングに基づく逆方向マッピングの作成を図示する。 図１５は、入力データの一部を伴う単一フレームからサンプリングされるデータを使用する、データ駆動マッピング関数のための順方向マッピングおよび逆方向マッピング関数を図示する。 図１６Ａは、可変オフセットを使用した図１５に示されるデータ駆動マッピングに基づく、入力データ実施例のエンコーディングを図示する。図１６Ｂは、図１６Ａに示されるエンコーディングのためのエンコードテーブルおよびデコードテーブルを図示する。図１６Ｃは、図１６Ｂのデコードテーブルを使用した図１６Ａの入力データ実施例のデコーディングを図示する。図１６Ｄは、第１のランダムに生成された値に基づく、入力データ実施例のエンコーディングを図示する。図１６Ｅは、第２のランダムに生成された値を使用した図１６Ｄの入力データ実施例のエンコーディングを図示する。 図１７Ａは、非対称テーブルを使用した図１５に示されるデータ駆動マッピングに基づく、入力データ実施例のエンコーディングを図示する。図１７Ｂは、図１７Ａに示されるエンコーディングのためのエンコードテーブルおよびデコードテーブルを図示する。図１７Ｃは、図１７Ａの入力データ実施例のデコーディングを図示する。 図１８は、選定された順方向マッピングに基づく逆方向マッピングの作成を図示し、非対称テーブルは、順方向マッピングにおいて使用される。 図１９は、順方向マッピング関数を用いて実装可能なエラー補正関数を図示する。 図２０Ａは、図１９のエラー補正関数を介した破損したデータストリームの補正を図示する。図２０Ｂは、図１９のエラー補正関数を介したビットエラー検出を図示する。 図２１Ａは、入力データを難読化するためのホワイトニング関数を図示する。 図２１Ｂは、付加的詳細を伴う、図２１Ａのホワイトニング関数を図示する。 図２２Ａは、一実施形態による、ビットをビットシーケンスの中に挿入することによる、入力データを難読化するための転置関数を図示する。図２２Ｂは、別の実施形態による、ビットをビットシーケンスの中に挿入することによる、入力データを難読化するための転置関数を図示する。 図２３Ａは、別の実施形態による、ビットをビットシーケンスの中に挿入することによる、入力データを難読化するための転置関数を図示する。図２３Ｂは、別の実施形態による、ビットをビットシーケンスの中に挿入することによる、入力データを難読化するための転置関数を図示する。 図２４Ａは、別の実施形態による、ビットをビットシーケンスの中に挿入することによる、入力データを難読化するための転置関数を図示する。図２４Ｂは、別の実施形態による、ビットをビットシーケンスの中に挿入することによる、入力データを難読化するための転置関数を図示する。 図２５は、別の実施形態による、ビットをビットシーケンスの中に挿入することによる、入力データを難読化するための転置関数を図示する。 図２６は、入力データをさらに難読化するためのプレフィックス順方向マップおよびプレフィックス逆方向マップの使用を図示する。 図２７Ａは、入力データをエンコードするためのプロセスのフローチャートを図示する。図２７Ｂは、入力データをデコードするためのプロセスのフローチャートを図示する。 図２８Ａは、ヘッダデータおよび入力データを送信機において連結およびスクランブルする一実施形態のブロック図を図示する。図２８Ｂは、受信機において受信された難読化されたデータをスクランブル解除する一実施形態のブロック図を図示する。 図２９は、２つのデータセットをともにスクランブルするためのスクランブリングマッピング関数を図示する。 図３０は、２つのデータセットをともにスクランブルするための畳み込みスクランブリングマッピング関数を図示する。 図３１は、一実施形態による、２つのデータセットをともにスクランブルするために使用され得る、ランダムに生成された値を含む、スクランブリングテーブルを図示する。 図３２は、別の実施形態による、２つのデータセットをともにスクランブルするために使用され得る、ランダムに生成された値を含む、スクランブリングテーブルを図示する。 図３３は、別の実施形態による、２つのデータセットをともにスクランブルするために使用され得る、ランダムに生成された値を含む、スクランブリングテーブルを図示する。 図３４は、一実施形態による、受信されたデータセットをスクランブル解除するために使用され得る、ランダムに生成された値を含む、スクランブリング解除テーブルを図示する。 図３５は、送信機および受信機と、データ難読化およびデータ難読化解除のための１つまたはそれを上回るキーまたは他のパラメータを提供するように構成される、ポリシサーバとの間の通信を図示する。 図３６は、ヘッダデータを入力データでスクランブルするために使用され得る、スクランブリング関数を図示する。 図３７は、本明細書に説明されるシステムおよび方法を実装するために使用され得る、コンピューティングシステムのブロック図である。 図３８は、通信プロトコルを環境内の複数のデバイス間に確立するためのシステムのブロック図を図示する。 図３９は、キー配布プロトコルを２つのデバイス間に実装するためのプロセスのフローチャートを図示する。 図４０は、キー配布テーブル生成プロセスを図示し、キー配布テーブルは、データテーブルを複数のデバイスに分散させるために使用される。 図４１は、通信プロトコルを複数のコントローラとゲートウェイとの間に実装するために、フレーム内のデータを難読化するためのスタンドアロンアルゴリズムを図示する。 図４２は、伝送されるための例示的フレームを図示する。 図４３は、図４１のシャッフルアルゴリズムの詳細なシャッフルプロセスを図示する。 図４４は、通信プロトコルを複数のコントローラとゲートウェイとの間に実装するために、データテーブル内のデータを難読化解除するためのスタンドアロンシャッフルアルゴリズムを図示する。 図４５は、通信プロトコルを複数のコントローラとゲートウェイとの間に実装するために、フレーム内のデータを難読化するためのシーケンシャルアルゴリズムを図示する。 図４６は、図４５のシーケンシャルアルゴリズムの詳細なテーブル修正プロセスを図示する。 図４７は、データ難読化が固定基地局とモバイルデバイスとの間の通信のために実装され得る、環境内の複数の固定基地局およびモバイルデバイスを図示する。 図４８は、固定基地局とモバイルデバイスとの間で伝送され得る、例示的パッケージであり、パッケージは、本明細書に説明されるシステムおよび方法を使用して難読化される。 図４９は、固定基地局とモバイルデバイスとの間のキープロビジョニングを図示する、ブロック図である。 図５０は、ネットワークアクセス制御システムのブロック図である。 図５１は、セッションをネットワーク内の２つのノード間に確立するためのプロセスのフローチャートである。 図５２Ａは、ネットワークアクセスサーバを通したネットワーク内の通信のためのノードをプロビジョニングするプロセスを図示する、ブロック図である。図５２Ｂは、ネットワークアクセスサーバを通したネットワーク内の通信のためのノードをプロビジョニングするプロセスのフローチャートである。 図５３は、サービスとしてのインフラストラクチャ（ＩａａＳ）セッションをネットワーク内のノード間に確立するプロセスを図示する、ブロック図である。 図５４は、サービスとしてのプラットフォーム（ＰａａＳ）セッションをネットワーク内のノード間に確立するプロセスを図示する、ブロック図である。 図５５は、サービスとしてのソフトウェア（ＳａａＳ）セッションをネットワーク内のノード間に確立するプロセスを図示する、ブロック図である。 図５６は、セッションがネットワーク内の複数のノード間に分散される方法を図示する、ブロック図である。 図５７は、ネットワークアクセス制御システムの中に挿入され、システム内の通信を向上させる、複数のバンプインザワイヤ（ＢＩＴＷ）ノードを含む、ネットワークアクセス制御システムのブロック図である。 図５８は、エンジンコントローラと車両サブシステムのＥＣＵとの間の通信のプロセスを図示する、ブロック図である。 図５９Ａは、エンジンコントローラによって車両サブシステムのＥＣＵに提供され得る、プロビジョニングメッセージを図示する。図５９Ｂは、図５９Ａのプロビジョニングメッセージを受信した後に生成され得る、ＥＣＵのプロビジョニングメッセージを図示する。図５９Ｃは、図５９Ｂのプロビジョニングメッセージを受信した後に生成され得る、エンジンコントローラのメッセージを図示する。図５９Ｄは、図５９Ａ−Ｃのプロビジョニングプロセス後に生成されたエンジンコントローラのメッセージを図示する。 図６０は、ＥＣＵとの再同期のためにエンジンコントローラによって生成され得る、再同期メッセージを図示する。 図６１は、伝送のためのメッセージを準備するためのテーブルチェーニング方法を図示する。 図６２Ａは、エンジンコントローラがＥＣＵの認証のために作成および送信し得る、メッセージを図示する。図６２Ｂは、エンジンコントローラがＥＣＵの認証のために作成および送信し得る、メッセージを図示する。 図６３Ａは、ファイルをコンパイルし、ファイルをユーザデバイスからエンジンコントローラに配布するためのプロセスである。図６３Ｂは、図６３Ａのファイルをコンパイルするためのプロセスを図示する。図６３Ｃは、図６３Ａのファイルの各ブロックを暗号化するためのプロセスを図示する。 図６３Ｄは、図６３Ａのファイルの各ブロックのヘッダを暗号化するプロセスを図示する。図６３Ｅは、図６３Ａのファイルのブロックのヘッダおよびペイロードをスクランブルするステップを図示する。 図６４は、ユーザデバイスとエンジンコントローラとの間のセキュアな伝送のプロセスである。 図６５は、ユーザデバイスによってエンジンコントローラに伝送されるファイルをデコーディングおよびアセンブリングするプロセスである。

（詳細な説明）
概して、図を参照すると、デジタルビットストリームのデータ難読化のためのシステムおよび方法が、説明される。本明細書に説明されるシステムおよび方法は、データパケットをエンコーディングおよびデコードし、データをセキュア化するために使用されてもよい。デジタルビットストリームは、本開示では、ビットストリーム、データストリーム、データパケット、またはデータと称され得、本開示における種々の専門用語の使用は、限定ではないことに留意されたい。

図をさらに参照すると、複数のデバイス間の難読化された通信を管理するためのシステムおよび方法が、説明される。複数のデバイス間の通信プロトコルは、キープロビジョニングを介して確立されてもよく、本明細書に説明される難読化技法は、通信をセキュア化するために使用されてもよい。

図１Ａを参照すると、データ通信システムの実施形態が、示される。データ通信システムは、概して、１つまたはそれを上回る送信機１００と、１つまたはそれを上回る受信機１５０とを含み、１つまたはそれを上回る送信機１００は、１つまたはそれを上回るデータ伝送を１つまたはそれを上回る受信機１５０に提供する。図１Ａの実施形態では、単に、１つの送信機１００および受信機１５０が、示されるが、しかしながら、本明細書に説明されるシステムおよび方法は、本開示の範囲から逸脱することなく、複数の送信機および／または受信機のために実装されてもよい。

上記に説明されるように、データ伝送１４０におけるデータは、難読化され、データ伝送をサイバー攻撃から保護する。送信機１００による伝送のためのデータの準備の間、データ変換モジュール１０２は、１つまたはそれを上回る関数およびマッピングを介して、データを難読化する。データ変換モジュール１０２は、伝送されるためのデータ（本開示では、「入力データ」と称される）と伝送されるためのデータデータパケットのためのＯＣＴＳヘッダ情報（すなわち、伝送されるためのデータデータパケットのペイロードセクションに現れるデータ）の両方を難読化する。用語「ヘッダ」および「ヘッダデータ」の使用は、本開示では、ＴＣＰ／ＩＰ等の通信プロトコルにおけるパケットのヘッダ（ルーティング情報等の情報が記憶されるであろう）の代わりに、ＯＣＴＳヘッダ情報を指すことに留意されたい。データ変換モジュール１０２は、データを難読化するプロセスを制御し（例えば、使用すべき関数およびマッピングとその順序とを判定する）、受信機がデータを難読化解除する（例えば、スクランブル解除する）ことを可能にし得る、情報を提供するように構成される、マネージャ１０４を含む。データ変換モジュール１０２はさらに、データを難読化するために使用される、３つのモジュールを含むように示される。データ変換モジュール１０２は、入力データを難読化するための入力データ難読化モジュール１０８と、データパケットのヘッダデータを難読化するためのヘッダデータ難読化モジュール１１０と、モジュール１０８、１１０からの難読化されたデータをともにマージするためのデータマージモジュール１１２とを含む。データ変換モジュール１０２は、難読化の間の使用のための複数のテーブル１０６を含んでもよい（例えば、後続図に説明されるように、キーとして）。

いったん難読化されたデータが、伝送され、受信機１５０によって受信されると、受信機１５０のデータ変換モジュール１５２は、送信機１００のデータ変換モジュール１０２において実行される難読化プロセスを反転させる。データ変換モジュール１５２は、データを難読化解除するプロセスを制御するように構成される、マネージャ１５４を含む。データ変換モジュール１５２はさらに、データを難読化解除するための３つのモジュールを含むように示される。データ変換モジュール１５２は、受信されたデータをヘッダデータ部分および入力データ部分に分割するためのデータ分割モジュール１５８と、入力データ部分を難読化解除するための入力データ難読化解除モジュール１６０と、ヘッダデータ部分を難読化解除するためのヘッダデータ難読化解除１６２とを含む。データ変換モジュール１５２は、後続図に説明されるように、難読化解除の間の使用のための複数のテーブル１５６を含んでもよい。

２つのデータ変換モジュール１０２、１５２の３つのモジュールは、独立して駆動されるように構成されてもよい。言い換えると、各モジュールは、その独自の関数、テーブル等に従って、そのデータを難読化してもよい。これは、オリジナルのエンコードされていないデータが非認可動作主によって復元されるためには、３つ全ての独立モジュールが非認可動作主によって「突破」される必要があるであろうため、非認可動作主がオリジナルのエンコードされていないデータを取得しないように防止することに役立つ。さらに、３つの独立モジュールのうちの１つがデータを難読化した方法の判定も、他の２つのモジュールの難読化の判定方法に関して何ら手掛かりを提供しないであろう。

図１Ａの実施形態では、データ変換モジュール１０２、１５２は、送信機１００および受信機１５０のそれぞれ内に示される（例えば、データ変換モジュール１０２、１５２は、送信機デバイスまたは受信機デバイス内にある）。種々の例示的実施形態では、データ通信システムの任意のタイプの構成が、可能性として考えられる（例えば、送信機１００は、難読化されるためのデータを遠隔データ変換モジュールに送信してもよく、受信機１５０は、難読化解除されたデータを遠隔データ変換モジュールから受信してもよい等）。データ変換モジュールの種々の関数は、いくつかの実施形態では、異なるコンピューティングデバイスにおいて施行されてもよい。全てのそのような変形例は、本開示の範囲内にあることが意図されることを理解されたい。

本開示は、データを難読化および難読化解除するために使用され得る、順方向マッピングおよび逆方向マッピング関数を説明する。順方向マッピング関数は、概して、入力ビットパターンの代わりに、新しいビットパターンを置換するために適用されてもよい一方、逆方向マッピング関数は、その置換を逆転させる。いくつかの実施形態では、送信機１００は、順方向マップを記憶または含有してもよく、受信機１５０は、逆方向マップを記憶または含有してもよい。当業者は、送信機が順方向マップのみを含有する必要があり、受信機が逆方向マップのみを含有する必要があることを理解するであろう。加えて、当業者は、マップの一方のみを前提として、他方のマップが、容易に導出され、したがって、単一マップのみが送信機および受信機の両方に提供されることを要求し得ることを認識するであろう。

図１Ｂを参照すると、データ記憶システム１８０の実施形態が、示される。図１Ａの実施形態では、データ難読化プロセスが、ビットデータストリームが送信機から受信機に伝送されるために説明される（例えば、「進行中のデータ」）。しかしながら、データ難読化プロセスはまた、または代替として、記憶されるためのデータに適用されてもよい（例えば、「停止中のデータ」）。図１Ｂの実施形態では、データ記憶システム１８０は、システムのメモリ（例えば、データベース１８２）内に記憶されるためのデータパケットを受信してもよい。データ記憶システム１８０は、図１Ａに説明されるように、記憶の前にデータを難読化するために、入力データ難読化モジュール１０８と、ヘッダデータ難読化モジュール１１０と、データマージモジュール１１２とを含んでもよい。さらに、データ記憶システム１８０は、データベース１８２からの読出後、データをデコードするために、データ分割モジュール１５８と、入力データ難読化解除モジュール１６０と、ヘッダデータ難読化解除モジュール１６２とを含んでもよい。データ記憶システム１８０は、データをエンコードし、読み出されたデータをデコードするプロセスを管理するための１つまたはそれを上回るマネージャを含んでもよい。本開示は、主に、伝送されるためのデータのためのデータ難読化プロセスを説明するが、本明細書におけるシステムおよび方法は、本開示の範囲から逸脱することなく、データがローカルで記憶されるために適用されてもよいことを理解されたい。さらに、本開示は、主に、データベースを説明するが、記憶装置は、データベースフォーマットである必要はない。当業者は、データベーススキーマを含有するかどうかにかかわらず、任意の形態の記憶装置が、使用されてもよいことを認識するであろう。例えば、難読化されたデータは、スタンドアロンファイル内、ファイルシステムの一部として、可撤性媒体上等に記憶されてもよい。当業者はまた、システムが、難読化および難読化解除コンポーネントを異なるマシンまたはさらに異なるネットワーク上に拡散してもよく、それらの異なるマシンおよびネットワークは、異なるエンティティによって制御されてもよいことを認識するであろう。

ここで図２−３を参照すると、送信機１００のデータ変換モジュール１０２が、より詳細に示される。データ変換モジュール１０２は、伝送されるための入力データを受信するように構成される、データ入力バッファ１１４を含む。データ入力バッファ１１４は、着信データを受け取り、必要な場合、データをフォーマットし（例えば、データを適切なサイズにフォーマットする）、エンコーディングのために、データを入力データ難読化モジュール１０８にパスする。データ入力バッファ１１４はさらに、データをマネージャ１０４に／から提供および受信してもよい。

マネージャ１０４は、データパケットが送信されるために採用されるであろう難読化のための構成を確立する、入力データ制御関数としての役割を果たすことができる。マネージャ１０４は、受信機１５０が、受信されると、データパケットをデコードすることを有効にする、識別子（例えば、１つまたはそれを上回る構成またはサブ構成）を作成する。マネージャ１０４はさらに、データの難読化において使用されるための１つまたはそれを上回るテーブルが変更されるべきであること、ハンドシェイク要求が送信または確認応答されるべきであることを示すコマンド、または難読化プロセスの設定および制御のために必要な他のコマンド等、入力データ制御コマンドをハンドリングする。マネージャ１０４は、識別子および入力データ制御コマンドをヘッダ難読化モジュール１１０にヘッダ情報の一部として提供してもよい。マネージャ１０４はさらに、乱数生成器（ＲＮＧ）１１６を含む、または使用してもよい。ＲＮＧ１１６は、いくつかの実施形態では、擬似ＲＮＧ（ＰＲＮＧ）であってもよい。ＲＮＧ１１６は、入力データ難読化モジュール１０８において入力データの難読化の間に使用すべきテーブルおよび／または関数を判定するために、識別子を作成するために使用されてもよい。ＰＲＮＧはまた、データを用いた排他的ＯＲ（ＸＯＲ）のため等の難読化関数のために、入力データ難読化モジュール１０８によって使用され得る、擬似乱数のストリームを生成するために使用されてもよい。

マネージャ１０４は、種々のレベルの精巧化を有してもよい。一実施形態では、マネージャ１０４は、ハードコード化されたパススルーとして実装されてもよい。言い換えると、マネージャ１０４は、決定を行わない、または任意のオプションを有していなくてもよく、単に、入力を受信し、自動的に、出力を生成してもよい（すなわち、データを受信する、データをＲＮＧ１１６の中に挿入する、および結果として生じるランダム化されたデータを出力する）。他の実施形態では、マネージャ１０４は、より精巧化され、値をランダムに生成する方法、難読化プロセスのためにデータ変換モジュール１０２を構成する方法等を判定するために使用され得る、複数の関数およびパラメータを受信してもよい。マネージャ１０４は、関数およびパラメータを、複数のサーバもしくは他のソースから、またはデータ変換モジュール１０２内の単一ソースから受信してもよい。マネージャ１０４は、マネージャにおいて受信されたデータの量に基づいて、難読化の複雑性を増加させることが可能であってもよい。

入力データ難読化モジュール１０８は、難読化のためにデータに適用可能な複数の関数１２４を含んでもよい。入力データ難読化モジュール１０８は、任意の数の関数１２４を含んでもよい（すなわち、モジュール１０８によって使用される関数の数、タイプ、および順序は、固定されてもよい、またはマネージャ１０４によって選定される値もしくは識別子および他の設定もしくはプロパティに基づいて、ランダムに変動してもよい）。例えば、入力データ難読化モジュール１０８によって使用される関数１２４は、伝送されているデータのためのユーザ要件、データのタイプ、データが関連する用途、および／またはデータの伝送のために利用可能なリソースに基づいて、選定されてもよい。

ヘッダ難読化モジュール１１０は、ヘッダ情報を難読化するための複数の関数を含む。例えば、ヘッダ難読化モジュール１１０は、ヘッダデータ内のビットをスワップするように構成される、１つまたはそれを上回るスクランブリング関数１１８を含む。さらに、ヘッダ難読化モジュール１１０は、伝送されるためのデータデータパケット内の入力データビットの代わりに、新しいビットパターンを置換するように構成される、１つまたはそれを上回る順方向マッピング関数１２０を含んでもよい。データ変換モジュール１０２は、入力をヘッダ難読化モジュール１１０の種々の関数に提供するように構成される、ヘッダ情報マネージャ１２６を含むように示される。

入力データが、入力データ難読化モジュール１０８によって難読化され、ヘッダデータが、ヘッダ難読化モジュール１１０によって難読化された後、データマージモジュール１１２は、２つのデータセットをともにマージする。データマージモジュール１１２は、両データセットからのビットをスクランブルし、２つのデータセットをともに連結するために、スクランブリングモジュール１２８と、連結モジュール１３０とを含む。マージされたデータは、受信機１５０への伝送のために、エンコードされたデータ出力バッファ１３２に提供される。

より具体的には、図３を参照すると、データ変換モジュール１０２の機能性が、より詳細に示される。実線は、データが難読化され、受信機１５０に伝送されるためのデータパスを表す。データは、データ入力バッファ１１４において受信され、エンコーディングのために、入力データ難読化モジュール１０８に提供される。さらに、エンコードされたヘッダ情報が、ヘッダ難読化モジュール１１０によってデータマージモジュール１１２に提供されるように示される。破線は、データ制御パスを表し、情報は、データを難読化する方法（例えば、使用すべき関数、使用すべきテーブル等）を判定するために使用される。点破線は、ヘッダ情報マネージャ１２６とヘッダ難読化モジュール１１０の種々の関数との間の制御パスを表す。

ここで図４−５を参照すると、受信機１５０のデータ変換モジュール１５２が、より詳細に示される。概して、データ変換モジュール１５２の種々のコンポーネントは、データ変換モジュール１０２のコンポーネントの反転である（すなわち、データを難読化解除するために、データを難読化するために使用されたものと同一の一般的プロセスを使用する）。データ変換モジュール１５２は、エンコードされたデータを受信し、データをデータ分割モジュール１５８に提供するように構成される、エンコードされたデータ入力バッファ１６４を含む。データ分割モジュール１５８は、スクランブリング解除モジュール１６６（スクランブリング関数１１８によってスクランブル解除されたビットをスクランブル解除するため）および分割モジュール１６８（ヘッダデータを入力データから分離するため）を介して、データを分割する。データ分割モジュール１５８は、入力をヘッダ情報マネージャ１５４から受信し、データ分割プロセスのための関連情報を判定する（例えば、データの難読化の間に使用されたテーブルについての情報を含む、データの部分を識別するため）。

一実施形態では、受信機１５０は、受信機によって認識可能なフォーマットでエンコーディングおよびフォーマットされる、データパケットを受信してもよい。例えば、パケットは、ＯＣＴＳでエンコードされてもよい。受信されたパケットが、ＯＣＴＳパケットではない場合、データパケットのさらなる処理は、受信機のために要求されない。しかしながら、パケットのいくつかの処理が、データ分割モジュール１５８において、データパケットがＯＣＴＳであるかどうかを判定するために要求されてもよい。データ分割モジュール１５８（または受信機１５０の別のモジュール）は、パケットがＯＣＴＳパケットであるかどうかを判定するための検証モジュール１６９を含んでもよい。検証モジュール１６９は、例えば、１つまたはそれを上回るフィールド（例えば、以下に説明されるようなクイックルックフィールドおよびチェックサムフィールド）をチェックし、パケットがＯＣＴＳパケットであるかどうかを選別してもよい。データ分割モジュール１５８は、ＯＣＴＳパケットである場合、さらなる処理をデータパケットに実施し、パケットがスクランブリング解除およびデコードされることを可能にしてもよい。

分割されたデータは、マネージャ１７８に提供される。ヘッダデータおよびオリジナルメッセージは両方とも、本時点では、依然として難読化されたままである。マネージャ１７８は受信されたデータパケットのために入力データ難読化モジュール１０８によって使用された難読化のための構成を判定する。マネージャ１７８はさらに、ＰＲＮＧ１８２を含んでもよい。ＰＲＮＧ１８２は、一実施形態では、図２のＲＮＧ１１６に類似する、擬似乱数生成器であってもよい。例えば、ＲＮＧ１１６が、ＰＲＮＧである場合に、同一シード値が、ＲＮＧ１１６およびＲＮＧ１８２内で使用される場合、ＲＮＧ１１６およびＲＮＧ１８２からの出力は、同一であろう。難読化されたヘッダデータは、ヘッダ難読化解除モジュール１６２に転送される。ヘッダ難読化解除モジュール１６２は、１つまたはそれを上回るスクランブリング解除関数１７０と、１つまたはそれを上回る逆方向マッピング関数１７４とを含み、後続図に説明されるように、ヘッダデータを難読化解除する。ヘッダ難読化解除モジュール１６２は、データ変換モジュール１０２によってデータを難読化するために使用された関数のタイプおよび数に関連する構成情報をマネージャ１７８に返す。情報は、難読化された入力データとともに、入力データ難読化解除モジュール１６０に転送される。マネージャ１７８によって判定された構成情報に基づいて、入力データ難読化解除モジュール１６０は、１つまたはそれを上回る関数１７６（送信機１００において入力データに適用された関数１２４に関連し得る）を適用し、データを難読化解除してもよい。入力データ難読化解除モジュールの結果は、記憶され、次いで、データ出力バッファ１８０内で利用可能にされる。

概して、図２および４を参照すると、ＲＮＧ１１６、１８２が、マネージャ内に実装されるように示される。他の実施形態では、ＲＮＧ関数は、データ変換モジュール１０２、１５２の他のモジュールのいずれか内に実装されてもよい。送信機１００が、真乱数生成器を使用する（ＰＲＮＧの代わりに）場合、ＲＮＧの出力は、受信機が、データを難読化解除するために、出力を受信する必要があるため、受信機１５０に送信されるべきである。送信機１００が、ＰＲＮＧを使用する場合、受信機１５０は、ＰＲＮＧへの入力を前提として、ＰＲＮＧと同一値を生成可能であってもよい。

より具体的には、図５を参照すると、データ変換モジュール１５２の機能性が、より詳細に示される。図３と同様に、実線は、データ変換モジュールによって難読化解除されるための入力データおよびヘッダデータのためのデータパスを表す。データは、エンコードされたデータ入力バッファ１６４において受信され、データ分割モジュール１５８に提供され、これは、順に、上記に説明されるように、データを２つの難読化解除モジュール１６０、１６２に提供する。破線は、データパス制御パスを表し、情報は、データを難読化解除する方法（例えば、使用すべき関数、使用すべきテーブル等）を判定するために使用される。点破線は、ヘッダ情報マネージャ１５４とヘッダ難読化解除モジュール１６２の種々の関数との間のヘッダ制御パスを表す。

概して、図６−１１を参照すると、ヘッダ難読化プロセスの一実施形態が、より詳細に説明される。より具体的には、ヘッダ難読化モジュール１１０および送信機１００のデータ変換モジュール１０２のアクティビティならびにヘッダ難読化解除モジュール１６２および受信機１５０のデータ変換モジュール１５２のアクティビティが、より詳細に説明される。最初に、ヘッダ情報は、システムの動作において多くの目的を果たし得ることに留意されたい。例えば、ヘッダ情報は、制御情報を送信機１００と受信機１５０との間でパスするための情報パスとして使用されてもよい。ヘッダ情報はまた、具体的受信機のために意図されるデータのパケットを識別し、したがって、他の受信機のために意図されるパケットを拒否するために使用されてもよい。このように、ヘッダ情報は、具体的割り当てられたセキュア化されたネットワークの中へのエントリを得るために使用されることができる。ヘッダ情報はまた、パケットが本発明の側面に従ってエンコードされたものではないことが保証されるかどうかを判定するために使用されてもよい。そのような判定は、パケットが本発明の側面に従ってエンコードされていないことを判定することが、受信機１５０がデコーディングステップを完全にバイパスすることを可能にするため、受信機１５０において有用であり得る。これは、無駄にされるコンピューティングサイクルを防止する。加えて、ヘッダ情報は、エンコードされた入力データの難読化解除を有効にするために必要な情報を含有してもよい。一般に、ヘッダ情報は、パケットのサイズと比較して比較的に小さい。例えば、一実施形態では、ヘッダ情報は、２０バイト未満である一方、パケットは、１，５００バイトを含有してもよい。

ヘッダ難読化モジュール１１０は、概して、ヘッダ情報を難読化し、意図される受信者以外の任意の者がデータを使用または閲覧する能力を否定する。ヘッダ難読化モジュール１１０は、入力データの難読化のため、またはデータマージのために使用されるものと異なる一意の関数のセットを使用し、全体的難読化プロセスの複雑性を増加させてもよい。代替として、難読化モジュール１１０は、データ変換モジュールの他のモジュールと同一難読化関数を使用してもよい。難読化モジュール１１０は、例えば、１つまたはそれを上回る置換またはマッピング関数（例えば、第１のビットパターンを第２のビットパターンで置換する）、１つまたはそれを上回るホワイトニング関数、および／または１つまたはそれを上回る転置関数を使用してもよい。これらの関数は、後続図により詳細に説明される。

ここで図６Ａを参照すると、送信機１００のヘッダ難読化モジュール１１０のブロック図が、示される。ヘッダ難読化モジュール１１０の出力は、送信機が同じメッセージを再伝送または送信するように強制される場合、出力を繰り返さないように設計される。言い換えると、ヘッダ難読化モジュール１１０の各出力は、ヘッダ情報が同一であるかどうかにかかわらず、一意であるべきである。

図６Ａの実施形態では、２つのタイプの難読化関数が、図示される。ヘッダ難読化モジュール１１０は、ヘッダ情報ビットスクランブリング関数２０６と、ヘッダ情報順方向マッパ２１２とを含む。他の実施形態では、ヘッダ難読化モジュール１１０は、任意の数の一意の関数を含んでもよい。

ヘッダ情報ビットスクランブリング関数２０６は、概して、設定数のビット内でビットをスワップするように構成される。例えば、関数２０６は、１６ビット内の任意の単一ビットをワード内の任意の他の場所に移動する能力を用いて、かつ反転関数を実施する（例えば、受信機において）または各ビットをそのオリジナル場所に返す能力を用いて、ビットを１６ビットワード内でスワップしてもよい。ビットのグループをスワップする関数が、使用されてもよく、スワップされているビットのグループサイズおよび場所は両方とも、スワップのレベルおよび場所によって定義される。概して、図７−９を参照すると、１つのそのような例示的関数は、１６ビットワードに関して図示される。１６ビットを伴う実施例が、図７−９に示されるが、種々の実施形態では、スワップ関数は、任意の数のビットのために適用可能であってもよいことを理解されたい。

図７の実施形態では、１６ビットワードのためのスワップ関数が、示され、ワードの各要素は、［０，１５］としてインデックス化される。本関数は、３つのレベルの数を定義し、レベル０スワップ、レベル１スワップ、レベル２スワップ、およびレベル３スワップをもたらす。レベル３では、ビットは、それぞれ、８ビットの２^１＝２グループにグループ化され、レベル２では、ビットは、それぞれ、４ビットの２^２＝４グループにグループ化される等となる。同様に長さ１６ビットのスクランブリングキー２２４（図８−９に示される）が、事前に交換される、初期化プロセスの間に交換される、またはＲＮＧ１１６によって生成されてもよい。スクランブリングキー２２４の１６ビットは、入力ワードのビットがスクランブルされる方法を判定する。

例えば、図７に示されるように、レベル３スワップは、スクランブリングワードのビット０によって駆動されるように示される。スクランブルキー２２４のビット０が、１である場合、ビット［０，７］および［８，１５］の２つのグループ間のスワップは、実施される。スクランブルキー２２４のビット０が、０である場合、スワップは、実施されないであろう。レベル２スワップは、スクランブルキー２２４のビット１および２によって駆動されるように示される。スクランブルキー２２４のビット１が、１である場合、２つのグループ［０，３］と［４，７］との間のスワップは、実施される。スクランブルキー２２４のビット２が、１である場合、２つのグループ［８，１１］と［１２，１５］との間のスワップは、実施される。本プロセスは、示されるように、各レベルおよびビットを通して繰り返される。図８を参照すると、関数２０６によって受信された入力ワード２２０に関して、スクランブル解除されたワード２２２が、生成される。各強調されるエリアは、スワップが１の値を有するスクランブルキー２２４のビットに基づいて生じた場所を図示する。例えば、ビット０が１であったため、スワップが、ビット［０，７］と［８，１５］との間で実施された。スワップ関数は、レベル３から開始し、レベル０まで作用する。図７−９に示されるように、１４のスワップのみが、必要であって、したがって、スクランブルキー２２４のビット１５は、無視されることに留意されたい。

図９を参照すると、ビットワード２２０のスクランブリング解除が、示される（図６Ｂを参照して以下に説明されるように、ヘッダ難読化解除モジュール１６２において実施される）。ビットワード２２０をスクランブル解除するプロセスは、反転されてもよい、すなわち、最初に、ビット１４から開始し（図７に示されるように、ビット１５は、無視される）、レベル０スワップを適用し、ビット０まで、レベル０スワップが適用されるであろう。

再び、図６Ａを参照すると、ヘッダ情報順方向マッパ２０８（および図６Ｂの逆方向マッパ２５８）が、ヘッダ難読化プロセスにおいて使用される。概して、「順方向マップ」および「逆方向マップ」は、ヘッダ難読化プロセスのマッピング関数のためのベクトルペアとして提供される。順方向マップは、ヘッダをエンコードするための関数を提供し、逆方向マップは、ヘッダをデコードするための関数を提供する。順方向マッピング関数は、ヘッダ値の一部または全部のための新しい値を置換する。逆方向マップは、エンコードされた値をそのオリジナル値に返すために使用される。

順方向マッパ２１２および逆方向マッパ２５８は、合致される。使用されるマップは、基本マップ（例えば、単一値と固定の新しい値の事前に設定されたマッピング）、単一変数の関数として駆動されるデータ駆動マップ、または複数の変数の関数として駆動されるデータ駆動マップであってもよい。マップの複雑性のレベルは、所望の保護のレベルに基づいて増加してもよい。マッピングは、図１３−１４を参照してより詳細に説明される。

マネージャ１０４によってヘッダ難読化モジュール１１０（したがって、図６Ａに示される関数２０６、２１２）にパスされた情報は、データをエンコードするためにデータパスにおいて現在使用中の構成およびテーブルを識別する、１つまたはそれを上回るテーブル識別子および／または制御情報を含んでもよい。情報は、具体的ＯＣＴＳ（最適化されたコードテーブルシグナリング）構成に依存してもよい。通信プロセス管理のための情報はまた、制御情報の一部として含まれてもよい。マネージャ１０４によってヘッダ難読化モジュール１１０にパスされた情報はさらに、ＲＮＧ１０６からの出力または使用されるＲＮＧシーケンスの出力から導出される入力を含んでもよい。マネージャ１０４によってヘッダ難読化モジュール１１０にパスされた情報はさらに、ヘッダ難読化モジュール１１０によってヘッダデータをエンコードするために必要とされる、フレーム長（可変であり得る、フレーム長のサイズを識別するため）または任意の他の情報を含んでもよい。また、図１０を参照すると、テーブルは、マネージャ１０４によってヘッダ難読化モジュール１１０に提供され得る、ある情報を識別するように示される。情報はさらに、チェックサムまたはクイックルック入力を含み、伝送のためのデータを検証するため（すなわち、受信されたフレームがデータ変換モジュールのための意図されたものであることを確実にする、ヘッダメッセージが正確なおよびアドレス指定されていることを検証するため等）に使用されてもよい。図１０に示されるフィールドは、ヘッダ情報内に含まれ得る、例示的フィールドとして提供される。より一般的には、ヘッダ情報は、メッセージをデコードするために必要な情報を含み、テーブルＩＤ、送信機によって使用されるマッピングテーブルを識別する構成フィールド、システム構成情報、１つまたはそれを上回るランダム抽出値（単に、スクランブルワードの代わりに）、データサイズフィールド（難読化されたデータの量を示す）、および／または随意のフレーム長（以下に説明されるように、ダミーデータを識別するために使用され得る）等の情報を含んでもよい。ヘッダ難読化モジュール１１０は、異なる技法を使用して、ヘッダデータの各フィールドを難読化してもよい。前述の開示は、ヘッダ内でパスされ得る情報のタイプの限定を意味するものではなく、当業者は、他の情報も、必要に応じて、情報をデコーダに提供し、メッセージが適切にデコードされたことを確実にするためにヘッダ内に含まれ得ることを認識するであろう。

より具体的には、クイックルックフィールドを参照すると、フィールドは、伝送されたデータパケットが本明細書に開示される種々の実施形態によってエンコードされたタイプではなかったかどうかを迅速に判定する使用されてもよい。例えば、クイックルックフィールドは、データパケットがＯＣＴＳ構成を有するかどうかを判定するために使用されてもよい。これは、ＯＣＴＳを使用してエンコードされたパケットが、ＯＣＴＳでエンコードされていないパケットとネットワーク上に共存することを可能にする。受信されたパケット毎に、ネットワークデバイスは、クイックルックフィールドを使用して、パケットがＯＣＴＳパケットではないかどうかを判定することができる。該当しない場合、次いで、さらなるＯＣＴＳ処理は、必要ではなく、パケットは、パケットがハンドリングされる従来の方法でハンドリングされる。しかしながら、クイックルックフィールドが、パケットがＯＣＴＳでエンコードされたパケットであり得ることを示す場合、さらなる処理が、必要である。一実施形態では、クイックルックフィールドは、ＸＯＲ関数を使用して生成されてもよい。例えば、クイックルックフィールドは、テーブル識別子のうちの２つ等、ヘッダの２つの他の部分のＸＯＲ関数の結果であってもよい。速度および効率のために、クイックルックフィールド自体は、難読化される必要はなく、ヘッダの難読化された部分のＸＯＲ関数の結果であってもよい。このように、いったんクイックルックフィールドの場所およびＸＯＲに入力されるであろうフィールドが、受信および識別されると、単一ＸＯＲおよび単一比較が、迅速に実施され、パケットがさらなる処理を要求し得るかどうかを判定することができる。データパケットを受信する受信機は、クイックルックフィールドをチェックし、データパケットが適切なフォーマット（例えば、ＯＣＴＳ構成）であるかどうかを判定してもよい。種々の実施形態では、ＸＯＲ関数以外の関数が、クイックルックフィールドを作成するために使用されてもよい。

より具体的には、チェックサムフィールドを参照すると、フィールドは、ヘッダ難読化の間、難読化されてもよい。チェックサムフィールドは、概して、伝送、記憶の間、エラーを検出する、またはパケットを１つの本開示の技法を使用してエンコードされたものとして選別するために使用されてもよい。チェックサムフィールドは、チェックサムを作成するために周知の方法のいずれかを使用して、送信機１００において難読化されたデータの全てまたはデータのいくつかのサブセットに基づいて作成されてもよい。例えば、チェックサムは、クイックルックフィールドを除き、伝送されるための全てのデータを使用することによって計算されてもよい。チェックサム関数は、データセットのためのチェックサムを計算可能であるべきであって、難読化関数は、データパス難読化関数から一意であって、入力変数の数は、異なり、使用される関数は、ランダム変数によって判定され、各要素は、難読化関数によって駆動される少なくとも１つの変換を受ける。受信機は、その独自のチェックサムを受信されたデータパケットの難読化解除されたヘッダデータで計算し、パスされたチェックサムに合致するかどうか確認してもよい。種々の実施形態では、送信機は、受信機が伝送の間にエラーが存在するかどうかまたは提供される情報に悪意があるかどうかを判定することを可能にする、情報をヘッダ内に提供するための任意の他のタイプのエラー検出方法を使用してもよい。例えば、受信機は、データサイズが許容可能境界内にあるかどうかをチェックしてもよく、これは、伝送の間のエラーまたは受信機に分析を受信されたものより大きいデータバッファに実施させるための悪意のある試みのいずれかを示し得る。

ヘッダ情報内の各フィールドは、具体的かつ定義された数のビットを含んでもよい。ビットは、受信機がデータ難読化解除の間、ヘッダ情報を識別し得るように定義されてもよい。例えば、データＩＤは、７ビット、スクランブルワードは、４ビット、クイックルックフィールドは、１６ビット、チェックサムは、１６ビット等であってもよい。ヘッダは、任意の方法でフォーマットされてもよく、ヘッダが受信機によって識別可能である限り、任意の数のフィールドのための任意の数のビットを含んでもよいことを理解されたい。

ヘッダ情報ビットスクランブリング関数２０６およびヘッダ情報順方向マッパ２１２は、ヘッダ情報およびＰＲＮＧ値をヘッダ情報マネージャ１２６から読み出す。ヘッダデータおよびＰＲＮＧ値は、使用すべきマッピング関数のタイプ（例えば、使用すべき１つまたはそれを上回る順方向マッピング関数２０８）を定義してもよく、さらに、受信機によって難読化されたデータのヘッダ部分を識別するために使用され得る、識別情報を含んでもよい。図６Ａに示されるように、１つまたはそれを上回る順方向マッピング関数２０８が、選択され、データを難読化する際に使用するために、ヘッダ情報ビットスクランブリング関数２０６に提供されてもよい。関数の選択は、ヘッダ情報マネージャ１２６から読み出される情報に基づいてもよい。

図６Ａを依然として参照すると、ヘッダ情報が、ヘッダ情報ビットスクランブリング関数２０６によってスクランブルされた後、ヘッダ情報順方向マッパ２１２は、難読化されたヘッダデータをマップするように構成される。順方向マッパ２１２は、テーブルルックアップと同様に単純であってもよい、またはローリングオフセットを使用したデータ駆動マッピングを採用してもよい。順方向マッパ２１２は、ビットスクランブリング関数２０６から独立して、第２の独立難読化関数として提供される。データが、マッピングによって難読化された後、データは、エンコードされたヘッダ情報２１４として、データ変換モジュールの別のモジュールに提供されてもよい（入力データと組み合わせるため）。

ここで図６Ｂを参照すると、受信機１５０、より具体的には、ヘッダ難読化解除モジュール１６２のアクティビティが、より詳細に示される。上記に説明されるように、ヘッダ難読化解除モジュール１６２は、概して、送信機１００のヘッダ難読化モジュール１１０によって実施されるデータ難読化を逆転させてもよい。エンコードされたヘッダ情報２１４は、送信機１００から受信され、エンコードされたデータをエンコードされたヘッダ情報およびエンコードされた入力データに分割するために、データ分割モジュール２５４に提供される。ヘッダ情報マネージャ２５６は、エンコードされたヘッダ情報を受信し、データを難読化するために使用された関数または方法と関連付けられたパラメータとともに、１つまたはそれを上回る関数または方法を判定してもよい。ヘッダ難読化解除モジュール１６２は、ヘッダデータに適用されるマッピング関数を逆転するためのヘッダ情報逆方向マッパ２５８と、ヘッダデータに適用されるビットスクランブリング関数を逆転するためのヘッダ情報ビットスクランブリング解除関数２６０とを含む。

ここで図１１Ａを参照すると、例示的実施形態による、ヘッダ情報をエンコードするためのプロセス３００のフローチャートが、示される。プロセス３００は、例えば、ヘッダ難読化モジュール１１０によって実行されてもよい。プロセス３００は、ヘッダ情報（３０２）およびＰＲＮＧ値（３０４）を受信することを含む。受信されたヘッダ情報は、単に、エンコードされ、受信機に伝送されるためのデータパケットに関連する情報を含んでもよい。ＰＲＮＧ値は、ヘッダデータ値に基づいて擬似ランダムに生成された値を含んでもよい。プロセス３００はさらに、データをヘッダ情報に追加し、受信機によるデータ情報のデコーディングを有効にすることを含む（３０６）。

プロセス３００はさらに、ＰＲＮＧ値を使用して、ヘッダ情報を難読化するための１つまたはそれを上回るパラメータを判定することを含む（３０８）。上記に説明されるように、ヘッダは、ビットまたはバイトスワッピング関数、マッピング関数のために使用すべきルックアップテーブル、使用すべきマッピングまたはスクランブリングのタイプ、マップまたはスクランブルするためのヘッダ要素、および同等物を識別してもよい。ヘッダ情報を難読化する方法を識別後、識別された１つまたはそれを上回る関数は、ヘッダ情報を難読化するために使用される（３１０）。例えば、また、図７−９を参照すると、データを難読化するために使用され得る、関数の一実施例は、ビットスワッピング関数である。種々の実施形態では、関数は、データ変換モジュールによって識別されてもよい、または関数のうちの１つまたはそれを上回るものは、特定の顧客または用途のための一意の関数セットであってもよい（例えば、特定の顧客は、特定のタイプの難読化関数を使用して、個人またはクライアントが、その独自の個人化された保護をデータセットに追加することを可能にする）。ヘッダデータ自体は、単一関数を使用して難読化されてもよいが、また、ヘッダの異なる部分が異なる関数を使用して難読化される、複数の関数を使用して難読化されてもよい。加えて、ヘッダのいくつかの部分は、難読化されないままであってもよい、またはある用途では、ヘッダを難読化する必要が全くない場合がある。

プロセス３００はさらに、順方向マッピング関数（３１２）を使用して、さらにヘッダデータを難読化することを含む。順方向マッピング関数は、例えば、ブロック３０８において識別された関数であってもよい。難読化されたヘッダ情報は、次いで、入力データとのスクランブリングおよび連結のために、別のモジュールに提供される（３１４）。上記に説明されるように、入力データおよびヘッダデータは、２つの異なるモジュールにおいて別個に難読化され、次いで、第３のモジュールにおいて組み合わせられ、スクランブルされる。

ここで図１１Ｂを参照すると、例示的実施形態による、ヘッダ情報をデコードするためのプロセス３５０のフローチャートが、示される。プロセス３５０は、例えば、ヘッダ難読化解除モジュール１６２によって実行されてもよい。プロセス３５０は、エンコードされたデータパケットを送信機から受信すること（３５２）と、データパケットをヘッダ部分および入力データ部分に分割すること（３５４）とを含む。例えば、ブロック３５４は、概して、エンコードされたデータパケットを分割およびスクランブル解除することによって、ヘッダ情報を識別するステップを含む。プロセス３５０はさらに、ヘッダ情報を検証すること（３５６）を含む。再び、図１０を参照すると、ヘッダ情報の検証は、概して、チェックサム値をチェックすること、クイックルックフィールドを確認し、受信機が意図される受信者であるかどうかを判定すること等を含んでもよい。

プロセス３５０はさらに、データパケットをエンコードするために使用される、１つまたはそれを上回る難読化関数を識別することを含む（３５８）。例えば、受信機１５０のマネージャ１７８は、依然として難読化されたままのヘッダ情報を精査し、乱数をＰＲＮＧから取得してもよい。マネージャ１７８は、ヘッダ情報を介して送信機１００のＰＲＮＧによって使用されるシード値を判定し、同一シード値をそのＰＲＮＧのために使用してもよい。これは、ヘッダ難読化解除モジュール１７０が、送信機１００によってデータを難読化するために使用される関数を複製することを可能にし得る。プロセス３５０はさらに、ヘッダ情報をスクランブル解除および逆方向マップすること（３６０）を含む。いったんヘッダ情報が、難読化解除されると、ヘッダ内の情報は、入力データを難読化解除するために使用されてもよい（後続図により詳細に説明される）。

概して、図１１Ｃ−Ｄを参照すると、ヘッダ情報をエンコードおよびデコードするプロセスは、より技術的詳細に示される。図１１Ｃは、ヘッダ情報をエンコードするための一実施形態を図示する。プロセスは、ＰＲＮＧシーケンスを用いたヘッダ情報のＸＯＲを含む（３７０）。ＰＲＮＧシーケンスは、データ変換モジュールのマネージャによって擬似ランダムに生成されたデータのシーケンスである。プロセスはさらに、チェックサムを計算すること（３７１）と、チェックサムをマップすること（３７２）とを含む。ブロック３７１−３７２は、概して、伝送されるための全てのヘッダデータのためのチェックサムを計算し、伝送のためのチェックサムフィールドを難読化することを含んでもよい。プロセスはさらに、データテーブル識別子およびデータサイズフィールドのためのビットスクランブリング関数（３７３）と、フィールドのマッピング（３７４）とを含む。プロセスはさらに、各ランダム抽出をマップすること（３７５）を含む。例えば、ブロック３７５は、図１０に示されるように、ワード１およびワード２フィールドをマップすることを含む。プロセスはさらに、上記に説明されるように、クイックルックフィールドを計算すること（３７６）を含む。プロセスはさらに、ヘッダデータを他の難読化されたデータと連結し、２つのデータセットをともにスクランブルすること（３７７）を含む。

図１１Ｄは、ヘッダ情報をデコードするための一実施形態を図示する。概して、デコーディングプロセスは、単に、エンコーディングプロセスの反転であってもよい。プロセスは、ヘッダデータをスクランブル解除し、他の難読化されたデータから分離すること（３８０）を含む。プロセスはさらに、クイックルックフィールドをチェックし、ヘッダがＯＣＴＳヘッダ（またはデータの受信機が受信することを予期する別のヘッダタイプ）であるかどうかを検証すること（３８１）を含む。逆方向マッピングは、ヘッダの検証に応じて、各ランダム抽出（３８２）および種々のデータフィールド（３８３）に適用される。プロセスはさらに、データテーブル識別子およびデータサイズフィールドをスクランブル解除すること（３８４）を含む。プロセスは、次いで、チェックサムを逆方向マップすること（３８５）と、チェックサムを使用して、ヘッダデータにエラーがないことを検証すること（３８６）を含む。

概して、図１２−２５を参照すると、入力データ難読化プロセスの一実施形態が、より詳細に説明される。より具体的には、入力データ難読化モジュール１０８および送信機１００のデータ変換モジュール１０２のアクティビティならびに入力データ難読化解除モジュール１６０および受信機１５０のデータ変換モジュール１５２のアクティビティが、より詳細に説明される。入力データは、概して、送信機１００によって受信機１５０に伝送されるために所望されるデータである。入力データは、送信機１００によってエンコードされるように構成される、任意のサイズまたはタイプであってもよい。入力データ難読化モジュールは、概して、入力データを難読化し、意図される受信者以外の任意の者がデータを使用または閲覧する能力を否定する。入力データ難読化モジュールは、ヘッダデータの難読化またはデータマージのために使用されるものと異なる一意の関数のセットを使用するか、またはヘッダデータ難読化および／またはデータマージのために使用されるものと同一の一意の関数のセットを使用するかのいずれかであってもよい。

ここで図１２Ａを参照すると、送信機１００の入力データ難読化モジュール１０８のブロック図が、示される。入力データ難読化モジュール１０８は、概して、入力データマネージャ４０２によって送信されるためのデータおよびデータの伝送のために利用可能なリソースのための要件に最良に合致するように選定され得る、関数のセットを含む。入力データマネージャ４０２は、データを難読化し、データ難読化プロセスを初期化および更新するために使用すべき関数を判定するように構成される。入力データマネージャ４０２は、関数および関数のための１つまたはそれを上回るパラメータをランダムに選択するために使用され得る、ＲＮＧ（例えば、図２に説明されるようなＲＮＧ１１６）を含んでもよい。ＲＮＧが、使用される場合、生成された選択は、受信機にパスされる必要がある一方、ＰＲＮＧは、送信機および受信機が同一シードを使用して同一擬似乱数を生成し得るように使用され得る。加えて、ＰＲＮＧは、ＸＯＲ関数またはビット置換またはビット転置関数において使用すべき一連のビットを生成するために使用されてもよい。

入力データ難読化モジュール１０８は、任意の数の関数を実装してもよい。例えば、図１２Ａに示されるように、第１の難読化関数４０４、第２の難読化関数４０６、最大ｎ番目の難読化関数４０８が、入力データに連続して適用されてもよい。入力データマネージャ４０２は、入力を各関数に提供し、関数の１つまたはそれを上回るパラメータを制御してもよい。使用され得る、データ難読化関数または方略のいくつかの実施例は、置換またはマッピング（例えば、入力データ内の第１のビットパターンを第２のビットパターンで置換する）、ホワイトニング（例えば、エンコードされたデータストリームの統計を均一分布確率関数に変換する）、および転置（例えば、入力データの２つまたはそれを上回る要素の交換）を含む。本開示は、そのような関数の種々の実施例を提供するが、他の実施形態では、これらの関数または他の難読化関数の任意のタイプの変形例が、本明細書に説明されるシステムおよび方法と併用されてもよいことを理解されたい。

ここで図１２Ｂを参照すると、受信機１５０、より具体的には、入力データ難読化解除モジュール１６０のアクティビティが、より詳細に示される。入力データ難読化解除モジュール１６０は、概して、送信機１００の入力データ難読化モジュール１０８によって実施される入力データ難読化を逆転させてもよい。ヘッダ難読化解除モジュール１６２は、上記に説明されるように、エンコードされたヘッダ情報およびエンコードされた入力データを受信されたエンコードされたデータから識別してもよい。マネージャ４２０は、エンコードされた入力データ部分を受信し、データを元々エンコードするために使用された１つまたはそれを上回る関数および関数のためのパラメータを判定してもよい。他の実施形態では、マネージャ４２０は、単に、エンコードされた入力データ部分の受信に応じて関数コールを行う、より受動的モジュールであってもよい。入力データ難読化解除モジュール１６０は、次いで、データをエンコードするために送信機１００によって使用される関数に関連する（例えば、その反転である）、入力難読化解除モジュール４２２、４２４、４２６等を使用して、データをデコードしてもよい。入力データ難読化解除モジュール１６０は、受信機１５０による使用のためのデコードされた入力データ４２８を出力する。

概して、図１３−２０を参照すると、マッピング関数の種々の実施例が、より詳細に示される。マッピング関数は、データを難読化するために、入力データ（またはヘッダデータ）に適用可能であってもよい。本開示に提供される実施例は、一例にすぎず、他のマッピング関数または置換方法も、データを難読化するために使用されてもよく、マッピング関数または置換方法の任意の組み合わせが、使用されてもよいことを理解されたい。

図１３を参照すると、基本マッピング関数が、図示される。図１３は、入力データをエンコードするための順方向マッピングテーブルと、入力データをデコードするための逆方向マッピングテーブルとを図示する。順方向マッピングテーブルが、入力データ難読化モジュール１０８によって使用されてもよい（難読化関数４０２、４０４、または４０６として）一方、逆方向マッピングテーブルは、入力データ難読化解除モジュール１６０によって使用されてもよい。図１３の順方向マップおよび逆方向マップは、以下のように、ベクトルペアとして提示されてもよい。
‘順方向マップ’＝｛０１０ １００ ０１１ １０１ ００１ １１１ ０００ １１０｝
‘逆方向マップ’＝｛１１０ １００ ０００ ０１０ ００１ ０１１ １１１ １０１｝

図１３の実施例では、入力値のエンコードされた値は、入力値を順方向マッピングベクトル内のインデックスとして使用して見出される。例えば、順方向マッピングにおけるインデックス４内の要素は、１（１０進数では、１、２進数では、００１）であって、オリジナルデータ内のインデックス４に元々位置する要素が、ここでは、エンコードされたデータ内のインデックス１にあることを意味する。逆方向マップを介したデコーディングに関して、インデックス１は、４にマップされ、エンコードされたデータ内のインデックス１に位置する要素がインデックス４に返されることを意味する。言い換えると、ｅｎｃｏｄｅ（４）＝１およびｄｅｃｏｄｅ（１）＝４である。順方向マップおよび逆方向マップは、相互交換可能であってもよい、すなわち、順方向マップおよび逆方向マップは、反転され、反対マップとして使用されてもよい。

順方向マップが、例えば、ベクトル要素を並べ替えるように構成される、シャッフル関数を使用して作成されてもよい。一実施形態では、シャッフル関数は、上記に説明されるように、ＲＮＧまたはＰＲＮＧによって駆動される。具体的インデックスにマップされるｎ−要素ベクトル内の要素毎の確率は、１／ｎであって、各要素は、異なるインデックスにマップされる。図１４を参照すると、シャッフル関数によって生成され得る、インデックス化されたソートが、図示される。順方向マップに示されるように、入力データ（すなわち、コンテンツ列）内の要素をシャッフル後、昇順ソートが、入力データ（すなわち、コンテンツ列）に適用され、インデックス列要素は、コンテンツ列にスレーブ化される。逆方向マップが、次いで、示されるように、２つの列内の要素を交換することによって、インデックス化されたソートから生成される。基本マッピング関数は、マップ検証プロセス（すなわち、全ての要素に関してｄｅｃｏｄｅ（ｅｎｃｏｄｅ（ｘ））＝ｘであることを検証する）を含んでもよい。図１３−１４に示される実施形態は、２進数において導出される実施例を図示し、ｎビットおよび２^ｎ要素を伴う。他の実施形態では、テーブルは、可能性として考えられる要素の数がｃｈ^ｎであるように、任意の進数ｃｈにおけるインデックス値および入力データ値のために導出されてもよい。

種々の実施形態では、順方向マッピングおよび逆方向マッピングは、完全テーブルとして、オフラインで構築され、データ変換モジュール１０２に提示されてもよい、またはマネージャ１０４からの入力に基づいて生成されてもよい。例えば、順方向および逆方向マッピングは、オフラインで生成されてもよいが、エンコーディングのための付加的難読化複雑性を提供しながら、完全マッピングをデータ変換モジュール１０２に提供するために、余剰オーバーヘッドを要求してもよい。

シャッフル関数は、十分な深度を有し、シャッフルプロセスを検索およびクラックするプロセスを困難にしてもよい。例えば、８ビットマップに関して、８ビットマップ内の要素の数は、２^８または２５６である。８ビットマップのためのテーブル空間は、したがって、２５６！，＝１．３１２２Ｅ＋２５４である。本大テーブル空間は、シャッフルのシャッフルを前提として達成可能である。例えば、シャッフリングのプロセスは、いくつかのデータセンタを横断して分散されてもよく、１つのデータセンタが、第２のデータセンタのシャッフルされたテーブルを再シャッフルする。

種々の実施形態では、マッピング関数内に含まれるテーブルは、４、８、または１６ビットワードを含んでもよい。そのようなサイズは、エンコードされるための１６ビットワードを効率的に利用し得る。しかしながら、他の実施形態では、本明細書における方法は、任意のビットサイズのために適用されてもよい。難読化の観点から、敵が、単に、エンコードされたデータ伝送を観察することによって、テーブルサイズを判定することは困難であろう。加えて、マネージャ１０４からの入力に基づいて、各伝送は、異なるサイズビットワードを使用してエンコードされてもよい。

ここで図１５を参照すると、データ駆動難読化方略が、説明される。入力データ、ＲＮＧ、または別のソースのいずれかによって駆動される、エンコーディング関数の実装は、難読化関数の難読化複雑性を増加させることができる。データ駆動エンコーディング関数は、各フレームがスタンドアロンであり得るように、単一フレームからサンプリングされてもよい、または前のフレームからサンプリングされてもよい。

データ駆動マッピング関数を有する１つの方法は、各テーブルエントリへのインデックスをオフセットすることである。例えば、単一値オフセットが、入力データに基づいて選択され、マッピング関数内の値に適用されてもよい。図１５では、オフセット値＝３が、順方向および逆方向マッピングにおけるインデックス４に適用される。マッピングに適用されるオフセットを表す方程式は、以下である。
ｏｆｆｓｅｔ＿ｖａｌｕｅ＝３，ｘ＝４
ｏｆｆｓｅｔ＿ｅｎｃｏｄｅは、ｅｎｃｏｄｅ ｉｎｄｅｘ＋ｏｆｆｓｅｔ＿ｖａｌｕｅの剰余和に対して実施される。
ｏｆｆｓｅｔ＿ｅｎｃｏｄｅ（４）＝ｅｎｃｏｄｅ（（４＋３）％８）＝ｅｎｃｏｄｅ（７）＝６であって、式中、ｘ％ｙは、剰余ｙにおけるｘの値を示す。
ｏｆｆｓｅｔ＿ｄｅｃｏｄｅは、ｏｆｆｓｅｔ＿ｄｅｃｏｄｅ（６）＝（ｄｅｃｏｄｅ（６）＋８−ｏｆｆｓｅｔ）％ｖｅｃｔｏｒ＿ｅｌｅｍｅｎｔ＿ｃｏｕｎｔとして評価される。
この場合、ｏｆｆｓｅｔ＿ｄｅｃｏｄｅは、ｏｆｆｓｅｔ＿ｄｅｃｏｄｅ（６）＝（ｄｅｃｏｄｅ（６）＋８−ｏｆｆｓｅｔ）％８＝（７＋８−３）％８＝１２％８＝４である。

いくつかの実施形態では、フレーム全体のために固定オフセットを使用する代わりに、オフセットは、フレームのための複数の変数の関数であってもよい。所与の値ｘのためのオフセットは、以下のようになり得る。
ｅｎｃｏｄｅ（ｘ）＝‘Ｆｏｒｗａｒｄ ｍａｐ’［（ｘ＋ｏｆｆｓｅｔ）％（ｓｉｚｅｏｆ（‘Ｆｏｒｗａｒｄ ｍａｐ’）］であって、式中
ｏｆｆｓｅｔ＝（ｅｌｅｍｅｎｔ ｉｎｄｅｘ^＊ｒａｎｄｏｍ ｄｒａｗ）％（ｓｉｚｅｏｆ（‘Ｆｏｒｗａｒｄ ｍａｐ’）であって、
ｘ％ｙは、剰余ｙ内のｘの値を示す。

本関数は、要素およびフレームベースの各完全フレームの要素毎に、一意のオフセットを提供する。いったんオフセットが、判定されると、エンコードおよびデコード関数は、図１３−１５に示されるものに類似し得る。多くの技法が、オフセット項を生成するために使用されてもよいことに留意されたい。いくつかの実施形態では、非線形オフセット関数が、オフセット項を作成するために使用されてもよい。実施例として、剰余関数が、上記の例示的方程式に示されるように使用されてもよい。非線形オフセット関数を使用することによって、順方向マッピングが、一意の逆方向マッピングを有せず、難読化を増加させるように作製され得る。

オフセットを複数の変数の関数となるようにさせる一実施例が、図１６Ａ−Ｅに示される。図１６Ａに示されるように、メッセージ（「ｈｅｌｌｏ」）エンコードするために、ａｓｃｉｉでエンコードされたメッセージが、作成され、そのバイナリコーディングに拡張される。メッセージは、３ビットデータ駆動マッピングのために３ビットチャンクに区画する。３ビットチャンクは、１０進数に変換されて示され、インデックスカウントが、チャンク毎に確立され、それぞれのオフセットが、算出される。オフセットは、以下の方程式：ｏｆｆｓｅｔ＝（ｒａｎｄｏｍ ｄｒａｗ^＊ｉｎｄｅｘ）％Ｔａｂｌｅ＿ｓｉｚｅ（式中、％は、剰余関数を表す）を介して算出される。値（ｘ＋ｏｆｆｓｅｔ）％Ｔａｂｌｅ＿ｓｉｚｅが、算出され、エンコードテーブル（図１６Ｂに示される）が、値ｅｎｃｏｄｅ［（ｘ＋ｏｆｆｓｅｔ）％Ｔａｂｌｅ＿ｓｉｚｅ］を見出すために使用される。

受信機によるデコーディングのために、デコードテーブル（エンコードテーブルを使用して生成され、図１６Ｂに示される）が、各ｄｅｃｏｄｅ［ｍｅｓｓａｇｅ ｅｌｅｍｅｎｔ］を見出すために使用されることができる。インデックスカウントが、受信機において３ビットチャンク毎に確立され、オフセット（ｏｆｆｓｅｔ＝（Ｒａｎｄｏｍ ｄｒａｗ^＊ｉｎｄｅｘ）％Ｔａｂｌｅ＿ｓｉｚｅ）が、再び算出される。値ｘ＝（ｄｅｃｏｄｅ［ｍｅｓｓａｇｅ ｅｌｅｍｅｎｔ］＋Ｔａｂｌｅ＿ｓｉｚｅ−ｏｆｆｓｅｔ）％Ｔａｂｌｅ＿ｓｉｚｅが、算出され、値ｘは、その３ビットバイナリ表現に逆変換され、これは、次いで、ａｓｃｉｉに逆変換される。図１６Ｃのテーブルは、データ駆動マップ関数を使用して図１６Ａにおいてエンコードされたデータをデコードする実施例を図示する。

図１６Ｄ−Ｅのテーブルは、本明細書に説明されるマッピング関数の難読化特徴を図示する。両テーブルは、エンコーディングのために全てゼロビットを伴う、メッセージを図示する。図１６Ｄのテーブルでは、２９のランダム抽出値が、エンコーディングのために受信され、図１６Ｅのテーブルでは、ランダム抽出値は、１９である。異なるランダム抽出値の結果、異なるオフセットが、オリジナルメッセージのために計算され、オリジナルメッセージが同一であるにもかかわらず、異なるエンコードされた出力をもたらす。

いくつかの実装では、非対称テーブルが、順方向マッピングおよび逆方向マッピング関数とともに実装されてもよい。非対称テーブルは、ｍ出力ビットへのｎ入力ビットのためのマッピング関数のために使用されてもよく、ｎ＞ｍ（例えば、１対多マッピング）である。以下は、例示的２ビット入力、３ビット出力マッピングである。
‘ｆｏｒｗａｒｄ ｍａｐ’＝｛０１０ １００ ０１１ １０１ ００１ １１１ ０００ １１０｝
‘ｒｅｖｅｒｓｅ ｍａｐ’＝｛１１ １０ ００ ０１ ００ ０１ １１ １０｝。

図１７Ａ−Ｃを参照すると、非対称テーブルを使用してメッセージをエンコードおよびデコードするエンドツーエンド例証が、示される。図１７Ａでは、ａｓｃｉｉメッセージが、そのバイナリコーディングに拡張され、２ビットチャンクに分割される（かつ１０進数に変換される）ように示される。各インデックスは、（２^＊入力＋（ｘ％２））として算出される。エンコードテーブルが、次いで、ｅｎｃｏｄｅ［ｉｎｄｅｘ］を見出し、エンコードされたデータをもたらすために使用される。結果として生じるエンコードされたデータは、３ビットシーケンスに分割されて示され、各そのようなシーケンスは、オリジナルデータ内の２ビットシーケンスに対応する。図１７Ｂは、所与の値のために生成されたエンコードテーブルおよびデコードテーブルを図示する。

図１７Ｃに示されるデコーティングに関して、デコードテーブルは、各ｄｅｃｏｄｅ［ｍｅｓｓａｇｅ ｅｌｅｍｅｎｔ］を見出すために使用される。各エンコードされた値は、デコードされ、次いで、その２ビットバイナリ表現に逆変換され、次いで、ａｓｃｉｉに逆変換される。デコードテーブルは、デコーティング関数がデータをエンコードするために使用されるエンコーディング関数にマップすることを確実にするために生成される。デコードテーブルは、例えば、外部サーバ（例えば、以下に説明されるようなポリシサーバ）によって生成されてもよい。本方法におけるデータ駆動コーディングを駆動するために使用される外部データは、エンコードおよびデコード関数の両方のために外部駆動データの知識を要求する、図１６Ａ−Ｅのデータ駆動マップと比較して、エンコーディングのためだけに要求されることに留意されたい。

図１８を参照すると、２つの付加的非対称テーブルが、エンコードおよびデコードテーブル生成の実施例を図示するために示される。実施例では、コンテンツ列がシャッフルされた後、昇順ソートが、コンテンツ列に実施され、入力およびインデックス列が、コンテンツ列にスレーブ化される。逆方向マップが、次いで、列をリネーミングすることによってインデックス化されたソートから生成される。コンテンツ列は、インデックス列となり、入力列は、コンテンツ列となる。各実施例では、結果として生じるテーブル（逆方向マップ）は、オリジナルエンコードテーブル（順方向マップ）のためのデコードテーブルである。

入力は、入力のための２ビットのみであるため、４つの一意の要素のみが存在し、３ビット、８要素出力にマップされることができる。これは、本実施形態では、各入力要素が２つの出力にマップされることを可能にする。ケース１では、これは、各入力要素を生じるにつれて繰り返すことによって実装されることができる（例えば、００、００、０１、０１等）。ケース２では、これは、入力要素のシーケンス全体を繰り返すことによって実装されることができる（例えば、００、０１、１０、１１、次いで、００に戻る）。種々の実施形態では、入力ビットの任意のタイプのシーケンスが、類似様式で使用されてもよい。

数学的用語では、ケース１に関して、図１８における入力からインデックスへのデータ駆動変換は、ｉｎｄｅｘ＝（ｉｎｐｕｔ^＊２＋（ｘ％２））であって、式中、ｘは、データ駆動入力であって、一般に、ｉｎｄｅｘ＝ｉｎｐｕｔ^＊２^ｍ−ｎ＋（ｘ％２^ｍ−ｎ）である。

非対称テーブルは、入力ビットの数が、常時、エンコードされたビットの数未満であるため、それらと関連付けられたオーバーヘッドを有してもよい。オーバーヘッドは、パーセントで測定される、Ｏｖｅｒｈｅａｄ＝（ｏｕｔｐｕｔ ｂｉｔｓ−ｉｎｐｕｔ ｂｉｔｓ）／ｉｎｐｕｔ ｂｉｔｓとして測定される。例えば、８入力ビットおよび１０出力ビットに関して、オーバーヘッドは、２５％である。オーバーヘッドパーセンテージ範囲は、入力ビットおよび出力ビットの数に基づいて０％〜５０％と変動してもよい。

図１７−１８に説明されるように、非対称テーブルは、その１対多（ｎ対ｍ）エンコーディングおよび多対１（ｍ対ｎ）デコードを解法する困難度に基づいて、入力データを難読化するために使用されている。代替は、代わりに、ｍ−ｎビットをエラー制御コーディングに対して意図することである。使用され得る、エラー制御コードの２つの実施例は、ＢＣＨコードおよびＬＤＰＣコードである。本開示は、ＢＣＨコードの使用を説明するが、任意のタイプのエラーコーディングスキームが使用されてもよいことを理解されたい。

エラー制御コーディングは、ＯＣＴＳ（最適化されたコードテーブルシグナリング）テーブルを使用して実装されてもよく、テーブル生成は、バイナリＢＣＨコードに基づく。ＢＣＨコードは、（ｎ，ｋ，ｔ）コードとして説明され、ｎは、ビット単位のブロック長であって、ｋは、情報ビットの数であって、ｔは、補正され得るエラー中のビットの数である。ｎブロック長は、ＯＣＴＳテーブルのサイズを設定し、これは、長さ２^ｎである（すなわち、ｎ＝７である場合、ＯＣＴＳテーブル内には１２８個のエントリが存在し、ｎ＝１５である場合、３２，７６８個のエントリが存在する）。

図１９は、ＢＣＨエンコーディングのための部分的エンコード／デコードテーブルを図示する。非対称テーブルの前述の実施例は、２ビットのみをエンコードしたが、完全３ビット出力テーブルを生成したことに留意されたい。ＢＣＨエンコードは、完全７ビット出力を生成するが、完全１２８要素テーブルではなく、１６要素テーブルのみを生成する。図２０Ａは、図１９の非対称テーブルを使用した破損したデータストリームの補正を図示する。

ＬＤＰＣコード実装は、類似してもよく、テーブルルックアップとしての代わりに、算出として実施される。エラー補正能力は、受信機によってエラー内の受信されたビットの数を推定するために使用されることができる。図２０Ｂに図示されるようなプロセスは、エラー補正され、デコードされたメッセージをエンコードすることによって、オリジナルメッセージのローカル推定値を作成し、本ローカル推定値と受信されたビットを区別するためのものである。推定値は、エラーの数がエラー補正の限界内にある限り、正確である。補正されていないエラーの場合、推定値は、高くなるが、エラーカウントを低減させるためにコードレートを変更すべきかどうかを決定するために使用される場合、依然として、有用であり得る。

再び、図１２Ａを参照すると、データを難読化するために実装され得る、別の例示的関数は、ホワイトニング関数であり得る。ホワイトニング関数は、任意のエンコードされたデータストリームの統計を均一分布確率関数に変換し、したがって、統計的測定値をホワイトニングするために使用されてもよい。ホワイトニングのための１つの技法は、難読化されるためのストリームと長さが等しい擬似ランダムに選定されたビットのシーケンスを作成し、ホワイトニングされるためのランダムに選定されたビットおよびデータのビット毎ＸＯＲを作成することである。出力をホワイトニングするための別の技法は、エンコーディングのために各シンボルを表すために使用されているビットを追跡することによって、１対多のマッピングを使用して遂行されることができる。多くのマッピングのうちの１つを使用したシンボルのエンコーディングが、あまり均一ではないと思われるビットストリームをもたらすであろう場合、代替マッピングのうちの１つが、代わりに選定されてもよい。

ここで図２１Ａ−Ｂを参照すると、ホワイトニング関数の例示的実装が、示される。図２１Ａは、ホワイトニング難読化データを生成する方法を示し、図２２は、ホワイトニング難読化データをデータ入力に適用し、データ入力を難読化する方法を示す。一実施形態では、履歴バッファの初期ロードは、ヘッダ情報から導出される。初期ロードは、ヘッダ情報の全体またはヘッダ情報のサブセットから成ってもよい。初期ロードは、ヘッダ内に現れるビットと同一シーケンス内にロードされてもよい、またはスクランブルされてもよい（すなわち、履歴バッファの中への初期ロードとヘッダ情報との間の正確な相関は、要求されない）。さらに、初期ロードは、難読化されていないヘッダ情報から導出されてもよく、これは、ホワイトニング関数が適用され得る前に、ヘッダ情報の難読化解除を要求することによって、セキュリティを増加させるであろう。図２１Ａ−Ｂに示される実施例では、初期ロードは、ヘッダ情報からの６４ビットから成る（ＤＥＥＡ ＤＢＣ５ ＢＡＣ１ １ＡＡ１）。バッファはさらに、１つまたはそれを上回るヘッダデータプロパティ（例えば、時刻）から導出される、他の値を含んでもよい。

ＰＲＮＧが、マネージャ１０４において初期化され、それぞれのＰＲＮＧが値（図２１Ａ−Ｂでは、ＰＲＮＧ＿ｄｒａｗと称される）の同じシーケンスを生成するように、デコーダマネージャ１５４において複製される。受信機は、ヘッダ内に提供される情報に基づいて、送信機においてＰＲＮＧのために使用されるシード値を判定可能である。図２１Ｂに示されるように、ヘッダデータ（例えば、ランダム抽出（「ＲＤ」）データ）の一部は、ＰＲＮＧへの入力として使用されてもよい。言い換えると、ヘッダデータからのビットは、乱数生成プロセスを駆動してもよい。別の実施形態では、複数のランダム抽出は、単一ＰＲＮＧがビットのより長いシーケンスを生成するために使用されてもよい。さらに別の実施形態では、複数のＰＲＮＧは、ＰＲＮＧ毎に、同一シードと併用されてもよい。さらに別の実施形態では、複数のＰＲＮＧは、それぞれ、異なるシードと併用されてもよい。

ホワイトニング関数は、履歴バッファ（ＤＥＥＡ）内の第１のブロックおよびＰＲＮＧ＿ｄｒａｗ（Ａ０１９）内の第１のブロックをとり、ＸＯＲ関数を適用することによって開始する。本実施例では、結果は、７ＥＦ３である。他の実施形態では、各バッファ内の第１のブロック以外のブロックは、ともにＸＯＲされてもよい。本実施形態は、便宜上、それぞれ内の第１のブロックの使用を図示する。結果として生じる値７ＥＦ３は、次いで、データシーケンスとＸＯＲされる。

新しく生成された値（７ＥＦ３）は、履歴バッファの最後に追加される一方、他の値は、繰り上げられ、最初の値ＤＥＥＡは、除去される。当業者は、履歴バッファが、循環バッファとしても同様に実装され得、新しく生成された値が、最近使用された値に取って代わり、使用されるべき次の値を示すポインタが、単に、バッファ内の次の値をポイントするように更新されることを認識するであろう。さらに、使用されたＰＲＮＧ＿ｄｒａｗからの値（Ａ０１９）は、除去される。次いで、プロセスは、繰り返し、最初の値（現時点では、１ＡＡ１およびＢＣ７６）は、ともにＸＯＲされる。本プロセスは、ＰＲＮＧ＿ｄｒａｗ内の全ての値が使用されるまで繰り返す。

種々の実施形態では、プロセスは、上記に示されるように、一度に１６ビット以外のデータの任意のサイズのために実行されてもよい。プロセスは、３２ビットチャンク、１２ビットチャンク等のために実行されてもよい。終了時、奇数のビットが残っている（一度に１６ビットが使用されているとき、１６ビット未満が残っている）場合、データは、ビットベースで処理されてもよい。

デコーダは、同一シード値（図２１Ａ−Ｂの実施例では、ヘッダから取得された、マップされたＲＤ）を使用して、擬似ランダム値の同じシーケンスを生成する。デコーダにおいて生成された擬似ランダム値の本シーケンスは、別のＸＯＲ関数を使用して、受信されたデータとマージされ、オリジナルデータストリームを露見させる。

再び、図１２Ａを参照すると、データを難読化するために実装され得る、別の例示的関数は、転置関数（本開示では、パック関数とも称される）であってもよい。そのような関数は、ａｓｃｉｉでエンコードされたテキストのパターンをディスラプトするための状況において使用されてもよく、各英数字文字の最初のビットは、０である。実施例として、図２２Ａ−Ｂでは、第８のビットをパックするための第２のソースの２つの実施例が、示される。第１の実施例は、エンコードされるためのメッセージの最後のバイトであって、第２の実施例は、送信機と受信機との間の通信のためのフレームカウントとしての役割を果たすためにもたらされるバイトである。ＰＲＮＧ等のデータをパックする他のソースも、使用されてもよい。

図２２Ａ−Ｂの基本的実施例では、一般的プロセスは、ａｓｃｉｉエンコードのビット０−６をパックされたメッセージのビット０−６の中に移動し、ａｓｃｉｉエンコードのビット５６をパックされたメッセージのビット場所７の中に移動するためのものである。言い換えると、ａｓｃｉｉエンコードの最初の７ビットが、とられ、次いで、第７のバイトからの最初のビットが、挿入される。本プロセスは、繰り返され、次の７ビットをａｓｃｉｉエンコード（一次ソース）から、次いで、次のビットを第７のバイト（二次ソース）から引き出す。

標準名称が、（ａ，ｂ，ｃ）の形態で示され、エンコーディングの基本単位は、（ａ＋ｂ）ビットの長さであって、ビットは、一次ソースからもたらされ、ｂビットは、二次ソースからもたらされる。図２２−２５に示される実施形態では、ａ＋ｂは、全ての実施例において、８と等しく、他の実施形態では、他のビット長が、本明細書に説明されるアルゴリズムと併用されてもよいことに留意されたい。例えば、ａおよびｂのための値は、恣意的に選定されてもよい。識別子ｃは、パックされたビットまたは複数のビットのための開始ビット場所を定義する（本実施例では、基本インデックスとして０を用いる）。ｃ値は、（０、…、ａ＋ｂ−１）の範囲内であるべきである。図２２Ａ−Ｂでは、ａ＝７、ｂ＝１、およびｃ＝７である。示されるように、文字「ｅ」は、７番目の位置に示され、文字「ｅ」を表すビットが転置関数において使用されるであろうことを示す。「ｅ」の第１のビットは、メッセージ内の第１の文字の７番目の位置に移動され（ａ＝７であるため）、「ｅ」の第２のビットは、メッセージ内の第２の文字の７番目の位置に移動される等となる。転置されていない各ビットは、単に、転置されたビットのための空間を作るためのスポットまで移動される。

図２３Ａ−Ｂでは、第８のビットがインデックス７以外の場所にパックされる実施例が、示される。図２３Ａの実施形態では、パックされたビットは、インデックス４のみに設置される（ｃ＝４であるため）。言い換えると、転置されるための文字「ｅ」のビットは、各バイト内の４番目の位置に移動される。図２３Ｂでは、パックされたビットは、シーケンシャルインデックス場所内に記憶される（ｃ＝０、次いで、１、次いで、２等）。言い換えると、各バイトに転置されるための文字「ｅ」の１ビットは、バイト内の異なる定義された場所に設置される。本パターンは、シーケンシャルとして示され、他の実施形態では、パターンは、任意の方法でランダム化されてもよい。

図２４Ａ−Ｂでは、異なる数のビットが第１のまたは一次ソースから引き出される、実施例が、示される。図２４Ａの実施形態では、６ビットが、一次ソースからもたらされ、したがって、２ビットが、二次ソースからもたらされる。言い換えると、他の実施例と比較して、「ｙ」セグメントからのビットが、「ｅ」セグメント内のビットと同様に使用される。２ビットが、各バイトの中に転置されるように示される。図２４Ｂでは、８ビットのシーケンス毎に、５、６、または７ビットのいずれかが、一次ソースからもたらされる（すなわち、もたらされるビットの数は、シーケンス毎に可変である）。例えば、２ビットが、第１のバイトの中にも、１ビットが、第２のバイトの中に、２ビットが、第３のバイトの中にたらされる等となる。本実施例では、データパケット全体を横断して転置されるビットの総数は最後の２バイト内のビットの数と等しくあるべきであって、そこから、ビットは、読み出されることに留意されたい。図２５は、パック機能性を規定する（転置されたビットが各バイト内に挿入される場所を定義する、ｃの値を変更する）ための付加的自由度を図示する。図２５は、ストリーミング関数としての関数を図示し、ｃの値は、経時的に変化する。

以下のテーブルは、（ａ，ｂ，ｃ）フォーマットの使用を図示し、ストリーミングフォーマットの使用は、サイド・バイ・サイドベースである。テーブルの左側は、（ａ，ｂ，ｃ）フォーマットを図示し、各行は、連続（ａ，ｂ，ｃ）値を規定し、これは、具体的パック関数を識別する。右側のパックストリーミングスケジュールエリアもまた、示される。以下のように、すなわち、第１の行では、０ビットを一次ソースから引き出し、出力バッファ内に記憶し、２ビットを二次ソースから引き出し、ビットを出力バッファの中に連結するように解釈される。これは、パックストリーミングスケジュールが使い果たされるまで、全ての行に関して継続される。（ａ，ｂ，ｃ）フォーマットからパックストリーミングスケジュールに変換するためのマッピング関数は、中央の列に識別される。

以下のテーブルは、付加的複雑性のためのデータ駆動関数を追加する実装を図示する。本実装に関して、（ａ，ｂ，ｃ）フォーマットされたパックの完全セットは、パック関数自体の外部の変数の関数として修正されてもよい。

本実施例では、データ駆動パック変更は、リソースのより高次の管理が動的な低次のデータ駆動変更によって影響されないように、ブロック内に保たれる。例えば、以下のテーブルでは、４つの（ａ，ｂ，ｃ）値のグループが、ブロックとして取り扱われ、ブロック内のａの和は、２４であって、ブロック内のｂの和は、８であって、したがって、バイト指向管理と良好に整合する。

データ駆動パックを実装するための候補方略は、以下に示される基本テーブルとして以下を設定し、基本に対する変更を実装することである。導出は、以下のようになり得る。
−基本テーブルとして示される、４つのエントリのブロックを設計する。本テーブルは、データ駆動テーブルの（ａ，ｂ）ペアがセット（（７，１）、（６，２）、（５，３））からであるように設計される。これは、全ての基本テーブル（ａ，ｂ）ペアを（６，２）として設定し、ペアを（＋１，−１）、（０，０）、または（−１，＋１）によって修正することによって遂行される。
−データ駆動パックテーブルの外部で生成された３ビットバイナリワードによって駆動されるように、パックテーブルの８つの変形例を設計する。
−ブロックを横断したａの和が２４のままであって、ブロックを横断したｂの和が８のままであるように設計する。
−各（ａ，ｂ）ペアが合計８になるように設計する。本具体的ケースでは、これは、ａまたはｂのいずれかへの１の変更は、それぞれ、ｂまたはａへの−１の変更を伴うはずであるとまとめられる。
−ｃ値が範囲（０，ａ＋ｂ−１）内であるように設計する。
以下のテーブルは、これらの制約を使用して作成される。

スタンドアロン方略として、パック関数は、ビットをエンコードされたストリームの中に挿入するが、ビットの順序を変更しない。したがって、前述の方略は、データの順序を転置する関数とペア化され得、これは、特に、転置される要素のサイズがパック関数内の要素の任意のシーケンスに対して素である場合、難読化スキームをはるかに強固にするであろう。

再び、図１２Ａを参照すると、入力難読化関数４０４は、プレフィックス一意の順方向および逆方向マッピング関数であってもよい。プレフィックス一意の順方向および逆方向マッピングの目的は、ハードウェア一意のデータ変換モジュールプラットフォーム群を提供する能力を確立することである。上記に説明されるように、例えば、図１３では、順方向マップおよび逆方向マップペアが、示される。マッピングは、プレフィックス順方向および逆方向マップを含むように拡張されてもよい。例えば、図２６に示されるように、プレフィックス順方向マップおよびプレフィックス逆方向マップも同様に、生成されてもよい。

図２６における上部４つのテーブルは、新しいペアの順方向および逆方向マップを作成するために畳み込まれてもよく、畳み込みのプロセスは、インデックスをそのコンテンツにマップするための順方向マッピングを使用し、プレフィックスマップを使用して、コンテンツをプレフィックス順方向マップへのインデックスとして使用するためのものである。順方向マップは、プレフィックス順方向マップの中に畳み込まれ、プレフィックス逆方向マップへの逆向き作用は、逆方向マップの中に畳み込まれる。

ここで図２７Ａを参照すると、例示的実施形態による、入力データをエンコードするためのプロセス５００のフローチャートが、示される。プロセス５００は、例えば、入力データ難読化モジュール１０８によって実行されてもよい。プロセス５００は、エンコードされるための入力データ（５０２）および入力データマネージャからの入力（５０４）を受信することを含む。一実施形態では、入力データマネージャからの入力は、ＲＮＧからの１つまたはそれを上回るランダムに選択された値を含む。例えば、マネージャからの入力は、データを難読化するために使用すべき１つまたはそれを上回る関数の選択と、関数によって使用されるための１つまたはそれを上回るランダムに選定された値とを含んでもよい。値は、例えば、入力データの中に挿入するため、入力データと組み合わせるため（例えば、ＸＯＲ関数を介して）、またはその他のためのビットのストリングであってもよい。

プロセス５００は、複数の関数を識別し、入力データに適用すること（５０６）と、入力データマネージャ入力および関数を使用して、データを難読化すること（５０８）と、を含む。例えば、ブロック５０８は、概して、入力データマネージャからの第１の関数および入力を介して、入力データを難読化し、次いで、さらなる難読化のために、難読化されたデータを第２の関数に提供することを含んでもよい。これは、任意の数の関数のために継続してもよい。プロセス５００はさらに、ヘッダデータとのスクランブリングおよび連結のために、難読化された入力データを別のモジュールに提供すること（５１０）を含む。上記に説明されるように、入力データおよびヘッダデータは、２つの異なるモジュールにおいて別個に難読化され、次いで、第３のモジュールにおいて組み合わせられ、スクランブルされる。いくつかの実施形態では、ヘッダデータおよび入力データの一方または両方は、デコーダがデータを受信機においてデコードするために必要な情報を含んでもよい。

ここで図２７Ｂを参照すると、例示的実施形態による、入力データをデコードするためのプロセス５５０のフローチャートが、示される。プロセス５５０は、例えば、入力データ難読化解除モジュール１６０によって実行されてもよい。プロセス５５０は、分割された入力データをヘッダ難読化解除モジュールから受信すること（５５２）を含む。上記に説明されるように、ヘッダ難読化解除モジュールは、エンコードされたデータパケットを送信機から受信してもよく、エンコードされたデータをエンコードされた入力データ部分およびエンコードされたヘッダデータ部分に分割するように構成されてもよい。ブロック５５２は、スクランブリング解除モジュールおよび分割モジュールに返された、エンコードされた入力データ部分を受信することを含んでもよい。

プロセス５５０はさらに、入力データを難読化するために使用される１つまたはそれを上回るパラメータを識別すること（５５４）と、複数の関数を識別し、エンコードされた入力データに適用すること（５５６）と、関数を使用して、データを難読化解除すること（５５８）とを含む。ブロック５５４、５５６、５５８は、概して、データを難読化するプロセスの反転を表し得る。例えば、ブロック５５４、５５６、５５８は、概して、送信機がデータをエンコードした方法を識別し、送信機が使用したプロセスを逆転させることを含む。

いくつかの実施形態では、パディング関数が、データ難読化の間、使用されてもよい。パディング関数は、概して、データセットが十分な複雑性のために十分に大きくない（すなわち、データセットが、適用される難読化関数の数にかかわらず、データが脆弱であるほど十分に小さい、またはデータセットがある関数のために不便な長さである）とき、データセットのために使用されてもよい。パディング関数は、データのための閾値に到達するまで、バッファをランダム値で充填してもよい。例えば、難読化されるためのデータパケットのデータ長が、２００バイト等の最小値未満である場合、データは、擬似ランダム値でパティングされ、データパケットを最小長まで充填する。パディングは、典型的には、付加的難読化関数の前に行われ、追加される擬似ランダム値が直接暴露されないことを確実にしてもよい。

パディング関数が、使用されるとき、データ伝送の受信機は、データがパティングされたかどうかを判定する。例えば、現在のフレームサイズが、ヘッダ情報の一部として送信されるデータサイズ値を上回る場合、ビットサイズの差異は、データに追加されるパティングされるビットの数を表し得る。例えば、１，３００バイトワードが、受信機によって受信され、データサイズ値が、１，２３３である場合、受信機は、６７バイトパディングがデータに追加されたことを判定してもよい。データ伝送の最後の６７バイトは、次いで、データ難読化解除の前に破棄される。パティングされたデータは、一実施形態では、データの終了に追加されてもよく、他の実施形態では、パティングされたビットは、受信機がどのビットがパティングされたビットであるかを区別可能である限り、任意の場所に追加されてもよい。

ここで図２８Ａ−Ｂを参照すると、送信機１００によって受信機１５０に伝送されるためのデータを難読化するための連結およびスクランブリングプロセスが、説明される。概して、上記に説明されるように、伝送されるためのデータパケットのためのヘッダデータおよび入力データは、種々の関数を使用して、別個に難読化されてもよい。ヘッダ難読化モジュール１１０および入力データ難読化モジュール１０８はそれぞれ、独立して、データを難読化し、伝送のためのデータを提供してもよい。しかしながら、データが伝送される前に、第３の難読化ステップが、生じてもよく、ヘッダデータおよび入力データは、ともに組み合わせられ、連結され、スクランブルされる。図２８Ａは、データおよび入力をマネージャ６０２（例えば、ヘッダ情報マネージャ１２６に類似する）から受信するように構成される、データマージモジュール１１２を図示する。マネージャ６０２からの入力は、概して、ヘッダデータの難読化に関連するパラメータおよび他の情報を含んでもよく、これは、受信機がデータを難読化解除するための１つまたはそれを上回る関数またはパラメータを判定することに役立ち得る。

データマージモジュール１１２は、概して、連結モジュール６０４およびスクランブリングモジュール６０６を含んでもよい。連結モジュール６０４は、概して、２つのデータセットを結び付けるように構成されてもよく、スクランブリングモジュール６０６は、概して、両データセットからのビットが交絡されるように、２つのデータセットからのビットをともにスクランブルするように構成されてもよい。スクランブリングモジュール６０６は、以下に説明されるように、任意の数またはタイプのスクランブリング関数を実装してもよい。任意の数の異なる関数が、２つのデータセットからの組み合わせられたビットを難読化するために使用されてもよいことを理解されたい。データマージモジュール１１２が、データをマージするための２つのモジュール６０４、６０６を示すが、任意の数の異なる関数が、種々の実施形態では、データセットをともにマージするために使用されてもよいことを理解されたい。

図２８Ｂを参照すると、データ分割モジュール１５８は、エンコードされたデータ入力を送信機１００から受信するように構成される。データ分割モジュール１５８は、受信されたデータをスクランブル解除し、次いで、スクランブル解除されたデータをヘッダデータ部分および入力データ部分に分割するように構成される。データ分割モジュール１５８は、スクランブリング解除モジュール６５２と、分割モジュール６５４とを含むように示される。スクランブリング解除モジュール６５２は、１つまたはそれを上回る所定のパラメータに基づいて、データをスクランブル解除してもよい。例えば、パラメータは、送信機１００がデータ伝送プロセスを開始する前に、ポリシサーバから受信された所定のパラメータであってもよい。データをスクランブル解除後、分割モジュール６５４は、データをヘッダデータ部分および入力データ部分に分割するように構成される。

ここで、概して、図２９−３４を参照すると、２つのデータセット（上記に説明されるように、ヘッダデータセットおよび入力データセット）を連結およびスクランブルするための種々の関数が、より詳細に説明される。ヘッダデータおよび入力データが、独立して難読化された後、第３のモジュールは、ヘッダデータおよび入力データを組み合わせ、データを伝送されるための単一データデータパケットとして難読化することによって、さらなる難読化を追加してもよい。本開示に説明されるように、ヘッダデータおよび入力データをともに難読化する１つのそのような方法は、両データセットのビットをともに単一データセットの中にスクランブルすることである。いくつかの実施形態では、スクランブリングの順序は、順方向マッピング関数またはデータの連続スワップを実施するために使用されるランダムに生成された値（例えば、ＲＮＧ値）のテーブルの一方または両方によって駆動されてもよい。受信機は、次いで、データを入力データおよびヘッダデータに分割する前に、ランダムに生成された値のベクトル定義逆方向マッピング関数またはテーブルを使用して、データをデコードすることができる。

データマージプロセスは、概して、曖昧性の別の層を伝送されるためのエンコードされたデータストリームに追加する。プロセスのスクランブリング部分は、ビットの任意の数またはサイズに実施されてもよい（例えば、ビット、バイト、２バイト断片等によってデータをスクランブルする）。難読化の複雑性は、ビット転置のためのレートが、ビットスクランブリングのためのビットレートに対して素である場合、増加される。

連結関数は、２つのステップを伴ってもよい。すなわち、ＯＣＴＳヘッダデータ要素を具体的順序の中に連結することと、ＯＣＴＳヘッダデータを難読化された入力データと連結することとである。ＯＣＴＳヘッダデータは、上記に説明されるように、ヘッダデータ難読化モジュール内で作成され、ヘッダデータと入力データの連結は、スクランブル関数に先行して実施される。スクランブリングに先立って、ＯＣＴＳヘッダデータは、直接、入力データに先行するか、または後続するかのいずれかである。ヘッダデータが、入力データに先行する場合、ヘッダデータの処理は、受信されるとすぐに開始し、したがって、処理の前に、情報の完全フレームが到着することを待機する必要がないことによって、待ち時間を低減させることができる。ＴＣＰ／ＩＰプロトコルにおけるように、完全に到着するまでフレームを処理不可能である場合、ヘッダデータは、入力データに後続し、メムコピー関数が、処理の間、データをコピーするために使用される。

スクランブリング関数は、複雑性およびフレーム要素到着時間のために調節されてもよい。例えば、１，５００バイトフレームに関して、バイト毎にスクランブルされ得る方法の数は、１５００！であって、ビット毎にスクランブル解除され得る方法の数は、（８^＊１５００）！であって、２バイト毎にスクランブルされ得る方法の数は、（１５００／２）！である。

エンコーダおよびデコーダによって使用され得る、スクランブリングおよびスクランブリング解除関数は、前述の順方向マッピングおよび逆方向マッピング関数に類似し得る。例えば、スクランブリングおよびスクランブリング解除関数は、ベクトルペアとして表されてもよい。図２９を参照すると、例示的スクランブリング関数が、２７要素（６つのヘッダ要素および２１の入力データ要素）を伴う、データフレームのために示される。要素毎に、スクランブリングマッピングおよびスクランブリング解除マッピング（図２９では、順方向および逆方向マッピングとして標識される）が、示される。順方向マップは、データをスクランブルするために使用され、逆方向マップは、受信機においてマージされたデータをスクランブル解除し、データをそのオリジナル順序に戻すために使用される。

上記に説明されるものと同様に、順方向および逆方向スクランブリングマッピングは、畳み込まれてもよい。一意のプレフィックス順方向および逆方向マッピングベクトルが、識別されたユーザまたはデバイスに特有のマッピングを作成するために使用されてもよい。図３０を参照すると、例示的畳み込み順方向および逆方向スクランブリングマッピングが、図示される。順方向マッピングおよびプレフィックス順方向マッピングは、畳み込み順方向マッピングを作成するために使用され、逆方向マッピングおよびプレフィックス逆方向マッピングは、畳み込み逆方向マッピングを作成するために使用される。

概して、図２９−３０を参照すると、スクランブリングマッピングは、受信機がヘッダデータを入力データから分離し得ることを確実にするために、ヘッダデータに関連するデータ要素がある位置に保たれることを保証するように生成されてもよい。例えば、マッピングは、全てのヘッダデータパケットを最初のｎパケット内に保つように作成されてもよい。値ｎは、用途ベースであって、送信機および／または受信機のマネージャによって選定されてもよい。これは、受信機がより迅速または容易にヘッダデータを入力データから分離することを可能にし得る。

いくつかの実施形態では、ランダムに生成された値のテーブルが、データをスクランブルする方法を判定するために使用されてもよい。スクランブリング関数は、テーブル内のランダム値に基づいて、スワップインデックスを用いて、データストリーム内のインデックス化された値のスワップを識別する。テーブルは、送信機および受信機の両方に利用可能であってもよい。スクランブルテーブル実装の基本的実施例は、図３１に示される。図３１の実施例では、スクランブルされるためのベクトルは、２０要素ベクトルである（例証目的のために、図３１では、上部に列挙される）。

テーブルを使用してスクランブリング関数を実施するために、固定抽出ベクトルが、インデックス毎にデータ要素カウントを法として固定スクランブルテーブルを計算することによって作成される。スワップペアが、次いで、インデックスとその固定抽出をペア化することによって、インデックス毎に作成される。第１のインデックスから開始し、全てのインデックスを通して反復することによって、スワップペアによって識別されるスワップが、実施される。図３１の実施例では、第１のスワップペアは、ヌルペアであって、データのコンテンツ［０］とデータ［０］をスワップする。第２のスワップペアは、データのコンテンツ［１］とデータ［１８］をスワップする。図に示されるように、ｎ番目のスワップペアは、データ［ｎ−１］のコンテンツとデータのコンテンツ［データ要素の固定スクランブルテーブル［ｎ］％番号］をスワップする。したがって、２０番目のスワップに関して、データ［１９］のコンテンツは、データ［７６０％２０］のコンテンツとスワップされるであろう。したがって、データ［１９］のコンテンツは、データ［０］のコンテンツとスワップされるであろう。スワップは、任意のスワップが生じる前のデータ［０］がｎ番目の反復時にデータ［０］と異なる値を含有し得るように漸次的であることに留意されたい。したがって、ｎ番目のスワップは、０からｎ−１までの全てのスワップが完了した後、データ［ｎ−１］内に含有される値のスワップをもたらす。本実装は、最大固定スクランブルテーブルの長さの任意のデータベクトル長のために使用され、スワップペアがデータベクトルの長さに依存するため、データベクトル長毎に一意のスクランブリングを提供することができる。したがって、所与の２つのデータベクトルを前提として、一方は、１９のデータ要素を含有し、一方は、２０のデータ要素を含有し、最初の１９のデータ要素が同じであろうが、所与の同一固定スクランブルテーブルが与えられても、異なるスワップをもたらすであろう。図３１に示されるテーブルに基づいて、２０要素データベクトルのための第２のスワップは、データ［１］およびデータ［１８］のスワップ（２７８％２０＝１８）をもたらすであろうが、１９要素データベクトルのための第２のスワップは、データ［１］およびデータ［１２］のスワップをもたすであろう（２７８％１９＝１２）。

図３２を参照すると、第２の例示的スクランブリングテーブルが、示される。本実施形態では、オフセット項が、固定スクランブルテーブル内の開始点を識別するために使用される。例えば、第１のスワップをインデックス０において実施する代わりに、スワップは、インデックスのいずれかにおいて開始してもよい。オフセットは、データ駆動オフセットであって、したがって、データベクトル長毎だけではなく、また、選定されるオフセット毎に、データの一意のスクランブリングを作成してもよい。例えば、ＰＲＮＧによって生成された擬似ランダム値は、オフセットとして使用されてもよい。擬似ランダム値は、同一入力を前提として、エンコーダおよびデコーダの両方が同一ランダム値をＰＲＮＧから生成し得るように生成されてもよい。代替として、乱数が、エンコーダによってオフセットとして使用される場合、使用すべきデコーダにパスされる必要がある。

図３３を参照すると、第３の例示的スクランブリングテーブルが、示される。図３３の実施例では、オフセット項評価内に含まれる項の数は、増加され、したがって、単一固定スクランブルテーブルを使用して広がるテーブル空間を増加させる。

図３４を参照すると、例示的スクランブリング解除テーブルが、示される。スクランブリング解除テーブルは、図３１に示されるスクランブリングテーブルに基づく（すなわち、図３４のテーブルは、図３１のテーブルによってスクランブルされるデータをスクランブル解除するために使用される）。受信されたデータセットをスクランブル解除するプロセスは、概して、データをエンコードする間、同一のスワップのセットであるが、逆順に実施することを含んでもよい。図３４に示されるように、スクランブルテーブルの順序は、データのスクランブリング解除を生じさせるために逆転される。

概して、図３５−３７を参照すると、本明細書のシステムおよび方法によって提供され得る、付加的特徴が、より詳細に説明される。

ここで図３５を参照すると、送信機１００および受信機１５０とポリシサーバ７０２との間の通信が、示される。本開示に説明されるように、送信機１００は、第１の関数のセットに従ってデータを難読化してもよく、受信機１５０は、第１の関数のセットに関連する第２の関数のセットに従って伝送を難読化解除する場合のみ、オリジナルデータを復元することができる。データが、受信機１５０に伝送されると、受信機は、データを難読化解除し、連続伝送をもたらすために使用すべき関数を把握しなければならない。図３５を参照すると、送信機１００および受信機１５０は、送信機１００および受信機１５０に使用すべき難読化関数およびパラメータに関する情報を提供し得る、ポリシサーバ７０２と通信する。

図３５の実施形態では、ポリシサーバ７０２は、送信機１００および受信機１５０の両方と通信するように示される。送信機１００は、特定の受信機との接続を確立することを所望してもよい（すなわち、データを受信機に伝送するために）。接続を確立するために、送信機１００は、要求をポリシサーバ７０２に伝送する。ポリシサーバ７０２は、送信機１００がデータを受信機１５０に伝送する許可を有するかどうかを判定してもよい。ポリシサーバ７０２が、送信機１００がデータを受信機１５０に伝送し得ることを判定する場合、要求を承認し、それに応答して、データを送信機１００および受信機１５０の両方に提供するであろう。例えば、ポリシサーバ７０２は、キー、マッピング関数において使用するためのテーブル、マッピングのために使用され得、かつ送信機１００が受信機１５０に伝送されるデータのヘッダ内で選定されたテーブルを含むように選定し得る、複数のテーブル、または送信機１００および受信機１５０への任意の他のタイプのパラメータもしくはデータ入力を伝送してもよい。送信機１００および受信機１５０に提供されるデータは、関連する（すなわち、送信機１００は、順方向マップが提供されてもよく、受信機１５０は、対応する逆方向マップが提供されてもよい）。ポリシサーバ７０２によって提供されるデータは、データをエンコードおよびデコードするとき、送信機１００および受信機１５０が同一関数およびパラメータを使用することを可能にし、送信機が、受信機が具体的エンコーディング情報を送信機から受信せずデコードし得る、エンコードされたデータを伝送することを可能にしてもよい。

ポリシサーバ７０２は、送信機１００および受信機１５０による難読化および難読化解除情報の使用を限定してもよい。例えば、情報は、単一伝送、単一セッション、最大数のパケット、または具体的時間周期のためだけに割り当てられてもよい。送信機１００および受信機１５０は両方とも、ポリシサーバによって割り当てられる限界を行使することが期待される。しかし、最低でも、受信機１５０は、限界を行使し、受信することが認可されていないデータを処理しないように防止しなければならない。ポリシサーバ７０２によって設定された限界を行使する１つの利点は、受信機１５０によって使用される難読化解除情報がセキュアなままであることをさらに確実にすることである。いったんポリシサーバ７０２によって設定された限界に到達すると、送信機１００が、付加的情報を受信機１５０に送信することを所望する場合、送信機１００は、送信機１００および受信機１５０の両方に返送されるための新しい難読化および難読化解除情報（例えば、新しいテーブル）を要求してもよい。

難読化および難読化解除情報の共有セットがない場合、送信機１００は、受信機１５０が適切なフォーマットではない任意のデータ通信を無視し得るため、受信機１５０と通信しないように阻止され得る。したがって、送信機１００および受信機１５０が開始する前の任意の通信前に、難読化および難読化解除データは、ポリシサーバ７０２によって送信機１００および受信機１５０と共有されなければならない。言い換えると、送信機によるデータ難読化方法および受信機による難読化解除方法の設定の間、送信機と受信機との間の通信は、実際には、生じ得ない。要するに、ポリシサーバによる難読化データおよび難読化解除データの提供は、送信機と受信機との間の通信のためのあるタイプの認証として作用する。これは、相互に通信することが許可される、２つまたはそれを上回る送信機および受信機のグループと、相互に通信することができるが、別のサブグループのメンバと通信することができない、２つまたはそれを上回る送信機および受信機の異なるサブグループとの作成を有効にする。各送信機および受信機は、適切な伝送のためのデータをエンコードおよびデコードするために必要とされる情報を取得するために、ポリシサーバ７０２と通信してもよい。送信機１００とポリシサーバ７０２および受信機１５０とポリシサーバ７０２との間の通信は、任意の共通データ暗号化方法（例えば、ＰＧＰ）を介してセキュア化されてもよい。送信機１００とポリシサーバ７０２および受信機１５０とポリシサーバ７０２との間の通信もまた、本明細書に説明されるＯＣＴＳ技法を介してセキュア化されてもよい。

ポリシサーバ７０２は、独立送信機１００および受信機１５０から独立して示されるが、他の実施形態では、ポリシサーバ７０２は、送信機１００または受信機１５０においてローカルで実装されてもよいことを理解されたい。

図３６は、ヘッダデータを入力データでスクランブルするために使用され得る、スクランブリング関数を図示する。上記に説明されるように、ヘッダデータおよび入力データが、別個に難読化された後、２つのデータセットは、連結およびスクランブルされるべきである。図３６は、ヘッダ部分および入力データ部分と連結されたデータセットを図示する。ヘッダデータサイズは、１６バイトであるように示される。当然ながら、他の実施形態では、ヘッダデータサイズは、任意の長さであってもよい。

異なる用途は、入力データ内のヘッダデータの異なるレベルの難読化を要求し得る。例えば、デコーティングの速度は、スクランブリングがより大きいチャンク（例えば、バイトレベル）で行われ、ヘッダが伝送の開始に比較的に近接してスクランブルされることを確実にすることによって、優先されてもよい。別の実施例として、スクランブリングは、ハードウェア（例えば、ＩＣ）内で、またはパラレルプロセッサを使用して行われてもよい。難読化が、より重要である場合、スクランブリングは、より小さい断片（例えば、ビットレベル）で行われることができ、ヘッダデータは、データ伝送のより大きい部分にわたって拡散されてもよい。

図３６に示されるように、連結されたデータは、ヘッダデータ（１６バイト）を伴う第１の部分と、入力データ（ｘバイト）を伴う第２の部分とを含む。データは、ヘッダデータを最初に、入力データを次に設置することによって連結される。送信機は、次いで、連結されたデータのためにスクランブリング関数を開始してもよい。スクランブリングプロセスは、開始の代わりに、ヘッダデータがある、データの終了時に開始してもよい。スクランブリングプロセスは、ビットをデータセットの後尾からデータセットの先頭にスクランブルし続けてもよい。代替として、図２９に示されるように、別の例示的スクランブリング関数が、図示され、テーブルに基づくスワップを示す。

ヘッダデータを最後にスクランブルすることは、有利であるが、ヘッダデータは、依然として、入力データでスクランブルされ、難読化を増加させるべきである。例えば、図３７に示されるように、最初の１００または２００バイトの連結されたデータが、ともにスクランブルされ、最初の２００バイトの入力データでスクランブルされた１６バイトヘッダデータをもたらしてもよい。これは、さらに数百を上回るバイトとなり得るデータセット全体を横断してヘッダデータをスクランブルすることの代替である。

いくつかの実施形態では、連結されたデータは、異なるチャンクに分割されてもよい。例えば、図３６の最後の実施例では、連結されたデータは、ヘッダデータおよび入力データを含む、１００バイトの第１のチャンクと、入力データの３つのチャンクとに分割される。これは、スクランブリング関数が、概して、データセットを通して連続して作用する、第１の実施例のスクランブリングと対比される。各チャンク内のデータは、スクランブリング関数によってスクランブルされてもよい。ヘッダデータは、入力データの一部でスクランブルされ、伝送されるためのデータデータパケットの難読化を増加させる。

図３７は、例えば、データ変換モジュール１０２または１５２および／または本開示に説明される種々の他の例証的システムを実装するために使用され得る、コンピュータシステム９００の描写を図示する。コンピューティングシステム９００は、情報を通信するためのバス９０５または他の通信コンポーネントと、情報を処理するためにバス９０５に結合されるプロセッサ９１０とを含む。コンピューティングシステム９００はまた、情報およびプロセッサ９１０によって実行されるための命令を記憶するためにバス９０５に結合される、ランダムアクセスメモリ（ＲＡＭ）または他の動的記憶デバイス等のメインメモリ９１５を含む。メインメモリ９１５はまた、プロセッサ９１０による命令の実行の間、位置情報、一時的変数、または他の中間情報を記憶するために使用されることができる。コンピューティングシステム９００はさらに、プロセッサ９１０のための静的情報および命令を記憶するためにバス９０５に結合される、読取専用メモリ（ＲＯＭ）９２０または他の静的記憶デバイスを含んでもよい。ソリッドステートデバイス、磁気ディスク、または光ディスク等の記憶デバイス９２５が、情報および命令を永続的に記憶するためにバス９０５に結合される。

コンピューティングシステム９００は、情報をユーザに表示するために、バス９０５を介して、液晶ディスプレイまたはアクティブマトリクスディスプレイ等のディスプレイ９３５に結合されてもよい。英数字および他のキーを含む、キーボード等の入力デバイス９３０が、情報およびコマンド選択をプロセッサ９１０に通信するために、バス９０５に結合されてもよい。別の実装では、入力デバイス９３０は、タッチスクリーンディスプレイ９３５を有する。入力デバイス９３０は、方向情報およびコマンド選択をプロセッサ９１０に通信するために、かつディスプレイ９３５上のカーソル移動を制御するために、マウス、トラックボール、またはカーソル方向キー等のカーソル制御を含むことができる。

いくつかの実装では、コンピューティングシステム９００は、ネットワーキングアダプタ等の通信アダプタ９４０を含んでもよい。通信アダプタ９４０は、バス９０５に結合されてもよく、コンピューティングもしくは通信ネットワーク９４５および／または他のコンピューティングシステムとの通信を有効にするように構成されてもよい。種々の例証的実装では、任意のタイプのネットワーキング構成は、有線（例えば、Ｅｔｈｅｒｎｅｔ（登録商標）を介して）、無線（例えば、Ｗｉ−Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）等を介して）、事前に構成されたａｄ−ｈｏｃ、ＬＡＮ、ＷＡＮ等の通信アダプタ９４０を使用して達成されてもよい。

種々の実装によると、本明細書に説明される例証的実装をもたらすプロセスは、プロセッサ９１０がメインメモリ９１５内に含有される命令の配列を実行することに応答して、コンピューティングシステム９００によって達成されることができる。そのような命令は、記憶デバイス９２５等の別のコンピュータ可読媒体から、メインメモリ９１５の中に読み取られることができる。メインメモリ９１５内に含有される命令の配列の実行は、コンピューティングシステム９００に、本明細書に説明される例証的プロセスを実施させる。マルチ処理配列内の１つまたはそれを上回るプロセッサもまた、メインメモリ９１５内に含有される命令を実行するために採用されてもよい。代替実装では、有線回路が、ソフトウェア命令の代わりに、またはそれと組み合わせて使用され、例証的実装を実装してもよい。したがって、実装は、ハードウェア回路およびソフトウェアの任意の具体的組み合わせに限定されない。

本明細書のシステムおよび方法は、ＡＥＳ等の他の暗号化技法より有利である。例えば、そのような技法は、プロトコルが全てのデータパッカが受信され、受信機において順序通り受信されることを確実にすることに配慮する、ＴＣＰ／ＩＰまたは他の類似プロトコルに依拠し得る。難読化の強度は、部分的に、ブロックチェーニングの使用に依拠し得、これは、伝送の順序を重要にする。しかしながら、本明細書におけるシステムおよび方法は、フレームが順序通り受信されることに依存せず、各フレームは、その独自の難読化方略でスタンドアロンとなり得る。これは、本明細書における難読化方法が、ビデオまたはオーディオ等のデータをストリーミングするためのＵＤＰまたは他のプロトコル等のプロトコルのために使用されることを可能にする。

概して、本開示に説明されるように、種々のテーブルが、データ難読化および難読化解除プロセスの間、使用されてもよい。しかしながら、種々のタイプのテーブルは、難読化および難読化解除プロセスの一部として使用されてもよく、複数のタイプの複数のテーブルが、同一プロセスにおいて使用されてもよいことを理解されたい。例えば、第１の構造を伴う第１のタイプのテーブルは、ビットスクランブリングプロセスの間、使用されてもよく、第２の構造を伴う第２のタイプのテーブルは、ビットマッピングプロセスの間、使用されてもよい。本明細書におけるシステムおよび方法、種々のステップを横断して、任意の数の異なるテーブルタイプおよび構造の使用を生じさせるように適合可能であり得る。

データ難読化プロセスにおいて使用するためのテーブルは、任意のＮ個の要素のセットを含んでもよく、限定ではないが、これらの要素のグループ化を実装する物理的または仮想上の任意のものを含む。形式的または非形式的プロトコルは、要求されない。要素は、単一ビット、任意のビットの標準的グループ化（バイト、ワード、ダブルワード、またはクワッドワード等）、任意の固定もしくは浮動小数点バイナリ表現、または任意のビットの非標準的グループ化であってもよい。要素は、バイナリ、ターシャリ、クオタナリ、クワイナリ等のベース表現で表されてもよい。

テーブルは、ハードウェアまたはソフトウェア内で任意のフォーマットで表される、もしくは実装されてもよい。例えば、テーブルは、ＲＡＭまたはＲＯＭ内に実装されてもよい。メモリの基本場所は、アドレスまたは行へのアクセスを与えてもよく、オフセットは、データまたは列へのアクセスを与えてもよい。別の実施例として、テーブルは、先入れ先出し（ＦＩＦＯ）機構として実装されてもよい。全てのテーブル要素は、ＦＩＦＯ内に記憶され、適切な要素の数をプッシュまたはポップすることによってアクセスされる。別の実施例として、テーブルは、シフトレジスタとして表されてもよい。要素インデックスは、シフトレジスタ内でエンコードされ、多くのシフトレジスタ間に並行して分割されてもよい。別の実施例として、テーブルは、値のアレイもしくはベクトル、または第１の要素を保持する第１のインデックス、第２の要素を保持する第２のインデックス等と組み合わせられる、複数のベクトルもしくはアレイとして表されてもよい。別の実施例として、テーブルは、バイナリ、テキスト、またはＸＭＬドキュメント等のフォーマットされたドキュメントとして実装されてもよい。他の実施例として、テーブルは、格子構造、状態マシン、変調器／復調器、デジタル信号プロセッサ（ＤＳＰ）等内に実装されてもよい。

さらなる実施例として、テーブルは、任意のタイプのソフトウェア実装で実装されてもよい。一実施例として、テーブルは、概して、図に示される、ルックアップテーブルとして実装されてもよく、あるインデックスにおけるテーブルへのアクセスは、そのインデックスにおける要素へのアクセスを与える。別の実施例として、テーブルは、バイナリ検索ツリー（または別のデータ構造）として実装されてもよい。入力ストリングは、ツリーの開始ノードからのデータのパスを判定し、テーブル演算の出力は、リーフノードに到達した後に与えられる。他の実施例として、テーブルは、仮想メモリマップ、ビットストリーム、スタック、アレイまたはベクトル、マトリクス、ＸＭＬドキュメント、テキストドキュメント、バイナリファイル等として、ソフトウェア内で実装されてもよい。

前の図および説明を参照すると、データ難読化のためのシステムおよび方法が、デバイス間の伝送のためにデータを難読化するために説明される。ここで後続特徴を参照すると、複数のデバイス間のデータ通信を管理するためのシステムおよび方法が、説明される。より具体的には、キー配布プロセスが、複数のデバイスが難読化された通信を有することを可能にする、プロトコルを複数のデバイスに提供するために説明される。そのようなシステムおよび方法は、複数のデバイスが、上記の図１−３６に説明されるように、難読化方法を使用して通信することを可能にし得る。

マイクロコントローラは、概して、ローカルで、またはインターネットを通して、情報を交換し、インターネットを経由してアクセス可能となるように有効にされてもよい。複数のマイクロコントローラが、マイクロコントローラおよび／または他の電子機器が内蔵されるエリア内の種々のデバイスのネットワークである、ＩｏＴを形成するために使用されてもよい（例えば、建物、建物内のエリア、車両内等のいくつかのデバイス）。マイクロコントローラが関連付けられるデバイスは、例えば、センサ、ノード、または任意の他のタイプの機器であってもよい。ＩｏＴは、種々のデバイスが、データを受信および伝送することを有効にし得る。ＩｏＴは、典型的には、種々のデバイスが低電力構成においてデータを共有することを有効にする、ローカル低電力無線接続を要求する。ＩｏＴは、概して、種々のデバイスの接続を促進するために、ゲートウェイまたはクライアントを要求し得る。

ここで図３８を参照すると、環境１０００内の複数のデバイス間の通信プロトコルを確立するためのシステムが、示される。複数のデバイス１００２が、環境１０００内に示される。各デバイス１００２は、他のデバイスとの無線通信のために構成される、任意のタイプのデバイスであてもよい。各デバイス１００２は、概して、電力供給源１０１０を含んでもよい。一実施形態では、デバイスは、バッテリ給電式であって、低電力構成で動作するように構成されてもよい。他の実施形態では、デバイスは、１つまたはそれを上回る他の電力供給源を含んでもよい。本明細書に説明されるシステムおよび方法は、各デバイス１００２の低電力ステータスのために適合され、デバイスが、他の低電力デバイスとのセキュア伝送を設定することを可能にする。なお、当業者が認識するであろうように、同一システムおよび方法はまた、低電力デバイスではないデバイスとも作用するであろう。各デバイス１００２は、他のデバイスとの伝送を促進するためのマイクロコントローラを含む。本開示は、デバイス１００２を説明するために、用語「デバイス」および「コントローラ」を同義的に使用する。

環境１０００はさらに、複数のデバイス１００２間およびそれらのデバイスとサーバ１００６との間のデータ通信を管理するように構成される、ゲートウェイ１００４を含む。ゲートウェイ１００４は、例えば、データを受信し、複数のマイクロコントローラに伝送することができる、Ｒａｓｐｂｅｒｒｙ Ｐｉ^ＴＭまたは他の類似デバイス等のコンピューティングデバイスであってもよい。ゲートウェイ１００４は、概して、種々のデバイス１００２のための伝送プロトコルを確立してもよい。ゲートウェイ１００４は、任意のＲＦまたは有線通信方法を介して（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）低エネルギー（ＢＬＥ）、Ｚｉｇｂｅｅ（登録商標）、ＩＥＥＥ ８０２．１５．４、または任意の他の通信プロトコルを介して）、デバイス１００２と通信してもよい。

環境１０００はさらに、ゲートウェイ１００４が通信し得る、サーバ１００６を含む。サーバ１００６は、例えば、上記に説明されるようなポリシサーバ７０２に類似するポリシサーバであって、ゲートウェイ１００４と種々のデバイス１００２との間の相互作用を管理するように構成されてもよい。サーバ１００６は、環境１０００内の種々のデバイスのための許可を判定してもよく（例えば、デバイスが、データを相互に共有することが承認されるかどうか）、ゲートウェイ１００４による使用のためのテーブル、キー、または他の情報を伝送し、難読化された伝送を環境１０００内に設定してもよく、同等物を行ってもよい。

図３８は、１つの特定の実施形態を示すが、他の構成も可能性として考えられることを理解されたい。例えば、サーバ１００６において実施される１つまたはそれを上回るアクティビティは、代わりに、ゲートウェイ１００４において実施されてもよい。別の実施例として、ゲートウェイ１００４は、任意のタイプのクライアントデバイスであってもよい。ゲートウェイ１００４は、クライアントデバイスまたはサーバデバイスであってもよい。

ここで図３９を参照すると、２つのデバイス間の通信プロトコルを実装するためのプロセス１１００のフローチャートが、示される。一実施形態では、ゲートウェイ１００４は、キーをそれ自体とデバイス１００２との間でセキュアに交換することによって、通信プロトコルを２つのデバイス間に実装する。

プロセス１１００は、概して、秘密交換１１０２と、キー配布テーブル（ＫＤＴ）生成１１０４と、データテーブル（ＤＴ）生成１１０６と、データテーブル交換１１０８と、ベクトル同期１１１０とを含む。秘密交換１１０２は、相互に通信することを所望するデバイスの２つのコントローラ間の「秘密」の交換であってもよい。「秘密」は、単に、コントローラとゲートウェイとの間で共有される番号であってもよい。秘密は、以下に説明されるように、テーブル配布キーを作成するために使用されるであろう、ＰＲＮＧ内の場所を表してもよい。言い換えると、秘密は、事前に計算されたＰＲＮＧ場所であり得る。一実施形態では、秘密は、２８バイトであって、１２バイトは、擬似乱数生成（例えば、ＴｉｎｙＭＴ）のためのパラメータ（例えば、乱数を生成するために使用される多項式の指数）を定義し、１６バイトは、ＰＲＮＧシーケンス内のジャンプベクトルを識別する。他の実施形態では、秘密は、異なるサイズであってもよく、合理的保護を生成するための任意のタイプのパラメータを定義してもよい。「秘密」は、ＴＤＫを生成するために、両者（コントローラおよびゲートウェイ）によって使用される。両者が、秘密を把握するため、両者は、同一ＰＲＮＧアルゴリズムを使用して、ＰＲＮＧ値を計算することができる。

初期「秘密」は、製造時にコントローラ内に記録されることができる、またはプロビジョニング時に生成されてもよい。「秘密」は、製造番号またはユニバーサル一意識別子（ＵＵＩＤ）であり得る。初期「秘密」の交換は、複数の方法で行われることができる。初期秘密を交換するための１つの技法は、手動である、すなわち、「秘密」は、人間等のオペレータを使用して、デバイス間で交換される。本技法では、初期「秘密」は、電子的に伝送されず、したがって、初期「秘密」が電子的に傍受される機会は、低減される。本技法では、コントローラは、「秘密」を表示可能なユーザインターフェース（ＵＩ）を含有してもよく、交換は、オペレータが、「秘密」をコントローラＵＩから読み取り、ゲートウェイＵＩを使用して、「秘密」を打ち込むことから成ってもよい。ＵＩが、コントローラ上で利用不可能である場合、「秘密」は、デバイスまたはデバイスのためのパッケージングに取り付けられるラベル上に印刷されてもよい。それらのケースでは、オペレータは、「秘密」をラベルから読み取り、それをゲートウェイＵＩの中に打ち込むことができる。

オペレータが「秘密」をゲートウェイデバイスの中に打ち込むためのＵＩが、ゲートウェイに存在しない場合、「秘密」は、電子的に交換されなければならない。コントローラが、十分な算出リソースを有する場合、「秘密」は、種々のアルゴリズムを使用して、セキュアに共有されることができる。一実施形態では、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎアルゴリズムが、秘密を共有するために使用される。当業者が把握するであろうように、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎアルゴリズムは、２人の当事者が、相互に以前の知識を有しておらず、非セキュアチャネルを経由して共有秘密キーをともに確立することを可能にする、キー交換方法である。しかしながら、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎアルゴリズムは、算出上高価であって、したがって、低電力を用いるＩｏＴデバイスでは、控えめに、したがって、初期秘密キーの交換のためだけに使用されるべきである。

別の実施形態では、秘密をセキュアに共有するために使用され得る、別のアルゴリズムは、非対称暗号化である。非対称暗号化は、パブリックおよびプライベートキーを使用し、データを暗号化および解読する。各クライアントデバイスまたはコントローラは、ゲートウェイのパブリックキーを有する。使用され得る、別のアルゴリズムは、パブリックキーインフラストラクチャであって、ゲートウェイは、証明書を各コントローラに送信し、コントローラは、認証局を使用して、証明書がゲートウェイに属することを検証する。そのような実施形態では、新しい秘密は、全てのセッションにおいて交換される。

別の実施形態では、プロセス集約的アルゴリズムに対して十分な算出電力を伴っていない、ＩｏＴデバイスは、近接プロビジョニングを使用して（すなわち、デバイスがゲートウェイに十分に近接するときのみ）、「秘密」を交換してもよい。近接プロビジョニングに関して、コントローラは、非常に弱い信号（例えば、−２０デシベルミリワット）を伝送してもよく、ゲートウェイは、信号の受信された信号強度インジケータ（ＲＳＳＩ）を使用して、ゲートウェイとデバイスとの間の距離を算出してもよい（本距離は、デバイスがゲートウェイに十分に近接するかどうかを判定するために使用される）。別の実施例として、秘密は、ゲートウェイによって、その製造番号がゲートウェイに既知であるデバイスにのみ交換されてもよい。さらに別の実施例として、秘密は、秘密が公に交換され、ゲートウェイがデバイスが交換後に正しく動作することを検証する、信頼および検証方法を使用して、交換されてもよい。

秘密が交換された後、デバイスおよびゲートウェイは、秘密を記憶装置内に保存してもよく、保存された秘密は、一実施形態では、デバイスの電源が遮断された後、デバイスとセッションを再確立するために使用されてもよい。別の実施形態では、秘密は、いったんデバイスがゲートウェイとペアリングされると、任意の他のゲートウェイとペアリングされることができないように、単回使用のためだけにプロビジョニングされてもよい。種々の実施形態では、秘密は、記憶され、任意の回数だけ再使用されてもよい、またはゲートウェイ、サーバ、ユーザからの、もしくは製造時にプロビジョニングされた１つもしくはそれを上回るネットワーク選好に応じて、限定回数だけ使用されてもよい。ＰＲＮＧ内の場所を識別する１６バイトの秘密は、初期ＰＲＮＧデータベクトルとして定義される。

プロセス１１００は、キー配布テーブル生成１１０４を含む。キー配布テーブルは、概して、以下に説明されるように、データテーブルを難読化および難読化解除において使用するためのデバイスに送信するために使用される。キー配布テーブルを生成するために、秘密の一部は、ＰＲＮＧのためのジャンプベクトルとして使用され、結果として生じる擬似乱数シーケンスは、テーブルを生成するために使用される。任意のタイプのＰＲＮＧが、使用されてもよい（例えば、ＴｉｎｙＭＴ）。キー配布テーブル生成は、ゲートウェイおよびコントローラの両方において行われる。各エンティティは、同一秘密を有するため、ＰＲＮＧを介して、同一キー配布テーブルを生成するであろう。

図４０を参照すると、キー配布テーブル生成１１０４が、より詳細に示される。キー配布テーブル生成１１０４は、テーブルを初期化すること（ブロック１１２０）を含み、これは、テーブル長およびテーブル内のエントリ毎の値を設定することを含んでもよい。例えば、ブロック１１２０は、テーブル内のＩ番目のエントリの値をＩに設定することを含んでもよい。

テーブルの第１のインデックス（ｉｎｄｅｘ＝０）から開始し、スワップ関数（ブロック１１２４）が、テーブル内の値をスワップするために使用される。例えば、所与のインデックス値に関して、現在のインデックスとテーブル長との間の次の擬似乱数（Ｓ）が、見出される。Ｓは、次いで、インデックスＩ（ＫＤＴ［Ｉ］）における値とスワップされるべき値のためのインデックスとして使用される。スワップ後、インデックスは、インクリメントされ（ブロック１１２２）、インデックスがテーブルの長さ未満である限り（ブロック１１２６においてチェックされる）、スワップ関数が、再び適用される（ブロック１１２４）。ＫＤＴ生成は、同一ＰＲＮＧおよび秘密を使用して行われるため、各デバイスは、同一テーブルを生成するであろう。

再び、図３９およびプロセス１１００を参照すると、プロセスは、データテーブル生成１１０６を含む。初期データテーブル（ＤＴ_０）は、ゲートウェイにおいてのみ生成される。データテーブルを生成するためのアルゴリズムは、キー配布テーブルを生成するためのアルゴリズム（図４０に示される）に類似し得るが、擬似乱数の代わりに、真乱数を使用して、スワップすべきインデックスを判定する。真乱数は、システムのエントロピに基づき得る。例えば、当業者が認識するであろうように、ＩＯＸ（ＭＡＣ ＯＳ）では、０と２５５との間の真乱数が、コード：Ｆｉｌｅ＝^＊ｒｎｄ＿ｆｉｌｅ＝ｆｏｐｅｎ（“／ｄｅｖ／ｒａｎｄｏｍ”，“ｒ”）；ｒａｎｄ＝ｆｇｅｔｃ（ｒｎｄ＿ｆｉｌｅ）を使用して生成され得る。別の実施例を用いると、当業者が把握するであろうように、Ｌｉｎｕｘ（登録商標）では、ランダム値が、カーネルエントロピプールから取得され得る。データテーブルＤＴ_０は、ゲートウェイにおいてのみ生成されるため、真乱数が、使用されることができる。ゲートウェイは、以下により詳細に説明されるように、コントローラおよびゲートウェイが同期しなくなる場合に使用するために、ＤＴ_０をＲＡＭ内に記憶してもよい。ゲートウェイは、コントローラ毎に、別個のデータテーブルを維持する。

プロセス１１００はさらに、データテーブル交換１１０８を含む。データテーブル交換プロセスは、概して、ＫＤＴ（以下に説明される）を使用して、データテーブルをシャッフルアルゴリズムでエンコードし、エンコードされたテーブルをコントローラに伝送することを含む。いったんコントローラがＤＴ_０を受信すると、以下により詳細に説明されるように、コントローラおよびゲートウェイが同期しなくなる場合に備えて、ＤＴ_０のコピーもまたＲＡＭ内に維持してもよい。プロセス１１００はさらに、ベクトル同期１１１０を含む。任意のデバイスが、そのパートナーと、秘密または秘密の一部（すなわち、単に、ＰＲＮＧシーケンス内のジャンプベクトルを識別する１６バイト、または多項式指数値およびジャンプベクトルの両方を含む、完全２８バイト）を交換してもよい。１つを上回るＰＲＮＧシーケンスが、アルゴリズムによって使用される場合、１つを上回るベクトルおよび多項式は、デバイス間で交換されてもよい。

随時、ゲートウェイは、新しい秘密を生成し、コントローラに送信してもよい。このように、コントローラとゲートウェイの将来的再初期化は、異なる初期秘密、したがって、異なるＫＤＴの交換をもたらすであろう。古い秘密は、ゲートウェイおよびコントローラの両方において、新しい秘密で上書きされるであろう。本プロセスは、攻撃者がデバイス間の通信についての付加的情報を判定することを可能にするであろう、コントローラおよびゲートウェイの反復的同期を防止することによって、全体的システムのセキュリティを増加させる。別の実施形態では、ゲートウェイは、特定の「秘密」が使用されることができる閾値回数を含んでもよい。さらに別の実施形態では、ゲートウェイは、複数の同期を連続して試みることが著しく困難になるように、同一「秘密」値の各後続使用間の時間量を増加させてもよい。

再び、図３８を参照すると、環境１０００は、随意に、デバイス１００２、ゲートウェイ１００４、およびサーバ１００６のいずれかと通信可能なキー配布センタ１００８を含んでもよい。代替実施形態では、キー配布センタ１００８は、図３９−４０に説明されるように、キープロビジョニング特徴を提供してもよい。そのような場合では、キー配布センタ１００８は、デバイス１００２またはコントローラ毎に、識別情報を有してもよい。

コントローラ、ゲートウェイ、またはサーバが、最初にオンになると、セッションをキー配布センタ１００８と確立してもよく、セッションは、コントローラ、ゲートウェイ、またはサーバのためのデータテーブルを作成する。したがって、セッション毎に、キー配布テーブルが、存在する（以下では、それぞれ、コントローラ、ゲートウェイ、およびサーバに関して、Ｔ_Ｃ、Ｔ_Ｇ、およびＴ_Ｓとして標識される）。いくつかの実施形態では、デバイス１００２は、直接、キー配布センタ１００８と通信不可能であり得る。それらのケースでは、デバイス１００２からの通信は、ゲートウェイ１００４によってキー配布センタ１００８に中継されてもよい。

デバイス１００２のコントローラが、ゲートウェイ１００４とトークすることを所望する場合、データテーブルをキー配布センタ１００８から要求してもよい。デバイス１００２が、直接、キー配布センタ１００８と通信することができないとき等、いくつかの実施形態では、ゲートウェイ１００４およびデバイス１００２が、相互に通信するためにまだプロビジョニングされていない場合でも、ゲートウェイ１００４は、デバイス１００２からのキー配布センタ１００８に中継されるための要求を許可してもよい。一実施形態では、キー配布センタ１００８は、新しいデータテーブル（ＤＴ_ＣＧ）の２つのコピーをゲートウェイに送信し、テーブルの一方は、ゲートウェイのためのものであって、一方は、コントローラのためのものである。ゲートウェイのためのＤＴ_ＣＧは、Ｔ_Ｇを使用してエンコードされ、コントローラのためのＤＴ_ＣＧは、Ｔ_Ｃを使用してエンコードされる。ゲートウェイは、次いで、コントローラのＴＤＫ（Ｔ_Ｃ）でエンコードされたＤＴ_ＣＧをコントローラに中継する。ゲートウェイおよびコントローラはそれぞれ、その個別のキー配布テーブルを有し、したがって、ＤＴ_ＣＧのその独自のコピーをデコードすることができる。他の実施形態では、キー配布センタ１００８は、ＤＴ_ＣＧを、直接、コントローラに送信し、再び、Ｔ_Ｃでエンコードされてもよい。

同様に、ゲートウェイが、コントローラとトークすることを所望する（またはコントローラがゲートウェイとトークすることを所望していることのメッセージをコントローラから受信する）と、ゲートウェイは、要求をキー配布テーブル１００８に送信し、セッションを確立する。いったんセッションキー（Ｔ_Ｃ）が、コントローラに送信されると、ゲートウェイは、ゲートウェイ−コントローラ通信において使用するためのデータテーブルのために、要求をキー配布テーブル１００８に送信することができる。ゲートウェイは、次いで、上記に説明されるように、新しいデータテーブルの２つのコピーを受信し、エンコードされたデータテーブルをコントローラに中継する。

上記に説明されるように、いったんデータテーブルが、生成されると（ゲートウェイまたはキー配布センタのいずれかによって）、データテーブルが伝送される前に、シャッフルアルゴリズムが、データテーブルに適用され、テーブル内のデータを難読化してもよい。ここで図４１を参照すると、データテーブル内のデータをエンコードする１つの方法が、説明される。図４１に示されるプロセス１２００は、コントローラへの最初のペイロード伝送のためと、次いで、後に、送信機および受信機が同期するために必要である場合に使用され得る、スタンドアロンエンコードアルゴリズムであってもよい。スタンドアロンエンコードアルゴリズムは、状態独立である（擬似ランダムシーケンス内の前の位置を把握する必要はない）。スタンドアロンエンコードアルゴリズムは、ＰＲＮＧデータベクトル（例えば、秘密）を初期化または再初期化する必要があるとき、ゲートウェイによって開始される。本開示では、「秘密」および「ＰＲＮＧデータベクトル」は、同義的に使用され得る。

プロセス１２００は、真乱数を生成すること（ブロック１２０２）と、伝送されるためのフレームを設定すること（ブロック１２０４）とを含む。また、図４２を参照すると、例示的フレームが、フレームの先頭に設定されたＲＮＤ値（ブロック１２０２において判定された）と、フレームの後尾に設定されたＣＲＣ値（ブロック１２０６において判定された）とともに示される。プロセス１２００はさらに、巡回冗長性コード（ＣＲＣ）を計算すること（ブロック１２０６）を含む。ＣＲＣは、好ましくは、ペイロードおよび乱数に関してともに計算される。

プロセス１２００はさらに、フレームを乱数のアレイとＸＯＲすること（ブロック１２０８）を含む。秘密は、ＲＮＤ値として設定され、ＰＲＮＧは、秘密でシードされ、ペイロードおよびＣＲＣと長さが等しい乱数のアレイを作成する。本生成されたアレイは、フレームをＸＯＲするために使用される。ＸＯＲは、オリジナルペイロードおよびＣＲＣを難読化し、データテーブルのデコードを試みるプレーンテキスト攻撃を防止する。

プロセス１２００はさらに、シャッフルアルゴリズム（ブロック１２１０）を含む。データテーブルは、フレーム内のビットをシャッフルするために使用される。シャッフルは、ビットマスク、宛先バッファ、ビットインデックス、バイトオフセット、およびビットオフセットのアレイを使用する。データテーブルが、ペイロードである場合、ＴＤＫが、フレーム内のビットをシャッフルするために使用される。

ここで図４３を参照すると、シャッフルアルゴリズムが、より詳細に示される。アルゴリズムは、宛先バッファ（例えば、宛先バッファを全てゼロに初期化する）を初期化すること（ブロック１２２０）を含む。フレーム内のビットインデックス毎に、以下が、実施されてもよい。

オフセットが、計算される（ブロック１２２２）。例えば、ｂｙｔｅ ｏｆｆｓｅｔ＝ｂｉｔ ｉｎｄｅｘ／８が、計算され、ｂｉｔ ｏｆｆｓｅｔ＝ｂｉｔ ｉｎｄｅｘ％８が、計算される。フレームビットが、試験され（ブロック１２２２）、ｂｉｔ ｍａｓｋ［ｂｉｔ ｏｆｆｓｅｔ］ ＡＮＤ ｆｒａｍｅ［ｂｙｔｅ ｏｆｆｓｅｔ］の両方が真であるかどうかをチェックすることによって、フレームバイト内のビットが設定されるかどうかを判定する。両値が、真である場合、宛先ビットが、データテーブル（すなわち、ｄｅｓｔｉｎａｔｉｏｎ ｂｉｔ ｉｎｄｅｘ＝ＤＴ［ｂｉｔ ｉｎｄｅｘ］を使用して計算される（ブロック１２２６）。宛先オフセットが、計算される（ブロック１２２８）。例えば、ｄｅｓｔｉｎａｔｉｏｎ ｂｙｔｅ ｏｆｆｓｅｔ＝ｄｅｓｔｉｎａｔｉｏｎ ｂｉｔ ｉｎｄｅｘ／８およびｄｅｓｔｉｎａｔｉｏｎ ｂｉｔ ｏｆｆｓｅｔ＝ｄｅｓｔｉｎａｔｉｏｎ ｂｉｔ ｉｎｄｅｘ％８。宛先ビットが、設定される（ブロック１２３０）。例えば、宛先ビット（ＤＢ）は、ＤＢ［ｄｅｓｔｉｎａｔｉｏｎ ｂｙｔｅ ｏｆｆｓｅｔ］と等しく設定される。別の実施例として、ＤＢ＝ｍａｓｋ［ｄｅｓｔｉｎａｔｉｏｎ ｂｙｔｅ ｏｆｆｓｅｔ］。ブロック１２２２−１２３０は、フレーム内のビットインデックス毎に繰り返される（ブロック１２３２）。ステップ１２０８の一部として作成されたＰＲＮＧデータベクトルは、エンコード／デコードシーケンシャル伝送における後の使用のために、ゲートウェイのメモリ内に保存される。

ここで図４４を参照すると、デコードスタンドアロンアルゴリズムが、コントローラがエンコードされたデータテーブルをゲートウェイから受信することによって実装され得るように示される（プロセス１２４０）。プロセス１２４０は、エンコードされたフレーム内のフレームビットをシャッフル解除する、シャッフル関数（ブロック１２４２）を含む。プロセス１２４０はさらに、ＰＲＮＧデータベクトルまたは秘密として使用するためのフレームの開始時に位置する真乱数を読み出すこと（ブロック１２４４）を含む。ＰＲＮＧは、秘密でシードされ、ＰＲＮＧからの数字は、フレーム（例えば、ペイロードおよびＣＲＣ）をＸＯＲするために使用される（ブロック１２４６）。これは、オリジナルペイロード（例えば、オリジナルデータテーブル）を露見させる。ＣＲＣは、除去され（ブロック１２４８）、コントローラは、ペイロードおよび乱数のためにＣＲＣを計算し、それを除去されたＣＲＣと比較し、コントローラとゲートウェイとの間の同期を確実にする。ＣＲＣ検査が失敗する場合、受信機は、同期が喪失されたと結論付ける。

同期が、コントローラとゲートウェイとの間で喪失される場合、コントローラは、オリジナルデータテーブル（ＤＴ_０）を使用して、エンコードされた同期コマンドをゲートウェイに送信してもよい。ゲートウェイは、最初に、現在のデータテーブルを使用して、コマンドのデコードを試みるであろう。メッセージをデコードするその試みが、失敗する場合、ゲートウェイは、次いで、オリジナルデータテーブル（ＤＴ_０）を使用して、メッセージのデコードを試みることができる。ゲートウェイが、ＤＴ_０を使用してメッセージのデコードに成功する場合、コントローラが同期を喪失した（例えば、古いデータテーブルを使用していた）と結論付け得る。コントローラが、もはや現在のデータテーブルまたはＤＴ_０を有していない（例えば、電力を喪失した）場合、コントローラは、上記に説明されるように、秘密を使用して、ＴＤＫを生成し、ゲートウェイに、再同期するためにＴＤＫでエンコードされた要求を送信することができる。ゲートウェイは、最初に、現在のデータテーブルを使用して、メッセージのデコードを試み、これは、ＣＲＣ検査に失敗するであろう。ゲートウェイは、次いで、ＤＴ_０を使用して、メッセージのデコードを試み、これもまた、ＣＲＣ検査に失敗するであろう。最後に、ゲートウェイは、ＴＤＫを生成するために記憶された秘密値を使用して、メッセージのデコードを試みるであろう。ＴＤＫを用いてデコードの成功は、ゲートウェイに、コントローラが電力を喪失した（または別様にオリジナルデータテーブルを喪失した）ことを示す。ゲートウェイは、次いで、新しいＤＴ_０を生成し、ＴＤＫでエンコードされ、かつ図４１において上記に説明されるように、スタンドアロンメッセージとしてエンコードされたそれをコントローラに送信することができる。

コントローラとゲートウェイとの間の喪失された同期の別の実施例として、ゲートウェイが、コントローラと同期していない（例えば、コントローラが、メッセージを送信したが、圏外であって、したがって、メッセージが、ゲートウェイによって受信されないが、コントローラは、次のテーブルにすでに切り替えている）ことを認識し得る。ゲートウェイは、エンコードスタンドアロンアルゴリズムを使用してＴＤＫでエンコードされた、新しいＰＲＮＧデータベクトル（真ＲＮＧをシードとして使用してＰＲＮＧから生成される）をコントローラに送信することができる。コントローラは、現在のデータテーブルを用いて、メッセージのデコードを試みるであろう（ＣＲＣ検査に失敗するであろう）。コントローラは、次いで、ＲＡＭ内に記憶されるＤＴ_０を使用して、メッセージのデコードを試みるであろう（同様に、ＣＲＣ検査に失敗するであろう）。コントローラは、次いで、記憶していた秘密を使用して、ＴＤＫを生成することができ、ＴＤＫを使用して、メッセージのデコードを試みることができる（成功するであろう）。ゲートウェイはまた、ＴＤＫを秘密から生成し、ＴＤＫを使用して、データテーブルを生成する。

コントローラとゲートウェイとの間の喪失された同期の別の実施例として、コントローラは、電力を喪失し、もはやＴＤＫを有していない場合がある。コントローラは、したがって、ゲートウェイによって送信される新しい秘密をデコードすることが不可能である。コントローラは、次いで、記憶された秘密を使用して、ＴＤＫを生成し、ゲートウェイに、再同期のための要求を送信してもよく、要求は、ＴＤＫを使用してエンコードされる。ゲートウェイは、現在のデータテーブル（失敗）、ＤＴ_０（失敗）、次いで、ＴＤＫ（成功）を使用して、メッセージのデコードを試みる。ゲートウェイは、エンコードスタンドアロンアルゴリズムを使用して、新しいＲＮＧをコントローラに送信する（新しい秘密またはＰＲＮＧデータベクトルを見出すためにＰＲＮＧと併用される）。ゲートウェイは、次いで、ＴＤＫを使用して、データテーブルを生成し、それをコントローラに送信する。

いくつかの実施形態では、ゲートウェイが、閾値時間量にわたって、コントローラとの通信に失敗する場合、全てのテーブルを破棄し、後続通信に応じて、コントローラと再初期化してもよい。いくつかの実施形態では、新しいデータテーブルが送信される度に、新しい秘密が、前述のように、同様に送信されてもよい。

概して、図４１−４４を参照すると、データをエンコードおよびデコードするためのエンコードおよびデコードスタンドアロンアルゴリズムが、説明される。別の実施形態では、エンコードおよびデコードするシーケンシャルアルゴリズムが、伝送されるためのデータをエンコードおよびデコードするために使用されてもよい。ここで図４５を参照すると、例示的エンコードシーケンシャルアルゴリズム方法が、示される。シーケンシャルアルゴリズムでは、コントローラおよびゲートウェイの両方が、ＰＲＮＧおよびテーブルの状態を保つ。パケット毎に、ＰＲＮＧの位置は、ＰＲＮＧデータベクトルに基づいて変化する（最初に、秘密、続いて、ＰＲＮＧが前のパケット内で中断した場所）。テーブルは、ペイロードおよびＰＲＮＧシーケンスに基づいて変更される（すなわち、テーブルへのデータ駆動変更）。これは、「テーブルブロックチェーニング」と称され得る。

シーケンシャルアルゴリズムの間に変更されるテーブルの部分のサイズは、構成可能であって、「変更サイズ」と称される。一実施形態では、変更サイズは、素数であってもよく、および／またはデータテーブルのサイズは、変更サイズによって均一に分割可能であるべきではない。変更サイズとサイズが等しいテーブル修正バッファ（ＴＭＢ）が、シーケンシャルアルゴリズムの間、変更ベクトルを一時的に記憶するために使用されてもよい。

図４５のプロセス１３００を参照すると、フレームが、ペイロードとともに設定され（ブロック１３０２）、ＣＲＣが、ペイロードのために計算される（ブロック１３０４）。ＣＲＣは、フレームの最後に追加される（例えば、図４２に示されるように）。上記に説明されるように、スタンドアロンアルゴリズムでは、ＰＲＮＧからの値（秘密を使用して）は、フレームとＸＯＲするために使用される（ブロック１３０６）。

第１の変更サイズＸＯＲ値は、テーブル修正バッファにコピーされる（ブロック１３０８）。データテーブルは、フレームビットをシャッフルするために使用され（ブロック１３１０）、データテーブルは、次の伝送と併用するために修正される（ブロック１３１２）。ここで図４６を参照すると、テーブル修正ブロック１３１２が、より詳細に説明される。データテーブルは、各フレーム難読化後に修正されてもよい。テーブル修正プロセスは、概して、取って代わられるための次の値のインデックスを見出すことと、値をテーブル修正バッファ内のそのインデックスのための値に取って代えることとを含んでもよい。

インデックスｉ＝０から開始し、ＴＭＢ［ｉ］内に記憶された値を読み出すことによって、スワップインデックスＳを特定する（ブロック１３２０）。次いで、データテーブル内において、インデックスｉおよびインデックスＳ内に記憶された値をスワップする（ブロック１３２２）。本プロセスは、テーブル修正バッファ内のエントリ毎に繰り返される（ブロック１３２４）。

次回、データテーブルが修正されると、修正は、前の反復において修正された最後のエントリ後の次のエントリから開始し得る。インデックスが、データテーブルのサイズに到達すると、ラップアラウンドし、データテーブルの開始時から継続する。ＰＲＮＧデータベクトルは、次回使用するために、処理されたばかりのフレームの長さだけ増加される。例えば、変更サイズが、７であると判定され、データテーブルのサイズが、１２である場合、ＤＴ_１は、値ＤＴ_０［０］からＤＴ_０［６］を値ＤＴ_０［Ｓ［０］］からＤＴ_０［Ｓ［６］］とスワップさせることによって、ＤＴ_０に基づいて生成され、Ｓは、テーブル修正バッファである。次回、ＤＴ_２から始まり、次いで、値ＤＴ_１［７］からＤＴ_１［１２］を値ＤＴ_１［Ｓ［０］］からＤＴ_１［Ｓ［６］］とスワップさせることによって、ＤＴ_１に基づいて生成され、Ｓは、テーブル修正バッファ内に記憶される新しい値を含有する。

別の実施形態では、修正されるべきデータテーブルの部分は、テーブルと各後続変更の重複部分の変更等、代替方法において判定されてもよい。さらに別の実施形態では、データテーブルは、閾値数のフレームが送信／受信された後にのみ変化してもよい。さらに別の実施形態では、データテーブルの１つおきのビットのみが、変化してもよい。さらに別の実施形態では、テーブルのある部分は、スキップされ、改変されなくてもよい。データテーブル修正はまた、０インデックスからの代わりに、素のオフセットから開始してもよい。当業者は、任意の数の代替修正または組み合わせもまた、データテーブルを修正するために実装されてもよいことを認識するであろう。同様に、当業者は、ＰＲＮＧデータベクトルを修正するための任意の数の代替技法を認識するであろう。

単独では、ＸＯＲ関数およびシャッフル関数はそれぞれ、データ難読化のための比較的に脆弱な方法であるが、しかしながら、組み合わせられると、難読化の強度は、その一部の和より増加される。テーブル更新は、ＰＲＮＧおよびペイロードの関数である。テーブルは、ＸＯＲを介して修正されたペイロードデータに基づいて修正される。ＸＯＲとシャッフル関数との間でテーブル更新を行うことは、ハッカーが反復攻撃を通してデータを判定することができないため、テーブル修正をハッキングの試みから保護する。

一実施形態では、シャッフルステップ（ブロック１３１０）後、付加的ＸＯＲが、異なるＰＲＮＧシーケンスを使用して行われてもよい。複数のＰＲＮＧデータベクトルが、異なるＰＲＮＧシーケンスを使用するために、交換および使用されてもよい。他の実施形態では、付加的ＸＯＲは、適用されなくてもよい、または図４５に示されるＸＯＲおよびシャッフル関数に加え、付加的変換が、適用されてもよい。

一実施形態では、前述のプロセスに説明されるように、ＰＲＮＧ値は、シャッフルテーブルとＸＯＲされ、次いで、ＸＯＲされた値は、データとＸＯＲされ、次いで、結果として生じるＸＯＲされたデータは、シャッフルされる。ＰＲＮＧ値とシャッフルテーブルのＸＯＲは、ＰＲＮＧを隠蔽し、ＰＲＮＧをプレーンテキスト攻撃に対して防御する。図４５を参照すると、ブロック１３０６は、ＰＲＮＧ値とシャッフルテーブルのＸＯＲと、本最初のＸＯＲ結果とフレームのＸＯＲとを含むであろう。これは、フレーム毎に実施される。別の実施形態では、これは、最初のフレームのために行われてもよいが、後続フレームに関して、テーブルとＸＯＲするためにＰＲＮＧ値を使用する代わりに、前のフレームからのＸＯＲされたデータ（シャッフル前であるが、全ての他の難読化後）が、ＰＲＮＧ値の代わりに、シャッフルテーブルとＸＯＲされる。本実施形態は、処理効率を増加させる。図４５を参照すると、ブロック１３０６は、ＰＲＮＧ値の代わりに、前のフレームからのＸＯＲされたデータと新しいフレームのＸＯＲを含むであろう。各そのような実施形態では、デコードプロセスは、データをデコードするためのミラーステップを含む。

コントローラは、エンコードされた伝送をゲートウェイから受信し、デコードシーケンシャルアルゴリズムを使用し、データをデコードすることができる。コントローラは、データテーブルを使用して、フレームビットをシャッフル解除してもよく、シャッフル解除されたテーブルは、テーブル修正バッファ内で使用されることができる。データテーブルは、次いで、テーブル修正バッファ内のテーブルを使用して、かつ図４６に説明されるものと同一修正ステップを使用することによって、次の伝送と併用するために修正される。次いで、ＰＲＮＧからの数字は、フレームをＸＯＲし、ペイロードおよびＣＲＣを露見させるために使用される。最後に、コントローラは、ペイロードのためのＣＲＣを計算し、それをフレームからのＣＲＣに対して比較し、コントローラがゲートウェイと同期していることを検証することができる。ＣＲＣが、同一である場合、メッセージは、コントローラによって承認され、ＰＲＮＧデータベクトルは、次の伝送のために使用するためのフレームの長さだけ増加される。

概して、図３８−４６を参照すると、通信が完全であることが保証されない、複数のデバイスとゲートウェイとの間の通信プロトコルを促進するためのプロトコルおよびアルゴリズムが、説明される。ここで後続段落を参照すると、ゲートウェイと遠隔サーバとの間のより高い帯域幅通信を促進するためのアルゴリズムが、説明される。より高い帯域幅通信が可能である場合、情報は、概して、ＴＣＰ−ＩＰを経由して渡されるように構成され得る。ＴＣＰ−ＩＰプロトコルを使用することによって、ペイロードの伝送は、ＴＣＰ−ＩＰプロトコルの中に組み込まれる再伝送技法に起因して、完全であることが保証される。それらのケースでは、アルゴリズムは、所与のデータパケット（例えば、データテーブル）に関して、そのテーブルサイズ（例えば、上記に説明されるように、データテーブルのサイズ）によって分割可能であるフレームサイズを受け取り得る。例えば、１６０のテーブルサイズに関して、アルゴリズムは、１，６００バイトフレームを受け取り得る。別の実施例として、２５６のテーブルサイズに関して、アルゴリズムは、１，０２４バイトフレームを受け取り得る。

各フレームは、複数のブロックから作製され、ブロックは、データテーブルサイズと同一サイズを有する。アルゴリズムは、各ブロックをエンコードする。図３８−４６のアルゴリズムと比較して、これらのブロックをコーディングするためのアルゴリズムは、同様に作用し得るが、ＣＲＣを使用して、ブロックを検査する必要がない。

ＴＣＰ−ＩＰプロトコルを使用するときのエンコーディングアルゴリズムは、所与のフレームに関して、ＰＲＮＧからの数字を使用して、フレームをＸＯＲし、したがって、オリジナルペイロードを隠蔽し、データテーブルのデコードを試みるプレーンテキスト攻撃を防止することを含む。ＸＯＲされた値は、データテーブル更新において使用するためにＴＭＢにコピーされる。データテーブルは、次いで、フレームビットをシャッフルするために使用され、データテーブルは、次いで、ＴＭＢを使用して修正される（上記に説明されるように）。シャッフル後、付加的ＸＯＲが、異なるＰＲＮＧシーケンスを使用して行われてもよい。他の実施形態では、付加的ＸＯＲステップは、存在しなくてもよい、または付加的変換が、基本的ＸＯＲおよびシャッフルステップの周囲に追加されてもよい。

付随のデコーティングアルゴリズムでは、ＰＲＮＧは、着信したエンコードされたバッファをＸＯＲするために使用された、ＰＲＮＧデータベクトル（例えば、秘密）でシードされる。データテーブルは、次いで、フレーム内のビットをシャッフル解除するために使用される。データテーブルは、次いで、シャッフル解除されたバッファをＴＭＢとして使用して修正される。ＰＲＮＧからの数字は、次いで、フレームをＸＯＲし、オリジナルペイロードを露見させるために使用される。

いくつかの実施形態では、通信プロトコルが、複数のデバイス間に作成されてもよく、複数のデバイスは、１つまたはそれを上回る固定基地局と、１つまたはそれを上回るモバイルデバイスとを含む。例えば、本明細書に説明されるシステムおよび方法は、ユーザの複数のモバイルデバイスと、例えば、建物、走行経路、または同等物上の複数の固定基地局との間の通信を管理するように適合されてもよい。種々の交通機関管理のための固定基地局の実施例が、以下で使用され、他の実施形態では、固定基地局は、エリアを管理する、リソースを配分する、および同等物のための任意のタイプの固定基地局であってもよい。

固定基地局は、概して、情報を送信および受信するための限定量のスペクトルを有し得る。高速通信を提供するために、固定基地局は、固定基地局と同時に通信するユーザの数を限定する必要があり得る。したがって、固定基地局の全体的ネットワークが、多くのユーザを受け入れることを可能にするために、複数の固定基地局が、相互の比較的に近傍に設置されてもよく、モバイルデバイスは、サービスの中断を伴わずに、セッションを維持しながら、固定基地局間で切り替えてもよい。モバイルデバイスと固定基地局との間の認証は、モバイルデバイスが移動し、パッケージを複数の固定基地局から受信し、固定基地局が、パッケージを複数のモバイルデバイスから受信するにつれて生じるべきである。本明細書に説明されるシステムおよび方法は、両者（すなわち、固定基地局およびモバイルデバイス）に既知のキーを使用して、以下に説明されるように、パッケージを認証および難読化する。より具体的には、固定基地局とモバイルデバイスとの間のパッケージを認証およびデコードするために使用される、キーをモバイルデバイスに動的に提供するための予測アルゴリズムが、説明される。

図４７を参照すると、複数の固定基地局１４０２と、複数のモバイルデバイス１４０４とを含む、環境１４００が、示される。上記に説明されるように、複数の固定基地局１４０２は、相互の比較的に近傍に設置されてもよく、方略的理由から（例えば、エリア内により多くの無線ネットワークカバレッジを提供するため）、任意のパターンまたは順序で配列されてもよい。モバイルデバイス１４０４は、例えば、異なる固定基地局１４０２の範囲内外において、環境１４００の周囲をトラバースする、携帯電話、可動物体に取り付けられるデバイス、または車両等であってもよい。図示されるように、モバイルデバイス１４０４は、移動するにつれて、固定基地局１４０２に対して任意の位置にあってもよく、複数の固定基地局の範囲内にあってもよい。本明細書に説明されるシステムおよび方法を使用して、モバイルデバイス１４０４は、第１の固定基地局に接続し、セキュア化された伝送を伴うセッションを確立し、次いで、第２の固定基地局に接続し、同一のセキュア化された伝送を伴う同一セッションを維持することが可能となり得る。

一実施形態では、モバイルデバイスまたは他のモバイルプラットフォームは、複数のユーザを有してもよい。例えば、上記に述べられた走行経路実施例を使用すると、モバイルプラットフォームは、一部の乗車者が、電話で会話しながら、または映画を鑑賞しながら、交通情報を複数の固定基地局から受信することができる、スマート自動車であってもよい。別の実施例では、モバイルプラットフォームは、個々のユーザがインターネットをブラウジングしながら、線路状況情報を受信することができる、電車であってもよい。固定基地局は、交通機関方法の通視線または経路内に位置してもよい。固定基地局は、例えば、高速通信チャネルを介してネットワークに接続される、ネットワーク化固定基地局であってもよい。別の実施例として、固定基地局は、情報をモバイルデバイスに提供するための固定情報基地局であってもよい（例えば、線路が閉鎖されている場合、または交通渋滞の場合、電車を停止または減速させるようにアラートする等、電車の線路状況についての情報）。スマートシティ情報システムでは、そのような基地局は、交通を動的に平衡し、車両が走行時間を最小限にすることを可能にするために使用されてもよい。固定基地局は、ネットワーク化されていない場合、鉄道線路内の遠隔固定基地局の場合のように、通過する車両によって更新されてもよい。

そのような通信プロトコルにおいて送信されるパッケージは、任意のサイズであってもよく、パッケージ全体または単にパッケージの一部が、本明細書に説明されるシステムおよび方法を介して難読化されてもよい。パッケージは、例えば、ＣＲＣ値を使用して、認証されてもよい。別の実施例として、パッケージは、パッケージ内のタイムスタンプ情報を識別し、パッケージ上のタイムスタンプと宛先デバイス上の現在の時間を比較し、パッケージが最新のものであることを確実にすることによって、認証されてもよい。

パッケージは、完全または部分的に、予期される固定基地局への接続の数と、基地局とモバイルプラットフォームとの間のセッションをネゴシエートするために利用可能な時間量とに応じて、エンコードされてもよい。いくつかのパッケージは、固定基地局によってタイムリーな様式で処理される、セッションＩＤ番号または別の識別方法を含んでもよい。これらの値をエンコードしないことによって、パッケージ全体は、固定基地局によって、より迅速に処理およびハンドリングされ得る。明確な識別値はまた、固定基地局が、ユーザの識別を推測する必要なく、パッケージを正しいデータテーブルでデコードすることを可能にする。

ここで図４８を参照すると、パッケージを固定基地局へおよびそこから伝送するための例示的方法１５００が、示される。方法１５００は、ペイロード１５０２と、パティングされた値１５０４とから成る、パッケージから開始する。パティングされたデータ１５０４は、ペイロード１５０２のエンコーディング、デコーティング、および認証を促進するための既存のパティングされたデータであってもよい。パティングされたデータ１５０４は、ハッシュ、タイムスタンプ、ＣＲＣ、または他の値であってもよい。値を生成する代わりに、パティングされたデータ１５０４を使用して、データをエンコードおよびデコードすることによって、パッケージ１５００の総サイズへの追加は、存在しない。

伝送のためのパッケージをフォーマットする際、パティングされたデータ１５０４が、最初に、パッケージから抽出され、次いで、擬似乱数１４０６を生産する、ＰＲＮＧのためのシードとして使用される。

次に、ＸＯＲが、擬似乱数１５０６を使用して、ペイロード１５０２に実施される。これは、オリジナルペイロードを隠蔽し、データをプレーンテキスト攻撃に対して防御する。これはまた、上記に説明されるように、ＰＲＮＧをシャッフル／スクランブルテーブルとＸＯＲすることおよび／または以前のフレームのＸＯＲされたデータをＰＲＮＧと置換することを含んでもよい。抽出されるパティングされたデータ１５０４は、次いで、ＸＯＲされたペイロード１５０２に再付加され、パッケージ全体が、スクランブルされる（１５０８）。

スクランブルされたパッケージ１５０８は、伝送され、宛先において受信される。宛先では、パッケージ１５０８は、スクランブル解除され、パティングされたデータ１５０４は、その既知の場所から抽出される。パティングされたデータ１５０４は、次いで、ＰＲＮＧにシードし、送信機と同一擬似乱数を生産するために使用される。ペイロード１５０２は、擬似乱数とＸＯＲされ、オリジナルペイロードを生産する。

抽出されたデータの性質に応じて、ペイロードの真正性を検証するためのいくつかの方法が、存在する。一実施例として、予期されるＣＲＣ値が、計算され、抽出されたＣＲＣと比較される。別の実施例として、ペイロードの予期されるハッシュが、算出され、抽出されたハッシュと比較される。別の実施例として、タイムスタンプは、宛先の現在の時間と比較される。

一実施形態では、スクランブリングアルゴリズムは、ペイロードのサイズに関するため、ＸＯＲおよびスクランブルの範囲を調節することによって、明確な識別値を保存するように修正されることができる。同様に、識別値は、パティングされたデータとして取り扱われ、パッケージの残りをＸＯＲするために使用される。しかしながら、スクランブリングは、パティングされたデータを除外し、それを明確なテキストとして保つであろう。

キーが、パッケージをデコードするために使用される。固定基地局およびモバイルデバイス環境内でキーを提供する１つの方法が、図４９に説明される。セッションサーバ１６０２は、経路内を移動するにつれて、モバイルデバイスにキーを動的にプロビジョニングするために使用される。セッションサーバ１６０２は、中継塔１５０６（例えば、固定基地局）との通信を維持する。塔１６０６が、電源投入される（例えば、オンラインになる）と、セッションが、セッションサーバ１６０２と確立される。

ポリシサーバ１６０４は、モバイルデバイス（例えば、ユーザ）を通信サーバと認証させてもよい。モバイルデバイス１６０８が電源投入されるとき、デバイスは、任意のテーブルベースのキーを有していない。必要なキーを入手するために、モバイルデバイス１６０８は、ネットワークに対して認証を行い、ネットワークを使用するための認可を受信してもよい。モバイルデバイス１６０８は、パブリックキーインフラストラクチャ（ＰＫＩ）を使用して、セッションをポリシサーバ１６０４と確立してもよい。セッションは、セルラーネットワークを経由して、またはネットワーク送受信塔と通信することによって、確立されることができる。ネットワーク送受信塔は、ブートストラップ要求をポリシサーバ１６０４に転送してもよい。

接続が、ポリシサーバ１６０４と確立されると、その署名された証明書をモバイルデバイス１６０８に送信する。デバイスは、ＰＫＩを使用して、証明書の真正性を検証し、真正である場合、ポリシサーバ１６０４のパブリックキーでエンコードされた秘密を生成し、それを送信する。ポリシサーバ１６０４は、そのプライベートキーを使用して、秘密を開放する。会話の両者は、秘密を使用して、擬似乱数のシーケンスを生成し、それらの数字を使用して、ＫＤＴを作成する。ＫＤＴが、作成された後、ポリシサーバ１６０４は、セッションデータテーブルを作成し、ＫＤＴを使用して、それをデバイス１６０８に送信する。ユーザ証明書が、データテーブルを使用して、ポリシサーバ１６０４と交換される。ユーザ（例えば、モバイルデバイス１６０８）が、サービスを使用することが認可される場合、ポリシサーバ１６０４は、セッションをセッションサーバ１６０２にハンドオーバする。

セッションが、ポリシサーバ１６０４からハンドオーバされると、セッションサーバ１６０２は、ユーザの近傍の固定基地局を特定する。セッションサーバ１６０２は、デバイスに送信されるための固定基地局のセットを識別してもよい。

ユーザは、識別された経路外または識別された経路内に存在してもよい。ユーザが、識別された経路内に存在しないとき、識別された固定基地局のセットは、全ての経路の最も近い固定基地局を含む。ユーザが、識別された経路内に存在する場合、ユーザの方向および速度が、ＧＰＳを使用して計算されることができ、ユーザに提供するための固定基地局のセットは、ある数Ｐの前の基地局と、ある数Ｎの次の基地局とを含み、通常、Ｐは、Ｎ未満である。

数Ｎの次の基地局は、次のネットワーク化および非ネットワーク化基地局を含む。ユーザの場所と次のネットワーク化基地局との間の全ての非ネットワーク化基地局は、固定基地局のセット内に含まれるであろう。非ネットワーク化基地局に加え、含まれるべき次のネットワーク化基地局は、ヒューリスティックに判定される。例えば、経路が、分岐を間もなく有する場合、分岐に沿った基地局のＤＮＳが、経路に沿ったＤＮＳとともに含まれるであろう。

セッションサーバ１６０２は、デバイスのデータテーブルを固定基地局のセット内のネットワーク化固定基地局に送信する。ある場合には、全ての経路内の全ての基地局が、デバイス１６０８に送信され、全ての固定基地局の認証を可能にしてもよい。これは、例えば、全ての自動車が、ネットワーク通信のためのバックボーンを使用しない場合でも、固定基地局を認証する方法を有するであろう、自動車警告システムにおいて、または進行し得る全ての線路に沿った全ての固定基地局を認証する必要がある、機関車によって、使用されることができる。

本時点で、デバイス１６０８は、そのデータテーブルを使用して、塔１６０６と認証を行うことができる。データテーブルセッションを使用して、サーバ１６０２は、近傍塔テーブルをデバイスに送信するであろう。塔テーブルは、塔ブロードキャストメッセージを認証するために使用される。

固定基地局とユーザとの間のメッセージは、データテーブルを用いて暗号化される。

次の基地局のキーテーブルが、ユーザデバイス１６０８に送信される。システムは、悪意のあるユーザが、実際の固定基地局であるかのように、固定基地局のキーテーブルを入手し、そのキーテーブルを使用して、情報を提供しないように防止する必要がある。

固定基地局のセット内のキーは、ユーザのセッションキーデータテーブルを用いて暗号化され、それらは、システムによって長期記憶装置（ハードディスク等）に保存されることは決してない。

全ての固定基地局キーがユーザのデバイス内に常駐するケースでは、それらは、ユーザのデータテーブルを用いて暗号化され、データテーブル自体は、パスワードを用いて暗号化されるであろう。パスワードは、データテーブルをメモリに移動させるために使用され、キーは、メモリに移動するにつれて、デコードされる。このように、ボックスが、モバイルプラットフォームまたはモバイルユーザ（車両または電車等）から盗まれる場合、キーは、復元されることができない。

キーが、認証のために使用されるとき、メッセージの一部は、ユーザまたは固定基地局キーテーブルを用いて暗号化される。会話の受信側は、パッケージの難読化された部分をデコードし、真正性を検証する。これは、タイムコード等のデータのある既知の断片をエンコードすることによって、ペイロードのＣＲＣをエンコードすることにより行われることができる。パッケージが、デコードされた後、ＣＲＣまたはデータの既知の断片は、パッケージを認証するために使用される。

固定基地局は、認証されたパッケージのみを転送するように構成されてもよい。完全難読化が、所望されるとき、ペイロードは、本明細書で前述のように、別個のユーザ間セッションキーを使用して難読化されることができる。

パッケージは、タイムスタンプを含有し、基地局キーを用いてエンコードされてもよい。サービス妨害攻撃は、固定基地局に非認証着信メッセージを拒否させることによって回避されることができる。

ここで、概して、図５０−５６を参照すると、ネットワークアクセス制御システムが、説明される。ネットワークアクセス制御システムは、概して、例えば、証明書のリストを維持する、期限切れ証明書を管理する、証明書失効のリストを管理する、認証局失効リストを管理する、または同等物の必要なく、ネットワーク内の複数のノードのプロビジョニングおよび管理を可能にし得る。概して、本開示を参照すると、ノード間の通信のための難読化技法を提供するための種々のシステムおよび方法が、説明される。以下の説明は、ノード間に認可された通信を設定し、難読化されたデータがノード間で伝送されることを可能にするためのシステムおよび方法を説明する。

図５０を参照すると、ネットワークアクセス制御システム１７００の大まかなブロック図が、示される。ネットワークアクセス制御システム１７００は、概して、アクセス要求側１７０２と、ネットワークアクセスサーバ１７０４と、ポリシサーバ１７０６とを含む。アクセス要求側１７０２は、ネットワークに接続するように構成される、任意のデバイス（例えば、ネットワーク１７１０内の種々のノードに接続することを試みるモバイルデバイス、ネットワーク内のノードのうちの１つ等）であってもよい。デバイスは、概して、本開示に説明されるような任意のタイプのデバイスであってもよい。ネットワークアクセスサーバ１７０４は、要求をアクセス要求側１７０２（例えば、ユーザデバイス）から受信し、接続をネットワーク１７１０内の複数のノード１７０８に提供する。ノード１７０８は、異なる実施形態に従って、実際のまたは仮想マシンであってもよい。ポリシサーバ１７０６は、概して、種々のノード１７０８間の通信を認証してもよく、上記に説明されるようなポリシサーバ７０２および１６０４に類似してもよい。

ネットワークアクセス制御システムでは、アクセス要求側１７０２は、セキュアリンクを経由して、ネットワークアクセスサーバ１７０４と通信し、これは、次いで、いったんアクセス要求側１７０２が認証されると、セキュアリンクを経由して、ポリシサーバ１７０６と通信する。ポリシサーバ１７０６は、次いで、ネットワーク１７１０内のノード１７０８へのアクセス要求側１７０２のアクセス権を判定する。先行技術では、ノードとサーバとの間の各リンクは、トランスポート層セキュリティ（ＴＬＳ）プロトコル等のプロトコルによってセキュア化され得、証明書が、デバイス間の接続をセキュア化するために使用される。ノード１７０８は、概して、本開示に説明されるような任意のタイプのマシンまたはデバイス（例えば、実際のマシン、仮想マシン、プラットフォームコンポーネント、ソフトウェアコンポーネント等）であってもよい。

ここで、概して、本開示を参照すると、ネットワークアクセス制御システムが、説明される。図５１−５６の実施形態では、ノードは、証明書を管理する必要なく、通信のためにプロビジョニングされる。図５１を参照すると、セッションをネットワーク１７１０内で確立するプロセス１８００が、示される。プロセス１８００は、２つのノードが、秘密をセキュアに交換すること（ブロック１８０２）を含み、その後、両ノードは、秘密を使用して、ＰＲＮＧにシードする。ＰＲＮＧの出力は、キー配布テーブルを作成するために使用される（１８０４）。ノードのうちの１つが、データテーブルを作成し（ブロック１８０６）、これは、次いで、キー配布テーブルを使用して、他のノードと交換される（ブロック１８０８）。データテーブルは、続いて、ＰＲＮＧおよびデータに基づいて、ノード間に全てのパケット交換において修正される。プロセス１８００は、概して、本開示の上記に説明されるようなセッションを確立するためのプロセスであって、以下の図は、セッションをネットワーク内で確立するであろうノードをプロビジョニングするためのプロセスを説明する。

ここで図５２Ａ−Ｂを参照すると、ネットワーク内のノードのプロビジョニングが、より詳細に示される。より具体的には、図５２Ａは、ノードがネットワークアクセスサーバ１９０４によってネットワーク内で使用されることを可能にするためのネットワーク内のノード１９０８の構成を図示する。ネットワーク内のノードの構成を促進するために、オペレータは、ノード１９０８にアクセスし、構成プログラム１９１２を開始してもよい。構成プログラム１９１２は、概して、ネットワークアクセスサーバパブリックキー１９１４を使用して、ネットワークアクセスサーバ１９０４と認証を行うように構成される。ネットワークアクセスサーバパブリックキー１９１４は、次いで、秘密をネットワークアクセスサーバ１９０４と交換するために使用され、セッション（１９１６）が、ノード１９０８とネットワークアクセスサーバ１９０４との間に確立される。図５２Ａの実施形態は、ネットワークアクセスサーバパブリックキーを示すが、他の実施形態では、他の認証方法（例えば、５０９証明書）が、ネットワークアクセスサーバをノードにおいて認証するために使用されてもよい。さらに他の本発明の実施形態では、セキュアセッションは、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ、またはＥｒｄｅｍ Ａｌｋｉｍによる「Ｐｏｓｔ−ｑｕａｎｔｕｍ ｋｅｙ ｅｘｃｈａｎｇｅ−ａ ｎｅｗ ｈｏｐｅ」ｂｙ（ｈｔｔｐｓ：／／ｅｐｒｉｎｔ．ｉａｃｒ．ｏｒｇ／２０１５／１０９２．ｐｄｆ）に開示されるもの、またはＦｒｏｄｏキー交換等のキー交換アルゴリズムを使用して確立されることができ、サーバは、セキュアセッションが、確立された後、かつユーザパスワードが交換される前に、認証されることができる。

いったんネットワークアクセスサーバ１９０４とのセッションが、確立されると、構成プログラム１９１２は、オペレータ証明書（例えば、ユーザの証明書）をネットワークアクセスサーバ１９０４に送信する。ネットワークアクセスサーバ１９０４は、ユーザをポリシサーバ１９０６と認証させ、ユーザがノード１９０８を構成することが認可されていることを検証してもよい。

構成プログラム１９１２による構成は、ノード１９０８のためのキー配布テーブルを作成し、キー配布テーブルをノードのセキュア記憶装置１９１８内に記憶することを含む。キー配布テーブルは、ネットワークアクセスサーバ１９０４に提供され、これは、キー配布テーブル（および他のノード情報）をサーバセキュアデータベース１９２０内に記憶する。別の実施形態では、キー配布テーブルを保存する代わりに、プライベート／パブリックキーが、ノード１９０８のために作成されてもよく、ノードのプライベートキーは、ノードに記憶される一方、パブリックキーは、記憶のためにネットワークアクセスサーバ１９０４に送信される。

ここで図５２Ｂを参照すると、ノードをプロビジョニングするためのプロセス１９５０が、より詳細に示される。より具体的には、プロセス１９５０は、アクセス要求側からの要求の受信に応じて、ネットワークアクセスサーバからノードをプロビジョニングするプロセスを示す。ネットワークアクセスサーバは、プロセス１９５０において、仮想マシン（ＶＭ）内のノードを開始するように構成される。

プロセス１９５０では、ノードは、図５２Ａに説明されるように、プロビジョニングのためにすでに構成されている。プロセス１９５０は、ノードのイメージを探すこと（ブロック１９５２）を含む。ブロック１９５２は、概して、ネットワークアクセスサーバが、適切な動作ソフトウェアまたは他のソフトウェアを伴うノードのイメージを探すことを含んでもよい。ブロック１９５２はさらに、概して、任意の所望の設定または特性を伴うノードのイメージを検索することを含んでもよい。

プロセス１９５０はさらに、ノードイメージのコピーを作成すること（ブロック１９５４）と、ノードイメージのコピーをマウントすること（ブロック１９５６）とを含む。ネットワークアクセスサーバは、ノードへのセキュアアクセスをすでに有しているため、キー配布テーブルをノードイメージのコピーに書き込む（ブロック１９５８）。ネットワークアクセスサーバは、ＶＭにノードイメージのコピーをロードし（ブロック１９６０）、キー配布テーブルは、ネットワークアクセスサーバの記憶装置内に保存される（ブロック１９６２）。

本開示に説明されるようなプロビジョニングシステムは、任意のタイプの動作環境を通して実装されてもよい。例えば、プロビジョニングは、サービスとしてのインフラストラクチャ（ＩａａＳ）、サービスとしてのプラットフォーム（ＰａａＳ）、またはサービスとしてのソフトウェア（ＳａａＳ）モデルを通して行われてもよい。ＩａａＳモデルでは、プロビジョニングは、仮想プラットフォームを通して遂行され、仮想マシンとノードとの間の接続を確立してもよい。ＰａａＳモデルでは、プロビジョニングは、データベース、ウェブページ等の物理または仮想サービスを通して遂行されてもよい（例えば、データベースとノードとの間の接続を確立する）。ＳａａＳモデルでは、プロビジョニングは、ソフトウェアアプリケーションを通して遂行されてもよい（例えば、ブラウザとノードとの間の接続を確立する）。概して、図５３−５５を参照すると、各タイプの動作環境（ＩａａＳ、ＰａａＳ、ＳａａＳ）内のプロビジョニングが、より詳細に説明される。

図５３は、ＩａａＳセッションをネットワーク内のノード間に確立するプロセスを図示する、ブロック図である。アクセス要求側１９０２は、上記に説明されるように、ノード１９０８の使用を要求するために（ブロック２００２として示される）、セキュアセッションをネットワークアクセスサーバ１９０４と確立してもよい。ポリシサーバ１９０６は、要求を受信し（リンク２００４として示される）、アクセス要求側１９０２を認証し、ノード１９０８を使用するための権限を付与する（ブロック２００６として示される）。ノード１９０８は、実際のまたは仮想マシンであってもよい。

ネットワークアクセスサーバ１９０４は、次いで、アクセス要求側１９０２の端末クライアント２０１４とノード１９０８の端末クライアント２０１６との間の通信のために使用されるためのデータテーブル（ブロック２００８として示される）を作成する。データテーブルは、ノードのキー配布テーブルを用いて、ネットワークアクセスサーバ１９０４によって暗号化される（ブロック２０１０として示される）。データテーブルおよび暗号化されたキーが、アクセス要求側１９０２の端末クライアント２０１４に送信される（リンク２０１２として示される）。端末クライアント２０１４は、ノード１９０８の端末クライアント２０１６との接続を開放し、暗号化されたキーを転送する。本暗号化されたキーは、ノードのキー配布テーブルを使用して、ノードによってデコードされ、アクセス要求側１９０２とノード１９０８との間のセッションを開始するために使用される。

図５４は、ＰａａＳセッションをネットワーク内のノード間に確立するプロセスを図示する、ブロック図である。図５４の実施例は、プラットフォームとしてセキュア接続をデータベース２０２０と確立することを図示する。プラットフォームコンポーネントは、例えば、図５２Ｂのプロセス１９５０を使用して、プラットフォーム内のミドルウェアを通してプロビジョニングされる。図５４の実施例では、ｎｏｄｅＪＳアプリケーションとデータベースとの間の相互作用が、示される。本明細書のシステムおよび方法は、他の用途およびプラットフォームにも適用可能であることを理解されたい。

アプリケーション２０２２が、セキュア接続をデータベース２０２０と確立する必要があるとき、ミドルウェア２０２４は、コールを傍受してもよい（リンク２０２６として示される）。ミドルウェア２０２４は、ネットワークアクセスサーバ１９０４とのセキュア接続を開放し（リンク２０２８として示される）、証明書２０３０（例えば、ユーザ証明書、アプリケーション証明書）をサーバにパスする。ネットワークアクセスサーバ１９０４は、アプリケーションの認証および認可を検証し、アプリケーション（ｎｏｄｅＪＳ２０２２）のための新しいデータテーブルと、データベース２０２０のためにキー配布テーブルを用いて暗号化されたデータテーブルのコピーとを提供する。

ミドルウェア２０２４は、キー（データテーブル）を受信させ続け（リンク２０３２として示される）、暗号化されたキー（暗号化されたデータテーブル）を送信するために、データベース２０２０への接続を開放する（リンク２０３４として示される）。データベース２０２０は、キー配布テーブルを記憶し（ブロック２０３６として示される）、アプリケーション２０２２によって提供されると、それを使用して、データテーブルをデコードする。セキュア接続が、次いで、アプリケーションとデータベースとの間に確立される（ブロック２０３８として示される）。

図５５は、ＳａａＳセッションをネットワーク内のノード間に確立するプロセスを図示する、ブロック図である。図５５の実施形態は、アクセス要求側１９０２によってノードとの接続を確立するために使用されるソフトウェアアプリケーションとしてのブラウザを示す。他の実施形態では、任意のタイプのソフトウェアアプリケーションが、使用されてもよい。アクセス要求側１９０２が、ブラウザ２０４０を通してアプリケーションを使用するとき、アプリケーション２０４２は、ブラウザにダウンロードされる。アプリケーション２０４２は、次いで、ネットワークアクセスサーバ１９０４とのセキュアセッションにおいて起動することができる（リンク２０４４として示される）。セキュアセッションは、ＴＬＳまたは任意の他のプロトコルを介して確立されてもよい。アプリケーション２０４２は、例えば、ＡｕｇｕｌａｒＪＳアプリケーションであってもよい。

アクセス要求側１９０２が、ネットワークアクセスサーバ１９０４（およびポリシサーバ１９０６）によって認証および認可されると、サーバは、新しいデータテーブルと、ソフトウェアコンポーネントキー配布テーブルを用いて暗号化されたデータテーブルとをブラウザ２０４０に提供する（リンク２０４６として示される）。アプリケーション２０４２は、ソフトウェアバックエンド２０４８との接続を開放し、暗号化されたデータテーブルをソフトウェアバックエンドに提供する。ソフトウェアバックエンド２０４８は、ブラウザ２０４０内のアプリケーション２０４２とアプリケーションのサーバコンポーネントとの間の接続を確立するために、その記憶されたキー配布テーブル（ブロック２０５０として示される）を使用して、データテーブルを解読する。

ここで図５６を参照すると、セッションが複数のノード間で配布または移行される方法を図示する、ブロック図が、示される。図５６の実施形態では、アクセス要求側１９０２は、第１のノード２１０２とのセッション下にある（リンク２１１２として示される）。アクセス要求側１９０２が、付加的リソースをネットワークアクセスサーバ１９０４に要求すると（リンク２１１４として示される）、サーバは、セッションが、第２のノード２１０４に移動され、要求に適応すべきであることを判定してもよい。ネットワークアクセスサーバ１９０４は、新しいセッションキーをアクセス要求側１９０２に送信する（リンク２１１６として示される）。新しいセッションキーは、第１のノード２１０２のキー配布テーブルを用いて暗号化されたデータテーブルと、第２のノード２１０４のキー配布テーブルを用いて暗号化されたデータテーブルのコピーとを含む。

アクセス要求側１９０２は、データテーブルを第１のノード２１０２に転送する（リンク２１１８として示される）。第１のノード２１０２は、そのキー配布テーブルを使用して、データテーブルをデコードし、要求を認識し、第２のノード２１０４とのセッションを開放する。第１のノード２１０２は、第２のノード２１０４との接続を開放し、第２のノードのキー配布テーブルを用いて暗号化されたデータテーブルをノードにパスする（リンク２１２０として示される）。

リンク２１２０を介して受信された暗号化されたデータテーブルは、第２のノード２１０４においてデコードされ、セキュア接続を第１のノード２１０２と確立するために使用される（リンク２１２２として示される）。全てのデータが、２つのノード間で移動されると、ネットワークアクセスサーバ１９０４は、データテーブルを作成し、データテーブルに加えて、第２のノード２１０４のキー配布テーブルを用いて暗号化されたコピーをアクセス要求側１９０２に送信する（リンク２１２４として示される）。

アクセス要求側１９０２は、次いで、第２のノード２１０４との接続を開放し（リンク２１２６として示される）、暗号化されたデータテーブルをパスする。第２のノード２１０４は、データテーブルを解読し、それを使用して、ノードとアクセス要求側１９０２との間のセッションを確立する（リンク２１２８として示される）。プロセスが、移行プロセスである場合、第１のノード２１０２は、次いで、第２のノード２１０４への移行が完了するにつれて、アクセス要求側１９０２から解放されてもよい。

ここで図５７を参照すると、ネットワークアクセス制御システム２１５０の大まかなブロック図が、示される。ネットワークアクセス制御システム１７０４、ポリシサーバ１７０６、およびクライアント（ノード）１７０８に加え、複数のバンプインザワイヤ（ＢＩＴＷ）ノード２１５２が、システム内に示される。ＢＩＴＷノードは、既存のシステムの中に挿入され、各通信のエンドポイントにおけるノードを変更せずに、システム内の通信を改良し得る（すなわち、より高い信頼性およびセキュリティの通信）、ノードである。言い換えると、ＢＩＴＷノードは、メッセージを受信することになるノードとシステム２１５０の種々の他のコンポーネントとの間でメッセージを中継する。ＢＩＴＷノードは、本開示に説明されるような他のノードと同様に、以下に説明されるように、システム２１５０内の通信のためにプロビジョニングおよび設定されてもよい。

ネットワークアクセスサーバ１７０４は、認可のためにポリシサーバ１７０６から認可を受信後、キーを用いてＢＩＴＷノード２１５２をプロビジョニングしてもよく、これは、通常のノードをプロビジョニングするプロセスに類似する。ＢＩＴＷノード２１５２は、以下に説明されるように、２つのインターフェース、すなわち、他のネットワーク内のノードとの通信を促進するためのネットワークバウンドインターフェースと、識別された特定のノードのためのクライアントバウンドインターフェースとを含んでもよい。各ＢＩＴＷノード２１５２は、図５７では、クライアント１７０８と関連付けられて示される。各ＢＩＴＷノード２１５２と関連付けられた複数のノード１７０８を含む、ＢＩＴＷノード２１５２およびノード１７０８の任意の構成が、可能性として考えられ得ることを理解されたい。

ＢＩＴＷノード２１５２は、パッケージをリッスンし、パッケージが受信されると、クライアント宛先ＩＰをパッケージから判定してもよい。ＢＩＴＷノード２１５２は、次いで、クライアント宛先ＩＰを使用して、パッケージの意図される受信者を判定してもよい。ＢＩＴＷノード２１５２が、意図される受信者を把握しない場合、アクセス要求プロトコル（ＡＲＰ）パケットは、近傍クライアント（ノード）に伝送されてもよく、ＢＩＴＷノード２１５２は、次いで、クライアントから、クライアントのＩＰアドレスを示す応答を受信してもよい。ＢＩＴＷノード２１５２が、クライアント宛先ＩＰアドレスに合致するＩＰアドレスをパッケージから受信しない場合、ＢＩＴＷノード２１５２は、クライアント宛先ＩＰがネットワーク内に存在しないことを把握する。ＩＰアドレスが、ＡＲＰに応答して受信される場合、ＢＩＴＷノード２１５２は、将来的通信のために、関連付けられたＭＡＣアドレスを保存してもよい。

ＢＩＴＷノード２１５２が、新しいＩＰアドレスをネットワーク内で発見するにつれて、構成サーバ２１５４に知らせてもよい。構成サーバ２１５４は、次いで、ネットワーク内の全てのＢＩＴＷノード２１５２に知らせ、全てのそのようなノードがネットワーク内の種々のクライアントのＩＰアドレスを把握することを可能にしてもよい。

ＢＩＴＷノード２１５２は、別のＢＩＴＷノードがネットワークの中に挿入されると、宛先ＩＰまたはクライアント１７０８へのパスの中に挿入されたＢＩＴＷノードを検出するように構成されてもよい。新しいＢＩＴＷネットワーク内のノードの追加を検出する、ＢＩＴＷノード２１５２は、新しいＢＩＴＷノードとセッションを開始してもよい。オリジナルＢＩＴＷノードは、セッションを認可するためのトークンを有してもよい、またはトークンをネットワークアクセスサーバ１７０４から要求および受信してもよい。

クライアント１７０８へおよびそこから送信されるメッセージの難読化および難読化解除は、パッケージの通信パス内のＢＩＴＷノードにおいて生じてもよい。例えば、エンドクライアント１７０８に送信されるパッケージは、メッセージをクライアントに送信する対応するＢＩＴＷノード２１５２によって難読化されてもよく、パッケージは、宛先ＢＩＴＷノードにおいて難読化解除されてもよい。

本明細書に説明されるプロビジョニングシステムおよび方法は、単一ポリシサーバが、ネットワーク内の全てのサーバを横断して全ての認証およびアクセスを制御することを可能にする。ポリシサーバは、ポリシサーバが問題を有する場合、システム全体の障害を防止するために、複製されてもよい。セッションを確立するプロセスは、プロセスと関連付けられたテーブルおよびプロセッサと関連付けられたテーブルを通して、ノードにおいてプロセッサに結び付けられる。セッションが、より多くのプロセッサに拡張される必要がある場合、テーブルは、拡張のために使用される。ノード間の同期が、喪失される場合、リアルタイムで、オリジナル設定と同一様式で再開されることができる。

概して、本開示を参照すると、ノード間の通信のための難読化技法を提供するための種々のシステムおよび方法が、説明される。本明細書に説明されるシステムおよび方法の一例示的環境は、車両であり得る。現代の車両は、多くの（例えば、７０またはそれを上回る）電子制御ユニット（ＥＣＵ）を含み得る。そのようなＥＣＵの実施例は、エンジン制御ユニット、トランスミッションシステム、エアバッグシステム、アンチロックブレーキシステム、クルーズコントロールシステム、電動パワーステアリング、オーディオシステム、パワーウィンドウ、ドア、ミラー調節システム、ハイブリッドまたは電気車両のためのバッテリもしくは再充電システム等を含んでもよい。概して、本開示を参照すると、本明細書におけるシステムおよび方法は、セキュア化された無線通信をサブシステム内のＥＣＵとまたはその間に確立するために使用されてもよい。より具体的には、以下の図５８−６２を参照すると、本開示のシステムおよび方法は、車両内の実装に関して説明される。

本明細書のシステムおよび方法はまた、複数のＥＣＵおよびノードを含む、任意の環境のために適用されてもよいことを理解されたい。図５８−６２に説明される実施形態は、車両内のシステムおよび方法の例示的実装として提供されるが、任意の他のタイプのネットワーク化環境内において適用されるように適合可能である。そのような例示的ネットワークは、建物エリア内の接続されたプリンタおよび他のコンピュータのネットワーク、監視またはアラームシステムのための複数のセンサ、エリア内の複数のモバイルまたは定常デバイス、および同等物を含んでもよい。

現代の車は、概して、限定された能力を伴う数百個のセンサを有し得、各センサは、ＥＣＵに接続され、エンジンコントローラ（例えば、車両の主要なコントローラ、また、以下では、単に、コントローラと称される）と通信可能である。いくつかのＥＣＵは、１つのセンサのみに接続されてもよく、いくつかの実施形態では、ＥＣＵおよびセンサは、同一デバイス上にある。他の実施形態では、ＥＣＵおよびセンサは、異なるデバイス上にあってもよい、または複数のセンサは、単一ＥＣＵに接続してもよい。ＥＣＵとエンジンコントローラとの間で伝送されるための情報は、認証および暗号化されるべきである。概して、本開示に説明されるように、ＥＣＵとエンジンコントローラとの間のセッションは、最初に、「キー」をその２つの間で共有することによって確立されてもよい。所与のＥＣＵのためのキーは、概して、一意の初期データテーブル（そのサイズは、各ＥＣＵのデータフィールドに調整される）とＰＲＮＧのための一意の多項式インデックスの組み合わせであってもよい。各ＥＣＵへのキーのプロビジョニングは、工場設定（または車両またはセンサが製造されている他の設定）等のセキュア環境内でのみ生じるべきである。

車両の電源投入に応じて、エンジンコントローラおよびＥＣＵは、データテーブルが、ＥＣＵ毎にすでに事前にプロビジョニングされており、ＥＣＵ毎の各データテーブルのコピーが、エンジンコントローラに保たれているため、「秘密」から開始し、キー配布テーブルを作成し、データテーブルを作成する必要はない（図３９のプロセス１１００に関して説明されるように）。代わりに、エンジンコントローラは、同一ランダム３２ビットワードシードを各ＥＣＵに送信する（各エンジンコントローラは、ランダム３２ビットワードで事前にプロビジョニングされる）。ＥＣＵは、ＥＣＵの一意のデータテーブルを使用して、本シードをスクランブルし、結果をベクトルとしてＰＲＮＧ多項式と併用し、ＰＲＮＧにシードする。このように、エンジンコントローラとの各ＥＣＵのセッションは、一意のデータテーブルおよび一意のＰＲＮＧシーケンスから開始する。各ＥＣＵは、データテーブルを恒久的メモリ内に、かつ事前にプロビジョニングされた多項式インデックスを揮発性メモリ内に保つ。本時点から、ＥＣＵとエンジンコントローラとの間のペイロードのセキュア通信が、概して、図４１のプロセス１２００に説明されるように進められることができる。

代替実施形態では、各ＥＣＵは、その独自のデータテーブルおよび秘密で事前にプロビジョニングされることができる（２８バイトは、プロセス１１００に説明されるように、ＰＲＮＧ多項式指数およびＰＲＮＧベクトルを構成する）。エンジンコントローラは、ＥＣＵ毎のデータテーブルおよび秘密のコピーを恒久的メモリ内に保つ。本実施形態は、ＰＲＮＧの計算が、ＥＣＵよりはるかに強力なプロセッサである、エンジンコントローラにおいて生じることを可能にするであろう。

概して、図５８−６２を参照すると、車両内の各ＥＣＵをキーでプロビジョニングする方法が、説明される。ＥＣＵは、車両内で経時的に交換され得る。例えば、タイヤと関連付けられたＥＣＵは、車両のタイヤが変更されると、変更され得る。ＥＣＵが、車両内で交換されると、新しいＥＣＵは、交換されているＥＣＵ内のキーと異なるキーでプロビジョニングされてもよく、セッションは、新しいＥＣＵとエンジンコントローラとの間に確立されてもよい。しかしながら、新しいＥＣＵは、オペレータ（車所有者、ディーラー等）が、そのインストールの際に新しいＥＣＵに権限を付与するまで、エンジンコントローラによって信頼され得ない。

ここで図５８を参照すると、エンジンコントローラと車両サブシステムのＥＣＵとの間の通信のプロセスを図示する、ブロック図が、示される。エンジンコントローラ２２０２は、コントローラエリアネットワーク（ＣＡＮ）キュー２２０４を含み、そこからメッセージが、ＥＣＵ２２０６へおよびそこから伝送される。したがって、コントローラ２２０２から伝送されるための全てのメッセージは、ＣＡＮキュー２２０４に入れられ、ＣＡＮバス２２０８に導入される。

図５８のシステムは、シミュレーションモードおよびエミュレーションモードの両方をサポートしてもよい。エミュレーションモードでは、コントローラからのメッセージは、ＣＡＮキュー２２０４を介して、ＣＡＮバス２２０８に提供され、次いで、ＣＡＮバス２２０８からＥＣＵ２２０６に提供される。エミュレーションモードをサポートするために、キュー２２０４およびＣＡＮバス２２０８は、メッセージをエミュレートされている種々のＥＣＵに送信し、そこから受信するために使用される。メッセージは、キューに入れられ、順次、伝送のためにＣＡＮバス２２０８に導入される。ＣＡＮキュー２２０４は、そのエンキューおよびデキュー方法において同期される。シミュレーションモードでは、コントローラ（ＣＡＮキュー２２０４）からのメッセージは、直接、ＥＣＵ２２０６に提供され、メッセージへのＥＣＵ回答は、直接、ＣＡＮキュー２２０４に提供される。

エンジンコントローラ２２０２は、車両内のＥＣＵをプロビジョニングするように構成される。プロビジョニングを開始するために、ユーザデバイス２２１０は、コントローラ２２０２と接続し、ペアリングを可能にしてもよい。ユーザデバイス２２１０は、車両サブシステムのための更新を提供することができる、携帯電話、ディーラーの店舗内の機器、または認可されたユーザ（例えば、ディーラー）に属する任意の他のタイプのデバイスであってもよい。ユーザデバイス２２１０およびコントローラ２２０２は、ＯＢＤ−ＩＩポートを介して、または任意の他の利用可能な方法によって、接続してもよい。ユーザデバイス２２１０およびコントローラ２２０２は、プロビジョニング方法に先立って、ペアリングされてもよい。ユーザデバイス２２１０は、概して、車両の１つまたはそれを上回るＥＣＵのために意図されるソフトウェア更新（または他の情報）を含む、１つまたはそれを上回るメッセージを提供する。ユーザデバイス２２１０とコントローラ２２０２との間の通信プロセスは、図６３−６５により詳細に説明される。

車両の種々のＥＣＵが、電源投入されると、各個々のＥＣＵ２２０６は、プロビジョニング要求をコントローラ２２０２に送信してもよい（ＣＡＮバス２２０８を介して）。そのような状況は、ＥＣＵがプロビジョニング要求を同時にサブミットし得るため、ＣＡＮバス２２０８に多数の衝突を生じさせ得る。これは、エラーメッセージを頻繁に送信させる、または最終的に、ＣＡＮバス２２０８もしくはコントローラ２２０２の「バスオフ」状態もしくは他のエラー状態を生じさせ得る。車両設定では、そのようなエラーメッセージの生成は、典型的には、車両に関する深刻な問題を示し得る。したがって、より深刻なエラーメッセージが、代わりに、認識され得るように、衝突を回避することが望ましい。本明細書に説明されるプロビジョニング方法は、ＥＣＵによって生成された種々の要求間の衝突を回避することに役立つ。

図５８−６２に説明される暗号化プロセスは、ＣＡＮバス以外の任意のタイプのＩｏＴ用途のためにも実装可能であり得ることを理解されたい。ＣＡＮバスは、複数のデバイスが相互に通信することを可能にするための例示的規格として提供されるが、デバイスは、任意の他のタイプの方法またはプロトコルを介して相互接続されてもよい。

また、図５９Ａ−Ｄを参照すると、プロビジョニングプロセスが、より詳細に示される。各個々のＥＣＵ２２０６は、プロビジョニングされていない場合、通常通り伝送することによって開始する。その通常伝送の一部として、ＥＣＵ２２０６は、そのＩＤを含んでもよい。コントローラ２２０２が、伝送を各ＥＣＵ２２０６から受信すると、各ＥＣＵ２２０６がプロビジョニングされ得るかどうかをチェックすることができる。そのために、コントローラ２２０２は、図５９Ａに示されるように、ＣＡＮプロビジョニングメッセージ２３０２を伝送する。メッセージ２３０２は、ＣＡＮプロビジョニングＩＤ２３０４を含み、これは、ＥＣＵ２２０６によってプロビジョニングチェックとして認識可能な所定のメッセージＩＤである。メッセージ２３０２のペイロードは、ＥＣＵ２２０６のＩＤと、拡張子ビットとを含み、随意に、１８ビットの拡張子アドレスの後に、４ビットＥＣＵペイロードが続くように示される。

ＥＣＵ２２０６が、メッセージ２３０２を受信すると、ＥＣＵ２２０６が、プロビジョニングされることができ、メッセージ２３０２内のＥＣＵ ＩＤが、その独自のＩＤに合致する場合、ＥＣＵ２２０６は、次いで、プロビジョニングを要求することができる。図５９Ｂを参照すると、ＥＣＵプロビジョニングメッセージ２３１２が、示される。メッセージ２３１２は、プロビジョニングＩＤ２３１４を要求することを含み、これは、コントローラ２２０２によってプロビジョニング要求として認識可能な所定のメッセージＩＤである。メッセージ２３１２はさらに、概して、メッセージ２３０２に関して説明されるペイロードに類似するペイロードを含んでもよい。

コントローラ２２０２が、メッセージ２３１２をＥＣＵ２２０６から受信すると、コントローラおよびＥＣＵがセキュア環境内にあることを検証すべきである。コントローラ２２０２が、セキュア環境を検証することができない場合、コントローラ２２０２は、ユーザ（ユーザデバイス２２１０を介して）がＥＣＵ２２０６をプロビジョニングすることが容認可能であることを確認することを要求してもよく、確認の受信に応じて、プロビジョニングプロセスを継続してもよい。一実施形態では、コントローラ２２０２は、環境がセキュアであることを示す、ユーザ入力を待機してもよく、いったんコントローラ２２０２が環境がセキュアであることを確認可能になると処理され得るように、要求を保存してもよい。

いったん環境がセキュアになると、コントローラ２２０２は、図５９Ｃに示されるように、メッセージ２３２２で応答してもよい。メッセージ２３２２は、プロビジョニングＩＤ２３２４を含み、これは、所定のメッセージＩＤである。メッセージ２３２２はさらに、概して、メッセージ２３０２、２３１２に関して説明されるものに類似する、ペイロードを含んでもよい。メッセージ２３２２が、送信された後、図５９Ｄに示されるように、メッセージ２３３２等のさらなるメッセージが、コントローラ２２０２によって伝送されてもよい。メッセージ２３３２は、ＥＣＵ２２０６に送信されるためのキーの一部を含む（「プロビジョニングＩＤ＋Ｎ」として図５９Ｄに示され、キーのＮ番目のブロックがメッセージ内で送信されていることを示す）。コントローラ２２０２によって複数のメッセージ２３３２を経由して送信されるキーは、概して、本開示に説明されるように、難読化プロセスにおいて使用されるためのテーブルおよびＰＲＮＧベクトルを含む。

一実施形態では、コントローラ２２０２は、種々のＥＣＵから受信されたメッセージのサイズに基づいて、キーをグループ化してもよい。例えば、同一サイズを伴うフレームをブロードキャストする、全てのＥＣＵは、メッセージをエンコードするために、コントローラ２２０２によって、同一キーを提供されてもよい。

ＥＣＵ２２０６が、プロビジョニングされ、コントローラ２２０２との伝送のための準備ができた後、ＥＣＵ２２０６が初期化されると（例えば、車両が始動すると）、コントローラ２２０２は、ランダム３２ビットメッセージを車両内の全てのＥＣＵにブロードキャストする。各ＥＣＵ２２０６は、次いで、ＥＣＵ内の秘密のデータテーブル部分を使用して、３２ビットメッセージをスクランブルし、結果として生じる値は、上記に説明されるように、ＰＲＮＧのための初期ベクトルとして使用される。

ここで図６０を参照すると、ＥＣＵおよびコントローラの難読化アクティビティ（エンコーディングおよびデコーティング）が、より詳細に説明される。一般に、環境内で要求されるセキュリティのレベルに応じて、暗号化および解読のために使用されるアルゴリズムは、以下に説明されるように、低レベルまたは高レベル暗号化／解読アルゴリズムであってもよい。

低レベル暗号化方法では、ＥＣＵ２２０６からコントローラ２２０２に伝送されるためのデータは、概して、本開示に説明されるように、ＰＲＮＧとＸＯＲされ、次いで、スクランブルされる。テーブルは、次いで、データをＸＯＲするために使用されるＰＲＮＧの値に基づいて、チェーニングされる。テーブルチェーニングは、図６１により詳細に説明される。エンジンコントローラにおけるデコーティングのために、暗号化されたメッセージは、スクランブル解除され、データは、ＰＲＮＧとＸＯＲされる。テーブルは、次いで、データをＸＯＲするために使用されるＰＲＮＧの値とチェーニングされる。チェーニングが失敗する場合、次のＰＲＮＧ値が、次いで、使用されることができる。次のＰＲＮＧ値は、データとＸＯＲされ、テーブルチェーニング内で使用される。本プロセスは、ＰＲＮＧがテーブルのチェーニングの成功を生じさせたことが見出されるまで継続してもよい。

全体的プロセスが失敗する（すなわち、いずれのＰＲＮＧ値もテーブルのチェーニングの成功を生じさせない）場合、再同期メッセージが、コントローラ２２０２によってＥＣＵ２２０６に送信されてもよい。再同期メッセージは、図６０に示されるようなフォーマットを有してもよい。再同期メッセージ２４００は、再同期ＩＤ２４０２を含み、これは、所定のメッセージＩＤである。再同期メッセージ２４００はさらに、シード２４０４を含み、これは、テーブルをスクランブルするために使用され、後続暗号化／解読プロセスにおいてＰＲＮＧにシードするために使用される、乱数である。シードは、任意のサイズ（例えば、３２〜６４ビット）であってもよい。再同期メッセージ２４００はさらに、概して、伝送のために要求されるように、ＥＣＵ ＩＤおよび他のフィールドを含んでもよい。

高レベル暗号化方法では、ＥＣＵ２２０６がデータをコントローラ２２０２に伝送するであろう初めてのとき、ＥＣＵ２２０６は、上記に説明されるように、データをＰＲＮＧとＸＯＲし、データをスクランブルし、データをチェーニングしてもよい。しかしながら、後続反復（すなわち、さらなる伝送）のために、伝送されるためのデータは、ＰＲＮＧからの値の代わりに、前のＸＯＲされたデータ（事前にスクランブルされ、ＸＯＲされたデータ）とＸＯＲされる。データを前のＸＯＲされたデータとＸＯＲすることは、データの難読化レベルを増加させる。コントローラ２２０２は、次いで、上記に説明されるように、メッセージのデコーティングに進んでもよい。

図６０において上記に説明されるように、ＥＣＵ２２０６は、コントローラ２２０２に送信されるためのデータを難読化する。ＥＣＵ２２０６は、典型的には、車両内の単一センサからのデータを伝送しているため、ＥＣＵ２２０６は、概して、非常に少量のデータを伝送するように構成されてもよい。いくつかの実施形態では、ＥＣＵ２２０６は、パケット全体をデータで充填し、次いで、パケットを伝送することを待機する代わりに、データがセンサから受信されるにつれて、順次、データを暗号化および伝送することが可能であってもよい。言い換えると、ＥＣＵ２２０６は、一度に全ての代わりに、一度に１ビットまたは一度に１セグメント、伝送されるためのデータをエンコードする。概して、図６１を参照すると、一度に１バイト（または１セグメント）、データをエンコードする、ＥＣＵ２２０６のテーブルベースのシリアル暗号化プロセスが、より詳細に説明される。

シリアル暗号化プロセスに関して、ワンタイムパッドバッファが、ＥＣＵ２２０６によって準備される。バッファは、任意のサイズであってもよい。いくつかの実施形態では、バッファは、１６０〜２５６バイトであってもよい。ＥＣＵ２２０６が、最初の着信バイトをセンサから受信すると、バイトは、バッファの最初のバイトとＸＯＲされる。受信された次のバイトは、バッファの第２のバイトとＸＯＲされる等となる。ワンタイムパッドバッファの最後のバイトが、使用されるとき、ＥＣＵ２２０６によって記憶されたテーブルは、修正され、新しいワンタイムパッドバッファが、さらなるデータのために準備される。種々の実施形態では、図６１のシリアルプロセスは、１ビットから任意の数のバイトの任意のサイズパケットを一度にＸＯＲすることを可能にするように適合されてもよく、選定は、リソース制約および効率考慮点に基づいて行われてもよい。

バッファの最後のバイトが使用された後にテーブルを修正する一実施例が、ここで説明される。テーブル内の第１の１７バイトのデコードされたデータが、ＥＣＵ２２０６によって生成されたＰＲＮＧシーケンスの最初の１７バイトとＸＯＲされる。テーブルチェーンポインタによってポイントされた次の１７エントリは、次いで、ＸＯＲされたデータ内の値と交換される。言い換えると、テーブルの最初の１７バイト内のＸＯＲされたデータは、テーブル内のデータと交換され、その場所は、テーブルの次の１７バイトによって識別される。種々の実施形態では、テーブルの修正は、テーブルの任意の数のバイトをＸＯＲし、テーブル内の任意の数のバイトを交換することを含んでもよい。

図６１を参照すると、図６０のワンタイムパッドバッファを準備するためのプロセス２５００のフローチャートが、示される。プロセス２５００は、バッファをＰＲＮＧ２５０２によって生成されたＰＲＮＧシーケンス２５０４で充填することを含む。ＰＲＮＧシーケンス２５０４は、テーブル２５０６内のデータとＸＯＲされる（ブロック２５０８）。結果として生じるＸＯＲされたデータは、テーブル値とシャッフルされ（ブロック２５１０）、結果として生じる値は、ワンタイムパッドバッファ２５１２内で使用される。種々の実施形態では、ＰＲＮＧシーケンスは、任意のタイプの暗号またはアルゴリズム（例えば、ＡＥＳ２５６、ＡＥＳ１２８等）でエンコードされてもよい。

解読に関して、ワンタイムバッファが、同一テーブル、同一ＰＲＮＧ値（例えば、同一ＰＲＮＧ多項式）、およびＰＲＮＧ内の同一場所を使用して準備され、同一値を暗号化において使用されたワンタイムバッファ内にもたらすことができる。着信バイトは、バッファの次の未使用バイトとＸＯＲされ、バッファの最後のバイトが使用されるとき、テーブルは、上記に説明されるように、修正され、新しいバッファを作成するために使用される。

概して、図６２Ａ−Ｂを参照すると、ＥＣＵによってコントローラに送信されるメッセージの認証が、より詳細に説明される。一実施形態では、コントローラ２２０２によるメッセージの認証は、メッセージのＣＲＣコードを使用したインライン認証を使用して遂行されてもよい。本コードは、典型的には、その独自のフィールドをメッセージのペイロードの中に挿入させることができる。しかしながら、メッセージのペイロードが、ＣＲＣを含まない場合、またはペイロードが、十分なエントロピを提供するためには小さすぎる（すなわち、すなわち、メッセージが、ＣＲＣがペイロードに確実に追加されることができないほど、そのサイズのため、低エントロピを有する）とき、メッセージ認証は、以下に説明されるように、コントローラによってＥＣＵから受信された前のメッセージからのペイロードをエンコードすることによって遂行されてもよい。

メッセージは、前のいくつかのメッセージからのペイロードをエンコードすることによって認証されることができる。例えば、ＥＣＵ２２０６からの前のいくつかのメッセージＮに関して、ペイロードサイズＮの循環バッファが、コントローラ２２０２によって、最後のＮ個のペイロードがＥＣＵ２２０６によって送信され、確認応答され続けるために使用されてもよい。新しいメッセージを認証するために、６４ビットハッシュが、循環キューから算出され、ハッシュは、図６２Ａに示されるように、暗号化され、メッセージ２６００内で送信される。メッセージ２６００は、ＥＣＵ２２０６を認証するために使用される所定のＩＤである、ＩＤ２６０２と、暗号化されたハッシュ２６０４とを含む。コントローラ２２０２は、ハッシュ番号を検証し、認証を検証する。

コントローラ２２０２は、ＥＣＵ２２０６からのメッセージの認証が要求される頻度を駆動させることができる。例えば、コントローラ２２０２は、図６２Ｂに示されるように、メッセージ２６１０を送信することができる。メッセージ２６１０は、再認証ＩＤ２６１２を含み、これは、認証のためにＥＣＵ２２０６に求めるために使用される所定のメッセージＩＤである。メッセージ２６１０はさらに、インターバルフィールド２６１４を含み、これは、ＥＣＵ２２０６がそれ自体を認証すべきレートを規定する。例えば、インターバルが、１００である場合、ＥＣＵ２２０６は、１００メッセージ毎に認証すべきである。インターバルが、ゼロである場合、ＥＣＵ２２０６は、直ちに認証すべきである。メッセージ２６１０はさらに、認証のために使用される循環キューのサイズを判定する、フィールド２６１６を含む（例えば、認証プロセスにおいて使用するための前のメッセージの数を判定するため）。

図５８−６２のシステムおよび方法は、例えば、ソフトウェア更新を車両の種々のＥＣＵ２２０６ならびにエンジンコントローラ２２０２自体に提供するために使用されてもよい。また、図６３−６５を参照すると、情報（ソフトウェア更新等）をシステムサーバからエンジンコントローラ２２０２に提供するためのシステムおよび方法が、より詳細に示される。図６３−６５のシステムおよび方法は、サーバからコントローラ２２０２に伝送されるファイルの完全性および機密性をセキュア化することを可能にする。ファイルは、任意のタイプのコネクティビティ方法（例えば、ＷｉＦｉ、セルラー、ＦＭ帯域等）を介して伝送されてもよく、異なるコネクティビティ条件のために、部分的および断片化された更新のために、ならびにファイル内の一部または全部のブロックの再伝送のために適合可能であってもよい。種々の実施形態では、エンジンコントローラ２２０２は、ファイルを直接システムサーバから受信してもよい、またはファイルをエンジンコントローラに中継するように構成される中間ユーザデバイスからファイルを受信してもよい。

図６３Ａを参照すると、ファイルをコンパイルし、ファイルをサーバからエンジンコントローラ２２０２に配布するためのプロセス２７００が、示される。ファイル２７０２は、コンパイルブロック２７０４において、複数のブロックに分割される。各ブロックは、次いで、独立して暗号化され（ブロック２７０６）、次いで、エンジンコントローラ２２０２に伝送される（ブロック２７０８）。各ブロックを独立して伝送することによって、伝送失敗または割込の結果の任意の逸失ブロックが、再伝送されることができる。エンジンコントローラ２２０２は、各ブロックをデコードし（ブロック２７１０）、ファイル２７０２を再アセンブルする（ブロック２７１２）。

コンパイルプロセス（ブロック２７０４）は、図６３Ｂにより詳細に示される。ファイル２７０２は、複数のブロック２７２０に分割されるように示される。各ブロック２７２０は、ヘッダ２７２２と、ペイロード２７２４とを含む。各ヘッダ２７２２は、多項式パラメータ２７２６と、擬似ランダムシーケンス内のその位置を表すベクトル２７２８と、そのブロック番号２７３０とを含んでもよい。多項式パラメータ２７２６は、概して、本開示に説明されるように、コントローラによって、ＰＲＮＧを生成するために使用される。ブロック番号２７３０は、ファイル２７０２内の他のブロックに対するブロック２７２０の位置を識別する。ペイロード２７２４は、概して、ファイル内のブロックの数およびブロック毎のブロックサイズ等、更新ファイルのためのメタデータを含有する代わりに、最初のブロックのペイロードとともに、ファイルデータを含んでもよい。

暗号化プロセス（ブロック２７０６）が、図６３Ｃにより詳細に示される。最初に、ヘッダテーブルおよびペイロードテーブルが、生成される（ブロック２７４０）。ブロック（ブロック２７４２）毎に、ヘッダは、暗号化され（ブロック２７４４）、ヘッダおよびペイロードは、ブロックテーブルを使用して、スクランブルされる（ブロック２７４６）。また、図６３Ｄを参照すると、ヘッダ暗号化のためのブロック２７４４が、より詳細に示される。

ヘッダ暗号化２７４４は、乱数を生成すること（ブロック２７５０）を含む。一実施形態では、数字は、０〜２^３２であってもよい（３２ビット乱数に適応する）。乱数は、次いで、多項式パラメータを生成するためのパラメータとして使用される（ブロック２７５２）。第２の乱数が、上記のプロセス１１００に説明されるように、生成され（ブロック２７５４）、ＰＲＮＧのためのジャンプベクトルとして使用される（ブロック２７５６）。数字は、例えば、０〜２^１２７−１であってもよい（ペイロードのサイズに適応する）。ＰＲＮＧの状態およびブロック番号は、コピーされ（ブロック２７５８）、ヘッダは、ヘッダテーブルを用いて暗号化され（ビットスクランブルされ）（ブロック２７６０）、伝送のための暗号化されるヘッダを作成する。

図６３Ｅを参照すると、ブロックのヘッダおよびペイロードをスクランブルするステップが、示される。スクランブリングステップは、上記の図６３Ａのブロック２７０６と相関してもよい。ＰＲＮＧは、概して、本開示に説明されるように、擬似乱数のシーケンス２７７０を生成する。シーケンス２７７０は、ペイロード２７２４とＸＯＲされ、ＸＯＲされたペイロード２７７２を作成する。ＸＯＲされたペイロード２７７２は、次いで、ブロックテーブルを用いてバイトスクランブルされ、エンジンコントローラに伝送されるためのエンコードされたブロック２７７４を作成する。

ここで図６４を参照すると、サーバ（またはユーザデバイス２２１０）とエンジンコントローラ２２０２との間の伝送プロセス２８００が、より詳細に示される。より具体的には、図６４のプロセス２８００は、概して、本開示に説明される、パブリックおよびプライベートキー暗号化技法を使用して、車をプロビジョニングする（すなわち、ファイル更新を提供する）方法を説明する。サーバまたはユーザデバイス２２１０とエンジンコントローラ２２０２との間の通信は、典型的には、通信のための安全環境ではない、指定されたエリア内で生じ得る（すなわち、サーバまたはユーザデバイス２２１０およびエンジンコントローラ２２０２は、ディーラーまたは製造業者等のエリア、または指定されたガレージエリア、または同等物においてのみ、接続を確立してもよい）。エンジンコントローラ２２０２は、以下に説明されるように、通信リンクをセキュア化することによって、個々のセンサまたはＥＣＵ情報がエリア内の任意のデバイスによって読み取られることができない、安全環境モードを有効にしてもよい。プロセス２８００は、サーバまたはユーザデバイス２２１０とエンジンコントローラ２２０２との間のセキュア接続を確立するように具体的に構成される、ディーラー、製造業者、またはガレージにおける特殊機器を使用することを含んでもよい。

プロセス２８００は、車両が、接続をサーバ（またはユーザデバイス２２１０）と確立し、５０９．ｘ証明書を受信すること（ブロック２８０２）を含む。いくつかの実施形態では、サーバは、エンジンコントローラにアップロードされるための更新ファイル（または他のファイル）を生成または受信してもよい。他の実施形態では、エンジンコントローラは、直接、ユーザデバイスに接続し、更新ファイルをユーザデバイスから受信してもよい。プロセス２８００はさらに、５０９．ｘ証明書を検証することを含む（ブロック２８０４）。５０９．ｘ証明書は、サーバとのセキュア通信を検証する目的のために、エンジンコントローラによって受信され得る、例示的証明書である。

プロセス２８００はさらに、５０９．ｘ証明書内のパブリックキーを使用して、秘密を生成し、秘密をサーバに送信する（ブロック２８０６）ことを含む。秘密はまた、エンジンコントローラのＰＲＮＧにシードするために使用される（ブロック２８０８）。結果として生じるＰＲＮＧシーケンスは、ＫＤＴを作成するために使用され（ブロック２８１０）、ＫＤＴは、更新キーをエンコードするために使用され（ブロック２８１２）、キーは、ヘッダテーブルと、ペイロードテーブルとを含む。

代替実施形態では、他の方法が、通信をサーバと確立し、更新キーを送信するために使用されてもよい。例えば、サーバとのセッションが、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ、Ｎｅｗ−Ｈｏｐｅ、またはＦｒｏｄｏ秘密交換プロトコルを使用して確立されることができ、次いで、他のプロトコルが、エンジンコントローラによって、パスワード、パブリック−プライベートキーを介して、またはシグネチャを作成するために使用される任意の他のプロトコルによって等、サーバを識別するために使用されることができる。

ここで図６５を参照すると、エンジンコントローラにおいて更新ファイルをデコードおよびアセンブルするプロセス２９００が、示される。プロセス２９００は、サーバまたはユーザデバイスからの更新ファイル（または他のファイル）の各ブロックの受信を完了後、エンジンコントローラ２２０２によって実行されてもよい。プロセス２９００は、エンジンコントローラによって受信された単一ブロックのデコーティングと、単一ブロックからのペイロードの更新ファイルの中への挿入とを説明する。更新ファイルは、複数のブロックから成ってもよい。

プロセス２９００は、エンコードされたブロックを受信すること（ブロック２９０２）と、ブロックをバイトスクランブルすること（ブロック２９０４）とを含む。ブロックのヘッダは、エンジンコントローラによって記憶されたヘッダテーブルを用いてビットスクランブルされる（ブロック２９０６）。ＰＲＮＧのステータスは、ヘッダからコピーされ（ブロック２９０８）、ＰＲＮＧは、擬似ランダムシーケンスを生成するために使用される（ブロック２９１０）。シーケンスは、次いで、ペイロードとＸＯＲされる（ブロック２９１２）。ヘッダからのブロック番号は、ブロック内のペイロードのためのオフセットを計算し（すなわち、他のペイロードに対する各ブロックからのペイロード毎の正しい位置を判定するため）、ペイロードを最終のアセンブルされたファイルにコピーするために使用される（ブロック２９１４）。

任意のプロセスまたは方法ステップの順序もしくはシーケンスは、代替実施形態によると、変動または再シーケンス化されてもよい。他の置換、修正、変更、および省略もまた、本発明の範囲から逸脱することなく、種々の例示的実施形態の設計、動作条件、および配列に行われてもよい。

例示的実施形態に示されるような要素の構造および配列は、例証にすぎない。本開示の実施形態が、詳細に説明されたが、本開示を精査する当業者は、列挙される主題の新規教示および利点から著しく逸脱することなく、多くの修正が可能性として考えられることを容易に理解するであろう（例えば、種々の要素のサイズ、寸法、構造、および割合、パラメータの値、材料の使用、配向等の変動）。例えば、一体的に形成されるように示される要素は、複数の部品または要素から構築されてもよい。いくつかの同様のコンポーネントは、異なる図において同一参照番号を使用して本開示に説明されている。これは、これらのコンポーネントが全ての実施形態において同じであることの含意として解釈されるべきではなく、種々の修正が、種々の異なる実施形態において行われてもよい。

Claims (20)

1. 通信デバイスであって、
   通信インターフェースと、
   プロセッサと、
   前記プロセッサに動作可能に結合された非一過性コンピュータ可読メモリ媒体と
   を備え、
   前記メモリ媒体は、前記プロセッサに、
   シード値を読み出すことと、
   デジタルビットストリームを受信することと、
   前記シード値を擬似乱数生成器（ＰＲＮＧ）へのシードとして使用して、ランダムビットのストリームを生成することであって、前記ランダムビットのストリームは、少なくとも前記デジタルビットストリームと同数のビットを含有する、ことと、
   前記ランダムビットのストリームのビットをシャッフルして、ランダムビットバッファを作成することと、
   第１の排他的ＯＲ（ＸＯＲ）を前記デジタルビットストリームおよび前記ランダムビットバッファに適用することによって、難読化されたデジタルビットストリームを生成することであって、前記難読化されたデジタルビットストリームは、前記デジタルビットストリームと同数のビットを有する、ことと、
   前記難読化されたデジタルビットストリームを前記通信インターフェースに提供することと
   を行わせるように構成された命令を記憶するように構成されている、通信デバイス。
2. 前記ランダムビットのストリームは、２バイト数の乗数から成る、請求項１に記載の通信デバイス。
3. 前記命令はさらに、前記プロセッサに、前記プロセッサが、
   前記ランダムビットバッファを初期化することと、
   前記ランダムビットのストリーム内のビットをトラバースし、設定されるビット毎に、宛先ビット場所を計算することと、
   前記宛先ビット場所において前記ランダムビットバッファ内のビットを反転させることと
   を行うように、前記ランダムビットのストリームのビットをシャッフルさせるように構成されている、請求項１に記載の通信デバイス。
4. 前記命令はさらに、前記プロセッサに、前記プロセッサが、前記ランダムビットバッファのビットが全て同一値であるように設定するように、前記ランダムビットバッファを初期化させるように構成されている、請求項３に記載の通信デバイス。
5. 前記命令はさらに、前記プロセッサに、前記プロセッサが、前記ランダムビットバッファのビットが全て０であるように設定するように、前記ランダムビットバッファを初期化させるように構成されている、請求項３に記載の通信デバイス。
6. 前記命令は、前記プロセッサに、テーブルルックアップを使用して、前記宛先ビット場所を計算させるように構成されている、請求項３に記載の通信デバイス。
7. 前記命令はさらに、前記プロセッサに、
   第２のデジタルビットストリームを受信することと、
   前記第２のデジタルビットストリームおよび前記ランダムビットバッファを用いて第２のＸＯＲを実施することによって、第２の難読化されたデジタルビットストリームを生成することであって、前記第１のＸＯＲにおいて使用されない前記ランダムビットバッファのビットのみが、前記第２のＸＯＲにおいて使用される、ことと、
   前記第２の難読化されたデジタルビットストリームが前記第２のデジタルビットストリームと同数のビットを有する場合、前記第２の難読化されたデジタルビットストリームを前記通信インターフェースに提供することと
   を行わせるように構成されている、請求項１に記載の通信デバイス。
8. 前記命令はさらに、前記プロセッサに、
   前記第２のＸＯＲが、前記ランダムビットバッファの終了に到達するが、前記第２のデジタルビットストリームの全てのビットが、ＸＯＲされていないとき、第２のランダムビットのストリームを前記ＰＲＮＧから生成することと、
   前記第２のランダムビットのストリームのビットをシャッフルし、前記ランダムビットバッファを補充することと、
   第３のＸＯＲを前記第２のデジタルビットストリームおよび前記ランダムビットバッファに適用することによって、前記第２の難読化されたデジタルビットストリームを生成し続けることであって、前記第３のＸＯＲの第１のビットは、前記ランダムビットバッファの最初のビットであり、前記第２のデジタルビットストリームの最後のビット後のビットは、前記第２のＸＯＲにおいて使用される、ことと
   を行わせるように構成されている、請求項７に記載の通信デバイス。
9. 前記命令はさらに、前記プロセッサに、
   ルックアップテーブルを使用して前記ランダムビットのストリームのビットをシャッフルし、スワップすべきビットを識別することと、
   前記ランダムビットのストリーム内の複数のビットに基づいて、前記ルックアップテーブル内の複数の値をスワップすることによって、シャッフルされたルックアップテーブルを生成することと、
   前記シャッフルされたルックアップテーブルを使用して前記第２のランダムビットのストリームのビットをシャッフルし、スワップすべきビットを識別することと
   を行わせるように構成されている、請求項８に記載の通信デバイス。
10. 前記命令はさらに、前記プロセッサに前記ルックアップテーブル内の値の素数をスワップさせることによって、前記プロセッサに、前記シャッフルされたルックアップテーブルを生成させるように構成されている、請求項９に記載の通信デバイス。
11. データを難読化するためのコンピュータ実装方法であって、
    シード値を読み出すことと、
    デジタルビットストリームを受信することと、
    前記シード値を擬似乱数生成器（ＰＲＮＧ）へのシードとして使用して、ランダムビットのストリームを生成することであって、前記ランダムビットのストリームは、少なくとも前記デジタルビットストリームと同数のビットを含有する、ことと、
    前記ランダムビットのストリームのビットをシャッフルし、ランダムビットバッファを作成することと、
    第１の排他的ＯＲ（ＸＯＲ）を前記デジタルビットストリームおよび前記ランダムビットバッファに適用することによって、難読化されたデジタルビットストリームを生成することであって、前記難読化されたデジタルビットストリームは、前記デジタルビットストリームと同数のビットを有する、ことと
    を含む、コンピュータ実装方法。
12. 前記ランダムビットバッファを初期化することと、
    前記ランダムビットのストリーム内のビットをトラバースし、設定されるビット毎に、宛先ビット場所を計算することと、
    前記宛先ビット場所において前記ランダムビットバッファ内のビットを反転させることと
    をさらに含む、請求項１１に記載のコンピュータ実装方法。
13. 前記ランダムビットバッファを初期化することは、前記ランダムビットバッファのビットが全て同一値であるように設定する、請求項１２に記載のコンピュータ実装方法。
14. 前記宛先ビットを計算することは、テーブルルックアップを使用することを含む、請求項１２に記載のコンピュータ実装方法。
15. 第２のデジタルビットストリームを受信することと、
    前記第２のデジタルビットストリームおよび前記ランダムビットバッファを用いて第２のＸＯＲを実施することによって、第２の難読化されたデジタルビットストリームを生成することであり、前記第１のＸＯＲにおいて使用されない前記ランダムビットバッファのビットのみが、前記第２のＸＯＲにおいて使用される、ことと
    をさらに含む、請求項１１に記載のコンピュータ実装方法。
16. 前記第２のＸＯＲが、前記ランダムビットバッファの終了に到達するが、前記第２のデジタルビットストリームの全てのビットが、ＸＯＲされていないとき、第２のランダムビットのストリームを前記ＰＲＮＧから生成することと、
    前記第２のランダムビットのストリームのビットをシャッフルし、前記ランダムビットバッファを補充することと、
    第３のＸＯＲを前記第２のデジタルビットストリームおよび前記ランダムビットバッファに適用することによって、前記第２の難読化されたデジタルビットストリームを生成し続けることであって、前記第３のＸＯＲの第１のビットは、前記ランダムビットバッファの最初のビットであって、前記第２のデジタルビットストリームの最後のビット後のビットは、前記第２のＸＯＲにおいて使用される、ことと
    をさらに含む、請求項１５に記載のコンピュータ実装方法。
17. ルックアップテーブルを使用して前記ランダムビットのストリームのビットをシャッフルし、スワップすべきビットを識別することと、
    前記ランダムビットのストリーム内の複数のビットに基づいて、前記ルックアップテーブル内の複数の値をスワップすることによって、シャッフルされたルックアップテーブルを生成することと、
    前記シャッフルされたルックアップテーブルを使用して前記第２のランダムビットのストリームのビットをシャッフルし、スワップすべきビットを識別することと
    をさらに含む、請求項１６に記載のコンピュータ実装方法。
18. その上に命令を記憶するように構成された非一過性コンピュータ可読メモリ媒体であって、前記命令は、プロセッサによってロードされると、前記プロセッサに、
    シード値を読み出すことと、
    デジタルビットストリームを受信することと、
    前記シード値を擬似乱数生成器（ＰＲＮＧ）へのシードとして使用して、ランダムビットのストリームを生成することであって、前記ランダムビットのストリームは、少なくとも前記デジタルビットストリームと同数のビットを含有する、ことと、
    前記ランダムビットのストリームのビットをシャッフルし、ランダムビットバッファを作成することと、
    第１の排他的ＯＲ（ＸＯＲ）を前記デジタルビットストリームおよび前記ランダムビットバッファに適用することによって、難読化されたデジタルビットストリームを生成することであって、前記難読化されたデジタルビットストリームは、前記デジタルビットストリームと同数のビットを有する、ことと、
    前記難読化されたデジタルビットストリームを通信インターフェースに提供することと
    を行わせる、非一過性コンピュータ可読メモリ媒体。
19. 前記非一過性コンピュータ可読メモリ媒体上に記憶された命令はさらに、前記プロセッサに、
    第２のデジタルビットストリームを受信することと、
    前記第２のデジタルビットストリームおよび前記ランダムビットバッファを用いて、第２のＸＯＲを実施することによって、第２の難読化されたデジタルビットストリームを生成することであって、前記第１のＸＯＲにおいて使用されない前記ランダムビットバッファのビットのみが、前記第２のＸＯＲにおいて使用される、ことと、
    前記第２のＸＯＲが、前記ランダムビットバッファの終了に到達するが、前記第２のデジタルビットストリームの全てのビットが、ＸＯＲされていない場合、第２のランダムビットのストリームを前記ＰＲＮＧから生成することと、
    生成された場合、前記第２のランダムビットのストリームのビットをシャッフルし、前記ランダムビットバッファを補充することと、
    第２のランダムビットのストリームが生成された場合、第３のＸＯＲを前記第２のデジタルビットストリームおよび前記ランダムビットバッファに適用することによって、前記第２の難読化されたデジタルビットストリームを生成し続けることであって、前記第３のＸＯＲの第１のビットは、前記ランダムビットバッファの最初のビットであり、前記第２のデジタルビットストリームの最後のビット後のビットは、前記第２のＸＯＲにおいて使用される、ことと、
    前記第２の難読化されたデジタルビットストリームが前記第２のデジタルビットストリームと同数のビットを有する場合、前記第２の難読化されたデジタルビットストリームを前記通信インターフェースに提供することと
    を行わせる、請求項１８に記載の非一過性コンピュータ可読メモリ媒体。
20. 前記非一過性コンピュータ可読メモリ媒体上に記憶された命令はさらに、前記プロセッサに、
    ルックアップテーブルを使用して前記ランダムビットのストリームのビットをシャッフルし、スワップすべきビットを識別することと、
    前記ランダムビットのストリーム内の複数のビットに基づいて、前記ルックアップテーブル内の複数の値をスワップすることによって、シャッフルされたルックアップテーブルを生成することと、
    前記シャッフルされたルックアップテーブルを使用して前記第２のランダムビットのストリームのビットをシャッフルし、スワップすべきビットを識別することと
    を行わせる、請求項１９に記載の非一過性コンピュータ可読メモリ媒体。