(57)【要約】【課題】セキュア通信方法およびシステムを提供する。【解決手段】セキュア通信方法は、デバイスとのセキュア通信のために、コンテンツ保護のためのパラメータを取得して、前記デバイスと証明書を交換して相互を認証して、証明書を介して認証される鍵を用いて前記デバイスとのセキュア認証チャネルを確立するために前記鍵を前記デバイスと交換する。したがって、セキュア認証チャネル鍵を計算してセキュア認証チャネルを確立してセキュア通信を遂行することができる。【選択図】なし
2010526507.tif 000002
【特許請求の範囲】
【請求項１】
デバイス間のセキュア通信方法において、
コンテンツの保護のためのパラメータを取得するステップと、
証明書を用いて前記デバイスを認証するステップと、
前記証明書を介して認証される鍵を用いて前記デバイスとのセキュア認証チャネルを確立するために鍵を前記デバイスと交換するステップと、
前記デバイスから前記コンテンツがコピーまたは移動されると、前記コンテンツのコンテンツライセンス保護モードを変更するステップと、
を有することを特徴とするセキュア通信方法。
【請求項２】
前記鍵を前記デバイスと交換するステップは、
前記セキュア認証チャネルで使用するためのセキュア認証チャネル鍵の計算に必要な鍵の値を計算し、前記デバイスと前記鍵の値をやりとりするステップを含むことを特徴とする請求項１に記載のセキュア通信方法。
【請求項３】
前記鍵の値を使用して前記セキュア認証チャネル鍵を計算するステップをさらに含むことを特徴とする請求項２に記載のセキュア通信方法。
【請求項４】
前記鍵の値をやりとりするステップは、
特定の計算値を前記証明書と共に前記デバイスに送信するステップと、
前記デバイスで前記証明書を用いた有効性の検証を遂行した後、前記デバイスから予め定められたアルゴリズムに従って計算されたハッシュ値および前記デバイスの前記証明書を受信するステップと、
前記デバイスの証明書を用いて有効性の検証を遂行し、予め定められたアルゴリズムに従って計算されたハッシュ値を前記デバイスに送信するステップと、を有することを特徴とする請求項２に記載のセキュア通信方法。
【請求項５】
前記鍵は、予め定められたアルゴリズムに従って計算される公開鍵の値およびハッシュ値のうち少なくとも一つであることを特徴とする請求項１に記載のセキュア通信方法。
【請求項６】
相互作用可能な第１のデバイスおよび第２のデバイスを含み、
前記第１のデバイスと前記第２のデバイスは、証明書を用いて相互に認証し、前記第１のデバイスと前記第２のデバイスとの間のセキュア認証チャネルを確立するために前記証明書によって認証される鍵を交換することを特徴とするセキュア通信システム。
【請求項７】
前記第１のデバイスおよび第２のデバイスは、前記セキュア認証チャネルに使用するためのセキュア認証チャネル鍵の計算に必要な鍵の値を計算し、前記鍵の値を互いに交換することを特徴とする請求項６に記載のセキュア通信システム。
【請求項８】
前記第１のデバイスは、特定の計算値を前記第１のデバイスの前記証明書と共に前記第２のデバイスに送信し、前記第２のデバイスは、前記第１のデバイスの前記証明書を用いて有効性の検証を遂行し、予め定められたアルゴリズムに従ってハッシュ値を計算し、前記計算したハッシュ値を前記第２のデバイスの前記証明書と共に前記第１のデバイスに送信し、前記第１のデバイスは、前記第２のデバイスの証明書を用いた有効性の検証を遂行し、予め定められたアルゴリズムに従ってハッシュ値を計算し、前記計算したハッシュ値を前記第２のデバイスに送信することを特徴とする請求項７に記載のセキュア通信システム。
【請求項９】
前記第１のデバイスおよび前記第２のデバイスのうち少なくとも一つは、認証の際、外部の特定のオブジェクトに前記証明書の有効性の検証を要求することを特徴とする請求項６に記載のセキュア通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、セキュア通信方法およびシステムに関し、デバイス間で証明書および認証鍵を交換してセキュア認証チャネルを確立するセキュア通信技術に関する。
【背景技術】
【０００２】
一般に、デジタル著作権管理（Digital Rights Management；ＤＲＭ）は、デジタルリソース（Digital Resource）の不法複製および使用を未然に防止して適法な権限を有する使用者だけがデジタルリソースを使用することができるようにする総合的リソース保護技術である。ＤＲＭは、デジタルリソースの生産および流通全般に対して総合的な保護体系（Framework）を提供する。例えば、ＤＲＭは、暗号化技術を用いてデジタルリソースをパッケージ形態の暗号化されたデータに変換して、適法な認証手続きをふまないと該当リソースを使用することができないようにする。
【０００３】
このＤＲＭは、多様なリソースサービスモデルと連係しながら、安定的かつ合法的なリソースサービスの基盤となっている。実際に現在複数のサービス提供者は、各自固有のＤＲＭを採択して自分が提供するリソースを保護している。例えば、オンラインを介して音源を提供する音源サービスの場合、不法な複製を防止することができるように特定の暗号化パターンで暗号化された音源を提供しており、この音源は、該当サービス提供者によって提供されたアプリケーションでだけ再生可能にしている。
【０００４】
しかしながら、ＤＲＭは、その特性上、技術的または政策的にかなり排他的な特徴があるため、相異なるＤＲＭ間の相互互換は不可能である。したがって、特定のサービス事業者により提供されるリソースは、他の事業者により提供されるアプリケーションでは使用することができない。このため、ＤＲＭリソースの普遍的な使用を事実上制限し、合法的なコンテンツ市場の発展を遮る主要な問題点として指摘されている。
【０００５】
したがって、最近では、閉鎖的なＤＲＭ構造間で互換性のあるフレームワークを提供しようとする努力がなされており、その代表的なものがＤＲＭ相互互換システムである。ＤＲＭ相互互換システムは、相異なるＤＲＭ間を仲介することによって、リソースまたはライセンスを交換して使用することができるようにするシステムを意味してもよい。
【０００６】
このＤＲＭ相互互換システムの具現のためには、システムの各オブジェクトを定義し、これらのシステムオブジェクト間で連動することができるシナリオが提示されなければならない。特にＤＲＭ相互互換システムのようにコンテンツまたはライセンスの送信が頻繁に行われるシステムでは、デバイス間の通信に高いセキュリティが要求される。したがって、これらのシステムでは、デバイス間で認証およびセキュア通信を遂行することができる手順およびその関連技術が切実に必要とされる。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明が解決しようとする技術的課題は、デバイス間で予め定められたプロトコルを用いて相互認証し、その認証に基づいてセキュア通信を遂行するセキュア通信方法およびシステムを提供することである。
【課題を解決するための手段】
【０００８】
これらの技術的課題を解決するために、本発明は、一態様（Aspect）として、セキュア通信方法を提供する。前記セキュア通信方法は、デバイスとのセキュア通信方法において、コンテンツ保護のためのパラメータを取得するステップと、前記デバイスと証明書を交換して相互を認証するステップと、前記証明書を介して認証される鍵を用いて前記デバイスとのセキュア認証チャネルを確立するために前記鍵を前記デバイスと交換するステップと、を含む。
【０００９】
前記セキュア通信方法は、前記デバイスからコンテンツがコピー（Copy）または移動（Move）されると、前記コンテンツのコンテンツライセンス保護モードを変更するステップをさらに含んでもよい。
【００１０】
前記鍵を前記デバイスと交換するステップは、前記セキュア認証チャネルで使用するためのセキュア認証チャネル鍵の計算に必要な鍵の値を計算し、前記デバイスと前記鍵の値をやりとりするステップを含んでもよい。この場合、前記セキュア通信方法は、前記鍵の値を使用して前記セキュア認証チャネル鍵を計算するステップをさらに含んでもよい。
【００１１】
前記鍵の値をやりとりするステップは、特定の計算値を証明書と共に前記デバイスに送信するステップと、前記デバイスで前記証明書を用いた有効性の検証を遂行した後、前記デバイスから予め定められたアルゴリズムに従って計算されたハッシュ値および前記デバイスの証明書を受信するステップと、前記デバイスの証明書を用いて有効性の検証を遂行し、予め定められたアルゴリズムに従って計算されたハッシュ値を前記デバイスに送信するステップとを含んでもよい。
【００１２】
前記鍵は、特定のアルゴリズムに従って計算される公開鍵の値およびハッシュ値のうち少なくともいずれか一つでもよい。
【００１３】
一方、前述した技術的課題を解決するために、本発明は、他の態様として、セキュア通信システムを提供する。前記セキュア通信システムは、相互作用可能な第１のデバイスおよび第２のデバイスを含んでもよい。前記第１のデバイスと前記第２のデバイスは、証明書を交換してお互いに認証して、前記第１のデバイスと前記第２のデバイスとの間のセキュア認証チャネルを確立するために前記証明書を介して認証される鍵を交換することができる。
【００１４】
前記第１のデバイスおよび第２のデバイスは、前記セキュア認証チャネルに使用するためのセキュア認証チャネル鍵の計算に必要な鍵の値を計算し、前記鍵の値を互いに交換することができる。
【００１５】
前記第１のデバイスは、特定の計算値を前記第１のデバイスの証明書と共に前記第２のデバイスに送信し、前記第２のデバイスは、前記第１のデバイスの証明書を用いた有効性の検証を遂行し、予め定められたアルゴリズムに従ってハッシュ値を計算して前記第２のデバイスの証明書と共に前記第１のデバイスに送信して、前記第１のデバイスは、前記第２のデバイスの証明書を用いた有効性の検証を遂行し、予め定められたアルゴリズムに従ってハッシュ値を計算して前記第２のデバイスに送信することができる。
【００１６】
一方、前記第１のデバイスおよび前記第２のデバイスのうち少なくともいずれか一つは、認証の際、外部の特定のオブジェクト、例えば、オンライン証明書状態プロトコル（On-line Certificate Status Protocol；ＯＣＳＰ）サーバなどに証明書の有効性の検証を要求することもできる。
【発明の効果】
【００１７】
以上、説明した通り、本発明によると、デバイス間で証明書の交換を介して認証を遂行して、セキュア認証チャネル鍵の計算に必要な認証鍵の値を交換してセキュア認証チャネル鍵を計算することができる。したがって、セキュア認証チャネルを確立してセキュア通信を遂行することができる。
【図面の簡単な説明】
【００１８】
【図１】本発明の望ましい実施例に係るセキュア通信のためのハンドシェイク方法を遂行することができるシステムの構成を図示するブロック図である。
【図２】本発明の望ましい実施例に係るセキュア通信方法を図示するフローチャートである。
【図３】図２に示したパラメータ取得ステップの詳細手順およびプロトコル構造を図示するメッセージシーケンスチャートである。
【図４】図２に示した相互認証ステップの詳細手順およびプロトコル構造を図示するメッセージシーケンスチャートである。
【図５】図２に示した鍵交換ステップの詳細手順およびプロトコル構造を図示するメッセージシーケンスチャートである。
【図６】ＤＲＭ相互互換システムからＯＭＡ ＤＲＭシステムにライセンスを送信する手順を図示するメッセージシーケンスチャートである。
【発明を実施するための形態】
【００１９】
以下、本発明が属する分野において通常の知識を有する者が本発明を容易に実施することができるように本発明の望ましい実施例を添付図面を参照して詳細に説明する。以下に説明する本発明の望ましい実施例では、内容の明瞭性のために特定の技術用語を使用する。しかしながら、本発明は、その選択された特定の用語に限定することではなく、各々の特定の用語が類似の目的を達成するために類似の方式に動作する全ての技術同義語を含むことを予め明らかにする。
【００２０】
図１は、本発明の望ましい実施例に係るセキュア通信のためのハンドシェイク方法を遂行することができるシステムの構成を図示するブロック図である。
【００２１】
図１を参照すると、デバイスは他のデバイスとの通信のためにデバイスが一意に識別できるベース汎用リソース識別子（Base Universal Resource Identifier；ベースＵＲＩ）を使用することができる。
【００２２】
前記ベース汎用リソース識別子（ベースＵＲＩ）は、プライベートＩＰアドレス（Private IP Address；ＰＲＩ）またはパブリックＩＰアドレス（Public IP Address；ＰＵＢ）でもよい。望ましくは、広域ネットワーク（Wide Area Network；ＷＡＮ）の場合、ベース汎用リソース識別子（ベースＵＲＩ）としてパブリックＩＰアドレス（ＰＵＢ）を使用することができ、ローカル領域ネットワーク（Local Area Network；ＬＡＮ）の場合、ベース汎用リソース識別子（ベースＵＲＩ）としてプライベートＩＰアドレス（ＰＲＩ）または広域ＩＰアドレス（ＰＵＢ）を使用することができる。
【００２３】
例えば、図１に示した通り、広域ネットワーク（ＷＡＮ）のデバイスであるデバイスＣ（例えば、サービス提供者等）の場合、ベース汎用リソース識別子（ベースＵＲＩ）としてパブリックＩＰアドレス（ＰＵＢ）を使用することができ、ローカル領域ネットワーク（ＬＡＮ）のデバイス（例えば、クライアント等）であるデバイスＡおよびデバイスＢは、ベース汎用リソース識別子（ベースＵＲＩ）としてプライベートＩＰアドレス（ＰＲＩ）およびパブリックＩＰアドレス（ＰＵＢ）を各々使用することができる。
【００２４】
前記デバイスＡおよびデバイスＢは、ドメインに登録されたデバイスでもよい。このとき、ドメインとは、ＤＲＭ信用フレームワークの基本単位であって、許可された（Authorized）デバイスの集合を意味することがある。ドメイン内に登録されたドメインデバイス間では、許可された権限に従ってコンテンツを共有して使用することができる。ドメインデバイス間でコンテンツを送信するためには、セキュア認証チャネルを確立した後、セキュア通信を遂行すべきである。ドメインデバイスは、ドメインとの連係を管理するためのモジュール、コンテンツおよびライセンスをハンドリングするためのモジュールなどを備えることができる。ドメインデバイスは、これらのモジュールを用いてコンテンツを取得、処理、使用、記憶、送信することができる。
【００２５】
ドメインは、デバイスの物理的な位置を考慮して構成することもできる。即ち、特定の物理領域内に存在するデバイスでドメインを構成する。このドメインを構成するためにはローカル環境を構成する必要がある。このとき、ローカル環境とは、特定のローカル領域内に属するデバイスが相互作用することができる物理ネットワークを備え、この物理ネットワークが外部ネットワークとも相互作用することができる環境を意味することがある。このローカル環境を提供することができる例として、ホームネットワークシステムを挙げることができる。
【００２６】
一方、ベース汎用リソース識別子（ベースＵＲＩ）は、ドメインネームサービスを介して文字列形式の統一リソース位置指定子（Uniform Resource Locator；ＵＲＬ）で表現することもできる。このベース汎用リソース識別子（ベースＵＲＩ）は、該当デバイスを識別することができる一意の識別子である。デバイス間では、ベース汎用リソース識別子を使用してハイパーテキスト転送プロトコル（Hypertext Transport Protocol；ＨＴＴＰ）に基づいて通信することができる。
【００２７】
以下、セキュア認証チャネルを介してコンテンツサービスを安全に提供することができるセキュア通信手順を詳細に記述する。
【００２８】
図２は、本発明の望ましい実施例に係るセキュア通信方法を説明するためのフローチャートであって、デバイスＡとデバイスＢとの間でセキュア認証チャネル（Secure Authenticated Channel）を介してセキュア通信を遂行する過程を全体的に示している。
【００２９】
このとき、デバイスＡは、サービスの提供を受けるデバイス、例えば、クライアントを意味することがある。例えば、デバイスＡは、デバイスＢにコンテンツおよびそのコンテンツのコンテンツライセンスの提供を要求して受信することもできる。デバイスＢは、サービスを提供するデバイス、例えば、サービスを提供するサービス提供者またはドメイン内の他のクライアントデバイスを意味することがある。デバイスＡとデバイスＢは、サービスのために相互を認証した後、セキュア認証チャネルを確立し、セキュア認証チャネルを介してデータを送信することができる。
【００３０】
図２に示した通り、本発明の望ましい実施例に係るセキュア通信方法は、パラメータ取得ステップ（ステップＳ１）、相互認証ステップ（ステップＳ２）、鍵交換ステップ（ステップＳ３）およびデータ送信ステップ（ステップＳ４）を含んでもよい。
【００３１】
パラメータ取得ステップ（ステップＳ１）において、デバイスＡは、デバイスＢのベース汎用リソース識別子（ベースＵＲＩ）を用いてデバイスＢを呼び出し、デバイスＢからセキュア通信のために必要なパラメータ、例えば、認証のためのパラメータ、コンテンツ保護のためのパラメータ、サービスパラメータなどを受信して取得することができる。
【００３２】
相互認証ステップ（ステップＳ２）では、セキュア通信を確保するために、デバイスＡとデバイスＢは、相互認証を遂行することができる。相互認証の際、デバイスＡとデバイスＢは、デバイスＢの証明書とデバイスＡの証明書を各々受信してその有効性を検証することができる。証明書の有効性の検証の際、デバイスＡまたはデバイスＢは、オンライン証明書状態プロトコル（On-Line Certificate Status Protocol；ＯＣＳＰ）サーバと連動してもよい。
【００３３】
鍵交換ステップ（ステップＳ３）では、デバイスＡとデバイスＢとの間のセキュア認証チャネルを確立するために、デバイスＡとデバイスＢは、セキュア認証チャネルで使用するためのセキュア認証チャネル鍵の計算に必要な鍵の値を計算しながら、お互いにやりとりすることができる。また、これに基づいて前記セキュア認証チャネル鍵を計算することができる。前記やりとりする鍵の値は、証明書を介して認証される鍵の値でもよい。セキュア認証チャネル鍵を計算し、その値をデバイス間でお互いに確認すると、セキュア認証チャネルが確立される。すると、セキュア認証チャネルを介してデータを送信することができる。
【００３４】
データ送信ステップ（ステップＳ４）において、サービスパラメータに従って該当サービスと関連するデータをセキュア認証チャネルを介してデバイスＡとデバイスＢとの間で送受信することができる。例えば、コンテンツまたはコンテンツのライセンスがデバイスＢからデバイスＡに送信されてもよく、サービスと関連するメッセージがデバイスＡとデバイスＢとの間で送信されてもよい。コンテンツが送信される間に、そのコンテンツライセンスの特定の情報、例えば、ライセンス保護モードなどが変更されることもある。
【００３５】
以下、前述した各ステップ（ステップＳ１〜ステップＳ４）の詳細手順について記述する。
【００３６】
図３は、図２に示したパラメータ取得ステップ（ステップＳ１）の詳細手順およびプロトコル構造を示すメッセージシーケンスチャートである。
【００３７】
図３に示した通り、まず、デバイスＡ（１０）は、パラメータ取得のためにデバイスＢ（２０）を呼び出すことができる（ステップＳ１１）。このとき、デバイスＡ（１０）は、デバイスＢ（２０）を呼び出すためにデバイスＢ（２０）のベース汎用リソース識別子（ベースＵＲＩ）を使用することができる。例えば、デバイスＡ（１０）は、デバイスＢ（２０）のＵＲＬにアクセスするためのＨＴＴＰメッセージをデバイスＢ（２０）に送信する、あるいは、デバイスＢ（２０）のプライベートＩＰアドレス（ＰＲＩ）にアクセスするためのメッセージをデバイスＢ（２０）に送信することができる。
【００３８】
次に、デバイスＢ（２０）は、デバイスＡ（１０）にセキュア通信のために必要なパラメータを送信する。すると、デバイスＡ（１０）は、セキュア通信のための認証、セキュリティ、サービスなどと関連するパラメータを取得することができる（ステップＳ１２）。
【００３９】
このとき、前記パラメータとしては、デバイスＢ（２０）のデバイスＢのノンス（DeviceB-Nonce）、認証タイプ（Authentication-type）、デバイスＢ（２０）のデバイスＩＤ（DeviceB-ID）、セキュリティレベル（Security-Level）、ライセンス保護モードレベル（License Protection Mode Level）、コンテンツ保護のための暗号化／復号化鍵（Encryption／Decryption Key）および呼び出されたサービスタイプ（Service Type-Invoked）などがある。
【００４０】
前記デバイスＢ（２０）のデバイスノンスは、デバイスＢ（２０）がデバイスＡ（１０）の認証に使用するための値を意味することがある。このデバイスＢ（２０）のデバイスノンスは、デバイスＢ（２０）で疑似乱数発生器（Pseudo Random Generator）を使用して生成したランダム値でもよい。デバイスＢ（２０）のデバイスノンスは、デバイスＡ（１０）からデバイスＢ（２０）に送信されるメッセージに挿入されてデバイスＢ（２０）がデバイスＡ（１０）の認証に使用することができる。
【００４１】
前記認証タイプは、相互認証の際、如何なる認証方式を遂行するかを指定する情報を含んでもよい。例えば、認証タイプは、認証の際、ＯＣＳＰサーバ（３０）と連動した証明書の有効性の検証をデバイスＡ（１０）とデバイスＢ（２０）で各々遂行するか、デバイスＢ（２０）のみで遂行するかなどを指定することができる。
【００４２】
前記デバイスＢ（２０）のデバイスＩＤは、デバイスＢ（２０）を識別することができるパラメータを意味することがある。デバイスＢ（２０）のデバイスＩＤは、デバイスＢ（２０）を一意に識別するためのＵＲＬ、ＰＲＩ、ＰＵＢまたは物理情報、論理情報などでもよい。
【００４３】
前記セキュリティレベルは、デバイスＡ（１０）とデバイスＢ（２０）との間のセキュア通信において、保全性および機密性に関連するレベルを設定するパラメータを意味することがある。例えば、セキュリティレベルは、デバイスＡ（１０）とデバイスＢ（２０）との間のセキュア通信で保全性を提供するか、機密性を提供するか、保全性および機密性の両方を提供するかを設定することができる。
【００４４】
前記ライセンス保護モードレベルは、デバイスＡ（１０）とデバイスＢ（２０）との間のセキュア通信が如何なる水準のライセンス保護モードを有するかを指定するパラメータでもよい。このとき、ライセンス保護モードとは、コンテンツのライセンスを保護するために要求される保護モードを意味することがある。コンテンツのライセンスにはそのライセンスに含まれた情報に従ってライセンス保護モードが付与され、デバイスは、ライセンスを送信する時、該当ライセンスのライセンス保護モードを考慮することができる。ライセンス保護モードは、後で詳細に説明する。
【００４５】
前記暗号化／復号化鍵は、コンテンツの保護のためにコンテンツを暗号化または復号化するためのパラメータを意味することがある。例えば、前記暗号化／復号化鍵は、ＡＥＳブロック暗号（Cipher）のための所定ビットのコンテンツ暗号化／復号化鍵であってもよい。
【００４６】
前記呼び出されたサービスタイプは、呼び出されたサービスが如何なるタイプのサービスであるかを表すパラメータを意味することがある。例えば、前記呼び出されたサービスタイプは、ライセンス送信（Transfer-Licenses）、コンテンツ送信（Transfer-Contents）、プリンシパル関係登録（Register-Principal-Relations）などでもよい。
【００４７】
図４は、図２に示した相互認証ステップ（ステップＳ２）の詳細手順およびプロトコル構造を説明するためのメッセージシーケンスチャートである。
【００４８】
図４を参照すると、相互認証のために、デバイスＡ（１０）とデバイスＢ（２０）は、ランダムな個人鍵（、秘密鍵または私有鍵（private key））、証明書および公開鍵などを各々有してもよい。プロシージャが開始されると、まず、デバイスＡ（１０）は、デバイスＡ（１０）を認証することを要求するデバイスＡ（１０）認証メッセージをデバイスＢ（２０）に送信することができる（ステップＳ２１）。
【００４９】
このとき、デバイスＡ（１０）認証メッセージは、デバイスＡ（１０）のデバイスノンス（DeviceA-Nonce）、デバイスＢ（２０）のデバイスノンス（DeviceB-Nonce）、デバイスＢ（２０）のデバイスＩＤ（DeviceB-ID）、デバイスＡ（１０）のデバイスＩＤ（DeviceA-ID）、暗号スイートリスト（Cipher-Suite List）、ＤｅｖｉｃｅＡの証明書（DeviceA-Certificate）などを含んでもよい。
【００５０】
前記デバイスＡ（１０）のデバイスノンスは、デバイスＡ（１０）がデバイスＢ（２０）の認証に使用するための値を意味することがある。このデバイスＡ（１０）のデバイスノンスは、デバイスＡ（１０）で疑似乱数発生器を使用して生成したランダム値でもよい。デバイスＡ（１０）のデバイスノンスは、デバイスＢ（２０）からデバイスＡ（１０）に送信されるメッセージに挿入されて、デバイスＡ（１０）がデバイスＢ（２０）の認証に使用することができる。
【００５１】
前記デバイスＢ（２０）のデバイスノンスは、上述したように、デバイスＢ（２０）で生成されて提供されたランダム値であって、前記デバイスＡ（１０）認証メッセージを受信したデバイスＢ（２０）は、前記デバイスＢ（２０）のデバイスノンスを使用して前記デバイスＡ（１０）認証メッセージがデバイスＡ（１０）から送信されたものであることを確認することができる。
【００５２】
デバイスＢのデバイスＩＤおよびデバイスＡ（１０）のデバイスＩＤは、デバイスＢ（２０）およびデバイスＡ（１０）を各々識別することができる情報を意味することがある。デバイスＢ（２０）のデバイスＩＤおよびデバイスＡ（１０）のデバイスＩＤは、各々デバイスＢ（２０）およびデバイスＡ（１０）を一意に識別することができるＵＲＬ、ＰＲＩ、ＰＵＢまたは物理情報、論理情報などでもよい。
【００５３】
暗号スイートリスト（Cipher-Suite List）は、デバイスＡ（１０）で支援可能な暗号スイートのリストを意味することがある。デバイスＢ（２０）は、デバイスＡ（１０）認証メッセージの暗号スイートリストから特定の暗号スイートを選択してデバイスＡ（１０）に通報することができる。選択された暗号スイートは、セキュア認証チャネルにおけるデータ暗号化に適用される。
【００５４】
デバイスＡ（１０）の証明書は、デバイスＡ（１０）を認証するための情報を意味することがある。前記デバイスＡ（１０）の証明書は、証明書識別情報、デバイスＡ（１０）の識別情報、サービスポリシ情報、リボケーション情報、コンテンツ処理能力情報、ローカルスクランブルアルゴリズム（Local Scrambling Algorithm；ＬＳＡ）情報、ドメイン関連情報などを含んでもよい。
【００５５】
デバイスＡ（１０）認証メッセージをデバイスＢ（２０）が受信すると、デバイスＢ（２０）は、デバイスＡ（１０）認証メッセージに含まれた情報に基づいてデバイスＡ（１０）を認証することができる。認証の際、デバイスＢ（２０）は、ＯＣＳＰサーバ（３０）にデバイスＡ（１０）の証明書の有効性の検証を要求した後（ステップＳ２２）、ＯＣＳＰサーバ（３０）からその応答を受信することができる（ステップＳ２３）。例えば、デバイスＢ（２０）は、ＯＣＳＰサーバ（３０）にデバイスＡ（１０）の証明書を送信する。ＯＣＳＰサーバ（３０）は、デバイスＢ（２０）から受信したデバイスＡ（１０）の証明書が有効であるか否か、例えば、証明書がリボークされたか、あるいは、リボークされない有効な証明書であるかを検証し、その検証結果をＯＣＳＰ応答メッセージに含めてデバイスＢ（２０）に送信することができる。すると、デバイスＡ（１０）は、受信したＯＣＳＰ応答メッセージを見てデバイスＢ（２０）の証明書が有効であるか否かを確認することができる。
【００５６】
また、デバイスＢ（２０）は、ＯＣＳＰサーバ（３０）にデバイスＢ（２０）の証明書の有効性の検証を要求した後（ステップＳ２４）、その応答をＯＣＳＰサーバ（３０）から受信することもできる（ステップＳ２５）。例えば、デバイスＢ（２０）は、ＯＣＳＰサーバ（３０）にデバイスＢ（２０）の証明書を送信することができる。ＯＣＳＰサーバ（３０）は、デバイスＢ（２０）から受信したデバイスＢ（２０）の証明書が有効であるか否か、例えば、証明書がリボークされたか、あるいは、リボークされない有効な証明書であるかを検証し、その検証結果をＯＣＳＰ応答メッセージに含めてデバイスＢ（２０）に送信することができる。デバイスＢ（２０）の証明書が有効である場合、デバイスＢ（２０）は、検証されたデバイスＢ（２０）の証明書とＯＣＳＰ応答メッセージの情報をデバイスＡ（１０）に送信することができる。この場合、デバイスＡ（１０）は、ＯＣＳＰサーバ（３０）に接続することなく、ＯＣＳＰ応答メッセージの情報を見てデバイスＢ（２０）の証明書が有効であるか否かを容易に把握することができる。一方、デバイスＢ（２０）は、ＯＣＳＰサーバ（３０）と接続してデバイスＢ（２０）の証明書の検証を遂行せずに、デバイスＢ（２０）の証明書をデバイスＡ（１０）に送信することもできる。この場合、デバイスＡ（１０）がＯＣＳＰサーバ（３０）に接続してデバイスＢ（２０）の証明書の有効性の検証を要求し、その検証結果を受信することによって、デバイスＢ（２０）の証明書が有効であるか否かを検証することもできる。
【００５７】
デバイスＡ（１０）を認証した後、デバイスＢ（２０）は、デバイスＢ（２０）を認証することを要求するデバイスＢ（２０）認証メッセージをデバイスＡ（１０）に送信することができる（ステップＳ２６）。
【００５８】
このとき、デバイスＢ（２０）認証メッセージは、デバイスＡ（１０）のデバイスノンス（DeviceA-Nonce）、デバイスＢ（２０）のデバイスＩＤ（DeviceB-ID）、選択された暗号スイート（Cipher-Suite-Selected）、ＤｅｖｉｃｅＢの証明書（DeviceB-Certificate）、ＯＣＳＰ応答（OCSP Response）、セッションＩＤ（Session ID）などを含んでもよい。
【００５９】
前記デバイスＡ（１０）のデバイスノンスは、上述した通り、デバイスＡ（１０）で生成して提供したランダム値であって、前記デバイスＢ（２０）認証メッセージを受信したデバイスＡ（１０）は、前記デバイスＡ（１０）のデバイスノンスを使用してデバイスＢ（２０）を認証することができる。例えば、デバイスＡ（１０）は、前記デバイスＡ（１０）のデバイスノンスを用いて前記デバイスＢ（２０）認証メッセージがデバイスＢ（２０）から送信されたことを確認することができる。
【００６０】
デバイスＢのデバイスＩＤは、デバイスＢ（２０）を一意に識別することができる情報であって、ＵＲＬ、ＰＲＩ、ＰＵＢまたは物理情報、論理情報などでもよい。
【００６１】
選択された暗号スイートは、デバイスＡ（１０）が提供した暗号スイートリストからデバイスＢ（２０）が選択した暗号スイートに関する情報を意味することがある。このとき、選択された暗号スイートは、セキュア認証チャネルでデータの暗号化に適用されてもよい。選択された暗号スイートは、デバイスＡ（１０）とデバイスＢ（２０）との間でネゴシエートされた対称型暗号スイートでもよい。
【００６２】
デバイスＢ（２０）の証明書は、デバイスＢ（２０）を認証するための情報を意味することがある。前記デバイスＢ（２０）の証明書は、証明書識別情報、デバイスＢ（２０）の識別情報、サービスポリシ情報、リボケーション情報、コンテンツ処理能力情報、ローカルスクランブルアルゴリズム情報、ドメイン関連情報などを含んでもよい。
【００６３】
前記ＯＣＳＰ応答は、デバイスＢ（２０）がＯＣＳＰサーバ（３０）から受信したＯＣＳＰ応答メッセージの情報であって、デバイスＢ（２０）の証明書の検証に関する情報を含んでもよい。デバイスＡ（１０）は、デバイスＢ（２０）の認証の際、前記ＯＣＳＰ応答を見てデバイスＢ（２０）の証明書が有効であるか否かを容易に把握することができる。もし、ＯＣＳＰ応答がデバイスＢ（２０）認証要求メッセージに含まれていない場合、デバイスＡ（１０）は、ＯＣＳＰサーバ（３０）に接続してデバイスＢ（２０）の証明書の有効性の検証を要求し、その検証結果を受信することもできる。
【００６４】
セッションＩＤは、該当セッションを識別するための識別情報を意味することがある。セッションＩＤは、ネゴシエートされたセッションＩＤと暗号方式が記憶されることによってハンドシェイクプロトコルの間持続することができる。
【００６５】
デバイスＢ（２０）を認証した後、デバイスＡ（１０）は、認証関連情報、例えば、デバイスＢ（２０）認証要求メッセージを介して受信した情報を記憶する（ステップＳ２７）。例えば、デバイスＡ（１０）は、デバイスＢ（２０）のＩＤ（DeviceB-ID）、デバイスＢ（２０）の証明書（DeviceB-Certificate）、ＯＣＳＰ応答（OCSP Response）、セッションＩＤ（Session ID）、選択された暗号スイート（Cipher-Suite）などを記憶することができる。一方、デバイス間の相互認証は、前述した通り遂行されてもよいが、実施例によっては鍵交換ステップ内で遂行されてもよい。
【００６６】
図５は、鍵交換ステップの詳細手順およびプロトコル構造を説明するためのメッセージシーケンスチャートである。
【００６７】
図５を参照すると、まず、デバイスＡ（１０）とデバイスＢ（２０）は、セキュア認証チャネルで使用するためのセキュア認証チャネル鍵の計算に必要な鍵の値を予め定められたアルゴリズムに従って計算し、お互いにやりとりすることができる（ステップＳ４１）。このとき、やりとりする鍵の値は、証明書を介して認証される鍵でもよい。また、鍵交換ステップでは、鍵の値の計算と併せて、デバイスＡ（１０）とデバイスＢ（２０）の証明書の交換を介した相互認証を遂行することもできる。
【００６８】
例えば、デバイスＡ（１０）は、ランダム値を生成した後、そのランダム値と関連する公開鍵の値を計算して、その公開鍵の値をデバイスＡ（１０）の証明書と共にメッセージに含めてデバイスＢ（２０）に送信することができる。メッセージを受信したデバイスＢ（２０）は、前記メッセージから公開鍵およびデバイスＡ（１０）の認証情報を抽出して有効性を検証した後、予め定められたアルゴリズムに従って秘密鍵の値を計算することができる。次に、デバイスＢ（２０）は、ランダム値を生成した後、生成したランダム値と関連する公開鍵の値を計算して、この公開鍵の値、前記秘密鍵の値およびデバイスＢ（２０）の認証情報などのコンカチネーション（Concatenation）のハッシュ（Hash）値を計算してデバイスＢ（２０）の証明書と共にメッセージに含めてデバイスＡ（１０）に送信することができる。デバイスＡ（１０）は、受信したメッセージから公開鍵の値とデバイスＢ（２０）の認証情報を抽出して有効性を検証した後、予め定められたアルゴリズムに従って秘密鍵の値を計算することができる。次に、デバイスＡ（１０）は、前記ハッシュ値が正しいか否かをチェックした後、公開鍵の値、秘密鍵の値およびデバイスＡ（１０）の認証情報などのコンカチネーション（Concatenation）のハッシュ（Hash）値を計算してデバイスＢ（２０）に送信することができる。すると、デバイスＢ（２０）は、前記ハッシュ値をチェックして正しい値であるか否かを検証することができる。
【００６９】
次に、デバイスＡ（１０）とデバイスＢ（２０）は、計算した鍵の値を用いてセキュア認証チャネルに使用するための鍵である、例えば、セキュア認証チャネル鍵（Secure Authenticated Channel Key）を計算することができる（ステップＳ４２、Ｓ４３）。セキュア認証チャネル鍵は、暗号化鍵と復号化鍵が同じである対称鍵（Symmetric Key）であることがあり、暗号化認証セッション鍵（Encryption Authentication Session Key）、セキュア認証チャネル認証セッション鍵（Secure Authenticated Channel Authentication Session Key）などを含んでもよい。セキュア認証チャネル鍵の計算を完了すると、デバイスＡ（１０）とデバイスＢ（２０）は、セキュア認証チャネル鍵を交換する、あるいは、セキュア認証チャネル鍵を使用したデジタル署名をお互いに交換することもできる。
【００７０】
鍵交換ステップが完了すると、デバイスＡ（１０）とデバイスＢ（２０）との間にはセキュア認証チャネルが確立される（ステップＳ４４）。すると、データ送信ステップが遂行されてもよい（ステップＳ４）。即ち、確立されたセキュア認証チャネルでは、データが送信されてもよい。例えば、デバイスＡ（１０）は、セキュア認証チャネルを介してデバイスＢ（２０）からコンテンツまたはコンテンツのライセンスなどを受信することができる。
【００７１】
前記コンテンツのライセンスは、ライセンス識別情報、ライセンス提供者情報、コンプライアンス／ロバストレジーム（Compliance／Robustness Regime；Ｃ／Ｒレジーム）情報、リボケーション情報、許可されたドメイン（Authorized Domain）の識別情報、デスクランブル情報、使用状態（Usage State）情報などを含んでもよい。
【００７２】
このライセンスにはライセンス保護モード（License Protection Mode）が付与される。前記ライセンス保護モードとは、該当ライセンスを保護するために要求される保護条件を意味することがある。ライセンス保護モードの情報は、ライセンス内の特定のフィールドに含まれることもあり、またはデバイスで記憶および管理されてもよい。
【００７３】
ライセンス保護モードにはセキュア認証チャネル保護モード（Secure Authenticated Channel Protection Mode）、ドメイン保護モード（Authorized Domain Secret Protection Mode）、セキュア認証チャネル／ドメイン保護モード（Secure Authenticated Channel Protection／Authorized Domain Secret Protection Mode）およびデバイス鍵保護モード（Device Key Protection Mode）などがある。
【００７４】
前記セキュア認証チャネル保護モードは、ライセンスの送信時にライセンスをセキュア認証チャネルを介して保護するモードを意味することがある。即ち、セキュア認証チャネル保護モードは、セキュア認証チャネル鍵を用いてライセンスを保護するモードを意味することがある。また、ドメイン保護モードは、ライセンスを許可されたドメインの機密保護（Authorized Domain Secret Protection）によって保護するモードを意味することがある。また、セキュア認証チャネル／ドメイン保護モードは、ライセンスをセキュア認証チャネルおよび許可されたドメインの機密保護を介して保護するモードを意味することがある。デバイス鍵保護モードは、ライセンスの記憶時にライセンスをデバイス鍵で保護するモードを意味することがある。
【００７５】
このライセンス保護モードは、ライセンスに含まれている使用状態情報に従って設定されてもよい。ライセンスを送信する際、デバイスは、該当ライセンスのライセンス保護モードを考慮して送信を遂行することができる。例えば、デバイスは、送信または受信しようとするライセンスのライセンス保護モードがセキュア認証チャネル保護モードであれば、セキュア認証チャネルを介してライセンスを送信または受信することができる。この場合、パラメータ取得ステップで送信または取得したパラメータのライセンス保護モードレベルが、ライセンスの要求するライセンス保護モードに該当するか否かを確認することができる。
【００７６】
一方、もし、コンテンツが特定のデバイスから他のデバイスに送信される場合（例えば、コピーされる、あるいは、移動される場合等）、該当コンテンツのライセンスのライセンス保護モードは変更（Vary）されてもよい。
【００７７】
ドメインは、同種のＤＲＭコンテンツおよびライセンスの共有が可能であることもあり、もし、ＤＲＭ相互互換システムのドメインの場合、異種のＤＲＭコンテンツおよびライセンスの共有が可能であることもある。ＤＲＭ相互互換システムでは、ライセンスを互換にするためにライセンストークン（License Token）を使用する。ライセンストークンは、多様な種類のコンプライアント（Compliant）ＤＲＭライセンスの情報を抽出することができる予め定められたフォーマットの情報であって、一種の中立ライセンスを意味することがある。
【００７８】
以下、ＤＲＭ相互互換システムでネイティブＤＲＭ（例えば、ＯＭＡ ＤＲＭ等）によりコンテンツを使用する権限（Rights）、即ち、ライセンスを送信（Transfer）する過程を説明する。
【００７９】
図６は、ＤＲＭ相互互換システムからＯＭＡ ＤＲＭシステムにライセンスを送信する手順を示すメッセージシーケンスチャートであって、ＤＲＭ相互互換システムで使用されるライセンストークンを用いてＯＭＡ ＤＲＭクライアントにＯＭＡ ＤＲＭのライセンスを提供する例を示している。
【００８０】
図６に示した通り、ＤＲＭ相互互換システムのドメインクライアント（Domain Client）（６１）は、送信−ライセンス（Transfer-License）インターフェースを呼び出し、ライセンスメディエータ（License Mediator（ライセンスの仲介者））（６２）にコンテンツのライセンスをＯＭＡ ＤＲＭクライアント（７０）に送信するように要求する（ステップＳ６１）。このとき、ドメインクライアント（６１）は、前記コンテンツのコンテンツ識別子およびライセンストークンなどをライセンスメディエータに提供することができる。
【００８１】
送信−ライセンス要求を受信したライセンスメディエータ（６２）は、その送信−ライセンス要求が有効な要求であるか否かを検証する（ステップＳ６２〜６５）。例えば、ライセンスメディエータ（６２）は、インターフェースの呼び出しを介してプリンシパルマネージャ（Principal Manager）（６４）に前記クライアントが許可されたクライアントであるか否かを検証するように要求し（ステップＳ６２）、その応答を受信することができる（ステップＳ６３）。また、ライセンスメディエータ（６２）は、ライセンスレジストリ（License Registry）（６３）に前記ライセンストークンがドメインクライアント（６１）の現在所有している有効なライセンストークンであるか否かなどを検証するように要求し（ステップＳ６４）、その応答を受信することができる（ステップＳ６５）。
【００８２】
前記有効性の検証の結果、有効な要求の場合、ライセンスメディエータ（６２）は、ＯＭＡ ＤＲＭクライアント（７０）で使用するためのライセンスの登録に必要な情報、クライアントの情報およびライセンストークンなどをライセンスインスタンシエータ（License Instantiator）（６５）に提供してライセンスの登録を要求することができる（ステップＳ６６）。
【００８３】
ライセンスインスタンシエータ（６５）は、ライセンスメディエータ（６２）から提供された情報、例えば、ライセンストークンなどの有効性を検証した後、ＯＭＡ ＤＲＭのライセンス発行者（License Issuer）（図示せず）にライセンスの変換（Translate）を要求する。すると、ＯＭＡ ＤＲＭのライセンス発行者は、ライセンストークンをＯＭＡ ＤＲＭ権利オブジェクト（Rights Object；ＲＯ）に合うライセンスに変換することができる。続いて、ライセンスインスタンシエータ（６５）は、ＯＭＡ ＤＲＭのライセンス発行者から、ＤＲＭ情報成分（DRM-Info Element）内の、ＯＭＡ ＤＲＭ ＲＯトリガ（Trigger）および他の情報（Other Information）を受信し、これをライセンスメディエータ（６２）に送信する（ステップＳ６７）。ライセンスメディエータ（６２）は、ライセンスインスタンシエータ（６５）から送信された情報を受信してドメインクライアント（６１）に送信する（ステップＳ６８）。
【００８４】
次に、ライセンスメディエータ（６２）の制御によって、ライセンス仲介プロセス（License Mediation Process）が遂行される（ステップＳ６９）。ライセンス仲介プロセスの間、ＤＲＭ情報の成分内の現在の情報がＯＭＡ ＤＲＭクライアント（７０）に送信されてもよい。コンテンツインポータ（Content Importer）（図示せず）は、前記ライセンス仲介プロセスの間、ＤＲＭ情報の成分内の現在の情報をコンテンツのパッケージングなどに使用することができる。このとき、コンテンツインポータは、該当コンテンツをＯＭＡ ＤＲＭクライアント（７０）に搬入する機能を遂行するオブジェクトである。
【００８５】
もし、ＤＲＭ情報成分内に現在ＲＯトリガがある場合、ドメインクライアント（６１）は、前記ＲＯトリガをＯＭＡ ＤＲＭクライアント（７０）にパスする。ＯＭＡ ＤＲＭクライアント（７０）は、前記ＲＯトリガを使用してライセンスのダウンロード（License Download）を開始することができる。一方、ＤＲＭ情報成分内に現在ＲＯトリガが存在しない場合、ＯＭＡ ＤＲＭクライアント（７０）は、ＯＭＡ ＤＲＭコンテンツ内のライセンス発行者のＵＲＬを使用してライセンスのダウンロードを開始することができる。
【００８６】
以上、本発明に対してその望ましい実施例を図面を参照して説明したが、該当技術分野の熟練された当業者は、特許請求の範囲に記載された本発明の技術的思想および領域から外れない範囲内で本発明を多様に修正および変更させて実施することができる。
【符号の説明】
【００８７】
１０    デバイスＡ
２０    デバイスＢ
３０    オンライン証明書状態プロトコル（ＯＣＳＰ）サーバ
【図１】
2010526507.tif 000003
【図２】
2010526507.tif 000004
【図３】
2010526507.tif 000005
【図４】
2010526507.tif 000006
【図５】
2010526507.tif 000007
【図６】
2010526507.tif 000008
【国際調査報告】
2010526507.tif 000009
2010526507.tif 000010