JP2004056776A

JP2004056776A - データ送信装置、データ受信装置、データ伝送システム及びデータ伝送方法

Info

Publication number: JP2004056776A
Application number: JP2003151166A
Authority: JP
Inventors: Hideyuki Kuwano; 桑野　秀之; Hiroyuki Iizuka; 飯塚　裕之
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Holdings Corp
Priority date: 2002-05-29
Filing date: 2003-05-28
Publication date: 2004-02-19

Abstract

【課題】従来のＩＥＥＥ１３９４におけるＡｓｙｎｃｈｒｏｎｏｕｓ転送においてもコンテンツの著作権保護を可能とするデータ伝送システムを提供する。
【解決手段】Ｃｏｎｔｒｏｌｌｅｒ２０は、Ｃｏｎｓｕｍｅｒ４０に対して、Ａｓｙｎｃｈｒｏｎｏｕｓ転送でデータを送受信するためのプラグ等を予約する（ステップ２１１、ステップ２１２）。更に、Ｃｏｎｔｒｏｌｌｅｒ２０は、Ｐｒｏｄｕｃｅｒ３０に対して、コンテンツ等を送信するためのプラグ等を確保するためのコマンドを送信し（ステップ２１３）、Ｐｒｏｄｕｃｅｒ３０から送信用のＰｒｏｄｕｃｅｒプラグ等の情報を受信する（ステップ２１４）。Ｃｏｎｔｒｏｌｌｅｒ２０は、Ｃｏｎｓｕｍｅｒ４０に対してＰｒｏｄｕｃｅｒ３０のポートの情報を通知し（ステップ２１５）、Ｃｏｎｓｕｍｅｒ４０からのレスポンスを受信する（ステップ２１６）。Ｃｏｎｓｕｍｅｒ４０は、Ｐｒｏｄｕｃｅｒ３０に対して機器認証要求コマンドを発行し（ステップ２１９）、互いに機器認証と鍵の交換とを行なう（ステップ２１７）。
【選択図】　図２

Description

