JP2007528658A - 改良されたドメインマネージャ及びドメイン装置 - Google Patents

Abstract

ネットワークを管理するドメインマネージャ装置。マネージャは、ネットワークに加入する新たな装置にいくつかの対称認証鍵を発行し、好ましくは、いくつかの認証チケットを発行する。各認証鍵は、新たな装置がネットワークに含まれる他の各装置とセキュアに通信することを可能にする。各認証チケットは、第１識別子を有する装置が、第２識別子を有する装置に対して自らを認証することを可能にする。新たな装置は、第１識別子がそれの識別子と一致する認証チケットを受け付ける。新たな装置は、装置Ｂに自らを認証するため、装置Ｂに第２識別子Ｂを有するチケットを提示する。好ましくは、ドメインマネージャは、いくつかのマスタデバイスキーを生成し、１つを新たな装置に発行する。その後、認証チケットは、第２識別子を有する装置に発行されるマスタデバイスキーにより暗号化することができる。

Description

発明の詳細な説明

［イントロダクション］
最近数年間で、デジタル著作権管理（ＤＲＭ）のためのソフトウェア／ハードウェアアーキテクチャの開発への関心が高まっている。このようなアーキテクチャの主たる目的は、消費者の利便性とプライバシの観点から許容できるものである一方、コンテンツ所有者／プロバイダの観点から安全かつセキュアな方法によりデジタルデータコンテンツ（大部分はホームエンターテイメント関連）を提供することである。

コンテンツ所有者／プロバイダにとって最も大きなセキュリティの脅威は、彼らの著作権管理されたデジタルコンテンツの無制限な不法コピー及び配布である。このため、大部分のＤＲＭアーキテクチャの焦点は、所有者／プロバイダがデジタルコンテンツの配布及び処理方法を制御することを可能にする機構に関するものである。これをサポートするキーコンセプトは、コンプライアント装置（ｃｏｍｐｌｉａｎｔ ｄｅｖｉｃｅ）、すなわち、その構成により、コンテンツの所有者によって認められた方法によってのみデジタルコンテンツを処理することが保証される装置である。コンプライアント装置の最も重要な性質は、それらがセルフポリシング（ｓｅｌｆ−ｐｏｌｉｃｉｎｇ）である、すなわち、データコンテンツの一部に対して何れかの処理を実行する前に、当該処理が当該コンテンツ部分に対してコンテンツ所有者によって設定されたルールに矛盾していないことをチェックするという事実である。この性質により、コンプライアント装置の間のデータ交換ルールは大きく簡略化することが可能となり、例えば、コンプライアントなデジタルビデオレコーダに、「ノー・コピー」とマーキングされたビデオへの完全なアクセスを安全に与えることが可能となる。すなわち、レコーダがコンプライアントであるため、ビデオの所有者は、そうすることが可能であったとして、それが決してコピーを生成しないことが保証される。

コンプライアント装置は、通常は、コンプライアンスチェッキング（ｃｏｍｐｌｉａｎｃｅ ｃｈｅｃｋｉｎｇ）（それらが実際にコンプライアントであるということを他の装置に証明する）を容易にする暗号鍵を有し、それらの（潜在的には悪意ある）ユーザが、プロテクション機構を回避し、著作権管理されたデジタルコンテンツへの無制限なアクセスをすることを防ぐためのタンパレジスタント（ｔａｍｐｅｒ ｒｅｓｉｓｔａｎｔ）として製造される。

現在、装置のコンプライアンスチェッキングを行うための一般的なアプローチは、可能なものが２つある。個別認証（ｉｎｄｉｖｉｄｕａｌ ａｕｔｈｅｎｔｉｃａｔｉｏｎ）の場合、これは、公開鍵暗号化により実行され、すなわち、デジタル証明書を開始ライセンス期間によって証明された公開鍵による一意的な公開／秘密鍵ペアを各装置に割り当てることによって行われる。この場合、２つのコンプライアント装置がやりとりする必要があるときは常に、それらは、まず相互の認証プロトコルに従事し、それらが「コンプライアント」公開鍵に対応する秘密鍵を有することを互いに証明する。

装置のコンプライアンスチェッキングを実行する他の方法は、グループ認証（ｇｒｏｕｐ ａｕｔｈｅｎｔｉｃａｔｉｏｎ）を介したものである。この場合、与えられた装置のアイデンティティは、当該装置が自らがコンプライアント装置グループの一部であるということを証明可能である限り、重要ではない。実際、グループ認証を行う最も効率的な方法は、ブロードキャスト暗号化として知られる対称鍵暗号化アルゴリズムのクラスに基づくものであり、Ｊｅｆｆｒｅｙ Ｂ．Ｌｏｔｓｐｉｅｃｈ、Ｓｔｅｆａｎ Ｎｕｓｓｅｒ及びＦｌｏｒｉａｎ Ｐｅｓｔｏｎｉによる「Ｂｒｏａｄｃａｓｔ ｅｎｃｒｙｐｔｉｏｎ‘ｓ ｂｒｉｇｈｔ ｆｕｔｕｒｅ」（ＩＥＥＥ Ｃｏｍｐｕｔｅｒ，３５（１），２００２）に記載されている。

個別認証による主な問題は、それが、ソフトウェアにより実現される場合には低速であり、ハードウェアにより実現される場合にはコスト高となる（専用のハードウェアアクセラレータのコストは、装置全体の価格に追加される）公開鍵暗号化アルゴリズムによるものであるという事実である。他方、ブロードキャスト暗号化に基づく解決策は、ソフトウェアにより妥当な程度効率的に実現可能であるが、それらは、障害のある装置を無効する機能が限定されていると共に、コンプライアント装置間のやりとりを規制する複雑なセキュリティポリシーを表現するための限られたサポートしかないなどのそれ自身の問題を有している。

デジタル著作権管理の分野では、認証ドメイン（ａｕｔｈｏｒｉｚｅｄ ｄｏｍａｉｎ）のコンセプトが、ＤＶＢ及びＴＶ−Ａｎｙｔｉｍｅなどの規格団体において最近導入されている。認証ドメインは、コンテンツ所有者（自らの著作権の保護を所望する）及びコンテンツ消費者（コンテンツの無制限な使用を所望する）の利害の双方に供する解決策を求めようとするものである。このアイデアはまた、それが認証ドメインのボーダを超えない限り、コンテンツが比較的自由に使用することが可能な制御されたネットワーク環境を有するというものである。典型的には、認証ドメインは、ホームエンターテイメントの中心となる。

特定のアーキテクチャに対するいくつかのデザイン要求は、国際特許出願ＷＯ０３／０９８９３１（代理人整理番号ＰＨＮＬ０２０４５５）と、Ｆ．Ｋａｍｐｅｒｍａｎ、Ｗ．Ｊｏｎｋｅｒ、Ｐ．Ｌｅｎｏｉｒ及びＢ．ｖｄ Ｈｅｕｖｅｌによる「Ｓｅｃｕｒｅ ｃｏｎｔｅｎｔ ｍａｎａｇｅｍｅｎｔ ｉｎ ａｕｔｈｏｒｉｚｅｄ ｄｏｍａｉｎ」（Ｉｎ Ｐｒｏｃ．ＩＢＣ２００２，ｐａｇｅｓ４６７−４７５，Ｓｅｐｔ．２００２）においてすでに概略されている。これらの要求は、認証ドメインの識別、装置のチェックイン、装置のチェックアウト、権利のチェックイン、権利のチェックアウト、コンテンツのチェックイン、コンテンツのチェックアウトと共にドメイン管理などの問題を含む。上記文献は、公開鍵証明書を介した個別認証に基づくコンプライアンスチェッキングを仮定しているが、これはパフォーマンス／経済的な観点から最適ではない（公開鍵処理は、ソフトウェアにより実現されるときには低速となり、ハードウェアにより実現されるときにはコスト高となる）。

