JP4910324B2 - 情報処理装置及び情報処理方法、並びにコンピュータ・プログラム - Google Patents

Description

本発明は、著作権保護若しくはその他の目的で暗号化されたコンテンツを復号化する情報処理装置及び情報処理方法、並びにコンピュータ・プログラムに係り、特に、ＩＰネットワーク上で暗号化して伝送されるコンテンツを復号する情報処理装置及び情報処理方法、並びにコンピュータ・プログラムに関する。

さらに詳しくは、本発明は、ＴＣＰストリームのような長大なバイト・ストリームとして入力され、復号鍵が動的に変更される暗号データを復号する情報処理装置及び情報処理方法、並びにコンピュータ・プログラムに係り、特に、使用する鍵が変化する変化点において処理が滞ることなくバイト・ストリームを復号する情報処理装置及び情報処理方法、並びにコンピュータ・プログラムに関する。

最近、ネットワークを経由した映像や音楽などのコンテンツの流通・配信サービスが盛んに行なわれる。この種のサービスでは、ＣＤやＤＶＤなどのメディアの移動を必要とせず、ネットワークを経由して遠隔端末間でコンテンツ配信を行なうことができる。一方、ネットワーク経由で取り扱われるコンテンツは、著作物の１つとして、著作権法の下で無断の複製や改竄などの不正使用から保護を受ける。著作権法では、同法第３０条において、個人的に又は家庭内などを使用目的とした場合の使用者本人の複製を許容する一方、同法第４９条第１項においては、私的使用以外での複製物の使用を禁止している。

しかしながら、この種のコンテンツはデジタル・データであることからコピーや改竄などの不正な操作が比較的容易であることから、法的な整備だけでなく技術的な側面からも、個人的又は家庭的なコンテンツの使用を許容しながら不正使用に対する防御が必要である。

デジタル・コンテンツの利用が盛んな今日においては、その著作権保護を目的とした多くの技術が開発されている。例えば、デジタル伝送コンテンツの保護に関する業界標準であるＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）では、著作権が保護された形でコンテンツを伝送させるための仕組みについて規定している（例えば、非特許文献１を参照のこと）。

ＤＴＣＰでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、ＤＴＣＰ準拠機器はＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）など取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ：ＡＫＥ）アルゴリズムに従って行なうこと、並びにＡＫＥコマンドにより鍵交換を行なう機器の範囲を制限することなどを取り決めている。

コンテンツ提供元であるサーバ（ＤＴＣＰ Ｓｏｕｒｃｅ）とコンテンツ提供先であるクライアント（ＤＴＣＰ Ｓｉｎｋ）は、ＡＫＥコマンドの送受信により、認証手続きを経て鍵を共有化し、その鍵を用いて伝送路を暗号化してコンテンツの伝送を行なう。したがって、不正なクライアントは、サーバとの認証に成功しないと暗号鍵を取得できないから、コンテンツを享受することはできない。また、ＡＫＥコマンドを送受信する機器の台数や範囲を制限することによって、コンテンツが使用される範囲を著作権法で言うところの個人的又は家庭の範囲内に抑えることができる。

ＤＴＣＰは、原初的には、ＩＥＥＥ１３９４を伝送路に用いたホーム・ネットワーク上におけるデジタル・コンテンツの伝送について規定したものである。最近では、ＩＥＥＥ１３９４ベースで規定されたＤＴＣＰ技術をＩＰネットワークに移植した技術の開発が進められている（以降、この技術をＤＴＣＰ−ＩＰと呼ぶ）。ホーム・ネットワークの多くはルータなどを経由してインターネットなどの外部の広域ネットワークに接続されているので、ＤＴＣＰ−ＩＰ技術の確立により、デジタル・コンテンツを保護しながらＩＰネットワークを利用した柔軟で効率的なコンテンツの利用が図られる。

ＤＴＣＰ−ＩＰは、基本的にはＤＴＣＰ規格に含まれ、ＤＴＣＰ技術をＩＰネットワークに移植した同様の技術であるが、伝送路にＩＰネットワークを使用すること、暗号化されたコンテンツの伝送にＨＴＴＰやＲＴＰプロトコルを使用するという点で、ＩＥＥＥ１３９４ベースで規定された本来のＤＴＣＰとは相違する。また、ＩＰネットワーク上にはＰＣを主としたさまざまな機器が接続され、データの盗聴、改竄が簡単に行なわれてしまう危険が高いことから、ＤＴＣＰ−ＩＰは、コンテンツを保護しながらネットワーク伝送するためのさらなる方法を規定している（例えば、非特許文献２を参照のこと）。

ここで、ＤＴＣＰ−ＩＰに従ったコンテンツの伝送手順について説明する。但し、ＤＴＣＰに準拠した機器は２つの種類に分類される。１つはＤＴＣＰ＿Ｓｏｕｒｃｅと言い、コンテンツの要求を受理し、コンテンツを送信するサーバ機器である。もう１つはＤＴＣＰ＿Ｓｉｎｋと言い、コンテンツを要求し、コンテンツを受信し、再生若しくは記録するクライアント機器である。

図１０には、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間でＡＫＥに基づく鍵交換手続き、及び鍵交換により共有した鍵を利用した暗号化コンテンツ伝送を行なう仕組みを図解している。同図に示す例では、コンテンツ伝送にはＨＴＴＰプロトコルが利用される。

ＤＴＣＰ＿ＳｏｕｒｃｅとＤＴＣＰ＿Ｓｉｎｋはまず１つのＴＣＰ／ＩＰコネクションを確立し、機器同士の認証を行なう。この認証をＤＴＣＰ認証、若しくはＡＫＥ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ)と言う。ＤＴＣＰ準拠機器には、ＤＴＬＡ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｌｉｃｅｎｓｉｎｇ Ａｄｍｉｎｉｓｔｒａｔｏｒ)と呼ばれる認可組織によりユニークな機器ＩＤや認証鍵Ｋ_authが埋め込まれている。ＤＴＣＰ認証手続きでは、このような情報を用いて互いが正規のＤＴＣＰ準拠機器であることを確かめた後、コンテンツを暗号化若しくは復号するためのＤＴＣＰ＿Ｓｏｕｒｃｅが管理している認証鍵Ｋ_authをＤＴＣＰ＿Ｓｉｎｋ機器と共有することができる。

ＡＫＥ手続きが成功すると、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器は、それぞれ内部で同様の処理を行なってＫ_authからコンテンツ鍵の種となる種鍵Ｋ_xを生成する。種鍵Ｋ_xは、コンテンツ伝送時にコンテンツ鍵Ｋ_cを生成するために使用される（後述）。

そして、ＤＴＣＰ準拠の機器間でＡＫＥによる認証及び鍵交換手続きが済んだ後、ＤＴＣＰ＿ＳｉｎｋはＤＴＣＰ＿Ｓｏｕｒｃｅ上のコンテンツを要求する。ＤＴＣＰ＿Ｓｏｕｒｃｅは、ＣＤＳ（Ｃｏｎｔｅｎｔｓ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）などを通じてＤＴＣＰ＿ＳｉｎｋにＤＴＣＰ＿Ｓｏｕｒｃｅ上のコンテンツへのアクセス先を示すコンテンツ場所をあらかじめ伝えることができる。ＤＴＣＰ＿Ｓｉｎｋがコンテンツを要求するとき、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）などのプロトコルを利用することができる。

