JP2010021888A - 通信装置、鍵サーバ及び管理サーバ - Google Patents

通信装置、鍵サーバ及び管理サーバ Download PDF

Info

Publication number
JP2010021888A
JP2010021888A JP2008181885A JP2008181885A JP2010021888A JP 2010021888 A JP2010021888 A JP 2010021888A JP 2008181885 A JP2008181885 A JP 2008181885A JP 2008181885 A JP2008181885 A JP 2008181885A JP 2010021888 A JP2010021888 A JP 2010021888A
Authority
JP
Japan
Prior art keywords
information
piece
encrypted
key
encrypted piece
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2008181885A
Other languages
English (en)
Inventor
Tatsuyuki Matsushita
達之 松下
Ryuichi Koike
竜一 小池
Hideki Matsumoto
英樹 松本
Kentaro Umezawa
健太郎 梅澤
Hiroshi Kato
拓 加藤
Haruhiko Toyama
春彦 外山
Hideaki Sato
英昭 佐藤
Tatsu Kamibayashi
達 上林
Satoshi Ito
聡 伊藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2008181885A priority Critical patent/JP2010021888A/ja
Priority to US12/368,674 priority patent/US20100008509A1/en
Publication of JP2010021888A publication Critical patent/JP2010021888A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60Digital content management, e.g. content distribution
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/062Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying encryption of the keys

Abstract

【課題】コンテンツ配信システムにおいて配信される暗号化されたコンテンツが不正に復号されることをより効果的に抑制可能な配信技術を提供する。
【解決手段】リーチャ50Aは、バージョン情報を含むTorrent Fileを販売サーバ54から受信し、当該Torrent Fileに基づいて、トラッカ51にアクセスしてノード情報を取得し、ノード情報に基づいて、シーダ52A〜52Cやリーチャ50Bの少なくとも1つにアクセスして各暗号化ピースを受信して、各ピースに各々対応する全ての暗号化ピースを取得する。そして、リーチャ50Aは、各暗号化ピースを各々復号するための各復号鍵を含む鍵束を要求すると共に、各暗号化ピースの取得に用いたTorrent Fileのバージョン情報を含む要求メッセージを鍵サーバ53に送信し、鍵サーバ53の判断結果に応じて当該鍵束を受信する。
【選択図】 図1

Description