公開鍵暗号化アルゴリズムに関する信頼性は、明らかに上記デザインの弱点である。このことは、エニー・ツー・エニー（ａｎｙ−ｔｏ−ａｎｙ）装置通信パターンを可能にするため、ドメインのすべての装置部分が、公開鍵処理をスピードアップするためのハードウェア暗号化アクセラレータを有する必要がある。これは、システムの全体的なコストを明らかに引き上げることとなる。本開示では、上記問題点を解決しようとする他のデザインを提供する。特に以下の（矛盾する）問題点を調停しようとする。
・当該アーキテクチャは、個別の装置の認証をサポートすべきである。
・当該アーキテクチャは、公開鍵処理がソフトウェアにより実行されるとき、適度に効率的に動作すべきである（公開鍵ハードウェアアクセラレータは、必須とされるべきではない）。
・当該アーキテクチャは、大きなパフォーマンスの低下なく、潜在的に多数の無効にされる装置をサポートすべきである。
［発明の概要］
本発明の課題は、公開鍵暗号化の利用を要求しないネットワークの装置間の認証を可能にすることである。

上記課題は、本発明によると、前記ネットワークに加入する新たな装置に、各々が前記ネットワークを構成する他の各装置との認証された通信を可能にする所定数の対称認証鍵を発行する認証手段を有することを特徴とするドメインマネージャ装置において達成される。

上記課題はさらに、本発明によると、ネットワークを介し第２装置と通信するよう構成され、前記ネットワークを加入するようドメインマネージャ装置に要求し、各々が前記ネットワークに含まれる他の各装置との認証された通信を可能にする所定数の対称認証鍵を受け付けるネットワーキング手段と、前記第２装置との認証された通信を可能にする前記対称認証鍵を用いて前記第２装置と通信する認証手段とを有することを特徴とする第１装置において達成される。

本発明は、既存の解決策に関する主要な問題点、すなわち、個別認証のサポートの欠落を回避しながら、対称鍵暗号化アルゴリズムに基づく解決策に関する効果、すなわち、高速なソフトウェア実現を組み合わせる。さらに、このアーキテクチャは、既存の解決策に対して明らかな効果である大変効率的なリボケーション機構をサポートする。

本発明によるハイブリッドアーキテクチャの大きな効果は、公開鍵処理が装置間の認証に必要でないということである。第１装置がネットワークに加入することを要求するとき、すなわち、第１装置がドメインマネージャに対して自らを認証するとき、公開鍵処理を実行することが望ましいかもしれない。しかしながら、この点について、第１装置はネットワークのまだ一部ではない。この認証段階に続いて、同一のドメインの装置部分間のすべての認証が、（高速な）対称鍵処理により行われる。

これに対して支払われる対価は、すべての装置におけるさらなるストレージ要求であるが、認証ドメインは限られた個数（１０のオーダー）の装置しか有しないと仮定すると、これらのストレージ要求は過剰ではない。

さらに、請求項２によると、第１識別子を有する装置が第２識別子を有する装置に対して自らを認証することを可能にする認証チケットが発行可能である。これらは、第１装置によって第２装置に提示することが可能である。第２装置が受け付けた認証チケットを有効なものとして受け付けると、第１装置が認証される。

さらに、所定数のマスタデバイスキーが生成されるかもしれず、その後、マスタキーの各々が、ネットワークに加入する各装置に発行される。これらのキーは、ドメインマネージャと各装置との間で共有される秘密として機能し、各装置がドメインマネージャからと称される情報を認証することを可能にする。さらに、装置は、それらのデバイスマスタキーを格納するタンパレジスタントメモリしか必要としない。他のすべてのデータは、信頼されていないメモリに格納され、マスタキーの下で暗号化することができる。

装置Ｂに対して装置Ａを認証する各認証チケットは、好ましくは、装置Ｂに関するマスタデバイスキーにより少なくとも部分的に暗号化される。このように、Ａから当該チケットを受け付けると、Ｂは、チケットがそれを良好に解読することによって真正であると確認することができる。

本発明は、認証鍵とチケットの生成を予め可能にする。各マスタデバイスキーに一意的な識別子が割り当てられると、認証鍵及びチケットは、各マスタデバイスキー識別子に関連付けすることが可能である。これは、装置がネットワークにまだ加入していない装置に対してチケットを発行可能であることを意味する。例えば、ネットワークに加入するすべての装置は、加入時にネットワーク上にものより（多数の）少数の装置が存在しているとしても、同時にネットワークにおそらく存在しうる他のすべての装置について１つの認証チケットを発行することが可能である（すなわち、ネットワークにおいて同時に許容される装置の最大数より少ない１つのチケットを受け付ける）。

以降に加入する装置には、１つのマスタキーと当該マスタキーに対応する識別子が割り当てられる。さらなるアクションがない場合、すでにネットワークにあるすべての装置は、適切な認証鍵とチケットを用いることによって、以降に加入した装置に対して自らを認証し、それと通信することが可能となる。

ドメインマネージャは、ネットワークに含まれるグローバルリボケーション（ｒｅｖｏｃａｔｉｏｎ）リスト上の無効にされた装置を特定することによって、ローカルリボケーションを生成することができる。当該装置がローカルリボケーションリストを認証することを可能にするため、ドメインマネージャは、各々がマスタデバイスキーの１つを用いてローカルリボケーションリストの認証を可能にするいくつかのリボケーション認証コードを生成する。各装置は、自らのマスタデバイスキーを用いてリボケーション認証コードの１つを解読することが可能であり、これにより、ローカルリボケーションリストの真正性を確立することができる。

国際特許出願ＷＯ０３／１０７５８８（代理人整理番号ＰＨＮＬ０２０５４３）に記載されるように、リボケーションに対する既存の解決策による問題点は、多数の装置を無効にすることにより、重大なパフォーマンスペナルティを引き起こすということである。すなわち、ベストなケースでは、リボケーションデータ構造のサイズは、無効にされる装置の個数に対して少なくとも線形に増大する（従って、シンプルな計算は、１００，０００個の装置を無効にすることにより、１ＭＢのリボケーションリストがもたらされることを示す）。リボケーションリストが格納され、すべてのコンプライアント装置によって処理される必要があるため、これは装置のメモリ要求を大きく増大させる。本発明によると、グローバル装置リボケーションリストのわずかなサブセットのみが格納され、ネットワークの装置により処理される必要がある。
［詳細な説明］
図１は、ネットワーク１１０を介し相互接続される装置１０１〜１０５を有するシステム１００を概略的に示す。本実施例では、システム１００は、認証ドメインとして機能するイン・ホームネットワークである。典型的なデジタルホームネットワークは、ラジオ受信機、チューナ／デコーダ、ＣＤプレーヤー、一対のスピーカー、テレビ、ＶＣＲ、テープデッキなどのいくつかの装置を有する。これらの装置は、通常は、テレビなどの装置がＶＣＲなどの他の装置を制御することができるように相互接続される。チューナ／デコーダ又はセットトップボックス（ＳＴＢ）などの１つの装置は、普通は、その他の装置に対する集中制御を提供する中央装置となる。