図１０に示すようにＨＴＴＰの手続きに従ってコンテンツを要求する場合、ＤＴＣＰ＿ＳｏｕｒｃｅがＨＴＴＰサーバとなり、ＤＴＣＰ＿ＳｉｎｋがＨＴＴＰクライアントとなって、コンテンツの伝送を開始する。ちなみに、ＲＴＰによる伝送を要求するとき、ＤＴＣＰ＿ＳｏｕｒｃｅがＲＴＰ Ｓｅｎｄｅｒとなり、ＤＴＣＰ＿ＳｉｎｋがＲＴＰ Ｒｅｃｅｉｖｅｒとなってコンテンツの伝送を開始する。なお、これらの通信手続き以外にもＲＳＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）などの伝送プロトコルも適用が可能である。

ＨＴＴＰでコンテンツ伝送を行なう際、ＤＴＣＰ認証のためのＴＣＰ／ＩＰコネクションとは別に、ＨＴＴＰのためのＴＣＰ／ＩＰコネクションがＨＴＴＰクライアントより作成される（すなわち、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器はそれぞれ、ＡＫＥ手続き用とコンテンツ伝送用に個別のソケット（ＩＰアドレスとポート番号の組み合わせ）を持つ）。そして、ＨＴＴＰクライアントは、通常のＨＴＴＰと全く同様の動作手順によりＨＴＴＰサーバ上のコンテンツを要求する。これに対し、ＨＴＴＰサーバは、要求通りのコンテンツをＨＴＴＰレスポンスとして返す。

ここで、ＨＴＴＰレスポンスとして伝送されるデータは、ＨＴＴＰサーバすなわちＤＴＣＰ＿Ｓｏｕｒｃｅ機器がＡＫＥ認証をした後に共有した鍵を用いてコンテンツを暗号化したデータとなっている。

具体的には、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器は、乱数を用いてノンスＮ_cを生成して、Ｋ_xとＮ_cを基にコンテンツ鍵Ｋ_cを生成する。そして、ＤＴＣＰ＿Ｓｉｎｋ機器から要求されているコンテンツを、コンテンツ鍵Ｋ_cを用いて暗号化し、暗号化コンテンツとノンスＮcをＴＣＰストリーム上に乗せてＤＴＣＰ＿Ｓｉｎｋ機器に送信する。そして、ＩＰプロトコルは、ＴＣＰストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダ部を付加したＩＰパケットにし、指定されたＩＰアドレス宛てに届ける（例えば、非特許文献３を参照のこと）。

ＤＴＣＰ＿Ｓｉｎｋ機器側では、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器からの各ＩＰパケットを受信すると、これをＴＣＰストリームに組み立てる。そして、このストリーム中からノンスＮ_cを取り出すと、これと認証鍵Ｋ_authから求めた鍵Ｋ_xを用いて同様にコンテンツ鍵Ｋ_cを算出する。そして、このコンテンツ鍵Ｋ_cを用いて暗号化コンテンツを復号することができる。そして、復号化した後の平文のコンテンツに対し再生若しくは記録などの処理を実施することができる。

このように、ＤＴＣＰ−ＩＰは、ＤＴＣＰに準拠した機器同士で認証を行ない、ＤＴＣＰ認証が完了した機器同士で鍵を共有し、コンテンツを伝送する際に暗号化及び復号をすることにより、伝送路の途中におけるコンテンツの盗聴、改竄を防ぐという、ＩＰネットワーク上においても安全なコンテンツ伝送手法を提供することができる。

ところで、通信中のデータを保護するために暗号化通信を行なうことは一般的であるが、同じ暗号鍵を継続して使用し続けると、鍵が解読される危険が増す。このため、データ通信中に、所定期間毎、所定データ長毎、あるいは随時に暗号鍵を変更するという対策が採られることが多い。

例えば、傍受の危険の高い無線ＬＡＮシステムにおいては、ＷＥＰ（Ｗｉｒｅｄ Ｅｑｕｉｖａｌｅｎｔ Ｐｒｉｖａｃｙ）を利用したセキュリティが一般的に利用されているが、連続したパケットの暗号化に使用された鍵を比較的簡単に推測できるという脆弱性があり、長時間同じＷＥＰ鍵を使用し続けると鍵を解読することができる。これに対し、ＷＥＰ鍵の解読にそれなりに時間がかかることから、一定時間でＷＥＰ鍵を変更することで解読を防ぐことができる（例えば、特許文献１を参照のこと）。また、万が一ＷＥＰ鍵が解読された場合でも、ＷＥＰ鍵が定期的に変更されるため、解読した鍵では暗号を解くことができなくなり、安全である。

また、長大なＴＣＰストリーム全体に渡り同じ暗号鍵を使用し続けると、鍵が解読される危険は高くなる。このため、ＤＴＣＰ−ＩＰでは、Ｓｏｕｒｃｅ機器は１２８ＭＢのコンテンツ毎にノンスＮ_cすなわちコンテンツ鍵Ｋ_cを更新するよう規定している（例えば、非特許文献２を参照のこと）。バイト・ストリーム中で、同じノンスＮ_cから生成されたコンテンツ鍵Ｋ_cを用いて暗号化されたデータの範囲は、同じ鍵を用いて復号することができる復号化単位である。

しかしながら、ＴＣＰ／ＩＰなどのネットワーク上やファイル・システムからバイト・ストリームとして暗号データを受理して復号し、処理をする装置及びプログラムにおいては、復号における鍵が途中で変更されるような場合には、使用する鍵が変化する変化点において復号のための処理が滞ってしまう、という問題が発生する。

図１１には、復号鍵を途中で変更しながら伝送されるバイト・ストリームを受信する通信装置の機能的構成（従来技術）を模式的に示している。ネットワークやファイル・システムからバイト・ストリームで送られてくる暗号データは、復号鍵が途中で変更されている。

受信部では、入力された暗号データのうち同じ鍵を用いて復号する範囲のデータを１つの復号化単位（図中で暗号化データ１、２、…）として扱い、後段の復号部に連続的に転送するようになっている。

バイト・ストリーム上で鍵が変更されるとき、復号部では、変更前の鍵で復号される復号化単位の暗号データについてすべて復号処理を終了するまでは鍵を変更してはならず、このため、次の新しい鍵で復号するべき復号単位の暗号データを入力することができない。

このような場合、暗号データの受信部は、復号部で復号鍵の変更が可能になるまで受信データをバッファリング若しくは保持し続ける必要があるため、円滑なデータの処理をできなくなる。例えば、次のＩＰパケットが届いても、以前の復号鍵を用いた復号処理が完了せず、受信バッファが満杯であれば、パケット受信エラーにより再送処理が起動してしまう。

特開２００５−１１７４５８号公報 ＤＴＣＰ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｏｌｕｍｅ １ Ｖｅｒｓｉｏｎ １．３ （Ｉｎｆｏｒｍａｔｉｏｎａｌ Ｖｅｒｓｉｏｎ）ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｉｎｆｏ＿２００４０１０７＿ｄｔｃｐ＿Ｖｏｌ＿１＿１ｐ３．ｐｄｆ ＤＴＣＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ Ｅ Ｍａｐｐｉｎｇ ＤＴＣＰ ｔｏ ＩＰ， Ｖｅｒｓｉｏｎ １．０ （Ｉｎｆｏｒｍａｔｉｏｎａｌ Ｖｅｒｓｉｏｎ）ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｉｎｆｏ＿２００３１１２４＿ｄｔｃｐ＿ＶＩＳＥ＿１ｐ０．ｐｄｆ／ ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ） ７９１ ＩＮＴＥＲＮＥＴ ＰＲＯＴＯＣＯＬ

