JP2004312717A - データ保護管理装置およびデータ保護管理方法 - Google Patents

Abstract

【課題】 デジタルライセンスやデジタルデータを保護することにより、デジタルデータの乱用や不正利用を防止し、且つユーザに再生機器に対する選択の自由を与えることを目的とする。
【解決手段】 Ｉ／Ｏポートと、セッションマネージャと、ライセンス管理エンジンと、ユーセッジルール適用部と、暗号エンジンと、メモリ管理部と、メモリとを備え、ライセンス管理エンジンは、セッションマネージャで確立したセッションによってライセンスを取得、保存、管理し、ユーセッジルール適用部は、ライセンス管理エンジンが管理するライセンスの使用に関し、ユーセッジルールを適用することにより、デジタルライセンスデータをセキュアに保存・送信するための暗号化アルゴリズムやプロトコルを提供する。
【選択図】 図１

Description

本発明は、デジタルデータを保護する装置および方法に関し、特に、ライセンスを用いたデータ配信における配信データおよびライセンスデータ、及び電子チケットの保護に関する。

近年、ユーザが、コンテンツプロバイダーが作成したデジタルコンテンツをネットワーク経由で取得して再生する、データ配信サービスが普及してきた。サービスを提供するコンテンツプロバイダーは、彼らが所有する知的財産が著作権侵害を受けたり、不正に複製・乱用されたりすることがないと判断した場合に、デジタルコンテンツの使用を認めている。

デジタルコンテンツのセキュリティを提供する技術として、ユーザの識別子を用いたユーザ毎に専用の秘密アルゴリズムを用いることにより、デジタルコンテンツの不正使用を防御する方法があった（例えば、特開平７−２９５８００号公報）。これにより、専用の再生機器、或いは対応可能なＰＣハードウェアで固有なＩＤ（デバイス依存）を持つものでしかデジタルコンテンツを再生できないように制限することが可能となり、不正な複製からデータを保護することができる。

図１８は、従来のデータ配信システムの概要を示す図である。このシステムは、サーバであるコンテンツプロバイダー１００（以下、サーバと記載する）と、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）１０４と、クライアント１０６とを備えている。サーバ１００とＰＣ１０４は、ネットワークを介して接続可能であり、クライアント１０６は、サーバ１００からネットワーク経由で配信されたコンテンツに対し、記憶保持や再生などの処理を行う装置である。サーバ１００内のコンテンツ記憶装置１０２よりコンテンツを取得する際、サーバ１００は、クライアント１０６より通知されたシリアルナンバー（または、デバイスナンバー）を暗号化の鍵１０１とし、この暗号化の鍵１０１を用いて配信対象のコンテンツを暗号化する（１０３）。このシリアルナンバー自体を暗号化の鍵として使用するだけでなく、暗号化に必要な鍵やパスワードを生成するために用いられてもよい。暗号化されたコンテンツは、ＰＣ１０４を介してクライアント１０６に転送される。なお、ＰＣ１０４は、暗号化されたコンテンツを受信した際に、即時にクライアント１０６に通知するのでなく、任意のタイミングでクライアント１０６に通知してもよい。また、ＰＣ１０４上にアーガイブとしてまとめて管理してもよい。このため、ＰＣ１０４内の暗号化コンテンツ記憶装置１０５に、配信された暗号化されたコンテンツを記憶してもよい。クライアント１０６は、受信した暗号化されたコンテンツを、組み込まれた復号化の鍵１０９を用いて復号化処理を行い（１０７）、復号化されたコンテンツをコンテンツ記憶装置１０８に格納する。また、コンテンツ記憶装置１０８に格納せずに、オンザフライの再生を行う。

以上のように、クライアントからサーバにシリアルナンバーを通知し、サーバが受信したシリアルナンバーに基づいて暗号化したコンテンツデータをクライアントに送信することにより、コンテンツデータの配信を行う。

図１９も、従来のデータ配信システムの概要を示す図である。このシステムは、サーバであるコンテンツプロバイダー２０１（以下、サーバと記載する）と、ＰＣ２０５と、クライアント２１１とを備えている。サーバ２０１内のコンテンツ記憶装置２０２に格納されているコンテンツを配信する際、サーバ２０１は、コンテンツかユーザかクライアント２１１に関連つけられた鍵を生成し（２０３）、この鍵を用いてコンテンツの暗号化を行う（２０４）。ＰＣ２０５は、サーバ２０１にコンテンツの取得要求を通知することにより、暗号化されたコンテンツと、これに関連付けられた鍵をサーバ２０１から受け取り、それぞれコンテンツ記憶装置２０６と、鍵記憶装置２０７に格納する。ＰＣ２０５は、コンテンツ記憶装置２０６に格納されたコンテンツをクライアント２１１へ通知する前に、鍵記憶装置２０７に格納されている関連つけられた鍵を用いてコンテンツの復号化を行い（２０８）、クライアント２１１から、もしくは、クライアント２１１への通知のセッションから得られた鍵２１０を用いて、コンテンツを再び暗号化する（２０９）。クライアント２１１は、受信した暗号化されたコンテンツをコンテンツ記憶装置２１２に格納する。この場合、コンテンツを再生するなどメディア出力する前に、セッション鍵記憶装置２１４に格納されているセッション鍵を用いて、復号化を行う（２１５）。なお、受信した暗号化されたコンテンツを、まず復号化を行い、コンテンツ記憶装置２１２に格納してもよい。

以上のように、サーバが生成した鍵とその鍵を用いて暗号化したコンテンツデータをＰＣに通知し、ＰＣとクライアント間で別の鍵（セッション鍵）を用いて再暗号化することにより、コンテンツデータの配信を行う。
特開平７−２９５８００号公報

しかしながら、上述した従来の技術では、不正な複製からデータを保護するために、専用の再生機器や、対応可能なＰＣハードウェアで固有なＩＤ（デバイス依存）を持つものでしか取得したコンテンツデータの再生ができない。そのため、ユーザがＯＳやハードウェアのアップデートを行うことにより、今まで再生できていたコンテンツデータの再生ができなくなる可能性がある。また、再生に専用の再生機器が必要になるのでは、ユーザが利用したい時に、いつでも、どこでもコンテンツデータを楽しむことが難しい。

また、専用の再生機器でしか再生することができないため、メモリカードやＩＣカード、ＳＤカード、ＣＤ−Ｒなどの着脱可能な記録媒体にコンテンツデータを格納した場合でも、他の再生専用装置を用いて再生処理することができない。

また、現在のシステムでは、ＰＣとネットワークへの接続環境がないユーザは、コンテンツプロバイダーが用意したコンテンツを利用することができない。

本発明は、上記問題点を解決するためになされたものであり、デジタルデータの乱用や不正利用を防止し、且つユーザに再生機器に対する選択の自由を与え、デジタルデータを利用する際の保護機能を強化することを目的としている。また、コンテンツ配信手段としてネットワークのみに依存せず、その他の配信チャネルによるデータ配信も利用可能とすることを目的としている。

上記課題を解決するために、本発明のデータ保護管理装置は、送信元と送信先との間でライセンスと暗号化されたコンテンツのデータ通信が行われ、通信されるデータの保護管理を行うデータ保護管理装置であって、送信元からライセンス及び暗号化されたコンテンツを得るための処理を行うセッションマネージャ部と、前記セッションマネージャ部で得た前記ライセンスを保存し、管理するライセンス管理エンジン部と、前記ライセンスを保存するメモリ部とを備え、前記セッションマネージャ部は、送信元から、前記ライセンスの存在証明の要求の一部であるチャレンジを受けた場合、ライセンスの存在を証明する証明書を生成すると共に、生成した証明書を送信元に送信することを特徴とするデータ保護管理装置である。
本発明のデータ保護管理装置は、前記ライセンスに関連付けられたユーセッジルールを決定し、前記ライセンスおよび前記コンテンツの少なくともいずれか一方の処理に前記ユーセッジルールを適用するユーセッジルール適用部を備えたことを特徴とするものである。
本発明のデータ保護管理装置において、前記セッションマネージャ部は、前記証明書を暗号化することを特徴するものである。
本発明のデータ保護管理装置において、前記セッションマネージャ部は、前記ライセンスのオプション的な事項を証明書に加えることを特徴とするものである。
本発明のデータ保護管理装置は、前記オプション的な事項のデータを前記ライセンスに含まれる鍵を用いて暗号化することを特徴とするものである。
本発明のデータ保護管理装置において、前記ユーセッジルールは、前記ライセンスに基づいて、前記証明書に加えるデータを決定する情報を含むことを特徴とするものである。
本発明のデータ保護管理装置において、前記セッションマネージャ部は、ライセンスの変更を送信元から受けた場合は、ライセンス管理エンジンから変更前のライセンスを読出し、ライセンスの変更を行い、変更後のライセンスをライセンス管理エンジン部を用いて保存することを特徴とするものである。
本発明のデータ保護管理装置において、前記セッションマネージャ部は、コンテンツをライセンスと関連付けられた上記鍵で復号化することを特徴とするものである。
本発明のデータ保護管理装置において、前記セッションマネージャ部は、復号化されたコンテンツを、再び暗号化することを特徴とするものである。
本発明のデータ保護管理装置において、再び暗号化するための鍵は、送信先からの情報に基づいて生成することを特徴とするものである。
本発明のデータ保護装置は、接続を管理し、前記接続の相手との信任状の交換と相互認証を確立し、確立した前記接続でのライセンスとそれに続く前記データへのアクセス制限を適用する処理を行うセッションマネージャ部と、前記セッションマネージャ部で確立したセッションによって前記ライセンスを取得、保存、管理するライセンス管理エンジン部と、前記ライセンス管理エンジン部が管理する前記ライセンスに関連付けられたユーセッジルールを決定し、前記ライセンスや前記データの処理に前記ユーセッジルールを適用するユーセッジルール適用部と、前記データの暗号化と復号化や署名に必要な公開鍵または共通鍵の暗号アルゴリズムとハッシュアルゴリズムを実装しており、前記セッションでの暗号化プロトコルの機能を提供する暗号エンジン部と、メモリへのアクセスを制御し、前記暗号エンジン部での暗号化と復号化に必要な領域を提供するメモリ管理部と、前記データと前記ライセンスとそれらの接続の状態情報を保存するメモリ部とを備えることを特徴とする、以下、このデータ保護管理装置をセキュアコンテナと記載する。

これにより、デジタルライセンスデータをセキュアに保存・受信・送信するための暗号化アルゴリズムやプロトコルを提供することによって、ライセンスデータの安全管理を保証できる。

また、本発明のデータ保護管理装置は、システムに固有の鍵を暗号化と復号化のために少なくとも一つ保持することを特徴とする。これにより、システムに固有な鍵をコンテンツの暗号化に用いることが可能となり、データの盗聴や改ざんを防ぐ安全性をより強化できる。

また、本発明のデータ保護管理装置は、データ配信処理に基づく状態の変化に関する情報を記憶するログ管理エンジン部を更に備え、ログ情報の書き込みおよび読み出しを制御することを特徴とする。これにより、セキュアコンテナがトランザクションの記録やその他のセキュリティに関する操作を行うことが可能となり、セキュアコンテナやそこに保存されているデジタルライセンスデータが改ざんや乱用を受けた場合、システム制作者や許可された第三者がそれを認識できるようになる。