典型的には、音楽、曲、映画、テレビ番組、写真、ゲーム、書籍などのものを有し、またインタラクティブサービスを有するかもしれないコンテンツが、家庭のゲートウェイ又はセットトップボックス１０１を介し受信される。コンテンツはまた、携帯装置を用いて、又はディスクなどの記憶媒体などの他のソースを介し家庭に入ってくる可能性がある。ソースは、ブロードバンドケーブルネットワークとの接続、インターネット接続、衛星ダウンリンクなどとすることができる。そのとき、コンテンツはレンダリングのため、ネットワーク１１０を介しシンクに転送することが可能である。シンクは、例えば、テレビディスプレイ１０２、携帯表示装置１０３、携帯電話１０４及び／又は音声再生装置１０５とすることができる。

コンテンツアイテムがレンダリングする正確な方法は、装置のタイプとコンテンツのタイプに依存する。例えば、ラジオ受信機では、レンダリングは、音声信号の生成と、それらのラウドスピーカーへの供給を有する。テレビ受信機では、レンダリングは、一般に音声及び映像信号の生成と、それらの表示画面及びラウドスピーカーへの供給とを有する。他のタイプのコンテンツについては、同様に適切なアクションがとられる必要がある。レンダリングはまた、受信信号の解読又はスクランブル解除、音声及び映像信号の同期化などの処理を含むかもしれない。

セットトップボックス１０１又はシステム１００の他の何れかの装置は、受信コンテンツの記録及び以降の再生を可能にする適切な大きさのハードディスクなどの記憶媒体Ｓ１を有するものであってもよい。記憶媒体Ｓ１は、セットトップボックス１０１が接続されるＤＶＤ＋ＲＷレコーダなどのあるタイプのパーソナル・デジタル・レコーダ（ＰＤＲ）とすることが可能である。コンテンツはまた、システム１００に入力され、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）やＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）などのキャリア１２０上に格納することが可能である。

携帯表示装置１０３と携帯電話１０４は、Ｂｌｕｅｔｏｏｔｈ又はＩＥＥＥ８０２．１１ｂなどを利用して、ベースステーション１１１を用いてネットワーク１１０に無線接続される。その他の装置は、従来の有線接続を用いて接続される。装置１０１〜１０５がやりとりするのを可能にするため、異なる装置がメッセージ及び情報を交換し、互いに制御することを可能にするいくつかの相互互換規格が利用可能である。１つの周知な規格は、そのバージョン１．０が２０００年１月に公開され、ｈｔｔｐ：／／ｗｗｗ．ｈａｖｉ．ｏｒｇ／のアドレスにおいてインターネットを介し利用可能であるＨＡＶｉ（Ｈｏｍｅ Ａｕｄｉｏ／Ｖｉｄｅｏ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ）規格である。他の周知の規格は、ドメスティック・デジタル・バス（Ｄ２Ｂ）規格、ＩＥＣ１０３０に記載される通信プロトコル及びユニバーサル・プラグ・アンド・プレイ（ｈｔｔｐ：／／ｗｗｗ．ｕｐｎｐ．ｏｒｇ）である。

一般に言うと、認証ドメインは、以下のエンティティを有する。
・いくつかのデジタルコンテンツアイテム コンテンツアイテムは、著作権管理された電子情報である。各コンテンツアイテムは、当該アイテムに対する使用ルールを設定することが可能なエンティティ（人／機関）である所有者を有する。
・装置１０１〜１０５などのいくつかのコンプライアント装置 これらは、ライセンスされたメーカーによって製造される電子装置である。それらは、コンテンツアイテムのレンダリング、格納及び記録が可能である。構成によって、コンプライアント装置は、使用ルールを介しそれらの所有者によって許可された方法によってしかデータアイテムを処理することができない。コンプライアント装置は、当該アイテムに対する使用を照会する前には、コンテンツアイテムを処理しない。
・セットトップボックス１０１などの１つの認証ドメイン（ＡＤ）マネージャ装置 これは、ドメインのその他の装置を追跡するコンプライアント装置である。それは、当該ドメインに参入する新たな装置を登録し、危険な（もはやコンプライアントでないと知られる）装置と共にドメインから離れる装置を削除する。
・セットトップボックス１０１や音声再生装置１０５などのいくつかのコンテンツマネージャ装置 これらは、新たなデータコンテンツをドメインにもたらすコンプライアント装置である。それらは、コンテンツ所有者／プロバイダとやりとりすることによって、又はプレパッケージメディア（ＤＶＤなど）からコンテンツを直接読み出すことによって、これを行う。製造時、各コンプライアント装置には、タンパレジスタントメモリに格納される秘密鍵と、装置証明書によりライセンスされた組織によって証明された公開鍵を有する公開／秘密鍵ペアが与えられると仮定する。また、各コンプライアント装置は、装置証明書に含まれる一意的なグローバルデバイスＩＤ（ＧＤＩ）によって識別されると仮定する。

装置は複数の役割を演じることが可能であり、すなわち、それはコンテンツをレンダリング可能であると共に、ＡＤマネージャ及びおそらくはコンテンツマネージャであるということを理解することは重要である。与えられた装置に含まれる機能量は、メーカー／消費者の選択である。消費者の観点から、装置内の余計な機能は、追加的なコマンドインタフェースを介し実現され、ＡＤマネージャが特別なＡＤ管理インタフェースを必要としながら、コンテンツマネージャは、それらがサポートするコンテンツプロバイダとのやりとりを可能にするコマンドインタフェースを必要とする。
［認証ドメイン生成］
図２は、ＡＤマネージャ２１０と装置２００をより詳細に概略的に示す。新たなＡＤの生成は、ＡＤマネージャ機能を有する１つのコンプライアント装置を必要とする。ドメインの所有者は、ＡＤ管理インタフェースを用いて、「新たなＡＤの生成」コマンドを発信する。このようなコマンドを受信すると、ＡＤマネージャ装置はまず、それが管理した以前のＡＤに関するすべての情報を消去し、それに続いて、それのタンパレジスタントメモリＴＲＭに格納されるマスタデバイスキーリスト（好ましくは、１２８ビットＡＥＳキーである対称暗号鍵のリスト）を生成するため、キー生成手段ＫＧＭを起動する。

このリストのサイズは、ドメインに許容される装置の最大数に等しくなるようベストに選択される。これは、メーカー／コンテンツプロバイダの選択であるが、それは１０のオーダーであると予想する。そのサイズは、より大きいものを選ぶことも可能である。

最後に、マネージャは、それのタンパレジスタントメモリＴＲＭに格納されるドメインＩＤを生成する。ドメインＩＤは、好ましくは、マネージャのＧＤＩと増加するドメインバージョン番号の連結として構成される。製造時には、ドメインバージョン番号はゼロに設定される。ＡＤマネージャがリセットされると、ドメインバージョン番号はインクリメントされ、マネージャが常に異なるドメインＩＤを生成することを保証する。マスタデバイスキーリストとドメインＩＤの両方が生成されると、ＡＤ生成処理は完了し、マネージャは新たな装置を登録することによって新たなドメインに含めることができる。
［装置登録］
ＡＤに参入する装置２００は、ＡＤマネージャによって登録される必要がある。この登録は、装置Ｄがドメインに加入しようとするときに自動的に、又はリクエストにより実行されてもよい。登録は、ネットワークを介した通信を伴い、このため、装置２００とマネージャ２１０はネットワーキングモジュールＮＥＴを有する。