本発明の目的は、著作権保護若しくはその他の目的で暗号化されたコンテンツを好適に復号することができる、優れた情報処理装置及び情報処理方法、並びにコンピュータ・プログラムを提供することにある。

本発明のさらなる目的は、ＩＰネットワーク上で暗号化して伝送されるコンテンツを好適に復号することができる、優れた情報処理装置及び情報処理方法、並びにコンピュータ・プログラムを提供することにある。

本発明のさらなる目的は、ＴＣＰストリームのような長大なバイト・ストリームとして入力され、且つ復号鍵が動的に変更される暗号データを好適に復号することができる、優れた情報処理装置及び情報処理方法、並びにコンピュータ・プログラムを提供することにある。

本発明のさらなる目的は、復号鍵を動的に変更しながら暗号化されたバイト・ストリームを、使用する鍵が変化する変化点において処理が滞ることなく好適に復号することができる、優れた情報処理装置及び情報処理方法、並びにコンピュータ・プログラムを提供することにある。

本発明は、上記課題を参酌してなされたものであり、その第１の側面は、バイト・ストリームとして入力され、且つ復号鍵が動的に変更される暗号データを処理する情報処理装置であって、
バイト・ストリームとして入力される暗号データを受理し、同じ鍵を用いて復号するデータの範囲を復号化単位として識別し、バイト・ストリームから復号するのに必要な情報を抽出して、該抽出した情報を暗号データの断片を付加した暗号データ・セットとして出力する暗号データ受信部と、
暗号データ・セットをメモリ上に分散配置したままキューイングし、順次復号する暗号データ復号部と、
得られた平文データを処理する平文処理部と、
を具備することを特徴とする情報処理装置である。

本発明は、ＴＣＰ／ＩＰなどのネットワーク上やファイル・システムからバイト・ストリームとして暗号データを受理して復号する情報処理装置に関するものであり、特に、ＴＣＰストリームのような長大なバイト・ストリームとして入力される暗号データを復号する情報処理装置に関する。

暗号化通信であっても、同じ暗号鍵を継続して使用し続けると、途中で鍵が解読される危険が増す。このため、復号鍵を動的に変更しながら暗号化して、バイト・ストリームの伝送が行なわれる。この種のシステムとして、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間で行なわれるＨＴＴＰプロトコルを利用したコンテンツ伝送を挙げることができる。

しかしながら、このような暗号化バイト・ストリームを受理して復号し、処理を行なう場合には、復号鍵が変化する変化点において処理が滞るという問題がある。何故ならば、暗号データを復号する復号モジュールでは、同じ鍵を用いて復号するデータの範囲、すなわち復号化単位の暗号データについてすべて復号処理を終了するまでは鍵を変更してはならず、このため、新しい鍵で復号するべき次の復号化単位の暗号データを入力することができないからである。

本発明に係る情報処理装置は、暗号データを受理する受信部と、暗号データを復号する復号部と、復号データを再生若しくはその他のデータ処理を実行する処理部を備えている。

受信部では、バイト・ストリームとして入力される暗号データを受理すると、同じ鍵を用いて復号するデータの範囲を復号化単位として識別し、バイト・ストリームから復号するのに必要となる情報を抽出し、この種の情報を暗号データの断片に付加した暗号データ・セットとして復号部に渡す。

次いで、復号部では、暗号データ・セットを受理すると、そのデータをメモリ上に分散配置したままキューイングし、順次復号して、得られた平文データを後段の処理部に渡す。

したがって、本発明に係る情報処理装置によれば、受信部と復号部は独立して動作することができるので、ノンスなど復号時に必要なパラメータがバイト・ストリームの途中で動的に変更されても、受信部と復号部の動作が停止することなく、復号鍵の変化点において処理が滞ることもない。

前記暗号データ受信部は、読み取ることができた長さの暗号データで暗号データ・セットを生成し、また、鍵の変化点において暗号データ・セットを区切るようにする。また、オリジナル・データの長さ、暗号データの断片が暗号データ・ストリームのどの位置に存在したかの情報、暗号データが属する復号化単位の長さといった情報を暗号データ・セットに含めるようにする。

このように復号鍵に関する情報が暗号データ・セットに含まれているので、受信部と復号部は独立して動作することができる。そして、復号部では鍵が変化するときはその情報に従って鍵を変更していくのみで対応することができ、受信部はキューの入出力動作は停止させる必要がない。

また、復号部はデータをキューに溜めることができる分だけ蓄積し、そのキューに入ってきた暗号データ・セットを順番に処理していけばよい。また、復号部では暗号データ・セットをキューに入れて保持するので、暗号データの断片を復号部のバッファ領域を持たずコピーする必要はない。

このように、本発明に係る情報処理装置では、受信部と復号部の関連性を薄くし、それぞれのモジュールが独立して動作可能である。これは同時に各機能モジュールの実装を非常に簡略化できることを意味する。

また、本発明の第２の側面は、バイト・ストリームとして入力され、且つ復号鍵が動的に変更される暗号データの処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
バイト・ストリームとして入力される暗号データを受理し、同じ鍵を用いて復号するデータの範囲を復号化単位として識別し、バイト・ストリームから復号するのに必要な情報を抽出して、該抽出した情報を暗号データの断片を付加した暗号データ・セットとして出力する暗号データ受信手順と、
暗号データ・セットを分散配置したままキューイングし、順次復号する暗号データ復号手順と、
得られた平文データを処理する平文処理手順と、
を実行させることを特徴とするコンピュータ・プログラムである。

本発明の第２の側面に係るコンピュータ・プログラムは、コンピュータ・システム上で所定の処理を実現するようにコンピュータ可読形式で記述されたコンピュータ・プログラムを定義したものである。換言すれば、本発明の第２の側面に係るコンピュータ・プログラムをコンピュータ・システムにインストールすることによって、コンピュータ・システム上では協働的作用が発揮され、本発明の第１の側面に係る情報処理装置と同様の作用効果を得ることができる。

本発明によれば、ＴＣＰストリームのような長大なバイト・ストリームとして入力され、復号鍵が動的に変更される暗号データを好適に復号することができる、優れた情報処理装置及び情報処理方法、並びにコンピュータ・プログラムを提供することができる。

また、本発明によれば、復号鍵を動的に変更しながら暗号化されたバイト・ストリームを、使用する鍵が変化する変化点において処理が滞ることなく好適に復号することができる、優れた情報処理装置及び情報処理方法、並びにコンピュータ・プログラムを提供することができる。

本発明に係る情報処理装置によれば、暗号化されたバイト・ストリームを受信する通信装置は、受信したデータを復号するまでの処理を円滑に進めることができ、受信部と復号部の状態に依存性がなく独立動作可能であり、これによってそれぞれの機能モジュールを簡略化することができる。また、復号部は未復号の暗号データを保持するためのバッファ領域を持たず、暗号データの転送にコピーを必要としないことから、暗号化ストリームの復号処理の性能を向上することができる。

本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。

以下、図面を参照しながら本発明の実施形態について詳解する。

本発明は、ＴＣＰ／ＩＰなどのネットワーク上やファイル・システムからバイト・ストリームとして暗号データを受理して復号する情報通信システムに関するものであり、特に、ＴＣＰストリームのような長大なバイト・ストリームを途中で復号鍵を変更しながら暗号化通信を行なう情報通信システムに関する。かかるシステムの具体例は、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間で行なわれるＨＴＴＰプロトコルを利用したコンテンツ伝送である。