また、本発明のデータ保護管理方法は、送信元が、配信対象のデータに関連付けられた鍵を用いて暗号化されたデータを格納するステップと、送信元から情報処理装置へ、前記暗号化されたデータを転送するステップと、送信元から前記情報処理装置へ、１つ以上の制御命令を含む命令セットを転送するステップと、前記情報処理装置と送信先の間で、セキュアなデータ通路を確立するステップと、送信先から前記情報処理装置へ、１つ以上の制御命令を含む命令セットを転送するステップと、前記情報処理装置が、命令セットに基づいて、前記暗号化されたデータを、前記鍵を用いて複合化して、前記セキュアなデータ通路を介して送信先に転送するステップとを有することを特徴とする。この命令セットは、ユーセッジルールとも呼ばれる。また、送信元をソース、送信先をシンクとも呼ぶ。さらに、この情報処理装置は、前述したセキュアコンテナを示す。これにより、セキュアコンテナを通してデータを転送するので、要求される操作や制御を適用しながら安全にデータをソースからシンクに送付できる。

また、本発明のデータ保護管理方法は命令セットとして、セキュアなデータ通路で用いられる暗号化の強度を指定する制御命令を含むことを特徴とする。これにより、制御命令で暗号化の強度（つまり、セキュアコンテナとシンク間のセキュアなチャネルの強度）を管理することで、データ通路の種類に応じてより柔軟に安全性を向上することができる。

また、本発明のデータ保護管理方法は、命令セットとして、セキュアなデータ通路が有効である期間について示す制御命令を含むことを特徴とする。これにより、暗号化（セキュアコンテナとシンク間のセキュアなチャネル）を管理する制御命令は、再暗号化が可能な期間を定義可能となり、顧客が、購買期間中に（放送データなどを）個人用にコピー保存したり、データを計画利用できたりする購買型システムを確立することができる。

また、本発明のデータ保護管理方法は、命令セットとして、データの複製をシンクにいくつ送信するかを示す制御命令を含むことを特徴とする。これにより、暗号化（セキュアコンテナとシンク間のセキュアなチャネル）を管理する制御命令は、シンクに送信可能なコピー回数を規定することにより、データのバックアップや共有に有用である。コンテンツは顧客に対応付けられているので、監視や監査が可能である。

また、本発明のデータ保護管理方法は、命令セットとして、送信元から情報処理装置へ転送された制御命令を含むことを特徴とする。これにより、ソースからセキュアコンテナに送られる制御命令セットを追加することが可能となり、ソースがセキュリティ要件を規定できるなどの利点がある。ライセンスや鍵に付随する制御セットに定義されているデフォルト要件が弱められることはない。

また、本発明のデータ保護管理方法は、命令セットとして、送信先から情報処理装置へ転送された制御命令を含むことを特徴とする。これにより、シンクからセキュアコンテナに送られる制御命令セットを追加することが可能となり、シンクがセキュリティ要件を規定できるなどの利点がある。ライセンスや鍵に付随する制御セットに定義されているデフォルト要件が弱められることはない。

また、本発明のデータ保護管理方法は、命令セットとして、送信先が適合すべき要求事項を示す制御命令を含むことを特徴とする。これにより、暗号化（セキュアコンテナとシンク間のセキュアなチャネル）を管理する制御命令は、シンクに対する要件を定義することが可能となり、ソースがシンクに要件を指示することができる。例えば、シンクは購入するのに高額なデータに対してはユーザによる確認といった一定のセキュリティ基準に従わなければならないなどの要件を定義できる。

また、本発明のデータ保護管理方法は、送信元が、配信対象のデータに関連付けられた鍵を用いて前記データを暗号化するステップと、送信元から前記情報処理装置へ、前記暗号化されたデータを転送するステップと、送信元から前記情報処理装置へ、暗号化に用いた前記鍵を転送するステップと、送信元から前記情報処理装置へ、１つ以上の制御命令を含む命令セットを転送するステップと、前記情報処理装置が、命令セットに基づいて、前記暗号化されたデータを前記鍵を用いて複合化して、送信先に関連付けられた鍵を用いて前記データを再暗号化するステップとを有することを特徴とする。これにより、再暗号化処理では、シンクに対応付けられたデータの個別化を行うことが可能となり、暗号化が行われると、データを復号できるのは対応するシンクのみとなり、より安全性を高めることができる。

また、本発明のデータ保護管理方法は、命令セットとして、再暗号化に許される計算時間について示す制御命令を含むことを特徴とする。これにより、顧客が購買期間中に（放送データなどを）個人用にコピー保存することが可能な購買システムが確立できる。

また、本発明のデータ保護管理方法は、命令セットとして、データの再暗号化された複製をいくつ生成するかを示す制御命令を含むことを特徴とする。これにより、再暗号化を管理する制御命令は、コピー可能回数を規定する。データのバックアップや共有に有用で、コンテンツが顧客に対応付けられているので、監視や監査が可能である。

また、本発明のデータ保護管理方法は、命令セットとして、送信先が適合すべき要求事項を示す制御命令を含むことを特徴とする。これにより、再暗号化を管理する制御命令は、シンクに対する要件を規定することが可能となり、ソースはシンクに要件を指示することができる。例えば、シンクは購入するのに高額なデータに対しては一定のセキュリティ基準に従わなければならないなどの要件を指定できる。

また、本発明のデータ保護管理方法は、命令セットとして、送信先から前記情報処理装置へ転送された制御命令を含むことを特徴とする。これにより、再暗号化プロセスを管理する制御命令がシンクに存在することが可能であり、シンクが独立して再暗号化を行うことができるという利点がある。また、制御命令はソースに存在し、暗号化はソースで行われることにより、データ製作者や所有者に対応しているソースが、再暗号化プロセスを完全に制御できるという利点がある。本発明では、顧客がコンテンツを個別化するこができるので、他人にコンテンツを利用されることがない。コンテンツは再暗号化プロセスで匿名化することもできる。

また、本発明のデータ保護管理方法は、情報処理装置に格納された所定のライセンスの存在を証明する方法であって、送信元と前記情報処理装置との間で相互認証を行うステップと、送信元と前記情報処理装置の間で、セキュアなデータ通路を確立するステップと、送信元から前記情報処理装置へ、前記所定のライセンスの存在証明を要求するチャレンジを転送するステップと、前記情報処理装置が、命令セットに基づいて、前記チャレンジと前記所定のライセンスを用いて、固有の証明を生成するステップと、前記情報処理装置が、前記生成した証明を送信元に転送するステップと、送信元が、受け取った前記証明を検証するステップとを有することを特徴とする。これにより、ソースにそのライセンスの詳細情報を与えずに、シンクにライセンスが存在することを証明することが可能となる。つまり、シンクのライセンスプールにライセンスが存在すること示す証明を受け取りたい場合、ソースはセキュアなチャネルを利用してシンクに証明書の発行請求を出さなければならない。シンク（セキュアコンテナ）は、ソースからシンクに送られた要求（チャレンジ）を考慮に入れて証明書を生成する。生成された証明書は、セキュアなチャネルを通してソースに送られる。ライセンスに固有な証明書を発行する利点は、シンクがライセンスの詳細情報をソースに送る必要がない点である。また、この証明書は、ライセンスが電子チケットの代わりになる電子チケットシステムでも利用可能である。さらに、ソースから受け取った命令セットを用いることにより、ライセンス発行者が証明書の生成方法を制御できる。

また、本発明のデータ保護管理方法は、証明を生成する際に、情報処理装置が、チャレンジと証明を、送信元の公開鍵を用いて暗号化することを特徴する。これにより、公開鍵方式を利用して証明を暗号化することが可能となり、ソースとセキュアコンテナ間の接続をセキュアにする必要性がないという利点がある。この場合、セキュリティは公開鍵方式で実現される。ここで、ソースの公開鍵は、ライセンスの一部として組み込まれる可能性がある。

また、本発明のデータ保護管理方法は、証明を生成する際に、情報処理装置が、生成した証明をライセンスに含まれる鍵を用いて暗号化することを特徴とする。これにより、ライセンスの一部を鍵として利用することが可能となり、ライセンス発行者や許可された第三者のみが証明を復号できる。また、ソースが証明書を復号できるのであれば、そのソースは許可されたものであると考えられることから、ソースが自身の認証をセキュアコンテナに対し行う必要がなくなる。

また、本発明のデータ保護管理方法は、生成した証明を送信元に転送する際に、ライセンスに含まれる付加的なデータとともに証明を送信元に転送することを特徴とする。これにより、ライセンスからの追加データを証明に付け加えた後、証明をソースに転送することが可能となり、この方法で電子チケットを実現することができる。

また、本発明のデータ保護管理方法は、付加的なデータをライセンスに含まれる鍵を用いて暗号化することを特徴とする。これにより、ライセンスからの追加データを証明に添付し、証明と付加データの一方、或いは両方を暗号化し、ソースに転送することが可能となり、この方法で電子チケットを実現することができる。

また、本発明のデータ保護管理方法は、命令セットとして、ライセンスに基づいて、証明に付加されるデータを決定する情報を含むことを特徴とする。これにより、証明生成を管理する制御命令に、ライセンスのどのデータを証明に添付すべきかを示す情報を含めることが可能となり、ライセンスに付随するデータの特定のサブセットを証明に添付することができる。

また、本発明のデータ保護管理方法は、情報処理装置に格納された所定のライセンスの状態情報を変更する方法であって、送信元と前記情報処理装置との間で相互認証を行うステップと、送信元と前記情報処理装置の間で、セキュアなデータ通路を確立するステップと、送信先から前記情報処理装置へ、前記所定のライセンスの状態情報の変更を要求するとともに、ライセンスの存在証明を要求するチャレンジを転送するステップと、前記情報処理装置が、前記要求に従い、前記所定のライセンスの状態情報を変更するステップと、前記情報処理装置が、命令セットに基づいて、前記チャレンジと前記所定のライセンスを用いて、固有の証明を生成するステップと、前記情報処理装置が、前記生成した証明を送信元に転送するステップと、送信元が、受け取った前記証明を検証するステップとを有することを特徴とする。これにより、ライセンスの状態情報は、必要であれば、ライセンスに割り当てられるか、ライセンスの中に組み込まれる。つまり、状態情報を変更したい場合、まずソースとセキュアコンテナ間の相互認証を行い、認証が成功するとセキュアなチャネルが確立される。次に、ライセンス状態情報の変更を要請するリクエストが、ソースからセキュアコンテナに送付され、セキュアコンテナで要求に沿った操作がおこなわれる。ライセンス状態情報の変更が成功すれば、セキュアコンテナは証明をソースに送る。ソースでは、送付された証明から要求した変更の結果を確認できる。この方法の利点は、ライセンス状態情報の変更で、双方向、或いは複数の電子チケットを実現できる点とライセンスに対応するデジタルデータの使用を制限できる点である。

また、本発明のデータ保護管理方法は、情報処理装置に所定のライセンスを格納する方法であって、送信元と前記情報処理装置との間で相互認証を行うステップと、送信元と前記情報処理装置の間で、セキュアなデータ通路を確立するステップと、送信元から前記情報処理装置へ、前記所定のライセンスを転送するステップと、前記情報処理装置は、命令セットに基づき、前記受け取った所定のライセンスを格納するステップとを有することを特徴とする。つまり、セキュアコンテナとソースは相互認証を行い、認証が成功すれば、両者間にセキュアなチャネルが確立される。受理したライセンスデータはセキュアコンテナ内の内部メモリで保存される。これにより、ライセンスをセキュアコンテナに保存する時に、前記ライセンスデータはソースからデバイスへセキュアに転送され、デバイスのメモリに安全に保存される。ライセンスデータは決して平文で公開されることはない。

