暗号データを供給するための方法、モジュールおよびシステム
暗号データのプライマリソースの出力が利用できない期間中に暗号データを供給する方法が開示される。方法は、該期間の初めに暗号データのプライマリソースから暗号データの代替ソースに切り替えることと、該期間中に代替ソースからの暗号データを使用することと、該期間の終わりにプライマリソースに切り替えることを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、特に暗号データ（cipher data）のプライマリソースの出力が利用できない期間中において、暗号データを供給するための方法、モジュールおよびシステムに関する。
【背景技術】
【０００２】
現代のディジタル用途は、データのセキュアな交換に大きく頼っている。例えば、ディジタルオーディオおよびビデオを含むディジタルコンテンツはたいてい、許可された受取人による後の解読のために暗号化された形式で記憶され、伝送される。当然、多くの暗号化／解読技法が知られている。
【０００３】
例えば、Ｈｉｇｈ−ｂａｎｄｗｉｄｔｈ Ｄｉｇｉｔａｌ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ（ＨＤＣＰ）プロトコルは、ポイントツーポイントリンクによる高帯域幅ディジタルデータビデオストリームを保護するために使用される。ＨＤＣＰは例えば、Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ（ＨＤＭＩ）およびＤｉｇｉｔａｌ Ｖｉｄｅｏ Ｉｎｔｅｒｆａｃｅ（ＤＶＩ）によってビデオソースと相互接続されたディスプレイによって使用される。
【０００４】
ＨＤＣＰは、保護しなければならないデータストリームと後にＸＯＲされる（排他論理和がとられる）疑似ランダム暗号化暗号ストリームを生成するために後に使用される暗号エンジンを初期化するために初期認証フェーズを利用する。結果として生じるデータストリームは、暗号化暗号ストリームと同一の解読暗号ストリームを生成し、それを保護されたデータストリームとＸＯＲして初期データを復元しなければ解読することができない。単純なＨＤＣＰ送信側装置／受信側装置システム１００が図１に示されている。
【０００５】
システム１００は送信側装置１１０および受信側装置１２０を含む。送信側装置１１０は、データソース１１４からのデータを暗号化するためにＨＤＣＰ暗号データを生成するＨＤＣＰエンジン１１２を含む。暗号データはＸＯＲゲート１１６を用いてデータソースからのデータと結合され、それによって保護されたデータストリーム１４０を生成する。
【０００６】
受信側装置１２０は、ＨＤＣＰエンジン１１２と同様、保護されたデータストリーム１４０を解読するためにＨＤＣＰ暗号データを生成するＨＤＣＰエンジン１２２を含む。ＨＤＣＰ暗号データは、ＸＯＲゲート１２６を用いて保護されたデータストリーム１４０と結合され、その出力はデータシンク１２４に向けられる。
【０００７】
ＨＤＣＰエンジン１１２および１２２は、それらが要求された暗号化／解読を実行する許可を与えられていることを保証し、それらが互いに同期されていることを保証するために制御および認証情報１３０を交換する。
【０００８】
送信側装置１１０および受信側装置１２０は周期的に再初期化（すなわち鍵再生成（re-key））しなければならない。これは、送信側装置１１０によって供給されたビデオの各ラインについて、そしてビデオの各フレームについて行われる。鍵再生成（re-keying）は送信側装置１１０が受信側装置１２０と同期していることを確実にする。各ラインの後、ＨＤＣＰシステムは、一般に５８サイクルかかるソフトな鍵再生成を実行する。各フレームの後、ハードな鍵再生成が実行され、それには１４２サイクルが割り当てられている。
【０００９】
残念なことに、暗号化は、暗号エンジン１１２および１２２がそれらの期間の間は暗号化データを生成しないので、鍵再生成期間中、不可能である。ＨＤＣＰは一般にラスター化ビデオを保護するために使用されるので、垂直および水平ブランク間隔はこの周期的な鍵再生成に適応しており、暗号エンジン１１２および１２２がデータストリームの暗号化または解読に影響を及ぼすことなく間欠的な暗号化／解読暗号ストリームを生成するのを可能にする。
【００１０】
図２は、ＨＤＣＰラスター化ビデオ２００の例を示している。ラスター化ビデオはアクティブビデオデータ２１０を含み、その間ＨＤＣＰはアクティブである。ラスター化ビデオはまた、従来の垂直および水平帰線消去間隔に対応する垂直２２０および水平ブランク２３０を含む。補助データ２２２は帰線消去間隔に任意選択で埋め込むことができる。暗号化および解読ストリームは、補助データを含んでいない垂直および水平ブランク２２０および２３０のそれらの部分２４０について中断する。毎フレーム鍵再生成（per frame re-keying）２４０および毎ライン鍵再生成（per-line re-keying）は、垂直および／または水平ブランク２２０および２３０の間に生じることができる。
【００１１】
ＨＤＣＰは、ディジタル・コンテント・プロテクション（Digital Content Protection, LLC）から入手可能なＨＤＣＰ仕様書改訂１．２および１．３においてより詳細に述べられており、その内容はこれによって参照により採り入れられる。
【００１２】
残念なことに、必ずしも全部のデータストリームがＨＤＣＰ鍵再生成に適応するために十分な間隔（例えば中断）を含むわけではない。そのようなストリームは従来のＨＤＣＰプロトコルを用いた暗号化に向いていない。例えば、ＨＤＣＰは、非ラスター化ビデオ、または他のデータストリームと連係した使用には向いていない。
【００１３】
例えば、近く公開されるＤｉｓｐｌａｙＰｏｒｔプロトコルは、ＨＤＣＰ鍵再生成に適応するために十分な中断を含まない新しいビデオ相互接続を規定している。より詳しくは、ＤｉｓｐｌａｙＰｏｒｔは当初、単一ストリームラスター化ビデオに意図されていたが、データストリームに予測可能な中断が存在しない非ラスター化多重ストリーム用途まで拡張され得る。ＤｉｓｐｌａｙＰｏｒｔは、ビデオエレクトロニクス標準協会（ＶＥＳＡ）により出版された、ＤｉｓｐｌａｙＰｏｒｔ規格バージョン１．０および１．１においてより詳細に記載されており、その内容はこれによって参照により採り入れられる。
【００１４】
鍵再生成を必要としない新しい暗号化プロトコルは、そのようなストリームのための選択肢である。しかし、ＨＤＣＰはすでに産業界に受け入れられており、そしてＨＤＣＰエンジンはすでに多くの受信側装置および送信側装置の一部を形成している。
【発明の概要】
【発明が解決しようとする課題】
【００１５】
従って、間欠的な暗号化ストリームを供給するＨＤＣＰシステムにおいて使用されるものといった暗号エンジンを用いて多様なデータストリームの暗号化を可能にする新しい暗号化技法の必要性が存在する。
【課題を解決するための手段】
【００１６】
本発明の実施形態の例示的なプライマリ暗号エンジンは、間欠的暗号化ストリームを生成する。プライマリ暗号エンジンは、プライマリエンジンが暗号データを供給していない間に使用され得る暗号データの第２のソースとともに使用されるとしてよい。１実施形態において、プライマリ暗号エンジンはＨＤＣＰ暗号エンジンであり、第２の暗号エンジンはＨＤＣＰ暗号エンジンが鍵再生成している間に出力され得る未使用疑似ランダムデータのストリームを生成する。
【００１７】
一部の実施形態において、これは、いずれかの期間にわたりデータストリームよりも高いレートでＨＤＣＰ暗号エンジンを動作させることによって達成される。これがデータソースおよびシンクの両方において同期した様態で行われた場合、結果として生じるオペレーションは、暗号化および／または解読が単に鍵再生成間隔以外だけでなく常に生じることができるので、あたかも鍵再生成間隔がまったく存在しないように見える。これは鍵再生成間隔によって課される制約を排除し、ＨＤＣＰをよりいっそう多くの状況において、最も顕著にはＤｉｓｐｌａｙＰｏｒｔ規格において、適用できるようにする。
【００１８】
本発明の態様によれば、暗号データのプライマリソースの出力が利用できない期間中に暗号データを供給するための方法が提供され、方法は、期間の初めに暗号データのプライマリソースから暗号データの代替ソースに切り替えることと、期間中に代替ソースからの暗号データを使用することとを含む。
【００１９】
本発明の別の態様によれば、データストリームを暗号化または解読するための暗号データ用プライマリソースと、暗号データの代替ソースと、プライマリソースの出力が利用できない期間中に暗号データ用代替ソースに切り替えるためのスイッチとを含む、暗号化モジュールが提供される。
【００２０】
本発明のまた別の態様によれば、暗号化システムが提供され、これは、暗号化暗号データ用プライマリソースと、暗号化暗号データ用代替ソースと、暗号化データ用プライマリソースの出力が利用できない期間中に暗号化データ用代替ソースに切り替えその期間の後に暗号化データ用プライマリソースに戻すためのスイッチとを備えており、暗号化データは暗号化されたデータストリームを生成するためにデータストリームを暗号化するためのものである、送信側モジュールおよび、解読暗号データ用プライマリソースと、解読暗号データ用代替ソースと、期間中に解読データ用代替ソースに切り替えるためのスイッチとを備えており、解読データは解読されたデータストリームを生成するために暗号化されたデータストリームを解読するためのものである、受信側モジュールを含む。
【００２１】
本発明の他の態様および特徴は、本発明の特定の実施形態の以下の説明を精査すれば、当業者には明瞭となるであろう。
【００２２】
図には本発明の実施形態を例証としてのみ例示する。
【図面の簡単な説明】
【００２３】
【図１】ＨＤＣＰシステムのブロック図である。
【図２】ＨＤＣＰラスター化ビデオのブロック図である。
【図３】本発明の１実施形態の例示的な方法のフローチャートである。
【図４】本発明の実施形態の例示的な暗号化モジュールのブロック図である。
【図５】本発明の実施形態の例示的な暗号化システムのブロック図である。
【図６】本発明の実施形態の例示的なＨＤＣＰモジュールのブロック図である。
【図７】本発明の実施形態の例示的なＨＤＣＰモジュールのブロック図である。
【図８】本発明の実施形態の例示的なＨＤＣＰモジュールについてのタイミング図である。
【図９】本発明の実施形態の例示的なＨＤＣＰモジュールのブロック図である。
【図１０】本発明の実施形態の例示的なＨＤＣＰモジュールについてのタイミング図である。
【図１１】本発明の実施形態の例示的なＨＤＣＰモジュールについてのタイミング図である。
【図１２】本発明の実施形態の例示的なＨＤＣＰモジュールのブロック図である。
【発明を実施するための形態】
【００２４】
本発明の実施形態は、ＨＤＣＰにおける鍵再生成の間といったプライマリソースが利用できない時にアクセスすることができる暗号データの代替ソースを使用する。
【００２５】
本発明の１実施形態は、暗号化データのプライマリソースの出力が利用できない期間中に暗号データを供給するための方法であり、それをここで図３に関して説明する。
【００２６】
図示の通り、方法は、期間の初めに暗号データプのライマリソースから暗号データの代替ソースに切り替えること含む（ステップ３０２）。暗号データは疑似ランダムデータであるとしてよい。例えば、暗号データは従来のＨＤＣＰ暗号化エンジンによって出力された暗号データであるとしてよい。
【００２７】
次に、代替ソースからの暗号データが期間中に使用され得る（ステップ３０４）。期間の終わりにプライマリソースからの暗号データが再び使用され得る（ステップ３０６）。
【００２８】
期間は、ＨＤＣＰまたは類似の鍵再生成の間といった、プライマリソースからの暗号データが利用できない期間であるとしてよい。鍵再生成期間は例えば、データの各フレームごとの前かつ／またはデータの各ラインの前にあるとしてよい。しかし、十分に理解される通り、本発明は鍵再生成期間に限定されない。プライマリソースが利用できないあらゆる期間とすることができる。例えば、プライマリソースの故障中、またはプライマリソースが別様に使用されている時、それによりそれは対象のデータストリームについて利用できない。
【００２９】
暗号データの代替ソースはバッファであるとしてよい。そうした場合、方法はさらに、後の使用のために暗号データの一部をプライマリソースからバッファへ転送することを含み得る。
【００３０】
例えば、プライマリ暗号ソースが暗号化されるデータよりも高いレートで暗号データを生成する場合、暗号データは、暗号化エンジンがデータを供給するのをやめたその間隔における使用のためにバッファされるとしてよい。
【００３１】
極めて特定的な例において、ＨＤＣＰ暗号エンジンは、ＤｉｓｐｌａｙＰｏｒｔデータを暗号化するために使用されるとしてよい。ＨＤＣＰ暗号データは一般に３バイト／サイクルで生成されるのに対し、ＤｉｓｐｌａｙＰｏｒｔデータの各レーンは１バイト／サイクルを要求するにすぎない。１または２レーンについて１つのＨＤＣＰ暗号エンジンが存在する場合、１バイト／サイクルが、バッファが満杯になるまでバッファに向けて送られ得る。このようにして、本発明の実施形態において、方法はさらに、鍵再生成期間の後に所定の期間にわたり過剰な暗号データをバッファに向けて送ることを含む。ＨＤＣＰにおける代表的な最悪ケースのシナリオは、１４２サイクルを必要とするフレーム鍵再生成であるので、好ましい実施形態におけるバッファは暗号化または解読されるデータの各レーンについて１４２バイトを保持する。場合によっては、過剰な暗号データは、暗号化または解読されるデータストリームよりも高いレートで暗号データを生成することによって生成される。
【００３２】
バッファはＦＩＦＯ（先入れ先出し）バッファであるとしてよい。
【００３３】
これは、プライマリＨＤＣＰ暗号エンジンが鍵再生成期間中といった利用できない時にＨＤＣＰ暗号エンジンによる暗号化および／または解読を続行可能にする。これは転じて、データストリームに予測可能な中断を欠いている非ラスター化ビデオデータを暗号化可能にする。都合のよいことに、非ラスター化ビデオデータは、結果として生じる暗号化ストリームを用いて暗号化され得る。特定の実施形態において、方法はＤｉｓｐｌａｙＰｏｒｔデータを暗号化または解読することをさらに含む。
【００３４】
代替的な実施形態において、暗号化データの第２のソースは第２のＨＤＣＰ暗号エンジンであるとしてよい。
【００３５】
図４は、本発明の実施形態において例示的な暗号化モジュール４００を図示している。暗号化モジュール４００は、暗号データ用プライマリソース４０２、暗号データ用代替ソース４０４およびスイッチ４０６を含む。プライマリおよび代替ソース４０２、４０２によって生成された暗号データは、データストリーム４１０を暗号化または解読するためのものである。スイッチ４０６はプライマリソース４０２の出力が利用できない期間中に暗号データ用代替ソース４０４に切り替えるとしてよい。スイッチ４０６は例えば、暗号データ４０２が利用できないまさしくその時に切り替えることができよう。代替として、スイッチ４０６は、暗号データが常に利用できるような定期（または不定期）間隔で暗号データ４０２と暗号４０４との間で切り替えることができよう。代替として、スイッチ４０６は制御可能スイッチまたはマルチプレクサであるとしてよい。スイッチ４０６は代替として、ソース４０２および４０４のどちらか一方または両方からの暗号化データが記憶されるメモリまたはバッファへのレジスタまたは他のポインタとしてインプリメントすることもできよう。ポインタ／レジスタは、どちらか一方のソースからの暗号データ間で選択するために更新することができよう。代替として、スイッチ４０６は、当業者によって理解されるソース４０２および４０４間で選択するためのいずれかの他の装置または機能ブロックとすることができよう。
【００３６】
一部の実施形態において、代替ソース４０４は上述の通りバッファである。場合によっては、モジュール４００は、暗号データの一部をプライマリソースからバッファに向けて送る機能ブロックを含む。機能ブロックは、マルチプレクサ、スイッチ等の形態を取ることができよう。場合によっては、バッファに向けて送られる暗号データの部分は、暗号化または解読に必要とされない過剰な暗号データである。例えば、制御信号は暗号化されないので、従って制御信号を含むデータストリーム４１０の部分は暗号データを必要としない。一般に、制御信号がデータストリーム４１０に現れる時に生成される暗号データは絶対に使用されないので、従ってそれはバッファに転送されるために利用できる。
【００３７】
プライマリソース４０２は代替として、暗号データの部分がバッファに向けて送られている間、加速レートで暗号データを生成することができる。場合によっては、プライマリソース４０２は常にこの加速レートで動作する。常に同じレートで動作することは、バッファが満杯か否かに応じてレートを変えることよりも単純であり、より少ない制御を必要とする。一部の実施形態において、バッファに向けて送られる暗号データの部分は、暗号化または解読されるデータストリーム４１０が制御データを含む時に生成された暗号データである。
【００３８】
やはり、暗号データはＨＤＣＰ暗号データであるとしてよい。
【００３９】
図５に言及すれば、本発明の別の実施形態の例示的な暗号化システム５００は、送信側モジュール５１０および受信側モジュール５２０を含む。送信側モジュール５１０は、暗号化暗号データ用プライマリソース５１２、暗号化暗号データ用代替ソース５１４および、暗号化データ用プライマリソース５１２の出力が利用できない期間中に暗号化データ用代替ソース５１４に切り替え、その期間後にＨＤＣＰ暗号化データ用プライマリソース５１２に戻すためのスイッチ５１６を含む。暗号化暗号データは、暗号化されたデータストリーム５４０を生成するためにデータストリーム５３０を暗号化するために使用される。受信側モジュール５２０は、解読暗号データ用プライマリソース５２２、解読暗号データ用代替ソース５２４および、期間中に解読データ用代替ソース５２４に切り替え、そして期間後に解読データ用プライマリソース５２２に戻すためのスイッチ５２６を含む。解読暗号データは、解読されたデータストリーム５５０を生成するために暗号化されたデータストリーム５４０を解読するためのものである。
【００４０】
一部の実施形態において、送信側モジュール５１０および受信側モジュール５２０の各々のスイッチ５１６、５２６は、鍵再生成期間の初めにそれぞれの代替ソース５１４、５２４に切り替え、鍵再生成期間の終わりにそれぞれのプライマリソース５１２、５２２に戻すように適応されている。
【００４１】
一部の実施形態において、送信側モジュール５１０は暗号化データをデータストリーム５３０と結合するためのＸＯＲゲートをさらに含む。同様に、受信側モジュール５２０の一部の実施形態は、解読データを暗号化されたデータストリーム５４０と結合するためのＸＯＲゲートをさらに含む。
【００４２】
やはり、暗号データはＨＤＣＰ暗号データであるとしてよい。
【００４３】
システム５００はＤｉｓｐｌａｙＰｏｒｔプロトコル用に適応されているとしてよい。そのような場合、送信側モジュール５１０はレーンスキューイング（lane skewing）前のリンク層とＰＨＹ（物理層）との間のインタフェースに配置することができ、受信側モジュール５２０はレーンデスキューイング（lane de-skewing）前のリンク層とＰＨＹとの間のインタフェースに配置することができる。
【００４４】
十分に理解され得るように、本発明の一部の実施形態は、暗号エンジンの出力が利用できない鍵再生成期間中に暗号エンジンの出力の代わりにバッファされ出力され得る過剰な疑似ランダムデータを必要とする。必要とされるバッファリングの量、暗号エンジンがクロックされる必要があるレート、暗号エンジンが前記レートでクロックされる期間および、ソースまたは送信側装置エンジンとシンクまたは受信側装置エンジンとの間の同期メカニズムは、個々の用途に依存し、設計者の裁量である。
【００４５】
ＨＤＣＰ暗号データをＤｉｓｐｌａｙＰｏｒｔにマップするための特定的な解決策をここで図６〜１４に関して説明する。
【００４６】
ＤｉｓｐｌａｙＰｏｒｔは高帯域幅ポイントツーポイントディジタル相互接続解決策であり、それは最終的に、各々が１６２ＭＢ／秒または２７０ＭＢ／秒どちらかのデータを転送することができる現在は１、２または４データレーンをサポートするスケーラブルリンクによって多数のデータフォーマットおよびタイプをサポートすることができる。
【００４７】
ＨＤＣＰの出力暗号は最大３Ｂ／サイクルまでの疑似ランダムデータ生成することができるのに対し、ＤｉｓｐｌａｙＰｏｒｔはアクティブレーンの数に応じて１Ｂ、２Ｂまたは４Ｂ／サイクルいずれかの暗号データを必要とする。１および２レーンの場合、ＨＤＣＰ暗号の単一インスタンス（instance）を使用することができ、４レーンの場合には、ＨＤＣＰ暗号の２インスタンスを使用することができる。もし過剰分をバッファし、かつ鍵再生成がアクティブでない時に出力ストリームの必要性を満たすことの両方に十分なＨＤＣＰ疑似ランダムデータが利用できることを保証するために４レーン構成をオーバークロック（overclock）させたいのであれば、全部の場合に単一エンジンを使用することができるということに留意されたい。
【００４８】
１つ以上の暗号エンジンが送信側装置ロジックと同じレートでクロックされる場合、それは、それぞれ１／２／４レーン構成に必要とされるものよりも（３／１）／（３／２）／（２・３／４）＝３×／１．５×／１．５×多いデータを生成する。生成された過剰なデータの一部または全部は、未定の期間バッファに格納されてから、鍵再生成されている間、暗号が利用できない期間中に出力され得る。結果として得られるインプリメンテーションが図６に示されている。
【００４９】
図６において、ＨＤＣＰモジュール６００は、４レーンのデータ６３０、６４０、６５０および６６０にサービスするために２つのＨＤＣＰ暗号エンジン６１０および６２０を備える。第１の暗号エンジン６１０は、マルチプレクサ６１４に直接２Ｂ／サイクルの暗号データを、そしてＦＩＦＯバッファ６１２に１Ｂ／サイクルを供給する。ＦＩＦＯ６１２の出力もまたマルチプレクサ６１４に供給される。マルチプレクサ６１４はまた、暗号エンジン６１０が鍵再生成モードにあるか否かを指示する信号ＲＥＫＥＹ−ＥＮ６１６を入力として有する。この場合、値０がアクティブモードを表し、値１が鍵再生成モードを表す。従って、マルチプレクサ６１４が０を受け取った時に、暗号データは暗号エンジン６１０からＸＯＲゲート６１８および６１９に向けて送られて、それぞれレーン６３０および６４０からのデータと結合されてそれぞれの暗号化されたデータレーン６３５および６４５を生成する。同じ設定が第２の暗号エンジン６２０について反映される。すなわち、２Ｂ／サイクルの暗号データがマルチプレクサ６２４に直接供給され、そして１Ｂ／サイクルがＦＩＦＯバッファ６２２に供給される。ＦＩＦＯ６２２からの出力もやはりマルチプレクサ６２４に向かう。マルチプレクサ６２４はまた、暗号エンジン６２０が鍵再生成モードにあるか否かを指示する信号ＲＥＫＥＹ＿ＥＮ６２６を入力として有する。マルチプレクサ６２４が０を受け取った時に、暗号データは暗号エンジン６２０からＸＯＲゲート６２８および６２９に向けて送られて、それぞれレーン６５０および６６０からのデータと結合されてそれぞれの暗号化されたデータレーン６５５および６６５を生成する。
【００５０】
暗号がクロックされるレート、およびそれらが加速レートで走行する期間は、鍵再生成期間中にデータストリームを暗号化するためにＦＩＦＯ６１２、６２２に格納された十分な過剰なデータが存在する限り、完全に設計者の裁量である。ＨＤＣＰの場合、毎フレーム方式で１４２サイクル分のデータまたは毎ライン方式で５８サイクル分のデータが利用できなければならず、ここで「フレーム」および「ライン」の概念は用途に適合するように定義することができる。「ライン」および「フレーム」の文字通りの定義はラスター化ビデオデータの場合にあてはまるが、それほど構造化されていないデータパターンの場合、「ライン」は（帰線消去開始“ＢＳ”によって指示される）帰線消去開始制御シンボル間の時間として定義することができるであろうし、そして「フレーム」は５１２ＢＳ制御シンボルごとに生起する連続スクランブラリセット（“ＳＲ”）制御シンボル間の時間として定義することができよう。
【００５１】
それらが同じ過剰データを生成することを保証するソースおよびシンク装置のＨＤＣＰエンジン間の同期は、過剰バイトが識別され格納のためにタグ付けされる単純なアプリオリ定義戦略によって維持され得る。例えば、暗号はデータストリームと同じレートで走行することができる。最初の２５６Ｂの過剰データは、鍵再生成期間の終わりの後に記憶されてから、次の鍵再生成期間までバッファされるとしてよい。バッファは、ソースおよびシンクが各期間に同じＦＩＦＯ状態で始動するのを保証するために各々の鍵再生成期間の終わりにフラッシュされる。
【００５２】
ＨＤＣＰモジュール６００の別の構成が図７に例証されている。図示の通り、ＨＤＣＰモジュール７００はモジュール６００の一半分だけを、すなわちＨＤＣＰ暗号エンジン６１０によってサービスされる半分を表す。この構成では、ＸＯＲゲート６１９への出力を備える付加的なマルチプレクサ６１５が存在する。暗号エンジン６１０は、１Ｂ／サイクルをマルチプレクサ６１４に、１Ｂ／サイクルをマルチプレクサ６１５に、そして１Ｂ／サイクルをＦＩＦＯ６１２に向けて送る。
【００５３】
上述の通り、本発明の実施形態は、ＤｉｓｐｌａｙＰｏｒｔの１、２または４レーン構成に適用することができる。２レーン構成についてのタイミング図が図８に示されている。図８のタイミング図は、以下の１２の信号のタイミングを示している。クロックであるＬＡＮＥ＿ＣＬＫ８１０；ＨＤＣＰエンジンが鍵再生成モードにあるか否かを指示するＲＥＫＥＹ＿ＥＮ８１５；ＨＤＣＰ暗号エンジンからの出力であるＨＤＣＰｏｕｔ［７：０］８２０、ＨＤＣＰｏｕｔ［１５：８］８２５およびＨＤＣＰｏｕｔ［２３：１６］８３０；暗号データを出力するようにＦＩＦＯに合図するＦＩＦＯ＿ＲＥＮ８３５；ＦＩＦＯからの出力であるＦＩＦＯｏｕｔ［７：０］８４０およびＦＩＦＯｏｕｔ［１５：８］８４５；ＦＩＦＯが補充されていることを指示するＦＩＦＯ＿ＷＥＮ８５０；ＦＩＦＯへの入力であるＦＩＦＯｉｎ８５５；２レーンを暗号化または解読するために使用される暗号データを表すＬａｎｅ０Ｍａｓｋ８６０およびＬａｎｅ１Ｍａｓｋ８６５。最初の時間ブロックは通常のＨＤＣＰオペレーション８７０であり、その間にＨＤＣＰ出力８２０および８２５はデータをＬａｎｅ０Ｍａｓｋ８６０およびＬａｎｅ１Ｍａｓｋ８６５に供給する。ＦＩＦＯ出力８４０および８４５はイナクティブである。この例の目的で、ＦＩＦＯはタイミング図の開始時にすでに満杯である。次の時間ブロックはＨＤＣＰキープアウトまたは鍵再生成期間８７５であり、その間にＦＩＦＯ出力８４０および８４５はデータをＬａｎｅ０Ｍａｓｋ８６０およびＬａｎｅ１Ｍａｓｋ８６５に供給する。ＨＤＣＰ出力８２０、８２５および８３０はこの間イナクティブである。ＲＥＫＥＹ−ＥＮ８１５はこの期間中１の値を有し、他の全部の時間には０を有する。次の時間ブロックはＦＩＦＯ再ロード期間８８０であり、その間にＦＩＦＯｉｎ８５５はＦＩＦＯを再ロードするためにＨＤＣＰｏｕｔ［２３：１６］８３０からデータを受け取る。ＦＩＦＯ＿ＷＥＮ８５０はこの期間中１の値を有し、他の全部の時間には０の値を有する。他の全部の信号はあたかもＨＤＣＰ通常オペレーション８７０の間のように動作する。
【００５４】
４レーン構成の場合、タイミング図は第２のＨＤＣＰエンジンについて繰り返される。単レーン構成の場合、Ｌａｎｅ１Ｍａｓｋ８６５が存在せず、それはＦＩＦＯｏｕｔ［１５：８］８４５が使用されないことを意味する。それ以外、タイミングは同じである。
【００５５】
１レーン構成において、１Ｂ／サイクルのＨＤＣＰ暗号データだけが暗号化または解読に要求されるので、従って暗号エンジンは半分のレートで走行することができる。２レーン構成に加えて、１レーン構成を半分のレートで可能にする本発明の実施形態をここで図９に関して説明する。ＨＤＣＰモジュール９００は、マルチプレクサ６１４および６１５とＸＯＲゲート６１８との間の付加的なマルチプレクサ６２０を除いて、図７に関して説明したＨＤＣＰモジュール７００と同じである。マルチプレクサ６２０への入力は、マルチプレクサ６１４および６１５からの出力のほか、ＥＶＥＮ＿ＯＤＤ信号６２２である。マルチプレクサ６１５からの出力はまたＸＯＲゲート６１９にも向かう。単レーンモードにおいて、ＸＯＲゲート６１９が配置されたレーンはイナクティブであり、ＨＤＣＰ暗号エンジン６１０は１／２レートで走行し、ＥＶＥＮ＿ＯＤＤ信号６２２は０と１の間で振動する。振動信号６２２は、マルチプレクサ６１４および６１５の出力の組合せであるマルチプレクサ６２０の出力となる。２レーンモードにおいて、ＨＤＣＰ暗号エンジン６１０はフルレートで走行し、ＥＶＥＮ＿ＯＤＤ信号は０の値を有する。図１０はこの実施形態の単レーンモードのタイミング図であり、そして図１１は２レーンモードのタイミング図である。
【００５６】
図１０のタイミング図は、Ｌａｎｅ１Ｍａｓｋ８６５を除き図８と同じ全部の信号を含む。それは１つの付加的な信号ＥＶＥＮ＿ＯＤＤ１０１０を有し、それは全部の時間ブロックの間、振動する。
【００５７】
図１１は、図１０に関して説明したＥＶＥＮ＿ＯＤＤ信号を含むということ以外、図８と同じである。図１１において、ＥＶＥＮ＿ＯＤＤ信号は０の値を維持し、従ってＨＤＣＰモジュールは図８に関して説明した２レーンモードと同様にして動作する。
【００５８】
代替として、単レーンモードにおいて、ＨＤＣＰエンジンは１／３レートで走行することができよう。この実施形態において、バッファに向けて送られる暗号データは、データストリームが制御信号を含む時に使用されない暗号データでなければならないであろう。
【００５９】
別の代替的な実施形態において、ＨＤＣＰ暗号エンジンは４Ｂ／サイクルで出力するように修正されるとしてよい。これは、１つのＨＤＣＰ暗号エンジンが４レーンのＤｉｓｐｌａｙＰｏｒｔデータにサービスすることを可能にする。バッファはデータストリームが制御データを含む時に使用されていないＨＤＣＰ出力で満たされる。図１２は、この解決策の１実施形態に従ったＨＤＣＰモジュール１２００の概略図である。
【００６０】
ＨＤＣＰモジュール１２００のＨＤＣＰ暗号エンジン１２１０は４Ｂ／サイクルを出力し、１バイトずつ４つのマルチプレクサ１２３０、１２３２、１２３４および１２３６の各々に向かう。各マルチプレクサはまた入力としてそれぞれのＦＩＦＯ１２１１、１２１２、１２１４および１２１６の出力を有する。４つ全部のＦＩＦＯは入力としてＫｃｏｄｅ信号１２２０を有し、それはデータストリーム１２５０、１２６０、１２７０および１２８０が制御信号を含むことを指示する。ＨＤＣＰ暗号エンジン１２１０からの出力は、データストリーム１２５０、１２６０、１２７０および１２８０が制御信号を含む場合、ＦＩＦＯ１２１１、１２１２、１２１４および１２１６に向けて送られる。マルチプレクサ１２３０、１２３２、１２３４および１２３６はすべてＲＥＫＥＹ−ＥＮ信号１２２５を入力として受け取る。ＨＤＣＰ暗号エンジンが鍵再生成モードにあることをこの信号１２２５が指示した場合、それらは各自のＦＩＦＯからの暗号データを各自の出力として使用する。以前の例と同様、マルチプレクサからの出力はＸＯＲゲート１２４０、１２４２、１２４４および１２４６に向けて送られ、そこで暗号データはデータストリーム１２５０、１２６０、１２７０および１２８０と結合されてそれぞれ出力データストリーム１２４５、１２５５、１２６５および１２７５を生成する。
【００６１】
代替として、そしてより一般的に、ＨＤＣＰ暗号エンジン１２１０は、Ｎレーンについて要求されるよりも高いレートでクロックされることができよう。例えば、ＨＤＣＰサイファー１２１０は、各レーンのデータレート、レートＮ／（Ｎ−Ｍ）で暗号データを供給するレートでクロックされることができよう。その場合、暗号データのＮ単位ごとのうちのＭ個が後の使用のためにＦＩＦＯに供給されるとしてよい。
【００６２】
試みることができる代替的な解決策は、要求されるよりも大きなデータレートで走行し、他のエンジンの鍵再生成間隔を隠すために１つのＨＤＣＰエンジンの出力を使用する、複数のＨＤＣＰエンジンを利用することである。１つのエンジンが鍵再生成されている時、すなわちその出力がディスエーブルである時に、他の暗号エンジンがデータストリームを暗号化するために使用されるであろう。この付加的暗号化は、もしそれが使用されるのを待って遊んでいるのであれば付加的なサイファーをイネーブルにするか、またはそのサイファーが現在鍵再生成しているストリームによって要求される付加的な疑似ランダムデータを生成するためにそれをオーバークロックさせるかのどちらかによって、達成することができよう。
【００６３】
この解決策の場合、鍵再生成間隔中の使用のために常に１つの暗号エンジンが利用可能でなければならず、そしてエンジンの鍵再生成は十分にずらされ、全部の暗号エンジンが同時に鍵再生成を要求している期間が決して存在してはならない。また、暗号インスタンスの絶対数または、所与のいずれかの時に要求量の疑似ランダムデータを供給するために任意の数の利用可能なインスタンスをオーバークロックできる能力のどちらかによって、ＨＤＣＰエンジンのプール内に十分な帯域幅が存在しなければならない。
【００６４】
今や十分に理解されるはずであるように、ここで説明した方法はハードウェア、ソフトウェアまたはそれらの組合せにおいて実施することができる。例えば、コンピュータによってインプリメントされた時にそれぞれの方法を実行するコンピュータ可読命令がそれに記憶されているコンピュータ可読媒体。それらはハードウェア、ソフトウェアまたはそれらの組合せを用いて実施することができる。
【００６５】
説明したものは単に本発明の原理の応用を例証するにすぎない。それどころか、他の装置および方法が本発明の範囲を逸脱することなく当業者によって実施することができる。
【技術分野】
【０００１】
本発明は、特に暗号データ（cipher data）のプライマリソースの出力が利用できない期間中において、暗号データを供給するための方法、モジュールおよびシステムに関する。
【背景技術】
【０００２】
現代のディジタル用途は、データのセキュアな交換に大きく頼っている。例えば、ディジタルオーディオおよびビデオを含むディジタルコンテンツはたいてい、許可された受取人による後の解読のために暗号化された形式で記憶され、伝送される。当然、多くの暗号化／解読技法が知られている。
【０００３】
例えば、Ｈｉｇｈ−ｂａｎｄｗｉｄｔｈ Ｄｉｇｉｔａｌ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ（ＨＤＣＰ）プロトコルは、ポイントツーポイントリンクによる高帯域幅ディジタルデータビデオストリームを保護するために使用される。ＨＤＣＰは例えば、Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ（ＨＤＭＩ）およびＤｉｇｉｔａｌ Ｖｉｄｅｏ Ｉｎｔｅｒｆａｃｅ（ＤＶＩ）によってビデオソースと相互接続されたディスプレイによって使用される。
【０００４】
ＨＤＣＰは、保護しなければならないデータストリームと後にＸＯＲされる（排他論理和がとられる）疑似ランダム暗号化暗号ストリームを生成するために後に使用される暗号エンジンを初期化するために初期認証フェーズを利用する。結果として生じるデータストリームは、暗号化暗号ストリームと同一の解読暗号ストリームを生成し、それを保護されたデータストリームとＸＯＲして初期データを復元しなければ解読することができない。単純なＨＤＣＰ送信側装置／受信側装置システム１００が図１に示されている。
【０００５】
システム１００は送信側装置１１０および受信側装置１２０を含む。送信側装置１１０は、データソース１１４からのデータを暗号化するためにＨＤＣＰ暗号データを生成するＨＤＣＰエンジン１１２を含む。暗号データはＸＯＲゲート１１６を用いてデータソースからのデータと結合され、それによって保護されたデータストリーム１４０を生成する。
【０００６】
受信側装置１２０は、ＨＤＣＰエンジン１１２と同様、保護されたデータストリーム１４０を解読するためにＨＤＣＰ暗号データを生成するＨＤＣＰエンジン１２２を含む。ＨＤＣＰ暗号データは、ＸＯＲゲート１２６を用いて保護されたデータストリーム１４０と結合され、その出力はデータシンク１２４に向けられる。
【０００７】
ＨＤＣＰエンジン１１２および１２２は、それらが要求された暗号化／解読を実行する許可を与えられていることを保証し、それらが互いに同期されていることを保証するために制御および認証情報１３０を交換する。
【０００８】
送信側装置１１０および受信側装置１２０は周期的に再初期化（すなわち鍵再生成（re-key））しなければならない。これは、送信側装置１１０によって供給されたビデオの各ラインについて、そしてビデオの各フレームについて行われる。鍵再生成（re-keying）は送信側装置１１０が受信側装置１２０と同期していることを確実にする。各ラインの後、ＨＤＣＰシステムは、一般に５８サイクルかかるソフトな鍵再生成を実行する。各フレームの後、ハードな鍵再生成が実行され、それには１４２サイクルが割り当てられている。
【０００９】
残念なことに、暗号化は、暗号エンジン１１２および１２２がそれらの期間の間は暗号化データを生成しないので、鍵再生成期間中、不可能である。ＨＤＣＰは一般にラスター化ビデオを保護するために使用されるので、垂直および水平ブランク間隔はこの周期的な鍵再生成に適応しており、暗号エンジン１１２および１２２がデータストリームの暗号化または解読に影響を及ぼすことなく間欠的な暗号化／解読暗号ストリームを生成するのを可能にする。
【００１０】
図２は、ＨＤＣＰラスター化ビデオ２００の例を示している。ラスター化ビデオはアクティブビデオデータ２１０を含み、その間ＨＤＣＰはアクティブである。ラスター化ビデオはまた、従来の垂直および水平帰線消去間隔に対応する垂直２２０および水平ブランク２３０を含む。補助データ２２２は帰線消去間隔に任意選択で埋め込むことができる。暗号化および解読ストリームは、補助データを含んでいない垂直および水平ブランク２２０および２３０のそれらの部分２４０について中断する。毎フレーム鍵再生成（per frame re-keying）２４０および毎ライン鍵再生成（per-line re-keying）は、垂直および／または水平ブランク２２０および２３０の間に生じることができる。
【００１１】
ＨＤＣＰは、ディジタル・コンテント・プロテクション（Digital Content Protection, LLC）から入手可能なＨＤＣＰ仕様書改訂１．２および１．３においてより詳細に述べられており、その内容はこれによって参照により採り入れられる。
【００１２】
残念なことに、必ずしも全部のデータストリームがＨＤＣＰ鍵再生成に適応するために十分な間隔（例えば中断）を含むわけではない。そのようなストリームは従来のＨＤＣＰプロトコルを用いた暗号化に向いていない。例えば、ＨＤＣＰは、非ラスター化ビデオ、または他のデータストリームと連係した使用には向いていない。
【００１３】
例えば、近く公開されるＤｉｓｐｌａｙＰｏｒｔプロトコルは、ＨＤＣＰ鍵再生成に適応するために十分な中断を含まない新しいビデオ相互接続を規定している。より詳しくは、ＤｉｓｐｌａｙＰｏｒｔは当初、単一ストリームラスター化ビデオに意図されていたが、データストリームに予測可能な中断が存在しない非ラスター化多重ストリーム用途まで拡張され得る。ＤｉｓｐｌａｙＰｏｒｔは、ビデオエレクトロニクス標準協会（ＶＥＳＡ）により出版された、ＤｉｓｐｌａｙＰｏｒｔ規格バージョン１．０および１．１においてより詳細に記載されており、その内容はこれによって参照により採り入れられる。
【００１４】
鍵再生成を必要としない新しい暗号化プロトコルは、そのようなストリームのための選択肢である。しかし、ＨＤＣＰはすでに産業界に受け入れられており、そしてＨＤＣＰエンジンはすでに多くの受信側装置および送信側装置の一部を形成している。
【発明の概要】
【発明が解決しようとする課題】
【００１５】
従って、間欠的な暗号化ストリームを供給するＨＤＣＰシステムにおいて使用されるものといった暗号エンジンを用いて多様なデータストリームの暗号化を可能にする新しい暗号化技法の必要性が存在する。
【課題を解決するための手段】
【００１６】
本発明の実施形態の例示的なプライマリ暗号エンジンは、間欠的暗号化ストリームを生成する。プライマリ暗号エンジンは、プライマリエンジンが暗号データを供給していない間に使用され得る暗号データの第２のソースとともに使用されるとしてよい。１実施形態において、プライマリ暗号エンジンはＨＤＣＰ暗号エンジンであり、第２の暗号エンジンはＨＤＣＰ暗号エンジンが鍵再生成している間に出力され得る未使用疑似ランダムデータのストリームを生成する。
【００１７】
一部の実施形態において、これは、いずれかの期間にわたりデータストリームよりも高いレートでＨＤＣＰ暗号エンジンを動作させることによって達成される。これがデータソースおよびシンクの両方において同期した様態で行われた場合、結果として生じるオペレーションは、暗号化および／または解読が単に鍵再生成間隔以外だけでなく常に生じることができるので、あたかも鍵再生成間隔がまったく存在しないように見える。これは鍵再生成間隔によって課される制約を排除し、ＨＤＣＰをよりいっそう多くの状況において、最も顕著にはＤｉｓｐｌａｙＰｏｒｔ規格において、適用できるようにする。
【００１８】
本発明の態様によれば、暗号データのプライマリソースの出力が利用できない期間中に暗号データを供給するための方法が提供され、方法は、期間の初めに暗号データのプライマリソースから暗号データの代替ソースに切り替えることと、期間中に代替ソースからの暗号データを使用することとを含む。
【００１９】
本発明の別の態様によれば、データストリームを暗号化または解読するための暗号データ用プライマリソースと、暗号データの代替ソースと、プライマリソースの出力が利用できない期間中に暗号データ用代替ソースに切り替えるためのスイッチとを含む、暗号化モジュールが提供される。
【００２０】
本発明のまた別の態様によれば、暗号化システムが提供され、これは、暗号化暗号データ用プライマリソースと、暗号化暗号データ用代替ソースと、暗号化データ用プライマリソースの出力が利用できない期間中に暗号化データ用代替ソースに切り替えその期間の後に暗号化データ用プライマリソースに戻すためのスイッチとを備えており、暗号化データは暗号化されたデータストリームを生成するためにデータストリームを暗号化するためのものである、送信側モジュールおよび、解読暗号データ用プライマリソースと、解読暗号データ用代替ソースと、期間中に解読データ用代替ソースに切り替えるためのスイッチとを備えており、解読データは解読されたデータストリームを生成するために暗号化されたデータストリームを解読するためのものである、受信側モジュールを含む。
【００２１】
本発明の他の態様および特徴は、本発明の特定の実施形態の以下の説明を精査すれば、当業者には明瞭となるであろう。
【００２２】
図には本発明の実施形態を例証としてのみ例示する。
【図面の簡単な説明】
【００２３】
【図１】ＨＤＣＰシステムのブロック図である。
【図２】ＨＤＣＰラスター化ビデオのブロック図である。
【図３】本発明の１実施形態の例示的な方法のフローチャートである。
【図４】本発明の実施形態の例示的な暗号化モジュールのブロック図である。
【図５】本発明の実施形態の例示的な暗号化システムのブロック図である。
【図６】本発明の実施形態の例示的なＨＤＣＰモジュールのブロック図である。
【図７】本発明の実施形態の例示的なＨＤＣＰモジュールのブロック図である。
【図８】本発明の実施形態の例示的なＨＤＣＰモジュールについてのタイミング図である。
【図９】本発明の実施形態の例示的なＨＤＣＰモジュールのブロック図である。
【図１０】本発明の実施形態の例示的なＨＤＣＰモジュールについてのタイミング図である。
【図１１】本発明の実施形態の例示的なＨＤＣＰモジュールについてのタイミング図である。
【図１２】本発明の実施形態の例示的なＨＤＣＰモジュールのブロック図である。
【発明を実施するための形態】
【００２４】
本発明の実施形態は、ＨＤＣＰにおける鍵再生成の間といったプライマリソースが利用できない時にアクセスすることができる暗号データの代替ソースを使用する。
【００２５】
本発明の１実施形態は、暗号化データのプライマリソースの出力が利用できない期間中に暗号データを供給するための方法であり、それをここで図３に関して説明する。
【００２６】
図示の通り、方法は、期間の初めに暗号データプのライマリソースから暗号データの代替ソースに切り替えること含む（ステップ３０２）。暗号データは疑似ランダムデータであるとしてよい。例えば、暗号データは従来のＨＤＣＰ暗号化エンジンによって出力された暗号データであるとしてよい。
【００２７】
次に、代替ソースからの暗号データが期間中に使用され得る（ステップ３０４）。期間の終わりにプライマリソースからの暗号データが再び使用され得る（ステップ３０６）。
【００２８】
期間は、ＨＤＣＰまたは類似の鍵再生成の間といった、プライマリソースからの暗号データが利用できない期間であるとしてよい。鍵再生成期間は例えば、データの各フレームごとの前かつ／またはデータの各ラインの前にあるとしてよい。しかし、十分に理解される通り、本発明は鍵再生成期間に限定されない。プライマリソースが利用できないあらゆる期間とすることができる。例えば、プライマリソースの故障中、またはプライマリソースが別様に使用されている時、それによりそれは対象のデータストリームについて利用できない。
【００２９】
暗号データの代替ソースはバッファであるとしてよい。そうした場合、方法はさらに、後の使用のために暗号データの一部をプライマリソースからバッファへ転送することを含み得る。
【００３０】
例えば、プライマリ暗号ソースが暗号化されるデータよりも高いレートで暗号データを生成する場合、暗号データは、暗号化エンジンがデータを供給するのをやめたその間隔における使用のためにバッファされるとしてよい。
【００３１】
極めて特定的な例において、ＨＤＣＰ暗号エンジンは、ＤｉｓｐｌａｙＰｏｒｔデータを暗号化するために使用されるとしてよい。ＨＤＣＰ暗号データは一般に３バイト／サイクルで生成されるのに対し、ＤｉｓｐｌａｙＰｏｒｔデータの各レーンは１バイト／サイクルを要求するにすぎない。１または２レーンについて１つのＨＤＣＰ暗号エンジンが存在する場合、１バイト／サイクルが、バッファが満杯になるまでバッファに向けて送られ得る。このようにして、本発明の実施形態において、方法はさらに、鍵再生成期間の後に所定の期間にわたり過剰な暗号データをバッファに向けて送ることを含む。ＨＤＣＰにおける代表的な最悪ケースのシナリオは、１４２サイクルを必要とするフレーム鍵再生成であるので、好ましい実施形態におけるバッファは暗号化または解読されるデータの各レーンについて１４２バイトを保持する。場合によっては、過剰な暗号データは、暗号化または解読されるデータストリームよりも高いレートで暗号データを生成することによって生成される。
【００３２】
バッファはＦＩＦＯ（先入れ先出し）バッファであるとしてよい。
【００３３】
これは、プライマリＨＤＣＰ暗号エンジンが鍵再生成期間中といった利用できない時にＨＤＣＰ暗号エンジンによる暗号化および／または解読を続行可能にする。これは転じて、データストリームに予測可能な中断を欠いている非ラスター化ビデオデータを暗号化可能にする。都合のよいことに、非ラスター化ビデオデータは、結果として生じる暗号化ストリームを用いて暗号化され得る。特定の実施形態において、方法はＤｉｓｐｌａｙＰｏｒｔデータを暗号化または解読することをさらに含む。
【００３４】
代替的な実施形態において、暗号化データの第２のソースは第２のＨＤＣＰ暗号エンジンであるとしてよい。
【００３５】
図４は、本発明の実施形態において例示的な暗号化モジュール４００を図示している。暗号化モジュール４００は、暗号データ用プライマリソース４０２、暗号データ用代替ソース４０４およびスイッチ４０６を含む。プライマリおよび代替ソース４０２、４０２によって生成された暗号データは、データストリーム４１０を暗号化または解読するためのものである。スイッチ４０６はプライマリソース４０２の出力が利用できない期間中に暗号データ用代替ソース４０４に切り替えるとしてよい。スイッチ４０６は例えば、暗号データ４０２が利用できないまさしくその時に切り替えることができよう。代替として、スイッチ４０６は、暗号データが常に利用できるような定期（または不定期）間隔で暗号データ４０２と暗号４０４との間で切り替えることができよう。代替として、スイッチ４０６は制御可能スイッチまたはマルチプレクサであるとしてよい。スイッチ４０６は代替として、ソース４０２および４０４のどちらか一方または両方からの暗号化データが記憶されるメモリまたはバッファへのレジスタまたは他のポインタとしてインプリメントすることもできよう。ポインタ／レジスタは、どちらか一方のソースからの暗号データ間で選択するために更新することができよう。代替として、スイッチ４０６は、当業者によって理解されるソース４０２および４０４間で選択するためのいずれかの他の装置または機能ブロックとすることができよう。
【００３６】
一部の実施形態において、代替ソース４０４は上述の通りバッファである。場合によっては、モジュール４００は、暗号データの一部をプライマリソースからバッファに向けて送る機能ブロックを含む。機能ブロックは、マルチプレクサ、スイッチ等の形態を取ることができよう。場合によっては、バッファに向けて送られる暗号データの部分は、暗号化または解読に必要とされない過剰な暗号データである。例えば、制御信号は暗号化されないので、従って制御信号を含むデータストリーム４１０の部分は暗号データを必要としない。一般に、制御信号がデータストリーム４１０に現れる時に生成される暗号データは絶対に使用されないので、従ってそれはバッファに転送されるために利用できる。
【００３７】
プライマリソース４０２は代替として、暗号データの部分がバッファに向けて送られている間、加速レートで暗号データを生成することができる。場合によっては、プライマリソース４０２は常にこの加速レートで動作する。常に同じレートで動作することは、バッファが満杯か否かに応じてレートを変えることよりも単純であり、より少ない制御を必要とする。一部の実施形態において、バッファに向けて送られる暗号データの部分は、暗号化または解読されるデータストリーム４１０が制御データを含む時に生成された暗号データである。
【００３８】
やはり、暗号データはＨＤＣＰ暗号データであるとしてよい。
【００３９】
図５に言及すれば、本発明の別の実施形態の例示的な暗号化システム５００は、送信側モジュール５１０および受信側モジュール５２０を含む。送信側モジュール５１０は、暗号化暗号データ用プライマリソース５１２、暗号化暗号データ用代替ソース５１４および、暗号化データ用プライマリソース５１２の出力が利用できない期間中に暗号化データ用代替ソース５１４に切り替え、その期間後にＨＤＣＰ暗号化データ用プライマリソース５１２に戻すためのスイッチ５１６を含む。暗号化暗号データは、暗号化されたデータストリーム５４０を生成するためにデータストリーム５３０を暗号化するために使用される。受信側モジュール５２０は、解読暗号データ用プライマリソース５２２、解読暗号データ用代替ソース５２４および、期間中に解読データ用代替ソース５２４に切り替え、そして期間後に解読データ用プライマリソース５２２に戻すためのスイッチ５２６を含む。解読暗号データは、解読されたデータストリーム５５０を生成するために暗号化されたデータストリーム５４０を解読するためのものである。
【００４０】
一部の実施形態において、送信側モジュール５１０および受信側モジュール５２０の各々のスイッチ５１６、５２６は、鍵再生成期間の初めにそれぞれの代替ソース５１４、５２４に切り替え、鍵再生成期間の終わりにそれぞれのプライマリソース５１２、５２２に戻すように適応されている。
【００４１】
一部の実施形態において、送信側モジュール５１０は暗号化データをデータストリーム５３０と結合するためのＸＯＲゲートをさらに含む。同様に、受信側モジュール５２０の一部の実施形態は、解読データを暗号化されたデータストリーム５４０と結合するためのＸＯＲゲートをさらに含む。
【００４２】
やはり、暗号データはＨＤＣＰ暗号データであるとしてよい。
【００４３】
システム５００はＤｉｓｐｌａｙＰｏｒｔプロトコル用に適応されているとしてよい。そのような場合、送信側モジュール５１０はレーンスキューイング（lane skewing）前のリンク層とＰＨＹ（物理層）との間のインタフェースに配置することができ、受信側モジュール５２０はレーンデスキューイング（lane de-skewing）前のリンク層とＰＨＹとの間のインタフェースに配置することができる。
【００４４】
十分に理解され得るように、本発明の一部の実施形態は、暗号エンジンの出力が利用できない鍵再生成期間中に暗号エンジンの出力の代わりにバッファされ出力され得る過剰な疑似ランダムデータを必要とする。必要とされるバッファリングの量、暗号エンジンがクロックされる必要があるレート、暗号エンジンが前記レートでクロックされる期間および、ソースまたは送信側装置エンジンとシンクまたは受信側装置エンジンとの間の同期メカニズムは、個々の用途に依存し、設計者の裁量である。
【００４５】
ＨＤＣＰ暗号データをＤｉｓｐｌａｙＰｏｒｔにマップするための特定的な解決策をここで図６〜１４に関して説明する。
【００４６】
ＤｉｓｐｌａｙＰｏｒｔは高帯域幅ポイントツーポイントディジタル相互接続解決策であり、それは最終的に、各々が１６２ＭＢ／秒または２７０ＭＢ／秒どちらかのデータを転送することができる現在は１、２または４データレーンをサポートするスケーラブルリンクによって多数のデータフォーマットおよびタイプをサポートすることができる。
【００４７】
ＨＤＣＰの出力暗号は最大３Ｂ／サイクルまでの疑似ランダムデータ生成することができるのに対し、ＤｉｓｐｌａｙＰｏｒｔはアクティブレーンの数に応じて１Ｂ、２Ｂまたは４Ｂ／サイクルいずれかの暗号データを必要とする。１および２レーンの場合、ＨＤＣＰ暗号の単一インスタンス（instance）を使用することができ、４レーンの場合には、ＨＤＣＰ暗号の２インスタンスを使用することができる。もし過剰分をバッファし、かつ鍵再生成がアクティブでない時に出力ストリームの必要性を満たすことの両方に十分なＨＤＣＰ疑似ランダムデータが利用できることを保証するために４レーン構成をオーバークロック（overclock）させたいのであれば、全部の場合に単一エンジンを使用することができるということに留意されたい。
【００４８】
１つ以上の暗号エンジンが送信側装置ロジックと同じレートでクロックされる場合、それは、それぞれ１／２／４レーン構成に必要とされるものよりも（３／１）／（３／２）／（２・３／４）＝３×／１．５×／１．５×多いデータを生成する。生成された過剰なデータの一部または全部は、未定の期間バッファに格納されてから、鍵再生成されている間、暗号が利用できない期間中に出力され得る。結果として得られるインプリメンテーションが図６に示されている。
【００４９】
図６において、ＨＤＣＰモジュール６００は、４レーンのデータ６３０、６４０、６５０および６６０にサービスするために２つのＨＤＣＰ暗号エンジン６１０および６２０を備える。第１の暗号エンジン６１０は、マルチプレクサ６１４に直接２Ｂ／サイクルの暗号データを、そしてＦＩＦＯバッファ６１２に１Ｂ／サイクルを供給する。ＦＩＦＯ６１２の出力もまたマルチプレクサ６１４に供給される。マルチプレクサ６１４はまた、暗号エンジン６１０が鍵再生成モードにあるか否かを指示する信号ＲＥＫＥＹ−ＥＮ６１６を入力として有する。この場合、値０がアクティブモードを表し、値１が鍵再生成モードを表す。従って、マルチプレクサ６１４が０を受け取った時に、暗号データは暗号エンジン６１０からＸＯＲゲート６１８および６１９に向けて送られて、それぞれレーン６３０および６４０からのデータと結合されてそれぞれの暗号化されたデータレーン６３５および６４５を生成する。同じ設定が第２の暗号エンジン６２０について反映される。すなわち、２Ｂ／サイクルの暗号データがマルチプレクサ６２４に直接供給され、そして１Ｂ／サイクルがＦＩＦＯバッファ６２２に供給される。ＦＩＦＯ６２２からの出力もやはりマルチプレクサ６２４に向かう。マルチプレクサ６２４はまた、暗号エンジン６２０が鍵再生成モードにあるか否かを指示する信号ＲＥＫＥＹ＿ＥＮ６２６を入力として有する。マルチプレクサ６２４が０を受け取った時に、暗号データは暗号エンジン６２０からＸＯＲゲート６２８および６２９に向けて送られて、それぞれレーン６５０および６６０からのデータと結合されてそれぞれの暗号化されたデータレーン６５５および６６５を生成する。
【００５０】
暗号がクロックされるレート、およびそれらが加速レートで走行する期間は、鍵再生成期間中にデータストリームを暗号化するためにＦＩＦＯ６１２、６２２に格納された十分な過剰なデータが存在する限り、完全に設計者の裁量である。ＨＤＣＰの場合、毎フレーム方式で１４２サイクル分のデータまたは毎ライン方式で５８サイクル分のデータが利用できなければならず、ここで「フレーム」および「ライン」の概念は用途に適合するように定義することができる。「ライン」および「フレーム」の文字通りの定義はラスター化ビデオデータの場合にあてはまるが、それほど構造化されていないデータパターンの場合、「ライン」は（帰線消去開始“ＢＳ”によって指示される）帰線消去開始制御シンボル間の時間として定義することができるであろうし、そして「フレーム」は５１２ＢＳ制御シンボルごとに生起する連続スクランブラリセット（“ＳＲ”）制御シンボル間の時間として定義することができよう。
【００５１】
それらが同じ過剰データを生成することを保証するソースおよびシンク装置のＨＤＣＰエンジン間の同期は、過剰バイトが識別され格納のためにタグ付けされる単純なアプリオリ定義戦略によって維持され得る。例えば、暗号はデータストリームと同じレートで走行することができる。最初の２５６Ｂの過剰データは、鍵再生成期間の終わりの後に記憶されてから、次の鍵再生成期間までバッファされるとしてよい。バッファは、ソースおよびシンクが各期間に同じＦＩＦＯ状態で始動するのを保証するために各々の鍵再生成期間の終わりにフラッシュされる。
【００５２】
ＨＤＣＰモジュール６００の別の構成が図７に例証されている。図示の通り、ＨＤＣＰモジュール７００はモジュール６００の一半分だけを、すなわちＨＤＣＰ暗号エンジン６１０によってサービスされる半分を表す。この構成では、ＸＯＲゲート６１９への出力を備える付加的なマルチプレクサ６１５が存在する。暗号エンジン６１０は、１Ｂ／サイクルをマルチプレクサ６１４に、１Ｂ／サイクルをマルチプレクサ６１５に、そして１Ｂ／サイクルをＦＩＦＯ６１２に向けて送る。
【００５３】
上述の通り、本発明の実施形態は、ＤｉｓｐｌａｙＰｏｒｔの１、２または４レーン構成に適用することができる。２レーン構成についてのタイミング図が図８に示されている。図８のタイミング図は、以下の１２の信号のタイミングを示している。クロックであるＬＡＮＥ＿ＣＬＫ８１０；ＨＤＣＰエンジンが鍵再生成モードにあるか否かを指示するＲＥＫＥＹ＿ＥＮ８１５；ＨＤＣＰ暗号エンジンからの出力であるＨＤＣＰｏｕｔ［７：０］８２０、ＨＤＣＰｏｕｔ［１５：８］８２５およびＨＤＣＰｏｕｔ［２３：１６］８３０；暗号データを出力するようにＦＩＦＯに合図するＦＩＦＯ＿ＲＥＮ８３５；ＦＩＦＯからの出力であるＦＩＦＯｏｕｔ［７：０］８４０およびＦＩＦＯｏｕｔ［１５：８］８４５；ＦＩＦＯが補充されていることを指示するＦＩＦＯ＿ＷＥＮ８５０；ＦＩＦＯへの入力であるＦＩＦＯｉｎ８５５；２レーンを暗号化または解読するために使用される暗号データを表すＬａｎｅ０Ｍａｓｋ８６０およびＬａｎｅ１Ｍａｓｋ８６５。最初の時間ブロックは通常のＨＤＣＰオペレーション８７０であり、その間にＨＤＣＰ出力８２０および８２５はデータをＬａｎｅ０Ｍａｓｋ８６０およびＬａｎｅ１Ｍａｓｋ８６５に供給する。ＦＩＦＯ出力８４０および８４５はイナクティブである。この例の目的で、ＦＩＦＯはタイミング図の開始時にすでに満杯である。次の時間ブロックはＨＤＣＰキープアウトまたは鍵再生成期間８７５であり、その間にＦＩＦＯ出力８４０および８４５はデータをＬａｎｅ０Ｍａｓｋ８６０およびＬａｎｅ１Ｍａｓｋ８６５に供給する。ＨＤＣＰ出力８２０、８２５および８３０はこの間イナクティブである。ＲＥＫＥＹ−ＥＮ８１５はこの期間中１の値を有し、他の全部の時間には０を有する。次の時間ブロックはＦＩＦＯ再ロード期間８８０であり、その間にＦＩＦＯｉｎ８５５はＦＩＦＯを再ロードするためにＨＤＣＰｏｕｔ［２３：１６］８３０からデータを受け取る。ＦＩＦＯ＿ＷＥＮ８５０はこの期間中１の値を有し、他の全部の時間には０の値を有する。他の全部の信号はあたかもＨＤＣＰ通常オペレーション８７０の間のように動作する。
【００５４】
４レーン構成の場合、タイミング図は第２のＨＤＣＰエンジンについて繰り返される。単レーン構成の場合、Ｌａｎｅ１Ｍａｓｋ８６５が存在せず、それはＦＩＦＯｏｕｔ［１５：８］８４５が使用されないことを意味する。それ以外、タイミングは同じである。
【００５５】
１レーン構成において、１Ｂ／サイクルのＨＤＣＰ暗号データだけが暗号化または解読に要求されるので、従って暗号エンジンは半分のレートで走行することができる。２レーン構成に加えて、１レーン構成を半分のレートで可能にする本発明の実施形態をここで図９に関して説明する。ＨＤＣＰモジュール９００は、マルチプレクサ６１４および６１５とＸＯＲゲート６１８との間の付加的なマルチプレクサ６２０を除いて、図７に関して説明したＨＤＣＰモジュール７００と同じである。マルチプレクサ６２０への入力は、マルチプレクサ６１４および６１５からの出力のほか、ＥＶＥＮ＿ＯＤＤ信号６２２である。マルチプレクサ６１５からの出力はまたＸＯＲゲート６１９にも向かう。単レーンモードにおいて、ＸＯＲゲート６１９が配置されたレーンはイナクティブであり、ＨＤＣＰ暗号エンジン６１０は１／２レートで走行し、ＥＶＥＮ＿ＯＤＤ信号６２２は０と１の間で振動する。振動信号６２２は、マルチプレクサ６１４および６１５の出力の組合せであるマルチプレクサ６２０の出力となる。２レーンモードにおいて、ＨＤＣＰ暗号エンジン６１０はフルレートで走行し、ＥＶＥＮ＿ＯＤＤ信号は０の値を有する。図１０はこの実施形態の単レーンモードのタイミング図であり、そして図１１は２レーンモードのタイミング図である。
【００５６】
図１０のタイミング図は、Ｌａｎｅ１Ｍａｓｋ８６５を除き図８と同じ全部の信号を含む。それは１つの付加的な信号ＥＶＥＮ＿ＯＤＤ１０１０を有し、それは全部の時間ブロックの間、振動する。
【００５７】
図１１は、図１０に関して説明したＥＶＥＮ＿ＯＤＤ信号を含むということ以外、図８と同じである。図１１において、ＥＶＥＮ＿ＯＤＤ信号は０の値を維持し、従ってＨＤＣＰモジュールは図８に関して説明した２レーンモードと同様にして動作する。
【００５８】
代替として、単レーンモードにおいて、ＨＤＣＰエンジンは１／３レートで走行することができよう。この実施形態において、バッファに向けて送られる暗号データは、データストリームが制御信号を含む時に使用されない暗号データでなければならないであろう。
【００５９】
別の代替的な実施形態において、ＨＤＣＰ暗号エンジンは４Ｂ／サイクルで出力するように修正されるとしてよい。これは、１つのＨＤＣＰ暗号エンジンが４レーンのＤｉｓｐｌａｙＰｏｒｔデータにサービスすることを可能にする。バッファはデータストリームが制御データを含む時に使用されていないＨＤＣＰ出力で満たされる。図１２は、この解決策の１実施形態に従ったＨＤＣＰモジュール１２００の概略図である。
【００６０】
ＨＤＣＰモジュール１２００のＨＤＣＰ暗号エンジン１２１０は４Ｂ／サイクルを出力し、１バイトずつ４つのマルチプレクサ１２３０、１２３２、１２３４および１２３６の各々に向かう。各マルチプレクサはまた入力としてそれぞれのＦＩＦＯ１２１１、１２１２、１２１４および１２１６の出力を有する。４つ全部のＦＩＦＯは入力としてＫｃｏｄｅ信号１２２０を有し、それはデータストリーム１２５０、１２６０、１２７０および１２８０が制御信号を含むことを指示する。ＨＤＣＰ暗号エンジン１２１０からの出力は、データストリーム１２５０、１２６０、１２７０および１２８０が制御信号を含む場合、ＦＩＦＯ１２１１、１２１２、１２１４および１２１６に向けて送られる。マルチプレクサ１２３０、１２３２、１２３４および１２３６はすべてＲＥＫＥＹ−ＥＮ信号１２２５を入力として受け取る。ＨＤＣＰ暗号エンジンが鍵再生成モードにあることをこの信号１２２５が指示した場合、それらは各自のＦＩＦＯからの暗号データを各自の出力として使用する。以前の例と同様、マルチプレクサからの出力はＸＯＲゲート１２４０、１２４２、１２４４および１２４６に向けて送られ、そこで暗号データはデータストリーム１２５０、１２６０、１２７０および１２８０と結合されてそれぞれ出力データストリーム１２４５、１２５５、１２６５および１２７５を生成する。
【００６１】
代替として、そしてより一般的に、ＨＤＣＰ暗号エンジン１２１０は、Ｎレーンについて要求されるよりも高いレートでクロックされることができよう。例えば、ＨＤＣＰサイファー１２１０は、各レーンのデータレート、レートＮ／（Ｎ−Ｍ）で暗号データを供給するレートでクロックされることができよう。その場合、暗号データのＮ単位ごとのうちのＭ個が後の使用のためにＦＩＦＯに供給されるとしてよい。
【００６２】
試みることができる代替的な解決策は、要求されるよりも大きなデータレートで走行し、他のエンジンの鍵再生成間隔を隠すために１つのＨＤＣＰエンジンの出力を使用する、複数のＨＤＣＰエンジンを利用することである。１つのエンジンが鍵再生成されている時、すなわちその出力がディスエーブルである時に、他の暗号エンジンがデータストリームを暗号化するために使用されるであろう。この付加的暗号化は、もしそれが使用されるのを待って遊んでいるのであれば付加的なサイファーをイネーブルにするか、またはそのサイファーが現在鍵再生成しているストリームによって要求される付加的な疑似ランダムデータを生成するためにそれをオーバークロックさせるかのどちらかによって、達成することができよう。
【００６３】
この解決策の場合、鍵再生成間隔中の使用のために常に１つの暗号エンジンが利用可能でなければならず、そしてエンジンの鍵再生成は十分にずらされ、全部の暗号エンジンが同時に鍵再生成を要求している期間が決して存在してはならない。また、暗号インスタンスの絶対数または、所与のいずれかの時に要求量の疑似ランダムデータを供給するために任意の数の利用可能なインスタンスをオーバークロックできる能力のどちらかによって、ＨＤＣＰエンジンのプール内に十分な帯域幅が存在しなければならない。
【００６４】
今や十分に理解されるはずであるように、ここで説明した方法はハードウェア、ソフトウェアまたはそれらの組合せにおいて実施することができる。例えば、コンピュータによってインプリメントされた時にそれぞれの方法を実行するコンピュータ可読命令がそれに記憶されているコンピュータ可読媒体。それらはハードウェア、ソフトウェアまたはそれらの組合せを用いて実施することができる。
【００６５】
説明したものは単に本発明の原理の応用を例証するにすぎない。それどころか、他の装置および方法が本発明の範囲を逸脱することなく当業者によって実施することができる。
【特許請求の範囲】
【請求項１】
暗号データのプライマリソースの出力が利用できない期間中に暗号データを供給するための方法であって、
前記期間の初めに前記暗号データのプライマリソースから暗号データの代替ソースに切り替えることと、
前記期間中に前記代替ソースからの暗号データを使用することと、
を含むことを特徴とする方法。
【請求項２】
前記方法は、更に、前記期間の終わりに前記プライマリソースに切り換えることを含む請求項１に記載の方法。
【請求項３】
前記期間は鍵再生成期間である請求項２に記載の方法。
【請求項４】
前記鍵再生成期間は、データの各フレームの後および／またはデータの各ラインの後にある請求項２に記載の方法。
【請求項５】
前記暗号データは、ＨＤＣＰ暗号エンジンによって生成される請求項１の方法。
【請求項６】
前記代替ソースはバッファである、請求項１に記載の方法。
【請求項７】
前記方法は、更に、前記暗号データの一部を前記プライマリソースから前記バッファに向けて送ることを含む請求項６に記載の方法。
【請求項８】
前記方法は、更に、鍵再生成期間の後、所定の期間にわたり過剰な暗号データを前記バッファに向けて送ることを含む請求項６に記載の方法。
【請求項９】
前記過剰な暗号データは、暗号化または解読されるデータストリームよりも高いレートで暗号データを生成することによって生成される請求項８の方法。
【請求項１０】
前記方法は、更に、非ラスター化ビデオデータを暗号化または解読することを含む請求項１に記載の方法。
【請求項１１】
前記方法は、ＤｉｓｐｌａｙＰｏｒｔデータを暗号化または解読することを含む請求項１に記載の方法。
【請求項１２】
前記バッファは、先入れ先出しメモリである請求項６に記載の方法。
【請求項１３】
前記代替ソースは、第２のＨＤＣＰ暗号エンジンによって提供される請求項５に記載の方法。
【請求項１４】
前記暗号データは、疑似ランダムデータである請求項１に記載の方法。
【請求項１５】
コンピュータ読み取り可能媒体であって、前記媒体には、コンピュータが読み取り可能な命令が記憶されており、前記命令が前記コンピュータによって実行されることによって、請求項１の方法が実行されることを特徴とする媒体。
【請求項１６】
暗号化モジュールであって、
データストリームを暗号化または解読するための暗号データのプライマリソースと、
暗号データの代替ソースと、
前記プライマリソースの出力が利用できない期間中に前記暗号データの代替ソースに切り替えるためのスイッチと、
を備えることを特徴とする暗号化モジュール。
【請求項１７】
前記暗号データはＨＤＣＰ暗号データである請求項１６の暗号化モジュール。
【請求項１８】
前記代替ソースはバッファである請求項１６の暗号化モジュール。
【請求項１９】
前記暗号化モジュールは、更に、前記暗号データの一部を前記プライマリソースから前記バッファに向けて送るための手段を含む請求項１８の暗号化モジュール。
【請求項２０】
前記プライマリソースは、前記暗号データの一部が前記バッファに向けて送られている間、加速レートで暗号データを生成するように為されている請求項１９の暗号化モジュール。
【請求項２１】
前記バッファに向けて送られる前記暗号データの一部は、暗号化または解読に必要とされない過剰な暗号データである請求項１９の暗号化モジュール。
【請求項２２】
前記バッファに向けて送られる暗号データの少なくとも一部は、暗号化または解読されるデータストリームが制御データを含む時に生成される暗号データである請求項２１の暗号化モジュール。
【請求項２３】
暗号化システムであって、
送信側モジュールと、
受信側モジュールと、
を備えており、
前記送信側モジュールは、
暗号化暗号データのプライマリソースと、
暗号化暗号データの代替ソースと、
前記暗号化暗号データのプライマリソースの出力が利用できない期間中に前記暗号化暗号データの代替ソースに切り替えて、前記期間の後に前記暗号化暗号データのプライマリソースに切り換えるためのスイッチと、
を備えており、
前記暗号化暗号データは、データストリームを暗号化して、暗号化されたデータストリームを生成するためのものであり、
前記受信側モジュールは、
解読暗号データのプライマリソースと、
解読暗号データの代替ソースと、
前記期間中に前記解読暗号データの代替ソースに切り替えるためのスイッチと、
を備えており、
前記解読暗号データは、前記暗号化されたデータストリームを解読して、解読されたデータストリームを生成するためのものであることを特徴とする暗号化システム。
【請求項２４】
前記送信側モジュールの前記スイッチ及び前記受信側モジュールの前記スイッチは、それぞれ、鍵再生成期間の初めに前記代替ソースに切り替えて、鍵再生成期間の終わりに前記プライマリソースに切り換えるように為されている請求項２３の暗号化システム。
【請求項２５】
前記送信側モジュールは、更に、暗号化データをデータストリームと結合するための排他論理和ゲートを含む請求項２３の暗号化システム。
【請求項２６】
前記受信側モジュールは、更に、解読データを暗号化されたデータストリームと結合するための排他論理和ゲートを含む請求項２３の暗号化システム。
【請求項２７】
前記暗号化データおよび前記解読データはＨＤＣＰデータである請求項２３の暗号化システム。
【請求項１】
暗号データのプライマリソースの出力が利用できない期間中に暗号データを供給するための方法であって、
前記期間の初めに前記暗号データのプライマリソースから暗号データの代替ソースに切り替えることと、
前記期間中に前記代替ソースからの暗号データを使用することと、
を含むことを特徴とする方法。
【請求項２】
前記方法は、更に、前記期間の終わりに前記プライマリソースに切り換えることを含む請求項１に記載の方法。
【請求項３】
前記期間は鍵再生成期間である請求項２に記載の方法。
【請求項４】
前記鍵再生成期間は、データの各フレームの後および／またはデータの各ラインの後にある請求項２に記載の方法。
【請求項５】
前記暗号データは、ＨＤＣＰ暗号エンジンによって生成される請求項１の方法。
【請求項６】
前記代替ソースはバッファである、請求項１に記載の方法。
【請求項７】
前記方法は、更に、前記暗号データの一部を前記プライマリソースから前記バッファに向けて送ることを含む請求項６に記載の方法。
【請求項８】
前記方法は、更に、鍵再生成期間の後、所定の期間にわたり過剰な暗号データを前記バッファに向けて送ることを含む請求項６に記載の方法。
【請求項９】
前記過剰な暗号データは、暗号化または解読されるデータストリームよりも高いレートで暗号データを生成することによって生成される請求項８の方法。
【請求項１０】
前記方法は、更に、非ラスター化ビデオデータを暗号化または解読することを含む請求項１に記載の方法。
【請求項１１】
前記方法は、ＤｉｓｐｌａｙＰｏｒｔデータを暗号化または解読することを含む請求項１に記載の方法。
【請求項１２】
前記バッファは、先入れ先出しメモリである請求項６に記載の方法。
【請求項１３】
前記代替ソースは、第２のＨＤＣＰ暗号エンジンによって提供される請求項５に記載の方法。
【請求項１４】
前記暗号データは、疑似ランダムデータである請求項１に記載の方法。
【請求項１５】
コンピュータ読み取り可能媒体であって、前記媒体には、コンピュータが読み取り可能な命令が記憶されており、前記命令が前記コンピュータによって実行されることによって、請求項１の方法が実行されることを特徴とする媒体。
【請求項１６】
暗号化モジュールであって、
データストリームを暗号化または解読するための暗号データのプライマリソースと、
暗号データの代替ソースと、
前記プライマリソースの出力が利用できない期間中に前記暗号データの代替ソースに切り替えるためのスイッチと、
を備えることを特徴とする暗号化モジュール。
【請求項１７】
前記暗号データはＨＤＣＰ暗号データである請求項１６の暗号化モジュール。
【請求項１８】
前記代替ソースはバッファである請求項１６の暗号化モジュール。
【請求項１９】
前記暗号化モジュールは、更に、前記暗号データの一部を前記プライマリソースから前記バッファに向けて送るための手段を含む請求項１８の暗号化モジュール。
【請求項２０】
前記プライマリソースは、前記暗号データの一部が前記バッファに向けて送られている間、加速レートで暗号データを生成するように為されている請求項１９の暗号化モジュール。
【請求項２１】
前記バッファに向けて送られる前記暗号データの一部は、暗号化または解読に必要とされない過剰な暗号データである請求項１９の暗号化モジュール。
【請求項２２】
前記バッファに向けて送られる暗号データの少なくとも一部は、暗号化または解読されるデータストリームが制御データを含む時に生成される暗号データである請求項２１の暗号化モジュール。
【請求項２３】
暗号化システムであって、
送信側モジュールと、
受信側モジュールと、
を備えており、
前記送信側モジュールは、
暗号化暗号データのプライマリソースと、
暗号化暗号データの代替ソースと、
前記暗号化暗号データのプライマリソースの出力が利用できない期間中に前記暗号化暗号データの代替ソースに切り替えて、前記期間の後に前記暗号化暗号データのプライマリソースに切り換えるためのスイッチと、
を備えており、
前記暗号化暗号データは、データストリームを暗号化して、暗号化されたデータストリームを生成するためのものであり、
前記受信側モジュールは、
解読暗号データのプライマリソースと、
解読暗号データの代替ソースと、
前記期間中に前記解読暗号データの代替ソースに切り替えるためのスイッチと、
を備えており、
前記解読暗号データは、前記暗号化されたデータストリームを解読して、解読されたデータストリームを生成するためのものであることを特徴とする暗号化システム。
【請求項２４】
前記送信側モジュールの前記スイッチ及び前記受信側モジュールの前記スイッチは、それぞれ、鍵再生成期間の初めに前記代替ソースに切り替えて、鍵再生成期間の終わりに前記プライマリソースに切り換えるように為されている請求項２３の暗号化システム。
【請求項２５】
前記送信側モジュールは、更に、暗号化データをデータストリームと結合するための排他論理和ゲートを含む請求項２３の暗号化システム。
【請求項２６】
前記受信側モジュールは、更に、解読データを暗号化されたデータストリームと結合するための排他論理和ゲートを含む請求項２３の暗号化システム。
【請求項２７】
前記暗号化データおよび前記解読データはＨＤＣＰデータである請求項２３の暗号化システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公表番号】特表２０１０−５１９８２１（Ｐ２０１０−５１９８２１Ａ）
【公表日】平成２２年６月３日（２０１０．６．３）
【国際特許分類】
【出願番号】特願２００９−５５０１９２（Ｐ２００９−５５０１９２）
【出願日】平成２０年２月２６日（２００８．２．２６）
【国際出願番号】ＰＣＴ／ＣＡ２００８／０００３７１
【国際公開番号】ＷＯ２００８／１０４０６８
【国際公開日】平成２０年９月４日（２００８．９．４）
【出願人】（５０８３０１０８７）エーティーアイ・テクノロジーズ・ユーエルシー (68)
【氏名又は名称原語表記】ＡＴＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＵＬＣ
【住所又は居所原語表記】Ｏｎｅ Ｃｏｍｍｅｒｃｅ Ｖａｌｌｅｙ Ｄｒｉｖｅ Ｅａｓｔ， Ｍａｒｋｈａｍ， Ｏｎｔａｒｉｏ， Ｌ３Ｔ ７Ｘ６ Ｃａｎａｄａ
【Ｆターム（参考）】
【公表日】平成２２年６月３日（２０１０．６．３）
【国際特許分類】
【出願日】平成２０年２月２６日（２００８．２．２６）
【国際出願番号】ＰＣＴ／ＣＡ２００８／０００３７１
【国際公開番号】ＷＯ２００８／１０４０６８
【国際公開日】平成２０年９月４日（２００８．９．４）
【出願人】（５０８３０１０８７）エーティーアイ・テクノロジーズ・ユーエルシー (68)
【氏名又は名称原語表記】ＡＴＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＵＬＣ
【住所又は居所原語表記】Ｏｎｅ Ｃｏｍｍｅｒｃｅ Ｖａｌｌｅｙ Ｄｒｉｖｅ Ｅａｓｔ， Ｍａｒｋｈａｍ， Ｏｎｔａｒｉｏ， Ｌ３Ｔ ７Ｘ６ Ｃａｎａｄａ
【Ｆターム（参考）】
[ Back to top ]