JPWO2015008521A1 - コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、コンピューター・プログラム、並びにコンテンツ伝送システム - Google Patents

コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、コンピューター・プログラム、並びにコンテンツ伝送システム Download PDF

Info

Publication number
JPWO2015008521A1
JPWO2015008521A1 JP2015527200A JP2015527200A JPWO2015008521A1 JP WO2015008521 A1 JPWO2015008521 A1 JP WO2015008521A1 JP 2015527200 A JP2015527200 A JP 2015527200A JP 2015527200 A JP2015527200 A JP 2015527200A JP WO2015008521 A1 JPWO2015008521 A1 JP WO2015008521A1
Authority
JP
Japan
Prior art keywords
content
key
authentication
shared key
receiving device
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.)
Granted
Application number
JP2015527200A
Other languages
English (en)
Other versions
JP6390618B2 (ja
Inventor
中野　雄彦
雄彦 中野
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.)
Sony Corp
Original Assignee
Sony 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 Sony Corp filed Critical Sony Corp
Publication of JPWO2015008521A1 publication Critical patent/JPWO2015008521A1/ja
Application granted granted Critical
Publication of JP6390618B2 publication Critical patent/JP6390618B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H04L9/16—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms the keys or algorithms being changed during operation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

暗号方式を新しくしたより安全なシステムへ移行する際の、時間とコストの負担を軽減する。所定のセキュリティー強化策を施した移行段階の装置に対して、一定のシステム移行期間だけは高価値コンテンツを扱えるようにすることで、移行に要する時間的な問題を回避し、より安全なシステムへの移行を円滑に行なえるようにしている。ここで言う所定のセキュリティー強化策を施した装置とは、例えば、従来の暗号アルゴリズムにしか対応していないが、暗号方式以外のより脆弱な部分の安全性については確保できている装置である。

Description