本発明は、暗号鍵を用いて暗号化された暗号化コンテンツを、他の通信装置から受信する通信装置、暗号化コンテンツを復号するための復号鍵を送信する鍵サーバ、通信装置が他の通信装置へアクセスするための情報を記憶する通信装置、鍵サーバ及び管理サーバに関する。
一般に、コンテンツを配信するシステムには、「単一サーバ型」と「分散サーバ型」とがある。単一サーバ型のシステムでは、例えば、1つのコンテンツサーバと、ライセンスサーバと、クライアントとがネットワークを介して接続され、コンテンツサーバからコンテンツが各クライアントに配信される。配信されるコンテンツは暗号化されており、この暗号化に係る鍵情報をライセンスサーバが有している。コンテンツサーバでは、コンテンツはE( KT )[ C ]として保持される。ただし、KTはタイトル鍵と呼ばれる鍵であり、Cは平文のコンテンツである。E( KT )[ C ]はCがKTで暗号化されていることを示す。鍵情報にはKTが含まれている。クライアントBは、鍵情報をライセンスサーバから取得し、当該鍵情報を、当該クライアント(クライアントBとする)固有の鍵KBを用いて暗号化し、これをコンテンツサーバから受信したコンテンツE( KT )[ C ]と関連づけて保持する。そして、クライアントBは、鍵KBを用いて鍵情報を復号して、タイトル鍵KTを取り出し、当該タイトル鍵KTを用いてE( KT )[ C ]を復号することにより、コンテンツを利用することができる。
このような構成において、クライアントBは、コンテンツサーバからコンテンツE( KT )[ C ]をダウンロードする際、認証及び鍵交換を互いに行う。この結果、クライアントBは、一時鍵KtmpBを共有する。コンテンツサーバは、一時鍵KtmpBを用いてコンテンツE( KT )[ C ]を暗号化し、コンテンツE( KtmpB )[ E( KT )[ C ] ]をクライアントBに送信する。クライアントBは、上述の認証及び鍵交換によってコンテンツサーバと共有している一時鍵KtmpBを用いてコンテンツE( KtmpB )[ E( KT )[ C ]]を復号して、E( KT )[ C ]を取り出す。このような構成においては、ネットワークの経路上で、暗号化されたコンテンツE( KtmpB )[ E( KT )[ C ] ]が不正に読み取られたとしても、不正に読み取られたものは一時鍵KtmpBがなければ復号することができない。即ち、クライアント毎に異なる一時鍵を用いてコンテンツを暗号化することにより、同一のコンテンツをクライアント毎に個別化し、これにより、コンテンツの不正使用を抑制することができる。例えば、クライアントAに対する一時鍵KtmpAとクライアントBに対する一時鍵KtmpBとを異ならせることにより、クライアントAに配信されるコンテンツE( KtmpA )[ E( KT )[ C ] ]と、クライアントBに配信されるコンテンツE( KtmpB )[ E( KT )[ C ] ]とは異なる個別のデータとなる。このように同一のコンテンツを暗号鍵の相違により個別化することにより、コンテンツの不正使用を抑制することができる。
しかし、単一サーバ型のシステムでは、クライアントとコンテンツサーバとの1対1での通信となるため、多くのクライアントがコンテンツサーバからコンテンツの配信を受けようとすると、配信効率が悪くなるという問題がある。
一方、分散サーバ型のシステムには、例えば、P2PによるBitTorrentというコンテンツ配信システムがある(例えば、非特許文献1参照)。このようなシステムにおいては、コンテンツ毎に異なるトラッカと、シーダと、リーチャとがP2Pで各々接続される。また、配信されるコンテンツは、複数のピースに分割されている。シーダは、コンテンツの配信(アップロード)を目的として、コンテンツを構成するピースを配信するノードである。リーチャは、コンテンツの受信(ダウンロード)を目的として、コンテンツを構成する各ピースの受信とコンテンツを構成するピースの配信とを行うノードである。即ち、リーチャはコンテンツを構成するピースをある程度取得するとシーダになる場合がある。このように、シーダには、コンテンツを構成する全部のピース又は一部のピースを受信したリーチャがシーダへ変化したものと、システム側で(予め又は配信の途中に)用意される(最初からシーダである)ものとがある。後者を初期シーダと呼ぶ。初期シーダは、あるひとつのコンテンツを構成し得る全てのピース又は一部のピースを保持している。以降、特に断りのない限り、シーダとはシーダ又は初期シーダを意味するものとし、ノードとはリーチャ、シーダ、又は初期シーダを意味するものとする。トラッカは、各ノードに関するノード情報を保持しており、リーチャからアクセスがあった場合、ノード情報をリーチャに提供する。
このような構成において、あるリーチャがコンテンツの配信を受ける場合、まず、Torrent Fileと呼ばれる情報を取得する。Torrent Fileは、例えば、コンテンツプロバイダ又はユーザにコンテンツを販売するサービスを運用するサーバ(販売サーバと呼ぶ)から、他ノード又は販売サーバへ与えられ、さらに他ノード又は販売サーバからリーチャへ与えられる。この他に、例えばCD−ROMなどの記録媒体に記録されたTorrent Fileをオフラインでリーチャへ配布される場合もある。Torrent Fileには、コンテンツに関するトラッカ情報と、当該コンテンツのファイル情報とが格納されている。トラッカ情報はトラッカの接続先を含んでいる。ファイル情報は、例えば、コンテンツを構成する各ピースのハッシュ情報を含んでいる。ハッシュ情報は、ピースの完全性を確認するために用いられる。即ち、ハッシュ情報は、リーチャがダウンロードしたピースのハッシュを計算し、当該ピースのハッシュ値と照合して、受信したピースが改竄されていないことを確認するのに用いられる。
リーチャは、このようなTorrent Fileを取得すると、トラッカ情報に基づいてトラッカに接続する。トラッカは、リーチャに上述のノード情報を送信する。ノード情報は単数または複数のノードの接続先のリストを含んでいる。リーチャはノード情報に基づいて、複数のノードに接続する。各ノードが配信するピースは、ノード毎に異なっている場合が多い。リーチャは、複数のノードから異なるピースを受信することができるので、コンテンツの高速な受信が可能である。
このように、P2Pによるコンテンツ配信システムでは、コンテンツは複数のノードに分散して保持されている。従って、このようなシステムにおいては、コンテンツの配信を受けるノードが多くても、P2Pにより複数の他のノードからコンテンツの配信を受けることができるため、単一サーバ型のシステムに比べて配信効率が良い。
尚、このように、複数のノードからコンテンツを配信し得るコンテンツ配信システムにおいても、コンテンツの不正使用を抑制するためには、配信するコンテンツを暗号化によって保護することが望ましい。しかし、このようなコンテンツ配信システムでは、単一サーバ型のシステムとは異なり、各リーチャがシーダから受信する同一のコンテンツは、暗号化された状態であっても同一でなければならず、リーチャ毎に個別に暗号化したコンテンツを配信することは難しかった。このため、暗号化されたコンテンツを復号するための鍵が1つ曝露されてしまうと、ネットワーク上に多数存在するコンテンツが全て復号可能になってしまうという恐れがあった。
ところで、特許文献1には、コンテンツを複数のピースに分割し、それら複数のピースをそれぞれ1つの平文として、複数の暗号鍵を用いて各々暗号化して暗号文(暗号化ピースという)を生成するコンテンツ配信方法が開示されている。
Bittorrent Protocol Specification v1.0 特許第3917395号公報
しかし、特許文献1に記載のコンテンツ配信方法では、コンテンツの配信を受ける各ユーザが全ての暗号化ピースを取得する必要がある。このため、このコンテンツ配信方法をP2Pによるコンテンツ配信システムへそのまま応用した場合、配信効率が悪くなる恐れがある。更に、暗号化されたコンテンツを復号するための鍵が複数であっても、それらが曝露されてしまった場合、復号鍵を正規に取得することなしにコンテンツが復号可能になってしまうという恐れがある。即ち、料金を支払わずにコンテンツを不正使用することが可能になってしまう恐れがある。コンテンツの不正使用に関して、以下の2つの不正行為が考えられる。1つは、他のユーザが暴露した複数の復号鍵を用いて、コンテンツをユーザ自身が不正使用するという行為である。即ち、ユーザは、コンテンツを構成する全ての暗号化ピースをダウンロードしておき、コンテンツの復号が可能となる複数の復号鍵が漏洩したときこれを取得して、ダウンロードした各暗号化ピースを復号することによりコンテンツを復号するのである。もう1つは、他のユーザに不正使用させるという行為である。即ち、ユーザは、コンテンツを構成する全ての暗号化ピースを復号するための復号鍵の全て又は大部分を購入し、それらの復号鍵の全てを何らかの方法で暴露し、他のユーザがコンテンツを復号可能な状態にするのである。従って、コンテンツ配信システムにおいては、これらの不正行為によって復号鍵が暴露された場合の被害を抑える対策を講じる必要がある。
本発明は、上記に鑑みてなされたものであって、コンテンツ配信システムにおいて配信される暗号化されたコンテンツが不正に復号されることをより効果的に抑制可能な通信装置、鍵サーバ、管理サーバ、コンテンツ配信システム、通信方法及びプログラムを提供することを目的とする。
上述した課題を解決し、目的を達成するために、本発明は、コンテンツの一部である複数のピースを受信する通信装置であって、複数の第1暗号化ピースは、前記複数のピースを第1暗号鍵で暗号化することによって生成されるものであって、第2暗号化ピースは、前記複数のピースのうち1つ以上のピースを第2暗号鍵で暗号化することによって生成されるものであって、同一のピースを暗号化するための前記第1暗号鍵と前記第2暗号鍵とは異なっていて、前記第1暗号化ピース及び前記第2暗号化ピースの全部又は一部を示すファイル情報と、当該ファイル情報の有効性の有無を判断可能な版管理情報とを取得する情報取得手段と、他の通信装置から、前記ファイル情報を用いて、前記第1暗号化ピース又は前記第2暗号化ピースをピース毎に受信するコンテンツ受信手段と、前記コンテンツ受信手段がピース毎に受信した前記第1暗号化ピース又は前記第2暗号化ピースを復号するための各復号鍵を要求する要求メッセージと当該各対応暗号化ピースの取得に用いた前記ファイル情報の前記版管理情報とを鍵サーバへ送信する送信手段と、前記要求メッセージに従った前記鍵サーバから前記各復号鍵を受信する鍵受信手段とを備えることを特徴とする。
また、本発明は、コンテンツの一部である複数のピースを受信する通信装置であって、
複数の第1暗号化ピースは、前記複数のピースを第1暗号鍵で暗号化することによって生成されるものであって、第2暗号化ピースは、前記複数のピースのうち1つ以上のピースを第2暗号鍵で暗号化することによって生成されるものであって、同一のピースを暗号化するための前記第1暗号鍵と前記第2暗号鍵とは異なっていて、他の通信装置から、前記第1暗号化ピース又は前記第2暗号化ピースをピース毎に受信するコンテンツ受信手段と、前記コンテンツ受信手段がピース毎に受信した前記第1暗号化ピース又は前記第2暗号化ピースを復号するための各復号鍵を要求する要求メッセージを、当該各復号鍵を記憶する鍵サーバに送信する鍵要求送信手段と、前記要求メッセージによって要求された各復号鍵によって復号されるピース毎の前記第1暗号化ピース又は前記第2暗号化ピースを保持していることを証明するための保持証明情報を要求する情報要求メッセージを前記鍵サーバから受信する要求受信手段と、前記情報要求メッセージに従って前記保持証明情報を前記鍵サーバに送信する情報送信手段と、前記保持証明情報及び前記情報要求メッセージに基づいて前記鍵サーバから前記各復号鍵のうち全部又は一部を受信する鍵受信手段とを備えることを特徴とする。
また、本発明は、コンテンツの一部である複数のピースを受信する通信装置と通信する鍵サーバであって、複数の第1暗号化ピースは、前記複数のピースを第1暗号鍵で暗号化することによって生成されるものであって、第2暗号化ピースは、前記複数のピースのうち1つ以上のピースを第2暗号鍵で暗号化することによって生成されるものであって、同一のピースを暗号化するための前記第1暗号鍵と前記第2暗号鍵とは異なっていて、前記通信装置は、他の通信装置から、前記第1暗号化ピース又は前記第2暗号化ピースをピース毎に受信するものであって、前記通信装置から、ピース毎の前記第1暗号化ピース又は前記第2暗号化ピースを復号するための各復号鍵を要求する要求メッセージと前記第1暗号化ピース又は前記第2暗号化ピースの取得に用いられた前記ファイル情報の有効性の有無を判断可能な版管理情報とを受信する要求受信手段と、前記各復号鍵を記憶する第1記憶手段と、有効性を有する前記ファイル情報の前記版管理情報を特定するための有効性情報を記憶する第2記憶手段と、受信された前記版管理情報と、前記有効性情報とを用いて、前記要求メッセージによって要求された前記各復号鍵が有効であるか否かを判断する判断手段と、前記判断手段の判断結果が肯定的である場合、前記要求メッセージによって要求された前記各復号鍵の組み合わせに基づいて、当該各復号鍵を送信するか否かを決定する決定手段と、前記決定手段の決定結果が肯定的である場合、前記要求メッセージによって要求された前記組み合わせにおける前記各復号鍵を前記第1記憶手段から各々読み出してこれらを前記通信装置に送信する鍵送信手段とを備えることを特徴とする。
また、本発明は、コンテンツの一部である複数のピースを受信する通信装置と通信する鍵サーバであって、複数の第1暗号化ピースは、前記複数のピースを第1暗号鍵で暗号化することによって生成されるものであって、第2暗号化ピースは、前記複数のピースのうち1つ以上のピースを第2暗号鍵で暗号化することによって生成されるものであって、同一のピースを暗号化するための前記第1暗号鍵と前記第2暗号鍵とは異なっていて、前記通信装置は、他の通信装置から、前記第1暗号化ピース又は前記第2暗号化ピースをピース毎に受信するものであって、前記通信装置から、ピース毎の前記第1暗号化ピース又は前記第2暗号化ピースを復号するための各復号鍵を要求する要求メッセージを受信する要求受信手段と、前記各復号鍵を記憶する第1記憶手段と、前記要求メッセージによって要求された前記各復号鍵によって復号されるピース毎の前記第1暗号化ピース又は前記第2暗号化ピースを前記通信装置が保持しているか否かを判断するための保持判断情報を記憶する第2記憶手段と、前記要求メッセージによって要求された各復号鍵によって復号されるピース毎の前記第1暗号化ピース又は前記第2暗号化ピースを保持していることを証明するための保持証明情報を要求する情報要求メッセージを前記通信装置に送信する要求送信手段と、前記保持証明情報を前記通信装置から受信する情報受信手段と、受信された前記保持証明情報と、記憶された前記保持判断情報とを用いて、前記要求メッセージによって要求された前記各復号鍵によって復号されるピース毎の前記第1暗号化ピース又は前記第2暗号化ピースを前記通信装置が保持しているか否かを判断する保持証明判断手段と、前記判断手段の判断結果が肯定的である場合、前記要求メッセージによって要求された前記各復号鍵の組み合わせに基づいて、当該各復号鍵を送信するか否かを決定する決定手段と、前記決定手段の決定結果が肯定的である場合、前記要求メッセージによって要求された前記組み合わせにおける前記各復号鍵を前記第1記憶手段から各々読み出してこれらを前記通信装置に送信する鍵送信手段とを備えることを特徴とする。
また、本発明は、コンテンツの一部である複数のピースを受信する通信装置と通信する管理サーバであって、複数の第1暗号化ピースは、前記複数のピースを第1暗号鍵で暗号化することによって生成されるものであって、第2暗号化ピースは、前記複数のピースのうち1つ以上のピースを第2暗号鍵で暗号化することによって生成されるものであって、同一のピースを暗号化するための前記第1暗号鍵と前記第2暗号鍵とは異なっていて、ファイル情報は、前記第1暗号化ピース及び前記第2暗号化ピースの全部又は一部を示し且つ当該ファイル情報の有効性の有無を判断可能な版管理情報が対応付けられるものであり、前記通信装置は、他の通信装置から、前記ファイル情報を用いて、前記第1暗号化ピース又は前記第2暗号化ピースをピース毎に受信するものであって、前記他の通信装置にアクセスするための接続先情報を記憶する第1記憶手段と、前記通信装置が、前記ファイル情報と対応付けられ且つ当該管理サーバへアクセスするための第1アクセス情報を用いて当該管理サーバにアクセスした場合、前記他の通信装置にアクセスするための前記接続先情報を送信する情報送信手段とを備えることを特徴とする。
本発明によれば、コンテンツ配信システムにおいて配信される暗号化されたコンテンツが不正に復号されることをより効果的に抑制可能になる。
以下に添付図面を参照して、この発明にかかる通信装置、鍵サーバ及び管理サーバの最良な実施の形態を詳細に説明する。
[第1の実施の形態]
(1)構成
<コンテンツ配信システムの基本構成>
まず、本実施の形態にかかるコンテンツ配信システムの基本的な構成について説明する。図1は、本実施の形態にかかるコンテンツ配信システムの構成を示す図である。本実施の形態にかかるコンテンツ配信システムにおいては、リーチャ50A〜50Bと、トラッカ51と、シーダ52A〜52Cと、販売サーバ54とが各々P2PネットワークNTを介して接続されている。リーチャ50A〜50Bと、鍵サーバ53とは各々、図示しないインターネットなどのネットワークを介して接続される。ここでノードとは、リーチャ50A〜50Bと、シーダ52A〜52Cとである。シーダ52A〜52Cは、複数のピースに分割されたコンテンツについて、各ピースが各々異なる暗号鍵で暗号化された各暗号化ピースを保持している。尚、以降、このような暗号化ピースから構成されるコンテンツを暗号化コンテンツという。このような暗号化コンテンツの詳細については後述する。シーダ52A〜52Cのうち、シーダ52Aは、上述した初期シーダとして機能する。シーダ52Aは、一つのコンテンツを構成する各ピースについて、同一のピースに対して複数の暗号鍵を用いて各々暗号化されて生成された暗号化ピースの全てとTorrent Fileとを保持している。トラッカ51は、各ノードにアクセスするためのノード情報を保持している。尚、各ノードには各々、ノード識別情報が付与されているものとする。ノード識別情報とは、各ノードを一意に識別可能な識別情報であり、例えば、各ノードのIPアドレスである。鍵サーバ53は、各暗号化ピースを復号するための復号鍵を保持している。販売サーバ54は、Torrent Fileを保持している。
リーチャ50Aは、販売サーバ54からTorrent Fileを受信し、当該Torrent Fileに基づいて、トラッカ51にアクセスしてノード情報を取得し、ノード情報に基づいて、シーダ52A〜52Cやリーチャ50Bの少なくとも1つにアクセスして各暗号化ピースを受信して、各ピースに各々対応する全ての暗号化ピースを取得し、各暗号化ピースを各々復号するための各復号鍵を含む鍵束を鍵サーバ53から受信する。リーチャ50Bについても同様である。尚、以降、リーチャ50A〜50Bを各々区別する必要がない場合、単にリーチャ50と記載する。シーダ52A〜52Cを各々区別する必要がない場合も、単にシーダ52と記載する。
ここで、コンテンツの構成について説明する。コンテンツとは、種々のデジタルデータ、例えばMPEG2やMPEG4等の動画データや音声データの他、テキストデータや静止画データ等を指し、また、これらのデジタルデータが暗号化されているものもコンテンツと呼ぶ。例えば、HD DVD Prepared Video ContentをAACS(Advanced Access Content System)仕様に従って暗号化したものもコンテンツである。ここでは、コンテンツ全体をCと表すものとする。Cは平文であっても暗号化されていても構わない。図2は、コンテンツが複数のピースに分割された状態を模式的に示す図である。例えば、コンテンツCは、ある1つのコンテンツをN(N>1)個のピースC1〜CNに分割される。各ピースC1,C2,・・・CNのデータ長は全て同一であっても良いし、そうでなくても良い。これらのN個の各ピースC1〜CNについては、各々異なる暗号鍵で暗号化される。このとき、N個のうちa個のピースについては、同一のピースに対して、各々異なるm個の暗号鍵(第1暗号鍵及び第2暗号鍵)で暗号化される。残りの(N-a)個のピースについては、同一のピースに対して1つの暗号鍵(第1暗号鍵)で暗号化される。即ち、a個の各ピースについては、同一のピースがm個の異なる暗号鍵で各々暗号化されてm個の異なるピース(暗号化ピース)が生成される。(N-a)個の各ピースについては、各々1つの暗号鍵で暗号化して、1つのピースに対して1つの暗号化ピースが生成される。図3は、各暗号化ピースを模式的に示す図である。このa個の各ピースに各々対応して、m個の暗号化ピースの中から各々1つ選択される暗号化ピースの組み合わせを異ならせることにより、N個の暗号化ピースから構成される暗号化コンテンツ全体を個別化することができる。
尚、コンテンツの各ピースへの分割や、各ピースの暗号化は、トラッカ51や、鍵サーバ53や、コンテンツ製作者が用意したサーバのいずれが行っても良い。尚、以降、これらのうち少なくとも1つを行う装置をピース処理装置という。また、各暗号化ピースは、例えば、トラッカ51、鍵サーバ53又は信頼できる第三者(例えば、コンテンツ製作者が用意したサーバ)からシーダ52A(初期シーダ)へ与えられるものとする。
次に、リーチャ50と、トラッカ51と、シーダ52と、鍵サーバ53との各装置のハードウェア構成について説明する。各装置は各々、装置全体を制御するCPU(Central Processing Unit)等の制御装置と、各種データや各種プログラムを記憶するROM(Read Only Memory)やRAM(Random Access Memory)等の記憶装置と、各種データや各種プログラムを記憶するHDD(Hard Disk Drive)やCD(Compact Disk)ドライブ装置等の外部記憶装置と、これらを接続するバスとを備えており、通常のコンピュータを利用したハードウェア構成となっている。また、各装置には各々、情報を表示する表示装置と、ユーザの指示入力を受け付けるキーボードやマウス等の入力装置と、外部装置の通信を制御する通信I/F(interface)とが有線又は無線により接続される。
<シーダ52の構成>
次に、上述したハードウェア構成において、シーダ52のCPUが記憶装置や外部記憶装置に記憶された各種プログラムを実行することにより実現される各種機能について説明する。シーダ52は、コンテンツCを構成する複数のピースC1〜CNが各々暗号化された各暗号化ピースを、各ピースC1〜CNを各々復号するための各復号鍵のインデックス(添え字)と対応付けて記憶している。尚、各復号鍵は、各暗号鍵と同一であっても良いし、各暗号鍵と異なるものであっても良い。いずれにしろ、各ピースC1〜CNは各々暗号鍵で暗号化されているため、これらの各暗号化ピースを復号するための復号鍵のそれぞれについて、各復号鍵のインデックスを用いて、各暗号化ピースを特定することができる。このような各暗号化ピースは例えば外部記憶装置に記憶される。
以下簡単のため、暗号鍵と復号鍵が同一の場合で説明する。復号鍵のインデックスを、( i, j )で表し、復号鍵を、K ( i, j )で表すとすると、各暗号化ピースは、例えば、以下のように表される。
E( K( i, j) )[ Cj ]
(ただし、i, jは整数、1≦i≦m、1≦j≦N(m>1)、相異なるインデックス( i, j)、( i’, j’) (( i, j)≠( i’, j’))についてK( i, j)= K( i’, j’)であってもよい。)
このような各暗号化ピースから構成される暗号化コンテンツは、例えば、以下のように表される。
{ E( K( i1, 1 ) )[ C1 ], E( K( i2, 2 ) )[ C2 ], …, E( K( iN, N ))[ CN ]}
(ただし、1≦i1, …, iN≦m)
このような暗号化コンテンツにおける各暗号化ピースのシーケンスは、各暗号化ピースのインデックスの組み合わせにより表され、例えば以下のように表される。ここでは、各ピースC1〜CNに各々対応するインデックスが左から順に配列されて表されている。
{ ( i1, 1 ), ( i2, 2 ), …, ( iN, N) }
(ただし、1≦i1, …, iN≦m)
従って、シーダ52が各暗号化ピースとインデックスとを対応付けて記憶するものは、例えば、以下のように表される。
{ ( E( K( i1, 1) )[ C1 ], ( i1, 1 ) ), ( E( K( i2, 2) )[ C2 ], ( i2, 2 ) ), …,( E( K( iN, N) )[ CN ], ( iN, N ) ) }
(ただし、1≦i1, …, iN≦m)
更に、初期シーダであるシーダ52Aは、コンテンツを構成する各ピースに各々対応する各暗号化ピースについて、同一のピースに対して複数の暗号鍵により各々暗号化されて生成された暗号化ピースの全てを記憶している。図4は、シーダ52Aが記憶している各暗号化ピースを例示する図である。同図においては、N個のうちa個(1<a<N)のピースについて、同一のピースに対して複数の異なる暗号鍵で各々暗号化されていることが示されている。同図においては、同一のピースの暗号化に用いられる暗号鍵の個数は、ピース毎に異なっている。ピースC1に対する暗号鍵の個数はm個であり、ピースC3に対する暗号鍵の個数は2個である。但し、本実施の形態においては、同一のピースの暗号化に用いられる暗号鍵の個数はピース毎に同じであっても良い。ピース処理装置では、このように、N個のうちa個(1<a<N)のピースについて、同一のピースに対して複数の異なる暗号鍵で各々暗号化することにより、例えば、重要度の高いほど暗号鍵の数を増やすようにすることができる。
尚、本実施の形態においては、これに限らず、例えば、図5に示されるように、「a=N」の場合、即ち、N個全てのピースについて、同一のピースに対してm個の異なる暗号鍵で各々暗号化されていても良い。このような構成によれば、暗号化ピースのシーケンスのバリエーションを多くすることができる。また、図6に示されるように、「a=1」の場合、即ち、N個のうち1個のピースのみ、m個の異なる暗号鍵で暗号化されていても良い。このような構成によれば、配信効率を向上させることができる。
このような構成において、シーダ52は、リーチャ50からのアクセスにより、当該シーダ52が記憶している暗号化ピースのシーケンスを示すピース情報をリーチャ50に送信する。図7は、ピース情報のデータ構成を例示する図である。同図においては、ピースC1に対応する暗号化ピースについては、復号鍵K(1, 1 )により復号されることが示され、ピースC2に対応する暗号化ピースについては、復号鍵K(3, 2 ) により復号されることが示されている。即ち、ピース情報によって、各暗号化ピースと各暗号化ピースの復号化のための復号鍵の対応関係とが示される。シーダ52は、当該ピース情報に基づいて暗号化ピースを要求するピース要求をリーチャ50から受信すると、要求された暗号化ピースを保持しているか否かを判断し、当該判断結果が肯定的である場合に、当該暗号化ピースをリーチャ50に送信する。
<リーチャ50の構成>
次に、上述したハードウェア構成において、リーチャ50のCPUが記憶装置や外部記憶装置に記憶された各種プログラムを実行することにより実現される各種機能について説明する。図8は、リーチャ50の機能的構成を例示する図である。リーチャ50は、コンテンツ取得部500と、鍵束要求部501と、鍵束取得部502と、コンテンツ復号部503とを有する。これら各部の実体は、CPUのプログラム実行時にRAMなどの記憶装置上に生成されるものである。
コンテンツ取得部500は、P2PネットワークNTを介して、暗号化コンテンツを構成する各暗号化ピースをシーダ52の少なくとも1つから受信する。具体的には、コンテンツ取得部500は、まず、販売サーバ54からTorrent Fileを受信する。Torrent Fileは、トラッカ51に接続するためのトラッカ接続先情報を含むトラッカ情報と、暗号化コンテンツを構成する各暗号化ピースとしてどのようなものがあるかを示すファイル情報とを含んでいる。図9は、Torrent Fileを例示する図である。同図においては、ファイル情報として、各暗号化ピースを特定するための情報として、各暗号化ピースに対応するインデックスが各々示されている。トラッカ接続先情報は、例えば、トラッカ51のIPアドレスや、URLなどである。
コンテンツ取得部500は、Torrent Fileに基づいて、P2PネットワークNTを介してトラッカ51にアクセスして、P2PネットワークNTに接続されているノード(シーダ52、他のリーチャ50)にアクセスするためのノード情報を当該トラッカ51から受信する。ノード情報の詳細については後述する。そして、コンテンツ取得部500は、ノード情報に基づいて、ノードの少なくとも1つにアクセスして、当該ノードが記憶している自身の保持する暗号化ピースのシーケンスを示すピース情報を取得する。そして、コンテンツ取得部500は、ピース情報に基づいて、暗号化コンテンツを構成する各暗号化ピースを要求するピース要求をノードの少なくとも1つに送信し、当該ピース要求に応じて送信される暗号化ピースを受信することにより、暗号化コンテンツを構成する全ての暗号化ピース(ピースシーケンス)を取得する。例えば、図3に示した各暗号化ピースのうち、網掛けされた全ての暗号化ピースをピースシーケンスとしてコンテンツ取得部500は取得する。取得した暗号化ピースをコンテンツ取得部500は例えば外部記憶装置に記憶する。
鍵束要求部501は、ピースシーケンスを復号するための鍵束を要求する要求メッセージを鍵サーバ53へ送信する。鍵束とは、ピースシーケンスの各暗号化ピースを各々復号するための各復号鍵を、各暗号化ピースのシーケンスに合わせて含むものである。尚、鍵束及び復号鍵の詳細については後述する。要求メッセージは、この鍵束に含ませる各復号鍵のシーケンスを指定する情報として、ピースシーケンスにおける各暗号化ピースのインデックスの組み合わせ(シーケンス)を示すインデックス情報を含む。このようなシーケンスは、例えば、以下のように表される。
{ ( i1, 1 ), ( i2, 2 ), …, ( iN, N) }
(ただし、1≦i1, …, iN≦m)
鍵束取得部502は、要求メッセージに従って鍵サーバ53から送信された鍵束を受信する。コンテンツ復号部503は、コンテンツ取得部500が取得した各暗号化ピースを、鍵束取得部502が取得した鍵束に含まれ且つ各暗号化ピースに各々対応する復号鍵を用いて各々復号して、復号した各ピースから構成されるコンテンツを取得する。
尚、リーチャ50は、上述したように、シーダとして機能する場合もあるが、その機能的構成については、シーダ52の構成において説明したため、ここでは、その説明を省略する。
<鍵サーバ53の構成>
次に、鍵サーバ53のCPUが記憶装置や外部記憶装置に記憶された各種プログラムを実行することにより実現される各種機能について説明する。図10は、鍵サーバ53の機能的構成を例示する図である。鍵サーバ53は、制御部530と、パケット処理部531と、ネットワークインターフェース部532と、認証・鍵交換処理部533と、鍵記憶部534と、シーケンス情報記憶部536と、シーケンス情報照合部535と、鍵供給部537とを有する。制御部530と、シーケンス情報照合部535と、ネットワークインターフェース部532と、パケット処理部531と、認証・鍵交換処理部533と、鍵供給部537との実体は、CPUのプログラム実行時にRAMなどの記憶装置上に生成されるものである。鍵記憶部534は、例えば、外部記憶装置に記憶されるものである。
制御部530は、鍵サーバ53全体を制御し、シーケンス情報照合部535から鍵供給部537への指示を仲介したりする。パケット処理部531は、リーチャ50などの外部装置に送信する各種データをパケット化してネットワークインターフェース部532に受け渡したり、ネットワークインターフェース部532から受け渡されたパケットを基にデータを取得したりする。ネットワークインターフェース部532は、外部装置との通信を制御し、パケット処理部531から受け渡されたパケット化されたデータを送信したり、外部装置から受信したパケットをパケット処理部531に受け渡したりする。
認証・鍵交換処理部533は、ネットワークインターフェース部532を介して、リーチャ50から要求メッセージを受信し、当該リーチャ50と相互認証を行い、認証後、要求を受理する旨の受理メッセージをリーチャ50に送信する。
鍵記憶部534は、例えば、HDDなどの外部記憶装置において構成され、各暗号化ピースを各々復号するための各復号鍵を各々記憶する。各復号鍵は、上述したように、例えばK ( i, j )として表される。
シーケンス情報記憶部536は、例えばHDDなどの外部記憶装置において構成され、リーチャ50に過去に送信した全ての鍵束に各々対応するシーケンスを示すシーケンス情報を記憶する。鍵束に各々対応するシーケンスは、上述したインデックス情報に示されるシーケンスと同様に、例えば以下のように表される。
{ ( i1, 1 ), ( i2, 2 ), …, ( iN, N) }
(ただし、1≦i1, …, iN≦m)
シーケンス情報照合部535は、シーケンス情報記憶部536に記憶されたシーケンス情報と、リーチャ50から受信したインデックス情報とを照合することにより、インデックス情報によって示されるシーケンスに対応する鍵束を送信するか否かを決定する。具体的には、シーケンス情報照合部535は、インデックス情報に示されるシーケンスと同一のシーケンスを示すシーケンス情報がシーケンス情報記憶部536に記憶されていない場合、インデックス情報によって示されるシーケンスに対応する鍵束を送信することを決定する。鍵束は、例えば、以下のように表される。ここでは、各ピースC1〜CNに各々対応する復号鍵が左から順に配列されて表されている。
{K( i1, 1 ), K( i2, 2 ), …, K( iN, N )}
(ただし、1≦i1, …, iN≦m)
そして、シーケンス情報照合部535は、鍵束を送信することを決定した場合、制御部530を介して、当該鍵束を当該リーチャ50へ送信するよう鍵供給部537に指示する。また、シーケンス情報照合部535は、鍵束を送信しないことを決定した場合、制御部530を介して、当該鍵束の当該リーチャ50への送信禁止を鍵供給部537に指示する。
鍵供給部537は、制御部530を介してシーケンス情報照合部535から鍵束の送信を指示されると、当該鍵束のシーケンスに応じた復号鍵を鍵記憶部534から各々読み出し、読み出した各復号鍵を含む鍵束を、ネットワークインターフェース部532を介してリーチャ50に送信する。
<トラッカ51の構成>
次に、トラッカ51の構成について説明する。トラッカ51は、リーチャ50からアクセスされると、P2PネットワークNTに接続されているノードにアクセスするための接続先情報としてノード情報を当該リーチャ50に対して送信する。ノード情報は、IPアドレスとポート番号との組を含んでいる。図11は、ノード情報のデータ構成を例示する図である。同図においては、ノードA〜Bは各々、リーチャ50A〜50B、シーダ52A〜52Cのいずれかであり、当該各ノードのIPアドレスとポート番号との組が示されている。
ここで、トラッカ51がノード情報をどのように生成するかについて説明する。例えば、複数のトラッカ51が存在しえる場合、そのうちの1つのトラッカ51に接続するためのトラッカ接続先情報を含むTorrent Fileをあるノードが保持しており、また、暗号化ピースを保持しているとする。当該ノードは、Torrent Fileのトラッカ接続先情報を参照し、当該ノードを一意に識別するためのノード識別情報をトラッカ51に送信する。ノード識別情報とは、例えば、当該ノードのIPアドレスとポート番号とである。トラッカ51は、当該ノード識別情報を受信するとこれを用いて図11に示されるようなノード情報を生成する。
<コンテンツ配信処理の基本的な手順>
次に、本実施の形態にかかるコンテンツ配信システムで行うコンテンツ配信処理の基本的な手順について図12を用いて説明する。尚、リーチャ50は、暗号化ピースを他のリーチャ50からも受信可能であるが、ここでは、説明の便宜上、暗号化ピースをシーダ52A〜52Cからの少なくとも1つから受信するものとする。
リーチャ50は、まず、販売サーバ54にアクセスして、Torrent Fileを取得する(ステップS1)。そして、リーチャ50は、Torrent Fileに含まれるトラッカ情報に含まれるトラッカ接続先情報を用いてトラッカ51にアクセスすると(ステップS2)、トラッカ51はリーチャ50に対して、ノード情報を送信する(ステップS3)。リーチャ50は、ノード情報を受信すると(ステップS4)、ノード情報を用いて、例えばシーダ52A〜52Cの少なくとも1つにアクセスする(ステップS5)。シーダ52は、リーチャ50からアクセスされると、自身の保持する暗号化ピースのシーケンスを示すピース情報をリーチャ50へ送信する(ステップS6)。
リーチャ50は、ピース情報を受信すると(ステップS7)、当該ピース情報を用いて、少なくとも1つのシーダ52にアクセスする(ステップS8)。そして当該シーダ52に対して、各ピースC1〜CNに各々対応して複数存在しえる暗号化ピースのうち少なくとも1つを要求するピース要求をリーチャ50は送信して、各暗号化ピースを受信する。シーダ52は、リーチャ50からのピース要求に応じて、自身の保持する暗号化ピースをリーチャ50に送信する(ステップS9)。具体的には、リーチャ50は、例えば、シーダ52Bにアクセスして受信したピース情報を用いて、ピースC1が暗号化された暗号化ピースE( K( i1, 1 ) )[ C1 ](i1は1≦i1≦mの整数)のうち例えば「i1=1」の暗号化ピースをシーダ52Bが保持しているか否かを判断し、当該判断結果が肯定的である場合、当該シーダ52Bにアクセスして、当該暗号化ピースE( K( 1, 1 ) )[ C1 ]をシーダ52Bから受信することによりこれを取得する。尚、シーダ52Bが当該暗号化ピースE( K( 1, 1 ) )[ C1 ]を実際には保持していなかった場合、リーチャ50は、次いで、他のシーダ52(例えばシーダ52C)にアクセスして、当該他のシーダ52Cからピース情報を取得する。そして、リーチャ50は、上述と同様にして、ピース情報を用いて、当該暗号化ピースをシーダ52Cが保持しているか否かを判断して、当該判断結果が肯定的である場合、シーダ52にアクセスして、当該暗号化ピースの取得を試みる。リーチャ50は、このような処理を繰り返して、各暗号化ピースから構成される暗号化コンテンツ{E( K( i1, 1 ) )[ C1 ], E( K( i2, 2 ) )[ C2 ], …, E( K( iN, N ))[ CN ]}を得る。
なお、リーチャ50が、ピースCj(1≦j≦N)に対応して複数存在しえる暗号化ピースのうちいずれの暗号化ピースを取得対象とするか、即ち、E( K( i1, j ) )[ Cj ](i1は1≦i1≦mの整数)につきi1を「1」から「m」のうちいずれの値にするかについては、任意である。従って、リーチャ50が、各ピースC1〜CNに対応して各々取得した暗号化ピースにシーケンス{( i1, 1 ), ( i2, 2 ), …,(iN, N )}は、任意のものとなる。
また、ステップS9で送信される暗号化ピースを完全には受信することができないと判断されたとき、リーチャ50は、ステップS9よりも前のいずれかのステップに戻って処理をやり直すことができる。完全には受信することはできないと判断される場合とは、例えば、暗号化ピースや特定の暗号化ピースの一部を受信していたとしても、それらの取得を試みて失敗した回数や、取得を開始してからの時間が所定の閾値以上となる場合などである。
リーチャ50は、コンテンツを構成する各ピースに各々対応する暗号化ピースであって暗号化コンテンツを構成する全ての暗号化ピースを取得すると、各暗号化ピースを各々復号するための各復号鍵を含む鍵束を要求する要求メッセージを鍵サーバ53に送信する(ステップS10)。この要求メッセージには、各復号鍵に対応するシーケンスを示すインデックス情報{( i1, 1 ),…, ( iN, N)}が含まれる。
鍵サーバ53の認証・鍵交換処理部533は、ネットワークインターフェース部532を介して、当該要求メッセージを受信すると(ステップS11)、当該リーチャ50と相互認証を行い、認証成功の場合、要求を受理する旨の受理メッセージをリーチャ50に送信する(ステップS12)。リーチャ50は、鍵サーバ53から受理メッセージを受信すると(ステップS13)、鍵サーバ53からの鍵束の送信を待機する。
一方、鍵サーバ53のシーケンス情報照合部535は、ステップS11で受信された要求メッセージに含まれるインデックス情報を用いて、照合処理を行う(ステップS14)。図13は、照合処理の手順を示すフローチャートである。照合処理では、シーケンス情報照合部535は、ステップS11で受信された要求メッセージに含まれるインデックス情報と、シーケンス情報記憶部536に記憶されているシーケンス情報とを照合し(ステップS140)、インデックス情報に示されるシーケンスと同一のシーケンスを示すシーケンス情報がシーケンス情報記憶部536に記憶されている否かを判断する(ステップS141)。即ち、リーチャ50から要求されている鍵束が過去にリーチャ50のいずれかに送信されたか否かが判断される。
当該判断結果が否定的である場合(ステップS141:NO)、シーケンス情報照合部535は、インデックス情報に示されるシーケンスに対応する鍵束{K( i1, 1 ), K( i2, 2 ), …, K( iN, N )}を送信することを決定する。そして、シーケンス情報照合部535は、制御部530を介して、当該鍵束を当該リーチャ50へ送信するよう鍵供給部537に指示する。また、シーケンス情報照合部535は、当該シーケンスを示すシーケンス情報をシーケンス情報記憶部536に記憶させる(ステップS142)。鍵供給部537は、制御部530を介してシーケンス情報照合部535から送信を指示された鍵束を、鍵記憶部534から読み出しこれをネットワークインターフェース部532を介してリーチャ50に送信する(ステップS143)。尚、ステップS141の判断結果が肯定的である場合、シーケンス情報照合部535は、当該鍵束を送信しないことを決定し、制御部530を介して、当該鍵束の当該リーチャ50への送信禁止を鍵供給部537に指示する(ステップS144)。
図12に戻り、リーチャ50は、鍵束K( i1, 1 ), K( i2, 2 ), …, K( iN, N )を鍵サーバ53から受信した場合(ステップS15:YES)、鍵束に含まれる各復号鍵を用いて、各暗号化ピースE( K( i1, 1 ) )[ C1 ], E( K( i2, 2 ) )[ C2 ], …, E( K( iN, N )[ CN ])をそれぞれ復号し、復号した各ピースC1〜CNを得て、これらから構成されるコンテンツCを得る(ステップS16)。即ち、リーチャ50は、復号鍵K( i1, 1 )を用いてE( K( i1, 1 ) )[ C1 ]を復号して、ピースC1を得て、復号鍵K( i2, 2 )を用いてE( K( i2, 2 ) )[ C2 ]を復号して、ピースC2を得て、復号鍵K( iN, N )を用いてE( K( iN, N ))[ CN ]を復号して、ピースCNを得て、他のピースについても同様にして得ることにより、各ピースC1〜CNから構成されるコンテンツCを得る。
尚、リーチャ50は、ステップS15で鍵束を受信することなく、図13のステップS143で鍵サーバ53から送信されたエラーメッセージを受信した場合、ステップS10で取得した各ピースを復号することができず、従って、コンテンツを利用できない。この場合、ステップS5に戻り、リーチャ50は、ステップS10で取得したシーケンスとは異なるシーケンスで各暗号化ピースを取得した後に、ステップS10以降の処理を再度行う。
以上のように、P2Pネットワークを介して、同一のコンテンツを複数のリーチャ50に配信する場合、暗号化ピースのシーケンスを用いて、鍵サーバ53が鍵束の送信の可否を決定する。ここで、鍵サーバ53が、既に使用されたシーケンスの再使用を回避することにより、コンテンツをリーチャ50毎に個別化することができる。従って、例えば、1つの鍵束が漏洩したとしても、この鍵束に対応する暗号化コンテンツのみしか復号することができないので、コンテンツの不正使用を抑制することができる。また、予め定められたシーケンスではなく、リーチャ50が任意に取得した暗号化ピースにより定まるシーケンスを用いることにより、P2Pネットワークの環境に応じたフレキシブルなコンテンツ配信を実現することができる。
<本実施の形態にかかるコンテンツ配信システムの構成>
次に、上述したコンテンツ配信システムの基本的な構成に加えた本実施の形態に特有の構成について説明する。本構成においては、暗号化ピース及び復号鍵K( i, j )を時間の経過とともに更新する。ここでは、便宜上、暗号鍵と復号鍵とが同一である場合について説明する。尚、上述した通り、暗号鍵と復号鍵とが異なっていても良いが、その場合、暗号鍵と復号鍵とをそれぞれ更新する。例えば、上述のピース処理装置は、図5に例示されるような暗号化ピースを生成するとする。ピース処理装置は、このような暗号化ピースを生成した後ある一定時間Vが経過すると、新たな復号鍵を各々生成して鍵束K’( i, j )(i=1,…,m, j=1,…,N)を生成し、当該新たな復号鍵(暗号鍵)を用いて暗号化して合計mN個の暗号化ピースE( K’( i, j ) )[ Cj ]をそれぞれ生成し、それらを初期シーダ52Aへ渡す。また、ピース処理装置は、新たに生成した合計mN個の暗号化ピースE( K’( i, j ) )[ Cj ]を示すファイル情報を含む新たなTorrent Fileを生成し、それを販売サーバ54及び初期シーダ52Aへ渡す。ピース処理装置が鍵サーバ53でない場合にはピース処理装置は鍵サーバ53にも新たなTorrent Fileを渡す。更に、ピース処理装置は、暗号化ピースの更新を行った旨をトラッカ51に通知する。
ここで、ピース処理装置が生成するTorrent Fileの構成について説明する。図14は、Torrent Fileを例示する図である。本構成におけるTorrent Fileは、図9に例示したTorrent Fileの構成に加え、バージョン情報を有する。バージョン情報とは、Torrent Fileを更新する毎に更新される版を示す情報であり、Torrent Fileの有効性の有無を判断可能な版管理情報である。ピース処理装置は、暗号化ピース及び復号鍵を更新する度にバージョン情報の値を更新して、更新した暗号化ピースを示すファイル情報と共に、値を更新したバージョン情報を有するTorrent Fileを生成し、それを販売サーバ54及び初期シーダ52Aへ渡す。尚、Torrent Fileが有効性を有する、即ち、Torrent Fileが有効であるとは、そのファイル情報によって示される暗号化ピースが有効であり、当該暗号化ピースを復号するための復号鍵が有効であるということである。有効な復号鍵とは、例えば暴露等されたことにより無効化されてるものではなく、鍵サーバ53がリーチャ50から要求された場合に送信可能なものである。従って、Torrent Fileの有効性の有無が判断されることにより、そのファイル情報によって示される暗号化ピースの有効性の有無及び当該暗号化ピースを復号するための復号鍵が有効性の有無が判断される。尚、ここでは、ピース処理装置が値を更新した最新のバージョン情報を有するTorrent Fileのみが有効であるとして処理を行うものとする。
次に、このような構成において、上述のリーチャ50の基本的な機能に加わる更なる機能について説明する。リーチャ50の鍵束要求部501は、コンテンツ取得部500が取得したTorrent Fileであって暗号化ピースの取得に用いたTorrent Fileに含まれるバージョン情報を取得し、これをインデックス情報と共に上述の要求メッセージに含ませて鍵サーバ53に送信する。
次に、上述の鍵サーバ53の基本的な機能に加わる更なる機能について説明する。図15は、本構成における鍵サーバ53の機能的構成を例示する図である。本構成においては、鍵サーバ53は、有効性判断部539と、Torrent File有効性情報記憶部540とを更に有する。Torrent File有効性情報記憶部540は、有効なTorrent Fileのバージョン情報を特定するための有効性情報を記憶している。ここでは、有効性情報は、最新のバージョン情報を示す情報である。尚、ピース処理装置が鍵サーバ53である場合には、当該鍵サーバ53がバージョン情報を生成して有効性情報をTorrent File有効性情報記憶部540に記憶する。ピース処理装置が鍵サーバ53でない場合には、鍵サーバ53は有効性情報をピース処理装置から取得してこれをTorrent File有効性情報記憶部540に記憶する。有効性判断部539は、認証・鍵交換処理部533が受信した要求メッセージに含まれるバージョン情報と、Torrent File有効性情報記憶部540に記憶されている有効性情報とを照合することにより、リーチャ50から要求されている鍵束の有効性の有無を判断する。シーケンス情報照合部535は、有効性判断部539の判断結果に応じて、上述と同様にしてインデックス情報とシーケンス情報との照合を行う。
(2)動作
次に、本実施の形態にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順について図12を用いて説明する。ステップS1では、リーチャ50は、上述と同様にして、販売サーバ54にアクセスして、Torrent Fileを取得する。尚、リーチャ50は、ステップS1を行う度に最新のTorrent Fileを取得することになる。ステップS2〜S9は上述の基本構成における処理と同様である。ステップS10では、リーチャ50は、ステップS1で取得し暗号化ピースの取得に用いたTorrent Fileに含まれるバージョン情報を含む要求メッセージを鍵サーバ53に送信する。例えば、各暗号化ピースに対応するTorrent Fileのバージョン情報が同一である場合、リーチャ50は、以下のようにバージョン情報とインデックス情報との組み合わせにより表される要求メッセージを鍵サーバ53に送信する。
{Version, ( i1, 1 ), ( i2, 2 ), …, ( iN, N) }
(ただし、1≦i1, …, iN≦m)
Versionは、Torrent Fileのバージョン情報を表す。
尚、リーチャ50はステップS1の処理を複数回行って複数の異なるTorrent Fileを販売サーバ54から取得しており、複数のTorrent Fileを用いて各暗号化ピースを取得する場合もある。この場合、リーチャ50は、例えば以下のように、各暗号化ピースに対応するTorrent Fileのバージョン情報と当該バージョン情報に対応する各インデックス情報との組み合わせを要求メッセージに含ませてこれを鍵サーバ53に送信する。
{ ( i1, 1, Version_1 ), ( i2, 2, Version_2 ), …, ( iN, N, Version_N) }
Version_i(1≦i≦N)は、各暗号化ピースに対応するTorrent Fileのバージョン情報を表す。尚、各Version_iは各々異なるものであっても良いし、少なくとも2つが同じであっても良い。
次いで、ステップS11〜S13は上述の基本構成における処理と同様である。ステップS14では、鍵サーバ53は、以下の照合処理を行う。図16は、本実施の形態に係る照合処理の手順を示すフローチャートである。鍵サーバ53の有効性判断部539は、要求メッセージに含まれるバージョン情報と、Torrent File有効性情報記憶部540に記憶されている有効性情報とを照合する(ステップS140G)。そして、有効性判断部539は、これらが一致するか否かを判断することにより、当該要求メッセージにより要求されている鍵束が有効か否かを判断する(ステップS140H)。即ち、ここでは、最新のバージョン情報を含むTorrent Fileに含まれるファイル情報によって示される暗号化ピースを復号するための復号鍵のみが有効であると判断される。尚、要求メッセージに複数のバージョン情報が含まれる場合、有効性判断部539は、各バージョン情報についてステップS140Hの判断を行う。全てのバージョン情報についての判断結果が肯定的である場合、要求されている鍵束に含まれる復号鍵は全て有効であり、当該鍵束は有効であると判断する。次いで、シーケンス情報照合部535が、上述と同様にしてステップS140以降の処理を行う。少なくとも1つのバージョン情報に対するステップS140Hの判断結果が否定的である場合、有効性判断部539は、当該バージョン情報に対応するインデックス情報によって特定される復号鍵は無効であると判断し、当該復号鍵を含む鍵束は無効であると判断する。この場合、シーケンス情報照合部535が、上述と同様にしてステップS144の処理を行う。
以上のように、暗号化ピース及び鍵束を逐次更新していけば、全ての暗号化ピース及び鍵束を集め、それら全てを何らかの方法で暴露し、他のユーザにコンテンツを不正使用させるという不正行為を抑制することができる。なぜなら、そのような不正行為を行おうとする者が全ての暗号化ピースを取得する前に、所望の暗号化ピースをネットワーク上において見付け難くなるからである。つまり、各シーダ52には一定時間毎に新たな暗号化ピースが保持される又は新たな暗号化ピースに置き換わりうるので、時間的に古い鍵束に対応する暗号化ピースを取得しようとしても、見つけ出せない恐れがあるからである。このため、このような不正行為による被害としてコンテンツの不正使用をより効果的に抑制することができる。
(3)変形例
<変形例1_1>
上述の第1の実施の形態においては、Torrent Fileは上述のものに限らず、例えば、ファイル情報は、各暗号化ピースを用いてハッシュ演算により計算されるハッシュ値を含んでいても良い。各暗号化ピースのハッシュ値とは、例えば以下のように表される。
{ hash( E( K( i, j ) )[ Cj ] ) }
(ただし、1≦i≦m、1≦j≦N)
図17は、このようなTorrent Fileのデータ構成を例示する図である。同図においては、暗号化ピースのハッシュ値とインデックスとの対応関係が示される。リーチャ50は、これらm×n個のハッシュ値を用いて、受信した各暗号化ピースの完全性を確認することができる。更に、このようなTorrent Fileに対し、Torrent Fileの生成者又は信頼できる第三者(例えば、コンテンツ製作者)がディジタル署名を付加しても良い。この場合、リーチャ50は、受信した各暗号化ピースの完全性に加えて正当性も確認することができる。
また、このようなTorrent Fileを参照することで、暗号化ピースのハッシュ値からインデックスを特定することが可能であり、この結果、当該暗号化ピースを復号するための復号鍵を特定することも可能になる。
このような構成においては、更に、シーダ52は、ハッシュ値を含むピース情報をリーチャ50に送信するようにしても良い。図18は、ハッシュ値を含むインデックス情報を例示する図である。この場合も、リーチャ50は、ハッシュ値を用いて、受信した各暗号化ピースの完全性を確認することができる。
また、ファイル情報は、全てのインデックス(上記の例では1≦i≦m、1≦j≦Nの全ての( i, j ))についてのものである必要はなく、その一部についてのものであってもよい。
<変形例1_2>
上述した第1の実施の形態においては、版管理情報は、Torrent Fileを生成した時刻を示す情報や、Torrent Fileを用いてハッシュ演算により計算されるハッシュ値などであっても良く、バージョン情報を含めこれらのうち少なくとも2つ以上の組み合わせなどであっても良い。この場合、Torrent File有効性情報記憶部540は、有効なTorrent Fileの版管理情報を特定するための有効性情報として、最新のTorrent Fileを生成した時刻を示す情報や、最新のTorrent Fileを用いてハッシュ演算により計算されるハッシュ値を示す情報を記憶する。そして、鍵サーバ53は、上述の第1の実施の形態と同様にして、有効性情報を用いて、リーチャ50から送信された要求メッセージにより要求されている鍵束が有効か否かを判断する。
<変形例1_3>
上述した第1の実施の形態においては、リーチャ50は、要求メッセージにTorrent Fileがバージョン情報を含ませるようにしたが、バージョン情報ではなく、Torrent Fileに含まれるファイル情報によって示される暗号化ピースのハッシュ値を要求メッセージに含ませて送信するようにしても良い。この場合、当該ハッシュ値が、Torrent Fileの有効性を判断可能な版管理情報となる。この場合、リーチャ50が取得するTorrent Fileには、バージョン情報が含まれていなくても良い。また、この場合、例えば、変形例1_1で説明したように、Torrent Fileのファイル情報が各暗号化ピースのハッシュ情報を含むとする。このようなTorrent Fileのファイル情報をリーチャ50は参照して、その復号鍵を要求する各暗号化ピースのハッシュ値を要求メッセージに含ませて鍵サーバ53に送信する。又は、Torrent Fileのファイル情報が各暗号化ピースのハッシュ情報を含むのではなく、リーチャ50自体が、取得した暗号化ピースのハッシュ値を算出しこれを要求メッセージに含ませて送信する。
一方、いずれの場合も、鍵サーバ53のTorrent File有効性情報記憶部540は、有効なTorrent Fileに含まれるファイル情報によって示される各暗号化ピースのハッシュ値を予め記憶している。そして、有効性判断部539は、要求メッセージに含まれるハッシュ値と、Torrent File有効性情報記憶部540に記憶されているハッシュ値とを照合し、要求メッセージに含まれる全てのハッシュ値について一致するものがある場合、有効性判断部539は、要求された鍵束は有効であると判断する。一方、要求メッセージに含まれる各ハッシュ値のうちTorrent File有効性情報記憶部540に一致するものがないものがある場合、有効性判断部539は、要求された鍵束は無効であると判断する。この場合、鍵サーバ53は、要求した鍵束が無効である旨のメッセージをリーチャ50に送信するように構成しても良い。また、鍵サーバ53は、例えば、一致するものがTorrent File有効性情報記憶部540に記憶されていないハッシュ値に対応するインデックス情報をリーチャ50に送信することにより、無効な復号鍵により復号される暗号化ピースをリーチャ50に通知するようにしても良い。
<変形例1_4>
上述した第1の実施の形態においては、Torrent Fileは、バージョン情報に加え、有効なTorrent Fileのバージョン情報を特定するための有効性情報を含むようにしても良い。図19は、本変形例にかかるTorrent Fileを例示する図である。有効性情報は、例えば、有効なTorrent Fileのバージョン情報を示す情報である。例えば、あるコンテンツについてTorrent Fileのバージョン情報が「1」から順に「5」まで更新されているとする。このうち、有効なTorrent Fileのバージョン情報が「3」、「4」、「5」であるとき、有効性情報は、有効なTorrent Fileのバージョン情報として、「3」、「4」、「5」を示すようにしても良い。又は、有効性情報は、有効なTorrent Fileのバージョン情報の範囲を特定する情報であっても良い。この場合、有効なTorrent Fileのバージョン情報の範囲が「3」以上であるとして、有効性情報は、「3」のみを示すようにしても良い。また、有効でない復号鍵により復号される暗号化ピースを示すファイル情報を含むTorrent Fileのバージョン情報のリスト又は範囲を示すように、有効性情報を構成しても良い。この場合、有効性情報によって示されるバージョン情報のリスト又は範囲以外のTorrent Fileが有効であると特定することができる。
尚、どの時点のTorrent Fileを有効とするかは特に限定されない。また、暗号化ピース及び復号鍵を更新する度に、どの時点のTorrent Fileを有効とするかを変更しても良い。
このような構成において、鍵サーバ53の有効性情報記憶部540には、上述の有効性情報の代わりに、その時点において有効なTorrent Fileを特定する有効性情報が記憶される。尚、ピース処理装置が鍵サーバ53である場合には、当該鍵サーバ53が有効性情報を生成して有効性情報をTorrent File有効性情報記憶部540に都度記憶する。ピース処理装置が鍵サーバ53でない場合には、鍵サーバ53は有効性情報をピース処理装置から都度取得してこれをTorrent File有効性情報記憶部540に記憶する。
鍵サーバ53は、上述のステップS140Gでは、有効性情報との照合を行うのではなく、要求メッセージに含まれるバージョン情報が、Torrent File有効性情報記憶部540に記憶されている有効性情報によって示されるバージョン情報のリスト又は範囲に含まれるか否かを判断する。これにより、鍵サーバ53は、要求メッセージによって要求されている鍵束の有効性の有無を判断する。そして、当該判断結果が肯定的である場合、ステップS140に進み、当該判断結果が否定的である場合、ステップS144に進む。
尚、Torrent Fileに含まれる有効性情報は、上述のものに限らず、当該Torrent Fileの有効期限を示す情報であっても良い。当該Torrent Fileの有効期限とは、即ち、当該Torrent Fileに含まれるファイル情報によって示される暗号化ピースを復号するための復号鍵をリーチャ50が鍵サーバ53対して要求可能である期限である。この場合、リーチャ50は、有効性情報を参照することにより、取得したTorrent Fileがその時点において有効であるか否かを知ることができる。そして、例えば、リーチャ50は、鍵サーバ53に要求メッセージを送信する際に、各暗号化ピースの取得に用いたTorrent Fileに含まれる有効期限情報によって示される有効期限内であるか否かを判断し、当該判断結果が肯定的である場合に、当該Torrent Fileに含まれるバージョン情報を要求メッセージに含ませて鍵サーバ53に送信する。
また、リーチャ50は、取得したTorrent Fileに含まれる有効性情報を参照して、当該Torrent File自体の有効性の有無を判断し、当該判断結果に応じて、更新されているTorrent Fileを取得するようにしても良い。例えば、当該Torrent Fileが有効でないと判断した場合や、当該Torrent Fileの有効期限が間近に迫っており有効期限までの時間が所定時間以内であると判断した場合、リーチャ50は、当該Torrent Fileを取得した販売サーバ54や当該販売サーバ54とは異なる販売サーバ54から、更新されているTorrent Fileを取得し直しても良い。また、リーチャ50は、ある時点において取得したTorrent Fileを用いて暗号化ピースの取得を始め、リーチャ50にとって未知のインデックスに対応する暗号化ピースをシーダ52が保持している場合、シーダ52から当該未知のインデックスに対応する暗号化ピースを受信し、その受信後に、更新されているTorrent Fileを取得して受信した各暗号化ピースの完全性や正当性を確認してもよい。
一方、鍵サーバ53のTorrent File有効性情報記憶部540は、各Torrent Fileのバージョン情報と当該バージョン情報の有効性情報とを対応付けて記憶する。そして、有効性判断部539は、リーチャ50から受信した要求メッセージに含まれるバージョン情報について、Torrent File有効性情報記憶部540に記憶されているバージョン情報に対応付けられている有効性情報を参照して、有効期限内であるか否かを判断する。要求メッセージによって要求されている復号鍵毎にバージョン情報が異なる場合には、有効性判断部539はこの判断を復号鍵毎に行う。そして、全ての復号鍵について当該判断結果が肯定的である場合に、有効性判断部539は、要求メッセージによって要求されている鍵束は有効であると判断する。
以上のような構成によっても、コンテンツの不正使用をより効果的に抑制することができる。
<変形例1_5>
上述の第1の実施の形態においては、ピース処理装置が値を更新した最新のバージョン情報を有するTorrent Fileのみが有効であるとしたが、これに限らず、最新より以前にピース処理装置が値を更新したバージョン情報有するTorrent Fileを有効であるようにしても良い。また、有効なTorrent Fileのバージョン情報の範囲を適宜変更するようにしても良い。
尚、上述の第1の実施の形態においては、一定時間毎に暗号化ピース及び復号鍵を更新するようにしたが、これに限らず、例えば、鍵束の漏洩が起こった際には直ちに暗号化ピース及び復号鍵を更新するようにしても良い。
また、上述のステップS140Hでは、少なくとも1つのバージョン情報に対する判断結果が否定的である場合、鍵サーバ53は、例えば、当該バージョン情報に対応するインデックス情報をリーチャ50に送信することにより、無効である復号鍵がいずれであるのかをリーチャ50に通知するようにしても良い。
また、ステップS10では、リーチャ50は、バージョン情報を要求メッセージに含ませて鍵サーバ53に送信するようにしたが、これに限らず、受理メッセージを受信した後やその他のタイミングで、バージョン情報を鍵サーバ53へ送信しても良い。上述の変形例1_2におけるハッシュ値や変形例1_4における有効性情報についても同様である。
<変形例1_6>
上述した第1の実施の形態においては、リーチャ50がシーダ52から暗号化ピースを取得する際に、Torrent Fileに含まれるバージョン情報を用いて、当該シーダ52が保持する暗号化ピースの有効性の有無を判断するようにしても良い。この場合、シーダ52はピース情報をリーチャ50へ送信するとき、シーダ52が保持する各暗号化ピースについて対応するTorrent Fileのバージョン情報もリーチャ50へ送信する。ここでは、シーダ52は、上述の第1の実施の形態においてリーチャ50が鍵サーバ53にバージョン情報を送信する場合と同様に、バージョン情報とインデックス情報との組み合わせによりピース情報及びバージョン情報を送信するようにしても良い。
そして、リーチャ50は、シーダ52から取得したバージョン情報を用いて、当該シーダ52が保持する暗号化ピースの有効性の有無を判断する。図20は、本変形例におけるリーチャ50の機能的構成を例示する図である。本変形例においては、リーチャ50のコンテンツ取得部500は、有効性判断部500aを有する。有効性判断部500aは、シーダ52からピース情報及びバージョン情報を受信すると、当該バージョン情報と、当該バージョン情報と、トラッカ51から取得したTorrent Fileに含まれているバージョン情報とを照合し、この照合結果に応じて、シーダ52が保持する暗号化ピースの有効性の有無を判断する。そして、コンテンツ取得部500は、有効性判断部500aの判断結果に応じて、当該シーダ52から暗号化ピースを取得する。
次に、本変形例にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順について図21を用いて説明する。ステップS1〜S5は上述の第1の実施の形態と同様である。ステップS50では、シーダ52は、自身が保持する各暗号化ピースについてピース情報及び各ピースの取得に用いられたTorrent Fileのバージョン情報をリーチャ50へ送信する。ステップS51では、リーチャ50は、ピース情報及びバージョン情報をシーダ52から受信する。次いで、リーチャ50は、ステップS50で受信したバージョン情報と、ステップS1でトラッカ51から取得し暗号化ピースの取得に用いるTorrent Fileに含まれているバージョン情報とを照合し(ステップS52)、これらが一致するか否かを判断することにより、シーダ52が保持する暗号化ピースの有効性の有無を判断する(ステップS53)。尚、リーチャ50は、ステップS1の処理を複数回行って複数の異なるTorrent Fileをトラッカ51から取得しており、複数のTorrent Fileを用いて暗号化ピースを取得する場合がある。この場合、リーチャ50は、ステップS50で受信したバージョン情報と、当該複数のTorrent Fileに各々含まれるバージョン情報と各々照合する。また、シーダ52から取得したバージョン情報についても、各暗号化ピースに対応するバージョン情報が異なる場合がある。この場合、リーチャ50は、各暗号化ピースについて各々バージョン情報を照合する。そして、各暗号化ピースについてステップS52で取得した各バージョン情報と、リーチャ50が暗号化の取得に用いるTorrent Fileに含まれるバージョン情報とが一致する場合、リーチャ50は、シーダ52が保持する暗号化ピースが有効であると判断し、上述の第1の実施の形態と同様にして、ステップS8以降の処理を行う。尚、ステップS14では、鍵サーバ53は、図16に示したS140G,S140Hの処理を行わずにS140以降の処理を行えば良い。一方、ステップS52で前者のバージョン情報と後者のバージョン情報とが一致しないものがある場合、リーチャ50は、シーダ52が保持する暗号化ピースが有効でないと判断し、当該シーダ52からは暗号化ピースを取得しない。尚、この場合、リーチャ50は、ステップS1又はステップS5に戻って処理をやり直しても良い。
以上のように、リーチャ50自身が、Torrent Fileに含まれるバージョン情報を用いて、有効であると判断される暗号化ピースのみを取得する。これにより、暗号化ピースを復号するための復号鍵が例え暴露されたとしても、当該暗号化ピースの取得が回避され得る。従って、不正行為による被害としてコンテンツの不正使用をより効果的に抑制することができる。
尚、シーダ52が保持する各暗号化ピースに対応するTorrent Fileのバージョン情報が全て同一である場合、シーダ52はピース情報の送信とは異なるタイミングでバージョン情報をリーチャ50に送信しても良い。例えば、リーチャ50との接続のネゴシエーションを行うタイミングなどである。また、シーダ52がバージョン情報を取得する他の方法として、例えば、シーダ52がTorrent Fileを用いてハッシュ演算により計算されるハッシュ値を送信し、リーチャ50がハッシュ値を受信するとこれと同一のハッシュ値が計算されるTorrent Fileを検索し、見付かったTorrent Fileに含まれるバージョン情報を取得するという方法などがある。
<変形例1_7>
上述の第1の実施の形態においては、ノード情報は、各ノードのIPアドレス及びポート番号を示すものとしたが、これに限らず、IPアドレスのみを示すようにしても良いし、各ノードのMACアドレスを示すようにしても良いし、コンテンツ配信サービスの加入時に割り当てられる加入者IDを示すようにしても良いし、ノードのURLを含むようにしても良いし、ノードのIPアドレスとポート番号との組に加えてノードのURLが含まれていても良い。この場合、各ノードはノード識別情報として、当該ノードのIPアドレス、MACアドレス、加入者ID及びURLのうち少なくとも1つ以上をトラッカ51に送信すれば良い。
また、上述の第1の実施の形態においては、トラッカ51がノード情報を生成する際に、各ノードは、ノード識別情報をトラッカ51に送信するようにした。しかし、これに限らず、ノード識別情報に加えて、Torrent File識別情報をトラッカ51に送信しても良い。Torrent File識別情報とは、Torrent Fileを一意に識別可能な情報であり、例えば、Torrent Fileの一部又は全部のハッシュ値であっても良いし、Torrent Fileのファイル名であっても良い。また、そのIDを示すフィールドを含むようにTorrent Fileを構成し、そのIDの値をTorrent File識別情報として取り扱うようにしても良い。この場合、トラッカ51は、Torrent File識別情報毎にノード情報を生成しても良い。この場合、リーチャ50からアクセスされたトラッカ51は、リーチャ50が送信するTorrent File識別情報に対応するノード情報をリーチャ50へ送信する。
また、トラッカ51は、ノード識別情報を基にノードをグループ分けし、グループ毎にノード情報を生成しても良い。この場合、リーチャ50からアクセスされたトラッカ51は、当該リーチャ50のノード識別情報が属するグループに対応するノード情報をリーチャ50へ送信する。ここで、トラッカ51は、リーチャ50が複数のグループに属するようにグループ分けしても良く、この場合、トラッカ51は、リーチャ50のノード識別情報が属する全部または一部のグループにそれぞれ対応するノード情報をリーチャ50へ送信する。
また、トラッカ51は、ノード情報を生成する際に、Torrent Fileに含まれるバージョン情報を用いてノードをグループ分けしても良い。例えば、トラッカ51は、各々保持するTorrent Fileに含まれるバージョン情報が同一である各ノードの接続先が、同一のノード情報に示されるようにノード情報を生成する。又は、トラッカ51は、同一に限らず、所定範囲にあるバージョン(例えば、バージョン1とバージョン2のみ、など)を示すバージョン情報を含むTorrent Fileを保持するノード各ノードの接続先が、同一のノード情報に示されるようにノード情報を生成しても良い。リーチャ50はトラッカ51にアクセスしてノード情報を取得する際、Torrent Fileのバージョン情報をトラッカ51に送信する。トラッカ51は、リーチャ50から送信されたバージョン情報に対応するノード情報をリーチャ50へ送信する。このような構成によれば、ノード情報に接続先が示される全てのノードは、同一又は所定範囲にあるバージョンを示すバージョン情報を含むTorrent Fileを用いて、暗号化ピースの送受信を行うことになる。この場合、そのTorrent Fileが有効である限り、接続相手のノードが有効な暗号化ピースを保持していることになる。言い換えると、接続相手のノードから無効な暗号化ピースをダウンロードしてしまうケースがないことになる。このため、暗号化ピースのより効率的な配信が可能となる。尚、トラッカ51は、バージョン情報に限らず、変形例1_2で説明した様々な版管理情報や、変形例1_6で説明したTorrent File識別情報を用いてノードをグループ分けしても良い。
<変形例1_8>
上述した第1の実施の形態においては、販売サーバ54がリーチャ50に送信するTorrent Fileを、リーチャ50のグループ毎に異ならせても良い。即ち、各々異なる暗号化ピースを示すファイル情報を含むTorrent Fileを、グループ毎に異ならせてリーチャ50に送信する。その結果、P2PネットワークNTにおいて配信される暗号化ピースがグループ毎に異なるようにする。例えば、あるグループに属するリーチャ50については、暗号化ピースとして{ E( K( i, 1 ) )[ C1 ], E( K( i, 2 ) )[ C2 ], …, E( K( i, N ))[ CN ]} (ただし、1≦i≦2)があることを示すファイル情報を含むTorrent Fileを送信し、他のグループに属するリーチャ50については、暗号化ピースとして{ E( K( i, 1 ) )[ C1 ], E( K( i, 2))[ C2 ], …, E( K( i, N))[ CN ]}(ただし、3≦i≦5)があることを示すファイル情報を含むTorrent Fileを送信する。
グループ分けは、販売サーバ54がどの地域向けにコンテンツの配信サービスを行っているかを基準として行っても良い。例えば、日本のユーザ向けの配信サービスを扱う販売サーバ54がリーチャ50へ渡すTorrent Fileと、米国のユーザ向けの配信サービスを扱う販売サーバ54がリーチャ50へ渡すTorrent Fileとを異ならせるようにしても良い。
この場合、変形例1_7で説明したように、トラッカ51によるノード情報のグループ分けに応じて、Torrent Fileのグループ分けを行うようにしても良い。例えば、トラッカ51は、ノードが少なくとも1つ以上のグループに属し且つTorrent Fileがグループ毎に異なるように各ノードをグループ分けし、各ノードに対して当該ノードと同じグループに属する他のノードを含むノード情報を送信するようにすれば良い。また、この場合、ノード情報におけるグループと、Torrent Fileにおけるグループとは一対一対応するようにしても良いし、複数対一対応するようにしても良い。
以上のように、リーチャ50をグループ分けしてTorrent Fileを送信することにより、リーチャ50が属するグループとは異なるグループにおいて配信される暗号化ピースを復号するための鍵束が暴露されても、当該リーチャ50は、Torrent Fileを用いて自身が取得した暗号化ピースを当該鍵束を用いて復号することができない。このため、鍵束を暴露するという不正行為がより起こりにくくなり、また、不正行為が起こった場合の影響範囲をより限定することができる。
<変形例1_9>
上述した第1の実施の形態においては、Torrent Fileの更新が行われたとき、当該Torrent Fileに含まれるトラッカ接続先情報が変更された場合、更新前のTorrent Fileであって無効化されるTorrent Fileに含まれるトラッカ接続先情報によって接続可能なトラッカ51の機能を停止させるようにしても良い。即ち、当該トラッカ51は、アクセスしてきたリーチャ50へノード情報を送信する自身の機能を停止させる。この場合、例えば、外部装置からトラッカ51に対して上述の機能の停止を要求する停止要求メッセージを送信する。外部装置とは、例えば、販売サーバ54、シーダ52、リーチャ50、コンテンツプロバイダ、ピース処理装置などである。トラッカ51は当該停止要求メッセージを受信すると、無効化されるTorrent Fileに含まれるトラッカ接続先情報によってリーチャ50がアクセスしてきたとしても、ノード情報を送信しない。
又は、無効化されるTorrent Fileに含まれるトラッカ接続先情報によってアクセスしてきたリーチャ50全てではなく一部のリーチャ50のみにトラッカ51はノード情報を送信しないようにしても良い。例えば、トラッカ51は、Torrent Fileの更新が行われたとき、当該Torrent Fileに含まれるトラッカ接続先情報が変更された場合、停止要求メッセージに加え、ノード情報を送信しない対象となるリーチャ50を識別するためのリーチャ識別情報を示すリストを外部装置から取得する。リーチャ識別情報としては、例えば、リーチャ50のIPアドレスやポート番号や、リーチャ50のMACアドレスや上述の加入者IDなどやこれらの組み合わせなどがある。そして、トラッカ51は、アクセスしてきたリーチャ50からリーチャ識別情報を取得し、当該リーチャ識別情報がリストに存在するか否かを判断し、当該判断結果が肯定的である場合には、当該リーチャ50にはノード情報を送信しないようにする。
これらの構成によれば、無効化されるTorrent Fileによる暗号化ピースの取得をより効果的に抑制することができる。結果的に、コンテンツの不正使用をより効果的に抑制することができる。
また、Torrent Fileの更新が行われたとき、更新前のTorrent Fileであって無効化されるTorrent Fileに含まれるトラッカ接続先情報によって接続可能なトラッカ51は、アクセスしてきたリーチャ50に対して、更新されたTorrent Fileを取得することを促す促進メッセージを送信しても良い。リーチャ50は、当該促進メッセージに従って、更新されたTorrent Fileを販売サーバ54から取得すれば良い。これにより、リーチャ50は、更新されたTorrent Fileを用いて暗号化ピースを取得することになるため、より新しい暗号化ピースの取得をリーチャ50に促すことができる。
[第2の実施の形態]
次に、コンテンツ配信システムの第2の実施の形態について説明する。なお、上述の第1の実施の形態と共通する部分については、同一の符号を使用して説明したり、説明を省略したりする。
(1)構成
本実施の形態における構成について、上述の第1の実施の形態において説明したコンテンツ配信システムの基本構成との差異を主に説明する。従って、本実施の形態においては、第1の実施の形態に特有の機能の実現のために用いられるバージョン情報は、Torrent Fileには含まれていなくても良い。従って、鍵サーバ53は、有効性判断部539とTorrent File有効性情報記憶部540とを有さなくても良い。本実施の形態において鍵サーバ53は、リーチャ50から要求された鍵束に含まれる各復号鍵によって復号される各暗号化ピースをリーチャ50が実際に保持しているか否かを確認する。
<リーチャ50の構成>
本実施の形態においては、リーチャ50は、各暗号化ピースを復号するための各復号鍵を含む鍵束を要求する要求メッセージを鍵サーバ53に送信した後、鍵サーバ53からの要求に応じて、各暗号化ピースのうち少なくとも2つ以上の暗号化ピースを用いてハッシュ演算により計算されるハッシュ値を鍵サーバ53に送信する。図22は、本実施の形態にかかるリーチャ50の機能的構成を例示する図である。本実施の形態においては、リーチャ50は、コンテンツ取得部500と、鍵束要求部501と、鍵束取得部502と、コンテンツ復号部503に加え、保持証明部506を有する。
保持証明部506は、鍵束要求部501が鍵サーバ53に送信した要求メッセージによって要求された鍵束に含まれる復号鍵によって復号される各暗号化ピースを実際に保持していることを証明するための保持証明情報を鍵サーバ53に送信する。具体的には、保持証明部506は、要求メッセージによって要求された鍵束に含まれる復号鍵によって復号される各暗号化ピースのうち、少なくとも2つ以上の暗号化ピースのハッシュ値を保持証明情報として要求する情報要求メッセージを鍵サーバ53から受信する。そして、保持証明部506は、当該情報要求メッセージに従って、該当の暗号化ピースを外部記憶装置から読み出し、これらを連結したデータを用いてハッシュ演算によりハッシュ値を計算する。そして、保持証明部506は、計算したハッシュ値を鍵サーバ53に送信する。
<鍵サーバ53の構成>
図23は、本実施の形態にかかる鍵サーバ53の機能的構成を例示する図である。鍵サーバ53は、制御部530と、パケット処理部531と、ネットワークインターフェース部532と、認証・鍵交換処理部533と、鍵記憶部534と、シーケンス情報記憶部536と、シーケンス情報照合部535と、鍵供給部537とに加え、保持証明判断部541と保持判断情報記憶部542とを有する。保持判断情報記憶部542は、認証・鍵交換処理部533がリーチャ50から受信した要求メッセージによって要求された鍵束に含まれる復号鍵によって復号される各暗号化ピースをリーチャ50が実際に保持しているか否かを判断するための保持判断情報を記憶している。具体的には、保持判断情報記憶部542は、保持判断情報として、初期シーダ52Aと同じく全ての暗号化ピースをインデックスと対応付けて記憶している。
保持証明判断部541は、認証・鍵交換処理部533がリーチャ50から受信した要求メッセージによって要求された鍵束に含まれる復号鍵によって復号される各暗号化ピースをリーチャ50が実際に保持しているか否かを、保持判断情報記憶部542に記憶された保持判断情報を用いて判断する。具体的には、保持証明判断部541は、当該要求メッセージに含まれるインデックス情報を用いて、ハッシュ値を要求する対象の複数の暗号化ピースを選択する。そして、保持証明判断部541は、選択した暗号化ピースのハッシュ値を要求する情報要求メッセージをリーチャ50に送信する。例えば、インデックス情報によって示されるシーケンスが{( i1, 1 ), ( i2, 2 ), …, ( iN, N)}である場合、保持証明判断部541は、このシーケンスに含まれる各インデックスを2つ以上任意に選択する。そして、保持証明判断部541は、選択したインデックスを示すと共に当該インデックスに対応する暗号化ピースのハッシュ値を要求する情報要求メッセージをリーチャ50に送信する。また、保持証明判断部541は、選択した暗号化ピースについて、保持判断情報記憶部542から読み出し、これらを用いてハッシュ演算によりハッシュ値を計算する。そして、当該ハッシュ要求メッセージに従ってハッシュ値がリーチャ50から送信されると、これを保持証明判断部541は受信し、これと算出したハッシュ値とを照合する。そして、保持証明判断部541は、照合結果に応じて、当該リーチャ50から受信した要求メッセージによって要求された鍵束に含まれる復号鍵によって復号される各暗号化ピースをリーチャ50が実際に保持しているか否かを判断する。シーケンス情報照合部535は、保持証明判断部541の判断結果に応じて、シーケンス情報の照合を行う。
(2)動作
次に、本実施の形態にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順について図12を用いて説明する。ステップS1〜S13は上述の基本構成における処理と同様である。ステップS14では、鍵サーバ53は、以下の照合処理を行う。図24は、本実施の形態にかかる照合処理の手順を示すフローチャートである。例えば、ステップS11で鍵サーバ53が受信した要求メッセージに含まれるインデックス情報が以下に示されるものとする。
{ ( i1, 1 ), ( i2, 2 ), …, ( iN, N) }
(ただし、1≦i1, …, iN≦m)
鍵サーバ53の保持証明判断部541は、このインデックス情報によって示されるシーケンスに含まれる各インデックスを2つ以上任意に選択する。そして、保持証明判断部541は、選択したインデックスを示すと共に当該インデックスに対応する暗号化ピースのハッシュ値を要求する情報要求メッセージをリーチャ50に送信する(ステップS150)。例えば、( i2, 2 )と( i4, 4 )により特定される2つの暗号化ピースのハッシュ値を要求する情報要求メッセージがリーチャ50に送信される。
一方、リーチャ50は、情報要求メッセージを受信すると、該当の暗号化ピースを外部記憶装置から読み出し、これらを連結したデータを用いてハッシュ演算によりハッシュ値を計算して(ステップS151)、これを鍵サーバ53に送信する(ステップS152)。例えば、リーチャ50は、( i2, 2 )と( i4, 4 )により特定される2つの暗号化ピースを連結して、連結したデータを用いてハッシュ演算によりハッシュ値
hash(E( K(i2 , 2 ) ) [ C2 ] || E( K(i4 , 4 ) ) [ C4 ])
を計算する。尚、||はデータ連結を表す。
鍵サーバ53は、選択した暗号化ピースについて、保持判断情報記憶部542から読み出し、これらを用いてハッシュ演算によりハッシュ値を計算する。そして、鍵サーバ53は、リーチャ50から送信されたハッシュ値を受信すると(ステップS153)、これと、算出したハッシュ値とを照合する(ステップS154)。そして、これらが一致する場合(ステップS155:YES)、鍵サーバ53は、ステップS11で受信した要求メッセージによって要求された鍵束に含まれる復号鍵によって復号される各暗号化ピースをリーチャ50が実際に保持していると判断し、ステップS141以降の処理を行う。一方、ステップS155で前者のハッシュ値と後者のハッシュ値とが一致しない場合(ステップS155:NO)、鍵サーバ53は、ステップS11で受信した要求メッセージによって要求された鍵束に含まれる復号鍵によって復号される各暗号化ピースをリーチャ50が実際に保持していないと判断し、ステップS144に進む。即ち、この場合、鍵サーバ53は、ステップS11で受信した要求メッセージに従わずに、鍵束をリーチャ50に送信しない。
以上のようにして、鍵サーバ53は、リーチャ50が要求している鍵束を送信する前に、当該鍵束に含まれる復号鍵によって復号される暗号化ピースを実際に保持しているか否かを確認する。そして、鍵サーバ53は、当該暗号化ピースを実際に保持していないことを確認した場合には、当該鍵束をリーチャ50に送信しない。これにより、例えば、リーチャ50が鍵束を漏洩させることを目的として、暗号化ピースをダウンロードせずに鍵サーバ53に鍵束を要求するという不正行為を排除することができる。
(3)変形例
<変形例2_1>
上述の第2の実施の形態においては、保持判断情報記憶部542は、保持判断情報として、全ての暗号化ピースを記憶するようにしたが、この場合大きな記憶容量を必要とするため、一部の暗号化ピースのみを記憶するようにしても良い。保持判断情報記憶部542は、例えば、ピースC1〜C3について各々m個の暗号化ピースとして、E( K( 1, 1 ))[C1]〜E( K( m, 1 ))[C1], E( K( 1, 2 ))[C2]〜 E( K( m, 2 ))[C2], E( K( 1, 3 ))[C3]〜E( K( m, 3 ))[C3]の3m個の暗号化ピースのみを記憶する。そして、保持証明判断部541は、保持判断情報記憶部542に記憶された暗号化ピースの範囲内で、要求メッセージに含まれるインデックス情報によって示されるシーケンスに含まれるインデックスのうち、( i1, 1 ), ( i2, 2 ),( i3, 3 )の中から2つ以上を選択して、当該インデックスに対応する暗号化ピースのハッシュ値をリーチャ50に要求すれば良い。このような構成によれば、保持判断情報記憶部542において必要とする記憶容量を小さくすることができる。
尚、ステップS150では、保持証明判断部541は、保持判断情報記憶部542に記憶されていない暗号化ピースを選択しても良い。この場合、保持判断情報記憶部542は、当該暗号化ピースをシーダ52や他のリーチャ50などの他の通信装置から取得すれば良い。
尚、保持判断情報記憶部542は、保持判断情報として、暗号化ピース自体を記憶するのではなく、暗号化ピースのハッシュ値を記憶していても良い。この場合、保持判断情報記憶部542は、全ての暗号化ピースのうち少なくとも2つ以上の暗号化ピースの組み合わせ全てについてハッシュ値を記憶しても良いし、リーチャ50へ要求する又は要求する可能性のあるハッシュ値のみを記憶しても良い。この場合、保持証明判断部541は、ステップS154では、ステップS153でリーチャ50から受信したハッシュ値と、保持判断情報記憶部542に記憶されステップS154で選択した2つの暗号化ピースにより計算されるハッシュ値とを照合すれば良い。
また、この場合、ステップS150では、保持証明判断部541は、保持判断情報記憶部542に記憶されていないハッシュ値が計算される暗号化ピースを選択しても良い。この場合、保持判断情報記憶部542は、当該ハッシュ値自体や当該ハッシュ値の計算の基になる暗号化ピースをシーダ52や他のリーチャ50などの他の通信装置から取得すれば良い。
<変形例2_2>
上述の第2の実施の形態においては、リーチャ50は、鍵サーバ53の要求に応じて、ハッシュ値を計算してこれを保持証明情報として鍵サーバ53に送信した。しかし、これに限らず、リーチャ50は、保持証明情報として、2つ以上の暗号化ピースを連結したデータの全部又は一部を鍵サーバ53に送信するようにしても良い。この場合、鍵サーバ53の保持証明判断部541は、ステップS150では、要求メッセージに含まれるインデックス情報を用いて、2つ以上の暗号化ピースを選択した後、選択した暗号化ピースのインデックスを示すと共に当該暗号化ピースを連結したデータを要求する情報要求メッセージをリーチャ50に送信する。ここで、例えば、インデックス(i2 , 2 )に対応する暗号化ピースとインデックス(i4 , 4 )に対応する暗号化ピースとを連結したデータが要求されるとする。この場合、リーチャ50は、情報要求メッセージを受信すると、ステップS151では、インデックス(i2 , 2 )に対応する暗号化ピースとインデックス(i4 , 4 )に対応する暗号化ピースとを連結して、データE( K(i2 , 2 ) ) [ C2 ] || E( K(i4 , 4 ) ) [ C4 ])を生成し、ステップS152では、当該データを鍵サーバ53へ送信する。また、鍵サーバ53の保持証明判断部541は、保持判断情報記憶部542に記憶されステップS150で選択された暗号化ピースを連結したデータを生成する。そして、保持証明判断部541は、ステップS153で、当該データを受信すると、ステップS154では、当該データと、自身が生成したデータとを照合し、これらが一致する場合にステップS140以降の処理を行えば良い。
<変形例2_3>
上述の第2の実施の形態においては、鍵サーバ53がステップS150で選択する暗号化ピースの数は、2以上の固定値であっても良いし、2以上で適宜変更される可変値であっても良い。
[変形例]
なお、本発明は前記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、前記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。また、以下に例示するような種々の変形が可能である。
<変形例3_1>
上述した各実施の形態においては、鍵サーバ53と、リーチャ50とは、相互認証の後、通信対象のデータを暗号化するようにしても良い。図25は、このような構成の鍵サーバの構成を例示する図である。鍵サーバ53´は、上述の制御部530と、パケット処理部531と、ネットワークインターフェース部532と、認証・鍵交換処理部533と、鍵記憶部534と、シーケンス情報記憶部536と、シーケンス情報照合部535と、鍵供給部537とに加え、暗号処理部538を有する。認証・鍵交換処理部533は、リーチャ50と、通信対象のデータを暗号化するための暗号鍵の交換を行う。暗号処理部538は、認証・鍵交換処理部533が交換した暗号鍵を用いて通信対象のデータを暗号化してこれをネットワークインターフェース部532を介してリーチャ50に送信する。
また、上述した各実施の形態においては、復号鍵及び暗号鍵のうち少なくとも一方を鍵サーバ53自体が発行して生成するようにしても良いし、トラッカ51やコンテンツ製作者が用意したサーバが発行したり生成したりしたものを鍵サーバ53が取得するようにしても良い。
また、コンテンツCを分割した全てのピースC1〜CNが各々異なる暗号鍵で暗号化されているとしたが、これに限らず、一部のピースは同一の暗号鍵で暗号化されていても良い。
上述した各実施の形態においては、トラッカ51、シーダ52及びリーチャ50の数は、上述したものに限らない。
また、P2PネットワークNTに販売サーバ54が接続され、リーチャ50は、販売サーバ54からTorrent Fileを取得するようにした。しかし、販売サーバ54はP2PネットワークNTに接続されていなくても良く、リーチャ50は、例えばCD−ROMなどの記録媒体に記録されたTorrent Fileを読み出すことにより、Torrent Fileを取得するようにしても良い。
また、リーチャ50は、鍵サーバ53とネットワークを介して接続されるようにしたが、ネットワークを介さず専用線などを介して接続されるようにしてもよいし、プロキシサーバを介して接続されるようにしても良い。これにより管理能力を高めたり、プロキシサーバの後段にある鍵サーバが直接攻撃されないようにしたりすることができる。
また、リーチャ50は、ステップS10で、インデックス情報を要求メッセージに含ませて鍵サーバ53に送信したが、これに限らず、受理メッセージを受信した後にインデックス情報を鍵サーバ53へ送信してもよい。
上述のステップS50では、シーダ52は、リーチャ50からのアクセスにより、自身の保持するピースのシーケンスを示すピース情報及びバージョン情報を送信したが、リーチャ50からのアクセスを待たずに、ピース情報及びバージョン情報を当該リーチャ50へ送信するようにしても良い。
上述のステップS9では、シーダ52は、暗号化ピースをリーチャ50に送信したが、これに加えて、対応するインデックスを送信しても良い。例えば、送信する暗号化ピースがE( K( 1, 1 ) )[ C1 ]である場合、これに加えて、対応するインデックス( 1, 1 )をシーダ52はリーチャ50に送信しても良い。
また、リーチャ50は、暗号化ピースをシーダ52から受信するようにしたが、これに限らず、他のリーチャ50から暗号化ピースを取得するようにしても良い。
また、リーチャ50は、各ピースC1〜CNに各々対応する暗号化ピースにつき、同一のピースに対応する異なる暗号化ピースを複数取得しておくようにしても良い。例えば、ピースC1に対して、暗号化ピースE( K( i1, 1 ) )[ C1 ]及びE( K( i1’, 1 ) )[ C1 ](但し、i1≠i1’, 1≦i1≦m,1≦i1’≦m)をリーチャ50は取得しておいても良い。このような構成によれば、リーチャ50が鍵束を鍵サーバ53に要求する際に、仮にインデックス( i1, 1 )を含むシーケンスが既に使用されている場合当該シーケンスに対応する鍵束を取得することはできないが、インデックス( i1’, 1 ) を含むシーケンスが使用可能である場合には、シーダ52へ再びアクセスすることなく当該シーケンスに対応する鍵束を鍵サーバ53から取得することができる。このように、暗号化ピースを予め余分に取得しておくことにより、シーケンスの候補を予め複数用意することができるため、リーチャ50がシーダ52に再度アクセスする煩雑さを回避することができる。
<変形例3_2>
上述の各実施の形態においては、リーチャ50から要求されている鍵束に対応するシーケンスがシーケンス情報記憶部536に既に記憶されている場合、ステップS144では、鍵サーバ53のシーケンス情報照合部535は、制御部530を介して、当該鍵束の当該リーチャ50への送信禁止を鍵供給部537に指示するようにしたが、これに限らず、以下のようにすることもできる。例えば、リーチャ50が暗号化コンテンツE( K( i1, 1 ) )[ C1 ], E( K( i2, 2 ) )[ C2 ], …, E( K( iN, N ))[ CN ]を取得し、これに対応する鍵束を鍵サーバ53へ要求したとする。鍵サーバ53は、リーチャ50から要求された鍵束に対応するシーケンス{( i1, 1 ), ( i2, 2 ), …, ( iN, N )}がシーケンス情報記憶部536に既に記憶されている場合、シーケンス情報記憶部536に記憶されていない他のシーケンス{( i1’, 1 ), ( i2, 2 ), …, ( iN, N )}を生成して、リーチャ50が置き換えるべき暗号化ピースE( K( i1’, 1 ) )[ C1 ]とそのインデックスに関する情報(この例では( i1’, 1 ))をリーチャ50へ送信する。加えて、鍵サーバ53は他のシーケンス{( i1’, 1 ), ( i2, 2 ), …, ( iN, N )}に各々対応する各復号鍵を含む鍵束をリーチャ50へ送信する。このようにすれば、リーチャ50は、鍵サーバ53のシーケンス情報照合部535が行う照合処理において鍵束の送信が許可されるシーケンスに対応する暗号化ピースを取得するために、リーチャ50がトラッカ51へ再度アクセスする煩雑さを避けることができる。尚、鍵サーバ53は、リーチャ50に送信可能な暗号化ピースを予め保持しておく必要があるが、その暗号化ピースは1つでも複数でも良く、その暗号化ピースが複数の場合、リーチャ50が置き換えるべき暗号化ピースとして複数の暗号化ピース(とそれらのインデックスに関する情報)をリーチャ50へ送信してもよい。なお、リーチャ50から要求された鍵束に対応するシーケンス{( i1, 1 ), ( i2, 2 ), …, ( iN, N )}がシーケンス情報記憶部536に未だ記憶されていない場合、鍵サーバ53は上記に例示した置き換えを行ってもよいし、行わなくてもよい。
<変形例3_3>
上述の各実施の形態においては、照合処理では、シーケンス情報照合部535は、リーチャ50から要求されている鍵束が1回でも過去にリーチャ50のいずれかに送信していれば、当該鍵束を送信しないようにした。しかし、これに限らず、同一の鍵束を、2回以上の所定の回数まで送信可能にしても良い。この場合、鍵サーバ53の認証・鍵交換処理部533は、リーチャ50との間で行う相互認証において、リーチャ50を識別するためのリーチャ識別情報をリーチャ50から取得する。シーケンス情報照合部535は、鍵束のシーケンスを示すシーケンス情報と、リーチャ識別情報と、当該リーチャ識別情報によって識別されるリーチャ50が当該鍵束の送信を要求した使用回数とを対応付けてシーケンス情報記憶部536に記憶させる。図26は、本変形例に係る照合処理の手順を示すフローチャートである。尚、同図においては、ステップS140以前に行う処理については図示を省略している。ステップS140〜S141は第1の実施の形態と同様である。ステップS141の判定結果が肯定的である場合、即ち、リーチャ50から要求されている鍵束のシーケンスと同一のシーケンスを示すシーケンス情報がシーケンス情報記憶部536に既に記憶されている場合、当該シーケンス情報と、当該リーチャ50のリーチャ識別情報と対応付けられてシーケンス情報記憶部536に記憶されている使用回数を参照して、当該使用回数が所定回数以下であるか否かを判断する(ステップS140A)。当該判断結果が肯定的である場合、シーケンス情報照合部535は、当該シーケンス情報と、当該リーチャ識別情報と対応付けられてシーケンス情報記憶部536に記憶されている使用回数を1つインクリメントすることにより、当該使用回数を更新して(ステップS140B)、上述と同様のステップS143の処理を行う。また、ステップS141の判断結果が否定的である場合、シーケンス情報照合部535は、上述と同様にステップS142以降の処理を行う。尚、ステップS140Aの判断結果が否定的である場合は、シーケンス情報照合部535は、上述のステップS144と同様の処理を行う。
このような構成によれば、暗号化ピースにおける同一のシーケンスの使用を1回のみならず複数回許可することになり、より柔軟なコンテンツ配信を実現することができる。
<変形例3_4>
上述した各実施の形態においては、シーダ52がリーチャ50に送信するピース情報は、図7に示されるように、当該シーダ52が記憶している暗号化ピースのシーケンスを示すものであった。しかし、ピース情報は、シーダ52が記憶している暗号化ピースの各インデックス(i, j)のうち、各ピースC1〜CNを区別するためのインデックスjのみを示すものであっても良い。図27〜29は、本変形例にかかるピース情報を例示する図である。この場合、Torrent Fileに含まれるファイル情報は、例えば、上述の変形例1_1で説明したように、各暗号化ピースを用いてハッシュ演算により計算されるハッシュ値{ hash( E( K( i, j ) )[ Cj ] ) }(ただし、1≦i≦m、1≦j≦N)を含んでいるものとする(図17参照)。尚、以降、各ピースC1〜CNを区別するためのインデックスjについては、ピースインデックスと表記し、復号鍵の数に応じてバリエーションが生じるインデックスiについては、バリエーションインデックスと表記し、これらの組(i,j)を単にインデックスと表記する。また、ピースインデックスjに対応するピースについて、相異なる2つ以上の暗号鍵で各々暗号化された暗号化ピースが存在する場合これらの集合を暗号化ピース列jと適宜表記する。
このような構成において、リーチャ50のコンテンツ取得部500は、上述のようなピース情報に基づいて、暗号化ピースをシーダ52から取得すると、当該暗号化ピースについて、バリエーションインデックスjを特定する処理を行う。具体的には、コンテンツ取得部500は、当該暗号化ピースを用いてハッシュ演算によりハッシュ値を計算し、Torrent Fileに含まれるファイル情報を参照して、当該ハッシュ値に対応するインデックス(i, j)のうち、当該暗号化ピースのピースインデックスjに対応するバリエーションインデックスiを特定する。
図30は、本変形例にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順を示す図である。ステップS1〜S5は、上述の第1の実施の形態と同様である。ステップS6では、シーダ52は、リーチャ50からアクセスされると、例えば図27に示したように、自身の保持する暗号化ピースのピースインデックスを示すピース情報をリーチャ50へ送信し、ステップS7では、リーチャ50は、当該ピース情報を受信する。ステップS8では、リーチャ50は、当該ピース情報を用いて、少なくとも1つのシーダ52にアクセスして、各ピースC1〜CNに各々対応して複数存在しえる暗号化ピースのうち少なくとも1つを要求するピース要求を当該シーダ52に送信して、各暗号化ピースを受信する。シーダ52は、リーチャ50からのピース要求に応じて、自身の保持する暗号化ピースをリーチャ50に送信する(ステップS9)。ここでは、リーチャ50がシーダ52Bにアクセスして受信したピース情報に示されるインデックスには、バリエーションインデックスが含まれていない。このため、リーチャ50は、シーダ52Bにアクセスして受信したピース情報を用いて、例えば、ピースC1について暗号化された暗号化ピースE( K( i1, 1 ) )[ C1 ](i1は1≦i1≦mの整数)のうちいずれかの暗号化ピースをシーダ52Bが保持しているか否かを判断し、当該判断結果が肯定的である場合、当該シーダ52Bにアクセスして、ピースC1について暗号化された暗号化ピースのうちいずれかの暗号化ピースをシーダ52Bから受信することによりこれを取得する。尚、シーダ52BがピースC1について暗号化された暗号化ピースを実際には1つも保持していなかった場合、リーチャ50は、次いで、他のシーダ52(例えばシーダ52C)にアクセスして、当該他のシーダ52Cからピース情報を取得する。そして、リーチャ50は、上述と同様にして、ピース情報を用いて、当該暗号化ピースをシーダ52Cが保持しているか否かを判断して、当該判断結果が肯定的である場合、シーダ52にアクセスして、当該暗号化ピースの取得を試みる。
次いで、ステップS4001では、リーチャ50は、受信した暗号化ピースのハッシュ値を計算する。その後、ステップS4002では、リーチャ50は、図17に示したTorrent Fileを参照して、当該ハッシュ値に対応するインデックス(i, j)のうち、当該暗号化ピースのピースインデックスjに対応するバリエーションインデックスiを特定する。ステップS10以降は上述の第1の実施の形態又は第2の実施の形態と同様である。
以上のようにして、リーチャ50が暗号化ピースを受信する前に、シーダ52が記憶している暗号化ピースのバリエーションインデックスiを特定できないようにした場合、コンテンツの不正使用をより一層効果的に抑制することができる。リーチャ50が、例えばその復号鍵が漏洩したあるインデックス(i, j)に対応する暗号化ピースを取得しようとすることを抑制することができるからである。
<変形例3_5>
上述の変形例3_4においては、シーダ52は、リーチャ50へ暗号化ピースを送信する場合、ピース情報とは別に、当該暗号化ピースのバリエーションインデックスを示すバリエーションインデックス情報をリーチャ50へ送信するようにしても良い。この場合、リーチャ50は、上述のように、暗号化ピースのハッシュ値を計算する必要はない。このため、Torrent Fileに含まれるファイル情報は、各暗号化ピースのハッシュ値を含んでいなくても良い。図31は、本変形例にかかるコンテンツ配信処理の手順を示すフローチャートである。ステップS1〜S8は上述の変形例3_4と同様である。ステップS4003では、シーダ52は、リーチャ50へ送信する対象の暗号化ピースのバリエーションインデックスを示すバリエーションインデックス情報をリーチャ50へ送信し、ステップS4004で、リーチャ50は当該バリエーションインデックス情報を受信する。ステップS9〜S16は、上述の第1の実施の形態又は第2の実施の形態と同様である。尚、ステップS4003〜S4004は、ステップS9の後であっても構わない。
このような構成によれば、リーチャ50における暗号化ピースのバリエーションインデックスの特定を容易にしつつ、例えばその復号鍵が漏洩したあるインデックス(i, j)に対応する暗号化ピースを取得しようとすることを抑制することができる。
<変形例3_6>
上述した各実施の形態においては、リーチャ50は、1つの暗号化ピースを複数回に分けてシーダ52から受信するように構成しても良い。この場合、リーチャ50は、暗号化ピースについて、暗号化ピースの一部である部分データ(サブピースという)をシーダ52に要求するピース要求(一部データ要求という)を送信する。尚、各サブピースのデータ長は、一定の長さであっても良いし、可変長でも良い。また、暗号化ピースが何個のサブピースで構成されるかについては限定されず、一定の個数にしても良いし、可変にしても良い。また、各サブピースのデータ長や、1つの暗号化ピースを構成する全部のサブピースの個数は、コンテンツ配信システムに初期値として予め設定されるようにしても良いし、Torrent Fileにおいて予め示されるようにしても良い。尚、ここでは、Torrent Fileに含まれるファイル情報は、各暗号化ピースのデータ長を含むものとし、ハッシュ値を含んでいなくても良い。
図32は、本変形例にかかるリーチャ50の機能的構成を例示する図である。リーチャ50は、上述したコンテンツ取得部500と、鍵束要求部501と、鍵束取得部502と、コンテンツ復号部503とに加え、サブピース完成判定部504と、セッション情報管理部505とを有する。尚、リーチャ50は、暗号化ピースについてそのデータの全部を要求することも、サブピースを要求することもいずれも可能であるとする。前者については、上述の各実施の形態と略同様であるので、ここでは、後者について主に説明する。
本変形例にかかるコンテンツ取得部500は、ピース要求をシーダ52に送信する際に、取得対象の暗号化ピースについて、データの一部を取得済みであるか否かを判断し、データの一部を取得済みであると判断した場合、一部データ要求を生成してこれをシーダ52に送信する。一部データ要求は、例えば、取得対象である一部取得済み暗号化ピースを指定する指定ピースインデックス及び指定バリエーションインデックスの組(i,j)と、当該一部取得済み暗号化ピースの一部のデータであるサブピースを指定するサブピース指定情報とを示す。サブピース指定情報は、当該一部取得済み暗号化ピースの一部のデータ(サブピース)のデータ範囲を指定するものである。データ範囲は、例えば、当該サブピースの開始位置としてバイト数等で表されるオフセット値、当該サブピースの終了位置としてバイト数等で表されるオフセット値、当該サブピースのデータ長などやそれらの組み合わせなどを用いて指定される。図33は、本変形例にかかるピース要求のデータ構成を例示する図である。同図においては、一部データ要求として、指定ピースインデックス及び指定バリエーションインデックスの組と、サブピース指定情報として、サブピースの開始位置及びデータ長とが示されている。この一部データ要求は、インデックス(3,4)に対応する暗号化ピースE( K( 3, 4 ) )[C4]のデータのうち、先頭位置(0バイト目)から54677バイト目を開始位置とし、当該開始位置から54676バイトを有するデータ範囲のデータが取得対象のサブピースとして指定されていることが示されている。
尚、コンテンツ取得部500は、ピース要求をシーダ52に送信する際に、取得対象の暗号化ピースについて、データの全部を未取得であると判断した場合、上述の各実施の形態で説明したようなピース要求を生成してこれをシーダ52に送信する。
サブピース完成判定部504は、コンテンツ取得部500が暗号化ピース又はサブピースを受信した場合、当該暗号化ピース又は当該サブピースを一部とする暗号化ピースについて、その全部のデータを取得済みであるか否かを判定する完成判定処理を行う。この完成判定処理は、例えば、そのデータ長や、暗号化ピースにおけるデータの先頭位置や終了位置からデータ長を計算すること等により行う。ここでは、サブピース完成判定部504は、後述するセッション情報において示される取得済み量と、Torrent Fileに含まれるデータ長とを参照して、完成判定処理を行う。そして、サブピース完成判定部504は、判定対象の暗号化ピースについて、その全部のデータを取得済みであると判定した場合、当該暗号化ピースが複数のサブピースから構成されている場合には、当該暗号化ピースを構成する全てのサブピースを統合して、暗号化ピースを完成させる完成処理を行う。
また、サブピース完成判定部504は、判定対象の暗号化ピースについて、その全部のデータを取得済みでないと判定した場合、後述のセッション情報を参照して、当該暗号化ピースを構成するサブピースを送信したシーダ52にアクセスして、当該暗号化ピースを構成するサブピースのうち未だ取得していないサブピース(未取得サブピースという)を要求する一部データ要求を、コンテンツ取得部500を介してシーダ52に送信する。このようにして、サブピース完成判定部504は、コンテンツ取得部500を介して未取得サブピースの取得を試みる。例えば、サブピース完成判定部504は、当該暗号化ピースを構成するサブピース全て取得するまで、未取得サブピースをシーダ52から取得する処理を繰り返し行う。
セッション情報管理部505は、サブピースの送信元であるシーダ52に対して未取得サブピースを再度要求するために用いるセッション情報を生成してこれを記憶する。セッション情報は、例えば、シーダ特定情報と、取得済み量とを示す。シーダ特定情報とは、サブピースの送信元であるシーダ52を特定する情報である。シーダ特定情報としては、例えば、シーダ52のIPアドレスやポート番号や、シーダ52のMACアドレスや上述の加入者IDなどやこれらの組み合わせなどがある。取得済み量とは、暗号化ピースのうち取得済みのデータの数量を示す。取得済み量としては、例えば、暗号化ピースにおけるデータの先頭位置や取得済みのデータの終了位置から計算されるデータ長や、暗号化ピースを構成するサブピースのうち取得済みのサブピースのデータ長の合計や、当該取得済みのサブピースの個数などがある。
一方、シーダ52は、一部データ要求において要求されたサブピースを外部記憶装置から読み出してこれをリーチャ50に送信する。図33に示された一部データ要求を受信した場合は、シーダ52は、当該一部データ要求において示される指定ピースインデックス及び指定ピースインデックスに対応する暗号化ピースのうち、指定されたデータ範囲のデータを送信する。
図34は、本変形例にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順を示すフローチャートである。ステップS1〜S4の処理は、上述の各実施の形態と同様である。ステップS300では、リーチャ50は、暗号化ピースのダウンロード処理を行う。一方、シーダ52は、ステップS301で、暗号化ピースのアップロード処理を行う。図35は、ダウンロード処理及びアップロード処理の詳細な手順を示すフローチャートである。ステップS5〜S7の処理は、上述の各実施の形態と同様である。ステップS310では、リーチャ50は、ピース要求をシーダ52に送信する際に、取得対象の暗号化ピースについて、データの一部を取得済みであるか否かを判断する。データの一部を取得済みであると判断した場合(ステップS310:YES)、リーチャ50は、セッション情報のシーダ特定情報を参照して(ステップS313)、取得対象の暗号化ピースを構成するサブピースの送信元であるシーダ52を特定し、図32に示されるような一部データ要求をピース要求として生成して(ステップS314)、これを当該シーダ52に送信する(ステップS312)。尚、取得対象の暗号化ピースについて、データの全部を未取得であると判断した場合(ステップS310:NO)、リーチャ50は、上述の各実施形態で説明したピース要求を生成して(ステップS311)、これをシーダ52に送信する(ステップS312)。
一方、シーダ52は、ステップS312で送信されたピース要求を受信すると、当該ピース要求に応じた暗号化ピース又はサブピースを外部記憶装置から読み出してこれをリーチャ50に送信する(ステップS315)。リーチャ50は、暗号化ピース又はサブピースを受信すると(ステップS316)、セッション情報において取得済み量を更新する(ステップS317)。次いで、リーチャ50は、ピース要求が完了したか否かを判定する(ステップS318)。ここでは、リーチャ50は、ステップS312でサブピースを受信した場合には、当該サブピースから構成される暗号化ピースについて、セッション情報に示される取得済み量と、Torrent Fileに含まれるデータ長とを比較し、これらが一致する場合には、当該暗号化ピースについて、その全部のデータを取得済みであると判定し、ピース要求が完了したと判定する(ステップS318:YES)。そして、リーチャ50は、当該暗号化ピースを構成する全てのサブピースを統合して、暗号化ピースを完成させる完成処理を行う。次いで、リーチャ50は、他のシーダ52にアクセスして、他の暗号化ピースを受信するか否かを判断し(ステップS319)、当該判断結果が肯定的である場合には、ステップS5に戻り、他のシーダ52にアクセスする。ステップS319の判断結果が否定的である場合には、処理を終了する。
一方、ステップS318で、セッション情報に示される取得済み量と、Torrent Fileに含まれるデータ長とが一致する場合には、リーチャ50は、当該暗号化ピースについて、その全部のデータを取得済みでないと判定し、ピース要求が完了していないと判定する。この場合、リーチャ50は、ステップS5に戻り、セッション情報を参照して、当該暗号化ピースを構成するサブピースを送信したシーダ52に再度アクセスする。そして、以降の処理では、リーチャ50は、当該暗号化ピースを構成するサブピースのうち未取得サブピースを要求する一部データ要求を生成してこれをシーダ52に送信し、当該暗号化ピースを構成するサブピース全て取得するまで、未取得サブピースをシーダ52から取得する処理を繰り返し行う。
尚、リーチャ50がステップS311の後、ステップS316で暗号化ピースを受信する場合、何らかの原因で暗号化ピースのデータのうち全部を受信し切れない場合がある。この場合も、ステップS315でサブピースを受信した場合と同様に、ステップS318では、リーチャ50は、セッション情報に示される取得済み量と、Torrent Fileに含まれるデータ長とを比較することにより、ピース要求が完了したか否かを判定する。そして、ピース要求が完了していないと判定した場合、リーチャ50は、ステップS5に戻り、セッション情報を参照して、当該暗号化ピースを送信したシーダ52に再度アクセスする。そして、以降の処理では、リーチャ50は、当該暗号化ピースのうち未取得のデータ(未取得サブピースと同様に扱う)を要求する一部データ要求を生成してこれをシーダ52に送信する。以降は上述と同様である。一方、ステップS318で、リーチャ50は、一度の受信でピース要求が完了したと判定した場合、上述したステップS319の処理を行う。
そして、図34に戻り、リーチャ50は、コンテンツを構成する各ピースに各々対応する暗号化ピースであって暗号化コンテンツを構成する全ての暗号化ピースについて、全てのデータを取得すると、上述の第1の実施の形態又は第2の実施の形態と同様にして、ステップS10以降の処理を行う。
以上のように、リーチャ50が暗号化ピースを複数回に分けて各々サブピースとして取得する場合であっても、暗号化ピースの取得と同様にTorrent Fileを用いるため、当該Torrent Fileに含まれるバージョン情報を鍵サーバ53が照合し照合結果に応じて鍵束を送信することにより、コンテンツの不正使用をより効果的に抑制することができる。
尚、一部データ要求は、一部取得済み暗号化ピースを指定する指定ピースインデックス及び指定バリエーションインデックスの組(i,j)ではなく、指定ピースインデックスjを少なくとも示すようにしても良い。この場合、シーダ52は、一部データ要求を受信すると、当該一部取得済み暗号化ピースを指定する指定バリエーションインデックスと、サブピースを指定する情報とをリーチャ50に問い合わせることにより、これらの情報を取得して、送信対象のサブピースを特定して当該サブピースをリーチャ50に送信するようにしても良い。このような構成によれば、シーダ52に対する攻撃耐性が向上し得る。
<変形例3_7>
上述の第1の実施の形態又は第2の実施の形態の一部及び全部や各変形例を組み合わせても良い。
<変形例3_8>
上述した各実施の形態において、リーチャ50で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、当該各種プログラムを、インストール可能な形式又は実行可能な形式のファイルでCD−ROM、フレキシブルディスク(FD)、CD−R、DVD(Digital Versatile Disk)等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成しても良い。この場合には、プログラムは、リーチャ50において上記記録媒体から読み出して実行することにより主記憶装置(例えばRAM)上にロードされ、上記機能的構成において説明した各部が主記憶装置上に生成される。シーダ52において実現される各種プログラム、鍵サーバ53において実現される各種プログラム、トラッカ51において実現される各種プログラムについても同様である。
[他の態様の発明1]
前記情報取得手段は、前記ファイル情報と、当該ファイル情報が更新される度に更新される版を示す情報である前記版管理情報と取得する
ことを特徴とする請求項2に記載の通信装置。
[他の態様の発明2]
前記情報取得手段は、前記ファイル情報と、当該ファイ情報が生成された時刻を示す情報である前記版管理情報と取得する
ことを特徴とする請求項2に記載の通信装置。
[他の態様の発明3]
前記情報取得手段は、前記ファイル情報と、当該ファイル情報によって示される前記第1暗号化ピース及び前記第2暗号化ピースの全部又は一部を用いて所定の演算により計算される演算値である前記版管理情報と取得する
ことを特徴とする請求項2に記載の通信装置。
[他の態様の発明4]
前記情報取得手段は、
最新の前記ファイル情報を保持する販売サーバから前記ファイル情報を受信することにより取得する第1取得手段と、
前記ファイル情報によって示される前記第1暗号化ピース及び前記第2暗号化ピースの全部又は一部を用いて所定の演算により演算値を計算することにより、当該演算値である前記版管理情報を取得する第2取得手段とを有する
ことを特徴とする他の態様の発明3に記載の通信装置。
[他の態様の発明5]
前記情報取得手段は、前記管理サーバへアクセスするための第1アクセス情報と、前記ファイル情報と、前記版管理情報とを取得し、
前記第1受信手段は、取得された前記第1アクセス情報を用いて、前記管理サーバにアクセスして、前記ノード情報を受信し、
前記第2受信手段は、受信された前記ノード情報を用いて、前記他の通信装置にアクセスして、前記ファイル情報を用いて、前記第1暗号化ピース又は前記第2暗号化ピースを受信する
ことを特徴とする請求項7に記載の通信装置。
[他の態様の発明6]
更新された前記ファイル情報の取得を促す取得促進メッセージを前記管理サーバから受信する促進受信手段を更に備え、
前記情報取得手段は、前記取得促進メッセージに従い、更新された前記ファイル情報を少なくとも取得する
ことを特徴とする請求項7に記載の通信装置。
[他の態様の発明7]
前記第2記憶手段は、有効性を有する少なくとも1つ以上の前記ファイル情報の前記版管理情報を示す有効性情報及び有効性を有する前記ファイル情報の前記版管理情報の範囲を特定する有効性情報のうち少なくとも一方を記憶する
ことを特徴とする請求項14に記載の鍵サーバ。
[他の態様の発明8]
前記第2記憶手段は、少なくとも1つ以上の前記ファイル情報の前記版管理情報と、前記ファイル情報の有効期限を示す有効性情報とを対応付けて記憶し、
前記判断手段は、受信された前記版管理情報について、当該版管理情報と対応付けられて前記第2記憶手段に記憶されている前記有効性情報を参照して、有効期限内であるか否かを判断することにより、前記要求メッセージによって要求された前記各復号鍵が有効であるか否かを判断する
ことを特徴とする請求項13に記載の鍵サーバ。
[他の態様の発明9]
前記要求受信手段は、前記要求メッセージ及び各前記対応暗号化ピースのそれぞれについて前記版管理情報を受信し、
前記判断手段は、ピース毎の前記第1暗号化ピース又は前記第2暗号化ピースのそれぞれについて、前記版管理情報と、前記有効性情報とを照合することにより、前記要求メッセージによって要求された前記各復号鍵が有効であるか否かを各々判断し、
前記決定手段は、前記各復号鍵が全て有効であると判断された場合、前記要求メッセージによって要求された前記各復号鍵の組み合わせに基づいて、当該各復号鍵を送信するか否かを決定する
ことを特徴とする請求項13に記載の鍵サーバ。
[他の態様の発明10]
前記第2記憶手段は、ピース毎の前記第1暗号化ピース又は前記第2暗号化ピースのうち少なくとも2つ以上のピースに各々対応する前記第1暗号化ピース又は前記第2暗号化ピースを用いて所定の演算により計算される演算値である前記保持証明情報を記憶し、
前記保持証明判断手段は、受信された前記演算値と、記憶された前記演算値とを用いて、前記要求メッセージによって要求された前記各復号鍵によって復号されるピース毎の前記第1暗号化ピース又は前記第2暗号化ピースを前記通信装置が保持しているか否かを判断する
ことを特徴とする請求項18に記載の鍵サーバ。
[他の態様の発明11]
前記第2記憶手段は、前記第1暗号化ピース及び前記第2暗号化ピースの全部又は一部を記憶し、
前記保持証明判断手段は、
前記第2記憶手段に記憶された前記第1暗号化ピース及び前記第2暗号化ピースの全部又は一部のうち、前記少なくとも2つ以上のピースに各々対応する前記第1暗号化ピース又は前記第2暗号化ピースを用いて所定の演算により演算値を計算する計算手段と、
受信された前記演算値と、記憶された前記演算値とを用いて、前記要求メッセージによって要求された前記各復号鍵によって復号されるピース毎の前記第1暗号化ピース又は前記第2暗号化ピースを前記通信装置が保持しているか否かを判断する判断手段とを有する
ことを特徴とする請求項18に記載の鍵サーバ。
[他の態様の発明12]
前記情報取得手段は、前記ファイル情報が更新される度に更新される版を示す情報である前記版管理情報を取得し、
前記分類手段は、前記版管理情報によって示されるものが同一又は所定範囲にある前記ファイル情報を有するものが同一のグループに属するように、前記通信装置及び前記他の通信装置のうち少なくとも一方をグループ分けする
ことを特徴とする請求項22に記載の管理サーバ。
[他の態様の発明13]
前記情報取得手段は、前記ファイ情報が生成された時刻を示す情報である前記版管理情報を取得し、
前記分類手段は、前記版管理情報によって示されるものが同一又は所定範囲にある前記ファイル情報を有するものが同一のグループに属するように、前記通信装置及び前記他の通信装置のうち少なくとも一方をグループ分けする
ことを特徴とする請求項22に記載の管理サーバ。
[他の態様の発明14]
前記情報取得手段は、前記ファイル情報によって示される前記第1暗号化ピース及び前記第2暗号化ピースの全部又は一部を用いて所定の演算により計算される演算値である前記版管理情報を取得し、
前記分類手段は、前記版管理情報によって示されるものが同一又は所定範囲にある前記ファイル情報を有するものが同一のグループに属するように、前記通信装置及び前記他の通信装置のうち少なくとも一方をグループ分けする
ことを特徴とする請求項22に記載の管理サーバ。
[他の態様の発明15]
前記ファイル情報が更新され且つ当該ファイル情報に対応付けられる前記第1アクセス情報が変更された場合、前記接続先情報の送信の停止を要求する停止要求メッセージを外部装置から受信する受信手段を備え、
前記情報送信手段は、前記停止要求メッセージが受信された場合、当該管理サーバにアクセスした前記通信装置に対して、前記接続先情報を送信せずに、更新された前記ファイル情報の取得を促す取得促進メッセージを送信する
ことを特徴とする請求項21に記載の管理サーバ。
第1の実施の形態にかかるコンテンツ配信システムの基本的構成を示すブロック図である。 コンテンツが複数のピースに分割された状態を模式的に示す図である。 各暗号化ピースを模式的に示す図である。 シーダ52Aが記憶している各暗号化ピースを例示する図である。 シーダ52Aが記憶している各暗号化ピースを例示する図である。 シーダ52Aが記憶している各暗号化ピースを例示する図である。 ピース情報のデータ構成を例示する図である。 リーチャ50の基本的な機能的構成を例示する図である。 基本的なTorrent Fileを例示する図である。 鍵サーバ53の基本的な機能的構成を例示する図である。 ノード情報のデータ構成を例示する図である。 コンテンツ配信処理の基本的な手順を示すフローチャートである。 照合処理の基本的な手順を示すフローチャートである。 同実施形態にかかるTorrent Fileのデータ構成を例示する図である。 本構成における鍵サーバ53の機能的構成を例示する図である。 同実施の形態にかかる照合処理の手順を示すフローチャートである。 同実施の形態の一変形例にかかるTorrent Fileのデータ構成を例示する図である。 同実施の形態の一変形例にかかるハッシュ値を含むインデックス情報を例示する図である。 同実施の形態の一変形例にかかるTorrent Fileを例示する図である。 同実施の形態の一変形例にかかるリーチャ50の機能的構成を例示する図である。 同実施の形態の一変形例にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順示すフローチャートである。 第2の実施の形態にかかるリーチャ50の機能的構成を例示する図である。 同実施の形態にかかる鍵サーバ53の機能的構成を例示する図である。 同実施の形態にかかる照合処理の手順を示すフローチャートである。 一変形例にかかる鍵サーバの構成を例示する図である。 一変形例にかかる照合処理の手順を示すフローチャートである。 一変形例にかかるピース情報を例示する図である。 同変形例にかかるピース情報を例示する図である。 同変形例にかかるピース情報を例示する図である。 同変形例にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順を示す図である。 一変形例にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順を示す図である。 一変形例にかかるリーチャ50の機能的構成を例示する図である。 同変形例にかかるピース要求のデータ構成を例示する図である。 同変形例にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順を示すフローチャートである。 同変形例にかかるダウンロード処理及びアップロード処理の詳細な手順を示すフローチャートである。
符号の説明
50,50A,50B リーチャ(通信装置)
51 トラッカ(管理サーバ)
52,52A,52B,52C シーダ(通信装置)
53 鍵サーバ
54 販売サーバ
500 コンテンツ取得部(コンテンツ受信手段)
500a 有効性判断部
501 鍵束要求部(送信手段)
502 鍵束取得部(鍵受信手段)
503 コンテンツ復号部(復号手段)
504 サブピース完成判定部
505 セッション情報管理部
506 保持証明部
530 制御部
531 パケット処理部
532 ネットワークインターフェース部(受信手段、送信手段)
533 認証・鍵交換処理部
534 鍵記憶部(第1記憶手段)
535 シーケンス情報照合部(決定手段)
536 シーケンス情報記憶部(第2記憶手段)
537 鍵供給部(送信手段)
538 暗号処理部
539 有効性判断部
540 Torrent File有効性情報記憶部
541 保持証明判断部
542 保持判断情報記憶部
NT P2Pネットワーク

