(57)【要約】  本発明は、キーブロックに基づく認証のための装置２５０および方法に関する。既知の認証装置および認証方法の問題を克服し、新たな有効な無効化情報が装置に到達し認証に使用されることを保証するような、効果的なキーブロックおよび／またはアプリケーションの無効化を可能とするため、無効化情報２５４を有する当該装置２５０と、キーブロックＡＫＢを有する認証されるべきアプリケーションユニットとの間の認証を、その無効化情報２５４ならびにキーブロックＡＫＢを用いて行う認証手段、および、無効化情報２５４を更新する処理をトリガするための内部トリガ手段２５６を含む、キーブロックに基づく認証のための装置２５０を提案する。
2008545317.tif 000002
【特許請求の範囲】
【請求項１】
キーブロックに基づく認証のための装置であって、
無効化情報を有する当該装置と、キーブロックを有する認証されるべきアプリケーションユニットとの間の認証を、前記無効化情報ならびに前記キーブロックを用いて行う認証手段、および
前記無効化情報を更新する処理をトリガするための内部トリガ手段を含むことを特徴とする装置。
【請求項２】
前記無効化情報が、無効化バージョン番号を含み、
前記内部トリガ手段が、前記無効化バージョン番号を増分させることにより、前記無効化情報を更新するように構成されていることを特徴とする請求項１記載の認証のための装置。
【請求項３】
無効化されるキーブロックならびに／もしくはアプリケーションユニットのブラックリスト、および／または無効化されないキーブロックならびに／もしくはアプリケーションユニットのホワイトリストであって、前記無効化バージョン番号と等しいまたはより大きなバージョン番号を有するリストを、要求し、前記アプリケーションユニットから受け取るための通信手段をさらに含み、
前記認証手段が、前記ブラックリストおよび／または前記ホワイトリストを用いて前記認証を行うように構成されていることを特徴とする請求項２記載の認証のための装置。
【請求項４】
前記認証手段が、前記無効化バージョン番号と等しいまたはより大きなキーブロックバージョン番号を持つキーブロックを有するアプリケーションユニットのみを、認証するように構成されていることを特徴とする請求項２記載の認証のための装置。
【請求項５】
前記無効化情報が、無効化されるキーブロックおよび／またはアプリケーションユニットのブラックリストを含み、
当該装置が、
前記無効化情報の前記更新のためのデータを、要求し、前記アプリケーションユニットから受け取るための通信手段、および
前記ブラックリストを、前記通信手段により受け取られた新たなブラックリストに置き換える置換手段を含むことを特徴とする請求項１記載の認証のための装置。
【請求項６】
前記無効化情報が、無効化されないキーブロックおよび／またはアプリケーションユニットのホワイトリストを含み、
当該装置が、前記無効化情報の前記更新のためのデータを、要求し、前記アプリケーションユニットから受け取るための通信手段を含み、
当該装置がさらに、
キーブロックならびに／もしくはアプリケーションユニットの認定証明の供給時において、前記ホワイトリストを削除し、新たなホワイトリストをコンパイルするコンパイル手段、および／または
前記ホワイトリストを、前記通信手段により受け取られた新たなホワイトリストに置き換える置換手段を含むことを特徴とする請求項１記載の認証のための装置。
【請求項７】
前記無効化情報が、無効化連続番号をさらに含み、
前記内部トリガ手段が、前記更新時において前記無効化連続番号を増分させるように構成されており、
当該装置が、前記無効化連続番号と等しいまたはより大きなバージョン番号を有するデータのみを、前記更新用に受け入れるように構成されていることを特徴とする請求項５または６記載の認証のための装置。
【請求項８】
内部タイマをさらに含み、
前記内部トリガ手段が、予め決められた時間またはランダムに選択された時間が経過した後に、前記無効化情報を更新する前記処理をトリガするように構成されていることを特徴とする請求項１記載の認証のための装置。
【請求項９】
認証の回数を計数する内部カウンタをさらに含み、
前記内部トリガ手段が、予め決められた認証回数またはランダムに選択された認証回数の後に、前記無効化情報を更新する前記処理をトリガするように構成されていることを特徴とする請求項１記載の認証のための装置。
【請求項１０】
当該装置により処理されるデータの量、とりわけコンテンツが保護されたデータの量を測定する内部メーターをさらに含み、
前記内部トリガ手段が、予め決められたデータ量またはランダムに選択されたデータ量が処理された後に、前記無効化情報を更新する前記処理をトリガするように構成されていることを特徴とする請求項１記載の認証のための装置。
【請求項１１】
前記認証手段が、前記アプリケーションユニットを実質的に唯一のものとして識別する識別子と、前記アプリケーションユニットと関連付けられた認証キーとを、取得するように構成されており、
当該装置が、前記認証キーを保存するための不揮発性メモリをさらに含んでいることを特徴とする請求項１記載の認証のための装置。
【請求項１２】
キーブロックに基づく認証方法であって、
無効化情報を有する装置と、キーブロックを有する認証されるべきアプリケーションユニットとの間の認証を、前記無効化情報ならびに前記キーブロックを用いて行う認証工程、および
前記装置による前記無効化情報を更新する処理を、内部的にトリガする内部トリガ工程を含むことを特徴とする方法。
【請求項１３】
前記認証工程は、
前記装置が、前記アプリケーションユニットを実質的に唯一のものとして識別する識別子と、前記アプリケーションユニットと関連付けられた認証キーとを受け取り、該認証キーを不揮発性メモリ内に保存する第１の工程、および
前記認証キーを用いて、前記装置と前記アプリケーションユニットとの間で共有されるバスキーを生成する第２の工程を含み、
前記第１の工程は、前記更新する処理の後に１回実行され、前記第２の工程は、次の内部トリガ工程まで、各認証工程において実行されることを特徴とする請求項１２記載の認証方法。
【請求項１４】
コンピュータ上で実行された際に、請求項１２または１３記載の方法の各工程を該コンピュータに実行させるコンピュータプログラムコード手段を含むことを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、キーブロックに基づく認証のための装置および方法に関するものである。
【背景技術】
【０００２】
近年、ブロードキャスト暗号化（Ａ．Ｆｉａｔ、Ｍ．Ｎａｏｒ、「Ｂｒｏａｄｃａｓｔ  Ｅｎｃｒｙｐｔｉｏｎ，Ａｄｖａｎｃｅｓ  ｉｎ  Ｃｒｙｐｔｏｌｏｇｙ−ＣＲＹＰＴＯ  '９３，Ｌｅｃｔｕｒｅ  Ｎｏｔｅｓ  ｉｎ  Ｃｏｍｐｕｔｅｒ  Ｓｃｉｅｎｃｅ  ７７３（ブロードキャスト暗号化、暗号化技術における進歩−ＣＲＹＰＴＯ  '９３、コンピュータサイエンス講義ノート７７３）」、Ｓｐｒｉｎｇｅｒ、１９９４年、第４８０−４９１ページ；Ｄ．Ｍ．Ｗａｌｌｎｅｒ、Ｅ．Ｊ．Ｈａｒｄｅｒ、Ｒ．Ｃ．Ａｇｅｅ、「Ｋｅｙ  Ｍａｎａｇｅｍｅｎｔ  ｆｏｒ  Ｍｕｌｔｉｃａｓｔ：Ｉｓｓｕｅｓ  ａｎｄ  Ａｒｃｈｉｔｅｃｔｕｒｅｓ（マルチキャストのためのキー管理：問題およびアーキテクチャ）」、インターネット  ＲＦＣ  ２６２７、１９９９年６月；およびＣ．Ｋ．Ｗｏｎｇ、Ｍ．Ｇｏｕｄａ、Ｓ．Ｌａｍ、「Ｓｅｃｕｒｅ  Ｇｒｏｕｐ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｕｓｉｎｇ  Ｋｅｙ  Ｇｒａｐｈｓ（キーグラフを用いた安全なグループ通信）」、ＳＩＧＣＯＭＭ  １９９８年参照）は、複製防止の分野において、キーの頒布および無効化の問題を解決するための非常に一般的な方法であることが示されてきた。たとえば、Ｃｏｐｙ  Ｐｒｏｔｅｃｔｉｏｎ  ｆｏｒ  Ｒｅｃｏｒｄａｂｌｅ  ＭｅｄｉａならびにＣｏｐｙ  Ｐｒｏｔｅｃｔｉｏｎ  ｆｏｒ  Ｐｒｅ−ｒｅｃｏｒｄｅｄ  Ｍｅｄｉａ（ＣＰＲＭならびにＣＰＰＭ；記録可能型媒体のための複製防止ならびに予め記録された媒体のための複製防止；http://www.4century.org参照）、Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｂｌｕ−ｒａｙ  Ｄｉｓｃ  Ｒｅｗｒｉｔａｂｌｅ（ＢＤ−ＲＥ  ＣＰＳ；書換可能型ブルーレイディスクのためのコンテンツ保護システム；松下／Ｐｈｉｌｉｐｓ／ソニー）、およびＶｉｄｅｏ  Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ  Ｓｙｓｔｅｍ（ビデオコンテンツ保護システム；http://www.licensing.philips.com/vcps参照；ＨＰ／フィリップス）といったようなシステムは、キーブロックを用いて、準拠している再生および記録装置のみがコンテンツにアクセスできるように保証している。
【０００３】
ブロードキャスト暗号化の背景にある全般的な思想は、すべての装置の全体の組が、巧妙に選択された多くのサブセットによりカバーされるという思想である。それらのサブセットの各々に対して、１つのグループキーが割り当てられる。そのグループキーは、対応のサブセットに属するすべての装置内に埋め込まれる。１つの特定の装置が、複数のサブセットのメンバーとなり、したがって基板上に複数のグループキーを有する。１つの装置の基板上にあるこのグループキーの組は、デバイスキーとも呼ばれる。コンテンツ片へのアクセスを準拠装置の組に制限するために、コンテンツはルートキーＫｒｏｏｔを用いて暗号化され、さらにＫｒｏｏｔはいくつかの異なるグループキーを用いて暗号化される。これらのグループキーは、対応のサブセットが準拠装置の組をちょうどカバーし、それを超える装置はカバーしないように選択される。グループキーにより暗号化されたＫｒｏｏｔを含む構造は、キーブロックと呼ばれる。
【０００４】
以前は準拠装置であった装置の１つまたは複数がハッキングされたことが分かると、新たなコンテンツが新たなルートキーＫ'ｒｏｏｔを用いて暗号化され、このキーが、新たなキーブロックを用いて残りの準拠装置に転送される。すると、このキーブロックに使用されているグループキーは、準拠装置の新たな組のみをカバーするサブセットの新たな集合に対応することとなる。新たなキーブロックを生成して、サブセットの新たな集合を選択することにより、ある準拠装置の組を事実上無効化することができる。
【０００５】
他の代替手法と比較したブロードキャスト暗号化の利点は、低い送信条件（キーブロックのサイズは、通常は数千未満である非準拠装置／無効化された装置の数に、ほぼ比例する）と、低い複雑性（キーブロックの復号には、対称的なキー暗号化技術のみが必要とされる）とを兼ね備えている点である。さらに、無効化とキーの頒布とを、都合よく１つに丸め込むことができる。
【０００６】
ブロードキャスト暗号化の比較的新しい適用形態は、認証における使用である。上記の例のように、装置は依然として埋め込まれたデバイスキーの組を有し、各装置はデバイスキーの異なる組を有する。準拠装置を用いればキーブロックを復号することができるが、非準拠装置は復号することができない。チャレンジ応答プロトコル（ｃｈａｌｌｅｎｇｅ  ｒｅｓｐｏｎｓｅ  ｐｒｏｔｏｃｏｌ）においてキーブロックのルートキーを共有の秘密として用いることにより、１つの装置は、別の装置（たとえばセットトップボックスからのコンテンツを要求するレコーダ）が（依然として）準拠装置であるか否かを確認することができる。ブロードキャスト暗号化のこの使用法の例は、ｘＣＰ（ホームネットワークに参加する装置のためのシステム；「ＩＢＭ  ｒｅｓｐｏｎｓｅ  ｔｏ  ＤＶＢ−ＣＰＴ  Ｃａｌｌ  ｆｏｒ  Ｐｒｏｐｏｓａｌｓ  ｆｏｒ  Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ  ＆  Ｃｏｐｙ  Ｍａｎａｇｅｍｅｎｔ（コンテンツ保護および複製管理の提案に関するＤＶＢ−ＣＰＴの要求に対するＩＢＭの回答）」、ＤＶＢ−ＣＰＴ−７１６、２００１年１０月、http://www.almaden.ibm.com/software/ds/ContentAssurance/papers/xCP_DVB.pdf参照）、およびＶＣＰＳのようなシステムに見ることができる。
【０００７】
コンテンツ頒布におけるブロードキャスト暗号化の利点は認証にも受け継がれるが、残念ながら、ある重大な欠点もある。それは、キー発行攻撃（ｋｅｙ  ｐｕｂｌｉｓｈｉｎｇ  ａｔｔａｃｋ）である。問題は、このハッキングは、１人の優秀なハッカーが、認証を受けていない気軽なハッカーが準拠装置を用いた認証を行うことのできるようなソフトウェアツールを、そのツールで使用されるキーは無効化できないようにして、多数の気軽なハッカーに供給することを可能としてしまう点である。このハッキング方法は、以下のようなものである。
【０００８】
キーブロック復号のいかなる実装形態も完璧ではないので、装置全体の中には、比較的優秀なハッカーであればデバイスキーを取り出すことができるような装置は、常に存在し得る。とりわけ、ソフトウェアアプリケーションはこの点においては脆弱である。
【０００９】
優秀なハッカーは、デバイスキーを用いて、自分が入手することのできる任意のキーブロックからルートキーを取り出す。ここで、キーブロック自体は秘密ではなく、自由に頒布されるものである点に留意されたい。キーブロックから取り出されたルートキーは、その取出元であるキーブロックへの参照情報（たとえばハッシュ）と共に、インターネット上のサーバー内のデータベースに集められる。
【００１０】
準拠装置として認証されること（たとえばコンテンツを取得すること）またはホームネットワークに加わることを望む気軽なハッカーは、準拠装置を装うツールを、インターネットからダウンロードする。準拠装置のチャレンジ応答プロトコルが開始されると、上記のツールは、プロトコル内で使用されるキーブロックの参照情報（たとえばハッシュ）を、上記のサーバーに送信し、サーバーは、プロトコル内で上記のツールによりその後使用される対応のルートキーを返す。
【００１１】
優秀なハッカーにより使用されるデバイスキーは決して発行されず、ルートキーのみが発行されるので、新たなキーブロック内においてこれらのデバイスキーを無効化するのは、極めて難しい。
【００１２】
この攻撃に対処するための１つの方法は、ブロードキャスト暗号化に代えて、パブリックキー暗号化を用いる方法である。パブリックキー暗号化に基づく認証では、各装置が、認定権限を有する機関により署名（シグニチャ）された認定証明において固定された、自己の固有の識別子を有する。パブリックキー暗号化の非対称特性のため、ルートキーのような共有の秘密を設ける必要はない。また、優秀なハッカーは依然として気軽なハッカーのためのツールを構築することはできるが、このツールは特定の実装形態のプライベートキーに基づくものでなくてはならないため、対応のパブリックキーを無効化することができる。残念ながら、パブリックキー暗号化プロトコルは、ＭＩＰＳ（ソフトウェア実装の場合）およびｋゲート（ハードウェア実装の場合）の観点から非常に高コストであり、このことがパブリックキー暗号化プロトコルをＣＥ製品において不人気なものとしている。
【００１３】
キー発行攻撃は、ブロードキャスト暗号化を認証用に安全に用いることができないことを示唆しているが、より詳細に検討すると、「弱い」実装形態においてはデバイスキーが決して存在しない限りにおいて、ブロードキャスト暗号化は依然として有用な技術であることが分かる。たとえば、ハードウェアはほとんど攻撃されないが、ソフトウェアは脆弱であるような状況においては、ソフトウェアはデバイスキーを含むべきではないが、ハードウェアはデバイスキーを含み得る。この設計基準に従う１つのシステムは、ＶＣＰＳによるＤＶＤ＋ＲＷドライブとＰＣホストアプリケーションとの間の認証プロトコルである。この認証プロトコルでは、すべてのＤＶＤ＋ＲＷドライブ内にデバイスキーが埋め込まれており、各ソフトウェアは、自己の固有のキーブロックおよびルートキーを含んでいるが、デバイスキーは含んでいない。
【００１４】
ソフトウェアアプリケーションは依然としてハッキング可能であるが、（優秀な）ハッカーは、多くともルートキーを知るだけである。このルートキーを依然としてキー発行攻撃に用いることもできるかもしれないが、このルートキーはもはや「匿名の」ものではない。すなわち、各アプリケーションが自己の固有のキーブロックおよびルートキーを有しているので、原理上、対応のアプリケーションを無効化することが可能である。
【００１５】
アプリケーションをうまく無効化するためには、対応のアプリケーションが危険に曝されたと分かったためにもはや受容できないのは、どのルートキー（すなわちどのアプリケーション）であるかを学習するための機構を、ハードウェア装置が持つべきである。一般的に、これを確立するには２つの方法がある。１つは、ブラックリスト法、すなわち、どのアプリケーションがもはや準拠アプリケーションではないか（したがって暗黙的にはどのアプリケーションが準拠アプリケーションであるか）をハードウェア装置に伝える無効化リストが、定期的に頒布される方法である。もう１つは、ホワイトリスト法、すなわち、すべてのアプリケーションおよびそれらのキーブロック／ルートキーが定期的に無効化され、新たなキーブロックを用いてあらためて自己を証明しなくてはならない方法である。
【００１６】
いずれの場合でも、上記の「定期的な」段階、すなわちブラックリスト法においてはハードウェア装置が無効化情報をタイムリーに必要とし、ホワイトリスト法においては装置がすべての現行キーブロックを無効化するトリガを必要とする段階を、どのように実施するかが問題となる。たとえばＶＣＰＳより知られている方法は、無効化情報（必ずしもキーブロック無効化情報である必要はない）またはトリガが、第三者である通信パートナーを介して伝達される方法である。たとえば、ハードウェア装置が光ドライブである場合には、アプリケーション無効化情報またはトリガは、新規の光ディスク上に含められてもよい。あるいは、ハードウェア装置がブロードキャストチューナー（たとえばＡＴＳＣ用のチューナー）である場合には、アプリケーション無効化情報またはトリガは、ブロードキャストストリーム内に含められてもよい。ハードウェア装置がノマディック型のものである場合、すなわちゼロでないいくらかの割合分の装置は無効化されないであろう多くの他の装置に接続されるものである場合には、そのハードウェア装置は、かかる他の装置から無効化情報またはトリガを受け取ってもよい。
【００１７】
しかしながら、ハードウェア装置が比較的孤立しているような状況、または信用できない（ソフトウェア）アプリケーションを介してしかハードウェア装置が外界にアクセスできないような状況（この信用を確立することこそが、まさに（キーブロックに基づく）認証の目的である）も存在する。介在するソフトウェアアプリケーションは、無効化情報またはトリガがハードウェア装置に到達するのを意図的に妨害するかもしれず、あるいは、たとえば新たな無効化情報を古い無効化情報に置き換えるかもしれない。
【発明の開示】
【発明が解決しようとする課題】
【００１８】
したがって、本発明の１つの目的は、キーブロックを介して装置が無効化され、別個の無効化（ブラック／ホワイト）リストを介してアプリケーションユニットが無効化される、キーブロックに基づく認証のための装置および方法であって、上記の問題を克服し、新たな有効な無効化情報が装置に到達し認証に使用されることを保証するような、効果的なキーブロックおよび／またはアプリケーションの無効化を可能とする装置および方法を提供することである。
【課題を解決するための手段】
【００１９】
本発明によれば、上記の目的は、キーブロックに基づく認証のための装置であって、無効化情報を有する当該装置と、キーブロックを有する認証されるべきアプリケーションユニットとの間の認証を、上記の無効化情報ならびにキーブロックを用いて行う認証手段、および上記の無効化情報を更新する処理をトリガするための内部トリガ手段を含む装置によって達成される。
【００２０】
上記の目標はまた、請求項１２記載の対応の方法によっても達成される。本発明はさらに、コンピュータ上で実行された際に、本発明の方法の各工程をそのコンピュータに実行させるコンピュータプログラムコード手段を含む、コンピュータプログラムにも関するものである。
【００２１】
本発明は、装置自身が、自らの無効化情報の定期的な更新を実施し得るという洞察に基づいている。装置は、外部のイベントまたは外部からのトリガを待つのではなく、新たな無効化情報を取得するために自己のトリガを発生させることができる。とりわけ、無効化情報またはトリガを送るための信頼性の高い伝送チャネルがない状況においては、装置は、「時間切れ」後においては、他の装置（認証を希望する装置）が「新しい」無効化情報を供給するか、自己のキーブロックを更新するまで、認証プロトコルに携わることを拒否する。
【００２２】
ここで、「装置（デバイス）」との用語は、ハードウェア装置に限定されない点に留意されたい。本発明は、ソフトウェアアプリケーション中に実装されてもよく、とりわけ、ハードウェア装置としてデバイスキーを安全に担持することができる十分なハードウェアサポート（たとえば、ＴＰＭモジュール、またはインテル社のＬａＧｒａｎｄｅもしくはＡＲＭ  Ｔｒｕｓｔｚｏｎｅといった特殊かつ安全なチップセット上での実行）を有するような、ソフトウェアアプリケーション中に実装され得る。逆に、「アプリケーションユニット」との用語は、ソフトウェアでの実装形態に限定されるものではない。
【００２３】
本発明の１つの実施形態では、上記の無効化情報は、無効化バージョン番号を含むものとされ、内部トリガ手段は、その無効化バージョン番号を増分させることにより、無効化情報を更新するように構成される。このような無効化バージョン番号を有することにより、装置は、十分に新しい認証データを用いて認証を行うことができる。更新中においてこの無効化バージョン番号を増分させることにより、古い認証データが認証に利用されないよう、確実にすることができる。
【００２４】
本発明の１つの有利な実施形態では、装置は、無効化されるキーブロックならびに／もしくはアプリケーションユニットのブラックリスト、および／または無効化されないキーブロックならびに／もしくはアプリケーションユニットのホワイトリストであって、上記の無効化バージョン番号と等しいまたはより大きなバージョン番号を有するリストを、要求し、アプリケーションユニットから受け取るための通信手段をさらに含むものとされる。さらに、上記の認証手段が、上記のブラックリストおよび／またはホワイトリストを用いて認証を行うように構成される。装置は、認証のための新たなデータとして、ブラックリストおよび／またはホワイトリストを要求し、アプリケーションユニットからそのブラックリストおよび／またはホワイトリストの供給を受ける。装置は、ブラックリストおよび／またはホワイトリスト内の項目を確認することにより、無効化されるアプリケーションユニットと、無効化されないアプリケーションユニットとを区別することができる。古いブラックリストまたは古いホワイトリストの使用を避けるため、リストのバージョン番号は、無効化バージョン番号と等しいか、より大きくなくてはならない。この実施形態では、ブラックリストまたはホワイトリストを装置内に保存することは必須ではないので、これらのリストを安全に保存するためにさらなる努力をする必要を避けることが可能である。
【００２５】
本発明の別の実施形態では、上記の認証手段は、上記の無効化バージョン番号と等しいまたはより大きなキーブロックバージョン番号を持つキーブロックを有するアプリケーションユニットのみを、認証するように構成される。無効化バージョン番号は、十分に新しいキーブロック（すなわち十分に高いバージョン番号を有するキーブロック）と、古すぎるキーブロック（すなわち無効化バージョン番号よりも古いバージョン番号を有するキーブロック）との間の、カットオフを提供する。
【００２６】
本発明のさらに別の実施形態では、無効化情報は、無効化されるキーブロックおよび／またはアプリケーションユニットのブラックリストを含むものとされ、装置は、無効化情報の更新のためのデータを、要求し、アプリケーションユニットから受け取るための通信手段、および上記のブラックリストを、上記の通信手段により受け取られた新たなブラックリストに置き換える置換手段を含むものとされる。装置は、自身でブラックリストを保存し、認証されようとしているアプリケーションユニットが新しい無効化情報を提供することができない場合においても、認証イベントが発生するたびに、保存されているブラックリストによればそのアプリケーションユニットが無効化されるか否かを確認することができる。
【００２７】
本発明の別の実施形態では、無効化情報は、無効化されないキーブロックおよび／またはアプリケーションユニットのホワイトリストを含むものとされ、装置は、無効化情報の更新のためのデータを、要求し、アプリケーションユニットから受け取るための通信手段を含むものとされ、当該装置はさらに、キーブロックならびに／もしくはアプリケーションユニットの認定証明の供給時において、ホワイトリストを削除し、新たなホワイトリストをコンパイルするコンパイル手段、および／またはホワイトリストを、上記の通信手段により受け取られた新たなホワイトリストに置き換える置換手段を含むものとされる。装置は、自身でホワイトリストを保存しておくことにより、無効化されていないアプリケーションユニットおよび／またはキーブロックのリストを与えられる。そのため、かかる装置は、新たなホワイトリストに保持されていないアプリケーションユニットも認証し得る。
【００２８】
本発明の１つの有利な実施形態では、無効化情報は、ブラックリストおよび／またはホワイトリストに加えて、無効化連続番号をさらに含むものとされ、上記の内部トリガ手段は、更新時において無効化連続番号を増分させるように構成され、装置は、上記の無効化連続番号と等しいまたはより大きなバージョン番号を有するデータのみを、更新用に受け入れるように構成される。イベントのトリガ後において装置が新たな無効化情報を受け取った場合（キーブロックのブラックリストを用いた場合）、または新たなキーブロックに直面した場合（キーブロックのホワイトリストを用いた場合）においても、これを確かに新しい無効化情報または新しいキーブロックであるとすることを保証するため、装置も、無効化連続番号を保持する。更新処理がトリガされると、この無効化連続番号が増分させられる。ブラックリストの場合には、装置は、無効化連続番号と等しいまたはより大きなバージョン番号が埋め込まれたキーブロック無効化リストのみを受け入れる。一方、ホワイトリストの場合には、装置は、無効化連続番号と等しいまたはより大きなバージョン番号が埋め込まれた、新たなキーブロックまたは新たなホワイトリストのみを受け入れる。
【００２９】
上記の装置の別の好ましい実施形態は、内部タイマをさらに含むものとされ、上記の内部トリガ手段は、予め決められた時間またはランダムに選択された時間が経過した後に、無効化情報を更新する処理をトリガするように構成される。その経過後に新たな無効化情報の要求または無効化バージョン番号の増分が行われるべき、予め決められた固定時間が与えられることにより、装置は、アプリケーションユニットに、定期的な新たな無効化データの送受信を強制的に行わせる。そのため、無効化されるべきアプリケーションユニットが装置により不当に首尾よく認証され得る最長時間が、上記の予め決められた時間よりも短い時間に限定されるように、保証される。この時間は、各トリガ後においてランダムに選択されてもよい。
【００３０】
１つの有利な実施形態では、装置は、認証の回数を計数する内部カウンタをさらに含むものとされ、内部トリガ手段は、予め決められた認証回数またはランダムに選択された認証回数の後に、無効化情報を更新する処理をトリガするように構成される。別の有利な実施形態では、装置は、当該装置により処理されるデータの量、とりわけコンテンツが保護されたデータの量を測定する内部メーターをさらに含むものとされ、内部トリガ手段は、予め決められたデータ量またはランダムに選択されたデータ量が処理された後に、無効化情報を更新する処理をトリガするように構成される。認証の回数または処理されたデータの量をトリガイベントとして利用することにより、新たに無効化されるアプリケーションユニット（たとえば、古いブラックリストには載っていないが、最新のブラックリストには載っているアプリケーションユニット）の有用性を制限することができる。２つのトリガイベントの間の時間として限られた時間を提供する場合と同様に、新たに無効化されるアプリケーションユニットにより引き起こされ得るダメージ（たとえばコンテンツへの不当なアクセス）が制限される。
【００３１】
本発明のさらに別の実施形態では、上記の認証手段は、アプリケーションユニットを実質的に唯一のものとして識別する識別子と、そのアプリケーションユニットと関連付けられた認証キーとを、取得するように構成され、装置は、その認証キーを保存するための不揮発性メモリをさらに含むものとされる。第１の認証処理中において取得された認証キーを、装置とアプリケーションユニットとの間の共有の秘密として用いてもよく、かつ／または、追加の認証を要することなく、通信中の別の瞬間において、かかる共有の秘密を生成もしくはやりとりしてもよい。
【００３２】
本発明に係る方法の別の有利な実施形態では、認証工程は、
−  装置が、アプリケーションユニットを実質的に唯一のものとして識別する識別子と、そのアプリケーションユニットと関連付けられた認証キーとを受け取り、その認証キーを不揮発性メモリ内に保存する第１の工程、および
−  上記の認証キーを用いて、上記の装置とアプリケーションユニットとの間で共有されるバスキーを生成する第２の工程を含むものとされ、
上記の第１の工程は、上記の更新する処理の後に１回実行され、上記の第２の工程は、次の内部トリガ工程まで、各認証工程において実行される。
【００３３】
ブラックリストの場合には、装置は、認証中において、使用されているキーブロック（バージョン番号）が無効化リスト上に出現しないことを確かめることができる。この目的のため、装置は、バージョン番号をキーブロックまたはルートキーと結び付ける、キーブロック上のシグニチャを確認してもよい。
【００３４】
そして、無効化リストの更新中において、装置は、このリストに不正変更が加えられていないことを確認することができる。すなわち、装置は、無効化リスト上のシグニチャを確認することができる（装置の内部において無効化リストが保存されている場合には、このシグニチャの確認は１回のみ必要であるかもしれない）。
【００３５】
ホワイトリストの場合には、装置は、キーブロックが十分に新しいこと、すなわちそのキーブロックの番号が、内的に保存されているバージョン番号よりも高いことを確認することができる。このステップも、シグニチャ（すなわち、バージョン番号をキーブロックまたはルートキーと結び付ける、キーブロック上のシグニチャ）の確認を必要とする。
【００３６】
シグニチャの確認は、対称的なキー復号化／暗号化と比較して、およそ１桁高コストであるが、本発明の認証方法のこの実施形態によれば、これらの高コストなシグニチャ確認動作を、最小限に抑えることができる。
【００３７】
ブラックリスト法およびホワイトリスト法のためのプロトコルは、以下の２つの部分に分けることができる。
−  新たなキーブロックがハードウェア装置に導入される際の、キーブロック登録段階（第１の工程）。この新たなキーブロックは、新たなアプリケーション、または（ホワイトリストの無効化後においては）新たなキーブロックを伴う古いアプリケーションに対応し得る。この段階中において、ハードウェア装置は、シグニチャを確認し、キーブロックを復号してルートキーを取得する。続いて、ルートキーすなわち認証キーが、好ましくは装置基板上の安全な不揮発性記憶部に保存される。
−  認証プロトコルのチャレンジ応答部分が実行された際における、（好ましくは装置がＮＶＲＡＭ内に保存している）ルートキーに基づく認証段階（第２の工程）。この段階は、ずっと頻繁に実行され、コンテンツが消費されるたびに実行されるが、この段階はシグニチャの確認を必要としない。
【００３８】
ここで、より低コストな認証段階のために支払う代償は、ハードウェアが、（安全な）ＮＶＲＡＭ内にアプリケーションごとのルートキーを保存する必要があるかもしれない点であることを、注意しておかなくてはならない。一般的には、装置は、無効化連続番号および／または無効化バージョン番号を保存するために、いずれにしても（安全な）ＮＶＲＡＭを必要とするだろうから、このことは問題ではない。このことは、１アプリケーションにつき、およそ１６（ルートキー）＋４（アプリケーション識別子）＝２０バイトを必要とする（ＮＶＲＡＭは額面以上のものとして供給されるべきであるが）が、ハードウェアは、使用度の低いルートキーを、より定期的に必要とされるルートキーで上書きしてもよい。その結果、使用度の低いアプリケーションは、使用されるたびに、キーブロックのシグニチャの確認を受けなくてはならなくなる。
【００３９】
典型的には、登録段階は、あるアプリケーションが、そのハードウェア装置を用いた認証を初めて行いたいときに実行される。ブラックリスト法を介したキーブロック無効化の１つの便利な実装形態は、あるアプリケーションまたはそのアプリケーションのキーブロックがキーブロック無効化リストに現れたときに、このアプリケーションのルートキーをＮＶＲＡＭからはじき出す形態である。ホワイトリスト法を介したキーブロック無効化の１つの便利な実装形態は、トリガまたは時間切れを示す信号が受信された際に、すべてのルートキーをＮＶＲＡＭからはじき出す形態である。
【発明を実施するための最良の形態】
【００４０】
以下、図面を参照して、本発明をより詳細に説明する。
【００４１】
図１は、キー発行攻撃を図解したブロック図である。（優秀な）ハッカーは、たとえばソフトウェアアプリケーションをハッキングすることにより、デバイスキーの組を取得し、入手可能な任意のキーブロックからルートキーを復号する。これらのルートキーは、インターネット等の通信システム３を介してアクセス可能なデータベース１に保存される。特殊なプレーヤーソフトウェアアプリケーション５が、準拠するグラフィックカードをエミュレートし、ルートキーとそのルートキーを有するキーブロックとにより暗号化されたコンテンツを、たとえばブルーレイディスク１１のための（無効化されていない）再生ソフトウェアアプリケーション９から取得する。インターネット３を介して上記のデータベース１にアクセスし、返しとして上記のルートキー１５を取得するため、上記のキーブロックのインジケータ１３（たとえばハッシュ値）が利用される。このルートキー１５または媒体キーは、暗号化されたコンテンツ７を復号するため、すなわちそのコンテンツにアクセスするために、上記の特殊なプレーヤーソフトウェアアプリケーション５により使用され得る。
【００４２】
図２は、ブラックリストの場合における、本発明の１つの実施形態に係る認証プロトコルを示したフローチャートである。ステップ２０において、装置により、時間切れのイベントが生じたか否か、すなわち無効化情報を更新する処理のトリガが存在するか否かが確認される。かかる時間切れのイベントが生じていなければ、ステップ２１において、認証要求が現在存在するか否かが確認される。この確認は、認証が要求され、ブラックリストおよびキーブロックが装置に提供されるまで繰り返される。この無効化リストのバージョン番号が、装置内に記憶されている無効化バージョン番号と等しいかより大きい場合には（ステップ２２）、この認証プロトコルはステップ２３へと続き、無効化バージョン番号に、キーブロックのバージョン番号の値が与えられる。ステップ２４では、使用されているキーブロックが上記の無効化リスト内に存在するか否かが確認される。かかるキーブロックが有効であることが示された場合、すなわちかかるキーブロックが上記の無効化リストすなわちブラックリスト内に記載されていなかった場合には、認証のためのさらなるステップが実行される（ステップ２５）。
【００４３】
ステップ２２においてブラックリストのバージョン番号が無効化バージョン番号よりも小さいことが分かった場合、またはステップ２４においてブラックリストによれば現在のキーブロックが無効であることが分かった場合には、それぞれステップ２６または２７において認証が中止され、プロトコルはステップ２０へと続く。ステップ２０において、時間切れのイベントが生じたこと、すなわち当該装置の内部トリガ手段が更新処理をトリガしたことが確認されると、ステップ２８において無効化バージョン番号が増分させられ、再びステップ２０へと処理が続く。
【００４４】
図３は、ホワイトリストの場合における、図２に類似のフローチャートである。ステップ３０において、時間切れのイベントすなわちトリガの確認が行われる。かかるトリガが生じていない場合には、ステップ３１における認証要求の確認が後続し、この確認は、認証が要求され、キーブロックが提供されるまで繰り返される。ステップ３２での確認において、提供されたキーブロックのバージョン番号が、認証用の当該装置の無効化バージョン番号よりも小さい場合には、ステップ３５において認証が中止され、ステップ３０からの処理が再び始まる。キーブロックのバージョン番号が上記の無効化バージョン番号と等しいかより大きい場合には、無効化バージョン番号が更新され、上記のキーブロックのバージョン番号の値を有するようにされる（ステップ３３）。その後、認証のためのさらなるステップが実行される（ステップ３４）。この認証の完了後、ステップ３０からの処理が再び始まる。
【００４５】
図４は、ＶＣＰＳに基づく認証プロトコルを示したブロック図である。アプリケーションユニット４０には、アプリケーション識別子ＩＤＡと、アプリケーションキーブロックＡＫＢと、そのキーブロックＡＫＢのルートキーすなわち認証キーＫｒｏｏｔとが付与されている。装置４２には、装置識別子ＩＤＤと、デバイスキーの組｛ＫＤｉ｝ｉ＝１．．Ｎとが付与されている。装置４２には、ブラックリスト法の場合にはＡＫＢ無効化リスト４４が、ホワイトリスト法の場合には無効化バージョン番号４６が、さらに付与されている。アプリケーションユニット４０は、認証プロトコルを開始させ（ステップ４８）、装置４２に要求５０を送信する。その要求５０が受信され（ステップ５２）、それに応答して、上記の装置識別子ＩＤＤがアプリケーションユニット４０に送信される（ステップ５４）。アプリケーションユニット４０は、上記のアプリケーションキーブロックＡＫＢ内において、装置４２に関連するノードを検索し（ステップ５６）、キーブロックＡＫＢから認証キーを取得する。この認証キーは、上記のＫｒｏｏｔを、暗号化された形態で含む。
【００４６】
さらに、ステップ５８においてアプリケーション乱数ＲＡが生成され、メッセージ６０が装置４２に送信される。このメッセージ６０は、アプリケーションキーブロックＡＫＢの関連ノードのインジケータ、上記の認証キー、乱数ＲＡ、およびキーブロックＡＫＢの認定証明もしくはシグニチャを含む。ステップ６２において、適切なデバイスキーＫＤｊを用いて、上記の認証キーＫｒｏｏｔが復号される。さらに、上記の認定証明またはシグニチャ内において、アプリケーションキーブロックＡＫＢのヘッダ上にあるシグニチャが確認される。加えて、取得されたルートキーＫｒｏｏｔが、上記のヘッダ内にあるそのルートキーＫｒｏｏｔの影（シャドー）に適合するか否かが確認される。
【００４７】
ブラックリスト法の場合には、無効化リスト上のシグニチャが確認される。装置４２が自己の無効化リストを保存している場合には、この確認はその保存の後１回のみ行われればよいが、各認証のたびに（たとえばアプリケーションユニット４０により）装置４２に（新たな）無効化リストが付与される場合には、この確認は各認証の際に繰り返されなくてはならない。さらに、上記のキーブロック識別子またはアプリケーション識別子ＩＤＡが、上記の無効化リスト４４内に存在するか否かが確認される。
【００４８】
ここで、上記３つの段落で述べたように、ＶＣＰＳ認証プロトコルにおいては、アプリケーションキーブロックは直接的には無効化されない点に留意されたい。したがって、ＶＣＰＳ認証プロトコルには、認定証明／シグニチャの交換ならびに確認処理、およびキーブロックのブラック／ホワイトリストの解読処理が存在しない。
【００４９】
ホワイトリスト法の場合には、アプリケーションキーブロックのヘッダ内にあるバージョン番号が、上記の無効化バージョン番号と比較される。すなわち、キーブロックのバージョン番号が、好ましくはＮＶＲＡＭ内に保存されている、無効化バージョン番号と等しい値またはより大きな値であるか否かが確認される。
【００５０】
ステップ６４において、装置乱数ＲＤが装置４２により生成され、上記のアプリケーション乱数ＲＡおよびデバイスキー・コントリビューションＫＤｂｕｓと共に、かつルートキーＫｒｏｏｔによって暗号化された状態で、アプリケーションユニット４０へと送信される（６８）。アプリケーションユニット４０内に埋め込まれているルートキーＫｒｏｏｔによって、メッセージ６８が復号され、その有効性の確認が、正しいアプリケーション乱数ＲＡの存在の確認によって行われる（ステップ７０）。ステップ７２では、アプリケーションキー・コントリビューションＫＡｂｕｓが生成され、アプリケーション乱数ＲＡ、上記の装置乱数ＲＤ、およびアプリケーションキー・コントリビューションＫＡｂｕｓと共に、ルートキーＫｒｏｏｔによって暗号化された状態で装置４２に送信される（７４）。この応答７４の有効性の確認は、上記の装置乱数ＲＤの存在の確認によって行われる。ステップ７８および８０では、アプリケーションユニット４０および装置４２による１回限りの共有の秘密として、バスキーが生成される。このバスキーの生成は、たとえば、上記のアプリケーションキー・コントリビューションＫＡｂｕｓとデバイスキー・コントリビューションＫＤｂｕｓとの組合せにハッシュ関数を適用することにより行われる。これにより、認証が完了する。
【００５１】
ここで、いずれかの確認が、この認証の何らかの部分が有効でないことを示唆した場合には、アプリケーションユニット４０または装置４２により、認証が中止される点に留意されたい。ステップ６２における認定証明の確認は高コストであるので、認証プロトコルの速度を速めるには、このステップを避けることまたは反復回数を減らすことが有利である。
【００５２】
図５は、ブラックリスト法の場合における、本発明に従う認証工程の第１の部分を示したブロック図である。アプリケーションユニット１００には、アプリケーション識別子ＩＤＡと、アプリケーションキーブロックＡＫＢと、そのキーブロックＡＫＢのルートキーすなわち認証キーＫｒｏｏｔとが付与されている。装置１０２には、装置識別子ＩＤＤと、デバイスキーの組｛ＫＤｉ｝ｉ＝１．．Ｎと、ＡＫＢ無効化リスト１０４とが付与されている。装置１０２は、この無効化リスト１０４として、以前の認証処理からの無効化リストを保存していてもよいし、無効化リスト１０４を伴う別の手段が設けられていてもよい。また、認証処理の一部として、アプリケーションユニット１００により、装置１０２に無効化リスト１０４が付与されることも可能である。ステップ１０６から１２０は、ブラックリスト法の場合の認証プロトコルに関連して上記で説明したステップ４８から６２に対応する。しかしながら、ステップ１１６においてはアプリケーション乱数ＲＡの生成は行われず、したがってメッセージ１１８内にはアプリケーション乱数ＲＡは含まれない。すべての確認が、その認証が有効であることおよびアプリケーションユニット１００が無効化されていないことを示した場合には、アプリケーション識別子ＩＤＡおよびルートキーＫｒｏｏｔが共に保存され（ステップ１２２）、好ましくは安全な不揮発性メモリ（ＮＶＲＡＭ、図示せず）に保存される。さらに、確認通知１２４が、アプリケーションユニット１００に送信される。これにより、本発明によるブラックリスト法のための登録段階１２６が完了する。
【００５３】
図６は、ホワイトリストの場合における、本発明に従う認証工程の第１の部分を示したブロック図である。アプリケーションユニット１４０には、アプリケーション識別子ＩＤＡと、アプリケーションキーブロックＡＫＢと、そのキーブロックＡＫＢのルートキーすなわち認証キーＫｒｏｏｔとが付与されている。装置１４２には、装置識別子ＩＤＤと、デバイスキーの組｛ＫＤｉ｝ｉ＝１．．Ｎと、無効化バージョン番号１４４とが付与されている。ステップ１４６から１６０は、ホワイトリスト法の場合の認証プロトコルに関連して上記で説明したステップ４８から６２に対応する。しかしながら、ステップ１５６においてはアプリケーション乱数ＲＡの生成は行われず、したがってメッセージ１５８内にはアプリケーション乱数ＲＡは含まれない。すべての確認が、その認証が有効であることおよびアプリケーションユニット１４０が無効化されていないことを示した場合には、アプリケーション識別子ＩＤＡおよびルートキーＫｒｏｏｔが共に保存され（ステップ１６２）、好ましくは安全な不揮発性メモリ（ＮＶＲＡＭ、図示せず）に保存される。さらに、上記で説明したブラックリスト法の場合における本発明に従う認証と同様に、確認通知１６４が、アプリケーションユニット１４０に送信される。これにより、本発明によるホワイトリスト法のための登録段階１６６が完了する。
【００５４】
図７は、本発明に従う認証工程の第２の部分を示したブロック図である。この第２の部分は、ブラックリストを用いた認証と、ホワイトリストを用いた認証とにおいて共通である。アプリケーションユニット２００には、アプリケーション識別子ＩＤＡと、アプリケーションキーブロックＡＫＢと、そのキーブロックＡＫＢのルートキーすなわち認証キーＫｒｏｏｔとが付与されている。装置２０２には、互いに関連付けられたアプリケーション識別子とルートキーとのリスト｛ＩＤＡ（ｉ），Ｋ（ｉ）ｒｏｏｔ｝ｉ＝１．．ｍが付与されている。このアプリケーション識別子ＩＤＡ（ｉ）とルートキーＫ（ｉ）ｒｏｏｔとのリストは、上記で説明したようなブラックリスト法および／またはホワイトリスト法のための、それまでに行われた複数の登録段階１２６、１６６から取得されてもよい。この第２の部分は、ステップ２０４において、アプリケーションユニット２００が、アプリケーション乱数ＲＡを生成し、そのアプリケーション乱数ＲＡとアプリケーション識別子ＩＤＡとを含むメッセージ２０６を装置２０２に送信することにより開始される。装置２０２は、アプリケーション識別子とルートキーとの上記のリスト内において、受け取ったアプリケーション識別子ＩＤＡを用いて、アプリケーションキーブロックＡＫＢのルートキーＫｒｏｏｔを検索する（ステップ２０８）。装置２０２により装置乱数ＲＤおよびデバイスキー・コントリビューションＫＤｂｕｓが生成され（ステップ２１０）、送信信号２１２としてアプリケーションユニット２００に送信される。この送信信号２１２は、上記のアプリケーション乱数ＲＡ、装置乱数ＲＤ、およびデバイスキー・コントリビューションＫＤｂｕｓを、暗号化された形態で含んでいる。この送信信号は、上記のアプリケーションキーブロックＡＫＢおよびアプリケーションユニット２００に対応するルートキーＫｒｏｏｔを用いて暗号化される。この送信信号２１２は、アプリケーションユニット２００のルートキーＫｒｏｏｔによって復号され、正しいアプリケーション乱数ＲＡを確認することにより、有効性が確認される（ステップ２１４）。
【００５５】
ステップ２１６では、アプリケーションキー・コントリビューションＫＡｂｕｓが生成され、メッセージ２１８が装置２０２に送信される。このメッセージは、Ｋｒｏｏｔによって暗号化された装置乱数ＲＤ、アプリケーションキー・コントリビューションＫＡｂｕｓ、およびアプリケーション乱数ＲＡを含む。このメッセージ２１８の有効性の確認は、Ｋｒｏｏｔを用いてこのメッセージ２１８を復号し、正しい装置乱数ＲＤの存在を確認することにより行われる。ステップ２２０および２２２では、アプリケーションユニット２００および装置２０２による１回限りの共有の秘密として、バスキーが生成される。このバスキーの生成は、たとえば、上記のアプリケーションキー・コントリビューションＫＡｂｕｓとデバイスキー・コントリビューションＫＤｂｕｓとの組合せに、ハッシュ関数を適用することにより行われる。これにより、本発明に従う認証プロトコルの第２の部分２２６が完了する。
【００５６】
図８は、本発明に従う、装置とアプリケーションユニットとの間の認証方法を示したフローチャートである。この認証方法の第１の部分は、上記で説明したようなアプリケーション識別子ＩＤＡと対応のルートキーＫｒｏｏｔとを装置に提供する、登録段階１２６、１６６により構成される。この登録段階１２６、１６６に続いて、アプリケーションユニットおよび装置に（１回限りの）共有の秘密Ｋｂｕｓを提供する、認証の第２の部分２２６が行われる。この第２の部分を完了した後、内部のトリガ手段が更新処理をトリガしたか否かが確認される（ステップ２４０）。かかるトリガのイベントが生じていない場合には、続いて、第２の部分２２６が繰り返され得る。一方、かかるトリガのイベントが生じている場合には、当該装置の無効化情報が更新され、それに対応して新たな登録段階１２６、１６６が後続する。
【００５７】
図９は、本発明に従う認証のための装置２５０を示したブロック図である。この装置２５０は、当該装置２５０とアプリケーションユニット（図示せず）との間の認証のための、認証手段２５２を含んでいる。この装置２５０はさらに、無効化情報２５４と、その無効化情報の更新処理をトリガするための内部トリガ手段２５６とを有している。また、装置２５０には、上記のアプリケーションユニットとの通信、とりわけ上記の更新のためのデータの要求ならびに受信、および／または（新たな）無効化情報の要求ならびに受信を行うための、通信手段２５８が設けられている。内部トリガ手段２５６に更新処理をトリガさせるため、内部トリガ手段２５６には、内部タイマ２６０、内部カウンタ２６２、および内部メーター２６４が接続されている。装置２５０はさらに、無効化情報を、更新処理中に受信された新たな無効化情報に置き換える置換手段と、更新処理中および更新処理後において、古い無効化情報を削除して新たな無効化情報をコンパイルするコンパイル手段とを含んでいる。
【００５８】
キー発行攻撃のため、キーに基づくブロードキャスト暗号化は、認証には適していないと一般に考えられてきた。しかしながら、フィリップスおよびＨＰによるＶｉｄｅｏ  Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ  Ｓｙｓｔｅｍ（ＶＣＰＳ；ビデオコンテンツ保護システム； http://www.licensing.philips.com/vcps参照）は、デバイスキーの使用をハードウェア装置に限定し、各（脆弱な）ソフトウェアアプリケーションには自己のキーブロックおよびルートキーを付与することにより、このキー発行攻撃を回避するブロードキャスト暗号化の使用法を導入した。このシステムでは、二方向の認証が行われるが、二方向の無効化は行われない。すなわち、ソフトウェアアプリケーションはハードウェア装置を無効化し得るが、ハードウェア装置はソフトウェアアプリケーションを無効化することはできない。本発明によれば、キーブロックのブラックリスト法（ハードウェア装置は、もはや使用することのできないキーブロック／アプリケーションのリストを定期的に取得する）、またはキーブロックのホワイトリスト法（ハードウェア装置は、既存のすべてのキーブロック／アプリケーションを定期的に無効化し、認証を継続するための新たなキーブロックを要求する）を導入することにより、このシステムを、真の意味での二方向の無効化の場合に拡張することができる。ハードウェア装置が新たな無効化情報／無効化のための完全なトリガを取得するための、多くの解決法が提供される。本発明は、ソフトウェアアプリケーションと、ＰＣのバックエンドに存在するチューナーカードまたはグラフィックカードとの間の認証プロトコルを提供するのに、特に適している。
【００５９】
自己発生させられた時間切れの後、ハードウェア装置は、新たなキーブロック無効化リストが伝達されるまでいかなる認証をも拒否してもよいし（ブラックリストの場合）、かつ／または、次の時間切れまで、既存のキーブロックを用いたすべての認証を拒否し、新たなキーブロックを用いた認証のみを行ってもよい（ホワイトリストの場合）。ハードウェア装置は、時間、実行済みの認証、および／または処理済みのコンテンツに関する、内部概念を有することが提案される。何らかの別の（類似の）値を、イベントをトリガするための「カウントダウン」として用いてもよい。この「タイム（時間）」キーピング機能は、新たな無効化情報が伝達されるまで、または新たなキーブロックがインストールされるまで、いかなる追加の認証をも拒否するように装置に通知するトリガを、定期的に発信する。
【００６０】
このトリガの設定を引き起こす条件の例として、以下の条件が挙げられる。
ａ）ハードウェア装置が内部の（安全な）クロックを有し、ある固定量の時間が経過した後（たとえば６ヶ月ごとに）、このクロックが時間切れを発生させる。
ｂ）ハードウェア装置が、認証プロトコルが実行されるごとに増分される、内部カウンタを有する。このカウンタの値がある固定数（たとえば５１２）に到達すると、トリガが発信される。
ｃ）ハードウェア装置が、処理済みのコンテンツ量に関する記録を保持する内部カウンタを有する。この処理済みのコンテンツ量がある固定数（たとえば１０００ギガバイト）に到達すると、トリガが行われる。
【００６１】
ここで、好ましくは、処理用の認証データに不正変更が加えられることを防止するため、適切な対策がとられるべきである点に留意されたい。たとえば、攻撃を加える者が、古い無効化リストまたはキーブロックをあたかも新しいものであるかのようにつくろうことを防止するために、無効化リストまたはキーブロックのバージョン番号は、暗号化された安全な状態で、その無効化リストまたはキーブロックと一体に結び付けられてもよい（たとえば、バージョン番号と、無効化リスト／キーブロックとが、ライセンス機関または認定機関によって、一緒に署名されてもよい）。さらに、好ましくは、記憶またはメモリ手段は、安全かつ不揮発性のものとすべきである。
【００６２】
本発明は、優先期間機構と組み合わせられてもよい。この優先期間機構の例としては、「Ｇｒａｃｅ  ｐｅｒｉｏｄ  ｆｏｒ  ｕｎａｕｔｈｏｒｉｚｅｄ  ｄｅｖｉｃｅ−ｈｏｓｔ  ｉｎｔｅｒａｃｔｉｏｎｓ」（「認証されていない装置−ホスト間交信のための優先期間」、国際特許出願ＰＣＴ／ＩＢ２００５／０５１７５８号、代理人整理番号ＰＨＮＬ０４０６４７）に記載された機構が挙げられる。この例は、システムの１つの構成要素が新たな無効化情報を要求しているが、そのシステムがネットワークにアクセスしてかかる情報を取得する手段を有さない場合において、システムが膠着状態にはまり込む問題を解決しようとするものである。
【図面の簡単な説明】
【００６３】
【図１】キー発行攻撃を図解したブロック図
【図２】ブラックリストの場合における、本発明の１つの実施形態に係る認証プロトコルを示したフローチャート
【図３】ホワイトリストの場合における、図２に類似のフローチャート
【図４】ＶＣＰＳより既知の認証プロトコルを示したブロック図
【図５】ブラックリストの場合における、本発明に従う認証工程の第１の部分を示したブロック図
【図６】ホワイトリストの場合における、本発明に従う認証工程の第１の部分を示したブロック図
【図７】本発明に従う認証工程の第２の部分を示したブロック図
【図８】本発明に従う認証方法を示したフローチャート
【図９】本発明に従う認証のための装置を示したブロック図
【図１】
2008545317.tif 000003
【図２】
2008545317.tif 000004
【図３】
2008545317.tif 000005
【図４】
2008545317.tif 000006
【図５】
2008545317.tif 000007
【図６】
2008545317.tif 000008
【図７】
2008545317.tif 000009
【図８】
2008545317.tif 000010
【図９】
2008545317.tif 000011
【国際調査報告】
2008545317.tif 000012
2008545317.tif 000013