また、本発明のデータ保護管理方法は、情報処理装置に所定のライセンスを格納する方法であって、送信元と前記情報処理装置との間で相互認証を行うステップと、前記情報処理装置から送信元へ、送信先に関連付けられた公開鍵を転送するステップと、送信元が、前記受け取った公開鍵を用いて、前記所定のライセンスを暗号化し、前記暗号化したライセンスを前記情報処理装置へ転送するステップと、前記情報処理装置が、送信先に関連付けられた秘密鍵を用いて、前記暗号化したライセンスを複合化するステップとを有することを特徴とする。つまり、セキュアコンテナとソースは相互認証を行い、認証が成功すると、デバイスに対応した公開鍵がソースに送付される。ソースでは、受け取った公開鍵を使ってライセンスデータを暗号化し、暗号データをセキュアコンテナに送る。セキュアコンテナでは、受け取ったデータを内部メモリに保存する。これにより、ライセンスをセキュアコンテナに保存する時に、前記ライセンスデータはソースからデバイスへセキュアに転送され、デバイスのメモリに安全に保存される。ライセンスデータは決して平文で公開されることはない。

以上のように、本発明によれば、専用の再生機器や対応可能なＰＣハードウェアで固有なＩＤを持つものに限定されずに、取得したコンテンツを自由に再生することができ、且つ、デジタルライセンスデータをセキュアに保存・送信するための暗号化アルゴリズムやプロトコルを提供することにより、ライセンスデータの安全管理を保証することが可能となる。

また、システムに固有な鍵をコンテンツの暗号化に用いることが可能となり、データの盗聴や改ざんを防ぐ安全性をより強化できる。更に、セキュアコンテナやそこに保存されているデジタルライセンスデータが改ざんや乱用を受けた場合、システム制作者や許可された第三者がそれを認識できるようになる。

また、ある特定のプラットフォームやメディアに制限されることなく、オンラインでもオフラインでもあらゆるメディア配信に用いることができ。デジタルコンテンツやメディアの権利保護に加えて、ソフトウェアや番組配信といったライセンスベースの保護スキームにも適用することができる。

以下、本発明の実施の形態を図面を用いて詳細に説明する。

（実施の形態１）
コンテンツプロバイダーなどのサーバが保持するコンテンツデータを、ネットワークを介して取得するデータ配信システムおいて、コンテンツデータの不正な利用を制限し、データを保護することが求められている。本発明の実施の形態１におけるデータ保護管理装置は、例えば、改竄防止機能付きハードウェアのＩＣカードといった、セキュアなコンテナ内に組み込まれたＤＲＭ（Ｄｉｇｉｔａｌ
Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ）装置であって、正常なデジタルライセンス管理や、デジタルライセンスやライセンスに関連付けられたデジタルデータ格納制御などを行う。なお、これらは、ハードウェア、ソフトウェアのいずれで実現してもよい。

ライセンスは、関連のあるユーセッジルールを含むものが多い。ユーセッジルールは、前記ライセンスと、前記ライセンスに関連付けられたデジタルデータの利用に関するルールを定義するものである。ユーセッジルールで特定の処理に関するルールが定義されていない場合、予め既定されているデフォルトの設定を適用する。もしデフォルトとユーセッジルールが異なった場合、より制約が強く、よりセキュアなルールが適用されなければいけない。

図１７は、データ配信システムのネットワーク環境の概要を示したものである。本発明の実施の形態１におけるＤＲＭ装置は、コンテンツプロバイダーやコンテンツサーバからネットワークを介してデジタルデータを取得するクライアントデバイス上に実装される。なお、このネットワークは、有線であっても無線であってもよく、また、インターネットやイントラネット、サーバと１対１で直接接続、インターネットとローカルＬＡＮとの双方と接続するなど、接続形態は限定されない。

次に、本発明の実施の形態１におけるＤＲＭ装置について、詳細を説明する。

ＤＲＭ装置は、ライセンスデータをセキュアに保存・送信するための暗号化アルゴリズムやプロトコルを提供することにより、ライセンスデータの安全管理を保証するものである。なお、データの送信元（ソース）と送信先（シンク）間の追加的なデータセキュリティ層となるカードを通して転送されるデジタルデータにも適用可能である。

以下、ＤＲＭ装置を備え、ライセンスやデジタルデータをセキュアに管理する装置を、セキュアコンテナと呼ぶ。このセキュアコンテナは、耐タンパ性を持ってセキュアなものである。また、ソースから取得したライセンスデータ（またはコンテンツデータ）は、セキュアコンテナ内のメモリに保存される。

ソースとは、コンテンツのデータの提供元であり、コンテンツプロバイダーや、コンテンツサーバなどを指す。また、ソースは、ＣＤ−ＲＯＭやＤＶＤなどのコンテント媒体も含む。

シンクとは、前述したソースからコンテンツデータを取得する送信先であり、クライアントデバイスや再生装置などを指す。例えば、メモリカードやＩＣカード、ＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）カード、ＣＤ−Ｒなどの記録媒体を備え、これら記録媒体へのＲｅａｄ／Ｗｒｉｔｅ機能を有する装置である。なお、コンテンツデータの再生は、記録媒体を着脱することにより、他の再生専用装置を用いて実行することが可能である。

図１は、本発明の実施の形態１におけるセキュアコンテナの構成を示す機能ブロック図である。

セキュアコンテナ５００は、Ｉ／Ｏポート５０１と、セッションマネージャ５０２と、ライセンス管理エンジン５０６と、ユーセッジルール適用部５０５（ユーセッジルールは、命令セットとも呼ぶ）と、暗号エンジン５０７と、メモリ管理部５０３と、メモリ５０４とを備えている。Ｉ／Ｏポート５０１には、コンテンツの送信元であるソース５１０と、送信先であるシンク５１１が接続されている。シンク５１１には記録装置、再生装置、表示装置、音声出力装置、印刷装置などの装置の全てまたはいずれか一つが含まれる。また、シンク５１１は、セキュアコンテナ５００を含める場合もある。

セッションマネージャ５０２は、Ｉ／Ｏポート５０１を介して行われる接続を管理する。ここでの接続とは、通常の接続だけでなく、暗号化エンジン５０７を用いたセキュアな通信を行うことも可能である。セッションマネージャ５０２は、接続相手と信任状の交換と相互認証することでセッションを確立し、確立したセッションにおける、ライセンスデータとそれに続くコンテンツデータへのアクセス許可などのアクセス制限管理を可能とする。

ライセンス管理エンジン５０６は、セッションマネージャ５０２で確立したセッションにおいて、Ｉ／Ｏポート５０１を介してライセンスデータを取得し、取得したライセンスデータをメモリ５０４に保存し、管理を行う。

ユーセッジルール適用部５０５は、ライセンス管理エンジン５０６が管理する処理対象のライセンスデータに関連付けられたユーセッジルールを決定し、ライセンスデータやコンテンツデータの処理に、この決定したユーセッジルールを適用する。ユーセッジルールには、たとえば、コピー回数の限定や、部分的復号の許可など、種々のルールを含むことができる。

暗号エンジン５０７は、コンテンツデータの暗号化と復号化や署名に必要な公開鍵または共通鍵の暗号アルゴリズムとハッシュアルゴリズムを保持しており、セッションマネージャ５０２が確立したセッションでの暗号化プロトコルの機能を提供する。

メモリ管理部５０３は、メモリ５０４へのアクセスを制御し、暗号エンジン５０７での暗号化と復号化に必要な領域を提供する。メモリ５０４は、コンテンツデータとライセンスデータと、接続の状態情報を、記憶保持する。

以上により、セキュアコンテナは、デジタルライセンスデータをセキュアに保存・送信するための暗号化アルゴリズムやプロトコルを提供することが可能となり、ライセンスデータの安全管理を保証することができる。

また、デジタルライセンスが普通のテキスト形式でもセキュアコンテナの外に出ることが決してないこと、必要な操作はすべてセキュアコンテナ内で行われることである。

なお、このセキュアコンテナを、その全て或いは一部をソフトウェアで実装することにより、携帯電話などの機器にセキュアコンテナを実装することができる。更に、このセキュアコンテナを、メモリカード型のストレージデバイスに埋め込むことにより、ＳＤカードなどのメモリカード型デバイスにセキュアコンテナを実装することにより、基本的に、デジタルライセンスやデータ管理用メモリカード型デバイスの製造が可能になる。または、従来のデータ記憶装置に新たに機能が加わったデジタルライセンス及びデータ管理用メモリカード型デバイスの製造が可能になる。

また、本発明の実施の形態１におけるセキュアコンテナのメモリに、ＩＳＯ／ＩＥＣ９２９３に準拠したＦＡＴファイルシステムを組み込むことにより、デジタルライセンスデータをメモリに独自の方法で保存するのではなく、ファイル構成上に保存でき、また、デジタルライセンスデータの保存や検索、その他の管理操作用ＡＰＩに公開され普及しているＡＰＩを提供できる。

次に、本発明の実施の形態１におけるセキュアコンテナを介して、デジタルデータ（コンテンツ）をある送信元（ソース）から送信先（シンク）に転送する方法の一例を、図３Ａ、図３Ｂ、図４、図５を用いて説明する。

ソースからシンクへセキュアコンテナ５００を介したコンテンツ転送時のトランスコード処理において、４個のデータセットを定義する。４個のデータセットとは、コンテンツ（対応する鍵で暗号化されたもの）９０１と、コンテンツを暗号化するための鍵（ライセンスの一部）と、セキュアコンテナ５００とシンク間のセキュアなチャンネルで使用されるセッション鍵と、セキュアコンテナ５００内で制御操作を行う際に使用され、各鍵に対応した命令セット（ライセンスの一部）である。なお、これらのデータセットは、ソースまたはシンクからセキュアコンテナ５００へ通知されるが、通知するタイミングや通信手段は、同一である必要はなく、異なるパスで転送可能である。

図３Ａに示すように、ソースからシンクへのコンテンツの転送処理は、次の６つの段階に分けられる。ソースが、直接または間接的にコンテンツに関連付けられた鍵で暗号化されコンテンツ９０１を格納している段階（ａ）と、暗号化されたコンテンツをソースからセキュアコンテナへ転送する段階（ｂ）と、ソースからセキュアコンテナへ命令セットを転送する段階（ｃ）と、セキュアコンテナとシンクの間でセキュアなデータ通路を確立する段階（ｄ）と、シンクからセキュアコンテナへ命令セットを転送する段階（ｅ）と、コンテンツに関連付けられた鍵を用いてコンテンツ９０１を復号化し、トランスコード処理した後に、前記セキュアなデータ通路を通して転送する段階（ｆ）とである。

図３Ｂは、本発明の実施の形態１におけるセキュアコンテナ内での、前述した段階（ｆ）のトランスコード処理の概要を示している。

ソース５１０から送られてきた暗号化されたコンテンツ９０１は、Ｉ／Ｏポート５０１を介して、セッションマネージャ５０２に入力される。セッションマネージャ５０２は、復号化部９０３と暗号化部９０４からなるトランスコード処理部９０２と、セッション鍵生成部９１０を有する。復号化部９０３には、ライセンス管理エンジン５０６から複合化の鍵９０５が送り込まれる一方、ユーセッジルール適用部５０５からユーセッジルール９０６が送り込まれる。ユーセッジルールはまた、復号化部９０３と暗号化部９０４との間に設け切替え器９１１にも送られる。暗号化されたコンテンツ９０１は、複合化部９０３において、複合化の鍵９０５を用いて複合化される。また、複合化されたコンテンツは、ユーセッジルールに応じて、再生回数の制限や再生区分の制限が加えられた、条件付のコンテンツとなる。また、ユーセッジルールに応じて、複合化された出力はそのままＩ／Ｏポート５０１からシンク５１１に送られるか、暗号化部９０４に送られるか、全く出力されない。
暗号化部９０４では、セッション鍵９０７により、コンテンツが再暗号化され、トランスコードされた出力９０８としてＩ／Ｏポート５０１を介してシンク５１１に送られる。この実施の形態では、セッション鍵９０７は、シンク５１１からの情報に基づいて、セッション鍵生成部９１０で生成される。シンク５１１では、再暗号化されたコンテンツが複合化され、コンテンツのプレイが可能となる。暗号化部９０４で再暗号化がなされるのは、コンテンツの保護を高めるためである。このようにして、トランスコード処理部９０２では、コンテンツのコード化形式が変更される。セッション鍵生成部９１０では、シンク５１１からの情報に基づいてチャレンジ（トークン）も生成するようにしてもよい。