Ａ．システム構成
ＤＴＣＰ−ＩＰに従ったコンテンツ伝送は、コンテンツの要求を受理してコンテンツを送信するサーバとしてのＳｏｕｒｃｅ機器と、コンテンツを要求し、コンテンツを受信し、再生若しくは記録するクライアントとしてのＳｉｎｋ機器で構成される。図１には、本発明の一実施形態に係る情報通信システムの構成例を模式的に示している。

図示の例では、Ｓｏｕｒｃｅ機器Ａ〜Ｂ、Ｓｉｎｋ機器Ａ〜Ｂ及び中継機器Ａ〜Ｃの各エンティティにより、ＤＴＣＰ−ＩＰ ＡＫＥシステムが構築されている。

ＤＴＣＰ−ＩＰ に準拠した認証サーバであるＳｏｕｒｃｅ機器ＡとＤＴＣＰ−ＩＰに準拠した認証クライアントであるＳｉｎｋ機器Ａが中継機器Ａと中継機器Ｂを経由してネットワークで接続されている。

また、中継機器Ａ、中継機器Ｂ、中継機器Ｃ を経由して、ＤＴＣＰ−ＩＰに準拠した認証サーバであるＳｏｕｒｃｅ機器ＢやＤＴＣＰ−ＩＰに準拠した認証クライアントであるＳｉｎｋ機器ＢがＩＰネットワークで接続されている。

図２及び図３には、図１に示した情報通信システムにおいて、クライアント（すなわち、Ｓｉｎｋ機器）及びサーバ（すなわち、Ｓｏｕｒｃｅ機器）として動作する情報通信装置の機能構成をそれぞれ模式的に示している。Ｓｉｎｋ機器とＳｏｕｒｃｅ機器は、インターネットなどの図示しないＴＣＰ／ＩＰネットワーク上でコネクションを確立することができ、このコネクションを利用して、認証手続きやコンテンツ伝送手続きを実行することができる。

図２に示すＳｉｎｋ機器は、ＤＴＣＰ−ＩＰ規格に準拠しており、ＤＴＣＰ＿Ｓｉｎｋとして動作する。図示のクライアント機器は、機能ブロックとして、ＤＴＣＰ−ＩＰ認証ブロックと、ＤＴＣＰ−ＩＰコンテンツ受信ブロックと、コンテンツ再生／記録ブロックを備えている。

ＤＴＣＰ−ＩＰ認証ブロックは、ＡＫＥブロックと、メッセージ・ダイジェスト生成ブロックと、コンテンツ復号ブロックを備えている。

ＡＫＥブロックは、ＤＴＣＰ−ＩＰにおけるＡＫＥ機構（ＤＴＣＰ＿Ｓｉｎｋ側）を実現するブロックでる。このＡＫＥブロックは後述のメッセージ・ダイジェスト生成ブロックから要求されたパラメータを渡す機能も備えている。

メッセージ・ダイジェスト生成ブロックは、指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックである。メッセージ・ダイジェストを生成するアルゴリズムはあらかじめ用意されたアルゴリズムを指定することができる。あらかじめ用意されたアルゴリズムとして、例えばＭＤ５やＳＨＡ−１といった一方向性ハッシュ関数に関するアルゴリズムが挙げることができる（ＳＨＡ−１は、ＭＤ５と同様、ＭＤ４を改良したものに相当するが、１６０ビットのハッシュ値を生成するので、強度はＭＤシリーズを上回る）。

メッセージ・ダイジェスト生成ブロックは、ＤＴＣＰ−ＩＰ認証ブロックの外に公開してはならないＡＫＥブロックが保持するパラメータのメッセージ・ダイジェストを生成できるようにＡＫＥブロックと密に配置され、ＡＫＥブロックへパラメータを要求して取得することが可能であり、そのパラメータ若しくは外部から与えられたパラメータのメッセージ・ダイジェストを作成することができる。

コンテンツ復号ブロックは、サーバから受信した暗号化されたコンテンツ・データをＡＫＥで交換した鍵を用いてコンテンツの復号鍵を算出し、暗号コンテンツを復号するブロックである。ここで復号されたコンテンツは、コンテンツ再生／記録ブロックへ渡される。

コンテンツ再生／記録ブロックは、渡されたコンテンツを、再生モードの場合は再生を行ない、記録モードの場合は保存する。

ＤＴＣＰ−ＩＰコンテンツ受信ブロックは、ＡＫＥを実施した後にコンテンツ伝送手続きを実行する処理モジュールである。図示の例では、ＤＴＣＰ−ＩＰコンテンツ受信ブロックはＨＴＴＰクライアント・ブロックを持ち、ＨＴＴＰクライアントとしてＨＴＴＰサーバへコンテンツを要求し、応答されたコンテンツをＨＴＴＰサーバから受信する。

ＨＴＴＰクライアント・ブロックは、ＨＴＴＰリクエスト管理ブロックとＨＴＴＰレスポンス管理ブロックに分かれる。さらに、ＨＴＴＰリクエスト管理ブロックは、ＨＴＴＰリクエスト送信ブロックとＨＴＴＰリクエスト生成ブロックへ分かれる。

ＨＴＴＰリクエスト生成ブロックは、送信するコンテンツ伝送要求（ＨＴＴＰリクエスト)を生成する。ここで生成されたＨＴＴＰリクエストは、ＨＴＴＰリクエスト送信ブロックによりサーバへ送信される。

ＨＴＴＰレスポンス管理ブロックは、ＨＴＴＰレスポンス受信ブロックとＨＴＴＰレスポンス解釈ブロックに分かれる。サーバから返信されるＨＴＴＰレスポンスと暗号化されたコンテンツは、ＨＴＴＰ受信ブロックで受信される。ここで受信したＨＴＴＰレスポンスは、ＨＴＴＰレスポンス解釈ブロックでチェックされる。ここでのチェックがＯＫの場合は受信した暗号化コンテンツをＤＴＣＰ−ＩＰ認証ブロック内のコンテンツ復号ブロックへ送る。また、このチェックがＮＧの場合は、エラー・レスポンスとしての処理を行なう。

ＤＴＣＰ−ＩＰ認証ブロックとＤＴＣＰ−ＩＰコンテンツ受信ブロックは、サーバ機器との間で個別のＴＣＰ／ＩＰコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。

また、図３に示すＳｏｕｒｃｅ機器は、ＤＴＣＰ−ＩＰ規格に準拠しており、ＤＴＣＰ＿Ｓｏｕｒｃｅとして動作する。サーバ機器は、機能ブロックとして、ＤＴＣＰ−ＩＰ認証ブロックと、ＤＴＣＰ−ＩＰコンテンツ送信ブロックと、コンテンツ管理ブロックを備えている。

ＤＴＣＰ−ＩＰ認証ブロックは、認証手続き実行手段に相当し、ＡＫＥブロックと、メッセージ・ダイジェスト生成ブロックと、コンテンツ暗号化ブロックを備えている。

ＡＫＥブロックは、ＤＴＣＰ−ＩＰにおけるＡＫＥ機構（ＤＴＣＰ＿Ｓｏｕｒｃｅ側）を実現するブロックである。このブロックは、後述のメッセージ・ダイジェスト生成ブロックから要求されたパラメータを渡す機能も備えている。ＡＫＥブロックは認証したＤＴＣＰ＿Ｓｉｎｋ機器に関する情報を認証した機器の数だけ保持し、それをクライアントからコンテンツが要求された際に認証済みのクライアントかどうかを判別するのに使用する。