登録段階は、コンプライアンスチェッキングと認証の２つのステップから構成される。コンプライアンスチェッキングステップでは、ＡＤマネージャは、ライセンス機関によってコンプライアントであるとして証明されたものとして新たな装置を認証する。このステップが良好に完了すると、ＡＤマネージャは、それらがドメインの他の装置とやりとりするのに必要とする暗号化マテリアルを与えることによって、新たな装置をドメインに追加する。
［コンプライアンスチェッキングプロトコル］
新たな装置をドメインに登録する第１のステップは、コンプライアンスチェッキングである。コンプライアンスチェッキングは、公開鍵暗号化により実行される。ＡＤマネージャと新たな装置は、その後、秘密鍵の送信を可能にする公開鍵相互認証プロトコルに従事する（そのようなプロトコルの具体例が、ＩＳＯ／ＩＥＣ１１７７０−３，１９９９に記載されている）。このため、両者は、公開鍵認証モジュールＰＫＡＵＴＨを有する。

当該プロトコルの終わりにおいて、各装置は、他方の装置がライセンス機関によって「コンプライアント」として証明された公開鍵に対応する秘密鍵にアクセスすることが可能となることが保証される。これが行われると、ＡＤマネージャ２１０は、登録装置２００にそれの装置マスタキーリストからの装置マスタキーを割り当てる（キートランスポートプロトコルを介し）。マネージャのリストの当該キーのインデックスは、新たに登録された装置のローカルデバイスＩＤ（ＬＤＩ）となる。ドメインマネージャが登録された各装置のＧＤＩと共に、当該ＧＤＩに関するＬＤＩを格納することが仮定される。これは、装置の登録のために求められる。

図３において、ローカルデバイス識別子（ＬＤＩ）、マスタデバイスキー（ＭＤＫ）及びグローバルデバイス識別子（ＧＤＩ）が、どのようにタンパレジスタントメモリＴＲＭに格納可能であるに関する具体例が示される。例えば、ＬＤＩ「１０」はＭＤＫ「１２３４」に関連し、ＧＤＩ「２０１」の装置に割り当てられる。ＬＤＩ「１２」はＭＤＫ「３２４１」に関連し、何れの装置にも（まだ）割り当てられない。
［装置認証］
ＡＤにある装置を受け入れることは、コンテンツアイテムを取得するため、当該装置がＡＤの他の装置について認証することを可能にすることを要求する。ＡＤマネージャは、いくつかのペア（認証鍵，認証チケット）から構成される認証証明セットを新たな装置に発行する認証モジュールＡＵＴＨを有する。

装置が登録されると、それにローカルデバイス識別子、すなわち、Ａが割り当てられ、当該ローカルデバイス識別子ＭＫ_Ａに関するマスタキーが与えられる。ＡＤマネージャはまた、Ａとして知られる装置に対して、好ましくは、（Ｋ_ＡＹ，認証チケット_ＡＹ）の形式の各ペアとして（Ｙは０〜Ｎ（Ｎはマスタキーの個数である）であり、ＹはＡに等しくない）、いくつかの認証鍵及び認証チケットから構成される認証証明セットを生成する。

認証鍵Ｋ_ＡＢは、装置Ａがローカルデバイス識別子Ｂにより装置との通信を暗号化することを可能にする。Ａの登録時に、ＬＤＩ Ｂを有する装置がネットワークに存在しないということに留意することが重要である。このような場合、他の装置がネットワークに加入すると、それにはＬＤＩ Ｂが割当可能であり、その後、ＡはキーＫ_ＡＢを用いてそれと通信することが可能となる。好ましくは、認証鍵は対称暗号鍵であり、すなわち、対称暗号化スキームによっては使用できない（また、秘密鍵暗号化スキームとして知られる）。対応するキーを等しいものとして、すなわち、Ｋ_ＡＢ＝Ｋ_ＢＡとして選ぶことが可能である。しかしながら、これは、装置マネージャが装置間のすべての可能性のあるペア単位のキーを記憶することを必要とし、このため、格納要求がドメインサイズに二次的に増大する。Ｋ_ＢＡと異なるＫ_ＡＢを選択することによって、マネージャは即座にこれらのキーを生成し、それらを認証チケットに配置し、その後それを放置する。各装置には、ドメインの他のすべての装置の既存の部分と共に、将来的にＡＤに加入するかもしれないすべての可能性のある装置について認証鍵が与えられる。

一実施例では、各装置に与えられる認証鍵の個数は、ＡＤ生成時にマネージャによって生成されるマスタキーリストのサイズと等しくなるよう選択される。このように、新たな装置がＡＤに参入すると、既存の装置が更新される必要がなく、ＡＤがそれの各コンポーネント間の連続的なネットワーク接続性を仮定しなくても動作可能となる。

各認証鍵に関する認証チケットがある。認証チケットは、装置Ａが自らをローカルデバイス識別子Ｂを有する装置に認証することを可能にする。再び、ＬＤＩ Ｂを有する装置は、Ａの登録時にネットワークに存在しないかもしれない。依然として、ローカルデバイス識別子がＡＤマネージャによって割り当てられているため、当該ＬＤＩが使用されていないときでさえ、ＬＤＩ Ｂを参照するチケットを生成することが可能である。

好ましくは、チケットは、（ＩＤ_{Ｄｏｍａｉｎ}，Ｋ_ＡＢ，ＧＤＩ_Ａ，ＬＤＩ_{ｓｏｕｒｃｅ}，ＬＤＩ_{ｄｅｓｔｉｎａｔｉｏｎ}）の形式を有する。ここで、ＩＤ_{Ｄｏｍａｉｎ}はドメイン識別子であり、ＧＤＩ_ＡはＡのグローバルデバイスＩＤであり、ＬＤＩ_{ｓｏｕｒｃｅ}はソース装置（ここでは、Ａ）のローカルデバイスＩＤであり、ＬＤＩ_{ｄｅｓｔｉｎａｔｉｏｎ}はデスティネーション装置（ここでは、Ｂ）のローカルデバイスＩＤである。チケットは、Ａが同じドメインのコンプライアント装置部分であるということをＢに証明するため、Ａによって使用可能である。チケットは、期限日及び／又はバージョン番号を搬送するかもしれない。これは、装置が期限切れのチケットを拒絶することを可能にする。

装置Ａのチケットは、好ましくは、当該装置ＡのＧＤＩを有する。これは、当該チケットを受け取る装置が、ＡのＧＤＩを知ることを可能にする。ＧＤＩは、例えば、グローバルリボケーションリスト上のＡのＧＤＩをチェックすることによって、又はローカルチケットリボケーションリスト上の当該ＧＤＩをチェックすることによって、Ａが取り消されたか検証するのに必要とされる（以下を参照されたい）。