本明細書で開示する技術は、例えばＤＴＣＰなどの所定の相互認証及び鍵交換アルゴリズムに従って共有した鍵を用いて、著作権などの権利を保護すべきコンテンツを暗号化伝送するコンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、コンピューター・プログラム、並びにコンテンツ伝送システムに関する。
近年、データ圧縮技術の進化や高速ネットワークの普及などにより、高品質で高価値のコンテンツ（例えば、４Ｋ解像度を持つコンテンツなど）をディジタル・データとしてさまざまなメディアを通じて流通するようになってきている。また、パーソナル・コンピューターなどの情報機器の高性能化などもあり、不正な装置によりコンテンツが不正に利用され易くなってきている。このため、ディジタル・データとしてのコンテンツの保護を、これまで以上に強化することが求められている。また、高価値コンテンツの制作・提供業者は、セキュリティーを強化しなければディジタル伝送を許容しないことも想定される。
コンテンツ保護システムのセキュリティーを強化するために、利用する暗号方式を変えることが考えられる。
例えば、ユーザーの単一の秘密鍵から、複数の秘密鍵と対応する公開鍵を複数生成し、その公開鍵を証明書内に格納することで、サービスの要求するセキュリティー・レベルに合わせて使用する鍵長を可変にする鍵生成装置について提案がなされている（例えば、特許文献１を参照のこと）。
本明細書で開示する技術の目的は、著作権などの権利を保護すべきコンテンツを好適に暗号化伝送することができる、優れたコンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、コンピューター・プログラム、並びにコンテンツ伝送システムを提供することにある。
本明細書で開示する技術のさらなる目的は、より安全なシステムへの移行を小さな負荷で実施することができる、優れたコンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、コンピューター・プログラム、並びにコンテンツ伝送システムを提供することにある。
本願は、上記課題を参酌してなされたものであり、請求項１に記載の技術は、
所定の伝送規格に従って、コンテンツ受信装置と相互認証及び共有鍵の引き渡しを行なう認証・鍵共有部と、
前記共有鍵から生成した暗号鍵を用いてコンテンツを前記コンテンツ受信装置へ暗号化伝送するコンテンツ提供部と、
を具備し、
前記認証・鍵共有部は、前記コンテンツ受信装置が所定のセキュリティー強度を有しているか否かに応じて、引き渡す共有鍵を切り替える、
コンテンツ送信装置である。
本願の請求項２に記載の技術によれば、請求項１に記載のコンテンツ送信装置の前記認証・鍵共有部は、前記所定のセキュリティー強度を有したコンテンツ受信装置には第１のコンテンツを扱うことができる第１の共有鍵を引き渡し、前記所定のセキュリティー強度を有していないコンテンツ受信装置には第１のコンテンツを扱うことができない第２の共有鍵を引き渡すように構成されている。また、前記コンテンツ提供部は、前記第１の共有鍵から生成した暗号鍵で第１のコンテンツを暗号化伝送するが、前記第２の共有鍵から生成した暗号鍵では第１のコンテンツを暗号化伝送しないように構成されている。
本願の請求項３に記載の技術によれば、請求項２に記載のコンテンツ送信装置において、前記所定のセキュリティー強化策は、暗号方式以外のより脆弱な部分の安全性が確保されていることである。
本願の請求項４に記載の技術によれば、請求項２に記載のコンテンツ送信装置において、前記第１の共有鍵及び前記第２の共有鍵は第１の暗号方式に従う暗号鍵を生成するための共有鍵である。そして、前記認証・鍵共有部は、前記第１の暗号方式にしか対応しないコンテンツ受信装置には前記第１の共有鍵又は前記第２の共有鍵を引き渡すが、第２の暗号方式に対応するコンテンツ受信装置には前記第２の暗号方式に従う暗号鍵を生成するための共有鍵を引き渡すように構成されている。
本願の請求項５に記載の技術によれば、請求項２に記載のコンテンツ送信装置の前記認証・鍵共有部は、相互認証時に前記コンテンツ受信装置から送られてくる機器証明書に格納されたＥＳフラグに基づいて、前記コンテンツ受信装置が前記所定のセキュリティー強度を有する機器か否かを判別するように構成されている。
本願の請求項６に記載の技術によれば、請求項２に記載のコンテンツ送信装置の前記認証・鍵共有部は、相互認証時に前記コンテンツ受信装置から送られてくるコマンドのペイロードのＣＡＰＡＢＩＬＩＴＹフィールドに格納されたＥＳフラグに基づいて、前記コンテンツ受信装置が前記所定のセキュリティー強度を有する機器か否かを判別するように構成されている。
本願の請求項７に記載の技術によれば、請求項６に記載のコンテンツ送信装置の前記認証・鍵共有部は、相互認証時に前記コンテンツ受信装置から送られてくるコマンドのペイロードのＣＡＰＡＢＩＬＩＴＹフィールドに格納されたＮＳフラグに基づいて、前記コンテンツ受信装置が前記第２の暗号方式に対応しているか否かを判別するように構成されている。
本願の請求項８に記載の技術によれば、請求項６又は７のいずれかに記載のコンテンツ送信装置において、前記ＣＡＰＡＢＩＬＩＴＹフィールドは、前記コンテンツ受信装置の秘密鍵を使って当該フィールドのデータから計算された電子署名を伴うように構成されている。
本願の請求項９に記載の技術によれば、請求項７に記載のコンテンツ送信装置の前記認証・鍵共有部は、前記コンテンツ受信装置から送られてきた機器証明書にＥＳフラグが格納されていることを確認したが、相互認証時のコマンド内でＮＳフラグを確認できないときには、その相互認証処理をエラーとして中断するように構成されている。
本願の請求項１０に記載の技術によれば、請求項２に記載のコンテンツ送信装置の前記認証・鍵共有部は、相互認証時に前記コンテンツ受信装置に送るコマンドのペイロードのＣＡＰＡＢＩＬＩＴＹフィールドに、第２の暗号方式への対応の有無を示すＮＳフラグを格納するとともに、自分の秘密鍵を使って当該フィールドのデータから計算された電子署名を伴わせるように構成されている。
本願の請求項１１に記載の技術によれば、請求項３に記載のコンテンツ送信装置において、前記所定の伝送規格は、ＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）若しくはＤＴＣＰ−ＩＰ（ＤＴＣＰ ｍａｐｐｉｎｇ ｔｏ ＩＰ）である。
また、本願の請求項１２に記載の技術は、
所定の伝送規格に従って、コンテンツ受信装置と相互認証及び共有鍵の引き渡しを行なう認証・鍵共有ステップと、
前記共有鍵から生成した暗号鍵を用いてコンテンツを前記コンテンツ受信装置へ暗号化伝送するコンテンツ提供ステップと、
を有し、
前記認証・鍵共有ステップでは、前記コンテンツ受信装置が所定のセキュリティー強度を有しているか否かに応じて、引き渡す共有鍵を切り替える、
コンテンツ送信方法である。
また、本願の請求項１３に記載の技術は、
所定の伝送規格に従って、コンテンツ送信装置と相互認証及び共有鍵の受け取りを行なう認証・鍵共有部と、
前記の受け取った共有鍵から生成した暗号鍵を用いて暗号化伝送されたコンテンツを取得するコンテンツ取得部と、
を具備し、
前記認証・鍵共有部は、自分が所定のセキュリティー強度を有していることに応じて、第１のコンテンツを扱うことができる第１の共有鍵を受け取り、
前記コンテンツ取得部は、前記第１の共有鍵から生成した暗号鍵で暗号化伝送された第１のコンテンツを取得する、
コンテンツ受信装置である。
本願の請求項１４に記載の技術によれば、請求項１３に記載のコンテンツ受信装置の前記認証・鍵共有部は、相互認証時に前記コンテンツ送信装置に送る機器証明書に、自分が前記所定のセキュリティー強度を有しているか否かを示すＥＳフラグを格納するように構成されている。
本願の請求項１５に記載の技術によれば、請求項１３に記載のコンテンツ受信装置の前記認証・鍵共有部は、相互認証時に前記コンテンツ送信装置に送るコマンドのペイロードのＣＡＰＡＢＩＬＩＴＹフィールドに、自分が前記所定のセキュリティー強度を有しているか否かを示すＥＳフラグ、又は、自分が暗号方式に対応しているか否かを示すＮＳフラグのうち少なくとも一方を格納するように構成されている。
本願の請求項１６に記載の技術によれば、請求項１５に記載のコンテンツ受信装置の前記認証・鍵共有部は、前記ＣＡＰＡＢＩＬＩＴＹフィールドに、自分の秘密鍵を使って当該フィールドのデータから計算された電子署名を伴わせるように構成されている。
また、本願の請求項１７に記載の技術は、
所定の伝送規格に従って、コンテンツ送信装置と相互認証及び共有鍵の受け取りを行なう認証・鍵共有ステップと、
前記の受け取った共有鍵から生成した暗号鍵を用いて暗号化伝送されたコンテンツを取得するコンテンツ取得ステップと、
を有し、
前記認証・鍵共有ステップでは、自分が所定のセキュリティー強度を有していることに応じた共有鍵を受け取る、
コンテンツ受信方法である。
また、本願の請求項１８に記載の技術は、
所定の伝送規格に従って、コンテンツ受信装置と相互認証及び共有鍵の引き渡しを行なう認証・鍵共有部、
前記共有鍵から生成した暗号鍵を用いてコンテンツを前記コンテンツ受信装置へ暗号化伝送するコンテンツ提供部、
としてコンピューターを機能させるようにコンピューター可読形式で記述され、
前記認証・鍵共有部は、前記コンテンツ受信装置が所定のセキュリティー強度を有しているか否かに応じて、引き渡す共有鍵を切り替える、
コンピューター・プログラムである。
また、本願の請求項１９に記載の技術は、
所定の伝送規格に従って、コンテンツ送信装置と相互認証及び共有鍵の受け取りを行なう認証・鍵共有部、
前記の受け取った共有鍵から生成した暗号鍵を用いて暗号化伝送されたコンテンツを取得するコンテンツ取得部、
としてコンピューターを機能させるようにコンピューター可読形式で記述され、
前記認証・鍵共有部は、自分が所定のセキュリティー強度を有していることに応じた共有鍵を受け取る、
コンピューター・プログラムである。
本願の請求項に係るコンピューター・プログラムは、コンピューター上で所定の処理を実現するようにコンピューター可読形式で記述されたコンピューター・プログラムを定義したものである。換言すれば、本願の請求項に係るコンピューター・プログラムをコンピューターにインストールすることによって、コンピューター上では協働的作用が発揮され、本願の請求項１に係るコンテンツ送信装置と同様の作用効果を得ることができる。
また、本願の請求項２０に記載の技術は、
相互認証と共有鍵の交換を行ない、前記共有鍵から生成した暗号鍵を用いてコンテンツを暗号化伝送するコンテンツ送信装置とコンテンツ受信装置で構成され、
前記コンテンツ送信装置は、前記コンテンツ受信装置が所定のセキュリティー強度を有しているか否かに応じて、引き渡す共有鍵を切り替える、
コンテンツ伝送システムである。
但し、ここで言う「システム」とは、複数の装置（又は特定の機能を実現する機能モジュール）が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない。
本明細書で開示する技術によれば、より安全なシステムへの移行を小さな負荷で実施することができる、優れたコンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、コンピューター・プログラム、並びにコンテンツ伝送システムを提供することができる。
本明細書で開示する技術を適用したコンテンツ伝送システムは、暗号方式を新しくしたより安全なシステムへの移行を段階的に行なうことで、完全移行するまでの装置の負担を軽減することができる。
なお、本明細書に記載された効果は、あくまでも例示であり、本発明の効果はこれに限定されるものではない。また、本発明が、上記の効果以外に、さらに付加的な効果を奏する場合もある。
本明細書で開示する技術のさらに他の目的、特徴や利点は、後述する実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
図１は、本明細書で開示する技術を適用したコンテンツ伝送システム１００の構成例を示した図である。 図２は、本明細書で開示する技術を適用したコンテンツ伝送システム２００の他の構成例を模式的に示した図である。 図３は、Ｓｏｕｒｃｅデバイスとして動作するコンテンツ送信装置３００の機能的構成を模式的に示した図である。 図４は、Ｓｉｎｋデバイスとして動作するコンテンツ受信装置４００の機能的構成を模式的に示した図である。 図５は、ＳｏｕｒｃｅデバイスとＳｉｎｋデバイス間でコンテンツ伝送を行なう際の全体的な手順を模式的に示した図である。 図６は、コンテンツ・リスト閲覧フェーズ（ＳＥＱ５０１）の中身を模式的に示した図である。 図７は、完全認証によるＡＫＥ手続きフェーズ（ＳＥＱ５０２）の中身を示した図である 図８は、リモート・アクセス時に行なうＡＫＥ（ＲＡ−ＡＫＥ）手続きフェーズ（ＳＥＱ５０２）の中身を示した図である。 図９は、リモート・アクセスによりコンテンツの移動（ＭＯＶＥ）を行なうためのＡＫＥ（ＭＯＶＥ ＲＴＴ−ＡＫＥ）手続きフェーズ（ＳＥＱ５０２）の中身を示した図である。 図１０は、Ｐｒｏｔｅｃｔｅｄ ＲＴＴ Ｐｒｏｔｏｃｏｌ手続き（ＳＥＱ９０６）の中身を示した図である。 図１１は、コンテンツ伝送フェーズ（ＳＥＱ５０３）の中身を模式的に示した図である。 図１２は、ＤＴＣＰ仕様並びにＤＴＣＰ−ＩＰ仕様に基づくコンテンツの暗号化、伝送、並びに復号化の流れを模式的に示した図である。 図１３は、コンテンツ伝送システムが従来の暗号方式から新しい暗号方式へ切り替わるタイムチャート１３００を模式的に示した図である。 図１４は、Ｓｏｕｒｃｅ及びＳｉｎｋデバイスの暗号方式と伝送可能なコンテンツの対応関係を示した図である。 図１５は、Ｄｅｖｉｃｅ Ｃｅｒｔｉｆｉｃａｔｅのフォーマットを示した図である。 図１６は、Ｄｅｖｉｃｅ Ｃｅｒｔｉｆｉｃａｔｅ内にＥＳフラグを定義した様子を示した図である。 図１７は、ＥＳフラグ並びにＮＳフラグを含んだペイロードの具体的な構成例を示した図である。 図１８は、ＮＳフラグを含んだペイロードの具体的な構成例を示した図である。 図１９は、Ｓｏｕｒｃｅデバイスが共通鍵を決定するための処理手順を示したフローチャートである。 図２０は、Ｓｉｎｋデバイス側で新しい暗号方式を優先的に実行するための処理手順を示したフローチャートである。 図２１は、Ｓｏｕｒｃｅデバイス側で新しい暗号方式を優先的に実行するための処理手順を示したフローチャートである。 図２２は、コンピューター・プログラム配信システム２２００の構成を示した図である。 図２３は、サーバー２０１若しくはＤＴＣＰのＳｏｕｒｃｅデバイスとして動作することが可能なパーソナル・コンピューター２３００の構成例を示した図である。 図２４は、サーバー２０１若しくはＤＴＣＰのＳｏｕｒｃｅデバイスとして動作することが可能なレコーダー２４００の構成例を示した図である。 図２５は、サーバー２０１若しくはＤＴＣＰのＳｏｕｒｃｅデバイスとして動作することが可能なネットワーク・アクセス・サーバー（ＮＡＳ）２５００の構成例を示した図である。
高価値コンテンツの伝送時などにおいて、セキュリティー強化の目的で、利用する暗号方式を新しくしたいという要求がある。例えば、楕円暗号技術ＥＣＣ（Ｅｌｌｉｐｔｉｃ Ｃｕｒｖｅ Ｃｒｙｐｔｏｇｒａｐｈｙ）の鍵長を長くすることが挙げられる。
しかしながら、コンテンツを扱う装置が暗号アルゴリズムの新しい方式に対応する際には、さまざまな問題が発生する。例えば、新たな方式の処理を行なうハードウェアやソフトウェアを実装し、その動作検証をするには、少なからず時間とコストがかかる。
また、新しい暗号方式として鍵長を変える場合には、既存の装置に新しい鍵を埋め込むなどシステムの改修も必要になる可能性が高い。また、よりセキュアな暗号方式に変更する場合、一般的に、より高い処理能力が必要になるため、装置にはその負担も発生する。また、装置の一部だけが新しい暗号方式に対応してセキュリティーを強化しても、その他の部分が脆弱であれば、装置全体としてセキュリティーを確保できない。すなわち、各部が同レベルのセキュリティー強度を持つようにしなければならない。
さらに、システムを新たな暗号アルゴリズムに切り替えると、従来のシステムとは互換性が失われることも考えられる。
これに対し、本明細書で開示する技術では、より安全なシステムへの移行を段階的に行なえるようにして、負担の軽減を図るものである。具体的には、所定のセキュリティー強化策を施した移行段階の装置に対して、一定のシステム移行期間だけは高価値コンテンツを扱えるようにすることで、移行に要する時間的な問題を回避し、より安全なシステムへの移行を円滑に行なえるようにしている。ここで言う所定のセキュリティー強化策を施した装置とは、例えば、従来の暗号アルゴリズムにしか対応していないが、暗号方式以外のより脆弱な部分の安全性については確保できている装置である。
本明細書で開示する技術は、例えば、ディジタル・コンテンツの伝送保護に関する業界標準的な技術であるＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）を適用したコンテンツ伝送に適用することができる。
ここで、ＤＴＣＰは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決めている。その規定は、ＤＴＣＰ準拠機器は取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ：ＡＫＥ）アルゴリズムに従って行なうこと、並びにＡＫＥコマンドにより鍵交換を行なう機器の範囲を制限すること、などを含む。ＤＴＣＰは、原初的には、ＩＥＥＥ１３９４などを伝送路に用いたホーム・ネットワーク上におけるコンテンツ伝送について規定したものであるが、最近では、ＤＴＣＰ技術をＩＰネットワークに移植したＤＴＣＰ−ＩＰ（ＤＴＣＰ ｍａｐｐｉｎｇ ｔｏ ＩＰ）によるリモート・アクセス機能を盛り込んだＤＴＣＰ＋の開発も進められている。
以下では、主にＤＴＣＰ並びにＤＴＣＰ−ＩＰを採用するコンテンツ伝送システムに本明細書で開示する技術を適用した実施形態について、図面を参照しながら詳細に説明する。なお、ＤＴＣＰ仕様は、ＤＴＣＰ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｏｌｕｍｅ１ Ｒｅｖｉｓｉｏｎ１．７に従い、ＤＴＣＰ−ＩＰ仕様は、ＤＴＣＰ−ＩＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ Ｅ Ｒｅｖｉｓｉｏｎ １．４に従うものとする。
Ａ．システム構成
図１には、本明細書で開示する技術を適用したコンテンツ伝送システム１００の構成例を模式的に示している。図示のコンテンツ伝送システム１００は、家庭内に敷設されたホーム・ネットワーク１１０上に接続されたサーバー１０１と、端末１０２、端末１０３で構成される。同図では、簡素化のため、１台のサーバーと２台の端末しか描いていないが、２台以上のサーバー、並びに３台以上の端末がホーム・ネットワーク上に設置されることも想定される。
サーバー１０１は、端末１０２、１０３にコンテンツを提供する装置である。サーバー１０１は、例えば、セットトップボックスやレコーダー、テレビジョン受信機、パーソナル・コンピューター、ネットワーク・アクセス・サーバー（ＮＡＳ）などである。サーバー１０１は、例えば、地上ディジタル放送で受信又は録画した放送コンテンツや、ブルーレイ・ディスクなどの記録媒体（図示しない）から読み込んだ映画などの商用コンテンツ、さらにはインターネット上のコンテンツ・サーバー（図示しない）からダウンロードしたコンテンツを端末１０２、１０３に提供する。端末１０２、１０３は、ホーム・ネットワーク１１０越しに、サーバー１０１にコンテンツを要求する装置であり、携帯電話やスマートフォン、タブレットなどの多機能携帯端末などに相当する。また、端末１０２は、サーバー１０１からダウンロードしたコンテンツを蓄積し、さらに端末１０３に提供することもある。コンテンツを提供する形態として、ストリーミングやコンテンツの移動（ＭＯＶＥ）が挙げられる。
本実施形態では、サーバー１０１と端末１０２など、異種の機器は、例えばＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）に規定されるプロトコルに従って、ホーム・ネットワーク１１０を介して相互接続される。また、サーバー１０１と端末１０２間の相互接続時の通信手順は、例えばＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄＰｌａｙ）に従うものとし、例えば機器発見（ｄｉｓｃｏｖｅｒｙ）などの処理が行なわれる。また、本実施形態では、相互接続されたサーバー１０１と端末１０２又は１０３間で、圧縮コンテンツを伝送する際には、例えばＤＴＣＰに従った暗号化処理を利用して、不正利用できないようにする。すなわち、コンテンツを利用したい端末１０２は、所定の相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ：ＡＫＥ）アルゴリズムに従って、サーバー１０１と相互認証するとともに共有鍵（後述）を共有した後に、サーバー１０１内に蓄積されたコンテンツのダウンロードを要求することができる。サーバー１０１は、要求されたコンテンツを、共有鍵から生成した暗号鍵を用いて暗号化伝送する。コンテンツを提供するサーバー１０１はＤＴＣＰのＳｏｕｒｃｅデバイスに相当し、コンテンツを利用する端末１０２はＤＴＣＰのＳｉｎｋデバイスに相当する。端末１０２から端末１０３へコンテンツをダウンロードする場合も同様に、ＡＫＥアルゴリズムに従って相互認証及び共有鍵の共有を行なった後、コンテンツを暗号化伝送する。この場合は、端末１０２がＤＴＣＰのＳｏｕｒｃｅデバイス、端末１０３がＤＴＣＰのＳｉｎｋデバイスとなる。なお、端末１０２、１０３が外出先などホーム・ネットワーク１１０の外からサーバー１０１にアクセス（リモート・アクセス）したいときには、ホーム・ネットワーク１１０内で端末１０２、１０３をサーバー１０１に事前に登録しておく必要がある（後述）。
また、図２には、本明細書で開示する技術を適用したコンテンツ伝送システム２００の他の構成例を模式的に示している。図示のコンテンツ伝送システム２００は、家庭内に敷設されたホーム・ネットワーク２１０上に接続されたサーバー２０１並びに端末２０２と、インターネットなどの外部ネットワーク２２０上に接続された端末２０３で構成される。ホーム・ネットワーク２１０と外部ネットワーク２２０は、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）プロトコルに従い、ルーター２３０経由で相互接続されている。同図では、簡素化のため、ホーム・ネットワーク２１０上にサーバーと端末をそれぞれ１台ずつしか描いていないが、２台以上のサーバーが設置されることや、ホーム・ネットワーク２１０上にも端末が接続され、さらに外部ネットワーク２２０上に２台以上の端末が接続されることも想定される。
サーバー２０１は、セットトップボックスやレコーダー、テレビジョン受信機、パーソナル・コンピューター、ネットワーク・アクセス・サーバー（ＮＡＳ）などである。サーバー２０１は、放送コンテンツや商用コンテンツなど、外部ネットワーク２２０からリモート・アクセスする端末２０２に提供する。コンテンツを提供する形態として、ストリーミングやコンテンツの移動（ＭＯＶＥ）が挙げられる。端末２０２は、携帯電話やスマートフォン、タブレットなどの多機能携帯端末などであり、ホーム・ネットワーク２１０及び外部ネットワーク２２０からなるＩＰネットワーク越しに、サーバー２０１にコンテンツを要求する。
本実施形態では、サーバー２０１と端末２０２、２０３など、異種の機器は、例えばＤＬＮＡに規定されるプロトコルに従って、ホーム・ネットワーク２１０及び外部ネットワーク２２０を介して相互接続される。また、サーバー２０１と端末２０２間の相互接続時の通信手順は、例えばＵＰｎＰに従うものとし、例えば機器発見（ｄｉｓｃｏｖｅｒｙ）などの処理が行なわれる。また、本実施形態では、ホーム・ネットワーク２１０及び外部ネットワーク２２０を介して相互接続されたサーバー２０１と端末２０３間、並びに、端末２０２と端末２０３間で、圧縮コンテンツを伝送する際には、例えばＤＴＣＰ−ＩＰに従った暗号化処理を利用して、不正利用できないようにする。すなわち、端末２０３は、ホーム・ネットワーク２１０及び外部ネットワーク２２０からなるＩＰネットワーク越しに、サーバー２０１又は端末２０２と相互認証するとともにリモート・アクセス用の共有鍵（後述）を共有した後に、サーバー２０１又は端末２０２内に蓄積されたコンテンツを要求する。サーバー２０１又は端末２０２は、端末２０３から要求されたコンテンツを、リモート・アクセス用の共有鍵から生成した暗号鍵を用いて暗号化伝送する。また、端末２０３は、ホーム・ネットワーク２１０内でサーバー２０１又は端末２０２に事前に登録しておく必要がある（後述）。コンテンツを提供するサーバー２０１又は端末２０２はＤＴＣＰのＳｏｕｒｃｅデバイスに相当し、コンテンツを利用する端末２０３はＤＴＣＰのＳｉｎｋデバイスに相当する。
図３には、ＤＴＣＰのＳｏｕｒｃｅデバイスとして動作するコンテンツ送信装置３００の機能的構成を模式的に示している。例えば、図１に示したコンテンツ伝送システム１００において、端末１０２にコンテンツをダウンロードするサーバー１０１や、端末１０３にコンテンツをダウンロードする端末１０２、図２に示したコンテンツ伝送システムにおいて、端末１０２、１０３にコンテンツをダウンロードするサーバー２０１や、端末１０３にコンテンツをダウンロードする端末１０２などが図示のＳｏｕｒｃｅデバイスに相当する。
通信・制御部３０１は、ホーム・ネットワーク並びに外部ネットワークを介した通信動作を制御するとともに、当該コンテンツ送信装置３００全体の動作を統括的に制御する。本実施形態では、通信・制御部３０１は、ＤＬＮＡに規定されるプロトコルに従って、端末などの異種の機器とホーム・ネットワーク並びに外部ネットワークを介して相互接続する。また、相互接続時の通信手順は例えばＵＰｎＰに従うものとし、通信・制御部３０１は、例えばデバイスに対する機器発見（ｄｉｓｃｏｖｅｒｙ）などの処理を実行する。また、通信・制御部３０１は、ＨＤＭＩ（登録商標）（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ）やＭＨＬ（登録商標）（Ｍｏｂｉｌｅ Ｈｉｇｈ‐Ｄｅｆｉｎｉｔｉｏｎ Ｌｉｎｋ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）などの外部機器接続用（若しくは、コンテンツのディジタル出力用）のインターフェースを備えており、ハード・ディスク装置やブルーレイ・ディスク装置などの録画再生機器を外付け接続することができる。
コンテンツ記録部３０２は、ホーム・ネットワーク並びに外部ネットワーク越しで端末に提供するコンテンツを記録している。コンテンツ記録部３０２は、例えばハード・ディスクやブルーレイ・ディスク、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）のような、コンテンツを記録する記録媒体を備え、例えばＦＡＴ（Ｆｉｌｅ Ａｌｌｏｃａｔｉｏｎ Ｔａｂｌｅ）のような一般的なファイル・システムの管理下で記録した各コンテンツを管理している。
コンテンツ取得部３０３は、端末に提供するコンテンツを取得する。コンテンツ取得部３０３は、例えば地上ディジタル放送用チューナーなどからなり、放送コンテンツを取得する。この場合のコンテンツ取得部３０３は、例えばＡＲＩＢ（Ａｓｓｏｃｉａｔｉｏｎ ｏｆ Ｒａｄｉｏ Ｉｎｄｕｓｔｒｉｅｓ ａｎｄＢｕｓｉｎｅｓｓｅｓ：電波産業会）で規定される仕様に基づく。コンテンツ取得部３０３は、例えば、放送チャンネルの全セグメント又は一部のセグメントの受信機能、ＥＰＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ）の機能（番組検索、番組情報の表示、番組予約）、ＨＤＣＰ（Ｈｉｇｈ−ｂａｎｄｗｉｄｔｈ Ｄｉｇｉｔａｌ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）仕様などに基づくコピー制御機能、放送コンテンツを限定受信したり受信した放送コンテンツを外部出力する際に暗号化したりするコンテンツ保護機能などを備えている。
また、コンテンツ取得部３０３は、通信・制御部３０１に接続されたブルーレイ・ディスクなどのメディア再生装置（図示しない）から映画などの商用コンテンツをメディアから読み取る。また、コンテンツ取得部３０３は、ブラウザーなどからなり、インターネット上のコンテンツ・サーバー（図示しない）から有償又は無償のコンテンツをダウンロードする。
コンテンツ取得部３０３は、取得したコンテンツを、必要に応じて上記のコンテンツ記録部３０２内に記録してもよい。また、コンテンツ取得部３０３は、Ｓｉｎｋデバイスに提供するコンテンツをコンテンツ記録部３０２から取得することもある。
コンテンツ取得部３０３が取得したコンテンツ（放送コンテンツや商用コンテンツ）の中には、高品質なディジタル・データからなる高価値コンテンツもある。高価値コンテンツの提供業者などは、よりセキュリティー・レベルの高い取り扱いを要求する場合もある。
コンテンツ提供部３０４は、Ｓｉｎｋデバイスとして動作するコンテンツ受信装置（後述）からの要求に応答して、コンテンツ取得部３０３が取得したコンテンツを提供する。コンテンツ提供部３０４は、例えばＨＴＴＰ（Ｈｙｐｅｔ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）プロトコルやＲＴＰ（ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）を利用して、通信・制御部３０１を通じてＳｉｎｋデバイスへコンテンツを伝送する。コンテンツ提供部３０４は圧縮機能を備えるか、又は、図３には図示しないコンテンツ圧縮処理部を備えるものとする。また、本実施形態では、伝送コンテンツの安全すなわち不正利用を防ぐために、ＤＴＣＰ規格が適用される。すなわち、コンテンツ提供部３０４は、圧縮コンテンツを、認証・鍵共有部３０６によりＳｉｎｋデバイスと共有した共有鍵から生成した暗号鍵を用いて、コンテンツを暗号化伝送する（後述）。但し、Ｓｉｎｋデバイスが外部ネットワーク上からのリモート・アクセスによりコンテンツを要求する場合、そのＳｉｎｋデバイスは端末管理部３０７に事前登録されたものでなければならない（後述）。
コンテンツ・リスト提供部３０５は、Ｓｉｎｋデバイスとして動作するコンテンツ受信装置（後述）からの要求に応答して、提供可能なコンテンツのリストと詳細情報を提供する。上述からも分かるように、サーバー１０１、２０１が端末に提供可能なコンテンツは、コンテンツ取得部３０３が受信する放送コンテンツやメディアから読み出す商用コンテンツ、コンテンツ記録部３０２に既に記録されているコンテンツが挙げられる。コンテンツ・リストの提供には、例えば、ＤＬＮＡのベースとなるＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄＰｌａｙ）で策定されている、コンテンツのリストとコンテンツの詳細情報を階層化して配信するＣＤＳ（Ｃｏｎｔｅｎｔ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）機能が適用され、例えばＳｉｎｋデバイスからのＣＤＳ：Ｂｒｏｗｓｅアクションに対してＣＤＳ情報を生成してＣＤＳ Ｒｅｓｕｌｔとして返す。
認証・鍵共有部３０６は、コンテンツの要求元となるＳｉｎｋデバイスとの間で、ＤＴＣＰ−ＩＰが規定する認証及び鍵交換（ＡＫＥ）アルゴリズムに従って、相互認証を行なうとともに、コンテンツの暗号鍵Ｋcを生成するための共有鍵ＫXの引き渡しを行なう。また、認証・鍵共有部３０６は、外部ネットワークからリモート・アクセスによりコンテンツを要求してくるＳｉｎｋデバイスに対しては、リモート・アクセス用の共有鍵ＫRを共有し、コンテンツの移動を要求してくるＳｉｎｋデバイスに対しては移動（Ｍｏｖｅ）用の共有鍵ＫXMを共有する。
上述したように、コンテンツ（放送コンテンツや商用コンテンツ）の中には、高品質なディジタル・データからなる高価値コンテンツもある。高価値コンテンツの提供業者などは、よりセキュリティー・レベルの高い取り扱いを要求する場合もある。本実施形態では、認証・鍵共有部３０６は、セキュリティー強化策を施していない従来のＳｉｎｋデバイスに渡す共有鍵ＫX2と、所定のセキュリティー強化策を施したＳｉｎｋデバイスに渡す共用鍵ＫX1とを違うものとしている。後者の共有鍵ＫX1は、所定のセキュリティー強化策を施したデバイス間でしか共有されないので、これを用いて高価値コンテンツを扱えるようになる（何故なら、従来のデバイスは共有鍵ＫX2しか持たないので、共用鍵ＫX1を基に暗号化された高価値コンテンツを復号できないからである）。付言すれば、認証・鍵共有部３０６は、新しい（鍵長を長くした）暗号方式に対応した（すなわち、完全移行した）Ｓｉｎｋデバイスに対しては、従来の鍵長の暗号鍵を生成する共有鍵Ｋxに代えて、鍵長の長い暗号鍵を生成するための共有鍵ＫX_NEWを引き渡すようにしてもよい。但し、共有鍵の引き渡し処理の詳細については後述に譲る。
ここで、所定のセキュリティー強化策を施したデバイスとは、例えば、従来の暗号アルゴリズムにしか対応していないが、暗号方式以外のより脆弱な部分の安全性については確保できているデバイスであり、システムが新しい暗号方式に置き換わる際の移行段階のデバイスとして位置付けられる。移行段階のデバイス間では、従来の暗号方式がそのまま適用されるが、専用の共有鍵ＫX1とすることで、高価値コンテンツを扱えるようにした。なお、高価値コンテンツを扱うための共有鍵を別途用いるという処理は、前記リモート・アクセス、及び、コンテンツの移動（Ｍｏｖｅ）の際にも、専用の共用鍵ＫR1、およびＫXM1を用いて同様に行なうことができる。
端末管理部３０７は、コンテンツを要求するＳｉｎｋデバイスの情報を管理する。現在のＤＴＣＰ−ＩＰ仕様では、第三者によるコンテンツの利用を制限することを意図して、家庭内のサーバーへのリモート・アクセスを、そのサーバーに登録したＳｉｎｋデバイスだけに限定している。端末管理部３０７に事前登録されたＳｉｎｋデバイスのみ、リモート・アクセスによるコンテンツの要求が許可されるものとする。端末管理部３０７は、外部ネットワークからリモート・アクセスによりコンテンツを利用するＳｉｎｋデバイスに対して事前登録の処理を行なうとともに、そのＳｉｎｋデバイスの情報を「ｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙ」や「ＲＡＣ（Ｒｅｍｏｔｅ Ａｃｃｅｓｓ Ｃｏｎｎｅｃｔｉｏｎ） ｒｅｇｉｓｔｒｙ」として管理する。但し、事前登録は本明細書で開示する技術とは直接関連しないので、詳細な説明は省略する。
コンテンツ再生出力部３０８は、コンテンツ記録部３０２に記録されているコンテンツを復号して、再生出力する。
なお、上記の機能ブロック３０３〜３０７は、通信・制御部３０１において、オペレーティング・システムやＴＣＰ／ＩＰプロトコルの上位で実行するアプリケーション・プログラムとして実現することもできる。また、この種のアプリケーション・プログラムは、インターネットなどの広域ネットワーク上で所定のダウンロード・サイトで配信することができ、ディジタル放送チューナーやＴＶ受像機などのＣＥ（Ｃｏｎｓｕｍｅｒ Ｅｌｅｃｔｒｏｎｉｃｓ）機器、スマートフォンなどの多機能端末にダウンロードして利用に供される。
このようなダウンロード・サイトは、例えば、コンピューター・プログラムを記憶する記憶装置２２１１と、コンピューター・プログラムのダウンロード要求を受信したことに応じてそのダウンロードを認める通信装置２２１２とを備えたサーバー２２１０からなり（図２２を参照のこと）、ダウンロードしたコンピューター・プログラムをインストールするクライアント装置（ＤＴＣＰのＳｏｕｒｃｅデバイス又はＤＴＣＰのＳｉｎｋデバイス）と併せてコンピューター・プログラム配信システム２２００を構成する。この種のサーバーは、クライアントからのコンピューター・プログラムのダウンロード要求に対して、コンピューター・プログラムの名称を示す情報を通知する情報通知装置２２１３をさらに備えている。情報通知装置２２１３は、コンピューター・プログラムの名称とともに、例えば、家庭内に記録した商用コンテンツを遠隔地の端末に提供するアプリケーションであることを示す情報を通知する。
図４には、ＤＴＣＰのＳｉｎｋデバイスとして動作するコンテンツ受信装置４００の機能的構成を模式的に示している。例えば、図１に示したコンテンツ伝送システム１００において、サーバー１０１にコンテンツを要求する端末１０２や、サーバー１０１若しくは端末１０２にコンテンツを要求する端末１０３、並びに、図２に示したコンテンツ伝送システム２００において、サーバー２０１にコンテンツを要求する端末２０２や、サーバー２０１若しくは端末２０２にコンテンツを要求する端末２０３などが図示のＳｉｎｋデバイスに相当する。
通信・制御部４０１は、ホーム・ネットワーク並びに外部ネットワークを介した通信動作を制御するとともに、当該コンテンツ受信装置４００全体の動作を統括的に制御する。本実施形態では、通信・制御部４０１は、ＤＬＮＡに規定されるプロトコルに従って、端末などの異種の機器とホーム・ネットワーク並びに外部ネットワークを介して相互接続する。また、相互接続時の通信手順は例えばＵＰｎＰに従うものとし、通信・制御部４０１は、例えばコントロール・ポイントからの機器発見（ｄｉｓｃｏｖｅｒｙ）に対する応答処理を実行する。
コンテンツ・リスト閲覧部４０２は、Ｓｏｕｒｃｅデバイスとして動作するコンテンツ送信装置３００（前述）に対して、コンテンツ・リストの取得要求を行ない、取得したコンテンツ・リストの閲覧画面を表示する。コンテンツ・リストの閲覧には、例えば、ＤＬＮＡのベースとなるＵＰｎＰで策定されているＣＤＳ機能が適用され（前述）、例えばＳｏｕｒｃｅデバイスに対してＣＤＳ：Ｂｒｏｗｓｅアクションを発行する。また、Ｓｏｕｒｃｅデバイスが提供可能なコンテンツのリストを記述したＣＤＳ情報を例えばＣＤＳ Ｒｅｓｕｌｔとして受け取ると、コンテンツ・リスト閲覧部４０２は、コンテンツ一覧画面を表示する。ユーザーは、この一覧画面上で再生出力したいコンテンツを、ユーザーが入力部４０７などを介して選択することができる。入力部４０７は、パーソナル・コンピューターにおけるキーボード並びにマウス、スマートフォンなどの多機能端末におけるタッチパネル、リモコンにおける十字キー並び決定ボタンなどに相当する。
コンテンツ取得部４０３は、コンテンツの取得要求をＳｏｕｒｃｅデバイスに送信して、Ｓｏｕｒｃｅデバイス内のコンテンツを取得する。コンテンツ取得部４０３は、例えば、コンテンツ・リスト閲覧部４０２が表示するコンテンツ一覧画面の中で、上記のようにユーザーが選択したコンテンツの取得を要求する。コンテンツ取得部４０３は、Ｓｏｕｒｃｅデバイスに対するコンテンツの取得要求並びにコンテンツの取得には、例えばＨＴＴＰやＲＴＰなどのプロトコルを利用する（同上）。
コンテンツ取得部４０３がＳｏｕｒｃｅデバイスから取得したコンテンツは、後述する認証・鍵共有部４０６によりＳｏｕｒｃｅデバイスとの間で共有した共有鍵から生成した暗号鍵を用いて暗号化されている（後述）。コンテンツ復号部４０４は、Ｓｏｕｒｃｅデバイスから取得した暗号化コンテンツを、共有鍵から生成した暗号鍵を用いて復号化することができる。そして、コンテンツ再生出力部４０５は、復号したコンテンツを再生出力する。
コンテンツ記録部４０８は、コンテンツ取得部４０３がダウンロード（コピー又は移動）の形式で取得したコンテンツを記録する。記録するコンテンツには記録用の暗号化処理が別途施されることもある。コンテンツ記録部３０２は、例えばハード・ディスクやブルーレイ、ＤＶＤのような、コンテンツを記録する記録媒体を備え、例えばＦＡＴのような一般的なファイル・システムの管理下で記録した各コンテンツを管理している。
認証・鍵共有部４０６は、コンテンツの要求先となるＳｏｕｒｃｅデバイスとの間で、ＤＴＣＰ−ＩＰが規定する認証及び鍵交換（ＡＫＥ）アルゴリズムに従って、相互認証を行なうとともに、コンテンツの暗号鍵Ｋcを生成するための共有鍵ＫXを受け取る。認証・鍵共有部４０６は、外部ネットワークからリモート・アクセスによりコンテンツを要求するＳｏｕｒｃｅデバイスとの間では、リモート・アクセス用共有鍵ＫRを共有する。また、コンテンツの移動を要求する際には、認証・鍵共有部４０６は、Ｓｏｕｒｃｅデバイスとの間でさらに移動（Ｍｏｖｅ）用の共有鍵ＫXMを共有する。また、認証・鍵共有部４０６は、ホーム・ネットワーク２１０接続時において、Ｓｏｕｒｃｅデバイスに対してリモート・アクセスのための事前登録を行なうものとする（前述）。
上述したように、コンテンツ（放送コンテンツや商用コンテンツ）の中には、高品質なディジタル・データからなる高価値コンテンツもある。高価値コンテンツの提供業者などは、よりセキュリティー・レベルの高い取り扱いを要求する場合もある。本実施形態では、認証・鍵共有部４０６は、共有鍵の受け取りに際して、当該コンテンツ受信装置４００にセキュリティー強化策が施されているか否かを、Ｓｏｕｒｃｅデバイスに通知する。そして、認証・鍵共有部４０６は、セキュリティー強化策が施されていない場合には共有鍵ＫX2を、セキュリティー強化策が施されている場合には共有鍵共有鍵ＫX1を受け取ることになる。後者の共有鍵ＫX1は、所定のセキュリティー強化策を施した移行段階のデバイス間でしか共有されないので、これを用いてＳｏｕｒｃｅデバイスから高価値コンテンツを受信し復号することができる（前述）。付言すれば、当該コンテンツ受信装置４００が新しい（鍵長を長くした）暗号方式に対応している（すなわち、完全移行した）Ｓｉｎｋデバイスである場合には、従来の鍵長の暗号鍵を生成する共有鍵に代えて、鍵長の長い暗号鍵を生成するための共有鍵ＫX_NEWを受け取ることもある。但し、共有鍵の引き渡し処理の詳細については後述に譲る。
上記の機能ブロック４０２〜４０６は、通信・制御部４０１において、オペレーティング・システムやＴＣＰ／ＩＰプロトコルの上位で実行するアプリケーション・プログラムとして実現することもできる。この種のアプリケーション・プログラムは、インターネットなどの広域ネットワーク上で所定のダウンロード・サイトで配信することができ、スマートフォンなど、ホーム・サーバー内のコンテンツを再生する多機能端末にダウンロードして利用に供される。
このようなダウンロード・サイトは、例えば、コンピューター・プログラムを記憶する記憶装置２２１１と、コンピューター・プログラムのダウンロード要求を受信したことに応じてそのダウンロードを認める通信装置２２１２とを備えたサーバー２２１０からなり（図２２を参照のこと）、ダウンロードしたコンピューター・プログラムをインストールするクライアント装置（ＤＴＣＰのＳｏｕｒｃｅデバイス又はＤＴＣＰのＳｉｎｋデバイス）と併せてコンピューター・プログラム配信システム２２００を構成する。この種のサーバーは、クライアントからのコンピューター・プログラムのダウンロード要求に対して、コンピューター・プログラムの名称を示す情報を通知する情報通知装置２２１３をさらに備えている。情報通知装置２２１３は、コンピューター・プログラムの名称とともに、例えば、家庭内に記録した商用コンテンツを遠隔地で閲覧することが認められるアプリケーションであることを示す情報を通知する。
Ｂ．システムにおける通信動作
続いて、ＤＴＣＰ仕様並びにＤＴＣＰ−ＩＰ仕様に従ってＳｏｕｒｃｅデバイスとＳｉｎｋデバイスとの間で行なわれる通信動作について説明する。
ここで言うＳｏｕｒｃｅデバイスは、図１に示したコンテンツ伝送システム１００において、端末１０２、１０３にコンテンツをダウンロードするサーバー１０１や、端末１０３にコンテンツをダウンロードする端末１０２、図２に示したコンテンツ伝送システムにおいて、端末２０２、２０３にコンテンツをダウンロードするサーバー２０１や、端末２０３にコンテンツをダウンロードする端末２０２である。また、Ｓｉｎｋデバイスは、図１に示したコンテンツ伝送システム１００において、サーバー１０１にコンテンツを要求する端末１０２や、サーバー１０１若しくは端末１０２にコンテンツを要求する端末１０３、並びに、図２に示したコンテンツ伝送システム２００において、サーバー２０１にコンテンツを要求する端末２０２や、サーバー２０１若しくは端末２０２にコンテンツを要求する端末２０３である。
図５には、ＳｏｕｒｃｅデバイスとＳｉｎｋデバイス間でコンテンツ伝送を行なう際の全体的な手順を模式的に示している。図示のコンテンツ移動手順は、Ｓｉｎｋデバイスが移動を要求するコンテンツを指定するコンテンツ・リスト閲覧フェーズ（ＳＥＱ５０１）と、ＳｏｕｒｃｅデバイスとＳｉｎｋデバイス間で相互認証及び鍵交換手順を実施して共有鍵ＫXを共有するＡＫＥ手続きフェーズ（ＳＥＱ５０２）と、コンテンツ・リスト閲覧フェーズで指定されたコンテンツを、共有鍵ＫXをから生成した暗号鍵ＫC用いて暗号化伝送するコンテンツ伝送フェーズ（ＳＥＱ５０３）からなる。
図６には、コンテンツ・リスト閲覧フェーズ（ＳＥＱ５０１）の中身を模式的に示している。この処理手順は、主にＳｏｕｒｃｅデバイス側のコンテンツ・リスト提供部３０５とＳｉｎｋデバイス側のコンテンツ・リスト閲覧部４０２の間で実施される。
Ｓｉｎｋデバイスからは、コンテンツ・リスト閲覧部４０２から、コンテンツ・リストの閲覧要求が発行される（ＳＥＱ６０１）。コンテンツ・リストの閲覧には、ＤＬＮＡのベースとなるＵＰｎＰで策定されている、コンテンツのリストとコンテンツの詳細情報を階層化して配信するＣＤＳ機能が適用される（前述）。したがって、ＳＥＱ６０１では、ＳｉｎｋデバイスからＣＤＳ：Ｂｒｏｗｓｅアクションが発行される。
Ｓｏｕｒｃｅデバイス側では、ＣＤＳ：Ｂｒｏｗｓｅアクションに対して、コンテンツ・リスト提供部３０５は、コンテンツ提供部３０４で提供可能なるコンテンツに関する取得可能なすべてのコンテンツ情報を取得して（ＳＥＱ６０２）、十分な情報量のＣＤＳ情報を生成する（ＳＥＱ６０３）。そして、Ｓｏｕｒｃｅデバイスは、Ｓｉｎｋデバイスに対してＣＤＳ Ｒｅｓｕｌｔとして返す（ＳＥＱ６０４）。
Ｓｉｎｋデバイス側では、コンテンツ・リスト閲覧部４０２が、受信したＣＤＳ Ｒｅｓｕｌｔを解析して、コンテンツのタイトル並びにより詳細情報を含むコンテンツ情報を表示する（ＳＥＱ６０５）。そして、Ｓｉｎｋデバイスのユーザーは、表示されているコンテンツ・リストの中から、再生したいコンテンツを選択することができる。コンテンツが選択されると、ＳｏｕｒｃｅデバイスからＳｉｎｋデバイスへのコンテンツの伝送が開始されるが、コンテンツ伝送に先駆けて、ＳｉｎｋデバイスとＳｏｕｒｃｅデバイス間で、相互認証及び鍵交換すなわちＡＫＥ処理（ＳＥＱ５０２）が実施される。
ＤＴＣＰ仕様では、ＡＫＥ処理方式として、公開鍵暗号方式を利用した完全認証（Ｆｕｌｌ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）と、秘密鍵方式を利用した限定認証（Ｒｅｓｔｒｉｃｔｅｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）の２種類の方式が定められている。限定認証では、Ｎｏ Ｍｏｒｅ ＣｏｐｙとＣｏｐｙ ｏｎｅ ｇｅｎｅｒａｔｉｏｎという２種類のコンテンツしか扱えないが、完全認証では、上記２種類のデータに加えてＣｏｐｙ Ｎｅｖｅｒのコンテンツまで扱うことができる。
図７には、ＤＴＣＰ仕様で規定されている、完全認証によるＡＫＥ手続きフェーズ（ＳＥＱ５０２）の中身を示している。但し、実線で描いた矢印は常時実施されるが、点線で描いた矢印は条件付きで実施される。この処理手順は、主にＳｏｕｒｃｅデバイス側の認証・鍵共有部３０６とＳｉｎｋデバイス側の認証・鍵共有部４０６の間で実施される。
まず、Ｓｉｎｋデバイスは、ＡＫＥステータス・コマンドを送信して（ＳＥＱ７０１）、Ｓｏｕｒｃｅデバイスが完全認証に対応しているかなど、Ｓｏｕｒｃｅデバイスの状態の確認を試みる。これに対し、ＳｏｕｒｃｅデバイスはＡＫＥステータスの返信する（ＳＥＱ７０２）。
次いで、Ｓｉｎｋデバイスは、ＣＨＡＬＬＥＮＧＥ ｓｕｂｆｕｎｃｔｉｏｎメッセージによりＳｏｕｒｃｅデバイスに乱数を送信して（ＳＥＱ７０３）、ＳｏｕｒｃｅデバイスのＡＫＥ処理を初期化させる。ＣＨＡＬＬＥＮＧＥ ｓｕｂｆｕｎｃｔｉｏｎメッセージには、Ｄｅｖｉｃｅ Ｃｅｒｔｉｆｉｃａｔｅ（機器証明書）が含まれる。Ｄｅｖｉｃｅ Ｃｅｒｔｉｆｉｃａｔｅは、ＤＴＬＡから各ＤＴＣＰ準拠デバイスに与えられる証明書である。Ｄｅｖｉｃｅ Ｃｅｒｔｉｆｉｃａｔｅのフォーマットを図１５に示す。Ｓｏｕｒｃｅデバイスは、ＳｉｎｋデバイスのＤｅｖｉｃｅ Ｃｅｒｔｉｆｉｃａｔｅの整合性を検証して、レスポンスを返信する（ＳＥＱ７０４）。
また、Ｓｏｕｒｃｅデバイスは、ＡＫＥステータス・コマンドを送信して（ＳＥＱ７０５）、Ｓｉｎｋデバイスの状態の確認を試み、ＳｉｎｋデバイスはＡＫＥステータスの返信する（ＳＥＱ７０６）。そして、Ｓｏｕｒｃｅデバイスは、ＣＨＡＬＬＥＮＧＥ ｓｕｂｆｕｎｃｔｉｏｎメッセージによりＳｉｎｋデバイスに乱数を送信して（ＳＥＱ７０７）、ＳｉｎｋデバイスのＡＫＥ処理を初期化させる。これに対し、Ｓｉｎｋデバイスは、レスポンスを返信する（ＳＥＱ７０８）。
次いで、Ｓｏｕｒｃｅデバイスは、直前に送られてきた乱数を相手デバイスに内蔵する算式によって演算して、その結果をＲＥＳＰＯＮＳＥ ｓｕｂｆｕｎｃｔｉｏｎメッセージによりＳｉｎｋデバイスへ送信する（ＳＥＱ７０９）。これに対し、Ｓｉｎｋデバイスはレスポンスを返す（ＳＥＱ７１０）。同様に、Ｓｉｎｋデバイスは、直前に送られてきた乱数を相手デバイスに内蔵する算式によって演算して、その結果をＲＥＳＰＯＮＳＥ ｓｕｂｆｕｎｃｔｉｏｎメッセージによりＳｏｕｒｃｅデバイスへ送信する（ＳＥＱ７１１）。これに対し、Ｓｏｕｒｃｅデバイスはレスポンスを返す（ＳＥＱ７１２）。そして、ＳｉｎｋデバイスとＳｏｕｒｃｅデバイスはお互いに、受け取った値と自身に内蔵された算式に基づいて演算した結果と比較し、一致することで相手が互いに同一のプロトコルを有するデバイスであると認識することができる。
次いで、Ｓｏｕｒｃｅデバイスは、コンテンツの暗号鍵の生成に用いる共有鍵ＫXを生成して、これをＥＸＣＨＡＮＧＥ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎメッセージでＳｉｎｋデバイスに送信する（ＳＥＱ７１３）。これに対し、Ｓｉｎｋデバイスはレスポンスを返す（ＳＥＱ７１４）。
次いで、ＳｉｎｋデバイスとＳｏｕｒｃｅデバイスの間で、ＳＲＭ（Ｓｙｓｔｅｍ Ｒｅｎｅｗａｂｉｌｉｔｙ Ｍｅｓｓａｇｅ） ｓｕｂｆｕｎｃｔｉｏｎメッセージの送信とレスポンスの返信を交わして（ＳＥＱ７１５、７１６）、双方のシステムがより新しいバージョンであるかを確認する（ＳＥＱ７１５）。
次いで、Ｓｉｎｋデバイスは、ＣＯＮＴＥＮＴ＿ＫＥＹ＿ＲＥＱ ｓｕｂｆｕｎｃｔｉｏｎメッセージをＳｏｕｒｃｅデバイスに送信して、暗号鍵を要求する（ＳＥＱ７１７）。これに対し、Ｓｏｕｒｃｅデバイスはレスポンスにより暗号鍵を返信する（ＳＥＱ７１８）。
また、図８には、ＤＴＣＰ−ＩＰ仕様で規定されている、リモート・アクセス時に行なうＡＫＥ（ＲＡ−ＡＫＥ）手続きフェーズ（ＳＥＱ５０２）の中身を示している。ＤＴＣＰ−ＩＰ仕様では、第三者によるコンテンツの利用を制限することを意図して、リモート・アクセスをＳｏｕｒｃｅデバイスに事前登録したＳｉｎｋデバイスに限定している（前述）。図示のＡＫＥ処理は、Ｓｉｎｋデバイスが事前登録しているか否かをチェックする手続きを含んでいる。この処理手順は、主にＳｏｕｒｃｅデバイス側の認証・鍵共有部３０６とＳｉｎｋデバイス側の認証・鍵共有部４０６の間で実施される。
Ｓｉｎｋデバイスは、リモート・アクセス用の共有鍵ＫR（Ｒｅｍｏｔｅ Ｅｘｃｈａｎｇｅ Ｋｅｙ）用のビットが設定された共有鍵フィールドを含んだＣＨＡＬＬＥＮＧＥコマンドを送信して、Ｓｏｕｒｃｅデバイスに対してＡＫＥ処理を要求する（ＳＥＱ８０１）。そして、ＳｏｕｒｃｅデバイスとＳｉｎｋデバイス間で、認証手続きのうちチャレンジ・レスポンス部分が実行される（ＳＥＱ８０２〜８０４）。但し、ＣＨＡＬＬＥＮＧＥコマンドの共有鍵ＫR用のビットが設定されていないときには、ＳｏｕｒｃｅデバイスはＲＡ−ＡＫＥ手続きを中止し、ＲＡ−ＡＫＥ以外のＡＫＥ手続きを引き続き行なうことができる。
Ｓｏｕｒｃｅデバイスは、ＳｉｎｋデバイスからＤｅｖｉｃｅ ＩＤ又はＩＤｕをＳｉｎｋ−ＩＤとして受け取ると（ＳＥＱ８０５）、そのＳｉｎｋ−ＩＤが自身の端末管理部３０７内で管理しているｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙ（前述）に登録されているかどうかをチェックする（ＳＥＱ８０６）。
Ｓｉｎｋ−ＩＤがｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙにリストされていない場合には（ＳＥＱ８０６のＮｏ）、Ｓｏｕｒｃｅデバイスは、ＳｉｎｋデバイスにＡＫＥ＿ＣＡＮＣＥＬコマンドを送信して（ＳＥＱ８１４）、ＲＡ−ＡＫＥ手続きを中止する（ＳＥＱ８１５）。
一方、Ｓｉｎｋ−ＩＤがｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙに既に登録されている場合には（ＳＥＱ８０６のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、このＳｉｎｋ−ＩＤに該当するＲＡＣ ｒｅｃｏｒｄが既に存在するかどうかを判別するために、ＲＡＣ ｒｅｇｉｓｔｒｙ（後述）内をチェックする（ＳＥＱ８０７）。
Ｓｉｎｋ−ＩＤに該当するＲＡＣ ｒｅｃｏｒｄが存在する場合には（ＳＥＱ８０７のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、そのＲＡＣ ｒｅｃｏｒｄに格納されているリモート・アクセス用共有鍵ＫR及びその共有鍵ラベルＫR＿ｌａｂｅｌを使うことに決定する。あるいは、Ｓｏｕｒｃｅデバイスは、リモート・アクセス用共有鍵ＫRを用いてコンテンツの伝送を行なっていないのであれば、ＲＡＣ ｒｅｃｏｒｄ内を参照し、格納されているＫR及びＫR＿ｌａｂｅｌの値を更新するようにしてもよい（ＳＥＱ８１３）。
Ｓｉｎｋ−ＩＤはｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙに登録済みであるが、該当するＲＡＣ ｒｅｃｏｒｄが存在しない場合には（ＳＥＱ８０７のＮｏ）、Ｓｏｕｒｃｅデバイスは、ＲＡＣ ｒｅｃｏｒｄをカウントするカウント値ＲＡＣＣがＲＡＣＣmax未満であるかどうかをチェックする（ＳＥＱ８０８）。ここで、ＲＡＣＣmaxは、リモート・アクセス・コネクションをカウントするカウンターであり、リモート・アクセス・コネクションが存在しないときにゼロに初期化される。
ＲＡＣＣがそのＲＡＣＣmax未満でないときには（ＳＥＱ８０８のＮｏ）、Ｓｏｕｒｃｅデバイスは、ＳｉｎｋデバイスにＡＫＥ＿ＣＡＮＣＥＬコマンドを送信して（ＳＥＱ８１４）、ＲＡ−ＡＫＥ手続きを中止する（ＳＥＱ８１５）。
ＲＡＣＣがＲＡＣＣmax未満であれば（ＳＥＱ８０８のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、ＲＡＣＣの値を１だけインクリメントした後（ＳＥＱ８０９）、所定の演算規則に従って、リモート・アクセス用共有鍵ＫR及びその共有鍵ラベルＫR＿ｌａｂｅｌを生成して（ＳＥＱ８１０）、これらをＳｉｎｋデバイスのＳｉｎｋ−ＩＤと対応付けて、ＲＡＣ ｒｅｇｉｓｔｒｙ内のＲＡＣ ｒｅｃｏｒｄに格納する（ＳＥＱ８１１）。Ｓｏｕｒｃｅデバイスは、例えば端末管理部３０７内でＲＡＣ ｒｅｃｏｒｄを管理する。
そして、Ｓｏｕｒｃｅデバイスは、既存のＲＡＣ ｒｅｃｏｒｄから取り出したリモート・アクセス用共有鍵ＫR及びその共有鍵ラベルＫR＿ｌａｂｅｌ（更新した場合を含む）、又は、新たに生成したリモート・アクセス用共有鍵ＫR及びその共有鍵ラベルＫR＿ｌａｂｅｌを、Ｓｉｎｋデバイスに送信する（ＳＥＱ８１６）。
ＳｏｕｒｃｅデバイスがＲＡ＿ＭＡＮＡＧＥＭＥＮＴ機能をサポートしている場合には、リモート・アクセス用の共有鍵ＫRを維持するためのＫR用生存タイマーを開始させ、少なくとも１分間ＫRを保持する（ＳＥＱ８１２）。
また、図９には、ＤＴＣＰ−ＩＰ仕様で規定されている、コンテンツの移動を行なうためのＡＫＥ（ＭＯＶＥ ＲＴＴ−ＡＫＥ）手続きフェーズ（ＳＥＱ５０２）の中身を示している。この処理手順は、主にＳｏｕｒｃｅデバイス側の認証・鍵共有部３０６とＳｉｎｋデバイス側の認証・鍵共有部４０６の間で実施される。
Ｓｉｎｋデバイスは、ＳｏｕｒｃｅデバイスにＭＶ＿ＩＮＩＴＩＡＴＥコマンドを送信することによって、移動用のＡＫＥ（ＭＯＶＥ ＲＴＴ−ＡＫＥ）手続きを開始する（ＳＥＱ９０１）。これに対し、Ｓｏｕｒｃｅデバイスは、ＤＴＣＰ−ＩＰのＭｏｖｅプロトコルを実行できるときには、その受領確認として、ＭＶ＿ＩＮＩＴＩＡＴＥレスポンスを返信する（ＳＥＱ９０２）。
また、Ｓｉｎｋデバイスは、能力情報の交換が必要な場合には、この時点で、ＳｏｕｒｃｅデバイスにＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥコマンドを送信する（ＳＥＱ９０３）。これに対し、Ｓｏｕｒｃｅデバイスは、ＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥレスポンスを返信する（ＳＥＱ９０４）。
続いて、ＳｉｎｋデバイスとＳｏｕｒｃｅデバイスは、Ｃｈａｌｌｅｎｇｅ−Ｒｅｓｐｏｎｓｅ ｐｏｒｔｉｏｎ ｏｆ ＡＫＥ手続き（ＳＥＱ９０５）を実施する。このＣｈａｌｌｅｎｇｅ−Ｒｅｓｐｏｎｓｅ ｐｏｒｔｉｏｎ ｏｆ ＡＫＥ手続きは、ＳｉｎｋデバイスからのＣＨＡＬＬＥＮＧＥのコマンド送信と、ＳｏｕｒｃｅデバイスからのＲＥＳＰＯＮＳＥ又はＲＥＳＰＯＮＳＥ２の送信に対するＳｉｎｋデバイスからの応答送信までのシーケンス（図示しない）を含んでいる。このＣｈａｌｌｅｎｇｅ−Ｒｅｓｐｏｎｓｅ ｐｏｒｔｉｏｎ ｏｆ ＡＫＥ手続きを経て、ＳｏｕｒｃｅデバイスとＳｉｎｋデバイスは移動用の認証鍵（ＨＫAUTH）を共有する。
続いて、Ｐｒｏｔｅｃｔｅｄ ＲＴＴ Ｐｒｏｔｏｃｏｌ手続きを実施する（ＳＥＱ９０６）。ＤＴＣＰ−ＩＰ仕様では、リモート・アクセスを制限するために、ＡＫＥコマンドに対する往復遅延時間（ＲＴＴ：Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）に制限を課している。Ｐｒｏｔｅｃｔｅｄ ＲＴＴ Ｐｒｏｔｏｃｏｌ手続きは、このＲＴＴの制限を確認する手続きである（後述）。但し、Ｓｉｎｋデバイスが既にＲＴＴ ｒｅｇｉｓｔｒｙに存在し、又は、ＳｉｎｋデバイスのＤｅｖｉｃｅ ＩＤがリモート・アクセス用のＲＡＣ ｒｅｇｉｓｔｒｙ（前述）に既に存在する場合などは、Ｐｒｏｔｅｃｔｅｄ ＲＴＴ Ｐｒｏｔｏｃｏｌ手続きをスキップすることができる。
その後、Ｓｏｕｒｃｅデバイスは、上述した移動用の認証鍵（ＨＫAUTH）から移動用の共有鍵ＫXMを生成して、これをＭＶ＿ＥＸＣＨＡＮＧＥ＿ＫＥＹコマンドでＳｉｎｋデバイスに送信する（ＳＥＱ９０７）。これに対し、Ｓｉｎｋデバイスは、ＭＶ＿ＥＸＣＨＡＮＧＥ＿ＫＥＹレスポンスを返信する（ＳＥＱ９０８）。
図１０には、Ｐｒｏｔｅｃｔｅｄ ＲＴＴ Ｐｒｏｔｏｃｏｌ手続き（ＳＥＱ９０６）の中身を示している。
Ｃｈａｌｌｅｎｇｅ−Ｒｅｓｐｏｎｓｅ ｐｏｒｔｉｏｎ ｏｆ ＡＫＥ（ＳＥＱ１０００）では、Ｓｉｎｋデバイスから、Ｒｘ乱数とＲｘ証明書（Ｄｅｖｉｃｅ Ｃｅｒｔｉｆｉｃａｔｅ）を含んだＲｘチャレンジが送信される。これに対し、Ｓｏｕｒｃｅデバイスからは、Ｔｘ乱数及びＴｘ証明書（Ｄｅｖｉｃｅ Ｃｅｒｔｉｆｉｃａｔｅ）を含んだＴｘチャレンジが返信される。以降、Ｓｏｕｒｃｅデバイスから、Ｒｘ乱数、Ｔｘメッセージ、Ｔｘ署名を含んだＲｘレスポンスが送信されるとともに、ＳｉｎｋデバイスからはＴｘ乱数、Ｒｘメッセージ、Ｒｘ署名を含んだＴｘレスポンスが送信され、通常のチャレンジ・レスポンス認証手続きが続く（図示を省略）。
Ｃｈａｌｌｅｎｇｅ−Ｒｅｓｐｏｎｓｅ ｐｏｒｔｉｏｎ ｏｆ ＡＫＥ（ＳＥＱ１０００）が完了した後、ＳｏｕｒｃｅデバイスからコマンドＲＴＴ＿ＲＥＡＤＹ．ＣＭＤが送信され（ＳＥＱ１００１）、ＳｉｎｋデバイスからレスポンスＲＴＴ＿ＲＥＡＤＹ．ＲＳＰが返信される（ＳＥＱ１００２）。そして、ＳｉｎｋデバイスからコマンドＲＴＴ＿ＲＥＡＤＹ．ＣＭＤが送信され（ＳＥＱ１００３）、ＳｏｕｒｃｅデバイスからレスポンスＲＴＴ＿ＲＥＡＤＹ．ＲＳＰが返信されると（ＳＥＱ１００４）、Ｐｒｏｔｅｃｔｅｄ ＲＴＴ Ｐｒｏｔｏｃｏｌ手続きが開始する。その際、Ｓｏｕｒｃｅデバイス側では２種類のメッセージ認証コード（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）ＭＡＣ１Ａ、ＭＡＣ２Ａを計算するとともに（ＳＥＱ１０１０）、Ｓｉｎｋデバイス側でも同様の計算方法により２種類のメッセージ認証コードＭＡＣ１Ｂ、ＭＡＣ２Ｂを計算しておく（ＳＥＱ１０３０）。Ｓｏｕｒｃｅデバイスは、コマンドＲＴＴ＿ＳＥＴＵＰ（Ｎ）．ＣＭＤにより変数Ｎを送信する（ＳＥＱ１００５）。これに対し、Ｓｉｎｋデバイスは、レスポンスとＡＣＣＥＰＴＥＤ（Ｎ）．ＲＳＰを返信する（ＳＥＱ１００６）。Ｓｏｕｒｃｅ、Ｓｉｎｋの各デバイスともに、ここで伝送される変数Ｎに対するメッセージ認証コードを用意する。
そして、Ｓｏｕｒｃｅデバイスは、ＲＴＴ測定用のコマンドであるＲＴＴ＿ＴＥＳＴ（ＭＡＣ１Ａ）．ＣＭＤを送信し（ＳＥＱ１００７）、Ｓｉｎｋデバイスは、これに対するレスポンスであるＡＣＣＥＰＴＥＤ（ＭＡＣ２Ｂ）．ＲＳＰを返信する（ＳＥＱ１００８）。
Ｓｏｕｒｃｅデバイスは、ＲＴＴ測定用のコマンドを送信してからレスポンスを受信するまでの往復遅延時間ＲＴＴが規定の閾値（７ミリ秒）以下であるか否か、すなわちＲＴＴチェックを行なう（ＳＥＱ１０１１）。ＲＴＴが閾値を超えるときには（ＳＥＱ１０１１のＮｏ）、Ｓｏｕｒｃｅデバイスは、試行回数が１０２３回を超えていないかどうかをさらにチェックする（ＳＥＱ１０１２）。試行回数が１０２３回を超えていないときには（ＳＥＱ１０１２のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、Ｎを１だけ増分してから、新たなＮに対応するメッセージ認証コードを用意してＲＴＴ＿ＳＥＴＵＰ（Ｎ）コマンドを送信し（ＳＥＱ１００５）、Ｓｉｎｋデバイスも新たなＮに対応するメッセージ認証コードを用意してＡＣＣＥＰＴＥＤ（Ｎ）レスポンスを送信し、ＳｏｕｒｃｅデバイスとＳｉｎｋデバイス間でＲＴＴ測定用コマンドの送信とレスポンスの返信を繰り返す。また、試行回数が１０２３回を超えたときには（ＳＥＱ１０１２のＮｏ）、Ｓｏｕｒｃｅデバイスは、この認証手順を中止（Ａｂｏｒｔ）する。
一方、ＲＴＴが閾値以下であるときには（ＳＥＱ１０１１のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、ＡＣＣＥＰＴＥＤ（ＭＡＣ２Ｂ）．ＲＳＰで受け取ったメッセージ認証コードＭＡＣ２Ｂが、自分で生成したＭＡＣ２Ａと一致するかどうかをさらにチェックする（ＳＥＱ１０１３）。一致しなければ（ＳＥＱ１０１３のＮｏ）、Ｓｏｕｒｃｅデバイスは、この認証手順を中止（Ａｂｏｒｔ）する。
互いのメッセージ認証コードＭＡＣ２ＡとＭＡＣ２Ｂが一致したときには（ＳＥＱ１０１３のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、ＲＴＴ検証コマンドＲＴＴ＿ＶＥＲＩＦＹ．ＣＭＤを送信する（ＳＥＱ１００９）。Ｓｉｎｋデバイスは、このコマンドに応答して（ＳＥＱ１０３１のＮｏ）、ＲＴＴ＿ＴＥＳＴ（ＭＡＣ１Ａ）．ＣＭＤで受け取ったメッセージ認証コードＭＡＣ１Ａが、自分で生成したＭＡＣ１Ｂと一致するかどうかをチェックする（ＳＥＱ１０３２）。一致しなければ（ＳＥＱ１０３２のＮｏ）、Ｓｉｎｋデバイスは、この認証手順を中止（Ａｂｏｒｔ）し、一致すれば（ＳＥＱ１０３２のＹｅｓ）、ＡＣＣＥＰＴＥＤ（ＯＫＭＳＧ）．ＲＳＰを返信する（ＳＥＱ１０１０）。
Ｓｏｕｒｃｅデバイスは、ＳｉｎｋデバイスからＡＣＣＥＰＴＥＤ（ＯＫＭＳＧ）．ＲＳＰを受け取ると、これに含まれているメッセージＯＫＭＳＧを検証する（ＳＥＱ１０１４）。メッセージＯＫＭＳＧの検証に成功すれば（ＳＥＱ１０１４のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、ＳｉｎｋデバイスをＲＴＴ ｒｅｓｉｓｔｒｙに追加するとともに、コンテンツ伝送カウンターを４０時間に設定する（ＳＥＱ１０１５）。また、メッセージＯＫＭＳＧの検証に失敗したときには（ＳＥＱ１０１４のＮｏ）、Ｓｏｕｒｃｅデバイスは、この認証手順を中止（Ａｂｏｒｔ）する。
図７〜図９のうちいずれのＡＫＥ処理における相互認証が成功すると、ＳｏｕｒｃｅデバイスとＳｉｎｋデバイスの間で同一の共有鍵ＫXを共有することができる。但し、リモート・アクセス時の共有鍵はＫR、リモート・アクセスによるコンテンツ移動時の共有鍵はＫXMであるが、以下では便宜上これらの共有鍵をまとめて単にＫXとする。
コンテンツ伝送フェーズ（ＳＥＱ５０３）では、上記のようにして得られた共有鍵ＫXを用いて、コンテンツの暗号化伝送が行なわれる。図１１には、コンテンツ伝送フェーズ（ＳＥＱ５０３）の中身を模式的に示している。この処理手順は、主にＳｏｕｒｃｅデバイス側のコンテンツ提供部３０４とＳｉｎｋデバイス側のコンテンツ取得部４０３の間で実施される。
Ｓｉｎｋデバイスは、ＨＴＴＰ ＧＥＴメソッドを用いたＨＴＴＰリクエスト（ＨＴＴＰ ＧＥＴ ｒｅｑｕｅｓｔ）により、Ｓｏｕｒｃｅデバイスに対して、コンテンツを要求する（ＳＥＱ１１０１）。このＨＴＴＰ ＧＥＴリクエストには、コンテンツのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）とともに、ＡＫＥ手続きフェーズ（ＳＥＱ５０２）により取得した共有鍵ラベルＫX＿ｌａｂｅｌを含める。
Ｓｏｕｒｃｅデバイスは、Ｓｉｎｋデバイスからのコンテンツ要求を許可する場合には、共有鍵ラベルＫX＿ｌａｂｅｌで指定された共有鍵ＫXから暗号鍵ＫCを生成すると、この暗号鍵ＫCを用いてコンテンツを暗号化して、ＨＴＴＰレスポンス（ＨＴＴＰ ＧＥＴ ｒｅｓｐｏｎｓｅ）としてＳｉｎｋデバイスに伝送する（ＳＥＱ１１０２）。
ＤＴＣＰ仕様並びにＤＴＣＰ−ＩＰ仕様に基づくコンテンツの暗号化、伝送、並びに復号化の流れを図１２に模式的に示した。
ＳｏｕｒｃｅデバイスとＳｉｎｋデバイスは、まず１つのＴＣＰ／ＩＰコネクションを確立して、ＡＫＥ手続きを行なう。そして、互いのＤｅｖｉｃｅ Ｃｅｒｔｉｆｉｃａｔｅに基づいて正規のＤＴＣＰ準拠デバイスであることを確かめ合った後に、認証鍵Ｋauthを共有する。そして、Ｓｏｕｒｃｅデバイスは共有鍵Ｋxを生成すると、これを認証鍵Ｋauthで暗号化してＳｉｎｋデバイスに送る。
ＡＫＥ手続きが済んだ後、ＨＴＴＰなどのプロトコルを利用してコンテンツ伝送が実施される（図１１を参照のこと）。その際、ＡＫＥ手続きのためのＴＣＰ／ＩＰコネクションとは別に、コンテンツ伝送のためのＴＣＰ／ＩＰコネクションが作成される。
Ｓｏｕｒｃｅデバイスは、伝送するコンテンツを暗号化する。具体的には、Ｓｏｕｒｃｅデバイスは、乱数を用いてノンスＮcを生成して、共有鍵ＫxとノンスＮcを引数にして、暗号モード（後述）に対応した演算処理により暗号鍵Ｋcを生成する。そして、この暗号鍵Ｋcを用いてコンテンツを暗号化する。
Ｓｏｕｒｃｅデバイスから暗号化コンテンツを伝送するＨＴＴＰレスポンスは、１つ以上のＰＣＰからなる。具体的には、Ｓｏｕｒｃｅデバイスは、乱数を用いてノンスＮcを生成すると、共有鍵ＫXとノンスＮcと暗号モードを表すＥ−ＥＭＩ（Ｅｘｔｅｎｄｅｄ Ｅｎｃｒｉｐｔｉｏｎ Ｍｏｄｅ Ｉｎｄｉｃａｔｏｒ）に基づいて暗号鍵Ｋcを計算し、暗号鍵Ｋcを用いて暗号化する（Ｅ−ＥＭＩは、暗号モードを記述する４ビット長のフィールドで構成され、その値はコピー制御情報の７種類に対応する）。そして、ヘッダーにノンスＮcとＥ−ＥＭＩを含むとともにペイロードに暗号化コンテンツを含んだＰＣＰ（Ｐｒｏｔｅｃｔｅｄ Ｃｏｎｔｅｎｔ Ｐａｃｋｅｔ）パケットをＴＣＰストリーム上に乗せる。ＩＰプロトコルは、暗号化コンテンツを含んだＴＣＰストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダー部を付加したＩＰパケットにし、指定されたＩＰアドレス宛てに届ける。
Ｓｉｎｋデバイスは、Ｓｏｕｒｃｅデバイスからの各ＩＰパケットを受信すると、これをＴＣＰストリームに組み立てる。そして、このストリームからノンスＮcとＥ−ＥＭＩを取り出すと、これらと共有鍵Ｋxを用いて暗号鍵Ｋcを算出し、受信した暗号化コンテンツを復号することができる。そして、復号化した後の平文のコンテンツに対し再生やコピー、移動などの処理を実施することができる。
Ｃ．セキュリティー・レベルに応じた共有鍵の交換
図７〜図１２に示したように、ＤＴＣＰ仕様並びにＤＴＣＰ−ＩＰ仕様は、ディジタル・データとしてのコンテンツをセキュアに伝送する技術を提供することができる。最近では、４Ｋ解像度を持つコンテンツなどの高品質で高価値のコンテンツが伝送対象となることから、これまで以上にセキュリティーの強化が求められてくる。
コンテンツ保護システムのセキュリティーを強化するために、鍵長を長くすることなど、利用する暗号方式を変えることが考えられる（例えば、特許文献１を参照のこと）。ところが、新たな暗号方式に切り替えるには、少なからず時間とコストがかかる。新しい暗号方式に対応したデバイスに完全に置き換わるまでに相応のシステム移行期間を要するであろう。その間は、従来の暗号方式にのみ対応したデバイスとは互換性が失われることが考えられる。ＤＴＣＰ仕様並びにＤＴＣＰ−ＩＰ仕様に準拠するコンテンツ伝送システムにおいても、暗号方式を新しくするには同様の問題がある。
そこで、本明細書で開示する技術では、より安全なシステムへの移行を段階的に行なう仕組みを導入して、時間やコストの負担の軽減を図っている。具体的には、所定のセキュリティー強化策を施した移行段階の装置に対して、一定のシステム移行期間だけは高価値コンテンツを扱えるようにすることで、移行に要する時間的な問題を回避し、より安全なシステムへの移行を円滑に行なえるようにしている。
Ｓｏｕｒｃｅデバイスすなわちコンテンツ送信装置３００側の認証・鍵共有部３０６は、セキュリティー強化策を施していない従来のＳｉｎｋデバイスに渡す共有鍵ＫX2と、所定のセキュリティー強化策を施したＳｉｎｋデバイスに渡す共用鍵ＫX1とを違うものとしている。
ここで、所定のセキュリティー強化策を施したデバイスとは、例えば、従来の暗号アルゴリズムにしか対応していないが、暗号方式以外のより脆弱な部分の安全性については確保できているデバイスであり、システムが新しい暗号方式に置き換わる際の移行段階のデバイスとして位置付けられる。
移行段階のデバイス間のコンテンツ伝送では、従来のままの暗号アルゴリズムが適用されるが、専用の共有鍵ＫX1とすることで、高価値コンテンツを扱えるようになる。何故なら、従来のデバイスは共有鍵ＫX2しか持たないので、共用鍵ＫX1を基に暗号化された高価値コンテンツを復号できないからである。
なお、所定のセキュリティー強化策を施したデバイスと施していないデバイスは、ともに新しい暗号アルゴリズム方式には対応しておらず、ともに従来の暗号アルゴリズムを適用する。所定のセキュリティー強化策を施したか否かの違いは、例えば実装のロバスト性に関するものである。より具体的に言えば、ソフトウェアだけでセキュリティーの実装が可能なデバイスはセキュリティー強化策を施したとは言えないが、デバイス鍵などの高機密情報をハードウェアで保護したデバイスはセキュリティー強化策を施したということができる。
また、ともに新しい暗号方式に対応したＳｏｕｒｃｅデバイスとＳｉｎｋデバイスの間では、従来の鍵長の暗号鍵を生成する共有鍵Ｋxに代えて、鍵長の長い暗号鍵を生成するための共有鍵ＫX_NEWが共有される。これによって、新しい暗号方式に対応したデバイス間では、共有鍵ＫX_NEWから生成される鍵長の長い暗号鍵を用いて、高価値コンテンツをよりセキュアに伝送することが可能になる。
図１３には、コンテンツ伝送システムが従来の暗号方式から新しい暗号方式へ切り替わるタイムチャート１３００を模式的に示している。
システム移行期限１３０１より以前の期間１３０２では、新しい暗号方式には対応していないが、所定のセキュリティー強化策を施した（移行段階の）デバイスにも、高価値コンテンツを扱うことを許容する。
一方、システム移行期限１３０１を経過した期間１３０３では、高価値コンテンツを扱うにはデバイスは新しい暗号方式に対応することが必須になる。よって、従来の暗号方式にしか対応しないデバイスは、所定のセキュリティー強化策を施しているか否かに拘わらず、高価値コンテンツを扱うことができなくなる。なお、システム移行期限１３０１以前に製造された、高価値コンテンツを扱えるデバイスは、システム移行期限１３０１以後も従来の暗号方式で高価値コンテンツを扱えるが、システム移行期限１３０１以後は高価値コンテンツを扱うデバイスはすべて新しい暗号方式に対応し、さらに新しい暗号方式に対応したデバイス同士は常に新しい暗号方式を用いるので、高価値コンテンツが従来の暗号方式で用いられることは長期的にはなくなっていくことになる。
例えば、コンテンツ伝送システムの運用者は、高価値コンテンツの制作・提供業者のセキュリティーを強化したいという要求と、装置ベンダーなどの暗号方式の切り換えに時間とコストの負担を軽減したいという要求のバランスを考慮して、適当なシステム移行期限１３０１を設定すればよい。
また、図１４には、Ｓｏｕｒｃｅ及びＳｉｎｋデバイスの暗号方式と伝送可能なコンテンツの対応関係を示している。但し、同図中、新しい暗号方式に対応したＳｏｕｒｃｅ及びＳｉｎｋデバイスは、従来の暗号方式にも対応して互換性を確保しているものとする。
従来の暗号方式に対応し、且つ、所定のセキュリティー強化策を施していないＳｏｕｒｃｅデバイスは、そもそも自ら高価値コンテンツを扱うことができない。したがって、所定のセキュリティー強化策を施していないＳｉｎｋデバイス、所定のセキュリティー強化策を施したＳｉｎｋデバイス、及び、新しい暗号方式に対応したＳｉｎｋデバイスのいずれにも、高価値コンテンツを伝送することはできず、高価値コンテンツ以外のコンテンツを従来の暗号方式で伝送するしかない（Ｃ１４０１、Ｃ１４０２、Ｃ１４０３）。
また、所定のセキュリティー強化策を施したＳｏｕｒｃｅデバイスは、所定のセキュリティー強化策を施したＳｉｎｋデバイス及び新しい暗号方式に対応したＳｉｎｋデバイスに対しては、共有鍵をＫX2からＫX1に切り替えて、高価値コンテンツを従来の暗号方式で伝送することができる（Ｃ１４１２、Ｃ１４１３）。しかしながら、所定のセキュリティー強化策を施していないＳｉｎｋデバイスに対しては、高価値コンテンツ以外のコンテンツを従来の暗号方式で伝送するしかない（Ｃ１４１１）。
また、新しい暗号方式に対応したＳｏｕｒｃｅデバイスは、所定のセキュリティー強化策を施したＳｉｎｋデバイスに対しては、共有鍵をＫX2からＫX1に切り替えて、高価値コンテンツを従来の暗号方式で伝送することができるとともに（Ｃ１４２２）、新しい暗号方式に対応したＳｉｎｋデバイスに対しては、高価値コンテンツを新しい暗号方式で伝送することができる（Ｃ１４２３）。しかしながら、所定のセキュリティー強化策を施していないＳｉｎｋデバイスに対しては、高価値コンテンツ以外のコンテンツを従来の暗号方式で伝送するしかない（Ｃ１４２１）。
Ｓｏｕｒｃｅデバイスは、高価値コンテンツを伝送する際に、伝送先のＳｉｎｋデバイスが所定のセキュリティー強化策を施しているか（暗号方式以外のより脆弱な部分の安全性については確保できているか）、あるいは新しい暗号方式に対応しているかどうかを知る必要がある。また、新しい暗号方式に対応したＳｉｎｋデバイスは、高価値コンテンツの要求先であるＳｏｕｒｃｅデバイスが新しい暗号方式を対応しているか否かを知らなければ、暗号方式を指示することはできない。
本実施形態では、デバイスが所定のセキュリティー強化策を施しているか（暗号方式以外のより脆弱な部分の安全性については確保できているか）否かを示すＥＳフラグを定義している。所定のセキュリティー強化策を施したデバイスは、自身から送信するメッセージ中のＥＳフラグ＝１を書き込んで、所定のセキュリティー強化策を施していることを相手に通知するようにしている。他方、所定のセキュリティー強化策を施していない（脆弱な部分の安全性を確保していない）場合には、ＥＳフラグ＝０を書き込む。
例えば、Ｄｅｖｉｃｅ Ｃｅｒｔｉｆｉｃａｔｅ内にＥＳフラグを定義することができる。図１６には、Ｄｅｖｉｃｅ Ｃｅｒｔｉｆｉｃａｔｅ内で、参照番号１６０１で示す、現仕様では予約（Ｒｅｓｅｒｖｅｄ）されている位置に、ＥＳフラグを定義した様子を示している。
Ｄｅｖｉｃｅ Ｃｅｒｔｉｆｉｃａｔｅは、ＤＴＬＡから各ＤＴＣＰ準拠デバイスに与えられる証明書である。Ｓｉｎｋデバイスは、例えば図７に示した完全認証（Ｆｕｌｌ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）において、ＣＨＡＬＬＥＮＧＥ ｓｕｂｆｕｎｃｔｉｏｎメッセージ（ＳＥＱ７０３）で送るＤｅｖｉｃｅ ＣｅｒｔｉｆｉｃａｔｅにＥＳフラグを格納することにより、所定のセキュリティー強化策を施していること（暗号方式以外のより脆弱な部分の安全性については確保できていること）をＳｏｕｒｃｅデバイスに通知することができる。また、図８に示したＲＡ−ＡＫＥ手続きにおいても、Ｓｉｎｋデバイスは、同様の方法で、所定のセキュリティー強化策を施していること（暗号方式以外のより脆弱な部分の安全性については確保できていること）をＳｏｕｒｃｅデバイスに通知することができる。
また、図９に示したＭＯＶＥ ＲＴＴ−ＡＫＥ手続きや、図１０に示したＰｒｏｔｅｃｔｅｄ ＲＴＴ Ｐｒｏｔｏｃｏｌ手続きでは、「Ｃｈａｌｌｅｎｇｅ−Ｒｅｓｐｏｎｓｅ ｐｏｒｔｉｏｎ」と書かれた処理フェーズ（ＳＥＱ９０５、ＳＥＱ１０００）の中で、ＳｉｎｋデバイスからのＣＨＡＬＬＥＮＧＥコマンド送信からＳｏｕｒｃｅデバイスからのＲＥＳＰＯＮＳＥ又はＲＥＳＰＯＮＳＥ２の送信に対するＳｉｎｋデバイスからの応答送信までのシーケンスを含んでいるが、ここで送られるＤｅｖｉｃｅ ＣｅｒｔｉｆｉｃａｔｅにＥＳフラグを格納することにより、所定のセキュリティー強化策を施していること（暗号方式以外のより脆弱な部分の安全性については確保できていること）をＳｏｕｒｃｅデバイスに通知することができる。
また、ＥＳフラグを、図１６に示したようにＤｅｖｉｃｅ Ｃｅｒｔｉｆｉｃａｔｅに含める以外に、ＤＴＣＰのＡＫＥ処理中に送られるコマンドに含めて送る方法も考えられる。図１７には、このコマンドで送られるペイロードの具体的な構成例を示している。ペイロード１７００のＳＩＮＫ−ＣＡＰＡＢＩＬＩＴＹフィールド１７０１には、ＥＳフラグ１７０２が格納されている。さらに、Ｓｉｎｋデバイス自身のＤｅｖｉｃｅ Ｐｒｉｖａｔｅ Ｋｅｙ（秘密鍵）を使って、上記のＳＩＮＫ−ＣＡＰＡＢＩＬＩＴＹフィールド１７０１のデータについて計算された電子署名を含むＳＩＮＫ−ＳＩＧＮＡＴＵＲＥフィールド１７０３を伴うことで、伝送中の改ざんを防止する。
ここで、ＳＩＮＫ−ＣＡＰＡＢＩＬＩＴＹフィールド１７０１は、ＥＳフラグ１７０２の他に、ＮＳフラグ１７０４も含んでいる。ＮＳフラグは、デバイスが新しい暗号方式（Ｎｅｗ Ｓｙｓｔｅｍ）に対応しているか否かを示すために定義されたフラグである。新しい暗号方式に対応したＳｉｎｋデバイスは、ＮＳフラグ＝１を書き込んで、相手に通知するようにしている。高価値コンテンツを扱えるＳｉｎｋデバイスは、新しい暗号方式に対応する場合もしない場合も、ＮＳフラグを含むコマンドをＡＫＥ処理の中で必ず送るものとする。そしてＳｏｕｒｃｅデバイスはＡＫＥ処理の中で、ＳｉｎｋのＥＳフラグが１である場合、ＮＳフラグを含むコマンドが同ＡＫＥ処理の中で受信されることを確認し、それができない場合は異常なＡＫＥ処理と判断する。例えばＳｉｎｋデバイスがＥＳフラグをＤｅｖｉｃｅ Ｃｅｒｔｉｆｉｃａｔｅに格納して送信する場合（図１６を参照のこと）、Ｓｏｕｒｃｅデバイスは、ＮＳフラグを含むコマンドを万一ＡＫＥ処理の中で受信できなければ、そのＡＫＥ処理をエラーとして中断する。
Ｓｉｎｋデバイスは、図１７に示したデータ１７００を、例えば図９に示したＭＯＶＥ ＲＴＴ−ＡＫＥ手続き中のＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥ．ＣＭＤメッセージ（ＳＥＱ９０３）のペイロードに含めて送ることができる。
また、詳細な説明を省略するが、ＲＴＴ−ＡＫＥ処理や、リモート・アクセス時の事前登録処理の中でも、Ｓｉｎｋデバイスは、図１７に示したデータ１７００を送ることができる。その他のＡＫＥ処理（例えば、ＲＡ−ＡＫＥ）でも、Ｓｉｎｋデバイスは、図１７に示したデータ１７００を送ることができる。
一方、Ｓｏｕｒｃｅデバイスは、図１７に示したようなコマンドへの応答で送られるペイロードにＮＳフラグを格納して、新しい暗号方式に対応しているかどうかを示すことができる。図１８には、このようなペイロードの具体的な構成例を示している。
ペイロード１８００のＳＯＵＲＣＥ−ＣＡＰＡＢＩＬＩＴＹフィールド１８０１には、ＮＳフラグ１８０２が格納されている。新しい暗号方式に対応したＳｏｕｒｃｅデバイスは、ＮＳフラグ＝１を書き込んで、相手に通知するようにしている。さらに、Ｓｏｕｒｃｅデバイス自身のＤｅｖｉｃｅ Ｐｒｉｖａｔｅ Ｋｅｙ（秘密鍵）を使って、上記のＳＯＵＲＣＥ−ＣＡＰＡＢＩＬＩＴＹフィールド１８０１のデータについて計算された電子署名を含むＳＯＵＲＣＥ−ＳＩＧＮＡＴＵＲＥフィールド１８０３を伴うことで、伝送中の改ざんを防止する。
所定のセキュリティー強化策を施したＳｏｕｒｃｅデバイスは、図１６又は図１７に示したような形式でＳｉｎｋデバイスから受け取ったＥＳフラグを参照して、高価値コンテンツを扱える共通鍵ＫX1、又は、高価値コンテンツを扱えない共通鍵ＫX2のいずれをＳｉｎｋデバイスに渡すかを決定する。
図１９には、Ｓｏｕｒｃｅデバイスが共通鍵を決定するための処理手順を、フローチャートの形式で示している。この処理は、主にＳｏｕｒｃｅデバイス内の認証・鍵共有部３０６で行なわれる。
まず、認証・鍵共有部３０６は、Ｓｉｎｋデバイスから送られてきたＥＳフラグが１かどうかをチェックする（ステップＳ１９０１）。
ここで、ＥＳフラグが１でない場合には（ステップＳ１９０１のＮｏ）、認証・鍵共有部３０６は、高価値コンテンツを扱えない共通鍵ＫX2を生成して、通信・制御部３０１からＳｉｎｋデバイスに送付する（ステップＳ１９０４）。この場合、Ｓｏｕｒｃｅデバイスは、高価値コンテンツ以外しかＳｉｎｋデバイスに伝送することはできない。
一方、ＥＳフラグが１の場合には（ステップＳ１９０１のＹｅｓ）、認証・鍵共有部３０６は、ＮＳフラグを含むコマンドをＡＫＥ処理の中で受信したかどうかをさらにチェックする（ステップＳ１９０２）。
ＮＳフラグを含むコマンドを万一ＡＫＥ処理の中で受信できなければ（ステップＳ１９０２のＮｏ）、認証・鍵共有部３０６は、そのＡＫＥ処理をエラーとして中断する。
また、ＮＳフラグを含むコマンドをＡＫＥ処理の中で受信できたときには（ステップＳ１９０２のＹｅｓ）、認証・鍵共有部３０６は、高価値コンテンツを扱うことができる共通鍵ＫX1を生成して、通信・制御部３０１からＳｉｎｋデバイスに送付する（ステップＳ１９０３）。
よりセキュリティー・レベルの高いコンテンツ伝送を実現するには、Ｓｏｕｒｃｅデバイス及びＳｉｎｋデバイスの双方で、新しい暗号方式を優先的に実行するようにすることが好ましい。新しい暗号方式への完全移行を早期化することにもつながる。
図２０には、Ｓｉｎｋデバイス側で新しい暗号方式を優先的に実行するための処理手順をフローチャートの形式で示している。この処理は、新しい暗号方式に対応したＳｉｎｋデバイス内の認証・鍵共有部４０６でＡＫＥ処理中に行なわれる。
認証・鍵共有部４０６は、ＡＫＥ処理中に、ＮＳフラグ＝１を格納したコマンドを通信・制御部４０１を介してＳｏｕｒｃｅデバイスに送信し、自分が新しい暗号方式に対応していることを示す（ステップＳ２００１）。
次いで、認証・鍵共有部４０６は、新しい暗号方式の有無を示す（すなわち、ＮＳフラグを格納した）コマンドの応答受信がタイムアウトするまでの間（ステップＳ２００２のＮｏ）、通信・制御部４０１を通じてＳｏｕｒｃｅデバイスから新しい暗号方式の有無を示すコマンドの応答受信を待機する（ステップＳ２００３のＮｏ）。
ここで、新しい暗号方式の有無を示すコマンドの応答受信がタイムアウトすると（ステップＳ２００２のＹｅｓ）、認証・鍵共有部４０６は、Ｓｏｕｒｃｅデバイスが新しい暗号方式に対応していないと判断して、通信・制御部４０１を通じてＳｏｕｒｃｅデバイスに従来の暗号方式でのコンテンツ伝送を要求する（ステップＳ２００６）。
また、Ｓｏｕｒｃｅデバイスから新しい暗号方式の有無を示すコマンドの応答を受信することができたときには（ステップＳ２００３のＹｅｓ）、認証・鍵共有部４０６は、そのコマンド応答に格納されているＮＳフラグを参照して、Ｓｏｕｒｃｅデバイスが新しい暗号方式に対応しているかどうかをチェックする（ステップＳ２００４）。
ＮＳフラグ＝１で、Ｓｏｕｒｃｅデバイスが新しい暗号方式に対応していることが分かった場合には（ステップＳ２００４のＹｅｓ）、認証・鍵共有部４０６は、通信・制御部４０１を通じてＳｏｕｒｃｅデバイスに新しい暗号方式でのコンテンツ伝送を要求する（ステップＳ２００５）。
また、ＮＳフラグ＝０で、Ｓｏｕｒｃｅデバイスが新しい暗号方式に対応していないことが分かった場合には（ステップＳ２００４のＮｏ）、認証・鍵共有部４０６は、Ｓｏｕｒｃｅデバイスが新しい暗号方式に対応していないと判断して、通信・制御部４０１を通じてＳｏｕｒｃｅデバイスに従来の暗号方式でのコンテンツ伝送を要求する（ステップＳ２００６）。
また、図２１には、Ｓｏｕｒｃｅデバイス側で新しい暗号方式を優先的に実行するための処理手順をフローチャートの形式で示している。この処理は、新しい暗号方式に対応したＳｏｕｒｃｅデバイス内の認証・鍵共有部３０６でＡＫＥ処理中に行なわれる。
まず、認証・鍵共有部３０６は、Ｓｉｎｋデバイスが従来の暗号方式でのコンテンツ伝送を要求しているかどうかをチェックする（ステップＳ２１０１）。
ここで、Ｓｉｎｋデバイスが従来の暗号方式でのコンテンツ伝送を要求した場合には（ステップＳ２１０１のＹｅｓ）、認証・鍵共有部３０６は、Ｓｉｎｋデバイスへのコンテンツ伝送に、従来の暗号方式を使用することを決定する（ステップＳ２１０６）。
また、Ｓｉｎｋデバイスが従来の暗号方式でのコンテンツ伝送を要求しない場合には（ステップＳ２１０１のＮｏ）、認証・鍵共有部３０６は、新しい暗号方式の有無を示す（すなわち、ＮＳフラグを格納した）コマンドを、通信・制御部３０１を通じて受信するまで待機する（ステップＳ２１０２のＮｏ）。
新しい暗号方式の有無を示すコマンドを受信すると（ステップＳ２１０２のＹｅｓ）、認証・鍵共有部３０６は、そのコマンドに格納されているＮＳフラグを参照して、Ｓｉｎｋデバイスが新しい暗号方式に対応しているかどうかをチェックする（ステップＳ２１０３）。
Ｓｉｎｋデバイスが新しい暗号方式に対応している場合には（ステップＳ２１０３のＹｅｓ）、認証・鍵共有部３０６は、Ｓｉｎｋデバイスが従来の暗号方式でのコンテンツ伝送を要求しているかどうかをさらにチェックする（ステップＳ２１０４）。そして、Ｓｉｎｋデバイスが従来の暗号方式でのコンテンツ伝送を要求している場合には（ステップＳ２１０４のＹｅｓ）、認証・鍵共有部３０６は、Ｓｉｎｋデバイスへのコンテンツ伝送に、新しい暗号方式を使用することを決定する（ステップＳ２１０５）。
また、Ｓｉｎｋデバイスが新しい暗号方式に対応していない場合や（ステップＳ２１０３のＮｏ）、Ｓｉｎｋデバイスが従来の暗号方式でのコンテンツ伝送を要求していない場合には（ステップＳ２１０４のＮｏ）、認証・鍵共有部３０６は、Ｓｉｎｋデバイスへのコンテンツ伝送に、従来の暗号方式を使用することを決定する（ステップＳ２１０６）。
上述したように、本明細書で開示する技術を適用したコンテンツ伝送システムは、暗号方式を新しくしたより安全なシステムへの移行を段階的に行なえるようにすることで、時間やコストの負担の軽減を図るものである。すなわち、所定のセキュリティー強化策を施した移行段階の装置（例えば、従来の暗号アルゴリズムにしか対応していないが、暗号方式以外のより脆弱な部分の安全性については確保できている装置）に対しては、一定のシステム移行期間だけは高価値コンテンツを扱えるようにしている。この結果、移行に要する時間的な問題を回避し、安全なシステムへの移行を円滑にすることができる。また、装置が備えるコスト当たりの処理能力は一般的に年々増加する傾向にあり、より計算量が必要な暗号アルゴリズムの負担も、上記のような長期的な対応によって軽減できる可能性が高い。
したがって、本明細書で開示する技術によれば、すべてのコンテンツ送信装置及びコンテンツ受信装置が新しい暗号方式に完全移行するまでの一定の期間においても、さしあたって必要不可欠な保護でコンテンツの安全性を維持しつつ、長期的にはより安全な新システムへの完全移行を、装置に大きな負担をかけずに実施することが可能となる。
なお、図２に示したコンテンツ伝送システム２００において、サーバー２０１若しくはＤＴＣＰのＳｏｕｒｃｅデバイスとして動作するコンテンツ送信装置の具体例として、セットトップボックスやレコーダー、テレビジョン受信機、パーソナル・コンピューター、ネットワーク・アクセス・サーバー（ＮＡＳ）などを挙げることができる。
図２３には、サーバー２０１若しくはＤＴＣＰのＳｏｕｒｃｅデバイスとして動作することが可能なパーソナル・コンピューター２３００の構成例を示している。パーソナル・コンピューター２３００はリモート・アクセス機能（前述）にも対応しているものとする。図示のパーソナル・コンピューター２３００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２３０１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２３０２、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）２３０３、ディスプレイ２３０４、スピーカー２３０５、例えばＨＤＤ（Ｈａｒｄ Ｄｉｓｃ Ｄｒｉｖｅ）やＳＤＤ（Ｓｕｐｅｒ Ｄｅｎｓｉｔｙ Ｄｉｓｃ）などの大容量情報記憶装置２３０６、Ｉ／Ｏインターフェース２３０７などの回路コンポーネントを備え、これらの回路コンポーネントがバス２３０８を介して相互接続されている。
ＣＰＵ２３０１は、メイン・メモリーとしてのＲＡＭ２３０２にロードされたプログラムを読み出して実行する。
ＲＡＭ２３０２には、コンテンツの暗号及び復号に関する機能がロードされる。例えば、ＤＴＣＰ＋機能を実行するためのプログラム、及び、ＲＡ−ＡＫＥ処理を実行するためのプログラムがＲＡＭ２３０２にロードされる。
ＥＥＰＲＯＭ２３０３は、書き換えが可能な不揮発性記憶装置であり、設定情報などが記憶される。パーソナル・コンピューター２３００がＳｏｕｒｃｅデバイスすなわちコンテンツ送信装置として動作する場合、ＳｉｎｋデバイスのＳｉｎｋ−ＩＤを含むＲＡＣ ｒｅｃｏｒｄがＥＥＰＲＯＭ２５０３に記憶される。
パーソナル・コンピューター２３００上では、Ｓｉｎｋデバイスから、リモート・アクセスが可能な端末として登録するよう要求を受けると、ＣＰＵ２５０１が、ＲＡＭ２３０２からＤＴＣＰ＋のＡＫＥ処理が記述されたプログラムを読み出し、Ｓｉｎｋデバイスとの間でＡＫＥ手続きを実行する。この手続きに成功すると、ＣＰＵ２３０１は、ＲＡＭ２３０２に記憶されたプログラムに従って交換鍵ＫR及びそのラベルＫR＿ｌａｂｅｌを生成し、Ｓｉｎｋ ＩＤと対応付けたＲＡＣ ｒｅｃｏｒｄとしてＥＥＰＲＯＭ２３０３に記憶する。
その後、パーソナル・コンピューター２３００上では、ＣＰＵ２３０１が、ＲＡ−ＡＫＥ処理の要求を受けた場合に、この要求を行なっているＳｉｎｋデバイスのＳｉｎｋ−ＩＤと、ＥＥＰＲＯＭ２３０３に記憶されたＳｉｎｋ−ＩＤと比較し、ＲＡ−ＡＫＥ処理を完了させるか否かを決定する処理を実行する。
そして、ＲＡ−ＡＫＥ処理が完了すると、パーソナル・コンピューター２３００と、ＲＡ−ＡＫＥ処理の要求を行なったＳｉｎｋデバイスとの間で共通する交換鍵が生成される。パーソナル・コンピューター２３００側では、交換鍵を基に生成したコンテンツ鍵を一時的に記憶し、大容量情報記憶装置２３０６からコンテンツを読み出したときに、このコンテンツを一時的に記憶されたコンテンツ鍵で暗号化する。暗号化されたコンテンツは、Ｉ／Ｏインターフェース２３０８を経て、外部に出力される。Ｉ／Ｏインターフェース２３０８が無線ＬＡＮ機能を有している場合、無線ＬＡＮを介して、ＲＡ−ＡＫＥ処理の要求を行なったＳｉｎｋデバイスに対し、暗号化コンテンツが送信される。
図２４には、サーバー２０１若しくはＤＴＣＰのＳｏｕｒｃｅデバイスとして動作することが可能なレコーダー２４００の構成例を示している。レコーダー２４００はリモート・アクセス機能（前述）にも対応しているものとする。図示のレコーダー２４００は、システム・チップ２４０１、大容量記憶装置２４０２、ＲＡＭ２４０３、ＥＥＰＲＯＭ２４０４、無線ＬＡＮチップ２４０５又はＬＡＮポート２４０９のうち少なくとも一方、チューナー２４０６、ディスプレイ２４０７、スピーカー２４０８を備えている。
システム・チップ２４０１は、ＣＰＵ２４０１ａ、コプロセッサー２４０１ｂ、インターフェース機能部２４０１ｃなどの回路モジュールを備え、これらの回路モジュールは、当該チップ内のバス２４０１ｄで相互接続されている。
ＣＰＵ２４０１ａは、インターフェース機能部２４０１ｃを介して接続された記憶装置に記憶されたプログラムを実行することが可能である。
コプロセッサー２４０１ｂは、補助演算装置であり、主に動画像の圧縮又は復号処理を実行する。例えば、Ｈ２６４、ＶＣ１、ＭＰＥＧ２、ＪＰＥＧなどのアルゴリズムを実行する。また、コプロセッサー２４０１ｂは、（大容量記憶装置２４０２に記憶された）動画像コンテンツをＳｉｎｋデバイスなどのコンテンツ受信装置に伝送する際には、通信速度などの通信環境に応じて画像のサイズを変換して、通信環境に最適なサイズで送信できるようにする処理、すなわちコーデックのトランスコーディングを行なう。コーデックのトランスコードにより、Ｓｉｎｋデバイスなどのコンテンツ伝送先での再生の遅れを軽減することができる。但し、コーデックのトランスコーディングは、コプロセッサー２４０１ｂのような専用ハードウェアではなく、ＣＰＵ２４０１ａで行なうようにすることもできる。また、コンテンツのトランスコーディングを行なう圧縮率は、ユーザーがコンテンツ毎に指定することも可能である。
大容量記憶装置２４０２は、例えばＨＤＤやＳＤＤなどであるが、Ｓｉｎｋデバイス若しくはコンテンツ受信装置に提供するコンテンツを記憶する。
チューナー２４０６は、地上ディジタル放送などの放送信号を選局受信する。本実施形態では、例えばＥＰＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ）などの機能に従って、番組を録画又は録画予約して、放送コンテンツを大容量記憶装置２４０２に記憶する。
チューナー２４０６で受信する放送番組や、大容量記憶装置２４０２に記憶したコンテンツは、ディスプレイ２４０７並びに２４０８を使って視聴することも可能である。
無線ＬＡＮチップ２４０５は、例えばＷｉ−Ｆｉ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ）若しくはＩＥＥＥ８０２．１１などの無線ＬＡＮ規格における物理層並びにＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）層の処理を行ない、所定のアクセスポイント経由で、あるいはＳｉｎｋデバイスとしてのコンテンツ受信装置と直接無線接続する。また、ＬＡＮポート２４０９は、差し込まれたＬＡＮケーブル２４０９Ａを介してＥｔｈｅｒｎｅｔ（登録商標）などの有線ＬＡＮ（図示しない）に接続されるとともに、例えばＩＥＥＥ８０２．３などの有線ＬＡＮ規格における物理層並びにＭＡＣ層の処理を行ない、Ｓｉｎｋデバイスとしてのコンテンツ受信装置と通信する。
メイン・メモリーとしてのＲＡＭ２４０３には、ＣＰＵ２４０１ａで実行されるプログラムがロードされる。ＲＡＭ２４０３にロードされる主なプログラムは、コンテンツの暗号及び復号に関する機能を実現するプログラムであり、例えば、ＤＴＣＰ＋機能を実行するためのプログラム、及び、ＲＡ−ＡＫＥ処理を実行するためのプログラムがＲＡＭ２４０３にロードされる。
ＥＥＰＲＯＭ２４０４は、書き換えが可能な不揮発性記憶装置であり、設定情報などが記憶される。レコーダー２４００がＳｏｕｒｃｅデバイスすなわちコンテンツ送信装置として動作する場合、ＳｉｎｋデバイスのＳｉｎｋ−ＩＤを含んだＲＡＣ ｒｅｃｏｒｄがＥＥＰＲＯＭ２４０４に記憶される。
レコーダー２４００上では、Ｓｉｎｋデバイスから、リモート・アクセスが可能な端末として登録するよう要求を受けると、ＣＰＵ２４０１ａが、ＲＡＭ２４０３からＤＴＣＰ−ＩＰのＡＫＥ処理が記述されたプログラムを読み出し、Ｓｉｎｋデバイスとの間でＡＫＥ手続きを実行する。この手続きに成功すると、ＣＰＵ２４０１ａは、ＲＡＭ２４０３に記憶されたプログラムに従って交換鍵ＫR及びそのラベルＫR＿ｌａｂｅｌを生成し、Ｓｉｎｋ−ＩＤと対応付けたＲＡＣ ｒｅｃｏｒｄとしてＥＥＰＲＯＭ２４０４に記憶する。
その後、レコーダー２４００上では、ＣＰＵ２４０１ａが、ＲＡ−ＡＫＥ処理の要求を受けた場合に、この要求を行なっているＳｉｎｋデバイスのＳｉｎｋ−ＩＤと、ＥＥＰＲＯＭ２４０４に記憶されたＳｉｎｋデバイスのＳｉｎｋＩＤを比較し、ＲＡ−ＡＫＥ処理を完了させるか否かを決定する処理を実行する。
そして、ＲＡ−ＡＫＥ処理が完了すると、レコーダー２４００と、ＲＡ−ＡＫＥ処理の要求を行なったＳｉｎｋデバイスとの間で共通するコンテンツ鍵が生成される。レコーダー２４００側では、生成されたコンテンツ鍵を一時的に記憶し、大容量情報記憶装置２４０２からコンテンツを読み出したときに、このコンテンツを一時的に記憶されたコンテンツ鍵で暗号化する。暗号化されたコンテンツは、インターフェース機能部２４０１ｃ及び無線ＬＡＮチップ２４０５を経て、ＲＡ−ＡＫＥ処理の要求を行なった端末に対し、暗号化コンテンツが送信される。
図２５には、サーバー２０１若しくはＤＴＣＰのＳｏｕｒｃｅデバイスとして動作することが可能なネットワーク・アクセス・サーバー（ＮＡＳ）２５００の構成例を示している。
ネットワーク・アクセス・サーバー２５００は、大容量記憶装置を備え、ホーム・ネットワーク１１０、２１０内に設置されて、大容量記憶装置内の情報をＩＰプロトコルに従って伝送する。例えば、レコーダー２５００で録画した放送コンテンツをネットワーク・アクセス・サーバー２５００にダビングしたり、ネットワーク・アクセス・サーバー２５００内に記憶したコンテンツをパーソナル・コンピューター２３００やスマートフォンなどのＳｉｎｋデバイスに伝送して視聴したりすることができる。また、ネットワーク・アクセス・サーバー２５００は、リモート・アクセス機能にも対応しているものとする。
図示のネットワーク・アクセス・サーバー２５００は、システム・チップ２５０１、大容量記憶装置２５０２、ＲＡＭ２５０３、ＥＥＰＲＯＭ２５０４、無線ＬＡＮチップ２５０５又はＬＡＮポート２５０６のうち少なくとも一方を備えている。
システム・チップ２５０１は、ＣＰＵ２５０１ａ、コプロセッサー２５０１ｂ、インターフェース機能部２５０１ｃなどの回路モジュールを備え、これらの回路モジュールは、当該チップ内のバス２５０１ｄで相互接続されている。
ＣＰＵ２５０１ａは、インターフェース機能部２５０１ｃを介して接続された記憶装置に記憶されたプログラムを実行することが可能である。
コプロセッサー２５０１ｂは、補助演算装置であり、主に動画像の圧縮又は復号処理を実行する。例えば、Ｈ２６４、ＶＣ１、ＭＰＥＧ２、ＪＰＥＧなどのアルゴリズムを実行する。また、コプロセッサー２５０１ｂは、（大容量記憶装置２５０２に記憶された）動画像コンテンツをＳｉｎｋデバイスなどのコンテンツ受信装置に伝送する際には、通信速度などの通信環境に応じて画像のサイズを変換して、通信環境に最適なサイズで送信できるようにする処理、すなわちコーデックのトランスコーディングを行なう。コーデックのトランスコードにより、Ｓｉｎｋデバイスなどのコンテンツ伝送先での再生の遅れを軽減することができる。但し、コーデックのトランスコーディングは、コプロセッサー２５０１ｂのような専用ハードウェアではなく、ＣＰＵ２５０１ａで行なうようにすることもできる。また、コンテンツのトランスコーディングを行なう圧縮率は、ユーザーがコンテンツ毎に指定することも可能である。
大容量記憶装置２５０２は、例えばＨＤＤやＳＤＤなどであるが、Ｓｉｎｋデバイス若しくはコンテンツ受信装置に提供するコンテンツを記憶する。例えば、ネットワーク・アクセス・サーバー２５００で録画した放送コンテンツを、（無線ＬＡＮチップ２７０５経由で受信して）大容量記憶装置２５０２にダビングすることもできる。
無線ＬＡＮチップ２５０５は、例えばＷｉ−Ｆｉ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ）若しくはＩＥＥＥ８０２．１１などの無線ＬＡＮ規格における物理層並びにＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）層の処理を行ない、所定のアクセスポイント経由で、あるいはＳｉｎｋデバイスとしてのコンテンツ受信装置と直接無線接続する。また、ＬＡＮポート２５０６は、差し込まれたＬＡＮケーブル２５０６Ａを介してＥｔｈｅｒｎｅｔ（登録商標）などの有線ＬＡＮ（図示しない）に接続されるとともに、例えばＩＥＥＥ８０２．３などの有線ＬＡＮ規格における物理層並びにＭＡＣ層の処理を行ない、Ｓｉｎｋデバイスとしてのコンテンツ受信装置と通信する。
メイン・メモリーとしてのＲＡＭ２５０３には、ＣＰＵ２５０１ａで実行されるプログラムがロードされる。ＲＡＭ２５０３にロードされる主なプログラムは、コンテンツの暗号及び復号に関する機能を実現するプログラムであり、例えば、ＤＴＣＰ−ＩＰ機能を実行するためのプログラム、及び、ＲＡ−ＡＫＥ処理を実行するためのプログラムがＲＡＭ２５０３にロードされる。
ＥＥＰＲＯＭ２５０４は、書き換えが可能な不揮発性記憶装置であり、設定情報などが記憶される。ネットワーク・アクセス・サーバー２５００がＳｏｕｒｃｅデバイスすなわちコンテンツ送信装置として動作する場合、ＳｉｎｋデバイスのＳｉｎｋ−ＩＤを含むＲＡＣ ｒｅｃｏｒｄがＥＥＰＲＯＭ２５０４に記憶される。
ネットワーク・アクセス・サーバー２５００上では、Ｓｉｎｋデバイスから、リモート・アクセスが可能な端末として登録するよう要求を受けると、ＣＰＵ２５０１ａが、ＲＡＭ２５０３からＤＴＣＰ＋のＡＫＥ処理が記述されたプログラムを読み出し、Ｓｉｎｋデバイスとの間でＡＫＥ手続きを実行する。この手続きに成功すると、ＣＰＵ２５０１ａは、ＲＡＭ２５０３に記憶されたプログラムに従って交換鍵ＫR及びそのラベルＫR＿ｌａｂｅｌを付与し、Ｓｉｎｋ−ＩＤとペアにしてＥＥＰＲＯＭ２５０４に記憶する。
その後、ネットワーク・アクセス・サーバー２５００上では、ＣＰＵ２５０１ａが、ＲＡ−ＡＫＥ処理の要求を受けた場合に、この要求を行なっているＳｉｎｋデバイスのＳｉｎｋ−ＩＤと、ＥＥＰＲＯＭ２５０４に記憶されたＳｉｎｋデバイスのＳｉｎｋＩＤを比較し、ＲＡ−ＡＫＥ処理を完了させるか否かを決定する処理を実行する。
そして、ＲＡ−ＡＫＥ処理が終了すると、ネットワーク・アクセス・サーバー２５００と、ＲＡ−ＡＫＥ処理の要求を行なったＳｉｎｋデバイスとの間で共通するコンテンツ鍵が生成される。ネットワーク・アクセス・サーバー２５００側では、生成されたコンテンツ鍵を一時的に記憶し、大容量情報記憶装置２５０２からコンテンツを読み出したときに、このコンテンツを一時的に記憶されたコンテンツ鍵で暗号化する。暗号化されたコンテンツは、インターフェース機能部２５０１ｃ及び無線ＬＡＮチップ２５０５を経て、ＲＡ−ＡＫＥ処理の要求を行なった端末に対し、暗号化コンテンツが送信される。
特開２００９−２６７９００号公報
以上、特定の実施形態を参照しながら、本明細書で開示する技術について詳細に説明してきた。しかしながら、本明細書で開示する技術の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
本明細書では、本明細書で開示する技術をＤＴＣＰ並びにＤＴＣＰ−ＩＰ仕様のネットワークに適用した実施形態を中心に説明してきたが、本明細書で開示する技術の要旨はこれに限定されるものではない。ＤＴＣＰ若しくはＤＴＣＰ−ＩＰ以外の技術仕様に基づくネットワーク上の機器間でコンテンツの移動を行なうコンテンツ伝送システムにも、同様に本明細書で開示する技術で開示する技術を適用することができる。
すなわち、本明細書で開示する技術をさまざまな伝送規格のシステムに適用して、すべての装置が新しい暗号方式に対応できない一定の期間においても、さしあたって必要不可欠な保護でコンテンツの安全性を維持しつつ、長期的にはより安全な新システムへの完全移行を、装置に大きな負担をかけずに実施することが可能となる。
要するに、例示という形態により本明細書で開示する技術について説明してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本明細書で開示する技術の要旨を判断するためには、特許請求の範囲を参酌すべきである。
なお、本明細書の開示の技術は、以下のような構成をとることも可能である。
（１）所定の伝送規格に従って、コンテンツ受信装置と相互認証及び共有鍵の引き渡しを行なう認証・鍵共有部と、
前記共有鍵から生成した暗号鍵を用いてコンテンツを前記コンテンツ受信装置へ暗号化伝送するコンテンツ提供部と、
を具備し、
前記認証・鍵共有部は、前記コンテンツ受信装置が所定のセキュリティー強度を有しているか否かに応じて、引き渡す共有鍵を切り替える、
コンテンツ送信装置。
（２）前記所定の伝送規格は、ＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）若しくはＤＴＣＰ−ＩＰ（ＤＴＣＰ ｍａｐｐｉｎｇ ｔｏ ＩＰ）である、
上記（１）に記載のコンテンツ送信装置。
（３）前記認証・鍵共有部は、前記所定のセキュリティー強度を有したコンテンツ受信装置には第１のコンテンツを扱うことができる第１の共有鍵を引き渡し、前記所定のセキュリティー強度を有していないコンテンツ受信装置には第１のコンテンツを扱うことができない第２の共有鍵を引き渡す、
上記（１）に記載のコンテンツ送信装置。
（４）前記所定のセキュリティー強化策は、暗号方式以外のより脆弱な部分の安全性が確保されていることである、
上記（３）に記載のコンテンツ送信装置。
（５）前記コンテンツ提供部は、前記第１の共有鍵から生成した暗号鍵で第１のコンテンツを暗号化伝送するが、前記第２の共有鍵から生成した暗号鍵では第１のコンテンツを暗号化伝送しない、
上記（３）に記載のコンテンツ送信装置。
（６）前記第１の共有鍵及び前記第２の共有鍵は第１の暗号方式に従う暗号鍵を生成するための共有鍵であり、
前記認証・鍵共有部は、前記第１の暗号方式にしか対応しないコンテンツ受信装置には前記第１の共有鍵又は前記第２の共有鍵を引き渡すが、第２の暗号方式に対応するコンテンツ受信装置には前記第２の暗号方式に従う暗号鍵を生成するための共有鍵を引き渡す、
上記（３）に記載のコンテンツ送信装置。
（７）前記認証・鍵共有部は、相互認証時に前記コンテンツ受信装置から送られてくる機器証明書に格納されたＥＳフラグに基づいて、前記コンテンツ受信装置が前記所定のセキュリティー強度を有する機器か否かを判別する、
上記（３）に記載のコンテンツ送信装置。
（８）前記認証・鍵共有部は、相互認証時に前記コンテンツ受信装置から送られてくるコマンドのペイロードのＣＡＰＡＢＩＬＩＴＹフィールドに格納されたＥＳフラグに基づいて、前記コンテンツ受信装置が前記所定のセキュリティー強度を有する機器か否かを判別する、
上記（３）に記載のコンテンツ送信装置。
（９）前記認証・鍵共有部は、相互認証時に前記コンテンツ受信装置から送られてくるコマンドのペイロードのＣＡＰＡＢＩＬＩＴＹフィールドに格納されたＮＳフラグに基づいて、前記コンテンツ受信装置が前記第２の暗号方式に対応しているか否かを判別する、
上記（８）に記載のコンテンツ送信装置。
（１０）前記ＣＡＰＡＢＩＬＩＴＹフィールドは、前記コンテンツ受信装置の秘密鍵を使って当該フィールドのデータから計算された電子署名を伴う、
上記（８）又は（９）のいずれかに記載のコンテンツ送信装置。
（１１）前記認証・鍵共有部は、前記コンテンツ受信装置から送られてきた機器証明書にＥＳフラグが格納されていることを確認したが、相互認証時のコマンド内でＮＳフラグを確認できないときには、その相互認証処理をエラーとして中断する、
上記（９）に記載のコンテンツ送信装置。
（１２）前記認証・鍵共有部は、相互認証時に前記コンテンツ受信装置に送るコマンドのペイロードのＣＡＰＡＢＩＬＩＴＹフィールドに、第２の暗号方式への対応の有無を示すＮＳフラグを格納する、
上記（３）に記載のコンテンツ送信装置。
（１３）前記認証・鍵共有部は、前記ＣＡＰＡＢＩＬＩＴＹフィールドに、自分の秘密鍵を使って当該フィールドのデータから計算された電子署名を伴わせる、
上記（１２）に記載のコンテンツ送信装置。
（１４）所定の伝送規格に従って、コンテンツ受信装置と相互認証及び共有鍵の引き渡しを行なう認証・鍵共有ステップと、
前記共有鍵から生成した暗号鍵を用いてコンテンツを前記コンテンツ受信装置へ暗号化伝送するコンテンツ提供ステップと、
を有し、
前記認証・鍵共有ステップでは、前記コンテンツ受信装置が所定のセキュリティー強度を有しているか否かに応じて、引き渡す共有鍵を切り替える、
コンテンツ送信方法。
（１５）所定の伝送規格に従って、コンテンツ送信装置と相互認証及び共有鍵の受け取りを行なう認証・鍵共有部と、
前記の受け取った共有鍵から生成した暗号鍵を用いて暗号化伝送されたコンテンツを取得するコンテンツ取得部と、
を具備し、
前記認証・鍵共有部は、自分が所定のセキュリティー強度を有していることに応じた共有鍵を受け取る、
コンテンツ受信装置。
（１６）前記所定の伝送規格は、ＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）若しくはＤＴＣＰ−ＩＰ（ＤＴＣＰ ｍａｐｐｉｎｇ ｔｏ ＩＰ）である、
上記（１５）に記載のコンテンツ受信装置。
（１７）前記認証・鍵共有部は、自分が所定のセキュリティー強度を有していることに応じて、第１のコンテンツを扱うことができる第１の共有鍵を受け取り、
前記コンテンツ取得部は、前記第１の共有鍵から生成した暗号鍵で暗号化伝送された第１のコンテンツを取得する、
上記（１５）に記載のコンテンツ受信装置。
（１８）前記所定のセキュリティー強化策は、暗号方式以外のより脆弱な部分の安全性を確保することである、
上記（１５）に記載のコンテンツ受信装置。
（１９）前記認証・鍵共有部は、相互認証時に前記コンテンツ送信装置に送る機器証明書に、自分が前記所定のセキュリティー強度を有しているか否かを示すＥＳフラグを格納する、
上記（１５）に記載のコンテンツ受信装置。
（２０）前記認証・鍵共有部は、相互認証時に前記コンテンツ送信装置に送るコマンドのペイロードのＣＡＰＡＢＩＬＩＴＹフィールドに、自分が前記所定のセキュリティー強度を有しているか否かを示すＥＳフラグを格納する、
上記（１５）に記載のコンテンツ受信装置。
（２１）前記認証・鍵共有部は、相互認証時に前記コンテンツ送信装置に送るコマンドのペイロードのＣＡＰＡＢＩＬＩＴＹフィールドに、自分が暗号方式に対応しているか否かを示すＮＳフラグを格納する、
上記（１５）に記載のコンテンツ受信装置。
（２２）前記認証・鍵共有部は、前記ＣＡＰＡＢＩＬＩＴＹフィールドに、自分の秘密鍵を使って当該フィールドのデータから計算された電子署名を伴わせる、
上記（２０）又は（２１）のいずれかに記載のコンテンツ送信装置。
（２３）所定の伝送規格に従って、コンテンツ送信装置と相互認証及び共有鍵の受け取りを行なう認証・鍵共有ステップと、
前記の受け取った共有鍵から生成した暗号鍵を用いて暗号化伝送されたコンテンツを取得するコンテンツ取得ステップと、
を有し、
前記認証・鍵共有ステップでは、自分が所定のセキュリティー強度を有していることに応じた共有鍵を受け取る、
コンテンツ受信方法。
（２４）所定の伝送規格に従って、コンテンツ受信装置と相互認証及び共有鍵の引き渡しを行なう認証・鍵共有部、
前記共有鍵から生成した暗号鍵を用いてコンテンツを前記コンテンツ受信装置へ暗号化伝送するコンテンツ提供部、
としてコンピューターを機能させるようにコンピューター可読形式で記述され、
前記認証・鍵共有部は、前記コンテンツ受信装置が所定のセキュリティー強度を有しているか否かに応じて、引き渡す共有鍵を切り替える、
コンピューター・プログラム。
（２５）所定の伝送規格に従って、コンテンツ送信装置と相互認証及び共有鍵の受け取りを行なう認証・鍵共有部、
前記の受け取った共有鍵から生成した暗号鍵を用いて暗号化伝送されたコンテンツを取得するコンテンツ取得部、
としてコンピューターを機能させるようにコンピューター可読形式で記述され、
前記認証・鍵共有部は、自分が所定のセキュリティー強度を有していることに応じた共有鍵を受け取る、
コンピューター・プログラム。
（２６）相互認証と共有鍵の交換を行ない、前記共有鍵から生成した暗号鍵を用いてコンテンツを暗号化伝送するコンテンツ送信装置とコンテンツ受信装置で構成され、
前記コンテンツ送信装置は、前記コンテンツ受信装置が所定のセキュリティー強度を有しているか否かに応じて、引き渡す共有鍵を切り替える、
コンテンツ伝送システム。
１００…コンテンツ伝送システム
１０１…サーバー、１０２、１０３…端末、１１０…ホーム・ネットワーク
２００…コンテンツ伝送システム
２０１…サーバー、２０２、２０３…端末
２１０…ホーム・ネットワーク、２２０…外部ネットワーク
２３０…ルーター
３００…コンテンツ送信装置（Ｓｏｕｒｃｅデバイス）
３０１…通信・制御部、３０２…コンテンツ記録部
３０３…コンテンツ取得部、３０４…コンテンツ提供部
３０５…コンテンツ・リスト提供部、３０６…認証・鍵共有部
３０７…端末管理部、３０８…コンテンツ再生出力部
４００…コンテンツ受信装置
４０１…通信・制御部
４０２…コンテンツ・リスト閲覧部、４０３…コンテンツ取得部
４０４…コンテンツ復号部、４０５…コンテンツ再生出力部
４０６…認証・鍵共有部、４０７…入力部、４０８…コンテンツ記録部
２２００…コンピューター・プログラム配信システム
２２１０…サーバー、２２１１…記憶装置
２２１２…通信装置、２２１３…情報通知装置
２３００…パーソナル・コンピューター、２３０１…ＣＰＵ
２３０２…ＲＡＭ、２３０３…ＥＥＰＲＯＭ、２３０４…ディスプレイ
２３０５…スピーカー、２３０６…大容量記憶装置
２３０７…Ｉ／Ｏインターフェース、２３０８…バス
２４００…レコーダー、２４０１…システム・チップ、２４０１ａ…ＣＰＵ、
２４０１ｂ…コプロセッサー、２４０１ｃ…インターフェース機能部
２４０１ｄ…バス、２４０２…大容量記憶装置、２４０３…ＲＡＭ
２４０４…ＥＥＰＲＯＭ、２４０５…無線ＬＡＮチップ
２４０６…チューナー、２４０７…ディスプレイ、２４０８…スピーカー
２４０９…ＬＡＮポート、２４０９Ａ…ＬＡＮケーブル
２５００…ネットワーク・アクセス・サーバー
２５０１…システム・チップ、２５０１ａ…ＣＰＵ、
２５０１ｂ…コプロセッサー、２５０１ｃ…インターフェース機能部
２５０１ｄ…バス、２５０２…大容量記憶装置、２５０３…ＲＡＭ
２５０４…ＥＥＰＲＯＭ、２５０５…無線ＬＡＮチップ
２５０６…ＬＡＮポート、２５０６Ａ…ＬＡＮケーブル

