コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラム
【課題】コンテンツのフォーマットに依存しない共通の形式でコピー制御情報をパケット内に挿入し、且つこれらの情報をセキュアに使用する。
【解決手段】 旧来のPCPヘッダ内のノンス情報フィールドの上位8ビットを用いてPCP−CCIを記述し、残りの下位56ビットにノンスNcを書き込む。PCP−CCIは、アナログ出力制御に関するAPS、出力時の画サイズに関するICTといった出力制御情報や、フィールドの有効性を記述したモード情報や、ヘッダ部に書き込まれる通常のコピー制御情報と本来はペイロード部に埋め込まれるコピー制御情報との代用可能性に関するSE情報で構成される。
【解決手段】 旧来のPCPヘッダ内のノンス情報フィールドの上位8ビットを用いてPCP−CCIを記述し、残りの下位56ビットにノンスNcを書き込む。PCP−CCIは、アナログ出力制御に関するAPS、出力時の画サイズに関するICTといった出力制御情報や、フィールドの有効性を記述したモード情報や、ヘッダ部に書き込まれる通常のコピー制御情報と本来はペイロード部に埋め込まれるコピー制御情報との代用可能性に関するSE情報で構成される。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、著作権保護若しくはその他の目的で暗号化された伝送コンテンツを伝送処理するコンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムに係り、特に、DTCPに準拠した情報機器同士で暗号化コンテンツの伝送手続きを実行するコンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムに関する。
【0002】
さらに詳しくは、本発明は、伝送するコンテンツに関する属性情報並びにコピー制御情報をパケット内に挿入して伝送するコンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムに係り、特に、コンテンツのフォーマットに依存しない形式で属性情報並びにコピー制御情報をパケット内に挿入して伝送するコンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムに関する。
【背景技術】
【0003】
情報技術の普及に伴い、AVコンテンツのほとんどがデジタル化されており、CDやDVDなどのデジタル・コンテンツを記録再生するメディアが広く利用されている。また、最近では、HDDレコーダやHDD搭載DVDレコーダなど、コンテンツをデジタル記録する機器が家庭内にも浸透してきている。さらには、ネットワークを経由した映像や音楽などのコンテンツの流通・配信サービスが盛んとなり、CDやDVDなどのメディアの移動なしに、ネットワークを経由して遠隔端末間でコンテンツ配信が行なわれている。
【0004】
勿論、これらAVコンテンツは、著作物の1つとして、著作権法の下で無断の複製や改竄などの不正使用から保護を受けることができる。著作権法では、同法第30条において、個人的に又は家庭内などを使用目的とした場合の使用者本人の複製を許容する一方、同法第49条第1項においては、私的使用以外での複製物の使用を禁止している。
【0005】
しかしながら、デジタル化されたコンテンツはコピーや改竄などの不正な操作が比較的容易であることから、法的な整備だけでなく技術的な側面からも、個人的又は家庭的なコンテンツの使用を許容しながら不正使用に対する防御が必要である。とりわけ、国内では2011年の地上アナログ放送停波に向けてアナログ放送受信機からデジタル放送受信機への置き換えが急速に進んでおり、家庭内のAVコンテンツのデジタル化に対してコンテンツの保護を技術的に実現することが必須と考えられている。
【0006】
デジタル・コンテンツの著作権保護を目的とした多くの技術が開発されている。例えば、デジタル伝送コンテンツの保護に関する業界標準として、DTLA(Digital Transmission Licensing Administrator)が開発したDTCP(Digital Transmission Content Protection)が挙げられ、著作権が保護された形でコンテンツを伝送させるための仕組みについて規定されている(例えば、非特許文献1を参照のこと)。
【0007】
DTCPでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、DTCP準拠機器はMPEG(Moving Picture Experts Group)など取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換(Authentication and Key Exchange:AKE)アルゴリズムに従って行なうこと、並びにAKEコマンドにより鍵交換を行なう機器の範囲を制限することなどを取り決めている。
【0008】
コンテンツ提供元であるサーバ(DTCP_Source)とコンテンツ提供先であるクライアント(DTCP_Sink)は、AKEコマンドの送受信により、認証手続きを経て鍵を共有化し、その鍵を用いて伝送路を暗号化してコンテンツの伝送を行なう。したがって、不正なクライアントは、サーバとの認証に成功しないと暗号鍵を取得できないから、コンテンツを享受することはできない。また、AKEコマンドを送受信する機器の台数や範囲を制限することによって、コンテンツが使用される範囲を著作権法で言うところの個人的又は家庭の範囲内に抑えることができる。
【0009】
DTCPは、原初的には、IEEE1394などを伝送路に用いたホーム・ネットワーク上におけるデジタル・コンテンツの伝送について規定したものである。しかしながら、最近では、DLNA(Digital Living Network Alliance)に代表されるように、デジタル化されたAVコンテンツをIPネットワークを用いて家庭内で流通させようという動きが本格的になっていることから、IPネットワークに対応したDTCP技術、すなわちDTCP−IP(DTCP mapping to IP)の開発が進められている。ホーム・ネットワークの多くはルータなどを経由してインターネットなどの外部のIPネットワークに接続されると、コンテンツの不正コピーや改竄の危惧が指摘されている。DTCP−IP技術の確立により、デジタル・コンテンツを保護しながらIPネットワークを利用した柔軟で効率的なコンテンツの利用が図ることが急務である。
【0010】
DTCP−IPは、基本的にはDTCP規格に含まれ、DTCP技術をIPネットワークに移植した同様の技術であるが、伝送路にIPネットワークを使用すること、暗号化されたコンテンツの伝送にHTTP(Hyper Text Transfer Protocol)やRTP(Real Time Protocol)などのプロトコルを使用するという点で、IEEE1394ベースで規定された本来のDTCPとは相違する。また、IPネットワーク上にはPCを主としたさまざまな機器が接続され、データの盗聴、改竄が簡単に行なわれてしまう危険が高いことから、DTCP−IPは、コンテンツを保護しながらネットワーク伝送するためのさらなる方法を規定している(例えば、非特許文献2を参照のこと)。
【0011】
ここで、DTCP−IPに準拠したコンテンツ伝送について説明する。DTCP−IPに準拠したSource機器及びSink機器間でHTTPプロトコルを利用したコンテンツ伝送を実施する場合、TCPストリームのような長大なバイト・ストリームを伝送の途中でコンテンツ鍵を変更しながら暗号化通信が行なわれ、且つ、暗号化コンテンツの復号処理その他のコンテンツ処理を実施する際にコンテンツ鍵の確認手続きが行なわれる。また、相互認証及び鍵交換(AKE)、コンテンツ伝送、並びにコンテンツ鍵確認の手続き毎にTCPコネクションが確立される。
【0012】
具体的には、AKE手続きが成功すると、DTCP_Source機器とDTCP_Sink機器は、認証鍵Kauthを共有することができる。DTCP_Source機器はコンテンツ鍵の種となる種鍵Kxを生成し、認証鍵Kauthで暗号化してDTCP_Sink機器に送る。DTCP_Source機器は、乱数を用いてノンス(Nonce)Ncを生成して、KxとNcと暗号モードを表すE−EMIを基にコンテンツ鍵Kcを生成する。そして、DTCP_Sink機器から要求されているコンテンツを、コンテンツ鍵Kcを用いて暗号化し、暗号化コンテンツとノンスNcとE−EMIをヘッダに含んだパケットをTCPストリーム上に乗せてSink機器に送信する。一方、DTCP_Sink機器側では、TCPストリームからノンスNcとE−EMIを取り出すと、これらと鍵Kxを用いて同様にコンテンツ鍵Kcを算出し、暗号化コンテンツを復号することができる。
【0013】
このように、DTCP−IPは、DTCPに準拠した機器同士で認証を行ない、DTCP認証が完了した機器同士で鍵を共有し、コンテンツを伝送する際に暗号化及び復号をすることにより、伝送路の途中におけるコンテンツの盗聴、改竄を防ぐという、IPネットワーク上においても安全なコンテンツ伝送手法を提供することができる。
【0014】
例えば、HTTPの手続きに従ってコンテンツを要求する場合、DTCP_SourceがHTTPサーバとなり、DTCP_SinkがHTTPクライアントとなって、HTTPのためのTCP/IPコネクションが作成され、コンテンツの伝送を開始する。HTTPクライアントは、通常のHTTPと全く同様の動作手順によりHTTPサーバ上のコンテンツを要求する。これに対し、HTTPサーバは、要求通りのコンテンツをHTTPレスポンスとして返す。DTCP_Sourceは、DTCP_Sinkから要求されているコンテンツを、コンテンツ鍵Kcを用いて暗号化し、暗号化コンテンツからなるペイロードとノンスNcとE−EMI含んだヘッダからなるパケット(PCP:Protected Content Packet)をTCPストリーム上に乗せて送信する。
【0015】
また、長大なTCPストリーム全体に渡り同じ暗号鍵を使用し続けると、鍵が解読される危険は高くなる。このため、DTCP_Source機器は128MBのコンテンツ毎にノンスNcを1ずつ増加させてコンテンツ鍵Kcを更新する。そして、バイト・ストリームの途中でノンスNcが大幅に変更されることから、コンテンツ鍵の確認手続きが必要となり、DTCP_Sink機器は、DTCP_Source機器に対しノンスNcの確認のための手続きを行なう。
【0016】
また、著作権保護に対応したコンテンツ伝送システムでは、コンテンツ保護に関するコンテンツ属性を指定する必要がある。DTCP−IPでは、PCPヘッダ部に記述するE−EMI(Encryption Mode Indicator)と、Embeded CCI(Copy Control Information)という2つのメカニズムにより、コンテンツに付随したコピー制御情報の伝送を実現している。
【0017】
Embedded CCIは、暗号化するコンテンツ・ストリームの一部として(すなわちPCPペイロードに埋め込んで)伝送されるコピー制御情報である。多くのコンテンツ・フォーマットはストリームに付随してCCIを伝送するために割り当てられたフィールドを備えているが、CCIの定義やフォーマットはコンテンツ・フォーマット毎に特殊である。Embedded CCIは、“Copy Never”、“Copy One Generation”、“No More Copies”、“Copy Free”などとして解釈される。コンテンツ・ストリームをタンパリングすると誤った暗号解読を行なうことになるので、Embedded CCIの完全性を保証することができる。
【0018】
一方のE−EMIは、PCPヘッダでコンテンツ・ストリームに関するコピー制御情報を示すことにより、容易にアクセスできると同時にセキュリティを実現する。平文状態のPCPヘッダの特定のビット位置というアクセス容易な場所にE−EMIを配置することにより、機器は、コンテンツ・ストリームのCCIを即座に判断することができ、コンテンツ伝送フォーマットを復号してEmbedded CCIを抽出する必要がない。E−EMIは、デジタルVCRのように特殊なコンテンツ・フォーマットを認識したりデコードしたりすることができないビット・ストリーム記憶機器を実現する際に重要である。
【0019】
DTCP−IPに準拠する適正なSource機器は、コンテンツ・ストリームの特性に従って正しい暗号モードを選択し、これに基づいてE−EMIを設定する。また、適正なSink機器は、PCPヘッダ中のE−EMIで指定される正しい暗号解読モードを選択する。E−EMIをコンテンツ鍵Kcの生成に使用しているので、E−EMIがタンパリングされると、暗号化時と復号時のコンテンツ鍵Kcが一致しないことから、コンテンツの暗号解読を誤るので、セキュリティが保たれる。
【0020】
図31には、PCPヘッダの内部構造を図解している(例えば、非特許文献3を参照のこと)。このうち、E−EMI(Extended EMI)は、暗号モードを記述する4ビットのフィールドである。E−EMIの値はコピー制御情報の種類に対応する。ビット値定義を下表に示しておく(例えば、非特許文献4を参照のこと)。但し、同表で未使用となっている9つのE−EMI値は将来の拡張用に予備となっている。
【0021】
【表1】
【0022】
上述したように、PCPヘッダにコンテンツの暗号モード及びコピー制御情報を指定するE−EMIが記述されるが、コンテンツの保護を目的としたコピー制御情報としてはこれらのパラメータでは十分でない(すなわち4ビット長のE−EMIフィールドに必要なコピー制御情報を書ききれない)場合がある。例えば、コンテンツのアナログ出力制御に関するパラメータ(APS:AnalogProtection System)や、出力時の画サイズに関するパラメータ(ICT:Image Consstraint Token)などの出力制御情報は、DTCPではコピー制御情報の構成要素(付加的若しくは拡張的なコピー制御情報であり、本明細書では「超拡張コピー制御情報」とも呼ぶ)として扱われる。これらは、E−EMIに書き込めないため、Embedded CCIの一部としてPCPペイロード中に埋め込むより他ない。
【0023】
また、DTCPにおけるコピー制御機能の1つとして、単純にE−EMIに従ってコピーの可否を制御するのではなく、機器がコンテンツのフォーマットとEmbedded CCIを正しく認識できた場合(すなわち“cognizant”である場合)、Embedded CCIに従ってコンテンツの処理方法を制御するという“Cognizant Function”(Cognizant機能)を提供している。PCPヘッダ部から取り出したE−EMIと、このCognizant機能を用いてPCPペイロードから取り出したEmbedded CCIを照合する必要がある。Embedded CCIとEMIの関係を下表に示しておく。
【0024】
【表2】
【0025】
しかしながら、DTCP−IPでは、コンテンツ・ストリームの一部としてEmbedded CCIを伝送するとしか規定していない。現在のDTCP−IPでは、MPEGトランスポート・ストリームに関してEmbedded CCIに相当するDTCPディスクリプタを挿入するという規定(例えば、非特許文献5を参照のこと)の他には、Embedded CCIの構成方法に関する規定は存在しない。MPEGを含む多くのコンテンツ・フォーマットにおいて、ストリームに付随してCCIを伝送するためのフィールドが割り当てられているが、CCIの定義やフォーマットはコンテンツ・フォーマット毎に特殊すなわち区々になっているのが現状である。
【0026】
PCPペイロードにコピー制御情報を埋め込むことは、コンテンツ内にコピー制御情報を挿入することであるから、必然的にその記述方法はコンテンツ・フォーマットに依存し、フォーマット毎に区々になる。したがって、DTCP−IPに準拠してAVコンテンツを暗号化伝送するときには、DTCP_Source機器側ではフォーマット毎にコピー制御情報の記述方法を変えて伝送し、DTCP_Sink機器側ではフォーマット毎にコピー制御情報を解析するためのソフトウェア又はハードウェアを用意する必要があり、機器コストの増大を招来する。また、暗号化したPCPペイロードにコピー制御情報を埋め込むと、受信側では復号後でないとこれを取り出すことができないという問題もある。
【0027】
【非特許文献1】DTCP Specification Volume 1 Version 1.4 (Informational Version)http://www.dtcp.com/
【非特許文献2】DTCP Volume 1 Supplement E Mapping DTCP to IP, Version 1.1 (Informational Version)http://www.dtcp.com/
【非特許文献3】DTCP Volume1 Supplement E Mapping DTCP to IP Version1.1(Informational Version) 4.22 Modification to 6.6.3 Content Encryption Formats
【非特許文献4】DTCP Volume1 Supplement E Mapping DTCP to IP Version1.1(Informational Version) 4.7 Modification to 6.4.2 Encryption Mode Indicator(EMI)
【非特許文献5】DTCP Specification Volume1 Version1.4(Informational Version) Appendix B DTCP_Descriptor for MPEG Transport Streams
【発明の開示】
【発明が解決しようとする課題】
【0028】
本発明の目的は、DTCPに準拠した情報機器同士で暗号化コンテンツの伝送手続きを好適に実行することができる、優れたコンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することにある。
【0029】
本発明のさらなる目的は、伝送するコンテンツに関する属性情報並びにコピー制御情報をパケット内に挿入して好適に伝送することができる、優れたコンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することにある。
【0030】
本発明のさらなる目的は、コンテンツのフォーマットに依存しない共通の形式で属性情報並びにコピー制御情報をパケット内に挿入し、且つこれらの情報をセキュアに使用することができる、優れたコンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することにある。
【課題を解決するための手段】
【0031】
本発明は、上記課題を参酌してなされたものであり、その第1の側面は、コピー制御がなされたコンテンツを伝送するコンテンツ伝送装置であって、
コンテンツ伝送先の機器との間で認証手続きを行なう認証手段と、
コンテンツに関するコピー制御情報を記述した第1のコピー制御情報を処理する第1のコピー制御情報処理手段と、
コンテンツに関する第1のコピー制御情報以外の情報を含んだ第2のコピー制御情報を処理する第2のコピー制御情報処理手段と、
第1のコピー制御情報及び第2のコピー制御情報を含んだヘッダ部と、コンテンツを所定のコンテンツ鍵で暗号化したペイロードからなるパケットを生成して、コンテンツ伝送先の機器に伝送するコンテンツ伝送手段と、
を具備することを特徴とするコンテンツ伝送装置である。
【0032】
本発明は、IPネットワーク上で著作権保護が必要となる情報コンテンツを伝送する情報通信システムに関するものであり、特に、具体的には、DTCP−IPに準拠した情報通信機器の間で、相互認証及び鍵交換を経て共有した鍵を用いて暗号化コンテンツ伝送を安全に行なうコンテンツ伝送装置に関する。
【0033】
著作権の保護に対応したコンテンツ伝送システムにおいては、コンテンツを暗号化伝送する際に、コンテンツ保護に関するコンテンツ属性を指定する必要がある。例えばDTCP−IPでは、PCPヘッダ部に記述するE−EMI(Encryption Mode Indicator)と、PCPペイロード部すなわちコンテンツ・ストリーム内に埋め込むEmbeded CCI(Copy Control Information)という2つのメカニズムにより、コンテンツに付随したコピー制御情報の伝送を実現している。
【0034】
ところが、一部のコピー制御情報をペイロード部すなわちコンテンツ・ストリームに記載するという暗号化伝送方式では、記載方法がコンテンツのフォーマットに依存するため、コピー制御情報を作成並びに解読するソフトウェア又はハードウェアのモジュールをフォーマット毎に用意しなければならず、機器コストが増大するという問題がある。
【0035】
そこで、本発明では、一部のコピー制御情報をパケットのヘッダ部に記載し、それ以外のコピー制御情報をペイロード部に記載してコンテンツを暗号化伝送するという旧来のシステム環境下において、旧来通りのSource機器及びSink機器との互換性を保ちながら、(DTCP−IPで)要求されるコピー制御を実現するために必要となるコピー制御情報をすべてヘッダ部に記載するコンテンツ伝送方式を提案する。
【0036】
そして、コンテンツに関するコピー制御情報として第1のコピー制御情報と第2のコピー制御情報を定義する。そして、第1のコピー制御情報及び第2のコピー制御情報を含んだヘッダ部と、コンテンツを所定のコンテンツ鍵で暗号化したペイロードからなるパケットを生成して、コンテンツ伝送先の機器に伝送するようにする。
【0037】
ペイロード部に(一部の)コピー制御情報を埋め込む場合とは相違し、ヘッダ部にコピー制御情報を埋め込む場合には、コンテンツのフォーマットに依存せず、すべてのフォーマットに共通の形式でコピー制御情報を挿入することができる。したがって、Source機器側においてコピー制御情報を作成し、Sink機器側においてコピー制御情報を解析するためのソフトウェア又はハードウェアのモジュールをすべてのフォーマットで共通化することができ、機器コストを削減することができる。
【0038】
第1のコピー制御情報は、例えば、コンテンツのコピーの可否を規定するコピー制御情報に対応した暗号モードを含んでいる。また、第2のコピー制御情報は、例えばコンテンツの出力制御に関する情報を含んでいる。
【0039】
例えば、DTCPでは、アナログ出力制御に関するパラメータ(APS)や、出力時の画サイズに関するパラメータ(ICT)といった出力制御情報がコピー制御情報の構成要素となっている。本発明に係るコンテンツ伝送方式では、これらのビット長の短いE−EMIには書ききれない情報を、第2のコピー制御情報、すなわち超拡張コピー制御情報としてヘッダ部に記述する方法を規定する。
【0040】
また、ヘッダに第1のコピー制御情報を書き込むフィールドを設けたヘッダと、コンテンツ埋め込み型のコピー制御情報を埋め込んだコンテンツからなるペイロードで構成された形式のパケットを用いてコンテンツ伝送が行なわれるコンテンツ伝送システムに適用する場合には、第2のコピー制御情報に、ヘッダ部に埋め込まれた第2の制御情報の有効性を示すモード情報と、コンテンツ埋め込み型のコピー制御情報の代わりに第1のコピー制御情報を代用可能であることを示す代用性情報を含めるようにしてもよい。
【0041】
また、コンテンツのフォーマットの認識可能性に応じたコンテンツのコピー制御を実施するcognizant機能が提供されている伝送システムに適用した場合、前記第2のコピー制御情報処理手段は、ヘッダに第2のコピー制御情報として含まれるモード情報と、ペイロード中におけるコンテンツ埋め込み型のコピー制御情報の存在の有無の組み合わせに応じてcognizant機能を実現することができる。
【0042】
すなわち、ヘッダ部内の所定位置に挿入された第2のコピー制御情報フィールドの有効性に関して記述したモード情報や、本来はペイロード部に埋め込まれるコピー制御情報の代わりにヘッダ部に書き込まれるコピー制御情報で代用できることを示すSE(Substitute for Embedded CCI)情報も、超拡張コピー制御情報としてヘッダ部に記述する。このような第2のコピー制御情報をヘッダ部の一部として構成することにより、コンテンツのフォーマットに依存せずすべてのフォーマットに共通の形式でコピー制御情報を伝送することが可能になる。すなわち、暗号化ペイロードからEmbedded CCIを取り出してE−EMIと照合することなく、従来はEmbedded CCIとE−EMIの組み合わせにより指定していたコピー制御機能や、cognizant機能を実現することが可能である。
【0043】
また、伝送システムの規格により、ノンスを用いて生成されたコンテンツ鍵で伝送コンテンツの暗号化が行なわれ、且つヘッダには所定ビット長のノンスを伝送するためのフィールドが設けられている場合、ノンスを伝送するためのフィールド内に第2のコピー制御情報を埋め込んで、パケットを伝送することができる。
【0044】
具体的には、前記の所定ビット長よりも第2のコピー制御情報のビット数分だけ短い擬似ノンスを生成し、第2のコピー制御情報とこの擬似ノンスをビット連結してなるノンスを用いて生成されるコンテンツ鍵で伝送コンテンツを暗号化することができる。
【0045】
図31に示したように、PCPヘッダには、E−EMIとともにノンス情報フィールドが設けられている。E−EMIは4ビットしかないので、もはや第2のコピー制御情報を記載する余裕はない。他方、ノンスNcは、コンテンツを暗号化するコンテンツ鍵Kcを生成する基となる情報であり64ビットが割り当てられている。本発明の1つの実装形態として、旧来のPCPヘッダ内のノンス情報フィールドの上位8ビットを用いて超拡張コピー制御情報を記述し、残りの下位56ビットに通常通りに生成されるノンスNc’の値を書き込むようにすることができる。コンテンツ中でE−EMIが変わる度、また定期的にノンスNcは更新する。通常、更新する機会毎に擬似的ノンスNc’の値を単調に増大させるが(1ずつインクリメントしていく)、56ビットしか使用しなくても、桁あふれは実用上は1度しか起こらないので桁あふれビットを1ビット用意することで対応できる。
【0046】
このような場合、本発明に係るコンテンツ伝送方式に対応したSource機器及びSink機器は、旧来の64ビットのノンス情報フィールド中の上位8ビットを第2のコピー制御情報フィールドとして利用するとともに、第2のコピー制御情報が書き込まれた上位8ビットと、56ビット長の擬似的なノンスNc’のビット連結からなる64ビット全体をノンスNcとして用いてコンテンツ鍵Kcの生成を行なう。不正コピー目的で第2のコピー制御情報を改竄しても、ノンスNcを改竄することなり、結局はコンテンツを復号できなくなるので、セキュリティも維持される。
【0047】
一方、旧来通りのSink機器も、旧来の64ビットのノンス情報フィールド全体に書き込まれた値をノンスNcとして解釈する。この場合、上位8ビットにPCP−CCIが書き込まれることから、ノンスNcの値を変更した際に本来満たされるべき規則性が失われることから、本発明に係る伝送方式に対応していないSink機器がノンスNcの規則性を期待していた場合、いわゆるLegacy問題が発生する。
【0048】
Source機器側で旧来の64ビットのノンス情報フィールドを8ビットの第2のコピー制御情報フィールドと56ビットの擬似的なノンス情報フィールドがビット連結として使用した場合、第2のコピー制御情報が変化する度にLegacyのSink機器にとってはノンスNcの連続性が失われる。これに応答して、LegacyのSink機器はコンテンツ鍵確認手続を起動することになる。このような場合、Source機器側では、コンテンツ鍵確認要求に対し、56ビットの擬似的なノンスで検証するのではなく、該確認要求されているノンスを第2のコピー制御情報を埋め込んで構成される64ビットのノンスと比較して検証するようにする。そして、ノンスNcに異常がないことを示すレスポンス(ACCEPTED)を返すことによって、LegacyのSink機器は以降も障害なくコンテンツ受信処理を継続することができる。
【0049】
また、本発明に係る伝送方式に対応したSink機器においても、コンテンツ伝送元であるSource機器が本方式を適用しているかどうか、すなわち上位8ビットに第2のコピー制御情報が記載されているかどうかを特定しなければならず、Legacy Source機器に対するLegacy問題が発生する。
【0050】
そこで、本発明では、前記コンテンツ伝送手段が第1のコピー制御情報及び第2のコピー制御情報を含んだヘッダを付けてパケットを伝送するとき、前記認証手段は、コンテンツ伝送先の機器に送信するコマンド内にその旨を示す情報を記載して、伝送先の機器に通知するようにしている。すなわち、コンテンツ送信元となるSource機器が本発明に係るコンテンツ伝送方式に対応している場合、PCPヘッダ部に超拡張コピー制御情報を埋め込むことを示すフラグを相互認証手続(AKE)で交換する機器証明書の中に含めることによって、Sink機器はSource機器がLegacy機器でないことを認識することができる。あるいは、能力確認用のコマンドを使用するようにしてもよい。
【0051】
また、本発明の第2の側面は、コピー制御がなされたコンテンツを伝送するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
コンテンツ伝送先の機器との間で認証手続きを行なう認証手順と、
コンテンツに関するコピー制御情報を記述した第1のコピー制御情報を設定する第1のコピー制御情報設定手順と、
コンテンツに関する第1のコピー制御情報以外の情報を含んだ第2のコピー制御情報を設定する第2のコピー制御情報設定手順と、
第1のコピー制御情報及び第2のコピー制御情報を含んだヘッダと、コンテンツを所定のコンテンツ鍵で暗号化したペイロードからなるパケットを生成して、コンテンツ伝送先の機器に伝送するコンテンツ伝送手順と、
を実行させることを特徴とするコンピュータ・プログラムである。
【0052】
本発明の第2の側面に係るコンピュータ・プログラムは、コンピュータ・システム上で所定の処理を実現するようにコンピュータ可読形式で記述されたコンピュータ・プログラムを定義したものである。換言すれば、本発明の第2の側面に係るコンピュータ・プログラムをコンピュータ・システムにインストールすることによって、コンピュータ・システム上では協働的作用が発揮され、本発明の第1の側面に係るコンテンツ伝送装置と同様の作用効果を得ることができる。
【発明の効果】
【0053】
本発明によれば、DTCPに準拠した情報機器同士で暗号化コンテンツの伝送手続きを好適に実行することができる、優れたコンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することができる。
【0054】
また、本発明によれば、伝送するコンテンツに関する属性情報並びにコピー制御情報をパケット内に挿入して好適に伝送することができる、優れたコンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することができる。
【0055】
また、本発明によれば、コンテンツのフォーマットに依存しない共通の形式で属性情報並びにコピー制御情報をパケット内に挿入し、且つこれらの情報をセキュアに使用することができる、優れたコンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することができる。
【0056】
本発明によれば、DTCP−IPに準拠した暗号化コンテンツの伝送を行なう際に、Sink機器側で必要となるすべてのコピー制御情報をPCPヘッダ中に記載することができる。言い換えれば、コンテンツのフォーマットに依存せずに(すなわちすべてのフォーマットに共通の形式で)、コピー制御情報をコンテンツに付けて伝送することができる。そして、Source機器側においてコピー制御情報を作成し、Sink機器側においてコピー制御情報を解析するためのソフトウェア又はハードウェアのモジュールをすべてのフォーマットで共通化することにより、機器コストを削減することができる。
【0057】
また、必要となるすべてのコピー制御情報をPCPヘッダ中に記載することで、コンテンツのフォーマットに依存することなくコピー制御情報を伝送することができるので、DTCP−IPにおいて既に規定されているMPEGトランスポート・ストリームにおいても同様に適用することが可能である。
【0058】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
【発明を実施するための最良の形態】
【0059】
本発明は、TCP/IPなどのネットワーク上やファイル・システムからバイト・ストリームとして暗号データを受理して復号する情報通信システムに関するものであり、特に、TCPストリームのような長大なバイト・ストリームを途中で復号鍵を変更しながら暗号化通信を行なう情報通信システムに関する。かかるシステムの具体例は、DTCP機器の間で行なわれるHTTPプロトコルを利用したコンテンツ伝送である。以下、図面を参照しながら本発明の実施形態について詳解する。
【0060】
A.システム構成
DTCP−IPに従ったコンテンツ伝送は、コンテンツの要求を受理してコンテンツを送信するサーバとしてのSource機器と、コンテンツを要求し、コンテンツを受信し、再生若しくは記録するクライアントとしてのSink機器で構成される。図1には、本発明の一実施形態に係る情報通信システムの構成例を模式的に示している。
【0061】
図示の例では、Source機器とSink機器の各エンティティにより、DTCP−IP AKEシステムが構築されている。
【0062】
DTCP−IP に準拠した認証サーバであるSource機器とDTCP−IPに準拠した認証クライアントであるSink機器はネットワークを経由して接続されている。
【0063】
ここで言うネットワークには、Ethernet(登録商標)や、インターネット、その他のIPネットワークが含まれる。
【0064】
図2及び図3には、図1に示した情報通信システムにおいて、クライアント(すなわち、Sink機器)及びサーバ(すなわち、Source機器)として動作するコンテンツ伝送装置の、特に認証及びコンテンツ伝送に着目した機能構成をそれぞれ模式的に示している。Sink機器とSource機器は、インターネットなどのTCP/IPネットワーク上でコネクションを確立することができ、このコネクションを利用して、認証手続きやコンテンツ伝送手続きを実行することができる。
【0065】
図2に示すSink機器は、DTCP−IP規格に準拠しており、DTCP_Sinkとして動作する。図示のクライアント機器は、機能ブロックとして、DTCP−IP認証ブロックと、DTCP−IPコンテンツ受信ブロックと、コンテンツ再生/記録ブロックを備えている。
【0066】
DTCP−IP認証ブロックは、AKEブロックと、メッセージ・ダイジェスト生成ブロックと、コンテンツ復号ブロックを備えている。
【0067】
AKEブロックは、DTCP−IPにおけるAKE機構(DTCP_Sink側)を実現するブロックでる。このAKEブロックは後述のメッセージ・ダイジェスト生成ブロックから要求されたパラメータを渡す機能も備えている。
【0068】
メッセージ・ダイジェスト生成ブロックは、指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックである。メッセージ・ダイジェストを生成するアルゴリズムはあらかじめ用意されたアルゴリズムを指定することができる。あらかじめ用意されたアルゴリズムとして、例えばMD5やSHA−1といった一方向性ハッシュ関数に関するアルゴリズムが挙げることができる(SHA−1は、MD5と同様、MD4を改良したものに相当するが、160ビットのハッシュ値を生成するので、強度はMDシリーズを上回る)。
【0069】
メッセージ・ダイジェスト生成ブロックは、DTCP−IP認証ブロックの外に公開してはならないAKEブロックが保持するパラメータのメッセージ・ダイジェストを生成できるようにAKEブロックと密に配置され、AKEブロックへパラメータを要求して取得することが可能であり、そのパラメータ若しくは外部から与えられたパラメータのメッセージ・ダイジェストを作成することができる。
【0070】
コンテンツ復号ブロックは、サーバから受信した暗号化されたコンテンツ・データをAKEで交換した鍵Kxを用いてコンテンツの復号鍵Kcを算出し、暗号コンテンツを復号するブロックである。ここで復号されたコンテンツは、コンテンツ再生/記録ブロックへ渡される。
【0071】
コンテンツ再生/記録ブロックは、渡されたコンテンツを、再生モードの場合は再生を行ない、記録モードの場合は保存する。但し、コンテンツの記録動作は、コンテンツ伝送用のパケットPCP内に挿入されているコピー制御情報の規定に従う。
【0072】
DTCP−IPコンテンツ受信ブロックは、AKEを実施した後にSource機器とのコンテンツ伝送手続きを実行する処理モジュールである。図示の例では、DTCP−IPコンテンツ受信ブロックはHTTPクライアント・ブロックを持ち、HTTPクライアントとしてHTTPサーバへコンテンツを要求し、応答されたコンテンツをHTTPサーバから受信する。
【0073】
HTTPクライアント・ブロックは、HTTPリクエスト管理ブロックとHTTPレスポンス管理ブロックに分かれる。さらに、HTTPリクエスト管理ブロックは、HTTPリクエスト送信ブロックとHTTPリクエスト生成ブロックに分かれる。
【0074】
HTTPリクエスト生成ブロックは、送信するコンテンツ伝送要求(HTTPリクエスト)を生成する。ここで生成されたHTTPリクエストは、HTTPリクエスト送信ブロックによりサーバへ送信される。
【0075】
HTTPレスポンス管理ブロックは、HTTPレスポンス受信ブロックとHTTPレスポンス解釈ブロックに分かれる。サーバから返信されるHTTPレスポンスと暗号化されたコンテンツは、HTTP受信ブロックで受信される。ここで受信したHTTPレスポンスは、HTTPレスポンス解釈ブロックでチェックされる。ここでのチェックがOKの場合は受信した暗号化コンテンツをDTCP認証ブロック内のコンテンツ復号ブロックへ送る。また、このチェックがNGの場合は、エラー・レスポンスとしての処理を行なう。Source機器からのHTTPレスポンスは1つ以上のPCPからなる。
【0076】
DTCP−IP認証ブロックとDTCP−IPコンテンツ受信ブロックは、サーバ機器との間で個別のTCP/IPコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。
【0077】
また、図3に示すSource機器は、DTCP−IP規格に準拠しており、DTCP_Sourceとして動作する。サーバ機器は、機能ブロックとして、DTCP−IP認証ブロックと、DTCP−IPコンテンツ送信ブロックと、コンテンツ管理ブロックを備えている。
【0078】
DTCP−IP認証ブロックは、認証手続き実行手段に相当し、AKEブロックと、メッセージ・ダイジェスト生成ブロックと、コンテンツ暗号化ブロックを備えている。
【0079】
AKEブロックは、DTCP−IPにおけるAKE機構(DTCP_Source側)を実現するブロックである。このブロックは、後述のメッセージ・ダイジェスト生成ブロックから要求されたパラメータを渡す機能も備えている。AKEブロックは認証したDTCP_Sink機器に関する情報を認証した機器の数だけ保持し、それをクライアントからコンテンツが要求された際に認証済みのクライアントかどうかを判別するのに使用する。
【0080】
メッセージ・ダイジェスト生成ブロックは指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックである。メッセージ・ダイジェストを生成するアルゴリズムはあらかじめ用意されたアルゴリズムを指定できる。あらかじめ用意されたアルゴリズムとは、例えばMD5やSHA−1といった一方向性ハッシュ関数に関するアルゴリズムが挙げられる(同上)。
【0081】
メッセージ・ダイジェスト生成ブロックは、DTCP−IP認証ブロックの外に公開してはならないAKEブロックが保持するパラメータのメッセージ・ダイジェストを生成できるようにAKEブロックと密に配置され、AKEブロックへパラメータを要求して取得することが可能で、そのパラメータ若しくは外部から与えられたパラメータのメッセージ・ダイジェストを作成することができる。
【0082】
コンテンツ暗号化ブロックは、DTCP−IPコンテンツ送信ブロックの要求に応じてコンテンツ管理ブロックより読み出したコンテンツ・データを、AKEで交換した鍵Kxから生成したコンテンツ鍵Kcを用いて暗号化するブロックである。ここで復号されたコンテンツは、クライアントへ送信するために、DTCP−IPコンテンツ送信ブロックへ渡される。
【0083】
コンテンツ管理ブロックは、DTCP−IPの機構を用いて保護されるべきコンテンツを管理するブロックである。コンテンツ暗号化ブロックの読み出しに応じて、コンテンツのデータを渡す。
【0084】
DTCP−IPコンテンツ送信ブロックは、HTTPサーバ・ブロックを持ち、HTTPサーバとしてクライアントからのリクエストを受理し、要求に応じた処理を実行する。
【0085】
HTTPサーバ・ブロックは、HTTPリクエスト管理ブロックとHTTPレスポンス管理ブロックに分かれる。さらに、HTTPリクエスト管理ブロックは、HTTPリクエスト受信ブロックと、HTTPリクエスト解釈ブロックに分かれる。
【0086】
HTTPリクエスト受信ブロックは、クライアントからのHTTPリクエストを受信する。受信したHTTPリクエストはHTTPリクエスト解釈ブロックに送られ、チェックされる。HTTPリクエスト解釈ブロックにおけるチェックがOKの場合、HTTPリクエストの情報をDTCP−IP認証ブロックへ通知する。
【0087】
HTTPレスポンス管理ブロックは、HTTPレスポンス生成ブロックとHTTPレスポンス送信ブロックに分かれる。
【0088】
HTTPレスポンス生成ブロックは、HTTPリクエスト解釈ブロックでのチェックがOKの場合、暗号化されたコンテンツを返すためのHTTPレスポンスを作成する。HTTPレスポンスは1つ以上のPCPからなる。一方、HTTPリクエスト解釈ブロックでのチェックがNGの場合、エラーを返すためのHTTPレスポンスを作成する。
【0089】
HTTPレスポンス送信ブロックは、作成されたHTTPレスポンスを、要求元のクライアントへHTTPレスポンスを送信する。また、HTTPリクエスト解釈ブロックでのチェックがOKの場合には、HTTPレスポンス・ヘッダに続けて、DTCP−IP認証ブロック内のコンテンツ暗号化ブロックで暗号化したコンテンツを送信する。
【0090】
DTCP−IP認証ブロックとDTCP−IPコンテンツ送信ブロックは、Sink機器との間で個別のTCP/IPコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。
【0091】
なお、DTCP−Sink機器及びDTCP−Source機器のいずれもがDTCP−IP認証ブロック内に持つメッセージ・ダイジェスト生成ブロックは、DTCP−IP自体で規定される機能モジュールではなく、また本発明の要旨には直接関連しない。
【0092】
B.HTTPを利用したコンテンツ伝送
この項では、DTCP−IPに従ったコンテンツの伝送手順について説明する。図4には、DTCP_Source機器とDTCP_Sink機器の間でAKEに基づく鍵交換手続き、及び鍵交換により共有した鍵を利用した暗号化コンテンツ伝送を行なう仕組みを図解している。
【0093】
DTCP_SourceとDTCP_Sinkは、まず1つのTCP/IPコネクションを確立し、機器同士の認証を行なう。この認証を、DTCP認証若しくはAKE(Authenticationand Key Exchange)と言う。DTCP準拠機器には、DTLA(前述)により発行された機器証明書が埋め込まれている。DTCP認証手続きでは、互いが正規のDTCP準拠機器であることを確かめた後、認証鍵KauthをDTCP_Source機器とDTCP_Source機器で共有することができる。
【0094】
AKE手続きが成功すると、DTCP_Source機器はコンテンツ鍵Kcの種となる種鍵Kxを生成し、認証鍵Kauthで暗号化してDTCP_Sink機器に送る。種鍵Kxは、コンテンツ伝送時にコンテンツを暗号化するためのコンテンツ鍵Kcを生成するために使用される。そして、DTCP準拠の機器間でAKEによる認証及び鍵交換手続きが済んだ後、DTCP_Sink機器はDTCP_Source機器上のコンテンツを要求する。DTCP_Source機器は、CDS(ContentDirectory Service)などを通じてDTCP_Sink機器にDTCP_Source機器上のコンテンツへのアクセス先を示すコンテンツ場所をあらかじめ伝えることができる。DTCP_Sinkがコンテンツを要求するとき、HTTPやRTPなどのプロトコルを利用することができる。
【0095】
図4に示すようにHTTPの手続きに従ってコンテンツを要求する場合、DTCP_SourceがHTTPサーバとなり、DTCP_SinkがHTTPクライアントとなって、コンテンツの伝送を開始する。ちなみに、RTPによる伝送を要求するとき、DTCP_SourceがRTPSenderとなり、DTCP_SinkがRTP Receiverとなってコンテンツの伝送を開始する。HTTPでコンテンツ伝送を行なう際、DTCP認証のためのTCP/IPコネクションとは別に、HTTPのためのTCP/IPコネクションがHTTPクライアントより作成される(すなわち、DTCP_Source機器とDTCP_Sink機器はそれぞれ、AKE手続き用とコンテンツ伝送用に個別のソケット(IPアドレスとポート番号の組み合わせ)を持つ)。そして、HTTPクライアントは、通常のHTTPと全く同様の動作手順によりHTTPサーバ上のコンテンツを要求する。これに対し、HTTPサーバは、要求通りのコンテンツをHTTPレスポンスとして返す。
【0096】
HTTPレスポンスとして伝送されるデータは、HTTPサーバすなわちDTCP_Source機器がAKE認証をした後に共有した鍵を用いてコンテンツを暗号化したデータとなっている。具体的には、DTCP_Source機器は、乱数を用いてノンスNcを生成して、種鍵KxとノンスNcと暗号モードを表すE−EMIを基にコンテンツ鍵Kcを生成する。そして、DTCP_Sink機器から要求されているコンテンツを、コンテンツ鍵Kcを用いて暗号化し、暗号化コンテンツからなるペイロードとノンスNcとE−EMIを含んだヘッダからなるパケットであるPCP(Protected Content Packet)をTCPストリーム上に乗せて送信する。そして、IPプロトコルは、TCPストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダ部を付加したIPパケットにし、指定されたIPアドレス宛てに届ける。
【0097】
DTCP_Sink機器側では、DTCP_Source機器からの各IPパケットを受信すると、これをTCPストリームに組み立てて、送信されたPCPを取り出す。そして、ストリームからノンスNcとE−EMIを取り出すと、これらと種鍵Kxを用いて同様にコンテンツ鍵Kcを算出し、暗号化コンテンツを復号することができる。そして、復号化した後の平文のコンテンツに対し再生若しくは記録などの処理を実施することができる。そして、HTTPプロトコルを利用したコンテンツ伝送が終了すると、例えばDTCP−Sink機器側から、使用したTCPコネクションを適宜切断する。
【0098】
また、長大なTCPストリーム全体に渡り同じ暗号鍵を使用し続けると、鍵が解読される危険は高くなる。このため、DTCP−IPでは、Source機器は128MB毎にノンスNcすなわちコンテンツ鍵Kcを更新する(1ずつインクリメントする)よう取り決められている。バイト・ストリーム中で、同じノンスNcから生成されたコンテンツ鍵Kcを用いて暗号化されたデータの範囲は、同じ鍵を用いて復号することができる復号化単位となる。
【0099】
DTCP−IPではさらにコンテンツ鍵の確認手続きが必要となる。すなわち、DTCP_Sink機器は、コンテンツ伝送用のTCPコネクションとは別に、コンテンツ鍵の確認用のTCPコネクションをさらに確立し、DTCP_Source機器に対しコンテンツ鍵確認のための手続きを行なう。DTCP_Sink機器は、コンテンツ鍵の確認が必要になると、適宜このTCPコネクションを確立する。例えば、DTCP−IP Volume 1 Supplement E.8.6には、コンテンツ鍵の確認手続きとして“Content Key Confirmation”を規定している。これによれば、Sink機器は、CONT_KEY_CONF subfunctionを用いて、現在のノンスNcに関連付けられたコンテンツ鍵の確認を行なう。
【0100】
既に述べたように、DTCP−IPでは、ノンスNcを含んだヘッダと、暗号化コンテンツからなるペイロードで構成される、PCPというパケット形式でコンテンツ伝送が行なわれる。
【0101】
図5には、PCPのデータ構造を模式的に示している。PCPヘッダは平文であり、ノンスNcが含まれている。また、PCPペイロードはノンスNcで決まるコンテンツ鍵Kcで暗号化されたコンテンツ(但し、コピー制御情報として“copy−free”が指定されているコンテンツは暗号化不要)で構成される。ここで、PCPペイロードは、常に16バイトの倍数になるように、必要に応じて暗号化前にpaddingが行なわれる。また、コンテンツの安全のため、定期的にノンスNcすなわちコンテンツ鍵Kcを更新するが、その時点でもPCPは仕切られる(コンテンツ鍵Kcを更新しなくても複数のPCPに仕切ることは可能)。また、protected_content_lengthの値が16の整数倍でないときは、コンテンツに1〜15バイトのパディングが付く。ノンスNcの更新に伴い、コンテンツ鍵確認手続を起動するのは上述した通りである。ちなみに、HTTPレスポンスは1つ以上のPCPからなり、RTPペイロードは1つのPCPからなる。図6には、PCPをパディングする様子を示している。
【0102】
C.コピー制御情報の伝送
DTCP−IPのように著作権の保護を目的としたコンテンツ伝送システムにおいては、コンテンツを暗号化伝送する際に、コンテンツ保護に関するコンテンツ属性を指定する必要がある。
【0103】
DTCP−IPでは、PCPヘッダにPCPペイロードの暗号モード及びコピー情報を指定する4ビットのE−EMIフィールドを設けることと、PCPペイロードすなわちコンテンツ・ストリームの一部としてコピー制御情報Embedded CCIを伝送することが規定されている。しかしながら、Embedded CCIに関しては、MPEGトランスポート・ストリームについてのみDTCPディスクリプタとして記述することが規定されているのみで、Embedded CCIの定義やフォーマットはコンテンツ・フォーマット毎に区々になっているのが現状である。このため、Embedded CCIの記述方法がコンテンツ・フォーマットに依存することとなり、コピー制御情報を作成並びに解読するソフトウェア又はハードウェアのモジュールをフォーマット毎に用意しなければならず、機器コストが増大するという問題がある。
【0104】
そこで、本実施形態では、E−EMIをPCPヘッダに記載するとともに、ヘッダには書ききれないコピー制御情報をEmbedded CCIとしてPCPペイロード埋め込んでコンテンツを暗号化伝送するという旧来のDTCP−IPシステムにおいて、旧来通り(すなわちLegacy)のSource機器及びSink機器との互換性を保ちながら、必要となるコピー制御情報をすべてPCPヘッダに記載するコンテンツ伝送方式を採用している。
【0105】
PCPヘッダ部にコピー制御情報を埋め込む場合、コンテンツのフォーマットに依存しないことから、すべてのコンテンツ・フォーマットに共通の形式でコピー制御情報を伝送することが可能になる。この結果、Source機器側においてコピー制御情報を作成し、Sink機器側においてコピー制御情報を解析するためのソフトウェア又はハードウェアのモジュールをすべてのフォーマットで共通化することにより、機器コストを削減することができる。
【0106】
図31を参照しながら既に説明したように、PCPヘッダには、E−EMIとともにノンス情報フィールドが設けられている。E−EMIは4ビットしかないので、もはやそれ以外のコピー制御情報(すなわち超拡張コピー制御情報)を記載する余裕はない。他方、ノンスNcは、コンテンツを暗号化するコンテンツ鍵Kcを生成する基となる情報であり64ビット長のフィールドがヘッダ内で割り当てられている。コンテンツ中でE−EMIが変わる度、また定期的にノンスNcは更新する。通常、更新する機会毎にノンスNcの値を単調に増大させる(1ずつインクリメントしていく)ため、64ビットを必要としない。そこで、本実装形態では、旧来のPCPヘッダ内のノンス情報フィールドの一部の領域を用いて超拡張コピー制御情報を伝送するようにしている。
【0107】
本明細書では、E−EMI以外にPCPヘッダに挿入される超拡張コピー制御情報のことを“PCP−CCI”と呼ぶことにする。図7には、本実施形態で採用するPCPヘッダのデータ構造を示している。同図の例では、旧来のPCPヘッダ内のノンス情報フィールドの上位8ビットを用いてPCP−CCIを記述し、残りの下位56ビットに通常通り生成するノンスNc’の値を書き込むようにしている。64ビットのノンス情報Ncフィールドの上位8ビットにPCP−CCIを埋め込んでも、コンテンツ鍵Kcの安全性は残りの56ビットで実用に耐えられる。
【0108】
図7からも分るように、PCPヘッダ部の基本的な構造やサイズは旧来のものと変更されない。この場合、本実施形態に係るコンテンツ伝送方式に対応したSource機器及びSink機器は、旧来の64ビットのノンス情報フィールド中のうち上位8ビットをPCP−CCIフィールドとして利用するとともに、PCP−CCI情報が書き込まれた上位8ビットと擬似的なノンスNc’の値が書き込まれた56ビットのビット連結からなる64ビット全体をノンスNcとして用いてコンテンツ鍵Kcの生成を行なう。この場合、不正コピー目的でPCP−CCIを改竄しても、ノンスNcを改竄することとなり、結局はコンテンツを復号できなくなるので、セキュリティも維持される。
【0109】
一方、旧来通りの機器も、旧来の64ビットのノンス情報フィールド全体に書き込まれた値をノンスNcとして解釈する。この場合、上位8ビットにPCP−CCIが書き込まれることからPCP−CCIがストリームの途中で変化した場合にはノンスNcの値の連続性が失われ、本発明に係る伝送方式に対応していないSink機器にとって、いわゆるLegacy問題が発生する。また、本発明に係る伝送方式に対応したSink機器においても、PCPすなわちコンテンツ伝送元であるSource機器が本方式を適用しているかどうか、すなわち上位8ビットにPCP−CCIが記載されているかどうかを特定しなければならず、同様にLegacy問題が発生する。但し、この問題の解決方法については後述に譲る。
【0110】
図8には、PCP−CCIフィールドのフォーマット構成例を示している。
【0111】
DTCPでは、アナログ出力制御に関する2ビットのパラメータ(APS)や、出力時の画サイズに関する1ビットの情報フラグ(ICT)といった出力制御情報がコピー制御情報の構成要素となっている。これらE−EMIには書ききれない情報がPCP−CCI内に割り当てられている。また、Ignoreビットは、下位56ビットの擬似的なNc’がカウントアップした結果、値が繰り上がってもPCP−CCIの他のフィールドに影響が出ないようにするためのフィールドである。Source機器は、Ignoreビットの初期値として“0”を設定し、擬似的なノンスNc’がカウントアップした結果、値が繰り上がった場合に“1”となる。
【0112】
また、PCP−CCIフィールドの有効性を記述した2ビットの情報フィールド“Mode”や、E−EMIと本来のEmbedded CCIの代用可能性に関する1ビットの情報フラグ“SE(Substitute for Embedded CCI)”も、PCP−CCI内に割り当てられている。このようなPCP−CCIをヘッダ部の一部として構成することにより、コンテンツのフォーマットに依存せずすべてのフォーマットに共通の形式でコピー制御情報を伝送することが可能になる。そして、暗号化ペイロードにEmbedded CCIが含まれていない場合でも、従来はEmbedded CCIとEMIの組み合わせにより指定していたコピー制御機能、つまりにcognizant機能を実現することが可能である。
【0113】
Modeビット・フィールドはPCP−CCIフィールドの意味若しくは有効性を表す。Mode=00bのときはPCP−CCIフィールドが情報を持たないことを表す。また、Mode=01bのときはペイロードがAudio/Visualコンテンツであることを表し、Mode=10bのときはペイロードがType1 Audioコンテンツであることを表す(例えば、DTCP Specification Volume 1 Version1.4(Informational Version) Appendix A Additional Rules for Audio Applicationsを参照のこと)。Mode=11bはReservedとする。また、Mode=01b又はMode=10bのときはAPS、ICTビットの意味を持ち、そのビットの意味はDTCPの規定(非特許文献5を参照のこと)に準ずる。
【0114】
図9には、Sink機器がModeビット・フィールドに基づいてPCP−CCIフィールドの意味を識別するための処理手順をフローチャートの形式で示している。
【0115】
Mode=00b、すなわちPCP−CCIフィールドが情報を持たない場合には(ステップS1のYes)、さらに復号したコンテンツを検査する。そこで、Sink機器が識別可能なEmbedded CCIを検出できなければ(ステップS4のNo)、Non Cognizantとして処理する(ステップS11)。一方、Embedded CCIが検出できた場合には(ステップS4のYes)、検出されたEmbedded CCIがAudio/Visual用のCCIかどうかを判別する(ステップS5)。そして、Audio/Visual用であれば、Audio/Visual Cognizantとして処理し(ステップS10)、それ以外であればAudio Cognizantとして処理する(ステップS9)。
【0116】
また、Mode=01bすなわちPCP−CCIフィールドがAudio/Visualの情報であれば(ステップS2のYes)、さらに復号したコンテンツを検査する。そこで、Sink機器が識別可能なEmbedded CCIを検出できなければ(ステップS6のNo)、Non Cognizantとして処理する(ステップS11)。一方、Embedded CCIを検出できた場合には、Audio/Visual Cognizantとして処理する(ステップS10)。
【0117】
また、Mode=10bすなわちPCP−CCIフィールドがAudio Type1の情報であれば(ステップS3のYes)、さらに復号したコンテンツを検査する。Sink機器が識別可能なEmbedded CCIを検出できなければ(ステップS7のNo)、Non Cognizantとして処理する(ステップS11)。一方、Embedded CCIを検出できた場合には、Audio Cognizantとして処理する(ステップS9)。
【0118】
また、Modeが上記以外の値すなわち11bのときは、Reservedとする(ステップS8)。
【0119】
図9には、Modeビット・フィールドに基づいてPCP−CCIフィールドの意味を識別するための処理手順を示したが、その変形例として、Modeビット・フィールドとSEビット・フラグの組み合わせに基づいてPCP−CCIフィールドの意味を識別することができる。図10にはこの場合の処理手順をフローチャートの形式で示している。
【0120】
Mode=00b、すなわちPCP−CCIフィールドが情報を持たない場合には(ステップS21のYes)、さらに復号したコンテンツを検査する。そこで、Sink機器が識別可能なEmbedded CCIを検出できなければ(ステップS24のNo)、Non Cognizantとして処理する(ステップS31)。一方、Embedded CCIが検出できた場合には(ステップS24のYes)、検出されたEmbedded CCIがAudio/Visual用のCCIかどうかを判別する(ステップS25)。そして、Audio/Visual用であれば、Audio/Visual Cognizantとして処理し(ステップS30)、それ以外であればAudio Cognizantとして処理する(ステップS29)。
【0121】
また、Mode=01bすなわちPCP−CCIフィールドがAudio/Visualの情報であれば(ステップS22のYes)、さらにSEビット・フラグをチェックする。ここで、SE=1bであれば(ステップS32のYes)、Audio/Visual Cognizantで処理するとともに、E−EMIでEmbedded CCIを代用する(ステップS34)。
【0122】
また、Mode=01bで(ステップS22のYes)、且つSE=1bでなければ(ステップS32のNo)、さらに復号したコンテンツを検査する。そこで、Sink機器が識別可能なEmbedded CCIを検出できなければ(ステップS26のNo)、Non Cognizantとして処理する(ステップS31)。一方、Embedded CCIを検出できた場合には、Audio/Visual Cognizantとして処理する(ステップS30)。
【0123】
また、Mode=10bすなわちPCP−CCIフィールドがAudio Type1の情報であれば(ステップS23のYes)、さらにSEビット・フラグをチェックする。ここで、SE=1bであれば(ステップS33のYes)、Audio Cognizantで処理するとともに、E−EMIでEmbedded CCIを代用する(ステップS35)。
また、Mode=10bで(ステップS23のYes)、且つSE=1bでなければ(ステップS33のNo)、さらに復号したコンテンツを検査する。そして、Sink機器が識別可能なEmbedded CCIを検出できなければ(ステップS27のNo)、Non Cognizantとして処理する(ステップS31)。一方、Embedded CCIを検出できた場合には、Audio Cognizantとして処理する(ステップS29)。
【0124】
また、Mode=10bで(ステップS23のYes)、且つSE=1bでなければ(ステップS33のNo)、さらに復号したコンテンツを検査する。そして、Sink機器が識別可能なEmbedded CCIを検出できなければ(ステップS27のNo)、Non Cognizantとして処理する(ステップS31)。一方、Embedded CCIを検出できた場合には、Audio Cognizantとして処理する(ステップS29)。
【0125】
また、Modeが上記以外の値すなわち11bのときは、Reservedとする(ステップS28)。
【0126】
また、SE=1bのときはコンテンツにEmbedded CCIが含まれておらず、E−EMIフィールドでEmbedded CCIを代用することを表す。図11には、Modeビット・フィールド及びSEビット・フラグの値の組み合わせに基づいてE−EMIをEmbedded CCIとして代用することが可能かどうかを判別するための処理手順をフローチャートの形式で示している。
【0127】
Mode=00bであれば、PCP−CCIフィールドが情報を持たず(ステップS41のYes)、E−EMIをEmbedded CCIとして代用することができない(ステップS46)。
【0128】
Mode=01bすなわちPCP−CCIフィールドがAudio/Visual情報である場合(ステップS42)、並びに、Mode=10bすなわちPCP−CCIフィールドがAudio情報である場合には(ステップS43)、さらにSEビットのフラグ値を確認する(ステップS44)。
【0129】
ここで、SEフラグがセットされていれば、E−EMIをEmbedded CCIとして代用できると判断する(ステップS45)。また、SEフラグがセットされていなければ、E−EMIをEmbedded CCIとして代用できないと判断する(ステップS46)。
【0130】
また、Modeが上記以外の値すなわち11bのときは、Reservedとする(ステップS46)。
【0131】
D.Legacy問題の解決
上述した実施形態では、コピー制御情報をパケットのヘッダ部とペイロード部(すなわちコンテンツ・ストリーム)に分けて記載する方法が採用されている暗号化伝送方式において、PCPヘッダ内のノンス情報フィールドの上位8ビットを用いてPCP−CCIを記述し、残りの下位56ビットに擬似的なノンスNc’を書き込むようにすることで、(DTCP−IPで)要求されるコピー制御を実現するために必要となるコピー制御情報をすべてヘッダ部に記載するようにした。この場合、ヘッダ部にはコンテンツのフォーマットに依存せず、すべてのフォーマットに共通の形式でコピー制御情報を挿入することができるので、コピー制御情報を作成し解析するためのソフトウェア又はハードウェアのモジュールをすべてのフォーマットで共通化することができ、機器コストを削減することができる。
【0132】
ところが、LegacyのSink機器の場合、64ビットのノンス情報フィールド全体に書き込まれた値をノンスNcとして解釈することから、上位8ビットにPCP−CCIが書き込まれると、PCP−CCIが変更されたときにノンスNcの値の連続性が失われることになり、コンテンツ鍵確認手続を起動する、というLegacy問題が発生する。また、本発明に係る伝送方式に対応したSink機器においても、コンテンツ伝送元であるSource機器が本方式を適用しているかどうか、すなわちPCPヘッダ中にPCP−CCIが記載されているかどうかを特定しなければならず、同様にLegacy問題が発生する。この項ではこれらのLegacy問題の解決方法について説明する。
【0133】
図12には、LegacyのSource機器とSink機器間でPCPを伝送する仕組みを図解している。
【0134】
Source機器側では種鍵Kxを生成すると、AKE手続を経てSink機器との間で種鍵Kxを共有する。
【0135】
また、Source機器は、上位層アプリケーションから伝送用のコンテンツが供給されると、E−EMI設定部は、コンテンツ・ストリームに関連付けられたコピー制御情報に従って正しい暗号モードを選択し、これに基づいてE−EMIを設定する。また、常に16バイトの倍数となるようにパディングを行ない、PCPデータ・バッファに一時格納する。
【0136】
コンテンツ鍵生成部は、種鍵KxとE−EMIと、ノンス生成部が乱数生成などにより生成した64ビット長のノンスNcに所定の演算処理を施してコンテンツ鍵Kcを生成する。ノンス生成部は、定期的にノンスNcを1ずつインクリメントするので、これに応じてコンテンツ鍵Kcも定期的に更新されることになる。
【0137】
AES−CBC(Advances Encryption Standard−Cipher Block Chainng)暗号化部は、PCPデータ・バッファからパディングされたPCPペイロードを順次取り出し、現在のコンテンツ鍵Kcで暗号化処理を施す。
【0138】
PCPヘッダ付加部は、E−EMI設定部で設定されたE−EMIを含んだPCPヘッダを生成し、これを暗号化されたPCPペイロードの先頭に取り付けてPCPを完成する。このときのPCPヘッダのデータ・フォーマットは図31に示した通りである。そして、コンテンツ要求元としてのSink機器から要求されるHTTP又はRTPなどのプロトコルに従ってPCPを送出する。
【0139】
一方、Sink機器側では、Source機器とのAKE手続を経て種鍵Kxを共有する。
【0140】
また、HTTP又はRTPなどのプロトコルに従ってSource機器からPCPを受信すると、まずPCPヘッダ抽出部がPCPヘッダとPCPペイロードに分離する。そして、PCPヘッダからはノンスNcやE−EMIが取り出される。
【0141】
コンテンツ鍵生成部は、種鍵KxとPCPヘッダから取り出されたE−EMIとノンスNcに所定の演算処理を施してコンテンツ鍵Kcを生成する。コンテンツ鍵確認部はノンスNcの連続性を検査し、不連続を検出した場合はコンテンツ鍵確認手続を起動する。
【0142】
AES−CBC暗号解読部は、PCPペイロードに対し、現在のコンテンツ鍵Kcで暗号解読処理を施す。解読後のPCPペイロードはPCPデータ・バッファに一時格納され、パディングされたデータを取り除いて、元のコンテンツが再現される。Embedded CCI検出部は、再現されたコンテンツを検査し、Embedded CCIを検出する。
【0143】
また、図13には、PCP−CCIをPCPヘッダに埋め込む伝送方式を適用したSource機器とSink機器間でPCPを伝送する仕組みを図解している。
【0144】
Source機器側では種鍵Kxを生成すると、AKE手続を経てSink機器との間で種鍵Kxを共有する。
【0145】
また、Source機器は、上位層アプリケーションから伝送用のコンテンツが供給されると、E−EMI/PCP−CCI設定部は、コンテンツ・ストリームに関連付けられたコピー制御情報に従って正しい暗号モードを選択し、これに基づいてE−EMIを設定し、さらにPCP−CCIを設定する(PCP−CCI中のModeビット・フィールド並びにSEビット・フラグの設定方法については非特許文献5を参照されたい)。PCP−CCIは8ビット長であり、そのデータ・フォーマットは図8に示した通りである。また、常に16バイトの倍数となるようにパディングを行ない、PCPデータ・バッファに一時格納する。
【0146】
擬似ノンスNc’生成部は、乱数生成などにより56ビット長の擬似的なノンスNc’を生成する。ノンスNc生成部は、擬似ノンスNc’の上位にPCP−CCIをビット連結して、64ビット長のノンスNcを作成する。
【0147】
コンテンツ鍵生成部は、種鍵KxとE−EMIと、ノンス生成部が作成した64ビット長のノンスNcに所定の演算処理を施してコンテンツ鍵Kcを生成する。ノンスNc生成部は、定期的にノンスNcを1ずつインクリメントするので、これに応じてコンテンツ鍵Kcも定期的に更新されることになる。但し、PCP−CCI情報が変化すると、擬似的なノンスNc’部分は連続的であっても、64ビット全体で扱われるノンスNcの連続性は失われる。
【0148】
AES−CBC暗号化部は、PCPデータ・バッファからパディングされたPCPペイロードを順次取り出し、現在のコンテンツ鍵Kcで暗号化処理を施す。
【0149】
PCPヘッダ付加部は、E−EMI設定部で設定されたE−EMIを含んだPCPヘッダを生成し、これを暗号化されたPCPペイロードの先頭に取り付けてPCPを完成する。このときのPCPヘッダのデータ・フォーマットは図7に示した通りである。そして、コンテンツ要求元としてのSink機器から要求されるHTTP又はRTPなどのプロトコルに従ってPCPを送出する。
【0150】
一方、Sink機器側では、Source機器とのAKE手続を経て種鍵Kxを共有する。
【0151】
また、HTTP又はRTPなどのプロトコルに従ってSource機器からPCPを受信すると、まずPCPヘッダ抽出部がPCPヘッダとPCPペイロードに分離する。そして、PCPヘッダからはノンスNcやE−EMI及びPCP−CCIが取り出される。
【0152】
ノンスNc取得部は、PCPヘッダ中の64ビット長のノンス情報を取得する。コンテンツ鍵確認部は、ノンスNcの下位56ビットの連続性を検査し、不連続を検出した場合はコンテンツ鍵確認手続を起動する。
【0153】
コンテンツ鍵生成部は、種鍵KxとPCPヘッダから取り出された64ビット長のノンスNcに所定の演算処理を施してコンテンツ鍵Kcを生成する。
【0154】
また、PCP−CCI取得部は、ノンスNc取得部から64ビット長のノンス情報フィールドのうち上位8ビットをPCP−CCIとして取得する。そして、PCP−CCI中のModeビット・フィールド並びにSEビット・フラグのビット値及びEmbedded CCI検出部の検出結果に基づいて、図10に示した手順に従い、コンテンツ・フォーマットの認識(Cognizant)並びにE−EMIのEmbedded CCI代用性を決定する。
【0155】
AES−CBC暗号解読部は、PCPペイロードに対し、現在のコンテンツ鍵Kcで暗号解読処理を施す。解読後のPCPペイロードはPCPデータ・バッファに一時格納され、パディングされたデータを取り除いて、元のコンテンツが再現される。Embedded CCI検出部は、再現されたコンテンツを検査し、Embedded CCIを検出する。
【0156】
ここで、PCP−CCIは平文の状態でPCPヘッダに記述されることから、PCPペイロードに埋め込んで暗号化する場合に比べると改竄が容易になる。しかしながら、PCP−CCIはノンスNcの上位8ビットを構成することから、これを改竄することは、ノンスNcすなわちコンテンツ鍵Kcをも改竄することとなり、結局はコンテンツを復号できなくなるので、セキュリティも維持される。
【0157】
図14には、図12に示したLegacyのSource及びSink機器と、図13に示した新方式のSource及びSink機器が混在するコンテンツ伝送環境下においてLegacy問題が発生する様子を模式的に示している。
【0158】
図12に示したSource及びSink機器間でのPCPの伝送、並びに図13に示したSource及びSink機器間でのPCPの伝送は問題なく処理されることは上述した通りである。
【0159】
これに対し、新方式のSource機器が送出するPCPヘッダにPCP−CCIを埋め込んだPCP(New PCP with PCP−CCI)をLegacyのSink機器が受信したとき、上位8ビットにPCP−CCIが書き込まれることによりノンスNcの値の連続性が失われるので(例えばPCP−CCI情報が変化したとき)、コンテンツ鍵確認手続を起動する、という第1のLegacy問題が発生する。
【0160】
また、PCPヘッダにPCP−CCIを埋め込んだPCP(New PCP with PCP−CCI)に対応したSink機器の場合、コンテンツの要求先であるSource機器がLegacy又は新方式のいずれであるかを正しく識別しなければならないという第2のLegacy問題が発生する。識別を誤ると、PCPヘッダに埋め込まれているPCP−CCIを読み取ることができない、あるいは64ビットのノンス情報フィールドの上位8ビットを誤ってPCP−CCIと認識してしまうことになる。
【0161】
第1のLegacy問題に関しては、コンテンツ鍵確認手続は起動されるが、Source機器側では、コンテンツ鍵確認要求に対し、ノンスNcに異常がないことを示すレスポンス(ACCEPTEDコマンド)を返すので、LegacyのSink機器は以降も障害なくコンテンツ受信処理を継続することができ、実用上の問題は発生しない。
【0162】
DTCP−IP Volume 1 Supplement SectionV1SE.8.6には、Content Key Confirmationについて規定している。これによれば、Sink機器は、コンテンツ・ストリーム毎に、最も新しく受信したPCPのノンスNcの値を確認し、さらに動的に変更される後続のノンスについても2分間隔で再確認しなければならない(但し、Sink機器がノンスを初期確認した後に後続のノンスNcの値が単調に増大する連続的な数値であることを監視し確認する場合には、周期的なコンテンツ鍵確認の手続きを省略することができる)。Sink機器は、CONT_KEY_CONF subfunctionを用いて、現在のノンスNcに関連付けられたコンテンツ鍵の確認を行なうことができる。
【0163】
各コンテンツ・ストリームにおいて、Sink機器は、未確認の初期ノンスを取得すると、当該コンテンツ・ストリームに関して暗号化コンテンツの復号を終了しなければならなくなる前に、コンテンツ鍵の確認を再試行する猶予期間が1分間だけ与えられる。そして、Sink機器は、この猶予期間を利用してノンスNcの確認に成功すると、暗号化コンテンツの復号動作を終了することなく継続することができる。
【0164】
図15には、コンテンツ鍵確認のためのSink機器とSource機器間の手続きを示している。但し、Rは64ビット値で、初期は乱数であるが、後続の試行では1 mod 264でインクリメントするとともに、以下の通りとする。
【0165】
MX=SHA1(Kx||Kx)
MAC3A=MAC3B=[SHA1(MX+NcT+R)]msb80
MAC4A=MAC4B=[SHA1(MX+NcT+R)]lsb80
(上式で、“+”はmod264の加算を意味するために使用される。)
【0166】
図示のコンテンツ確認手続きでは、Sink機器は、CONT_KEY_CONFコマンドにおいて、検査用のノンスNcTをSource機器に送る。
【0167】
Source機器側では、CONT_KEY_CONFコマンドを受信すると、検査用のノンスNcTを取り出して、現在のノンスNcと比較する。そして、現在のノンスNcがNcTとNcT+5の範囲にあるときには検査用のノンスNcTが有効であることを確認する。検査用のノンスNcTが有効であることを確認できたときには、さらにMAC3AとMAC3Bが等しいかどうかに基づいてコンテンツ鍵の確認を行なう。そして、コンテンツ鍵が正しかったことを示すACCEPTEDレスポンス、又は正しくなかったことを示すREJECTEDレスポンスのいずれかをSink機器に返す。
【0168】
Sink機器側では、Source機器からACCEPTEDレスポンスが返されたときには、さらにMAC4AとMAC4Bが等しいかどうかに基づいてコンテンツ鍵の確認を行なう。そして、Sink機器自身でコンテンツ鍵が正しいことを確認できた場合にはSink機器はconfirmed状態になる。
【0169】
一方、Source機器からACCEPTEDレスポンスが返されたがSink機器自身でのコンテンツ鍵確認に失敗した場合や、Source機器からREJECTEDレスポンスが返されたときには、Sink機器はnon−confirmation状態になる。
【0170】
ここで、confirmedはCONT_KEY_CONFによりコンテンツ鍵が正しいことが確認された状態、non−confirmationはCONT_KEY_CONFによりコンテンツ鍵が不正であることが確認された状態であり、いずれもDTCP Volume 1 Supplement E SectionV1SE8.6に規定されている。
【0171】
confirmed状態では、Sink機器は受信コンテンツの復号処理を継続して行なうことができる。他方、non−confirmation状態では、Sink機器は復号処理を継続できない。
【0172】
図16には、PCP−CCIに対応したSource機器がLegacyのSink機器との間でコンテンツ鍵確認手続きを行なうための処理手順をフローチャートの形式で示している。
【0173】
Source機器は、コンテンツ伝送先となるSink機器からコンテンツ確認を要求するCONT_KEY_CONFコマンドを受信すると(ステップS51)、コンテンツ鍵の確認を行なう(ステップS52)。具体的には、当該コマンドから検査用のノンスNcTを取り出して、現在のノンスNc、すなわち8ビット長のPCP−CCIと56ビット長の擬似的なノンスNc’をビット連結した値と比較する。そして、現在のノンスNcがNcTとNcT+5の範囲にあるときには検査用のノンスNcTが有効であることを確認する。
【0174】
そして、Source機器は、コンテンツ鍵が正しいことを確認した場合には その旨を示すACCEPTEDレスポンスをSink機器に返信するが(ステップS53)、コンテンツ鍵が不正であることを確認した場合にはその旨を示すREJECTEDレスポンスを返信する(ステップS54)。
【0175】
なお、ACCEPTED並びにREJECTEDはともにDTCP Volume 1 Supplement E SectionV1SE8.6に規定されている、コマンドに対するレスポンスである。
【0176】
また、図17には、LegacyのSink機器がPCP−CCIに対応したSource機器との間でコンテンツ鍵確認手続きを行なうための処理手順をフローチャートの形式で示している。
【0177】
Sink機器は、コンテンツ要求先となるSource機器に対しCONT_KEY_CONFコマンドを送信した後(ステップS61)、当該Source機器からのレスポンス受信を待機する(ステップS62)。
【0178】
ここで、Source機器からACCEPTEDレスポンスを受信したときには(ステップS63)、コンテンツ鍵を確認する(ステップS64)。このとき、コンテンツ鍵が正しい場合にはconfirmed(ステップS65)、コンテンツ鍵が不正である場合にはnon−confirmationである(ステップS67)。また、Sink機器がSource機器からREJECTEDレスポンスを受信したときには(ステップS66)、non−confirmationである(ステップS67)。
【0179】
ここで、confirmedはCONT_KEY_CONFによりコンテンツ鍵が正しいことが確認された状態、non−confirmationはCONT_KEY_CONFによりコンテンツ鍵が不正であることが確認された状態であり、いずれもDTCP Volume 1 Supplement E SectionV1SE8.6に規定されている。
【0180】
confirmedでは、Sink機器は受信コンテンツの復号処理を継続して行なうことができる。本実施形態では、Source機器は、検査用のノンスNcTを、8ビット長のPCP−CCIと56ビット長の擬似的なノンスNc’をビット連結した現在のノンスNcと比較するので、Sink機器から見るとノンスの変化が不自然であっても、confirmedである限り、コンテンツの受信及びその暗号解読を継続することができる。他方、non−confirmationでは、Sink機器は復号処理を継続できない。
【0181】
また、Sink機器は、最初のnon−confirmationとなってから1分間は複合処理を継続しながらコンテンツ鍵確認手続きを繰り返すことができるので(ステップS68)、ステップS41に戻り(ステップS70)、CONT_KEY_CONFコマンドを再発行する。
【0182】
コンテンツ鍵確認手続きを再試行して、1分以内にconfirmedとなれば(ステップS65)、受信コンテンツの復号処理を継続することができる。しかし、1分間non−confirmationが継続した場合には(ステップS68)、受信コンテンツの復号処理を停止しなければならない(ステップS69)。
【0183】
図18には、PCP−CCIに対応したSource機器(New Source)とLegacy Sinkの間で行なわれるコンテンツ鍵確認手続の動作シーケンスをまとめている。
【0184】
New Source側で、コンテンツの伝送中にPCP−CCIを変更すると、これに伴ってPCPヘッダに書き込まれるノンスNcの連続性が失われる。Legacy SinkはこのようなノンスNcのJumpを認識すると、コンテンツ鍵確認用のTCPコネクションを確立し、New Sourceに対しCONT_KEY_CONFコマンドを発行する。
【0185】
New Source側では、CONT_KEY_CONFコマンドからノンスNcTを取り出すと、更新後のPCP−CCIと現在の擬似的なノンスNc’をビット連結したノンスNcと比較する。そして、ノンスNcの改竄でないことを確認すると、Legacy Sinkに対しACCEPTEDレスポンスを返すとともに、継続してコンテンツを伝送する。これによって、Legacy Sinkは、コンテンツを継続して受信し解読処理を行なうことができる。
【0186】
また、第2のLegacy問題に関しては、相互認証手続(AKE)で交換する機器証明書の中にPCPヘッダ部に超拡張コピー制御情報を埋め込むことを示すCCIフラグを含めることによって、Sink機器はSource機器がLegacy機器でないことを認識することができる。あるいは、このようなCCIフラグを応答する能力確認用のコマンドを使用するようにしてもよい。
【0187】
PCP−CCIに対応した新規のDTCP機器は、例えばCCIフラグを1に設定された機器証明書を使用する。このCCIフラグは機器証明書内の予備(reserved)領域を使用することができる。Sink機器は、AKE手続きなどにおいて、Source機器の機器証明書をチェックして、PCP−CCIフィールドがPCPヘッダに存在するかどうかを安全に確認することができる。
【0188】
この場合、PCP−CCIに対応したSource機器は、PCPヘッダにPCP−CCIフィールドを埋め込んだ新しいフォーマットで、PCPパケットを常に送ることができる。一方、PCP−CCIに対応したSink機器は、新規のSource機器からコンテンツ・ストリームが到来したときには、そのPCPヘッダに含まれるPCP−CCIフィールドを使用することができる。
【0189】
図19には、Sink機器がSource機器のCCIフラグをチェックしてPCPヘッダ部のコピー制御情報を処理するための手順をフローチャートの形式で示している。
【0190】
Sink機器は、Source機器との間でコンテンツ伝送手続きの開始前にコンテンツ鍵交換及び認証手続(AKE)を行なう際に、当該Source機器はPCP−CCIをヘッダ部に埋め込んで送るかどうかを示す、CCIフラグの確認処理を実行する(S71)。同確認処理を実施する方法として数通りが考えられるが、詳細は後述に譲る。
【0191】
そして、CCIフラグを確認できたかどうかをチェックする(ステップS72)。確認できた場合には、コンテンツ伝送手続を開始し、Source機器からコンテンツ・ストリームをPCPとして受け取ったときに、PCPヘッダ中の64ビット長のノンス情報フィールドのうち上位8ビットをPCP−CCIとして参照する(ステップS73)。また、確認できなかった場合は、ノンス情報フィールドの上位8ビットをPCP−CCIとして参照しない(ステップS74)。
【0192】
ステップS71において確認処理を行なう方法、すなわちSource機器がPCPヘッダにPCP−CCIを埋め込んでいることを識別する具体的な1つの方法として、機器証明書の中にCCIフラグを含めることが挙げられる。
【0193】
この機器証明書は、例えばDTLAのように信頼のおけるライセンス・オーソリティによる電子署名が付加されているものとする。また、証明書の中にはその送信装置の公開鍵が含まれることで、チャレンジ・アンド・レスポンス型の認証手続きにおいて、送信側が自身の署名を付加したレスポンス(受信側からのチャレンジ・データを含む)を受信側に送り、受信側に対して自身の証明書が正当なものであることを示すことができる。
【0194】
図20には、機器証明書内にCCIフラグを埋め込むことによって、Source機器がPCP−CCI対応であることをSink機器に示す送受信シーケンス例を示している。
【0195】
まず、コンテンツ要求元であるSink機器から、Rx乱数とRx証明書を含んだRxチャレンジが送信される。これに対し、Source機器からは、Tx乱数及びTx証明書を含んだTxチャレンジが返信される。このTx証明書には、例えば予備領域の1ビットを使用して、CCIフラグがセットされている。Sink機器は、このCCIフラグをチェックして、Source機器がPCP−CCIに対応していることを確認する。
【0196】
以降、Source機器から、Rx乱数、Txメッセージ、Tx署名を含んだRxレスポンスが送信されるとともに、Sink機器からはTx乱数、Rxメッセージ、Rx署名を含んだTxレスポンスが送信され、通常のチャレンジ・アンド・レスポンス認証手続きが続く。
【0197】
図21には、Sink機器がSource機器から受信したTxチャレンジに含まれる機器証明書からCCIフラグを検証するための処理手順をフローチャートの形式で示している。
【0198】
Sink機器は、Source機器からTxチャレンジを受信すると(ステップS81)、これに含まれている機器証明書の署名を検証する(ステップS82)。そして、検証に成功したときには(ステップS83)、当該証明書中のCCIフラグの値を参照する(ステップS84)。また、検証に失敗したときには、フラグ値のチェックを行なうことなく、認証エラーを返す(ステップS85)。
【0199】
また、ステップS71において、Source機器がPCPヘッダにPCP−CCIを埋め込んでいることを識別する他の方法として、Source機器が自身の署名を付加して送るレスポンスの中にCCIフラグを埋め込むことが挙げられる。
【0200】
図22には、機器が自身の署名を付加して送るレスポンスの中にCCIフラグを埋め込むことによって、Source機器がPCP−CCI対応であることをSink機器に示す送受信シーケンス例を示している。
【0201】
まず、コンテンツ要求元であるSink機器から、Rx乱数とRx証明書を含んだRxチャレンジが送信される。これに対し、Source機器からは、Tx乱数及びTx証明書を含んだTxチャレンジが返信される。
【0202】
続いて、Source機器から、Rx乱数、Txメッセージ、Tx署名を含んだRxレスポンスが送信される。ここで、Txメッセージには、CCIフラグが含まれている。Sink機器は、このCCIフラグをチェックして、Source機器がPCP−CCIに対応していることを確認する。そして、Sink機器からはTx乱数、Rxメッセージ、Rx署名を含んだTxレスポンスが送信され、通常のチャレンジ・アンド・レスポンス認証手続きが続く。
【0203】
図23には、Sink機器がSource機器から受信したRxレスポンスに含まれるTxメッセージからCCIフラグを検証するための処理手順をフローチャートの形式で示している。
【0204】
Sink機器は、Source機器からRxレスポンスを受信すると(ステップS91)、Rx乱数とTxメッセージ対するTx署名を検証する(ステップS92)。そして、検証に成功したときには(ステップS93)、当該Txメッセージ中のCCIフラグの値を参照する(ステップS94)。また、検証に失敗したときには、フラグ値のチェックを行なうことなく、認証エラーを返す(ステップS95)。
【0205】
例えば、Txメッセージ中の予備領域の1ビットを使用して、CCIフラグを埋め込むことができる。但し、Rxレスポンス中にCCIフラグを挿入する場所がもはや残されていない場合には、新規のRxレスポンス用のコマンドを定義すればよい。
【0206】
また、LegacyのSink機器は新規のRxレスポンス用のコマンドに対応することができないという問題がある。このため、Sink機器からSource機器に対し新規のRxレスポンスを求めるための、新規のRxチャレンジ用のコマンドをさらに定義するようにしてもよい。
【0207】
図24には、Sink機器からSource機器に対し新規のRxチャレンジを送信し、これに対しSource機器がCCIフラグを埋め込んだ新規のRxレスポンスを返し、Source機器がPCP−CCI対応であることをSink機器に示す送受信シーケンス例を示している。
【0208】
まず、コンテンツ要求元であるSink機器から、Source機器に対し新規のRxレスポンスを求めるための、新規のRxチャレンジ用コマンドが送信される。このRxチャレンジ用のコマンドには、Rx乱数とRx証明書が含まれている(同上)。これに対し、Source機器からは、Tx乱数及びTx証明書を含んだTxチャレンジが返信される。
【0209】
続いて、Source機器から、Rx乱数、Txメッセージ、Tx署名を含んだ新規のRxレスポンス用コマンドが送信される。ここで、Txメッセージには、CCIフラグが含まれている。Sink機器は、このCCIフラグをチェックして、Source機器がPCP−CCIに対応していることを確認する。そして、Sink機器からはTx乱数、Rxメッセージ、Rx署名を含んだTxレスポンスが送信され、通常のチャレンジ・アンド・レスポンス認証手続きが続く。
【0210】
図25は、Source機器が、図24に示した動作に対応したチャレンジ・アンド・レスポンス動作を行なうための処理手順をフローチャートの形式で示している。
【0211】
Source機器は、Sink機器からRxチャレンジを受信すると(ステップS101)、これが従来通りのRxチャレンジ、又はCCIフラグを埋め込んだ新規のRxレスポンスを求める新規のRxチャレンジのいずれであるかを判別する(ステップS102)。
【0212】
そして、従来通りのRxチャレンジを受信したときには、以降は従来通りの認証手順を実施するが(ステップS103)、新規のRxチャレンジを受信したときには、図24に示した認証手順を実施して(ステップS104)、Sink機器に対し自己がPCP−CCIに対応していることを示す。
【0213】
また、図26には、Sink機器がSource機器から受信した新規のRxレスポンスに含まれるTxメッセージからCCIフラグを検証するための処理手順をフローチャートの形式で示している。
【0214】
Sink機器は、Source機器から新規のRxレスポンスを受信すると(ステップS111)、Rx乱数とTxメッセージ対するTx署名を検証する(ステップ1192)。そして、検証に成功したときには(ステップS113)、当該Txメッセージ中のCCIフラグの値を参照する(ステップS114)。また、検証に失敗したときには、フラグ値のチェックを行なうことなく、認証エラーを返す(ステップS115)。
【0215】
また、Sink機器からSource機器に対し新規のRxレスポンスを求める他の方法として、能力確認用のコマンドを新たに定義することが挙げられる。
【0216】
図27には、Sink機器からSource機器に対し能力確認コマンドを送信し、これに対しSource機器がCCIフラグを埋め込んだ能力確認レスポンスを返し、Source機器がPCP−CCI対応であることをSink機器に示す送受信シーケンス例を示している。
【0217】
まず、コンテンツ要求元であるSink機器から、Source機器に対し能力確認コマンドが送信される。これに対し、Source機器からは、能力確認レスポンスが返信される。このレスポンスには、CCIフラグがセットされている。
【0218】
続いて、コンテンツ要求元であるSink機器から、Source機器に対し新規のRxレスポンスを求めるための、新規のRxチャレンジ用コマンドが送信される。このRxチャレンジ用のコマンドには、Rx乱数とRx証明書が含まれている(同上)。これに対し、Source機器からは、Tx乱数及びTx証明書を含んだTxチャレンジが返信される。
【0219】
続いて、Source機器から、Rx乱数、Txメッセージ、Tx署名を含んだ新規のRxレスポンス用コマンドが送信される。ここで、Txメッセージには、CCIフラグがセットされている。Sink機器は、このCCIフラグをチェックして、Source機器がPCP−CCIに対応していることを確認する。そして、Sink機器からはTx乱数、Rxメッセージ、Rx署名を含んだTxレスポンスが送信され、通常のチャレンジ・アンド・レスポンス認証手続きが続く。
【0220】
図28は、Sink機器が、図27に示した動作に対応したチャレンジ・アンド・レスポンス動作を行なうための処理手順をフローチャートの形式で示している。
【0221】
Sink機器は、Source機器に対してCCIフラグを埋め込んだ新規のRxレスポンスを要求する際には、まず能力確認コマンドを送信する(ステップS121)。
【0222】
そして、Source機器から能力確認レスポンスが返されると、その中にCCIフラグがセットされているかどうかをチェックする(ステップS122)。
【0223】
そして、CCIフラグが設定されていないときには、以降は従来通りの認証手順を実施するが(ステップS123)、CCIフラグが設定されているときには、図27に示した認証手順を実施して(ステップS124)、Source機器がPCP−CCIに対応していることを確認する。新規の認証手続きは図26に示した処理手順に従うので、ここでは説明を省略する。
【0224】
なお、Sink機器から能力確認コマンドを送信したのに対し、Source機器が当該コマンドに対応していない場合には、“not implemented”コマンドが返されるので、Sink機器はSource機器がLegacyであることを識別できる。
【0225】
また、能力確認用のコマンドを新たに定義して新規のRxレスポンスを求める場合の変形例として、最初の能力確認コマンドとその応答にチャレンジ・アンド・レスポンス処理を組み込み、その動作シーケンス中にCCIフラグをセキュアに送ることも考えられる。この場合、Sink機器からSource機器に対し能力確認コマンドを送信し、これに対しSource機器がCCIフラグを埋め込んだ署名付きの能力確認レスポンスを返し、Source機器がPCP−CCI対応であることをSink機器に示すことができる。そして、引き続く認証処理は常に従来通りの手順となる。
【0226】
図29には、最初の能力確認コマンドとその応答にチャレンジ・アンド・レスポンス処理を組み込んだ場合に、Source機器がPCP−CCI対応であることをSink機器に示す送受信シーケンス例を示している。
【0227】
まず、コンテンツ要求元であるSink機器から、Source機器に対し能力確認コマンドが送信される。この能力確認コマンドには、チャレンジ・アンド・レスポンス用のRx乱数2が含まれている。これに対し、Source機器からは、能力確認レスポンスが返信される。この能力確認レスポンスには、Rx乱数2と、Txメッセージ2と、Tx署名2が含まれている。そして、Txメッセージ2にはCCIフラグがセットされている。Sink機器は、このCCIフラグをチェックして、Source機器がPCP−CCIに対応していることを確認する。
【0228】
続いて、Sink機器から、Rx乱数とRx証明書を含んだRxチャレンジが送信される。これに対し、Source機器からは、Tx乱数及びTx証明書を含んだTxチャレンジが返信される。
【0229】
続いて、Source機器から、Rx乱数、Txメッセージ、Tx署名を含んだRxレスポンスが送信される。そして、Sink機器からはTx乱数、Rxメッセージ、Rx署名を含んだTxレスポンスが送信され、通常のチャレンジ・アンド・レスポンス認証手続きが続く。
【0230】
図30は、Sink機器が、図29に示した動作に対応したチャレンジ・アンド・レスポンス動作を行なうための処理手順をフローチャートの形式で示している。ここでは、Tx署名2の検証を行なうにはTx証明書に含まれるSource機器の公開鍵が必要であるため、この検証処理はTxチャレンジの受信以降に行なうことになる。
【0231】
Sink機器は、チャレンジ・アンド・レスポンス用のRx乱数2を含んだ能力確認コマンドを送信する(ステップS131)。
【0232】
ここで、Source機器から応答を受信し(ステップS132)、且つこの応答がACCEPTEDである場合には(ステップS133のYes)、続いて、Rxチャレンジの送信とTxチャレンジの受信を行なう(ステップS134)。そして、Rx乱数2とTxメッセージに対するTx署名2を検証する(ステップS135)。
【0233】
Sink機器は、Tx署名2の検証に成功した場合には(ステップS136のYes)、Txメッセージ2に含まれるCCIフラグを参照し、セットされているかどうかを確認する(ステップS138)。そして、CCIフラグがセットされていることを確認したら、PCP−CCIを参照可とする。続いて、Rx乱数とRx証明書を含んだRxチャレンジが送信するとともに、Source機器からTx乱数及びTx証明書を含んだTxチャレンジを受信する(ステップS139)。
【0234】
また、ステップS133において能力確認コマンドに対するACCEPTED応答を受信できなかったときには、Sink機器は、Rx乱数とRx証明書を含んだRxチャレンジが送信するとともに、Source機器からTx乱数及びTx証明書を含んだTxチャレンジを受信するが(ステップS140)、CCIフラグを確認することができないので(ステップS141)、PCP−CCIは参照付加とする。
【0235】
また、ステップS137においてTx署名2の検証に失敗したときも、CCIフラグを確認することができないので(ステップS141)、PCP−CCIは参照付加とする。
【産業上の利用可能性】
【0236】
以上、特定の実施形態を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
【0237】
本発明の適用例として、DTCP_Source機器とDTCP_Sink機器の間で行なわれるHTTPプロトコルを利用したコンテンツ伝送を挙げることができるが、本発明の要旨はこれに限定されない。コピー制御情報とともに暗号化コンテンツを伝送するその他のさまざまなタイプの情報通信システムに対しても、同様に本発明を適用することができる。
【0238】
要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、特許請求の範囲を参酌すべきである。
【図面の簡単な説明】
【0239】
【図1】図1は、本発明の一実施形態に係る情報通信システムの構成例を模式的に示した図である。
【図2】図2は、図1に示した情報通信システムにおいて、クライアント(すなわち、Sink機器)として動作する情報通信装置の機能構成を示した図である。
【図3】図3は、図1に示した情報通信システムにおいて、サーバ(すなわち、Source機器)として動作する情報通信装置の機能構成を示した図である。
【図4】図4は、DTCP_Source機器とDTCP_Sink機器の間でAKEに基づく鍵交換手続き、及び鍵交換により共有した鍵を利用した暗号化コンテンツ伝送を行なう仕組みを説明するための図である
【図5】図5は、PCPのデータ構造を模式的に示した図である。
【図6】図6は、PCPペイロードにパディングする様子を示した図である。
【図7】図7は、本発明の実施形態に係るPCPヘッダのデータ構造を示した図である。
【図8】図8は、PCP−CCIフィールドのフォーマット構成例を示した図である。
【図9】図9は、Modeビット・フィールドに基づいてPCP CCIフィールドの意味を識別するための処理手順を示したフローチャートである。
【図10】図10は、Modeビット・フィールドとSEビット・フラグの値の組み合わせに基づいてPCP CCIフィールドの意味を識別するための処理手順を示したフローチャートである。
【図11】図11は、Modeビット・フィールド及びSEビット・フラグの値の組み合わせに基づいてE−EMIでEmbedded CCIを代用することが可能かどうかを判別するための処理手順を示したフローチャートである。
【図12】図12は、LegacyのSource機器とSink機器間でPCPを伝送する仕組みを説明するための図である。
【図13】図13は、PCP−CCIをPCPヘッダに埋め込む伝送方式を適用したSource機器とSink機器間でPCPを伝送する仕組みを説明するための図である。
【図14】図14は、図12に示したLegacyのSource及びSink機器と、図13に示した新方式のSource及びSink機器が混在するコンテンツ伝送環境下においてLegacy問題が発生する様子を示した図である。
【図15】図15は、コンテンツ鍵確認のためのSink機器とSource機器間の手続きを示した図である。
【図16】図16は、PCP−CCIに対応したSource機器がLegacyのSink機器との間でコンテンツ鍵確認手続きを行なうための処理手順を示したフローチャートである。
【図17】図17は、LegacyのSink機器がPCP−CCIに対応したSource機器との間でコンテンツ鍵確認手続きを行なうための処理手順を示したフローチャートである。
【図18】図18は、PCP−CCIに対応したSource機器(New Source)とLegacy Sinkの間で行なわれるコンテンツ鍵確認手続の動作シーケンスを示した図である。
【図19】図19は、Sink機器がSource機器のCCIフラグをチェックしてPCPヘッダ部のPCP−CCI情報を処理するための手順を示したフローチャートである。
【図20】図20は、機器証明書内にCCIフラグを埋め込むことによって、Source機器がPCP−CCI対応であることをSink機器に示す送受信シーケンス例を示した図である。
【図21】図21は、Sink機器がSource機器から受信したTxチャレンジに含まれる機器証明書からCCIフラグを検証するための処理手順を示したフローチャートである。
【図22】図22は、機器が自身の署名を付加して送るレスポンスの中にCCIフラグを埋め込むことによって、Source機器がPCP−CCI対応であることをSink機器に示す送受信シーケンス例を示した図である。
【図23】図23は、Sink機器がSource機器から受信したRxレスポンスに含まれるTxメッセージからCCIフラグを検証するための処理手順を示したフローチャートである。
【図24】図24は、Sink機器からSource機器に対し新規のRxチャレンジを送信し、これに対しSource機器がCCIフラグを埋め込んだ新規のRxレスポンスを返し、Source機器がPCP−CCI対応であることをSink機器に示す送受信シーケンス例を示した図である。
【図25】図25は、Source機器が、図24に示した動作に対応したチャレンジ・アンド・レスポンス動作を行なうための処理手順を示したフローチャートである。
【図26】図26は、Sink機器がSource機器から受信した新規のRxレスポンスに含まれるTxメッセージからCCIフラグを検証するための処理手順を示したフローチャートである。
【図27】図27は、Sink機器からSource機器に対し能力確認コマンドを送信し、これに対しSource機器がCCIフラグを埋め込んだ能力確認レスポンスを返し、Source機器がPCP−CCI対応であることをSink機器に示す送受信シーケンス例を示した図である。
【図28】図28は、Sink機器が、図27に示した動作に対応したチャレンジ・アンド・レスポンス動作を行なうための処理手順を示したフローチャートである。
【図29】図29は、Sink機器からSource機器に対し能力確認コマンドを送信し、これに対しSource機器がCCIフラグを埋め込んだ署名付きの能力確認レスポンスを返し、Source機器がPCP−CCI対応であることをSink機器に示す送受信シーケンス例を示した図である。
【図30】図30は、Sink機器が図29に示した動作に対応したチャレンジ・アンド・レスポンス動作を行なうための処理手順を示したフローチャートである。
【図31】図31は、PCPヘッダの内部構造を示した図である。
【技術分野】
【0001】
本発明は、著作権保護若しくはその他の目的で暗号化された伝送コンテンツを伝送処理するコンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムに係り、特に、DTCPに準拠した情報機器同士で暗号化コンテンツの伝送手続きを実行するコンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムに関する。
【0002】
さらに詳しくは、本発明は、伝送するコンテンツに関する属性情報並びにコピー制御情報をパケット内に挿入して伝送するコンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムに係り、特に、コンテンツのフォーマットに依存しない形式で属性情報並びにコピー制御情報をパケット内に挿入して伝送するコンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムに関する。
【背景技術】
【0003】
情報技術の普及に伴い、AVコンテンツのほとんどがデジタル化されており、CDやDVDなどのデジタル・コンテンツを記録再生するメディアが広く利用されている。また、最近では、HDDレコーダやHDD搭載DVDレコーダなど、コンテンツをデジタル記録する機器が家庭内にも浸透してきている。さらには、ネットワークを経由した映像や音楽などのコンテンツの流通・配信サービスが盛んとなり、CDやDVDなどのメディアの移動なしに、ネットワークを経由して遠隔端末間でコンテンツ配信が行なわれている。
【0004】
勿論、これらAVコンテンツは、著作物の1つとして、著作権法の下で無断の複製や改竄などの不正使用から保護を受けることができる。著作権法では、同法第30条において、個人的に又は家庭内などを使用目的とした場合の使用者本人の複製を許容する一方、同法第49条第1項においては、私的使用以外での複製物の使用を禁止している。
【0005】
しかしながら、デジタル化されたコンテンツはコピーや改竄などの不正な操作が比較的容易であることから、法的な整備だけでなく技術的な側面からも、個人的又は家庭的なコンテンツの使用を許容しながら不正使用に対する防御が必要である。とりわけ、国内では2011年の地上アナログ放送停波に向けてアナログ放送受信機からデジタル放送受信機への置き換えが急速に進んでおり、家庭内のAVコンテンツのデジタル化に対してコンテンツの保護を技術的に実現することが必須と考えられている。
【0006】
デジタル・コンテンツの著作権保護を目的とした多くの技術が開発されている。例えば、デジタル伝送コンテンツの保護に関する業界標準として、DTLA(Digital Transmission Licensing Administrator)が開発したDTCP(Digital Transmission Content Protection)が挙げられ、著作権が保護された形でコンテンツを伝送させるための仕組みについて規定されている(例えば、非特許文献1を参照のこと)。
【0007】
DTCPでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、DTCP準拠機器はMPEG(Moving Picture Experts Group)など取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換(Authentication and Key Exchange:AKE)アルゴリズムに従って行なうこと、並びにAKEコマンドにより鍵交換を行なう機器の範囲を制限することなどを取り決めている。
【0008】
コンテンツ提供元であるサーバ(DTCP_Source)とコンテンツ提供先であるクライアント(DTCP_Sink)は、AKEコマンドの送受信により、認証手続きを経て鍵を共有化し、その鍵を用いて伝送路を暗号化してコンテンツの伝送を行なう。したがって、不正なクライアントは、サーバとの認証に成功しないと暗号鍵を取得できないから、コンテンツを享受することはできない。また、AKEコマンドを送受信する機器の台数や範囲を制限することによって、コンテンツが使用される範囲を著作権法で言うところの個人的又は家庭の範囲内に抑えることができる。
【0009】
DTCPは、原初的には、IEEE1394などを伝送路に用いたホーム・ネットワーク上におけるデジタル・コンテンツの伝送について規定したものである。しかしながら、最近では、DLNA(Digital Living Network Alliance)に代表されるように、デジタル化されたAVコンテンツをIPネットワークを用いて家庭内で流通させようという動きが本格的になっていることから、IPネットワークに対応したDTCP技術、すなわちDTCP−IP(DTCP mapping to IP)の開発が進められている。ホーム・ネットワークの多くはルータなどを経由してインターネットなどの外部のIPネットワークに接続されると、コンテンツの不正コピーや改竄の危惧が指摘されている。DTCP−IP技術の確立により、デジタル・コンテンツを保護しながらIPネットワークを利用した柔軟で効率的なコンテンツの利用が図ることが急務である。
【0010】
DTCP−IPは、基本的にはDTCP規格に含まれ、DTCP技術をIPネットワークに移植した同様の技術であるが、伝送路にIPネットワークを使用すること、暗号化されたコンテンツの伝送にHTTP(Hyper Text Transfer Protocol)やRTP(Real Time Protocol)などのプロトコルを使用するという点で、IEEE1394ベースで規定された本来のDTCPとは相違する。また、IPネットワーク上にはPCを主としたさまざまな機器が接続され、データの盗聴、改竄が簡単に行なわれてしまう危険が高いことから、DTCP−IPは、コンテンツを保護しながらネットワーク伝送するためのさらなる方法を規定している(例えば、非特許文献2を参照のこと)。
【0011】
ここで、DTCP−IPに準拠したコンテンツ伝送について説明する。DTCP−IPに準拠したSource機器及びSink機器間でHTTPプロトコルを利用したコンテンツ伝送を実施する場合、TCPストリームのような長大なバイト・ストリームを伝送の途中でコンテンツ鍵を変更しながら暗号化通信が行なわれ、且つ、暗号化コンテンツの復号処理その他のコンテンツ処理を実施する際にコンテンツ鍵の確認手続きが行なわれる。また、相互認証及び鍵交換(AKE)、コンテンツ伝送、並びにコンテンツ鍵確認の手続き毎にTCPコネクションが確立される。
【0012】
具体的には、AKE手続きが成功すると、DTCP_Source機器とDTCP_Sink機器は、認証鍵Kauthを共有することができる。DTCP_Source機器はコンテンツ鍵の種となる種鍵Kxを生成し、認証鍵Kauthで暗号化してDTCP_Sink機器に送る。DTCP_Source機器は、乱数を用いてノンス(Nonce)Ncを生成して、KxとNcと暗号モードを表すE−EMIを基にコンテンツ鍵Kcを生成する。そして、DTCP_Sink機器から要求されているコンテンツを、コンテンツ鍵Kcを用いて暗号化し、暗号化コンテンツとノンスNcとE−EMIをヘッダに含んだパケットをTCPストリーム上に乗せてSink機器に送信する。一方、DTCP_Sink機器側では、TCPストリームからノンスNcとE−EMIを取り出すと、これらと鍵Kxを用いて同様にコンテンツ鍵Kcを算出し、暗号化コンテンツを復号することができる。
【0013】
このように、DTCP−IPは、DTCPに準拠した機器同士で認証を行ない、DTCP認証が完了した機器同士で鍵を共有し、コンテンツを伝送する際に暗号化及び復号をすることにより、伝送路の途中におけるコンテンツの盗聴、改竄を防ぐという、IPネットワーク上においても安全なコンテンツ伝送手法を提供することができる。
【0014】
例えば、HTTPの手続きに従ってコンテンツを要求する場合、DTCP_SourceがHTTPサーバとなり、DTCP_SinkがHTTPクライアントとなって、HTTPのためのTCP/IPコネクションが作成され、コンテンツの伝送を開始する。HTTPクライアントは、通常のHTTPと全く同様の動作手順によりHTTPサーバ上のコンテンツを要求する。これに対し、HTTPサーバは、要求通りのコンテンツをHTTPレスポンスとして返す。DTCP_Sourceは、DTCP_Sinkから要求されているコンテンツを、コンテンツ鍵Kcを用いて暗号化し、暗号化コンテンツからなるペイロードとノンスNcとE−EMI含んだヘッダからなるパケット(PCP:Protected Content Packet)をTCPストリーム上に乗せて送信する。
【0015】
また、長大なTCPストリーム全体に渡り同じ暗号鍵を使用し続けると、鍵が解読される危険は高くなる。このため、DTCP_Source機器は128MBのコンテンツ毎にノンスNcを1ずつ増加させてコンテンツ鍵Kcを更新する。そして、バイト・ストリームの途中でノンスNcが大幅に変更されることから、コンテンツ鍵の確認手続きが必要となり、DTCP_Sink機器は、DTCP_Source機器に対しノンスNcの確認のための手続きを行なう。
【0016】
また、著作権保護に対応したコンテンツ伝送システムでは、コンテンツ保護に関するコンテンツ属性を指定する必要がある。DTCP−IPでは、PCPヘッダ部に記述するE−EMI(Encryption Mode Indicator)と、Embeded CCI(Copy Control Information)という2つのメカニズムにより、コンテンツに付随したコピー制御情報の伝送を実現している。
【0017】
Embedded CCIは、暗号化するコンテンツ・ストリームの一部として(すなわちPCPペイロードに埋め込んで)伝送されるコピー制御情報である。多くのコンテンツ・フォーマットはストリームに付随してCCIを伝送するために割り当てられたフィールドを備えているが、CCIの定義やフォーマットはコンテンツ・フォーマット毎に特殊である。Embedded CCIは、“Copy Never”、“Copy One Generation”、“No More Copies”、“Copy Free”などとして解釈される。コンテンツ・ストリームをタンパリングすると誤った暗号解読を行なうことになるので、Embedded CCIの完全性を保証することができる。
【0018】
一方のE−EMIは、PCPヘッダでコンテンツ・ストリームに関するコピー制御情報を示すことにより、容易にアクセスできると同時にセキュリティを実現する。平文状態のPCPヘッダの特定のビット位置というアクセス容易な場所にE−EMIを配置することにより、機器は、コンテンツ・ストリームのCCIを即座に判断することができ、コンテンツ伝送フォーマットを復号してEmbedded CCIを抽出する必要がない。E−EMIは、デジタルVCRのように特殊なコンテンツ・フォーマットを認識したりデコードしたりすることができないビット・ストリーム記憶機器を実現する際に重要である。
【0019】
DTCP−IPに準拠する適正なSource機器は、コンテンツ・ストリームの特性に従って正しい暗号モードを選択し、これに基づいてE−EMIを設定する。また、適正なSink機器は、PCPヘッダ中のE−EMIで指定される正しい暗号解読モードを選択する。E−EMIをコンテンツ鍵Kcの生成に使用しているので、E−EMIがタンパリングされると、暗号化時と復号時のコンテンツ鍵Kcが一致しないことから、コンテンツの暗号解読を誤るので、セキュリティが保たれる。
【0020】
図31には、PCPヘッダの内部構造を図解している(例えば、非特許文献3を参照のこと)。このうち、E−EMI(Extended EMI)は、暗号モードを記述する4ビットのフィールドである。E−EMIの値はコピー制御情報の種類に対応する。ビット値定義を下表に示しておく(例えば、非特許文献4を参照のこと)。但し、同表で未使用となっている9つのE−EMI値は将来の拡張用に予備となっている。
【0021】
【表1】
【0022】
上述したように、PCPヘッダにコンテンツの暗号モード及びコピー制御情報を指定するE−EMIが記述されるが、コンテンツの保護を目的としたコピー制御情報としてはこれらのパラメータでは十分でない(すなわち4ビット長のE−EMIフィールドに必要なコピー制御情報を書ききれない)場合がある。例えば、コンテンツのアナログ出力制御に関するパラメータ(APS:AnalogProtection System)や、出力時の画サイズに関するパラメータ(ICT:Image Consstraint Token)などの出力制御情報は、DTCPではコピー制御情報の構成要素(付加的若しくは拡張的なコピー制御情報であり、本明細書では「超拡張コピー制御情報」とも呼ぶ)として扱われる。これらは、E−EMIに書き込めないため、Embedded CCIの一部としてPCPペイロード中に埋め込むより他ない。
【0023】
また、DTCPにおけるコピー制御機能の1つとして、単純にE−EMIに従ってコピーの可否を制御するのではなく、機器がコンテンツのフォーマットとEmbedded CCIを正しく認識できた場合(すなわち“cognizant”である場合)、Embedded CCIに従ってコンテンツの処理方法を制御するという“Cognizant Function”(Cognizant機能)を提供している。PCPヘッダ部から取り出したE−EMIと、このCognizant機能を用いてPCPペイロードから取り出したEmbedded CCIを照合する必要がある。Embedded CCIとEMIの関係を下表に示しておく。
【0024】
【表2】
【0025】
しかしながら、DTCP−IPでは、コンテンツ・ストリームの一部としてEmbedded CCIを伝送するとしか規定していない。現在のDTCP−IPでは、MPEGトランスポート・ストリームに関してEmbedded CCIに相当するDTCPディスクリプタを挿入するという規定(例えば、非特許文献5を参照のこと)の他には、Embedded CCIの構成方法に関する規定は存在しない。MPEGを含む多くのコンテンツ・フォーマットにおいて、ストリームに付随してCCIを伝送するためのフィールドが割り当てられているが、CCIの定義やフォーマットはコンテンツ・フォーマット毎に特殊すなわち区々になっているのが現状である。
【0026】
PCPペイロードにコピー制御情報を埋め込むことは、コンテンツ内にコピー制御情報を挿入することであるから、必然的にその記述方法はコンテンツ・フォーマットに依存し、フォーマット毎に区々になる。したがって、DTCP−IPに準拠してAVコンテンツを暗号化伝送するときには、DTCP_Source機器側ではフォーマット毎にコピー制御情報の記述方法を変えて伝送し、DTCP_Sink機器側ではフォーマット毎にコピー制御情報を解析するためのソフトウェア又はハードウェアを用意する必要があり、機器コストの増大を招来する。また、暗号化したPCPペイロードにコピー制御情報を埋め込むと、受信側では復号後でないとこれを取り出すことができないという問題もある。
【0027】
【非特許文献1】DTCP Specification Volume 1 Version 1.4 (Informational Version)http://www.dtcp.com/
【非特許文献2】DTCP Volume 1 Supplement E Mapping DTCP to IP, Version 1.1 (Informational Version)http://www.dtcp.com/
【非特許文献3】DTCP Volume1 Supplement E Mapping DTCP to IP Version1.1(Informational Version) 4.22 Modification to 6.6.3 Content Encryption Formats
【非特許文献4】DTCP Volume1 Supplement E Mapping DTCP to IP Version1.1(Informational Version) 4.7 Modification to 6.4.2 Encryption Mode Indicator(EMI)
【非特許文献5】DTCP Specification Volume1 Version1.4(Informational Version) Appendix B DTCP_Descriptor for MPEG Transport Streams
【発明の開示】
【発明が解決しようとする課題】
【0028】
本発明の目的は、DTCPに準拠した情報機器同士で暗号化コンテンツの伝送手続きを好適に実行することができる、優れたコンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することにある。
【0029】
本発明のさらなる目的は、伝送するコンテンツに関する属性情報並びにコピー制御情報をパケット内に挿入して好適に伝送することができる、優れたコンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することにある。
【0030】
本発明のさらなる目的は、コンテンツのフォーマットに依存しない共通の形式で属性情報並びにコピー制御情報をパケット内に挿入し、且つこれらの情報をセキュアに使用することができる、優れたコンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することにある。
【課題を解決するための手段】
【0031】
本発明は、上記課題を参酌してなされたものであり、その第1の側面は、コピー制御がなされたコンテンツを伝送するコンテンツ伝送装置であって、
コンテンツ伝送先の機器との間で認証手続きを行なう認証手段と、
コンテンツに関するコピー制御情報を記述した第1のコピー制御情報を処理する第1のコピー制御情報処理手段と、
コンテンツに関する第1のコピー制御情報以外の情報を含んだ第2のコピー制御情報を処理する第2のコピー制御情報処理手段と、
第1のコピー制御情報及び第2のコピー制御情報を含んだヘッダ部と、コンテンツを所定のコンテンツ鍵で暗号化したペイロードからなるパケットを生成して、コンテンツ伝送先の機器に伝送するコンテンツ伝送手段と、
を具備することを特徴とするコンテンツ伝送装置である。
【0032】
本発明は、IPネットワーク上で著作権保護が必要となる情報コンテンツを伝送する情報通信システムに関するものであり、特に、具体的には、DTCP−IPに準拠した情報通信機器の間で、相互認証及び鍵交換を経て共有した鍵を用いて暗号化コンテンツ伝送を安全に行なうコンテンツ伝送装置に関する。
【0033】
著作権の保護に対応したコンテンツ伝送システムにおいては、コンテンツを暗号化伝送する際に、コンテンツ保護に関するコンテンツ属性を指定する必要がある。例えばDTCP−IPでは、PCPヘッダ部に記述するE−EMI(Encryption Mode Indicator)と、PCPペイロード部すなわちコンテンツ・ストリーム内に埋め込むEmbeded CCI(Copy Control Information)という2つのメカニズムにより、コンテンツに付随したコピー制御情報の伝送を実現している。
【0034】
ところが、一部のコピー制御情報をペイロード部すなわちコンテンツ・ストリームに記載するという暗号化伝送方式では、記載方法がコンテンツのフォーマットに依存するため、コピー制御情報を作成並びに解読するソフトウェア又はハードウェアのモジュールをフォーマット毎に用意しなければならず、機器コストが増大するという問題がある。
【0035】
そこで、本発明では、一部のコピー制御情報をパケットのヘッダ部に記載し、それ以外のコピー制御情報をペイロード部に記載してコンテンツを暗号化伝送するという旧来のシステム環境下において、旧来通りのSource機器及びSink機器との互換性を保ちながら、(DTCP−IPで)要求されるコピー制御を実現するために必要となるコピー制御情報をすべてヘッダ部に記載するコンテンツ伝送方式を提案する。
【0036】
そして、コンテンツに関するコピー制御情報として第1のコピー制御情報と第2のコピー制御情報を定義する。そして、第1のコピー制御情報及び第2のコピー制御情報を含んだヘッダ部と、コンテンツを所定のコンテンツ鍵で暗号化したペイロードからなるパケットを生成して、コンテンツ伝送先の機器に伝送するようにする。
【0037】
ペイロード部に(一部の)コピー制御情報を埋め込む場合とは相違し、ヘッダ部にコピー制御情報を埋め込む場合には、コンテンツのフォーマットに依存せず、すべてのフォーマットに共通の形式でコピー制御情報を挿入することができる。したがって、Source機器側においてコピー制御情報を作成し、Sink機器側においてコピー制御情報を解析するためのソフトウェア又はハードウェアのモジュールをすべてのフォーマットで共通化することができ、機器コストを削減することができる。
【0038】
第1のコピー制御情報は、例えば、コンテンツのコピーの可否を規定するコピー制御情報に対応した暗号モードを含んでいる。また、第2のコピー制御情報は、例えばコンテンツの出力制御に関する情報を含んでいる。
【0039】
例えば、DTCPでは、アナログ出力制御に関するパラメータ(APS)や、出力時の画サイズに関するパラメータ(ICT)といった出力制御情報がコピー制御情報の構成要素となっている。本発明に係るコンテンツ伝送方式では、これらのビット長の短いE−EMIには書ききれない情報を、第2のコピー制御情報、すなわち超拡張コピー制御情報としてヘッダ部に記述する方法を規定する。
【0040】
また、ヘッダに第1のコピー制御情報を書き込むフィールドを設けたヘッダと、コンテンツ埋め込み型のコピー制御情報を埋め込んだコンテンツからなるペイロードで構成された形式のパケットを用いてコンテンツ伝送が行なわれるコンテンツ伝送システムに適用する場合には、第2のコピー制御情報に、ヘッダ部に埋め込まれた第2の制御情報の有効性を示すモード情報と、コンテンツ埋め込み型のコピー制御情報の代わりに第1のコピー制御情報を代用可能であることを示す代用性情報を含めるようにしてもよい。
【0041】
また、コンテンツのフォーマットの認識可能性に応じたコンテンツのコピー制御を実施するcognizant機能が提供されている伝送システムに適用した場合、前記第2のコピー制御情報処理手段は、ヘッダに第2のコピー制御情報として含まれるモード情報と、ペイロード中におけるコンテンツ埋め込み型のコピー制御情報の存在の有無の組み合わせに応じてcognizant機能を実現することができる。
【0042】
すなわち、ヘッダ部内の所定位置に挿入された第2のコピー制御情報フィールドの有効性に関して記述したモード情報や、本来はペイロード部に埋め込まれるコピー制御情報の代わりにヘッダ部に書き込まれるコピー制御情報で代用できることを示すSE(Substitute for Embedded CCI)情報も、超拡張コピー制御情報としてヘッダ部に記述する。このような第2のコピー制御情報をヘッダ部の一部として構成することにより、コンテンツのフォーマットに依存せずすべてのフォーマットに共通の形式でコピー制御情報を伝送することが可能になる。すなわち、暗号化ペイロードからEmbedded CCIを取り出してE−EMIと照合することなく、従来はEmbedded CCIとE−EMIの組み合わせにより指定していたコピー制御機能や、cognizant機能を実現することが可能である。
【0043】
また、伝送システムの規格により、ノンスを用いて生成されたコンテンツ鍵で伝送コンテンツの暗号化が行なわれ、且つヘッダには所定ビット長のノンスを伝送するためのフィールドが設けられている場合、ノンスを伝送するためのフィールド内に第2のコピー制御情報を埋め込んで、パケットを伝送することができる。
【0044】
具体的には、前記の所定ビット長よりも第2のコピー制御情報のビット数分だけ短い擬似ノンスを生成し、第2のコピー制御情報とこの擬似ノンスをビット連結してなるノンスを用いて生成されるコンテンツ鍵で伝送コンテンツを暗号化することができる。
【0045】
図31に示したように、PCPヘッダには、E−EMIとともにノンス情報フィールドが設けられている。E−EMIは4ビットしかないので、もはや第2のコピー制御情報を記載する余裕はない。他方、ノンスNcは、コンテンツを暗号化するコンテンツ鍵Kcを生成する基となる情報であり64ビットが割り当てられている。本発明の1つの実装形態として、旧来のPCPヘッダ内のノンス情報フィールドの上位8ビットを用いて超拡張コピー制御情報を記述し、残りの下位56ビットに通常通りに生成されるノンスNc’の値を書き込むようにすることができる。コンテンツ中でE−EMIが変わる度、また定期的にノンスNcは更新する。通常、更新する機会毎に擬似的ノンスNc’の値を単調に増大させるが(1ずつインクリメントしていく)、56ビットしか使用しなくても、桁あふれは実用上は1度しか起こらないので桁あふれビットを1ビット用意することで対応できる。
【0046】
このような場合、本発明に係るコンテンツ伝送方式に対応したSource機器及びSink機器は、旧来の64ビットのノンス情報フィールド中の上位8ビットを第2のコピー制御情報フィールドとして利用するとともに、第2のコピー制御情報が書き込まれた上位8ビットと、56ビット長の擬似的なノンスNc’のビット連結からなる64ビット全体をノンスNcとして用いてコンテンツ鍵Kcの生成を行なう。不正コピー目的で第2のコピー制御情報を改竄しても、ノンスNcを改竄することなり、結局はコンテンツを復号できなくなるので、セキュリティも維持される。
【0047】
一方、旧来通りのSink機器も、旧来の64ビットのノンス情報フィールド全体に書き込まれた値をノンスNcとして解釈する。この場合、上位8ビットにPCP−CCIが書き込まれることから、ノンスNcの値を変更した際に本来満たされるべき規則性が失われることから、本発明に係る伝送方式に対応していないSink機器がノンスNcの規則性を期待していた場合、いわゆるLegacy問題が発生する。
【0048】
Source機器側で旧来の64ビットのノンス情報フィールドを8ビットの第2のコピー制御情報フィールドと56ビットの擬似的なノンス情報フィールドがビット連結として使用した場合、第2のコピー制御情報が変化する度にLegacyのSink機器にとってはノンスNcの連続性が失われる。これに応答して、LegacyのSink機器はコンテンツ鍵確認手続を起動することになる。このような場合、Source機器側では、コンテンツ鍵確認要求に対し、56ビットの擬似的なノンスで検証するのではなく、該確認要求されているノンスを第2のコピー制御情報を埋め込んで構成される64ビットのノンスと比較して検証するようにする。そして、ノンスNcに異常がないことを示すレスポンス(ACCEPTED)を返すことによって、LegacyのSink機器は以降も障害なくコンテンツ受信処理を継続することができる。
【0049】
また、本発明に係る伝送方式に対応したSink機器においても、コンテンツ伝送元であるSource機器が本方式を適用しているかどうか、すなわち上位8ビットに第2のコピー制御情報が記載されているかどうかを特定しなければならず、Legacy Source機器に対するLegacy問題が発生する。
【0050】
そこで、本発明では、前記コンテンツ伝送手段が第1のコピー制御情報及び第2のコピー制御情報を含んだヘッダを付けてパケットを伝送するとき、前記認証手段は、コンテンツ伝送先の機器に送信するコマンド内にその旨を示す情報を記載して、伝送先の機器に通知するようにしている。すなわち、コンテンツ送信元となるSource機器が本発明に係るコンテンツ伝送方式に対応している場合、PCPヘッダ部に超拡張コピー制御情報を埋め込むことを示すフラグを相互認証手続(AKE)で交換する機器証明書の中に含めることによって、Sink機器はSource機器がLegacy機器でないことを認識することができる。あるいは、能力確認用のコマンドを使用するようにしてもよい。
【0051】
また、本発明の第2の側面は、コピー制御がなされたコンテンツを伝送するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
コンテンツ伝送先の機器との間で認証手続きを行なう認証手順と、
コンテンツに関するコピー制御情報を記述した第1のコピー制御情報を設定する第1のコピー制御情報設定手順と、
コンテンツに関する第1のコピー制御情報以外の情報を含んだ第2のコピー制御情報を設定する第2のコピー制御情報設定手順と、
第1のコピー制御情報及び第2のコピー制御情報を含んだヘッダと、コンテンツを所定のコンテンツ鍵で暗号化したペイロードからなるパケットを生成して、コンテンツ伝送先の機器に伝送するコンテンツ伝送手順と、
を実行させることを特徴とするコンピュータ・プログラムである。
【0052】
本発明の第2の側面に係るコンピュータ・プログラムは、コンピュータ・システム上で所定の処理を実現するようにコンピュータ可読形式で記述されたコンピュータ・プログラムを定義したものである。換言すれば、本発明の第2の側面に係るコンピュータ・プログラムをコンピュータ・システムにインストールすることによって、コンピュータ・システム上では協働的作用が発揮され、本発明の第1の側面に係るコンテンツ伝送装置と同様の作用効果を得ることができる。
【発明の効果】
【0053】
本発明によれば、DTCPに準拠した情報機器同士で暗号化コンテンツの伝送手続きを好適に実行することができる、優れたコンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することができる。
【0054】
また、本発明によれば、伝送するコンテンツに関する属性情報並びにコピー制御情報をパケット内に挿入して好適に伝送することができる、優れたコンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することができる。
【0055】
また、本発明によれば、コンテンツのフォーマットに依存しない共通の形式で属性情報並びにコピー制御情報をパケット内に挿入し、且つこれらの情報をセキュアに使用することができる、優れたコンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することができる。
【0056】
本発明によれば、DTCP−IPに準拠した暗号化コンテンツの伝送を行なう際に、Sink機器側で必要となるすべてのコピー制御情報をPCPヘッダ中に記載することができる。言い換えれば、コンテンツのフォーマットに依存せずに(すなわちすべてのフォーマットに共通の形式で)、コピー制御情報をコンテンツに付けて伝送することができる。そして、Source機器側においてコピー制御情報を作成し、Sink機器側においてコピー制御情報を解析するためのソフトウェア又はハードウェアのモジュールをすべてのフォーマットで共通化することにより、機器コストを削減することができる。
【0057】
また、必要となるすべてのコピー制御情報をPCPヘッダ中に記載することで、コンテンツのフォーマットに依存することなくコピー制御情報を伝送することができるので、DTCP−IPにおいて既に規定されているMPEGトランスポート・ストリームにおいても同様に適用することが可能である。
【0058】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
【発明を実施するための最良の形態】
【0059】
本発明は、TCP/IPなどのネットワーク上やファイル・システムからバイト・ストリームとして暗号データを受理して復号する情報通信システムに関するものであり、特に、TCPストリームのような長大なバイト・ストリームを途中で復号鍵を変更しながら暗号化通信を行なう情報通信システムに関する。かかるシステムの具体例は、DTCP機器の間で行なわれるHTTPプロトコルを利用したコンテンツ伝送である。以下、図面を参照しながら本発明の実施形態について詳解する。
【0060】
A.システム構成
DTCP−IPに従ったコンテンツ伝送は、コンテンツの要求を受理してコンテンツを送信するサーバとしてのSource機器と、コンテンツを要求し、コンテンツを受信し、再生若しくは記録するクライアントとしてのSink機器で構成される。図1には、本発明の一実施形態に係る情報通信システムの構成例を模式的に示している。
【0061】
図示の例では、Source機器とSink機器の各エンティティにより、DTCP−IP AKEシステムが構築されている。
【0062】
DTCP−IP に準拠した認証サーバであるSource機器とDTCP−IPに準拠した認証クライアントであるSink機器はネットワークを経由して接続されている。
【0063】
ここで言うネットワークには、Ethernet(登録商標)や、インターネット、その他のIPネットワークが含まれる。
【0064】
図2及び図3には、図1に示した情報通信システムにおいて、クライアント(すなわち、Sink機器)及びサーバ(すなわち、Source機器)として動作するコンテンツ伝送装置の、特に認証及びコンテンツ伝送に着目した機能構成をそれぞれ模式的に示している。Sink機器とSource機器は、インターネットなどのTCP/IPネットワーク上でコネクションを確立することができ、このコネクションを利用して、認証手続きやコンテンツ伝送手続きを実行することができる。
【0065】
図2に示すSink機器は、DTCP−IP規格に準拠しており、DTCP_Sinkとして動作する。図示のクライアント機器は、機能ブロックとして、DTCP−IP認証ブロックと、DTCP−IPコンテンツ受信ブロックと、コンテンツ再生/記録ブロックを備えている。
【0066】
DTCP−IP認証ブロックは、AKEブロックと、メッセージ・ダイジェスト生成ブロックと、コンテンツ復号ブロックを備えている。
【0067】
AKEブロックは、DTCP−IPにおけるAKE機構(DTCP_Sink側)を実現するブロックでる。このAKEブロックは後述のメッセージ・ダイジェスト生成ブロックから要求されたパラメータを渡す機能も備えている。
【0068】
メッセージ・ダイジェスト生成ブロックは、指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックである。メッセージ・ダイジェストを生成するアルゴリズムはあらかじめ用意されたアルゴリズムを指定することができる。あらかじめ用意されたアルゴリズムとして、例えばMD5やSHA−1といった一方向性ハッシュ関数に関するアルゴリズムが挙げることができる(SHA−1は、MD5と同様、MD4を改良したものに相当するが、160ビットのハッシュ値を生成するので、強度はMDシリーズを上回る)。
【0069】
メッセージ・ダイジェスト生成ブロックは、DTCP−IP認証ブロックの外に公開してはならないAKEブロックが保持するパラメータのメッセージ・ダイジェストを生成できるようにAKEブロックと密に配置され、AKEブロックへパラメータを要求して取得することが可能であり、そのパラメータ若しくは外部から与えられたパラメータのメッセージ・ダイジェストを作成することができる。
【0070】
コンテンツ復号ブロックは、サーバから受信した暗号化されたコンテンツ・データをAKEで交換した鍵Kxを用いてコンテンツの復号鍵Kcを算出し、暗号コンテンツを復号するブロックである。ここで復号されたコンテンツは、コンテンツ再生/記録ブロックへ渡される。
【0071】
コンテンツ再生/記録ブロックは、渡されたコンテンツを、再生モードの場合は再生を行ない、記録モードの場合は保存する。但し、コンテンツの記録動作は、コンテンツ伝送用のパケットPCP内に挿入されているコピー制御情報の規定に従う。
【0072】
DTCP−IPコンテンツ受信ブロックは、AKEを実施した後にSource機器とのコンテンツ伝送手続きを実行する処理モジュールである。図示の例では、DTCP−IPコンテンツ受信ブロックはHTTPクライアント・ブロックを持ち、HTTPクライアントとしてHTTPサーバへコンテンツを要求し、応答されたコンテンツをHTTPサーバから受信する。
【0073】
HTTPクライアント・ブロックは、HTTPリクエスト管理ブロックとHTTPレスポンス管理ブロックに分かれる。さらに、HTTPリクエスト管理ブロックは、HTTPリクエスト送信ブロックとHTTPリクエスト生成ブロックに分かれる。
【0074】
HTTPリクエスト生成ブロックは、送信するコンテンツ伝送要求(HTTPリクエスト)を生成する。ここで生成されたHTTPリクエストは、HTTPリクエスト送信ブロックによりサーバへ送信される。
【0075】
HTTPレスポンス管理ブロックは、HTTPレスポンス受信ブロックとHTTPレスポンス解釈ブロックに分かれる。サーバから返信されるHTTPレスポンスと暗号化されたコンテンツは、HTTP受信ブロックで受信される。ここで受信したHTTPレスポンスは、HTTPレスポンス解釈ブロックでチェックされる。ここでのチェックがOKの場合は受信した暗号化コンテンツをDTCP認証ブロック内のコンテンツ復号ブロックへ送る。また、このチェックがNGの場合は、エラー・レスポンスとしての処理を行なう。Source機器からのHTTPレスポンスは1つ以上のPCPからなる。
【0076】
DTCP−IP認証ブロックとDTCP−IPコンテンツ受信ブロックは、サーバ機器との間で個別のTCP/IPコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。
【0077】
また、図3に示すSource機器は、DTCP−IP規格に準拠しており、DTCP_Sourceとして動作する。サーバ機器は、機能ブロックとして、DTCP−IP認証ブロックと、DTCP−IPコンテンツ送信ブロックと、コンテンツ管理ブロックを備えている。
【0078】
DTCP−IP認証ブロックは、認証手続き実行手段に相当し、AKEブロックと、メッセージ・ダイジェスト生成ブロックと、コンテンツ暗号化ブロックを備えている。
【0079】
AKEブロックは、DTCP−IPにおけるAKE機構(DTCP_Source側)を実現するブロックである。このブロックは、後述のメッセージ・ダイジェスト生成ブロックから要求されたパラメータを渡す機能も備えている。AKEブロックは認証したDTCP_Sink機器に関する情報を認証した機器の数だけ保持し、それをクライアントからコンテンツが要求された際に認証済みのクライアントかどうかを判別するのに使用する。
【0080】
メッセージ・ダイジェスト生成ブロックは指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックである。メッセージ・ダイジェストを生成するアルゴリズムはあらかじめ用意されたアルゴリズムを指定できる。あらかじめ用意されたアルゴリズムとは、例えばMD5やSHA−1といった一方向性ハッシュ関数に関するアルゴリズムが挙げられる(同上)。
【0081】
メッセージ・ダイジェスト生成ブロックは、DTCP−IP認証ブロックの外に公開してはならないAKEブロックが保持するパラメータのメッセージ・ダイジェストを生成できるようにAKEブロックと密に配置され、AKEブロックへパラメータを要求して取得することが可能で、そのパラメータ若しくは外部から与えられたパラメータのメッセージ・ダイジェストを作成することができる。
【0082】
コンテンツ暗号化ブロックは、DTCP−IPコンテンツ送信ブロックの要求に応じてコンテンツ管理ブロックより読み出したコンテンツ・データを、AKEで交換した鍵Kxから生成したコンテンツ鍵Kcを用いて暗号化するブロックである。ここで復号されたコンテンツは、クライアントへ送信するために、DTCP−IPコンテンツ送信ブロックへ渡される。
【0083】
コンテンツ管理ブロックは、DTCP−IPの機構を用いて保護されるべきコンテンツを管理するブロックである。コンテンツ暗号化ブロックの読み出しに応じて、コンテンツのデータを渡す。
【0084】
DTCP−IPコンテンツ送信ブロックは、HTTPサーバ・ブロックを持ち、HTTPサーバとしてクライアントからのリクエストを受理し、要求に応じた処理を実行する。
【0085】
HTTPサーバ・ブロックは、HTTPリクエスト管理ブロックとHTTPレスポンス管理ブロックに分かれる。さらに、HTTPリクエスト管理ブロックは、HTTPリクエスト受信ブロックと、HTTPリクエスト解釈ブロックに分かれる。
【0086】
HTTPリクエスト受信ブロックは、クライアントからのHTTPリクエストを受信する。受信したHTTPリクエストはHTTPリクエスト解釈ブロックに送られ、チェックされる。HTTPリクエスト解釈ブロックにおけるチェックがOKの場合、HTTPリクエストの情報をDTCP−IP認証ブロックへ通知する。
【0087】
HTTPレスポンス管理ブロックは、HTTPレスポンス生成ブロックとHTTPレスポンス送信ブロックに分かれる。
【0088】
HTTPレスポンス生成ブロックは、HTTPリクエスト解釈ブロックでのチェックがOKの場合、暗号化されたコンテンツを返すためのHTTPレスポンスを作成する。HTTPレスポンスは1つ以上のPCPからなる。一方、HTTPリクエスト解釈ブロックでのチェックがNGの場合、エラーを返すためのHTTPレスポンスを作成する。
【0089】
HTTPレスポンス送信ブロックは、作成されたHTTPレスポンスを、要求元のクライアントへHTTPレスポンスを送信する。また、HTTPリクエスト解釈ブロックでのチェックがOKの場合には、HTTPレスポンス・ヘッダに続けて、DTCP−IP認証ブロック内のコンテンツ暗号化ブロックで暗号化したコンテンツを送信する。
【0090】
DTCP−IP認証ブロックとDTCP−IPコンテンツ送信ブロックは、Sink機器との間で個別のTCP/IPコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。
【0091】
なお、DTCP−Sink機器及びDTCP−Source機器のいずれもがDTCP−IP認証ブロック内に持つメッセージ・ダイジェスト生成ブロックは、DTCP−IP自体で規定される機能モジュールではなく、また本発明の要旨には直接関連しない。
【0092】
B.HTTPを利用したコンテンツ伝送
この項では、DTCP−IPに従ったコンテンツの伝送手順について説明する。図4には、DTCP_Source機器とDTCP_Sink機器の間でAKEに基づく鍵交換手続き、及び鍵交換により共有した鍵を利用した暗号化コンテンツ伝送を行なう仕組みを図解している。
【0093】
DTCP_SourceとDTCP_Sinkは、まず1つのTCP/IPコネクションを確立し、機器同士の認証を行なう。この認証を、DTCP認証若しくはAKE(Authenticationand Key Exchange)と言う。DTCP準拠機器には、DTLA(前述)により発行された機器証明書が埋め込まれている。DTCP認証手続きでは、互いが正規のDTCP準拠機器であることを確かめた後、認証鍵KauthをDTCP_Source機器とDTCP_Source機器で共有することができる。
【0094】
AKE手続きが成功すると、DTCP_Source機器はコンテンツ鍵Kcの種となる種鍵Kxを生成し、認証鍵Kauthで暗号化してDTCP_Sink機器に送る。種鍵Kxは、コンテンツ伝送時にコンテンツを暗号化するためのコンテンツ鍵Kcを生成するために使用される。そして、DTCP準拠の機器間でAKEによる認証及び鍵交換手続きが済んだ後、DTCP_Sink機器はDTCP_Source機器上のコンテンツを要求する。DTCP_Source機器は、CDS(ContentDirectory Service)などを通じてDTCP_Sink機器にDTCP_Source機器上のコンテンツへのアクセス先を示すコンテンツ場所をあらかじめ伝えることができる。DTCP_Sinkがコンテンツを要求するとき、HTTPやRTPなどのプロトコルを利用することができる。
【0095】
図4に示すようにHTTPの手続きに従ってコンテンツを要求する場合、DTCP_SourceがHTTPサーバとなり、DTCP_SinkがHTTPクライアントとなって、コンテンツの伝送を開始する。ちなみに、RTPによる伝送を要求するとき、DTCP_SourceがRTPSenderとなり、DTCP_SinkがRTP Receiverとなってコンテンツの伝送を開始する。HTTPでコンテンツ伝送を行なう際、DTCP認証のためのTCP/IPコネクションとは別に、HTTPのためのTCP/IPコネクションがHTTPクライアントより作成される(すなわち、DTCP_Source機器とDTCP_Sink機器はそれぞれ、AKE手続き用とコンテンツ伝送用に個別のソケット(IPアドレスとポート番号の組み合わせ)を持つ)。そして、HTTPクライアントは、通常のHTTPと全く同様の動作手順によりHTTPサーバ上のコンテンツを要求する。これに対し、HTTPサーバは、要求通りのコンテンツをHTTPレスポンスとして返す。
【0096】
HTTPレスポンスとして伝送されるデータは、HTTPサーバすなわちDTCP_Source機器がAKE認証をした後に共有した鍵を用いてコンテンツを暗号化したデータとなっている。具体的には、DTCP_Source機器は、乱数を用いてノンスNcを生成して、種鍵KxとノンスNcと暗号モードを表すE−EMIを基にコンテンツ鍵Kcを生成する。そして、DTCP_Sink機器から要求されているコンテンツを、コンテンツ鍵Kcを用いて暗号化し、暗号化コンテンツからなるペイロードとノンスNcとE−EMIを含んだヘッダからなるパケットであるPCP(Protected Content Packet)をTCPストリーム上に乗せて送信する。そして、IPプロトコルは、TCPストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダ部を付加したIPパケットにし、指定されたIPアドレス宛てに届ける。
【0097】
DTCP_Sink機器側では、DTCP_Source機器からの各IPパケットを受信すると、これをTCPストリームに組み立てて、送信されたPCPを取り出す。そして、ストリームからノンスNcとE−EMIを取り出すと、これらと種鍵Kxを用いて同様にコンテンツ鍵Kcを算出し、暗号化コンテンツを復号することができる。そして、復号化した後の平文のコンテンツに対し再生若しくは記録などの処理を実施することができる。そして、HTTPプロトコルを利用したコンテンツ伝送が終了すると、例えばDTCP−Sink機器側から、使用したTCPコネクションを適宜切断する。
【0098】
また、長大なTCPストリーム全体に渡り同じ暗号鍵を使用し続けると、鍵が解読される危険は高くなる。このため、DTCP−IPでは、Source機器は128MB毎にノンスNcすなわちコンテンツ鍵Kcを更新する(1ずつインクリメントする)よう取り決められている。バイト・ストリーム中で、同じノンスNcから生成されたコンテンツ鍵Kcを用いて暗号化されたデータの範囲は、同じ鍵を用いて復号することができる復号化単位となる。
【0099】
DTCP−IPではさらにコンテンツ鍵の確認手続きが必要となる。すなわち、DTCP_Sink機器は、コンテンツ伝送用のTCPコネクションとは別に、コンテンツ鍵の確認用のTCPコネクションをさらに確立し、DTCP_Source機器に対しコンテンツ鍵確認のための手続きを行なう。DTCP_Sink機器は、コンテンツ鍵の確認が必要になると、適宜このTCPコネクションを確立する。例えば、DTCP−IP Volume 1 Supplement E.8.6には、コンテンツ鍵の確認手続きとして“Content Key Confirmation”を規定している。これによれば、Sink機器は、CONT_KEY_CONF subfunctionを用いて、現在のノンスNcに関連付けられたコンテンツ鍵の確認を行なう。
【0100】
既に述べたように、DTCP−IPでは、ノンスNcを含んだヘッダと、暗号化コンテンツからなるペイロードで構成される、PCPというパケット形式でコンテンツ伝送が行なわれる。
【0101】
図5には、PCPのデータ構造を模式的に示している。PCPヘッダは平文であり、ノンスNcが含まれている。また、PCPペイロードはノンスNcで決まるコンテンツ鍵Kcで暗号化されたコンテンツ(但し、コピー制御情報として“copy−free”が指定されているコンテンツは暗号化不要)で構成される。ここで、PCPペイロードは、常に16バイトの倍数になるように、必要に応じて暗号化前にpaddingが行なわれる。また、コンテンツの安全のため、定期的にノンスNcすなわちコンテンツ鍵Kcを更新するが、その時点でもPCPは仕切られる(コンテンツ鍵Kcを更新しなくても複数のPCPに仕切ることは可能)。また、protected_content_lengthの値が16の整数倍でないときは、コンテンツに1〜15バイトのパディングが付く。ノンスNcの更新に伴い、コンテンツ鍵確認手続を起動するのは上述した通りである。ちなみに、HTTPレスポンスは1つ以上のPCPからなり、RTPペイロードは1つのPCPからなる。図6には、PCPをパディングする様子を示している。
【0102】
C.コピー制御情報の伝送
DTCP−IPのように著作権の保護を目的としたコンテンツ伝送システムにおいては、コンテンツを暗号化伝送する際に、コンテンツ保護に関するコンテンツ属性を指定する必要がある。
【0103】
DTCP−IPでは、PCPヘッダにPCPペイロードの暗号モード及びコピー情報を指定する4ビットのE−EMIフィールドを設けることと、PCPペイロードすなわちコンテンツ・ストリームの一部としてコピー制御情報Embedded CCIを伝送することが規定されている。しかしながら、Embedded CCIに関しては、MPEGトランスポート・ストリームについてのみDTCPディスクリプタとして記述することが規定されているのみで、Embedded CCIの定義やフォーマットはコンテンツ・フォーマット毎に区々になっているのが現状である。このため、Embedded CCIの記述方法がコンテンツ・フォーマットに依存することとなり、コピー制御情報を作成並びに解読するソフトウェア又はハードウェアのモジュールをフォーマット毎に用意しなければならず、機器コストが増大するという問題がある。
【0104】
そこで、本実施形態では、E−EMIをPCPヘッダに記載するとともに、ヘッダには書ききれないコピー制御情報をEmbedded CCIとしてPCPペイロード埋め込んでコンテンツを暗号化伝送するという旧来のDTCP−IPシステムにおいて、旧来通り(すなわちLegacy)のSource機器及びSink機器との互換性を保ちながら、必要となるコピー制御情報をすべてPCPヘッダに記載するコンテンツ伝送方式を採用している。
【0105】
PCPヘッダ部にコピー制御情報を埋め込む場合、コンテンツのフォーマットに依存しないことから、すべてのコンテンツ・フォーマットに共通の形式でコピー制御情報を伝送することが可能になる。この結果、Source機器側においてコピー制御情報を作成し、Sink機器側においてコピー制御情報を解析するためのソフトウェア又はハードウェアのモジュールをすべてのフォーマットで共通化することにより、機器コストを削減することができる。
【0106】
図31を参照しながら既に説明したように、PCPヘッダには、E−EMIとともにノンス情報フィールドが設けられている。E−EMIは4ビットしかないので、もはやそれ以外のコピー制御情報(すなわち超拡張コピー制御情報)を記載する余裕はない。他方、ノンスNcは、コンテンツを暗号化するコンテンツ鍵Kcを生成する基となる情報であり64ビット長のフィールドがヘッダ内で割り当てられている。コンテンツ中でE−EMIが変わる度、また定期的にノンスNcは更新する。通常、更新する機会毎にノンスNcの値を単調に増大させる(1ずつインクリメントしていく)ため、64ビットを必要としない。そこで、本実装形態では、旧来のPCPヘッダ内のノンス情報フィールドの一部の領域を用いて超拡張コピー制御情報を伝送するようにしている。
【0107】
本明細書では、E−EMI以外にPCPヘッダに挿入される超拡張コピー制御情報のことを“PCP−CCI”と呼ぶことにする。図7には、本実施形態で採用するPCPヘッダのデータ構造を示している。同図の例では、旧来のPCPヘッダ内のノンス情報フィールドの上位8ビットを用いてPCP−CCIを記述し、残りの下位56ビットに通常通り生成するノンスNc’の値を書き込むようにしている。64ビットのノンス情報Ncフィールドの上位8ビットにPCP−CCIを埋め込んでも、コンテンツ鍵Kcの安全性は残りの56ビットで実用に耐えられる。
【0108】
図7からも分るように、PCPヘッダ部の基本的な構造やサイズは旧来のものと変更されない。この場合、本実施形態に係るコンテンツ伝送方式に対応したSource機器及びSink機器は、旧来の64ビットのノンス情報フィールド中のうち上位8ビットをPCP−CCIフィールドとして利用するとともに、PCP−CCI情報が書き込まれた上位8ビットと擬似的なノンスNc’の値が書き込まれた56ビットのビット連結からなる64ビット全体をノンスNcとして用いてコンテンツ鍵Kcの生成を行なう。この場合、不正コピー目的でPCP−CCIを改竄しても、ノンスNcを改竄することとなり、結局はコンテンツを復号できなくなるので、セキュリティも維持される。
【0109】
一方、旧来通りの機器も、旧来の64ビットのノンス情報フィールド全体に書き込まれた値をノンスNcとして解釈する。この場合、上位8ビットにPCP−CCIが書き込まれることからPCP−CCIがストリームの途中で変化した場合にはノンスNcの値の連続性が失われ、本発明に係る伝送方式に対応していないSink機器にとって、いわゆるLegacy問題が発生する。また、本発明に係る伝送方式に対応したSink機器においても、PCPすなわちコンテンツ伝送元であるSource機器が本方式を適用しているかどうか、すなわち上位8ビットにPCP−CCIが記載されているかどうかを特定しなければならず、同様にLegacy問題が発生する。但し、この問題の解決方法については後述に譲る。
【0110】
図8には、PCP−CCIフィールドのフォーマット構成例を示している。
【0111】
DTCPでは、アナログ出力制御に関する2ビットのパラメータ(APS)や、出力時の画サイズに関する1ビットの情報フラグ(ICT)といった出力制御情報がコピー制御情報の構成要素となっている。これらE−EMIには書ききれない情報がPCP−CCI内に割り当てられている。また、Ignoreビットは、下位56ビットの擬似的なNc’がカウントアップした結果、値が繰り上がってもPCP−CCIの他のフィールドに影響が出ないようにするためのフィールドである。Source機器は、Ignoreビットの初期値として“0”を設定し、擬似的なノンスNc’がカウントアップした結果、値が繰り上がった場合に“1”となる。
【0112】
また、PCP−CCIフィールドの有効性を記述した2ビットの情報フィールド“Mode”や、E−EMIと本来のEmbedded CCIの代用可能性に関する1ビットの情報フラグ“SE(Substitute for Embedded CCI)”も、PCP−CCI内に割り当てられている。このようなPCP−CCIをヘッダ部の一部として構成することにより、コンテンツのフォーマットに依存せずすべてのフォーマットに共通の形式でコピー制御情報を伝送することが可能になる。そして、暗号化ペイロードにEmbedded CCIが含まれていない場合でも、従来はEmbedded CCIとEMIの組み合わせにより指定していたコピー制御機能、つまりにcognizant機能を実現することが可能である。
【0113】
Modeビット・フィールドはPCP−CCIフィールドの意味若しくは有効性を表す。Mode=00bのときはPCP−CCIフィールドが情報を持たないことを表す。また、Mode=01bのときはペイロードがAudio/Visualコンテンツであることを表し、Mode=10bのときはペイロードがType1 Audioコンテンツであることを表す(例えば、DTCP Specification Volume 1 Version1.4(Informational Version) Appendix A Additional Rules for Audio Applicationsを参照のこと)。Mode=11bはReservedとする。また、Mode=01b又はMode=10bのときはAPS、ICTビットの意味を持ち、そのビットの意味はDTCPの規定(非特許文献5を参照のこと)に準ずる。
【0114】
図9には、Sink機器がModeビット・フィールドに基づいてPCP−CCIフィールドの意味を識別するための処理手順をフローチャートの形式で示している。
【0115】
Mode=00b、すなわちPCP−CCIフィールドが情報を持たない場合には(ステップS1のYes)、さらに復号したコンテンツを検査する。そこで、Sink機器が識別可能なEmbedded CCIを検出できなければ(ステップS4のNo)、Non Cognizantとして処理する(ステップS11)。一方、Embedded CCIが検出できた場合には(ステップS4のYes)、検出されたEmbedded CCIがAudio/Visual用のCCIかどうかを判別する(ステップS5)。そして、Audio/Visual用であれば、Audio/Visual Cognizantとして処理し(ステップS10)、それ以外であればAudio Cognizantとして処理する(ステップS9)。
【0116】
また、Mode=01bすなわちPCP−CCIフィールドがAudio/Visualの情報であれば(ステップS2のYes)、さらに復号したコンテンツを検査する。そこで、Sink機器が識別可能なEmbedded CCIを検出できなければ(ステップS6のNo)、Non Cognizantとして処理する(ステップS11)。一方、Embedded CCIを検出できた場合には、Audio/Visual Cognizantとして処理する(ステップS10)。
【0117】
また、Mode=10bすなわちPCP−CCIフィールドがAudio Type1の情報であれば(ステップS3のYes)、さらに復号したコンテンツを検査する。Sink機器が識別可能なEmbedded CCIを検出できなければ(ステップS7のNo)、Non Cognizantとして処理する(ステップS11)。一方、Embedded CCIを検出できた場合には、Audio Cognizantとして処理する(ステップS9)。
【0118】
また、Modeが上記以外の値すなわち11bのときは、Reservedとする(ステップS8)。
【0119】
図9には、Modeビット・フィールドに基づいてPCP−CCIフィールドの意味を識別するための処理手順を示したが、その変形例として、Modeビット・フィールドとSEビット・フラグの組み合わせに基づいてPCP−CCIフィールドの意味を識別することができる。図10にはこの場合の処理手順をフローチャートの形式で示している。
【0120】
Mode=00b、すなわちPCP−CCIフィールドが情報を持たない場合には(ステップS21のYes)、さらに復号したコンテンツを検査する。そこで、Sink機器が識別可能なEmbedded CCIを検出できなければ(ステップS24のNo)、Non Cognizantとして処理する(ステップS31)。一方、Embedded CCIが検出できた場合には(ステップS24のYes)、検出されたEmbedded CCIがAudio/Visual用のCCIかどうかを判別する(ステップS25)。そして、Audio/Visual用であれば、Audio/Visual Cognizantとして処理し(ステップS30)、それ以外であればAudio Cognizantとして処理する(ステップS29)。
【0121】
また、Mode=01bすなわちPCP−CCIフィールドがAudio/Visualの情報であれば(ステップS22のYes)、さらにSEビット・フラグをチェックする。ここで、SE=1bであれば(ステップS32のYes)、Audio/Visual Cognizantで処理するとともに、E−EMIでEmbedded CCIを代用する(ステップS34)。
【0122】
また、Mode=01bで(ステップS22のYes)、且つSE=1bでなければ(ステップS32のNo)、さらに復号したコンテンツを検査する。そこで、Sink機器が識別可能なEmbedded CCIを検出できなければ(ステップS26のNo)、Non Cognizantとして処理する(ステップS31)。一方、Embedded CCIを検出できた場合には、Audio/Visual Cognizantとして処理する(ステップS30)。
【0123】
また、Mode=10bすなわちPCP−CCIフィールドがAudio Type1の情報であれば(ステップS23のYes)、さらにSEビット・フラグをチェックする。ここで、SE=1bであれば(ステップS33のYes)、Audio Cognizantで処理するとともに、E−EMIでEmbedded CCIを代用する(ステップS35)。
また、Mode=10bで(ステップS23のYes)、且つSE=1bでなければ(ステップS33のNo)、さらに復号したコンテンツを検査する。そして、Sink機器が識別可能なEmbedded CCIを検出できなければ(ステップS27のNo)、Non Cognizantとして処理する(ステップS31)。一方、Embedded CCIを検出できた場合には、Audio Cognizantとして処理する(ステップS29)。
【0124】
また、Mode=10bで(ステップS23のYes)、且つSE=1bでなければ(ステップS33のNo)、さらに復号したコンテンツを検査する。そして、Sink機器が識別可能なEmbedded CCIを検出できなければ(ステップS27のNo)、Non Cognizantとして処理する(ステップS31)。一方、Embedded CCIを検出できた場合には、Audio Cognizantとして処理する(ステップS29)。
【0125】
また、Modeが上記以外の値すなわち11bのときは、Reservedとする(ステップS28)。
【0126】
また、SE=1bのときはコンテンツにEmbedded CCIが含まれておらず、E−EMIフィールドでEmbedded CCIを代用することを表す。図11には、Modeビット・フィールド及びSEビット・フラグの値の組み合わせに基づいてE−EMIをEmbedded CCIとして代用することが可能かどうかを判別するための処理手順をフローチャートの形式で示している。
【0127】
Mode=00bであれば、PCP−CCIフィールドが情報を持たず(ステップS41のYes)、E−EMIをEmbedded CCIとして代用することができない(ステップS46)。
【0128】
Mode=01bすなわちPCP−CCIフィールドがAudio/Visual情報である場合(ステップS42)、並びに、Mode=10bすなわちPCP−CCIフィールドがAudio情報である場合には(ステップS43)、さらにSEビットのフラグ値を確認する(ステップS44)。
【0129】
ここで、SEフラグがセットされていれば、E−EMIをEmbedded CCIとして代用できると判断する(ステップS45)。また、SEフラグがセットされていなければ、E−EMIをEmbedded CCIとして代用できないと判断する(ステップS46)。
【0130】
また、Modeが上記以外の値すなわち11bのときは、Reservedとする(ステップS46)。
【0131】
D.Legacy問題の解決
上述した実施形態では、コピー制御情報をパケットのヘッダ部とペイロード部(すなわちコンテンツ・ストリーム)に分けて記載する方法が採用されている暗号化伝送方式において、PCPヘッダ内のノンス情報フィールドの上位8ビットを用いてPCP−CCIを記述し、残りの下位56ビットに擬似的なノンスNc’を書き込むようにすることで、(DTCP−IPで)要求されるコピー制御を実現するために必要となるコピー制御情報をすべてヘッダ部に記載するようにした。この場合、ヘッダ部にはコンテンツのフォーマットに依存せず、すべてのフォーマットに共通の形式でコピー制御情報を挿入することができるので、コピー制御情報を作成し解析するためのソフトウェア又はハードウェアのモジュールをすべてのフォーマットで共通化することができ、機器コストを削減することができる。
【0132】
ところが、LegacyのSink機器の場合、64ビットのノンス情報フィールド全体に書き込まれた値をノンスNcとして解釈することから、上位8ビットにPCP−CCIが書き込まれると、PCP−CCIが変更されたときにノンスNcの値の連続性が失われることになり、コンテンツ鍵確認手続を起動する、というLegacy問題が発生する。また、本発明に係る伝送方式に対応したSink機器においても、コンテンツ伝送元であるSource機器が本方式を適用しているかどうか、すなわちPCPヘッダ中にPCP−CCIが記載されているかどうかを特定しなければならず、同様にLegacy問題が発生する。この項ではこれらのLegacy問題の解決方法について説明する。
【0133】
図12には、LegacyのSource機器とSink機器間でPCPを伝送する仕組みを図解している。
【0134】
Source機器側では種鍵Kxを生成すると、AKE手続を経てSink機器との間で種鍵Kxを共有する。
【0135】
また、Source機器は、上位層アプリケーションから伝送用のコンテンツが供給されると、E−EMI設定部は、コンテンツ・ストリームに関連付けられたコピー制御情報に従って正しい暗号モードを選択し、これに基づいてE−EMIを設定する。また、常に16バイトの倍数となるようにパディングを行ない、PCPデータ・バッファに一時格納する。
【0136】
コンテンツ鍵生成部は、種鍵KxとE−EMIと、ノンス生成部が乱数生成などにより生成した64ビット長のノンスNcに所定の演算処理を施してコンテンツ鍵Kcを生成する。ノンス生成部は、定期的にノンスNcを1ずつインクリメントするので、これに応じてコンテンツ鍵Kcも定期的に更新されることになる。
【0137】
AES−CBC(Advances Encryption Standard−Cipher Block Chainng)暗号化部は、PCPデータ・バッファからパディングされたPCPペイロードを順次取り出し、現在のコンテンツ鍵Kcで暗号化処理を施す。
【0138】
PCPヘッダ付加部は、E−EMI設定部で設定されたE−EMIを含んだPCPヘッダを生成し、これを暗号化されたPCPペイロードの先頭に取り付けてPCPを完成する。このときのPCPヘッダのデータ・フォーマットは図31に示した通りである。そして、コンテンツ要求元としてのSink機器から要求されるHTTP又はRTPなどのプロトコルに従ってPCPを送出する。
【0139】
一方、Sink機器側では、Source機器とのAKE手続を経て種鍵Kxを共有する。
【0140】
また、HTTP又はRTPなどのプロトコルに従ってSource機器からPCPを受信すると、まずPCPヘッダ抽出部がPCPヘッダとPCPペイロードに分離する。そして、PCPヘッダからはノンスNcやE−EMIが取り出される。
【0141】
コンテンツ鍵生成部は、種鍵KxとPCPヘッダから取り出されたE−EMIとノンスNcに所定の演算処理を施してコンテンツ鍵Kcを生成する。コンテンツ鍵確認部はノンスNcの連続性を検査し、不連続を検出した場合はコンテンツ鍵確認手続を起動する。
【0142】
AES−CBC暗号解読部は、PCPペイロードに対し、現在のコンテンツ鍵Kcで暗号解読処理を施す。解読後のPCPペイロードはPCPデータ・バッファに一時格納され、パディングされたデータを取り除いて、元のコンテンツが再現される。Embedded CCI検出部は、再現されたコンテンツを検査し、Embedded CCIを検出する。
【0143】
また、図13には、PCP−CCIをPCPヘッダに埋め込む伝送方式を適用したSource機器とSink機器間でPCPを伝送する仕組みを図解している。
【0144】
Source機器側では種鍵Kxを生成すると、AKE手続を経てSink機器との間で種鍵Kxを共有する。
【0145】
また、Source機器は、上位層アプリケーションから伝送用のコンテンツが供給されると、E−EMI/PCP−CCI設定部は、コンテンツ・ストリームに関連付けられたコピー制御情報に従って正しい暗号モードを選択し、これに基づいてE−EMIを設定し、さらにPCP−CCIを設定する(PCP−CCI中のModeビット・フィールド並びにSEビット・フラグの設定方法については非特許文献5を参照されたい)。PCP−CCIは8ビット長であり、そのデータ・フォーマットは図8に示した通りである。また、常に16バイトの倍数となるようにパディングを行ない、PCPデータ・バッファに一時格納する。
【0146】
擬似ノンスNc’生成部は、乱数生成などにより56ビット長の擬似的なノンスNc’を生成する。ノンスNc生成部は、擬似ノンスNc’の上位にPCP−CCIをビット連結して、64ビット長のノンスNcを作成する。
【0147】
コンテンツ鍵生成部は、種鍵KxとE−EMIと、ノンス生成部が作成した64ビット長のノンスNcに所定の演算処理を施してコンテンツ鍵Kcを生成する。ノンスNc生成部は、定期的にノンスNcを1ずつインクリメントするので、これに応じてコンテンツ鍵Kcも定期的に更新されることになる。但し、PCP−CCI情報が変化すると、擬似的なノンスNc’部分は連続的であっても、64ビット全体で扱われるノンスNcの連続性は失われる。
【0148】
AES−CBC暗号化部は、PCPデータ・バッファからパディングされたPCPペイロードを順次取り出し、現在のコンテンツ鍵Kcで暗号化処理を施す。
【0149】
PCPヘッダ付加部は、E−EMI設定部で設定されたE−EMIを含んだPCPヘッダを生成し、これを暗号化されたPCPペイロードの先頭に取り付けてPCPを完成する。このときのPCPヘッダのデータ・フォーマットは図7に示した通りである。そして、コンテンツ要求元としてのSink機器から要求されるHTTP又はRTPなどのプロトコルに従ってPCPを送出する。
【0150】
一方、Sink機器側では、Source機器とのAKE手続を経て種鍵Kxを共有する。
【0151】
また、HTTP又はRTPなどのプロトコルに従ってSource機器からPCPを受信すると、まずPCPヘッダ抽出部がPCPヘッダとPCPペイロードに分離する。そして、PCPヘッダからはノンスNcやE−EMI及びPCP−CCIが取り出される。
【0152】
ノンスNc取得部は、PCPヘッダ中の64ビット長のノンス情報を取得する。コンテンツ鍵確認部は、ノンスNcの下位56ビットの連続性を検査し、不連続を検出した場合はコンテンツ鍵確認手続を起動する。
【0153】
コンテンツ鍵生成部は、種鍵KxとPCPヘッダから取り出された64ビット長のノンスNcに所定の演算処理を施してコンテンツ鍵Kcを生成する。
【0154】
また、PCP−CCI取得部は、ノンスNc取得部から64ビット長のノンス情報フィールドのうち上位8ビットをPCP−CCIとして取得する。そして、PCP−CCI中のModeビット・フィールド並びにSEビット・フラグのビット値及びEmbedded CCI検出部の検出結果に基づいて、図10に示した手順に従い、コンテンツ・フォーマットの認識(Cognizant)並びにE−EMIのEmbedded CCI代用性を決定する。
【0155】
AES−CBC暗号解読部は、PCPペイロードに対し、現在のコンテンツ鍵Kcで暗号解読処理を施す。解読後のPCPペイロードはPCPデータ・バッファに一時格納され、パディングされたデータを取り除いて、元のコンテンツが再現される。Embedded CCI検出部は、再現されたコンテンツを検査し、Embedded CCIを検出する。
【0156】
ここで、PCP−CCIは平文の状態でPCPヘッダに記述されることから、PCPペイロードに埋め込んで暗号化する場合に比べると改竄が容易になる。しかしながら、PCP−CCIはノンスNcの上位8ビットを構成することから、これを改竄することは、ノンスNcすなわちコンテンツ鍵Kcをも改竄することとなり、結局はコンテンツを復号できなくなるので、セキュリティも維持される。
【0157】
図14には、図12に示したLegacyのSource及びSink機器と、図13に示した新方式のSource及びSink機器が混在するコンテンツ伝送環境下においてLegacy問題が発生する様子を模式的に示している。
【0158】
図12に示したSource及びSink機器間でのPCPの伝送、並びに図13に示したSource及びSink機器間でのPCPの伝送は問題なく処理されることは上述した通りである。
【0159】
これに対し、新方式のSource機器が送出するPCPヘッダにPCP−CCIを埋め込んだPCP(New PCP with PCP−CCI)をLegacyのSink機器が受信したとき、上位8ビットにPCP−CCIが書き込まれることによりノンスNcの値の連続性が失われるので(例えばPCP−CCI情報が変化したとき)、コンテンツ鍵確認手続を起動する、という第1のLegacy問題が発生する。
【0160】
また、PCPヘッダにPCP−CCIを埋め込んだPCP(New PCP with PCP−CCI)に対応したSink機器の場合、コンテンツの要求先であるSource機器がLegacy又は新方式のいずれであるかを正しく識別しなければならないという第2のLegacy問題が発生する。識別を誤ると、PCPヘッダに埋め込まれているPCP−CCIを読み取ることができない、あるいは64ビットのノンス情報フィールドの上位8ビットを誤ってPCP−CCIと認識してしまうことになる。
【0161】
第1のLegacy問題に関しては、コンテンツ鍵確認手続は起動されるが、Source機器側では、コンテンツ鍵確認要求に対し、ノンスNcに異常がないことを示すレスポンス(ACCEPTEDコマンド)を返すので、LegacyのSink機器は以降も障害なくコンテンツ受信処理を継続することができ、実用上の問題は発生しない。
【0162】
DTCP−IP Volume 1 Supplement SectionV1SE.8.6には、Content Key Confirmationについて規定している。これによれば、Sink機器は、コンテンツ・ストリーム毎に、最も新しく受信したPCPのノンスNcの値を確認し、さらに動的に変更される後続のノンスについても2分間隔で再確認しなければならない(但し、Sink機器がノンスを初期確認した後に後続のノンスNcの値が単調に増大する連続的な数値であることを監視し確認する場合には、周期的なコンテンツ鍵確認の手続きを省略することができる)。Sink機器は、CONT_KEY_CONF subfunctionを用いて、現在のノンスNcに関連付けられたコンテンツ鍵の確認を行なうことができる。
【0163】
各コンテンツ・ストリームにおいて、Sink機器は、未確認の初期ノンスを取得すると、当該コンテンツ・ストリームに関して暗号化コンテンツの復号を終了しなければならなくなる前に、コンテンツ鍵の確認を再試行する猶予期間が1分間だけ与えられる。そして、Sink機器は、この猶予期間を利用してノンスNcの確認に成功すると、暗号化コンテンツの復号動作を終了することなく継続することができる。
【0164】
図15には、コンテンツ鍵確認のためのSink機器とSource機器間の手続きを示している。但し、Rは64ビット値で、初期は乱数であるが、後続の試行では1 mod 264でインクリメントするとともに、以下の通りとする。
【0165】
MX=SHA1(Kx||Kx)
MAC3A=MAC3B=[SHA1(MX+NcT+R)]msb80
MAC4A=MAC4B=[SHA1(MX+NcT+R)]lsb80
(上式で、“+”はmod264の加算を意味するために使用される。)
【0166】
図示のコンテンツ確認手続きでは、Sink機器は、CONT_KEY_CONFコマンドにおいて、検査用のノンスNcTをSource機器に送る。
【0167】
Source機器側では、CONT_KEY_CONFコマンドを受信すると、検査用のノンスNcTを取り出して、現在のノンスNcと比較する。そして、現在のノンスNcがNcTとNcT+5の範囲にあるときには検査用のノンスNcTが有効であることを確認する。検査用のノンスNcTが有効であることを確認できたときには、さらにMAC3AとMAC3Bが等しいかどうかに基づいてコンテンツ鍵の確認を行なう。そして、コンテンツ鍵が正しかったことを示すACCEPTEDレスポンス、又は正しくなかったことを示すREJECTEDレスポンスのいずれかをSink機器に返す。
【0168】
Sink機器側では、Source機器からACCEPTEDレスポンスが返されたときには、さらにMAC4AとMAC4Bが等しいかどうかに基づいてコンテンツ鍵の確認を行なう。そして、Sink機器自身でコンテンツ鍵が正しいことを確認できた場合にはSink機器はconfirmed状態になる。
【0169】
一方、Source機器からACCEPTEDレスポンスが返されたがSink機器自身でのコンテンツ鍵確認に失敗した場合や、Source機器からREJECTEDレスポンスが返されたときには、Sink機器はnon−confirmation状態になる。
【0170】
ここで、confirmedはCONT_KEY_CONFによりコンテンツ鍵が正しいことが確認された状態、non−confirmationはCONT_KEY_CONFによりコンテンツ鍵が不正であることが確認された状態であり、いずれもDTCP Volume 1 Supplement E SectionV1SE8.6に規定されている。
【0171】
confirmed状態では、Sink機器は受信コンテンツの復号処理を継続して行なうことができる。他方、non−confirmation状態では、Sink機器は復号処理を継続できない。
【0172】
図16には、PCP−CCIに対応したSource機器がLegacyのSink機器との間でコンテンツ鍵確認手続きを行なうための処理手順をフローチャートの形式で示している。
【0173】
Source機器は、コンテンツ伝送先となるSink機器からコンテンツ確認を要求するCONT_KEY_CONFコマンドを受信すると(ステップS51)、コンテンツ鍵の確認を行なう(ステップS52)。具体的には、当該コマンドから検査用のノンスNcTを取り出して、現在のノンスNc、すなわち8ビット長のPCP−CCIと56ビット長の擬似的なノンスNc’をビット連結した値と比較する。そして、現在のノンスNcがNcTとNcT+5の範囲にあるときには検査用のノンスNcTが有効であることを確認する。
【0174】
そして、Source機器は、コンテンツ鍵が正しいことを確認した場合には その旨を示すACCEPTEDレスポンスをSink機器に返信するが(ステップS53)、コンテンツ鍵が不正であることを確認した場合にはその旨を示すREJECTEDレスポンスを返信する(ステップS54)。
【0175】
なお、ACCEPTED並びにREJECTEDはともにDTCP Volume 1 Supplement E SectionV1SE8.6に規定されている、コマンドに対するレスポンスである。
【0176】
また、図17には、LegacyのSink機器がPCP−CCIに対応したSource機器との間でコンテンツ鍵確認手続きを行なうための処理手順をフローチャートの形式で示している。
【0177】
Sink機器は、コンテンツ要求先となるSource機器に対しCONT_KEY_CONFコマンドを送信した後(ステップS61)、当該Source機器からのレスポンス受信を待機する(ステップS62)。
【0178】
ここで、Source機器からACCEPTEDレスポンスを受信したときには(ステップS63)、コンテンツ鍵を確認する(ステップS64)。このとき、コンテンツ鍵が正しい場合にはconfirmed(ステップS65)、コンテンツ鍵が不正である場合にはnon−confirmationである(ステップS67)。また、Sink機器がSource機器からREJECTEDレスポンスを受信したときには(ステップS66)、non−confirmationである(ステップS67)。
【0179】
ここで、confirmedはCONT_KEY_CONFによりコンテンツ鍵が正しいことが確認された状態、non−confirmationはCONT_KEY_CONFによりコンテンツ鍵が不正であることが確認された状態であり、いずれもDTCP Volume 1 Supplement E SectionV1SE8.6に規定されている。
【0180】
confirmedでは、Sink機器は受信コンテンツの復号処理を継続して行なうことができる。本実施形態では、Source機器は、検査用のノンスNcTを、8ビット長のPCP−CCIと56ビット長の擬似的なノンスNc’をビット連結した現在のノンスNcと比較するので、Sink機器から見るとノンスの変化が不自然であっても、confirmedである限り、コンテンツの受信及びその暗号解読を継続することができる。他方、non−confirmationでは、Sink機器は復号処理を継続できない。
【0181】
また、Sink機器は、最初のnon−confirmationとなってから1分間は複合処理を継続しながらコンテンツ鍵確認手続きを繰り返すことができるので(ステップS68)、ステップS41に戻り(ステップS70)、CONT_KEY_CONFコマンドを再発行する。
【0182】
コンテンツ鍵確認手続きを再試行して、1分以内にconfirmedとなれば(ステップS65)、受信コンテンツの復号処理を継続することができる。しかし、1分間non−confirmationが継続した場合には(ステップS68)、受信コンテンツの復号処理を停止しなければならない(ステップS69)。
【0183】
図18には、PCP−CCIに対応したSource機器(New Source)とLegacy Sinkの間で行なわれるコンテンツ鍵確認手続の動作シーケンスをまとめている。
【0184】
New Source側で、コンテンツの伝送中にPCP−CCIを変更すると、これに伴ってPCPヘッダに書き込まれるノンスNcの連続性が失われる。Legacy SinkはこのようなノンスNcのJumpを認識すると、コンテンツ鍵確認用のTCPコネクションを確立し、New Sourceに対しCONT_KEY_CONFコマンドを発行する。
【0185】
New Source側では、CONT_KEY_CONFコマンドからノンスNcTを取り出すと、更新後のPCP−CCIと現在の擬似的なノンスNc’をビット連結したノンスNcと比較する。そして、ノンスNcの改竄でないことを確認すると、Legacy Sinkに対しACCEPTEDレスポンスを返すとともに、継続してコンテンツを伝送する。これによって、Legacy Sinkは、コンテンツを継続して受信し解読処理を行なうことができる。
【0186】
また、第2のLegacy問題に関しては、相互認証手続(AKE)で交換する機器証明書の中にPCPヘッダ部に超拡張コピー制御情報を埋め込むことを示すCCIフラグを含めることによって、Sink機器はSource機器がLegacy機器でないことを認識することができる。あるいは、このようなCCIフラグを応答する能力確認用のコマンドを使用するようにしてもよい。
【0187】
PCP−CCIに対応した新規のDTCP機器は、例えばCCIフラグを1に設定された機器証明書を使用する。このCCIフラグは機器証明書内の予備(reserved)領域を使用することができる。Sink機器は、AKE手続きなどにおいて、Source機器の機器証明書をチェックして、PCP−CCIフィールドがPCPヘッダに存在するかどうかを安全に確認することができる。
【0188】
この場合、PCP−CCIに対応したSource機器は、PCPヘッダにPCP−CCIフィールドを埋め込んだ新しいフォーマットで、PCPパケットを常に送ることができる。一方、PCP−CCIに対応したSink機器は、新規のSource機器からコンテンツ・ストリームが到来したときには、そのPCPヘッダに含まれるPCP−CCIフィールドを使用することができる。
【0189】
図19には、Sink機器がSource機器のCCIフラグをチェックしてPCPヘッダ部のコピー制御情報を処理するための手順をフローチャートの形式で示している。
【0190】
Sink機器は、Source機器との間でコンテンツ伝送手続きの開始前にコンテンツ鍵交換及び認証手続(AKE)を行なう際に、当該Source機器はPCP−CCIをヘッダ部に埋め込んで送るかどうかを示す、CCIフラグの確認処理を実行する(S71)。同確認処理を実施する方法として数通りが考えられるが、詳細は後述に譲る。
【0191】
そして、CCIフラグを確認できたかどうかをチェックする(ステップS72)。確認できた場合には、コンテンツ伝送手続を開始し、Source機器からコンテンツ・ストリームをPCPとして受け取ったときに、PCPヘッダ中の64ビット長のノンス情報フィールドのうち上位8ビットをPCP−CCIとして参照する(ステップS73)。また、確認できなかった場合は、ノンス情報フィールドの上位8ビットをPCP−CCIとして参照しない(ステップS74)。
【0192】
ステップS71において確認処理を行なう方法、すなわちSource機器がPCPヘッダにPCP−CCIを埋め込んでいることを識別する具体的な1つの方法として、機器証明書の中にCCIフラグを含めることが挙げられる。
【0193】
この機器証明書は、例えばDTLAのように信頼のおけるライセンス・オーソリティによる電子署名が付加されているものとする。また、証明書の中にはその送信装置の公開鍵が含まれることで、チャレンジ・アンド・レスポンス型の認証手続きにおいて、送信側が自身の署名を付加したレスポンス(受信側からのチャレンジ・データを含む)を受信側に送り、受信側に対して自身の証明書が正当なものであることを示すことができる。
【0194】
図20には、機器証明書内にCCIフラグを埋め込むことによって、Source機器がPCP−CCI対応であることをSink機器に示す送受信シーケンス例を示している。
【0195】
まず、コンテンツ要求元であるSink機器から、Rx乱数とRx証明書を含んだRxチャレンジが送信される。これに対し、Source機器からは、Tx乱数及びTx証明書を含んだTxチャレンジが返信される。このTx証明書には、例えば予備領域の1ビットを使用して、CCIフラグがセットされている。Sink機器は、このCCIフラグをチェックして、Source機器がPCP−CCIに対応していることを確認する。
【0196】
以降、Source機器から、Rx乱数、Txメッセージ、Tx署名を含んだRxレスポンスが送信されるとともに、Sink機器からはTx乱数、Rxメッセージ、Rx署名を含んだTxレスポンスが送信され、通常のチャレンジ・アンド・レスポンス認証手続きが続く。
【0197】
図21には、Sink機器がSource機器から受信したTxチャレンジに含まれる機器証明書からCCIフラグを検証するための処理手順をフローチャートの形式で示している。
【0198】
Sink機器は、Source機器からTxチャレンジを受信すると(ステップS81)、これに含まれている機器証明書の署名を検証する(ステップS82)。そして、検証に成功したときには(ステップS83)、当該証明書中のCCIフラグの値を参照する(ステップS84)。また、検証に失敗したときには、フラグ値のチェックを行なうことなく、認証エラーを返す(ステップS85)。
【0199】
また、ステップS71において、Source機器がPCPヘッダにPCP−CCIを埋め込んでいることを識別する他の方法として、Source機器が自身の署名を付加して送るレスポンスの中にCCIフラグを埋め込むことが挙げられる。
【0200】
図22には、機器が自身の署名を付加して送るレスポンスの中にCCIフラグを埋め込むことによって、Source機器がPCP−CCI対応であることをSink機器に示す送受信シーケンス例を示している。
【0201】
まず、コンテンツ要求元であるSink機器から、Rx乱数とRx証明書を含んだRxチャレンジが送信される。これに対し、Source機器からは、Tx乱数及びTx証明書を含んだTxチャレンジが返信される。
【0202】
続いて、Source機器から、Rx乱数、Txメッセージ、Tx署名を含んだRxレスポンスが送信される。ここで、Txメッセージには、CCIフラグが含まれている。Sink機器は、このCCIフラグをチェックして、Source機器がPCP−CCIに対応していることを確認する。そして、Sink機器からはTx乱数、Rxメッセージ、Rx署名を含んだTxレスポンスが送信され、通常のチャレンジ・アンド・レスポンス認証手続きが続く。
【0203】
図23には、Sink機器がSource機器から受信したRxレスポンスに含まれるTxメッセージからCCIフラグを検証するための処理手順をフローチャートの形式で示している。
【0204】
Sink機器は、Source機器からRxレスポンスを受信すると(ステップS91)、Rx乱数とTxメッセージ対するTx署名を検証する(ステップS92)。そして、検証に成功したときには(ステップS93)、当該Txメッセージ中のCCIフラグの値を参照する(ステップS94)。また、検証に失敗したときには、フラグ値のチェックを行なうことなく、認証エラーを返す(ステップS95)。
【0205】
例えば、Txメッセージ中の予備領域の1ビットを使用して、CCIフラグを埋め込むことができる。但し、Rxレスポンス中にCCIフラグを挿入する場所がもはや残されていない場合には、新規のRxレスポンス用のコマンドを定義すればよい。
【0206】
また、LegacyのSink機器は新規のRxレスポンス用のコマンドに対応することができないという問題がある。このため、Sink機器からSource機器に対し新規のRxレスポンスを求めるための、新規のRxチャレンジ用のコマンドをさらに定義するようにしてもよい。
【0207】
図24には、Sink機器からSource機器に対し新規のRxチャレンジを送信し、これに対しSource機器がCCIフラグを埋め込んだ新規のRxレスポンスを返し、Source機器がPCP−CCI対応であることをSink機器に示す送受信シーケンス例を示している。
【0208】
まず、コンテンツ要求元であるSink機器から、Source機器に対し新規のRxレスポンスを求めるための、新規のRxチャレンジ用コマンドが送信される。このRxチャレンジ用のコマンドには、Rx乱数とRx証明書が含まれている(同上)。これに対し、Source機器からは、Tx乱数及びTx証明書を含んだTxチャレンジが返信される。
【0209】
続いて、Source機器から、Rx乱数、Txメッセージ、Tx署名を含んだ新規のRxレスポンス用コマンドが送信される。ここで、Txメッセージには、CCIフラグが含まれている。Sink機器は、このCCIフラグをチェックして、Source機器がPCP−CCIに対応していることを確認する。そして、Sink機器からはTx乱数、Rxメッセージ、Rx署名を含んだTxレスポンスが送信され、通常のチャレンジ・アンド・レスポンス認証手続きが続く。
【0210】
図25は、Source機器が、図24に示した動作に対応したチャレンジ・アンド・レスポンス動作を行なうための処理手順をフローチャートの形式で示している。
【0211】
Source機器は、Sink機器からRxチャレンジを受信すると(ステップS101)、これが従来通りのRxチャレンジ、又はCCIフラグを埋め込んだ新規のRxレスポンスを求める新規のRxチャレンジのいずれであるかを判別する(ステップS102)。
【0212】
そして、従来通りのRxチャレンジを受信したときには、以降は従来通りの認証手順を実施するが(ステップS103)、新規のRxチャレンジを受信したときには、図24に示した認証手順を実施して(ステップS104)、Sink機器に対し自己がPCP−CCIに対応していることを示す。
【0213】
また、図26には、Sink機器がSource機器から受信した新規のRxレスポンスに含まれるTxメッセージからCCIフラグを検証するための処理手順をフローチャートの形式で示している。
【0214】
Sink機器は、Source機器から新規のRxレスポンスを受信すると(ステップS111)、Rx乱数とTxメッセージ対するTx署名を検証する(ステップ1192)。そして、検証に成功したときには(ステップS113)、当該Txメッセージ中のCCIフラグの値を参照する(ステップS114)。また、検証に失敗したときには、フラグ値のチェックを行なうことなく、認証エラーを返す(ステップS115)。
【0215】
また、Sink機器からSource機器に対し新規のRxレスポンスを求める他の方法として、能力確認用のコマンドを新たに定義することが挙げられる。
【0216】
図27には、Sink機器からSource機器に対し能力確認コマンドを送信し、これに対しSource機器がCCIフラグを埋め込んだ能力確認レスポンスを返し、Source機器がPCP−CCI対応であることをSink機器に示す送受信シーケンス例を示している。
【0217】
まず、コンテンツ要求元であるSink機器から、Source機器に対し能力確認コマンドが送信される。これに対し、Source機器からは、能力確認レスポンスが返信される。このレスポンスには、CCIフラグがセットされている。
【0218】
続いて、コンテンツ要求元であるSink機器から、Source機器に対し新規のRxレスポンスを求めるための、新規のRxチャレンジ用コマンドが送信される。このRxチャレンジ用のコマンドには、Rx乱数とRx証明書が含まれている(同上)。これに対し、Source機器からは、Tx乱数及びTx証明書を含んだTxチャレンジが返信される。
【0219】
続いて、Source機器から、Rx乱数、Txメッセージ、Tx署名を含んだ新規のRxレスポンス用コマンドが送信される。ここで、Txメッセージには、CCIフラグがセットされている。Sink機器は、このCCIフラグをチェックして、Source機器がPCP−CCIに対応していることを確認する。そして、Sink機器からはTx乱数、Rxメッセージ、Rx署名を含んだTxレスポンスが送信され、通常のチャレンジ・アンド・レスポンス認証手続きが続く。
【0220】
図28は、Sink機器が、図27に示した動作に対応したチャレンジ・アンド・レスポンス動作を行なうための処理手順をフローチャートの形式で示している。
【0221】
Sink機器は、Source機器に対してCCIフラグを埋め込んだ新規のRxレスポンスを要求する際には、まず能力確認コマンドを送信する(ステップS121)。
【0222】
そして、Source機器から能力確認レスポンスが返されると、その中にCCIフラグがセットされているかどうかをチェックする(ステップS122)。
【0223】
そして、CCIフラグが設定されていないときには、以降は従来通りの認証手順を実施するが(ステップS123)、CCIフラグが設定されているときには、図27に示した認証手順を実施して(ステップS124)、Source機器がPCP−CCIに対応していることを確認する。新規の認証手続きは図26に示した処理手順に従うので、ここでは説明を省略する。
【0224】
なお、Sink機器から能力確認コマンドを送信したのに対し、Source機器が当該コマンドに対応していない場合には、“not implemented”コマンドが返されるので、Sink機器はSource機器がLegacyであることを識別できる。
【0225】
また、能力確認用のコマンドを新たに定義して新規のRxレスポンスを求める場合の変形例として、最初の能力確認コマンドとその応答にチャレンジ・アンド・レスポンス処理を組み込み、その動作シーケンス中にCCIフラグをセキュアに送ることも考えられる。この場合、Sink機器からSource機器に対し能力確認コマンドを送信し、これに対しSource機器がCCIフラグを埋め込んだ署名付きの能力確認レスポンスを返し、Source機器がPCP−CCI対応であることをSink機器に示すことができる。そして、引き続く認証処理は常に従来通りの手順となる。
【0226】
図29には、最初の能力確認コマンドとその応答にチャレンジ・アンド・レスポンス処理を組み込んだ場合に、Source機器がPCP−CCI対応であることをSink機器に示す送受信シーケンス例を示している。
【0227】
まず、コンテンツ要求元であるSink機器から、Source機器に対し能力確認コマンドが送信される。この能力確認コマンドには、チャレンジ・アンド・レスポンス用のRx乱数2が含まれている。これに対し、Source機器からは、能力確認レスポンスが返信される。この能力確認レスポンスには、Rx乱数2と、Txメッセージ2と、Tx署名2が含まれている。そして、Txメッセージ2にはCCIフラグがセットされている。Sink機器は、このCCIフラグをチェックして、Source機器がPCP−CCIに対応していることを確認する。
【0228】
続いて、Sink機器から、Rx乱数とRx証明書を含んだRxチャレンジが送信される。これに対し、Source機器からは、Tx乱数及びTx証明書を含んだTxチャレンジが返信される。
【0229】
続いて、Source機器から、Rx乱数、Txメッセージ、Tx署名を含んだRxレスポンスが送信される。そして、Sink機器からはTx乱数、Rxメッセージ、Rx署名を含んだTxレスポンスが送信され、通常のチャレンジ・アンド・レスポンス認証手続きが続く。
【0230】
図30は、Sink機器が、図29に示した動作に対応したチャレンジ・アンド・レスポンス動作を行なうための処理手順をフローチャートの形式で示している。ここでは、Tx署名2の検証を行なうにはTx証明書に含まれるSource機器の公開鍵が必要であるため、この検証処理はTxチャレンジの受信以降に行なうことになる。
【0231】
Sink機器は、チャレンジ・アンド・レスポンス用のRx乱数2を含んだ能力確認コマンドを送信する(ステップS131)。
【0232】
ここで、Source機器から応答を受信し(ステップS132)、且つこの応答がACCEPTEDである場合には(ステップS133のYes)、続いて、Rxチャレンジの送信とTxチャレンジの受信を行なう(ステップS134)。そして、Rx乱数2とTxメッセージに対するTx署名2を検証する(ステップS135)。
【0233】
Sink機器は、Tx署名2の検証に成功した場合には(ステップS136のYes)、Txメッセージ2に含まれるCCIフラグを参照し、セットされているかどうかを確認する(ステップS138)。そして、CCIフラグがセットされていることを確認したら、PCP−CCIを参照可とする。続いて、Rx乱数とRx証明書を含んだRxチャレンジが送信するとともに、Source機器からTx乱数及びTx証明書を含んだTxチャレンジを受信する(ステップS139)。
【0234】
また、ステップS133において能力確認コマンドに対するACCEPTED応答を受信できなかったときには、Sink機器は、Rx乱数とRx証明書を含んだRxチャレンジが送信するとともに、Source機器からTx乱数及びTx証明書を含んだTxチャレンジを受信するが(ステップS140)、CCIフラグを確認することができないので(ステップS141)、PCP−CCIは参照付加とする。
【0235】
また、ステップS137においてTx署名2の検証に失敗したときも、CCIフラグを確認することができないので(ステップS141)、PCP−CCIは参照付加とする。
【産業上の利用可能性】
【0236】
以上、特定の実施形態を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
【0237】
本発明の適用例として、DTCP_Source機器とDTCP_Sink機器の間で行なわれるHTTPプロトコルを利用したコンテンツ伝送を挙げることができるが、本発明の要旨はこれに限定されない。コピー制御情報とともに暗号化コンテンツを伝送するその他のさまざまなタイプの情報通信システムに対しても、同様に本発明を適用することができる。
【0238】
要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、特許請求の範囲を参酌すべきである。
【図面の簡単な説明】
【0239】
【図1】図1は、本発明の一実施形態に係る情報通信システムの構成例を模式的に示した図である。
【図2】図2は、図1に示した情報通信システムにおいて、クライアント(すなわち、Sink機器)として動作する情報通信装置の機能構成を示した図である。
【図3】図3は、図1に示した情報通信システムにおいて、サーバ(すなわち、Source機器)として動作する情報通信装置の機能構成を示した図である。
【図4】図4は、DTCP_Source機器とDTCP_Sink機器の間でAKEに基づく鍵交換手続き、及び鍵交換により共有した鍵を利用した暗号化コンテンツ伝送を行なう仕組みを説明するための図である
【図5】図5は、PCPのデータ構造を模式的に示した図である。
【図6】図6は、PCPペイロードにパディングする様子を示した図である。
【図7】図7は、本発明の実施形態に係るPCPヘッダのデータ構造を示した図である。
【図8】図8は、PCP−CCIフィールドのフォーマット構成例を示した図である。
【図9】図9は、Modeビット・フィールドに基づいてPCP CCIフィールドの意味を識別するための処理手順を示したフローチャートである。
【図10】図10は、Modeビット・フィールドとSEビット・フラグの値の組み合わせに基づいてPCP CCIフィールドの意味を識別するための処理手順を示したフローチャートである。
【図11】図11は、Modeビット・フィールド及びSEビット・フラグの値の組み合わせに基づいてE−EMIでEmbedded CCIを代用することが可能かどうかを判別するための処理手順を示したフローチャートである。
【図12】図12は、LegacyのSource機器とSink機器間でPCPを伝送する仕組みを説明するための図である。
【図13】図13は、PCP−CCIをPCPヘッダに埋め込む伝送方式を適用したSource機器とSink機器間でPCPを伝送する仕組みを説明するための図である。
【図14】図14は、図12に示したLegacyのSource及びSink機器と、図13に示した新方式のSource及びSink機器が混在するコンテンツ伝送環境下においてLegacy問題が発生する様子を示した図である。
【図15】図15は、コンテンツ鍵確認のためのSink機器とSource機器間の手続きを示した図である。
【図16】図16は、PCP−CCIに対応したSource機器がLegacyのSink機器との間でコンテンツ鍵確認手続きを行なうための処理手順を示したフローチャートである。
【図17】図17は、LegacyのSink機器がPCP−CCIに対応したSource機器との間でコンテンツ鍵確認手続きを行なうための処理手順を示したフローチャートである。
【図18】図18は、PCP−CCIに対応したSource機器(New Source)とLegacy Sinkの間で行なわれるコンテンツ鍵確認手続の動作シーケンスを示した図である。
【図19】図19は、Sink機器がSource機器のCCIフラグをチェックしてPCPヘッダ部のPCP−CCI情報を処理するための手順を示したフローチャートである。
【図20】図20は、機器証明書内にCCIフラグを埋め込むことによって、Source機器がPCP−CCI対応であることをSink機器に示す送受信シーケンス例を示した図である。
【図21】図21は、Sink機器がSource機器から受信したTxチャレンジに含まれる機器証明書からCCIフラグを検証するための処理手順を示したフローチャートである。
【図22】図22は、機器が自身の署名を付加して送るレスポンスの中にCCIフラグを埋め込むことによって、Source機器がPCP−CCI対応であることをSink機器に示す送受信シーケンス例を示した図である。
【図23】図23は、Sink機器がSource機器から受信したRxレスポンスに含まれるTxメッセージからCCIフラグを検証するための処理手順を示したフローチャートである。
【図24】図24は、Sink機器からSource機器に対し新規のRxチャレンジを送信し、これに対しSource機器がCCIフラグを埋め込んだ新規のRxレスポンスを返し、Source機器がPCP−CCI対応であることをSink機器に示す送受信シーケンス例を示した図である。
【図25】図25は、Source機器が、図24に示した動作に対応したチャレンジ・アンド・レスポンス動作を行なうための処理手順を示したフローチャートである。
【図26】図26は、Sink機器がSource機器から受信した新規のRxレスポンスに含まれるTxメッセージからCCIフラグを検証するための処理手順を示したフローチャートである。
【図27】図27は、Sink機器からSource機器に対し能力確認コマンドを送信し、これに対しSource機器がCCIフラグを埋め込んだ能力確認レスポンスを返し、Source機器がPCP−CCI対応であることをSink機器に示す送受信シーケンス例を示した図である。
【図28】図28は、Sink機器が、図27に示した動作に対応したチャレンジ・アンド・レスポンス動作を行なうための処理手順を示したフローチャートである。
【図29】図29は、Sink機器からSource機器に対し能力確認コマンドを送信し、これに対しSource機器がCCIフラグを埋め込んだ署名付きの能力確認レスポンスを返し、Source機器がPCP−CCI対応であることをSink機器に示す送受信シーケンス例を示した図である。
【図30】図30は、Sink機器が図29に示した動作に対応したチャレンジ・アンド・レスポンス動作を行なうための処理手順を示したフローチャートである。
【図31】図31は、PCPヘッダの内部構造を示した図である。
【特許請求の範囲】
【請求項1】
コピー制御がなされたコンテンツを伝送するコンテンツ伝送装置であって、
コンテンツ伝送先の機器との間で認証手続きを行なう認証手段と、
コンテンツに関するコピー制御情報を記述した第1のコピー制御情報を処理する第1のコピー制御情報処理手段と、
コンテンツに関する第1のコピー制御情報以外の情報を含んだ第2のコピー制御情報を処理する第2のコピー制御情報処理手段と、
第1のコピー制御情報及び第2のコピー制御情報を含んだヘッダと、コンテンツを所定のコンテンツ鍵で暗号化したペイロードからなるパケットを生成して、コンテンツ伝送先の機器に伝送するコンテンツ伝送手段と、
を具備することを特徴とするコンテンツ伝送装置。
【請求項2】
第1のコピー制御情報処理手段は、コンテンツのコピーの可否を規定するコピー制御情報と、コピー可否に応じた暗号モードに関する情報を含む第1のコピー制御情報を処理する、
ことを特徴とする請求項1に記載のコンテンツ伝送装置。
【請求項3】
第2のコピー制御情報処理手段は、コンテンツの出力制御に関する情報を含む第2のコピー制御情報を処理する、
ことを特徴とする請求項1に記載のコンテンツ伝送装置。
【請求項4】
ヘッダに第1のコピー制御情報を書き込むフィールドを設けたヘッダと、コンテンツ埋め込み型のコピー制御情報を埋め込んだコンテンツからなるペイロードで構成された形式のパケットを用いてコンテンツ伝送が行なわれる伝送システム環境下において動作し、
前記第2のコピー制御情報処理手段は、ヘッダ部に埋め込まれた第2の制御情報の有効性を示すモード情報と、第1のコピー制御情報に関するコンテンツ埋め込み型のコピー制御情報の代用可能性を示す代用性情報を含んだ第2の制御情報を処理する、
ことを特徴とする請求項1に記載のコンテンツ伝送装置。
【請求項5】
前記伝送システム環境下では、コンテンツのフォーマットの認識可能性に応じたコンテンツのコピー制御を実施するcognizant機能が提供されており、
前記第2のコピー制御情報処理手段は、ヘッダに第2のコピー制御情報として含まれるモード情報と、ペイロード中におけるコンテンツ埋め込み型のコピー制御情報の存在の有無の組み合わせに応じてcognizant機能を実現する、
ことを特徴とする請求項4に記載のコンテンツ伝送装置。
【請求項6】
前記伝送システム環境下では、ノンスを用いて生成されたコンテンツ鍵で伝送コンテンツの暗号化が行なわれ、且つヘッダには所定ビット長のノンスを伝送するためのフィールドが設けられており、
前記コンテンツ伝送手段は、前記のノンスを伝送するためのフィールド内に第2のコピー制御情報を埋め込んで、パケットを伝送する、
ことを特徴とする請求項4に記載のコンテンツ伝送装置。
【請求項7】
前記の所定ビット長よりも第2のコピー制御情報のビット数分だけ短い擬似ノンスを生成する擬似ノンス生成手段をさらに備え、
前記コンテンツ伝送手段は、第2のコピー制御情報と擬似ノンスをビット連結してなるノンスを用いて生成されるコンテンツ鍵で伝送コンテンツを暗号化する、
ことを特徴とする請求項6に記載のコンテンツ伝送装置。
【請求項8】
コンテンツ伝送先の機器からの要求に応じて、パケットのヘッダに含めたノンスの検証を行なうコンテンツ鍵確認手段をさらに備え、
第2のコピー制御情報を埋め込んだノンスをヘッダに含めてパケットを伝送したときには、前記コンテンツ鍵確認手段は、コンテンツ伝送先の機器からノンスの検証要求に応じて、該要求されているノンスと第2のコピー制御情報を埋め込んだノンスとを比較して検証する、
ことを特徴とする請求項6に記載のコンテンツ伝送装置。
【請求項9】
前記コンテンツ伝送手段が第1のコピー制御情報及び第2のコピー制御情報を含んだヘッダを付けてパケットを伝送するとき、前記認証手段は、コンテンツ伝送先の機器に送信する認証用コマンド内にその旨を示す情報を記載する、
ことを特徴とする請求項1に記載のコンテンツ伝送装置。
【請求項10】
前記認証手段は、チャレンジ・アンド・レスポンス認証手続におけるチャレンジ用コマンドに含める機器証明書内に所定のフラグをセットする、
ことを特徴とする請求項9に記載のコンテンツ伝送装置。
【請求項11】
前記認証手段は、チャレンジ・アンド・レスポンス認証手続におけるレスポンス用コマンドに含めるメッセージ内に所定のフラグをセットする、
ことを特徴とする請求項9に記載のコンテンツ伝送装置。
【請求項12】
前記認証手段は、コンテンツ伝送先の機器からの所定の要求コマンドに応答して、当該情報の記載を行なう、
ことを特徴とする請求項9に記載のコンテンツ伝送装置。
【請求項13】
コピー制御がなされたコンテンツを伝送するコンテンツ伝送方法であって、
コンテンツ伝送先の機器との間で認証手続きを行なう認証ステップと、
コンテンツに関するコピー制御情報を記述した第1のコピー制御情報を設定する第1のコピー制御情報設定ステップと、
コンテンツに関する第1のコピー制御情報以外の情報を含んだ第2のコピー制御情報を設定する第2のコピー制御情報設定ステップと、
第1のコピー制御情報及び第2のコピー制御情報を含んだヘッダと、コンテンツを所定のコンテンツ鍵で暗号化したペイロードからなるパケットを生成して、コンテンツ伝送先の機器に伝送するコンテンツ伝送ステップと、
を具備することを特徴とするコンテンツ伝送方法。
【請求項14】
第1のコピー制御情報設定ステップでは、コンテンツのコピーの可否を規定するコピー制御情報と、コピー可否に応じた暗号モードに関する情報を含む第1のコピー制御情報を設定する、
ことを特徴とする請求項13に記載のコンテンツ伝送方法。
【請求項15】
第2のコピー制御情報設定ステップでは、コンテンツの出力制御に関する情報を含む第2のコピー制御情報を設定する、
ことを特徴とする請求項13に記載のコンテンツ伝送方法。
【請求項16】
ヘッダに第1のコピー制御情報を書き込むフィールドを設けたヘッダと、コンテンツ埋め込み型のコピー制御情報を埋め込んだコンテンツからなるペイロードで構成された形式のパケットを用いてコンテンツ伝送が行なわれる伝送システム環境下において、
前記第2のコピー制御情報設定ステップでは、ヘッダ部に埋め込まれた第2の制御情報の有効性を示すモード情報と、第1のコピー制御情報に関するコンテンツ埋め込み型のコピー制御情報の代用可能性を示す代用性情報を含んだ第2の制御情報を設定する、
ことを特徴とする請求項13に記載のコンテンツ伝送方法。
【請求項17】
前記伝送システム環境下では、コンテンツのフォーマットの認識可能性に応じたコンテンツのコピー制御を実施するcognizant機能が提供されており、
前記第2のコピー制御情報設定ステップでは、ヘッダに第2のコピー制御情報として含まれるモード情報と、ペイロード中におけるコンテンツ埋め込み型のコピー制御情報の存在の有無の組み合わせに応じてcognizant機能を実現する、
ことを特徴とする請求項16に記載のコンテンツ伝送方法。
【請求項18】
前記伝送システム環境下では、ノンスを用いて生成されたコンテンツ鍵で伝送コンテンツの暗号化が行なわれ、且つヘッダには所定ビット長のノンスを伝送するためのフィールドが設けられており、
前記コンテンツ伝送ステップでは、前記のノンスを伝送するためのフィールド内に第2のコピー制御情報を埋め込んで、パケットを伝送する、
ことを特徴とする請求項16に記載のコンテンツ伝送方法。
【請求項19】
前記の所定ビット長よりも第2のコピー制御情報のビット数分だけ短い擬似ノンスを生成する擬似ノンス生成ステップをさらに備え、
前記コンテンツ伝送ステップでは、第2のコピー制御情報と擬似ノンスをビット連結してなるノンスを用いて生成されるコンテンツ鍵で伝送コンテンツを暗号化する、
ことを特徴とする請求項18に記載のコンテンツ伝送方法。
【請求項20】
コンテンツ伝送先の機器からの要求に応じて、パケットのヘッダに含めたノンスの検証を行なうコンテンツ鍵確認ステップをさらに備え、
第2のコピー制御情報を埋め込んだノンスをヘッダに含めてパケットを伝送したときには、前記コンテンツ鍵確認ステップでは、コンテンツ伝送先の機器からノンスの検証要求に応じて、該要求されているノンスと第2のコピー制御情報を埋め込んだノンスとを比較して検証する、
ことを特徴とする請求項18に記載のコンテンツ伝送方法。
【請求項21】
前記コンテンツ伝送ステップにおいて第1のコピー制御情報及び第2のコピー制御情報を含んだヘッダを付けてパケットを伝送するとき、前記認証ステップでは、コンテンツ伝送先の機器に送信する認証用コマンド内にその旨を示す情報を記載する、
ことを特徴とする請求項13に記載のコンテンツ伝送方法。
【請求項22】
前記認証ステップでは、チャレンジ・アンド・レスポンス認証手続におけるチャレンジ用コマンドに含める機器証明書内に所定のフラグをセットする、
ことを特徴とする請求項21に記載のコンテンツ伝送方法。
【請求項23】
前記認証ステップでは、チャレンジ・アンド・レスポンス認証手続におけるレスポンス用コマンドに含めるメッセージ内に所定のフラグをセットする、
ことを特徴とする請求項21に記載のコンテンツ伝送方法。
【請求項24】
前記認証ステップでは、コンテンツ伝送先の機器からの所定の要求コマンドに応答して、当該情報の記載を行なう、
ことを特徴とする請求項21に記載のコンテンツ伝送方法。
【請求項25】
コピー制御がなされたコンテンツを伝送するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
コンテンツ伝送先の機器との間で認証手続きを行なう認証手順と、
コンテンツに関するコピー制御情報を記述した第1のコピー制御情報を設定する第1のコピー制御情報設定手順と、
コンテンツに関する第1のコピー制御情報以外の情報を含んだ第2のコピー制御情報を設定する第2のコピー制御情報設定手順と、
第1のコピー制御情報及び第2のコピー制御情報を含んだヘッダと、コンテンツを所定のコンテンツ鍵で暗号化したペイロードからなるパケットを生成して、コンテンツ伝送先の機器に伝送するコンテンツ伝送手順と、
を実行させることを特徴とするコンピュータ・プログラム。
【請求項1】
コピー制御がなされたコンテンツを伝送するコンテンツ伝送装置であって、
コンテンツ伝送先の機器との間で認証手続きを行なう認証手段と、
コンテンツに関するコピー制御情報を記述した第1のコピー制御情報を処理する第1のコピー制御情報処理手段と、
コンテンツに関する第1のコピー制御情報以外の情報を含んだ第2のコピー制御情報を処理する第2のコピー制御情報処理手段と、
第1のコピー制御情報及び第2のコピー制御情報を含んだヘッダと、コンテンツを所定のコンテンツ鍵で暗号化したペイロードからなるパケットを生成して、コンテンツ伝送先の機器に伝送するコンテンツ伝送手段と、
を具備することを特徴とするコンテンツ伝送装置。
【請求項2】
第1のコピー制御情報処理手段は、コンテンツのコピーの可否を規定するコピー制御情報と、コピー可否に応じた暗号モードに関する情報を含む第1のコピー制御情報を処理する、
ことを特徴とする請求項1に記載のコンテンツ伝送装置。
【請求項3】
第2のコピー制御情報処理手段は、コンテンツの出力制御に関する情報を含む第2のコピー制御情報を処理する、
ことを特徴とする請求項1に記載のコンテンツ伝送装置。
【請求項4】
ヘッダに第1のコピー制御情報を書き込むフィールドを設けたヘッダと、コンテンツ埋め込み型のコピー制御情報を埋め込んだコンテンツからなるペイロードで構成された形式のパケットを用いてコンテンツ伝送が行なわれる伝送システム環境下において動作し、
前記第2のコピー制御情報処理手段は、ヘッダ部に埋め込まれた第2の制御情報の有効性を示すモード情報と、第1のコピー制御情報に関するコンテンツ埋め込み型のコピー制御情報の代用可能性を示す代用性情報を含んだ第2の制御情報を処理する、
ことを特徴とする請求項1に記載のコンテンツ伝送装置。
【請求項5】
前記伝送システム環境下では、コンテンツのフォーマットの認識可能性に応じたコンテンツのコピー制御を実施するcognizant機能が提供されており、
前記第2のコピー制御情報処理手段は、ヘッダに第2のコピー制御情報として含まれるモード情報と、ペイロード中におけるコンテンツ埋め込み型のコピー制御情報の存在の有無の組み合わせに応じてcognizant機能を実現する、
ことを特徴とする請求項4に記載のコンテンツ伝送装置。
【請求項6】
前記伝送システム環境下では、ノンスを用いて生成されたコンテンツ鍵で伝送コンテンツの暗号化が行なわれ、且つヘッダには所定ビット長のノンスを伝送するためのフィールドが設けられており、
前記コンテンツ伝送手段は、前記のノンスを伝送するためのフィールド内に第2のコピー制御情報を埋め込んで、パケットを伝送する、
ことを特徴とする請求項4に記載のコンテンツ伝送装置。
【請求項7】
前記の所定ビット長よりも第2のコピー制御情報のビット数分だけ短い擬似ノンスを生成する擬似ノンス生成手段をさらに備え、
前記コンテンツ伝送手段は、第2のコピー制御情報と擬似ノンスをビット連結してなるノンスを用いて生成されるコンテンツ鍵で伝送コンテンツを暗号化する、
ことを特徴とする請求項6に記載のコンテンツ伝送装置。
【請求項8】
コンテンツ伝送先の機器からの要求に応じて、パケットのヘッダに含めたノンスの検証を行なうコンテンツ鍵確認手段をさらに備え、
第2のコピー制御情報を埋め込んだノンスをヘッダに含めてパケットを伝送したときには、前記コンテンツ鍵確認手段は、コンテンツ伝送先の機器からノンスの検証要求に応じて、該要求されているノンスと第2のコピー制御情報を埋め込んだノンスとを比較して検証する、
ことを特徴とする請求項6に記載のコンテンツ伝送装置。
【請求項9】
前記コンテンツ伝送手段が第1のコピー制御情報及び第2のコピー制御情報を含んだヘッダを付けてパケットを伝送するとき、前記認証手段は、コンテンツ伝送先の機器に送信する認証用コマンド内にその旨を示す情報を記載する、
ことを特徴とする請求項1に記載のコンテンツ伝送装置。
【請求項10】
前記認証手段は、チャレンジ・アンド・レスポンス認証手続におけるチャレンジ用コマンドに含める機器証明書内に所定のフラグをセットする、
ことを特徴とする請求項9に記載のコンテンツ伝送装置。
【請求項11】
前記認証手段は、チャレンジ・アンド・レスポンス認証手続におけるレスポンス用コマンドに含めるメッセージ内に所定のフラグをセットする、
ことを特徴とする請求項9に記載のコンテンツ伝送装置。
【請求項12】
前記認証手段は、コンテンツ伝送先の機器からの所定の要求コマンドに応答して、当該情報の記載を行なう、
ことを特徴とする請求項9に記載のコンテンツ伝送装置。
【請求項13】
コピー制御がなされたコンテンツを伝送するコンテンツ伝送方法であって、
コンテンツ伝送先の機器との間で認証手続きを行なう認証ステップと、
コンテンツに関するコピー制御情報を記述した第1のコピー制御情報を設定する第1のコピー制御情報設定ステップと、
コンテンツに関する第1のコピー制御情報以外の情報を含んだ第2のコピー制御情報を設定する第2のコピー制御情報設定ステップと、
第1のコピー制御情報及び第2のコピー制御情報を含んだヘッダと、コンテンツを所定のコンテンツ鍵で暗号化したペイロードからなるパケットを生成して、コンテンツ伝送先の機器に伝送するコンテンツ伝送ステップと、
を具備することを特徴とするコンテンツ伝送方法。
【請求項14】
第1のコピー制御情報設定ステップでは、コンテンツのコピーの可否を規定するコピー制御情報と、コピー可否に応じた暗号モードに関する情報を含む第1のコピー制御情報を設定する、
ことを特徴とする請求項13に記載のコンテンツ伝送方法。
【請求項15】
第2のコピー制御情報設定ステップでは、コンテンツの出力制御に関する情報を含む第2のコピー制御情報を設定する、
ことを特徴とする請求項13に記載のコンテンツ伝送方法。
【請求項16】
ヘッダに第1のコピー制御情報を書き込むフィールドを設けたヘッダと、コンテンツ埋め込み型のコピー制御情報を埋め込んだコンテンツからなるペイロードで構成された形式のパケットを用いてコンテンツ伝送が行なわれる伝送システム環境下において、
前記第2のコピー制御情報設定ステップでは、ヘッダ部に埋め込まれた第2の制御情報の有効性を示すモード情報と、第1のコピー制御情報に関するコンテンツ埋め込み型のコピー制御情報の代用可能性を示す代用性情報を含んだ第2の制御情報を設定する、
ことを特徴とする請求項13に記載のコンテンツ伝送方法。
【請求項17】
前記伝送システム環境下では、コンテンツのフォーマットの認識可能性に応じたコンテンツのコピー制御を実施するcognizant機能が提供されており、
前記第2のコピー制御情報設定ステップでは、ヘッダに第2のコピー制御情報として含まれるモード情報と、ペイロード中におけるコンテンツ埋め込み型のコピー制御情報の存在の有無の組み合わせに応じてcognizant機能を実現する、
ことを特徴とする請求項16に記載のコンテンツ伝送方法。
【請求項18】
前記伝送システム環境下では、ノンスを用いて生成されたコンテンツ鍵で伝送コンテンツの暗号化が行なわれ、且つヘッダには所定ビット長のノンスを伝送するためのフィールドが設けられており、
前記コンテンツ伝送ステップでは、前記のノンスを伝送するためのフィールド内に第2のコピー制御情報を埋め込んで、パケットを伝送する、
ことを特徴とする請求項16に記載のコンテンツ伝送方法。
【請求項19】
前記の所定ビット長よりも第2のコピー制御情報のビット数分だけ短い擬似ノンスを生成する擬似ノンス生成ステップをさらに備え、
前記コンテンツ伝送ステップでは、第2のコピー制御情報と擬似ノンスをビット連結してなるノンスを用いて生成されるコンテンツ鍵で伝送コンテンツを暗号化する、
ことを特徴とする請求項18に記載のコンテンツ伝送方法。
【請求項20】
コンテンツ伝送先の機器からの要求に応じて、パケットのヘッダに含めたノンスの検証を行なうコンテンツ鍵確認ステップをさらに備え、
第2のコピー制御情報を埋め込んだノンスをヘッダに含めてパケットを伝送したときには、前記コンテンツ鍵確認ステップでは、コンテンツ伝送先の機器からノンスの検証要求に応じて、該要求されているノンスと第2のコピー制御情報を埋め込んだノンスとを比較して検証する、
ことを特徴とする請求項18に記載のコンテンツ伝送方法。
【請求項21】
前記コンテンツ伝送ステップにおいて第1のコピー制御情報及び第2のコピー制御情報を含んだヘッダを付けてパケットを伝送するとき、前記認証ステップでは、コンテンツ伝送先の機器に送信する認証用コマンド内にその旨を示す情報を記載する、
ことを特徴とする請求項13に記載のコンテンツ伝送方法。
【請求項22】
前記認証ステップでは、チャレンジ・アンド・レスポンス認証手続におけるチャレンジ用コマンドに含める機器証明書内に所定のフラグをセットする、
ことを特徴とする請求項21に記載のコンテンツ伝送方法。
【請求項23】
前記認証ステップでは、チャレンジ・アンド・レスポンス認証手続におけるレスポンス用コマンドに含めるメッセージ内に所定のフラグをセットする、
ことを特徴とする請求項21に記載のコンテンツ伝送方法。
【請求項24】
前記認証ステップでは、コンテンツ伝送先の機器からの所定の要求コマンドに応答して、当該情報の記載を行なう、
ことを特徴とする請求項21に記載のコンテンツ伝送方法。
【請求項25】
コピー制御がなされたコンテンツを伝送するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
コンテンツ伝送先の機器との間で認証手続きを行なう認証手順と、
コンテンツに関するコピー制御情報を記述した第1のコピー制御情報を設定する第1のコピー制御情報設定手順と、
コンテンツに関する第1のコピー制御情報以外の情報を含んだ第2のコピー制御情報を設定する第2のコピー制御情報設定手順と、
第1のコピー制御情報及び第2のコピー制御情報を含んだヘッダと、コンテンツを所定のコンテンツ鍵で暗号化したペイロードからなるパケットを生成して、コンテンツ伝送先の機器に伝送するコンテンツ伝送手順と、
を実行させることを特徴とするコンピュータ・プログラム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【公開番号】特開2007−104236(P2007−104236A)
【公開日】平成19年4月19日(2007.4.19)
【国際特許分類】
【出願番号】特願2005−290753(P2005−290753)
【出願日】平成17年10月4日(2005.10.4)
【出願人】(000002185)ソニー株式会社 (34,172)
【Fターム(参考)】
【公開日】平成19年4月19日(2007.4.19)
【国際特許分類】
【出願日】平成17年10月4日(2005.10.4)
【出願人】(000002185)ソニー株式会社 (34,172)
【Fターム(参考)】
[ Back to top ]