このチケットは、好ましくは、Ｂ，Ｋ_Ｂのマスタデバイスキーを用いて暗号化される。このチケットはＢとマネージャとの間のみで共有されるキーにより暗号化されるため、Ｂはチケットがそれを生成したことのみ保証し、そのことは、マネージャがＡのコンプライアンスを検証したことを意味する（マネージャがプロトコルに従うコンプライアント装置であるとされると）。チケットの真正性をプロテクトする他の方法がまた利用されてもよい。これは、ＬＤＩ Ｂを有する装置が、ＡＤマネージャが当該チケットをＡに発行するときにネットワークに存在しない場合にも適用される。ある装置にＬＤＩ Ｂが割り当てられると、それはまた、当該ＬＤＩに関するマスタデバイスキーのコピーを受け取り、それに提示されたチケットの真正性を検証することが可能となる。

ある装置がドメインの一部となると、それは、ドメインの他の装置からそれが取得するコンテンツアイテムを処理するのに利用可能である。コンテンツアイテムを交換する前、２つの装置は、それらが同じドメインの一部であることを証明するため、互いに認証する。装置２００には、図２に示されるように、当該機能を実行する認証モジュールＡＵＴＨが設けられる。これら２つの装置の間の認証プロトコルは、以下の通りである。それは、Ｂ．Ｃｒｉｓｐｏ、Ｂ．Ｃ．Ｐｏｐｅｓｃｕ及びＡ．Ｓ．Ｔａｎｅｎｂａｕｍによる「Ｓｙｍｍｅｔｒｉｃ ｋｅｙ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｓｅｒｖｉｃｅｓ ｒｅｖｉｓｉｔｅｄ」（Ｔｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ ＩＲ−ＣＳ−００５，Ｖｒｉｊｅ Ｕｎｉｖｅｒｓｉｔｅｉｔ，２００３）に詳細に記載されている。

（１）Ａ→Ｂ：ＬＤＩ_Ａ，Ｎ_Ａ
（２）Ｂ→Ａ：ＬＤＩ_Ｂ，Ｎ_Ｂ，認証チケット_ＢＡ
（３）Ａ→Ｂ：＜Ｎ_Ｂ＞ＳＫ，認証チケット_ＡＢ
（４）Ｂ→Ａ：＜Ｎ_Ａ＞ＳＫ
上記プロトコルでは、Ｎ_ＡとＮ_Ｂは、それぞれＡとＢによって選ばれるチャレンジ（ｎｏｎｃｅ）である。

ステップ２の終わりで、装置Ａは、Ｋ_Ａ（当該装置に割り当てられたマスタキー）の下で暗号化され、Ａがチケットを解読し、Ｋ_ＢＡを取得することを可能にする認証チケット_ＢＡを取得する。ここで、装置Ａは、Ｋ_ＡＢとＫ_ＢＡの両方を有し、このため、それはＳＫ＝ＳＨＡ−１（Ｋ_ＡＢ，Ｋ_ＢＡ，Ｎ_Ａ，Ｎ_Ｂ）を計算し、それによりＮ_Ｂを暗号化することができる。

ステップ（３）の終わりで、装置Ｂは、Ｋ_ＡＢを取得するため解読可能な認証チケット_ＡＢを取得する。Ｋ_ＡＢとＫ_ＢＡの両方によって、装置ＢはまたＳＫを計算することができる。ＳＫによって、装置Ｂは、装置ＡがＮ_Ｂを正確に暗号化したことを検証することが可能となり（これは、Ｂに対してＡを認証する）、その後、それはＮ_Ａを暗号化し、ステップ（４）においてそれを装置Ａに送信することが可能となる。装置Ａは、＜Ｎ_Ａ＞ＳＫを解読し、これにより、Ａに対してＢを認証することが可能となる。

プロトコルの終わりに、ＳＫは、ＡとＢの間で共有される秘密となり、これら２つの装置間のデータトラフィックをセキュアするのに利用することが可能となる。記号＜Ｘ＞Ｋは、要素ＸがキーＫを用いて暗号化されることを示す。ＳＨＡ−１は、周知のＦＩＰＳ１８０−１セキュアハッシュ関数であり、ＳＫを計算するための好ましい選択である。

認証プロトコル中、他方のチケットを受け付ける前に、装置Ｂは以下のチェックを行う必要がある。
・チケットのＩＤ_{Ｄｏｍａｉｎ}が、装置が一部となる認証ドメインに対応する。
・チケットのＬＤＩ_{ｄｅｓｔｉｎａｔｉｏｎ}は、それ自体のＬＤＩ_Ｂに等しい。
・他方の装置は、無効にされていない（以下で説明される）。
［セキュアコンテンツ格納］
データコンテンツアイテムは、コンテンツマネージャ装置によってドメインに持ち込まれる。それらは、外部コンテンツプロバイダとやりとりすることによって、又はプリパッケージされたメディア（ＤＶＤなど）からコンテンツを読み出すことによって、当該コンテンツをもたらす。データアイテムは、非暗号化形式によりタンパレジスタントメモリのみに格納されるべきである。タンパレジスタントメモリが、信頼できないストレージよりかなり高価であるという事実が与えられると、２レベルスキームが使用される。すなわち、それがデータコンテンツを取得すると、コンテンツマネージャは、ランダムなコンテンツキー（例えば、１２８ビットＡＥＳキーなど）を生成し、当該キーによりコンテンツを暗号化する。その後、それはそれのマスタキーによりコンテンツキーを暗号化する。暗号化されたコンテンツと暗号化されたコンテンツキーは、その後、ローカルハードディスクや（再）書き換え可能なＤＶＤなどの非セキュア記憶媒体又はネットワーク装置に安全に格納することができる。装置がコンテンツを必要とするときは何時でも、それは、それのタンパレジスタントメモリの暗号化されたコンテンツと暗号化されたコンテンツキーを読み出し、それのマスタデバイスキーを用いて、コンテンツキーを解読し、コンテンツキーを用いて実際のコンテンツを解読することが可能である。

同じ最適化が、装置間のコンテンツ転送のパフォーマンスを向上させるのに利用可能である。２つの装置ＡとＢが同一のドメインの一部であると仮定すると、ＡからＢにコンテンツをセキュアに転送するプロトコルは、以下の通りである。
・ＡとＢは、同一ドメインの一部として互いに認証し、セキュアな通信チャネルを確立する。
・Ａは、セキュアでないチャネルを介し暗号化されたコンテンツをＢに転送する（これは、コンテンツがコンテンツキーにより暗号化されているため安全である）。
・Ａは、セキュアチャネルを介しコンテンツキーをＢに転送する。
・Ｂは、それのマスタデバイスキーによりコンテンツキーを暗号化し、それを以降の利用のためそれの非セキュアなストレージに格納する（暗号化されたコンテンツと共に）。
［装置無効化］
装置がドメインの一部となることを止める３つのケースがある。すなわち、装置がドメインから自発的に除かれるとき（例えば、それが他のドメインに移されるため）、装置がもはや機能しないとき、そして最後に、装置がもはやコンプライアントでないと知られるとき（装置無効化）、である。最後のケースがここで説明される。

もはやコンプライアントでないと知られる装置は、ライセンス機関によって無効にされる。このような装置が特定される機構は、本レポートの範囲外であるが、それらがブラックマーケットで販売されている不法な装置の法的調査に関するものである可能性が最も高い（危険なコンプライアント装置から抽出された暗号化マテリアルを含む不法な装置）。何れのケースにおいても、ライセンス機関は、グローバルデバイスリボケーションリスト（ＧＤＲＬ）を介しこれら危険な装置のＧＤＩを公開する。