図４は、本発明の実施の形態１におけるセキュアコンテナの、トランスコード処理の流れの一例を示すフローチャートである。

まず、セッションマネージャ５０２が、Ｉ／Ｏポート５０１を介して暗号化されたコンテンツをソースから受け取る（１００１）。

ライセンス管理エンジン５０６は、受け取ったコンテンツに関連付けられたライセンスデータをメモリ５０４から取得し、取得したライセンスデータをユーセッジルール適用部５０５に通知する。ユーセッジルール適用部５０５は、通知されたライセンスデータに基づいてユーセッジルールを決定し、この決定したユーセッジルールを適用して、復号化が必要か否か判定する（１００２）。

復号化が必要である場合（１００２がＹｅｓ）、暗号エンジン５０７は、ライセンスデータに基づいた復号化の鍵を用いて、暗号化されたコンテンツを復号化する（１００３）。復号化が必要でない場合（１００２がＮｏ）、復号化を行わずに、ステップ１００４に遷移する。

次に、ユーセッジルール適用部５０５は、先ほど決定したユーセッジルールを適用して、暗号化が必要か否かを判定する（１００４）。

暗号化が必要である場合（１００４がＹｅｓ）、暗号エンジン５０７は、セッション鍵を用いてコンテンツを暗号化し（１００５）、セッションマネージャ５０２は、トランスコードされたコンテンツ（再暗号化されたコンテンツ）を、Ｉ／Ｏポート５０１を介してシンク５１１に出力する（１００６）。暗号化が必要でない場合（１００４がＮｏ）、セッションマネージャ５０２は、復号化したコンテンツをそのまま、Ｉ／Ｏポート５０１を介してシンク５１１に出力する（１００７）。

図５は、本発明の実施の形態１におけるセキュアコンテナ内での、トランスコード処理の流れの別の一例を示すフローチャートである。ステップ１２０１，１２０２，１２０３，１２０４は、図４のステップ１００１，１００２，１００３，１００４と同じであるので説明を省略する。図５において、ステップ１２０５で、処理対象のコンテンツを最後までトランスコード処理を行ったか否かを判断し、処理を継続する場合には（１２０５がＮＯ）、ステップ１２０２に戻り、トランスコードを繰り返し処理する。これにより、ストリーミングや周期的なコンテンツを扱ってトランスコードを行うことが可能となる。

なお、セキュアコンテナ５００とシンク５１１間のセキュアな接続（ｄ）をディフィ・ヘルマン（Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ）鍵交換方式を利用して確立することにより、公開されて普及している方法を用いてセキュアな接続を確立できる。

また、シンク５１１への転送の段階（ｆ）での命令セット（ユーセッジルール）に、シンクへの転送に使用するセキュアなデータ通路で用いられる暗号化の強度を記述する制御命令を含むことができる。これにより、制御命令で暗号化の強度（つまり、セキュアコンテナ５００とシンク間のセキュアなチャネルの強度）を管理することが可能となり、データ通路の種類に応じてより柔軟に安全性を向上することができる。

また、シンクへの転送の段階（ｆ）での命令セットに、シンクへの転送に使用するセキュアなデータ通路が有効である期間を示す制御命令を含むことができる。これにより、暗号化（セキュアコンテナ５００とシンク間のセキュアなチャネル）を管理するこの制御命令は、ステップ１００４における暗号化が可能な期間を規定することが可能となる。その結果、顧客が、購買期間中に（放送データなどを）個人用にコピー保存したり、データを計画利用できたりする購買システムを確立することができる。

また、シンクへの転送の段階（ｆ）での命令セットに、データの複製をシンクにいくつ送信するかを示す制御命令を含むことができる。これにより、暗号化（セキュアコンテナとシンク間のセキュアなチャネル）を管理する制御命令は、送信可能なコピー回数を規定することが可能となり、データのバックアップや共有で使用する際に有効な回数を制限管理することができる。

また、シンクへの転送の段階（ｆ）での命令セットに、段階（ｃ）でソースから転送された命令セットの一部または全体を含めることができる。これにより、ソースからセキュアコンテナに送られた制御命令を追加することが可能となり、ソースがセキュリティ要件を規定できるなどの効果がある。ただし、ライセンスや鍵に付随する命令セットに定義されているデフォルト要件が弱められることはない。

また、シンクへの転送の段階（ｆ）での命令セットに、データがシンクに送信されるより事前に、シンクが適合すべき要求事項を示す制御命令を含むことができる。これにより、暗号化（セキュアコンテナとシンク間のセキュアなチャネル）を管理する制御命令は、シンクに対する要件を規定することが可能となり、その結果、ソースがシンクに要件を指示することが出来る。例えば、シンクは購入するのに高額なデータに対してはユーザによる確認といった一定のセキュリティ基準に従わなければならないなどの要件を指定できる。

また、セキュアコンテナとシンク間のセキュアな接続（ｄ）をＣＰＲＭ（Ｃｏｎｔｅｎｔｓ Ｐｒｏｔｅｃｔｉｏｎ ｏｆ Ｒｅｃｏｒｄａｂｌｅ Ｍｅｄｉａ、記録可能メディア用コンテンツ保護技術）を利用して確立することができる。ＣＰＲＭを利用することにより、ＳＤカードなど、ＣＰＲＭに対応するあらゆる環境でシステムを利用できる。

また、ソースからセキュアコンテナへの命令セットの転送の段階（ｃ）を行わなくてもよい。これにより、ソースが単に簡素な記憶装置、或いは記憶メディアである場合にも適用することができる。

次に、本発明の実施の形態１におけるセキュアコンテナを介して、再暗号化を適用した、デジタルデータ（コンテンツ）をある送信元（ソース）から送信先（シンク）に転送する方法の一例について、図６Ａ、図６Ｂ、図７、図８を用いて説明する。

ソースからシンクへセキュアコンテナ５００を介したコンテンツ転送時の再暗号化処理において、３個のデータセットを定義する。３個のデータセットとは、コンテンツ（対応する鍵で暗号化されたもの）１４０１と、コンテンツを暗号化に使用する鍵１４０７と、セキュアコンテナ５００内で制御操作を行う際にしようされる命令セットである。なお、これらのデータセットは、ソースからセキュアコンテナ５００へ通知されるが、通知するタイミングや通信手段は、同一である必要はなく、異なるパスで転送可能である。また、セキュアコンテナ５００は、これらのデータセットを利用して再暗号化を行い、この再暗号化処理では、シンクに対応付けられた特定の鍵を用いて再暗号化を行うため、コンテンツを復号できるのは対応するシンクのみとなる。

図６Ａに示すように、ソースからシンクへの再暗号化を適用したコンテンツの転送処理は、次の５つの段階に分けられる。ソースが、コンテンツに関連付けられたある鍵を用いて対応するコンテンツを暗号化する段階（ａ）と、暗号化されたコンテンツ１４０１をソースからセキュアコンテナに転送する段階（ｂ）と、段階（ａ）で暗号化に使用した鍵をソースからセキュアコンテナへ転送する段階（ｃ）と、ソースからセキュアコンテナへ命令セットを転送する段階（ｄ）と、コンテンツに関連付けられた鍵を用いてコンテンツ１４０１を復号化し、シンクに関連付けられたある鍵を用いてコンテンツを再暗号化する段階（ｅ）とである。なお、復号化と再暗号化の段階（ｅ）は、セキュアコンテナが保持している命令セットによって制御される。段階（ｃ）で説明した鍵は、前に送信または受信したライセンスの一部として送ることもできる。

図６Ｂは、本発明の実施の形態１におけるセキュアコンテナ内での、前述した段階（ｅ）の再暗号化処理の概要を示している。セキュアコンテナ５００は、暗号化されたコンテンツ１４０１を受け取り、再暗号化処理１４０２を実行して、再暗号化されたコンテンツ１４０８を出力する。この再暗号化処理１４０２は、復号化部１４０３と暗号化部１４０４とから構成されており、ライセンスに関連つけられた鍵（復号化の鍵１４０５）で暗号化されたコンテンツ１４０１がセッションマネージャ５０２に入力され、復号化の鍵１４０５を用いて復号化される。その後、関連するユーセッジルール１４０６を適用して、復号化されたコンテンツは、ライセンスに関連つけられた再暗号化の鍵１４０７を用いて再暗号化を行い、再暗号化されたコンテンツを出力する。ここでは、再暗号化の鍵１４０７は、ライセンスに基づいて生成されるので、ライセンス管理エンジン５０６から得られる。再暗号化されたコンテンツ１４０８は、Ｉ／Ｏポート５０１を介してシンク５１１に送られる。シンク５１１では、再暗号化されたコンテンツが記録されるか、または複合化され、プレイされる。

図７は、本発明の実施の形態１におけるセキュアコンテナの、再暗号化処理の流れの一例を示すフローチャートである。

まず、セッションマネージャ５０２が、Ｉ／Ｏポート５０１を介して暗号化されたコンテンツをソースから受け取り、メモリ５０４に保持している（１５０１）。

ライセンス管理エンジン５０６は、コンテンツに関連付けられたライセンスデータをメモリ５０４から取得し、取得したライセンスをユーセッジルール適用部５０５に通知する。ユーセッジルール適用部５０５は、通知されたライセンスに基づいてユーセッジルールを決定し、この決定したユーセッジルールを適用して、再暗号化が許可されるか否かを判定する（１５０２）。

再暗号化が許可されない場合（１５０２がＮｏ）、処理を終了する。一方、再暗号化が許可される場合（１５０２がＹｅｓ）、暗号化エンジン５０７は、復号化の鍵を用いて、暗号化されたコンテンツを復号化する（１５０３）。

暗号化エンジン５０７は、関連するユーセッジルールを適用して、復号化されたコンテンツを、ライセンスに関連付けられた暗号化の鍵を用いて再暗号化を行い（１５０４）、セッションマネージャ５０２は、再暗号化されたコンテンツをＩ／Ｏポート５０１を介して出力する（１５０５）。

図８は、本発明の実施の形態１におけるセキュアコンテナの、周期的なコンテンツの再暗号化処理の流れの一例を示すフローチャートである。まず、セッションマネージャ５０２が、Ｉ／Ｏポート５０１を介して暗号化されたコンテンツをソースから受け取り、メモリ５０４に保持、またはシンク５１１に送信するものとする。

ライセンス管理エンジン５０６は、コンテンツに関連付けられたライセンスデータをメモリ５０４から取得し、取得したライセンスデータをユーセッジルール適用部５０５に通知する。ユーセッジルール適用部５０５は、通知されたライセンスデータに基づいてユーセッジルールを決定し、この決定したユーセッジルールを適用して、再暗号化が許可されるか否かを判定する（１６０１）。

再暗号化が許可されない場合（１６０１がＮｏ）、処理を終了する。一方、再暗号化が許可される場合（１６０１がＹｅｓ）、暗号化エンジン５０７は、メモリ５０４から暗号化されたコンテンツの一部を読み込み、復号化の鍵を用いて、読み込んだ暗号化されたコンテンツを復号化する（１６０２）。

