JP2007041223A

JP2007041223A - データ配信装置及びデータ通信システム

Info

Publication number: JP2007041223A
Application number: JP2005224434A
Authority: JP
Inventors: Takahiro Hiramatsu; 隆宏平松; Hironobu Abe; 博信阿倍; Koichi Yamada; 耕一山田; Junichi Yokosato; 純一横里
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2005-08-02
Filing date: 2005-08-02
Publication date: 2007-02-15
Also published as: CN1909443B; US20070033391A1; CN1909443A; US7693278B2

Abstract

【課題】安全性の高いデータ通信を行う。
【解決手段】ＲＴＰパケット生成部１１はデータを分割してパケットを生成し、生成したパケットを識別するための情報をヘッダに付加する。ＲＴＰパケット暗号化手段１３は生成されたパケット内部のデータを所定のブロックに区切り、暗号鍵共有部１２が共有している暗号鍵を使用してブロック毎にデータを暗号化すると共に、最初のブロックを暗号化する際には、初期ベクタとしてヘッダに含まれるパケットを識別するための情報を使用して暗号化し、以降の１つのブロックを暗号化する際には直前のブロックの暗号化結果を利用する暗号化方式により暗号化する。
【選択図】図１

Description

この発明は映像や音声等のデータを配信するデータ配信装置、及びこのデータ配信装置と配信されたデータを受信するデータ受信装置とを備えたデータ通信システムに関するものである。

従来の技術としての非特許文献１では、ＩＰ（Internet Protocol）ネットワーク上で、映像や音声に代表されるリアルタイムのデータを配信する機構を提供している。ＩＰネットワーク上ではデータをパケット化して伝送するが、パケットが宛先に確実に配信されることも、配信側が配信した順序通りに受信側で受信できることも保証されない。

そのような保証が必要な場合は、通常、ＴＣＰ（Transport Control Protocol）プロトコルを利用するが、ＴＣＰプロトコルはパケットの喪失を再送により補うため、リアルタイム性が要求される用途には適さない。リアルタイム性が要求される用途ではＵＤＰ（User Datagram Protocol）を利用するが、ＵＤＰはＩＰと同様にパケットの確実な配信や順序通りの配信を保証しない。

映像や音声等のリアルタイムデータの伝送では、リアルタイム性を重視し再送にかかる時間を許容できないため、パケットが喪失した場合でも再送は行わない。ただし、電送されるデータを受信側が利用する際には、パケットを配信された順序に並び替える必要がある。

非特許文献１で記載されているＲＴＰ（Realtime Transport Protocol）では、パケットの喪失については無視するが、受信側でパケットを配信順序通りに容易に並び替えることができるように、ヘッダの中にパケットの配信順序を表す１６ビットのシーケンス番号を含んでいる。また、同様に、時刻情報を表すタイムスタンプをヘッダの中に含むことにより、配信側と受信側の間で時刻同期をとることを可能としている。

また、従来の技術としての非特許文献２では、ＲＴＰパケットのヘッダを除くペイロード部分を暗号化する手段を提供している。ここでは、暗号鍵とＲＴＰヘッダに含まれるシーケンス番号等の情報を用い、ＡＥＳ（Advanced Encryption Standard）のカウンタモードを用いて暗号鍵ストリームを生成し、ペイロード部分との排他的論理和を計算することにより暗号化する。

IETF Standard RFC 1889 RTP: A Transport Protocol for Real-Time Applications Jan.1996 IETF Standard RFC 3711 The Secure Real-time Transport Protocol (SRTP) Mar.2004

上記非特許文献２によるＲＴＰパケットの暗号化では、ブロック暗号を用いているが、実際には暗号鍵ストリームを生成するストリーム暗号として用いている。ストリーム暗号には、同一の暗号鍵ストリームを用いた場合に容易に解読されてしまう弱点がある等、安全性が低いという課題があった。
また、カウンタモードは比較的新しい暗号モードであるため、現存する暗号化ハードウェアが対応していない可能性があり、汎用的な暗号化ハードウェアを利用できないという課題があった。