デバイスリボケーションリストは、コンテンツプロバイダによってデータコンテンツアイテムと共に配布される。それらは世界中のすべてのコンプライアント装置に関するリボケーション情報を列挙しているため、デバイスリボケーションリストは、大変大きなものとなる可能性がある（１０億個のコンプライアント装置を有し、そのうち１％しか危険でない場合、リボケーションリストのサイズは、４０ＭＢのオーダーとなるであろう）。このため、すべての装置がグローバルリボケーションリストを処理するのに十分なメモリ／計算パワーを有するということは仮定できない。

リボケーション情報はコンテンツに含まれているため、この情報をドメインにもたらすのはコンテンツマネージャとなる。すべてのコンテンツマネージャがリボケーション情報を処理可能であることを要求する。すなわち、コンテンツマネージャが新たなＧＤＲＬを受け取ると、それは以下を実行する。
・それは、それのドメインマネージャが無効にされないことを証明する。ドメインマネージャが無効にされる場合、当該ドメインはもはやコンプライアントではない（ＡＤマネージャがコンプライアンスチェックを適切に行うことがもはや想定できないためである）。
・ＡＤマネージャが無効にされない場合、コンテンツマネージャは、それに接続しようとする。
・ＡＤマネージャが到達可能である場合、コンテンツマネージャはそれをＧＤＲＬに転送する。ＡＤマネージャは、ＧＤＲＬを処理し、後述されるチケットリボケーションリストＴＲＬ）を返す。その後、ＴＲＬはデータコンテンツに含まれる。ＴＲＬがデータコンテンツに付属されると、当該コンテンツは無制限の配布をサポートする。
・ＡＤマネージャが到達可能でない場合、コンテンツマネージャは、元のＧＤＲＬをデータコンテンツに付属させ続ける。しかしながら、この場合、データコンテンツは制限的な配布のみをサポートする。

ＴＲＬが当該ＴＲＬを発行したマネージャを有するドメインの装置部分についてのみ意味があるということを理解することは重要である。データコンテンツが他のドメインに移出される必要がある場合、それはＧＤＲＬであるべきであり、当該コンテンツに付属されるＴＲＬではない。
［チケットリボケーションリストの生成］
ＡＤマネージャは、チケットリボケーションリスト（ＴＲＬ）を生成するためのものである。ＡＤマネージャは、現在ドメインにある装置のＧＤＩのリストを有する。このことは、ＡＤマネージャがすべてのＧＤＩについて、それらがＧＤＲＬに現れるかチェックし、これにより、無効にされたドメイン装置（それらは、ＧＤＲＬに存在する）のＧＤＩのリストを生成することが可能である。このリストは、ＴＲＬである。ドメインにある装置の合計は高々１００のオーダーであるため、ＴＲＬはＧＤＲＬよりもはるかに小さくなることが予想される。

ドメインのすべての装置がＡＤマネージャによって生成されるようなＴＲＬを認証することが可能であるべきである。これを実現するため、ＡＤマネージャは、各ローカルデバイス識別子について（ドメインの各装置及び潜在的な各装置について）、当該ローカルデバイス識別子に関するマスタデバイスキーを用いて認証可能な１つのＴＲＬ認証コードを生成する。

好適な実施例では、ＬＤＩ Ｉについて、ＴＲＬ認証コードは、好ましくは、ＳＨＡ−１暗号ハッシュ関数を用いて、マスタデバイスキーＫ_Ｉを用いたＴＲＬのインターネットＲＦＣ２１０４に規定されるようなキーメッセージ認証コード（ＨＭＡＣ）である。このとき、ＴＲＬは、マスタキーリストのすべてのキーについて、認証コードを追加した無効にされた装置の実際のリストから構成される。

装置が無制限な配布としてマーキングされたデータコンテンツを受け取ると、それはまず、当該コンテンツに関するＴＲＬの真正性をチェックする。これは、まずそれのＬＤＩに対応するＴＲＬ認証コードを求め、それ自身のデバイスマスタキーを用いてＨＭＡＣを計算し、その後、認証コードがリストの計算されたＨＭＡＣと同一であることを検証することによって行われる。
［無制限な配布］
無制限な配布をサポートするコンテンツアイテムは、ドメインの何れか２つのコンプライアント装置間でやりとり可能である。２つのコンプライアント装置ＡとＢを考えると、コンテンツのやりとりのルールは以下の通りである（Ａはコンテンツソースであり、Ｂはデスティネーションであると仮定する）。
・ＡとＢは、上述の認証プロトコルを用いて互いを認証する。認証プロトコルの終わりに得られる共有鍵は、その後、それらのデータのやりとりの残りをセキュアにするのに使用される。
・Ａは、ＧＤＩ_ＢがＴＲＬにないことを検証する。Ｂが無効にされる場合、Ａはそれをコンテンツにわたさない。
・Ａは、ＴＲＬ及びコンテンツに関するアクセスルールと共に、コンテンツアイテムをＢに送信する。
・Ｂは、ＴＲＬの真正性を検証する（前述のように）。すべてに問題がない場合、Ｂは、さらにコンテンツを他のコンプライアント装置に配布することが可能である（もちろん、コンテンツアクセスルールに従って）。
［制限的な配布］
制限的な配布をサポートするコンテンツアイテムは、ソース装置がアイテムに関するＧＤＲＬを処理可能であるときのみやりとりすることが可能である。２つのコンプライアント装置ＡとＢを考えると、コンテンツのやりとりのルールは、以下のようになる（Ａはコンテンツソースであり、Ｂはデスティネーションであると仮定する）。
・Ａは、ＧＤＲＬを処理可能なコンプライアント装置でなければならい。
・ＡとＢは、上述された認証プロトコルを用いて互いを認証する。認証プロトコルの終わりに得られる共有鍵は、その後、それらのデータのやりとりの残りをセキュアにするのに使用される。
・Ａは、ＢのＧＤＩ（Ｂの認証チケットに列挙される）がＧＤＲＬにないことを検証する。Ｂが無効にされる場合、Ａはそれをコンテンツにわたさない。
・Ａは、ＧＤＲＬ及びコンテンツに関するアクセスルールと共に、コンテンツアイテムをＢに送信する。
・ＢがＧＤＲＬを処理可能である場合、それは、ライセンス機関の署名を検証することによって、ＧＤＲＬの真正性を検証する。そうでない場合、Ｂは、コンテンツアイテムをドメインの他の装置にさらに配布することが許可されない。

「制限的な配布」とマーキングされたコンテンツのコピーを保持する装置は、当該コンテンツに対するＴＲＬを取得するため、ＡＤマネージャにコンタクトすることによって、それを「無制限の配布」に変換しようとしてもよい。それが成功すると、それらは、コンテンツに関するＧＤＲＬをＴＲＬと置換し、コンテンツを「無制限」にマーキングする。
［キー更新］
ドメインから多すぎる装置が除かれる場合、ドメインマネージャは、新たな装置に割り当てるマスタキーが最終的に不足するかもしれない。この問題に対する１つの解決策は、ドメインを終了させ、新たなマスタデバイスキーリストにより再開することである。消費者の観点から、これは明らかに受け入れられるものではない。