暗号化エンジン５０７は、関連するユーセッジルールを適用して、復号化されたコンテンツの一部を再暗号化し、セッションマネージャ５０２は、再暗号化されたコンテンツをＩ／Ｏポート５０１を介して出力する（１６０３）。

次に、ユーセッジルール適用部５０５は、ユーセッジルールを適用して、コンテンツの次の一部の再暗号化が許可されるか否かを判定する（１６０４）。コンテンツの次の再暗号化が許可されれば（１６０４がＮｏ）、ステップ１６０２に遷移し、処理を継続する。一方、再暗号化が許可されない場合（１６０４がＹｅｓ）、処理を終了する。なお、ステップ１６０４において、コンテンツの最後まで処理が完了した場合も、再暗号化が許可されないと判断し、処理を終了する。

以上により、顧客がコンテンツを再暗号化することにより個別化するこが可能となり、他人にコンテンツを利用されることがない。また、コンテンツを再暗号化処理で匿名化することもできる。

また、段階（ｅ）での命令セット（ユーセッジルール）に、再暗号化に許される計算時間を示す制御命令を含むことができる。これにより、再暗号化を管理する制御命令は、再暗号化可能期間を規定することが可能となる。その結果、顧客が、購買期間中に（放送データなどを）個人用にコピー保存することが可能な購買システムを確立することができる。

また、段階（ｅ）での命令セットに、データの再暗号化された複製をいくつ生成するかを示す制御命令を含むことができる。これにより、再暗号化を管理する制御命令は、コピー回数を規定することが可能となり、データのバックアップや共有で使用する際に有効な回数を制限管理することができる。更に、コンテンツが顧客に対応付けられているので、監視や監査が可能である。

また、段階（ｅ）での命令セットは、再暗号化が許されるより事前に、シンクが適合すべき要求事項を示す制御命令を含むことができる。これにより、再暗号化を管理する制御命令は、シンクに対する要件を規定することが可能となり、その結果、ソースはシンクに要件を指示することが出来る。例えば、シンクは購入するのに高額なデータに対しては一定のセキュリティ基準に従わなければならないなどの要件を指定できる。

また、段階（ｅ）での命令セットは、段階（ｃ）で転送される暗号鍵を含むことができる。再暗号化されるデータの複製の個数を規定する制御命令は、（シンクにある）内蔵型の制御命令ではなく、ソースから転送されなければならない。命令セットに含めることによって、これら制御命令を有効に規定できる。

また、段階（ｅ）は、少なくとも部分的にソースに置かれている命令セットによって制御されることが可能である。この場合、制御命令はソースに存在し、暗号化はソースで行われる。その結果、データ製作者や所有者に対応しているソースが、再暗号化の処理を完全に制御できるという効果がある。また、再暗号化を管理する制御命令がシンクに存在する場合、シンクが独立して再暗号化を行うことが出来るという効果がある。

次に、本発明の実施の形態１におけるセキュアコンテナにおいて、ライセンスの存在を証明する方法の一例を、図９Ａ、図９Ｂ、図１０を用いて説明する。なお、セキュアコンテナは、シンク内に実装されものとし、このシンクに格納されたライセンスの詳細情報をソースに与えることなしに、ライセンスの存在を証明する方法である。

ソースが、シンクのライセンスプールの中にあるライセンスが存在すること示す証明を受け取りたい場合、ソースは、セキュアなチャネルを利用して、シンクに証明書（Ｐｒｏｏｆ）発行の要求を出さなければならない。シンク５１１（セキュアコンテナ５００）は、ソース５１０からシンク５１１に送られた要求（チャレンジ）を考慮に入れて証明書を生成する。生成された証明書は、セキュアなチャネルを介してソース５１０に送られる。

チャレンジは、認証技術を持つプロトコルの一形態であるチャレンジ−レスポンス型プロトコルで用いられるものである。クライアント（シンク）のＤＲＭシステムは、ライセンスに埋め込まれた秘密鍵でチャレンジに署名を行う。サーバー（ソース）は、ライセンスの一部である公開鍵でこの署名を確認する。公開鍵はライセンスと関連付けられてものであってもよい。これにより、ＤＲＭシステムがライセンスを保持し、正しい証明書の要求に答えているかどうかを、サーバは、確認することができる。例えば、利用者は、自身の秘密のコード（チャレンジ）をスマートカードに入力し、あるシステムにログインする新しいコード（レスポンス）を得る、といったものである。

図９Ａに示すように、ライセンスの存在を証明する処理は、次の６つの段階に分けられる。ソースとシンクの相互認証を行う段階（ａ）と、ソースとシンクの間にセキュアなデータ通路を確立する段階（ｂ）と、ライセンスの存在証明の要求であるチャレンジをシンクに転送する段階（ｃ）と、シンクにおいてチャレンジとライセンスのデータを用いて固有の証明を生成する段階（ｄ）と、生成した固有の証明をソースに転送する段階（ｅ）と、ソースにおいて取得した証明を検証する段階（ｆ）とである。

図９Ｂは、本発明の実施の形態１におけるセキュアコンテナ内での、前述した段階（ｄ）のライセンスの存在の証明を生成する処理の概要を示している。セッションマネージャ５０２は、ライセンスの証明を要求するセッションでチャレンジをソース５１０から受け取り、ライセンスの存在を証明する処理を処理部１８０１で生成し、生成した証明書１８０４を出力する。このライセンスの存在を証明する証明書の生成を行う処理部１８０１は、ライセンスに必須の事項の証明書を生成する証明書生成部１８０２と、ライセンスのオプション的な事項のデータを追加処理するデータ追加部１８０３とから構成される。ソース５１０からライセンスの証明が要求されると、セッション鍵生成部９１０は、セッション鍵とチャレンジを生成する。一方、ライセンス管理エンジン５０６から出力されたライセンスは、証明書生成部１８０２に送られる。なお、ライセンスは、メモリ５０４に既に存在しているものとする。証明書生成部１８０２では、セッション鍵とチャレンジを用いて証明書を生成する。その後、必要に応じ、生成された証明書に、ユーセッジルール適用部５０５からのユーセッジルールが適用される。ライセンスにオプション的な事項があるなら、データ追加部１８０３において、ライセンス管理エンジン５０６からの追加ライセンスデータや、メタデータを、証明書に追加する。また、必要であれば、新しく生成された証明書は、セッション鍵を用いて暗号化され、この証明書１８０４を出力する。出力された証明書１８０４は、ライセンスの内容そのものを伝えるものではなく、ライセンスが正しい内容のものであることを証明するものである。出力された証明書１８０４は、Ｉ／Ｏポート５０１を介してソース５１０に送られる。このように、図９Ａのステップ（ｃ）、（ｄ）、（ｅ）を行うことにより、ソース５１０は、シンクまたはセキュアコンテナ５００が適切なライセンスを保持していることを認識することができる。

この証明もしくは証明書とは、ライセンスを示す必要がある場合に、ライセンスの内容まで開示すると不正利用や改ざんされる恐れがあるので、内容を示す必要がない場合に、ただライセンスを保持しているという保証を示すためのものである。例えば、電子チケットでは、有効なチケットを持っていることが重要なのであって、暗号を用いていた中身をすべて開示される必要がない。

また、メタデータとは、ライセンスや証明書に直接は関係のない情報である。例えば、映画館用の電子チケットにおいては座席番号やドリンクサービスなどの付加的な情報を示しており、これだけに限定されない。

図１０は、本発明の実施の形態１におけるセキュアコンテナの、ライセンスの存在の証明を生成する処理の流れの一例を示すフローチャートである。まず、セッションマネージャ５０２が、Ｉ／Ｏポート５０１を介してライセンスの証明を要求するチャンレンジをソース５１０から受け取り、処理を開始する。

ライセンス管理エンジン５０６は、対応するライセンスをメモリ５０４（ライセンスプール）から取得し、取得したライセンスデータをユーセッジルール適用部５０５に通知する。ユーセッジルール適用部５０５は、通知されたライセンスデータに基づいてユーセッジルールを決定し、この決定したユーセッジルールを適用して、チャレンジの要求が有効か無効かを判定する（１９０１）。

要求が無効である場合（１９０１がＮｏ）、処理を終了する。なお、対応するライセンスがメモリ５０４に格納されていない場合も、要求が無効であるとして、処理を終了する。一方、要求が有効である場合（１９０１がＹｅｓ）、証明書生成部１８０２とデータ追加部１８０３は、ライセンスとチャレンジを用いて、証明書を生成する（１９０２、１９０３、１９０４、１９０５、１９０６）。すなわち、まずライセンスの基本的な事項の証明書を生成する（１９０２）。ライセンスのオプション的事項があるかどうかを判断し（１９０３）、あれば証明書にデータ追加する（１９０４）。さらに生成した証明書に暗号化が必要かどうかを判断し（１９０５）、必要と判断されれば暗号化を行う（１９０６）。データ追加部１８０３を省略し、ライセンスの基本的な事項とオプション的な事項の証明書を証明書生成部１８０２で生成する様にしても良い。

ユーセッジルール適用部５０５は、ユーセッジルールを適用して、証明書に付加的なデータの追加が必要か否かを判定する（１９０３）。付加的なデータの追加が必要な場合（１９０３がＹｅｓ）、ライセンス管理エンジン５０６は、ライセンスから付加されるデータを抽出し、証明書にデータを付加する（１９０４）。

ユーセッジルール適用部５０５は、ユーセッジルールを適用して、証明書に暗号化が必要か否かを判定する（１９０５）。暗号化が必要な場合（１９０５がＹｅｓ）、暗号化エンジン５０７は、セッション鍵を用いて証明書の暗号化を行う（１９０６）。最後に、セッションマネージャ５０２は、生成した証明書をＩ／Ｏポート５０１を介して出力し、ソース５１０に送られる。

なお、要求がユーセッジルールに基づいて有効か否かとは、例えば、電子チケットを利用する場合に、その電子チケットの有効期限や利用回数がユーセッジルールに書込まれていて、適合していれば利用可能な電子チケットとして有効であるというものである。この場合、ユーセッジルールを用いて、ライセンスが有効であるかないかを判定したが、ライセンスのデータファイルの名前や作成期日をチェックするなど、システムや外部のものが判定してもよい。

また、オプション的なデータとは、例えば、映画館用の電子チケットにおいて、映画鑑賞後のコメントをアンケートする人を選ぶためのマーキングなどであり、これだけに限定されない。

また、ライセンスに固有な証明書を発行する利点は、シンクがライセンスの詳細情報をソースに送る必要がない点である。また、この証明書は、ライセンスがｅチケットの代わりになる電子チケットシステムでも利用可能である。

また、セキュアコンテナとシンク間のセキュアな接続（ｂ）がディフィ・ヘルマン鍵交換方式を利用して確立することにより、公開され普及している方法によってセキュアな接続を確立できる。

また、セキュアコンテナとシンク間のセキュアな接続（ｂ）をＣＰＲＭを利用して確立することができる。ＣＰＲＭを利用することにより、ＳＤカードなど、ＣＰＲＭに対応するあらゆる環境でシステムを利用できる。

また、証明を生成する段階（ｄ）は、命令セットによって制御される。これにより、証明書の生成を管理する制御命令は、証明書の生成方法に影響を与えることが可能となり、ライセンス発行者が証明書の生成方法を制御できる。

また、証明を生成する段階（ｄ）で、片方向ハッシュ関数を利用するとことが可能であり、これにより、暗号化されたセキュアな証明書を生成できる。

