(57)【要約】【課題】正当な送信機と受信機の間の通信を監視した不正機器による、なりすまし・受信機への不当なコンテンツの送りつけを検出できる正規コンテンツ確認方法を提供する。【解決手段】コンテンツの暗号化/復号に用いるコンテンツ鍵の作成に必要な更新情報を暗号化されたコンテンツに付随して伝送するシステムにおいて、受信機は確認要求として少なくとも前記更新情報を送信機に送信し、前記送信機は前記更新情報が使用中であるかどうかを照合し、使用中であれば少なくとも前記送信機と前記受信機であらかじめ共有されている交換鍵と前記更新情報を用いて作成した了承メッセージを前記受信機に送る。【選択図】図３
2006115083.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツの暗号化/復号に用いるコンテンツ鍵の作成に必要な更新情報を暗号化されたコンテンツに付随して伝送するシステムにおいて、受信機は確認要求として少なくとも前記更新情報を送信機に送信し、前記送信機は前記更新情報が使用中であるかどうかを照合し、使用中であれば前記送信機と前記受信機であらかじめ共有されている交換鍵と前記更新情報を用いて作成した了承メッセージを前記受信機に送ることを特徴とする正規コンテンツ確認方法。
【請求項２】
送信機は受信機から受け取った更新情報が直前に使用した更新情報であっても使用中であると判断することを特徴とする請求項１記載の正規コンテンツ確認方法。
【請求項３】
受信機は確認要求として確認要求のたびに異なる数も送信機に送信し、前記送信機が了承メッセージを作成する際には、前記確認要求のたびに異なる数も利用することを特徴とする請求項１または２に記載の正規コンテンツ確認方法。
【請求項４】
受信機は確認要求として交換鍵と更新情報を用いて作成したメッセージも送信機に送信し、前記送信機は前期メッセージが正しく作成されており、かつ、更新情報が使用中である場合に了承メッセージを前記受信機に送ることを特徴とする請求項１から３のいずれかに記載の正規コンテンツ確認方法。
【請求項５】
送信機は受信機から受け取った更新情報が使用中であるかどうかを照合し、使用中でなければ非了承メッセージを前記受信機に送り、前記受信機は非了承メッセージを受信した場合には受信コンテンツを利用しないことを特徴とする請求項１から４のいずれかに記載の正規コンテンツ確認方法。
【請求項６】
受信機は、了承メッセージを受信できない場合、所定期間、確認要求を繰り返し行うが、前期所定期間を過ぎても前記了承メッセージを受信できない場合には、受信コンテンツを利用しないことを特徴とする請求項１から４のいずれかに記載の正規コンテンツ確認方法。
【請求項７】
受信機は、了承メッセージを受信できない場合、所定回数、確認要求を繰り返し行うが、前期所定回数を過ぎても前記了承メッセージを受信できない場合には、受信コンテンツを利用しないことを特徴とする請求項１から４のいずれかに記載の正規コンテンツ確認方法。
【請求項８】
受信機は、了承メッセージを受信できるまで確認要求を繰り返し行い、前記了承メッセージを受信したらコンテンツを利用することを特徴とする請求項５から７のいずれかに記載の正規コンテンツ確認方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツをネットワーク経由で配信する際に、配信先（送信機）と配信元（受信機）間で正当なコンテンツを送受信するためのデータ伝送セキュリティ技術に関する。
【背景技術】
【０００２】
近年、インターネットへの接続環境が整い、また家電製品もネットワーク対応を進めやすい環境（ネットワーク化を行うためのデバイスのローコスト化、能力向上など）が整ってきている。また同時に、伝送されるコンテンツが、不正コピーや不正傍受、不正改竄をされないように保護するための著作権保護技術が重要視されてきている。Digital Transmission Content Protection (DTCP)は、IEEE１３９４シリアルバスに伝送されるAVコンテンツの著作権保護技術として開発され、拡張としてインターネットプロトコル（IP）上でも技術展開が行われている。
【０００３】
図８、９は、HTTPプロトコル（サーバとクライアント間に、コネクションを確立してから、クライアントからのリクエストに対して、サーバがレスポンスを返すという形で、データのやりとりを行う）を用いたDTCP-IPによる、従来の伝送システムにおける送信機、受信機の機能ブロック図の一例である。
【０００４】
図８における送信機８００は、証明書・鍵保持部８０１、交換鍵作成部８０２、認証・鍵交換部８０３、更新情報作成・更新部８０４、コピー制御情報管理部８０５、コンテンツ鍵算出部８０６、コンテンツ蓄積部８０７、コンテンツ暗号化部８０８、コンテンツパケット作成部８０９、コンテンツパケット送信部８１０、ＨＴＴＰプロトコル部８１１を備える。
【０００５】
証明書・鍵保持部８０１は、公開鍵暗号の鍵ペア（公開鍵、秘密鍵）と証明書を保持している。
【０００６】
交換鍵作成部８０２は、コンテンツを暗号化するためのコンテンツ鍵(Kc)を算出するために用いる交換鍵(Kx)を生成する。
【０００７】
認証・鍵交換部８０３は、受信機からの認証要求を受け付け、当該受信機が、正当な機器であるかどうかを認証により確認する。ここで、認証としては、送信機と受信機がそれぞれ保持している公開鍵暗号の鍵ペア（公開鍵、秘密鍵）と証明書を使い、チャンレンジレスポンス型の認証を行う方法を用いる。認証の間に送信機と受信機間では認証鍵(Kauth)が共有され、認証後に、共有された認証鍵(Kauth)を用いて、交換鍵作成部８０２で作成された交換鍵(Kx)が受信機に渡される。これら一連の、認証から鍵取得までのプロセスを認証・鍵交換部８０３にて行う。
【０００８】
更新情報作成・更新部８０４は、更新情報(Nc)を新規作成あるいは更新する。ここで、例えば、作成とは乱数発生等により新たな更新情報(Nc)の作成を行うこと、更新とは現在の値に１を加算することである。更新情報(Nc)は、TCPコネクションの確立により作成される。更新は、所定のルールにより行われる。所定のルールとしては、同一TCPコネクション上でのHTTPリクエスト・レスポンスごとに更新されるなどがあげられるが、本発明の主眼ではないため、ここでは説明を省略する。ここで、作成・更新された更新情報(Nc)は、コンテンツ保護を維持するために所定のルールでコンテンツ鍵(Kc)を算出するために用いられる。さらに、更新情報(Nc)はコンテンツ鍵(Kc)で暗号化されたコンテンツに付随されて受信機に渡される。
【０００９】
コピー制御情報管理部８０５は、各コンテンツの管理内容（例えば、コピー禁止、一世代コピー可など）を、コンテンツに適応される暗号化モードをコピー制御情報(E_EMI)として管理する。コピー制御情報は、コンテンツ鍵(Kc)の算出に用いられ、算出されたコンテンツ鍵(Kc)で暗号化されたコンテンツに付随して受信機に渡される。
【００１０】
コンテンツ鍵算出部８０６は、交換鍵作成部８０２で作成された交換鍵(Kx)、更新情報作成・更新部８０４で作成・更新された更新情報(Nc)、コピー制御情報管理部８０５で管理されるコピー制御情報(E_EMI)などから、一方向性関数を用いてコンテンツ鍵(Kc)を算出する。
【００１１】
コンテンツ蓄積部８０７は、配信の対象となる各種コンテンツを格納している。
【００１２】
コンテンツ暗号化部８０８は、配信するコンテンツを、コンテンツ鍵算出部８０６で算出されたコンテンツ鍵(Kc)を用いて暗号化する。
【００１３】
コンテンツパケット作成部８０９は、コンテンツ暗号化部８０８で暗号化されたコンテンツに、更新情報作成・更新部８０４で作成・更新された更新情報(Nc)、コピー制御情報管理部８０５で管理されるコピー制御情報(E_EMI)を付加したコンテンツパケットを作成する。
【００１４】
コンテンツパケット送信部８１０は、コンテンツパケット作成部８０９で作成されたコンテンツパケットを送信する。
【００１５】
HTTPプロトコル部８１１は、HTTPサーバ処理を行う。HTTPリクエストを受信・解析し、HTTPレスポンスを作成して応答する。ここで、コンテンツパケット生成部８０９で作成されるコンテンツパケットは、送信機からのHTTP GETリクエストに対するHTTPレスポンスのボディとして送信される。
【００１６】
図９における受信機９００は、証明書・鍵保持部９０１、認証・鍵交換部９０２、更新情格納部９０３、コピー制御情報格納部９０４、コンテンツ鍵算出部９０５、コンテンツ利用部９０６、コンテンツ復号部９０７、コンテンツパケット解析部９０８、コンテンツパケット受信部９０９、HTTPプロトコル部９１０を備える。
【００１７】
証明書・鍵保持部９０１は、公開鍵暗号の鍵ペア（公開鍵、秘密鍵）と証明書を保持している。
【００１８】
認証・鍵交換部９０２は、所定のタイミングで認証要求を行い、認証の間に送信機と受信機間で認証鍵(Kauth)が共有され、認証後に、送信機から、共有された認証鍵(Kauth)を用いて暗号化された交換鍵(Kx)を受け取り、復号する。
【００１９】
更新格納部９０３は、暗号化されたコンテンツに付随する更新情報(Nc)を格納する。
【００２０】
コピー制御情報格納部９０４は、暗号化されたコンテンツに付随するコピー制御情報(E_EMI)を格納する。
【００２１】
コンテンツ鍵算出部９０５は、認証・鍵交換部９０２で送信機から渡された交換鍵(Kx)と、更新情報格納部９０３で格納された更新情報(Nc)、コピー制御情報格納部９０４で格納されたコピー制御情報(E_EMI)などから、一方向性関数を用いてコンテンツ鍵(Kc)を算出する。
【００２２】
コンテンツ利用部９０６は、復号されたコンテンツを再生・記録するなどして利用する。
【００２３】
コンテンツ復号部９０７は、コンテンツ鍵算出部９０５で算出されたコンテンツ鍵(Kc)を用いて、暗号化されたコンテンツを復号する。
【００２４】
コンテンツパケット解析部９０８は、暗号化されたコンテンツに付随する更新情報(Nc)、コピー制御情報(E_EMI)を分離し、夫々更新情報格納部９０３、コピー制御情報格納部９０４に渡す。
【００２５】
コンテンツパケット受信部９０９は、コンテンツパケットを受信する。
【００２６】
HTTPプロトコル部９１０は、HTTPクライアント処理を行う。HTTPリクエストを作成・送信し、ＨＴＴＰレスポンスを受信・解析する。
【００２７】
以下、図１０を用いて、従来の暗号通信プロトコル手順について説明する。
【００２８】
（１００１）送信機８００と受信機９００の間の認証プロセスを通じて、認証鍵(Kauth)が共有される。これは一回の認証毎に使い捨てられる。
【００２９】
（１００２）送信機８００は、交換鍵(Kx)を生成する。
【００３０】
（１００３）送信機８００は、認証鍵(Kauth)で交換鍵(Kx)を暗号化して(Ksx)、受信機に送付する。
【００３１】
（１００４）受信機９００は、受け取ったKsxを認証鍵(Kauth)で復号して、交換鍵(Kx)を得る。
【００３２】
（１００５）受信機９００から送信機８００に、HTTP GETリクエストによるコンテンツ要求が送信される。
【００３３】
（１００６）送信機８００は、更新情報(Nc)を生成する。
【００３４】
（１００７）送信機８００は、受信機９００から要求されたコンテンツのコピー制御情報(E_EMI)を認識する。
【００３５】
（１００８）送信機８００は、交換鍵(Kx),更新情報(Nc),コピー制御情報(E_EMI)を入力パラメータとして、一方向性関数により、コンテンツ鍵(Kc)を算出する。
【００３６】
（１００９）送信機８００は、受信機９００から要求されたコンテンツをコンテンツ鍵(Kc)により暗号化する。
【００３７】
（１０１０）送信機８００は、HTTP GETレスポンスのボディとして、暗号化したコンテンツに更新情報(Nc)、コピー制御情報(E_EMI)を付加して、受信機に送信する。
【００３８】
（１０１１）受信機９００は、受信したレスポンスから、更新情報(Nc)を獲得する。
【００３９】
（１０１２）受信機９００は、同様に、受信したレスポンスから、コピー制御情報(E_EMI)を獲得する。
【００４０】
（１０１３）受信機９００は、交換鍵(Kx),更新情報(Nc),コピー制御情報(E_EMI)を入力パラメータとして、一方向性関数により、コンテンツ鍵(Kc)を算出する。
【００４１】
（１０１４）受信機９００は、コンテンツ鍵(Kc)を用いて、暗号化されたコンテンツを復号する。
【００４２】
上記の一連のプロトコル手順によって、送信機と受信機の間に、共通の交換鍵(Kx)（１０８０、１０９０）と、コンテンツに付随する、更新情報(Nc)（１０８１、１０９１）とコピー制御情報(E_EMI)（１０８２、１０９２）が共有され、正当な受信機でのみこれらを用いて、暗号化されたコンテンツを正しく復号することができる
【非特許文献１】DTCP Volume 1 Supplement E Mapping DTCP to IP (Informational Version) Revision 1.0 November 24, 2003
【発明の開示】
【発明が解決しようとする課題】
【００４３】
しかしながら、従来のシステムにおいて、交換鍵を共有している当事者間での暗号通信によるコンテンツ保護の仕組みは確立されているが、不特定多数の機器が接続するIPネットワークの特性上「誰が送ってきたのか」という認証の問題が発生する可能性がある。すなわち、受信機がコンテンツを要求し受信したとしても、間違いなく要求先の正当な送信機からの正当なコンテンツであることを確認する手段がないため、例えば、攻撃者が、ＩＰネットワークを監視し、流れる暗号化コンテンツを記録（キャッシュ保存）し、その後、受信機の要求に対し、正当な送信機になりすましてコンテンツを応答しても判別できない。
【００４４】
以下、図１１を用いて、課題とされる一事例を説明する。
【００４５】
送信機８００と受信機９００は、交換鍵を共有している、正当な暗号通信対象機器である。送信機８００と受信機９００の間では、受信機９００のコンテンツ要求（１１１１）に応じて、付随情報を伴った暗号化コンテンツ（１１１２）が伝送される。ここで、ネットワーク上に接続した不正な機器１１００は、バス上を流れるHTTPリクエスト、レスポンスを監視し、これらを記録することができる（１１１３）。不正な機器１１００自身はコンテンツを復号し、視聴するなどの利用はできないが、例えば、その後、受信機９００から送信機８００へのHTTPリクエストをフックし（１１１４）、正当な送信機８００に成りすまし、以前記録したコンテンツを、本来受信機９００が受け取るべきコンテンツにすり替えて送信する（１１１５）ことができてしまう。
【００４６】
以上の背景から、本発明の目的は、不当ななりすまし機器からのすり替えコンテンツの受信を防止できる正規コンテンツ確認方法を提供することである。
【課題を解決するための手段】
【００４７】
前述の目的を達成するために、本発明の第１の正規コンテンツ確認方法は、コンテンツの暗号化/復号に用いるコンテンツ鍵の作成に必要な更新情報を暗号化されたコンテンツに付随して伝送するシステムにおいて、受信機は確認要求として少なくとも前記更新情報を送信機に送信し、前記送信機は前記更新情報が使用中であるかどうかを照合し、使用中であれば前記送信機と前記受信機であらかじめ共有されている交換鍵と前記更新情報を用いて作成した了承メッセージを前記受信機に送ることを特徴とする。
【００４８】
本発明の第２の正規コンテンツ確認方法は、送信機は受信機から受け取った更新情報が直前に使用した更新情報であっても使用中であると判断することを特徴とする。
【００４９】
本発明の第３の正規コンテンツ確認方法は、受信機は確認要求として確認要求のたびに異なる数も送信機に送信し、前記送信機が了承メッセージを作成する際には、前記確認要求のたびに異なる数も利用することを特徴とする。
【００５０】
本発明の第４の正規コンテンツ確認方法は、受信機は確認要求として交換鍵と更新情報を用いて作成したメッセージも送信機に送信し、前記送信機は前期メッセージが正しく作成されており、かつ、更新情報が使用中である場合に了承メッセージを前記受信機に送ることを特徴とする。
【００５１】
本発明の第５の正規コンテンツ確認方法は、送信機は受信機から受け取った更新情報が使用中であるかどうかを照合し、使用中でなければ非了承メッセージを前記受信機に送り、前記受信機は非了承メッセージを受信した場合には受信コンテンツを利用しないことを特徴とする。
【００５２】
本発明の第６の正規コンテンツ確認方法は、受信機は、了承メッセージを受信できない場合、所定期間、確認要求を繰り返し行うが、前期所定期間を過ぎても前記了承メッセージを受信できない場合には、受信コンテンツを利用しないことを特徴とする。
【００５３】
本発明の第７の正規コンテンツ確認方法は、受信機は、受信機は、了承メッセージを受信できない場合、所定回数、確認要求を繰り返し行うが、前期所定回数を過ぎても前記了承メッセージを受信できない場合には、受信コンテンツを利用しないことを特徴とする。
【００５４】
本発明の第８の正規コンテンツ確認方法は、受信機は、了承メッセージを受信できるまで確認要求を繰り返し行い、前記了承メッセージを受信したらコンテンツを利用することを特徴とする。
【発明の効果】
【００５５】
本発明の正規コンテンツ確認方法では、送信機は、受信機から送信された更新情報から、当該受信機が現在正しいコンテンツを受信しているかどうかを確認できる。一方、その確認結果通知である了承メッセージが、正当な送信機と当該受信機の間であらかじめ共有された交換鍵を用いて作成されるため、受信機は、受信した了承メッセージが、正当な送信機から送られたものかどうかを確認できる。これにより、不当ななりすまし機器からのすり替えコンテンツを判別することができる。
【００５６】
また、送信機における更新情報の更新は、内部処理のため、直前の更新情報が付加されたコンテンツを受信機が受信するよりも早いタイミングで行われることが考えられるため、直前の更新情報についても了承対象とすることにより、正しいコンテンツの送受信に関して誤った確認を行う頻度を軽減するという効果が得られる。
【００５７】
また、確認要求の度に異なる数も用いることにより、受信機から不正な機器が、送信機と受信機の間で交換される更新情報と了承メッセージの組み合わせを記憶しておくことにより、なりすまし機器のすり替えコンテンツ受信中に、識別を成功させるのを防ぐ。
【００５８】
また、確認要求に、正当な送信機と当該受信機の間であらかじめ共有された交換鍵を用いて作成されたメッセージを含めることにより、不正な機器が、現在使用中の更新情報を当該送信機に送信しても対応する了承メッセージを獲得できなくすることができるため、なりすまし機器のすり替えコンテンツ受信中に、識別を成功させるのを防ぐ。
【００５９】
ここで、受信機は、了承メッセージを受信できない場合には、受信コンテンツを利用しないことにより、不当ななりすまし機器からのすり替えコンテンツがユーザに利用可能となるのを防ぐ。
【００６０】
また、受信機は、了承メッセージを受信できない場合には、所定期間あるいは所定回数リトライを行った後に受信コンテンツを利用しないことにより、不正な機器が邪魔することにより、受信機が永遠にリトライしている間コンテンツが利用できてしまう（視聴できる）のを防ぐ。
【００６１】
また、受信機は、受信コンテンツの利用を中止した後も、了承メッセージを受信できるまで確認要求を行うことにより、不正な機器のなりすましが終われば、直ちに受信を再開できるという効果が得られる。
【発明を実施するための最良の形態】
【００６２】
（実施の形態１）
以下、本発明の正規コンテンツ確認方法について、従来の伝送システムに適応した場合について説明する。なお、以下の実施例において、前記従来例と同一あるいはそれに相当する処理・構成については、同一符号を用いてその詳細な説明を省略する。
【００６３】
図１は、実施の形態１に係る送信機の機能ブロック図である。
【００６４】
送信機１００は、図８の送信機８００と同様、証明書・鍵保持部８０１、交換鍵作成部８０２、認証・鍵交換部８０３、コピー制御情報管理部８０５、コンテンツ鍵算出部８０６、コンテンツ蓄積部８０７、コンテンツ暗号化部８０８、コンテンツパケット作成部８０９、コンテンツパケット送信部８１０、ＨＴＴＰプロトコル部８１１を備える。さらに、確認要求受付部１０１、識別情報確認部１０２、更新情報確認部１０３、確認応答部１０４、更新情報作成・更新部１０５を備える。
【００６５】
確認要求受付部１０１は、受信機から、更新情報(test_Nc)と任意の数（N=受信機が確認要求のたびに異なる数を指定する）、識別情報で構成される確認要求を受信する。
【００６６】
情報識別情報確認部１０２は、受信した確認要求に含まれる識別情報が、正しい受信機であることを示す情報であるかどうかを確認する。ここで、識別情報は、同じく確認要求に含まれる更新情報(Nc)と任意の数（N）、そして、受信機との間で共有されている交換鍵(Kx)を用いて算出されたものであり、同様の算出を行うことにより、送信機において正しい識別情報であるかどうかを確認できる。ここで、例えば、識別情報は、交換鍵(Kx)を連結した数をハッシュ関数に入力し、算出されたハッシュ値と更新情報(Nc)と任意の数(N)を加算し、さらにハッシュ関数に入力して得た値（160ビット）の下位80ビットとする。ハッシュ値は擬似的な乱数のような値をとり、これをもとに原文を再現することはできないので、不当な機器が交換鍵(Kx)を解読することはできない。
【００６７】
更新情報作成・更新部１０５は、送信機８００の更新情報作成・更新部８０４と同様、更新情報(Nc)を新規作成あるいは更新すると同時に、更新前の更新情報(pre_Nc)を保持する。
【００６８】
更新情報確認部１０３は、受信した確認要求に含まれる更新情報(test_Nc)が、現在、送信機１００がコンテンツ送信のために使用中の更新情報と一致するかどうかを確認する。ここで、使用中の更新情報としては、更新情報作成部・更新部１０５で管理されている更新情報(Nc)あるいは直前の更新情報(pre_Nc)をさす。また、更新情報が短い期間で変更されることを考慮し、それまでに使用した複数の更新情報を直前の更新情報として保持しても良い。
【００６９】
確認応答部１０４は、前記識別情報確認部１０２及び前記更新情報確認部１０３で是と判定した場合、受信機から受け取った更新情報(test_Nc)と任意の数（N）、そして、受信機との間に共有されている交換鍵(Kx)を用いて了承メッセージを作成し、当該受信機に送信する。ここで、例えば、了承メッセージは、下記のように算出される。交換鍵(Kx)を連結した数をハッシュ関数に入力し、ハッシュ値を算出する。算出されたハッシュ値と受信機からの更新情報(test_Nc)と任意の数(N)を加算し、さらにハッシュ関数に入力し得られた値（160ビット）の上位80ビットを了承メッセージに用いる。前記識別情報確認部１０２あるいは前記更新情報確認部１０３で否と判定した場合、非了承メッセージを作成し、当該受信機に送信する。非了承メッセージは、その目的として了承メッセージと異なる値を利用すればよい。例えば、了承メッセージと同様にして得られた値の下位80ビットを用いてもよい。また、了承メッセージと同様にハッシュ値を算出する際に用いる任意の数(N)を変更（例えば１を加算）して得られた値の上位80ビットを用いてもよい。
【００７０】
図２は、実施の形態１に係る受信機の機能ブロック図である。
【００７１】
受信機２００は、図９の受信機９００と同様、証明書・鍵保持部９０１、認証・鍵交換部９０２、更新情格納部９０３、コピー制御情報格納部９０４、コンテンツ鍵算出部９０５、コンテンツ復号部９０７、コンテンツパケット解析部９０８、HTTPプロトコル部９１０を備える。さらに、確認パラメータ生成部２０１、確認要求部２０２、確認結果照合部２０３、コンテンツパケット受信部２０４、コンテンツr利用部２０５を備える。
【００７２】
ここで、確認パラメータ作成部２０１は、確認要求のたびに異なる数(N)を生成する。そして、
更新情報(Nc)と作成した任意の数（N）、そして、送信機との間に共有されている交換鍵(Kx)を用いて識別情報を算出する。識別情報の算出方法は前述しているため省略する。
【００７３】
確認要求部２０２は、更新情報格納部９０３に格納されている更新情報(現在受信している暗号化コンテンツに付随してきたNcであり、Test_Ncとなる)、と確認パラメータ作成部２０１で作成された任意の数（N）と識別情報で構成される確認要求を送信機へ送信する。
【００７４】
確認結果照合部２０３は、送信機から受信した応答メッセージが、了承メッセージであるかどうかを確認する。ここで、了承メッセージかどうかを確認するために、送信した更新情報(test_Nc)と任意の数（N）、送信機との間に共有されている交換鍵(Kx)を用いて了承メッセージと同様の算出を行い、比較する。了承メッセージの算出方法は前述しているため省略する。
【００７５】
コンテンツパケット受信部２０４は、確認結果照合部２０３で判定された結果を受け、正しくないと判定された場合には、そのコンテンツを含むHTTPレスポンスの終了まで、そのボディとして受信しているコンテンツパケットを破棄する。正しいコンテンツであれば、そのまま受信を継続する。
【００７６】
コンテンツパケット利用部２０５は、確認結果照合部２０３で判定された結果を受け、正しくないと判定された場合には、そのコンテンツの利用を中止する。正しいコンテンツであれば、そのまま利用を継続する。
【００７７】
図３は、実施の形態１に係る処理手順（プロトコル）を示す図である。認証・鍵の共有やコンテンツのリクエストおよび受信の処理手順は、前記従来例の図１０での記載と同一であり省略する。図３を用いて、受信機２００が行う、受信コンテンツが正規であるかどうかを確認するプロトコル動作について説明する。
【００７８】
ステップＳ３２１：コンテンツ利用部２０５にて、復号コンテンツの利用を開始する。
【００７９】
ステップＳ３２２：確認パラメータ作成部２０１にて、任意の数(N)と識別情報を作成する。ここで、Nは直前に実施した確認要求で使用した数と等しくならないように作成される。
【００８０】
ステップＳ３２３：確認要求部２０２にて、コンテンツに付随していた更新情報(Nc)と任意の数(N)、そして識別情報を用いた確認要求を作成し、送信する。
【００８１】
ステップＳ３２４：確認結果照合部２０３にて、送信機より、応答メッセージを受信する。
【００８２】
ステップＳ３２５：確認結果照合部２０３にて、受信した応答メッセージが了承メッセージであるかどうかを確認する。了承メッセージであれば、ステップＳ３２６に進み、コンテンツの利用を継続する。了承メッセージでなければ、ステップＳ３２７に進み、コンテンツの利用を中止する。
【００８３】
ステップＳ３２６：コンテンツ利用部２０５にて、復号されているコンテンツの利用を継続する。
【００８４】
ステップＳ３２７：コンテンツ利用部２０５にて、コンテンツ利用を中止し、コンテンツパケット受信部２０４にて、受信中のコンテンツパケットを破棄する。
【００８５】
図３を用いて、送信機１００が行う、受信機が正規コンテンツを受信しているかどうかを確認するためのプロトコル動作について説明する。
【００８６】
ステップＳ３１１：確認要求受付部１０１にて、受信機より、確認要求を受信する。
【００８７】
ステップＳ３１２：識別情報確認部１０２にて、受信した確認要求に含まれる識別情報が正しいかどうかを判断する。正しければ、ステップＳ３１４に進み了承メッセージを作成する。正しくなければステップＳ３１６に進み、非了承メッセージを作成する。
【００８８】
ステップＳ３１３：更新情報確認部１０３にて、受信した確認要求に含まれる更新情報が使用中とみなせるかどうかを判断する。使用中であれば、ステップＳ３１４に進み、了承メッセージを作成する。使用中でなければ、ステップＳ３１６に進み、非了承メッセージを作成する。
【００８９】
ステップＳ３１４：確認応答部１０４にて、受信機から受け取った更新情報と任意の数（N）、そして、受信機との間に共有されている交換鍵(Kx)を用いて了承メッセージを作成する。
【００９０】
ステップＳ３１５：確認応答部１０４にて、応答メッセージを送信する。
【００９１】
ステップＳ３１６：確認応答部１０４にて、了承メッセージとは異なる非了承メッセージを作成する。そのままステップＳ３１５に進む。
【００９２】
更新情報は、送信機により所定のルールに従って、更新される。従って、不当な機器がコンテンツのすり替えを行った場合、すりかえられたコンテンツに付随している更新情報と、送信機がその時点で保持している更新情報は一致しない。したがって、送信機は、受信機から送信された更新情報から、当該受信機が現在、正しいコンテンツを受信しているかどうかを確認できる。一方、その確認結果通知である了承メッセージが、正当な送信機と当該受信機の間であらかじめ共有された交換鍵を用いて作成されるため、受信機は、受信した了承メッセージが、正当な送信機から送られたものかどうかを確認できる。これにより、不当ななりすまし機器からのすり替えコンテンツを判別することができる。
【００９３】
また、送信機における更新情報の更新は、内部処理のため、直前の更新情報が付加されたコンテンツを受信機が受信するよりも早いタイミングで行われることが考えられるため、直前の更新情報についても了承対象とすることにより、正しいコンテンツの送受信に関して誤った確認を行う頻度を軽減するという効果が得られる。
【００９４】
また、確認要求の度に異なる数も用いることにより、受信機から不正な機器が、送信機と受信機の間で交換される更新情報と了承メッセージの組み合わせを記憶しておくことにより、なりすまし機器のすり替えコンテンツ受信中に、識別を成功させるのを防ぐ。
【００９５】
また、確認要求にも、正当な送信機と当該受信機の間であらかじめ共有された交換鍵を用いて作成したメッセージを含めることにより、不正な機器が、現在使用中の更新情報を当該送信機に送信しても対応する了承メッセージを獲得できなくすることができるため、なりすまし機器のすり替えコンテンツ受信中に、識別を成功させるのを防ぐ。
【００９６】
また、受信機は、了承メッセージを受信できない場合には、すなわち、非了承メッセージを受信した場合には、受信コンテンツを利用しないことにより、不正な機器が邪魔することにより、不当ななりすまし機器からのすり替えコンテンツがユーザに利用可能となるのを防ぐ。
【００９７】
なお、実施の形態１では、送信機、受信機間でHTTPプロトコルを用いて、コンテンツの送受信を行う場合について説明しているが、本発明はこれに限らず、例えば、送信機がコンテンツをリアルタイムでストリーミング配信する場合についても適応できる。
【００９８】
（実施の形態２）
実施の形態２では、実施の形態１と異なる部分について説明する。実施の形態２では、受信機から送信機に対し確認要求を最大所定回数までリトライする。
【００９９】
図４は、実施の形態２に係る受信機の機能ブロック図である。
【０１００】
受信機４００は、図２の受信機２００と同様、証明書・鍵保持部９０１、認証・鍵交換部９０２、更新情格納部９０３、コピー制御情報格納部９０４、コンテンツ鍵算出部９０５、コンテンツ復号部９０７、コンテンツパケット解析部９０８、HTTPプロトコル部９１０、確認パラメータ生成部２０１、確認要求部２０２、確認結果照合部２０３を備える。さらに、リトライ判断部４０１、コンテンツパケット受信部４０２、コンテンツ利用部４０３を備える。
【０１０１】
リトライ判断部４０１は、確認結果照合部２０３で否と判定された場合に、リトライを行うかどうかを判断する。ここで、例えば、確認要求を行った回数でさらにリトライを行うかどうかを判断するとし、同じ更新情報を用いて連続して既に２回確認要求を行っている場合には、これ以上リトライを行わないと判断する。
【０１０２】
コンテンツパケット受信部４０２は、リトライ判断部４０１を経由し、確認結果照合部２０３で判定された結果を受け、正しくないと判定された場合には、そのコンテンツを含むHTTPレスポンスの終了まで、そのボディとして受信しているコンテンツパケットを破棄する。正しいコンテンツであれば、そのまま受信を継続する。
【０１０３】
コンテンツパケット利用部４０３は、リトライ判断部４０１を経由し、確認結果照合部２０３で判定された結果を受け、正しくないと判定された場合には、そのコンテンツの利用を中止する。正しいコンテンツであれば、そのまま利用を継続する。
【０１０４】
図５は、実施の形態２に係る処理手順（プロトコル）を示す図である。図５を用いて、受信機４００が行う、受信コンテンツが正規であるかどうかを確認するプロトコル動作について説明する。ステップＳ３２１〜ステップＳ３２４までは、前記実施例１の図３での記載と同一であり、省略する。
【０１０５】
ステップＳ３２５：確認結果照合部２０３にて、受信した応答メッセージが了承メッセージであるかどうかを確認する。了承メッセージであれば、ステップＳ３２６に進み、コンテンツの利用を継続する。了承メッセージでなければ、ステップＳ５０１に進み、リトライするかどうかを判断する。
【０１０６】
ステップＳ３２６：コンテンツ利用部４０３にて、復号されているコンテンツの利用を継続する。
【０１０７】
ステップＳ５０１：リトライ判断部４０１にて、確認要求のリトライを行うかどうかを判断する。リトライする場合には、ステップＳ３２２に戻り、確認要求送信のための準備をする。リトライしない場合には、Ｓ３２７に進む。
【０１０８】
ステップＳ３２７：コンテンツ利用部４０３にて、コンテンツ利用を中止し、コンテンツパケット受信部４０２にて、受信中のコンテンツパケットを破棄する。
【０１０９】
従って、リトライにより正しいコンテンツの送受信に関して誤った確認を行う頻度を軽減するという効果を得ると同時に、最大リトライ回数を設けることにより、不正な機器が邪魔することにより、受信機が永遠にリトライしている間コンテンツが利用できてしまう（視聴できる）というのを防ぐ。
【０１１０】
なお、実施の形態２では、リトライの制限を回数としたが、期間（時間）で設けてもよく、同様の効果が得られる。
【０１１１】
また、実施の形態２では、リトライ時に用いる更新情報は最初の時の更新情報と同一固定としたが、受信コンテンツと共に変化していく更新情報と同期させてもよい。
【０１１２】
（実施の形態３）
実施の形態３では、実施の形態１と異なる部分について説明する。実施の形態３では、受信機が受信コンテンツの利用を中止した後も、了承メッセージを受信できるまで、確認要求を行う。
【０１１３】
図６は、実施の形態３に係る受信機の機能ブロック図である。
【０１１４】
受信機６００は、図４の受信機４００と同様、証明書・鍵保持部９０１、認証・鍵交換部９０２、更新情格納部９０３、コピー制御情報格納部９０４、コンテンツ鍵算出部９０５、コンテンツ復号部９０７、コンテンツパケット解析部９０８、HTTPプロトコル部９１０、確認パラメータ生成部２０１、確認結果照合部２０３、リトライ判断部４０１、コンテンツ利用部４０３を備える。さらに、確認要求部６０１、コンテンツパケット受信部６０２を備える。
【０１１５】
確認要求部６０１は、一旦コンテンツの利用を中止した後も、確認要求を送信機へ送信する。ここで、例えば、確認要求を送信するタイミングは、所定期間の繰り返しとする。
【０１１６】
コンテンツパケット受信部６０２は、確認要求部６０１からリクエストがあれば、受信中のコンテンツパケットを破棄せずに、コンテンツパケット解析部９０８へ渡す。これは、確認要求作成に必要な、現在受信中のコンテンツに付随する更新情報(Nc)とコピー制御情報(E_EMI)を格納するためである。
【０１１７】
図７は、実施の形態３に係る処理手順（プロトコル）を示す図である。図７を用いて、受信機６００が行う、受信コンテンツが正規であるかどうかを確認するプロトコル動作について説明する。ステップＳ３２１〜ステップＳ３２７までは、前記実施例２の図５での記載と同一であり、省略する。
【０１１８】
ステップＳ７０１：確認要求部６０１にて、所定の時間が経過しているかどうかを確認し、経過していれば、コンテンツ受信部６０２での受信コンテンツパケットの破棄を中止し、ステップＳ３２２に戻り、確認要求を送信する。
【０１１９】
従って、不正な機器の成りすましが終われば、直ちに受信を再開できる。
【０１２０】
なお、実施の形態３では、コンテンツの利用中止後の確認要求の発行を、所定期間の繰り返しとしたが、ユーザの入力指定であってもよい。
【産業上の利用可能性】
【０１２１】
本発明の正規コンテンツ確認方法は、ネットワーク上で、不正な機器が、正当な送信機と受信機の間の通信を監視し受信機に不当なコンテンツを送りつけるといった攻撃を逃れるためのコンテンツ確認技術として有用である。
【図面の簡単な説明】
【０１２２】
【図１】本発明の実施の形態１に係る送信機の機能ブロックを示す図
【図２】本発明の実施の形態１に係る受信機の機能ブロックを示す図
【図３】本発明の実施の形態１に係る処理手順を示す図
【図４】本発明の実施の形態２に係る受信機の機能ブロックを示す図
【図５】本発明の実施の形態２に係る処理手順を示す図
【図６】本発明の実施の形態３に係る受信機の機能ブロックを示す図
【図７】本発明の実施の形態３に係る処理手順を示す図
【図８】従来の実施の形態に係る送信機の機能ブロックを示す図
【図９】従来の実施の形態に係る受信機の機能ブロックを示す図
【図１０】従来の実施の形態に係る暗号通信プロトコル手順を示す図
【図１１】従来の実施の形態に係るネットワーク構成と課題を示す図
【符号の説明】
【０１２３】
１００    送信機
１０１    確認要求受付部
１０２    識別情報確認部
１０３    更新情報確認部
１０４    確認応答部
１０５    更新情報作成・更新部
２００    受信機
２０１    確認パラメータ生成部
２０２    確認要求部
２０３    確認結果照合部
２０４    コンテンツパケット受信部
２０５    コンテンツ利用部
８０１    証明書・鍵保持部
８０２    交換鍵作成部
８０３    認証・鍵交換部
８０５    コピー制御情報管理部
８０６    コンテンツ鍵算出部
８０７    コンテンツ蓄積部
８０８    コンテンツ暗号化部
８０９    コンテンツパケット作成部
８１０    コンテンツパケット送信部
９０１    証明書・鍵保持部
９０２    認証・鍵交換部
９０３    更新情報格納部
９０４    コピー制御情報格納部
９０５    コンテンツ鍵算出部
９０７    コンテンツ復号部
９０８    コンテンツパケット解析部
９１０    ＨＴＴＰプロトコル部
【図１】
2006115083.tif 000003
【図２】
2006115083.tif 000004
【図３】
2006115083.tif 000005
【図４】
2006115083.tif 000006
【図５】
2006115083.tif 000007
【図６】
2006115083.tif 000008
【図７】
2006115083.tif 000009
【図８】
2006115083.tif 000010
【図９】
2006115083.tif 000011
【図１０】
2006115083.tif 000012
【図１１】
2006115083.tif 000013