より許容される選択肢は、取り除かれた装置のＬＤＩを再利用することである。ＬＤＩ_Ａ＝１１の装置Ａを考える。Ａがドメインの一部となるのを止めるとき、それのＧＤＩがドメインのＴＲＬに追加され、Ａのデバイスマスタキーが、マネージャのマスタキーリストの新しいキーと置換される。図３のテーブルでは、これは、単にＭＤＫ「４３２１」を新たなＭＤＫにより上書きすることによって行うことができる。この新たなキーは、その後、ドメインに加入する以降の装置に割り当てられる（これがＣであると仮定する）。このように、ここでＣに対して、Ａに以前に割り当てられていたＬＤＩが割り当てられる（ＬＤＩ_Ｃ＝１１）。通常の装置登録プロトコルと同様に、マネージャは、それのマスタキーリストの他のすべてのマスタキーについて認証証明セットをＣに与える。

チケットがマスタデバイスキーにより暗号化される場合、ここでの問題は、ドメインの他のすべての装置が、Ｃのキーの代わりにＡの古いマスタキーにより暗号化されたチケットを有し、これらのチケットが更新される必要があるということである。これは、例えば、ドメインマネージャに更新されたチケットをすべての装置に送信させ（例えば、ネットワークブロードキャストメッセージとして）、又はこれらの装置に定期的に更新されたチケットについてドメインマネージャを調査させることによって、行うことが可能である。

しかしながら、Ｃ自体を用いて更新を必要とする装置のマスタキーの下で暗号化された上記置換チケットをそれに与えることによって、この更新を行うことが可能である。このため、ＡＤマネージャは、ＣのＬＤＩが以前にＡに割り当てられていたことを検出しなければならない。ここで、ＡＤマネージャは、置換認証チケットセットをＣに発行する。これらの置換チケットは、認証チケットについて通常されるように、Ｃのマスタデバイスキーにより少なくとも部分的に暗号化される。置換チケットによって、他の装置は、Ｃに対してそれ自体を認証することが可能である。さらに、各置換チケットは、自らをＣに対して認証するのにそれを使用可能な装置のマスタデバイスキーにより少なくとも部分的に暗号化される。

認証プロトコルでは、ＣはＡのＬＤＩを再利用しており、ＢはＣをＡと区別することができないため、Ａに対するＢの認証を可能にするそれの（古い）チケットをＣに転送する。Ｃは、このチケットを解読し、これにより認証しようとするが、当該チケットはＡの古いマスタキーにより暗号化されているため、当該処理は失敗する。ここでは、Ｃは、Ｂが更新されていないと認識し、ＢがＣに対して自らを認証するのを可能にする更新されたチケットをそれに転送する。

Ｂは、それのマスタでナイスキーを用いて置換チケットを解読し、これにより、置換チケットが真性であることを知る。その後、Ｂは、それのチケットセットの対応するエントリを置換チケットに置換する。

また、キーＫ_ＢＡは、キーＫ_ＢＣにより更新される必要がある。これを行うため、Ｋ_ＢＣと認証チケット_ＢＣの両方がＫ_Ｂにより暗号化することが可能となり、これにより、それらは安全にＢに送信することが可能となる。

好適な実施例では、認証プロトコルは、以下のように動作する。

（１）Ｃ→Ｂ：ＬＤＩ_Ｃ，Ｎ_Ｃ
（２）Ｂ→Ｃ：ＬＤＩ_Ｂ，Ｎ_Ｂ，認証チケット_ＢＡ
（３）Ｃ→Ｂ：＜Ｋ_ＢＣ，認証チケット_ＢＣ＞Ｋ_Ｂ，＜Ｎ_Ｂ＞ＳＫ，認証チケット_ＣＢ
（４）Ｂ→Ｃ：＜Ｎ_Ｃ＞ＳＫ，認証チケット_ＢＣ
最初の２つのステップは、通常のプロトコルに等しい。Ｃは、Ｂがそれに古いチケットを送信したことを検出した後、ステップ（３）において、ＢにＢのマスタデバイスキーＫ_Ｂにより何れも暗号化された更新されたＫ_ＢＣと認証チケット_ＢＣを送信する。Ｃはまた、いつものように、ＳＫにより暗号化されたチャレンジＮ_Ｂ（上述のように計算された）とそれの認証チケット_ＣＢを送信する。ステップ（４）において、ＢはキーＳＫを用いて、Ｃのチャレンジを暗号化し、それをＣにそれの新たな認証チケットと共に送り返す。これで認証が完了した。
［ドメイン結婚及び離婚］
認証ドメインの「結婚」を２つの認証ドメインが結合することであると定義する。同様に、認証ドメインの「離婚」は、あるドメインが２つの別々のドメインに分割するとき発生する。結婚の場合には、１つの解決策は、１つのドメインのすべての装置を他方のドメインに加入させる（１つずつ）ことである。もちろん、新たに形成されたドメインの装置の合計は、最大許容値以下となることが予想される。この解決策の効果は、第２のドメインからの装置のみが更新される必要があるということである。第１のドメインの装置は、新たに加入する装置とやりとりするのに必要なすべてのキーマテリアル／認証チケットを有する。

離婚の場合、シナリオは、装置セットＳから構成される１つの認証ドメインが、Ｓ＝Ｕ＋Ｖとなるように２つの分離した（ｄｉｓｊｏｉｎｔ）なサブセットに分割されるというものである。新たに生成されたドメインの１つは（例えば、Ｕなど）、元のドメインＳから単にすべての認証キーマテリアルを維持することが可能であるだけである。Ｕのケースで行われる必要がある唯一のことは、Ｖのすべての装置を無効にすることである。

Ｖの場合、新たなドメインを構成するため、Ｖの装置の少なくとも１つは、ドメインマネージャ機能を有する必要がある。Ｖの１つの装置がドメインマネージャとして選択及び初期化されると、他方の装置は、本セクションで前述された装置登録処理を利用して、それを単に登録することができる。

上述の実施例は、本発明を限定するのではなく例示するものであり、当業者は添付された請求項の範囲から逸脱することなく他の多数の実施例を構成することが可能であるということに留意すべきである。ホームネットワークを表すシステム１００は、もちろん、認証ドメインが有用な状況だけでない。

請求項では、括弧内に置かれた任意の参照符号は、請求項を限定するものとして解釈されるべきでない。「有する」という用語は、請求項に列挙した以外の要素又はステップの存在を排除するものではない。要素に先行する「ある」という用語は、そのような要素が複数存在することを排除するものではない。本発明は、複数の異なる要素を有するハードウェアによって、そして適切にプログラムされたコンピュータによって実現可能である。

複数の手段を列挙した装置クレームでは、これらの手段のいくつかは、１つの同一のハードウェアアイテムにより実現可能である。ある手段が互いに異なる従属クレームに記載されているという事実は、これらの手段の組み合わせが効果的に利用可能でないことを示すものではない。

図１は、ネットワークを介し相互接続される装置を有するシステムを概略的に示す。 図２は、ＡＤマネージャ及び装置をより詳細に概略的に示す。 図３は、ローカルデバイス識別子（ＬＤＩ）、マスタデバイスキー（ＭＤＫ）及びグローバルデバイス識別子（ＧＤＩ）がどのように格納することが可能であるかに関する具体例を示す。

Claims (21)

