本発明は、WANなどの外部ネットワークを経由したリモート・アクセス(RA)を通じてコンテンツを安全に伝送する通信システムに関するものである。同通信システムは、基本的に、リモート・アクセスによりコンテンツを提供するサーバ(RA−Source)と、リモート・アクセスによりコンテンツを要求するクライアント(RA−Sink)からなる。本明細書では、リモート・アクセス時に行なうAKE手続きを、「RA−AKE」と呼ぶことにする。以下、図面を参照しながら本発明の実施形態について詳細に説明する。
図1には、本発明に係る通信システムの一構成例を模式的に示している。図示の通信システムでは、RA−Sourceに相当するコンテンツ提供装置10が家庭内に設置され、RA−Sinkに相当するコンテンツ利用装置20が屋外にいる。そして、コンテンツ利用装置20は、携帯電話のような通信機能によってコンテンツ提供装置10に対してリモート・アクセスする。
コンテンツ提供装置10は、一般にルーター30とモデム40経由でWAN50などの外部ネットワークに接続される。WAN50は例えばインターネットである。ルーター30には、WAN50側のIPアドレスが、ユーザーが加入するIntenet Accsess Service(IAS)プロバイダー60から割り当てられる。また、コンテンツ利用装置20も、基本的にこのIPアドレスにアクセスする。ルーター30は、コンテンツ提供装置10にはプライベートIPアドレスを割り当て、WAN50からのアクセスについてはポート・フォワーディングによって通信を中継する。なお、ルーター30に割り当てられるIPアドレスは、IASプロバイダー60によって更新される場合があるが、そのようなケースではDDNSサービス70を用い、ルーター30乃至コンテンツ提供装置10のDDNS(Dynamic DNS(Domain Name System))機能を使うことで対応できる。
また、図2には、本発明に係る通信システムの他の構成例を模式的に示している。図示の通信システムでは、RA−Sinkに相当するコンテンツ利用装置20も家庭内に設置され、ルーター31とモデム41経由でWAN50に接続されている。コンテンツ利用装置20から発信されるTCP/IP(Transmission Control Protocol/Internet Protocol)通信は、ルーター31のNAT(Network Address Translation)機能によってアドレス変換されるが、それ以外は図1の場合と同様である。
図3には、コンテンツ提供装置10の機能的構成を模式的に示している。コンテンツ提供装置10は、CPU(Central Processing Unit)11と、コンテンツ受信/再生部12と、通信部13と、記憶部14と、タイマー15を備えるが、RA−Sourceとして機能して、リモート・アクセスでコンテンツを送信する。
コンテンツ受信/再生部12は、放送受信機能や、パッケージ・メディア再生機能をそなえている。CPU11は、コンテンツ受信/再生部12で得られるコンテンツについて、リモート・アクセス可能なものを適切な保護を施した後に、通信部13を通じて、RA−AKEにより相互認証及び鍵交換を行なったRA−Sink(コンテンツ利用装置20)に送信する。
記憶部14には、後述の登録処理によって記憶することになったRA−Sinkの識別情報や、RA−AKEを通じてRA−Sinkと共有したリモート・アセス用の交換鍵とその交換鍵の識別情報などが記憶される。また、記憶部14は、コンテンツ受信/再生部12で得たコンテンツを蓄積する用途で用いることもできる。
タイマー15は、リモート・アクセス可能なコンテンツを扱う際に、時間管理が必要となる場合(例えば、後述するように、基準点時刻からのリモート・アクセス不可期限を管理する場合)に使われる。
図4には、コンテンツ利用装置20の機能的構成を模式的に示している。コンテンツ利用装置20は、CPU21と、通信部22と、コンテンツ出力部23と、記憶部24を備えるが、RA−Sinkとして機能して、リモート・アクセスでコンテンツを受信する。
RA−Sinkとしてのコンテンツ利用装置20は、通信部22を通じてRA−Source(コンテンツ提供装置10)に対して後述の機器登録処理を行なう他、RA−AKEを行なってRA−Sourceから交換鍵を取得して記憶部24に保持するとともに、その鍵を基に算出する暗号鍵でRA−Sourceから得た暗号化コンテンツを復号して、コンテンツ出力部23からコンテンツを出力する。記憶部24は、RA−Sourceから受け取った交換鍵やコンテンツを蓄積する用途で用いられる。
以下の説明では、交換鍵から暗号鍵を算出する方法はDTCP−IPに従うものとする(但し、本発明の要旨は必ずしもこの方法には限定されない)。
ここで、SourceとSinkの間でDTCP−IPにより暗号化コンテンツ伝送を行なう仕組みについて、図5を参照しながら説明しておく。コンテンツ伝送の形態は、Source上のコンテンツをSinkにコピーする方法と、SourceからSinkへコンテンツを移動してSourceにコンテンツを残さない方法があるが(周知)、同図では前者のコピーによるコンテンツ伝送方法を前提にして説明する。
SourceとSinkは、まず1つのTCP/IPコネクションを確立して、機器同士の認証(AKE手続き)を行なう。DTCP準拠機器には、DTLA(前述)により発行された機器証明書が埋め込まれている。AKE手続きでは、互いが正規のDTCP準拠機器であることを確かめた後、認証鍵KauthをSourceとSinkで共有することができる。
AKE手続きが成功すると、Sourceはコンテンツ鍵Kcの種となる交換鍵Kxを生成し、認証鍵Kauthで暗号化してSinkに送る。Source及びSinkそれぞれにおいて、交換鍵Kxに対して所定の演算処理を適用することによって、コンテンツ伝送時にコンテンツを暗号化するために使用されるコンテンツ鍵Kcを生成することができる。
そして、DTCP準拠の機器間でAKEによる認証及び鍵交換手続きが済んだ後、HTTPやRTPなどのプロトコルを利用してコンテンツ伝送が開始される。図示の例では、HTTPの手続きに従ってコンテンツ伝送が行なわれる。その際、AKE手続きのためのTCP/IPコネクションとは別に、HTTPのためのTCP/IPコネクションが作成される(すなわち、SourceとSinkはそれぞれ、AKE手続き用とコンテンツ伝送用に個別のソケット情報(IPアドレスとポート番号の組み合わせ)を持つ)。
HTTPプロトコルに従ってコンテンツ伝送を行なうには、SinkがSourceにコンテンツを要求するダウンロード形式と、Source側からSinkにコンテンツをプッシュするアップロード形式の2通りが挙げられる。前者の場合、HTTPクライアントとしてのSinkは、例えばHTTP GETメソッドを用いたHTTPリクエストにより、HTTPサーバーとしてのSourceにコンテンツを要求し、これに対し、Souceからは要求通りのコンテンツがHTTPレスポンスとして伝送される。また後者の場合、HTTPクライアントとしてのSourceは、例えばHTTP POSTメソッドを用いたHTTPリクエストにより、HTTPサーバーとしてのSinkとの伝送を開始する。
Sourceから伝送されるデータは、SourceがAKE認証をした後に共有した鍵を用いてコンテンツを暗号化したデータとなっている。具体的には、Sourceは、乱数を用いてノンスNcを生成して、交換鍵KxとノンスNcと暗号モードに応じたコンテンツ鍵Kcを生成する。そして、Sinkから要求されているコンテンツを、コンテンツ鍵Kcを用いて暗号化し、暗号化コンテンツからなるペイロードとノンスNcと暗号モードの情報を含んだヘッダからなるパケットをTCPストリーム上に乗せて送信する。IPプロトコルでは、TCPストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダ部を付加したIPパケットにし、指定されたIPアドレス宛てに届ける。
Sink側では、Sourceからの各IPパケットを受信すると、これをTCPストリームに組み立てる。そして、このストリームからノンスNcとE−EMIを取り出すと、これらと交換鍵Kxを用いてコンテンツ鍵Kcを算出し、暗号化コンテンツを復号することができる。そして、復号化した後の平文のコンテンツに対し再生処理を実施することができる。あるいは、Sinkは、暗号化コンテンツを復号することなく、コンテンツを記憶部24に格納したり、他の機器にスルーしたりする。このようにしてHTTPプロトコルを利用したコンテンツ伝送が終了すると、例えばSink側から、コンテンツ伝送に使用したTCPコネクションを適宜切断する。(DTCP−IPでは、パケットのヘッダ部に記述するE−EMI(ExtendedEncryption Mode Indicator)と、Embedded CCI(Copy Control Information)という2つのメカニズムにより、コンテンツに付随したコピー制御情報の伝送を実現している。)
なお、DTCP−IPでは、連続不使用時間が所定の期間(例えば2時間)を超える前に破棄することが規定されている。SinkはSourceから最新の交換鍵Kxを入手できなければ、暗号化コンテンツを利用不能となる。また、交換鍵Kxの運用方法には、Sink毎に1つずつ鍵を用意する方法と、Sinkによらず1つの鍵を使う方法がある。
図6には、SourceとSink間で現行のDTCP−IPに従って行なわれる、AKEコマンドを用いた相互認証及び鍵交換の動作シーケンス(RTT−AKE)を示している。
AKE手続きのチャレンジ・レスポンス部分(Challenge−Response portion of AKE)では、まず、コンテンツを要求するSinkから、Rx乱数とRx証明書を含んだRxチャレンジが送信される。これに対し、Sourceからは、Tx乱数及びTx証明書を含んだTxチャレンジが返信される。以降、Sourceから、Rx乱数、Txメッセージ、Tx署名を含んだRxレスポンスが送信されるとともに、SinkからはTx乱数、Rxメッセージ、Rx署名を含んだTxレスポンスが送信され、通常のチャレンジ・レスポンス認証手続きが続く。チャレンジ・レスポンス部分で送信されるコマンドには、各チャレンジ・コマンドには、機器固有の識別情報であるDevice IDが含まれている。
上記のチャレンジ・レスポンス応答手続きでは、TTL(IPルーターのホップ回数)の制限が課されている。すなわち、現在のDTCP−IPでは、送信機器はAKEで用いるコマンドを送るTCP/IP通信においてTTLが3以下に設定され、受信機器はTTLが3より大きい場合は受け取ったデータを無効にしなければならない。
その後、RTT保護プロトコル(Protected RTT Protocol)を経て、SourceからSinkへ、EXCHANGE_KEYコマンドが送信され、これに対し、Sinkからレスポンス(図示しない)が返される。
図6に示した現行のDTCP−IPに従うRTT−AKEでは、AKEコマンドに対し往復遅延時間(RTT)やIPルーターのホップ回数(TTL)が制限されており、現状のままでは、リモート・アクセスに適用することはできない(前述)。しかしながら、ユーザーの利便性を考えると、ユーザーが出先から自宅のサーバーにリモート・アクセスして、コンテンツを再生するという使い方が望まれる。勿論、著作権保護したいというコンテンツ・オーナーの利益を確保する必要がある。したがって、リモート・アクセスは、コンテンツ・オーナーが許容するコンテンツの範囲内に制限すべきであり、且つ、リモート・アクセスされるコンテンツの保護も行なわなければならない。
これに対し、本発明として提案する、リモート・アクセス時のAKE手続きすなわちRA−AKEでは、図6に示したRTT−AKE手続きで行なっている「Protected RTT Protocol」を行なわない。すなわち、SourceとSinkの間のRTTが7ミリ秒を超えてもAKE手続きを中止しない。また、RA−AKEでは、上記のTTLの上限を設けない。すなわち、RA−AKEでは、RTT並びにTTLの制限を設けないことで、リモート・アクセスに対応するSource(コンテンツ提供装置10)と、リモート・アクセスに対応するSink(コンテンツ利用装置20)が、応答遅延時間が7ミリ秒を超え、又は、ホップ数が3を超えるだけ離間していたとしても、両機器間でAKE手続きを成功裏に実施して、リモート・アクセス用の交換鍵を共有することができる。
但し、RTT並びにTTLの制限が外された状態の通信システムでは、任意の機器間でコンテンツの伝送が可能になるため、コンテンツの著作権保護の観点から不正な利用を防止する仕組みが必要になる。
RA−AKE手続きにおいてRTT並びにTTLの制限を設けないことに伴う不正な利用方法の1つとして、不特定多数(言い換えれば、著作権法で許容される私的使用の範囲を超えた)のユーザーが各自のRA−Sinkを特定のユーザーのRA−Sourceと接続し、そのコンテンツを遠隔利用することが考えられる。したがって、不特定多数のユーザーからの接続を制限する必要がある。
不特定多数のユーザーからの接続を制限するために、RA−Sourceが事前に登録されたRA−SinkとだけRA−AKE手続きを行なう方法と、RA−AKE手続きで鍵を渡すRA−Sinkの台数を制限する方法が考えられる。前者の事前登録に関しては、現在のDTCP−IPのRTT−AKEのように、RTTやTTL制限を伴うAKE手続きに成功した場合にだけ、RA−SourceがRA−Sinkの機器固有IDを記憶するようにすることで、不特定多数のユーザーがRA−AKE手続きを成功できないようにする。
また、RA−Sourceに登録するRA−Sinkの台数を制限することで、不正利用の規模を限定することができる。以下では、RA−Sourceは、所定台数までのRA−SinkのIDを登録するための「RAレジストリー」(記憶部14内に)を備えているものとする。ここで、仮にRA−Sinkの機器固有IDをRA−Sourceに登録できた場合であっても、後述するように、コンテンツ伝送の際にリモート・アクセス用の交換鍵を供給するRA−Sinkの台数を制限することで、不正利用の規模を限定することができる。
RA−Sinkの登録手続きは、例えば、RTT並びにTTLの制限に収まる家庭内で事前に行なわれる。その際、RA−Sourceは多めの10台のRA−Sinkを登録するようにしてもよい。そして、RA−Sourceに対し10台のRA−Sinkを事前登録したとしても、RA−Sourceはこのうちの5台までしかリモート・アクセス用の交換鍵を渡さないようにする。
図7には、RA−SourceにRA−Sinkを登録する際の認証シーケンス例を示している。
この認証シーケンスは、RA−SinkがRA−Sourceに対して登録要求コマンド「RA_REGI_INIT」を送信することによって開始する。RA−AKE手続きのチャレンジ・レスポンス部分(Challenge−Response portion of AKE)では、まず、RA−Sinkから、Rx乱数とRx証明書を含んだRxチャレンジが送信される。これに対し、RA−Sourceからは、Tx乱数及びTx証明書を含んだTxチャレンジが返信される。以降、RA−Sourceから、Rx乱数、Txメッセージ、Tx署名を含んだRxレスポンスが送信されるとともに、RA−SinkからはTx乱数、Rxメッセージ、Rx署名を含んだTxレスポンスが送信される。なお、「RA_REGI_INIT」を送信する代わりに、Rxチャレンジとして送信する情報の中に、「RA_REGI_INIT」の送信に相当する情報、例えば「RA_REGI_INIT_flag」を含める方法も考えられる。
各チャレンジ・コマンドには、機器固有の識別情報であるDevice IDが含まれている。但し、同チャレンジ・レスポンス部分の中では、SinkからSourceへのレスポンスとして「RESPONSE2」が送られることがある。これは、機器がCommon Device KeyとCommon Device Certificateを実装することで、Device IDが機器固有とならない場合である。RESPONSE2が送られる場合は、機器固有の識別情報として、Device IDではなく、RESPONSE2に含まれる機器固有情報であるIDuを使うことになる。
登録手続きにおけるRA−AKE手続きのチャレンジ・レスポンス部分は、現行のDTCP−IPにおけるRTT−AKE手続きと同様の処理となり、TTLの制限が課されている。その後、RTT保護プロトコル(Protected RTT Protocol)がさらに続き、RA−SourceとRA−Sinkの間のRTTが7ミリ秒を超えるとRA−AKE手続きを中止する。
RA−Sourceは、ここまでの手順に成功したRA−Sinkを登録するための「RA−Sink Registratoin」処理を実行する。そして、RA−Sourceは、記憶部14内のRAレジストリーにRA−SinkのIDを登録できる余裕があれば追加登録し、その結果を、結果コードを送るコマンド「RA_REGI_END」でRA−Sinkに通知する。
なお、図7中の「RA_REGI_INIT」と「RA_REGI_END」は、DTCP−IPのAKE control commandにリモート・アクセス用のコマンドとして追加するものとする。図28には、リモート・アクセス用のAKE control commandの構成例を示している。図示の例では、subfunctionフィールドに新たな値を割り当て、AKE_Infoで情報を運ぶことができる。
図8には、RA−SourceがRA−Sinkを登録するための「RA−Sink Registratoin」処理の手順をフローチャートの形式で示している。
RA−Sourceは、まず、当該処理ルーチンを開始する以前の処理(Challenge−Response portion of AKE、並びに、Protected RTT Protocol)を異常終了(abort)したか否かをチェックする(ステップS1)。
ここで、以前の処理を異常終了していた場合には(ステップS1のNo)、RA−Sourceは、要求元のRA−Sinkに対し、登録処理に「失敗」した旨の結果コードを通知して(ステップS9)、本処理ルーチンを終了する。
また、以前の処理を正常に終了していた場合には(ステップS1のYes)、RA−Sourceは、RESPONSE2(前述)を受信したか否かをチェックする(ステップS2)。そして、RESPONSE2を受信したときには(ステップS2のYes)、RA−Sourceは、要求元のRA−SinkのIDをIDuとする(ステップS3)。また、RESPONSE2を受信していないときには(ステップS2のNo)、RA−Sourceは、要求元のRA−SinkのDevice IDをIDとする(ステップS4)。
次いで、RA−Sourceは、要求元のRA−SinkのIDをRAレジストリーに既に登録済みか否かをチェックする(ステップS5)。
ここで、要求元のRA−SinkのIDをRAレジストリーに既に登録済みである場合には(ステップS5のYes)、RA−Sourceは、要求元のRA−Sinkに対し、登録処理に「成功」した旨の結果コードを通知して(ステップS8)、本処理ルーチンを終了する。
他方、要求元のRA−SinkのIDをRAレジストリーにまだ登録していないときには(ステップS5のNo)、RA−Sourceは、続いて、記憶部14内のRAレジストリーに空きがあるか否かをチェックする(ステップS6)。
ここで、RAレジストリーに空きがない場合には(ステップS6のNo)、RA−Sourceは、要求元のRA−Sinkに対し、登録処理に「失敗」した旨の結果コードを通知して(ステップS9)、本処理ルーチンを終了する。
また、RAレジストリーに空きがある場合には(ステップS6のYes)、RA−Sourceは、RAレジストリーにRA−SinkのIDを追加登録する(ステップS7)。そして、RA−Sourceは、要求元のRA−Sinkに対し、登録処理に「成功」した旨の結果コードを通知して(ステップS8)、本処理ルーチンを終了する。
図7並びに図8を参照しながら説明したように、RA−Sourceは、RTT−AKEと同様の認証手順に成功すると、RAレジストリーにRA−SinkのIDを登録できる余裕があれば追加登録する。RA−Sinkは、RA−Sourceにリモート・アクセスするには、上記認証手順を経て自分のIDをRA−SourceのRAレジストリーに登録することが必要である。したがって、RA−Sourceは、RAレジストリーの登録可能数によって、RA−Sourceを利用可能なRA−Sinkの台数を制限して、コンテンツの不正利用の規模を限定することができる。
図9には、RA−SourceがRA−Sinkに対してリモート・アクセス用の交換鍵を供給する際の認証シーケンス例を示している。図示のシーケンスは、リモート・アクセス用の交換鍵を供給するRA−Sinkの台数を制限する仕組みを備えている。
この認証シーケンスは、RA−SinkがRA−Sourceに対して鍵供給要求コマンド「RA_AKE_INIT」を送信することによって開始する。RA−AKE手続きのチャレンジ・レスポンス部分(Challenge−Response portion of AKE)では、まず、RA−Sinkから、Rx乱数とRx証明書を含んだRxチャレンジが送信される。これに対しRA−Sourceからは、Tx乱数及びTx証明書を含んだTxチャレンジが返信される。以降、RA−Sourceから、Rx乱数、Txメッセージ、Tx署名を含んだRxレスポンスが送信されるとともに、RA−SinkからはTx乱数、Rxメッセージ、Rx署名を含んだTxレスポンスが送信される。なお、「RA_AKE_INIT」を送信する代わりに、Rxチャレンジとして送信する情報の中に、「RA_AKE_INIT」の送信に相当する情報、例えば「RA_AKE_INIT_flag」を含める方法も考えられる。
各チャレンジ・コマンドには、機器固有の識別情報であるDevice IDが含まれている。但し、同チャレンジ・レスポンス部分の中では、SinkからSourceへのレスポンスとして「RESPONSE2」が送られることがあるが、その場合は、機器固有の識別情報として、Device IDではなく、RESPONSE2に含まれるIDuを使うことになる(同上)。
TTLの制限は、RA−Sourceへ登録する際には必要であるが、リモート・アクセス用の交換鍵供給のためのRA−AKE手続きでは省略される。また、RTT保護プロトコル(Protected RTT Protocol)も、鍵供給のためのRA−AKE手続きでは省略される。これによって、RA−Sinkは、リモート環境下でもリモート・アクセス用の交換鍵を要求することができ、すなわち、リモート・アクセスによるコンテンツの利用が可能になる。
そして、上記の認証手順に成功すると、RA−Sourceは、「RA−Sink ID confirmation」処理を実行する。この処理では、RA−Sourceは、要求元のRA−SinkのIDがRAレジストリーに登録済みであることを確認するとともに、リモート・アクセス用の交換鍵の供給数(KC)が上限を超えていないかを確認する。そして、RA−Sourceは、これらの確認ができた場合に、リモート・アクセス用の交換鍵(RA_Kx)と、当該交換鍵のID(RA_Kx_label)と結果コードを、コマンド「RA_EXCHANGE_KEY」でRA−Sinkに渡す。
なお、リモート・アクセス用の交換鍵の供給数KCの上限は、記憶部14内のRAレジストリーに登録できるIDの数と同じか、それより少なく設定される。つまり、事前登録する台数の制限によってコンテンツの不正利用の規模を限定する以外に、KCの上限によってRA−Sinkの利用可能な数を制限して不正利用の規模をさらに限定することが可能である。また、RAレジストリーへの登録台数の制限の他に、KCの上限を設けることによって、RA−Sourceへ登録できるRA−Sinkの台数を、コンテンツを利用できるRA−Sinkの台数に比べて大きく設定することができ、その結果、新たなRA−Sinkを登録する際に古い登録内容を消去する手間を省くことができる。
リモート・アクセス用の交換鍵の供給数KCは、RA−SourceがRA−Sinkに渡した交換鍵のうち、有効なものの数である。したがって、どのRA−Sinkにも交換鍵を渡していない初期状態ではKCはゼロであり、渡した交換鍵をRA−Sourceが破棄したときはその分を減らすことができる。
ここで、KCの上限が2以上の場合、リモート・アクセス用の交換鍵の運用方法には、RA−Sink毎に1つずつ鍵を用意する方法と、RA−Sinkによらず1つの鍵を使う方法がある。前者の場合は1つの交換鍵を破棄するとKCを1つ減らすことになり、後者の場合は交換鍵を破棄するとKCをゼロにリセットすることになる。
リモート・アクセス用の交換鍵の(RA_Kx)の破棄については、DTCP−IPと同様に連続不使用期間が所定の期間を超える前に破棄するというルールで運用することが考えられる。また、RA−Sinkがリモート・アクセスの終了時に当該交換鍵の破棄を求めるコマンド(RA_FINISH)を交換鍵のID(RA_Kx_label)とともに送るという運用形態も考えられる。この破棄要求コマンドRA_FINISHは、図9中の「RA−AKE_INIT」、「RA_EXCHANGE_KEY」とともに、DTCP−IPのAKE control commandに、リモート・アクセス用のコマンドとして追加するものとする。
図10には、RA−SourceがRA−Sinkの登録確認及びリモート・アクセス用の交換鍵の供給数確認を行なうための「RA−Sink ID confirmation」処理の手順をフローチャートの形式で示している。
RA−Sourceは、まず、当該処理ルーチンを開始する以前の処理(Challenge−Response portion of AKE、Protected RTT Protocol)を異常終了(abort)したか否かをチェックする(ステップS11)。
ここで、以前の処理を異常終了していた場合には(ステップS11のNo)、RA−Sourceは、要求元のRA−Sinkに対し、RA−AKE手続きを中断して(ステップS20)、本処理ルーチンを終了する。
また、以前の処理を正常に終了していた場合には(ステップS11のYes)、RA−Sourceは、RESPONSE2を受信したか否かをチェックする(ステップS12)。そして、RESPONSE2を受信したときには(ステップS12のYes)、RA−Sourceは、要求元のRA−SinkのIDをIDuとする(ステップS13)。また、RESPONSE2を受信していないときには(ステップS12のNo)、RA−Sourceは、要求元のRA−SinkのDevice IDをIDとする(ステップS14)。
次いで、RA−Sourceは、要求元のRA−SinkのIDを記憶部14内のRAレジストリーに既に登録済みか否かをチェックする(ステップS15)。
ここで、要求元のRA−SinkのIDをRAレジストリーに登録してあることを確認できないときには(ステップS15のNo)、RA−Sourceは、要求元のRA−Sinkに対し、RA−AKE手続きを中断して(ステップS20)、本処理ルーチンを終了する。
他方、要求元のRA−SinkのIDをRAレジストリーに登録済みであることを確認できたときには(ステップS15のYes)、RA−Sourceは、続いて、リモート・アクセス用の交換鍵の供給数KCが上限値未満であるかどうかをチェックする(ステップS16)。
そして、リモート・アクセス用の交換鍵の供給数KCが上限値未満であることを確認できたときには(ステップS16のYes)、RA−Sourceは、KCを1だけインクリメントして(ステップS17)、確認処理に「成功」した旨の結果コードを、リモート・アクセス用の交換鍵(RA_Kx)とそのID(RA_Kx_label)とともに、要求元のRA−Sinkに通知して(ステップS19)、本処理ルーチンを終了する。
また、鍵の供給数KCが上限値に到達しているときには(ステップS16のNo)、RA−Sourceは、「busy」である旨の結果コードを要求元のRA−Sinkに通知して(ステップS18)、本処理ルーチンを終了する。
RA−SourceとRA−Sinkの間でリモート・アクセス用の交換鍵が共有されると、リモート・アクセスによるコンテンツ伝送が可能な状態となる。図19には、RA−SinkがRA−Sourceに対してコンテンツを要求する際の動作シーケンスを示している。但し、同図では、RA−SinkからRA−Sourceに対してHTTPプロトコルに従ってコンテンツが要求され、ダウンロード形式でコンテンツが伝送されるものとする。
RA−Sinkは、図9に示したRA−AKE手続きによってリモート・アクセス用の交換鍵(RA_Kx)とそのID(RA_Kx_label)を取得した後、HTTP GETメソッドを用いたHTTPリクエスト(HTTP GET request)により、RA−Sourceにコンテンツ・データをリクエストする。このリクエストの際には、コンテンツのURLとともに、リモート・アクセス出力用の交換鍵のID(RA_Kx_label)を送る。ここで、RA−SinkからRA−Sourceに交換鍵のID(RA_Kx_label)を送るためのヘッダーフィールドを定義する。
RA−Sourceは、コンテンツ・データのリクエストを受けると、要求されたコンテンツがリモート・アクセス出力数をチェックするための「コンテンツのリモート・アクセス(RA)出力管理1」の処理を実行する。そして、リクエストで指定されたURLのコンテンツがリモート・アクセス出力可能であることが確認できたなら、RA−Sourceは、交換鍵IDで指定されたリモート・アクセス用の交換鍵を用いて暗号鍵を算出し、この暗号鍵を用いて暗号化したコンテンツをHTTPレスポンス(HTTP GET response)として返送する。
図20には、RA−Sourceが実施する、コンテンツのリモート・アクセス(RA)出力管理1の処理手順をフローチャートの形式で示している。
まず、RA−Sourceは、HTTPリクエストに含まれる交換鍵IDで示される交換鍵がDTCP−IP用か否かをチェックする(ステップS51)。
ここで、HTTPリクエストに含まれる交換鍵IDで示される交換鍵がDTCP−IP用でない場合には(ステップS51のNo)、RA−Sourceは、続いて、当該交換鍵がリモート・アクセス用か否かをチェックする(ステップS52)。
当該交換鍵がリモート・アクセス用である場合には(ステップS52のYes)、RA−Sourceは、HTTPリクエストに含まれるURLで指定されたコンテンツがリモート・アクセス可能か否かをチェックする(ステップS53)。コンテンツがリモート・アクセス可能か否かは、例えば、RA−flagを用いて管理することができる(後述)。
そして、HTTPリクエストに含まれる交換鍵IDで示される交換鍵がDTCP−IP用である場合(ステップS51のYes)、又は、HTTPリクエストで指定されたコンテンツがリモート・アクセス可能であることが分かった場合には(ステップS53のYes)、RA−Sourceは、RA−SinkからのHTTPリクエスト(HTTP GET request)への応答をOKとして(ステップS54)、本処理ルーチンを終了する。
他方、HTTPリクエストに含まれる交換鍵IDで示される交換鍵がリモート・アクセス用でない場合(ステップS52のNo)、又は、HTTPリクエストで指定されたコンテンツがリモート・アクセス不能の場合には(ステップS53のNo)、RA−Sourceは、RA−SinkからのHTTPリクエスト(HTTP GET request)への応答をエラーとして(ステップS55)、本処理ルーチンを終了する。
ここまでの説明では、通信システムが一対のRA−SourceとRA−Sinkだけで構成されることを想定していた。しかしながら、RA−SourceやRA−Sinkは、それぞれさらに別の機器とデイジーチェーン形式で接続され、コンテンツを伝送する可能性がある。著作権保護されたコンテンツの伝送範囲は、本来、家庭内に留めるべきであり、コンテンツの受信と再送信が何段にもわたり繰り返し行なわれることは好ましくない。このため、コンテンツの受信と再送信を技術的に阻止することが必要である。本実施形態では、登録時におけるRTT及びTTLの制限と、鍵の供給数制限をより厳密なものにするために、さらに幾つかのルールを設けている。
図11に示すシステム構成例では、RA−Source#0と接続するRA−Sink#1が、さらにRA−Source#1としての機能も備え、別の機器RA−Sink#2と接続している。このような場合、RA−Sink#1としてリモート・アクセスして受信したコンテンツを、RA−Source#1としてRA−Sink#2に再度リモート・アクセス出力することを禁止することによって、コンテンツ提供元であるRA−Source#0の管理が及ばない所でリモート・アクセスされるのを防止するように運用する。
また、図12に示すシステム構成例では、RA−Sink#1が、リモート・アクセスによりRA−Source#0に接続するとともに、Source#1としての機能も備えDTCP−IPにより別の機器Sink#2に接続され、さらに、Sink#2がRA−Source#2としての機能も備えて別の機器RA−Sink#3と接続している。RA−Sink#1は、リモート・アクセスにより受信したコンテンツを、DTCP−IPを通じて別の機器Sink#2にローカル伝送することができる。DTCP−IPによるローカル伝送は、著作権保護の仕組みに則ったものであり、問題はない。また、Sink#2が受信したコンテンツを、RA−Source#2としてRA−Sink#3に再度リモート・アクセス出力することを禁止することによって、コンテンツ提供元であるRA−Source#0の管理が及ばない所でリモート・アクセスされるのを防止するように運用する。
図11、図12を参照しながら説明したシステム運用は、要するに、機器はリモート・アクセス又はDTCP−IPでのローカル伝送によって受信したコンテンツのリモート・アクセス出力を禁止して、コンテンツ提供元の意図しないリモート・アクセスを防止することである。このような運用を実現する1つの方法として、コンテンツのリモート・アクセス出力並びにローカル伝送時に以下の(1)、(2)の規定を設けることが挙げられる。
(1)RA−Sourceは、コンテンツが「リモート・アクセス出力可能」という情報を伴わない限り、リモート・アクセス出力を行なわないようする。
(2)RA−Source、Sourceは、リモート・アクセス又はDTCP−IPによるローカル伝送時に、リモート・アクセス出力の可否を表す情報を送らない。
図13に示すシステム構成例では、Source#0とDTCP−IPにより接続するSink#1が、さらにRA−Source#1としての機能も備え、別の機器RA−Sink#2と接続している。Source#0は、DTCP−IPを通じてのみ、Sink#1にコンテンツをローカル伝送することができる。DTCP−IPによるローカル伝送は、著作権保護の仕組みに則ったものであり、問題はない。ここで、上記(1)、(2)の制限規定が課されると、Sink#1は、受信したコンテンツをRA−Source#1としてRA−Sink#3に再度リモート・アクセス出力することができなくなる。
このケースでは、コンテンツ提供元の管理が及ばない所でのリモート・アクセス出力を防止することができるが、「リモート・アクセス出力可能」の情報を伴ったコンテンツであっても、一度もリモート・アクセス出力されないことになる。これに対し、本発明者らは、RA−Source#1が、Sink#1としてDTCP−IPを通じてローカル伝送によりSource#0から受信したコンテンツを、Source#0に代わってさらに別の機器RA−Sink#2にリモート・アクセス出力する(すなわち、リモート・アクセス出力を代行する)という運用は禁止する必要はない、と思料する。リモート・アクセス出力を代行するという運用は、DEP−RA−AKEを行なって、Source#0が鍵をSink#1とだけ共有し、Sink#1がその鍵を使ってコンテンツを暗号化伝送し、RA−Source1からリモート・アクセス出力することで実現できる。
図14には、DEP−RA−AKEを行なってSource#0が鍵をSink#1とだけ共有する際の認証シーケンス例を示している。
この認証シーケンスは、Sink#1がSource#0に対して鍵供給要求コマンド「DEP_RA_INIT」を送信することによって開始する。AKE手続きのチャレンジ・レスポンス部分(Challenge−Response portion of AKE)では、まず、Sink#1から、Rx乱数とRx証明書を含んだRxチャレンジが送信される。これに対しSource#0からは、Tx乱数及びTx証明書を含んだTxチャレンジが返信される。以降、Source#0から、Rx乱数、Txメッセージ、Tx署名を含んだRxレスポンスが送信されるとともに、Sink#1からはTx乱数、Rxメッセージ、Rx署名を含んだTxレスポンスが送信される。なお、「DEP_RA_AKE」を送信する代わりに、Rxチャレンジとして送信する情報の中に、「DEP_RA_AKE」の送信に相当する情報、例えば「DEP_RA_AKE_flag」を含める方法も考えられる。
各チャレンジ・コマンドには、機器固有の識別情報であるDevice IDが含まれている。但し、同チャレンジ・レスポンス部分の中では、SinkからSourceへのレスポンスとして「RESPONSE2」が送られることがあるが、その場合は、機器固有の識別情報として、Device IDではなく、RESPONSE2に含まれるIDuを使うことになる(同上)。
AKE手続きはDTCP−IPを通じて実施されることから、TTLの制限が課される。また、また、RTT保護プロトコル(Protected RTT Protocol)がさらに続く。リモート・アクセス出力代行の手続きDEP−RA−AKEは、ローカル環境内だけで行なわれるべきであり、現行のDTCP−IPにおけるRTT−AKEと同様に、RTT及びTTLが課される。
そして、上記の認証手順に成功すると、Source#0は、「DEP_RA−Sink Confirmation」処理を実行する。この処理では、Source#0は、鍵をSink#1とだけ共有するとともに、他の機器とこのDEP−RA−AKEは実施できないようにする。そして、Source#0は、鍵をSink#1とだけ共有できることを確認できた場合に、リモート・アクセス出力代行用の交換鍵(D−RA_Kx)とそのID(D−RA_Kx_label)と結果コードを、コマンド「DEP−RA_EXCHANGE_KEY」でSink#1に渡す。
Source#0は、その後はAKEによって共有した鍵を破棄するまで、他の機器とこのDEP−RA−AKEは実施できないようにする。また、Sink#1側では、当該処理手順を通じて共有できたリモート・アクセス出力代行用の交換鍵を使って、「リモート・アクセス出力可能」の情報を伴ったままコンテンツを暗号化伝送する。そして、Sink#1は、RA−Source#1として、RA−Sink#2へ当該コンテンツをリモート・アクセス出力することができる。
図15には、SourceがSinkにコンテンツのリモート・アクセス出力の代行を認証する「DEP_RA−Sink Confirmation」処理の手順をフローチャートの形式で示している。
Sourceは、まず、当該処理ルーチンを開始する以前の処理(Challenge−Response portion of AKE、Protected RTT Protocol)を異常終了(abort)したか否かをチェックする(ステップS21)。
ここで、以前の処理を異常終了していた場合には(ステップS21のNo)、Sourceは、要求元のSinkに対し、DEP_RA−Sink手続きを中断して(ステップS30)、本処理ルーチンを終了する。
また、以前の処理を正常に終了していた場合には(ステップS21のYes)、Sourceは、RESPONSE2を受信したか否かをチェックする(ステップS22)。そして、RESPONSE2を受信したときには(ステップS22のYes)、Sourceは、要求元のSinkのIDをIDuとする(ステップS23)。また、RESPONSE2を受信していないときには(ステップS22のNo)、Sourceは、要求元のSinkのDevice IDをIDとする(ステップS24)。
次いで、Sourceは、自分のDEP_RAレジストリーが空か否かをチェックする(ステップS25)。DEP_RAレジストリーは、コンテンツのリモート・アクセス出力を許可する唯一の機器のIDを保持するために記憶部14内に用意されたレジストリーである。
ここで、DEP_RAレジストリーが空であることを確認できたときには(ステップS25のYes)、Sourceは、DEP_RAレジストリーに要求元のSinkのIDを代入する(ステップS26)。そして、Sourceは、リモート・アクセス出力代行用の交換鍵(D−RA_Kx)とそのID(D−RA_Kx_label)と結果コードを、コマンド「DEP−RA_EXCHANGE_KEY」でSink#1に渡して(ステップS29)、本処理ルーチンを終了する。
また、DEP_RAレジストリーが空でないときには(ステップS25のNo)、Sourceは、DEP_RAレジストリーに保持されているIDが要求元のSinkのIDと一致するかどうかをさらにチェックする(ステップS27)。
DEP_RAレジストリーに保持されているIDが要求元のSinkのIDと一致する場合、すなわち、要求元のSinkをコンテンツのリモート・アクセス出力を代行する機器として既に登録しているときには(ステップS27のYes)、Sourceは、リモート・アクセス出力代行用の交換鍵(D−RA_Kx)とそのID(D−RA_Kx_label)と結果コードを、コマンド「DEP−RA_EXCHANGE_KEY」でSink#1に渡して(ステップS29)、本処理ルーチンを終了する。
他方、DEP_RAレジストリーに保持されているIDが要求元のSinkのIDと一致しないときには(ステップS27のNo)、Sourceは、「busy」である旨の結果コードを要求元のSinkに通知して(ステップS28)、本処理ルーチンを終了する。
Sourceは、図15に示した処理手順を実行した後は、他の機器とこのDEP−RA−AKEを重複して実施することができない。また、Sourceは、DEP−RA−AKEで共有したリモート・アクセス代行用の交換鍵(D−RA_Kx)を破棄したときに、DEP_RAレジストリーを空にすることで、他の機器とこのDEP−RA−AKEを実施できるようになる。
リモート・アクセス代行用の交換鍵の(D_RA_Kx)の破棄については、例えば、Sinkがリモート・アクセス代行を終了する時に、当該交換鍵の破棄を求めるコマンド(DEP_RA_FINISH)を交換鍵のID(D_RA_Kx_label)とともに送るという運用形態が考えられる。この破棄要求コマンドDEP_RA_FINISHは、図14中の「DEP_RA_INIT」、「DEP_RA_EXCHANGE_KEY」とともに、DTCP−IPのAKE control commandに、リモート・アクセス用のコマンドとして追加するものとする。
図21には、(RA−Sourceの機能を備えた)SinkがSourceに対してリモート・アクセスを代行するコンテンツを要求する際の動作シーケンスを示している。但し、同図では、SinkからSourceに対してHTTPプロトコルに従ってコンテンツが要求され、ダウンロード形式でコンテンツが伝送されるものとする。
Sinkは、図14に示したDEP_RA−AKE手続きによってリモート・アクセス用の交換鍵(D_RA_Kx)とそのID(D_RA_Kx_label)を取得した後、HTTP GETメソッドを用いたHTTPリクエスト(HTTP GET request)により、Sourceに対してコンテンツ・データをリクエストする。このリクエストの際には、コンテンツのURLとともに、リモート・アクセス代行用の交換鍵のID(D_RA_Kx_label)を送る。ここで、SinkからSourceに交換鍵のID(D_RA_Kx_label)を送るためのヘッダーフィールドを定義する。
Sourceは、コンテンツのリモート・アクセス出力代行のリクエストを受けると、要求されたコンテンツがリモート・アクセス出力代行可能か否かをチェックするための「コンテンツのリモート・アクセス代行(DEP−RA)出力管理1」の処理を実行する。そして、リクエストで指定されたURLのコンテンツがリモート・アクセス出力代行可能であることが確認できたなら、Sourceは、交換鍵IDで指定されたリモート・アクセス代行用の交換鍵を用いて暗号鍵を算出し、この暗号鍵を用いて暗号化したコンテンツを、「リモート・アクセス出力可能」の情報を伴ったまま、HTTPレスポンス(HTTP GET response)として返送する。
図22には、リモート・アクセス出力代行を要求されたSourceが実施する、コンテンツのリモート・アクセス出力代行管理の処理手順をフローチャートの形式で示している。
まず、Sourceは、HTTPリクエストに含まれる交換鍵IDで示される交換鍵がDTCP−IP用か否かをチェックする(ステップS61)。
ここで、HTTPリクエストに含まれる交換鍵IDで示される交換鍵がDTCP−IP用でない場合には(ステップS61のNo)、RA−Sourceは、続いて、当該交換鍵がリモート・アクセス代行用か否かをチェックする(ステップS62)。
当該交換鍵がリモート・アクセス代行用である場合には(ステップS62のYes)、Sourceは、HTTPリクエストに含まれるURLで指定されたコンテンツがリモート・アクセス可能か否かをチェックする(ステップS63)。コンテンツがリモート・アクセス可能か否かは、例えば、RA−flagを用いて管理することができる(後述)。
そして、HTTPリクエストに含まれる交換鍵IDで示される交換鍵がDTCP−IP用である場合(ステップS61のYes)、又は、HTTPリクエストで指定されたコンテンツがリモート・アクセス可能であることが分かった場合には(ステップS63のYes)、Sourceは、SinkからのHTTPリクエスト(HTTP GET request)への応答をOKとする(ステップS64)。
他方、HTTPリクエストに含まれる交換鍵IDで示される交換鍵がリモート・アクセス代行用でない場合(ステップS62のNo)、又は、HTTPリクエストで指定されたコンテンツがリモート・アクセス不能の場合には(ステップS63のNo)、Sourceは、SinkからのHTTPリクエスト(HTTP GET request)への応答をエラーとする(ステップS55)。
なお、図13に示したシステム構成において、リモート・アクセス不可のコンテンツをSource#0からSink#1に伝送したい場合には、現行のDTCP−IPに従って行なうことが考えられるが、以下のようにすることで、リモート・アクセス代行用の交換鍵(D_RA_Kx)を用いた伝送でリモート・アクセス可能及び不可の双方のコンテンツを扱えるようにすることもできる。
Source#0は、DEP−RA−AKEで共有した交換鍵を使うコンテンツ伝送の際には、リモート・アクセスの可否情報(RA−flag)を伴うことで、RA−Source#1は、受信したコンテンツをリモート・アクセス出力できるかどうかを判別できるようにする。
なお、RA−flagは、コンテンツ・データとともに暗号化したり、RA−flagの値を暗号鍵の計算をする関数に入力にして、暗号鍵Kcの値に反映させたりする方法や(図23を参照のこと)、RA−flagを含む、平文で伝送する情報を、その情報と暗号鍵をハッシュ関数で処理して求めた署名データ(signature)とともに送ることで(図24を参照のこと)、改竄を防ぐことができる。
また、RA−flagをコンテンツ・データとともに暗号化する場合、その格納先としては、DTCP−IPで運用されているDTCP_descriptorやPCP−URのreservedとなっているビットや(図25、図26を参照のこと)、あるいは新たなコンテンツ関連情報のコンテナを設けてそこに配置することなどが考えられる。
なお、上記の説明では、図13に示したシステム構成において、Sink#1は、Source#0からのコンテンツを記録せずに、RA−Source#1経由でリモート・アクセス出力することを想定している。変形例として、コンテンツをSource#0からSink#1にMOVEする場合も、DP−RA−AKEで共有した鍵を使ったコンテンツの伝送時にリモート・アクセスの可否情報(RA−flag)を伴うことで、RA−Source#1は、受信したコンテンツをリモート・アクセス出力できるかどうかを判別することができる。ここで、DTCP−IPで言うMOVE機能は、Sinkは受信したコンテンツをNoMore Copiesとして符号化して記録すること、及び、Source側では伝送した後のコンテンツを消去又は利用不能にするという条件の下で、暗号化コンテンツをSourceからSinkへ伝送することを意味する。
ここまでは、RA−Sourceを利用できるRA−Sinkの台数を制限する方法について説明してきた。これに対し、コンテンツ・オーナーの中には、自分が提供するコンテンツを同時にリモート・アクセスを利用できる数を制限することで不正の脅威を小さくしたいと要望することも考えられる。例えば、記録禁止の有料番組を受信機が直ちにリモート・アクセス出力する場合などである。
コンテンツのリモート・アクセス利用数を制限する方法として、RA−AKEで共有する鍵をRA−Sink毎に変えるとともに、各RA−Sinkにどのコンテンツをリモート・アクセスしているかを管理する方法が挙げられる。そして、RA−Sourceは、所定の数以上のRA−Sinkに同じコンテンツを同時に伝送しないようにすればよい。
RA−Sourceは、コンテンツを同時にリモート・アクセスを利用できる数を制限するために、例えば以下に示すような管理テーブルを用いる。
上記の管理テーブルでは、RA−Sinkに伝送中のコンテンツのURLとRA−Sinkと1対1に対応する交換鍵ID(RA_Kx_label)の組み合わせが各エントリーで管理されている。この管理テーブル中で、URLのみが一致し、交換鍵IDが相違するエントリーは、1つのコンテンツを異なるRA−Sinkが利用していることを表す。
RA−Sourceは、新たにコンテンツ伝送を開始する前に、この管理テーブルを参照して、同じコンテンツが所定の数を超えるRA−Sinkに送られないように制御する。コンテンツの伝送開始が許容されるときには、RA−Sourceは、URLと交換鍵IDの組み合わせからなるエントリーを管理テーブルに追加する。
図16には、同じコンテンツを同時に伝送するRA−Sinkの台数が制限される場合の、RA−SinkがRA−Sourceにコンテンツを要求する際の動作シーケンスを示している。
RA−Sinkは、図9に示したRA−AKE手続きによってリモート・アクセス用の交換鍵(RA_Kx)とそのID(RA_Kx_label)を取得した後、HTTP GETメソッドを用いたHTTPリクエスト(HTTP GET request)により、RA−Sourceにコンテンツ・データをリクエストする。このリクエストの際には、コンテンツのURLとともに、リモート・アクセス出力用の交換鍵のID(RA_Kx_label)を送る。ここで、RA−SinkからRA−Sourceに交換鍵のID(RA_Kx_label)を送るためのヘッダーフィールドを定義する。
RA−Sourceは、コンテンツ・データのリクエストを受けると、要求されたコンテンツを同時にリモート・アクセス出力するRA−Sinkの台数をチェックするための「同一コンテンツのリモート・アクセス(RA)出力管理2」の処理を実行する。そして、指定されたURLのコンテンツを同時に伝送するRA−Sinkの台数がまだ制限数に達していない場合は、RA−Sourceは、交換鍵IDで指定されたリモート・アクセス用の交換鍵を用いて暗号鍵を算出し、この暗号鍵を用いて暗号化したコンテンツをHTTPレスポンス(HTTP GET response)として返送する。また、RA−Sourceは、上記の管理テーブルにエントリーを追加する。
なお、RA−Sourceがリモート・アクセス用の鍵を破棄したときに、破棄した鍵に対応するエントリーを上記のテーブルから消去する。なお、RA−Sinkがリモート・アクセスを終了した時で、上記の管理テーブルからエントリーの削除を求めるコマンド(RA_FINISH)を、リモート・アクセス用の交換鍵のID(RA_Kx_label)とともに送るようにしてもよい(同上)。
図17には、図16に示した動作シーケンスにおいて、RA−Sourceがコンテンツ・データのリクエストに応じて実行する、同一コンテンツの出力数を管理するための処理手順をフローチャートの形式で示している。
まず、RA−Sourceは、HTTPリクエストに含まれる交換鍵IDで示される交換鍵がDTCP−IP用か否かをチェックする(ステップS31)。
ここで、HTTPリクエストに含まれる交換鍵IDで示される交換鍵がDTCP−IP用である場合には(ステップS31のYes)、RA−Sourceは、RA−SinkからのHTTPリクエスト(HTTP GET request)への応答をOKとして(ステップS38)、本処理ルーチンを終了する。
また、HTTPリクエストに含まれる交換鍵IDで示される交換鍵がDTCP−IP用でない場合には(ステップS31のNo)、RA−Sourceは、続いて、当該交換鍵がリモート・アクセス用か否かをチェックする(ステップS32)。
当該交換鍵がリモート・アクセス用である場合には(ステップS32のYes)、RA−Sourceは、HTTPリクエストに含まれるURLで指定されたコンテンツがリモート・アクセス可能か否かをチェックする(ステップS33)。コンテンツがリモート・アクセス可能か否かは、例えば、RA−flagを用いて管理することができる(後述)。
HTTPリクエストに含まれる交換鍵IDで示される交換鍵がリモート・アクセス用でない場合(ステップS32のNo)、又は、HTTPリクエストで指定されたコンテンツがリモート・アクセス不能の場合には(ステップS33のNo)、RA−Sourceは、RA−SinkからのHTTPリクエスト(HTTP GET request)への応答をエラーとして(ステップS39)、本処理ルーチンを終了する。
また、HTTPリクエストで指定されたコンテンツがリモート・アクセス可能であることが分かった場合には(ステップS33のYes)、RA−Sourceは、コンテンツ・データのリクエスト中に含まれるURLと交換鍵ID(RA_Kx_label)の組み合わせと同じエントリーが管理テーブル中にあるかどうかをチェックする(ステップS34)。
ここで、コンテンツ・データのリクエスト中に含まれるURLと交換鍵ID(RA_Kx_label)の組み合わせと同じエントリーが管理テーブル中にあるときには(ステップS34のYes)、当該コンテンツが要求元のRA−Sinkに利用されても利用数の制限を超えることはない。そこで、RA−Sourceは、要求元のRA−SinkからのGET requestに対する応答を「OK」として(ステップS38)、本処理ルーチンを終了する。
他方、コンテンツ・データのリクエスト中に含まれるURLと交換鍵ID(RA_Kx_label)の組み合わせと同じエントリーが管理テーブル中にないときには、RA−Sourceは、続いて、URLが同じエントリーが管理テーブル中にあるかどうかをチェックする(ステップS35)。
コンテンツ・データのリクエスト中に含まれるURLが同じであるエントリーが管理テーブル中にないときには(ステップS35のNo)、当該コンテンツが要求元のRA−Sinkに利用されても利用数の制限を超えることはない。そこで、RA−Sourceは、コンテンツ・データのリクエストで指定されたURLと交換鍵ID(RA_Kx_label)の組み合わせからなるエントリーを管理テーブルに追加する(ステップS37)。そして、RA−Sourceは、要求元のRA−SinkからのGET requestに対する応答を「OK」として(ステップS38)、本処理ルーチンを終了する。
また、コンテンツ・データのリクエスト中に含まれるURLと同じであるエントリーが管理テーブル中にあるときには(ステップS35のYes)、リクエストに応答して要求元のRA−Sinkにコンテンツを提供すると、利用数の制限を超えるおそれがある。そこで、RA−Sourceは、管理テーブル中で、コンテンツ・データのリクエスト中に含まれるURLと同じであるエントリーの数が上限値未満か否かをさらにチェックする(ステップS36)。
管理テーブル中で、コンテンツ・データのリクエスト中に含まれるURLと同じであるエントリーの数が上限値未満であれば(ステップS36のYes)、当該コンテンツが要求元のRA−Sinkに利用されても利用数の制限を超えることはない。そこで、RA−Sourceは、コンテンツ・データのリクエストで指定されたURLと交換鍵ID(RA_Kx_label)の組み合わせからなるエントリーを管理テーブルに追加し(ステップS37)、要求元のRA−SinkからのGET requestに対する応答を「OK」として(ステップS38)、本処理ルーチンを終了する。
管理テーブル中で、コンテンツ・データのリクエスト中に含まれるURLと同じであるエントリーの数が上限値に達していると(ステップS36のNo)、当該コンテンツが要求元のRA−Sinkに利用されても利用数の制限を超えてしまう。このため、RA−Sourceは、要求元のRA−SinkからのGET requestに対する応答を「ERROR」として(ステップS39)、本処理ルーチンを終了する。
ここまでの説明では、「リモート・アクセス出力可能」という情報を伴わないコンテンツはリモート・アクセスできないことが前提であった。しかしながら、現実には、記録可能なコンテンツであれば、DVDやメモリカードなどの可搬型の記録媒体(removable media)に書き込むことで、コンテンツを家庭の外に持ち出して、別の機器で利用することができる。よって、記録可能なコンテンツについては、「リモート・アクセス出力可能」という情報を伴わなくても、記録した後はリモート・アクセス可能とする運用も考えられる。
但し、RA−Sinkで受信したコンテンツの書き込み先が可搬型記録媒体の場合は、コンテンツを最後まで書き込んだ後に持ち出せるということで、リモート・アクセスについてもコンテンツの記録中や、記録開始時点から所定の時間が経過するまでリモート・アクセスの抑制が求められるかもしれない。
図18には、RA−Sourceとして動作する機器がコンテンツを記録又はMOVE機能で取り込むための処理手順をフローチャートの形式で示している。
RA−Sourceは、まず、取り込んだコンテンツが「リモート・アクセス出力可否」に関する情報を伴っているかどうかをチェックする(ステップS41)。
ここで、取り込むコンテンツが取り込んだコンテンツが「リモート・アクセス出力可否」に関する情報を伴っているときには(ステップS41のYes)、さらに、当該情報の指定内容が「リモート・アクセス出力可」となっているか否かをチェックする(ステップS42)。
ここで、「リモート・アクセス出力可否」に関する情報の指定内容が「リモート・アクセス出力可」となっていないときには(ステップS42のNo)、RA−Sourceは、その情報に従って、リモート・アクセス不可期限を「無限」に設定する(ステップS43)。
次いで、RA−Sourceは、取り込んだコンテンツのリモート・アクセス出力の可否を示すRA−flagを設定して(ステップS44)、本処理ルーチンを終了する。
一方、コンテンツが「リモート・アクセス出力可能」という情報を伴っていないときには(ステップS45のNo)、RA−Sourceは、基準となる時点の時刻に所定の期間を加えた結果の値Tを求め(ステップS46)、Tをそのコンテンツのリモート・アクセス不可期限とするとともに(ステップS47)、その期限まで当該コンテンツのリモート・アクセス出力を禁止する設定でRA−flagを「不可」に初期化して(ステップS48)、本処理ルーチンを終了する。
ここで、基準点時刻とは、例えば放送コンテンツであれば番組の先頭が放送されたタイミングの時刻で、それに加える所定の時間としては、番組情報としてコンテンツとともに送られる番組の時間長などが考えられる。記録メディア中のコンテンツなど、いつ記録されたものか不明なものについては、コンテンツをMOVE機能により取り込もうとした時点の時刻にコンテンツの再生長を加えた値をTとすることが考えられる。
なお、図18では省略しているが、コンテンツが「リモート・アクセス出力不可」という情報を伴うときには(ステップS42で分かったときには)、RA−Sourceは、RA−flagを不可とするとともに、Tを「無限」に設定する。
図18に示した処理手順を経て、RA−flagが「不可」と設定されたコンテンツで、Tが「無限」に設定でないものは、指定されたタイミング以降は、リモート・アクセス可能なものとして扱うことができる。
図27には、RA−Sourceが、コンテンツに設定されたRA−flag及びTを更新するための処理手順をフローチャートの形式で示している。
RA−Sourceは、まず、コンテンツのRA−flagが「可」に設定されているか否かをチェックする(ステップS71)。ここで、コンテンツのRA−flagが既に「可」に設定されているときには(ステップS71のYes)、後続の処理をすべてスキップして、本処理ルーチンを終了する。
コンテンツのRA−flagが「可」に設定されていないときには(ステップS71のNo)、RA−Sourceは、次いで、コンテンツのリモート・アクセス不可期限が「無限」に設定されているか否かをチェックする(ステップS72)。ここで、コンテンツのリモート・アクセス不可期限が「無限」に設定されているときには(ステップS72のYes)、後続の処理をすべてスキップして、本処理ルーチンを終了する。
コンテンツのリモート・アクセス不可期限が「無限」に設定されていないときには(ステップS72のNo)、RA−Sourceは、次いで、コンテンツのリモート・アクセス不可期限が現時点より未来か否かをチェックする(ステップS73)。
コンテンツのリモート・アクセス不可期限が現時点より未来であれば(ステップS73のYes)、そのまま本処理ルーチンを終了する。また、コンテンツのリモート・アクセス不可期限が現時点より未来でない、すなわちリモート・アクセス不可期限に既に到達しているときには(ステップS73のNo)、RA−Sourceは、コンテンツのRA−flagを「可」に更新して(ステップS74)、本処理ルーチンを終了する。
RA−Sourceが図27に示した処理手順を定期的に実行することで、コンテンツのRA−flagを「可」に更新することができる。当該処理手順の具体的な実施タイミングとして、例えばコンテンツ・リスト(図示しない)を外部に提示するときなどが挙げられる。
DTCP−IPではコンテンツは家庭内ネットワークでの利用だけが可能であった。これに対し、本実施形態に係る通信システムでは、不正利用の可能性を絞り込むことで、家庭の外から、すなわちリモート・アクセスによるコンテンツの利用が可能となる。
また、本実施形態に係る通信システムでは、RTT、TTL、コンテンツを利用するRA−Sinkの台数、交換鍵の供給数など、リモート・アクセスを制限する複数の制限値を調整することで、システムを柔軟に構築することができる。
また、本実施形態に係る通信システムによれば、DTCP−IPの通信プロトコルをベースにして構築しつつ、RTTやTTLの制限を外して、リモート・アクセスによるコンテンツの利用を実現することができる。
本発明に係る通信システムに置いて、RA−Sourceに相当するコンテンツ提供装置の機能的構成については、図3を参照しながら既に説明した。例えば、パーソナル・コンピューターや、レコーダー、その他のさまざまな情報機器がコンテンツ提供装置として機能することができる。
図29には、コンテンツ提供装置に適用されるパーソナル・コンピューター80の構成例を示している。図示のパーソナル・コンピューター80は、CPU81、RAM(Random Access Memory)82、EEPROM(Electrically Erasable and Programmable ROM)83、ディスプレイ84、スピーカー85、例えばHDD(Hard Disc Drive)やSDD(Super Density Disc)などの大容量情報記憶装置86、I/Oインターフェース87などの回路コンポーネントを備え、これらの回路コンポーネントがバス88を介して相互接続されている。
CPU81は、メインメモリーとしてのRAM82にロードされたプログラムを読み出して実行する。
RAM82には、コンテンツの暗号及び復号に関する機能がロードされる。例えば、DTCP−IP機能を実行するためのプログラム、及び、RA−AKE処理を実行するためのプログラムがRAM82にロードされる。また、RA−SourceにRA−Sinkを登録する際の認証シーケンス(図7を参照のこと)を実行するためのプログラムは、RA−AKE処理を実行するためのプログラムの一部として、このRAM82にロードされ、CPU81が実行する。
EEPROM83は、書き換えが可能な不揮発性記憶装置であり、設定情報などが記憶される。パーソナル・コンピューター80がRA−Sourceすなわちコンテンツ提供装置として動作する場合、RA−sinkとなる端末IDがEEPROM83に記憶される。
パーソナル・コンピューター80上では、RA−sink(例えば、モバイル端末)から、このRA−sinkをRA−AKE手続きが可能な端末として登録するよう要求を受けると、CPU81が、RAM82からDTCP−IPのAKE処理が記述されたプログラムを読み出し、RA−sinkとの間でAKE手続きを実行する。
この手続きに成功すると、CPU81は、RAM82に記憶されたプログラムに従って、RA−sinkの端末IDを、EEPROM83に記憶する。
その後、パーソナル・コンピューター80上では、CPU81が、RA−AKE処理の要求を受けた場合に、この要求を行なっている端末のIDと、EEPROM83に記憶されたRA−sinkの端末IDとを比較し、RA−AKE処理を完了させるか否かを決定する処理を実行する。
そして、RA−AKE処理が完了すると、パーソナル・コンピューター80と、RA−AKE処理の要求を行なった端末との間で共通するコンテンツ鍵が生成される。パーソナル・コンピューター80側では、生成されたコンテンツ鍵を一時的に記憶し、大容量情報記憶装置86からコンテンツを読み出したときに、このコンテンツを一時的に記憶されたコンテンツ鍵で暗号化する。暗号化されたコンテンツは、I/Oインターフェース88を経て、外部に出力される。I/Oインターフェース88が無線LAN機能を有している場合、無線LANを介して、RA−AKE処理の要求を行なった端末に対し、暗号化コンテンツが送信される。
また、図30には、コンテンツ提供装置に適用されるレコーダー90の構成例を示している。図示のレコーダー90は、システム・チップ91、大容量記憶装置92、RAM93、EEPROM94、無線LANチップ95を備えている。
システム・チップ91は、CPU91a、コプロセッサー91b、インターフェース機能部91cなどの回路モジュールを備え、これらの回路モジュールは、当該チップ内のバス91dで相互接続されている。
CPU91aは、インターフェース機能部91cを介して接続された記憶装置に記憶されたプログラムを実行することが可能である。
コプロセッサー91bは、補助演算装置であり、主に動画像の圧縮又は復号処理を実行する。例えば、H264、VC1、MPEG2、JPEGなどのアルゴリズムを実行する。
大容量記憶装置92は、例えばHDDやSDDなどであるが、コンテンツ利用装置に提供するコンテンツを記憶する。
メインメモリーとしてのRAM93には、CPU91aで実行されるプログラムがロードされる。RAM93にロードされる主なプログラムは、コンテンツの暗号及び復号に関する機能を実現するプログラムであり、例えば、DTCP−IP機能を実行するためのプログラム、及び、RA−AKE処理を実行するためのプログラムがRAM82にロードされる。
EEPROM94は、書き換えが可能な不揮発性記憶装置であり、設定情報などが記憶される。レコーダー90がRA−Sourceすなわちコンテンツ提供装置として動作する場合、RA−sinkとなる端末IDがEEPROM94に記憶される。
レコーダー90上では、RA−sink(例えば、モバイル端末)から、このRA−sinkをRA−AKE手続きが可能な端末として登録するよう要求を受けると、CPU91aが、RAM93からDTCP−IPのAKE処理が記述されたプログラムを読み出し、RA−sinkとの間でAKE手続きを実行する。
この手続きに成功すると、CPU91aは、RAM93に記憶されたプログラムに従って、RA−sinkの端末IDを、EEPROM94に記憶する。
その後、レコーダー90上では、CPU91aが、RA−AKE処理の要求を受けた場合に、この要求を行なっている端末のIDと、EEPROM94に記憶されたRA−sinkの端末IDとを比較し、RA−AKE処理を完了させるか否かを決定する処理を実行する。
そして、RA−AKE処理が完了すると、レコーダー90と、RA−AKE処理の要求を行なった端末との間で共通するコンテンツ鍵が生成される。レコーダー90側では、生成されたコンテンツ鍵を一時的に記憶し、大容量情報記憶装置92からコンテンツを読み出したときに、このコンテンツを一時的に記憶されたコンテンツ鍵で暗号化する。暗号化されたコンテンツは、インターフェース機能部91c及び無線LANチップ95を経て、RA−AKE処理の要求を行なった端末に対し、暗号化コンテンツが送信される。