Claims (20)

  1. 所定の伝送規格に従って、コンテンツ受信装置と相互認証及び共有鍵の引き渡しを行なう認証・鍵共有部と、
    前記共有鍵から生成した暗号鍵を用いてコンテンツを前記コンテンツ受信装置へ暗号化伝送するコンテンツ提供部と、
    を具備し、
    前記認証・鍵共有部は、前記コンテンツ受信装置が所定のセキュリティー強度を有しているか否かに応じて、引き渡す共有鍵を切り替える、
    コンテンツ送信装置。
  2. 前記認証・鍵共有部は、前記所定のセキュリティー強度を有したコンテンツ受信装置には第１のコンテンツを扱うことができる第１の共有鍵を引き渡し、前記所定のセキュリティー強度を有していないコンテンツ受信装置には第１のコンテンツを扱うことができない第２の共有鍵を引き渡し、
    前記コンテンツ提供部は、前記第１の共有鍵から生成した暗号鍵で第１のコンテンツを暗号化伝送するが、前記第２の共有鍵から生成した暗号鍵では第１のコンテンツを暗号化伝送しない、
    請求項１に記載のコンテンツ送信装置。
  3. 前記所定のセキュリティー強化策は、暗号方式以外のより脆弱な部分の安全性が確保されていることである、
    請求項２に記載のコンテンツ送信装置。
  4. 前記第１の共有鍵及び前記第２の共有鍵は第１の暗号方式に従う暗号鍵を生成するための共有鍵であり、
    前記認証・鍵共有部は、前記第１の暗号方式にしか対応しないコンテンツ受信装置には前記第１の共有鍵又は前記第２の共有鍵を引き渡すが、第２の暗号方式に対応するコンテンツ受信装置には前記第２の暗号方式に従う暗号鍵を生成するための共有鍵を引き渡す、
    請求項２に記載のコンテンツ送信装置。
  5. 前記認証・鍵共有部は、相互認証時に前記コンテンツ受信装置から送られてくる機器証明書に格納されたＥＳフラグに基づいて、前記コンテンツ受信装置が前記所定のセキュリティー強度を有する機器か否かを判別する、
    請求項２に記載のコンテンツ送信装置。
  6. 前記認証・鍵共有部は、相互認証時に前記コンテンツ受信装置から送られてくるコマンドのペイロードのＣＡＰＡＢＩＬＩＴＹフィールドに格納されたＥＳフラグに基づいて、前記コンテンツ受信装置が前記所定のセキュリティー強度を有する機器か否かを判別する、
    請求項２に記載のコンテンツ送信装置。
  7. 前記認証・鍵共有部は、相互認証時に前記コンテンツ受信装置から送られてくるコマンドのペイロードのＣＡＰＡＢＩＬＩＴＹフィールドに格納されたＮＳフラグに基づいて、前記コンテンツ受信装置が前記第２の暗号方式に対応しているか否かを判別する、
    請求項６に記載のコンテンツ送信装置。
  8. 前記ＣＡＰＡＢＩＬＩＴＹフィールドは、前記コンテンツ受信装置の秘密鍵を使って当該フィールドのデータから計算された電子署名を伴う、
    請求項６又は７のいずれかに記載のコンテンツ送信装置。
  9. 前記認証・鍵共有部は、前記コンテンツ受信装置から送られてきた機器証明書にＥＳフラグが格納されていることを確認したが、相互認証時のコマンド内でＮＳフラグを確認できないときには、その相互認証処理をエラーとして中断する、
    請求項７に記載のコンテンツ送信装置。
  10. 前記認証・鍵共有部は、相互認証時に前記コンテンツ受信装置に送るコマンドのペイロードのＣＡＰＡＢＩＬＩＴＹフィールドに、第２の暗号方式への対応の有無を示すＮＳフラグを格納するとともに、自分の秘密鍵を使って当該フィールドのデータから計算された電子署名を伴わせる、
    請求項２に記載のコンテンツ送信装置。
  11. 前記所定の伝送規格は、ＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）若しくはＤＴＣＰ−ＩＰ（ＤＴＣＰ ｍａｐｐｉｎｇ ｔｏ ＩＰ）である、
    請求項１に記載のコンテンツ送信装置。
  12. 所定の伝送規格に従って、コンテンツ受信装置と相互認証及び共有鍵の引き渡しを行なう認証・鍵共有ステップと、
    前記共有鍵から生成した暗号鍵を用いてコンテンツを前記コンテンツ受信装置へ暗号化伝送するコンテンツ提供ステップと、
    を有し、
    前記認証・鍵共有ステップでは、前記コンテンツ受信装置が所定のセキュリティー強度を有しているか否かに応じて、引き渡す共有鍵を切り替える、
    コンテンツ送信方法。
  13. 所定の伝送規格に従って、コンテンツ送信装置と相互認証及び共有鍵の受け取りを行なう認証・鍵共有部と、
    前記の受け取った共有鍵から生成した暗号鍵を用いて暗号化伝送されたコンテンツを取得するコンテンツ取得部と、
    を具備し、
    前記認証・鍵共有部は、自分が所定のセキュリティー強度を有していることに応じて、第１のコンテンツを扱うことができる第１の共有鍵を受け取り、
    前記コンテンツ取得部は、前記第１の共有鍵から生成した暗号鍵で暗号化伝送された第１のコンテンツを取得する、
    コンテンツ受信装置。
  14. 前記認証・鍵共有部は、相互認証時に前記コンテンツ送信装置に送る機器証明書に、自分が前記所定のセキュリティー強度を有しているか否かを示すＥＳフラグを格納する、
    請求項１３に記載のコンテンツ受信装置。
  15. 前記認証・鍵共有部は、相互認証時に前記コンテンツ送信装置に送るコマンドのペイロードのＣＡＰＡＢＩＬＩＴＹフィールドに、自分が前記所定のセキュリティー強度を有しているか否かを示すＥＳフラグ、又は、自分が暗号方式に対応しているか否かを示すＮＳフラグのうち少なくとも一方を格納する、
    請求項１３に記載のコンテンツ受信装置。
  16. 前記認証・鍵共有部は、前記ＣＡＰＡＢＩＬＩＴＹフィールドに、自分の秘密鍵を使って当該フィールドのデータから計算された電子署名を伴わせる、
    請求項１５に記載のコンテンツ送信装置。
  17. 所定の伝送規格に従って、コンテンツ送信装置と相互認証及び共有鍵の受け取りを行なう認証・鍵共有ステップと、
    前記の受け取った共有鍵から生成した暗号鍵を用いて暗号化伝送されたコンテンツを取得するコンテンツ取得ステップと、
    を有し、
    前記認証・鍵共有ステップでは、自分が所定のセキュリティー強度を有していることに応じた共有鍵を受け取る、
    コンテンツ受信方法。
  18. 所定の伝送規格に従って、コンテンツ受信装置と相互認証及び共有鍵の引き渡しを行なう認証・鍵共有部、
    前記共有鍵から生成した暗号鍵を用いてコンテンツを前記コンテンツ受信装置へ暗号化伝送するコンテンツ提供部、
    としてコンピューターを機能させるようにコンピューター可読形式で記述され、
    前記認証・鍵共有部は、前記コンテンツ受信装置が所定のセキュリティー強度を有しているか否かに応じて、引き渡す共有鍵を切り替える、
    コンピューター・プログラム。
  19. 所定の伝送規格に従って、コンテンツ送信装置と相互認証及び共有鍵の受け取りを行なう認証・鍵共有部、
    前記の受け取った共有鍵から生成した暗号鍵を用いて暗号化伝送されたコンテンツを取得するコンテンツ取得部、
    としてコンピューターを機能させるようにコンピューター可読形式で記述され、
    前記認証・鍵共有部は、自分が所定のセキュリティー強度を有していることに応じた共有鍵を受け取る、
    コンピューター・プログラム。
  20. 相互認証と共有鍵の交換を行ない、前記共有鍵から生成した暗号鍵を用いてコンテンツを暗号化伝送するコンテンツ送信装置とコンテンツ受信装置で構成され、
    前記コンテンツ送信装置は、前記コンテンツ受信装置が所定のセキュリティー強度を有しているか否かに応じて、引き渡す共有鍵を切り替える、
    コンテンツ伝送システム。