メッセージ・ダイジェスト生成ブロックは指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックである。メッセージ・ダイジェストを生成するアルゴリズムはあらかじめ用意されたアルゴリズムを指定できる。あらかじめ用意されたアルゴリズムとは、例えばＭＤ５やＳＨＡ−１といった一方向性ハッシュ関数に関するアルゴリズムが挙げられる（同上）。

メッセージ・ダイジェスト生成ブロックは、ＤＴＣＰ−ＩＰ認証ブロックの外に公開してはならないＡＫＥブロックが保持するパラメータのメッセージ・ダイジェストを生成できるようにＡＫＥブロックと密に配置され、ＡＫＥブロックへパラメータを要求して取得することが可能で、そのパラメータ若しくは外部から与えられたパラメータのメッセージ・ダイジェストを作成することができる。

コンテンツ暗号化ブロックは、ＤＴＣＰ−ＩＰコンテンツ送信ブロックの要求に応じて、コンテンツ管理ブロックより読み出したコンテンツ・データをＡＫＥで交換した鍵から生成したコンテンツ鍵を用いて暗号化するブロックである。ここで復号されたコンテンツは、クライアントへ送信するために、ＤＴＣＰ−ＩＰコンテンツ送信ブロックへ渡される。

コンテンツ管理ブロックは、ＤＴＣＰ−ＩＰの機構を用いて保護されるべきコンテンツを管理するブロックである。コンテンツ暗号化ブロックの読み出しに応じて、コンテンツのデータを渡す。

ＤＴＣＰ−ＩＰコンテンツ送信ブロックは、ＨＴＴＰサーバ・ブロックを持ち、ＨＴＴＰサーバとしてクライアントからのリクエストを受理し要求に応じた処理を実行する。

ＨＴＴＰサーバ・ブロックは、ＨＴＴＰリクエスト管理ブロックとＨＴＴＰレスポンス管理ブロックに分かれる。さらに、ＨＴＴＰリクエスト管理ブロックは、ＨＴＴＰリクエスト受信ブロックと、ＨＴＴＰリクエスト解釈ブロックに分かれる。

ＨＴＴＰリクエスト受信ブロックは、クライアントからのＨＴＴＰリクエストを受信する。受信したＨＴＴＰリクエストはＨＴＴＰリクエスト解釈ブロックに送られ、チェックされる。ＨＴＴＰリクエスト解釈ブロックにおけるチェックがＯＫの場合、ＨＴＴＰリクエストの情報をＤＴＣＰ−ＩＰ認証ブロックへ通知する。

ＨＴＴＰレスポンス管理ブロックは、ＨＴＴＰレスポンス生成ブロックとＨＴＴＰレスポンス送信ブロックに分かれる。

ＨＴＴＰレスポンス生成ブロックは、ＨＴＴＰリクエスト解釈ブロックでのチェックがＯＫの場合、暗号化されたコンテンツを返すためのＨＴＴＰレスポンスを作成する。一方、ＨＴＴＰリクエスト解釈ブロックでのチェックがＮＧの場合、エラーを返すためのＨＴＴＰレスポンスを作成する。

ＨＴＴＰレスポンス送信ブロックは、作成されたＨＴＴＰレスポンスを、要求元のクライアントへＨＴＴＰレスポンスを送信する。また、ＨＴＴＰリクエスト解釈ブロックでのチェックがＯＫの場合には、ＨＴＴＰレスポンス・ヘッダに続けて、ＤＴＣＰ−ＩＰ認証ブロック内のコンテンツ暗号化ブロックにて暗号化したコンテンツを送信する。

ＤＴＣＰ−ＩＰ認証ブロックとＤＴＣＰ−ＩＰコンテンツ送信ブロックは、Ｓｉｎｋ機器との間で個別のＴＣＰ／ＩＰコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。

なお、ＤＴＣＰ−Ｓｉｎｋ機器及びＤＴＣＰ−Ｓｏｕｒｃｅ機器のいずれもがＤＴＣＰ−ＩＰ認証ブロック内に持つメッセージ・ダイジェスト生成ブロックはＤＴＣＰ−ＩＰ自体で規定される機能モジュールではなく、また本発明の要旨には直接関連しない。例えば、本出願人に既に譲渡されている特願２００４−１１３４５９号公報にはメッセージ・ダイジェスト生成ブロックに付いて記述されている。

Ｂ．ＨＴＴＰを利用したコンテンツ伝送
図４には、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間でＡＫＥ手続き、及びＨＴＴＰプロトコルを利用したコンテンツ伝送を行なう仕組みを図解している。ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間では、ＡＫＥ手続き用のＴＣＰコネクションと、ＨＴＴＰを利用したコンテンツ要求用、並びにコンテンツ鍵の確認用のＴＣＰコネクションがそれぞれ独立して確立される（すなわち、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器はそれぞれ、ＡＫＥ手続き用とコンテンツ伝送用、コンテンツ鍵の確認用に個別のソケット（ＩＰアドレスとポート番号の組み合わせ）を持つ）。

まず、ＡＫＥ手続き用のＴＣＰコネクションを確立し、同手続きが成功すると、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間では認証鍵Ｋ_authを共有することができる。ＡＫＥ手続きが終了すると、このＴＣＰコネクションは切断される。そして、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器は、それぞれ内部で同様の処理を行なってＫ_authからコンテンツ鍵の種となる種鍵Ｋ_xを生成する。

次いで、ＤＴＣＰ−Ｓｉｎｋ機器側からのコンテンツ要求などに応じて、ＨＴＴＰプロトコルを用いたコンテンツ伝送用のＴＣＰコネクションが確立される。

ＤＴＣＰ＿Ｓｏｕｒｃｅ機器は、乱数を用いてノンスＮ_cを生成して、Ｋ_xとＮ_cを基にコンテンツ鍵Ｋ_cを生成する。そして、ＤＴＣＰ＿Ｓｉｎｋ機器から要求されているコンテンツを、コンテンツ鍵Ｋ_cを用いて暗号化し、暗号化コンテンツとノンスＮ_cをＴＣＰストリーム上に乗せてＤＴＣＰ＿Ｓｉｎｋ機器に送信する。ＩＰプロトコルは、ＴＣＰストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダ部を付加したＩＰパケットにし、指定されたＩＰアドレス宛てに届ける。

ＤＴＣＰ＿Ｓｉｎｋ機器側では、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器からの各ＩＰパケットを受信すると、これをＴＣＰストリームに組み立てる。そして、ストリームからノンスＮ_cを取り出すと、これと認証鍵Ｋ_authから求めた鍵Ｋ_xを用いてコンテンツ鍵Ｋ_cを算出する。そして、このコンテンツ鍵Ｋ_cを用いて受信した暗号化コンテンツを復号することができる。

ＨＴＴＰプロトコルを利用したコンテンツ伝送が終了すると、使用したＴＣＰコネクションを適宜切断することができる。

