(57)【要約】【課題】  暗号化データ通信装置１、２で、効果的な暗号化データを通信する。【解決手段】  データ処理手段１３、２２が通信対象となるデータの圧縮ストリームに含まれるヘッダ及びユーザデータの部分に相当する固定長ビットストリームの全部又は一部を暗号化する暗号化方式に対応した処理を実行し、データ通信手段１４、２１が暗号化データを通信する。また、データ処理手段１３、２２は、圧縮ストリームに含まれるアプリケーションデータ部における非暗号化部分に所定のコードを挿入して当該コードを同期コードの全部又は一部として使用する方式に対応した処理を実行する。【選択図】  図１
2006157426.tif 000002
【特許請求の範囲】
【請求項１】
暗号化データを通信する暗号化データ通信装置において、
通信対象となるデータの圧縮ストリームに含まれるヘッダ及びユーザデータの部分に相当する固定長ビットストリームの全部又は一部を暗号化する暗号化方式に対応した処理を実行するデータ処理手段と、
前記データ処理手段により処理される暗号化データを通信するデータ通信手段と、
を備えたことを特徴とする暗号化データ通信装置。
【請求項２】
請求項１に記載の暗号化データ通信装置において、
前記データ処理手段は、前記圧縮ストリームに含まれるアプリケーションデータ部における非暗号化部分に所定のコードを挿入して当該コードを同期コードの全部又は一部として使用する方式に対応した処理を実行する、
ことを特徴とする暗号化データ通信装置。
【請求項３】
請求項２に記載の暗号化データ通信装置において、
前記圧縮ストリームは、ＭＰＥＧ方式によりデータが圧縮されたものであり、
前記データ処理手段は、所定のフレームのＭＢに前記所定のコードを挿入する方式に対応した処理を実行する、
ことを特徴とする暗号化データ通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、暗号化データを送信する送信端末装置や、暗号化データを受信する受信端末装置といった暗号化データ通信装置に関し、特に、効果的な暗号化データを通信する技術に関する。
【背景技術】
【０００２】
ネットワーク伝送技術が進歩したことで、ＷＥＢカメラ等の撮影装置により撮影した映像データを、ネットワークを通してリアルタイムにモニタリングすることが可能となった。その一方で、ネットワーク上を流れるパケットデータを盗み見たり、改竄を行おうとする第三者に対するセキュリティの確保が重要な課題となった。そこで、第三者からの攻撃を回避するための暗号化技術がネットワーク伝送には必須技術となり、現在研究が進められている。
通常、ネットワークを使った伝送では帯域が制限されるため、撮影した映像データをＭＰＥＧ−４やＪＰＥＧ等の圧縮アルゴリズムを使用して圧縮し、この圧縮ストリームをＲＦＣ規格に準拠したＩＰパケットに分割して伝送している。セキュリティを確保する既存技術にはネットワークレイヤでＩＰパケットを暗号化／認証するＩＰｓｅｃやアプリケーションレイヤで認証及びセッションを暗号化するＳＳＬなどがあるが、ＩＰｓｅｃはクライアント側の負荷が重いこと、ＳＳＬはアプリケーションに依存するなどいくつかの課題がある。
【０００３】
特に、Ｗｅｂカメラを使った遠隔監視システムにおいては、システム設定が簡易であり、撮影装置の設置場所の自由度等のように構築／運用が柔軟にできること、ランニングコストが抑えられること、及びアプリケーションに依存することなく高い安全性が確保できることが求められる。このため、Ｗｅｂカメラを使った遠隔監視システムにおいては、第三者による盗み見や改竄といった攻撃に対しセキュリティを確保することが重要な問題となる。例えば、アプリケーションレイヤでコンテンツデータそのものに暗号をかけ、既存のネットワーク機器に影響を与えずにセキュリティを高める製品の開発も進められており、コンテンツそのものに暗号化をかける方法が主流となりつつある。
【０００４】
製品採用されている暗号アルゴリズムには、ＮＩＳＴ（米国標準技術局）の公募により認められた３ＤＥＳ（３  Ｄａｔａ  Ｅｎｃｒｙｐｔｉｏｎ  Ｓｔａｎｄａｒｄ）やＡＥＳ（Ａｄｖａｎｃｅｄ  Ｅｎｃｒｙｐｔｉｏｎ  Ｓｔａｎｄａｒｄ）等のブロック暗号方式や、高速で大容量通信での暗号化処理に適したＭＵＧＩ（Ｍｕｌｔｉ  Ｇｉｇａ  ｃｉｐｈｅｒ）やＭＵＬＴＩ−Ｓ０１等のストリーミング暗号方式がある。
本従来例及び後述する実施例では、一例として、電子政府が推奨しているストリーミング暗号化方式の１つであるＭＵＧＩを例に説明する。
【０００５】
図６には、ＭＵＧＩにおける暗号化処理部の内部機能ブロックの一例を示してある。
ＭＵＧＩの暗号化処理部は、１２８ビットの秘密鍵と１２８ビットの初期ベクタを入力すると一意に決まる乱数列を生成する擬似乱数発生器５１と、擬似乱数発生器５１により生成された乱数列と入力である平文ストリームとを排他的に論理和した暗号化ストリームを出力する演算部５２から構成されている。
秘密鍵と初期ベクタを入力すると擬似乱数発生器５１は内部状態を初期化した後に状態遷移を繰り返しながら乱数列を生成し、この乱数列と入力した平文ストリームとをビット毎に排他的論理和した結果である暗号化ストリームが演算部５２から出力される。
【０００６】
図７には、ＭＵＧＩにおける復号化処理部の内部機能ブロックの一例を示してある。
復号化処理部も、暗号化処理部と同様に、１２８ビットの秘密鍵と１２８ビットの初期ベクタを入力すると一意に決まる乱数列を生成する擬似乱数発生器６１と、擬似乱数生成器６１により生成された乱数列と入力である暗号化ストリームとを排他的に論理和して暗号化前の平文ストリームを出力する演算部６２から構成されている。
つまり、暗号化時と復号時で２回の排他的論理和を実行することで、必ず元の平文ストリームに戻る仕組みになっている。従って、運用にあたっては、送受信端末装置の擬似乱数発生器５１、６１から生成する乱数列が一致（同期）していることが前提となる。
【０００７】
通常、ネットワークを使った伝送では、輻輳等によりＩＰパケットのロスが発生する。このため、本来届くはずのＩＰパケットが失われ、ＭＵＧＩを使ったストリーミング暗号化方式の場合には、送信側の擬似乱数発生器５１と受信側の擬似乱数発生器６１との同期外れが発生する。一度、同期が外れるとそれ以降の暗号ストリームを復号化処理部では正しい平文ストリームに復号できなくなるので、システム運用上問題となる。
【０００８】
このような問題に対応すべく、従来は、定期的に擬似乱数発生器５１、６１の秘密鍵若しくは初期ベクタを更新し或いはリセットし、擬似乱数発生器５１、６１により生成される乱数列を定期的に送受信端末装置で合わせ込んだり、或いはパケットロスの際にロスに相当したダミーデータを復号化処理部にて挿入して乱数列が不一致となることを回避する対策がとられてきた。
例えば、復号するための鍵を所定の送信間隔で送信するといった従来例がある（例えば、特許文献１参照。）。
特に、ＭＰＥＧ−４等のデータストリームを暗号化する場合には、規格上、ストリームシンタックスとして予めユーザが割り当てられているｕｓｅｒ＿ｄａｔａを使って、鍵や初期ベクタを記述して定期的に更新させながら、擬似乱数発生器５１、６１により生成する乱数列を一致させるような方法がとられている。
【０００９】
図８には、ＭＰＥＧ−４のストリームシンタックスを示してある。
ＭＰＥＧ−４ストリームのシンタックスはＩＳＯ／ＩＥＣ１４４９６により規定されている。概略的には、Ｓｔｒｅａｍ＿Ｈｅａｄｅｒ部と、Ａｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部に分類することができる。
Ｓｔｒｅａｍ＿Ｈｅａｄｅｒ部はコーデックに依存したヘッダ部分であり、主にストリーム構成に関する情報が記述されており、Ａｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部の中に出現することが禁止されたビットパターンで構成された４つのユニークヘッダ、すなわち、ＶＳ（ｖｉｓｕａｌ＿ｏｂｊｅｃｔ＿ｓｅｑｕｅｎｃｅ＿ｓｔａｒｔ＿ｃｏｄｅ）ヘッダ、ＶＯ（ｖｉｓｕａｌ＿ｏｂｊｅｃｔ＿ｓｔａｒｔ＿ｃｏｄｅ）ヘッダ、ＶＯＨ（ｖｉｄｅｏ＿ｏｂｊｅｃｔ＿ｓｔａｒｔ＿ｃｏｄｅ）ヘッダ、ＶＯＬ（ｖｉｄｅｏ＿ｏｂｊｅｃｔ＿ｌａｙｅｒ＿ｓｔａｒｔ＿ｃｏｄｅ）ヘッダと、スタートコードやマーカビットといったストリームの情報（Ｓｔｅａｍ  ｉｎｆｏ）が含まれる。
【００１０】
Ａｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部はＧＯＶ（ｇｒｏｕｐ＿ｖｏｐ＿ｓｔａｒｔ＿ｃｏｄｅｓ）ヘッダから始まり、アプリケーションに合わせてユーザが使用することのできるｕｓｅｒ＿ｄａｔａ領域の後に、ユニークなＶＯＰ（ｖｏｐ＿ｓｔａｒｔ＿ｃｏｄｅ）ヘッダとフレームに相当するＭＢ（Ｍａｃｒｏ＿Ｂｌｏｃｋ）データとが交互に続いた構成となっている。ＶＯＰとＭＢとの組からフレーム（ｆｒａｍｅ）が構成され、最初のフレームではＭＢ（Ｉ−ＶＯＰ）が用いられる。
なお、前記したユニークなＶＯＰヘッダについては、ＭＰＥＧの規格により、当該ヘッダとして決められている値が、マクロブロック（ＭＢ）等のデータ部分に出現しないように保証されている。但し、マクロブロック（ＭＢ）等を暗号化すると、偶然に、ユニークなヘッダ値と同じ値が生成されてしまう可能性はある。
【００１１】
ここで、Ａｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部の後に再びＳｔｒｅａｍ＿Ｈｅａｄｅｒ部が出現するリフレッシュタイミングは、規格で決められてはおらず、圧縮する画像のサイズとビットレートの設定によりその周期は毎回変動する。
このため、受信側の復号化処理部では、暗号化ストリームのいずれのビット列が鍵或いは初期ベクタに相当するのかを識別することが非常に困難である。そこで、従来の暗号化技術では、コーデックに依存したＳｔｒｅａｍ＿Ｈｅａｄｅｒ部を暗号化ストリーム上で同期マーカとして使うために暗号化せず、ＭＰＥＧ−４ストリームのＡｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部のＭＢだけに暗号をかけている。
このように、従来では、受信側で受信した暗号化ストリームの同期検出の問題から、ＭＰＥＧ−４等の圧縮ストリームに暗号をかける場合には、ストリームの情報を記述したＳｔｒｅａｍ＿Ｈｅａｄｅｒ部は暗号化していない。
【００１２】
【特許文献１】特開２００３−１７４４４１号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
上記のように、従来の暗号化の方法では、圧縮ストリーム情報を記述したＳｔｒｅａｍ＿Ｈｅａｄｅｒ部が暗号化されないため、例えば、定期的にやり取りされるパケットを収集することで、第三者により、アプリケーションデータの種類及び付加した初期ベクタを含むストリームの情報が推測され、秘匿性の低下につながる可能性があった。
また、暗号化したＭＢの部分に、同期マーカとして使用するＳｔｒｅａｍ＿Ｈｅａｄｅｒ部のユニークコードが偶然に出現してしまう可能性があり、Ｓｔｒｅａｍ＿Ｈｅａｄｅｒ部のユニークコードを同期マーカとする従来の方法では、誤認識を回避するための処理が必要となり回路規模が大きくなっていた。
【００１４】
具体的には、同期マーカの誤認識を回避する処理を行うために、例えば、メモリを用意してデータの比較を行う等のための回路規模が大きくなる。一例として、誤認識を回避するためには、同期マーカの前後のデータについても認識するようにして何らかの判定を行い、本来の同期マーカであるか或いは偶然出現した同期マーカと同じ値であるかを区別することができるようにする。
なお、暗号化する前のマクロブロック（ＭＢ）には、ユニークコードと同じ値は出現しないように規格により保証されているが、そのマクロブロック（ＭＢ）を暗号化した場合には、暗号化した結果、規格外の値、すなわち、ユニークコードが出現する可能性がある。
【００１５】
また、ＭＰＥＧストリームのフレームに相当するＭＢのデータ量は入力画像に依存して増減するため、例えば、データ量の大きいＭＢが続くような場合には、暗号化処理の負荷が大きくなり装置全体のパフォーマンスの低下につながってしまった。特に、メガピクセルに対応したストリームデータを暗号化／復号処理するような場合には、処理負荷の変動がパフォーマンスの低下につながる問題が大きかった。
このように、従来の暗号化の方法では、主に、３つの課題があった。
【００１６】
本発明は、このような従来の課題を解決するために為されたもので、効果的な暗号化データを通信することができる暗号化データ通信装置を提供することを目的とする。
具体的には、本発明では、例えば、秘匿性を向上させることや、回路規模を小さくすることや、装置のパフォーマンスを向上させることが可能な、暗号化データを送信する送信端末装置や、暗号化データを受信する受信端末装置を提供することを目的とする。
【課題を解決するための手段】
【００１７】
上記目的を達成するため、本発明に係る暗号化データ通信装置では、次のような構成により、暗号化データを通信する。
すなわち、データ処理手段が、通信対象となるデータの圧縮ストリームに含まれるヘッダ（Ｈｅａｄｅｒ）及びユーザデータ（ｕｓｅｒ＿ｄａｔａ）の部分に相当する固定長ビットストリームの全部又は一部を暗号化する暗号化方式に対応した処理を実行する。データ通信手段が、前記データ処理手段により処理される暗号化データを通信する。
【００１８】
例えば、送信端末装置では、通信対象となるデータを圧縮して圧縮ストリームを取得する圧縮処理手段と、前記取得された圧縮ストリームに含まれるヘッダ及びユーザデータの部分に相当する固定長ビットストリームの全部又は一部を暗号化する暗号化処理手段（データ処理手段）と、当該暗号化されたデータ（暗号化データ）を送信する送信手段（データ通信手段）を備える。
また、受信端末装置では、暗号化データを受信する受信手段（データ通信手段）と、当該受信された暗号化データにおける暗号化部分を復号する復号処理手段（データ処理手段）と、当該復号により取得された圧縮ストリームを伸張する伸張処理手段を備える。
【００１９】
従って、例えば、圧縮ストリームに含まれるヘッダが暗号化されることによりデータの秘匿性を向上させることができ、また、暗号化される対象となる部分が固定長であるため暗号化対象となるデータ量の変動を抑えることができることから装置のパフォーマンスを向上させることができ、これらにより、効果的な暗号化データを通信することができる。
ここで、通信対象となるデータとしては、例えば、テキストデータや、映像（画像）データや、音声データなど、種々なものが用いられてもよい。
また、圧縮方式としては、種々な方式が用いられてもよい。
また、暗号化の手法としては、種々な手法が用いられてもよい。
また、圧縮ストリームに含まれるヘッダ及びユーザデータの部分に相当する固定長ビットストリームの全部が暗号化されてもよく、或いは、一部が暗号化されてもよい。なお、他の部分については、暗号化されない。
【００２０】
本発明に係る暗号化データ通信装置では、一構成例として、次のような構成とした。
すなわち、前記データ処理手段は、前記圧縮ストリームに含まれるアプリケーションデータ（Ａｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ）部における非暗号化部分に所定のコードを挿入して当該コードを同期コード（同期マーカ）の全部又は一部として使用する方式に対応した処理を実行する。
【００２１】
例えば、送信端末装置では、前記暗号化処理手段（前記データ処理手段）が、前記圧縮ストリームに含まれるアプリケーションデータ部における非暗号化部分に、所定のコードを挿入する。
また、受信端末装置では、前記復号処理手段（前記データ処理手段）が、当該コードのみ或いは当該コードと他のデータ部分との組を同期コードとして使用して、暗号化データにおける暗号化部分を復号し、また、当該コードを削除する。
【００２２】
従って、例えば、所定のコードが挿入されて同期コードとして使用されることにより同期コードの誤認識回避のための回路を省いて回路規模を小さくすることが可能であり、また、非暗号化部分に所定のコードが挿入されることによりデータの秘匿性を向上させることができ、これらにより、効果的な暗号化データを通信することができる。
ここで、所定のコードとしては、種々なコードが用いられてもよい。
また、所定のコードから同期コードの全部が構成されてもよく、或いは、所定のコードから同期コードの一部が構成されてもよい。
また、所定のコードが挿入される位置としては、種々な位置が用いられてもよい。
【００２３】
本発明に係る暗号化データ通信装置では、一構成例として、次のような構成とした。
すなわち、前記圧縮ストリームは、ＭＰＥＧ方式によりデータが圧縮されたものである。
また、前記データ処理手段は、所定のフレームのＭＢに前記所定のコードを挿入する方式に対応した処理を実行する。
例えば、送信端末装置では、前記暗号化処理手段（前記データ処理手段）が、ＭＰＥＧ方式による圧縮ストリームを暗号化するに際して、所定のフレームのＭＢに前記所定のコードを挿入する。
従って、ＭＰＥＧ方式による圧縮ストリームを通信するに際して、効果的な暗号化データを通信することができる。
ここで、所定のフレームとしては、種々なものが用いられてもよい。
【００２４】
本発明は、以上のような各種の処理を行う方法や、プログラムや、プログラムを記憶した記録媒体として提供することも可能である。
例えば、本発明に係る装置を構成するコンピュータに実行させるプログラムであって、以上のような各種の処理を行う機能を当該コンピュータにより実現することを特徴とするプログラムを提供することが可能である。
また、本発明に係る装置を構成するコンピュータに実行させるプログラムを当該コンピュータの入力手段により読み取り可能に記憶した記録媒体であって、当該プログラムは以上のような各種の処理を当該コンピュータに実行させることを特徴とする記録媒体を提供することが可能である。
【発明の効果】
【００２５】
以上説明したように、本発明に係る暗号化データ通信装置によると、通信対象となるデータの圧縮ストリームに含まれるヘッダ（Ｈｅａｄｅｒ）及びユーザデータ（ｕｓｅｒ＿ｄａｔａ）の部分に相当する固定長ビットストリームの全部又は一部を暗号化するようにしたため、効果的な暗号化を実現することができる。
また、本発明に係る暗号化データ通信装置によると、前記圧縮ストリームに含まれるアプリケーションデータ（Ａｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ）部における非暗号化部分に所定のコードを挿入して、当該コードを同期コード（同期マーカ）の全部又は一部として使用するようにしたため、効果的な暗号化データ通信を実現することができる。
【発明を実施するための最良の形態】
【００２６】
本発明に係る一実施例を図面を参照して説明する。
図１には、本発明の一実施例に係る暗号化データ通信システムの構成例を示してある。
本例の暗号化データ通信システムは、送信端末装置１と受信端末装置２とをネットワーク３を介して接続して構成されている。
送信端末装置１は、その内部機能ブロックとして、入力部１１と、圧縮部１２と、暗号化処理部１３と、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）インターフェイス部１４を備えている。
受信端末装置２は、その内部機能ブロックとして、ＬＡＮインターフェイス部２１と、復号化処理部２２と、伸張部２３と、出力部２４を備えている。
【００２７】
送信端末装置１により行われる概略的な動作の一例を示す。
入力部１は、例えばカメラなど（図示せず）から入力されるアナログ映像の信号をデジタル映像の信号へ変換して圧縮部１２へ出力する。
圧縮部１２は、ＪＰＥＧ或いはＭＰＥＧ等の圧縮アルゴリズムを使用して、入力部１１から入力されるデジタル映像信号の映像を圧縮し、当該圧縮により得られる圧縮ストリームを暗号化処理部１３へ出力する。
暗号化処理部１３は、圧縮部１２から入力される圧縮ストリームに対して所定の暗号化処理を行って、当該圧縮ストリームを暗号化ストリームへ変換してＬＡＮインターフェイス部１４へ出力する。
ＬＡＮインターフェイス部１４は、暗号化処理部１３から入力される暗号化ストリームをパケットに分割して、例えばＲＦＣ規格に準拠したパケットヘッダを付加した後に、ＩＰパケットとしてネットワーク３へ送出する。
ネットワーク３は、送信端末装置１から出力されるＩＰパケットを受信端末装置２へ伝送する。
【００２８】
受信端末装置２により行われる概略的な動作の一例を示す。
ＬＡＮインターフェイス部２１は、ネットワーク３を経由して受け取ったＩＰパケットについて、当該ＩＰパケットのヘッダ部とペイロード部を分離し、分離したペイロード部を連結した暗号化ストリームに戻して復号化処理部２２へ出力する。
復号化処理部２２は、ＬＡＮインターフェイス部２１から入力される暗号化ストリームに対して復号処理を行って、当該暗号化ストリームを平文の圧縮ストリームへ変換して伸張部２３へ出力する。
伸張部２３は、復号化処理部２２から入力される圧縮ストリームに対して伸張処理を行って、当該圧縮ストリームを非圧縮デジタル信号へ伸張して出力部２４へ出力する。
出力部２４は、伸張部２３から入力される非圧縮デジタル信号を再生機（図示せず）に合わせたフォーマットに変換して再生機へ出力する。
なお、送信側の圧縮部１２で行われる圧縮処理の方式と受信側の伸張部２３で行われる伸張処理の方式とは対応しており、送信側の暗号化処理部１３で行われる暗号化処理の方式と受信側の復号化処理部２２で行われる復号処理の方式とは対応している。
【００２９】
次に、送信側の暗号化処理部１３により行われる動作及び受信側の復号化処理部２２により行われる動作について詳しく説明する。
本例では、送信側の圧縮部１２で用いる圧縮アルゴリズムはＭＰＥＧ−４であるとし、送信側の暗号化処理部１３及び受信側の復号化処理部２２で用いる暗号化アルゴリズムはＭＵＧＩであるとして、説明する。
なお、本例では、映像を扱う場合を示すが、処理対象としては映像に限定されず、例えば、ユニークなストリームヘッダを有する種々なアプリケーションの全てに対応することが可能である。
【００３０】
図２には、本例の送信側の暗号化処理部１３の内部機能ブロックの一例を示してある。
本例の暗号化処理部１３は、擬似乱数発生器３１と、演算部３２と、ヘッダ検出部３３と、冗長コード挿入部３４を備えている。
図３には、本例の受信側の復号化処理部２２の内部機能ブロックの一例を示してある。
本例の復号化処理部２２は、擬似乱数発生器４１と、演算部４２と、冗長コード検出部４３と、冗長コード削除部４４を備えている。
【００３１】
図４には、ＭＰＥＧ−４の圧縮ストリームのシンタックスと、本例において暗号化する部分を示してある。この圧縮ストリームは、圧縮部１２から出力される信号に相当し、暗号化処理部１３で暗号化される。
本例では、固定長であるストリームヘッダ部（Ｓｔｒｅａｍ＿Ｈｅａｄｅｒ部）の全て、及び可変長であるアプリケーションデータ部（Ａｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部）のＧＯＶからユーザデータ（ｕｓｅｒ＿ｄａｔａ）までのビット列を暗号化し、当該ｕｓｅｒ＿ｄａｔａの直後のＶＯＰヘッダから次にＶＳヘッダが現れるリフレッシュタイミングまでのＡｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部については暗号化処理を施さない。
【００３２】
ここで、他の構成例として、暗号化強度を高めるために、Ａｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部に含まれるユニークコードであるＶＯＰヘッダを暗号化することも可能である。なお、各マクロブロック（ＭＢ）のサイズは固定ではないため、ＶＯＰヘッダを暗号化する場合には、各ＭＢの領域を把握するために、各ＭＢのデータサイズなどの情報をストリームに付加する処理を行う。
【００３３】
本例では、Ａｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部の一部は暗号化しない（非暗号化とする）が、Ａｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部そのものが圧縮ストリームであるため、ネットワーク上で仮にストリームが盗み見られたとしても、再生に圧縮アルゴリズムに対応した伸張処理が必要になること、また、ストリームの改竄が行われたとしてもＭＰＥＧ−４特有のフレーム相関により正しく表示される可能性が低いことから、この非暗号化が暗号化強度の劣化にはつながらない。
なお、再生に圧縮アルゴリズムに対応した伸張処理が必要になるとは、単にＭＰＥＧ−４のデコーダがあっても伸張はできず、Ｓｔｒｅａｍ＿Ｈｅａｄｅｒ部の情報が伸張には必要であるということである。本例では、マクロブロック（ＭＢ）を非暗号化データとする代わりに、その伸張に必要なＳｔｒｅａｍ＿Ｈｅａｄｅｒ部を暗号化しているため、暗号化強度の劣化には繋がらない。
【００３４】
ここで、Ｓｔｒｅａｍ＿Ｈｅａｄｅｒ部のどのような情報が伸張に必要な情報であるかの具体例を示す。なお、必ずしも本具体例に限定されなくともよい。
例えば、ＶＳヘッダ、ＶＯヘッダ、ＶＯＨヘッダ、ＶＯＬヘッダは４バイトのユニークコードであり、伸張時にストリームの先頭を識別するための同期マーカとして必要となる。また、例えば、ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ＿ｒｅｓｏｌｕｔｉｏｎの情報は、１６ビットの情報で、１モジュロ・タイムベースを等間隔に分割するサブインターバルの数を示しており、この情報がないと正常にフレームを再生表示することができない。
【００３５】
また、本例では、受信側で暗号化したビット列を特定するために、暗号化処理をしないＡｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部の所定の位置に、規格上においてＡｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部では出現が禁止されているユニークコードを送信側で挿入して同期マーカとする。受信側では、この同期マーカに基づいて、暗号化部分のビット列を特定して、復号処理を行う。同期マーカとして用いる値は、例えば、エンコーダ側（送信側）と共に予めデコーダ側（受信側）にも設定しておく。また、例えば、「同期マーカ（本例では、ＶＯＰ＋ＶＳ）から１０２バイト前までの期間が暗号化部分のビット列である」などのように、同期マーカに基づいて暗号化部分のビット列の位置を特定することが可能な情報を予めデコーダ側に設定しておく。
【００３６】
図５には、暗号化ストリームにユニークな冗長コードを挿入する位置のフォーマットの一例を示してある。
本例では、Ａｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部のｕｓｅｒ＿ｄａｔａに続くＶＯＰヘッダの直後に、ＶＳヘッダのビット列と一致するユニークな４バイトのビット列（以下で、ＶＳヘッダと言う）を挿入する。この場合、４バイトのＶＯＰヘッダと４バイトのＶＳヘッダとが連続するため、８バイトが同期マーカに割り当てられる。
更に、規格上、ｕｓｅｒ＿ｄａｔａに続くＶＯＰヘッダの直後にはイントラ符号化されたＭＢ（Ｉ−ＶＯＰ）がくることになっているため、ユニークな冗長コードをＩ−ＶＯＰに挿入することで、それ以降に続くＭＢは冗長コードを含んだＩ−ＶＯＰを参照することなる。つまり、仮に、ＶＯＰヘッダからストリーム構造が推測できたとしても、参照フレームに冗長コードを挿入するため、このままではフレーム相関をとっている以降のフレームは正しく再生できない。ここで、イントラ符号化では、一般に、他のピクチャの情報を使用せずに、それ自身のピクチャの情報のみで符号化が行われる。
【００３７】
なお、本例では、４バイトのＶＯＰヘッダの直後にＶＳヘッダに一致するユニークな４バイトを挿入して８バイトが同期マーカとして割り当てられる場合を示すが、ユニークな情報を挿入する位置は他の位置であってもよい。また、ユニークな情報のビット数（バイト数）は、４バイトに限らず、種々な情報量であってもよい。
また、本例では、ユニークな情報としてＶＳヘッダに一致する情報を用いるが、他の構成例として、ＶＯヘッダや、ＶＯＨヘッダや、ＶＯＬヘッダや、ＧＯＶヘッダや、ＶＯＰヘッダなどのように、他のユニークコードに一致する情報を用いることも可能である。
【００３８】
ここで、本例では、暗号化をかけた位置を特定するために、同期マーカとして、ユニークなコードをＭＢに入れていることから、ＭＢに余計なデータを入れる結果として、第三者は映像を正しく再生できないという効果も得られる。
なお、一般に、Ｉ−ＶＯＰのＶＯＰヘッダとＰ−ＶＯＰのＶＯＰヘッダとは互いに異なる値であり、Ｐ−ＶＯＰのＶＯＰヘッダは共通である。このため、一連のＡｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部に１個のＩ−ＶＯＰのみが含まれる場合には当該Ｉ−ＶＯＰのＶＯＰヘッダを同期マーカとして使用することが可能であるが、一般には、２個以上のＩ−ＶＯＰがＡｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部に含まれ得る。Ｐ−ＶＯＰは、一般に、過去のピクチャを参照して予測符号化されたものである。また、過去と将来のピクチャを参照して双方向予測符号化されるＢ−ＶＯＰも考えられる。
【００３９】
図２に示される暗号化処理部１３により行われる動作の一例を示す。
暗号化処理部１３への入力は、図４に示されるような圧縮ストリームであり暗号化前のものである。
ヘッダ検出部３３は、圧縮ストリームを入力して、当該圧縮ストリームに含まれるユニークコードを検出し、これに基づいて、暗号化するビット列として、Ｓｔｒｅａｍ＿Ｈｅａｄｅｒ部及びＡｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部におけるＵｓｅｒ＿Ｄａｔａ部分までを抽出する。
ヘッダ検出部３３は、例えば、ＭＰＥＧ−４規格上、４バイトのユニークコードであるＶＳヘッダ（００  ００  ０１  Ｂ０ｈ）を見つけたら、このＶＳヘッダからＡｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部のＵｓｅｒ＿Ｄａｔａ部の末尾までの１０２バイト（Ｂｙｔｅｓ）に相当する期間は信号レベルをハイ（Ｈｉｇｈ）にする一方でそれ以外の期間は信号レベルをロウ（Ｌｏｗ）にする識別情報を出力する。なお、この１０２バイトというビット数（バイト数）は、一例であり、他の値が用いられてもよい。一般に、ＶＳヘッダからＧＯＶヘッダまでは規格で定まっているが、ｕｓｅｒ＿ｄａｔａ領域のビット数（バイト数）は種々である。
また、他の例として、ＶＯＨヘッダ（００  ００  ０１  ０１ｈ）を見つけた場合には、このＶＯＨヘッダからＡｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部のＵｓｅｒ＿Ｄａｔａ部の末尾までの９２バイト（Ｂｙｔｅｓ）に相当する期間の信号レベルをハイにする一方でそれ以外の期間は信号レベルをロウにする識別情報を出力するようにしてもよい。
【００４０】
擬似乱数発生器３１は、秘密鍵と初期ベクタを入力して、乱数列を生成して演算部３２へ出力する。
演算部３２は、ヘッダ検出部３３から出力される識別情報に従って信号レベルがハイ（Ｈｉｇｈ）である期間に、擬似乱数発生器３１により生成された乱数列と入力される圧縮ストリームとの排他的論理和を実行するように制御を行って、当該圧縮ストリームに対して部分的に暗号化処理を施し、これにより得られた暗号化ストリームを冗長コード挿入部３４へ出力する。
冗長コード挿入部３４は、ヘッダ検出部３３から出力される識別情報の信号レベルがハイ（Ｈｉｇｈ）からロウ（Ｌｏｗ）へ切り替わって、予め設定した所定時間（本例では、ＶＯＰヘッダに相当する時間）が経過したら、演算部３２から入力される暗号化ストリームにユニークな冗長コード（本例では、ＶＳヘッダに一致するもの）を強制的に数バイト挿入し、これにより得られる図５に示されるような暗号化ストリームを後段のＬＡＮインターフェイス部１４へ送る。
【００４１】
図３に示される復号化処理部２２により行われる動作の一例を示す。
復号化処理部２２への入力は、前段のＬＡＮインターフェイス部２１においてＩＰパケットからペイロード部のみを抽出して連結しなおした暗号化ストリームである。
冗長コード検出部４３は、入力される暗号化ストリームをスキャンして、送信端末装置１で強制的に挿入されたユニークな冗長コード（本例では、ＶＳヘッダに一致するもの）を検出し、当該検出結果の情報（検出情報）を出力する。本例では、送信端末装置１で本来禁止されているユニークな冗長コードをＡｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部に挿入しているため、受信端末装置２では誤検出することなく挿入された冗長コードを検出することができ、冗長コードから所定バイト離れた位置の暗号化ビット列を特定することが可能である。なお、本例では、このユニークな４バイトの冗長コードを検出するに際して、その直前に配置されたＶＯＰヘッダも合わせて８バイト分のビット列を検査する。
【００４２】
擬似乱数発生器４１は、秘密鍵と初期ベクタを入力して、乱数列を生成して演算部４２へ出力する。
演算部４２は、冗長コード検出部４３から出力される検出情報に基づいて、擬似乱数発生器４１により生成された乱数列と暗号化ストリームに含まれる暗号化ビット列との排他的論理和を行って、これにより平文に戻した圧縮ストリームを冗長コード削除部４４へ出力する。
冗長コード削除部４４は、冗長コード検出部４３から出力される検出情報に基づいて、演算部４２から入力される圧縮ストリームから、送信端末装置１で挿入された冗長コードを削除し、これにより得られた圧縮ストリームを伸張部２３へ出力する。
【００４３】
以上のように、本例の暗号化データ通信システムでは、ネットワーク３を使ってコンテンツデータを暗号化して伝送する際に、コンテンツデータの圧縮ストリームに含まれるヘッダ及び所定のユーザデータに相当する固定長データビットストリームに暗号をかけることが行われる。
また、本例の暗号化データ通信システムでは、ネットワーク３を使ってコンテンツデータを暗号化して伝送する際に、コンテンツデータの圧縮ストリームに含まれるアプリケーションデータにユニークな冗長コードを埋め込むことが行われる。また、特に、コンテンツデータがＭＰＥＧデータである場合には、ユニークな冗長コードをＩ−ＶＯＰのＭＢに挿入して、秘匿性を高めることが行われる。
【００４４】
具体的には、本例の暗号化データ通信システムでは、コンテンツデータの圧縮ストリームを暗号化するに際して、次のような処理を行う。
すなわち、送信側の暗号化処理部１３では、Ｓｔｒｅａｍ＿Ｈｅａｄｅｒ部とそれに続くｕｓｅｒ＿ｄａｔａまでの固定長のデータビット列のみを暗号化し、Ａｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部におけるそれ以降の部分は暗号化せずにそのまま伝送する。また、Ａｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部における暗号化しない部分の所定の位置に、暗号化したデータビット列の領域を識別するためのユニークな冗長コードを埋め込み、これを同期マーカ（本例では、同期マーカの一部）として使用する。
また、受信側の復号化処理部２２では、暗号化処理部１３で埋め込まれた同期マーカをもとに、受信した暗号化ストリームのＳｔｒｅａｍ＿Ｈｅａｄｅｒ部とそれに続くｕｓｅｒ＿ｄａｔａまでの固定長データビット列の位置を検知して、復号処理を行う。また、同時に、暗号化処理部１３で挿入された冗長コードを削除する。
【００４５】
従って、本例の暗号化データ通信システムでは、暗号化ストリームの秘匿性の低下を抑えることや、回路規模を小さく抑えることや、入力画像に依存していた暗号化処理負荷やその変動を軽減してパフォーマンスの低下を抑えることを実現することができ、効率の良い暗号化処理及び復号処理を実現することができる。また、例えば、メガピクセルに対応したデータストリームの暗号化処理及び復号処理に対応することもできる。
【００４６】
具体的には、本例の暗号化データ通信システムでは、ストリームの情報を記述したＳｔｒｅａｍ＿Ｈｅａｄｅｒ部を暗号化するため、第三者により、定期的にやり取りされるパケットが収集されたとしても、付加された初期ベクタを推測することは困難であり、秘匿性の強化につながる。
【００４７】
また、本例の暗号化データ通信システムでは、規格でＡｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部での出現が禁止されているユニークな冗長コードを暗号化ストリームの同期マーカに使うことから、受信端末装置２で同期マーカを誤認識することを防ぐことができ、このため、従来必要であった同期マーカの誤認識回避用処理が不要となり、回路規模を小さくすることができる。
なお、暗号化したＳｔｒｅａｍ＿Ｈｅａｄｅｒ部に同期マーカとして使うユニークな冗長コードに一致するビット列が出現する可能性はあるが、この条件としてはＳｔｒｅａｍ＿Ｈｅａｄｅｒ部のユニークコード（４バイト）と“０”が３２ビット（ユニークコード４バイト相当）連続する乱数列との排他的論理和をとるときであり、確率としては｛１／（２の３２乗）｝である。また、同期コード全体の８バイトだと、更に確率は小さくなる。
【００４８】
また、ＭＢに挿入する同期マーカを構成するユニークコードをより長い値とすれば、対応するユニークコードが暗号化したヘッダ部に出現する可能性は低くなる。なお、従来におけるＭＢを暗号化をする方式では、いずれかのユニークヘッダを同期マーカとしていたため、同期マーカのデータ長を長くすることができなかった。
また、通常、ＭＢ（従来における暗号化部分）のデータ長と比べて、ヘッダ及び所定のユーザデータ（本例における暗号化部分）のデータ長の方が短いため、ユニークコードに一致するビット列が偶然に出現する確率は低くなる。
なお、本例では、ＶＯＰヘッダと挿入したコード（本例では、ＶＳヘッダに一致するコード）とを合わせたものを同期マーカとしたが、例えば、挿入したコードのみを同期マーカとして使用することも可能である。
【００４９】
また、本例の暗号化データ通信システムでは、暗号化するビット列のサイズを常に固定にすることができ、ストリームのリフレッシュタイミングに合わせた周期的処理となるため、暗号化処理による負荷を軽減することができ、入力画像に影響を受けていた暗号化処理の負荷変動を抑えて、パフォーマンスの低下を回避することができる。
また、固定長のストリーム（本例では、Ｓｔｒｅａｍ＿Ｈｅａｄｅｒ部やｕｓｅｒ＿ｄａｔａ領域）を暗号化するため、例えば、メガピクセルに対応した撮像装置であっても、暗号化処理及び復号処理の処理量を従来と同等程度に抑えることが可能である。つまり、メガピクセルの画像ではＭＢのデータ量が大きくなるが、ＭＢの暗号化をする場合には処理負荷が大きくなる一方、本例では、ＭＢを暗号化せず、その代わりにＳｔｒｅａｍ＿Ｈｅａｄｅｒ部やｕｓｅｒ＿ｄａｔａ領域を暗号化する構成であるため、暗号化の処理量を抑えることができる。
【００５０】
また、処理が重くストリーミングに適さないとされてきたブロック暗号方式についても、同様に対応することができる。
また、本例では、ＭＰＥＧ−４に適用した場合を示したが、これに限らず、ＭＰＥＧ−２やＪＰＥＧ等のように、他の画像圧縮方式に適用することも可能であり、また、映像（画像）に限らず、音声等に適用することも可能である。
【００５１】
また、本例では、送信側の暗号化処理部１３において、圧縮ストリームに含まれるＶＳヘッダを検出してから１０２バイト分を暗号化する構成とし、つまり、Ｓｔｒｅａｍ＿Ｈｅａｄｅｒ部の全てとＡｐｐｌｉｃａｔｉｏｎ＿Ｄａｔａ部の最初からｕｓｅｒ＿ｄａｔａまでの全てを暗号化する構成としたが、本例で暗号化することとしたビット列の中に暗号化を除外する部分を設けることも可能である。つまり、Ｓｔｒｅａｍ＿Ｈｅａｄｅｒ部からｕｓｅｒ＿ｄａｔａ部分までの全てを暗号化するのではなく、例えば、ｕｓｅｒ＿ｄａｔａ領域など、一部の領域については暗号化を行わない構成とすることも可能である。例えば、ＶＳヘッダを検出してから最初の３０バイト分の後における５バイト分は暗号化しないでその後の４０バイトは暗号化するといった構成や、或いは、いずれかの所定の３バイト分は暗号化しないといった構成などを用いることも可能である。
【００５２】
また、本例では、Ｉ−ＶＯＰのＭＢにユニークコードを挿入したが、ユニークコードを挿入するＶＯＰは、Ｉ−ＶＯＰに限られず、Ｐ−ＶＯＰであってもよい。但し、Ｐ−ＶＯＰにユニークコードを挿入する場合には、例えば「同期マーカ（本例では、ＶＯＰ＋ＶＳ）から所定バイト前までの期間が暗号化部分のビット列である」などということが、単純には言えなくなる。図５を例とすると、本例ではフレーム１（ｆｒａｍｅ１）のＩ−ＶＯＰのＭＢにユニークコードを挿入したが、この代わりに、フレーム２（ｆｒａｍｅ２）のＰ−ＶＯＰのＭＢにユニークコードを挿入する場合には、暗号化部分のビット列の位置を特定するために、直前のフレーム１のＩ−ＶＯＰのＭＢのサイズを把握することが必要となる。これは、ＭＢのサイズは固定長ではなく、それ以外の部分は固定長であり予めサイズの把握が可能であるためである。従って、例えば、フレーム２のＰ−ＶＯＰのＭＢにユニークコードを挿入するような構成とする場合には、予め送信側でフレーム１のＩ−ＶＯＰのＭＢのサイズを受信側へ伝える仕組みを設ける。この仕組みとしては、例えば、付加ビットを設けてそこにＩ−ＶＯＰのサイズの情報を入れるなどを用いることができる。このようにすることで、受信側では、送信側から伝えられるフレーム１のＩ−ＶＯＰのＭＢのサイズを参照して、暗号化部分のビット列の位置を特定することができる。また、他の構成例として、送信側からフレーム１のＩ−ＶＯＰのＭＢのサイズを受信側へ伝える仕組みを設けなくとも、受信側においてフレーム１のＶＯＰコードからフレーム２のＶＯＰコードまでのサイズを調べることによりフレーム１のＩ−ＶＯＰのＭＢのサイズを把握するような構成とすることもできる。
また、ＭＰＥＧ−４ではＶＯＰという表現を用いるが、例えば、ＭＰＥＧ−２で用いられるＩピクチャやＰピクチャなどのように、他の表現が用いられる場合についても、適用することが可能である。
【００５３】
なお、本例の送信端末装置１では、圧縮部１２の機能により圧縮処理手段が構成されており、暗号化処理部１３の機能により暗号化処理手段（データ処理手段）が構成されており、ＬＡＮインターフェイス部１４の機能により送信手段（データ通信手段）が構成されている。
また、本例の受信端末装置２では、ＬＡＮインターフェイス部２１の機能により受信手段（データ通信手段）が構成されており、復号化処理部２２の機能により復号処理手段（データ処理手段）が構成されており、伸張部２３の機能により伸張処理手段が構成されている。
【００５４】
ここで、本発明に係る送信端末装置や受信端末装置や通信システムなどの構成としては、必ずしも以上に示したものに限られず、種々な構成が用いられてもよい。また、本発明は、例えば、本発明に係る処理を実行する方法或いは方式や、このような方法や方式を実現するためのプログラムや当該プログラムを記録する記録媒体などとして提供することも可能であり、また、種々な装置やシステムとして提供することも可能である。
また、本発明の適用分野としては、必ずしも以上に示したものに限られず、本発明は、種々な分野に適用することが可能なものである。
また、本発明に係る送信端末装置や受信端末装置や通信システムなどにおいて行われる各種の処理としては、例えばプロセッサやメモリ等を備えたハードウエア資源においてプロセッサがＲＯＭ（Read Only Memory）に格納された制御プログラムを実行することにより制御される構成が用いられてもよく、また、例えば当該処理を実行するための各機能手段が独立したハードウエア回路として構成されてもよい。
また、本発明は上記の制御プログラムを格納したフロッピー（登録商標）ディスクやＣＤ（Compact Disc）−ＲＯＭ等のコンピュータにより読み取り可能な記録媒体や当該プログラム（自体）として把握することもでき、当該制御プログラムを当該記録媒体からコンピュータに入力してプロセッサに実行させることにより、本発明に係る処理を遂行させることができる。
【図面の簡単な説明】
【００５５】
【図１】本発明の一実施例に係る暗号化データ通信システムの構成例を示す図である。
【図２】暗号化処理部の構成例を示す図である。
【図３】復号化処理部の構成例を示す図である。
【図４】暗号化するストリーム部分のフォーマットの一例を示す図である。
【図５】冗長コードを挿入する位置のフォーマットの一例を示す図である。
【図６】ＭＵＧＩにおける暗号化処理部の構成例を示す図である。
【図７】ＭＵＧＩにおける復号化処理部の構成例を示す図である。
【図８】ＭＰＥＧ−４の圧縮ストリームのフォーマットの一例を示す図である。
【符号の説明】
【００５６】
１・・送信端末装置、  ２・・受信端末装置、  ３・・ネットワーク、  １１・・入力部、  １２・・圧縮部、  １３・・暗号化処理部、  １４、２１・・ＬＡＮインターフェイス部、  ２２・・復号化処理部、  ２３・・伸張部、  ２４・・出力部、  ３１、４１、５１、６１・・擬似乱数発生器、  ３２、４２、５２、６２・・演算部、  ３３・・ヘッダ検出部、  ３４・・冗長コード挿入部、  ４３・・冗長コード検出部、  ４４・・冗長コード削除部、
【図１】
2006157426.tif 000003
【図２】
2006157426.tif 000004
【図３】
2006157426.tif 000005
【図４】
2006157426.tif 000006
【図５】
2006157426.tif 000007
【図６】
2006157426.tif 000008
【図７】
2006157426.tif 000009
【図８】
2006157426.tif 000010