また、証明を生成する段階（ｄ）で、チャレンジと証明を、ソースの公開鍵を用いて暗号化することができる。これにより、ソースとセキュアコンテナ間の接続をセキュアにする必要がないという利点がある。この場合、セキュリティは公開鍵方式で実現される。ここで、ソースの公開鍵は、ライセンスの一部として組み込まれる可能性がある。

また、証明を生成する段階（ｄ）で、証明をソースに転送する前に、証明はライセンスに含まれる鍵を用いて暗号化することができる。これにより、ライセンス発行者や許可された第三者のみが、証明を復号できる。更に、ソースが証明書を復号できるのであれば、そのソースは許可されたものであると考えられることから、ソースが自身の認証をセキュアコンテナに対し行う必要がなくなる。

また、証明をソースに転送する段階（ｅ）で、証明は、ライセンスに含まれる付加的なデータとともに、ソースに転送することができる。これにより、電子チケットを実現することが可能となる。

また、ライセンスに含まれる付加データを証明に添付して、この証明をソースに転送する前に、転送する証明や付加データ、またはこの両方を、ライセンスに含まれる鍵（セッション鍵）によって暗号化することができる。これにより、電子チケットを実現することが可能となる。

また、命令セットに、ライセンスに含まれるどのデータが、証明に付加されるべきかという情報を含めることができる。これにより、証明の生成を管理する制御命令に、ライセンスに含まれるどのデータを証明に添付すべきかを示す情報を含めることが可能となり、コンテンツの有効期限や有効地域情報といった、ライセンスに付随するメタデータの特定のものを証明に添付することができる。

また、命令セットに、ランダムデータを含めることが可能となる。つまり、ランダムデータを証明に添付した後、暗号化を行う。この結果をランダムなデータにみせかけ、先に送付されている他のライセンス証明との関連性なくすことができるという利点が生まれる。

次に、本発明の実施の形態１におけるセキュアコンテナにおいて、ライセンス状態情報の変更方法の一例を、図１１Ａ、図１１Ｂ、図１２を用いて説明する。ライセンス状態情報は、必要であればライセンスに割り当てられるか、ライセンスの中に組み込まれる。ライセンス状態情報を変更したい場合、まず、ソースとセキュアコンテナ間の相互認証を行い、認証が成功することにより、セキュアなチャネルが確立される。次に、ソースからセキュアコンテナに、ライセンス状態情報の変更の要求が送付され、セキュアコンテナは、受け取った要求に従って処理を行う。ライセンス状態情報の変更が成功すれば、セキュアコンテナは、変更の証明をソースに送付する。ソースでは、送付された証明を用いて、要求した変更の結果を確認することができる。なお、セキュアコンテナは、シンク内に実装されものとする。

図１１Ａに示すように、ライセンス状態情報の変更処理は、次の７つの段階に分けられる。ソースとシンクの相互認証を行う段階（ａ）と、ソースとシンクの間にセキュアなデータ通路を確立する段階（ｂ）と、ライセンス状態情報を変更する要求とともにチャレンジをシンクに転送する段階（ｃ）と、シンクにおいて要求された変更をライセンスに行う段階（ｄ）と、ソースにおいてチャレンジとライセンスのデータを用いて固有の証明を生成する段階（ｅ）と、生成した固有の証明をソースに転送する段階（ｆ）と、ソースにおいて取得した証明を検証する段階（ｇ）とである。

図１１Ｂは、本発明の実施の形態１におけるセキュアコンテナ内での、ライセンスの存在の証明を生成し、さらにライセンスを変更する処理の概要を示している。セッションマネージャ５０２は、ソース５１０から、ライセンスの証明を要求するセッションでチャレンジを受け取り、ライセンスの存在の証明を生成する処理を実行すると共に、ライセンスを変更する処理２１０１も実行して、生成した証明書２１０５を出力する。このライセンスの存在の証明を生成し、ライセンスを変更する処理を行う処理部２１０１は、ライセンスの状態情報を変更する処理２１０２と、証明書を生成する処理２１０３と、データを追加する処理２１０４とから構成される。ライセンス状態情報の変更の要求とチャレンジがセッションマネージャ５０２に通知され、ライセンス管理エンジン５０６からライセンスを取得し、通知された変更の要求に従ってライセンスデータを修正する。ライセンス管理エンジン５０６に格納されているライセンスを、この修正されたライセンスに更新し、チャレンジを用いて証明書を作成する。その後、ユーセッジルール適用部５０５から関連するユーセッジルールを適用して、要求があるなら、ライセンスからのデータや、メタデータを、証明書に追加する。また、必要であれば、新しく生成された証明書は、暗号化部２１０６においてセッション鍵を用いて暗号化され、この証明書２１０５を出力する。なお、ユーセッジルールは、出力されるデータパケット（証明書２１０５を示す）にも適用される。

図１２は、本発明の実施の形態１におけるセキュアコンテナの、ライセンスを変更し、さらにライセンスの存在の証明を生成する処理の流れの一例を示すフローチャートである。まず、セッションマネージャ５０２が、Ｉ／Ｏポート５０１を介して、ライセンス状態情報の変更の要求と、ライセンスの証明を要求するチャンレジをソースから受け取り、処理を開始する。

ライセンス管理エンジン５０６は、対応するライセンスをメモリ５０４（ライセンスプール）から取得し、取得したライセンスデータをユーセッジルール適用部５０５に通知する。ユーセッジルール適用部５０５は、通知されたライセンスデータに基づいてユーセッジルールを決定し、この決定したユーセッジルールを適用して、チャレンジの要求が有効か無効かを判定する（２２０１）。

要求が無効である場合（２２０１がＮｏ）、処理を終了する。なお、対応するライセンスがメモリ５０４に格納されていない場合も、要求が無効であるとして、処理を終了する。一方、要求が有効である場合（２２０１がＹｅｓ）、ライセンス管理エンジン５０６は、受け取ったライセンス状態情報の変更の要求に基づき、ライセンスの状態情報を変更し（２２０２）、メモリ５０４（ライセンスプール）に格納されているライセンスを、変更したライセンスに更新する（２２０３）。

次に、暗号エンジン５０７は、ライセンスとチャレンジを用いて、証明書を生成する（２２０４）。

ユーセッジルール適用部５０５は、ユーセッジルールを適用して、証明書に付加的なデータの追加が必要か否かを判定する（２２０５）。付加的なデータの追加が必要な場合（２２０５がＹｅｓ）、ライセンス管理データ５０６は、ライセンスから付加されるデータを抽出し、証明書にデータを付加する（２２０６）。なお、付加データを追加する必要がなければ（２２０５がＮｏ）、データ追加は行わない。

ユーセッジルール適用部５０５は、ユーセッジルールを適用して、証明書に暗号化が必要か否かを判定する（２２０７）。暗号化が必要な場合（２２０７がＹｅｓ）、暗号化エンジン５０７は、セッション鍵を用いて証明書の暗号化を行う（２２０８）。最後に、セッションマネージャ５０２は、生成した証明書をＩ／Ｏポート５０１を介して出力し、ソース５１０に送信する。

なお、ライセンスの変更の例としては、年毎のライセンスや会員制のサービスなどで、年間会費を支払うことにより、ライセンスの有効性が延長されるよう変更する場合である。具体例として、ソフトウェアライセンスやオンラインマガジンの予約購読などに用いることができる。他の例として、複数の電子チケットの場合、有効期限内に１０回利用できる電車の回数券に適用されると、残り利用回数を減少したり、期限になると無効にしたりする変更を行うことができる。

この方法の利点は、ライセンス状態情報の変更で、双方向、あるいは複数の電子チケットを実現できる点とライセンスに対応するデジタルデータの使用を制限できる点である。以下に説明を記す。

ライセンスの変更を許可するシステムでは、システム側での管理外でライセンスが変更される可能性が高くなり、セキュリティ上の危険が増加する。そのため、ライセンスに一つ以上の変更できる情報を持たせ、ライセンスの変更方法や、有効な変更の範囲を、ユーセッジルールに記述することにより、セキュリティ上の危険を減少し、安全にライセンスの変更を可能とすることができる。

ライセンスの状態の例としては、往復チケットで、一つ目の状態は「往路」であり、二つ目の状態は「復路」、というものが挙げられる。往復チケットの状態は、「復路」の後は、自動的に「無効」となる。ライセンスの状態変更のみ許可するのであれば、コンテンツを復号化する鍵などを保護でき、セキュリティを向上させることができる。また、他の例として、ある映画コンテンツの再生許可回数や再生許可時間という状態をライセンスに定めておく。映画コンテンツのデジタルデータが利用されると、ライセンスに含まれる状態情報が、定められた状態まではアップデートされる。回数や時間の定められた状態に達すると、ライセンスは「無効」の状態になり、デジタルデータの利用ができなくなる。

また、セキュアコンテナとシンク間のセキュアな接続（ｂ）がディフィ・ヘルマン鍵交換方式を利用して確立することにより、公開され普及している方法によってセキュアな接続を確立できる。

また、セキュアコンテナとシンク間のセキュアな接続（ｂ）をＣＰＲＭを利用して確立することができる。ＣＰＲＭを利用することにより、ＳＤカードなど、ＣＰＲＭに対応するあらゆる環境でシステムを利用できる。

また、証明を生成する段階（ｅ）は、命令セットによって制御される。これにより、証明書の生成を管理する制御命令は、証明書の生成方法に影響を与えることが可能となり、ライセンス発行者が証明書の生成方法を制御できる。

また、証明を生成する段階（ｅ）で、片方向ハッシュ関数を利用することが可能であり、これにより、暗号化されたセキュアな証明書を生成できる。

また、証明を生成する段階（ｅ）で、チャレンジと証明を、ソースの公開鍵を用いて暗号化することができる。これにより、ソースとセキュアコンテナ間の接続をセキュアにする必要がないという利点がある。この場合、セキュリティは公開鍵方式で実現される。ここで、ソースの公開鍵は、ライセンスの一部として組み込まれる可能性がある。

また、証明を生成する段階（ｅ）で、証明をソースに転送する前に、証明はライセンスに含まれる鍵を用いて暗号化することができる。これにより、ライセンス発行者や許可された第三者のみが、証明を復号できる。更に、ソースが証明書を復号できるのであれば、そのソースは許可されたものであると考えられることから、ソースが自身の認証をセキュアコンテナに対し行う必要がなくなる。

また、証明をソースに転送する段階（ｆ）で、証明は、ライセンスに含まれる付加的なデータとともに、ソースに転送することができる。これにより、電子チケットを実現することができる。

また、ライセンスに含まれる付加データを証明に添付して、この証明をソースに転送する前に、転送する証明や付加データ、またはこの両方を、ライセンスに含まれる鍵（セッション鍵）によって暗号化することができる。これにより、電子チケットを実現することが可能となる。

また、命令セットに、ライセンスに含まれるどのデータが、証明に付加されるべきかという情報を含めることができる。これにより、ライセンスに付随するメタデータの特定のものを証明に添付することができる。

また、命令セットに、ランダムデータを含めることが可能となる。つまり、短ダムデータを証明に添付した後、暗号化を行う。この結果をランダムデータにみせかけ、先に送付されている他のライセンス証明との関連性なくすことができるという利点が生まれる。

