通信システム、通信装置及び通信方法、並びにコンピューター・プログラムム
【課題】コンテンツを同時に伝送する機器の台数を制限しながら、ユーザーの正当な使用の範囲でのコンテンツの伝送を行なう。
【解決手段】コンテンツ利用装置は、交換鍵と対応する鍵IDを定期的にコマンドで送信し、コンテンツ提供装置は、鍵IDを所定の受信周期毎に受信できている期間だけ対応する交換鍵を保持する。コンテンツ提供装置は、定期的に鍵IDを受信できなくなると、対応する交換鍵を破棄し、その後、当該鍵IDを含んだコマンドを受信すると、交換鍵は無効になったことを示す情報を含んだレスポンスを返す。
【解決手段】コンテンツ利用装置は、交換鍵と対応する鍵IDを定期的にコマンドで送信し、コンテンツ提供装置は、鍵IDを所定の受信周期毎に受信できている期間だけ対応する交換鍵を保持する。コンテンツ提供装置は、定期的に鍵IDを受信できなくなると、対応する交換鍵を破棄し、その後、当該鍵IDを含んだコマンドを受信すると、交換鍵は無効になったことを示す情報を含んだレスポンスを返す。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、コンテンツの伝送における不正利用を防止する通信システム、通信装置及び通信方法、並びにコンピューター・プログラムに係り、特に、暗号化コンテンツの復号鍵を所定の相互認証及び鍵交換(AKE)アルゴリズムに従って交換して暗号化コンテンツを伝送する通信システム、通信装置及び通信方法、並びにコンピューター・プログラムに関する。
【背景技術】
【0002】
従来、放送コンテンツやパッケージ・メディア中のコンテンツは、コンテンツ利用装置や再生機器が設置された場所、又は、これらの機器とホームネットワーク経由で接続された機器で利用すること(以下、「ローカル・アクセス(LA)」とも呼ぶ)が基本であった。例えば、屋外から携帯機器で上記のコンテンツ利用装置や再生機器と接続し、WAN(Wide Area Network)などの外部ネットワーク経由の伝送を伴ってコンテンツを利用すること(以下、「リモート・アクセス(RA)」とも呼ぶ)は、通信路やコーデックなどの技術的な観点から困難であった。しかし、将来的には、LTE(Long Term Evolution)やWiMAX(World Interoperability for Microwave Access)といったデータ通信技術、並びに、H.264などの高圧縮コーデックの普及が見込まれ、これらを活用することでリモート・アクセスの実現可能性が見えてくる。例えば、ユーザーが出先から自宅のサーバーにリモート・アクセスして、コンテンツを再生するという使い方である。
【0003】
ディジタル化されたコンテンツはコピーや改竄などの不正な操作が比較的容易である。とりわけ、リモート・アクセスにおいては、個人的又は家庭的なコンテンツの使用を許容しながら、コンテンツ伝送に介在する不正利用を防止し、コンテンツの著作権を保護する必要がある。
【0004】
ディジタル・コンテンツの伝送保護に関する業界標準的な技術として、DTLA(Digital Transmission Licensing Administrator)が開発したDTCP(Digital Transmission Content Protection)が挙げられる。DTCPでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、DTCP準拠機器は取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換(Authentication and Key Exchange:AKE)アルゴリズムに従って行なうこと、並びにAKEコマンドにより鍵交換を行なう機器の範囲を制限することなどである。
【0005】
また、IPネットワークに移植したDTCP技術、すなわちDTCP−IP(DTCP mapping to IP)によれば、家庭内においてもディジタル・コンテンツをIPネットワーク経由で流通させることができる。現在のDTCP−IP(DTCP Volume 1 Specification Supplement E Revision 1.2)は、主にコンテンツの家庭内のみの利用を確保することを意図し、AKEコマンドに対し往復遅延時間(RTT:Round Trip Time)や、IPルーターのホップ回数(TTL:Time To Live)に制限を設定している。
【0006】
例えば、SourceがDTCP−IP認証を開始してから終了する直前までの間、受信した各AKEコマンドを監視し続け、TTL値の最大値を更新し続け、認証手続きが終了する直前にTTL値の最大値をチェックし、この最大値が3以下であれば鍵交換して認証手続きを完了するが、3を超えると、最終段階の処理を行なわずに認証手続きを終わらせる情報通信システムについて提案がなされている(例えば、特許文献1を参照のこと)。
【0007】
また、コンテンツのオーナーは、コンテンツの不正利用を制限するために、1つのコンテンツ提供装置(Source)が同時に多数のコンテンツ利用装置(Sink)にコンテンツ伝送を行なうことを禁止する可能性がある。
【0008】
これに対し、コンテンツを利用するユーザーは、複数のコンテンツ利用装置を状況に応じて使い分けたり、家庭内に設置された1台のコンテンツ提供装置を家族で共用したりすることもあり得る。このような利用形態において、家庭内の1台のコンテンツ提供装置から複数のコンテンツ利用装置にコンテンツ伝送を行なうことはコンテンツの正当な利用の範囲内であり、上記のようにコンテンツのオーナーが台数制限を設定してコンテンツ伝送を禁止するのは、ユーザーのコンテンツ利用を不当に制限することになる。
【先行技術文献】
【特許文献】
【0009】
【特許文献1】特開2007−36351号公報
【発明の概要】
【発明が解決しようとする課題】
【0010】
本発明の目的は、暗号化コンテンツの復号鍵を所定の相互認証及び鍵交換アルゴリズムに従って交換して暗号化コンテンツを好適に伝送することができる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することにある。
【0011】
本発明のさらなる目的は、著作権やその他の目的で保護が必要となるコンテンツを同時に伝送する機器の台数を制限しながら、ユーザーの正当な使用の範囲でのコンテンツの伝送を行なうことができる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することにある。
【課題を解決するための手段】
【0012】
本願は、上記課題を参酌してなされたものであり、請求項1に記載の発明は、
コンテンツを提供するコンテンツ提供装置とコンテンツを利用する1以上のコンテンツ利用装置の間でコンテンツ伝送のための通信を行なう通信システムであって、
コンテンツ提供装置とコンテンツ利用装置の間で相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段と、
コンテンツ提供装置が各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ID及びコンテンツ利用装置を特定する機器IDと組み合わせて記録する鍵記録手段と、
コンテンツ利用装置がコンテンツ提供装置に鍵IDを含んだ鍵寿命管理コマンドを定期的に送信している間だけ、当該鍵IDの情報を前記鍵記録手段に維持する鍵管理手段と、
を具備する通信システムである。
【0013】
但し、ここで言う「システム」とは、複数の装置(又は特定の機能を実現する機能モジュール)が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない。
【0014】
また、本願の請求項2に記載の発明は、
コンテンツの提供先となる1以上のコンテンツ利用装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段と、
各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ID及びコンテンツ利用装置を特定する機器IDと組み合わせて記録する鍵記録手段と、
コンテンツ利用装置から鍵IDを含んだ鍵寿命管理コマンドを所定の受信周期で受信している間だけ、当該鍵IDに対応する情報を前記鍵記録手段に維持する鍵管理手段と、
を具備する通信装置である。
【0015】
本願の請求項3に記載の発明によれば、請求項2に記載の通信装置の鍵管理手段は、鍵寿命管理コマンドを所定の受信周期で受信できなかった鍵IDに対応する情報を前記鍵記録手段から破棄するように構成されている。
【0016】
本願の請求項4に記載の発明によれば、請求項2に記載の通信装置の鍵管理手段は、コンテンツ利用装置から鍵寿命管理コマンドを受信したことに応答して、受信した鍵寿命管理コマンドに含まれる鍵IDに対応する情報が前記鍵記録手段に維持されているときには鍵が有効であることを示すレスポンスを返信し、対応する情報が前記鍵記録手段から破棄した後であれば鍵が無効であることを示すレスポンスを返信するように構成されている。
【0017】
本願の請求項5に記載の発明によれば、請求項2に記載の通信装置の鍵管理手段は、鍵の破棄を指示する情報がセットされた鍵寿命管理コマンドを受信したことに応答して、対応する鍵の情報を前記鍵管理手段から破棄するように構成されている。
【0018】
本願の請求項6に記載の発明によれば、請求項2に記載の通信装置は、鍵交換するコンテンツ利用装置の事前登録を行なう登録手段をさらに備えている。そして、鍵管理手段は、前記登録手段に事前登録されていないコンテンツ利用装置から鍵寿命コマンドを受信したことに応答して、未登録であることを示すレスポンスを返信するように構成されている。
【0019】
また、本願の請求項7に記載の発明は、
コンテンツの提供元となるコンテンツ提供装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段と、
前記相互認証及び鍵交換手段によりコンテンツ提供装置から渡された鍵を特定する鍵IDを含んだ鍵寿命管理コマンドを送信する鍵寿命管理手段と、
を具備する通信装置である。
【0020】
本願の請求項8に記載の発明によれば、請求項7に記載の通信装置の鍵寿命管理手段は、鍵が不要になったときに、鍵の破棄を指示する情報をセットした鍵寿命管理コマンドを送信するように構成されている。
【0021】
また、本願の請求項9に記載の発明は、
コンテンツの提供先となる1以上のコンテンツ利用装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換ステップと、
各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ID及びコンテンツ利用装置を特定する機器IDと組み合わせて記録する鍵記録ステップと、
コンテンツ利用装置から鍵IDを含んだ鍵寿命管理コマンドを所定の受信周期で受信している間だけ、当該鍵IDに対応する情報を前記鍵記録手段に維持する鍵管理ステップと、
を有する通信方法である。
【0022】
また、本願の請求項10に記載の発明は、
コンテンツの提供元となるコンテンツ提供装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換ステップと、
前記相互認証及び鍵交換ステップにおいてコンテンツ提供装置から渡された鍵を特定する鍵IDを含んだ鍵寿命管理コマンドを送信する鍵寿命管理ステップと、
を有する通信方法である。
【0023】
また、本願の請求項11に記載の発明は、コンテンツを提供するコンテンツ提供装置とコンテンツを利用する1以上のコンテンツ利用装置の間でコンテンツ伝送のための通信を行なう通信システムにおいて、コンテンツ提供装置として動作するための処理をコンピューター上で実行するようにコンピューター可読形式で記述されたコンピューター・プログラムであって、前記コンピューターを、
コンテンツの提供先となる1以上のコンテンツ利用装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段、
各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ID及びコンテンツ利用装置を特定する機器IDと組み合わせて記録する鍵記録手段、
コンテンツ利用装置から鍵IDを含んだ鍵寿命管理コマンドを所定の受信周期で受信している間だけ、当該鍵IDに対応する情報を前記鍵記録手段に維持する鍵管理手段、
として機能させるためのコンピューター・プログラムである。
【0024】
また、本願の請求項12に記載の発明は、コンテンツを提供するコンテンツ提供装置とコンテンツを利用する1以上のコンテンツ利用装置の間でコンテンツ伝送のための通信を行なう通信システムにおいて、コンテンツ利用装置として動作するための処理をコンピューター上で実行するようにコンピューター可読形式で記述されたコンピューター・プログラムであって、前記コンピューターを、
コンテンツの提供元となるコンテンツ提供装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段、
前記相互認証及び鍵交換手段によりコンテンツ提供装置から渡された鍵を特定する鍵IDを含んだ鍵寿命管理コマンドを送信する鍵寿命管理手段、
として機能させるためのコンピューター・プログラムである。
【0025】
本願の請求項11、12に係る各コンピューター・プログラムは、コンピューター上で所定の処理を実現するようにコンピューター可読形式で記述されたコンピューター・プログラムを定義したものである。換言すれば、本願の請求項11、12に係るコンピューター・プログラムをコンピューターにインストールすることによって、コンピューター上では協働的作用が発揮され、それぞれ本願の請求項2、7に係る通信装置と同様の作用効果を得ることができる。
【発明の効果】
【0026】
本発明によれば、著作権やその他の目的で保護が必要となるコンテンツを同時に伝送する機器の台数を制限しながら、ユーザーの正当な使用の範囲でのコンテンツの伝送を行なうことができる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することができる。
【0027】
本願の請求項1、2、3、7、9乃至12に記載の発明によれば、コンテンツ利用装置は、コンテンツ提供装置へ、鍵IDを含んだ鍵寿命管理コマンドを所定の送信周期毎に送信し、コンテンツ提供装置は、鍵寿命管理コマンドを所定の受信周期毎に受信できている期間だけ対応する鍵を維持するので、コンテンツ提供装置がコンテンツ伝送を同時に行なえるコンテンツ利用装置の台数を所定数以下に制限することができる。
【0028】
本願の請求項に記載4の発明によれば、コンテンツ提供装置は、鍵寿命管理コマンドを受信したことに応答して、対応する鍵を維持しているときには、鍵が有効であることを示すレスポンスを返信する。また、所定の受信周期で鍵寿命管理コマンドを受信できなかったことにより対応する鍵を破棄した後に、コマンドを受信したときには、鍵が無効であることを示すレスポンスを返す。したがって、コンテンツ利用装置は、自分が持つ鍵の現在の状況を確認することができる。
【0029】
本願の請求項5、8に記載の発明によれば、コンテンツ利用装置は不要になった鍵に対応する鍵寿命管理コマンドに不要である旨の情報をセットし、コンテンツ提供装置は、鍵が不要である旨の情報がセットされた鍵寿命管理コマンドを受信したことに応答して対応する鍵を破棄するので、台数の上限以内で他のコンテンツ利用装置と新たに鍵交換を行なうことができるようになる。
【0030】
本願の請求項6に記載の発明によれば、コンテンツ提供装置は、コンテンツのオーナーの求めなどに応じて、鍵交換するコンテンツ利用装置の事前登録を行なうことができる。コンテンツ提供装置は、事前登録されていないコンテンツ利用装置から鍵寿命コマンドを受信したことに応答して、未登録であることを示すレスポンスを返信するので、コンテンツ利用装置は自分が未登録であることを認識することができる。
【0031】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
【図面の簡単な説明】
【0032】
【図1】図1は、本発明に係る通信システムの一構成例を模式的に示した図である。
【図2】図2は、本発明に係る通信システムの他の構成例を模式的に示した図である。
【図3】図3は、コンテンツ提供装置10の機能的構成を模式的に示した図である。
【図4】図4は、コンテンツ利用装置20の機能的構成を模式的に示した図である。
【図5】図5は、SourceとSinkの間でDTCP−IPにより暗号化コンテンツ伝送を行なう仕組みを説明するための図である。
【図6】図6は、SourceとSink間で現行のDTCP−IPに従って行なわれる、AKEコマンドを用いた相互認証及び鍵交換の動作シーケンスを示した図である。
【図7】図7は、コンテンツ提供装置に相当するSourceとコンテンツ利用装置に相当するSink間で行なわれる、コンテンツ伝送を同時に行なえるコンテンツ利用装置の台数制限を含んだ相互認証及び鍵交換の動作シーケンスを示した図である。
【図8】図8は、接続テーブルの更新処理の一例を示した図である。
【図9】図9は、KEEP_ALIVEコマンドのフォーマット例を示した図である。
【図10】図10は、SourceとSink間で行なわれる、交換鍵Krの寿命更新を行なう動作シーケンス例を示した図である。
【図11】図11は、SourceとSink間で行なわれる、交換鍵Krの寿命更新を行なう他の動作シーケンス例を示した図である。
【発明を実施するための形態】
【0033】
以下、図面を参照しながら本発明の実施形態について詳細に説明する。
【0034】
本発明は、WANなどの外部ネットワークを経由したリモート・アクセス(RA)を通じてコンテンツを安全に伝送する通信システムに関するものである。同通信システムは、基本的に、リモート・アクセスによりコンテンツを提供するサーバ(RA−Source)と、リモート・アクセスによりコンテンツを要求するクライアント(RA−Sink)からなる。本明細書では、リモート・アクセス時に行なうAKE手続きを、「RA−AKE」と呼ぶことにする。以下、図面を参照しながら本発明の実施形態について詳細に説明する。
【0035】
図1には、本発明に係る通信システムの一構成例を模式的に示している。図示の通信システムでは、RA−Sourceに相当するコンテンツ提供装置10が家庭内に設置され、RA−Sinkに相当するコンテンツ利用装置20が屋外にいる。そして、コンテンツ利用装置20は、携帯電話のような通信機能によってコンテンツ提供装置10に対してリモート・アクセスする。
【0036】
コンテンツ提供装置10は、一般にルーター30とモデム40経由でWAN50などの外部ネットワークに接続される。WAN50は例えばインターネットである。ルーター30には、WAN50側のIPアドレスが、ユーザーが加入するIntenet Accsess Service(IAS)プロバイダー60から割り当てられる。また、コンテンツ利用装置20も、基本的にこのIPアドレスにアクセスする。ルーター30は、コンテンツ提供装置10にはプライベートIPアドレスを割り当て、WAN50からのアクセスについてはポート・フォワーディングによって通信を中継する。なお、ルーター30に割り当てられるIPアドレスは、IASプロバイダー60によって更新される場合があるが、そのようなケースではDDNSサービス70を用い、ルーター30乃至コンテンツ提供装置10のDDNS(Dynamic DNS(Domain Name System))機能を使うことで対応できる。
【0037】
また、図2には、本発明に係る通信システムの他の構成例を模式的に示している。図示の通信システムでは、RA−Sinkに相当するコンテンツ利用装置20も家庭内に設置され、ルーター31とモデム41経由でWAN50に接続されている。コンテンツ利用装置20から発信されるTCP/IP(Transmission Control Protocol/Internet Protocol)通信は、ルーター31のNAT(Network Address Translation)機能によってアドレス変換されるが、それ以外は図1の場合と同様である。
【0038】
図3には、コンテンツ提供装置10の機能的構成を模式的に示している。コンテンツ提供装置10は、CPU(Central Processing Unit)11と、コンテンツ受信/再生部12と、通信部13と、記憶部14と、タイマー15を備えるが、RA−Sourceとして機能して、リモート・アクセスでコンテンツを送信する。
【0039】
コンテンツ受信/再生部12は、放送受信機能や、パッケージ・メディア再生機能を備えている。CPU11は、コンテンツ受信/再生部12で得られるコンテンツについて、リモート・アクセス可能なものを適切な保護を施した後に、通信部13を通じて、RA−AKEにより相互認証及び鍵交換を行なったRA−Sink(コンテンツ利用装置20)に送信する。
【0040】
記憶部14には、後述の登録処理によって記憶することになったRA−Sinkの識別情報や、RA−AKEを通じてRA−Sinkと共有したリモート・アセス用の交換鍵とその交換鍵の識別情報(以下、「鍵ID」とも呼ぶ)などが記憶される。本実施形態では、同時に登録できる交換鍵及び鍵IDの組はn個に制限される(但し、nは正の整数)。後述する接続テーブルや受信機器テーブルも、記憶部14に保存される。また、記憶部14は、コンテンツ受信/再生部12で得たコンテンツを蓄積する用途で用いることもできる。
【0041】
タイマー15は、リモート・アクセス可能なコンテンツを扱う際に、時間管理が必要となる場合(例えば、後述するように、RA−Sinkからの鍵IDの受信周期を管理する場合)に使われる。
【0042】
図4には、コンテンツ利用装置20の機能的構成を模式的に示している。コンテンツ利用装置20は、CPU21と、通信部22と、コンテンツ出力部23と、記憶部24を備えるが、RA−Sinkとして機能して、リモート・アクセスでコンテンツを受信する。
【0043】
RA−Sinkとしてのコンテンツ利用装置20は、通信部22を通じてRA−Source(コンテンツ提供装置10)に対して後述する交換鍵及び鍵IDの登録処理を行なう他、RA−AKEを行なってRA−Sourceから交換鍵を取得して記憶部24に保持するとともに、その鍵を基に算出する暗号鍵でRA−Sourceから得た暗号化コンテンツを復号して、コンテンツ出力部23からコンテンツを出力する。記憶部24は、RA−Sourceから受け取った交換鍵やコンテンツを蓄積する用途で用いられる。
【0044】
タイマー25は、リモート・アクセス可能なコンテンツを扱う際に、時間管理が必要となる場合(例えば、後述するように、RA−Sourceからの鍵IDの送信周期を管理する場合)に使われる。
【0045】
以下の説明では、交換鍵から暗号鍵を算出する方法はDTCP−IPに従うものとする(但し、本発明の要旨は必ずしもこの方法には限定されない)。
【0046】
ここで、コンテンツ提供装置に相当するSourceとコンテンツ利用装置に相当するSinkの間でDTCP−IPにより暗号化コンテンツ伝送を行なう仕組みについて、図5を参照しながら説明しておく(RA−SourceとRA−Sink間での仕組みも同様であると理解されたい)。コンテンツ伝送の形態は、Source上のコンテンツをSinkにコピーする方法と、SourceからSinkへコンテンツを移動してSourceにコンテンツを残さない方法があるが(周知)、同図では前者のコピーによるコンテンツ伝送方法を前提にして説明する。
【0047】
SourceとSinkは、まず1つのTCP/IPコネクションを確立して、機器同士の認証(AKE手続き)を行なう。DTCP準拠機器には、DTLA(前述)により発行された機器証明書が埋め込まれている。AKE手続きでは、互いが正規のDTCP準拠機器であることを確かめた後、認証鍵KauthをSourceとSinkで共有することができる。
【0048】
AKE手続きが成功すると、Sourceはコンテンツ鍵Kcの種となる交換鍵Kxを生成し、認証鍵Kauthで暗号化してSinkに送る。Source及びSinkそれぞれにおいて、交換鍵Kxに対して所定の演算処理を適用することによって、コンテンツ伝送時にコンテンツを暗号化するために使用されるコンテンツ鍵Kcを生成することができる。
【0049】
そして、DTCP準拠の機器間でAKEによる認証及び鍵交換手続きが済んだ後、HTTP(Hyper Text Transfer Protocol)やRTP(Real Time Protocol)などのプロトコルを利用してコンテンツ伝送が開始される。図示の例では、HTTPの手続きに従ってコンテンツ伝送が行なわれる。その際、AKE手続きのためのTCP/IPコネクションとは別に、HTTPのためのTCP/IPコネクションが作成される(すなわち、SourceとSinkはそれぞれ、AKE手続き用とコンテンツ伝送用に個別のソケット情報(IPアドレスとポート番号の組み合わせ)を持つ)。
【0050】
HTTPプロトコルに従ってコンテンツ伝送を行なうには、SinkがSourceにコンテンツを要求するダウンロード形式と、Source側からSinkにコンテンツをプッシュするアップロード形式の2通りが挙げられる。前者の場合、HTTPクライアントとしてのSinkは、例えばHTTP GETメソッドを用いたHTTPリクエストにより、HTTPサーバーとしてのSourceにコンテンツを要求し、これに対し、Souceからは要求通りのコンテンツがHTTPレスポンスとして伝送される。また後者の場合、HTTPクライアントとしてのSourceは、例えばHTTP POSTメソッドを用いたHTTPリクエストにより、HTTPサーバーとしてのSinkとの伝送を開始する。
【0051】
Sourceから伝送されるデータは、SourceがAKE認証をした後に共有した鍵を用いてコンテンツを暗号化したデータとなっている。具体的には、Sourceは、乱数を用いてノンスNcを生成して、交換鍵KxとノンスNcと暗号モードに応じたコンテンツ鍵Kcを生成する。そして、Sinkから要求されているコンテンツを、コンテンツ鍵Kcを用いて暗号化し、暗号化コンテンツからなるペイロードとノンスNcと暗号モードの情報を含んだヘッダーからなるパケットをTCPストリーム上に乗せて送信する。IPプロトコルでは、TCPストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダー部を付加したIPパケットにし、指定されたIPアドレス宛てに届ける。
【0052】
Sink側では、Sourceからの各IPパケットを受信すると、これをTCPストリームに組み立てる。そして、このストリームからノンスNcとE−EMIを取り出すと、これらと交換鍵Kxを用いてコンテンツ鍵Kcを算出し、コンテンツ鍵Kcを用いて暗号化コンテンツを復号することができる。そして、復号化した後の平文のコンテンツに対し再生処理を実施することができる。あるいは、Sinkは、暗号化コンテンツを復号することなく、コンテンツを記憶部24に格納したり、他の機器にスルーしたりする。このようにしてHTTPプロトコルを利用したコンテンツ伝送が終了すると、例えばSink側から、コンテンツ伝送に使用したTCPコネクションを適宜切断する。(DTCP−IPでは、パケットのヘッダー部に記述するE−EMI(ExtendedEncryption Mode Indicator)と、Embedded CCI(Copy Control Information)という2つのメカニズムにより、コンテンツに付随したコピー制御情報の伝送を実現している。)
【0053】
なお、DTCP−IPでは、連続不使用時間が所定の期間(例えば2時間)を超える前に交換鍵Kxを破棄することが規定されている。SinkはSourceから最新の交換鍵Kxを入手できなければ、暗号化コンテンツを利用不能となる。また、交換鍵Kxの運用方法には、Sink毎に1つずつ鍵を用意する方法と、Sinkによらず1つの鍵を使う方法がある。本実施形態では、Sink毎に1つずつ交換鍵Kxを用意するとともに、各交換鍵Kxに識別情報(鍵ID)が割り当てられるものとする。
【0054】
図6には、コンテンツ提供装置に相当するSourceとコンテンツ利用装置に相当するSink間で現行のDTCP−IPに従って行なわれる、AKEコマンドを用いた相互認証及び鍵交換の動作シーケンス(RTT−AKE)を示している。
【0055】
AKE手続きのチャレンジ・レスポンス部分(Challenge−Response portion of AKE)では、まず、コンテンツを要求するSinkから、Rx乱数とRx証明書を含んだRxチャレンジが送信される。これに対し、Sourceからは、Tx乱数及びTx証明書を含んだTxチャレンジが返信される。以降、Sourceから、Rx乱数、Txメッセージ、Tx署名を含んだRxレスポンスが送信されるとともに、SinkからはTx乱数、Rxメッセージ、Rx署名を含んだTxレスポンスが送信され、通常のチャレンジ・レスポンス認証手続きが続く。チャレンジ・レスポンス部分で送信されるコマンドには、各チャレンジ・コマンドには、機器固有の識別情報であるDevice IDが含まれている。
【0056】
上記のチャレンジ・レスポンス応答手続きでは、TTL(IPルーターのホップ回数)の制限が課されている。すなわち、現在のDTCP−IPでは、送信機器はAKEで用いるコマンドを送るTCP/IP通信においてTTLが3以下に設定され、受信機器はTTLが3より大きい場合は受け取ったデータを無効にしなければならない。
【0057】
その後、RTT保護プロトコル(Protected RTT Protocol)を経て、SourceからSinkへ、EXCHANGE_KEYコマンドが送信され、これに対し、Sinkからレスポンス(図示しない)が返される。
【0058】
図6に示した現行のDTCP−IPに従うRTT−AKEでは、AKEコマンドに対し往復遅延時間(RTT)やIPルーターのホップ回数(TTL)に上限を設定して、IPネットワーク経由でコンテンツを伝送できる範囲を制限している。コンテンツのオーナーによっては、さらにコンテンツの不正利用を制限するために、1台のコンテンツ提供装置(RA−Source)から同時にコンテンツ伝送を行なうコンテンツ利用装置(RA−Sink)の台数に上限を設定する場合がある。
【0059】
ところが、コンテンツを利用するユーザーは、複数のコンテンツ利用装置(RA−Sink)を状況に応じて使い分けたり、家庭内に設置された1台のコンテンツ提供装置(RA−Source)を家族で共用したりすることもあり得る。家庭内の1台のコンテンツ提供装置から複数のコンテンツ利用装置にコンテンツ伝送を行なうことはコンテンツの正当な利用の範囲内であり、上記のようにコンテンツのオーナーが台数制限を設定してコンテンツ伝送を禁止するのは、ユーザーのコンテンツ利用を不当に制限することになる。
【0060】
そこで、本実施形態に係る通信システムでは、1台のコンテンツ提供装置から同時にコンテンツ伝送を行なうコンテンツ利用装置の台数の上限をn台に設定しながら(但し、nは正の整数)、ユーザーによる特別な切り替え操作なしに、上限のn台に含まれるコンテンツ利用装置を適宜入れ替えることによって、コンテンツのオーナーからのコンテンツ保護の要求に応えながら、ユーザーによるコンテンツの正当な利用を確保する仕組みを導入している。
【0061】
コンテンツ提供装置がコンテンツ伝送を同時に行なえるコンテンツ利用装置の台数を所定数以下に制限するために、コンテンツ利用装置は、コンテンツ提供装置へ、交換鍵と対応する鍵IDを、所定の送信周期毎にコマンドで送信する。そして、コンテンツ提供装置は、鍵IDを所定の受信周期毎に受信できている期間だけ、対応する交換鍵を保持する。他方、鍵IDを含んだコマンドを所定の受信周期で受信できなかったときには、対応する交換鍵を破棄する。DTCP−IPでは、連続不使用時間が所定の期間を超える前に交換鍵を破棄することが規定されているが(前述)、本実施形態では、2時間以内であっても鍵IDを含んだコマンドを定期的に受信できなくなるとコンテンツ提供装置は対応する交換鍵を破棄する。
【0062】
コンテンツ提供装置は、鍵IDを含んだコマンドを受信すると、対応する交換鍵を維持しているかどうかを確認する。そして、交換鍵を維持している間に対応するコマンドを受信したときには、交換鍵が有効であることを示す情報を含んだレスポンスを送信元のコンテンツ利用装置に返信する。他方、鍵IDを含んだコマンドを所定の受信周期で受信できなかったことにより、対応する交換鍵を破棄した後にコマンドを受信したときには、交換鍵が無効であることを示す情報を含んだレスポンスを送信元のコンテンツ利用装置に返信する。
【0063】
また、コンテンツ提供装置は、鍵IDを含んだコマンドを定期的に受信できなかったことにより、交換鍵を破棄した後に、これに対応する鍵IDを含んだコマンドを受信したときには、コンテンツ提供装置は、送信元のコンテンツ利用装置に対して、当該交換鍵(若しくは交換鍵から生成したコンテンツ鍵)が無効であるという情報を含んだレスポンスを返信する。
【0064】
また、コンテンツ利用装置は、コンテンツ提供装置との通信処理の終了などにより交換鍵が不要になったときには、定期的に送信するコマンドにそのことを示す情報をセットする。コンテンツ提供装置は、このコマンドを受信すると、対応する交換鍵を破棄する。
【0065】
また、コンテンツ提供装置は、事前に登録しているコンテンツ利用装置としか鍵の寿命管理を行なわないようにしてもよい。コンテンツ利用装置は定期的に送信するコマンドの中に自分を特定する機器IDを含ませ、これに対し、コマンドを受信したコンテンツ提供装置は、受信したコマンドに含まれる機器IDに対応するコンテンツ利用装置が登録済みであるかどうかを確認する。そして、コマンド送信元のコンテンツ利用装置が登録済みでない場合には、コンテンツ提供装置は、コマンドに含まれる鍵IDに対応する交換鍵の有効確認を行なう前に、コンテンツ利用装置が未登録であることを示す情報を含んだレスポンスを送信元のコンテンツ利用装置に返信する。
【0066】
図7には、コンテンツ提供装置に相当するSourceとコンテンツ利用装置に相当するSink間で行なわれる、コンテンツ伝送を同時に行なえるコンテンツ利用装置の台数制限を含んだ相互認証及び鍵交換の動作シーケンスを示している。但し、図示のシーケンスは、DTCPのFull Authentication処理をベースとして用いるものとする。また、リモート・アクセスでは設定しない運用が一般的と考えられるが、図6に示した動作シーケンスと同様に、AKEコマンドに対し往復遅延時間(RTT)やIPルーターのホップ回数(TTL)に上限を設定してもよい。但し、図示を省略している。
【0067】
Sinkは、コンテンツを必要とするときに、Sourceに、CHALLENGEコマンドを送信する。このとき、当該相互認証及び鍵交換の手続が、Sourceへのリモート・アクセス用の鍵(Kr)を共有することが目的であることを示すため、Sinkは、CHALLENGEコマンドの中に、Kr−bitをセットする。また、Sinkの特定情報であるDevice IDも、CHALLENGEコマンドで送信される。
【0068】
以後、DTCPのFull Authenticationプロトコルに基づいて、SourceからCHALLENGEコマンド、SinkからRESPONSEコマンド、SourceからRESPONSEコマンド又はRESPONSE2コマンドが順に送信される。
【0069】
なお、チャレンジ・レスポンス部分の中では、SinkからSourceへのレスポンスとして「RESPONSE2」が送られることがある。これは、機器がCommon Device KeyとCommon Device Certificateを実装することで、Device IDがSinkの特定情報とならない場合であり、RESPONSE2コマンドで送られるIDuがSinkの特定情報として用いられる。
【0070】
Sourceは、Sinkを特定するための機器IDを決める(ステップS71)。Sourceは、RESPONSE2を受信したときはIDuを、RESPONSE2コマンドを受信しなかったときはDevice IDを、機器IDとして使う。
【0071】
Sourceは、Sinkとの相互認証及び鍵交換の手続の結果、Sinkにリモート・アクセス用の交換鍵Krを渡した場合、この交換鍵Krと、Krを特定するための鍵IDと、Sinkの機器IDの組からなるエントリーを、下表に示すように、接続テーブルに保存する。接続テーブルには、同時にコンテンツ伝送できるSinkの制限台数分のエントリーを保存することができるものとする。下表ではエントリー数は2であるが、本発明の要旨は制限台数が2台に限定されるものではない。
【0072】
【表1】
【0073】
また、Sourceは、下表に示すようなリモート・アクセス用の受信機器テーブルを管理しており、同時にコンテンツ伝送を行なうSinkの機器IDを同テーブルに保存している。コンテンツのオーナーがリモート・アクセスするSinkの事前登録を求める場合には、Sinkの機器IDを受信機器テーブルにあらかじめ登録しておく。受信機器テーブルに事前登録できるSinkの台数に上限を設定してもよいが、本発明の要旨は特定の上限台数に限定されるものではない。なお、Sinkの機器IDを受信機器テーブルに登録する方法の一例として、DTCPにおけるRTT−AKEを行なった際に、SourceがSinkを登録するといった方法が挙げられる。
【0074】
【表2】
【0075】
Sourceは、上述したように、Sinkとの相互認証及び鍵交換の手続においてSinkの機器IDを決定すると(ステップS71)、受信機器テーブルに登録済みであるかを確認する(ステップS72)。コンテンツのオーナーは、リモート・アクセスするSinkをSourceにあらかじめ登録しておくことを求める場合があり、それを確認するための処理である。
【0076】
Sinkの機器IDが受信機器テーブルに未登録の場合には(ステップS72のNo)、Sourceは、当該相互認証及び鍵交換の手続の中断を知らせるAKE_CANCELコマンドをSinkに送って、処理を終了する。Sourceは、AKE_CANCELコマンドの中で、Sinkが受信機器テーブルに未登録であることを示す情報を記載するようにしてもよい。Sinkは、鍵交換の前に受信機器テーブルへの登録を行なうようにしてもよい。
【0077】
一方、Sinkの機器IDが受信機テーブルに登録済みの場合には(ステップS72のYes)、続いて、Souceは、Sinkの機器IDが接続テーブルに記録されているかを確認する(ステップS73)。
【0078】
Sinkの機器IDが接続テーブルに記録されていない場合には(ステップS73のNo)、Sourceは、接続テーブルに新たに機器IDを記録する余裕があるかをさらに確認する(ステップS75)。本実施形態では、Sourceは、接続テーブルに記録可能な鍵IDの個数を、鍵カウンターを用いて管理するものとし、この鍵カウンターの値が上限値n未満であれば記録可能とする。Sourceは、鍵カウンターの値が、接続テーブルに記録されている鍵IDの数と同じになるように管理している。
【0079】
鍵カウンターの値が既にnに達している場合(ステップS75のNo)、Sourceは、当該相互認証及び鍵交換の手続の中断を知らせるAKE_CANCELコマンドをSinkに送って、処理を終了する。Sourceは、AKE_CANCELコマンドの中で、接続テーブルに登録されているエントリー数が上限nに達していることを示す情報を記載するようにしてもよい。
【0080】
鍵カウンターの値がn未満の場合(ステップS75のYes)、Sourceは、鍵カウンターに1を加算した後(ステップS76)、リモート・アクセス用の交換鍵Krと、Krを特定するための鍵IDを生成し(ステップS77)、この交換鍵Kr及び鍵IDとSinkの機器IDの組からなるエントリーを接続テーブルに追加する(ステップS78)。
【0081】
また、Sinkの機器IDが接続テーブルに既に記録されている場合には(ステップS73のYes)、当該機器IDに対応するエントリーを接続テーブルから削除した後(ステップS74)、リモート・アクセス用の交換鍵Krと、Krを特定するための鍵IDを新たに生成し(ステップS77)、この交換鍵Kr及び鍵IDとSinkの機器IDの組からなるエントリーを接続テーブルに追加する(ステップS78)。なお、別のパターンとして、当該機器IDに対応するエントリーを接続テーブルから削除する代わりに、機器IDと対応する交換鍵Kr及び鍵IDを接続テーブルから取り出し、改めてこれらの情報を接続テーブルに追加しない処理も考えられる。但し、このパターンについては図示しない。
【0082】
そして、Sourceは、ステップS77で生成したリモート・アクセス用の交換鍵Krを、DTCP仕様で規定されている方法に従って暗号化した後、EXCHANGE_KEYコマンドによって、鍵IDとともにSinkに送信する。
【0083】
Sourceは、交換鍵KrをSinkに送信すると同時に、この交換鍵Krの寿命管理をタイマーによって開始する(ステップS79)。具体的には、Sourceは、鍵IDと対応するタイマーを用意し(すなわち、接続テーブルに保存する鍵ID毎にタイマーを用意し)、所定の値(例えば1分に相当する値)をセットしてダウンカウントを開始する。
【0084】
以後、Sourceは、タイマーを一定のクロックでカウントをゼロまで自動的に減らす。タイマーがゼロに達したら、Sourceは、接続テーブルの更新処理を起動する。
【0085】
図8には、接続テーブルの更新処理の一例を示している。接続テーブルを更新することにより、鍵寿命管理コマンド(AKE_ALIVE.CMD)によって定期的に受信できなかった鍵IDを含むエントリーが接続テーブルから削除される。
【0086】
Sourceは、まず、ゼロになったタイマーに対応する鍵IDを含むエントリーが接続テーブルに存在するか否かをチェックする(ステップS81)。該当するエントリーが接続テーブルに存在しなければ(ステップS81のNo)、処理を終了する。
【0087】
該当するエントリーが接続テーブルに存在するときには(ステップS81のYes)、Sourceは、ゼロになったタイマーに対応する鍵IDを含むエントリーを接続テーブルから削除し(ステップS82)、鍵カウンターを1だけ減算する(ステップS83)。この結果、Sourceは新たに別のSink(あるいは同じSink)と改めて鍵交換を行なうことができるようになる。
【0088】
なお、コマンドの通信に要する遅延を考慮して、タイマーがゼロになった時点から交換鍵を破棄するまでにマージンを設けることや、別のSinkが新たに交換鍵を要求するまでは図8に示した処理を実行しない、という運用も考えられる。
【0089】
このようにSouorceが交換鍵Krの寿命管理を行なうのに対し、Sinkは使用中の交換鍵Krの寿命更新を要求することができる。
【0090】
本実施形態では、Sinkは、KEEP_ALIVEコマンドを所定の送信周期で送信することによって交換鍵Krの寿命更新を要求する。また、Sourceは、KEEP_ALIVEコマンドを所定の受信周期で受信することで、対応する鍵を維持する。図9には、KEEP_ALIVEコマンドのフォーマット例を示している。図示の例では、KEEP_ALIVEコマンドは、ペイロードに、送信元であるSinkを特定する情報である機器IDを記載するフィールドと、寿命更新を要求する交換鍵Krを特定する情報である鍵IDを記載するフィールドを含み、最後の1ビットが交換鍵Krの破棄を指示する破棄フラグとして用いられる。
【0091】
Sourceは、KEEP_ALIVEコマンドを受信すると、寿命更新の処理を実行した後、KEEP_ALIVEレスポンスを返信する。なお、図示を省略するが、KEEP_ALIVEレスポンスの応答情報については、DTCPのAKE Control Command Formatに定義されているstatusフィールドを用いることが考えられる。
【0092】
Sourceは、Sinkから受信したKEEP_ALIVEコマンドに含まれる鍵IDに対応するタイマーに所定の時間を示す値をセットし、ダウンカウントを改めてその値から行なうように制御することで、寿命を更新する。なお、この寿命更新処理は、タイマーがゼロになった後でも、対応する鍵がまだ破棄されていなければ行なうものとする。
【0093】
図10には、SourceとSink間で行なわれる、交換鍵Krの寿命更新を行なう動作シーケンス例を示している。Sinkは、Sourceから交換鍵Kr及びその鍵IDを渡されると、所定の送信周期でKEEP_ALIVEコマンドを送信する。
【0094】
Sourceは、SinkからKEEP_ALIVEコマンドを受信すると、同コマンドに含まれる機器IDが受信機器テーブルに登録済みかを確認する(ステップS101)。
【0095】
KEEP_ALIVEコマンド中の機器IDが受信機器テーブルに未登録の場合は(ステップS101のNo)、Sourceは、応答情報を「機器が未登録」として(ステップS105)、この応答情報を含めたKEEP_ALIVEレスポンスを要求元のSinkに送信して、処理を終了する。
【0096】
一方、KEEP_ALIVEコマンド中の機器IDが受信機器テーブルに登録済みの場合は(ステップS101のYes)、Sourceは、続いて、KEEP_ALIVEコマンド中の鍵IDが接続テーブルに存在するかを確認する(ステップS102)。
【0097】
KEEP_ALIVEコマンド中の鍵IDが接続テーブルに存在していなければ(ステップS102のNo)、Sourceは、応答情報を「鍵が無効」として(ステップS106)、この応答情報を含めたKEEP_ALIVEレスポンスを要求元のSinkに送信して、処理を終了する。
【0098】
また、KEEP_ALIVEコマンド中の鍵IDが接続テーブルに存在している場合には(ステップS102のYes)、Sourceは、この鍵IDと対応するタイマーを所定の時間を示す値で初期化して、改めてダウンカウントを開始する(ステップS103)。そして、Sourceは、応答情報を「鍵が有効」として(ステップS104)、この応答情報を含めたKEEP_ALIVEレスポンスを要求元のSinkに送信して、処理を終了する。
【0099】
Sinkは、Sourceとの相互認証及び鍵交換の手続が完了したら、取得した交換鍵Krを維持したい限り、所定の期間内の送信周期でKEEP_ALIVEコマンドを繰り返し送信する。
【0100】
また、Sinkは、Sourceとの通信(コンテンツの受信)を終了して交換鍵Krが不要になったときに、Sourceに交換鍵Krの破棄を求めるようにしてもよい。Sourceは、接続テーブルから該当するエントリーを削除することによって、上限台数n以内で新たに別のSinkがSourceに接続して通信(コンテンツ伝送)を行なうことができるようになる。
【0101】
Sinkは、例えば所定の送信周期で送信するKEEP_ALIVEコマンドに交換鍵Krの破棄を求める情報を含めることで、Sourceに交換鍵Krの破棄を要求することができる。図9に示したKEEP_ALIVEコマンドのフォーマット例では、ペイロードに破棄フラグが含まれており、この破棄フラグをセットすることで、交換鍵Krの破棄を指示することができる。
【0102】
図11には、SourceとSink間で行なわれる、交換鍵Krの寿命更新を行なう他の動作シーケンス例を示している。図示の動作シーケンスは、不要となった交換鍵Krを破棄する処理を含む点で、図10に示した動作シーケンスとは相違する。
【0103】
Sourceは、SinkからKEEP_ALIVEコマンドを受信すると、同コマンドに含まれる機器IDが受信機器テーブルに登録済みかを確認する(ステップS111)。
【0104】
KEEP_ALIVEコマンド中の機器IDが受信機器テーブルに未登録の場合は(ステップS111のNo)、Sourceは、応答情報を「機器が未登録」として(ステップS116)、この応答情報を含めたKEEP_ALIVEレスポンスを要求元のSinkに送信して、処理を終了する。
【0105】
一方、KEEP_ALIVEコマンド中の機器IDが受信機器テーブルに登録済みの場合は(ステップS111のYes)、Sourceは、続いて、KEEP_ALIVEコマンド中の鍵IDが接続テーブルに存在するかを確認する(ステップS112)。
【0106】
KEEP_ALIVEコマンド中の鍵IDが接続テーブルに存在していなければ(ステップS112のNo)、Sourceは、応答情報を「鍵が無効」として(ステップS120)、この応答情報を含めたKEEP_ALIVEレスポンスを要求元のSinkに送信して、処理を終了する。
【0107】
また、KEEP_ALIVEコマンド中の鍵IDが接続テーブルに存在している場合には(ステップS112のYes)、Sourceは、KEEP_ALIVEコマンド中の破棄フラグがセットされているかをさらに確認する(ステップS113)。
【0108】
KEEP_ALIVEコマンド中の破棄フラグがセットされているときには(ステップS113のYes)、Sourceは、同コマンド中の鍵IDと、これに対応する交換鍵を破棄するとともに(ステップS117)、同コマンド中の鍵IDと対応する交換鍵と機器IDのエントリーを接続テーブルから削除し(ステップS118)、鍵カウンターを1だけ減算する(ステップS119)。そして、Sourceは、応答情報を「鍵が無効」として(ステップS120)、この応答情報を含めたKEEP_ALIVEレスポンスを要求元のSinkに送信して、処理を終了する。
【0109】
一方、KEEP_ALIVEコマンド中の破棄フラグがセットされていないときには(ステップS113のNo)、Sourceは、この鍵IDと対応するタイマーを所定の時間を示す値で初期化して、改めてダウンカウントを開始する(ステップS114)。そして、Sourceは、応答情報を「鍵が有効」として(ステップS115)、この応答情報を含めたKEEP_ALIVEレスポンスを要求元のSinkに送信して、処理を終了する。
【0110】
図10並びに図11に示した動作シーケンスによれば、家庭内に設置されたコンテンツ提供装置(Source)の中のコンテンツを屋外から利用するようなケースで、コンテンツを同時に利用するコンテンツ利用装置(Sink)の台数を厳しく制限する必要が生じても、コンテンツ提供装置と相互認証及び鍵交換の手続を行なった各コンテンツ利用装置がそれぞれ所定の送信周期でKEEP_ALIVEコマンドを送信するので、コンテンツ提供装置は維持すべき交換鍵を正確に把握することができ、また、不要な交換鍵を破棄することで、別のコンテンツ利用装置と新たに通信を行なうことができる。
【0111】
コンテンツ提供装置は、鍵IDによって維持すべき交換鍵を管理するので、コンテンツ利用装置が移動通信中にアドレスが変化しても、その影響を受けずに処理することができる。
【産業上の利用可能性】
【0112】
以上、特定の実施形態を参照しながら、本発明について詳細に説明してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
【0113】
本発明の適用例として、DTCP−IPが適用されるホームネットワーク上のサーバーに、家庭外のクライアントからリモート・アクセスしてコンテンツを利用する通信システムを挙げることができるが、本発明の要旨は、DTCP−IPを適用した通信システムにも、コンテンツにリモート・アクセスする通信システムにも限定されない。著作権やその他の目的で保護が必要となるコンテンツを同時に伝送する機器の台数を制限しながら、ユーザーの正当な使用の範囲でのコンテンツの伝送を行なう通信システムに、同様に本発明を適用することができる。
【0114】
要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、特許請求の範囲を参酌すべきである。
【符号の説明】
【0115】
10…コンテンツ提供装置(RA−source)
11…CPU
12…コンテンツ受信/再生部
13…通信部
14…記憶部
15…タイマー
20…コンテンツ利用装置(RA−sink)
21…CPU
22…通信部
23…コンテンツ出力部
24…記憶部
25…タイマー
30、31…ルーター
40、41…モデム
50…WAN
60…IASサービス
70…DDNSサービス
【技術分野】
【0001】
本発明は、コンテンツの伝送における不正利用を防止する通信システム、通信装置及び通信方法、並びにコンピューター・プログラムに係り、特に、暗号化コンテンツの復号鍵を所定の相互認証及び鍵交換(AKE)アルゴリズムに従って交換して暗号化コンテンツを伝送する通信システム、通信装置及び通信方法、並びにコンピューター・プログラムに関する。
【背景技術】
【0002】
従来、放送コンテンツやパッケージ・メディア中のコンテンツは、コンテンツ利用装置や再生機器が設置された場所、又は、これらの機器とホームネットワーク経由で接続された機器で利用すること(以下、「ローカル・アクセス(LA)」とも呼ぶ)が基本であった。例えば、屋外から携帯機器で上記のコンテンツ利用装置や再生機器と接続し、WAN(Wide Area Network)などの外部ネットワーク経由の伝送を伴ってコンテンツを利用すること(以下、「リモート・アクセス(RA)」とも呼ぶ)は、通信路やコーデックなどの技術的な観点から困難であった。しかし、将来的には、LTE(Long Term Evolution)やWiMAX(World Interoperability for Microwave Access)といったデータ通信技術、並びに、H.264などの高圧縮コーデックの普及が見込まれ、これらを活用することでリモート・アクセスの実現可能性が見えてくる。例えば、ユーザーが出先から自宅のサーバーにリモート・アクセスして、コンテンツを再生するという使い方である。
【0003】
ディジタル化されたコンテンツはコピーや改竄などの不正な操作が比較的容易である。とりわけ、リモート・アクセスにおいては、個人的又は家庭的なコンテンツの使用を許容しながら、コンテンツ伝送に介在する不正利用を防止し、コンテンツの著作権を保護する必要がある。
【0004】
ディジタル・コンテンツの伝送保護に関する業界標準的な技術として、DTLA(Digital Transmission Licensing Administrator)が開発したDTCP(Digital Transmission Content Protection)が挙げられる。DTCPでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、DTCP準拠機器は取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換(Authentication and Key Exchange:AKE)アルゴリズムに従って行なうこと、並びにAKEコマンドにより鍵交換を行なう機器の範囲を制限することなどである。
【0005】
また、IPネットワークに移植したDTCP技術、すなわちDTCP−IP(DTCP mapping to IP)によれば、家庭内においてもディジタル・コンテンツをIPネットワーク経由で流通させることができる。現在のDTCP−IP(DTCP Volume 1 Specification Supplement E Revision 1.2)は、主にコンテンツの家庭内のみの利用を確保することを意図し、AKEコマンドに対し往復遅延時間(RTT:Round Trip Time)や、IPルーターのホップ回数(TTL:Time To Live)に制限を設定している。
【0006】
例えば、SourceがDTCP−IP認証を開始してから終了する直前までの間、受信した各AKEコマンドを監視し続け、TTL値の最大値を更新し続け、認証手続きが終了する直前にTTL値の最大値をチェックし、この最大値が3以下であれば鍵交換して認証手続きを完了するが、3を超えると、最終段階の処理を行なわずに認証手続きを終わらせる情報通信システムについて提案がなされている(例えば、特許文献1を参照のこと)。
【0007】
また、コンテンツのオーナーは、コンテンツの不正利用を制限するために、1つのコンテンツ提供装置(Source)が同時に多数のコンテンツ利用装置(Sink)にコンテンツ伝送を行なうことを禁止する可能性がある。
【0008】
これに対し、コンテンツを利用するユーザーは、複数のコンテンツ利用装置を状況に応じて使い分けたり、家庭内に設置された1台のコンテンツ提供装置を家族で共用したりすることもあり得る。このような利用形態において、家庭内の1台のコンテンツ提供装置から複数のコンテンツ利用装置にコンテンツ伝送を行なうことはコンテンツの正当な利用の範囲内であり、上記のようにコンテンツのオーナーが台数制限を設定してコンテンツ伝送を禁止するのは、ユーザーのコンテンツ利用を不当に制限することになる。
【先行技術文献】
【特許文献】
【0009】
【特許文献1】特開2007−36351号公報
【発明の概要】
【発明が解決しようとする課題】
【0010】
本発明の目的は、暗号化コンテンツの復号鍵を所定の相互認証及び鍵交換アルゴリズムに従って交換して暗号化コンテンツを好適に伝送することができる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することにある。
【0011】
本発明のさらなる目的は、著作権やその他の目的で保護が必要となるコンテンツを同時に伝送する機器の台数を制限しながら、ユーザーの正当な使用の範囲でのコンテンツの伝送を行なうことができる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することにある。
【課題を解決するための手段】
【0012】
本願は、上記課題を参酌してなされたものであり、請求項1に記載の発明は、
コンテンツを提供するコンテンツ提供装置とコンテンツを利用する1以上のコンテンツ利用装置の間でコンテンツ伝送のための通信を行なう通信システムであって、
コンテンツ提供装置とコンテンツ利用装置の間で相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段と、
コンテンツ提供装置が各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ID及びコンテンツ利用装置を特定する機器IDと組み合わせて記録する鍵記録手段と、
コンテンツ利用装置がコンテンツ提供装置に鍵IDを含んだ鍵寿命管理コマンドを定期的に送信している間だけ、当該鍵IDの情報を前記鍵記録手段に維持する鍵管理手段と、
を具備する通信システムである。
【0013】
但し、ここで言う「システム」とは、複数の装置(又は特定の機能を実現する機能モジュール)が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない。
【0014】
また、本願の請求項2に記載の発明は、
コンテンツの提供先となる1以上のコンテンツ利用装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段と、
各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ID及びコンテンツ利用装置を特定する機器IDと組み合わせて記録する鍵記録手段と、
コンテンツ利用装置から鍵IDを含んだ鍵寿命管理コマンドを所定の受信周期で受信している間だけ、当該鍵IDに対応する情報を前記鍵記録手段に維持する鍵管理手段と、
を具備する通信装置である。
【0015】
本願の請求項3に記載の発明によれば、請求項2に記載の通信装置の鍵管理手段は、鍵寿命管理コマンドを所定の受信周期で受信できなかった鍵IDに対応する情報を前記鍵記録手段から破棄するように構成されている。
【0016】
本願の請求項4に記載の発明によれば、請求項2に記載の通信装置の鍵管理手段は、コンテンツ利用装置から鍵寿命管理コマンドを受信したことに応答して、受信した鍵寿命管理コマンドに含まれる鍵IDに対応する情報が前記鍵記録手段に維持されているときには鍵が有効であることを示すレスポンスを返信し、対応する情報が前記鍵記録手段から破棄した後であれば鍵が無効であることを示すレスポンスを返信するように構成されている。
【0017】
本願の請求項5に記載の発明によれば、請求項2に記載の通信装置の鍵管理手段は、鍵の破棄を指示する情報がセットされた鍵寿命管理コマンドを受信したことに応答して、対応する鍵の情報を前記鍵管理手段から破棄するように構成されている。
【0018】
本願の請求項6に記載の発明によれば、請求項2に記載の通信装置は、鍵交換するコンテンツ利用装置の事前登録を行なう登録手段をさらに備えている。そして、鍵管理手段は、前記登録手段に事前登録されていないコンテンツ利用装置から鍵寿命コマンドを受信したことに応答して、未登録であることを示すレスポンスを返信するように構成されている。
【0019】
また、本願の請求項7に記載の発明は、
コンテンツの提供元となるコンテンツ提供装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段と、
前記相互認証及び鍵交換手段によりコンテンツ提供装置から渡された鍵を特定する鍵IDを含んだ鍵寿命管理コマンドを送信する鍵寿命管理手段と、
を具備する通信装置である。
【0020】
本願の請求項8に記載の発明によれば、請求項7に記載の通信装置の鍵寿命管理手段は、鍵が不要になったときに、鍵の破棄を指示する情報をセットした鍵寿命管理コマンドを送信するように構成されている。
【0021】
また、本願の請求項9に記載の発明は、
コンテンツの提供先となる1以上のコンテンツ利用装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換ステップと、
各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ID及びコンテンツ利用装置を特定する機器IDと組み合わせて記録する鍵記録ステップと、
コンテンツ利用装置から鍵IDを含んだ鍵寿命管理コマンドを所定の受信周期で受信している間だけ、当該鍵IDに対応する情報を前記鍵記録手段に維持する鍵管理ステップと、
を有する通信方法である。
【0022】
また、本願の請求項10に記載の発明は、
コンテンツの提供元となるコンテンツ提供装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換ステップと、
前記相互認証及び鍵交換ステップにおいてコンテンツ提供装置から渡された鍵を特定する鍵IDを含んだ鍵寿命管理コマンドを送信する鍵寿命管理ステップと、
を有する通信方法である。
【0023】
また、本願の請求項11に記載の発明は、コンテンツを提供するコンテンツ提供装置とコンテンツを利用する1以上のコンテンツ利用装置の間でコンテンツ伝送のための通信を行なう通信システムにおいて、コンテンツ提供装置として動作するための処理をコンピューター上で実行するようにコンピューター可読形式で記述されたコンピューター・プログラムであって、前記コンピューターを、
コンテンツの提供先となる1以上のコンテンツ利用装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段、
各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ID及びコンテンツ利用装置を特定する機器IDと組み合わせて記録する鍵記録手段、
コンテンツ利用装置から鍵IDを含んだ鍵寿命管理コマンドを所定の受信周期で受信している間だけ、当該鍵IDに対応する情報を前記鍵記録手段に維持する鍵管理手段、
として機能させるためのコンピューター・プログラムである。
【0024】
また、本願の請求項12に記載の発明は、コンテンツを提供するコンテンツ提供装置とコンテンツを利用する1以上のコンテンツ利用装置の間でコンテンツ伝送のための通信を行なう通信システムにおいて、コンテンツ利用装置として動作するための処理をコンピューター上で実行するようにコンピューター可読形式で記述されたコンピューター・プログラムであって、前記コンピューターを、
コンテンツの提供元となるコンテンツ提供装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段、
前記相互認証及び鍵交換手段によりコンテンツ提供装置から渡された鍵を特定する鍵IDを含んだ鍵寿命管理コマンドを送信する鍵寿命管理手段、
として機能させるためのコンピューター・プログラムである。
【0025】
本願の請求項11、12に係る各コンピューター・プログラムは、コンピューター上で所定の処理を実現するようにコンピューター可読形式で記述されたコンピューター・プログラムを定義したものである。換言すれば、本願の請求項11、12に係るコンピューター・プログラムをコンピューターにインストールすることによって、コンピューター上では協働的作用が発揮され、それぞれ本願の請求項2、7に係る通信装置と同様の作用効果を得ることができる。
【発明の効果】
【0026】
本発明によれば、著作権やその他の目的で保護が必要となるコンテンツを同時に伝送する機器の台数を制限しながら、ユーザーの正当な使用の範囲でのコンテンツの伝送を行なうことができる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することができる。
【0027】
本願の請求項1、2、3、7、9乃至12に記載の発明によれば、コンテンツ利用装置は、コンテンツ提供装置へ、鍵IDを含んだ鍵寿命管理コマンドを所定の送信周期毎に送信し、コンテンツ提供装置は、鍵寿命管理コマンドを所定の受信周期毎に受信できている期間だけ対応する鍵を維持するので、コンテンツ提供装置がコンテンツ伝送を同時に行なえるコンテンツ利用装置の台数を所定数以下に制限することができる。
【0028】
本願の請求項に記載4の発明によれば、コンテンツ提供装置は、鍵寿命管理コマンドを受信したことに応答して、対応する鍵を維持しているときには、鍵が有効であることを示すレスポンスを返信する。また、所定の受信周期で鍵寿命管理コマンドを受信できなかったことにより対応する鍵を破棄した後に、コマンドを受信したときには、鍵が無効であることを示すレスポンスを返す。したがって、コンテンツ利用装置は、自分が持つ鍵の現在の状況を確認することができる。
【0029】
本願の請求項5、8に記載の発明によれば、コンテンツ利用装置は不要になった鍵に対応する鍵寿命管理コマンドに不要である旨の情報をセットし、コンテンツ提供装置は、鍵が不要である旨の情報がセットされた鍵寿命管理コマンドを受信したことに応答して対応する鍵を破棄するので、台数の上限以内で他のコンテンツ利用装置と新たに鍵交換を行なうことができるようになる。
【0030】
本願の請求項6に記載の発明によれば、コンテンツ提供装置は、コンテンツのオーナーの求めなどに応じて、鍵交換するコンテンツ利用装置の事前登録を行なうことができる。コンテンツ提供装置は、事前登録されていないコンテンツ利用装置から鍵寿命コマンドを受信したことに応答して、未登録であることを示すレスポンスを返信するので、コンテンツ利用装置は自分が未登録であることを認識することができる。
【0031】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
【図面の簡単な説明】
【0032】
【図1】図1は、本発明に係る通信システムの一構成例を模式的に示した図である。
【図2】図2は、本発明に係る通信システムの他の構成例を模式的に示した図である。
【図3】図3は、コンテンツ提供装置10の機能的構成を模式的に示した図である。
【図4】図4は、コンテンツ利用装置20の機能的構成を模式的に示した図である。
【図5】図5は、SourceとSinkの間でDTCP−IPにより暗号化コンテンツ伝送を行なう仕組みを説明するための図である。
【図6】図6は、SourceとSink間で現行のDTCP−IPに従って行なわれる、AKEコマンドを用いた相互認証及び鍵交換の動作シーケンスを示した図である。
【図7】図7は、コンテンツ提供装置に相当するSourceとコンテンツ利用装置に相当するSink間で行なわれる、コンテンツ伝送を同時に行なえるコンテンツ利用装置の台数制限を含んだ相互認証及び鍵交換の動作シーケンスを示した図である。
【図8】図8は、接続テーブルの更新処理の一例を示した図である。
【図9】図9は、KEEP_ALIVEコマンドのフォーマット例を示した図である。
【図10】図10は、SourceとSink間で行なわれる、交換鍵Krの寿命更新を行なう動作シーケンス例を示した図である。
【図11】図11は、SourceとSink間で行なわれる、交換鍵Krの寿命更新を行なう他の動作シーケンス例を示した図である。
【発明を実施するための形態】
【0033】
以下、図面を参照しながら本発明の実施形態について詳細に説明する。
【0034】
本発明は、WANなどの外部ネットワークを経由したリモート・アクセス(RA)を通じてコンテンツを安全に伝送する通信システムに関するものである。同通信システムは、基本的に、リモート・アクセスによりコンテンツを提供するサーバ(RA−Source)と、リモート・アクセスによりコンテンツを要求するクライアント(RA−Sink)からなる。本明細書では、リモート・アクセス時に行なうAKE手続きを、「RA−AKE」と呼ぶことにする。以下、図面を参照しながら本発明の実施形態について詳細に説明する。
【0035】
図1には、本発明に係る通信システムの一構成例を模式的に示している。図示の通信システムでは、RA−Sourceに相当するコンテンツ提供装置10が家庭内に設置され、RA−Sinkに相当するコンテンツ利用装置20が屋外にいる。そして、コンテンツ利用装置20は、携帯電話のような通信機能によってコンテンツ提供装置10に対してリモート・アクセスする。
【0036】
コンテンツ提供装置10は、一般にルーター30とモデム40経由でWAN50などの外部ネットワークに接続される。WAN50は例えばインターネットである。ルーター30には、WAN50側のIPアドレスが、ユーザーが加入するIntenet Accsess Service(IAS)プロバイダー60から割り当てられる。また、コンテンツ利用装置20も、基本的にこのIPアドレスにアクセスする。ルーター30は、コンテンツ提供装置10にはプライベートIPアドレスを割り当て、WAN50からのアクセスについてはポート・フォワーディングによって通信を中継する。なお、ルーター30に割り当てられるIPアドレスは、IASプロバイダー60によって更新される場合があるが、そのようなケースではDDNSサービス70を用い、ルーター30乃至コンテンツ提供装置10のDDNS(Dynamic DNS(Domain Name System))機能を使うことで対応できる。
【0037】
また、図2には、本発明に係る通信システムの他の構成例を模式的に示している。図示の通信システムでは、RA−Sinkに相当するコンテンツ利用装置20も家庭内に設置され、ルーター31とモデム41経由でWAN50に接続されている。コンテンツ利用装置20から発信されるTCP/IP(Transmission Control Protocol/Internet Protocol)通信は、ルーター31のNAT(Network Address Translation)機能によってアドレス変換されるが、それ以外は図1の場合と同様である。
【0038】
図3には、コンテンツ提供装置10の機能的構成を模式的に示している。コンテンツ提供装置10は、CPU(Central Processing Unit)11と、コンテンツ受信/再生部12と、通信部13と、記憶部14と、タイマー15を備えるが、RA−Sourceとして機能して、リモート・アクセスでコンテンツを送信する。
【0039】
コンテンツ受信/再生部12は、放送受信機能や、パッケージ・メディア再生機能を備えている。CPU11は、コンテンツ受信/再生部12で得られるコンテンツについて、リモート・アクセス可能なものを適切な保護を施した後に、通信部13を通じて、RA−AKEにより相互認証及び鍵交換を行なったRA−Sink(コンテンツ利用装置20)に送信する。
【0040】
記憶部14には、後述の登録処理によって記憶することになったRA−Sinkの識別情報や、RA−AKEを通じてRA−Sinkと共有したリモート・アセス用の交換鍵とその交換鍵の識別情報(以下、「鍵ID」とも呼ぶ)などが記憶される。本実施形態では、同時に登録できる交換鍵及び鍵IDの組はn個に制限される(但し、nは正の整数)。後述する接続テーブルや受信機器テーブルも、記憶部14に保存される。また、記憶部14は、コンテンツ受信/再生部12で得たコンテンツを蓄積する用途で用いることもできる。
【0041】
タイマー15は、リモート・アクセス可能なコンテンツを扱う際に、時間管理が必要となる場合(例えば、後述するように、RA−Sinkからの鍵IDの受信周期を管理する場合)に使われる。
【0042】
図4には、コンテンツ利用装置20の機能的構成を模式的に示している。コンテンツ利用装置20は、CPU21と、通信部22と、コンテンツ出力部23と、記憶部24を備えるが、RA−Sinkとして機能して、リモート・アクセスでコンテンツを受信する。
【0043】
RA−Sinkとしてのコンテンツ利用装置20は、通信部22を通じてRA−Source(コンテンツ提供装置10)に対して後述する交換鍵及び鍵IDの登録処理を行なう他、RA−AKEを行なってRA−Sourceから交換鍵を取得して記憶部24に保持するとともに、その鍵を基に算出する暗号鍵でRA−Sourceから得た暗号化コンテンツを復号して、コンテンツ出力部23からコンテンツを出力する。記憶部24は、RA−Sourceから受け取った交換鍵やコンテンツを蓄積する用途で用いられる。
【0044】
タイマー25は、リモート・アクセス可能なコンテンツを扱う際に、時間管理が必要となる場合(例えば、後述するように、RA−Sourceからの鍵IDの送信周期を管理する場合)に使われる。
【0045】
以下の説明では、交換鍵から暗号鍵を算出する方法はDTCP−IPに従うものとする(但し、本発明の要旨は必ずしもこの方法には限定されない)。
【0046】
ここで、コンテンツ提供装置に相当するSourceとコンテンツ利用装置に相当するSinkの間でDTCP−IPにより暗号化コンテンツ伝送を行なう仕組みについて、図5を参照しながら説明しておく(RA−SourceとRA−Sink間での仕組みも同様であると理解されたい)。コンテンツ伝送の形態は、Source上のコンテンツをSinkにコピーする方法と、SourceからSinkへコンテンツを移動してSourceにコンテンツを残さない方法があるが(周知)、同図では前者のコピーによるコンテンツ伝送方法を前提にして説明する。
【0047】
SourceとSinkは、まず1つのTCP/IPコネクションを確立して、機器同士の認証(AKE手続き)を行なう。DTCP準拠機器には、DTLA(前述)により発行された機器証明書が埋め込まれている。AKE手続きでは、互いが正規のDTCP準拠機器であることを確かめた後、認証鍵KauthをSourceとSinkで共有することができる。
【0048】
AKE手続きが成功すると、Sourceはコンテンツ鍵Kcの種となる交換鍵Kxを生成し、認証鍵Kauthで暗号化してSinkに送る。Source及びSinkそれぞれにおいて、交換鍵Kxに対して所定の演算処理を適用することによって、コンテンツ伝送時にコンテンツを暗号化するために使用されるコンテンツ鍵Kcを生成することができる。
【0049】
そして、DTCP準拠の機器間でAKEによる認証及び鍵交換手続きが済んだ後、HTTP(Hyper Text Transfer Protocol)やRTP(Real Time Protocol)などのプロトコルを利用してコンテンツ伝送が開始される。図示の例では、HTTPの手続きに従ってコンテンツ伝送が行なわれる。その際、AKE手続きのためのTCP/IPコネクションとは別に、HTTPのためのTCP/IPコネクションが作成される(すなわち、SourceとSinkはそれぞれ、AKE手続き用とコンテンツ伝送用に個別のソケット情報(IPアドレスとポート番号の組み合わせ)を持つ)。
【0050】
HTTPプロトコルに従ってコンテンツ伝送を行なうには、SinkがSourceにコンテンツを要求するダウンロード形式と、Source側からSinkにコンテンツをプッシュするアップロード形式の2通りが挙げられる。前者の場合、HTTPクライアントとしてのSinkは、例えばHTTP GETメソッドを用いたHTTPリクエストにより、HTTPサーバーとしてのSourceにコンテンツを要求し、これに対し、Souceからは要求通りのコンテンツがHTTPレスポンスとして伝送される。また後者の場合、HTTPクライアントとしてのSourceは、例えばHTTP POSTメソッドを用いたHTTPリクエストにより、HTTPサーバーとしてのSinkとの伝送を開始する。
【0051】
Sourceから伝送されるデータは、SourceがAKE認証をした後に共有した鍵を用いてコンテンツを暗号化したデータとなっている。具体的には、Sourceは、乱数を用いてノンスNcを生成して、交換鍵KxとノンスNcと暗号モードに応じたコンテンツ鍵Kcを生成する。そして、Sinkから要求されているコンテンツを、コンテンツ鍵Kcを用いて暗号化し、暗号化コンテンツからなるペイロードとノンスNcと暗号モードの情報を含んだヘッダーからなるパケットをTCPストリーム上に乗せて送信する。IPプロトコルでは、TCPストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダー部を付加したIPパケットにし、指定されたIPアドレス宛てに届ける。
【0052】
Sink側では、Sourceからの各IPパケットを受信すると、これをTCPストリームに組み立てる。そして、このストリームからノンスNcとE−EMIを取り出すと、これらと交換鍵Kxを用いてコンテンツ鍵Kcを算出し、コンテンツ鍵Kcを用いて暗号化コンテンツを復号することができる。そして、復号化した後の平文のコンテンツに対し再生処理を実施することができる。あるいは、Sinkは、暗号化コンテンツを復号することなく、コンテンツを記憶部24に格納したり、他の機器にスルーしたりする。このようにしてHTTPプロトコルを利用したコンテンツ伝送が終了すると、例えばSink側から、コンテンツ伝送に使用したTCPコネクションを適宜切断する。(DTCP−IPでは、パケットのヘッダー部に記述するE−EMI(ExtendedEncryption Mode Indicator)と、Embedded CCI(Copy Control Information)という2つのメカニズムにより、コンテンツに付随したコピー制御情報の伝送を実現している。)
【0053】
なお、DTCP−IPでは、連続不使用時間が所定の期間(例えば2時間)を超える前に交換鍵Kxを破棄することが規定されている。SinkはSourceから最新の交換鍵Kxを入手できなければ、暗号化コンテンツを利用不能となる。また、交換鍵Kxの運用方法には、Sink毎に1つずつ鍵を用意する方法と、Sinkによらず1つの鍵を使う方法がある。本実施形態では、Sink毎に1つずつ交換鍵Kxを用意するとともに、各交換鍵Kxに識別情報(鍵ID)が割り当てられるものとする。
【0054】
図6には、コンテンツ提供装置に相当するSourceとコンテンツ利用装置に相当するSink間で現行のDTCP−IPに従って行なわれる、AKEコマンドを用いた相互認証及び鍵交換の動作シーケンス(RTT−AKE)を示している。
【0055】
AKE手続きのチャレンジ・レスポンス部分(Challenge−Response portion of AKE)では、まず、コンテンツを要求するSinkから、Rx乱数とRx証明書を含んだRxチャレンジが送信される。これに対し、Sourceからは、Tx乱数及びTx証明書を含んだTxチャレンジが返信される。以降、Sourceから、Rx乱数、Txメッセージ、Tx署名を含んだRxレスポンスが送信されるとともに、SinkからはTx乱数、Rxメッセージ、Rx署名を含んだTxレスポンスが送信され、通常のチャレンジ・レスポンス認証手続きが続く。チャレンジ・レスポンス部分で送信されるコマンドには、各チャレンジ・コマンドには、機器固有の識別情報であるDevice IDが含まれている。
【0056】
上記のチャレンジ・レスポンス応答手続きでは、TTL(IPルーターのホップ回数)の制限が課されている。すなわち、現在のDTCP−IPでは、送信機器はAKEで用いるコマンドを送るTCP/IP通信においてTTLが3以下に設定され、受信機器はTTLが3より大きい場合は受け取ったデータを無効にしなければならない。
【0057】
その後、RTT保護プロトコル(Protected RTT Protocol)を経て、SourceからSinkへ、EXCHANGE_KEYコマンドが送信され、これに対し、Sinkからレスポンス(図示しない)が返される。
【0058】
図6に示した現行のDTCP−IPに従うRTT−AKEでは、AKEコマンドに対し往復遅延時間(RTT)やIPルーターのホップ回数(TTL)に上限を設定して、IPネットワーク経由でコンテンツを伝送できる範囲を制限している。コンテンツのオーナーによっては、さらにコンテンツの不正利用を制限するために、1台のコンテンツ提供装置(RA−Source)から同時にコンテンツ伝送を行なうコンテンツ利用装置(RA−Sink)の台数に上限を設定する場合がある。
【0059】
ところが、コンテンツを利用するユーザーは、複数のコンテンツ利用装置(RA−Sink)を状況に応じて使い分けたり、家庭内に設置された1台のコンテンツ提供装置(RA−Source)を家族で共用したりすることもあり得る。家庭内の1台のコンテンツ提供装置から複数のコンテンツ利用装置にコンテンツ伝送を行なうことはコンテンツの正当な利用の範囲内であり、上記のようにコンテンツのオーナーが台数制限を設定してコンテンツ伝送を禁止するのは、ユーザーのコンテンツ利用を不当に制限することになる。
【0060】
そこで、本実施形態に係る通信システムでは、1台のコンテンツ提供装置から同時にコンテンツ伝送を行なうコンテンツ利用装置の台数の上限をn台に設定しながら(但し、nは正の整数)、ユーザーによる特別な切り替え操作なしに、上限のn台に含まれるコンテンツ利用装置を適宜入れ替えることによって、コンテンツのオーナーからのコンテンツ保護の要求に応えながら、ユーザーによるコンテンツの正当な利用を確保する仕組みを導入している。
【0061】
コンテンツ提供装置がコンテンツ伝送を同時に行なえるコンテンツ利用装置の台数を所定数以下に制限するために、コンテンツ利用装置は、コンテンツ提供装置へ、交換鍵と対応する鍵IDを、所定の送信周期毎にコマンドで送信する。そして、コンテンツ提供装置は、鍵IDを所定の受信周期毎に受信できている期間だけ、対応する交換鍵を保持する。他方、鍵IDを含んだコマンドを所定の受信周期で受信できなかったときには、対応する交換鍵を破棄する。DTCP−IPでは、連続不使用時間が所定の期間を超える前に交換鍵を破棄することが規定されているが(前述)、本実施形態では、2時間以内であっても鍵IDを含んだコマンドを定期的に受信できなくなるとコンテンツ提供装置は対応する交換鍵を破棄する。
【0062】
コンテンツ提供装置は、鍵IDを含んだコマンドを受信すると、対応する交換鍵を維持しているかどうかを確認する。そして、交換鍵を維持している間に対応するコマンドを受信したときには、交換鍵が有効であることを示す情報を含んだレスポンスを送信元のコンテンツ利用装置に返信する。他方、鍵IDを含んだコマンドを所定の受信周期で受信できなかったことにより、対応する交換鍵を破棄した後にコマンドを受信したときには、交換鍵が無効であることを示す情報を含んだレスポンスを送信元のコンテンツ利用装置に返信する。
【0063】
また、コンテンツ提供装置は、鍵IDを含んだコマンドを定期的に受信できなかったことにより、交換鍵を破棄した後に、これに対応する鍵IDを含んだコマンドを受信したときには、コンテンツ提供装置は、送信元のコンテンツ利用装置に対して、当該交換鍵(若しくは交換鍵から生成したコンテンツ鍵)が無効であるという情報を含んだレスポンスを返信する。
【0064】
また、コンテンツ利用装置は、コンテンツ提供装置との通信処理の終了などにより交換鍵が不要になったときには、定期的に送信するコマンドにそのことを示す情報をセットする。コンテンツ提供装置は、このコマンドを受信すると、対応する交換鍵を破棄する。
【0065】
また、コンテンツ提供装置は、事前に登録しているコンテンツ利用装置としか鍵の寿命管理を行なわないようにしてもよい。コンテンツ利用装置は定期的に送信するコマンドの中に自分を特定する機器IDを含ませ、これに対し、コマンドを受信したコンテンツ提供装置は、受信したコマンドに含まれる機器IDに対応するコンテンツ利用装置が登録済みであるかどうかを確認する。そして、コマンド送信元のコンテンツ利用装置が登録済みでない場合には、コンテンツ提供装置は、コマンドに含まれる鍵IDに対応する交換鍵の有効確認を行なう前に、コンテンツ利用装置が未登録であることを示す情報を含んだレスポンスを送信元のコンテンツ利用装置に返信する。
【0066】
図7には、コンテンツ提供装置に相当するSourceとコンテンツ利用装置に相当するSink間で行なわれる、コンテンツ伝送を同時に行なえるコンテンツ利用装置の台数制限を含んだ相互認証及び鍵交換の動作シーケンスを示している。但し、図示のシーケンスは、DTCPのFull Authentication処理をベースとして用いるものとする。また、リモート・アクセスでは設定しない運用が一般的と考えられるが、図6に示した動作シーケンスと同様に、AKEコマンドに対し往復遅延時間(RTT)やIPルーターのホップ回数(TTL)に上限を設定してもよい。但し、図示を省略している。
【0067】
Sinkは、コンテンツを必要とするときに、Sourceに、CHALLENGEコマンドを送信する。このとき、当該相互認証及び鍵交換の手続が、Sourceへのリモート・アクセス用の鍵(Kr)を共有することが目的であることを示すため、Sinkは、CHALLENGEコマンドの中に、Kr−bitをセットする。また、Sinkの特定情報であるDevice IDも、CHALLENGEコマンドで送信される。
【0068】
以後、DTCPのFull Authenticationプロトコルに基づいて、SourceからCHALLENGEコマンド、SinkからRESPONSEコマンド、SourceからRESPONSEコマンド又はRESPONSE2コマンドが順に送信される。
【0069】
なお、チャレンジ・レスポンス部分の中では、SinkからSourceへのレスポンスとして「RESPONSE2」が送られることがある。これは、機器がCommon Device KeyとCommon Device Certificateを実装することで、Device IDがSinkの特定情報とならない場合であり、RESPONSE2コマンドで送られるIDuがSinkの特定情報として用いられる。
【0070】
Sourceは、Sinkを特定するための機器IDを決める(ステップS71)。Sourceは、RESPONSE2を受信したときはIDuを、RESPONSE2コマンドを受信しなかったときはDevice IDを、機器IDとして使う。
【0071】
Sourceは、Sinkとの相互認証及び鍵交換の手続の結果、Sinkにリモート・アクセス用の交換鍵Krを渡した場合、この交換鍵Krと、Krを特定するための鍵IDと、Sinkの機器IDの組からなるエントリーを、下表に示すように、接続テーブルに保存する。接続テーブルには、同時にコンテンツ伝送できるSinkの制限台数分のエントリーを保存することができるものとする。下表ではエントリー数は2であるが、本発明の要旨は制限台数が2台に限定されるものではない。
【0072】
【表1】
【0073】
また、Sourceは、下表に示すようなリモート・アクセス用の受信機器テーブルを管理しており、同時にコンテンツ伝送を行なうSinkの機器IDを同テーブルに保存している。コンテンツのオーナーがリモート・アクセスするSinkの事前登録を求める場合には、Sinkの機器IDを受信機器テーブルにあらかじめ登録しておく。受信機器テーブルに事前登録できるSinkの台数に上限を設定してもよいが、本発明の要旨は特定の上限台数に限定されるものではない。なお、Sinkの機器IDを受信機器テーブルに登録する方法の一例として、DTCPにおけるRTT−AKEを行なった際に、SourceがSinkを登録するといった方法が挙げられる。
【0074】
【表2】
【0075】
Sourceは、上述したように、Sinkとの相互認証及び鍵交換の手続においてSinkの機器IDを決定すると(ステップS71)、受信機器テーブルに登録済みであるかを確認する(ステップS72)。コンテンツのオーナーは、リモート・アクセスするSinkをSourceにあらかじめ登録しておくことを求める場合があり、それを確認するための処理である。
【0076】
Sinkの機器IDが受信機器テーブルに未登録の場合には(ステップS72のNo)、Sourceは、当該相互認証及び鍵交換の手続の中断を知らせるAKE_CANCELコマンドをSinkに送って、処理を終了する。Sourceは、AKE_CANCELコマンドの中で、Sinkが受信機器テーブルに未登録であることを示す情報を記載するようにしてもよい。Sinkは、鍵交換の前に受信機器テーブルへの登録を行なうようにしてもよい。
【0077】
一方、Sinkの機器IDが受信機テーブルに登録済みの場合には(ステップS72のYes)、続いて、Souceは、Sinkの機器IDが接続テーブルに記録されているかを確認する(ステップS73)。
【0078】
Sinkの機器IDが接続テーブルに記録されていない場合には(ステップS73のNo)、Sourceは、接続テーブルに新たに機器IDを記録する余裕があるかをさらに確認する(ステップS75)。本実施形態では、Sourceは、接続テーブルに記録可能な鍵IDの個数を、鍵カウンターを用いて管理するものとし、この鍵カウンターの値が上限値n未満であれば記録可能とする。Sourceは、鍵カウンターの値が、接続テーブルに記録されている鍵IDの数と同じになるように管理している。
【0079】
鍵カウンターの値が既にnに達している場合(ステップS75のNo)、Sourceは、当該相互認証及び鍵交換の手続の中断を知らせるAKE_CANCELコマンドをSinkに送って、処理を終了する。Sourceは、AKE_CANCELコマンドの中で、接続テーブルに登録されているエントリー数が上限nに達していることを示す情報を記載するようにしてもよい。
【0080】
鍵カウンターの値がn未満の場合(ステップS75のYes)、Sourceは、鍵カウンターに1を加算した後(ステップS76)、リモート・アクセス用の交換鍵Krと、Krを特定するための鍵IDを生成し(ステップS77)、この交換鍵Kr及び鍵IDとSinkの機器IDの組からなるエントリーを接続テーブルに追加する(ステップS78)。
【0081】
また、Sinkの機器IDが接続テーブルに既に記録されている場合には(ステップS73のYes)、当該機器IDに対応するエントリーを接続テーブルから削除した後(ステップS74)、リモート・アクセス用の交換鍵Krと、Krを特定するための鍵IDを新たに生成し(ステップS77)、この交換鍵Kr及び鍵IDとSinkの機器IDの組からなるエントリーを接続テーブルに追加する(ステップS78)。なお、別のパターンとして、当該機器IDに対応するエントリーを接続テーブルから削除する代わりに、機器IDと対応する交換鍵Kr及び鍵IDを接続テーブルから取り出し、改めてこれらの情報を接続テーブルに追加しない処理も考えられる。但し、このパターンについては図示しない。
【0082】
そして、Sourceは、ステップS77で生成したリモート・アクセス用の交換鍵Krを、DTCP仕様で規定されている方法に従って暗号化した後、EXCHANGE_KEYコマンドによって、鍵IDとともにSinkに送信する。
【0083】
Sourceは、交換鍵KrをSinkに送信すると同時に、この交換鍵Krの寿命管理をタイマーによって開始する(ステップS79)。具体的には、Sourceは、鍵IDと対応するタイマーを用意し(すなわち、接続テーブルに保存する鍵ID毎にタイマーを用意し)、所定の値(例えば1分に相当する値)をセットしてダウンカウントを開始する。
【0084】
以後、Sourceは、タイマーを一定のクロックでカウントをゼロまで自動的に減らす。タイマーがゼロに達したら、Sourceは、接続テーブルの更新処理を起動する。
【0085】
図8には、接続テーブルの更新処理の一例を示している。接続テーブルを更新することにより、鍵寿命管理コマンド(AKE_ALIVE.CMD)によって定期的に受信できなかった鍵IDを含むエントリーが接続テーブルから削除される。
【0086】
Sourceは、まず、ゼロになったタイマーに対応する鍵IDを含むエントリーが接続テーブルに存在するか否かをチェックする(ステップS81)。該当するエントリーが接続テーブルに存在しなければ(ステップS81のNo)、処理を終了する。
【0087】
該当するエントリーが接続テーブルに存在するときには(ステップS81のYes)、Sourceは、ゼロになったタイマーに対応する鍵IDを含むエントリーを接続テーブルから削除し(ステップS82)、鍵カウンターを1だけ減算する(ステップS83)。この結果、Sourceは新たに別のSink(あるいは同じSink)と改めて鍵交換を行なうことができるようになる。
【0088】
なお、コマンドの通信に要する遅延を考慮して、タイマーがゼロになった時点から交換鍵を破棄するまでにマージンを設けることや、別のSinkが新たに交換鍵を要求するまでは図8に示した処理を実行しない、という運用も考えられる。
【0089】
このようにSouorceが交換鍵Krの寿命管理を行なうのに対し、Sinkは使用中の交換鍵Krの寿命更新を要求することができる。
【0090】
本実施形態では、Sinkは、KEEP_ALIVEコマンドを所定の送信周期で送信することによって交換鍵Krの寿命更新を要求する。また、Sourceは、KEEP_ALIVEコマンドを所定の受信周期で受信することで、対応する鍵を維持する。図9には、KEEP_ALIVEコマンドのフォーマット例を示している。図示の例では、KEEP_ALIVEコマンドは、ペイロードに、送信元であるSinkを特定する情報である機器IDを記載するフィールドと、寿命更新を要求する交換鍵Krを特定する情報である鍵IDを記載するフィールドを含み、最後の1ビットが交換鍵Krの破棄を指示する破棄フラグとして用いられる。
【0091】
Sourceは、KEEP_ALIVEコマンドを受信すると、寿命更新の処理を実行した後、KEEP_ALIVEレスポンスを返信する。なお、図示を省略するが、KEEP_ALIVEレスポンスの応答情報については、DTCPのAKE Control Command Formatに定義されているstatusフィールドを用いることが考えられる。
【0092】
Sourceは、Sinkから受信したKEEP_ALIVEコマンドに含まれる鍵IDに対応するタイマーに所定の時間を示す値をセットし、ダウンカウントを改めてその値から行なうように制御することで、寿命を更新する。なお、この寿命更新処理は、タイマーがゼロになった後でも、対応する鍵がまだ破棄されていなければ行なうものとする。
【0093】
図10には、SourceとSink間で行なわれる、交換鍵Krの寿命更新を行なう動作シーケンス例を示している。Sinkは、Sourceから交換鍵Kr及びその鍵IDを渡されると、所定の送信周期でKEEP_ALIVEコマンドを送信する。
【0094】
Sourceは、SinkからKEEP_ALIVEコマンドを受信すると、同コマンドに含まれる機器IDが受信機器テーブルに登録済みかを確認する(ステップS101)。
【0095】
KEEP_ALIVEコマンド中の機器IDが受信機器テーブルに未登録の場合は(ステップS101のNo)、Sourceは、応答情報を「機器が未登録」として(ステップS105)、この応答情報を含めたKEEP_ALIVEレスポンスを要求元のSinkに送信して、処理を終了する。
【0096】
一方、KEEP_ALIVEコマンド中の機器IDが受信機器テーブルに登録済みの場合は(ステップS101のYes)、Sourceは、続いて、KEEP_ALIVEコマンド中の鍵IDが接続テーブルに存在するかを確認する(ステップS102)。
【0097】
KEEP_ALIVEコマンド中の鍵IDが接続テーブルに存在していなければ(ステップS102のNo)、Sourceは、応答情報を「鍵が無効」として(ステップS106)、この応答情報を含めたKEEP_ALIVEレスポンスを要求元のSinkに送信して、処理を終了する。
【0098】
また、KEEP_ALIVEコマンド中の鍵IDが接続テーブルに存在している場合には(ステップS102のYes)、Sourceは、この鍵IDと対応するタイマーを所定の時間を示す値で初期化して、改めてダウンカウントを開始する(ステップS103)。そして、Sourceは、応答情報を「鍵が有効」として(ステップS104)、この応答情報を含めたKEEP_ALIVEレスポンスを要求元のSinkに送信して、処理を終了する。
【0099】
Sinkは、Sourceとの相互認証及び鍵交換の手続が完了したら、取得した交換鍵Krを維持したい限り、所定の期間内の送信周期でKEEP_ALIVEコマンドを繰り返し送信する。
【0100】
また、Sinkは、Sourceとの通信(コンテンツの受信)を終了して交換鍵Krが不要になったときに、Sourceに交換鍵Krの破棄を求めるようにしてもよい。Sourceは、接続テーブルから該当するエントリーを削除することによって、上限台数n以内で新たに別のSinkがSourceに接続して通信(コンテンツ伝送)を行なうことができるようになる。
【0101】
Sinkは、例えば所定の送信周期で送信するKEEP_ALIVEコマンドに交換鍵Krの破棄を求める情報を含めることで、Sourceに交換鍵Krの破棄を要求することができる。図9に示したKEEP_ALIVEコマンドのフォーマット例では、ペイロードに破棄フラグが含まれており、この破棄フラグをセットすることで、交換鍵Krの破棄を指示することができる。
【0102】
図11には、SourceとSink間で行なわれる、交換鍵Krの寿命更新を行なう他の動作シーケンス例を示している。図示の動作シーケンスは、不要となった交換鍵Krを破棄する処理を含む点で、図10に示した動作シーケンスとは相違する。
【0103】
Sourceは、SinkからKEEP_ALIVEコマンドを受信すると、同コマンドに含まれる機器IDが受信機器テーブルに登録済みかを確認する(ステップS111)。
【0104】
KEEP_ALIVEコマンド中の機器IDが受信機器テーブルに未登録の場合は(ステップS111のNo)、Sourceは、応答情報を「機器が未登録」として(ステップS116)、この応答情報を含めたKEEP_ALIVEレスポンスを要求元のSinkに送信して、処理を終了する。
【0105】
一方、KEEP_ALIVEコマンド中の機器IDが受信機器テーブルに登録済みの場合は(ステップS111のYes)、Sourceは、続いて、KEEP_ALIVEコマンド中の鍵IDが接続テーブルに存在するかを確認する(ステップS112)。
【0106】
KEEP_ALIVEコマンド中の鍵IDが接続テーブルに存在していなければ(ステップS112のNo)、Sourceは、応答情報を「鍵が無効」として(ステップS120)、この応答情報を含めたKEEP_ALIVEレスポンスを要求元のSinkに送信して、処理を終了する。
【0107】
また、KEEP_ALIVEコマンド中の鍵IDが接続テーブルに存在している場合には(ステップS112のYes)、Sourceは、KEEP_ALIVEコマンド中の破棄フラグがセットされているかをさらに確認する(ステップS113)。
【0108】
KEEP_ALIVEコマンド中の破棄フラグがセットされているときには(ステップS113のYes)、Sourceは、同コマンド中の鍵IDと、これに対応する交換鍵を破棄するとともに(ステップS117)、同コマンド中の鍵IDと対応する交換鍵と機器IDのエントリーを接続テーブルから削除し(ステップS118)、鍵カウンターを1だけ減算する(ステップS119)。そして、Sourceは、応答情報を「鍵が無効」として(ステップS120)、この応答情報を含めたKEEP_ALIVEレスポンスを要求元のSinkに送信して、処理を終了する。
【0109】
一方、KEEP_ALIVEコマンド中の破棄フラグがセットされていないときには(ステップS113のNo)、Sourceは、この鍵IDと対応するタイマーを所定の時間を示す値で初期化して、改めてダウンカウントを開始する(ステップS114)。そして、Sourceは、応答情報を「鍵が有効」として(ステップS115)、この応答情報を含めたKEEP_ALIVEレスポンスを要求元のSinkに送信して、処理を終了する。
【0110】
図10並びに図11に示した動作シーケンスによれば、家庭内に設置されたコンテンツ提供装置(Source)の中のコンテンツを屋外から利用するようなケースで、コンテンツを同時に利用するコンテンツ利用装置(Sink)の台数を厳しく制限する必要が生じても、コンテンツ提供装置と相互認証及び鍵交換の手続を行なった各コンテンツ利用装置がそれぞれ所定の送信周期でKEEP_ALIVEコマンドを送信するので、コンテンツ提供装置は維持すべき交換鍵を正確に把握することができ、また、不要な交換鍵を破棄することで、別のコンテンツ利用装置と新たに通信を行なうことができる。
【0111】
コンテンツ提供装置は、鍵IDによって維持すべき交換鍵を管理するので、コンテンツ利用装置が移動通信中にアドレスが変化しても、その影響を受けずに処理することができる。
【産業上の利用可能性】
【0112】
以上、特定の実施形態を参照しながら、本発明について詳細に説明してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
【0113】
本発明の適用例として、DTCP−IPが適用されるホームネットワーク上のサーバーに、家庭外のクライアントからリモート・アクセスしてコンテンツを利用する通信システムを挙げることができるが、本発明の要旨は、DTCP−IPを適用した通信システムにも、コンテンツにリモート・アクセスする通信システムにも限定されない。著作権やその他の目的で保護が必要となるコンテンツを同時に伝送する機器の台数を制限しながら、ユーザーの正当な使用の範囲でのコンテンツの伝送を行なう通信システムに、同様に本発明を適用することができる。
【0114】
要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、特許請求の範囲を参酌すべきである。
【符号の説明】
【0115】
10…コンテンツ提供装置(RA−source)
11…CPU
12…コンテンツ受信/再生部
13…通信部
14…記憶部
15…タイマー
20…コンテンツ利用装置(RA−sink)
21…CPU
22…通信部
23…コンテンツ出力部
24…記憶部
25…タイマー
30、31…ルーター
40、41…モデム
50…WAN
60…IASサービス
70…DDNSサービス
【特許請求の範囲】
【請求項1】
コンテンツを提供するコンテンツ提供装置とコンテンツを利用する1以上のコンテンツ利用装置の間でコンテンツ伝送のための通信を行なう通信システムであって、
コンテンツ提供装置とコンテンツ利用装置の間で相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段と、
コンテンツ提供装置が各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ID及びコンテンツ利用装置を特定する機器IDと組み合わせて記録する鍵記録手段と、
コンテンツ利用装置がコンテンツ提供装置に鍵IDを含んだ鍵寿命管理コマンドを定期的に送信している間だけ、当該鍵IDの情報を前記鍵記録手段に維持する鍵管理手段と、
を具備する通信システム。
【請求項2】
コンテンツの提供先となる1以上のコンテンツ利用装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段と、
各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ID及びコンテンツ利用装置を特定する機器IDと組み合わせて記録する鍵記録手段と、
コンテンツ利用装置から鍵IDを含んだ鍵寿命管理コマンドを所定の受信周期で受信している間だけ、当該鍵IDに対応する情報を前記鍵記録手段に維持する鍵管理手段と、
を具備する通信装置。
【請求項3】
前記鍵管理手段は、鍵寿命管理コマンドを所定の受信周期で受信できなかった鍵IDに対応する情報を前記鍵記録手段から破棄する、
請求項2に記載の通信装置。
【請求項4】
前記鍵管理手段は、コンテンツ利用装置から鍵寿命管理コマンドを受信したことに応答して、受信した鍵寿命管理コマンドに含まれる鍵IDに対応する情報が前記鍵記録手段に維持されているときには鍵が有効であることを示すレスポンスを返信し、対応する情報が前記鍵記録手段から破棄した後であれば鍵が無効であることを示すレスポンスを返信する、
請求項2に記載の通信装置。
【請求項5】
前記鍵管理手段は、鍵の破棄を指示する情報がセットされた鍵寿命管理コマンドを受信したことに応答して、対応する鍵の情報を前記鍵管理手段から破棄する、
請求項2に記載の通信装置。
【請求項6】
鍵交換するコンテンツ利用装置の事前登録を行なう登録手段をさらに備え、
前記鍵管理手段は、前記登録手段に事前登録されていないコンテンツ利用装置から鍵寿命コマンドを受信したことに応答して、未登録であることを示すレスポンスを返信する、
請求項2に記載の通信装置。
【請求項7】
コンテンツの提供元となるコンテンツ提供装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段と、
前記相互認証及び鍵交換手段によりコンテンツ提供装置から渡された鍵を特定する鍵IDを含んだ鍵寿命管理コマンドを送信する鍵寿命管理手段と、
を具備する通信装置。
【請求項8】
前記鍵寿命管理手段は、鍵が不要になったときに、鍵の破棄を指示する情報をセットした鍵寿命管理コマンドを送信する、
請求項7に記載の通信装置。
【請求項9】
コンテンツの提供先となる1以上のコンテンツ利用装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換ステップと、
各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ID及びコンテンツ利用装置を特定する機器IDと組み合わせて記録する鍵記録ステップと、
コンテンツ利用装置から鍵IDを含んだ鍵寿命管理コマンドを所定の受信周期で受信している間だけ、当該鍵IDに対応する情報を前記鍵記録手段に維持する鍵管理ステップと、
を有する通信方法。
【請求項10】
コンテンツの提供元となるコンテンツ提供装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換ステップと、
前記相互認証及び鍵交換ステップにおいてコンテンツ提供装置から渡された鍵を特定する鍵IDを含んだ鍵寿命管理コマンドを送信する鍵寿命管理ステップと、
を有する通信方法。
【請求項11】
コンテンツを提供するコンテンツ提供装置とコンテンツを利用する1以上のコンテンツ利用装置の間でコンテンツ伝送のための通信を行なう通信システムにおいて、コンテンツ提供装置として動作するための処理をコンピューター上で実行するようにコンピューター可読形式で記述されたコンピューター・プログラムであって、前記コンピューターを、
コンテンツの提供先となる1以上のコンテンツ利用装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段、
各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ID及びコンテンツ利用装置を特定する機器IDと組み合わせて記録する鍵記録手段、
コンテンツ利用装置から鍵IDを含んだ鍵寿命管理コマンドを所定の受信周期で受信している間だけ、当該鍵IDに対応する情報を前記鍵記録手段に維持する鍵管理手段、
として機能させるためのコンピューター・プログラム。
【請求項12】
コンテンツを提供するコンテンツ提供装置とコンテンツを利用する1以上のコンテンツ利用装置の間でコンテンツ伝送のための通信を行なう通信システムにおいて、コンテンツ利用装置として動作するための処理をコンピューター上で実行するようにコンピューター可読形式で記述されたコンピューター・プログラムであって、前記コンピューターを、
コンテンツの提供元となるコンテンツ提供装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段、
前記相互認証及び鍵交換手段によりコンテンツ提供装置から渡された鍵を特定する鍵IDを含んだ鍵寿命管理コマンドを送信する鍵寿命管理手段、
として機能させるためのコンピューター・プログラム。
【請求項1】
コンテンツを提供するコンテンツ提供装置とコンテンツを利用する1以上のコンテンツ利用装置の間でコンテンツ伝送のための通信を行なう通信システムであって、
コンテンツ提供装置とコンテンツ利用装置の間で相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段と、
コンテンツ提供装置が各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ID及びコンテンツ利用装置を特定する機器IDと組み合わせて記録する鍵記録手段と、
コンテンツ利用装置がコンテンツ提供装置に鍵IDを含んだ鍵寿命管理コマンドを定期的に送信している間だけ、当該鍵IDの情報を前記鍵記録手段に維持する鍵管理手段と、
を具備する通信システム。
【請求項2】
コンテンツの提供先となる1以上のコンテンツ利用装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段と、
各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ID及びコンテンツ利用装置を特定する機器IDと組み合わせて記録する鍵記録手段と、
コンテンツ利用装置から鍵IDを含んだ鍵寿命管理コマンドを所定の受信周期で受信している間だけ、当該鍵IDに対応する情報を前記鍵記録手段に維持する鍵管理手段と、
を具備する通信装置。
【請求項3】
前記鍵管理手段は、鍵寿命管理コマンドを所定の受信周期で受信できなかった鍵IDに対応する情報を前記鍵記録手段から破棄する、
請求項2に記載の通信装置。
【請求項4】
前記鍵管理手段は、コンテンツ利用装置から鍵寿命管理コマンドを受信したことに応答して、受信した鍵寿命管理コマンドに含まれる鍵IDに対応する情報が前記鍵記録手段に維持されているときには鍵が有効であることを示すレスポンスを返信し、対応する情報が前記鍵記録手段から破棄した後であれば鍵が無効であることを示すレスポンスを返信する、
請求項2に記載の通信装置。
【請求項5】
前記鍵管理手段は、鍵の破棄を指示する情報がセットされた鍵寿命管理コマンドを受信したことに応答して、対応する鍵の情報を前記鍵管理手段から破棄する、
請求項2に記載の通信装置。
【請求項6】
鍵交換するコンテンツ利用装置の事前登録を行なう登録手段をさらに備え、
前記鍵管理手段は、前記登録手段に事前登録されていないコンテンツ利用装置から鍵寿命コマンドを受信したことに応答して、未登録であることを示すレスポンスを返信する、
請求項2に記載の通信装置。
【請求項7】
コンテンツの提供元となるコンテンツ提供装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段と、
前記相互認証及び鍵交換手段によりコンテンツ提供装置から渡された鍵を特定する鍵IDを含んだ鍵寿命管理コマンドを送信する鍵寿命管理手段と、
を具備する通信装置。
【請求項8】
前記鍵寿命管理手段は、鍵が不要になったときに、鍵の破棄を指示する情報をセットした鍵寿命管理コマンドを送信する、
請求項7に記載の通信装置。
【請求項9】
コンテンツの提供先となる1以上のコンテンツ利用装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換ステップと、
各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ID及びコンテンツ利用装置を特定する機器IDと組み合わせて記録する鍵記録ステップと、
コンテンツ利用装置から鍵IDを含んだ鍵寿命管理コマンドを所定の受信周期で受信している間だけ、当該鍵IDに対応する情報を前記鍵記録手段に維持する鍵管理ステップと、
を有する通信方法。
【請求項10】
コンテンツの提供元となるコンテンツ提供装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換ステップと、
前記相互認証及び鍵交換ステップにおいてコンテンツ提供装置から渡された鍵を特定する鍵IDを含んだ鍵寿命管理コマンドを送信する鍵寿命管理ステップと、
を有する通信方法。
【請求項11】
コンテンツを提供するコンテンツ提供装置とコンテンツを利用する1以上のコンテンツ利用装置の間でコンテンツ伝送のための通信を行なう通信システムにおいて、コンテンツ提供装置として動作するための処理をコンピューター上で実行するようにコンピューター可読形式で記述されたコンピューター・プログラムであって、前記コンピューターを、
コンテンツの提供先となる1以上のコンテンツ利用装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段、
各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ID及びコンテンツ利用装置を特定する機器IDと組み合わせて記録する鍵記録手段、
コンテンツ利用装置から鍵IDを含んだ鍵寿命管理コマンドを所定の受信周期で受信している間だけ、当該鍵IDに対応する情報を前記鍵記録手段に維持する鍵管理手段、
として機能させるためのコンピューター・プログラム。
【請求項12】
コンテンツを提供するコンテンツ提供装置とコンテンツを利用する1以上のコンテンツ利用装置の間でコンテンツ伝送のための通信を行なう通信システムにおいて、コンテンツ利用装置として動作するための処理をコンピューター上で実行するようにコンピューター可読形式で記述されたコンピューター・プログラムであって、前記コンピューターを、
コンテンツの提供元となるコンテンツ提供装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段、
前記相互認証及び鍵交換手段によりコンテンツ提供装置から渡された鍵を特定する鍵IDを含んだ鍵寿命管理コマンドを送信する鍵寿命管理手段、
として機能させるためのコンピューター・プログラム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【公開番号】特開2012−34142(P2012−34142A)
【公開日】平成24年2月16日(2012.2.16)
【国際特許分類】
【出願番号】特願2010−171184(P2010−171184)
【出願日】平成22年7月29日(2010.7.29)
【出願人】(000002185)ソニー株式会社 (34,172)
【Fターム(参考)】
【公開日】平成24年2月16日(2012.2.16)
【国際特許分類】
【出願日】平成22年7月29日(2010.7.29)
【出願人】(000002185)ソニー株式会社 (34,172)
【Fターム(参考)】
[ Back to top ]