JP2015527200A 2013-07-19 2014-04-30 コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、コンピューター・プログラム、並びにコンテンツ伝送システム Active JP6390618B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2013151075 2013-07-19
JP2013151075 2013-07-19
PCT/JP2014/062018 WO2015008521A1 (ja) 2013-07-19 2014-04-30 コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、コンピューター・プログラム、並びにコンテンツ伝送システム

Publications (2)

Publication Number Publication Date
JPWO2015008521A1 true JPWO2015008521A1 (ja) 2017-03-02
JP6390618B2 JP6390618B2 (ja) 2018-09-19

Family

ID=52345996

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015527200A Active JP6390618B2 (ja) 2013-07-19 2014-04-30 コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、コンピューター・プログラム、並びにコンテンツ伝送システム

Country Status (3)

Country Link
US (1) US10044683B2 (ja)
JP (1) JP6390618B2 (ja)
WO (1) WO2015008521A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160364553A1 (en) * 2015-06-09 2016-12-15 Intel Corporation System, Apparatus And Method For Providing Protected Content In An Internet Of Things (IOT) Network
CN112218171B (zh) * 2020-09-15 2022-07-19 深圳数字电视国家工程实验室股份有限公司 基于接口的数据传输方法、电子设备及存储介质

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6823454B1 (en) * 1999-11-08 2004-11-23 International Business Machines Corporation Using device certificates to authenticate servers before automatic address assignment
WO2006028092A1 (ja) * 2004-09-07 2006-03-16 Matsushita Electric Industrial Co., Ltd. コンテンツ配信管理装置
JP2006094241A (ja) * 2004-09-24 2006-04-06 Fuji Xerox Co Ltd 暗号化装置、暗号化処理方法及びプログラム、並びに該暗号化装置を用いた情報保護システム
JP2006171892A (ja) * 2004-12-13 2006-06-29 Betrusted Japan Co Ltd ウェブサイト所有者情報伝達方法、ウェブサイト所有者情報送信装置及び方法並びにプログラム
US20070058814A1 (en) * 2005-09-13 2007-03-15 Avaya Technology Corp. Method for undetectably impeding key strength of encryption usage for products exported outside the U.S.
JP2008066834A (ja) * 2006-09-05 2008-03-21 Sony Corp 通信システムおよび通信方法、情報処理装置および方法、デバイス、プログラム、並びに記録媒体
JP2008113172A (ja) * 2006-10-30 2008-05-15 Hitachi Ltd コンテンツ送信装置、コンテンツ受信装置及びコンテンツ暗号化方法
US20100017595A1 (en) * 2008-07-16 2010-01-21 King Neal J Security In Networks
JP2013026686A (ja) * 2011-07-15 2013-02-04 Sony Corp 通信装置及び通信方法、通信システム、並びにコンピューター・プログラム

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7225259B2 (en) * 2001-02-21 2007-05-29 Nokia Inc. Service tunnel over a connectionless network
EP1304844B1 (en) * 2001-10-19 2007-04-04 Sony Deutschland GmbH Content protection and copy management system for a network
US7590840B2 (en) * 2003-09-26 2009-09-15 Randy Langer Method and system for authorizing client devices to receive secured data streams
US7742438B1 (en) * 2004-10-21 2010-06-22 Owlink Technology, Inc. HDCP data transmission over a single communication channel
US20060143701A1 (en) * 2004-12-23 2006-06-29 Cisco Technology, Inc. Techniques for authenticating network protocol control messages while changing authentication secrets
US7913289B2 (en) * 2005-05-23 2011-03-22 Broadcom Corporation Method and apparatus for security policy and enforcing mechanism for a set-top box security processor
JP3949148B2 (ja) * 2005-09-06 2007-07-25 株式会社東芝 無線通信装置、受信装置、送信装置および通信制御プログラム
JP4581955B2 (ja) * 2005-10-04 2010-11-17 ソニー株式会社 コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラム
JP4518058B2 (ja) * 2006-01-11 2010-08-04 ソニー株式会社 コンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラム
US8023478B2 (en) * 2006-03-06 2011-09-20 Cisco Technology, Inc. System and method for securing mesh access points in a wireless mesh network, including rapid roaming
JP5324813B2 (ja) 2008-04-28 2013-10-23 Ｋｄｄｉ株式会社 鍵生成装置、証明書生成装置、サービス提供システム、鍵生成方法、証明書生成方法、サービス提供方法およびプログラム
CN113596828A (zh) * 2014-10-31 2021-11-02 康维达无线有限责任公司 端对端服务层认证

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6823454B1 (en) * 1999-11-08 2004-11-23 International Business Machines Corporation Using device certificates to authenticate servers before automatic address assignment
WO2006028092A1 (ja) * 2004-09-07 2006-03-16 Matsushita Electric Industrial Co., Ltd. コンテンツ配信管理装置
JP2006094241A (ja) * 2004-09-24 2006-04-06 Fuji Xerox Co Ltd 暗号化装置、暗号化処理方法及びプログラム、並びに該暗号化装置を用いた情報保護システム
JP2006171892A (ja) * 2004-12-13 2006-06-29 Betrusted Japan Co Ltd ウェブサイト所有者情報伝達方法、ウェブサイト所有者情報送信装置及び方法並びにプログラム
US20070058814A1 (en) * 2005-09-13 2007-03-15 Avaya Technology Corp. Method for undetectably impeding key strength of encryption usage for products exported outside the U.S.
JP2008066834A (ja) * 2006-09-05 2008-03-21 Sony Corp 通信システムおよび通信方法、情報処理装置および方法、デバイス、プログラム、並びに記録媒体
JP2008113172A (ja) * 2006-10-30 2008-05-15 Hitachi Ltd コンテンツ送信装置、コンテンツ受信装置及びコンテンツ暗号化方法
US20100017595A1 (en) * 2008-07-16 2010-01-21 King Neal J Security In Networks
JP2013026686A (ja) * 2011-07-15 2013-02-04 Sony Corp 通信装置及び通信方法、通信システム、並びにコンピューター・プログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HITACHI, LTD., ET AL., DIGITAL TRANSMISSION CONTENT PROTECTION SPECIFICATION VOLUME 1 [INFORMATIONAL VERSION], vol. Recision 1.7 ED2, JPN6018019574, 5 June 2013 (2013-06-05), pages 30, ISSN: 0003804837 *