Claims (25)

  1. コンテンツの一部である複数のピースを受信する通信装置であって、
    複数の第1暗号化ピースは、前記複数のピースを第1暗号鍵で暗号化することによって生成されるものであって、
    第2暗号化ピースは、前記複数のピースのうち1つ以上のピースを第2暗号鍵で暗号化することによって生成されるものであって、
    同一のピースを暗号化するための前記第1暗号鍵と前記第2暗号鍵とは異なっていて、
    前記第1暗号化ピース及び前記第2暗号化ピースの全部又は一部を示すファイル情報と、当該ファイル情報の有効性の有無を判断可能な版管理情報とを取得する情報取得手段と、
    他の通信装置から、前記ファイル情報を用いて、前記第1暗号化ピース又は前記第2暗号化ピースをピース毎に受信するコンテンツ受信手段と、
    前記コンテンツ受信手段がピース毎に受信した前記第1暗号化ピース又は前記第2暗号化ピースを復号するための各復号鍵を要求する要求メッセージと当該各対応暗号化ピースの取得に用いた前記ファイル情報の前記版管理情報とを鍵サーバへ送信する送信手段と、
    前記要求メッセージに従った前記鍵サーバから前記各復号鍵を受信する鍵受信手段とを備える
    ことを特徴とする通信装置。
  2. 前記情報取得手段は、所定又は任意のタイミングで更新される前記ファイル情報と、前記版管理情報とを取得する
    ことを特徴とする請求項1に記載の通信装置。
  3. 前記コンテンツ受信手段は、
    前記他の通信装置が保持する前記第1暗号化ピース又は前記第2暗号化ピースの取得に用いられた前記ファイル情報の前記版管理情報を取得する第3取得手段と、
    前記情報取得手段が取得した前記版管理情報と前記第3取得手段が取得した前記版管理情報とを用いて、前記他の通信装置から前記第1暗号化ピース又は前記第2暗号化ピースを取得するか否かを判断する判断手段と、
    前記判断手段の判断結果に応じて、前記他の通信装置に対して前記第1暗号化ピース又は前記第2暗号化ピースを要求する要求手段とを有する
    ことを特徴とする請求項1又は2に記載の通信装置。
  4. 前記情報取得手段は、前記ファイル情報と、有効性を有する前記ファイル情報の前記版管理情報を示す有効性情報及び有効性を有する前記ファイル情報の前記版管理情報の範囲を特定する有効性情報のうち少なくとも一方とを取得し、
    前記判断手段は、前記情報取得手段が取得した前記版管理情報及び前記有効性情報と前記第3取得手段が取得した前記版管理情報とを用いて、前記他の通信装置から前記第1暗号化ピース又は前記第2暗号化ピースを取得するか否かを判断する
    ことを特徴とする請求項1乃至3のいずれか一項に記載の通信装置。
  5. 前記情報取得手段は、前記ファイル情報と、前記版管理情報と、前記ファイル情報の有効期限を示す有効性情報とを取得し、当該有効性情報によって示される有効期限に基づいて、更新された前記ファイル情報を少なくとも取得する
    ことを特徴とする請求項1乃至4のいずれか一項に記載の通信装置。
  6. 前記通信装置は、少なくとも1つ以上のグループに属するようにグループ分けされており、
    前記ファイル情報によって示される前記第1暗号化ピース及び前記第2暗号化ピースの全部又は一部は前記グループ毎に異なり、
    前記情報取得手段は、前記通信装置の属する前記グループに対応する前記ファイル情報と、当該ファイル情報の有効性の有無を判断可能な版管理情報とを取得する
    ことを特徴とする請求項1乃至5のいずれか一項に記載の通信装置。
  7. 前記コンテンツ受信手段は、
    前記第1暗号化ピース又は前記第2暗号化ピースを記憶する他の通信装置にアクセスするためのノード情報を管理サーバから受信する第1受信手段と、
    受信された前記ノード情報を用いて、前記他の通信装置にアクセスして、前記第1暗号化ピース又は前記第2暗号化ピースを受信する第2受信手段とを有する
    ことを特徴とする請求項1乃至6のいずれか一項に記載の通信装置。
  8. 前記送信手段は、前記要求メッセージに前記版管理情報を含めて、前記鍵サーバに送信する
    ことを特徴とする請求項1乃至7のいずれか一項に記載の通信装置。
  9. 受信された前記各復号鍵を用いて、各前記対応暗号化ピースを各々復号する復号手段を更に備える
    ことを特徴とする請求項1乃至8のいずれか一項に記載の通信装置。
  10. コンテンツの一部である複数のピースを受信する通信装置であって、
    複数の第1暗号化ピースは、前記複数のピースを第1暗号鍵で暗号化することによって生成されるものであって、
    第2暗号化ピースは、前記複数のピースのうち1つ以上のピースを第2暗号鍵で暗号化することによって生成されるものであって、
    同一のピースを暗号化するための前記第1暗号鍵と前記第2暗号鍵とは異なっていて、
    他の通信装置から、前記第1暗号化ピース又は前記第2暗号化ピースをピース毎に受信するコンテンツ受信手段と、
    前記コンテンツ受信手段がピース毎に受信した前記第1暗号化ピース又は前記第2暗号化ピースを復号するための各復号鍵を要求する要求メッセージを、当該各復号鍵を記憶する鍵サーバに送信する鍵要求送信手段と、
    前記要求メッセージによって要求された各復号鍵によって復号されるピース毎の前記第1暗号化ピース又は前記第2暗号化ピースを保持していることを証明するための保持証明情報を要求する情報要求メッセージを前記鍵サーバから受信する要求受信手段と、
    前記情報要求メッセージに従って前記保持証明情報を前記鍵サーバに送信する情報送信手段と、
    前記保持証明情報及び前記情報要求メッセージに基づいて前記鍵サーバから前記各復号鍵のうち全部又は一部を受信する鍵受信手段とを備える
    ことを特徴とする通信装置。
  11. 前記要求受信手段は、前記要求メッセージによって要求した各復号鍵によって復号されるピース毎の前記第1暗号化ピース又は前記第2暗号化ピースのうち少なくとも2つ以上のピースに各々対応する前記第1暗号化ピース又は前記第2暗号化ピースを用いて所定の演算により計算される演算値である前記保持証明情報を要求する情報要求メッセージを前記鍵サーバから受信し、
    前記情報送信手段は、
    前記演算値要求メッセージに従って前記少なくとも2つ以上のピースに各々対応する前記第1暗号化ピース又は前記第2暗号化ピースを用いて所定の演算により演算値を計算する計算手段と、
    計算された前記演算値を前記鍵サーバに送信する演算値送信手段と有する
    ことを特徴とする請求項10に記載の通信装置。
  12. 前記要求受信手段は、前記要求メッセージによって要求された各復号鍵によって復号されるピース毎の前記第1暗号化ピース又は前記第2暗号化ピースのうち少なくとも2つ以上のピースに各々対応する前記第1暗号化ピース又は前記第2暗号化ピースを連結したデータの全部又は一部である前記保持証明情報を要求する演算値要求メッセージを前記鍵サーバから受信し、
    前記情報送信手段は、前記情報要求メッセージに従って前記少なくとも2つ以上のピースに各々対応する前記第1暗号化ピース又は前記第2暗号化ピースを連結することによりデータを生成する連結手段と、
    前記データの全部又は一部を前記鍵サーバに送信するデータ送信手段とを有する
    ことを特徴とする請求項10に記載の通信装置。
  13. コンテンツの一部である複数のピースを受信する通信装置と通信する鍵サーバであって、
    複数の第1暗号化ピースは、前記複数のピースを第1暗号鍵で暗号化することによって生成されるものであって、
    第2暗号化ピースは、前記複数のピースのうち1つ以上のピースを第2暗号鍵で暗号化することによって生成されるものであって、
    同一のピースを暗号化するための前記第1暗号鍵と前記第2暗号鍵とは異なっていて、
    前記通信装置は、他の通信装置から、前記第1暗号化ピース又は前記第2暗号化ピースをピース毎に受信するものであって、
    前記通信装置から、ピース毎の前記第1暗号化ピース又は前記第2暗号化ピースを復号するための各復号鍵を要求する要求メッセージと前記第1暗号化ピース又は前記第2暗号化ピースの取得に用いられた前記ファイル情報の有効性の有無を判断可能な版管理情報とを受信する要求受信手段と、
    前記各復号鍵を記憶する第1記憶手段と、
    有効性を有する前記ファイル情報の前記版管理情報を特定するための有効性情報を記憶する第2記憶手段と、
    受信された前記版管理情報と、前記有効性情報とを用いて、前記要求メッセージによって要求された前記各復号鍵が有効であるか否かを判断する判断手段と、
    前記判断手段の判断結果が肯定的である場合、前記要求メッセージによって要求された前記各復号鍵の組み合わせに基づいて、当該各復号鍵を送信するか否かを決定する決定手段と、
    前記決定手段の決定結果が肯定的である場合、前記要求メッセージによって要求された前記組み合わせにおける前記各復号鍵を前記第1記憶手段から各々読み出してこれらを前記通信装置に送信する鍵送信手段とを備える
    ことを特徴とする鍵サーバ。
  14. 前記第2記憶手段は、有効性を有する前記ファイル情報の版を示す情報である前記版管理情報を示す前記有効性情報を記憶する
    ことを特徴とする請求項13に記載の鍵サーバ。
  15. 前記第2記憶手段は、有効性を有する前記ファイル情報が生成された時刻を示す情報である前記版管理情報を示す前記有効性情報を記憶する
    ことを特徴とする請求項13に記載の鍵サーバ。
  16. 前記第2記憶手段は、有効性を有する前記ファイル情報によって示される前記第1暗号化ピース又は前記第2暗号化ピースの全部又は一部を用いて所定の演算により計算される演算値である前記版管理情報を示す前記有効性情報を記憶する
    ことを特徴とする請求項13に記載の鍵サーバ。
  17. コンテンツの一部である複数のピースを受信する通信装置と通信する鍵サーバであって、
    複数の第1暗号化ピースは、前記複数のピースを第1暗号鍵で暗号化することによって生成されるものであって、
    第2暗号化ピースは、前記複数のピースのうち1つ以上のピースを第2暗号鍵で暗号化することによって生成されるものであって、
    同一のピースを暗号化するための前記第1暗号鍵と前記第2暗号鍵とは異なっていて、
    前記通信装置は、他の通信装置から、前記第1暗号化ピース又は前記第2暗号化ピースをピース毎に受信するものであって、
    前記通信装置から、ピース毎の前記第1暗号化ピース又は前記第2暗号化ピースを復号するための各復号鍵を要求する要求メッセージを受信する要求受信手段と、
    前記各復号鍵を記憶する第1記憶手段と、
    前記要求メッセージによって要求された前記各復号鍵によって復号されるピース毎の前記第1暗号化ピース又は前記第2暗号化ピースを前記通信装置が保持しているか否かを判断するための保持判断情報を記憶する第2記憶手段と、
    前記要求メッセージによって要求された各復号鍵によって復号されるピース毎の前記第1暗号化ピース又は前記第2暗号化ピースを保持していることを証明するための保持証明情報を要求する情報要求メッセージを前記通信装置に送信する要求送信手段と、
    前記保持証明情報を前記通信装置から受信する情報受信手段と、
    受信された前記保持証明情報と、記憶された前記保持判断情報とを用いて、前記要求メッセージによって要求された前記各復号鍵によって復号されるピース毎の前記第1暗号化ピース又は前記第2暗号化ピースを前記通信装置が保持しているか否かを判断する保持証明判断手段と、
    前記判断手段の判断結果が肯定的である場合、前記要求メッセージによって要求された前記各復号鍵の組み合わせに基づいて、当該各復号鍵を送信するか否かを決定する決定手段と、
    前記決定手段の決定結果が肯定的である場合、前記要求メッセージによって要求された前記組み合わせにおける前記各復号鍵を前記第1記憶手段から各々読み出してこれらを前記通信装置に送信する鍵送信手段とを備える
    ことを特徴とする鍵サーバ。
  18. 前記要求送信手段は、
    前記要求メッセージによって要求された各復号鍵によって復号されるピース毎の前記第1暗号化ピース又は前記第2暗号化ピースのうち少なくとも2つ以上のピースに各々対応する前記第1暗号化ピース又は前記第2暗号化ピースを選択する選択手段と、
    前記少なくとも2つ以上の対応暗号化ピースを用いて所定の演算により計算される演算値である前記保持証明情報を要求する情報要求メッセージを前記通信装置に送信する第1送信手段とを有し、
    前記情報受信手段は、前記情報要求メッセージに従って前記少なくとも2つ以上のピースに各々対応する前記第1暗号化ピース又は前記第2暗号化ピースを用いて所定の演算により計算された演算値である前記保持証明情報を前記通信装置から受信する
    ことを特徴とする請求項17に記載の鍵サーバ。
  19. 前記第2記憶手段は、前記第1暗号化ピース及び前記第2暗号化ピースの全部又は一部を記憶し、
    前記要求送信手段は、前記要求メッセージによって要求された各復号鍵によって復号されるピース毎の前記第1暗号化ピース又は前記第2暗号化ピースのうち少なくとも2つ以上のピースに各々対応する前記第1暗号化ピース又は前記第2暗号化ピースを連結したデータの全部又は一部である前記保持証明情報を要求する情報要求メッセージを前記通信装置に送信し、
    前記情報受信手段は、前記情報要求メッセージに従って前記少なくとも2つ以上のピースに各々対応する前記第1暗号化ピース又は前記第2暗号化ピースが連結されたデータの全部又は一部である前記保持証明情報を前記通信装置から受信し、
    前記保持証明判断手段は、受信された前記データと、前記第2記憶手段に記憶された前記第1暗号化ピース及び前記第2暗号化ピースの全部又は一部のうち、前記少なくとも2つ以上のピースに各々対応する前記第1暗号化ピース又は前記第2暗号化ピースを連結したデータとを用いて、前記要求メッセージによって要求された前記各復号鍵によって復号される前記対応暗号化ピースを前記通信装置が保持しているか否かを判断する
    ことを特徴とする請求項17に記載の鍵サーバ。
  20. 前記各ピースに対応して既に送信した前記各復号鍵の組み合わせを示すシーケンス情報を記憶する第2記憶手段を備え、
    前記決定手段は、前記各復号鍵が全て有効であると判断された場合、前記要求メッセージによって要求された前記各復号鍵の組み合わせを示すシーケンス情報が、前記第2記憶手段に記憶されているか否かを判断することにより、当該各復号鍵を送信するか否かを決定する
    ことを特徴とする請求項17乃至19のいずれか一項に記載の鍵サーバ。
  21. コンテンツの一部である複数のピースを受信する通信装置と通信する管理サーバであって、
    複数の第1暗号化ピースは、前記複数のピースを第1暗号鍵で暗号化することによって生成されるものであって、
    第2暗号化ピースは、前記複数のピースのうち1つ以上のピースを第2暗号鍵で暗号化することによって生成されるものであって、
    同一のピースを暗号化するための前記第1暗号鍵と前記第2暗号鍵とは異なっていて、
    ファイル情報は、前記第1暗号化ピース及び前記第2暗号化ピースの全部又は一部を示し且つ当該ファイル情報の有効性の有無を判断可能な版管理情報が対応付けられるものであり、
    前記通信装置は、他の通信装置から、前記ファイル情報を用いて、前記第1暗号化ピース又は前記第2暗号化ピースをピース毎に受信するものであって、
    前記他の通信装置にアクセスするための接続先情報を記憶する第1記憶手段と、
    前記通信装置が、前記ファイル情報と対応付けられ且つ当該管理サーバへアクセスするための第1アクセス情報を用いて当該管理サーバにアクセスした場合、前記他の通信装置にアクセスするための前記接続先情報を送信する情報送信手段とを備える
    ことを特徴とする管理サーバ。
  22. 前記通信装置が有する前記ファイル情報の前記版管理情報を取得する情報取得手段を更に備え、
    前記情報送信手段は、
    前記版管理情報を用いて、前記通信装置及び前記他の通信装置のうち少なくとも一方をグループ分けする分類手段と、
    前記通信装置と同じグループに属する前記他の通信装置にアクセスするための前記接続先情報を送信する送信手段とを有する
    ことを特徴とする請求項21に記載の管理サーバ。
  23. 前記情報送信手段は、
    前記通信装置及び前記他の通信装置のうち少なくとも一方が、少なくとも1つ以上のグループに属し且つグループ毎に前記ファイル情報によって示される前記第1暗号化ピース及び前記第2暗号化ピースの全部又は一部が異なるようにグループ分けする分類手段と、
    前記通信装置と同一のグループに属する前記他の通信装置にアクセスするための接続先情報を前記第1記憶手段から読み出してこれを送信する送信手段とを有する
    ことを特徴とする請求項21に記載の管理サーバ。
  24. 前記ファイル情報が更新され且つ当該ファイル情報に対応付けられる前記第1アクセス情報が変更された場合、前記接続先情報の送信の停止を要求する停止要求メッセージを外部装置から受信する受信手段を備え、
    前記情報送信手段は、前記停止要求メッセージが受信された場合、当該管理サーバにアクセスした前記通信装置に対して前記接続先情報を送信しない
    ことを特徴とする請求項21乃至23のいずれか一項に記載の管理サーバ。
  25. 前記ファイル情報が更新され且つ当該ファイル情報に対応付けられる前記第1アクセス情報が変更された場合、前記接続先情報の送信の停止を要求する停止要求メッセージと、前記接続先情報を送信しない対象となる前記通信装置を識別するための通信装置識別情報を対応付けて示すリスト情報とを外部装置から受信する受信手段と、
    当該管理サーバにアクセスした前記通信装置から当該通信装置を識別するための前記通信装置識別情報を取得する取得手段とを備え、
    前記情報送信手段は、前記停止要求メッセージ及び前記リスト情報が受信された場合、当該管理サーバにアクセスした前記通信装置のうち前記リスト情報に前記通信装置識別情報が示されている通信装置に対して前記接続先情報を送信しない
    ことを特徴とする請求項21乃至23のいずれか一項に記載の管理サーバ。