図１５は、本発明の実施の形態１におけるシステムの概要を示す図である。サーバであるコンテンツプロバイダー３００（以下、サーバと記載する）と、ＤＲＭ（Ｄｉｇｉｔａｌ Ｒｉｇｈｔ Ｍａｎａｇｅｍｅｎｔ）装置３０８を備えるクライアント３１８との、少なくとも２つの構成要素から構成されている。また、ＰＣ３１９を更に備え、サーバから取得するコンテンツを格納するために用いられてもよい。サーバ３００とクライアント３１８は、ネットワークを介して接続可能であり、クライアント３１８は、サーバ３００からネットワーク経由で取得したコンテンツに対し、記憶保持や再生などの処理を行う装置である。サーバ３００内のコンテンツ記憶装置３０１よりコンテンツを取得する際、サーバ３００は、コンテンツに関連するライセンス（鍵）３０３を用いて配信対象のコンテンツを暗号化する（３０２）。このライセンス３０３は、ＤＲＭ装置３０８とサーバ３００間のセッションで定義されるセッション鍵３０４を用いて暗号化され（３０５）、この後、暗号化されたライセンスは、ＤＲＭ装置３０８に通知される。ＤＲＭ装置３０８は、暗号化されたライセンスを受け取り、セッション鍵３１１を用いて復号化し（３０９）、復号化されたライセンスをライセンス記憶装置３１０に格納する。なお、セッション鍵で復号化するとしたが、暗号化されたままでライセンス記憶装置３１０に格納してもよい。一方、サーバ３００から取得したコンテンツは、クライアント３１８内のコンテンツ記憶装置３１７に格納される。なお、ＰＣ３１９内のコンテンツ記憶装置３０７に格納してもよい。このサーバ３００から取得したコンテンツを再生するために、再生対象のコンテンツをＤＲＭ装置３０８に通知し、ライセンス記憶装置３１０に格納した関連するライセンスを用いて、コンテンツを復号化する（３１２）。なお、復号化に加えて再び暗号化するトランスコード（３１２）を適用することができる。このトランスコードには、ＤＲＭ装置３０８とクライアント３１８間のセッションで定義されるセッション鍵３１３を用いる。クライアント３１８は、ＤＲＭ装置３０８からコンテンツを受け取り、必要に応じてセッション鍵３１４を用いて復号化を行い、取得したコンテンツの再生処理などのメディア出力を実行する。

ライセンス３０３は、ユーセッジルールや暗号部分を含んでいる。ライセンス鍵３０２は、ライセンス３０３の暗号に関する一部であり、ライセンス内に一つ以上含まれてもよい。

クライアント３１８とは、エンドユーザのデバイスや、コンテンツを取り込むデバイスを指す。ＤＲＭ装置３０８とは、クライアント３１８に実装されるＤＲＭシステムであり、クライアント３１８内に固定されていても、着脱可能であってもよい。着脱可能であるものとして、ＤＲＭシステムを含むメモリカードが考えられる。

セッション鍵は、セキュアな接続を保証するために暗号化と復号化に用いられる一時的な鍵である。セッション鍵は、接続のやり取りであるセッションが行われている期間と場所のみ有効である。

図１６は、本発明の実施の形態１におけるの別のシステムの概要を示す図である。サーバであるコンテンツプロバイダー３００（以下、サーバと記載する）と、ＤＲＭ装置３０８を備えるクライアント３１８と、外部の記憶装置メディア４００との、少なくとも３つの構成要素から構成されている。前述した図１５と基本的には同じであるが、コンテンツデータは外部の記憶メディア４００（または外部の記憶デバイス）にのみ格納されることができる点が異なる。サーバ３００から取得したコンテンツを再生するには、再生対象のコンテンツを記憶メディア４００からクライアント３１８のＤＲＭ装置３０８に通知し、ライセンス記憶装置３１０に格納した関連するライセンスを用いて、コンテンツを復号化する（３１２）。なお、復号化に加えて再び暗号化するトランスコード（３１２）を適用することができる。このトランスコードには、ＤＲＭ装置３０８とクライアント３１８間のセッションで定義されるセッション鍵３１３を用いる。クライアント３１８は、ＤＲＭ装置３０８からコンテンツを受け取り、必要に応じてセッション鍵３１４を用いて復号化を行い、取得したコンテンツの再生処理などのメディア出力を実行する。

例えば、ユーザはカード型システムを利用して、オンラインでライセンスを購入することができる。購入を行う時は、認証確認を実行し、認証が無事完了した時点で、システムはライセンス発行者（サーバ３００）とのセキュアな接続を確立する。その後、要求されたライセンスデータを暗号化し、システムに送付する。システムは、暗号化されたライセンスデータを復号（３０９）し、それが有効なものであるかを確認した後、ライセンス記憶装置３１０に保存する。ライセンスを暗号化した状態で保存するという命令セット、つまりユーセッジルールがある場合は、システムに内蔵された固有のデバイス秘密鍵を使ってライセンスを暗号化した後、データをライセンス記憶装置３１０に保存する。

ユーザが例えばオーディオコンテンツを再生したい場合、ＤＲＭ装置３０８は、まず認証を行い、認証が正常に終了すると、ユーザのクライアント再生デバイス（クライアント３１８）とのセキュアな接続を確立し、セッション鍵（３１３、３１４）を用意する。セッション鍵（３１３、３１４）が発行されると、該当するコンテンツはＤＲＭ装置３０８に送付される。ここでは、コンテンツは対応するライセンスに含まれる鍵で暗号化（３１２）され、セッション鍵で再び暗号化（３１２）された後、クライアントの再生デバイス（クライアント３１８）に転送される。ＤＲＭ装置３０８からクライアント３１８に送付されたコンテンツは、決められたセッション鍵３１４を使って復号された後、クライアントデータパス（３１５）を処理され、クライアント３１８のメディア出力（３１６）に送付される。

ライセンス付きのコンテンツを再暗号化し、再発行されたライセンスと対応付ける必要がある場合、コンテンツはクライアント３１８からＤＲＭ装置３０８に送られ、まず現行のライセンス鍵で復号され、再発行されたライセンス鍵で再び暗号化された後、クライアント３１８に返送される。この場合、オリジナルのライセンスに対応付けられている命令セット（ユーセッジルール）で再暗号化処理の制御と認可を行う。

電子チケットサービスなどの目的で、ＤＲＭ装置にライセンスの存在証明の発行を、その権利を持ったものが要求した場合、本発明では、クライアントに存在証明以上のライセンスデータを送信する必要がない。クライアント或いは権利を持つ者がＤＲＭ装置との認証に成功すると、両者間にセキュアな接続が確立され、セッション鍵が決定される。権利を持つ者或いはクライアントがＤＲＭ装置に存在証明を要求すると、ＤＲＭ装置は証明を作成する。証明書にはオプションで付加データを含ませることが出来る。ライセンスに付随する制御命令セット、つまり利用条件は、ライセンスの存在が証明できれば、証明書の生成に影響を与えることができる。制御命令セットは、証明書発行要求ごとに異なる証明書を発行する、証明書はランダムな特質を持つ、などの要求を出し、証明書生成に影響を与えることが出来る。

権利を持つ者が、複数の電子チケットを求めるなど、ライセンス状態データの変更を求める場合、その変更の制御命令が存在証明書の発行要求に組み込まれる。この制御命令には、該当するライセンスの状態情報にどのような変更を加えるべきかを定義している。ＤＲＭ装置は、要求された変更を実行し、アップデートされた状態データが追加されたライセンス証明を発行要求者に返す。

（実施の形態２）
図２は、本発明の実施の形態２におけるセキュアコンテナの構成を示す機能ブロック図である。

セキュアコンテナ６００は、Ｉ／Ｏポート５０１と、セッションマネージャ５０２と、ライセンス管理エンジン５０６と、ユーセッジルール適用部５０５と、暗号エンジン５０７と、メモリ管理部５０３と、メモリ５０４とを備えている点は実施の形態１と同様だが、実施の形態２においては、デバイス依存鍵保持部６０１と、ログ管理エンジン６０２とを追加している。

本発明の実施の形態２において新規に追加された構成要素について説明する。

デバイス依存鍵保持部６０１は、各クライアントのシステムに固有の鍵であって、暗号化と復号化のために、１つだけでなく複数個備えることが可能である。例えば、暗号エンジン５０７が、共通鍵暗号のアルゴリズムを用いてライセンスデータなどを暗号化および復号化する際に、このデバイス依存鍵保持部６０１からのデバイス依存鍵を使用する。デバイス依存鍵は、デバイスごとに固有であって、予めデバイス内部に格納またはハードコードされている。また、デバイス依存鍵のうち、利用者の情報を参照していない場合、匿名（ａｎｏｎｙｍｏｕｓ）の性質を持つという。このようにライセンスが匿名で格納されている場合、デバイス依存鍵または組込みの鍵が用いられる。

ログ管理エンジン６０２は、セキュアコンテナで処理された状態の変化をログ情報として記録保持を行う。セッション上の通信トランザクションのログ情報や、暗号エンジン５０７での暗号や復号の処理や、その他のセキュリティに関する処理を、セッションマネージャ５０２から受け取り、ログ情報として記録保持する。

以上により、システムに固有な鍵をコンテンツの暗号化に用いることが可能となり、データの盗聴や改ざんを防ぐ安全性をより強化できる。更に、セキュアコンテナやそこに保存されているデジタルライセンスデータが改ざんや乱用を受けた場合、システム制作者や許可された第三者がそれを認識できるようになる。

本発明の実施の形態２におけるセキュアコンテナにおいて、ライセンスを保存する方法の一例を、図１３Ａ、図１３Ｂ、図１４を用いて説明する。セキュアコンテナとソース間の相互認証を行い、認証が成功することにより、セキュアなチャネルが確立される。このセキュアなチャネルを介して受け取ったライセンスデータは、セキュアコンテナ内の内部メモリに保存される。なお、セキュアコンテナは、シンク内に実装されものとする。

図１３Ａに示すように、ライセンスを保存する処理は、次の４つの段階に分けられる。ソースとシンクの相互認証を行う段階（ａ）と、ソースとシンクの間にセキュアなデータ通路を確立する段階（ｂ）と、ライセンスをセキュアなデータ通路を通してソースからシンクに転送する段階（ｃ）と、シンクにおいてラインセンスを格納する段階（ｄ）とである。

図１３Ｂは、本発明の実施の形態２におけるセキュアコンテナ内での、ライセンスを保存する処理の概要を示している。セッションマネージャ５０２は、暗号化されたライセンス受け取り、ライセンスを保存する処理２４０２を実行する。ライセンスは、ライセンス管理エンジン５０６、メモリ管理部５０３を介して、メモリ５０４に格納される。このライセンスを保存する処理２４０２は、復号化２４０３と暗号化２４０４とから構成される。ソース５１０から送られてきた暗号化されたライセンス２４０１は、セッションマネージャ５０２に入力される。セッション鍵生成部９１０は、ソース５１０からのセッションに基づいてセッション鍵を生成し、このセッション鍵用いて、暗号化されたライセンスが復号化される。複合化された内容にはユーセッジルールも含まれており、そのユーセッジルールを適用する。さらに、必要であるなら、復号化されたライセンスを再暗号化する。再暗号化は、デバイス依存鍵保持部６０１からのデバイス依存鍵を用いて行われる。復号化もしくは再暗号化されたライセンスを、ライセンスプールに２４０５に格納する。

図１４は、本発明の実施の形態２におけるセキュアコンテナの、ライセンスを保存する処理の流れの一例を示すフローチャートである。まず、セッションマネージャ５０２が、Ｉ／Ｏポート５０１を介して、ソース５１０から暗号化されたライセンスを受け取り、処理を開始する。受け取ったライセンスは、ソース５１０から別ルート（たとえば郵送）で送られてきたユーザの秘密鍵（ＩＤ固有の場合）で復号できるものと、デバイス依存鍵（匿名の場合）で復号できるものとがある。