【０００１】
【発明の属する技術分野】
本発明は、映像コンテンツや音声コンテンツなどのディジタルデータの送受信に係るデータ送信装置及びデータ受信装置、並びにデータ伝送方法及びデータ伝送システムに関し、特にデータ伝送時における映像コンテンツ等の著作権保護技術に関する。
【０００２】
【従来の技術】
従来におけるディジタルデータの伝送方式として、ＩＥＥＥ１３９４シリアルバスインタフェース規格（以下、「ＩＥＥＥ１３９４」という。）（例えば、非特許文献１参照）に基づくデータ伝送方式がある。このデータ伝送方式を用いた通信には、映像信号や音声信号などのように、データ伝送レートをほぼ一定に保つことが要求されるデータの伝送に適したＩｓｏｃｈｒｏｎｏｕｓ通信と、制御信号などのように、データ伝送レートが一定か否かは問わないが確実に通信できることが要求されるデータの伝送のためのＡｓｙｎｃｈｒｏｎｏｕｓ通信とがある。なお、両通信におけるそれぞれの１単位のデータをＩＥＥＥ１３９４のバス上で混在させることも可能である。
【０００３】
ここで、上記のＩＥＥＥ１３９４、Ｉｓｏｃｈｒｏｎｏｕｓ通信及びＡｓｙｎｃｈｒｏｎｏｕｓ通信の概要について説明する。
図２０は、ディジタル映像信号やディジタル音声信号の伝送にＩＥＥＥ１３９４を利用する場合のＡＶ（Ａｕｄｉｏ　Ｖｉｓｕａｌ）プロトコルスタックを示す図である。図２０に示すように、ＩＥＥＥ１３９４は、下位の層のプロトコルとして規定されている。そして、これを用いる上位の層のプロトコルとして、主にコンピュータの周辺記憶装置に用いる、ＩＥＥＥ１３９４上でＳＣＳＩプロトコルを効率的に伝送することを目的としたＳＢＰ−２や、ネットワークを意識してＩＥＥＥ１３９４上でＩＰｖ４のｄａｔａｇｒａｍを送信するＩＰ　ｏｖｅｒ　１３９４や、ＡＶ情報などリアルタイムデータ伝送を意識したＡＶプロトコル（ＩＥＥＥ　６１８８３）など、様々なプロトコルが提案されている。中でもＡＶプロトコル１０２は、多くのディジタルＡＶ装置で実装されており、ＩＥＥＥ１３９４普及の牽引役となっている。
【０００４】
ＡＶプロトコル１０２は、Ｉｓｏｃｈｒｏｎｏｕｓパケットを用いて映像、音声などのリアルタイムデータを伝送することを主な目的とした規約である。このＡＶプロトコル１０２は、リアルタイムデータ伝送１０３、信号伝送手順１０４、コントロール信号１０５の３つの要素から構成されている。
【０００５】
リアルタイムデータ伝送１０３は、様々なフォーマットのデータをＩｓｏｃｈｒｏｎｏｕｓパケットに格納し、ＩＥＥＥ１３９４バスを介して伝送するために、必要な付加情報やパケット化の方法を規定している。信号伝送手順１０４は、ＩＥＥＥ１３９４バスによって接続された装置間でＩｓｏｃｈｒｏｎｏｕｓパケットを用いてデータをやり取りする際の、装置間の入出力経路を確立する手順を規定している。この場合、「プラグ」という概念を用いることにより、装置間に仮想的な伝送路が確立される。コントロール信号１０５は、ＩＥＥＥ１３９４バスを通して、接続された装置の動作を制御するための制御信号について規定している。この制御信号は、Ａｓｙｎｃｈｒｏｎｏｕｓパケットによって伝送される。
【０００６】
上記のように、ＡＶプロトコル１０２では、信号伝送手順１０４として、論理的な信号接続を行なうために「プラグ」という概念を提供している。プラグは仮想的なものであり、入力プラグと出力プラグとがある。上記の装置は、入力プラグや出力プラグを物理的な接続端子とは無関係に複数個持つことができる。入力プラグと出力プラグをデータチャネルに接続して信号経路を制御することをコネクション管理という。
【０００７】
以下では、Ｉｓｏｃｈｒｏｎｏｕｓ通信及びＡｓｙｎｃｈｒｏｎｏｕｓ通信の概要について説明する。図２１は、Ｉｓｏｃｈｒｏｎｏｕｓ通信におけるＩｓｏｃｈｒｏｎｏｕｓパケットのパケット構造図である。Ｉｓｏｃｈｒｏｎｏｕｓ通信においては、図２１のＩｓｏｃｈｒｏｎｏｕｓパケットの単位でデータ伝送が行なわれる。Ｉｓｏｃｈｒｏｎｏｕｓパケットのデータサイズは、伝送レートによって異なる。送信側は、特定のノードにデータを送信するのではなく、０〜６３のチャネル番号を使用してバス全体にパケットを送る。受信ノードは、自分が受信したいチャネル番号のパケットを選択してデータを取り込む。従って、特定のノード間でＩｓｏｃｈｒｏｎｏｕｓ通信を行なう場合には、送信ノードと受信ノードとの間で、予め使用するチャネル番号をお互いに認識しておく必要がある。
【０００８】
図２２は、Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるＡｓｙｎｃｈｒｏｎｏｕｓパケットのパケット構造図である。Ａｓｙｎｃｈｒｏｎｏｕｓ通信においては、図２２のＡｓｙｎｃｈｒｏｎｏｕｓパケットの単位でデータ伝送が行なわれる。このパケットの最大データサイズ（最大ペイロード長）は、伝送レートに応じて、５１２［バイト］から４０９６［バイト］の範囲で規定される。Ａｓｙｎｃｈｒｏｎｏｕｓ通信には、「Ｒｅａｄ」、「Ｗｒｉｔｅ」、「Ｌｏｃｋ」の３種類のトランザクション（処理）がある。Ｒｅａｄトランザクションは、相手ノードの目的のアドレスから所定のデータ長のデータを読み出す。Ｗｒｉｔｅトランザクションは、相手ノードの目的のアドレスに対して所定のデータ長のデータを書き込む。Ｌｏｃｋトランザクションは、相手ノードの目的のアドレスに対して条件付きで所定のデータ長のデータを書き込む。ＲｅａｄトランザクションやＷｒｉｔｅトランザクションは、主にデータ伝送に、Ｌｏｃｋトランザクションは、主にコマンドなどの送信に利用される。
【０００９】
以下では、従来のＡｓｙｎｃｈｒｏｎｏｕｓ通信における通信シーケンスについて、図２３を用いて説明する。
まず、Ｃｏｎｔｒｏｌｌｅｒ１２０は、Ｃｏｎｓｕｍｅｒ１４０に対して「ＡＬＬＯＣＡＴＥコマンド」を送信してＣｏｎｓｕｍｅｒ１４０の受信プラグを予約する（ステップ１０１）。Ｃｏｎｓｕｍｅｒ１４０は、「ＡＬＬＯＣＡＴＥコマンド」を受信すると、プラグを予約して「ＡＣＣＥＰＴＥＤレスポンス」をＣｏｎｔｒｏｌｌｅｒ１２０に返信する（ステップ１０２）。次に、Ｃｏｎｔｒｏｌｌｅｒ１２０は、Ｃｏｎｓｕｍｅｒ１４０から「ＡＣＣＥＰＴＥＤ　レスポンス」を受信すると、Ｐｒｏｄｕｃｅｒ１３０に「ＡＬＬＯＣＡＴＥ＿ＡＴＴＡＣＨコマンド」を送信する（ステップ１０３）。
【００１０】
これにより、Ｐｒｏｄｕｃｅｒ１３０は、Ｐｒｏｄｕｃｅｒポートをコネクトして「ＡＣＣＥＰＴＥＤ　レスポンス」をＣｏｎｔｒｏｌｌｅｒ１２０に返信する（ステップ１０４）。Ｃｏｎｔｒｏｌｌｅｒ１２０は、Ｐｒｏｄｕｃｅｒ１３０から「ＡＣＣＥＰＴＥＤ　レスポンス」を受信すると、Ｃｏｎｓｕｍｅｒ１４０に対して「ＡＴＴＡＣＨコマンド」を送信する（ステップ１０５）。Ｃｏｎｓｕｍｅｒ１４０は、「ＡＴＴＡＣＨコマンド」を受信すると、Ｃｏｎｓｕｍｅｒポートをコネクトして「ＡＣＣＥＰＴＥＤ　レスポンス」をＰｒｏｄｕｃｅｒ１３０に返信する（ステップ１０６）。以上の処理により、Ａｓｙｎｃｈｒｏｎｏｕｓコネクションが確立され、データ転送（ステップ１０７）が可能となる。
【００１１】
先に述べたように、リアルタイムデータ伝送１０３におけるＩｓｏｃｈｒｏｎｏｕｓ通信は、受信装置を特定しないブロードバンド型のデータ通信方式であり、ＩＥＥＥ１３９４バスに接続されている全ての装置がバス上のデータを参照することができる。しかしながら、映像データや音声データについては、その著作権の保護が必要となる場合がある。
【００１２】
そこで、ＩＥＥＥ１３９４バスを介して接続した装置間で送受信されるディジタルコンテンツを保護するための仕組みとして、５ＣＤＴＣＰ（Ｆｉｖｅ　Ｃｏｍｐａｎｙ　Ｄｉｇｉｔａｌ　Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｃｏｎｔｅｎｔ　Ｐｒｏｔｅｃｔｉｏｎ　ｓｙｓｔｅｍ）（以下、適宜、ＤＴＣＰという）が定められた。このＤＴＣＰは、コピー制限されたディジタルコンテンツを送受信する際に、送信装置と受信装置との間で予め暗号化／復号化の処理が正しく取り扱えるかどうかの認証を行ない、送信装置と受信装置との間でのみ可能な方式を用いてディジタルコンテンツを暗号化してデータの送受信を行なうものである。
【００１３】
以下では、ＩＥＥＥ１３９４に基づくＤＴＣＰにおけるコンテンツの保護方式について、図２４を用いて説明する。
図２４は、機器認証と暗号鍵の交換に係る通信シーケンスの概略図である。ＩＥＥＥ１３９４におけるＤＴＣＰは、上記のＩｓｏｃｈｒｏｎｏｕｓパケットによるデータ転送（以下、「Ｉｓｏｃｈｒｏｎｏｕｓ転送」という。）を想定して定義されている。Ｉｓｏｃｈｒｏｎｏｕｓ転送は、前述のようにブロードバンド型の送信方式であるため、バス上にデータが送信されると、データ受信装置はそのバスに接続された時点からデータを受信することが可能となる。
【００１４】
図２４に示すように、ＤＴＣＰにおいては、コピー制限のあるディジタルコンテンツをＩｓｏｃｈｒｏｎｏｕｓ転送方式で送信する場合は、まず、受信側のＳｉｎｋ１４０から送信側のＳｏｕｒｃｅ１３０に機器認証要求を発行する（ステップ１２１）。その際、Ｓｉｎｋ１４０は、Ｓｏｕｒｃｅ１３０に対して受信側のパラメータを送信する。Ｓｏｕｒｃｅ１３０は、受信したパラメータが正しければＳｉｎｋ１４０に対して送信側のパラメータを送信する。逆に、受信したパラメータが正しくなければ、Ｓｏｕｒｃｅ１３０は、データ送信を拒絶する旨の通知をＳｉｎｋ１４０に行なう。送信側と受信側のパラメータが相互に交換されたら、それぞれ共通の認証鍵を算出する（ステップ１２３、ステップ１２６）。認証鍵の算出が済むと、Ｓｏｕｒｃｅ１３０は、算出した認証鍵を用いて、コンテンツを暗号化するための暗号鍵を暗号化して（ステップ１２４）、Ｓｉｎｋ１４０に送信する（ステップ１２５）。Ｓｉｎｋ１４０側では、算出した認証鍵に基づいて受信した暗号鍵を復号する（ステップ１２７）。Ｓｏｕｒｃｅ１３０は、暗号鍵を用いてコンテンツを暗号化して送信し（ステップ１２９）、Ｓｉｎｋ１４０は、受信した暗号化されたコンテンツを復号化する（ステップ１３０）。このように、従来のＩｓｏｃｈｒｏｎｏｕｓ転送では、伝送時におけるコンテンツ等の保護を行なっている。
【００１５】
上述したように、ＩＥＥＥ１３９４においては、ＤＴＣＰによるコンテンツの保護はＩｓｏｃｈｒｏｎｏｕｓ転送を前提としており、Ａｓｙｎｃｈｒｏｎｏｕｓ転送については規定されていない。これは、Ｉｓｏｃｈｒｏｎｏｕｓ転送は、主にビデオストリームや音声データなどの著作権が重要視されるコンテンツの送信を主な目的としているが、Ａｓｙｎｃｈｒｏｎｏｕｓ転送は、コマンドの伝送や外部ストレージのデータ伝送など暗号化すると制御手順が煩雑になったり処理速度が遅くなったりすることや、特定のノードＩＤを指定して行なう送信であって基本的には指定されたノードＩＤ以外の装置では受信できない仕様であることが一因だと考えられる。
【００１６】
しかし、近年、ＰＤＦ（Ｐｏｒｔａｂｌｅ　Ｄｏｃｕｍｅｎｔ　Ｆｏｒｍａｔ、アドビ社の商標）などのように、コンテンツ作成者の意匠を再現できるような静止画データや高画質なイメージデータによって現される被写体について肖像権が問題になるようなデータを扱う機会が多くなっており、そのようなデータのコンテンツ保護も必要になっている。データ保護を行なわないと、悪意のある装置がバスの中間に存在していた場合、ノードＩＤを詐称してデータを搾取してしまうことも考えられる。
【００１７】
従って、Ｉｓｏｃｈｒｏｎｏｕｓ転送で送信するよりもＡｓｙｎｃｈｒｏｎｏｕｓ転送で送信した方が都合が良いデータにおいても、伝送上のデータ保護が必要な場合がある。そして、その保護方式は、ＡＶ装置においてはＩＥＥＥ１３９４バスを持つ装置が数多く市場に存在していることを考慮すると、比較的変更の度合いが小さく、かつ効果的な伝送方式であることが望ましい。つまり、Ｉｓｏｃｈｒｏｎｏｕｓ転送で実現しているＤＴＣＰのコンテンツ保護方式を踏襲したＡｓｙｎｃｈｒｏｎｏｕｓ転送を実現し得る伝送方式が望まれる。
【００１８】
また、ＤＴＣＰのコンテンツ保護方式を非同期伝送に適用した例として、ＤＴＣＰのＵＳＢ適用（ＤＴＣＰ　Ｖｏｌｕｍｅ　１　Ｓｕｐｐｌｅｍｅｎｔ　Ａ　Ｉｎｆｏｒｍａｔｉｏｎａｌ　Ｖｅｒｓｉｏｎ　／　Ｍａｐｐｉｎｇ　ＤＴＣＰ　ｔｏ　ＵＳＢ）が規格化されている。さらに、ＩＥＥＥ１３９４とＵＳＢの変換を行なう方式も提案されている（例えば、特許文献１参照）。しかしながら、ＵＳＢの場合は、ＩＥＥＥ１３９４と異なり、ホスト装置と周辺装置という機能分担になっており、接続される装置の制御はホスト装置が全て管理している。例えば、パソコンにプリンタが接続されている場合は、ドライバと呼ばれる装置固有の制御を行なうソフトウェアを経由して、パソコンが周辺装置の制御を行なう。この場合、ドライバは周辺装置メーカーが独自に提供するために、ドライバと周辺装置の制御は１対１で対応することになる。
【００１９】
【特許文献１】
特開２００１−３３３１３０号公報
【００２０】
【非特許文献１】
ＩＥＥＥ　１３９４−１９９５，　Ｓｔａｎｄａｒｄ　ｆｏｒ　ａ　Ｈｉｇｈ　Ｐｅｒｆｏｒｍａｎｃｅ　Ｓｅｒｉａｌ　Ｂｕｓ
【００２１】
【発明が解決しようとする課題】
しかしながら、パソコンとは異なるディジタルテレビなどのＡＶ装置の場合、ドライバを使って周辺装置固有の制御をすることは困難である。このため、例えば、ＡＶ装置にプリンタを接続する場合は、汎用性を有するＩＥＥＥ１３９４インタフェースを利用したデータ伝送が望ましい。
【００２２】
とはいえ、　ＩＥＥＥ１３９４のＩｓｏｃｈｒｏｎｏｕｓ転送で適用されているＤＴＣＰの転送方式をそのままＡｓｙｎｃｈｒｏｎｏｕｓ転送に転用するにはいくつかの課題がある。
まず、Ｉｓｏｃｈｒｏｎｏｕｓ転送の場合、暗号鍵は３０秒から２分の間で定期的に更新することになっており、その切替タイミング示す情報は、図２１に示すようにＩｓｏｃｈｒｏｎｏｕｓパケットのヘッダ部分のＯ／Ｅ（Ｏｄｄ　Ｅｖｅｎ）フィールド１４１に格納されている。従って、暗号鍵を切り替える時間が完全に一定間隔でなくても、送信側と受信側の切替タイミングがずれてしまうことはない。ところが、Ａｓｙｎｃｈｒｏｎｏｕｓ転送では、図２２に示すように、データパケットに暗号鍵の切替を通知するフラグとして使えるような空き領域は存在しない。また、Ｏ／Ｅフィールド１４１に相当する部分も定義されていない。
【００２３】
さらに、Ａｓｙｎｃｈｒｏｎｏｕｓ転送の場合、Ｉｓｏｃｈｒｏｎｏｕｓ転送と違い時間とデータ伝送量は比例関係にはなく、一定間隔で大量のデータを送ることは保証されない。つまり、Ｉｓｏｃｈｒｏｎｏｕｓ転送において一定時間内に送られたデータは、ほぼ一定量となるが、Ａｓｙｎｃｈｒｏｎｏｕｓ転送の場合にはそうなる保証はまったくない。そして、送信するデータの大きさはコンテンツ等によりまったく違う。従って、暗号鍵を切り替える場合は、どのようなタイミングで暗号鍵を切り替えるのかということを送信側及び受信側で認識しておく必要がある。
【００２４】
そして、Ｉｓｏｃｈｒｏｎｏｕｓ転送の場合には、暗号化の単位が送信するコンテンツによって一義的に定められている。この暗号化の単位は、それぞれのコンテンツのデータ伝送レートに応じて決定されている。ところが、Ａｓｙｎｃｈｒｏｎｏｕｓ転送では、伝送レートには何ら意味はなく、伝送したいデータの量も多様である。従って、この単位で暗号化すれば最適であるという基準はなく、ＤＴＣＰのＵＳＢ適用の場合などは、８バイトから１０２３バイトの間で自由に設定できるようになっている。ＵＳＢが主に利用されるようなパソコンなどの場合は、上記のように、送信側に予め受信側の装置が何であるかを登録しておけばよい。しかしながら、ＩＥＥＥ１３９４が主に利用されるＡＶ装置においては、接続される装置に応じてそのパラメータを登録するような手順を踏むことは許されない。従って、何らかの形で暗号化の単位を送信側と受信側で共有させる必要がある。
【００２５】
以上のような理由のため、ＤＴＣＰ方式をＩＥＥＥ１３９４　Ａｓｙｎｃｈｒｏｎｏｕｓ通信に適用するためには、Ｉｓｏｃｈｒｏｎｏｕｓ転送とは異なった対応が必要になる。
そこで、本発明は、上記課題に鑑みてなされたものであり、従来のＩＥＥＥ１３９４におけるＡｓｙｎｃｈｒｏｎｏｕｓ転送においてもコンテンツの著作権保護を可能とするデータ伝送システムを提供することを目的とする。
【００２６】
【課題を解決するための手段】
上記目的を達成するために、本発明に係るデータ送信装置は、通信インタフェースを介して接続されているデータ受信装置に対して、非同期通信方式でデータを送信するデータ送信装置であって、前記データ受信装置と情報のやりとりをすることによって、前記データ受信装置との間に論理的な伝送路を確立するコネクション確立手段と、前記論理的な伝送路が確立される前、又は、前記論理的な伝送路の確立過程において、又は、前記論理的な伝送路が確立された後に、前記データ受信装置に対する機器認証を行なう機器認証手段と、前記機器認証手段による機器認証の結果に基づいて、暗号鍵を生成し、生成した暗号鍵を前記データ受信装置との間で共有化する暗号鍵共有化手段と、共有化された暗号鍵を用いてデータを暗号化し、前記データ受信装置に送信するデータ送信手段とを備える。
【００２７】
これにより、受信側とのコネクションを確立する前後又はコネクションを確立する途中で、相互の機器認証を行なうと共に、認証結果に基づいて生成され共有する暗号鍵でデータの暗号化を行なっているので、万一、暗号鍵を搾取されても次のコネクション確立時には別の暗号鍵を用いて暗号化を行なう。従って、例えば、ＩＥＥＥ１３９４Ａｓｙｎｃｈｒｏｎｏｕｓ転送において、不正な装置からコンテンツを保護することが可能となる。
【００２８】
また、上記目的を達成するために、本発明に係るデータ受信装置は、通信インタフェースを介して接続されているデータ送信装置から非同期通信方式でデータを受信するデータ受信装置であって、前記データ送信装置と情報のやりとりをすることによって、前記データ送信装置との間に論理的な伝送路を確立するコネクション確立手段と、前記論理的な伝送路が確立される前、又は、前記論理的な伝送路の確立過程において、又は、前記論理的な伝送路が確立された後に、前記データ送信装置が当該データ受信装置を認証するための機器認証を行なう機器認証手段と、前記機器認証手段による機器認証の結果に基づいて、暗号鍵を生成し、生成した暗号鍵を前記データ受信装置との間で共有化する暗号鍵共有化手段と、前記データ送信装置から送られてくるデータを受信し、受信したデータを前記暗号鍵共有化手段によって共有化された暗号鍵で復号化するデータ受信手段とを備える。
【００２９】
これにより、送信側とのコネクションを確立する前後又はコネクションを確立する途中で、相互の機器認証を行なうと共に、認証結果に基づいて生成され共有する暗号鍵でデータの暗号化を行なっているので、万一、暗号鍵を搾取されても次のコネクション確立時には別の暗号鍵を用いて暗号化を行なう。
【００３０】
なお、上記目的を達成するために、本発明は、上記データ送信装置やデータ受信装置の特徴的な構成手段をステップとするデータ送信方法やデータ受信方法として実現することもできる。また、上記目的を達成するために、本発明は、上記データ送信装置やデータ受信装置から構成されるデータ伝送システムとして実現することもできる。
【００３１】
【発明の実施の形態】
以下、本発明に係る実施の形態について、図面を参照しながら説明する。
【００３２】
（実施の形態１）
図１は、本実施の形態におけるデータ伝送システム１０ａの全体の機能構成を示すブロック図である。このデータ伝送システム１０ａは、任意のタイミングで（例えば、オペレータの指示によって）、ＩＥＥＥ１３９４等の所定のバスインタフェースを介して映像や音声などのコンテンツ等の伝送（「転送」ともいう。）を行なうと共に、その際のコンテンツにおける著作権保護をも可能とするシステムである。図１に示すように、データ伝送システム１０ａは、Ｃｏｎｔｒｏｌｌｅｒ２０の制御に従って、Ｐｒｏｄｕｃｅｒ３０がＩＥＥＥ１３９４バス５０を介してＣｏｎｓｕｍｅｒ４０に暗号化されたコンテンツ等を非同期で伝送するシステムである。
【００３３】
Ｃｏｎｔｒｏｌｌｅｒ２０は、Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるデータ送信装置であるＰｒｏｄｕｃｅｒ３０とデータ受信装置であるＣｏｎｓｕｍｅｒ４０とのコネクション（即ち、論理的な伝送路の確立及び解除）を管理する制御装置である。上記のＣｏｎｔｒｏｌｌｅｒ２０、Ｐｒｏｄｕｃｅｒ３０及びＣｏｎｓｕｍｅｒ４０の具体例を挙げると、Ｃｏｎｔｒｏｌｌｅｒ２０及びＰｒｏｄｕｃｅｒ３０の機能を有するディジタル放送用のＳＴＢ（Ｓｅｔ　Ｔｏｐ　Ｂｏｘ）とＣｏｎｓｕｍｅｒ４０に相当するビデオプリンタとの組合せなどが該当する。そして、上記のデータ伝送システム１０ａは、高画質のディジタル放送の映像等をビデオプリンタに出力する際の著作権の保護をも行なう。
【００３４】
Ｐｒｏｄｕｃｅｒ３０は、ＩＥＥＥ１３９４バス５０を介して、Ｃｏｎｓｕｍｅｒ４０にＡｓｙｎｃｈｒｏｎｏｕｓパケットを用いることによって上記のコンテンツ等を送信する装置であり、パラメータ交換部３１、認証鍵生成部３２、交換鍵記憶部３３、交換鍵暗号化部３４、交換鍵交換部３５、暗号化パラメータ送信部３６、暗号鍵生成部３７及びコンテンツ暗号化部３８等を備えている。
【００３５】
パラメータ交換部３１は、Ｃｏｎｓｕｍｅｒ４０のパラメータ交換部４１との間で、認証鍵を生成するためのパラメータを交換し、認証鍵生成部３２に送信する。認証鍵生成部３２は、パラメータ交換部３１から受信したパラメータに基づいてＣｏｎｓｕｍｅｒ４０を認証するための認証鍵を生成し、交換鍵暗号化部３４に送信する。交換鍵記憶部３３は、例えばＲＡＭ等であり、予め交換鍵を記憶する（あるいは、記憶されている初期値を元に乱数を発生することにより交換鍵を生成するようにしてもよい）。交換鍵暗号化部３４は、交換鍵記憶部３３から交換鍵を読み出し、認証鍵生成部３２から受信した認証鍵で暗号化して交換鍵交換部３５に送信する。
【００３６】
交換鍵交換部３５は、Ｃｏｎｓｕｍｅｒ４０の交換鍵交換部４５との間で、交換鍵を交換する。暗号化パラメータ送信部３６は、暗号鍵生成部３７とＣｏｎｓｕｍｅｒ４０の暗号化パラメータ受信部４６に対して、暗号鍵を生成するためのパラメータを送信する。暗号鍵生成部３７は、暗号化パラメータ送信部３６から受信した暗号化パラメータに基づいて暗号鍵を生成する。コンテンツ暗号化部３８は、暗号鍵生成部３７によって生成された暗号鍵によりコンテンツを暗号化し、ＩＥＥＥ１３９４バス５０を介して暗号化したコンテンツをＣｏｎｓｕｍｅｒ４０に送信する。
【００３７】
Ｃｏｎｓｕｍｅｒ４０は、ＩＥＥＥ１３９４バス５０を介して、Ｐｒｏｄｕｃｅｒ３０からＡｓｙｎｃｈｒｏｎｏｕｓパケットを介して上記のコンテンツ等を受信する装置であり、パラメータ交換部４１、認証鍵生成部４２、交換鍵復号化部４４、交換鍵交換部４５、暗号化パラメータ受信部４６、暗号鍵生成部４７及びコンテンツ復号化部４８等を備えている。
【００３８】
パラメータ交換部４１は、Ｐｒｏｄｕｃｅｒ３０のパラメータ交換部３１との間で、認証鍵を生成するためのパラメータを交換し、認証鍵生成部４２に送信する。認証鍵生成部４２は、パラメータ交換部４１から受信したパラメータに基づいて、Ｐｒｏｄｕｃｅｒ３０を認証するための認証鍵を生成し、交換鍵復号化部４４に送信する。交換鍵復号化部４４は、交換鍵交換部４５を介して交換鍵交換部３５から受信した交換鍵を、認証鍵生成部４２から受信した認証鍵で復号して暗号鍵生成部４７に送信する。
【００３９】
交換鍵交換部４５は、Ｐｒｏｄｕｃｅｒ３０の交換鍵交換部３５から交換鍵を受信する。暗号化パラメータ受信部４６は、Ｐｒｏｄｕｃｅｒ３０の暗号化パラメータ送信部３６から暗号鍵を生成するためのパラメータを受信し、暗号鍵生成部４７に送信する。暗号鍵生成部４７は、交換鍵復号化部４４から受信した交換鍵と暗号化パラメータ受信部４６から受信したパラメータとに基づいて暗号鍵を生成し、コンテンツ復号化部４８に送信する。コンテンツ復号化部４８は、Ｐｒｏｄｕｃｅｒ３０から受信したコンテンツを暗号鍵生成部４７から受信した暗号鍵で復号する。
【００４０】
図２は、Ａｓｙｎｃｈｒｏｎｏｕｓ転送を行なうためのコネクションを確立する際の通信シーケンス図である。
まず、Ｃｏｎｔｒｏｌｌｅｒ２０は、Ｃｏｎｓｕｍｅｒ４０に対して、Ａｓｙｎｃｈｒｏｎｏｕｓ転送でデータを送受信するためのプラグ／ポートを予約する「ＡＬＬＯＣＡＴＥコマンド」を送信する（ステップ２１１）。Ｃｏｎｓｕｍｅｒ４０は、「ＡＬＬＯＣＡＴＥコマンド」を受信すると、プラグ／ポートを予約して、コネクトするポートの情報と共に「ＡＣＣＥＰＴＥＤ　レスポンス」をＣｏｎｔｒｏｌｌｅｒ２０に返す（ステップ２１２）。
【００４１】
次に、Ｃｏｎｔｒｏｌｌｅｒ２０は、Ｃｏｎｓｕｍｅｒ４０から「ＡＣＣＥＰＴＥＤ　レスポンス」を受信することによって、Ｃｏｎｓｕｍｅｒ４０が上記のコンテンツ等を受信することが可能であると判断し、Ｐｒｏｄｕｃｅｒ３０に対して、Ａｓｙｎｃｈｒｏｎｏｕｓ転送によって上記のコンテンツ等を送信するための送信用のプラグ／ポートを確保するための「ＡＬＬＯＣＡＴＥ＿ＡＴＴＡＣＨコマンド」を送信する（ステップ２１３）。
【００４２】
この際、Ｃｏｎｔｒｏｌｌｅｒ２０は、Ｐｒｏｄｕｃｅｒ３０に対して、Ｃｏｎｓｕｍｅｒ４０におけるコネクトされたポートの情報を通知する。Ｐｒｏｄｕｃｅｒ３０は、「ＡＬＬＯＣＡＴＥ＿ＡＴＴＡＣＨコマンド」を受信すると、送信用のＰｒｏｄｕｃｅｒプラグ／ポートを確保してＣｏｎｔｒｏｌｌｅｒ２０に「ＡＣＣＥＰＴＥＤ　レスポンス」を返信する（ステップ２１４）。
【００４３】
この後、Ｃｏｎｔｒｏｌｌｅｒ２０は、Ｃｏｎｓｕｍｅｒ４０に対して「ＡＴＴＡＣＨコマンド」を送信する（ステップ２１５）。この際、Ｃｏｎｔｒｏｌｌｅｒ２０は、Ｃｏｎｓｕｍｅｒ４０に対して、Ｐｒｏｄｕｃｅｒ３０のポートの情報を通知する（ステップ２１５）。Ｃｏｎｓｕｍｅｒ４０は、「ＡＴＴＡＣＨコマンド」を受信すると、Ｃｏｎｓｕｍｅｒポートをコネクトして「ＡＣＣＥＰＴＥＤ　レスポンス」を返す（ステップ２１６）。
【００４４】
以上のシーケンスで、Ａｓｙｎｃｈｒｏｎｏｕｓコネクションが確立する。次に、Ｃｏｎｓｕｍｅｒ４０は、Ｐｒｏｄｕｃｅｒ３０に対して機器認証要求コマンドを発行する（ステップ２１９）。このときＰｒｏｄｕｃｅｒ３０は、Ａｓｙｎｃｈｒｏｎｏｕｓコネクションが確立してから、タイマを起動してＣｏｎｓｕｍｅｒ４０からの機器認証要求コマンドを受ける時間を計時することにより、Ｃｏｎｓｕｍｅｒ４０がＤＴＣＰ方式に対応しているか否かを知ることができる。例えば、Ｐｒｏｄｕｃｅｒ３０がコンテンツデータを暗号化してデータ転送することを要求しているにもかかわらず、Ａｓｙｎｃｈｒｏｎｏｕｓコネクションが確立後もＣｏｎｓｕｍｅｒ４０から機器認証要求コマンドが発行されない場合には、Ｃｏｎｓｕｍｅｒ４０はＤＴＣＰ方式に対応していないとみなし、コンテンツデータの送信を拒絶する。
【００４５】
Ｐｒｏｄｕｃｅｒ３０がコンテンツデータを特に暗号化してデータ送信することを求めていなければ、機器認証要求コマンドに関わらずデータ送信が可能になる。一方、Ｃｏｎｓｕｍｅｒ４０からみると機器認証要求コマンドを発行したにもかかわらず、「Ｎｏｔ　Ｉｍｐｌｅｍｅｎｔｅｄ」レスポンスが返ってきた場合には、Ｐｒｏｄｕｃｅｒ３０はＤＴＣＰ方式に対応していないとみなして、暗号化データは送信されてこないと判断することができる。
【００４６】
以上のステップでＡｓｙｎｃｈｒｏｎｏｕｓコネクションが確立すると、Ｐｒｏｄｕｃｅｒ３０とＣｏｎｓｕｍｅｒ４０の間でＤＴＣＰの暗号化されたコンテンツ等について送受信するために「認証」と「鍵交換」の処理を行なう（ステップ２１７）。
これらの「認証」と「鍵交換」の処理については、基本的には、上記の図２４の内容と同様である。図２４を参照しながらその概要を説明する。
【００４７】
まず、Ｃｏｎｓｕｍｅｒ４０（受信側）からＰｒｏｄｕｃｅｒ３０（送信側）に対して、認証用のパラメータと共に認証開始要求を通知する（ステップ１２１）。このパラメータは、乱数を用いて生成されるので、その都度異なったものになる。Ｐｒｏｄｕｃｅｒ３０は、Ｃｏｎｓｕｍｅｒ４０から認証開始要求を受信すると、Ｃｏｎｓｕｍｅｒ４０が不正装置でなければＰｒｏｄｕｃｅｒ３０の認証パラメータをＣｏｎｓｕｍｅｒ４０に通知する。Ｃｏｎｓｕｍｅｒ４０側、Ｐｒｏｄｕｃｅｒ３０側それぞれにおいて機器認証が完了すると（ステップ１２２）、お互いに認証鍵を算出する（ステップ１２３、１２６）。この段階でＡＫＥといわれる機器認証と鍵交換のシーケンスが完了し、データ転送が可能になる。
【００４８】
（実施の形態２）
上記実施の形態１では、Ａｓｙｎｃｈｒｏｎｏｕｓコネクションが確立したあとに、Ｃｏｎｓｕｍｅｒ４０が無条件に認証開始要求を発行する実施例について説明したが、本実施の形態では、Ｐｒｏｄｕｃｅｒ３０側から認証開始のアクションを起こす場合の実施例について説明する。
【００４９】
図３は、Ａｓｙｎｃｈｒｏｎｏｕｓ転送を行なうためのコネクションを確立する際の通信シーケンス図である。Ａｓｙｎｃｈｒｏｎｏｕｓコネクションを確立するまでの手順（ステップ２１１〜ステップ２１６）は、上記実施の形態１と同様であるため、その説明は省略する。
【００５０】
Ａｓｙｎｃｈｒｏｎｏｕｓコネクションが確立した段階で、Ｐｒｏｄｕｃｅｒ３０は、Ｃｏｎｓｕｍｅｒ４０に対して転送モード通知を行なう（ステップ２２０）。この転送モード通知は、Ｐｒｏｄｕｃｅｒ３０が送信するデータを暗号化モードで転送するか、通常モードで転送するかをＣｏｎｓｕｍｅｒ４０に通知するために用いる。なお、暗号化モードの場合であっても暗号化してデータを送らなければならないというわけではなく、暗号化モードにしておいて暗号化せずにデータを送信することも可能である。
【００５１】
転送モード通知を受信したＣｏｎｓｕｍｅｒ４０は、機器認証要求コマンドを発行する（ステップ２１９）。このとき、Ｃｏｎｓｕｍｅｒ４０から「Ｎｏｔ　Ｉｍｐｌｅｍｅｎｔｅｄ」レスポンスが返ってきた場合には、Ｐｒｏｄｕｃｅｒ３０は、Ｃｏｎｓｕｍｅｒ４０がＤＴＣＰ方式に対応していないと判断して通常モードでデータ転送を行なう。なお、コンテンツデータが暗号化すべきデータならば、Ｐｒｏｄｕｃｅｒ３０は、コンテンツデータの送信を中止する。一方、コンテンツデータが特に暗号化する必要がない場合は、Ｐｒｏｄｕｃｅｒ３０は、通常モードでデータ転送を行なう。また、Ｃｏｎｓｕｍｅｒ４０から「ＡＣＣＥＰＴＥＤレスポンス」が返ってきた場合には、暗号化モードになって、Ｐｒｏｄｕｃｅｒ３０とＣｏｎｓｕｍｅｒ４０との間でＤＴＣＰの暗号化されたコンテンツ等について送受信するために「認証」と「鍵交換」の処理を行なう（ステップ２１７）。
【００５２】
一方、Ｃｏｎｓｕｍｅｒ４０は、Ｐｒｏｄｕｃｅｒ３０から転送モード通知（ステップ２２０）がなく、データ転送が開始された場合には通常モードによるデータ転送と判断し、送信データは暗号化されていないと判断する。従って、Ｐｒｏｄｕｃｅｒ３０がＤＴＣＰ方式に対応していない場合でも問題なくデータの送信を行なうことができる。「認証」と「鍵交換」の処理については、実施の形態１と同様であるので省略する。
【００５３】
（実施の形態３）
上記の実施の形態１及び２においては、暗号化したデータを送受信するための前半の処理（前処理）について説明したが、本実施の形態では、ＩＥＥＥ　１３９４　Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるコネクション確立後の、Ｐｒｏｄｕｃｅｒ３０（送信側）からＣｏｎｓｕｍｅｒ４０（受信側）に実際のデータを転送する処理について説明する。
【００５４】
図４は、一般的なＩＥＥＥ　１３９４　Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるデータ転送の様子を示す概念図である。ここで、伝送されるデータのひとまとまりは、「フレーム」と呼ばれる。また、このフレームは、Ｐｒｏｄｕｃｅｒ３０及びＣｏｎｓｕｍｅｒ４０の伝送能力に応じて、「セグメント」と呼ばれる単位に分割される。さらに、データを伝送するために、Ｐｒｏｄｕｃｅｒ３０には「ｏＡＰＲ」と呼ばれるＰｒｏｄｕｃｅｒポートを管理するためのレジスタ（図示せず）が用意され、Ｃｏｎｓｕｍｅｒ４０には「ｉＡＰＲ」と呼ばれるＣｏｎｓｕｍｅｒポートを管理するためのレジスタ（図示せず）と、セグメントを受信するためのバッファ（セグメントバッファ４０ｂ）とが用意される。
【００５５】
図４に示すように、Ｐｒｏｄｕｃｅｒ３０側のフレーム３０ａがセグメント（その１つがセグメント３０ｂである。）に分割されてＩＥＥＥ１３９４バス５０を介して送信され、Ｃｏｎｓｕｍｅｒ４０側のセグメントバッファ４０ｂに格納される。Ｃｏｎｓｕｍｅｒ４０側では、セグメントバッファ４０ｂに格納されたデータからフレーム４０ａが再構成される。
【００５６】
図５は、上記のｉＡＰＲレジスタ６０の構造を示す図である。ｉＡＰＲレジスタ６０において、ｒフィールド６１は、未使用の領域である。ｍｏｄｅフィールド６２は、転送のステータスを通知するための領域である（例えば、「ＭＯＲＥ」は、１セグメントの送信完了を表し、続きのセグメントが存在することを表す。また、「ＬＡＳＴ」は、フレームの転送が終了したことを表す。）。ｃｏｕｎｔフィールド６３は、セグメントバッファ４０ｂに書き込まれたデータのバイト数を通知するための領域である。
【００５７】
図６は、上記のｏＡＰＲレジスタ７０の構造を示す図である。ｏＡＰＲレジスタ７０において、ｒフィールド７１は、未使用の領域である。ｍｏｄｅフィールド７２は、転送におけるステータスを通知するための領域である（例えば、「ＳＥＮＤ」は、次のセグメントの転送要求を表す）。ｃｏｕｎｔＨｉフィールド７３は、セグメントバッファ４０ｂに書き込まれたデータのバイト数を表す領域である。
【００５８】
図７は、ＩＥＥＥ１３９４Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるデータ転送の様子を示す通信シーケンス図である。
まず、Ｃｏｎｓｕｍｅｒ４０は、データを受信する準備ができると、Ｌｏｃｋトランザクションでデータ受信準備完了を通知する（ステップ２１）。これは、Ｃｏｎｓｕｍｅｒ４０がＰｒｏｄｕｃｅｒ３０のｏＡＰＲレジスタ７０のｍｏｄｅフィールド７２を「ＳＥＮＤ」に設定することで実現される。同時に、ｃｏｕｎｔＨｉフィールド７３にセグメントバッファ４０ｂのデータサイズを書き込むことにより、Ｃｏｎｓｕｍｅｒ４０の使用できるセグメントバッファ４０ｂのデータサイズを通知することができる。Ｐｒｏｄｕｃｅｒ３０は、フレーム３０ａを指定されたセグメントバッファ４０ｂの容量に対応させて分割し、セグメント１（３０ｂ）から順にＷｒｉｔｅトランザクションでＣｏｎｓｕｍｅｒ４０のセグメントバッファ４０ｂに格納を行なう。このとき、１回のＷｒｉｔｅトランザクションで送信されるデータサイズは、データ伝送レートにより規定されているので、送信するデータがなくなるか、セグメントバッファ４０ｂの占有率が最大になるまで、Ｗｒｉｔｅトランザクションを継続する（ステップ２２）。セグメントバッファ４０ｂの占有率が最大になった場合には、Ｐｒｏｄｕｃｅｒ３０がＣｏｎｓｕｍｅｒ４０に続きのセグメントがあるもののセグメント送信が完了したことを通知する。これはＰｒｏｄｕｃｅｒ３０がＣｏｎｓｕｍｅｒ４０のｉＡＰＲレジスタ６０のｍｏｄｅフィールド６２を「ＭＯＲＥ」に設定することによって実現する（ステップ２３）。
【００５９】
次に、Ｃｏｎｓｕｍｅｒ４０は、セグメントバッファ４０ｂのデータを処理して受信可能状態になると再びＰｒｏｄｕｃｅｒ３０のｏＡＰＲレジスタ７０のｍｏｄｅフィールド７２を「ＳＥＮＤ」に設定して、データ受信準備完了を通知する（ステップ２４）。以下、同様の処理を繰り返し、送信するデータがなくなるとＰｒｏｄｕｃｅｒ３０がＣｏｎｓｕｍｅｒ４０のｉＡＰＲレジスタ６０のｍｏｄｅフィールド６２を「ＬＡＳＴ」と設定してフレームの送信が完了したことを通知する（ステップ２５）。
【００６０】
最後に、必要なデータ転送が終了して、コネクションが不要になった旨の通知を受けると、Ｃｏｎｔｒｏｌｌｅｒ２０は、ディスコネクト処理を行ない、確立されていたコネクションを解除する。これと同時に暗号鍵も解消される。新たにコネクションを確立してデータ伝送を希望する場合は、その都度認証を行なって認証鍵を生成する。
【００６１】
以上が、一般的なＩＥＥＥ１３９４におけるＡｓｙｎｃｈｒｏｎｏｕｓ通信の例である。なお、本実施の形態における「フレーム」の概念は従来とほぼ同じであり、伝送される一まとまりのデータを表わす。このフレームは、１つのファイルの場合もあるし、複数のファイルで構成される場合もある。本実施の形態では、便宜上、Ｐｒｏｄｕｃｅｒ３０からＣｏｎｓｕｍｅｒ４０に１つのファイルの送信要求を送信した場合を考える。
【００６２】
図８は、Ｐｒｏｄｕｃｅｒ３０（送信側）からＣｏｎｓｕｍｅｒ４０（受信側）にデータ転送通知がある場合の通信シーケンスの概略図である。
まず、Ａｓｙｎｃｈｒｏｎｏｕｓコネクションが確立すると、Ｐｒｏｄｕｃｅｒ３０は、モード設定コマンドを出力して（ステップ２２０）、暗号化モードでデータを転送することを通知する。Ｃｏｎｓｕｍｅｒ４０は、その通知を受信すると機器認証と鍵交換の処理を行なう（ステップ２１７）。機器認証と鍵交換が完了すると、Ｐｒｏｄｕｃｅｒ３０は、Ｃｏｎｓｕｍｅｒ４０にデータ転送通知を送信し（ステップ２３１ａ）、Ｃｏｎｓｕｍｅｒ４０がそれに対して許可応答を行ない（ステップ２３２ａ）、データ転送が開始される（ステップ２３３ａ）。このとき、転送されるデータは、Ｐｒｏｄｕｃｅｒ３０とＣｏｎｓｕｍｅｒ４０で共有している暗号鍵を用いて暗号化及び復号される。
【００６３】
上記のデータ転送が完了して、Ｐｒｏｄｕｃｅｒ３０から次のデータ転送通知が送信されると（ステップ２３１ｂ）、Ｐｒｏｄｕｃｅｒ３０とＣｏｎｓｕｍｅｒ４０は、暗号鍵を更新して（図示せず）、次のデータ転送を開始する（ステップ２３３ｂ）。
図９（ａ）、（ｂ）は、複数のフレームを送信するときに、フレームと暗号鍵の更新タイミングとの時間的な関係を示す模式図である。ここでは、１回のＡｓｙｎｃｈｒｏｎｏｕｓコネクションで複数のフレームが送信される場合を想定する。
【００６４】
図９（ａ）では、フレーム２３０ａ〜２３０ｄが、いずれも予め定めた所定の大きさ（例えば、１６ＭＢ）よりも小さいフレームであるとする。さらに、各フレーム（２３０ａ〜２３０ｄ）を送信する際は、それぞれ更新された異なる暗号鍵（９１〜９４）で暗号化が施される。
【００６５】
しかし、図９（ｂ）に示すように、送信するフレームに対しては、所定の大きさ（ここでは１６ＭＢ）よりも大きなフレーム２３０ｆが含まれる場合があり、そのフレーム（この場合はフレーム２３０ｆ）は、所定の大きさ（ここでは１６ＭＢ）ずつ分割され、それぞれの所定の大きさ毎に暗号鍵を更新される。これは、ＡＶデータのように大量のデータを送る際に、データ搾取の被害を最小限に留めるために行なわれる対策の一つである。
【００６６】
なお、ここでは、所定の大きさを１６ＭＢとしたが、この大きさに限定するものではなく、任意の大きさに設定することができる。
図１０は、上記の複数のフレームの送信時に暗号鍵の更新を行なう場合のフローチャートである。
【００６７】
最初に、Ｐｒｏｄｕｃｅｒ３０は、送信すべき新たなフレームがある場合は（Ｓ１５０１）、そのフレームの大きさが所定の大きさ（１６ＭＢ）より大きいか否かを判定する（Ｓ１５０２）。
次に、Ｐｒｏｄｕｃｅｒ３０は、そのフレームが所定の大きさ（１６ＭＢ）より大きい（Ｓ１５０２：Ｙｅｓ）場合は、そのフレームを所定の大きさ（１６ＭＢ）ずつ分割を行なう（Ｓ１５０３）。
【００６８】
これにより、Ｐｒｏｄｕｃｅｒ３０は、暗号鍵を更新して（Ｓ１５０４）、この暗号鍵でフレームの暗号化を行ない、Ｃｏｎｓｕｍｅｒ４０に送信する（Ｓ１５０５）。なお、Ｐｒｏｄｕｃｅｒ３０は、フレームを所定の大きさに分割した場合は、分割したデータの単位で暗号鍵を切り替える（Ｓ１５０６）。Ｐｒｏｄｕｃｅｒ３０は、全てのフレームについて、上記の処理を行なう（Ｓ１５０１〜Ｓ１５０７）。
【００６９】
以上のように、本実施の形態に係るデータ伝送システムを用いて通信を行なうことにより、送信側と受信側とのコネクションを確立した後で相互の機器認証を行なうことにより、ＩＥＥＥ１３９４Ａｓｙｎｃｈｒｏｎｏｕｓ転送においてもＩｓｏｃｈｒｏｎｏｕｓ転送から大きな変更を行なうことなく、データの保護を実現することができる。また、一まとまりのデータのＡｓｙｎｃｈｒｏｎｏｕｓ転送毎に異なる暗号鍵を用いてデータの暗号化を行なっているので、万一、暗号鍵を搾取されても、次のデータを転送する際には別の暗号鍵を用いて暗号化を行なうため、不正な装置からコンテンツを保護することが可能となる。
【００７０】
なお、暗号鍵を切り替える方法としては、以下のような方法もある。
図１１は、他の方法によって暗号鍵を切り替えるデータ伝送システム１０ｅにおける通信シーケンス図である。
まず、Ｃｏｎｔｒｏｌｌｅｒ２０は、Ｃｏｎｓｕｍｅｒ４０に対して「ＡＬＬＯＣＡＴＥコマンド」を送信してＣｏｎｓｕｍｅｒ４０の受信プラグを予約する（ステップ５１）。Ｃｏｎｓｕｍｅｒ４０は、「ＡＬＬＯＣＡＴＥコマンド」を受信すると、プラグを予約して「ＡＣＣＥＰＴＥＤ　レスポンス」を返す（ステップ５２）。次に、Ｃｏｎｔｒｏｌｌｅｒ２０は、「ＡＣＣＥＰＴＥＤ　レスポンス」を受け取ると、Ｐｒｏｄｕｃｅｒ３０に「ＡＬＬＯＣＡＴＥ＿ＡＴＴＡＣＨコマンド」を送信する（ステップ５３）。Ｐｒｏｄｕｃｅｒ３０は、「ＡＬＬＯＣＡＴＥ＿ＡＴＴＡＣＨコマンド」を受信すると、Ｐｒｏｄｕｃｅｒ　ポートをコネクトして「ＡＣＣＥＰＴＥＤ　レスポンス」をＣｏｎｔｒｏｌｌｅｒ２０に返す（ステップ５４）。Ｃｏｎｔｒｏｌｌｅｒ２０は、「ＡＣＣＥＰＴＥＤ　レスポンス」を受け取ると、Ｃｏｎｓｕｍｅｒ４０に対して、「ＡＴＴＡＣＨコマンド」を送信する（ステップ５５）。Ｃｏｎｓｕｍｅｒ４０は、「ＡＴＴＡＣＨコマンド」を受信すると、Ｃｏｎｓｕｍｅｒ　ポートをコネクトして「ＡＣＣＥＰＴＥＤ　レスポンス」をＣｏｎｔｒｏｌｌｅｒ２０に返す（ステップ５６）。ここまでの処理によって、Ａｓｙｎｃｈｒｏｎｏｕｓコネクションが確立される。
【００７１】
次に、ＤＴＣＰの暗号化データを送受信するために認証と鍵交換を行なう。
Ａｓｙｎｃｈｒｏｎｏｕｓコネクションが確立されると、Ｃｏｎｓｕｍｅｒ４０は、無条件に送信側に対して認証開始要求を認証用パラメータと共に通知する。Ｐｒｏｄｕｃｅｒ３０は、送信するデータが暗号化するデータであるならば、Ｐｒｏｄｕｃｅｒ３０側の認証パラメータをＣｏｎｓｕｍｅｒ４０に通知する。Ｐｒｏｄｕｃｅｒ３０及びＣｏｎｓｕｍｅｒ４０それぞれ認証パラメータを受け取ると、お互いに相手が正当な装置であることを確信し、それぞれにおいて認証鍵を算出する。送信するデータが暗号化する必要のないデータの場合には、認証開始要求に対して「ＲＥＪＥＣＴのレスポンス」を返す。
【００７２】
その後、Ｐｒｏｄｕｃｅｒ３０は、暗号化するための暗号鍵を、算出した認証鍵を用いて暗号化してＣｏｎｓｕｍｅｒ４０に通知する。暗号化された暗号鍵を受け取ったＣｏｎｓｕｍｅｒ４０は、Ｃｏｎｓｕｍｅｒ４０側で算出した認証鍵を用いて暗号鍵を復号化する（ステップ５７）。
【００７３】
以上の処理によって、最初の通信における暗号鍵の交換が終了する。暗号鍵の交換が終了すると、データの伝送を行なう。データの伝送は、まず、コネクションが確立したＣｏｎｓｕｍｅｒ　ポートを指定して印刷ジョブキューへ追加するコマンドを発行する（ステップ５８）。それが許可されると、Ｃｏｎｓｕｍｅｒ４０の指定ポートへの受信開始要求を行ない（ステップ６０）、Ｐｒｏｄｕｃｅｒ３０の指定ポートへの送信開始要求を行なって（ステップ６２）データ送信が開始される（ステップ６３）。
【００７４】
Ａｓｙｎｃｈｒｏｎｏｕｓデータ伝送は、上記図４に示すように、セグメントバッファ４０ｂの単位で書き込みを行なう。従って、セグメントバッファ４０ｂより大きなサイズのデータの伝送を行なう場合は、複数のブロックに分割して伝送することになる。すでに述べたように、セグメントバッファ４０ｂに伝送した後に、まだ伝送すべきデータが残っている場合には、Ｐｒｏｄｕｃｅｒ３０は、ｉＡＰＲのＭＯＤＥフィールドを「ＭＯＲＥ」としてデータが継続していることを通知する。このとき、同時に図５に示すｉＡＰＲのリザーブフィールド６１を暗号鍵の切替について通知するように定義すれば、次のデータ伝送からは暗号鍵が変わることをＰｒｏｄｕｃｅｒ３０からＣｏｎｓｕｍｅｒ４０に通知することができる（ステップ６４）。
【００７５】
ＤＴＣＰにおける暗号鍵の生成は、交換した暗号鍵を初期値として所定の乱数で変化するため、初期値と暗号鍵の切替タイミングさえ同期させることができれば、送信側と受信側で暗号鍵を同期させて切り替えることが可能となる。従って、送信側で任意のセグメントバッファに所定の書き込みを行なうことにより、暗号鍵の切替回数及びそのタイミングを決定することが可能になり、データ伝送中の不正利用についても未然に防止することが可能になる。
【００７６】
なお、ここではｉＡＰＲに所定のデータを書き込むことで暗号鍵の切替タイミングを通知する構成について説明したが、受信側が主体となって送信側のｏＡＰＲに切替タイミングを通知するように構成しても同様の効果が得られる。また、別のコマンド転送プロトコルであるＦＣＰ（Ｆｕｎｃｔｉｏｎ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ）を用いて暗号鍵の切替タイミングを通知するように構成しても、上記と同様の効果が得られる。
【００７７】
図１２は、データ伝送システム１０ｅによるデータ転送の途中で暗号鍵を切り替える場合のフローチャートである。
まず、Ｃｏｎｔｒｏｌｌｅｒ２０は、データ転送方式がＤＴＣＰ方式、かつＡｓｙｎｃｈｒｏｎｏｕｓ方式であることを識別すると（ステップ７１、ステップ７２）、Ｐｒｏｄｕｃｅｒ３０及びＣｏｎｓｕｍｅｒ４０において、Ａｓｙｎｃｈｒｏｎｏｕｓ転送のためのコネクションの確立（ステップ７３）及び、相互の機器認証と鍵交換（ステップ７４）を実行する。
【００７８】
さらに、Ｐｒｏｄｕｃｅｒ３０は、一まとまりのデータの転送途中であっても、ｉＡＰＲレジスタ６０のリザーブフィールド６１を用いることによって、暗号鍵の切り替えるタイミングを通知する（ステップ７６〜ステップ７９）。
以上のように、本実施の形態に係るデータ伝送システムによれば、一まとまりのデータのＡｓｙｎｃｈｒｏｎｏｕｓ転送の途中で、ｉＡＰＲレジスタ等のリザーブフィールド等を利用して適宜に暗号鍵を切り替えるので、送信側と受信側で暗号鍵の切替タイミングを一致させることが可能となるので、必要に応じて暗号鍵を自由に切り替えることができる。
【００７９】
（実施の形態４）
本実施の形態では、さらに暗号鍵の更新手段とＡｓｙｎｃｈｒｏｎｏｕｓパケットのデータ構造について詳細に説明する。ＩＥＥＥ１３９４Ａｓｙｎｃｈｒｏｎｏｕｓ　転送においては、すでに説明したように、上記図２２に示すようなＡｓｙｎｃｈｒｏｎｏｕｓパケットに格納された形でデータが転送される。そこで、上記図４に示すように、フレーム３０ａは、Ａｓｙｎｃｈｒｏｎｏｕｓパケットの「ｄａｔａ　ｆｉｅｌｄ」に収まるサイズに分割される。ここでは、簡単にパケットに分割されることとする。
【００８０】
ここで、Ｉｓｏｃｈｒｏｎｏｕｓ転送と同じように、周期的にＡｓｙｎｃｈｒｏｎｏｕｓ転送に用いる暗号鍵を切り替えるためには、切り替えるタイミングを示す信号をパケットに格納する必要がある。さらに、暗号の種類を通知するために暗号モード識別子（以下、「ＥＭＩ：Ｅｎｃｒｉｐｔｉｏｎ　Ｍｏｄｅ　Ｉｎｄｉｃａｔｏｒ」という。）も必要になる。しかしながら、前述のように、ヘッダ部分には他にデータを格納可能な空き領域はないので、データ領域の中に何らかのヘッダ情報を格納する必要がある。
【００８１】
図１３は、フレーム２３０を数個のパケットに分割した場合のデータ構成図である。フレーム２３０は、所定の大きさのＰＣＰパケット（２５６ａ〜２５６ｆ）に分割される。さらに、それぞれのパケットにはＰＣＰヘッダ２５５が付加される。このＰＣＰヘッダ２５５には、暗号鍵更新信号２５１とパケットの実効データサイズ２５０並びにＥＭＩ（図示せず）などが含まれる。
【００８２】
本実施の形態では、暗号鍵更新信号２５１が５つ目のパケット２５６ｅで変化（即ち、”暗号鍵更新信号”が「０」→「１」に変化）していることを表わしている。従って、５つ目のパケット２５６ｅからは、更新された暗号鍵が使用される。さらに、それぞれのパケットは、暗号化の最小単位である複数の単位ブロック２５２に分割される。言い換えれば、ｍ個の単位ブロックのデータが集められて一つのパケットが構成されていることになる。
【００８３】
しかしながら、フレームの最後のパケット２５６ｆだけは必ずしも単位ブロックの大きさと同じになるとは限らない。従って、最終パケット２５６ｆの最終ブロック２５３が単位ブロックよりも小さくなってしまう場合には、不足分をパディングデータ２５４でパディングして、最終ブロックも単位ブロックと同じ大きさになるようにしてデータ送信を行なう。このようにすることで、ブロック暗号化の端数処理を省略することができる。
【００８４】
また、ＰＣＰヘッダ２５５に実効データサイズ２５０を記録しておくことで、単位ブロックの大きさが既知であれば、最終パケット２５６ｆで暗号化されているデータの大きさ２５８も容易に演算で求めることができる。さらに、ＰＣＰヘッダの大きさを単位ブロックの整数倍（ｎ倍）の大きさにすることにより、これらの演算はいっそう容易になる。
【００８５】
例えば、図１４（ａ）に示すように、ＰＣＰヘッダを含む単位パケットの大きさが５１２バイト、単位ブロックを４バイト、ＰＣＰヘッダを４バイト、フレーム全体で９１０バイトのデータの場合、第１のパケットのデータは５０８バイト、第２のパケットのデータは４０２バイトになる。第２のパケットのデータのバイト数は、単位ブロックの大きさの４バイトで割り切れないので、２バイト分パディングをすることになる。ただし、ＰＣＰヘッダの実効データフィールドにはパディングを含まないデータサイズ４０２バイトが格納される。
【００８６】
そして、暗号化の対象となるデータは、第１のパケットが５０８バイト、第２のパケットが４０４バイトとなり、共に単位ブロックの大きさである４バイトの整数倍となるので、暗号化の際の端数処理が不要になる。復号化の際にも、ＰＣＰヘッダの実効バイト数４０２バイトがわかれば、暗号化されているデータのサイズを求めるのは容易である。
【００８７】
図１４（ｂ）は、上記のように、単位ブロックの整数倍のデータで構成されるＰＣＰパケットのデータ構造を示す図である。
以上のように、本実施の形態に係るデータ伝送システムをよれば、Ａｓｙｎｃｈｒｏｎｏｕｓパケットの中に暗号鍵を切り替えるタイミングを示す情報を格納して、送受信双方で共有させる。さらに、Ａｓｙｎｃｈｒｏｎｏｕｓパケットのデータサイズを予め定めた単位ブロックの整数倍とすることで、暗号化処理の簡略化を図ることができる。
【００８８】
（実施の形態５）
上記の実施の形態３および４では、フレームが１つのファイルから構成される場合の実施例について説明したが、本実施の形態では、フレームが複数（例えば、２つ）のファイルから構成され、それぞれのファイルのＥＭＩが異なる場合について説明する。
【００８９】
図１５は、１つのフレームが２つのファイルで構成されるデータを送信する場合の送信データの分割方法を表す図である。ファイル１が所定のデータサイズ（ここでは１６ＭＢとする）より大きい場合、上記実施の形態３で説明したように、暗号鍵が１６ＭＢ毎に更新される。ファイル１のデータの残り分は更新された暗号鍵で暗号化され送信される。この場合、ファイル１の最終パケットのサイズは、規定のパケットサイズと同じ大きさになるとは限らない。ファイル１のＥＭＩとファイル２のＥＭＩが異なる場合、ＰＣＰヘッダのＥＭＩ２５１は別々にする必要があり、同じパケットに２つのファイルのデータを格納することができない。
【００９０】
そこで、フレームとしての連続性を確保するため、ファイル１の最終パケットが規定のパケットサイズと同じになるように不足分を非暗号データ２６０ｂでパディングする（このパディングを「Ａｌｉｇｎｍｅｎｔ　Ｐａｄｄｉｎｇ」という）。さらに、ファイルが切り換った（「ファイル１」→「ファイル２」に変更された）場合は、１６ＭＢに満たなくとも暗号鍵を切り替える。
【００９１】
これにより、受信側では、ファイル１の最終パケットの実効データサイズ２５０から、暗号化されているデータのサイズの算出が可能となり、さらにはパディングされているデータのサイズも算出できる。また、暗号鍵が１６ＭＢに満たないデータであっても更新された場合は、パディングされている可能性があることもわかる。そして、ファイル２の先頭のパケットのデータは、パケットの始めから格納することができ、ＰＣＰヘッダのＥＭＩやファイル２のＥＭＩについても、ファイル毎に格納させることができる。例えば、ＸＭＬ系の言語のように、複数のファイルから構成されるコンテンツを送信装置から受信装置に転送する場合は、このような方式は有効である。
【００９２】
また、同様のコンテンツを受信側からの要求に基づいて送信側から転送する場合には、一般的には受信側のデータ仕様に合わせてコンテンツの転送要求を行なうことになるので、その要求したデータの単位にフレームを分割すれば、本実施の形態によるパディング処理を行なうことは避けられる。
【００９３】
（実施の形態６）
上記の実施の形態５では、ヘッダにＥＭＩが含まれる場合の実施例について説明したが、本実施の形態では、コンテンツを受け取った受信装置でのデータの取り扱い方法を規定した識別子（以下ＣＴ：Ｃｏｎｔｅｎｔ　Ｔｙｐｅとする）をヘッダに付加する場合の実施例について説明する。
【００９４】
ＤＴＣＰでは、コンテンツによって受信したデータをどのように扱うかが詳細に定義されている。例えば、ＤＴＣＰを使用するＭＰＥＧ−ＴＳなどのコンテンツに含まれるコピー制御情報（以下、「ＣＣＩ：Ｃｏｐｙ　Ｃｏｎｔｒｏｌ　Ｉｎｆｏｒｍａｔｉｏｎ」という。）を解釈できる送信装置は、コンテンツに含まれるＣＣＩ情報を解釈して、所定のＥＭＩを付加して印刷しなければならないという定義や、ＩＥＣ６１８８３−６に規定されているＡＭ８２４　Ａｕｄｉｏ　コンテンツの場合、このように扱わなければならないという内容が定義されている。そこで、コンテンツの種類を識別子の形でヘッダにして送信することで、受信装置側で受信したデータをどのように扱わなければならないかが識別できる。
【００９５】
図１６は、Ａｓｙｎｃｈｒｏｎｏｕｓ転送時のフレームのデータ構造の変遷の様子を表す図である。コンテンツのフレームは、データパケット３４０に分割され、データパケットヘッダ３４１が付加される（ステップ３３０）。データパケットを付加されたデータは、データヘッダと共に暗号化される（ステップ３３１）。暗号化されたデータは、前述のパケットヘッダ３４２を付加して送信される。
【００９６】
このデータに対して受信装置は、パケットヘッダをはずし、暗号データを復号化して、データパケットヘッダをはずすと共にデータパケットヘッダに含まれるＣＴを抽出し、データを復号する。そして、受信装置は、パケットヘッダに含まれているＥＭＩ情報とデータパケットヘッダから抽出したＣＴ、場合によってはコンテンツに格納されているＣＣＩを用いて受信データについての詳細な処理を行なう。
【００９７】
以上のように、データの取り扱いを規定した識別子を付加したＣＴヘッダを暗号化することで、コンテンツを搾取するというような不法行為を防止することができる。
【００９８】
（実施の形態７）
上記の実施の形態１〜６では、データの伝送方法について説明してきたが、本実施の形態では、複数の論理接続をサポートできる装置間での認証鍵の使い方について例示する。
【００９９】
ここで、図１７に示すように、２つの装置の間で、２つの論理的接続を使ってデータを送受信する場合を考える。図１７において、送信装置２７０の記憶装置２７２に記録されているコンテンツを２つの論理的接続、２７５ａ、２７５ｂを用いて、受信装置２７１の第１の記録デバイス（例えば、ＶＴＲ）２７３と第２の記録デバイス（例えば、ＤＶＤ）２７４に記録する場合を考える。
【０１００】
まず、第１の記録デバイス２７３への記録が開始され、続いて第２の記録デバイス２７４への記録が開始されるものとする。
図１８は、上記の論理的接続を確立するための通信シーケンス図である。まず、第１の論理的接続２７５ａが確立される（ステップ３００）。さらに、送信装置２７０は受信装置２７１に対して暗号モードを通知する（ステップ３０１）。暗号モードを受け取った受信装置２７１は、送信装置２７０に対して認証開始要求を発行する（ステップ３０２）。
【０１０１】
ここで、上記で説明したように、送信装置２７０と受信装置２７１は、ＡＫＥのシーケンスに入って認証と交換鍵Ｋｘが交換される（ステップ３０３）。ＡＫＥが完了すると、受信装置２７１は送信装置２７０に対してデータ送信要求を行ない（ステップ３０４）、データ送信が開始される（ステップ３０５）。この例は受信装置から送信要求を発行する場合を説明しているが、送信装置から送信開始通知を行なう場合も同様である。
【０１０２】
次に、第１の論理的接続２７５ａを用いて通信を行なっている最中に、第２の論理的接続２７５ｂを行なう場合を考える。第２の論理的接続が確立すると（ステップ３０６）、送信装置２７０は、第１の論理的接続の場合と同様に受信装置２７１に対して暗号モードを通知する（ステップ３０７）。暗号モードを受け取った受信装置２７１は、送信装置２７０に対して認証開始要求を発行する（ステップ３０８）が、すでに認証は済んでいるので送信装置２７０は認証済み通知を行なう（ステップ３０９）。受信装置２７１、認証済みであることがわかると、暗号鍵の問い合わせを行ない（ステップ３１０）、送信装置２７０から暗号鍵が通知される（ステップ３１１）。この時点で、受信装置２７１は暗号データを復号化する準備が整うので、データの送信が開始可能となる（ステップ３１２）。
【０１０３】
なお、上記の２つの論理的接続によるデータ伝送は、一方が非同期方式で他方が同期方式でもよく、また、両方が非同期方式若しくは同期方式でもよい。
以上のように、２台の装置間で複数の論理的接続が可能な場合は、機器認証の処理を流用することによって、認証に関する処理時間を短縮することが可能となる。
【０１０４】
（実施の形態８）
上記の実施の形態１〜７では、Ａｓｙｎｃｈｒｏｎｏｕｓコネクションを確立する毎に機器認証を行なうことを前提にした伝送方式について説明したが、以下の実施の形態では、機器認証は電気的に最初に接続されたときにのみ行ない、以降のコネクション確立時では暗号鍵の変更のみを行なう方式について説明する。
【０１０５】
図１９は、本実施の形態に係るデータ伝送システム１０ｆにおける通信シーケンス図である。Ｐｒｏｄｕｃｅｒ３０（送信側）とＣｏｎｓｕｍｅｒ４０（受信側）は、ＩＥＥＥ１３９４バスが電気的に接続されたときに、まず初期化の処理を行なう（ステップ８１）。その後、Ｐｒｏｄｕｃｅｒ３０及びＣｏｎｓｕｍｅｒ４０の相互機器認証を行なう（ステップ８２）。認証方法については、上記の実施の形態において説明しているので、ここでは省略する。
【０１０６】
データＡの伝送を行なうため、予めＡｓｙｎｃｈｒｏｎｏｕｓコネクションの確立を行なう（ステップ８３）。この処理についても、上記の実施の形態において説明しているのでここでは省略する。コネクションが確立された段階でＰｒｏｄｕｃｅｒ３０とＣｏｎｓｕｍｅｒ４０の間で暗号鍵の交換を行なう（ステップ８４）。さらに、暗号鍵の交換が完了後にデータ伝送を行なう（ステップ８５）。データを全て終了すると、ディスコネクトしてコネクションを解除する（ステップ８６）。
【０１０７】
次に、データＢの伝送を行なうとき、あらためてＡｓｙｎｃｈｒｏｎｏｕｓコネクションの確立を行なう（ステップ８７）。この場合のコネクションを確立する段階では、機器認証は行なわず、Ｐｒｏｄｕｃｅｒ３０とＣｏｎｓｕｍｅｒ４０の間で、新たな暗号鍵の交換のみを行なう（ステップ８８）。このときの暗号鍵はデータＡを伝送した場合の暗号鍵とは異なるものである。以下、同様にしてＡｓｙｎｃｈｒｏｎｏｕｓコネクションを確立する毎に暗号鍵の交換のみを行なう。なお、上記では、データＡ及びデータＢの２つのデータを伝送する実施例について示したが、それ以上の複数のデータを伝送する場合も同様に実施することが可能である。
【０１０８】
以上のように、本実施の形態に係るデータ伝送システムによれば、送信側と受信側との相互の機器認証は、電気的に接続された最初の１回のみ実行し、暗号鍵の変更は、コネクションが確立する毎に実行するので、機器認証に要する時間の削減を可能とすると共に、データが不正に搾取されることを防止することができる。
【０１０９】
なお、上記実施の形態では、同一のコネクション中に暗号鍵を切り替える様に構成しても同様の効果が得られるのは明白である。さらに、上記実施の形態では、初期化処理の際に機器認証を行なう場合について説明したが、数時間単位、毎日、週１回毎、データ伝送１０回毎等のように、データ伝送に比べて長いサイクルで認証を行なうようにデータ伝送システムを構成してもよい。
【０１１０】
【発明の効果】
以上のように、本発明に係るデータ伝送システムは、送信側と受信側とのコネクションを確立する前後又はコネクションを確立する途中で、相互の機器認証を行なうと共に、ひとまとまりのデータのＡｓｙｎｃｈｒｏｎｏｕｓ転送毎に異なる暗号鍵を用いてデータの暗号化を行なっているので、万一、暗号鍵を搾取されても次のデータを転送する際には別の暗号鍵を用いて暗号化を行なう。従って、ＩＥＥＥ１３９４Ａｓｙｎｃｈｒｏｎｏｕｓ転送においても、不正な機器からコンテンツを保護することが可能となる。
【０１１１】
また、本発明に係るデータ伝送システムは、Ａｓｙｎｃｈｒｏｎｏｕｓ転送を行なう際の暗号化するデータの単位を適宜変更し、送信側から受信側に通知するので、セキュリティの強度をより高めることが可能となる。
さらに、本発明に係るデータ伝送システムは、ひとまとまりのデータのＡｓｙｎｃｈｒｏｎｏｕｓ転送の途中で、ｉＡＰＲレジスタ等のリザーブフィールド等を利用して適宜に暗号鍵を切り替えるので、送信側と受信側で暗号鍵の切替タイミングを一致させることが可能となるので、必要に応じて暗号鍵を自由に切り替えることができる。
【０１１２】
さらにまた、本発明に係るデータ伝送システムは、送信側と受信側との相互の機器認証は、電気的に接続された最初の１回のみ実行し、暗号鍵の切り替えは、コネクションが確立する毎に実行するので、機器認証に要する時間を削減することが可能とすると共に、セキュリティも確保することが可能となる。
【図面の簡単な説明】
【図１】実施の形態１におけるデータ伝送システムの全体の機能構成を示すブロック図である。
【図２】実施の形態１におけるＡｓｙｎｃｈｒｏｎｏｕｓ転送を行なうためのコネクションを確立する際の通信シーケンス図である。
【図３】実施の形態２におけるＡｓｙｎｃｈｒｏｎｏｕｓ転送を行なうためのコネクションを確立する際の通信シーケンス図である。
【図４】一般的なＩＥＥＥ１３９４Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるデータ転送の様子を示す概念図である。
【図５】ｉＡＰＲレジスタの構造を示す図である。
【図６】ｏＡＰＲレジスタの構造を示す図である。
【図７】ＩＥＥＥ１３９４Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるデータ転送の様子を示す通信シーケンス図である。
【図８】実施の形態３における送信側から受信側にデータ転送要求がある場合の通信シーケンスの概略図である。
【図９】（ａ）は、複数のフレームの送信時における、所定の大きさより小さいフレームと暗号鍵の更新タイミングとの時間的な関係を示す模式図である。
（ｂ）は、複数のフレームの送信時における、所定の大きさより大きいフレームと暗号鍵の更新タイミングとの時間的な関係を示す模式図である。
【図１０】複数のフレームの送信時に暗号鍵の更新を行なう場合のフローチャートである。
【図１１】実施の形態３における、他の方法によって暗号鍵を切り替えるデータ伝送システムにおける通信シーケンス図である。
【図１２】実施の形態３における、データ伝送システムによるデータ転送の途中で暗号鍵を切り替える場合のフローチャートである。
【図１３】実施の形態４におけるフレームを数個のパケットに分割した場合のデータの構成図である。
【図１４】（ａ）は、実施の形態４におけるデータサイズを算出方法の概略図である。
（ｂ）は、単位ブロックの整数倍のデータで構成されるＰＣＰパケットのデータ構造を示す図である。
【図１５】実施の形態５におけるフレーム内のパケット構成の概略図である。
【図１６】実施の形態６におけるデータ送信時のデータ構造の変遷を表した図である。
【図１７】実施の形態７におけるシステム構成の一例である。
【図１８】実施の形態７におけるデータ送信時の概略通信シーケンス図である。
【図１９】実施の形態８におけるデータ伝送システムの通信シーケンス図である。
【図２０】従来のディジタル映像信号やディジタル音声信号の伝送にＩＥＥＥ１３９４を利用する場合のＡＶプロトコルスタックを示す図である。
【図２１】Ｉｓｏｃｈｒｏｎｏｕｓ通信におけるＩｓｏｃｈｒｏｎｏｕｓパケットのパケット構造図である。
【図２２】Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるＡｓｙｎｃｈｒｏｎｏｕｓパケットのパケット構造図である。
【図２３】従来のＡｓｙｎｃｈｒｏｎｏｕｓ通信における通信シーケンス図である。
【図２４】従来の機器認証と暗号鍵の交換に係る通信シーケンスの概略図である。
【符号の説明】
１０ａ　　データ伝送システム
１０ｅ　　データ伝送システム
１０ｆ　　データ伝送システム
３０ａ　　フレーム
３０ｂ　　セグメント
３１　　　パラメータ交換部
３２　　　認証鍵生成部
３３　　　交換鍵記憶部
３４　　　交換鍵暗号化部
３５　　　交換鍵交換部
３６　　　暗号化パラメータ送信部
３７　　　暗号鍵生成部
３８　　　コンテンツ暗号化部
４０ａ　　フレーム
４０ｂ　　セグメントバッファ
４１　　　パラメータ交換部
４２　　　認証鍵生成部
４４　　　交換鍵復号化部
４５　　　交換鍵交換部
４６　　　暗号化パラメータ受信部
４７　　　暗号鍵生成部
４８　　　コンテンツ復号化部
５０　　　ＩＥＥＥ１３９４バス
６０　　　ｉＡＰＲレジスタ
７０　　　ｏＡＰＲレジスタ
１０２　　　ＡＶプロトコル
１０３　　　リアルタイムデータ伝送
１０４　　　信号伝送手順
１０５　　　コントロール信号
１４１　　　Ｏ／Ｅフィールド
２７０　　　送信装置
２７１　　　受信装置
２７２　　　記憶装置
２７３　　　記録デバイス
２７４　　　記録デバイス