この発明は上記のような課題を解決するためになされたもので、データが確実に伝送されることを保証しない通信路において、汎用的な暗号化ハードウェアを利用して、安全性の高いデータ通信を行うことができるデータ配信装置及びデータ通信システムを得ることを目的とする。

この発明に係るデータ配信装置は、データを分割してパケットを生成し、生成したパケットを識別するための情報をヘッダに付加するパケット生成手段と、データ受信装置との間で暗号鍵を共有している暗号鍵共有手段と、上記パケット生成手段により生成されたパケット内部のデータを所定のブロックに区切り、上記暗号鍵共有手段が共有している暗号鍵を使用してブロック毎にデータを暗号化すると共に、最初のブロックを暗号化する際には、初期ベクタとしてヘッダに含まれる上記パケットを識別するための情報を使用して暗号化し、以降の１つのブロックを暗号化する際には直前のブロックの暗号化結果を利用する暗号化方式により暗号化するパケット暗号化手段と、該パケット暗号化手段により暗号化されたパケットを通信路を介して上記データ受信装置に配信するパケット通信手段とを備えたものである。

この発明により、汎用的な暗号化ハードウェアを利用して、安全性の高いデータ通信を行うことができるという効果が得られる。

実施の形態１．
図１はこの発明の実施の形態１によるデータ通信システムの構成を示すブロック図である。このデータ通信システムは、映像・音声等のデータをＲＴＰにより配信する配信サーバ（データ配信装置）１と、配信サーバ１より配信される映像・音声等のデータを受信する受信クライアント（データ受信装置）２を備えている。

図１において、配信サーバ１は、ＲＴＰパケット生成部（パケット生成手段）１１、暗号鍵共有部（暗号鍵共有手段、第１の暗号鍵共有手段）１２、ＲＴＰパケット暗号化部（パケット暗号化手段）１３及びＲＴＰパケット通信部（パケット通信手段、第１のパケット通信手段）１４を備えている。また、受信クライアント２は、ＲＴＰパケット通信部（第２のパケット通信手段）２１、暗号鍵共有部（第２の暗号鍵共有手段）２２、ＲＴＰパケット復号部（パケット復号手段）２３及びＲＴＰパケット解読部（パケット解読手段）２４を備えている。配信サーバ１のＲＴＰパケット通信部１４と受信クライアント２のＲＴＰパケット通信部２１は通信路３１により接続され、暗号鍵共有部１２と暗号鍵共有部２２は通信路３２により接続されている。

図１の配信サーバ１において、ＲＴＰパケット生成部１１は、図示しない映像や音声等のデータを分割してＲＴＰパケットを生成し、生成したパケットを識別するための情報であるシーケンス番号や、時刻情報を表すタイムスタンプ等をＲＴＰヘッダに付加する。暗号鍵共有部１２は通信クライアント２との間で暗号鍵を共有している。

ＲＴＰパケット暗号化部１３は、ＲＴＰパケット生成部１１により生成されたパケット内部のデータを所定のブロックに区切り、暗号鍵共有手段１２が共有している暗号鍵を使用してブロック毎にデータを暗号化すると共に、最初のブロックを暗号化する際には、初期ベクタとしてＲＴＰヘッダに含まれるパケットを識別するための情報であるシーケンス番号を使用して暗号化し、以降の１つのブロックを暗号化する際には直前のブロックの暗号化結果を利用する暗号化方式により暗号化する。ＲＴＰパケット通信部１４はＲＴＰパケット暗号化部１３により暗号化されたＲＴＰパケットを通信路３１を介して受信クライアント２に配信する。

また、図１の受信クライアント２において、ＲＴＰパケット通信部２１は通信路３１を介して配信サーバ１から配信される暗号化されたＲＴＰパケットを受信する。暗号鍵共有部２２は配信サーバ１との間で暗号鍵を共有している。ＲＴＰパケット復号部２３は、ＲＴＰパケット通信部２１により受信されたＲＴＰパケットを、暗号鍵共有部２２が共有している暗号鍵を使用して復号する。ＲＴＰパケット解読部２４は、ＲＴＰパケット復号部２３により復号されたＲＴＰパケットから、元の映像や音声等のデータを復元する。