ここで、長大なＴＣＰストリーム全体に渡り同じ暗号鍵を使用し続けると、鍵が解読される危険は高くなる。このため、ＤＴＣＰ−ＩＰでは、Ｓｏｕｒｃｅ機器は１２８ＭＢのコンテンツ毎にノンスＮ_cすなわちコンテンツ鍵Ｋ_cを更新するよう取り決められている。バイト・ストリーム中で、同じノンスＮ_cから生成されたコンテンツ鍵Ｋ_cを用いて暗号化されたデータの範囲は、同じ鍵を用いて復号することができる復号化単位となる。

復号鍵が動的に変更される暗号化ストリームを受信及び復号処理する際には、使用する鍵が変化する変化点において処理が滞るという問題がある。本実施形態では、ＤＴＣＰ−Ｓｉｎｋ機器側では、受信部において、バイト・ストリームとして入力される暗号データを受理すると、同じ鍵を用いて復号するデータの範囲を復号化単位として識別し、バイト・ストリームから復号するのに必要となるノンスなどの情報を抽出し、この種の情報を暗号データの断片に付加した暗号データ・セットとして後段の復号部に渡すようにしている。したがって、受信部と復号部は独立して動作することができるので、ノンスなど復号時に必要なパラメータがバイト・ストリームの途中で動的に変更されても、受信部と復号部の動作が停止することなく、復号鍵の変化点において処理が滞ることもない。但し、この点についての詳細は後述に譲る。

また、バイト・ストリームの途中で復号鍵が動的に変更されることから、コンテンツ鍵の確認用のＴＣＰコネクションをさらに確立し、ＤＴＣＰ＿Ｓｉｎｋ機器は、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器に対しコンテンツ鍵確認のための手続きを行なう。ＤＴＣＰ＿Ｓｉｎｋ機器は、コンテンツ鍵の確認が必要になると、適宜このＴＣＰコネクションを確立する。ＤＴＣＰ＿Ｓｉｎｋ機器側で復号コンテンツについて再生やその他の平文処理が終了すると、鍵確認の必要はなくなるので、このＴＣＰコネクションは切断される。但し、この確認手続き自体は本発明の要旨には直接関連しないので、ここではこれ以上説明しない。

Ｃ．暗号コンテンツの受信及び復号処理
上述したように、ＤＴＣＰ−ＩＰは、ＴＣＰコネクションを介してＤＴＣＰに準拠した機器同士で認証を行ない、ＤＴＣＰ認証が完了した機器同士で鍵を共有し、コンテンツを伝送する際に暗号化及び復号をすることにより、伝送路の途中におけるコンテンツの盗聴、改竄を防ぐという、ＩＰネットワーク上においても安全なコンテンツ伝送手法を提供することができる。さらに、長大なＴＣＰストリーム全体に渡り同じ暗号鍵を使用し続けると、鍵が解読される危険は高くなることから、ＤＴＣＰ−ＩＰでは、１２８ＭＢのコンテンツ毎にノンスＮ_cすなわちコンテンツ鍵Ｋ_cを更新するよう取り決められている。

ここで、復号鍵が途中で動的に変更される暗号化バイト・ストリームを受理して復号し、処理を行なう場合には、復号鍵が変化する変化点において処理が滞るという問題がある。何故ならば、復号モジュールでは、同じ鍵を用いて復号するデータの範囲、すなわち復号化単位の暗号データについてすべて復号処理を終了するまでは鍵を変更してはならず、このため、次の新しい鍵で復号するべき復号単位の暗号データを入力することができないからである。

これに対し、本実施形態に係るＤＴＣＰ＿Ｓｉｎｋ機器では、受信部において、バイト・ストリームとして入力される暗号データを受理すると、同じ鍵を用いて復号するデータの範囲を復号化単位として識別し、バイト・ストリームから復号するのに必要となるノンスなどの情報を抽出し、この種の情報を暗号データの断片に付加した暗号データ・セットとして後段の復号部に渡すようにしている。したがって、受信部と復号部は独立して動作することができるので、ノンスなど復号時に必要なパラメータがバイト・ストリームの途中で動的に変更されても、受信部と復号部の動作が停止することなく、復号鍵の変化点において処理が滞ることもない。

この項では、ＤＴＣＰ＿Ｓｉｎｋ機器における暗号化バイト・ストリームの受信及び復号処理について詳解する。

図５には、ＤＴＣＰ＿Ｓｉｎｋ機器において暗号化バイト・ストリームの受信及び復号処理を行なうための機能的構成を模式的に示している。図示の通り、暗号データを受理する受信部と、暗号データを復号する復号部と、復号データを再生若しくはその他のデータ処理を実行する処理部の各機能モジュールで構成される。

受信部は、ＤＴＣＰ−ＩＰコンテンツ受信ブロック内のＨＴＴＰレスポンス管理ブロックに相当し、復号部は、ＤＴＣＰ−ＩＰ認証ブロック内のコンテンツ復号ブロックに相当する（図２を参照のこと）。また、処理部は、復号して平文状態となった映像や音響などのコンテンツを再生出力するコンテンツ再生アプリケーションに相当する。

受信部は、ネットワーク若しくはファイル・システムからバイト・ストリームの形式で暗号データを受理すると、まず読み取った暗号データからノンスＮ_c若しくは復号鍵などの復号に必要となる復号用情報を読み取る。そして、暗号化ストリームのうち同じ鍵を用いて復号することができる復号化単位を識別して、復号化単位をさらに適当な大きさの断片に分割し、各断片に復号用の情報を付加して暗号化データ・セットを生成し、復号部に転送する。

図６には、暗号データ・セットのデータ構成例を示している。図示の例では、暗号データ・セットは、当該データ・セットに含まれる暗号データの断片の長さと、ノンスＮ_cなど復号鍵に関する情報及びその暗号データ・セットを復号するために必要なオプション・データ、そして暗号データの断片から成るオブジェクトで構成される。

復号化単位全体の暗号データを受信するのには時間がかかる、あるいは１つの復号化単位のデータ長が復号部に１回当り投入するデータ量として大き過ぎることがあるので、受信部では復号化単位の暗号データを適当に断片化して暗号データ・セットを生成する。暗号化データの断片の長さは、例えばネットワークから一度に読むことのできた暗号データの長さやファイル・システムから一度の操作で読み出す暗号データ長さなどであるが、暗号データ・セット毎に長さを明記するため固定長である必要はない。したがって、受信部はすべての暗号データを読み取ってから暗号データ・セットを作成するのではなく、そのときに読み取ることができた長さの暗号データで暗号データ・セットを生成することができる。但し、鍵の変化点において暗号データ・セットを区切られなければならない。

暗号データ・セットに付加される鍵に関する情報とは、鍵そのものでも良いし、鍵と結び付けることのできるようなコピー・モードでも構わない。図４に示したＤＴＣＰ−ＩＰコンテンツ伝送手続きの場合、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器が暗号化ストリームに乗せるノンスＮ_cが鍵に関する情報に相当する。

オプション・データには、暗号データ・セットに含まれる暗号データの断片が暗号データ・ストリーム内のどの位置に存在したデータか（すなわち、バイト・ストリーム中の相対位置）を示す情報や、暗号データ・セットが属する復号化単位の長さ情報などが書き込まれる。

オプション・データとして書き込まれる情報の内容は、復号方法などに依存する。例えば、ＤＴＣＰ−ＩＰ１で扱われる暗号データは１つ以上のＰＣＰ１で構成される。１つのＰＣＰ（Ｐｒｏｔｅｃｔｅｄ Ｃｏｎｔｅｎｔ Ｐａｃｋｅｔ）がそれに含まれるデータを復号するための情報を示しており、その中には暗号化する前のオリジナル・データの長さが記述されている。