ライセンス管理エンジン５０６は、受け取ったライセンスがＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）固有であるか否かを判断する（２５０１）。ライセンスがＩＤ固有である場合（２５０１がＩＤ固有）、暗号エンジン５０７は、対応するＩＤを持つユーザの秘密鍵を用いて、ライセンスを復号化する（２５０２）。一方、ライセンスが匿名（ａｎｏｎｙｍｏｕｓ）である場合（２５０１が匿名）、暗号エンジン５０７は、デバイス依存の秘密鍵（デバイス依存鍵６０１）を用いて、ライセンスを復号化する（２５０３）。ライセンス管理エンジン５０６は、復号化したライセンスが有効か否かを判断し（２５０４）、有効でない場合（２５０４がＮｏ）、処理を終了する。

ライセンス管理エンジン５０６は、復号化したライセンスをユーセッジルール適用部５０５に通知する。ユーセッジルール適用部５０５は、通知されたライセンスに基づいてユーセッジルールを決定し、この決定したユーセッジルールを適用して、ライセンスの暗号化が必要か否かを判定する（２５０５）。

ライセンスは暗号化が必要な場合（２５０５がＹｅｓ）、暗号化エンジン５０７は、復号化されたライセンスを、デバイス依存の秘密鍵（デバイス依存鍵６０１）を用いて暗号化する（２５０６）。暗号化が必要でない場合（２５０５がＮｏ）、暗号化は行わない。暗号化管理エンジン５０６は、復号化されたライセンス又は再暗号化されたライセンスを、メモリ５０４（ライセンスプール）に格納する（２５０７）。

なお、ＩＤ固有のライセンスとは、利用者の秘密鍵で暗号化されているライセンスであり、ライセンスプール（ライセンス管理エンジン）に格納される。利用者の秘密鍵とは、パスワードなどの利用者に関連する情報を含んでいたり、システムの利用者の情報として登録されていたりする。しかし、暗号化に用いられる利用者の秘密鍵は、公開されず、ユーザ自身も、システムに格納されている鍵以外は複製を持つことができない。この秘密鍵は、コンテンツプロバイダーや、システムの製造者、認可された第三者機関により与えられたり、デバイス内部で生成されたりする。

一方で、暗号化に用いる鍵と復号化に用いる鍵が異なる公開鍵暗号を用いることもできる。公開鍵を採用する場合、暗号化に用いる公開鍵はデバイスから提供される。ただし、暗号化の鍵と関連はあるものの、暗号化の鍵のみでは復号化の鍵を、適当な時間内には計算することはできない。

以上により、ライセンスをセキュアコンテナに保存する時に、ライセンスデータはソースからシンクへセキュアなデータ通路を介して転送され、シンクのメモリに安全に保存される。ライセンスデータは決して平文で公開されることはない。

また、セキュアコンテナとシンク間のセキュアな接続がディフィ・ヘルマン鍵交換方式を利用して確立することにより、公開され普及している方法によってセキュアな接続を確立できる点である。

また、セキュアコンテナとシンク間のセキュアな接続（ｂ）をＣＰＲＭを利用して確立することができる。ＣＰＲＭを利用することにより、ＳＤカードなど、ＣＰＲＭに対応するあらゆる環境でシステムを利用できる。

また、ライセンスを保存する別の方法として、ソースとシンクの相互認証を行う段階（ａ）と、シンクに関連付けられた公開鍵をソースに転送する段階（ｂ）と、シンクに関連付けられた公開鍵を用いて暗号化されたライセンスをソースからシンクに転送する段階（ｃ）と、シンクにおいてラインセンスをシンクに関連付けられた秘密鍵によって復号化する段階（ｄ）とにより構成される方法であってもよい。この場合、セキュアコンテナとソースは相互認証を行い、認証が成功すると、デバイスに対応した公開鍵がソースに送付される。ソースでは、受け取った公開鍵を使ってライセンスデータを暗号化し、暗号データをセキュアコンテナに送る。セキュアコンテナでは、受け取ったデータを内部メモリに保存する。
上記の実施の形態は、組み合せて用いることも可能である。

以上により、ライセンスをセキュアコンテナに保存する時に、ライセンスデータはソースからシンクへセキュアに転送され、シンクのメモリに安全に保存される。ライセンスデータは決して平文で公開されることはない。

本発明は、データ保護管理装置およびデータ保護管理方法に利用可能である。

本発明の実施の形態１におけるセキュアコンテナの構成の一例を示すブロック図。 本発明の実施の形態２におけるセキュアコンテナの構成の一例を示すブロック図。 復号化したコンテンツをシンクに与える手順を示す図。 本発明の実施の形態１におけるセキュアコンテナの、トランスコード処理の概要を示す図。 本発明の実施の形態１におけるセキュアコンテナの、トランスコード処理の流れの一例を示すフローチャート。 本発明の実施の形態１におけるセキュアコンテナの、トランスコード処理の流れの一例を示すフローチャート。 復号化したコンテンツをセキュアコンテナに与える手順を示す図。 本発明の実施の形態１におけるセキュアコンテナの、再暗号化処理の概要を示す図。 本発明の実施の形態１におけるセキュアコンテナの、再暗号化処理の流れの一例を示すフローチャート。 本発明の実施の形態１におけるセキュアコンテナの、周期的な再暗号化処理の流れの一例を示すフローチャート。 ライセンスの存在証明をソースが受ける手順を示す図。 本発明の実施の形態１におけるセキュアコンテナの、ライセンスの存在の証明を生成する処理の概要を示す図。 本発明の実施の形態１におけるセキュアコンテナの、ライセンスの存在の証明を生成する処理の流れの一例を示すフローチャート。 ライセンスの変更証明をソースが受ける手順を示す図。 本発明の実施の形態１におけるセキュアコンテナの、ライセンスの存在の証明を生成し、さらにライセンスを変更する処理の概要を示す図。 本発明の実施の形態１におけるセキュアコンテナの、ライセンスの存在の証明を生成し、さらにライセンスを変更する処理の流れの一例を示すフローチャート。 ライセンスの格納の手順を示す図。 本発明の実施の形態２におけるセキュアコンテナの、ライセンスを保存する処理の概要を示す図。 本発明の実施の形態２におけるセキュアコンテナの、ライセンスを保存する処理の流れの一例を示すフローチャート。 本発明の実施の形態１におけるデータ配信システムの概要の一例を示す図。 本発明の実施の形態１におけるデータ配信システムの概要の別の一例を示す図。 本発明の実施の形態１におけるデータ配信システムのネットワーク環境の概要の一例を示す図。 従来のデータ配信システムの概要の一例を示す図。 従来のデータ配信システムの概要の別の一例を示す図。

符号の説明

５００： セキュアコンテナ
５０１：Ｉ／Ｏポート
５０２：セッションマネージャ
５０３：メモリ管理部
５０４：メモリ
５０５：ユーセッジルール適用部
５０６：ライセンス管理エンジン
５０７：暗号エンジン
５１０：ソース
５１１：シンク
６０１：デバイス依存鍵保持部
６０２：ログ管理エンジン
９０２：トランスコード処理部
９０３：復号化部
９０４：暗号化部
１４０２：再暗号化処理
１４０３：復号化部
１４０４：暗号化部
１８０１：証明書の生成を行う処理部
１８０２：証明書生成部
１８０３：データ追加部

Claims (20)

1. 送信元と送信先との間でライセンスと暗号化されたコンテンツのデータ通信が行われ、通信されるデータの保護管理を行うデータ保護管理装置であって、
   送信元からライセンス及び暗号化されたコンテンツを得るための処理を行うセッションマネージャ部と、
   前記セッションマネージャ部で得た前記ライセンスを保存し、管理するライセンス管理エンジン部と、
   前記ライセンスを保存するメモリ部とを備え、
   前記セッションマネージャ部は、送信元から、前記ライセンスの存在証明を要求するチャレンジを受けた場合、ライセンスの存在を証明する証明書を生成すると共に、生成した証明書を送信元に送信することを特徴とするデータ保護管理装置。
2. 前記ライセンスに関連付けられたユーセッジルールを決定し、前記ライセンスおよび前記コンテンツの少なくともいずれか一方の処理に前記ユーセッジルールを適用するユーセッジルール適用部を備えたことを特徴とする請求項１記載のデータ保護管理装置。
3. 前記セッションマネージャ部は、前記証明書を暗号化することを特徴する請求項１記載のデータ保護管理装置。
4. 前記セッションマネージャ部は、前記ライセンスのオプション的な事項を証明書に加えることを特徴とする請求項１記載のデータ保護管理装置。
5. 前記オプション的な事項のデータを前記ライセンスに含まれる鍵を用いて暗号化することを特徴とする請求項４記載のデータ保護管理装置。
6. 前記ユーセッジルールは、前記ライセンスに基づいて、前記証明書に加えるデータを決定する情報を含むことを特徴とする請求項２記載のデータ保護管理装置。
7. 前記セッションマネージャ部は、ライセンスの変更を送信元から受けた場合は、ライセンス管理エンジンから変更前のライセンスを読出し、ライセンスの変更を行い、変更後のライセンスをライセンス管理エンジン部に保存することを特徴とする請求項１記載のデータ保護管理装置。
8. 前記セッションマネージャ部は、コンテンツを上記鍵で復号化することを特徴とする請求項１記載のデータ保護管理装置。
9. 前記セッションマネージャ部は、復号化されたコンテンツを、再び暗号化することを特徴とする請求項８記載のデータ保護管理装置。
10. 再び暗号化するための鍵は、送信先からの情報に基づいて生成することを特徴とする請求項９記載のデータ保護管理装置。
11. 送信元と送信先との間でライセンスと暗号化されたコンテンツのデータ通信が行われ、通信されるデータの保護管理を行うデータ保護管理方法であって、
    送信元からライセンス及び暗号化されたコンテンツを得るための処理を行うセッションステップと、
    前記セッションマネージャ部で得た前記ライセンスを保存し、管理するステップと、
    前記暗号化されたコンテンツの復号化に必要な鍵を保持するステップと、
    前記ライセンスを保存するステップとを備え、
    前記セッションステップは、送信元から、前記ライセンスの存在証明を要求するチャレンジを受けた場合、ライセンスの存在を証明する証明書を生成すると共に、生成した証明書を送信元に送信することを特徴とするデータ保護管理方法。
12. 前記ライセンスに関連付けられたユーセッジルールを決定し、前記ライセンスおよび前記コンテンツの少なくともいずれか一方の処理に前記ユーセッジルールを適用することを特徴とする請求項１１記載のデータ保護管理方法。
13. 前記セッションステップは、前記証明書を暗号化することを特徴する請求項１１記載のデータ保護管理方法。
14. 前記セッションステップは、前記ライセンスのオプション的な事項を証明書に加えることを特徴とする請求項１１記載のデータ保護管理方法。
15. 前記オプション的な事項のデータを前記ライセンスに含まれる鍵を用いて暗号化することを特徴とする請求項１４記載のデータ保護管理方法。
16. 前記ユーセッジルールは、前記ライセンスに基づいて、前記証明書に加えるデータを決定する情報を含むことを特徴とする請求項１２記載のデータ保護管理方法。
17. 前記セッションステップは、ライセンスの変更を送信元から受けた場合は、ライセンス管理エンジンから変更前のライセンスを読出し、ライセンスの変更を行い、変更後のライセンスをライセンス管理エンジン部に保存することを特徴とする請求項１１記載のデータ保護管理方法。
18. 前記セッションステップは、コンテンツを上記鍵で復号化することを特徴とする請求項１１記載のデータ保護管理方法。
19. 前記セッションステップは、復号化されたコンテンツを、再び暗号化することを特徴とする請求項１８記載のデータ保護管理方法。
20. 再び暗号化するための鍵は、送信先からの情報に基づいて生成することを特徴とする請求項１９記載のデータ保護管理方法。
    

Images