Also Published As

Publication number Publication date
US10044683B2 (en) 2018-08-07
US20160149868A1 (en) 2016-05-26
JP6390618B2 (ja) 2018-09-19
WO2015008521A1 (ja) 2015-01-22

Similar Documents

Publication Publication Date Title
CN101517975B (zh) 通过将互联网协议电视和家庭网络互相连接来发送/接收内容的方法和设备
JP4518058B2 (ja) コンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラム
US8984646B2 (en) Content transmission device and content reception device
EP2975854B1 (en) Content distribution method, content distribution system, source device, and sink device
EP2917867B1 (en) An improved implementation of robust and secure content protection in a system-on-a-chip apparatus
WO2011030520A1 (en) Communication system, communication apparatus, communication method, and computer program
US20150149778A1 (en) Content reception apparatus and method, and content transmission apparatus and method
JP2010021875A (ja) データ送信装置、データ受信装置、データ送信方法およびデータ受信方法
US7886160B2 (en) Information processing apparatus and method, and computer program
JP6390618B2 (ja) コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、コンピューター・プログラム、並びにコンテンツ伝送システム
JP4292222B2 (ja) 著作権保護処理装置および著作権保護処理方法
JP6221428B2 (ja) コンテンツ受信装置及びコンテンツ受信方法、並びにコンピューター・プログラム
JP2010231787A (ja) コンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラム
US20230254342A1 (en) Cryptographic binding of data to network transport
JP6848013B2 (ja) コンテンツ送信装置、および、そのコンテンツ送信方法
JP2018038041A (ja) 通信システム及び通信方法
JP6332280B2 (ja) コンテンツ送信装置及びコンテンツ送信方法、並びにコンピューター・プログラム
WO2015004978A1 (ja) コンテンツ送信装置及びコンテンツ送信方法、並びにコンピューター・プログラム
JP6187139B2 (ja) コンテンツ伝送システム
Li et al. RFID-based digital content copy protection system in movie and audio rental agency
JP2015082681A (ja) コンテンツ受信装置及びコンテンツ受信方法、並びにコンピューター・プログラム
JP2015014979A (ja) コンテンツ伝送システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170410

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180529

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180710

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180724

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180806

R151 Written notification of patent or utility model registration

Ref document number: 6390618

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151