ＤＴＣＰ−ＩＰでは、オリジナル・データを暗号化するのに１２８ビットＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）というアルゴリズムを使用している。このアルゴリズムにオリジナル・データを入力すると同じサイズの暗号データが得られるが、入力単位が１２８ビット固定になっているため、鍵の変化点やオリジナル・データの終端で１２８ビットにデータ量が満たない場合には１２８ビットまで０で埋められて入力される（データが１２８ビット以上ある場合は１２８ビットの暗号化を繰り返す）。また、同アルゴリズムにより復号する際には、１２８ビットの倍数長の暗号データを入力して同じサイズのオリジナル・データを得るが、ＰＣＰで示されたサイズ以上のオリジナル・データが得られた場合はそのサイズまでが有効データとして扱われる（復号も１２８ビット単位で処理を繰り返す）。

本実施形態では、ＤＴＣＰ−ＩＰで扱われるＰＣＰから鍵情報（＝Ｅ−ＥＭＩ）を読み出し、ＰＣＰの中に含まれる暗号データをネットワークやファイル・システムから読み取れた量毎に暗号データ・セット群を作成して、復号部に転送していく。

図７には、受信部において、ＤＴＣＰ−ＩＰ暗号データから暗号データ・セットを作成する様子を示している。ＤＴＣＰ−ＩＰ１で扱われる暗号データは１つ以上のＰＣＰ１で構成され、１つのＰＣＰが同じ復号鍵で復号することができる復号化単位に相当する。受信部では、そのときに読み取ることができた長さの暗号データの断片にＰＣＰヘッダに記述されている鍵情報を各暗号データ・セットに付加して、暗号データ・セット１、２…を順次生成していく。

但し、鍵の変化点や暗号データの終端では復号後の有効範囲を知る必要があるため、この暗号データの断片が暗号データ・ストリームのどの位置に存在したかの情報やオリジナル・データの長さなども一緒に暗号データ・セットへ入れておく必要がある。このようにオプション・データはその復号手法などに依存するパラメータを指定する。

なお、暗号データ・セットを作成するためには、暗号データ・ストリーム中に含まれている暗号データの断片を格納するだけのデータ領域が必要である。仮想メモリを備えたオペレーティング・システムでは動的に領域を確保して暗号データ・セットを構成することは容易である。また、資源が限られたハードウェアでは、領域を使いまわすなどの工夫をすることにより、同様の仕組みを実現することが可能である。

復号部は、受信部より転送された暗号データ・セット群を受理すると、その暗号データ・セット群をキューに溜めていく。

従来、暗号データの復号処理を行なう場合、受信した暗号データをある連続したメモリ領域に一旦コピーし、復号部がメモリから暗号データを順次読み出しながら復号処理を行なう（図１１を参照のこと）。このような場合、バイト・ストリームとして入力される暗号データの復号鍵が動的に変化する際には、同じ鍵で処理すべき暗号データ、すなわち復号化単位を構成するすべての暗号データがすべて復号されたことを確認してから次の復号単位の復号鍵を復号部セットし、そして新しい鍵で復号する暗号データを入力しなければならない。しかしながら、このような方式では、受信部が復号部の状態に従って暗号データの転送を制御しなければならず、復号鍵の変更があるタイミングの前後でデータの受け渡しが滞ると言う問題がある。

これに対し、本実施形態では、受信部は復号部における復号処理の進行状態とは無関係に、暗号データ・セットを転送できるだけ転送することができる。一方、復号部はデータをキューに溜めることができる分だけ蓄積し、そのキューに入ってきた暗号データ・セットを順番に処理していけばよい。復号鍵に関する情報が暗号データ・セットに含まれているので、復号部では鍵が変化するときはその情報に従って鍵を変更していくのみで対応することができ、受信部はキューの入出力動作は停止させる必要がない。また、復号部では暗号データ・セットをキューに入れて保持するので、暗号データの断片を復号部のバッファ領域を持たずコピーする必要はない。そして、復号部は復号した平文データを処理部に転送する。

処理部では、平文データでユーザにより指定された処理を行なう。例えば、復号されたムービー若しくは音声データをデコーダに入力し再生をしたり、任意の形式のデータをファイル・システムへ保存したりする。

このように、本実施形態に係る情報処理装置では、受信部と復号部の関連性を薄くし、それぞれのモジュールが独立して動作可能である。これは同時に各機能モジュールの実装を非常に簡略化できることを意味する。

本実施形態において、ＤＴＣＰ−Ｓｉｎｋ装置が実施する暗号化バイト・ストリームの受信及び復号処理の概要は、図５に示した通りである。すなわち、受信部は、受信したバイト・ストリームからデータを読み取って暗号データ・セットを作成して復号部へ転送する。これに対し、復号部では、暗号データ・セットがキューイングされていたら指定された鍵情報で暗号データの断片を復号し、処理部へ転送する。そして処理部は、ユーザに指定された処理を平文データに対して実施する。

図８には、受信部において行なわれる処理手順をフローチャートの形式で示している。

まず、 ネットワークやファイル・システムなど指定された入力装置から暗号データを読み込めるかどうかをチェックする（ステップＳ１）。暗号データの読み込み可能な場合は次ステップＳ１へ進むが、暗号データの読み込みが不可能である場合には、ステップＳ１０へ進み、当該処理ルーチンの終了処理を行なう。但し、読み込み不可能（終了）の場合であっても、前回読み取った暗号データで未処理部分が残っていて、且つ、鍵情報を保持している場合は、次ステップＳ２へ進む。

ステップＳ２では、入力装置から暗号データを読み込み、受信部にて保持する。このとき、読み込むデータのサイズは任意で、すべての暗号データを読み込む必要はない。既に読み込んだデータがある場合はその後ろに新たに読み込んだデータを連結する。

ここで、現在処理中の復号化単位における鍵情報を受信部の内部で既に持っているかどうかを判別する（ステップＳ３）。受信部の内部に既に鍵情報を持っている場合はステップＳ６へ進み、未だ鍵情報を取得していない場合は、それを解析するためにステップＳ４へ進む。非同期に鍵情報が変更された場合や、読み取った暗号データの内容などで、現在の鍵情報を消去して新しく鍵情報を解析する必要がある場合もステップＳ４へ進む。

ステップＳ４では、鍵情報を取得するのに必要なデータ量の暗号データを読み込んでいるかどうかをチェックする。ここで、まだ読み込みが足りない場合はステップＳ１へ戻る。

また、鍵情報を取得するのに十分なデータ量があれば、ステップＳ５へ進み、読み込んだ暗号データから鍵情報を解析し、その結果を保持する。そして鍵情報の解析で使用したデータを受信部から削除し、ステップＳ１へ戻ります。

ステップＳ６では、鍵情報や必要なオプション情報、読み込んだ暗号データの断片を用いて、暗号データ・セットを作成する。暗号データ・セットに含まれる暗号データの断片は、新たに作成した領域にコピーして保持させることができる。しかし、コピーによる負荷の増大を抑えたい場合には、ステップＳ１にて暗号データを読み込む際にその都度新たな領域を作成しておき、その領域に直接暗号データを読み込み、暗号データ・セットに内包することもできる。

次いで、作成した暗号データ・セットを復号部に転送する（ステップＳ７）。転送したら、読み込んだ暗号データから転送した暗号データの断片を削除する（若しくは転送したこととしてマークする）。