通信路３１はＲＴＰパケットを伝送し、例えばインターネット等のＩＰネットワークである。通信路３２は暗号鍵情報を伝送する通信路であり、通信路３１と同一の通信路であっても良いし、同等であるが別個の通信路であっても良いし、全く別の通信路であっても良い。

次に動作について説明する。
まず、配信サーバ１と受信クライアント２は、ＲＴＰプロトコルによるデータ通信を開始する前に、お互いの暗号鍵共有部１２及び暗号鍵共有部２２が、通信路３２を介して通信することにより、配信サーバ１及び受信クライアント２以外の第三者に内容を知られることなく、秘密に暗号鍵（図示しない）を共有している。この暗号鍵を共有する手段についてはここでは規定しないが、例えばＳＳＬ（Secure Socket Layer）を用いても良いし、ＭＩＫＥＹ(Multimedia Internet KEYing）を用いても良いし、その他の手段によっても良い。また、暗号鍵の生成は配信サーバ１側で行っても良いし、受信クライアント２側で行っても良い。

配信サーバ１において、ＲＴＰパケット生成部１１は、図示しない配信する映像や音声等のデータを一定長又は可変長のパケットサイズに収まるように分割する。分割するパケットサイズは、配信するデータの特性によって決めても良いし、通信路３１の特性によって決めても良いし、その他の理由によって決めても良い。例えば、映像データを配信する場合には、１つのＲＴＰパケットに１フレーム分の映像データを格納しても良いし、通信路３１としてＩＰ網を利用する場合には、ＩＰパケットのサイズが通常のＩＰ網で通信する際に標準的な１５００バイトになるように分割しても良いし、その他のサイズで分割しても良い。

ＲＴＰパケットはＲＴＰヘッダとＲＴＰペイロードで構成されるが、ＲＴＰパケット生成部１１は、上記手順において分割した配信するデータをＲＴＰペイロードに格納し、ＲＴＰペイロードの前に１６ビットのシーケンス番号等を含むＲＴＰヘッダを付加する。

ＲＴＰパケット暗号化部１３は、ＲＴＰパケット生成部１１により生成されたＲＴＰパケットのうちのＲＴＰペイロードを所定のブロックに区切り、暗号鍵共有部１２が受信クライアント２と共有している暗号鍵を用いて、ＤＥＳ（Data Encryption Standard）やＡＥＳ（Advanced Encryption Standard）等の共通暗号鍵暗号方式のうち、ブロック暗号に分類される暗号化方式によってブロック毎に暗号化する。安全性を確保するため、ＲＴＰパケット暗号化部１３は、ブロック暗号の暗号モードとして、前のブロックの暗号化結果を次のブロックの暗号化に反映させる、例えばＣＢＣ（Cipher Block Chaining）モードの暗号化方式を使用する。

ＣＢＣモードで暗号化したデータを通信し、受信側の受信クライアント２で正常に復号を行うためには、全てのブロックが誤りなく伝送されることが必要条件となる。ＩＰネットワークのようなパケットを単位として通信する通信路３１では、データの喪失はパケット単位で発生するため、１つのパケットが喪失した場合に、受信側での以降のパケットの復号処理が不可能とならないためには、暗号化の際の初期ベクタとして前のパケットの最後の暗号化結果を用いることはできない。

そこで、この実施の形態１では、ＲＴＰパケット暗号化部１３はシーケンス番号を初期ベクタの長さになるまでパディングした値を初期ベクタとして使用する。ＲＴＰヘッダに含まれるシーケンス番号は、パケット毎に変化する値であり、また暗号化されないＲＴＰヘッダに含まれるため配信側と受信側で必ず共有される。ＲＴＰパケット通信部１４は、ＲＴＰパケット暗号化部１３により暗号化されたＲＴＰパケットを、通信路３１を通じて受信クライアント２のＲＴＰパケット通信部２１に配信する。

受信クライアント２では、ＲＴＰパケット通信部２１は受信した暗号化されたＲＴＰパケットをＲＴＰパケット復号部２３に出力する。ＲＴＰパケット復号部２３は、暗号鍵共有部２２から配信サーバ１との間で共有する暗号鍵を受け取り、暗号鍵とＲＴＰヘッダに含まれるシーケンス番号を用いてＲＴＰペイロードを復号する。復号されたＲＴＰパケットはＲＴＰパケット解読部２４に出力される。ＲＴＰパケット解読部２４は、ＲＴＰパケット復号部２３により復号されたＲＴＰパケットから元のデータを復元し、データを必要とする図示しない処理部に出力する。図示しない処理部とは、例えば、配信されたデータが映像であった場合には映像復号部及び映像表示部で、配信されたデータが音声であった場合には音声復号部及び音声再生部等である。

この実施の形態１では、ＲＴＰパケット生成部（パケット生成手段）１１がＲＴＰパケットを生成し、ＲＴＰパケット暗号化部（パケット暗号化手段）１３が初期ベクタとしてＲＴＰヘッダに含まれるシーケンス番号を使用して暗号化しているが、パケット生成手段がＩＰパケットを生成し、パケット暗号化手段が初期ベクタとしてＩＰヘッダに含まれるＩＤ（識別子）を使用して暗号化しても良く、パケット生成手段がＵＤＰパケットを生成し、パケット暗号化手段が初期ベクタとしてＵＤＰヘッダに含まれるＩＤ（識別子）を使用して暗号化しても良い。

以上のように、この発明の実施の形態１によれば、ＲＴＰパケット暗号化部１２が、ＲＴＰパケット生成部１１により生成されたパケット内部のデータを所定のブロックに区切り、暗号鍵共有手段１２が共有している暗号鍵を使用してブロック毎にデータを暗号化すると共に、最初のブロックを暗号化する際には、初期ベクタとしてＲＴＰヘッダに含まれるパケットを識別するための情報であるシーケンス番号を使用して暗号化し、以降の１つのブロックを暗号化する際には直前のブロックの暗号化結果を利用するＣＢＣモードの暗号化方式により暗号化することにより、ＩＰネットワークのようなデータが確実に伝送されることを保証しない通信路３１において、汎用的な暗号化ハードウェアを利用して、安全性の高いデータ通信を行うことができるという効果が得られる。

実施の形態２．
この発明の実施の形態２によるデータ通信システムの構成を示すブロック図は、上記実施の形態１の図１と同じである。上記実施の形態１では、ＲＴＰヘッダに含まれるシーケンス番号を初期ベクタとして利用しているが、この発明の実施の形態２では、シーケンス番号を暗号化した値を初期ベクタとして使用するものである。

図２はこの発明の実施の形態２によるデータ通信システムにおける配信サーバのＲＴＰパケット暗号化部のＣＢＣモードの動作を説明する図である。図２において、平文ブロック４１はＲＴＰペイロードをブロックサイズ毎に区切った最初の平文ブロックで、平文ブロック４２はＲＴＰペイロードをブロックサイズ毎に区切った２番目の平文ブロックである。暗号ブロック４３は平文ブロック４１を暗号化した結果であり、暗号ブロック４４は平文ブロック４２を暗号化した結果である。排他的論理和計算部４５ａ，４５ｂ，４５ｃは、２つの入力の排他的論理和を計算するものであり、図中には説明の都合上３つ記してあるが、１つのハードウェアで構成しても良い。暗号化部４６ａ，４６ｂ，４６ｃは、暗号鍵共有部１２が共有している暗号鍵を用いて暗号化を行うものであり、図中には説明の都合上３つ記してあるが、１つのハードウェアで構成しても良い。

また、図２において、シーケンス番号４７はＲＴＰヘッダに含まれるシーケンス番号を平文ブロック４１や平文ブロック４２と同じサイズになるまでパディングした値である。初期ベクタ４８は配信サーバ１と受信クライアント２で共有している所定の値の初期ベクタである。暗号ブロック４９はシーケンス番号４７と初期ベクタ４８との排他的論理和計算結果を暗号化した結果であり、上記実施の形態１で使用している初期ベクタに相当するものである。すなわち、この実施の形態２では、シーケンス番号４７を暗号化した値を初期ベクタとして使用している。

次に動作について説明する。
まず、排他的論理和計算部４５ａはシーケンス番号４７と所定の値の初期ベクタ４８の排他的論理和を計算して暗号化部４６ａに出力する。暗号化部４６ａは暗号鍵共有部１２が共有している暗号鍵を使用して暗号化を行って暗号ブロック４９を出力する。

これ以降の排他的論理和計算部４５ｂの処理は、暗号ブロック４９を初期ベクタと見た場合の、通常のＣＢＣモードと同様となる。排他的論理和計算部４５ｂは平文ブロック４１と暗号ブロック４９の排他的論理和を計算して暗号化部４６ｂに出力する。暗号化部４６ｂは暗号鍵共有部１２が共有している暗号鍵を使用して暗号化を行って暗号ブロック４３を出力する。続いて、排他的論理和計算部４５ｃは平文ブロック４２と暗号ブロック４３の排他的論理和を計算して暗号化部４６ｃに出力する。暗号化部４６ｃは暗号鍵共有部１２が共有している暗号鍵を使用して暗号化を行って暗号ブロック４４を出力する。

ＲＴＰパケット暗号化部１３がこのような処理を図示しないＲＴＰペイロードを区切った最後の平文ブロックまで連続して行うことにより、暗号ブロック４９から図示しない最後の暗号ブロックまでが出力される。ＲＴＰパケット暗号化部１３は、これらのうち暗号ブロック４９を除く全ての暗号ブロックを連結してＲＴＰペイロードに格納する。

受信クライアント２のＲＴＰパケット復号部２３は、配信サーバ１のＲＴＰパケット暗号部１３と逆の処理を行うことにより、平文ブロック４１から図示しない最後の平文ブロックまでを連結した平文データを得る。

ここで、所定の値の初期ベクタ４８としては、値０を必ず利用することとしても良いし、０以外の固定値を必ず利用することとしても良いし、暗号鍵と同様にランダムに決定した値を配信サーバ１と受信クライアント２の間で秘密に共有しても良い。

この実施の形態２では、初期ベクタ４８として値０又は固定値を利用する場合は、配信サーバ１と受信クライアント２の間で秘密に共有する値を暗号鍵のみとすることができ、しかも、上記実施の形態１と比較して安全性を向上させることができる。また、初期ベクタ４８としてランダム値を秘密に共有する場合には、さらに安全性を向上させることができる。いずれの場合でも、図２により明らかであるように、実施の形態２により処理を追加しても、通常のＣＢＣモードと同様な処理を行っているため、汎用的なＣＢＣモードによる暗号化ハードウェアを利用することが可能である。

以上のように、この実施の形態２によれば、上記実施の形態１と同様の効果が得られると共に、ＲＴＰパケット暗号化部１３がシーケンス番号を暗号化した値を初期ベクタとして使用して暗号化することにより、さらに安全性を向上させることができるという効果が得られる。

実施の形態３．
この発明の実施の形態３によるデータ通信システムの構成を示すブロック図は、上記実施の形態１の図１と同じである。この実施の形態３では、ＲＴＰパケット暗号化部１３が初期ベクタとしてシーケンス番号を拡張した拡張シーケンス番号を使用して暗号化するものである。

図３はこの発明の実施の形態３によるデータ通信システムにおける配信サーバのＲＴＰパケット暗号化部のＣＢＣモードの動作を説明する図である。図３において、拡張シーケンス番号５０はＲＴＰヘッダに含まれる１６ビットのシーケンス番号を任意の長さに拡張したものであり、その他の符号４１〜４９は図２と同様のものである。

ＲＴＰのシーケンス番号は１６ビットの値であるため、シーケンス番号６５５３５のパケットを配信した後、シーケンス番号は巡回し０となる。巡回した回数を任意のビット数のカウンタにより数えておき、このカウンタの値とシーケンス番号とを連結した値を拡張シーケンス番号５０として用いる。このカウンタのビット数を適切に設定することにより、２つ以上のＲＴＰパケットの暗号化に、同一の初期ベクタが用いられる可能性を無視できる程低減することができる。

次に動作について説明する。
排他的論理和計算部４５ａは拡張シーケンス番号５０と所定の値の初期ベクタ４８の排他的論理和を計算して暗号化部４６ａに出力する。暗号化部４６ａは暗号鍵共有部１２が共有している暗号鍵を使用して暗号化を行って暗号ブロック４９を出力する。これ以降の処理は上記実施の形態２と同様に通常のＣＢＣモードとなる。

なお、このカウンタの値については、配信サーバ１及び受信クライアント２の間で共有する必要があるが、ＲＴＰパケットの拡張ヘッダに格納して配信しても良いし、配信サーバ１及び受信クライアント２の各々にこのカウンタを独立して設け、各々で独立してカウントしても良い。

ここで、この発明の実施の形態３による効果を説明するために、通信路３１上で伝送されるデータを差し替えることができる図示しない第三者が存在した場合を考える。
上記実施の形態１及び上記実施の形態２によるデータ通信システムでは、配信サーバ１が配信したデータを、図示しない第三者が差し替えた場合、受信クライアント２ではデータが差し替えられたことを認識できないことがある。すなわち、第三者が１６ビットのシーケンス番号が一巡する間のＲＴＰパケットを全て記録しておき、二巡目以降のＲＴＰパケットを記録した一巡目のＲＴＰパケットに差し替えて配信する。受信クライアント２のＲＴＰパケット復号部２３では、シーケンス番号４７、初期ベクタ４８及び図示しない暗号鍵が一致していれば正常に復号できるため、差し替えられたことを検知できない。一方、この実施の形態３では、シーケンス番号を拡張することにより実用上シーケンス番号が巡回しないようにすることができ、上記のような攻撃を防止することが可能となる。

以上のように、この実施の形態３によれば、上記実施の形態２と同様の効果が得られると共に、暗号ブロック４９の値がより推測しづらくなり、また、上記のような種類の攻撃を防止可能となり、上記実施の形態２と比較して、より安全性を高めることができるという効果が得られる。

なお、この実施の形態３では、拡張シーケンス番号５０を暗号化しているが、上記実施の形態１と同様に暗号化しなくても良い。

実施の形態４．
この発明の実施の形態４によるデータ通信システムの構成を示すブロック図は、上記実施の形態１の図１と同じである。また、配信サーバのＲＴＰパケット暗号化部のＣＢＣモードの動作を説明する図は上記実施の形態３の図３と同じである。この実施の形態４では、上記実施の形態３の拡張シーケンス番号に関し、上記カウンタの初期値としてランダムに設定された値を使用し、その値を配信サーバ１と受信クライアント２の間で秘密に共有して独立してカウントする。

以上のように、この実施の形態４によれば、上記実施の形態３と同様の効果が得られると共に、拡張シーケンス番号の一部を秘密とすることにより、仮に同一の鍵で複数のデータ配信を行った場合でも、上記実施の形態３で記述したような通信路上に介在する第三者による攻撃を防止することが可能となるという効果が得られる。

実施の形態５．
この発明の実施の形態５によるデータ通信システムの構成を示すブロック図は、上記実施の形態１の図１と同じである。この実施の形態５では、上記実施の形態１〜上記実施の形態４において用いたシーケンス番号４７や拡張シーケンス番号５０に加え、ＲＴＰヘッダに含まれる時刻情報を表すタイムスタンプを利用することを特徴とする。

図４はこの発明の実施の形態５によるデータ通信システムにおける配信サーバのＲＴＰパケット暗号化部のＣＢＣモードの動作を説明する図である。図４において、排他的論理和計算部４５ｄは２つの入力の排他的論理和を計算するもので、暗号化部４６ｄは図示しない暗号鍵を用いて暗号化を行うもので、タイムスタンプ５１は時刻情報を表すものでＲＴＰヘッダに含まれており、暗号ブロック５２はタイムスタンプ５１と所定の初期ベクタ４８の排他的論理和を暗号化した結果である。その他の符号４１〜５０については図３と同様である。

次に動作について説明する。
排他的論理和計算部４５ｄは、タイムスタンプ５１と所定の初期ベクタ４８の排他的論理和を計算して暗号化部４６ｄに出力する。暗号化部４６ｄは暗号鍵共有部１２が共有している暗号鍵を用いて暗号化を行い、暗号ブロック５２を出力する。以降の動作は図３と同様である。

以上のように、この実施の形態５によれば、上記実施の形態３と同様の効果が得られると共に、暗号化の際に利用する値として、時刻情報を表すタイムスタンプ５１を利用することにより更に安全性を高めることができ、さらに、汎用的なＣＢＣモードで暗号化するハードウェアを利用できるという効果が得られる。

なお、この実施の形態５では、図４の構成により、拡張シーケンス番号５０とタイムスタンプ５１を利用して暗号化しているが、上記実施の形態３の図３の構成により、拡張シーケンス番号５０を、シーケンス番号４７とタイムスタンプ５１を連結したものに置き換え、初期ベクタ４８の排他的論理和の暗号化結果を暗号ブロック４９としても良い。

また、この実施の形態５では、拡張シーケンス番号５０とタイムスタンプ５１を利用してデータを暗号化しているが、シーケンス番号４７とタイムスタンプ５１を利用してデータを暗号化しても良い。

さらに、この実施の形態５では、拡張シーケンス番号５０とタイムスタンプ５１を暗号化しているが、上記実施の形態１と同様に暗号化しなくても良い。

この発明の実施の形態１によるデータ通信システムの構成を示すブロック図である。この発明の実施の形態２によるデータ通信システムにおける配信サーバのＲＴＰパケット暗号化部のＣＢＣモードの動作を説明する図である。この発明の実施の形態３によるデータ通信システムにおける配信サーバのＲＴＰパケット暗号化部のＣＢＣモードの動作を説明する図である。この発明の実施の形態５によるデータ通信システムにおける配信サーバのＲＴＰパケット暗号化部のＣＢＣモードの動作を説明する図である。

符号の説明

１配信サーバ、２受信クライアント、１１ＲＴＰパケット生成部、１２暗号鍵共有部、１３ＲＴＰパケット暗号化部、１４ＲＴＰパケット通信部、２１ＲＴＰパケット通信部、２２暗号鍵共有部、２３ＲＴＰパケット復号部、２４ＲＴＰパケット解読部、３１通信路、３２通信路、４１平文ブロック、４２平文ブロック、４３暗号ブロック、４４暗号ブロック、４５ａ，４５ｂ，４５ｃ，４５ｄ排他的論理和計算部、４６ａ，４６ｂ，４６ｃ，４６ｄ暗号化部、４７シーケンス番号、４８初期ベクタ、４９暗号ブロック、５０拡張シーケンス番号、５１タイムスタンプ、５２暗号ブロック。

Claims

データを分割してパケットを生成し、生成したパケットを識別するための情報をヘッダに付加するパケット生成手段と、
データ受信装置との間で暗号鍵を共有している暗号鍵共有手段と、
上記パケット生成手段により生成されたパケット内部のデータを所定のブロックに区切り、上記暗号鍵共有手段が共有している暗号鍵を使用してブロック毎にデータを暗号化すると共に、最初のブロックを暗号化する際には、初期ベクタとしてヘッダに含まれる上記パケットを識別するための情報を使用して暗号化し、以降の１つのブロックを暗号化する際には直前のブロックの暗号化結果を利用する暗号化方式により暗号化するパケット暗号化手段と、
該パケット暗号化手段により暗号化されたパケットを通信路を介して上記データ受信装置に配信するパケット通信手段とを備えたデータ配信装置。
上記パケット暗号化手段は暗号化方式としてＣＢＣ（Cipher Block Chaining）モードを使用することを特徴とする請求項１記載のデータ配信装置。
上記パケット生成手段はＩＰ（Internet Protocol）パケットを生成し、上記パケット暗号化手段は上記初期ベクタとしてＩＰヘッダに含まれるＩＤ（識別子）を使用することを特徴とする請求項１記載のデータ配信装置。
上記パケット生成手段はＵＤＰ（User Datagram Protocol）パケットを生成し、上記パケット暗号化手段は上記初期ベクタとしてＵＤＰヘッダに含まれるＩＤを使用することを特徴とする請求項１記載のデータ配信装置。
上記パケット生成手段はＲＴＰ（Realtime Transport Protocol）パケットを生成し、上記パケット暗号化手段は上記初期ベクタとしてＲＴＰヘッダに含まれるシーケンス番号を使用することを特徴とする請求項１記載のデータ配信装置。
上記パケット暗号化手段は、上記初期ベクタとして上記シーケンス番号を暗号化した値を使用し、上記シーケンス番号の暗号化の際に、上記受信クライアントとの間で共有する所定の初期ベクタを使用した上記暗号化方式及び上記暗号鍵により暗号化することを特徴とする請求項５記載のデータ配信装置。
上記パケット暗号化手段は、上記初期ベクタとして、上記ＲＴＰヘッダに含まれるシーケンス番号が値の上限を超え巡回した回数を数えるカウンタの値と上記シーケンス番号を連結した拡張シーケンス番号を使用することを特徴とする請求項５記載のデータ配信装置。
上記パケット暗号化手段は、上記初期ベクタとして上記拡張シーケンス番号を暗号化した値を使用し、上記拡張シーケンス番号の暗号化の際に、上記受信クライアントとの間で共有する所定の初期ベクタを使用した上記暗号化方式及び上記暗号鍵により暗号化することを特徴とする請求項７記載のデータ配信装置。
上記パケット暗号化手段は、上記カウンタの初期値としてランダムに設定された値を使用し、その値を上記受信クライアントとの間で共有することを特徴とする請求項７又は請求項８記載のデータ配信装置。
上記パケット暗号化手段は上記初期ベクタとして上記拡張シーケンス番号及びＲＴＰヘッダに含まれる時刻情報を表すタイムスタンプを使用することを特徴とする請求項５記載のデータ配信装置。
上記パケット暗号化手段は、上記初期ベクタとして上記拡張シーケンス番号及び上記タイムスタンプを暗号化した値を使用し、上記拡張シーケンス番号及びタイムスタンプの暗号化の際に、上記受信クライアントとの間で共有する所定の初期ベクタを使用した上記暗号化方式及び上記暗号鍵により暗号化することを特徴とする請求項１０記載のデータ配信装置。
データを配信するデータ配信装置と配信されたデータを受信するデータ受信装置とを備えたデータ通信システムにおいて、
上記データ配信装置は、
データを分割してパケットを生成し、生成したパケットを識別するための情報をヘッダに付加するパケット生成手段と、
上記データ受信装置との間で暗号鍵を共有している第１の暗号鍵共有手段と、
上記パケット生成手段により生成されたパケット内部のデータを所定のブロックに区切り、上記第１の暗号鍵共有手段が共有している暗号鍵を使用してブロック毎にデータを暗号化すると共に、最初のブロックを暗号化する際には、初期ベクタとしてヘッダに含まれる上記パケットを識別するための情報を使用して暗号化し、以降の１つのブロックを暗号化する際には直前のブロックの暗号化結果を利用する暗号化方式により暗号化するパケット暗号化手段と、
該パケット暗号化手段により暗号化されたパケットを通信路を介して上記データ受信装置に配信する第１のパケット通信手段とを備え、
上記データ受信装置は、
上記第１のパケット通信手段により配信されたデータを受信する第２のパケット通信手段と、
上記データ配信装置との間で暗号鍵を共有している第２の暗号鍵共有手段と、
上記第２のパケット通信手段により受信されたパケットを、上記第２の暗号鍵共有手段が共有している暗号鍵を使用して復号するパケット復号手段と、
該パケット復号手段により復号されたパケットからデータを復元するパケット解読手段とを備えたことを特徴とするデータ通信システム。