Claims

通信インタフェースを介して接続されているデータ受信装置に対して、非同期通信方式でデータを送信するデータ送信装置であって、
前記データ受信装置と情報のやりとりをすることによって、前記データ受信装置との間に論理的な伝送路を確立するコネクション確立手段と、
前記論理的な伝送路が確立される前、又は、前記論理的な伝送路の確立過程において、又は、前記論理的な伝送路が確立された後に、前記データ受信装置に対する機器認証を行なう機器認証手段と、
前記機器認証手段による機器認証の結果に基づいて、暗号鍵を生成し、生成した暗号鍵を前記データ受信装置との間で共有化する暗号鍵共有化手段と、
共有化された暗号鍵を用いてデータを暗号化し、前記データ受信装置に送信するデータ送信手段と
を備えることを特徴とするデータ送信装置。
前記機器認証手段は、前記データ受信装置が不正な装置か否かを判別する第１の機器認証部、及び、前記データ受信装置が不正な装置ではなく、かつ正当な装置か否かを判別する第２の機器認証部、及び、前記データ受信装置が正当な装置か否かを判別する第３の機器認証部の少なくとも１つを有し、
前記鍵情報共有化手段は、前記第１の機器認証部によって前記データ受信装置が不正な装置ではないと判別された場合、又は、前記第２の機器認証部によって前記データ受信装置が不正な装置ではなく、かつ正当な装置であると判別された場合、又は、前記第３の機器認証部によって前記データ受信装置が正当な装置であると判別された場合に、前記暗号鍵の共有化を行なう
ことを特徴とする請求の範囲第１項記載のデータ送信装置。
前記機器認証手段は、前記データ送信装置と前記データ受信装置とが電気的に接続されたことを検出した場合に、前記機器認証を行なう
ことを特徴とする請求の範囲第１項記載のデータ送信装置。
前記機器認証手段は、
前記論理的な伝送路が確立された時刻からの経過時間を計測する計時部と、
前記データ受信装置から機器認証要求を受け付ける認証要求受付部と、
前記計時部によって一定時間が計測されるまでに前記認証要求受付部が機器認証要求を受け付けたか否かを判定する要求判定部と、
前記計時部によって一定時間が計測されるまでに前記認証要求受付部が機器認証要求を受け付けなかったと判定された場合に、前記データ受信装置に対して機器認証未対応通知を行なう受信装置モード通知部と
を備えることを特徴とする請求の範囲第１項記載のデータ送信装置。
前記コネクション確立手段によって論理的な伝送路が確立される毎に、前記機器認証手段は前記機器認証を行ない、前記暗号鍵共有化手段は前記暗号鍵を生成し、生成した暗号鍵を共有する
ことを特徴とする請求の範囲第１項記載のデータ送信装置。
前記データ送信装置はさらに、前記データ受信装置に対して、暗号化してデータ送信を行なう暗号化モードか暗号化せずにデータ送信を行なう通常モードかを通知する転送モード通知手段を備え、
前記機器認証手段は、前記転送モード通知手段によって前記データ受信装置に暗号化モードが通知された場合に、前記データ受信装置に対する機器認証を行ない、
前記データ送信手段は、前記転送モード通知手段によって前記データ受信装置に暗号化モードが通知された場合には、前記データを暗号化して送信し、前記転送モード通知手段によって前記データ受信装置に通常モードが通知された場合には、前記データを暗号化しないで送信する
ことを特徴とする請求の範囲第１項記載のデータ送信装置。
前記機器認証手段は、前記データ受信装置が不正な装置か否かを判別する第１の機器認証部、及び、前記データ受信装置が不正な装置ではなく、かつ正当な装置か否かを判別する第２の機器認証部、及び、前記データ受信装置が正当な装置か否かを判別する第３の機器認証部の少なくとも１つを有し、
前記鍵情報共有化手段は、前記第１の機器認証部によって前記データ受信装置が不正な装置ではないと判別された場合、又は、前記第２の機器認証部によって前記データ受信装置が不正な装置ではなく、かつ正当な装置であると判別された場合、又は、前記第３の機器認証部によって前記データ受信装置が正当な装置であると判別された場合に、前記暗号鍵の共有化を行なう
ことを特徴とする請求の範囲第６項記載のデータ送信装置。
前記データ送信装置はさらに、前記転送モード通知手段による通知に対して前記データ受信装置が正常に応答しない場合に、前記データ受信装置に対して機器認証未対応通知を行なう受信装置モード通知手段を備える
ことを特徴とする請求の範囲第６項記載のデータ送信装置。
前記データ送信手段は、前記受信装置モード通知手段によって機器認証未対応通知が行なわれた場合に、データを送信しない
ことを特徴とする請求の範囲第８項記載のデータ送信装置。
前記データ送信手段は、前記受信装置モード通知手段によって機器認証未対応通知が行なわれた場合に、暗号化不要なデータだけを送信する
ことを特徴とする請求の範囲第８項記載のデータ送信装置。
前記データ送信装置はさらに、前記受信装置モード通知手段によって機器認証未対応通知が行なわれた場合に、前記コネクション確立手段によって確立された伝送路を解除する伝送路解除手段を備える
ことを特徴とする請求の範囲第８項記載のデータ送信装置。
送信すべきデータは、論理的な伝送単位であるフレームの集まりからなり、
前記データ送信手段は、前記フレーム毎に、前記暗号鍵を更新し、更新した暗号鍵を用いて前記フレームを暗号化し、前記データ受信装置に送信する
ことを特徴とする請求の範囲第１項記載のデータ送信装置。
前記フレームは、前記データ受信装置から前記データ送信装置への１回の送信要求に対して前記データ送信装置から前記データ受信装置に送信されるデータである
ことを特徴とする請求の範囲第１２項記載のデータ送信装置。
前記データ送信手段はさらに、前記フレームが所定量よりも大きい場合には、前記所定量の単位で前記暗号鍵を更新する
ことを特徴とする請求の範囲第１２項記載のデータ送信装置。
前記データ送信装置はさらに、
前記フレームを物理的な伝送単位であるパケットに分割するフレーム分割手段と、
前記パケットに当該パケットに関する情報を含むパケットヘッダを付加するパケットヘッダ付加手段とを備える
ことを特徴とする請求の範囲第１２項記載のデータ送信装置。
前記データ送信手段は、一定サイズのデータであるブロックを単位として前記フレームを暗号化し、前記フレームが前記ブロックの整数倍でない場合には、整数倍になるように、前記フレームを構成する所定のパケットにパディングデータを付加すると共に、前記パケットのパケットヘッダに前記パケットの実効データサイズを示す情報を含ませる
ことを特徴とする請求の範囲第１５項記載のデータ送信装置。
前記パケットヘッダのデータサイズは、前記ブロックの整数倍である
ことを特徴とする請求の範囲第１６項記載のデータ送信装置。
前記パケットヘッダ付加手段は、前記パケットに施している暗号の種類を示す暗号モード識別子を含むパケットヘッダを前記パケットに付加し、
前記フレームは、複数のファイルで構成され、
前記データ送信装置はさらに、前記複数のファイルの暗号モード識別子が異なる場合には、フレームの最終パケットを含むファイル以外のファイルについて、最終パケットのデータサイズが他のパケットと同一となるように、前記最終パケットにパディングデータを付加するパケット調整手段を備える
ことを特徴とする請求の範囲第１５項記載のデータ送信装置。
前記パケットヘッダ付加手段は、前記パケットに施している暗号の種類を示す暗号モード識別子を含むパケットヘッダを前記パケットに付加し、
前記フレームは、複数のファイルで構成され、
前記データ送信手段は、前記複数のファイルの前記暗号モード識別子が異なる場合には、前記暗号モード識別子の異なるファイルを別のフレームで送信する
ことを特徴とする請求の範囲第１５項記載のデータ送信装置。
送信すべきデータは、論理的な伝送単位であるフレームからなり、
前記データ送信装置はさらに、
前記フレームを物理的な伝送単位であるパケットに分割するフレーム分割手段と、
前記パケットに、当該パケットを受信したデータ受信装置での取り扱い方法を示すコンテンツタイプ識別子を含むパケットヘッダを付加するパケットヘッダ付加手段とを備え、
前記データ送信手段は、前記パケットヘッダが付加されたパケットを暗号化して送信する
ことを特徴とする請求の範囲第１項記載のデータ送信装置。
前記フレームは、複数のファイルで構成され、
前記データ送信装置はさらに、前記複数のファイルのコンテンツタイプ識別子が異なる場合には、フレームの最終パケットを含むファイル以外のファイルについて、最終パケットのデータサイズが他のパケットと同一となるように、前記最終パケットにパディングデータを付加するパケット調整手段を備える
ことを特徴とする請求の範囲第２０項記載のデータ送信装置。
送信すべきデータは、複数のフレームからなり、
前記データ送信手段は、前記フレーム毎に、前記暗号鍵を更新し、更新した暗号鍵を用いて前記フレームを暗号化し、前記データ受信装置に送信する
ことを特徴とする請求の範囲第２１項記載のデータ送信装置。
前記フレームは、複数のファイルで構成され、
前記データ送信手段は、前記複数のファイルの前記コンテンツタイプ識別子が異なる場合には、前記コンテンツタイプ識別子の異なるファイルを別のフレームで送信する
ことを特徴とする請求の範囲第２０項記載のデータ送信装置。
送信すべきデータは、複数のフレームからなり、
前記データ送信手段は、前記フレーム毎に、前記暗号鍵を更新し、更新した暗号鍵を用いて前記フレームを暗号化し、前記データ受信装置に送信する
ことを特徴とする請求の範囲第２３項記載のデータ送信装置。
前記通信インタフェースは、ＩＥＥＥ１３９４インタフェースであり、
前記非同期通信方式は、ＩＥＥＥ１３９４で規定されたＡｓｙｎｃｈｒｏｎｏｕｓ通信方式である
ことを特徴とする請求の範囲第１項記載のデータ送信装置。
通信インタフェースを介して接続されているデータ受信装置に対してデータを送信するデータ送信装置であって、
前記データ受信装置との間で同時かつ独立したデータ伝送が可能な２つ又はそれ以上の論理的な伝送路を確立するための機器認証を前記データ受信装置に対して行なう機器認証手段と、
前記機器認証手段による機器認証によって確立された第１の論理的な伝送路を介して前記データ受信装置にデータを送信する第１のデータ送信手段と、
前記機器認証手段による機器認証によって確立された第２の論理的な伝送路を介して前記データ受信装置にデータを送信する第２のデータ送信手段とを備え、
前記機器認証手段は、第１の論理的な伝送路だけのための機器認証を行ない、その機器認証の結果に基づいて、暗号鍵を生成し、生成した暗号鍵を前記データ受信装置との間で共有化し、
前記第１及び第２のデータ送信手段は、いずれも、前記機器認証手段によって共有化された暗号鍵を用いて、データを暗号化し、前記データ受信装置に送信する
ことを特徴とするデータ送信装置。
前記第１の論理的な伝送路は、非同期通信方式による伝送路であり、
前記第２の論理的な伝送路は、同期通信方式による伝送路である
ことを特徴とする請求の範囲第２６項記載のデータ送信装置。
通信インタフェースを介して接続されているデータ送信装置から非同期通信方式でデータを受信するデータ受信装置であって、
前記データ送信装置と情報のやりとりをすることによって、前記データ送信装置との間に論理的な伝送路を確立するコネクション確立手段と、
前記論理的な伝送路が確立される前、又は、前記論理的な伝送路の確立過程において、又は、前記論理的な伝送路が確立された後に、前記データ送信装置が当該データ受信装置を認証するための機器認証を行なう機器認証手段と、
前記機器認証手段による機器認証の結果に基づいて、暗号鍵を生成し、生成した暗号鍵を前記データ受信装置との間で共有化する暗号鍵共有化手段と、
前記データ送信装置から送られてくるデータを受信し、受信したデータを前記暗号鍵共有化手段によって共有化された暗号鍵で復号化するデータ受信手段と
を備えることを特徴とするデータ受信装置。
前記機器認証手段は、
前記論理的な伝送路が確立された時刻からの経過時間を計測する計時部と、
前記データ送信装置から、暗号化してデータ送信を行なう暗号化モードか暗号化せずにデータ送信を行なう通常モードかの通知を受ける転送モード通知受付部と、
前記データ送信装置に対して機器認証要求を行なう認証要求発行部と、
前記計時部によって一定時間が計測されるまでに前記転送モード通知受付部が暗号化モードの通知を受けたか否かを判定する通知判定部とを備え、
前記データ受信手段は、前記通知判定部によって前記転送モード通知受付部が暗号化モードの通知を受けたと判定された場合には、前記データ送信装置から送られてくるデータを前記暗号鍵で復号化し、前記通知判定部によって前記転送モード通知受付部が暗号化モードの通知を受けなかったと判定された場合、及び、前記転送モード通知受付部が通常モードの通知を受けた場合には、前記データ送信装置から送られてくるデータを暗号化されていないデータとして扱い、前記データを復号化しない
ことを特徴とする請求の範囲第２８記載のデータ受信装置。
前記機器認証手段は、前記データ送信装置と前記データ受信装置とが電気的に接続されたことを検出した場合に、前記機器認証を行なう
ことを特徴とする請求の範囲第２８項記載のデータ受信装置。
前記データ受信手段は、前記機器認証手段による機器認証によって、当該データ受信装置に対する前記データ送信装置の機器認証が拒絶された場合に、前記データ送信装置から送られてくるデータを暗号化されていないデータとして扱い、前記データを復号化しない
ことを特徴とする請求の範囲第２８項記載のデータ受信装置。
前記データ送信装置から送られてくるデータは、論理的な伝送単位であるフレームの集まりからなり、
前記データ受信手段は、受信したデータを構成するフレーム毎に、前記暗号鍵を更新し、更新した暗号鍵を用いて前記フレームを復号化する
ことを特徴とする請求の範囲第２８項記載のデータ受信装置。
前記データ受信手段はさらに、前記フレームが所定量よりも大きい場合には、前記所定量の単位で前記暗号鍵を更新する
ことを特徴とする請求の範囲第３２項記載のデータ受信装置。
前記データ受信手段はさらに、前記フレームが所定量よりも大きい場合には、前記フレーム中の暗号化されていない所定のヘッダに含まれる暗号鍵更新情報に基づいて前記暗号鍵を更新する
ことを特徴とする請求の範囲第３２項記載のデータ受信装置。
前記フレームは、物理的な伝送単位であるパケットの集まりからなり、
前記パケットは、前記データ送信装置から当該データ受信装置に転送すべきデータが暗号化されて含まれるパケット本体と当該パケットに関する非暗号化情報が含まれるパケットヘッダとからなり、
前記データ受信手段は、受信したデータを構成するフレームからパケットヘッダを除去した後に、前記フレームを復号化する
ことを特徴とする請求の範囲第３２項記載のデータ受信装置。
前記パケットヘッダには、前記パケット本体に含まれるデータの実効長を示す実効データ長が含まれ、
前記データ受信手段は、受信したデータを構成するパケットヘッダから前記実効データ長を抽出し、抽出した実効データ長から、当該パケット本体に含まれる暗号化データのサイズを示す暗号データ長を算出し、算出した暗号データ長分の前記暗号化データを復号する
ことを特徴とする請求の範囲第３５項記載のデータ受信装置。
前記データ送信装置から送られてくるデータは、物理的な伝送単位であるパケットの集まりからなり、
前記パケットは、前記データ送信装置から当該データ受信装置に転送すべきデータが暗号化されて含まれるパケット本体と当該パケットを受信したデータ受信装置での取り扱い方法を示すコンテンツタイプ識別子が含まれるパケットヘッダとからなり、
前記データ受信手段はさらに、受信したデータのパケットヘッダから前記コンテンツタイプ識別子を抽出し、
前記データ受信装置はさらに、前記データ受信手段によって抽出されたコンテンツタイプ識別子に応じた処理方式で、前記データ受信手段が受信したデータを処理するデータ処理手段を備える
ことを特徴とする請求の範囲第２８項記載のデータ受信装置。
前記データ処理手段は、前記コンテンツタイプ識別子が所定の値を示す場合に、暗号の種類を示す暗号モード識別子を前記データに付加して印刷出力する
ことを特徴とする請求の範囲第３７項記載のデータ受信装置。
前記通信インタフェースは、ＩＥＥＥ１３９４インタフェースであり、
前記非同期通信方式は、ＩＥＥＥ１３９４で規定されたＡｓｙｎｃｈｒｏｎｏｕｓ通信方式である
ことを特徴とする請求の範囲第２８項記載のデータ受信装置。
通信インタフェースを介して接続されているデータ送信装置とデータ受信装置とを備えるデータ伝送システムであって、
前記データ送信装置は、
前記データ受信装置と情報のやりとりをすることによって、前記データ受信装置との間に論理的な伝送路を確立する第１のコネクション確立手段と、
前記論理的な伝送路が確立される前、又は、前記論理的な伝送路の確立過程において、又は、前記論理的な伝送路が確立された後に、前記データ受信装置に対する機器認証を行なう第１の機器認証手段と、
前記第１の機器認証手段による機器認証の結果に基づいて、暗号鍵を生成し、生成した暗号鍵を前記データ受信装置との間で共有化する第１の暗号鍵共有化手段と、
共有化された暗号鍵を用いてデータを暗号化し、前記データ受信装置に非同期通信方式で送信するデータ送信手段とを備え、
前記データ受信装置は、
前記データ送信装置と情報のやりとりをすることによって、前記データ送信装置との間に論理的な伝送路を確立する第２のコネクション確立手段と、
前記論理的な伝送路が確立される前、又は、前記論理的な伝送路の確立過程において、又は、前記論理的な伝送路が確立された後に、前記データ送信装置が当該データ受信装置を認証するための機器認証を行なう第２の機器認証手段と、
前記第２の機器認証手段による機器認証の結果に基づいて、暗号鍵を生成し、生成した暗号鍵を前記データ受信装置との間で共有化する第２の暗号鍵共有化手段と、
前記データ送信装置から送られてくるデータを非同期通信方式で受信し、受信したデータを前記第２の暗号鍵共有化手段によって共有化された暗号鍵で復号化するデータ受信手段とを備える
ことを特徴とするデータ伝送システム。
通信インタフェースを介して接続されているデータ受信装置に対して、非同期通信方式でデータを送信するデータ送信方法であって、
前記データ受信装置と情報のやりとりをすることによって、前記データ受信装置との間に論理的な伝送路を確立するコネクション確立ステップと、
前記論理的な伝送路が確立される前、又は、前記論理的な伝送路の確立過程において、又は、前記論理的な伝送路が確立された後に、前記データ受信装置に対する機器認証を行なう機器認証ステップと、
前記機器認証ステップによる機器認証の結果に基づいて、暗号鍵を生成し、生成した暗号鍵を前記データ受信装置との間で共有化する暗号鍵共有化ステップと、
共有化された暗号鍵を用いてデータを暗号化し、前記データ受信装置に送信するデータ送信ステップと
を含むことを特徴とするデータ送信方法。
通信インタフェースを介して接続されているデータ受信装置に対してデータを送信するデータ送信方法であって、
前記データ受信装置との間で同時かつ独立したデータ伝送が可能な２つの論理的な伝送路を確立するための機器認証を前記データ受信装置に対して行なう機器認証ステップと、
前記機器認証ステップによる機器認証によって確立された第１の論理的な伝送路を介して前記データ受信装置にデータを送信する第１のデータ送信ステップと、
前記機器認証ステップによる機器認証によって確立された第２の論理的な伝送路を介して前記データ受信装置にデータを送信する第２のデータ送信ステップとを含み、
前記機器認証ステップでは、第１の論理的な伝送路だけのための機器認証を行ない、その機器認証の結果に基づいて、暗号鍵を生成し、生成した暗号鍵を前記データ受信装置との間で共有化し、
前記第１及び第２のデータ送信ステップでは、いずれも、前記機器認証ステップによって共有化された暗号鍵を用いて、データを暗号化し、前記データ受信装置に送信する
ことを特徴とするデータ送信方法。
通信インタフェースを介して接続されているデータ送信装置から非同期通信方式でデータを受信するデータ受信方法であって、
前記データ送信装置と情報のやりとりをすることによって、前記データ送信装置との間に論理的な伝送路を確立するコネクション確立ステップと、
前記論理的な伝送路が確立される前、又は、前記論理的な伝送路の確立過程において、又は、前記論理的な伝送路が確立された後に、前記データ送信装置が当該データ受信装置を認証するための機器認証を行なう機器認証ステップと、
前記機器認証ステップによる機器認証の結果に基づいて、暗号鍵を生成し、生成した暗号鍵を前記データ送信装置との間で共有化する暗号鍵共有化ステップと、
前記データ送信装置から送られてくるデータを受信し、受信したデータを前記暗号鍵共有化ステップによって共有化された暗号鍵で復号化するデータ受信ステップと
を含むことを特徴とするデータ受信方法。
通信インタフェースを介して接続されているデータ受信装置に対して、非同期通信方式でデータを送信するデータ送信装置のためのプログラムであって、
前記データ受信装置と情報のやりとりをすることによって、前記データ受信装置との間に論理的な伝送路を確立するコネクション確立ステップと、
前記論理的な伝送路が確立される前、又は、前記論理的な伝送路の確立過程において、又は、前記論理的な伝送路が確立された後に、前記データ受信装置に対する機器認証を行なう機器認証ステップと、
前記機器認証ステップによる機器認証の結果に基づいて、暗号鍵を生成し、生成した暗号鍵を前記データ受信装置との間で共有化する暗号鍵共有化ステップと、
共有化された暗号鍵を用いてデータを暗号化し、前記データ受信装置に送信するデータ送信ステップと
を含むことを特徴とするプログラム。
通信インタフェースを介して接続されているデータ受信装置に対してデータを送信するデータ送信装置のためのプログラムであって、
前記データ受信装置との間で同時かつ独立したデータ伝送が可能な２つの論理的な伝送路を確立するための機器認証を前記データ受信装置に対して行なう機器認証ステップと、
前記機器認証ステップによる機器認証によって確立された第１の論理的な伝送路を介して前記データ受信装置にデータを送信する第１のデータ送信ステップと、
前記機器認証ステップによる機器認証によって確立された第２の論理的な伝送路を介して前記データ受信装置にデータを送信する第２のデータ送信ステップとを含み、
前記機器認証ステップでは、第１の論理的な伝送路だけのための機器認証を行ない、その機器認証の結果に基づいて、暗号鍵を生成し、生成した暗号鍵を前記データ受信装置との間で共有化し、
前記第１及び第２のデータ送信ステップでは、いずれも、前記機器認証ステップによって共有化された暗号鍵を用いて、データを暗号化し、前記データ受信装置に送信する
ことを特徴とするプログラム。
通信インタフェースを介して接続されているデータ送信装置から非同期通信方式でデータを受信するデータ受信装置のためのプログラムであって、
前記データ送信装置と情報のやりとりをすることによって、前記データ送信装置との間に論理的な伝送路を確立するコネクション確立ステップと、
前記論理的な伝送路が確立される前、又は、前記論理的な伝送路の確立過程において、又は、前記論理的な伝送路が確立された後に、前記データ送信装置が前記データ受信装置を認証するための機器認証を行なう機器認証ステップと、
前記機器認証ステップによる機器認証の結果に基づいて、暗号鍵を生成し、生成した暗号鍵を前記データ受信装置との間で共有化する暗号鍵共有化ステップと、
前記データ送信装置から送られてくるデータを受信し、受信したデータを前記暗号鍵共有化ステップによって共有化された暗号鍵で復号化するデータ受信ステップと
を含むことを特徴とするプログラム。