次いで、現在の鍵情報で有効な暗号データの長さが指定されていて、その長さの暗号データを復号部にすべて転送したならば（すなわち、復号化単位の暗号データをすべて転送したならば）（ステップＳ８）、次ステップＳ９へ進み、それ以外の場合はステップＳ１へ戻る。ステップＳ９では、保持している鍵情報を消去した後、ステップＳ１へ戻る。そして、ステップＳ１０では、復号部に終了を通知して本処理ルーチンを終了する。

図９には、復号部において行なわれる処理手順をフローチャートの形式で示している。

まず、当該復号部に受信部から１つ以上の暗号データ・セットが転送され、復号部のキューに蓄積されているかどうかをチェックする（ステップＳ２１）。暗号データ・セットが保持されていれば次ステップＳ２３へ進むが、暗号データ・セットが転送されていなければステップＳ２２へ進む。

ステップＳ２２では、受信部から終了通知がされているかどうかをチェックする。そして、当該通知がなされていなければステップＳ２１へ戻る。また、受信部から終了通知がされていれば、終了状態となり、本処理ルーチンを終了する。

ステップＳ２３では、暗号データ・セットをキューから読み出し、それに示された鍵情報やオプション情報を用いて復号処理を行なう。復号化を終了したら、次ステップＳ２４へ進む。

ステップＳ２４では、復号結果を処理部へ転送し、次の暗号データ・セットを処理するためにステップＳ２１に戻る。

以上、特定の実施形態を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。

本発明の適用例として、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間で行なわれるＨＴＴＰプロトコルを利用したコンテンツ伝送を挙げることができるが、本発明の要旨はこれに限定されない。長大なバイト・ストリームを途中で復号鍵を変更しながら暗号化通信を行なう、その他のさまざまなタイプの情報通信システムに対しても、同様に本発明を適用することができる。

要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、特許請求の範囲を参酌すべきである。

図１は、本発明の一実施形態に係る情報通信システムの構成例を模式的に示した図である。 図２は、図１に示した情報通信システムにおいて、クライアント（すなわち、Ｓｉｎｋ機器）として動作する情報通信装置の機能構成を模式的に示した図である。 図３は、図１に示した情報通信システムにおいて、サーバ（すなわち、Ｓｏｕｒｃｅ機器）として動作する情報通信装置の機能構成を模式的に示した図である。 図４は、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間でＡＫＥ手続き、及びＨＴＴＰプロトコルを利用したコンテンツ伝送を行なう仕組みを示した図である。 図５は、ＤＴＣＰ＿Ｓｉｎｋ機器において暗号化バイト・ストリームの受信及び復号処理を行なうための機能的構成を模式的に示した図である。 図６は、暗号データ・セットのデータ構成例を示した図である。 図７は、ＤＴＣＰ−ＩＰ暗号データから暗号データ・セットを作成する様子を示した図である。 図８は、受信部において行なわれる処理手順を示したフローチャートである。 図９は、復号部において行なわれる処理手順を示したフローチャートである。 図１０は、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間でＡＫＥ手続き、及びＨＴＴＰプロトコルを利用したコンテンツ伝送を行なう仕組みを示した図である。 図１１は、復号鍵を途中で変更しながら伝送されるバイト・ストリームを受信する通信装置の機能的構成（従来技術）を模式的に示した図である。

Claims (9)

1. バイト・ストリームとして入力され、且つ復号鍵が動的に変更される暗号データを処理する情報処理装置であって、
   バイト・ストリームとして入力される暗号データから、同じ鍵を用いて復号するデータの範囲を復号化単位として識別し、バイト・ストリームから復号鍵に関する情報を抽出して、前記復号化単位を暗号データの断片に分割し、各断片に該抽出した復号鍵に関する情報を付加した暗号データ・セットを生成して出力する暗号データ受信部と、
   データを保持するメモリを有し、前記暗号データ受信部から出力される暗号データ・セットを前記メモリ上にキューイングし、暗号データ・セットに含まれている復号鍵に関する情報を用いて暗号データの断片を順次復号する暗号データ復号部と、
   得られた平文データを処理する平文処理部と、
   を具備することを特徴とする情報処理装置。
2. 前記暗号データ受信部は、受信処理することができた長さの暗号データで暗号データ・セットを生成し、鍵の変化点において暗号データ・セットを区切る、
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記暗号データ受信部は、前記復号鍵に関する情報とともに、復号単位の暗号データを暗号化する前のオリジナル・データの長さ、暗号データの断片が暗号データ・ストリームのどの位置に存在したかの情報、暗号データ・セットが属する復号化単位の長さを暗号データ・セットに含める、
   ことを特徴とする請求項１に記載の情報処理装置。
4. 前記暗号データ受信部は、暗号データ復号部における復号処理の進行状態とは無関係に、暗号データ・セットを転送できるだけ転送する、
   ことを特徴とする請求項１に記載の情報処理装置。
5. バイト・ストリームとして入力され、且つ復号鍵が動的に変更される暗号データを、コンピュータを用いて処理する情報処理方法であって、
   前記コンピュータが備える暗号データ受信手段が、バイト・ストリームとして入力される暗号データから、同じ鍵を用いて復号するデータの範囲を復号化単位として識別し、バイト・ストリームから復号鍵に関する情報を抽出して、前記復号化単位を暗号データの断片に分割し、各断片に該抽出した復号鍵に関する情報を付加した暗号データ・セットを生成して出力する暗号データ受信ステップと、
   前記コンピュータが備える暗号データ復号手段が、前記暗号データ受信ステップで出力される暗号データ・セットを前記コンピュータが備えるメモリ上にキューイングし、暗号データ・セットに含まれている復号鍵に関する情報を用いて暗号データの断片を順次復号する暗号データ復号ステップと、
   前記コンピュータが備える平文処理手段が、得られた平文データを処理する平文処理ステップと、
   を有することを特徴とする情報処理方法。
6. 前記暗号データ受信ステップでは、受信処理することができた長さの暗号データで暗号データ・セットを生成し、鍵の変化点において暗号データ・セットを区切る、
   ことを特徴とする請求項５に記載の情報処理方法。
7. 前記暗号データ受信ステップでは、前記復号鍵に関する情報とともに、復号単位の暗号データを暗号化する前のオリジナル・データの長さ、暗号データの断片が暗号データ・ストリームのどの位置に存在したかの情報、暗号データ・セットが属する復号化単位の長さを暗号データ・セットに含める、
   ことを特徴とする請求項５に記載の情報処理方法。
8. 前記暗号データ受信ステップでは、暗号データ復号ステップにおける復号処理の進行状態とは無関係に、暗号データ・セットを転送できるだけ転送する、
   ことを特徴とする請求項５に記載の情報処理方法。
9. バイト・ストリームとして入力され、且つ復号鍵が動的に変更される暗号データの処理をコンピュータ上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータを、
   バイト・ストリームとして入力される暗号データを受理し、同じ鍵を用いて復号するデータの範囲を復号化単位として識別し、バイト・ストリームから復号するのに必要な情報を抽出して、前記復号化単位を暗号データの断片に分割し、各断片に該抽出した情報を付加した暗号データ・セットを生成して出力する暗号データ受信部、
   データを保持するメモリを有し、前記暗号データ受信部から出力される暗号データ・セットを前記メモリ上に分散配置したままキューイングし、順次復号する暗号データ復号部、
   得られた平文データを処理する平文処理部、
   として機能させるためのコンピュータ・プログラム。

Images