1. 複数の装置を有するネットワークを管理するドメインマネージャ装置であって、
   前記ネットワークに加入する新たな装置に、各々が前記ネットワークを構成する他の各装置との認証された通信を可能にする所定数の対称認証鍵を発行する認証手段を有することを特徴とする装置。
2. 請求項１記載の装置であって、
   前記認証手段は、各々が第１識別子を有する装置が第２識別子を有する装置に対して自らを認証することを可能にする所定数の認証チケットを生成し、前記新たな装置の識別子と一致する第１識別子を有する認証チケットを前記新たな装置に発行するよう構成されることを特徴とする装置。
3. 請求項１記載の装置であって、さらに、
   所定数のマスタデバイスキーを生成するキー管理手段を有し、
   前記認証手段は、前記生成されたマスタデバイスキーの１つを前記新たな装置に発行するよう構成される、
   ことを特徴とする装置。
4. 請求項２及び３記載の装置であって、
   各認証チケットは、前記第２識別子に関する前記所定数からのマスタデバイスキーにより少なくとも部分的に暗号化されることを特徴とする装置。
5. 請求項３記載の装置であって、
   前記キー管理手段は、生成された各マスタデバイスキーを互いに一意的な識別子と関連付け、前記新たな装置に発行されたマスタデバイスキーに関する一意的な識別子を前記新たな装置に装置識別子として割当て、前記新たな装置が前記ネットワークの一部となることを止めると、新たなマスタデバイスキーを生成し、前記新たな装置に前記装置識別子として以前に割り当てられた一意的な識別子と前記生成された新たなマスタデバイスキーを関連付けるよう構成されることを特徴とする装置。
6. 請求項４及び５記載の装置であって、
   前記認証手段は、前記キー管理手段が、前記新たな装置に割り当てられた装置識別子が他の装置に以前に割り当てられたものであると検出すると、置換認証チケットセットを前記新たな装置に発行するよう構成され、
   各置換認証チケットは、第１識別子を有する装置が前記新たな装置に対して自らを認証するのを可能にし、前記第１識別子に関するマスタデバイスキーにより少なくとも部分的に暗号化される、
   ことを特徴とする装置。
7. 請求項３記載の装置であって、
   前記キー管理手段は、いくつかの無効にされた装置を特定するグローバルリボケーションリストを受け取り、前記ネットワークに含まれる前記無効にされた装置を特定するローカルリボケーションリストを生成し、いくつかのリボケーション認証コードを生成するよう構成され、
   各リボケーション認証コードは、前記生成された所定数のマスタデバイスキーからの各マスタデバイスキーを用いて、前記ローカルリボケーションの認証を可能にする、
   ことを特徴とする装置。
8. 請求項７記載の装置であって、
   前記キー管理手段は、各マスタデバイスキーを用いて前記ローカルリボケーションの各キーメッセージ認証コードを計算することによって、各リボケーション認証コードを生成するよう構成されることを特徴とする装置。
9. 請求項１記載の装置であって、
   前記認証鍵の所定数は、前記ネットワークに同時に含まれうる装置の最大数未満又は以上として選択されることを特徴とする装置。
10. 請求項３記載の装置であって、
    前記セットのマスタデバイスキーの個数は、前記ネットワークに同時に含まれうる装置の最大数以上として選択されることを特徴とする装置。
11. 請求項２及び５記載の装置であって、
    前記認証手段は、特定の生成されたマスタデバイスキーに関する特定の識別子について、いくつかの認証チケットを生成するよう構成され、
    生成される各認証チケットは、前記特定の識別子を有する装置が前記生成されたマスタデバイスキーの１つに関する一意的な識別子の他の１つを有する装置に対して自らを認証することを可能にする、
    ことを特徴とする装置。
12. 複数の装置を有するネットワークを介し第２装置と通信するよう構成される第１装置であって、
    前記ネットワークを加入するようドメインマネージャ装置に要求し、各々が前記ネットワークに含まれる他の各装置との認証された通信を可能にする所定数の対称認証鍵を受け付けるネットワーキング手段と、
    前記第２装置との認証された通信を可能にする前記対称認証鍵を用いて前記第２装置と通信する認証手段と、
    を有することを特徴とする装置。
13. 請求項１２記載の第１装置であって、
    前記ネットワーキング手段は、各々が当該第１装置が前記複数の装置からの各装置に対して自らを認証することを可能にする認証チケットセットを前記ドメインマネージャ装置から受け付けるよう構成され、
    前記認証手段は、当該第１装置が前記第２装置に対して自らを認証することを可能にする前記セットからの認証チケットを前記第２装置に配布するよう構成される、
    ことを特徴とする装置。
14. 請求項１３記載の第１装置であって、
    前記ネットワーキング手段は、前記第２装置からさらなる認証チケットを受け付けるよう構成され、
    前記認証手段は、前記受け付けたさらなる認証チケットを有効なものとして受け付けると、前記第２装置を認証するよう構成される、
    ことを特徴とする装置。
15. 請求項１４記載の第１装置であって、
    前記ネットワーキング手段は、前記ドメインマネージャ装置からマスタデバイスキーをさらに受け付けるよう構成され、
    前記認証手段は、前記受け付けたさらなる認証チケットが前記マスタデバイスキーを用いて良好に解読可能である場合、前記受け付けたさらなる認証チケットを有効なものとして受け付けるよう構成される、
    ことを特徴とする装置。
16. 請求項１４又は１５記載の第１装置であって、
    前記認証手段は、前記配布されたチケットと前記受け付けたさらなる認証チケットに含まれる情報からセッションキーを導くよう構成されることを特徴とする装置。
17. 請求項１５記載の第１装置であって、
    前記さらなる認証チケットは解読され、
    前記認証手段は、前記マスタデバイスキーにより前記さらなる認証チケットを解読することに失敗すると、前記第２装置が当該第１装置に対して自らを認証することを可能にする新たな認証チケットを前記第２装置に配布するよう構成され、
    前記新たな認証チケットは、前記第２装置のマスタデバイスキーにより少なくとも部分的に暗号化される、
    ことを特徴とする装置。
18. 請求項１５記載の第１装置であって、
    前記認証手段は、当該第１装置が前記第２装置に対して自らを認証することを可能にする当該第１装置のマスタデバイスキーにより少なくとも部分的に暗号化される新たなチケットを前記第２装置から受け付け、前記新たなチケットを前記マスタデバイスキーにより解読し、前記新たなチケットの解読に成功すると、当該第１装置が前記新たなチケットにより前記第２装置に対して自らを認証することを可能にする前記セットからのチケットを置換するよう構成されることを特徴とする装置。
19. 請求項１５記載の第１装置であって、
    前記ネットワーキング手段は、前記ネットワークに含まれる無効にされた装置を特定するローカルリボケーションリストと、各々が各マスタデバイスキーを用いて前記ローカルリボケーションの認証を可能にするいくつかのリボケーション認証コードとを受け付けるよう構成され、
    前記認証手段は、前記受け付けたリボケーション認証コードの１つが、前記マスタデバイスキーを用いて良好に解読可能である場合、前記ローカルリボケーションリストを有効なものとして受け付けるよう構成される、
    ことを特徴とする装置。
20. 請求項１記載の装置として装置を動作させるよう構成されるコンピュータプログラム。
21. 請求項１２記載の装置として装置を動作させるよう構成されるコンピュータプログラム。

Images