JP2008181885A 2008-07-11 2008-07-11 通信装置、鍵サーバ及び管理サーバ Pending JP2010021888A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2008181885A JP2010021888A (ja) 2008-07-11 2008-07-11 通信装置、鍵サーバ及び管理サーバ
US12/368,674 US20100008509A1 (en) 2008-07-11 2009-02-10 Communication apparatus, key server, and management server

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008181885A JP2010021888A (ja) 2008-07-11 2008-07-11 通信装置、鍵サーバ及び管理サーバ

Publications (1)

Publication Number Publication Date
JP2010021888A true JP2010021888A (ja) 2010-01-28

Family

ID=41505186

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008181885A Pending JP2010021888A (ja) 2008-07-11 2008-07-11 通信装置、鍵サーバ及び管理サーバ

Country Status (2)

Country Link
US (1) US20100008509A1 (ja)
JP (1) JP2010021888A (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012248135A (ja) * 2011-05-31 2012-12-13 Sony Corp 情報処理装置、および情報処理方法、並びにプログラム
JP2014121076A (ja) * 2012-12-19 2014-06-30 Toshiba Corp 鍵管理装置、通信装置、通信システムおよびプログラム

Families Citing this family (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5395372B2 (ja) * 2008-06-19 2014-01-22 株式会社東芝 通信装置、鍵サーバ及びデータ
US8204915B2 (en) * 2009-02-13 2012-06-19 Alcatel Lucent Apparatus and method for generating a database that maps metadata to P2P content
EP2517436B1 (fr) * 2009-12-22 2019-12-18 Orange Communication pair à pair en fonction de la capacité de transmission
US9081888B2 (en) 2010-03-31 2015-07-14 Cloudera, Inc. Collecting and aggregating log data with fault tolerance
US8874526B2 (en) 2010-03-31 2014-10-28 Cloudera, Inc. Dynamically processing an event using an extensible data model
US9082127B2 (en) 2010-03-31 2015-07-14 Cloudera, Inc. Collecting and aggregating datasets for analysis
US9317572B2 (en) 2010-03-31 2016-04-19 Cloudera, Inc. Configuring a system to collect and aggregate datasets
JP2012084071A (ja) 2010-10-14 2012-04-26 Toshiba Corp デジタルコンテンツの保護方法、復号方法、再生装置、記憶媒体、暗号装置
US8788815B1 (en) * 2011-01-31 2014-07-22 Gazzang, Inc. System and method for controlling access to decrypted data
US8880592B2 (en) 2011-03-31 2014-11-04 Cloudera, Inc. User interface implementation for partial display update
TWI459230B (zh) 2011-08-08 2014-11-01 Ind Tech Res Inst 數位版權管理裝置及數位版權管理方法
US8661527B2 (en) 2011-08-31 2014-02-25 Kabushiki Kaisha Toshiba Authenticator, authenticatee and authentication method
US9577824B2 (en) * 2011-09-23 2017-02-21 CSC Holdings, LLC Delivering a content item from a server to a device
JP5275432B2 (ja) 2011-11-11 2013-08-28 株式会社東芝 ストレージメディア、ホスト装置、メモリ装置、及びシステム
JP5100884B1 (ja) 2011-12-02 2012-12-19 株式会社東芝 メモリ装置
JP5204291B1 (ja) 2011-12-02 2013-06-05 株式会社東芝 ホスト装置、装置、システム
JP5204290B1 (ja) 2011-12-02 2013-06-05 株式会社東芝 ホスト装置、システム、及び装置
JP5112555B1 (ja) 2011-12-02 2013-01-09 株式会社東芝 メモリカード、ストレージメディア、及びコントローラ
US8639928B2 (en) 2011-12-05 2014-01-28 Certicom Corp. System and method for mounting encrypted data based on availability of a key on a network
TWI475879B (zh) * 2011-12-06 2015-03-01 Ind Tech Res Inst 數位版權管理物件之加密/解密方法、數位版權管理物件加密/解密裝置
JP5275482B2 (ja) 2012-01-16 2013-08-28 株式会社東芝 ストレージメディア、ホスト装置、メモリ装置、及びシステム
US9128949B2 (en) 2012-01-18 2015-09-08 Cloudera, Inc. Memory allocation buffer for reduction of heap fragmentation
US9172608B2 (en) 2012-02-07 2015-10-27 Cloudera, Inc. Centralized configuration and monitoring of a distributed computing cluster
CN103248645B (zh) * 2012-02-08 2018-03-16 深圳市腾讯计算机系统有限公司 Bt离线数据下载系统及方法
US9405692B2 (en) 2012-03-21 2016-08-02 Cloudera, Inc. Data processing performance enhancement in a distributed file system
US8856930B2 (en) * 2012-03-30 2014-10-07 F-Secure Corporation Download control
US9338008B1 (en) 2012-04-02 2016-05-10 Cloudera, Inc. System and method for secure release of secret information over a network
US9842126B2 (en) 2012-04-20 2017-12-12 Cloudera, Inc. Automatic repair of corrupt HBases
JP5973808B2 (ja) * 2012-07-03 2016-08-23 フェリカネットワークス株式会社 情報処理装置、端末装置、情報処理システム、情報処理方法およびコンピュータプログラム
US9753954B2 (en) 2012-09-14 2017-09-05 Cloudera, Inc. Data node fencing in a distributed file system
JP6018511B2 (ja) * 2013-01-31 2016-11-02 株式会社東芝 サーバ装置、グループ鍵通知方法及びそのプログラム
US9201811B2 (en) 2013-02-14 2015-12-01 Kabushiki Kaisha Toshiba Device and authentication method therefor
US8984294B2 (en) 2013-02-15 2015-03-17 Kabushiki Kaisha Toshiba System of authenticating an individual memory device via reading data including prohibited data and readable data
US9342557B2 (en) 2013-03-13 2016-05-17 Cloudera, Inc. Low latency query engine for Apache Hadoop
US9977877B2 (en) * 2013-03-19 2018-05-22 Ip Squared Technologies Holding, Llc System and method for terminating copyright infringement by BitTorrent users
US9477731B2 (en) 2013-10-01 2016-10-25 Cloudera, Inc. Background format optimization for enhanced SQL-like queries in Hadoop
US9934382B2 (en) 2013-10-28 2018-04-03 Cloudera, Inc. Virtual machine image encryption
US9690671B2 (en) 2013-11-01 2017-06-27 Cloudera, Inc. Manifest-based snapshots in distributed computing environments
US9154471B2 (en) 2013-11-26 2015-10-06 At&T Intellectual Property I, L.P. Method and apparatus for unified encrypted messaging
US10171635B2 (en) 2013-12-04 2019-01-01 Cloudera, Inc. Ensuring properly ordered events in a distributed computing environment
US9209971B2 (en) 2014-01-21 2015-12-08 Cofactor Computing Llc Method and system for shielding data in untrusted environments
US9336363B2 (en) * 2014-01-21 2016-05-10 Cofactor Computing Llc Method and system for secure deployment of information technology (IT) solutions in untrusted environments
US9460302B2 (en) 2014-01-21 2016-10-04 Cofactor Computing Llc Method and system for shielding data in transit and data in memory
US9325672B2 (en) * 2014-04-25 2016-04-26 Cellco Partnership Digital encryption shredder and document cube rebuilder
US9747333B2 (en) 2014-10-08 2017-08-29 Cloudera, Inc. Querying operating system state on multiple machines declaratively
US10120904B2 (en) 2014-12-31 2018-11-06 Cloudera, Inc. Resource management in a distributed computing environment
US9992175B2 (en) * 2016-01-08 2018-06-05 Moneygram International, Inc. Systems and method for providing a data security service
CN107181774B (zh) * 2016-03-09 2020-11-20 伊姆西Ip控股有限责任公司 分布式数据中心之间的数据移动
US11212667B2 (en) * 2017-03-09 2021-12-28 Lg Electronics Inc. Method for transferring user equipment capability and apparatus for supporting same
CN108683747B (zh) 2018-06-11 2020-11-27 华为技术有限公司 资源获取、分发、下载方法、装置、设备及存储介质
US10929402B1 (en) * 2018-08-10 2021-02-23 Amazon Technologies, Inc. Secure join protocol in encrypted databases
US10911337B1 (en) * 2018-10-10 2021-02-02 Benjamin Thaddeus De Kosnik Network activity monitoring service

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000057595A1 (en) * 1999-03-22 2000-09-28 Kent Ridge Digital Labs Method and apparatus for encrypting and decrypting data
DE60140125D1 (de) * 2000-08-11 2009-11-19 Nds Ltd Ertragenem inhalt
US7076067B2 (en) * 2001-02-21 2006-07-11 Rpk New Zealand Limited Encrypted media key management
US7146009B2 (en) * 2002-02-05 2006-12-05 Surety, Llc Secure electronic messaging system requiring key retrieval for deriving decryption keys
JP2004088619A (ja) * 2002-08-28 2004-03-18 Sony Corp 符号列暗号化方法、装置および暗号解除方法、装置および記録媒体
US7346769B2 (en) * 2003-10-23 2008-03-18 International Business Machines Corporation Method for selective encryption within documents
US20060075225A1 (en) * 2004-06-30 2006-04-06 Flynn James P Digital content protection for peer to peer networks
US7165050B2 (en) * 2004-09-20 2007-01-16 Aaron Marking Media on demand via peering
JP4887682B2 (ja) * 2005-08-05 2012-02-29 日本電気株式会社 通信システム、鍵管理・配信サーバ、端末装置及びそれらに用いるデータ通信方法並びにそのプログラム
JP5034498B2 (ja) * 2006-02-20 2012-09-26 株式会社日立製作所 ディジタルコンテンツの暗号化,復号方法,及び,ディジタルコンテンツを利用した業務フローシステム
DE102006027030A1 (de) * 2006-06-08 2007-12-13 Wittkötter, Erland, Dr. Vorrichtung und Verfahren zum geschützten Verteilen elektronischer Dokumente
US7558789B2 (en) * 2006-11-20 2009-07-07 Illinois Institute Of Technology Method for improving local descriptors in peer-to-peer file sharing

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012248135A (ja) * 2011-05-31 2012-12-13 Sony Corp 情報処理装置、および情報処理方法、並びにプログラム
JP2014121076A (ja) * 2012-12-19 2014-06-30 Toshiba Corp 鍵管理装置、通信装置、通信システムおよびプログラム

Also Published As

Publication number Publication date
US20100008509A1 (en) 2010-01-14

Similar Documents

Publication Publication Date Title
JP2010021888A (ja) 通信装置、鍵サーバ及び管理サーバ
US10417394B2 (en) Method and system for unified mobile content protection
US20110125849A1 (en) Peer-to-peer content distribution
US7680937B2 (en) Content publication
AU2003254377B2 (en) Methods and systems for providing a secure data distribution via public networks
US8108362B2 (en) Secure content descriptions
US20090138714A1 (en) Communication apparatus, key server, management server, communication server, content distribution system, communication method, and recording medium
US8468339B2 (en) Efficient security information distribution
JP5395372B2 (ja) 通信装置、鍵サーバ及びデータ
JP5208549B2 (ja) 通信装置、システム、送信方法及びプログラム
JP6326173B1 (ja) データ送受信システム及びデータ送受信方法
JP2009116901A (ja) 更新方法、送信方法、サーバ及び端末
CN109754226B (zh) 数据管理方法、设备和存储介质
CN115225409B (zh) 基于多备份联合验证的云数据安全去重方法
JP2009033721A (ja) グループ従属端末、グループ管理端末、サーバ、鍵更新システム及びその鍵更新方法
JP2009272927A (ja) 通信装置、サーバ、及びプログラム
JP2010124071A (ja) 通信装置、通信方法及びプログラム
JP5586397B2 (ja) セキュア・ネットワーク・ストレージ・システム、方法、クライアント装置、サーバ装置、及びプログラム
JP2009153091A (ja) 通信装置、鍵サーバ、管理サーバ、通信サーバ、通信方法及びプログラム
WO2010067797A1 (ja) 通信装置、サーバ装置及び通信プログラム
RU2647635C2 (ru) Способ и система распространения контента в сети передачи данных со встроенным механизмом условного доступа
EP1826696B1 (en) Secure random checksum distribution
JP2012244380A (ja) コンテンツ販売管理装置及びコンテンツ販売システム及びコンピュータプログラム及びコンテンツ販売管理方法
JP2021052300A (ja) ファイル管理システム、ストレージサーバ、ファイル管理方法及びファイル管理プログラム