通信装置
【課題】認証処理の遅延を抑制しつつ、認証する機器数を正しく制限する「通信装置」を提供する。
【解決手段】認証処理部２１は、受信したＡＫＥリクエスト毎に、個別リクエスト認証処理を起動する。個別リクエスト認証処理では、処理中の先着したＡＫＥリクエストについての個別リクエスト認証処理による、認証済機器数を表すカウンタ値の増加の可能性の有無と、可能なカウンタ値の増加数を解析し、解析した増加数を、現在のカウンタ値に加えた値が、所定の制限数を超えない場合にのみ、ＡＫＥリクエストの認証処理を実行する。
【解決手段】認証処理部２１は、受信したＡＫＥリクエスト毎に、個別リクエスト認証処理を起動する。個別リクエスト認証処理では、処理中の先着したＡＫＥリクエストについての個別リクエスト認証処理による、認証済機器数を表すカウンタ値の増加の可能性の有無と、可能なカウンタ値の増加数を解析し、解析した増加数を、現在のカウンタ値に加えた値が、所定の制限数を超えない場合にのみ、ＡＫＥリクエストの認証処理を実行する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の機器をネットワークで接続し、コンテンツの送信元となる機器であるソースが、コンテンツの送信先となる機器を認証して、認証した機器にコンテンツを送信するシステムにおいて、ソースで認証する機器数を制限する技術に関するものである。
【背景技術】
【０００２】
複数の機器をネットワークで接続し、コンテンツの送信元となる機器であるソースが、コンテンツの送信先となる機器を認証して、認証した機器にコンテンツを送信するシステムにおいて、ソースで認証する機器数を制限する技術としては、ソースにおいて、図６に示す手順によって認証機器数を制限する認証処理が知られている（たとえば、特許文献１、非特許文献１）。
【０００３】
図６に示すように、この認証処理では、ソースは、まず、カウンタＳＣを０に初期化する（ステップ６０２）。
そして、所定の契機で生じるキー廃棄の発生と（ステップ６０４）、認証及びキー交換を求めるＡＫＥ（Authentication and Key Exchange）リクエストの受信（ステップ６０６）を監視する。
そして、キー廃棄が発生している場合には（ステップ６０４）、ステップ６０２に戻り、ＳＣを０に初期化する。
一方、ＡＫＥリクエストを受信した場合には（ステップ６０６）、ＳＣが３４未満であるかどうかを調べ（ステップ６０８）、ＳＣが３４未満であれば、ＡＫＥ（Authentication and Key Exchange：認証及びキー交換）を、ＡＫＥリクエストの発行元との間で実行する（ステップ６１０）。
【０００４】
そして、ＡＫＥリクエストの発行元が、コンテンツを受信する機器であるシンクであるか、シンクのPloxyとなる機器であるバスブリッジであるかを、ＡＫＥリクエストに含まれるAPフラグの値より判定し（ステップ６１２）、APフラグが１であってＡＫＥリクエストの発行元がバスブリッジである場合には、ステップ６１８に進んで、ＳＣを１増加し、ステップ６０４、６０６の監視に戻る。
【０００５】
一方、APフラグが０であってＡＫＥリクエストの発行元がシンクである場合には、ＡＫＥリクエストの発行元のシンクが、認証済のシンクを登録するレジスタに既に登録済みであるかどうかを調べ（ステップ６１４）、登録済であれば、そのままステップ６０４、６０６の監視に戻り、登録済でなければ、ＡＫＥリクエストの発行元のシンクをレジスタに登録した上で（ステップ６１６）、ステップ６１８に進んで、ＳＣを１増加し、ステップ６０４、６０６の監視に戻る。
【０００６】
一方、ステップ６０８で、ＳＣが３４以上であると判定された場合には、ＡＫＥリクエストの発行元がAP = 0のシンクであって、かつ、レジスタに既に登録済みであるかどうかを調べ（ステップ６２０）、そうであれば、ＡＫＥを、ＡＫＥリクエストの発行元との間で実行し（ステップ６２２）、ステップ６０４、６０６の監視に戻る。一方、ＡＫＥリクエストの発行元がAP = 0のシンクでないか、レジスタに登録されていない場合には（ステップ６２０）、ＡＫＥリクエストを拒絶し（ステップ６２４）、ステップ６０４、６０６の監視に戻る。
ここで、このような認証処理によれば、認証される機器数は３４以下に制限されることになる。
【０００７】
ここで、上述した認証処理による、ソースと、シンク/バスブリッジの全体の認証動作のシーケンスはおおよそ図７に示すものである。
すなわち、シンクまたはバスブリッジは、ソースに、certificate 等を伴うＡＫＥリクエストを発行する。
ソースは、図６に示した認証処理によってＡＫＥリクエストに対してＡＫＥを実行する場合には、当該ＡＫＥにおいて、以下の処理を行う。
すなわち、ＡＫＥリクエスト発行元の正当性をcertificateを用いて承認できたならば、ＡＫＥリクエスト発行元と、チャレンジ、レスポンスによって所定の情報を交換し、ソースとＡＫＥリクエスト発行元において共通の認証鍵を生成するチャレンジ-レスポンスシーケンスを実行する。
【０００８】
そして、チャレンジ-レスポンスシーケンスが成功したならば、認証鍵を用いて暗号化した交換キーをＡＫＥリクエスト発行元に送信する。
また、以降、ソースは、交換キーを利用して暗号化したコンテンツをＡＫＥリクエスト発行元に送信し、ＡＫＥリクエスト発行元では、ソースから受信した交換キーを利用して、ソースから送信されたコンテンツを復号し利用する。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００２-０８４２７４号公報
【非特許文献】
【００１０】
【非特許文献１】Hitachi, Ltd., Intel Corporation, Matsushita Electric Industrial Co., Ltd., Sony Corporation and Toshiba Corporation ,"Digital Transmission Content Protection Specification Volume 1 (Informational Version)", P.72-73, [online], 2007年10月1日, Digital Transmission Licensing Administrator (DTLA), [2009年12月22日検索],インターネット(http://www.dtcp.com/data/info 20071001 DTCP V1 1p51.pdf)
【発明の概要】
【発明が解決しようとする課題】
【００１１】
さて、図６に示した認証処理によって、ソースにおいて、認証する機器数を制限する場合には、以下の問題が生じる。
すなわち、ソースにおいて、連続的に複数のＡＫＥリクエストを受信した場合に、各ＡＫＥリクエストを逐次的に一つずつ、順次、処理した場合には、後着のＡＫＥリクエストに対する処理に比較的大きな遅延が生じる。
一方、各ＡＫＥリクエストを並列に処理した場合には、各ＡＫＥリクエストについての処理開始時にＳＣが３４未満であっても、各ＡＫＥリクエスト処理終了時にＳＣが３４以上となってしまうことがあり、この場合には、正しく認証する機器数を３４以下に制限できなくなる。すなわち、たとえば、ＳＣが３３のときに（認証済機器数が３３のときに）、二つのＡＫＥリクエストが連続して到着した場合に、この二つのＡＫＥリクエストの処理を平行して行うと、当該処理開始時点において、ＳＣが３３であるために、二つのＡＫＥリクエストに対してＡＫＥが実行されてしまうことがあり、この場合、二つのＡＫＥリクエストについての処理終了時には、認証機器数３４を超えて３５となってしまうことがある。
【００１２】
一方、連続的に複数のＡＫＥリクエストを受信した場合に、より先着のＡＫＥリクエストについてＡＫＥが実行されＳＣが１増加されるものと仮定して、ＳＣが３４以上とならないように、後着のＡＫＥリクエストを拒絶することも考えられるが、このようにすると先着のＡＫＥリクエストについての処理の結果ＳＣが１増加されなかった場合には、後着のＡＫＥリクエストを正当な理由なく拒絶してしまうことになる。すなわち、たとえば、ＳＣが３３のときに、二つのＡＫＥリクエストが連続して到着した場合に、１番目に到着したＡＫＥリクエストについてＡＫＥが実行されＳＣが１増加されてＳＣが３４となるものと仮定し、２番目に到着したＡＫＥリクエストを拒絶した場合において、１番目に到着したＡＫＥリクエストについてＡＫＥが実行されなかったり、ＡＫＥが実行されてもＳＣが１増加されなかった場合には、ＳＣが３３に維持されるので、２番目に到着したＡＫＥリクエストを不当に拒絶してしまったことになる。
【００１３】
そこで、本発明は、ソースにおいて、認証処理の遅延を抑制しつつ、認証する機器数を正しく制限することを課題とする。
【課題を解決するための手段】
【００１４】
前記課題達成のために、本発明は、通信機器とデータ通信を行う通信装置に、前記通信機器から受信した各認証要求について、当該認証要求の発行元の通信機器の認証を行うと共に、認証した通信機器が既に認証済の通信機器でない場合に、認証済機器数を１増加する認証処理を行う認証処理部と、前記認証処理部が認証した通信機器と前記データ通信を行うデータ通信部とを備え、前記認証処理部において、発行元が認証済の通信機器でない認証要求についての認証処理を、当該認証要求に先行して受信した、認証処理を実行中の、発行元が認証済の通信機器でない他の認証要求の数を、前記認証済機器数に加算した数が、前記所定の制限数未満である場合に実行するようにしたものである。
【００１５】
このような通信装置によれば、受信した認証要求についての認証処理を、先着した未処理の認証要求の認証処理による、認証済機器数の可能最大増加数を、未処理の認証要求の発行元の通信機器が認証済の通信機器であるかどうかより求め、求めた可能増加数が現在の認証済機器数に加えた値が、制限値未満となる場合のみ行う。
【００１６】
よって、各認証要求の認証処理によって、認証済機器数が制限値を越えることはないので、認証する機器数を正しく制限することができるようになる。また、先着の認証要求についての認証処理の完了を待たずに、後着の認証要求についての認証処理の実行を開始できるので、認証処理の遅延も抑制することができる。
【００１７】
また、本発明は、前記課題達成のために、通信機器とデータ通信を行う通信装置に、前記通信機器から受信した各認証要求について、当該認証要求の発行元の通信機器と認証鍵を共有するための第１の処理と、前記認証鍵を用いて暗号化した交換キーを前記通信装置に送信し、認証した通信機器が既に認証済の通信機器でない場合に、認証済機器数を１増加する第２の処理とを含む認証処理を行う認証処理部と、前記交換キーを送信した通信機器と、当該交換キーを利用した暗号化を施した前記データ通信を行うデータ通信部とを備え、前記認証処理部において、発行元が認証済の通信機器でない認証要求についての認証処理を、前記第１の処理を実行し、当該第１の処理の終了後に、前記第２の処理を実行中の他の認証処理が存在しなくなった時点で、前記認証済機器数が所定の制限数未満である場合に、前記第２の処理を実行することにより行うようにしたものである。
【００１８】
このような通信装置によれば、各認証要求についての認証処理において、第１の処理まで実行し、当該第１の処理の終了後に、前記第２の処理を実行中の他の認証処理が存在しなくなった時点で、前記認証済機器数が所定の制限数未満である場合に、第２の処理を行う。
【００１９】
よって、各認証要求についての認証処理により、認証済機器数が制限数を越えることはないので、認証する通信機器数を正しく制限することができるようになる。また、他の認証要求についての認証処理の状況如何に関わらずに、認証処理を、第２の処理直前の処理まで進めておけるので、認証処理の遅延も抑制することができる。
【発明の効果】
【００２０】
以上のように、本発明によれば、ソースにおいて、認証処理の遅延を抑制しつつ、認証する機器数を正しく制限することができる。
【図面の簡単な説明】
【００２１】
【図１】本発明の実施形態に係るＡＶシステムの構成を示すブロック図である。
【図２】本発明の実施形態に係るＡＶ装置の機能構成を示すブロック図である。
【図３】本発明の実施形態に係る認証処理を示すフローチャートである。
【図４】本発明の実施形態に係る個別リクエスト認証処理を示すフローチャートである。
【図５】本発明の実施形態に係る個別リクエスト認証処理を示すフローチャートである。
【図６】先行技術に係る認証処理を示すフローチャートである。
【図７】認証動作のシーケンスを示す図である。
【発明を実施するための形態】
【００２２】
以下、本発明の実施形態について説明する。
図１に、本実施形態に係るＡＶシステムの構成を示す。
図示するように、ＡＶシステムは、複数のＡＶ装置１をIEEE1394規格に従ったバス２で接続したものである。また、ＡＶシステムは、バス２間の中継等を行うバスブリッジ３によって連結された複数のバス２を備えて構成することもできる。
ここで、ＡＶ装置１は、それぞれ、バス制御部１０、ＣＰＵ１１、メモリ１２、ＡＶ機器１３、入力装置１４を備えている。ここで、ＡＶ機器１３は、ディスプレイやオーディオ再生装置やビデオ再生装置やテレビ受信機やラジオ受信機やオーディオ出力装置などの、オーディオとビジュアルの少なくとも一方を入力/出力する機器である。
【００２３】
次に、ＡＶ装置１の機能構成を図２に示す。
ここで、図中の認証処理部２１、ＡＶ制御部２２は、ＣＰＵ１１がメモリ１２に記憶されているプログラムを実行することにより実現される機能である。
さて、図示するようにバス制御部１０は、バス２との間の信号入出力を行う送受信部１０１、ＡＶ機器１３がバス２を介して他の機器に送信したりバス２を介して他の機器から受信するコンテンツデータの暗号化/復号を行う暗号/復号処理部１０２を備えている。
また、ＡＶ制御部２２は、ユーザ操作やバス制御部１０を介して他のＡＶ装置１から受信したコマンドに応じて、ＡＶ装置１の動作の制御を行う。
そして、ソースとなるＡＶ装置１の認証処理部２１は、図３に示す認証処理を行う
図示するように、この認証処理において、認証処理部２１は、まず、カウンタＳＣを０に初期化すると共に、認証済のシンクを登録するレジスタを空に初期化する（ステップ３０２）。ここで、ソースとは、他ＡＶ装置にコンテンツデータを送信するＡＶ装置１を指し、シンクとは、ソースとなるＡＶ装置１からコンテンツデータを受信するＡＶ装置１を指す。
【００２４】
そして、所定の契機で生じるキー廃棄の発生と（ステップ３０４）、認証及びキー交換を求めるＡＫＥ（Authentication and Key Exchange）リクエストの受信（ステップ３０６）を監視する。
そして、キー廃棄が発生している場合には（ステップ３０４）、ステップ３０２に戻り、ＳＣとレジスタを０に初期化する。
一方、ＡＫＥリクエストを受信した場合には（ステップ３０６）、受信したＡＫＥリクエストを処理中リクエストテーブルに追加し（ステップ３０８）、受信したＡＫＥリクエストを対象リクエストとする個別リクエスト認証処理を起動する（ステップ３１０）。
そして、ステップ３０４、３０６の監視に戻る。
次に、このような認証処理のステップ３１０で起動される個別リクエスト認証処理の手順を図４に示す。
図示するように、個別リクエスト認証処理では、ＳＣが３４未満であるかどうかを調べ（ステップ４０２）、ＳＣが３４以上であれば、対象リクエストの発行元がAP = 0のシンクであって、かつ、レジスタに既に登録済みであるかどうかを調べ（ステップ４２２）、そうであれば、ＡＫＥを、対象リクエストの発行元との間で実行し（ステップ４２４）、処理中リクエストテーブルから対象リクエストを削除し（ステップ４２０）、個別リクエスト認証処理を終了する。ここで、ステップ４２４で実行されるＡＫＥでは、先に図７を用いて説明したように、ＡＫＥリクエスト発行元の正当性をcertificateを用いた承認、チャレンジ、レスポンスによるＡＫＥリクエスト発行元との共通の認証鍵の生成、ＡＫＥリクエスト発行元への認証鍵を用いて暗号化した交換キー送信が行われる。一方、対象リクエストの発行元がAP = 0のシンクでないか、レジスタに登録されていない場合には（ステップ４２２）、対象リクエストを拒絶し（ステップ４２６）、処理中リクエストテーブルから対象リクエストを削除し（ステップ４２０）、個別リクエスト認証処理を終了する。
【００２５】
一方、ステップ４０２でＳＣが３４未満であると判定された場合には、処理中リクエストテーブルに対象リクエストに先行して登録されている、対象リクエストよりも先着の各ＡＫＥリクエストとの認証成功時のＳＣの値をＶＳＣとして算出する（ステップ４０４）。
すなわち、ここでは、処理中リクエストテーブルに対象リクエストに先行して登録されているＡＫＥリクエストのうち、ＡＫＥリクエストのリクエスト元がＡＰ=１のバスブリッジ３であるか、ＡＫＥリクエストのリクエスト元がレジスタに登録されていないＡＰ=０のシンクであるＡＫＥリクエストの数、すなわち、リクエスト元がレジスタに登録されているシンクであるＡＫＥリクエストを除くＡＫＥリクエストの数を求め、求めたＡＫＥリクエスト数をＳＣの値に加算した数をＶＳＣとする。
【００２６】
そして、ＶＳＣが、３４未満であるかどうかを調べ（ステップ４０６）、ＶＳＣが３４以上であれば、対象リクエストの発行元がAP = 0のシンクであって、かつ、レジスタに既に登録済みであるかどうかを調べ（ステップ４２２）、そうであれば、ＡＫＥを、対象リクエストの発行元との間で実行し（ステップ４２４）、処理中リクエストテーブルから対象リクエストを削除し（ステップ４２０）、個別リクエスト認証処理を終了する。一方、対象リクエストの発行元がAP = 0のシンクでないか、レジスタに登録されていない場合には（ステップ４２２）、対象リクエストを拒絶し（ステップ４２６）、処理中リクエストテーブルから対象リクエストを削除し（ステップ４２０）、個別リクエスト認証処理を終了する。
【００２７】
一方、ステップ４０６において、ＶＳＣが３４未満であると判定された場合には、ＡＫＥを、対象リクエストの発行元との間で実行する（ステップ４０８）。そして、ＡＫＥが失敗した場合には（ステップ４１０）、処理中リクエストテーブルから対象リクエストを削除し（ステップ４２０）、個別リクエスト認証処理を終了する。
【００２８】
一方、ＡＫＥが成功した場合には（ステップ４１０）、対象リクエストの発行元が、コンテンツを受信する機器であるシンクであるか、シンクのPloxyとなる機器であるバスブリッジ３であるかを、対象リクエストに含まれるAPフラグの値より判定し（ステップ４１２）、APフラグが１であって対象リクエストの発行元がバスブリッジ３である場合には、ＳＣを１増加すると共に（ステップ４１８）処理中リクエストテーブルから対象リクエストを削除し（ステップ４２０）、個別リクエスト認証処理を終了する。
【００２９】
一方、APフラグが０であって対象リクエストの発行元がシンクである場合には（ステップ４１２）、対象リクエストの発行元のシンクが、レジスタに既に登録済みであるかどうかを調べ（ステップ４１４）、登録済であれば、処理中リクエストテーブルから対象リクエストを削除し（ステップ４２０）、個別リクエスト認証処理を終了する。
【００３０】
一方、登録済でなければ、ＡＫＥリクエストの発行元のシンクをレジスタに登録した上で（ステップ４１６）、ＳＣを１増加すると共に（ステップ４１８）処理中リクエストテーブルから対象リクエストを削除し（ステップ４２０）、個別リクエスト認証処理を終了する。
【００３１】
以上、ソースの認証処理部２１が行う認証処理と個別リクエスト認証処理について説明した。
なお、以上の各処理中において実行したＡＫＥでＡＫＥリクエスト発行元と交換した交換キーは、ソースにおいて、バス制御部１０の暗号/復号処理部１０２に設定され、以降、暗号/復号処理部１０２は、ＡＶ装置１から入力し、送受信部１０１を介して送信するコンテンツデータを、当該コンテンツデータの送信先の機器に前述した認証処理によって送信した交換キーを利用して求まる暗号キーにより暗号化する。また、交換キーをソースから受信した機器では、暗号/復号処理部１０２に設定し、以降、暗号/復号処理部１０２は、ソースから受信したコンテンツデータを、当該コンテンツデータの送信元のソースから受信した交換キーを利用して求まる暗号キーにより復号し出力する。
【００３２】
以上のような、認証処理部２１が行う認証処理と個別リクエスト認証処理によれば、受信したＡＫＥリクエスト毎に起動された各個別リクエスト認証処理において、先着した未処理のＡＫＥリクエストの個別リクエスト認証処理による、認証済機器数を表すＳＣの増加の可能性の有無と、可能なＳＣの増加数を解析し、解析した増加数を、現在のＳＣに加えた値が、３４未満である場合にのみ、ＡＫＥリクエストの認証処理を実行する。
【００３３】
よって、各個別リクエスト認証処理によるＡＫＥリクエストの認証処理によって、ＳＣが３４を越えることはないので、認証する機器数を正しく制限することができるようになる。また、先着のＡＫＥリクエストの認証処理の完了を待たずに、後着のＡＫＥリクエストの認証処理の実行を開始できるので、認証処理の遅延も抑制することができる。
【００３４】
ところで、上述した個別リクエスト認証処理は、図５に示すように行うようにしてもよい。なお、個別リクエスト認証処理を図５のように行う場合には、図３に示した認証処理のステップ３０８の処理中リクエストテーブルへの受信ＡＫＥリクエストの追加処理は、これを設ける必要はない。
すなわち、個別リクエスト認証処理において、まず、ＳＣが３４未満であるかどうかを調べ（ステップ５０２）、ＳＣが３４以上であれば、対象リクエストの発行元がAP = 0のシンクであって、かつ、レジスタに既に登録済みであるかどうかを調べ（ステップ５２８）、そうであれば、ＡＫＥを、対象リクエストの発行元との間で実行し（ステップ５３０）、個別リクエスト認証処理を終了する。一方、対象リクエストの発行元がAP = 0のシンクでないか、レジスタに登録されていない場合には（ステップ５２８）、対象リクエストを拒絶し（ステップ５３２）、個別リクエスト認証処理を終了する。
【００３５】
一方、ステップ５０２でＳＣが３４未満であると判定された場合には、対象リクエストの発行元との間で、ＡＫＥを、図７に示した認証動作シーケンスのチャレンジ-レスポンスシーケンスまで実行して、対象リクエストの発行元との間で認証鍵を共有する（ステップ５０４）。
【００３６】
そして、チャレンジ-レスポンスシーケンスまでＡＫＥが成功したかどうかを調べ（ステップ５０６）、失敗していれば、個別リクエスト認証処理を終了する。
一方、チャレンジ-レスポンスシーケンスまでＡＫＥが成功した場合には（ステップ５０６）、処理中フラグがオンの他の個別リクエスト認証処理が存在しなくなるのを待つ（ステップ５０８）。
そして、処理中フラグがオンの他の個別リクエスト認証処理が存在しなくなったならば（ステップ５０８）、再度、ＳＣが３４未満であるかどうかを調べ（ステップ５１０）、ＳＣが３４以上であれば、対象リクエストの発行元がAP = 0のシンクであって、かつ、レジスタに既に登録済みであるかどうかを調べ（ステップ５３４）、そうであれば、対象リクエストの発行元に、当該発行元との間で行ったチャレンジ-レスポンスシーケンスで共有した認証鍵で暗号化した交換キーを送信して（ステップ５３６）、ＡＫＥを完了して、対象リクエストの発行元との間の認証動作シーケンスを終了すると共に、個別リクエスト認証処理を終了する。
【００３７】
一方、対象リクエストの発行元がAP = 0のシンクでないか、レジスタに登録されていない場合には（ステップ５３４）、チャレンジ-レスポンスシーケンスまでで、対象リクエストについてのＡＫＥを中止し（ステップ５３８）、個別リクエスト認証処理を終了する。ここで、ＡＫＥの中止は、対象リクエストの発行元にＡＫＥのキャンセルコマンドを送信したり、対象リクエスト発行元からの認証動作シーケンスの進行を求めるコマンドを拒絶したり、放置によって対象リクエスト発行元のタイムアウトによるＡＫＥ失敗を引き起こすこと等により行うことができる。
【００３８】
次に、ステップ５１０において、ＳＣが３４未満であると判定された場合には、自個別リクエスト認証処理の処理中フラグをオンに設定する（ステップ５１２）。なお、処理中フラグの初期値はオフである。
そして、対象リクエストの発行元に、当該発行元との間で行ったチャレンジ-レスポンスシーケンスで共有した認証鍵で暗号化した交換キーを送信して（ステップ５１４）、ＡＫＥを完了して、対象リクエストの発行元との間の認証動作シーケンスを終了する。
次に、交換キーの送信が成功したかどうかを調べ（ステップ５１６、失敗していれば、自個別リクエスト認証処理の処理中フラグをオフに戻し（ステップ５２６）、個別リクエスト認証処理を終了する。
【００３９】
一方、交換キーの送信が成功している場合には（ステップ５１６）、対象リクエストの発行元が、コンテンツを受信する機器であるシンクであるか、シンクのPloxyとなる機器であるバスブリッジ３であるかを、対象リクエストに含まれるAPフラグの値より判定し（ステップ５１８）、APフラグが１であって対象リクエストの発行元がバスブリッジ３である場合には、ＳＣを１増加すると共に（ステップ５２４）、自個別リクエスト認証処理の処理中フラグをオフに戻し（ステップ５２６）、個別リクエスト認証処理を終了する。
【００４０】
一方、APフラグが０であって対象リクエストの発行元がシンクである場合には（ステップ５１８）、対象リクエストの発行元のシンクが、レジスタに既に登録済みであるかどうかを調べ（ステップ５２０）、登録済であれば、自個別リクエスト認証処理の処理中フラグをオフに戻し（ステップ５２６）、個別リクエスト認証処理を終了する。
【００４１】
一方、登録済でなければ、ＡＫＥリクエストの発行元のシンクをレジスタに登録した上で（ステップ５２２）、ＳＣを１増加すると共に（ステップ５２４）、自個別リクエスト認証処理の処理中フラグをオフに戻し（ステップ５２６）、個別リクエスト認証処理を終了する。
【００４２】
以上のような図５に示した個別リクエスト認証処理によれば、受信したＡＫＥリクエスト毎に起動された各個別リクエスト認証処理では、ＡＫＥを、交換キーの送信直前のシーケンスまで実行しておき、当該時点において、処理中フラグがオンの他の個別リクエスト認証処理が存在しない、すなわち、他の個別リクエスト認証処理がＳＣを増加させる可能性のあるＡＫＥの交換キーの送信処理に進んでおらず、かつ、ＳＣが３４未満である場合にのみ、ＡＫＥリクエストの認証処理を実行する。
よって、各個別リクエスト認証処理によるＡＫＥリクエストの認証処理によって、ＳＣが３４を越えることはないので、認証する機器数を正しく制限することができるようになる。また、先着のＡＫＥリクエストの認証処理の状況如何に関わらずに、後着のＡＫＥリクエストの認証処理を、交換キーの送信直前のシーケンスまで進めておけるので、認証処理の遅延も抑制することができる。
以上、本発明の実施形態について説明した。
【符号の説明】
【００４３】
１…ＡＶ装置、２…バス、３…バスブリッジ、１０…バス制御部、１１…ＣＰＵ、１２…メモリ、１３…ＡＶ機器、１４…入力装置、２１…認証処理部、２２…ＡＶ制御部、１０１…送受信部、１０２…暗号/復号処理部。
【技術分野】
【０００１】
本発明は、複数の機器をネットワークで接続し、コンテンツの送信元となる機器であるソースが、コンテンツの送信先となる機器を認証して、認証した機器にコンテンツを送信するシステムにおいて、ソースで認証する機器数を制限する技術に関するものである。
【背景技術】
【０００２】
複数の機器をネットワークで接続し、コンテンツの送信元となる機器であるソースが、コンテンツの送信先となる機器を認証して、認証した機器にコンテンツを送信するシステムにおいて、ソースで認証する機器数を制限する技術としては、ソースにおいて、図６に示す手順によって認証機器数を制限する認証処理が知られている（たとえば、特許文献１、非特許文献１）。
【０００３】
図６に示すように、この認証処理では、ソースは、まず、カウンタＳＣを０に初期化する（ステップ６０２）。
そして、所定の契機で生じるキー廃棄の発生と（ステップ６０４）、認証及びキー交換を求めるＡＫＥ（Authentication and Key Exchange）リクエストの受信（ステップ６０６）を監視する。
そして、キー廃棄が発生している場合には（ステップ６０４）、ステップ６０２に戻り、ＳＣを０に初期化する。
一方、ＡＫＥリクエストを受信した場合には（ステップ６０６）、ＳＣが３４未満であるかどうかを調べ（ステップ６０８）、ＳＣが３４未満であれば、ＡＫＥ（Authentication and Key Exchange：認証及びキー交換）を、ＡＫＥリクエストの発行元との間で実行する（ステップ６１０）。
【０００４】
そして、ＡＫＥリクエストの発行元が、コンテンツを受信する機器であるシンクであるか、シンクのPloxyとなる機器であるバスブリッジであるかを、ＡＫＥリクエストに含まれるAPフラグの値より判定し（ステップ６１２）、APフラグが１であってＡＫＥリクエストの発行元がバスブリッジである場合には、ステップ６１８に進んで、ＳＣを１増加し、ステップ６０４、６０６の監視に戻る。
【０００５】
一方、APフラグが０であってＡＫＥリクエストの発行元がシンクである場合には、ＡＫＥリクエストの発行元のシンクが、認証済のシンクを登録するレジスタに既に登録済みであるかどうかを調べ（ステップ６１４）、登録済であれば、そのままステップ６０４、６０６の監視に戻り、登録済でなければ、ＡＫＥリクエストの発行元のシンクをレジスタに登録した上で（ステップ６１６）、ステップ６１８に進んで、ＳＣを１増加し、ステップ６０４、６０６の監視に戻る。
【０００６】
一方、ステップ６０８で、ＳＣが３４以上であると判定された場合には、ＡＫＥリクエストの発行元がAP = 0のシンクであって、かつ、レジスタに既に登録済みであるかどうかを調べ（ステップ６２０）、そうであれば、ＡＫＥを、ＡＫＥリクエストの発行元との間で実行し（ステップ６２２）、ステップ６０４、６０６の監視に戻る。一方、ＡＫＥリクエストの発行元がAP = 0のシンクでないか、レジスタに登録されていない場合には（ステップ６２０）、ＡＫＥリクエストを拒絶し（ステップ６２４）、ステップ６０４、６０６の監視に戻る。
ここで、このような認証処理によれば、認証される機器数は３４以下に制限されることになる。
【０００７】
ここで、上述した認証処理による、ソースと、シンク/バスブリッジの全体の認証動作のシーケンスはおおよそ図７に示すものである。
すなわち、シンクまたはバスブリッジは、ソースに、certificate 等を伴うＡＫＥリクエストを発行する。
ソースは、図６に示した認証処理によってＡＫＥリクエストに対してＡＫＥを実行する場合には、当該ＡＫＥにおいて、以下の処理を行う。
すなわち、ＡＫＥリクエスト発行元の正当性をcertificateを用いて承認できたならば、ＡＫＥリクエスト発行元と、チャレンジ、レスポンスによって所定の情報を交換し、ソースとＡＫＥリクエスト発行元において共通の認証鍵を生成するチャレンジ-レスポンスシーケンスを実行する。
【０００８】
そして、チャレンジ-レスポンスシーケンスが成功したならば、認証鍵を用いて暗号化した交換キーをＡＫＥリクエスト発行元に送信する。
また、以降、ソースは、交換キーを利用して暗号化したコンテンツをＡＫＥリクエスト発行元に送信し、ＡＫＥリクエスト発行元では、ソースから受信した交換キーを利用して、ソースから送信されたコンテンツを復号し利用する。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００２-０８４２７４号公報
【非特許文献】
【００１０】
【非特許文献１】Hitachi, Ltd., Intel Corporation, Matsushita Electric Industrial Co., Ltd., Sony Corporation and Toshiba Corporation ,"Digital Transmission Content Protection Specification Volume 1 (Informational Version)", P.72-73, [online], 2007年10月1日, Digital Transmission Licensing Administrator (DTLA), [2009年12月22日検索],インターネット(http://www.dtcp.com/data/info 20071001 DTCP V1 1p51.pdf)
【発明の概要】
【発明が解決しようとする課題】
【００１１】
さて、図６に示した認証処理によって、ソースにおいて、認証する機器数を制限する場合には、以下の問題が生じる。
すなわち、ソースにおいて、連続的に複数のＡＫＥリクエストを受信した場合に、各ＡＫＥリクエストを逐次的に一つずつ、順次、処理した場合には、後着のＡＫＥリクエストに対する処理に比較的大きな遅延が生じる。
一方、各ＡＫＥリクエストを並列に処理した場合には、各ＡＫＥリクエストについての処理開始時にＳＣが３４未満であっても、各ＡＫＥリクエスト処理終了時にＳＣが３４以上となってしまうことがあり、この場合には、正しく認証する機器数を３４以下に制限できなくなる。すなわち、たとえば、ＳＣが３３のときに（認証済機器数が３３のときに）、二つのＡＫＥリクエストが連続して到着した場合に、この二つのＡＫＥリクエストの処理を平行して行うと、当該処理開始時点において、ＳＣが３３であるために、二つのＡＫＥリクエストに対してＡＫＥが実行されてしまうことがあり、この場合、二つのＡＫＥリクエストについての処理終了時には、認証機器数３４を超えて３５となってしまうことがある。
【００１２】
一方、連続的に複数のＡＫＥリクエストを受信した場合に、より先着のＡＫＥリクエストについてＡＫＥが実行されＳＣが１増加されるものと仮定して、ＳＣが３４以上とならないように、後着のＡＫＥリクエストを拒絶することも考えられるが、このようにすると先着のＡＫＥリクエストについての処理の結果ＳＣが１増加されなかった場合には、後着のＡＫＥリクエストを正当な理由なく拒絶してしまうことになる。すなわち、たとえば、ＳＣが３３のときに、二つのＡＫＥリクエストが連続して到着した場合に、１番目に到着したＡＫＥリクエストについてＡＫＥが実行されＳＣが１増加されてＳＣが３４となるものと仮定し、２番目に到着したＡＫＥリクエストを拒絶した場合において、１番目に到着したＡＫＥリクエストについてＡＫＥが実行されなかったり、ＡＫＥが実行されてもＳＣが１増加されなかった場合には、ＳＣが３３に維持されるので、２番目に到着したＡＫＥリクエストを不当に拒絶してしまったことになる。
【００１３】
そこで、本発明は、ソースにおいて、認証処理の遅延を抑制しつつ、認証する機器数を正しく制限することを課題とする。
【課題を解決するための手段】
【００１４】
前記課題達成のために、本発明は、通信機器とデータ通信を行う通信装置に、前記通信機器から受信した各認証要求について、当該認証要求の発行元の通信機器の認証を行うと共に、認証した通信機器が既に認証済の通信機器でない場合に、認証済機器数を１増加する認証処理を行う認証処理部と、前記認証処理部が認証した通信機器と前記データ通信を行うデータ通信部とを備え、前記認証処理部において、発行元が認証済の通信機器でない認証要求についての認証処理を、当該認証要求に先行して受信した、認証処理を実行中の、発行元が認証済の通信機器でない他の認証要求の数を、前記認証済機器数に加算した数が、前記所定の制限数未満である場合に実行するようにしたものである。
【００１５】
このような通信装置によれば、受信した認証要求についての認証処理を、先着した未処理の認証要求の認証処理による、認証済機器数の可能最大増加数を、未処理の認証要求の発行元の通信機器が認証済の通信機器であるかどうかより求め、求めた可能増加数が現在の認証済機器数に加えた値が、制限値未満となる場合のみ行う。
【００１６】
よって、各認証要求の認証処理によって、認証済機器数が制限値を越えることはないので、認証する機器数を正しく制限することができるようになる。また、先着の認証要求についての認証処理の完了を待たずに、後着の認証要求についての認証処理の実行を開始できるので、認証処理の遅延も抑制することができる。
【００１７】
また、本発明は、前記課題達成のために、通信機器とデータ通信を行う通信装置に、前記通信機器から受信した各認証要求について、当該認証要求の発行元の通信機器と認証鍵を共有するための第１の処理と、前記認証鍵を用いて暗号化した交換キーを前記通信装置に送信し、認証した通信機器が既に認証済の通信機器でない場合に、認証済機器数を１増加する第２の処理とを含む認証処理を行う認証処理部と、前記交換キーを送信した通信機器と、当該交換キーを利用した暗号化を施した前記データ通信を行うデータ通信部とを備え、前記認証処理部において、発行元が認証済の通信機器でない認証要求についての認証処理を、前記第１の処理を実行し、当該第１の処理の終了後に、前記第２の処理を実行中の他の認証処理が存在しなくなった時点で、前記認証済機器数が所定の制限数未満である場合に、前記第２の処理を実行することにより行うようにしたものである。
【００１８】
このような通信装置によれば、各認証要求についての認証処理において、第１の処理まで実行し、当該第１の処理の終了後に、前記第２の処理を実行中の他の認証処理が存在しなくなった時点で、前記認証済機器数が所定の制限数未満である場合に、第２の処理を行う。
【００１９】
よって、各認証要求についての認証処理により、認証済機器数が制限数を越えることはないので、認証する通信機器数を正しく制限することができるようになる。また、他の認証要求についての認証処理の状況如何に関わらずに、認証処理を、第２の処理直前の処理まで進めておけるので、認証処理の遅延も抑制することができる。
【発明の効果】
【００２０】
以上のように、本発明によれば、ソースにおいて、認証処理の遅延を抑制しつつ、認証する機器数を正しく制限することができる。
【図面の簡単な説明】
【００２１】
【図１】本発明の実施形態に係るＡＶシステムの構成を示すブロック図である。
【図２】本発明の実施形態に係るＡＶ装置の機能構成を示すブロック図である。
【図３】本発明の実施形態に係る認証処理を示すフローチャートである。
【図４】本発明の実施形態に係る個別リクエスト認証処理を示すフローチャートである。
【図５】本発明の実施形態に係る個別リクエスト認証処理を示すフローチャートである。
【図６】先行技術に係る認証処理を示すフローチャートである。
【図７】認証動作のシーケンスを示す図である。
【発明を実施するための形態】
【００２２】
以下、本発明の実施形態について説明する。
図１に、本実施形態に係るＡＶシステムの構成を示す。
図示するように、ＡＶシステムは、複数のＡＶ装置１をIEEE1394規格に従ったバス２で接続したものである。また、ＡＶシステムは、バス２間の中継等を行うバスブリッジ３によって連結された複数のバス２を備えて構成することもできる。
ここで、ＡＶ装置１は、それぞれ、バス制御部１０、ＣＰＵ１１、メモリ１２、ＡＶ機器１３、入力装置１４を備えている。ここで、ＡＶ機器１３は、ディスプレイやオーディオ再生装置やビデオ再生装置やテレビ受信機やラジオ受信機やオーディオ出力装置などの、オーディオとビジュアルの少なくとも一方を入力/出力する機器である。
【００２３】
次に、ＡＶ装置１の機能構成を図２に示す。
ここで、図中の認証処理部２１、ＡＶ制御部２２は、ＣＰＵ１１がメモリ１２に記憶されているプログラムを実行することにより実現される機能である。
さて、図示するようにバス制御部１０は、バス２との間の信号入出力を行う送受信部１０１、ＡＶ機器１３がバス２を介して他の機器に送信したりバス２を介して他の機器から受信するコンテンツデータの暗号化/復号を行う暗号/復号処理部１０２を備えている。
また、ＡＶ制御部２２は、ユーザ操作やバス制御部１０を介して他のＡＶ装置１から受信したコマンドに応じて、ＡＶ装置１の動作の制御を行う。
そして、ソースとなるＡＶ装置１の認証処理部２１は、図３に示す認証処理を行う
図示するように、この認証処理において、認証処理部２１は、まず、カウンタＳＣを０に初期化すると共に、認証済のシンクを登録するレジスタを空に初期化する（ステップ３０２）。ここで、ソースとは、他ＡＶ装置にコンテンツデータを送信するＡＶ装置１を指し、シンクとは、ソースとなるＡＶ装置１からコンテンツデータを受信するＡＶ装置１を指す。
【００２４】
そして、所定の契機で生じるキー廃棄の発生と（ステップ３０４）、認証及びキー交換を求めるＡＫＥ（Authentication and Key Exchange）リクエストの受信（ステップ３０６）を監視する。
そして、キー廃棄が発生している場合には（ステップ３０４）、ステップ３０２に戻り、ＳＣとレジスタを０に初期化する。
一方、ＡＫＥリクエストを受信した場合には（ステップ３０６）、受信したＡＫＥリクエストを処理中リクエストテーブルに追加し（ステップ３０８）、受信したＡＫＥリクエストを対象リクエストとする個別リクエスト認証処理を起動する（ステップ３１０）。
そして、ステップ３０４、３０６の監視に戻る。
次に、このような認証処理のステップ３１０で起動される個別リクエスト認証処理の手順を図４に示す。
図示するように、個別リクエスト認証処理では、ＳＣが３４未満であるかどうかを調べ（ステップ４０２）、ＳＣが３４以上であれば、対象リクエストの発行元がAP = 0のシンクであって、かつ、レジスタに既に登録済みであるかどうかを調べ（ステップ４２２）、そうであれば、ＡＫＥを、対象リクエストの発行元との間で実行し（ステップ４２４）、処理中リクエストテーブルから対象リクエストを削除し（ステップ４２０）、個別リクエスト認証処理を終了する。ここで、ステップ４２４で実行されるＡＫＥでは、先に図７を用いて説明したように、ＡＫＥリクエスト発行元の正当性をcertificateを用いた承認、チャレンジ、レスポンスによるＡＫＥリクエスト発行元との共通の認証鍵の生成、ＡＫＥリクエスト発行元への認証鍵を用いて暗号化した交換キー送信が行われる。一方、対象リクエストの発行元がAP = 0のシンクでないか、レジスタに登録されていない場合には（ステップ４２２）、対象リクエストを拒絶し（ステップ４２６）、処理中リクエストテーブルから対象リクエストを削除し（ステップ４２０）、個別リクエスト認証処理を終了する。
【００２５】
一方、ステップ４０２でＳＣが３４未満であると判定された場合には、処理中リクエストテーブルに対象リクエストに先行して登録されている、対象リクエストよりも先着の各ＡＫＥリクエストとの認証成功時のＳＣの値をＶＳＣとして算出する（ステップ４０４）。
すなわち、ここでは、処理中リクエストテーブルに対象リクエストに先行して登録されているＡＫＥリクエストのうち、ＡＫＥリクエストのリクエスト元がＡＰ=１のバスブリッジ３であるか、ＡＫＥリクエストのリクエスト元がレジスタに登録されていないＡＰ=０のシンクであるＡＫＥリクエストの数、すなわち、リクエスト元がレジスタに登録されているシンクであるＡＫＥリクエストを除くＡＫＥリクエストの数を求め、求めたＡＫＥリクエスト数をＳＣの値に加算した数をＶＳＣとする。
【００２６】
そして、ＶＳＣが、３４未満であるかどうかを調べ（ステップ４０６）、ＶＳＣが３４以上であれば、対象リクエストの発行元がAP = 0のシンクであって、かつ、レジスタに既に登録済みであるかどうかを調べ（ステップ４２２）、そうであれば、ＡＫＥを、対象リクエストの発行元との間で実行し（ステップ４２４）、処理中リクエストテーブルから対象リクエストを削除し（ステップ４２０）、個別リクエスト認証処理を終了する。一方、対象リクエストの発行元がAP = 0のシンクでないか、レジスタに登録されていない場合には（ステップ４２２）、対象リクエストを拒絶し（ステップ４２６）、処理中リクエストテーブルから対象リクエストを削除し（ステップ４２０）、個別リクエスト認証処理を終了する。
【００２７】
一方、ステップ４０６において、ＶＳＣが３４未満であると判定された場合には、ＡＫＥを、対象リクエストの発行元との間で実行する（ステップ４０８）。そして、ＡＫＥが失敗した場合には（ステップ４１０）、処理中リクエストテーブルから対象リクエストを削除し（ステップ４２０）、個別リクエスト認証処理を終了する。
【００２８】
一方、ＡＫＥが成功した場合には（ステップ４１０）、対象リクエストの発行元が、コンテンツを受信する機器であるシンクであるか、シンクのPloxyとなる機器であるバスブリッジ３であるかを、対象リクエストに含まれるAPフラグの値より判定し（ステップ４１２）、APフラグが１であって対象リクエストの発行元がバスブリッジ３である場合には、ＳＣを１増加すると共に（ステップ４１８）処理中リクエストテーブルから対象リクエストを削除し（ステップ４２０）、個別リクエスト認証処理を終了する。
【００２９】
一方、APフラグが０であって対象リクエストの発行元がシンクである場合には（ステップ４１２）、対象リクエストの発行元のシンクが、レジスタに既に登録済みであるかどうかを調べ（ステップ４１４）、登録済であれば、処理中リクエストテーブルから対象リクエストを削除し（ステップ４２０）、個別リクエスト認証処理を終了する。
【００３０】
一方、登録済でなければ、ＡＫＥリクエストの発行元のシンクをレジスタに登録した上で（ステップ４１６）、ＳＣを１増加すると共に（ステップ４１８）処理中リクエストテーブルから対象リクエストを削除し（ステップ４２０）、個別リクエスト認証処理を終了する。
【００３１】
以上、ソースの認証処理部２１が行う認証処理と個別リクエスト認証処理について説明した。
なお、以上の各処理中において実行したＡＫＥでＡＫＥリクエスト発行元と交換した交換キーは、ソースにおいて、バス制御部１０の暗号/復号処理部１０２に設定され、以降、暗号/復号処理部１０２は、ＡＶ装置１から入力し、送受信部１０１を介して送信するコンテンツデータを、当該コンテンツデータの送信先の機器に前述した認証処理によって送信した交換キーを利用して求まる暗号キーにより暗号化する。また、交換キーをソースから受信した機器では、暗号/復号処理部１０２に設定し、以降、暗号/復号処理部１０２は、ソースから受信したコンテンツデータを、当該コンテンツデータの送信元のソースから受信した交換キーを利用して求まる暗号キーにより復号し出力する。
【００３２】
以上のような、認証処理部２１が行う認証処理と個別リクエスト認証処理によれば、受信したＡＫＥリクエスト毎に起動された各個別リクエスト認証処理において、先着した未処理のＡＫＥリクエストの個別リクエスト認証処理による、認証済機器数を表すＳＣの増加の可能性の有無と、可能なＳＣの増加数を解析し、解析した増加数を、現在のＳＣに加えた値が、３４未満である場合にのみ、ＡＫＥリクエストの認証処理を実行する。
【００３３】
よって、各個別リクエスト認証処理によるＡＫＥリクエストの認証処理によって、ＳＣが３４を越えることはないので、認証する機器数を正しく制限することができるようになる。また、先着のＡＫＥリクエストの認証処理の完了を待たずに、後着のＡＫＥリクエストの認証処理の実行を開始できるので、認証処理の遅延も抑制することができる。
【００３４】
ところで、上述した個別リクエスト認証処理は、図５に示すように行うようにしてもよい。なお、個別リクエスト認証処理を図５のように行う場合には、図３に示した認証処理のステップ３０８の処理中リクエストテーブルへの受信ＡＫＥリクエストの追加処理は、これを設ける必要はない。
すなわち、個別リクエスト認証処理において、まず、ＳＣが３４未満であるかどうかを調べ（ステップ５０２）、ＳＣが３４以上であれば、対象リクエストの発行元がAP = 0のシンクであって、かつ、レジスタに既に登録済みであるかどうかを調べ（ステップ５２８）、そうであれば、ＡＫＥを、対象リクエストの発行元との間で実行し（ステップ５３０）、個別リクエスト認証処理を終了する。一方、対象リクエストの発行元がAP = 0のシンクでないか、レジスタに登録されていない場合には（ステップ５２８）、対象リクエストを拒絶し（ステップ５３２）、個別リクエスト認証処理を終了する。
【００３５】
一方、ステップ５０２でＳＣが３４未満であると判定された場合には、対象リクエストの発行元との間で、ＡＫＥを、図７に示した認証動作シーケンスのチャレンジ-レスポンスシーケンスまで実行して、対象リクエストの発行元との間で認証鍵を共有する（ステップ５０４）。
【００３６】
そして、チャレンジ-レスポンスシーケンスまでＡＫＥが成功したかどうかを調べ（ステップ５０６）、失敗していれば、個別リクエスト認証処理を終了する。
一方、チャレンジ-レスポンスシーケンスまでＡＫＥが成功した場合には（ステップ５０６）、処理中フラグがオンの他の個別リクエスト認証処理が存在しなくなるのを待つ（ステップ５０８）。
そして、処理中フラグがオンの他の個別リクエスト認証処理が存在しなくなったならば（ステップ５０８）、再度、ＳＣが３４未満であるかどうかを調べ（ステップ５１０）、ＳＣが３４以上であれば、対象リクエストの発行元がAP = 0のシンクであって、かつ、レジスタに既に登録済みであるかどうかを調べ（ステップ５３４）、そうであれば、対象リクエストの発行元に、当該発行元との間で行ったチャレンジ-レスポンスシーケンスで共有した認証鍵で暗号化した交換キーを送信して（ステップ５３６）、ＡＫＥを完了して、対象リクエストの発行元との間の認証動作シーケンスを終了すると共に、個別リクエスト認証処理を終了する。
【００３７】
一方、対象リクエストの発行元がAP = 0のシンクでないか、レジスタに登録されていない場合には（ステップ５３４）、チャレンジ-レスポンスシーケンスまでで、対象リクエストについてのＡＫＥを中止し（ステップ５３８）、個別リクエスト認証処理を終了する。ここで、ＡＫＥの中止は、対象リクエストの発行元にＡＫＥのキャンセルコマンドを送信したり、対象リクエスト発行元からの認証動作シーケンスの進行を求めるコマンドを拒絶したり、放置によって対象リクエスト発行元のタイムアウトによるＡＫＥ失敗を引き起こすこと等により行うことができる。
【００３８】
次に、ステップ５１０において、ＳＣが３４未満であると判定された場合には、自個別リクエスト認証処理の処理中フラグをオンに設定する（ステップ５１２）。なお、処理中フラグの初期値はオフである。
そして、対象リクエストの発行元に、当該発行元との間で行ったチャレンジ-レスポンスシーケンスで共有した認証鍵で暗号化した交換キーを送信して（ステップ５１４）、ＡＫＥを完了して、対象リクエストの発行元との間の認証動作シーケンスを終了する。
次に、交換キーの送信が成功したかどうかを調べ（ステップ５１６、失敗していれば、自個別リクエスト認証処理の処理中フラグをオフに戻し（ステップ５２６）、個別リクエスト認証処理を終了する。
【００３９】
一方、交換キーの送信が成功している場合には（ステップ５１６）、対象リクエストの発行元が、コンテンツを受信する機器であるシンクであるか、シンクのPloxyとなる機器であるバスブリッジ３であるかを、対象リクエストに含まれるAPフラグの値より判定し（ステップ５１８）、APフラグが１であって対象リクエストの発行元がバスブリッジ３である場合には、ＳＣを１増加すると共に（ステップ５２４）、自個別リクエスト認証処理の処理中フラグをオフに戻し（ステップ５２６）、個別リクエスト認証処理を終了する。
【００４０】
一方、APフラグが０であって対象リクエストの発行元がシンクである場合には（ステップ５１８）、対象リクエストの発行元のシンクが、レジスタに既に登録済みであるかどうかを調べ（ステップ５２０）、登録済であれば、自個別リクエスト認証処理の処理中フラグをオフに戻し（ステップ５２６）、個別リクエスト認証処理を終了する。
【００４１】
一方、登録済でなければ、ＡＫＥリクエストの発行元のシンクをレジスタに登録した上で（ステップ５２２）、ＳＣを１増加すると共に（ステップ５２４）、自個別リクエスト認証処理の処理中フラグをオフに戻し（ステップ５２６）、個別リクエスト認証処理を終了する。
【００４２】
以上のような図５に示した個別リクエスト認証処理によれば、受信したＡＫＥリクエスト毎に起動された各個別リクエスト認証処理では、ＡＫＥを、交換キーの送信直前のシーケンスまで実行しておき、当該時点において、処理中フラグがオンの他の個別リクエスト認証処理が存在しない、すなわち、他の個別リクエスト認証処理がＳＣを増加させる可能性のあるＡＫＥの交換キーの送信処理に進んでおらず、かつ、ＳＣが３４未満である場合にのみ、ＡＫＥリクエストの認証処理を実行する。
よって、各個別リクエスト認証処理によるＡＫＥリクエストの認証処理によって、ＳＣが３４を越えることはないので、認証する機器数を正しく制限することができるようになる。また、先着のＡＫＥリクエストの認証処理の状況如何に関わらずに、後着のＡＫＥリクエストの認証処理を、交換キーの送信直前のシーケンスまで進めておけるので、認証処理の遅延も抑制することができる。
以上、本発明の実施形態について説明した。
【符号の説明】
【００４３】
１…ＡＶ装置、２…バス、３…バスブリッジ、１０…バス制御部、１１…ＣＰＵ、１２…メモリ、１３…ＡＶ機器、１４…入力装置、２１…認証処理部、２２…ＡＶ制御部、１０１…送受信部、１０２…暗号/復号処理部。
【特許請求の範囲】
【請求項１】
通信機器とデータ通信を行う通信装置であって、
前記通信機器から受信した各認証要求について、当該認証要求の発行元の通信機器の認証を行うと共に、認証した通信機器が既に認証済の通信機器でない場合に、認証済機器数を１増加する認証処理を行う認証処理部と、
前記認証処理部が認証した通信機器と前記データ通信を行うデータ通信部とを有し、
前記認証処理部は、発行元が認証済の通信機器でない認証要求についての認証処理を、当該認証要求に先行して受信した、認証処理を実行中の、発行元が認証済の通信機器でない他の認証要求の数を、前記認証済機器数に加算した数が、前記所定の制限数未満である場合に実行することを特徴とする通信装置。
【請求項２】
通信機器とデータ通信を行う通信装置であって、
前記通信機器から受信した各認証要求について、当該認証要求の発行元の通信機器と認証鍵を共有するための第１の処理と、前記認証鍵を用いて暗号化した交換キーを前記通信装置に送信し、認証した通信機器が既に認証済の通信機器でない場合に、認証済機器数を１増加する第２の処理とを含む認証処理を行う認証処理部と、
前記交換キーを送信した通信機器と、当該交換キーを利用した暗号化を施した前記データ通信を行うデータ通信部とを有し、
前記認証処理部は、発行元が認証済の通信機器でない認証要求についての認証処理を、前記第１の処理を実行し、当該第１の処理の終了後に、前記第２の処理を実行中の他の認証処理が存在しなくなった時点で、前記認証済機器数が所定の制限数未満である場合に、前記第２の処理を実行することにより行うことを特徴とする通信装置。
【請求項３】
通信機器とデータ通信を行うコンピュータによって読みとられ実行されるコンピュータプログラムであって、
前記コンピュータを、
前記通信機器から受信した各認証要求について、当該認証要求の発行元の通信機器の認証を行うと共に、認証した通信機器が既に認証済の通信機器でない場合に、認証済機器数を１増加する認証処理を行う認証処理部と、
前記認証処理部が認証した通信機器と前記データ通信を行うデータ通信部として機能させ、
前記認証処理部は、発行元が認証済の通信機器でない認証要求についての認証処理を、当該認証要求に先行して受信した、認証処理を実行中の、発行元が認証済の通信機器でない他の認証要求の数を、前記認証済機器数に加算した数が、前記所定の制限数未満である場合に実行することを特徴とするコンピュータププログラム。
【請求項４】
通信機器とデータ通信を行うコンピュータによって読みとられ実行されるコンピュータプログラムであって、
前記コンピュータを、
前記通信機器から受信した各認証要求について、当該認証要求の発行元の通信機器と認証鍵を共有するための第１の処理と、前記認証鍵を用いて暗号化した交換キーを前記通信装置に送信し、認証した通信機器が既に認証済の通信機器でない場合に、認証済機器数を１増加する第２の処理とを含む認証処理を行う認証処理部と、
前記交換キーを送信した通信機器と、当該交換キーを利用した暗号化を施した前記データ通信を行うデータ通信部として機能させ、
前記認証処理部は、発行元が認証済の通信機器でない認証要求についての認証処理を、前記第１の処理を実行し、当該第１の処理の終了後に、前記第２の処理を実行中の他の認証処理が存在しなくなった時点で、前記認証済機器数が所定の制限数未満である場合に、前記第２の処理を実行することにより行うことを特徴とするコンピュータプログラム。
【請求項１】
通信機器とデータ通信を行う通信装置であって、
前記通信機器から受信した各認証要求について、当該認証要求の発行元の通信機器の認証を行うと共に、認証した通信機器が既に認証済の通信機器でない場合に、認証済機器数を１増加する認証処理を行う認証処理部と、
前記認証処理部が認証した通信機器と前記データ通信を行うデータ通信部とを有し、
前記認証処理部は、発行元が認証済の通信機器でない認証要求についての認証処理を、当該認証要求に先行して受信した、認証処理を実行中の、発行元が認証済の通信機器でない他の認証要求の数を、前記認証済機器数に加算した数が、前記所定の制限数未満である場合に実行することを特徴とする通信装置。
【請求項２】
通信機器とデータ通信を行う通信装置であって、
前記通信機器から受信した各認証要求について、当該認証要求の発行元の通信機器と認証鍵を共有するための第１の処理と、前記認証鍵を用いて暗号化した交換キーを前記通信装置に送信し、認証した通信機器が既に認証済の通信機器でない場合に、認証済機器数を１増加する第２の処理とを含む認証処理を行う認証処理部と、
前記交換キーを送信した通信機器と、当該交換キーを利用した暗号化を施した前記データ通信を行うデータ通信部とを有し、
前記認証処理部は、発行元が認証済の通信機器でない認証要求についての認証処理を、前記第１の処理を実行し、当該第１の処理の終了後に、前記第２の処理を実行中の他の認証処理が存在しなくなった時点で、前記認証済機器数が所定の制限数未満である場合に、前記第２の処理を実行することにより行うことを特徴とする通信装置。
【請求項３】
通信機器とデータ通信を行うコンピュータによって読みとられ実行されるコンピュータプログラムであって、
前記コンピュータを、
前記通信機器から受信した各認証要求について、当該認証要求の発行元の通信機器の認証を行うと共に、認証した通信機器が既に認証済の通信機器でない場合に、認証済機器数を１増加する認証処理を行う認証処理部と、
前記認証処理部が認証した通信機器と前記データ通信を行うデータ通信部として機能させ、
前記認証処理部は、発行元が認証済の通信機器でない認証要求についての認証処理を、当該認証要求に先行して受信した、認証処理を実行中の、発行元が認証済の通信機器でない他の認証要求の数を、前記認証済機器数に加算した数が、前記所定の制限数未満である場合に実行することを特徴とするコンピュータププログラム。
【請求項４】
通信機器とデータ通信を行うコンピュータによって読みとられ実行されるコンピュータプログラムであって、
前記コンピュータを、
前記通信機器から受信した各認証要求について、当該認証要求の発行元の通信機器と認証鍵を共有するための第１の処理と、前記認証鍵を用いて暗号化した交換キーを前記通信装置に送信し、認証した通信機器が既に認証済の通信機器でない場合に、認証済機器数を１増加する第２の処理とを含む認証処理を行う認証処理部と、
前記交換キーを送信した通信機器と、当該交換キーを利用した暗号化を施した前記データ通信を行うデータ通信部として機能させ、
前記認証処理部は、発行元が認証済の通信機器でない認証要求についての認証処理を、前記第１の処理を実行し、当該第１の処理の終了後に、前記第２の処理を実行中の他の認証処理が存在しなくなった時点で、前記認証済機器数が所定の制限数未満である場合に、前記第２の処理を実行することにより行うことを特徴とするコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１１−１４５９１９（Ｐ２０１１−１４５９１９Ａ）
【公開日】平成２３年７月２８日（２０１１．７．２８）
【国際特許分類】
【出願番号】特願２０１０−６７４９（Ｐ２０１０−６７４９）
【出願日】平成２２年１月１５日（２０１０．１．１５）
【出願人】（０００１０１７３２）アルパイン株式会社 (2,424)
【Ｆターム（参考）】
【公開日】平成２３年７月２８日（２０１１．７．２８）
【国際特許分類】
【出願日】平成２２年１月１５日（２０１０．１．１５）
【出願人】（０００１０１７３２）アルパイン株式会社 (2,424)
【Ｆターム（参考）】
[ Back to top ]