JP5297529B2 - 認証システム - Google Patents

Description

本発明は、情報通信網に端末として接続されるノードが他のノードによるサービスを享受するにあたり、サービスが他者に利用されることのないように他のノードと安全に通信することが可能となるようにサービスに関連付けて認証を行う認証システムに関する。

一般に、インターネットやホームネットワークのような情報通信網に端末として接続されるノード（ノードの一部機能でもよい）において、他のノード（ノードの一部機能でもよい）が提供するサービスを享受する場合には、他者にサービスが利用されるのを防止するために、サービスの提供側のノードと享受側のノードとの通信内容を暗号化している。

また、通信を暗号化する暗号鍵には、サービスの提供側と享受側とのノードに配布した共通のセッション鍵を用いることが考えられている。この種のセッション鍵を各ノードに配布するにあたっては、他者に知られないように安全に配送することが要求される。

この種の要求を満たすために、信頼された第三者機関により共有鍵暗号方式による認証を行うことによって、セッション鍵を配布する認証システムが提案されている。この種の認証方法としては、たとえば、クリプトナイト（KryptoKnight）が知られている（たとえば、特許第３０７８８４１号公報参照）。

この種の認証方法では、通信の開始者であるノードと通信の応答者であるノードとに共通のセッション鍵を配布するにあたり、第三者機関である認証手段においてセッション鍵を生成し、各ノードごとに規定した秘密鍵を用いてセッション鍵を含む暗号文を生成することにより、セッション鍵を各ノードに対して安全に配布することを可能にしている。すなわち、認証手段が生成したセッション鍵を、各ノードの持つ秘密鍵によってしか開封できない暗号文として各ノードに送信することにより、各ノードに共通のセッション鍵を各ノードごとに安全に配布することが可能になっている。

認証方法には、プッシュシナリオとプルシナリオとがある。プッシュシナリオでは、開始者となるノードが、開始者のノードと応答者のノードとのセッション鍵を含む暗号文を認証手段から受け取って、開始者のノードに宛てたセッション鍵を復号し、認証手段から受け取った応答者のノードへの暗号文を応答者のノードに転送する。また、プルシナリオでは、開始者のノードが応答者のノードを介して認証手段にセッション鍵の配布を要求すると、応答者のノードがセッション鍵を含む暗号文を認証手段から受け取って、応答者のノードに宛てた暗号文を復号し、認証手段から受け取った開始者への暗号文を開始者のノードに転送する。

ところで、共有鍵暗号方式で認証を行う場合に、認証手段にはノードと共通の秘密鍵が何らかの方法で登録される。秘密鍵はノードごとに登録されるから、認証手段では、ノードごとの秘密鍵を用いてセッション鍵を含む暗号文を各ノードに送信することにより、ノードごとにセッション鍵を配布することが可能になる。すなわち、複数のノードに共通のセッション鍵が配布されるから、セッション鍵を用いて暗号化した暗号文を用いてノード間で安全に通信することができる。ただし、認証手段には、各ノードに対応する秘密鍵が１個ずつしか登録されないから、情報通信網内にドメインを１個しか形成することができない。

ここで、ノードが参加するドメインごとに異なるサービスを提供可能とし、１台のノードが享受するサービスを変更可能とするには、ドメインごとに認証手段を設けることが必要であり、またノードにはドメインごとに用いる複数個の秘密鍵が必要になる。したがって、ノードが享受しようとするサービスを変更可能にするには複数の認証手段を設けることが必要であり、しかも、ノードは享受しようとするサービスに応じた認証手段を選択するとともに、選択した認証手段により認証を受けてセッション鍵を取得することが必要である。

すなわち、ノードは享受しようとするサービスごとに秘密鍵を選択するとともに、当該秘密鍵を用いて認証を受けるための認証手段にアクセスすることが必要であるから、サービスの変更に非常に手間がかかるという問題がある。言い換えると、ノードが享受するサービスを変更するには秘密鍵および認証手段を選択しなければならず、ノードの利用者にとって各ノードでセッション鍵を取得する際の手順が複雑になるという問題がある。

本発明は上記事由に鑑みて為されたものであり、その目的は、サービスの内容に応じてノードが通信する範囲であるドメインを規定し、しかもノードが享受するサービスを変更するにあたって、各ドメインで用いるセッション鍵を各ノードが容易に取得できるようにした認証システムを提供することにある。

本発明に係る認証システムは、利用者が利用する利用者ノードと、所属するドメインに対応するサービスを提供する複数のサービスノードと、認証用データベース記憶ユニットと、認証ユニットと、ユーザ情報データベース記憶ユニットと、鍵配布ユニットと、を備える。上記認証用データベース記憶ユニットは、上記利用者ノードの秘密鍵が上記ドメインごとに予め登録された認証用データベースを記憶するように構成される。上記利用者ノードの秘密鍵は上記ドメイン毎に互いに異なっている。上記ユーザ情報データベース記憶ユニットは、上記利用者ノードに上記ドメインを関連付けるアカウントが登録されるユーザ情報データベースを記憶するように構成される。上記利用者ノードは、上記利用者ノードが所属している現在のドメインから上記利用者ノードが所属を希望する希望ドメインへの変更を要求するにあたって、ドメイン変更要求を上記鍵配布ユニットに上記情報通信網を通じて送信するように構成される。上記鍵配布ユニットは、上記利用者ノードから上記ドメイン変更要求を受け取った場合に、上記ユーザ情報データベースに上記利用者ノードに上記希望ドメインを関連付ける上記アカウントが登録されていれば、上記認証用データベースを利用して、上記希望ドメインに対応する上記利用者ノードの上記秘密鍵を取得して上記利用者ノードに上記情報通信網を通じて送信するように構成される。上記認証ユニットは、上記利用者ノードが上記希望ドメインに対応する上記秘密鍵を取得した後に、上記希望ドメインにおいて上記利用者ノードと上記希望ドメインに属する上記サービスノードとの間の暗号化通信に用いられるセッション鍵を発行し、上記発行されたセッション鍵を上記希望ドメインに対応する上記秘密鍵で暗号化して上記情報通信網を通じて上記利用者ノードに送信するように構成される。

好ましい形態では、上記ユーザ情報データベース記憶ユニットに接続された登録ユニットを備え、上記登録ユニットは、上記利用者が操作する入力装置の操作により上記アカウントを上記ユーザ情報データベースに登録するように構成される。

より好ましい形態では、上記複数のサービスノードのうちの連携サービスノードは、上記利用者ノードと連携して動作するサービスを提供するように構成される。上記登録手段は、上記利用者ノードと上記連携サービスノードとの組を上記入力装置の操作によりグループとして上記ユーザ情報データベースに登録する機能を有する。上記鍵配布ユニットは、上記利用者ノードから上記ドメイン変更要求を受け取った場合に、上記ユーザ情報データベースに上記利用者ノードと上記希望ドメインとを関連付ける上記アカウントが登録されており、かつ、上記利用者ノードと上記希望ドメインに属する上記連携サービスノードとの組が上記ユーザ情報データベースに上記グループとして登録されていれば、上記認証用データベース記憶手段に記憶された上記認証用データベースを利用して、上記希望ドメインに対応する上記利用者ノードの上記秘密鍵を取得して上記利用者ノードに上記情報通信網を通じて送信するように構成される。

好ましい形態では、上記鍵配布ユニットは、上記ドメイン変更要求に応じて上記希望ドメインに対応する上記秘密鍵を上記利用者ノードに送信した後に、上記利用者ノードから確認応答を受け取ると、上記現在ドメインに対応する上記秘密鍵を上記認証用データベースから削除するように構成される。

好ましい形態では、上記利用者ノードは、上記認証ユニットから現在の上記ドメインに対応する上記セッション鍵を取得できなくなると、上記利用者ノードが所属している上記ドメインごとにあらかじめ定められた順番で他の上記ドメインに対応する上記セッション鍵を要求するように構成される。

好ましい形態では、上記サービスノードは複数種類のサービスを提供するように構成され、上記認証用データベースには、上記各サービスノードが提供するサービスごとにアクセス制限を行うためのアクセス制限情報が登録され、上記認証ユニットは、上記利用者ノードおよび上記サービスノードに上記セッション鍵を配布する際に上記アクセス制限情報を上記利用者ノードおよび上記サービスノードに設定するように構成される。

本発明に用いるシステムの構成例を示す構成図である。 同上におけるセッション鍵の配布手順を示す動作説明図である。 同上に用いる３者間の鍵配布プロトコルの例を示す動作説明図である。 同上におけるドメインの変更手順を示す動作説明図である。 同上におけるセッション鍵の配布手順を示す動作説明図である。 同上におけるドメインの変更手順を示す動作説明図である。 同上におけるドメインの変更手順を示す動作説明図である。 同上のシステムのサーバの構成例を示す構成図である。

以下に説明する実施形態では、情報通信網に複数のドメインを設け、利用者が管理するノードの所属するドメインを利用者自身によって変更できる構成を示す。ノードは、認証手段からドメインに対応するセッション鍵が配布されることにより、所属するドメインが決められる。

図１に示すように、ここでは、３個のドメインＤを設けた場合について説明する。なお、必要に応じて３個のドメインＤを符号Ｄ１，Ｄ２，Ｄ３で区別する。ただし、ドメインＤの個数は２個でもよく、また４個以上のドメインＤを設ける場合もある。また、図示例では、４個のノードＮを示しているが、ノードの個数に制限はない。なお、必要に応じて４個のノードＮを符号Ｎ０，Ｎ１，Ｎ２，Ｎ３で区別する。

図示例において、ノードＮ０〜Ｎ３のうち、ノードＮ０は以下の説明において着目しているノードであって、ホームネットワークシステムにおける機器を想定している。すなわち、ノードＮ０は利用者が利用する。このようにノードＮ０は利用者が利用する利用者ノードＮｕである。

一方、ノードＮ１はドメインＤ１に、ノードＮ２はドメインＤ２に、ノードＮ３はドメインＤ３に、それぞれ属するノードを示している。ノードＮ１，Ｎ２は、ホームネットワークシステムにおいて利用されるサーバであって、宅内に配置される宅内サーバ、機器の製造者や管理者が利用するサーバなどを想定している。したがって、ノードＮ１，Ｎ２は、所属する各ドメインＤ１，Ｄ２においてノードＮ０にサービスを提供する。また、ノードＮ３は、ドメインＤ３においてノードＮ０と連携して動作する。ノードＮ３がノードＮ０と連携する動作は、ノードＮ３がノードＮ０に対して提供するサービスとみなすことができる。このように、ノードＮ１〜Ｎ３は、サービスを提供するノード（サービスノード）Ｎｓである。各ノードＮ１〜Ｎ３は、１種類のサービスを提供するだけではなく、複数種類のサービスを提供してもよい。

各ノードＮ０〜Ｎ３は、インターネット網や宅内網のような情報通信網ＮＴに接続されている。ノードＮ０は識別子ＩＤ０を、ノードＮ１は識別子ＩＤ１を、ノードＮ２は識別子ＩＤ２を、ノードＮ３は識別子ＩＤ３を、それぞれ有する。いずれかの識別子ＩＤ０〜ＩＤ３を用いることで、ノードＮを特定できる。また、各ノードＮ０〜Ｎ３は、情報通信網ＮＴを介してサーバＳ１と通信するように構成されている。

サーバＳ１は、ノードＮ０がノードＮ１〜Ｎ３の提供するサービスを享受するために、ノードＮ０とノードＮ１〜Ｎ３との関連付けを行う機能を有する。サーバＳ１の具体的な機能は後述する。

以下では、情報通信網ＮＴにおいて何らかの機能を有する単位を「オブジェクト」として扱う。本実施形態におけるオブジェクトの種別（クラス）には、ノードＮ０の利用者と、利用者に提供するサービスと、利用者とサービスとの関係を管理するホスト（サーバＳ１）とがある。

ノードＮ０の利用者はノードＮ０の識別子で他のノードの利用者と区別される。ノードＮ０の識別子ＩＤ０とノードＮ０が属するドメインＤとの組み合わせをサーバＳ１に認証させることによって、ノードＮ０の所属するドメインＤが決定される。さらに、後述するように、各ノードＮ１〜Ｎ３が提供するサービスに識別子（サービス識別子）が付与される。サービス識別子とドメインＤとの組み合わせをサーバＳ１に認証させることによって、ノードＮ０の享受するサービスが決定される。

本実施形態では、ノードＮ０が所望のノードＮｓの提供するサービスを享受するためには、ノードＮ０が所望のノードＮｓと共通のセッション鍵を持つ必要がある。セッション鍵は、サーバＳ１に設けられた認証手段（認証サーバ）ＡＭからノードＮ０に提供される。ノードＮ０が、所望のノードＮｓとセッション鍵を用いて暗号化した通信を行うことにより通信を安全（セキュア）に行うことが可能になっている。なお、必要に応じて３個の認証手段ＡＭを符号ＡＭ１〜ＡＭ３で区別する。

認証手段ＡＭ１はドメインＤ１に、認証手段ＡＭ２はドメインＤ２に、認証手段ＡＭ３はドメインＤ３にそれぞれ対応付けられている。よって、認証手段ＡＭ１はドメインＤ１のセッション鍵を発行し、認証手段ＡＭ２はドメインＤ２のセッション鍵を発行し、認証手段ＡＭ３はドメインＤ３のセッション鍵を発行する。セッション鍵は、セッション鍵を発行した認証手段ＡＭに対応付けられたドメインＤでのみ有効になる。よって、ノードＮにセッション鍵を配布することによって、ノードＮ０の所属するドメインＤを決めることができる。

サーバＳ１は、認証手段ＡＭ１〜ＡＭ３に加えて、各ドメインＤ１〜Ｄ３に属しているノードＮ０〜Ｎ３の識別子ＩＤ０〜ＩＤ３および各ノードＮ０〜Ｎ３が各ドメインＤ１〜Ｄ３で使用する秘密鍵とが対応付けて登録される認証用データベースＤＢ１〜ＤＢ３と、ノードＮ０〜Ｎ３と共有する秘密鍵をノードＮ０に配布するプロキシサービスとしての鍵配布手段ＫＤ１とを備える。

すなわち、サーバＳ１は、図８に示すように、認証手段ＡＭ１〜ＡＭ３に加えて、３つの認証用データベース記憶手段ＤＳと、鍵配布手段（鍵配布ユニット）ＫＤ１と、を備える。なお、必要に応じて３つの認証用データベース記憶手段ＤＳを符号ＤＳ１，ＤＳ２，ＤＳ３で区別する。

認証用データベース記憶手段ＤＳ１は、ドメインＤ１に対応する認証用データベース（第１認証用データベース）ＤＢ１を記憶するように構成される。第１認証用データベースＤＢ１には、ノードＮ０の識別子ＩＤ０とノードＮ０がドメインＤ１で使用する秘密鍵とが対応付けて登録されている。また、第１認証用データベースＤＢ１には、ノードＮ１の識別子ＩＤ１とノードＮ１がドメインＤ１で使用する秘密鍵とが対応付けて登録されている。

認証用データベース記憶手段ＤＳ２は、ドメインＤ２に対応する認証用データベース（第２認証用データベース）ＤＢ２を記憶するように構成される。第２認証用データベースＤＢ２には、ノードＮ０の識別子ＩＤ０とノードＮ０がドメインＤ２で使用する秘密鍵とが対応付けて登録されている。また、第２認証用データベースＤＢ２には、ノードＮ２の識別子ＩＤ２とノードＮ２がドメインＤ２で使用する秘密鍵とが対応付けて登録されている。

認証用データベース記憶手段ＤＳ３は、ドメインＤ３に対応する認証用データベース（第３認証用データベース）ＤＢ３を記憶するように構成される。第３認証用データベースＤＢ３には、ノードＮ０の識別子ＩＤ０とノードＮ０がドメインＤ３で使用する秘密鍵とが対応付けて登録されている。また、第３認証用データベースＤＢ３には、ノードＮ３の識別子ＩＤ３とノードＮ３がドメインＤ３で使用する秘密鍵とが対応付けて登録されている。

本実施形態において、３つの認証用データベース記憶手段ＤＳは、認証用データベース記憶ユニットを構成している。認証用データベース記憶ユニットは、第１〜第３認証用データベースＤＢ１〜ＤＢ３よりなる認証用データベースＤＢを記憶しており、この認証用データベースＤＢには、ノードＮ０の秘密鍵がドメインＤごとに予め登録されている。

鍵配布手段ＫＤ１は、ノードＮ０〜Ｎ３と共有する秘密鍵をノードＮ０に配布するプロキシサービスを行うように構成されている。

このように本実施形態では、認証用データベースＤＢにおいて、１台のノードＮ０にドメインＤ毎に異なる秘密鍵が対応付けられている。さらに、ドメインＤ２についてはノードＮ０に対して異なる２個の秘密鍵が対応付けられている。後述する具体例で言えば、ノードＮ０に関して、第１認証用データベースＤＢ１には秘密鍵Ｋ０−１が、第２認証用データベースＤＢ２には秘密鍵Ｋ０−２１，Ｋ０−２２、第３認証用データベースＤＢ３には秘密鍵Ｋ０−３が、それぞれあらかじめ登録される。Ｋ０−Ｎは、ノードＮ０の秘密鍵を示す。ここで、「−Ｎ」が異なることは秘密鍵が異なることを意味する。すなわち、ノードＮ０には４種類の秘密鍵Ｋ０−１，Ｋ０−２１，Ｋ０−２２，Ｋ０−３が対応付けられている。ノードＮ０の状態（ノードＮ０が所属しているドメインＤ）によりいずれか１種類の秘密鍵が用いられる。

上述の秘密鍵は、ノードＮの製造者などにより事前に認証用データベースＤＢ（ＤＢ１〜ＤＢ３）に登録される。サーバＳ１では、認証手段ＡＭ１が第１認証用データベースＤＢ１を、認証手段ＡＭ２が第２認証用データベースＤＢ２を、認証手段ＡＭ３が第３認証用データベースＤＢ３を、それぞれ参照可能になっている。また、鍵配布手段ＫＤ１はすべての認証用データベースＤＢを参照可能になっている。さらに、サーバＳ１は、ユーザ情報データベース記憶手段（ユーザ情報データベース記憶ユニット）ＤＳｕと、登録手段（登録ユニット）ＲＧ１とを備えている。

記認証手段（認証ユニット）ＡＭは、セッション鍵生成モジュール１０と、秘密鍵取得モジュール１１と、暗号化モジュール１２と、セッション鍵送信モジュール１３と、を備えている。

セッション鍵生成モジュール１０は、利用者ノードＮｕ、または、利用者ノードＮｕにサービスを提供するサービスノードＮｓである特定サービスノードＮｓから情報通信網ＮＴを通じてセッション鍵配布要求を受け取ると、利用者ノードＮｕと特定サービスノードＮｓとの間の暗号化通信に用いられるセッション鍵を生成するように構成される。

秘密鍵取得モジュール１１は、セッション鍵配布要求を受け取ると、認証用データベース記憶ユニットに記憶された認証用データベースＤＢを参照して、特定サービスノードＮｓが属するドメインＤに対応する利用者ノードＮｕの秘密鍵（第１秘密鍵）を取得するとともに、特定サービスノードＮｓの秘密鍵（第２秘密鍵）を取得するように構成される。

暗号化モジュール１２は、セッション鍵生成モジュール１０が生成したセッション鍵を秘密鍵取得モジュール１１が取得した利用者ノードＮｕの第１秘密鍵を使用して暗号化して利用者用暗号メッセージを作成するとともに、セッション鍵生成モジュール１０が生成したセッション鍵を秘密鍵取得モジュール１１が取得した特定サービスノードＮｓの第２秘密鍵を使用して暗号化してサービス用暗号メッセージを作成するように構成される。

セッション鍵送信モジュール１３は、暗号化モジュール１２が作成した利用者用暗号メッセージを利用者ノードＮｕに情報通信網ＮＴを通じて送信するとともに、暗号化モジュール１２が作成したサービス用暗号メッセージを特定サービスノードＮｓに情報通信網ＮＴを通じて送信するように構成される。

利用者ノードＮｕは、利用者ノードＮｕが所属している現在のドメインＤに対応する第１秘密鍵を記憶している。利用者ノードＮｕは、認証手段ＡＭのセッション鍵送信モジュール１３から利用者用暗号メッセージを受け取ると、利用者ノードＮｕが記憶している第１秘密鍵を利用して利用者暗号メッセージを復号するように構成される。これによって、利用者ノードＮｕは、認証手段ＡＭからセッション鍵を取得する。

サービスノードＮｓは、サービスノードＮｓが所属しているドメインＤに対応する第２秘密鍵を記憶している。サービスノードＮｓは、認証手段ＡＭのセッション鍵送信モジュール１３からサービス用暗号メッセージを受け取ると、サービスノードＮｓが記憶している第２秘密鍵を利用して利用者暗号メッセージを復号するように構成される。これによって、サービスノードＮｓは、認証手段ＡＭからセッション鍵を取得する。なお、各サービスノードＮｓの第２秘密鍵は互いに異なる。

このように、利用者ノードＮｕがサービスノードＮｓと同じセッション鍵を取得できることは、利用者ノードＮｕがサービスノードＮｓと同じドメインＤに所属しているということを意味する。

ユーザ情報データベース記憶ユニットＤＳｕは、利用者ノードＮｕとドメインＤとを関連付けるアカウントが登録されるユーザ情報データベースＤＢｕを記憶するように構成される。

利用者ノードＮｕは、利用者ノードＮｕが所属している現在のドメインＤ（例えばドメインＤ１）から利用者ノードＮｕが所属を希望する希望ドメインＤ（例えばドメインＤ２）への変更を要求するにあたって、希望ドメインＤを示すドメイン変更要求を鍵配布手段ＫＤ１に情報通信網ＮＴを通じて送信するように構成される。

鍵配布手段ＫＤ１は、アカウント確認モジュール２０と、秘密鍵要求モジュール２１と、秘密鍵送信モジュール２２と、を備える。

アカウント確認モジュール２０は、ドメイン変更要求を受け取ると、ユーザ情報データベースＤＳｕに、利用者ノードＮｕと希望ドメインＤとを関連付けるアカウントが登録されているか否かを判断するように構成される。

秘密鍵要求モジュール２１は、アカウント確認モジュール２０がユーザ情報データベースＤＢｕに利用者ノードＮｕと希望ドメインＤとを関連付けるアカウントが登録されていると判断すると、認証用データベース記憶手段に記憶された認証用データベースＤＢを利用して、希望ドメインＤに対応する利用者ノードＮｕの第１秘密鍵を取得するように構成される。

秘密鍵送信モジュール２２は、秘密鍵要求モジュール２１が取得した利用者ノードＮｕの第１秘密鍵を利用者ノードＮｕに情報通信網ＮＴを通じて送信するように構成される。

利用者ノードＮｕは、鍵配布手段ＫＤ１の秘密鍵送信モジュール２２から第１秘密鍵を受け取ると、受け取った第１秘密鍵を現在のドメインＤに対応する第１秘密鍵として記憶するように構成される。

利用者ノードＮｕは、鍵配布手段ＫＤ１にドメイン変更要求を送信することによって、鍵配布手段ＫＤ１から希望ドメインＤに対応する第１秘密鍵を取得できる。その結果、利用者ノードＮｕは、希望ドメインＤに属するサービスノードＮｓと同じセッション鍵を認証手段ＡＭから受け取ることができるようになる。

本実施形態では、ノードＮ０の享受するサービスがドメインＤ１〜Ｄ３ごとに異なっている。また、ノードＮ０は、ドメインＤ１、ドメインＤ２、ドメインＤ３の順でより高次のサービスを享受できる。各ドメインＤ１〜Ｄ３のサービスは個々に独立している。基本的にはノードＮ０が属するドメインＤに応じてノードＮ０が享受可能なサービスは異なる。ただし、ドメインＤ１〜Ｄ３が階層化されている場合には、ノードＮ０が最上位のドメインＤ３に属していると、ノードＮ０は、ドメインＤ３におけるサービスだけではなく、ドメインＤ１，Ｄ２におけるサービスも享受することができるようにしてもよい。また、ノードＮ０がドメインＤ２に属していると、ノードＮ０は、ドメインＤ１，Ｄ２の両方のサービスを享受可能になるようにしてもよい。すなわち、ノードＮ０が属しているドメインＤを基準のドメインとしてノードＮ０が高次のサービスを享受し、必要に応じて、ノードＮ０が一時的に下位のドメインＤに属する状態に切り換えることでノードＮ０が低次のサービスを享受することを可能にしてもよい。

本実施形態では、ノードＮ０がドメインＤに属することにより享受できるサービスを以下のように規定する。すなわち、ノードＮ０がドメインＤ１に属していると、ノードＮ０はファームウェアアップデートのような最小限のサービスを享受することができる。また、ノードＮ０がドメインＤ２に属していると、ノードＮ０は対価との引き替えに機能拡張のサービスを受けることができる。このドメインＤ２におけるサービスでは、ノードＮ０に新たな機能を付加するためのプログラムが提供される。ドメインＤ１，Ｄ２におけるサービスは、ノードＮ０が単独で動作するためのサービスであるが、ドメインＤ３では、ノードＮ０は他のノードとグループを形成するサービスを享受することができる。すなわち、ノードＮ０は、グループ内のノードと連携することが可能になる。

１．利用者を制限しない場合
初期状態として、ノードＮ０が工場出荷後に情報通信網ＮＴに接続された状態を想定する。ノードＮ０は情報通信網ＮＴに接続されて起動されると情報通信網ＮＴに参加を通知する。ノードＮ０の参加はサーバＳ１に通知され、サーバＳ１の第１認証用データベースＤＢ１に登録される。

ノードＮ１において、他のノード（図示例では、ノードＮ０）のファームウェアのアップデートを無償で行う必要が生じたときには、ノードＮ０との間でセキュアに通信を行うことができるように、サーバＳ１に対して、ノードＮ０との間で用いるセッション鍵の配布を要求する。言い換えると、共通のセッション鍵をサーバＳ１から受け取ることによりノードＮ０，Ｎ１は同じドメインＤ１に属することになる。ドメインＤ１で用いるセッション鍵は、以下の手順で配布される。

ここでは、何らかの方法によって、ノードＮ０についてファームウェアのアップデートが必要であることをノードＮ１が認識したとする。たとえば、ノードＮ０がノードＮ１に対して、定期的（１ヶ月に１回、１年に１回など）に、ファームウェアのアップデータの有無を問い合わせれば、ノードＮ１では、ノードＮ０のファームウェアのアップデートの要否を認識することができる。

ノードＮ１がノードＮ０のファームウェアのアップデートを行うときには、まず、図２に示すように、ノードＮ１がノードＮ０にサービスの提供を通知し（Ｐ１００）、これによって、ノードＮ０は、サーバＳ１にセッション鍵の配布を要求するためにセッション鍵配布要求をサーバＳ１に送信する（Ｐ１０１）。サーバＳ１では、認証手段ＡＭ１がノードＮ０からのセッション鍵配布要求を受け取り、第１認証用データベースＤＢ１を参照してノードＮ０の識別子ＩＤ０に対応する秘密鍵を取得する。すなわち、認証手段ＡＭ１は、ノードＮ０の識別子１Ｄ０を第１認証用データベースＤＢ１に照合する（Ｐ１０２，Ｐ１０３）。

第１認証用データベースＤＢ１には、ドメインＤ１に属するノードＮ０，Ｎ１の識別子ＩＤ０，ＩＤ１とともに、ノードＮ０の秘密鍵（第１秘密鍵）Ｋ０−１およびノードＮ１の秘密鍵（第２秘密鍵）Ｋ１が事前（工場出荷時など）に登録されている。認証手段ＡＭ１は、秘密鍵Ｋ０−１，Ｋ１と識別子ＩＤ０，ＩＤ１とを用い、クリプトナイト（KryptoKnight）あるいはケルベロス（Kerberos）のような周知の３者間の鍵配布プロトコルによりセッション鍵をノードＮ０，Ｎ１に配布する（Ｐ１０４，Ｐ１０５）。なお、以下の説明においても、とくに説明しないが、３者間の鍵配布プロトコルには、クリプトナイトやケルベロスのような周知のプロトコルが用いられる。

以下に説明する動作例では、第１認証用データベースＤＢ１にはノードＮ０に対応する秘密鍵（第１秘密鍵）Ｋ０−１およびノードＮ１に対応する秘密鍵（第２秘密鍵）Ｋ１が、第２認証用データベースＤＢ２にはノードＮ０に対応する２つの秘密鍵（第１秘密鍵）Ｋ０−２１，Ｋ０−２２およびノードＮ２に対応する秘密鍵（第２秘密鍵）Ｋ２が、第３認証用データベースＤＢ３にはノードＮ０に対応する秘密鍵（第１秘密鍵）Ｋ０−３およびノードＮ３に対応する秘密鍵（第２秘密鍵）Ｋ３が、それぞれ事前に登録されている。

なお、秘密鍵Ｋ０−２１は、ノードＮ０の所属するドメインＤがドメイン（下位ドメイン）Ｄ１からドメイン（上位ドメイン）Ｄ２に変更された場合に、ノードＮ０に配布される。一方、秘密鍵Ｋ０−２２は、ノードＮ０の所属するドメインＤがドメイン（上位ドメイン）Ｄ３からドメイン（下位ドメイン）Ｄ２に変更された場合に、ノードＮ０に配布される。

上述のように、ノードＮ１がノードＮ０を介してサーバＳ１にセッション鍵の配布を要求すると、ノードＮ０，Ｎ１に共通のセッション鍵が配布される。これによって、ノードＮ０はノードＮ１と同じドメインＤ１に含まれ（セキュアグループＳＧ１を形成し）、互いに通信することが可能になる。すなわち、ノードＮ０はドメインＤ１において提供されるサービス（ここでは、ファームウェアのアップデート）を享受することが可能になる。

上述した３者間鍵配布プロトコルでは、ノードＮ０がノードＮ１へのセッション鍵をサーバＳ１から受け取ると（Ｐ１０４）、ノードＮ０はセッション鍵をノードＮ１に引き渡す（Ｐ１０５）。上述の３者間鍵配布プロトコルでは、手順Ｐ１０５の後に、ノードＮ０，Ｎ１に同じセッション鍵が設定されたことを確認する手順を含めてもよい（Ｐ１０６）。手順Ｐ１０６はオプションであるから省略してもよい。

以下に、３者間の鍵配布プロトコル（３ＰＫＤＰ＝3 Party Key Distribution Protocol）について簡単に説明する。この鍵配布プロトコルでは、通信の開始者となるノードと通信の応答者となるノードとの一方が他方のデータを中継して認証手段と通信する。これによって、認証手段が生成したセッション鍵を両ノードで共有することができる。３ＰＫＤＰにおいては、開始者のノードと応答者のノードとのどちらが認証手段と通信するかに応じてプッシュシナリオとプルシナリオとが考えられている。

プッシュシナリオでは、開始者のノードが、応答者のノードと通信した後に認証手段と通信する。これによって、開始者のノードが、認証手段から開始者のノードに宛てた暗号文と応答者のノードに宛てた暗号文とを受け取る。そして、開始者のノードが、開始者のノードに宛てた暗号文からセッション鍵を取得するとともに、応答者のノードに宛てた暗号文を応答者のノードに引き渡す。これによって、応答者のノードがセッション鍵を取得する。

一方、プルシナリオでは、開始者のノードが応答者のノードと通信すると、応答者のノードが、認証手段と通信する。これによって、応答者のノードが、認証手段から開始者のノードに宛てた暗号文と応答者のノードに宛てた暗号文とを受け取る。そして、応答者のノードが、応答者のノードに宛てた暗号文からセッション鍵を取得するとともに、開始者のノードに宛てた暗号文を開始者のノードに引き渡す。これによって、開始者のノードがセッション鍵を取得する。

上述した動作例では、通信の開始者がノードＮ１であり、通信の応答者がノードＮ０であり、ノードＮ０が認証手段ＡＭ１にセッション鍵の配布を要求している。よって、上述した動作例は、プルシナリオである。しかしながら、本実施形態では、ノードＮ０が通信の開始者となって認証手段ＡＭ１と通信するプッシュシナリオを採用してもよい。

プッシュシナリオとプルシナリオとのいずれのプロトコルを用いるかにかかわらず、セッション鍵を含む暗号文の正真性（改竄されていないこと）を保証するために、暗号文にはＭＡＣ値が付加される。また、認証手段からノードに宛てた暗号文は、認証手段と各ノードとにおいて事前に登録されている秘密鍵を用いて暗号化および復号化される。また、認証手段では、ノードで生成されたノンスとセッション鍵とノードの識別情報とをメッセージとし秘密鍵を用いてＭＡＣ値を算出し、ノードに宛ててセッション鍵とＭＡＣ値を含めて暗号化した暗号文を送信する。

プルシナリオの一例を図３に示す。図示例では、ノードＡ（上述の動作例ではノードＮ１）が開始者であり、ノードＢ（上述の動作例ではノードＮ０）が応答者になる。ここで、ノードＡは、認証手段ＡＭと共通の秘密鍵（共通鍵）Ｋａ（上述の動作例では秘密鍵Ｋ１）を事前に保有しており、ノードＢは、認証手段ＡＭと共通の秘密鍵（共通鍵）Ｋｂ（上述の動作例では秘密鍵Ｋ２）を事前に保有している。

ノードＡは、ノンスＮａを生成し、ノードＡの識別情報ＩＤａとともに、生成したノンスＮａを送信する（Ｐ１）。ノードＡから識別情報ＩＤａとノンスＮａとを受け取ったノードＢは、ノンスＮｂを生成し、ノードＡから受け取った識別情報ＩＤａとノンスＮａとに加えて、ノードＢの識別情報ＩＤｂとノンスＮｂとを含むセッション鍵配布要求を認証手段ＡＭに送信する（Ｐ２）。

認証手段ＡＭ（セッション鍵生成モジュール１０）は、セッション鍵配布要求（識別情報ＩＤａ，ＩＤｂおよびノンスＮａ，Ｎｂ）をノードＢから受け取ると、セッション鍵Ｋｓを生成する。また、認証手段ＡＭ（秘密鍵取得モジュール１１）は、認証用データベースＤＢからノードＡと共通の秘密鍵Ｋａを取得する。認証手段ＡＭ（暗号化モジュール１２）は、ノードＡと共通の秘密鍵Ｋａを用いて、ノンスＮａとセッション鍵ＫｓとノードＢの識別情報ＩＤｂとでメッセージ認証コードの値（ＭＡＣ値）ＭＡＣ〔Ｋａ〕（Ｎａ，Ｋｓ，ＩＤｂ）を計算する。さらに、認証手段ＡＭ（暗号化モジュール１２）は、計算されたＭＡＣ値をノンスＮｓａ（＝ＭＡＣ〔Ｋａ〕（Ｎａ，Ｋｓ，ＩＤｂ））に用い、ノンスＮｓａとセッション鍵Ｋｓとを暗号化した暗号文（サービス用暗号メッセージ）｛ＥＮＣ〔Ｋａ〕（Ｎｓａ） ＸＯＲ Ｋｓ｝を生成する。

加えて、認証手段ＡＭ（秘密鍵取得モジュール１１）は、認証用データベースＤＢからノードＢと共通の秘密鍵Ｋｂを取得する。認証手段ＡＭ（暗号化モジュール１２）は、ノードＢと共通の秘密鍵Ｋｂを用いて、ノンスＮｂとセッション鍵ＫｓとノードＡの識別情報ＩＤａとでＭＡＣ値ＭＡＣ〔Ｋｂ〕（Ｎｂ，Ｋｓ，ＩＤａ）を計算する。さらに、認証手段ＡＭ（暗号化モジュール１２）は、計算されたＭＡＣ値をノンスＮｓｂ（＝ＭＡＣ〔Ｋｂ〕（Ｎｂ，Ｋｓ，ＩＤａ））に用い、ノンスＮｓｂとセッション鍵Ｋｓとを暗号化した暗号文（利用者用暗号メッセージ）｛ＥＮＣ〔Ｋｂ〕（Ｎｓｂ） ＸＯＲ Ｋｓ｝を生成する。

認証手段ＡＭ（セッション鍵送信モジュール１３）によって、セッション鍵Ｋｓを含む２つの暗号文（利用者用暗号メッセージ、サービス用暗号メッセージ）は、それぞれＭＡＣ値が付加されてノードＢに送信される（Ｐ３）。ノードＢは、認証手段ＡＭから暗号文を受け取ると、秘密鍵Ｋｂで暗号化された暗号文を復号化して、ノンスＮｓｂとセッション鍵Ｋｓとを取得する。また、ノンスＮｓｂは、ＭＡＣ値ＭＡＣ〔Ｋｂ〕（Ｎｂ，Ｋｓ，ＩＤａ）である。よって、ノードＢは、既知のノンスＮｂおよび識別情報ＩＤａと取得したセッション鍵Ｋｓとを用いてＭＡＣ値を計算する。ノードＢは、計算したＭＡＣ値を受信したＭＡＣ値と照合することにより、暗号文の正真性を確認する。

次に、ノードＢは、認証手段ＡＭから受け取ったノードＡへの暗号文｛ＥＮＣ〔Ｋａ〕（Ｎｓａ） ＸＯＲ Ｋｓ｝とＭＡＣ値ＭＡＣ〔Ｋａ〕（Ｎａ，Ｋｓ，ＩＤｂ）とをノードＡに転送する。また、ノードＢは、セッション鍵ＫｓによるＭＡＣ値ＭＡＣ〔Ｋｓ〕（Ｎａ，Ｎｂ，ＩＤｂ）を計算し、認証手段ＡＭから受け取ったノードＡへの暗号文およびＭＡＣ値に、計算したＭＡＣ値とノンスＮｂとを付加してノードＡに送信する（Ｐ４）。

ノードＡは、ノードＢから暗号文｛ＥＮＣ〔Ｋａ〕（Ｎｓａ） ＸＯＲ Ｋｓ｝を受信すると、秘密鍵Ｋａを用いて復号化し、ノンスＮｓａとセッション鍵Ｋｓとを取得する。また、ノードＡは、ノードＢと同様に、ＭＡＣ値ＭＡＣ〔Ｋａ〕（Ｎａ，Ｋｓ，ＩＤｂ）、ＭＡＣ〔Ｋｓ〕（Ｎａ，Ｎｂａ，ＩＤｂ）を計算する。ノードＡは、計算されたＭＡＣ値を受信したＭＡＣ値と照合することにより、暗号文の正真性を確認する。

その後、ノードＡは、セッション鍵ＫｓによるＭＡＣ値ＭＡＣ〔Ｋｓ〕（Ｎａ，Ｎｂ）を算出し、ノードＢに返送する（Ｐ５）。ノードＢは、手順Ｐ１においてナンスＮａを受け取っている。そのため、ノードＢは、ＭＡＣ値ＭＡＣ〔Ｋｓ〕（Ｎａ，Ｎｂ）を算出することにより、ノードＡからの応答であることを確認することができる。

なお、ノードＡ，Ｂがセッション鍵Ｋｓを受け取ったことを認証手段ＡＭにおいて確認する必要があれば、手順Ｐ５の前に、ノードＡは、秘密鍵ＫａによるＭＡＣ値ＭＡＣ〔Ｋａ〕（Ｎａ，Ｋｓ）を算出して、ＭＡＣ値ＭＡＣ〔Ｋｓ〕（Ｎａ，Ｎｂ）とともにノードＢに送信してもよい。この場合、ノードＢは、ノードＡからの応答を確認すると、秘密鍵ＫｂによるＭＡＣ値ＭＡＣ〔Ｋｂ〕（Ｎｂ，Ｋｓ）を算出して、ノードＡから受け取ったＭＡＣ値〔Ｋａ〕（Ｎａ，Ｋｓ）とともに認証手段ＡＭに送信する（Ｐ６）。

認証手段ＡＭは、ノードＢから受け取った２個のＭＡＣ値ＭＡＣ〔Ｋｓ〕（Ｎａ，Ｎｂ），ＭＡＣ〔Ｋｂ〕（Ｎｂ，Ｋｓ）を用いてノードＡ，Ｂがセッション鍵Ｋｓを受け取ったことを確認することができる。

２．利用者を制限する場合
上述したように、ノードＮ０は、ドメインＤ１においては、ファームウェアの無償アップデートのような必要最小限のサービスしか享受できない。ノードＮ０がさらに高次のサービスを受けるには、ノードＮ２が提供するサービスを享受することができるように、ノードＮ２の属しているドメインＤ２にノードＮ０が参加することが必要になる。

ところで、高次のサービスを提供する場合、サービス提供者は、サービスに対する対価を求める場合が多い。ここでは、ドメインＤ２において高次のサービスを提供するにあたり、ノードＮ０の利用者による対価の支払いが可能になるように、ノードＮ０をドメインＤ２に参加させるための付帯条件としてノードＮ０を利用する利用者の登録を要求している。

ノードＮ０は、機器であって、利用者の登録を行うための入力手段を備えているとは限らない。そのため、利用者の登録にあたっては、ノードＮ０とは別に設けられた入力装置ＩＭが用いられる。入力装置ＩＭは、たとえば移動体電話機や情報端末（パーソナルコンピュータやＰＤＡなど）である。サーバＳ１には、利用者の登録を行う機能を実現するために、上述したように登録手段ＲＧ１とユーザ情報データベース記憶手段ＤＳｕとが設けられている。登録手段ＲＧ１は、移動体電話網のような情報通信網ＮＴ２を介して入力装置ＩＭと通信するように構成される。ユーザ情報データベース記憶手段ＤＳｕは、利用者名とノードＮ０の識別子ＩＤ０とを対応付けて登録されたユーザ情報データベースＤＢｕを記憶している。

ノードＮ０の利用者の登録を入力装置ＩＭを用いて行うには、まず、入力装置ＩＭによって登録手段ＲＧ１にアクセスする（Ｐ２００）。その後に、利用者名とノードＮ０の識別子ＩＤ０とを登録手段ＲＧ１を介してユーザ情報データベースＤＢｕに登録する（Ｐ２０１，Ｐ２０２）。

ユーザ情報データベースＤＢｕには、ノードＮｘの利用者Ｕｓのアカウントは、Ｕｓ：｛ＩＤｘ｝という形式で登録される。たとえば、ノードＮ０の利用者Ｕ０が登録を行うと、ユーザ情報データベースＤＢｕには、Ｕ０：｛ＩＤ０｝という形式でアカウントが登録される。また、ノードＮ０、Ｎ２における利用者Ｕ０のアカウントは、Ｕ０：｛ＩＤ２，ＩＤ０｝で表される。ユーザ情報データベースＤＢｕの内容については後述する。

ユーザ情報データベースＤＢｕに設定されたアカウントは入力装置ＩＭに返送される（Ｐ２０３）。入力装置ＩＭは、ユーザ情報データベースに登録された内容を入力装置ＩＭの表示部に表示させる。したがって、入力装置ＩＭの操作者が登録内容を確認できる。

ノードＮ０の利用者Ｕ０のアカウントがユーザ情報データベースＤＢｕに登録されていると、ノードＮ０が所属するドメインの変更が可能になる。ドメインの変更は、ノードＮ０から鍵配布手段ＫＤ１に対して要求する。すなわち、利用者は、ノードＮ０を操作することにより、ドメインＤ１からドメインＤ２への変更を鍵配布手段ＫＤ１に要求する。ドメインＤ１からドメインＤ２に変更する要求（ドメイン変更要求）には、ノードＮ０の識別子ＩＤ０と、所属を希望するドメイン（希望ドメイン）Ｄ２の識別子とが含まれる。

利用者がノードＮ０の所属するドメインの変更を要求するのは、たとえば、ノードＮ０の利用者Ｕ０が現状のサービスよりも高次のサービスの存在を認知し、そのサービスを享受しようとする場合である。ノードＮ０の利用者Ｕ０が高次のサービスの存在を認知する契機には、ノードＮ０がサービスを検知した場合、ノードＮ０が定期的にサービスの変更を確認している場合、他ノードからノードＮ０に新たなサービスを通知してきた場合などがある。

ここでは、図４に示す手順を用いて、ドメインＤ１に属しているノードＮ０がドメインＤ２に属する状態への変更を要求するとする。この場合、ノードＮ０は、ノードＮ０の識別子ＩＤ０と現在のドメイン（現在ドメイン）Ｄ１と希望するドメイン（希望ドメイン）Ｄ２とを指定して鍵配布手段ＫＤ１にドメイン変更要求を送信する（Ｐ３００）。鍵配布手段ＫＤ１は、各ドメインＤ１〜Ｄ３と各認証手段ＡＭ１〜ＡＭ３とを対応付けた表１のようなテーブルを備えている。鍵配布手段ＫＤ１は、ドメイン変更要求に含まれる現在ドメインＤ１および希望ドメインＤ２を表１のテーブルと照合し、認証手段ＡＭ１，ＡＭ２を抽出する。

また、鍵配布手段ＫＤ１（アカウント確認モジュール２０）は、ノードＮ０からドメイン変更要求を受け取ると、ユーザ情報データベースＤＢｕにノードＮ０の利用者Ｕ０のアカウントが登録されているか否かを確認する（Ｐ３０１，Ｐ３０２）。ユーザ情報データベースに利用者Ｕ０のアカウントが登録されていると、鍵配布手段ＫＤ１（秘密鍵要求モジュール２１）は、現在ドメインＤ１に対応して表１のテーブルから抽出された認証手段ＡＭ１と、希望ドメインＤ２に対応して表１のテーブルから抽出された認証手段ＡＭ２とに、それぞれ識別子ＩＤ０を引き渡す（Ｐ３０３，Ｐ３０４）。

認証手段ＡＭ１は、鍵配布手段ＫＤ１から識別子ＩＤ０を受け取ると、認証手段ＡＭ１に付設された第１認証用データベースＤＢ１に識別子ＩＤ０を照合する。同様に、認証手段ＡＭ２は、鍵配布手段ＫＤ１から識別子ＩＤ０を受け取ると、認証手段ＡＭ２に付設された第２認証用データベースＤＢ２に識別子ＩＤ０を照合する（Ｐ３０５〜Ｐ３０８）。これによって、認証手段ＡＭ１は、秘密鍵Ｋ０−１を取得する。また、認証手段ＡＭ２は、ノードＮ０に対応する秘密鍵Ｋ０−２１と、ノードＮ２に対応する秘密鍵Ｋ２とを取得する。

認証手段ＡＭ１は、ノードＮ０に対応する秘密鍵を第１認証用データベースＤＢ１から取得できるか否かによって、ノードＮ０がドメインＤ１に属しているか否かを確認する。上記の場合、認証手段ＡＭ１は、秘密鍵Ｋ０−１を第１認証用データベースＤＢ１から取得できたから、ノードＮ０がドメインＤ１に属していると判定する。認証手段ＡＭ１は、判定した結果を鍵配布手段ＫＤ１に通知する（Ｐ３０９）。ノードＮ０がドメインＤ１に属していることが確認された場合、鍵配布手段ＫＤ１（秘密鍵要求モジュール２１）は、認証手段ＡＭ２が第２認証用データベースＤＢ２から取得したドメインＤ２の秘密鍵Ｋ０−２１を認証手段ＡＭ２から取得する（Ｐ３１０）。鍵配布手段ＫＤ１（秘密鍵送信モジュール２２）は、認証手段ＡＭ２から取得した秘密鍵Ｋ０−２１をノードＮ０に配布する（Ｐ３１１）。ノードＮ０は、ドメインＤ２に対応する秘密鍵Ｋ０−２１を受け取ると、ドメインＤ１に属していたときに用いていた秘密鍵（すなわち、現在ドメインＤ１に対応する秘密鍵）Ｋ０−１を削除し、以後の通信では秘密鍵（希望ドメインＤ２に対応する秘密鍵）Ｋ０−２１を用いる。この動作により、ノードＮ０が所属するドメインＤがドメインＤ１からドメインＤ２に変更される。

一方、鍵配布手段ＫＤ１は、ノードＮ０に秘密鍵Ｋ０−２１を配布した後、第１認証用データベースＤＢ１からのノードＮ０の識別子ＩＤ０および秘密鍵Ｋ０−１のエントリの削除と（Ｐ３１２）、第２認証用データベースＤＢ２へのノードＮ０の識別子ＩＤ０および秘密鍵Ｋ０−２１のエントリの作成（Ｐ３１３）とを行う。鍵配布手段ＫＤ１によるエントリの削除と作成とは、どちらを先に行ってもよい。

ここで、第１認証用データベースＤＢ１からのノードＮ０の識別子ＩＤ０および秘密鍵Ｋ０−１のエントリの削除は、ノードＮ０に秘密鍵Ｋ０−２１を配布したことをもって自動的に行うことが可能できる。この場合、仮にノードＮ０への秘密鍵Ｋ０−２１の配布が失敗したとすると、ノードＮ０は秘密鍵Ｋ０−１のみを持つことになる。一方、第１認証用データベースＤＢ１から秘密鍵Ｋ０−１のエントリが削除されているから、ノードＮ０は秘密鍵Ｋ０−１を用いても、ドメインＤ１に属することができない。また、秘密鍵Ｋ０−２１を持っていないから、ノードＮ０はドメインＤ２にも属することができない。つまり、ノードＮ０はドメインＤ１，Ｄ２のいずれにも属することができなくなる。

このような事態を回避するために、ノードＮ０をドメインＤ１に属する状態からドメインＤ２に属する状態に変更したこと（つまり、秘密鍵Ｋ０−２１を受け取ったこと）についてノードＮ０から鍵配布手段ＫＤ１に確認応答を行ってもよい（Ｐ３１４）。この場合、鍵配布手段ＫＤ１は、ノードＮ０からの確認応答をトリガとして、第１認証用データベースＤＢ１からのノードＮ０の識別子ＩＤ０および秘密鍵Ｋ０−２１のエントリの削除を行う。つまり、ノードＮ０が秘密鍵Ｋ０−２１を受け取ったことを鍵配布手段ＫＤ１が確認した後にノードＮ０をドメインＤ１から削除する。これによって、両ドメインＤ１，Ｄ２のいずれかにノードＮ０が属することを保証することができる。なお、手順Ｐ３１２はオプションであり、適宜に選択可能である。

上述のようにしてノードＮ０がドメインＤ２に属するための秘密鍵Ｋ０−２１を取得すると、図５に示すように、認証手段ＡＭ２は、秘密鍵Ｋ２，Ｋ０−２１を用い、周知の３者間の鍵配布プロトコルによって、ノードＮ０，Ｎ２がドメインＤ２において用いるセッション鍵を配布する（この手順は、図２に示した手順と同様である）。

すなわち、ノードＮ２がノードＮ０にサービスを提供するときには、まず、ノードＮ０にサービスの提供を通知し（Ｐ４００）、これによって、ノードＮ０がサーバＳ１の認証手段ＡＭ２にセッション鍵の配布を要求する（Ｐ４０１）。サーバＳ１では、認証手段ＡＭ２が、ノードＮ０からのセッション鍵配布要求を受け取って、第２認証用データベースＤＢ２を参照して、ノードＮ０の識別子ＩＤ０に対応する秘密鍵Ｋ−０２１と、ノードＮ２の識別子ＩＤ２に対応する秘密鍵Ｋ２とを取得する（Ｐ４０２，Ｐ４０３）。

そして、認証手段ＡＭ２は、秘密鍵Ｋ０−２１，Ｋ２と識別子ＩＤ０，ＩＤ２とを用い、周知の３者間の鍵配布プロトコルによりセッション鍵をノードＮ０，Ｎ２に配布する（Ｐ４０４，Ｐ４０５）。

上述のように、ノードＮ２がノードＮ０を介してサーバＳ１にセッション鍵の配布を要求し、ノードＮ０，Ｎ２に共通のセッション鍵が配布される。これによって、ノードＮ０はノードＮ２と同じドメインＤ２に含まれ、互いに通信することが可能になる。すなわち、ノードＮ０はドメインＤ２において提供されるサービス（ここでは、機能拡張のサービス）を享受することが可能になる。

上述した３者間の鍵配布プロトコルでは、ノードＮ０がノードＮ２へのセッション鍵をサーバＳ１から受け取ると（Ｐ４０４）、受け取ったセッション鍵をノードＮ２に引き渡す（Ｐ４０５）。上述した３者間の鍵配布プロトコルでは、手順Ｐ４０５の後に、ノードＮ０，Ｎ２に同じセッション鍵が設定されたことを確認する手順を含めてもよい（Ｐ４０６）。ただし、手順Ｐ４０６はオプションであるから省略してもよい。

なお、上述の例では、ノードＮ０がドメインＤ２に属するときに、秘密鍵Ｋ０−２１を１個だけ持たせている。しかしながら、ノードＮ０がドメインＤ２に属するときに、下位のドメインＤ１で用いる秘密鍵Ｋ０−１を削除せずにそのまま持たせてもよい。この場合、ノードＮ０は、ドメインＤ２で用いる秘密鍵Ｋ０−２１をデフォルトで用いる。

すなわち、ノードＮ０は２個の秘密鍵Ｋ０−１，Ｋ０−２１を持っていてもよい。この場合、ノードＮ０は、デフォルトで秘密鍵Ｋ２を用いることによってドメインＤ２に属する。ノードＮ０がドメインＤ１のサービスを享受しようとするときには、ノードＮ０は、認証手段ＡＭ１にアクセスし、秘密鍵Ｋ０−１を用いて認証手段ＡＭ１からノードＮ１とのセッション鍵を取得する。この動作によって、ノードＮ０はノードＮ１にアクセスすることが可能になる。そのため、ノードＮ０は、ファームウェアのアップデートなどドメインＤ１におけるサービスを享受することができる。

このように、ノードＮ０のドメインＤを下位のドメインＤ１から上位のドメインＤ２に変更した場合に、ノードＮ０は、両ドメインＤ１，Ｄ２に対応する２個の秘密鍵Ｋ０−１，Ｋ０−２１を保有していてもよい。この場合、ノードＮ０は、通常は上位のドメインＤ２に対応した秘密鍵Ｋ０−２１を用いることができる。しかも、ノードＮ０は、必要に応じて下位のドメインＤ１に対応した秘密鍵Ｋ０−１を用いて認証手段ＡＭ１からセッション鍵を取得することが可能になる。

この場合、ノードＮ０はドメインＤ１でのサービスの享受を終了した後に、セッション鍵の有効期間が満了すると秘密鍵Ｋ０−２１を用いる状態に自動的に復帰する。あるいはまた、ノードＮ０において適宜の操作がなされることにより秘密鍵Ｋ０−２１を用いる状態に戻る。つまり、ノードＮ０は一時的にドメインＤ１に属することになる。

さらに、ノードＮ０が上位のドメインＤ２に属する状態において一時的に下位のドメインＤ１に属する状態を選択する動作に代えて、上位のドメインＤ２に属する状態で、下位のドメインＤ１にも属するようにしてもよい。すなわち、下位のドメインＤ１と上位のドメインＤ２とを選択することなく同時に利用可能としてもよい。

３．グループを形成する場合
上述したように、ノードＮ０がドメインＤ１あるいはドメインＤ２に属するときには、ノードＮ０は単独でサービスを享受している。以下では、ノードＮ０がさらに上位のドメインＤ３に属することによって、ノードＮ０のグループ登録を可能にする場合について説明する。グループ登録が行われると、たとえば、ノードＮ０と、ノードＮ０と同グループに属している他のノードとの連携動作が可能になる。

ノードＮ０がドメインＤ３でのサービスを享受するには、ドメインＤ２でのサービスを享受する場合と同様に、利用者Ｕ０のアカウントがユーザ情報データベースＤＢｕに登録されている必要がある（図４の手順Ｐ２００〜Ｐ２０３を参照）。ノードＮ０がドメインＤ３に属する状態に変更される前にドメインＤ２に属していた場合には、ユーザ情報データベースＤＢｕには利用者Ｕ０のアカウントがすでに登録されている。そのため、利用者Ｕ０のアカウントを利用できる。しかしながら、ドメインＤ３では、グループ登録を行うから、アカウントには、利用者名およびノードＮ０の識別子ＩＤ０のほかに、ノードＮ０とともにグループをなすノードの登録も必要である。

以下では、ノードＮ３をノードＮ０とともにグループをなすノードとする。つまり、ユーザ登録データベースにアカウントを登録する際に、利用者名およびノードＮ０の識別子ＩＤ０を登録することに加え、ノードＮ０の識別子ＩＤ０とノードＮ３の識別子ＩＤ３とのグループ登録を行う。ユーザ登録データベースＤＢｕへの利用者Ｕ０のアカウントの登録には、ドメインＤ２のサービスを享受する場合と同様に入力装置ＩＭが用いられる。

ユーザ情報データベースＤＢｕにおいて、ノードＮｘを利用する利用者Ｕｓのアカウントについて、ノードＮｘをグループＧｙに登録するには次のようにすればよい。すなわち、ノードＮｘを利用者Ｕｓに対応付けるために、アカウントをＵｓ：｛ＩＤｘ｝という形式で登録する。さらに、ノードＮｘをグループＧｙに登録するために、グループをＧｙ：｛ＩＤｘ｝という形式で登録する。ここでのノードＮｘの識別子ＩＤｘは、利用者ＵｓやグループＧｙに対応付けられるすべてのノードの識別子を含む。

ドメインＤ３に含まれるノードＮ３のほか、ドメインＤ３の下位のドメインＤ２に含まれるノードＮ２も利用者に対応付けるとすると、ノードＮ０の利用者Ｕ０のアカウントとして、Ｕ０：｛ＩＤ２，ＩＤ３，ＩＤ０｝という内容が登録される。また、利用者Ｕ０がグループ登録を行うグループをＧ１として、グループＧ１において、ドメインＤ３のノードＮ３のみをノードＮ０に対応付けるとすれば、Ｇ１：｛ＩＤ３，ＩＤ０｝という内容が登録される。

上述のように、ユーザ情報データベースＤＢｕにおいて、ノードＮ０の利用者Ｕ０のアカウントとして、利用者Ｕ０に３個のノードＮ０，Ｎ２，Ｎ３が対応付けられ、そのうち、グループＧ１に２個のノードＮ０，Ｎ３が対応付けて登録されている場合を想定する。つまり、ユーザ情報データベースＤＢｕにおいて、利用者Ｕ０のアカウントとして、グループＧ１に対応付けるノードＮ０，Ｎ３の識別子ＩＤ０，ＩＤ３が登録されているものとする。

ここで、ノードＮ０のドメインＤがドメインＤ２からドメインＤ３に変更されるように、利用者がノードＮ０を操作すると、図６に示すように、ノードＮ０は、ノードＮ０の識別子ＩＤ０と現在ドメインＤ２と希望ドメインＤ３とを指定して鍵配布手段ＫＤ１にドメイン変更要求を送信する（Ｐ６００）。利用者がノードＮ０の所属するドメインを変更するための操作を行う契機は、ノードＮ０がドメインＤ１に属している状態からドメインＤ２に属する状態に変更する場合と同様である。

ノードＮ０から鍵配布手段ＫＤ１へのドメインの変更要求では、現在ドメインＤ２と希望ドメインＤ３とが指定されている。そのため、ドメイン変更要求を受けた鍵配布手段ＫＤ１は、表１のテーブルを参照して、現在ドメインＤ２および希望ドメインＤ３にそれぞれ対応する認証手段ＡＭ２，ＡＭ３を抽出する。

ノードＮ０がドメインＤ３に属するためには、ノードＮ０が利用する秘密鍵を変更する必要がある。すなわち、ノードＮ０がドメインＤ２に属しているときには、ノードＮ０は秘密鍵Ｋ０−２１を用いているが、ドメインＤ３では秘密鍵Ｋ０−３を用いる。現状の秘密鍵Ｋ０−２１から新たな秘密鍵Ｋ０−３を取得する手順は、ノードＮ０のドメインＤをドメインＤ１からドメインＤ２に変更する際の手順Ｐ３００〜Ｐ３１１と同様である。ただし、認証手段ＡＭ１を認証手段ＡＭ２に、認証手段ＡＭ２を認証手段ＡＭ３に、認証用データベースＤＢ１を認証用データベースＤＢ２に、認証用データベースＤＢ２を認証用データベースＤＢ３に、それぞれ読み替える必要がある。

ノードＮ０のドメインＤをドメインＤ２からドメインＤ３に変更する手順を、以下に簡単に説明する。上述したように鍵配布手段ＫＤ１は、ノードＮ０からドメイン変更要求を受けて、認証手段ＡＭ２，ＡＭ３を抽出する。さらに、鍵配布手段ＫＤ１は、ユーザ情報データベースＤＢｕにノードＮ０の利用者Ｕ０のアカウントが登録されているか否かを確認する（Ｐ６０１，Ｐ６０２）。利用者Ｕ０のアカウントがユーザ情報データベースＤＢｕ登録されていると、鍵配布手段ＫＤ１は、認証手段ＡＭ２，ＡＭ３にそれぞれノードＮ０の識別子ＩＤ０を引き渡す（Ｐ６０３，Ｐ６０４）。その後、認証手段ＡＭ２は第２認証用データベースＤＢ２に識別子ＩＤ０に対応する秘密鍵が登録されているか否かを確認する。また、認証手段ＡＭ３は第３認証用データベースＤＢ３に識別子ＩＤ０に対応する秘密鍵が登録されているか否かを確認する（Ｐ６０５〜Ｐ６０８）。

これによって、認証手段ＡＭ２は、ノードＮ０がドメインＤ２で使用する秘密鍵Ｋ０−２１を取得する。また、認証手段ＡＭ３は、ノードＮ０がドメインＤ３で使用する秘密鍵Ｋ０−３を取得する。

認証手段ＡＭ２は秘密鍵Ｋ０−２１を、認証手段ＡＭ３は秘密鍵Ｋ０−３を、それぞれ鍵配布手段ＫＤ１に渡す（Ｐ６０９，Ｐ６１０）。鍵配布手段ＫＤ１は、秘密鍵Ｋ０−２１を用いてノードＮ０に秘密鍵Ｋ０−３を配布する（Ｐ６１１）。ノードＮ０は、秘密鍵Ｋ０−３を受け取ると、ドメインＤ２に属していたときに用いていた秘密鍵（すなわち現在ドメインＤ２に対応する秘密鍵）Ｋ０−２１を削除する。ノードＮ０は、以後の通信では秘密鍵（希望ドメインＤ３に対応する秘密鍵）Ｋ０−３を用いる。これによって、ノードＮ０の属するドメインＤがドメインＤ２からドメインＤ３に変更されたことになる。

また、鍵配布手段ＫＤ１は、ノードＮ０に秘密鍵Ｋ０−３を配布した後、第２認証用データベースＤＢ２からのノードＮ０の識別子ＩＤ１および秘密鍵Ｋ０−２１のエントリの削除と（Ｐ６１２）、第３認証用データベースＤＢ３へのノードＮ０の識別子ＩＤ１および秘密鍵Ｋ０−３のエントリの作成（Ｐ６１３）とを行う。ドメインＤ１からドメインＤ２への変更と同様に、鍵配布手段ＫＤ１によるエントリの削除と作成とは、どちらを先に行ってもよい。

また、ノードＮ０に秘密鍵Ｋ０−３を配布した後に、第２認証用データベースＤＢ２からノードＮ０の識別子ＩＤ１および秘密鍵Ｋ０−２１のエントリを自動的に削除してもよい。しかしながら、ノードＮ０への秘密鍵Ｋ０−３の配布が失敗していたとすると、ノードＮ０は秘密鍵Ｋ０−３を持たないにもかかわらず、秘密鍵Ｋ０−２１のエントリが第２認証用データベースＤＢ２から削除されている。そのため、ノードＮ０はドメインＤ２，Ｄ３のいずれにも属することができなくなる。

そこで、ノードＮ０が秘密鍵Ｋ０−３を受け取った後に鍵配布手段ＫＤ１に対して確認応答を行う処理（Ｐ６１４）と、鍵配布手段ＫＤ１がノードＮ０から確認応答を受信したことをトリガとして認証用データベースＤＢ２からのノードＮ０の識別子ＩＤ１および秘密鍵Ｋ０−２１のエントリの削除を行う処理とをオプションとして付加してもよい。

ノードＮ０がドメインＤ３に属するための秘密鍵Ｋ０−３を取得した後は、ドメインＤ３に属するノードＮ０，Ｎ３の間で通信が必要になったときに、認証手段ＡＭ３では、秘密鍵Ｋ３，Ｋ０−３を用い、周知の３者間の鍵配布プロトコルを用いてドメインＤ３に属する各ノードＮ０，Ｎ３にセッション鍵を配布する。セッション鍵の配布手順は、図２に示した手順Ｐ１００〜Ｐ１０６、あるいは図５に示した手順Ｐ４００〜Ｐ４０６と同様であるから説明を省略する。

ドメインＤ３に属する各ノードＮ０，Ｎ３にセッション鍵が配布されると、ノードＮ０はノードＮ３とグループを形成する。これによって、ノードＮ０とノードＮ３との連携動作が可能になる。連携動作については後述する。

なお、上述の例では、ドメインＤ３に属するノードＮ０は、秘密鍵Ｋ０−３だけを有している。しかしながら、秘密鍵Ｋ−０２１を必ずしも削除する必要はない。すなわち、ドメインＤ３に属するノードＮ０は、秘密鍵Ｋ−０３と秘密鍵Ｋ０−２１との両方を有していてもよい。この場合、ノードＮ０は、秘密鍵Ｋ０−３をデフォルトで用いる。

この場合、鍵配布手段ＫＤ１は、秘密鍵Ｋ０−３をノードＮ０に配布した後に、第２認証用データベースＤＢ２におけるノードＮ０の識別子ＩＤ０および秘密鍵Ｋ０−２１のエントリを削除しないように構成される。また、ノードＮ０も秘密鍵Ｋ０−２１を削除しないように構成される。

ノードＮ０は、秘密鍵Ｋ０−３をデフォルトで用いる。そのため、ノードＮ０は、デフォルトでドメインＤ３に属する。ノードＮ０は、ドメインＤ２のサービスを享受しようとするときには、認証手段ＡＭ２にアクセスしてドメインＤ２で用いる秘密鍵Ｋ０−２１を用いて認証手段ＡＭ２からノードＮ２と同じセッション鍵を取得する。この動作によって、ノードＮ０はノードＮ２にアクセスすることが可能になる。よって、ノードＮ０は、ドメインＤ２におけるサービスを享受することが可能になる。

上述の例ではドメインＤ２でのサービスを享受する場合について説明したが、同様の処理をドメインＤ１からドメインＤ２への変更の際にも行ってもよい。すなわち、ノードＮ０が３種類の秘密鍵Ｋ０−１，Ｋ０−２１，Ｋ０−３を保持していれば、ドメインＤ２でのサービスだけではなく、ドメインＤ１でのサービスも享受することが可能である。

ノードＮ０に複数種類の秘密鍵を持たせる場合に、ドメインＤ３以外でのサービスの享受を終了した後に、セッション鍵の有効期間が満了すると秘密鍵Ｋ０−３を用いる状態に自動的に復帰するのが望ましい。また、ノードＮ０において適宜の操作がなされることにより秘密鍵Ｋ０−３を用いる状態に復帰させてもよい。

さらに、上述のようにノードＮ０が属するドメインを切り換える動作に代えて、複数のドメインに同時に属するようにしてもよい。すなわち、ノードＮ０が上位のドメインＤ３でのサービスを利用する状態において、下位のドメインＤ１，Ｄ２でのサービスも同時に利用可能にしてもよい。

上述の動作例では、ノードＮ０の属するドメインＤをドメインＤ１からドメインＤ２に変更する場合と、ドメインＤ２からドメインＤ３に変更する場合とが例示されている。しなしながら、ノードＮ０のドメインＤをドメインＤ１からドメインＤ３に変更することも可能であり、その場合も、同様の手順を用いることができる。

ノードＮ０のドメインＤをドメインＤ１からドメインＤ３に変更する場合の手順を簡単に説明する。上述のように、ノードＮ０がドメインＤ３に属するためには、まず、登録手段ＲＧ１を用いてユーザ情報データベースＤＢｕに利用者のアカウントを登録するとともにグループ登録を行う必要がある。次に、ノードＮ０が、鍵配布手段ＫＤ１に、ドメインＤ１からドメインＤ３へのドメイン変更要求を送信する。変更要求を受けた鍵配布手段ＫＤ１は、認証手段ＡＭ１，ＡＭ３を抽出する。鍵配布手段ＫＤ１は、第１認証用データベースＤＢ１に登録されている秘密鍵Ｋ０−１と第３認証用データベースＤＢ３に登録されている秘密鍵Ｋ０−３を用いることにより、ノードＮ０に秘密鍵Ｋ０−３を送信する。これによって、ノードＮ０の保有する秘密鍵が秘密鍵Ｋ０−１から秘密鍵Ｋ０−３に変更される。

なお、ノードＮ０がドメインＤ１またはドメインＤ２に属する場合は、ドメインＤ１，Ｄ２に含まれるすべてのノードＮ１，Ｎ２との間でセッション鍵を共有して安全に通信することができる。しかしながら、ノードＮ０がドメインＤ３に属する場合は、ドメインＤ３内においてノードＮ０とグループＧ１をなす一部のノードＮ３との間でセッション鍵を共有して安全に通信を行うことになる。

４．下位ドメインに変更する場合
以下では、ノードＮ０が属するドメインを上位ドメインから下位ドメインに変更する手順について説明する。各ドメインＤ１〜Ｄ３でのサービスをあらためて例示しておく。すなわち、上述の例では、ドメインＤ１ではノードＮ０はファームウェアアップデートのような基本的なサービスを無料で享受できる。ドメインＤ２ではノードＮ０は有料のサービスを享受できる。ドメインＤ３ではノードＮ０はドメイン内の他のノードとグループを形成することができ、これによって複数のノードの連携動作が可能になる。

したがって、ノードＮ０が属するドメインＤを上位ドメインＤ３から下位ドメインＤ２に変更すると、連携動作ができなくなる。ノードＮ０が属するドメインＤを上位ドメインＤ２から下位ドメインＤ１に変更すると、有料のサービスを享受できなくなる。さらに、ノードＮ０のドメインＤをドメインＤ３からドメインＤ１に変更することも可能である。

以下では、ノードＮ０のドメインＤがドメインＤ３からドメインＤ２に変更される場合を例として説明する。しかしながら、ノードＮ０のドメインＤがドメインＤ２からドメインＤ１に変更される場合や、ノードＮ０のドメインＤがドメインＤ３からドメインＤ１に変更される場合も同様の手順になる。

ノードＮ０のドメインＤをドメインＤ３からドメインＤ２に変更する場合には、ユーザ情報データベースＤＢｕの利用者Ｕ０のアカウントＵ０：｛ＩＤ２，ＩＤ３，ＩＤ０｝からノードＮ０の識別子ＩＤ０を削除する。ただし、ユーザ情報データベースＤＢｕには、ドメインＤ２に対応するアカウントＵ０：｛ＩＤ２，ＩＤ０｝が必要である。よって、上述したアカウントＵ０：｛ＩＤ２，ＩＤ３，ＩＤ０｝からドメインＤ３に属するノードＮ３の識別子ＩＤ３を削除するようにしてもよい。また、グループ登録を解除するから、ユーザ情報データベースＤＢｕのグループＧ１の登録内容Ｇ１：｛ＩＤ３，ＩＤ０｝からノードＮ０の識別情報ＩＤ０を削除する。

ユーザ情報データベースＤＢｕにおける利用者のアカウントやグループ登録の登録内容を変更するには、利用者のアカウントやグループをユーザ情報データベースＤＢｕに登録した場合と同様に、入力装置ＩＭにより登録手段ＲＧ１にアクセスし、入力装置ＩＭにより登録手段ＲＧ１を介して、ユーザ情報データベースＤＢｕからノードＮ０のドメインＤ３に関するアカウントおよびグループ（グループ登録）を削除する。

ユーザ情報データベースＤＢｕの変更は、登録手段ＲＧ１を介して入力装置ＩＭに返送される。したがって、ユーザ情報データベースＤＢｕの変更を入力装置ＩＭに付設された表示部で確認することができる。登録か削除かの相違はあるが、この手順は図４に示した手順Ｐ２００〜Ｐ２０３と同様である。

上述した動作例に従えば、ノードＮ０がドメインＤ３に属しているときに、ノードＮ０の利用者Ｕ０のアカウントはＵ０：｛ＩＤ２，ＩＤ３，ＩＤ０｝であり、グループはＧ１：｛ＩＤ３，ＩＤ０｝になっている。したがって、ノードＮ０におけるドメインＤ３に関するアカウントおよびドメインＤ３に関するグループをユーザ情報データベースＤＢｕから削除すると、アカウントはＵ０：｛ＩＤ２，ＩＤ０｝になり、グループはＧ１：｛ＩＤ３｝になる。

その後、ノードＮ０において、ドメインＤをドメインＤ３からドメインＤ２に変更する操作を行うと、ドメインを下位ドメインから上位ドメインに変更する場合と同様に、ノードＮ０は鍵配布手段ＫＤ１にアクセスする（Ｐ９００）。ここで、鍵配布手段ＫＤ１は、ユーザ情報データベースＤＢｕのアカウントを確認する（Ｐ９０１，Ｐ９０２）。すなわち、鍵配布手段ＫＤ１は、ユーザ情報データベースＤＢｕを利用して、ノードＮ０がドメインＤ２におけるサービスを享受しようとしていることを確認する。

したがって、鍵配布手段ＫＤ１は、表１に示されたテーブルを参照して、現在ドメインＤ３に対応する認証手段ＡＭ３と、希望ドメインＤ２に対応する認証手段ＡＭ２とをそれぞれ抽出する。鍵配布手段ＫＤ１は、抽出された認証手段ＡＭ３に、現在ドメインＤ３に対応する秘密鍵Ｋ０−３が認証用データベースＤＢ３に登録されているか否かを確認させる。このようにして、鍵配布手段ＫＤ１は、認証用データベースＤＢ３に秘密鍵Ｋ０−３が登録されていることを確認する（Ｐ９０３〜Ｐ９０６）。

その後、鍵配布手段ＫＤ１は、認証手段ＡＭ２を介して認証用データベースＤＢ２にアクセスし、第２認証用データベースＤＢ２からノードＮ０に対応する秘密鍵Ｋ０−２２を取得する（Ｐ９０７〜Ｐ９１０）。

鍵配布手段ＫＤ１は、秘密鍵Ｋ０−２２を取得すると、ノードＮ０に秘密鍵Ｋ０−２２を配布する（Ｐ９１１）。また、鍵配布手段ＫＤ１は、認証用データベースＤＢ３からノードＮ０の識別子ＩＤ１および秘密鍵Ｋ０−３のエントリを削除する。これによって、ノードＮ０がドメインＤ３におけるサービスを享受できなくなる。

ここで、認証用データベースＤＢ３からノードＮ０の識別子ＩＤ１および秘密鍵Ｋ０−３のエントリを削除するタイミングは、ノードＮ０の属するドメインＤを上位のドメインＤに変更する場合と同様に、鍵配布手段ＫＤ１が秘密鍵Ｋ０−２２をノードＮ０に配布した後の任意のタイミングとしてもよい。しかしながら、ノードＮ０が秘密鍵Ｋ０−２２を受け取った際に確認応答を行う場合（Ｐ９１２）、鍵配布手段ＫＤ１はノードＮ０から確認応答が受け取った際に、認証用データベースＤＢ３におけるノードＮ０の識別子ＩＤ１および秘密鍵Ｋ０−３のエントリを削除するのが好ましい。もちろん、手順Ｐ９１２は適宜に選択できるオプションである。

上述のようにしてノードＮ０が秘密鍵Ｋ０−２２を取得すると、認証手段ＡＭ２は、秘密鍵Ｋ３，Ｋ０−２２を用い、周知の３者間の鍵配布プロトコルによって、ノードＮ０，Ｎ２にドメインＤ２用のセッション鍵を配布する。セッション鍵を配布する手順は、図２における手順Ｐ１００〜Ｐ１０６、図５における手順Ｐ４００〜Ｐ４０６と同様であるから説明を省略する。

なお、ノードＮ０の属するドメインＤを下位のドメインＤ１から上位のドメインＤ２に変更した場合は、上位のドメインＤ２におけるサービスだけではなく下位のドメインＤ１におけるサービスを享受することを可能にする場合もある。しかしながら、ノードＮ０の属するドメインＤを上位のドメインＤ３から下位のドメインＤ２に変更した場合は、上位のドメインＤ３におけるサービスを享受することはできなくなる。

上述の動作例では、ノードＮ０の属するドメインＤをドメインＤ３からドメインＤ２に変更する場合のみを例示したが、ドメインＤ２からドメインＤ１に変更する場合、ドメインＤ３からドメインＤ１に変更する場合も同様の動作になる。

ところで、ユーザ情報データベースＤＢｕにおける利用者Ｕｓのアカウントでは、上述したように、利用者ＵｓにノードＮｘの識別子ＩＤｘが対応付けられている。また、ユーザ情報データベースＤＢｕにおける利用者Ｕｓのアカウントのグループ登録では、ノードＮがグループに対応付けられている。

ユーザ情報データベースＤＢｕに利用者Ｕｓのアカウントを設定する場合、グループ登録を行うか否かにかかわらず、登録手段ＲＧ１により利用者Ｕｓに対応付けてノードＮｘの識別子ＩＤｘが登録されるか削除される。グループ登録を行う場合、登録手段ＲＧ１によりグループに含まれるノードＮｘの識別子ＩＤｘが登録されるか削除される。なお、ユーザ情報データベースＤＢｕからアカウントが削除された後には、アカウントは未登録になる。

また、上述したように、ノードの利用者がユーザ情報データベースＤＢｕにアカウントを登録しただけではノードの属するドメインは変更されない。プロキシサービスとしての鍵配布手段ＫＤ１の管理下において認証手段ＡＭが対応するドメインＤで使用されるセッション鍵をノードＮ０に発行することによりノードＮ０のドメインＤが変更される。

下記の表２は、ユーザ情報データベースＤＢｕの具体例を示す。なお、表２において、ステータスの値は、アカウントの状態を示す。たとえば、「０」が未登録、「１」が登録、「２」が削除を表す。

５．ドメイン変更の優先度
以下では、ノードＮ０の設定変更などにより、ノードＮ０の属しているドメインＤで用いるセッション鍵を認証手段ＡＭから得ることができなくなった場合に、ノードＮ０の属するドメインＤを変更する動作を説明する。

上述したように、認証システムは、３つのドメインＤ１〜Ｄ３に階層化されている。ドメインＤ３はドメインＤ２よりも上位のドメインであり、ドメインＤ２はドメインＤ１よりも上位のドメインである。また、ノードＮ０が属しているドメインＤに応じてドメインＤを変更する順番（優先度）の規則が表３のように規定されている。

表３によれば、たとえば、ドメインＤ３に属しているノードＮ０が認証手段ＡＭ３からドメインＤ３に対応するセッション鍵を取得できなくなると、ノードＮ０はまずドメインＤをドメインＤ３からドメインＤ２への変更しようとする。つまり、ノードＮ０は、認証手段ＡＭ２にアクセスしてドメインＤ２に対応するセッション鍵を取得しようとする。ここで、認証手段ＡＭ２からセッション鍵を受け取ることができない場合には、ノードＮ０はドメインＤをドメインＤ３からドメインＤ１へ変更しようとする。つまり、ノードＮ０は認証手段ＡＭ１にアクセスしてドメインＤ１に対応するセッション鍵を取得しようとする。

同様にして、ドメインＤ２に属しているノードＮ０が認証手段ＡＭ２からドメインＤ２に対応するセッション鍵を取得できなくなると、ノードＮ０はまずドメインＤをドメインＤ２からドメインＤ３へ変更しようとする。つまり、ノードＮ０は、認証手段ＡＭ３にアクセスしてドメインＤ３に対応するセッション鍵を取得しようとする。認証手段ＡＭ３からセッション鍵が得られない場合は、ノードＮ０はドメインＤをドメインＤ２からドメインＤ１へ変更しようとする。つまり、ノードＮ０は、認証手段ＡＭ１にアクセスしてドメインＤ１に対応するセッション鍵を取得しようとする。

さらに、ドメインＤ１に属するノードＮ０が認証手段ＡＭ１からドメインＤ１に対応するセッション鍵を取得することができない場合には、ノードＮ０はまずドメインＤをドメインＤ１からドメインＤ２へ変更しようとする。つまり、ノードＮ０は、認証手段ＡＭ２にアクセスしてドメインＤ２に対応するセッション鍵を取得しようとする。認証手段ＡＭ２からドメインＤ２に対応するセッション鍵が得られない場合は、ノードＮ０はドメインＤをドメインＤ１からドメインＤ３へ変更しようとする。つまり、ノードＮ０は、認証手段ＡＭ３にアクセスしてドメインＤ３に対応するセッション鍵を取得しようとする。

本動作例では、３種類のドメインＤ１〜Ｄ３を用いている。ノードＮ０が２種類のドメインについてセッション鍵の取得を試みてもセッション鍵を取得することができなければ、ノードＮ０はいずれの認証手段ＡＭ１〜ＡＭ３からもセッション鍵を得ることができないということになる。このような場合には、ノードＮ０を初期状態に戻し、情報通信網ＮＴにあらためて参加させる。

上述したように、ノードＮ０が、自身が所属するドメインＤの認証手段ＡＭからセッション鍵を取得できなくなると、表３に示した規則に従って他のドメインＤの認証手段ＡＭにアクセスしてセッション鍵を取得しようとする。すなわち、ノードＮ０が属しているドメインＤに応じて、セッション鍵を取得するためにアクセスする認証手段ＡＭの順番が決められている。ノードＮ０は、この決められた順番で認証手段ＡＭにアクセスする。なお、表３に示した規則では、ノードＮ０のドメインＤが現在のドメインＤよりも上位のドメインＤに変更されるように、ドメインＤの優先順位が決定されている。

６．サービスを単位とする場合
上述した動作例では、各ノードＮｓ（Ｎ１〜Ｎ３）が１つのサービスを提供する例を示した。しかしながら、各ノードＮｓ（Ｎ１〜Ｎ３）は、複数のサービスを提供するように構成されていてもよい。この場合、各ノードＮｓは、サービスごとにノードＮ０に提供するか否かを選択するように構成されていてもよい。一例としては、ドメインＤ２においてサービスを享受するために課金が必要な場合に、料金別にサービスを変更するような場合がある。

以下では、ノードＮｉの識別子をＩＤｉとする。また、ノードＮｉにおいて提供ないし享受するサービスに識別子Ｂｊを付与する。なお、以下の説明において「サービスＢｊ」という表記は、識別子Ｂｊで特定されるサービスを意味する。

ノードＮｉにおいてサービスＢｊを提供可能である場合には、（Ｎｉ provide Ｂｊ）と記述する。ノードＮｉにおいてサービスＢｊを享受する形態としては、読出、書込、実行の３種類がある。ノードＮｉにおいてサービスＢｊの読出／書込／実行が可能である場合には、（Ｎｉ read／write／exec Ｂｊ）と記述する。これらの情報（アクセス制限）は、入力装置ＩＭを用いるなどして認証手段ＡＭにあらかじめ登録されている。認証手段ＡＭがノードＮｉにセッション鍵を与える際に各ノードＮｉに設定される。

上述した各動作例では、ノードＮｉのアクセス可能範囲がドメインの範囲内であって、ノードを単位としたアクセス制限がなされている。これに対して、各ノードＮｉにおいてサービスＢｊについて提供と享受とを分ける場合には、サービスＢｊを単位として操作内容を含むアクセス制限がなされる。したがって、各ノードＮｉにおいて、複数のサービスＢｊが実行可能であり、各サービスＢｊを単位としてアクセス制限がなされる。

たとえば、ノードＮ０が、ドメインＤ１において、ノードＮ１の提供するファームウェアアップデートというサービスＢ１を享受する場合には、認証手段ＡＭ１（認証用データベースＤＢ１）に、（Ｎ０ read Ｂ１）と（Ｎ１ provide Ｂ１）とが登録される。

また、ドメインＤ２において、ノードＮ２が提供する読出と書込とが可能な課金されたサービスＢ２をノードＮ０が享受する場合には、認証手段ＡＭ２に、（Ｎ０ read／write Ｂ２）と（Ｎ２ provide Ｂ２）とが登録される。ドメインＤ２において、ノードＮ２が提供するファームウェアアップデートのような読出のみの課金されたサービスＢ２′をノードＮ０が享受する場合には、認証手段ＡＭ２に、（Ｎ０ read Ｂ２′）と（Ｎ２
provide Ｂ２′）とが登録される。

さらに、ドメインＤ３において、ノードＮ０がノードＮ３と連携する場合には、ノードＮ３の提供するサービスＢ３に対して読出と書込とに加えて実行が必要になる。そのため、認証手段ＡＭ３に、（Ｎ０ read／write／exec Ｂ３）と（Ｎ３ provide Ｂ３）とが登録される。

上述した動作を表４、表５にまとめる。表４におけるアクセス制限は認証手段ＡＭに登録される。認証手段ＡＭに登録されたアクセス制限は、認証手段ＡＭに対応したドメインＤに所属するノードＮにセッション鍵の配布時に設定される。表５には各サービスＢｊの内容をまとめている。

本動作では、ノードＮ０が属するドメインＤに応じて、ドメインＤに含まれるノードＮとセッション鍵を共有することによりサービスを享受するだけではない。本動作では、サービスＢ１，Ｂ２，Ｂ２′，Ｂ３と表４にアクセス制限として示した規則を適用することにより、ドメインＤ内においてサービスを細分化して享受することを可能にしている。

すなわち、ノードＮ０にドメインＤの範囲内でノードＮと共通のセッション鍵が配布されることにより、ノードＮ０はドメインＤで制限された範囲内のサービスを享受する。さらに、サービスＢｊの提供と供給とを分けることにより、サービスＢｊを単位として操作内容を含むアクセス制限が可能になる。言い換えると、各ノードＮｓは、複数のサービスを提供することが可能になる。しかも、アクセス制限の規則を付加することで、ドメインＤ内でもサービスの提供範囲を制限することが可能になる。

一例として、利用者Ｕ０が、登録手段ＲＧ１の設定でノードＮ０に対して、有料のファームウェアアップデートというサービスＢ２′を選択した場合を想定する。この場合、表４における（ＩＤ０ read Ｂ２′）と（ＩＤ２ provide Ｂ２′）とのアクセス制限が利用者情報データベースＤＢｕに設定される。したがって、ノードＮ０がドメインＤ２で用いるセッション鍵を認証手段ＡＭ２から取得する際には、有料のファームウェアアップデートという限定的なサービスＢ２′のみにアクセスすることが可能になる。すなわち、利用者データベースＤＢｕに設定されたアクセス制限は、その後、認証手段ＡＭ（対応する認証用データベースＤＢ１〜ＤＢ３）に設定され、また、ノードＮにも設定される。アクセス制限は、利用者データベースＤＢｕと認証手段ＡＭ（対応する認証用データベースＤＢ１〜ＤＢ３）との双方で設定された後に、ノードＮに設定されてもよい。

ところで、サービスによるアクセス制限を行う場合に、サービスを享受するノードにおいては読出（read）が設定され、サービスを提供するノードにおいては提供（provide）が設定されていなければ、サービスを享受するノードはサービスを提供するノードにアクセスできない。すなわち、サービスを享受するノードのアクセス制限の情報とサービスを提供するノードのアクセス制限の情報との間に対応関係がなければ、ビジビリティ（視認性）がない（つまり、不可視である）。そのため、この特徴を利用してサービスの存在を隠蔽することが可能である。

表４を用いて例示すると、（Ｎ０ read Ｂ２′）がノードＮ０に、（Ｎ２ provide Ｂ２′）がノードＮ２にそれぞれ設定されていなければ、ノードＮ０からはノードＮ２のサービスＢ２′が不可視である。つまり、サービスを享受するノードＮ０（Ｎｕ）とサービスを提供するノードＮ２（Ｎｓ）とのいずれか一方（実際には、ノードＮ０）で上述の設定が行われていなければ、ノードＮ０からはサービスＢ２′が不可視になる。そのため、サービスＢ２′の存在を隠蔽することができる。

なお、ノードが属するドメインを変更しなくても、ドメイン間の信頼関係によって異なるドメインに属するノード間で通信することを可能にすれば、他のドメインのノードが提供している特定のサービスを享受することも可能である。

なお、ドメイン間の信頼関係は、クリプトナイトにおける複数ドメイン間をまたがるノード間のセキュア通信を行う際に用いられる。ドメイン間の信頼関係は、ドメイン同士が相手のドメイン鍵（上述した秘密鍵）を保有していることを意味する。

さらに、上述の例では、各ドメインＤに認証手段ＡＭと認証用データベース記憶手段ＤＳとが対応付けられている。すなわち、３つの認証手段ＡＭ１，ＡＭ２，ＡＭ３と、３つの認証用データベース記憶手段ＤＳ１，ＤＳ２，ＤＳ３とが設けられている。しかしながら、３つの認証手段ＡＭ１〜ＡＭ３の機能をすべて有する１つの認証手段が設けられていてもよい。また、３つの認証用データベースＤＳ１〜ＤＳ３の機能をすべて有する１つの認証用データベース記憶手段を有していてもよい。

以上述べたように本実施形態の認証システムは、情報通信網に設けられ利用者が利用するノードとサービスを提供するノードとを含む複数のノードと、情報通信網に設定した複数のドメインを有し利用者が利用する１つのノードに対してドメインごとに異なる秘密鍵が事前に登録された認証用データベースと、認証用データベースにノードを照合し当該ノードが属するドメインでの秘密鍵を取得する認証手段と、利用者が利用するノードにサービスを提供するノードを関連付けるアカウントが登録されるユーザ情報データベースと、利用者が利用するノードから所属するドメインの変更要求を受けると当該ノードに関するアカウントがユーザ情報データベースに登録されていることを確認し認証手段を通して当該ノードについて変更後のドメインにおける秘密鍵を取得して変更後の秘密鍵をノードに配布する鍵配布手段とを有し、認証手段は、利用者の利用するノードが変更後のドメインで用いる秘密鍵を取得した後に、変更後のドメインにおいて当該ノードが他のノードと通信する際に用いるセッション鍵を発行するとともに、当該ドメインで用いる秘密鍵によるメッセージ認証を行ったセッション鍵を各ノードに配布することを特徴とする。

すなわち、本実施形態の認証システムは、利用者が利用する利用者ノードＮｕと、所属するドメインＤに対応するサービスを提供する複数のサービスノードＮｓと、認証用データベース記憶ユニットＤＳと、認証ユニット（認証手段）ＡＭと、ユーザ情報データベース記憶ユニットＤＳｕと、鍵配布ユニット（鍵配布手段）ＫＤ１と、を備える。認証用データベース記憶ユニットＤＳは、利用者ノードＮｕの秘密鍵がドメインＤ（Ｄ１〜Ｄ３）ごとに予め登録された認証用データベース（ＤＢ１〜ＤＢ３）を記憶するように構成される。利用者ノードＮｕの秘密鍵はドメインＤ毎に互いに異なっている。ユーザ情報データベース記憶ユニットＤＳｕは、利用者ノードＮｕにドメインＤを関連付けるアカウントが登録されるユーザ情報データベースＤＢｕを記憶するように構成される。利用者ノードＮｕは、利用者ノードＮｕが所属している現在のドメインＤから利用者ノードＮｕが所属を希望する希望ドメインＤへの変更を要求するにあたって、ドメイン変更要求を鍵配布ユニットＫＤ１に情報通信網ＮＴを通じて送信するように構成される。鍵配布ユニットＫＤ１は、利用者ノードＮｕからドメイン変更要求を受け取った場合に、ユーザ情報データベースＤＢｕに利用者ノードＮｕに希望ドメインＤを関連付けるアカウントが登録されていれば、認証用データベースＤＢ１〜ＤＢ３を利用して、希望ドメインＤに対応する利用者ノードＮｕの秘密鍵を取得して利用者ノードＮｕに情報通信網ＮＴを通じて送信するように構成される。認証ユニットＡＭは、利用者ノードＮｕが希望ドメインＤに対応する秘密鍵を取得した後に、希望ドメインＤにおいて利用者ノードＮｕと希望ドメインＤに属するサービスノードＮｓとの間の暗号化通信に用いられるセッション鍵を発行し、発行されたセッション鍵を希望ドメインＤに対応する秘密鍵で暗号化して情報通信網ＮＴを通じて利用者ノードＮｕに送信するように構成される。

本実施形態の構成によれば、利用者が利用するノードＮ０が所属するドメインＤをあらかじめユーザ情報データベースＤｂｕに登録しておき、アカウントが設定されているときには、鍵配布手段ＫＤ１によりドメインＤに応じた秘密鍵をノードＮに配布し、当該秘密鍵を用いてセッション鍵を配布するから、秘密鍵の配布にあたってアカウントの設定を用いることによって、秘密鍵により規定されるドメインＤを安全に変更することができる。しかも、各ドメインＤに対応する秘密鍵を用いてセッション鍵を配布するから、セッション鍵はドメインＤを超えて使用されることがなく、サービスの提供範囲をドメインＤの範囲内に制限することができる。

また、利用者が操作する入力装置の操作によりアカウントを登録する登録手段がユーザ情報データベースに付設されていてもよい。

すなわち、好ましい形態では、ユーザ情報データベース記憶ユニットＤＳｕに接続された登録ユニット（登録手段）ＲＧ１を備える。登録ユニットＲＧ１は、利用者が操作する入力装置ＩＭの操作によりアカウントをユーザ情報データベースＤＢｕに登録するように構成される。

このように、ユーザ情報データベースＤＢｕにアカウントを設定する際に利用者が操作する入力装置ＩＭを用いる構成を採用すれば、アカウントの設定と秘密鍵の配布とが独立して行われ、秘密鍵の配布の際の安全性を高めることができる。

さらに、ドメインのうちのいずれかでは、ノードが利用者の利用するノードと連携して動作することをサービスとして提供し、登録手段は、連携して動作するノードの組を入力装置の操作によりグループとしてユーザ情報データベースに登録する機能を有し、認証手段は、利用者が利用するノードから当該ドメインに所属するようにドメインの変更が要求されると、ユーザ情報データベースにグループが登録されているときに当該ドメインで用いる秘密鍵を配布するようにしてもよい。

すなわち、より好ましい形態では、複数のサービスノードＮｓのうちの連携サービスノードＮ３は、利用者ノードＮｕと連携して動作するサービスを提供するように構成される。登録手段ＲＧ１は、利用者ノードＮｕと連携サービスノードＮ３との組を入力手段（入力装置）ＩＭの操作によりグループとしてユーザ情報データベースＤｂｕに登録する機能を有する。鍵配布ユニットＫＤ１は、利用者ノードＮｕからドメイン変更要求を受け取った場合に、ユーザ情報データベースＤｂｕに利用者ノードＮｕと希望ドメインＤとを関連付けるアカウントが登録されており、かつ、利用者ノードＮｕと希望ドメインＤに属する連携サービスノードＮ３との組がユーザ情報データベースＤｂｕにグループとして登録されていれば、認証用データベースＤＢ１〜ＤＢ３を利用して、希望ドメインＤに対応する利用者ノードＮｕの秘密鍵を取得して利用者ノードＮｕに情報通信網ＮＴを通じて送信するように構成される。

このように、ドメインＤに所属する複数台のノードＮをグループとして連携させる際に、ユーザ情報データベースＤＢｕにおいてグループになるノードＮが登録されているときに、ノードＮの連携を可能にするドメインＤ（Ｄ３）で用いる秘密鍵の配布を可能にする構成を採用すれば、利用者のアカウントだけではなくグループを確認することで、秘密鍵をより安全に配布することが可能になる。

鍵配布手段は、利用者が利用するノードから所属するドメインの変更が要求されることにより当該ドメインにおける秘密鍵を当該ノードに配布した後に、当該ノードから確認応答を受け取ると、変更前のドメインで用いていた秘密鍵のエントリを前記認証用データベースから削除することができる。

すなわち、好ましい形態では、鍵配布ユニット（鍵配布手段）ＫＤ１は、ドメイン変更要求に応じて希望ドメインに対応する秘密鍵を利用者ノードＮｕに送信した後に、利用者ノードＮｕから確認応答を受け取ると、現在ドメインＤに対応する秘密鍵を認証用データベースＤＢ１〜ＤＢ３から削除するように構成される。

このように、秘密鍵をノードＮに配布した後に確認応答を受け取った後に、認証用データベースＤＢ１〜ＤＢ３における秘密鍵（のエントリ）を削除する構成を採用すれば、通信の異常などによりノードＮが持つ秘密鍵と認証用データベースＤＢ１〜ＤＢ３における秘密鍵のエントリとに矛盾が生じるという事態を避けることができ、ノードＮが所属するドメインＤの変更を確実に行うことができる。

さらに、利用者の利用するノードは、認証手段からセッション鍵を取得できなくなると、ノードが所属しているドメインごとにあらかじめ定められた順番で他のドメインに対応する認証手段からのセッション鍵の取得を試みるようにしてもよい。

すなわち、好ましい形態では、利用者ノードＮｕは、認証ユニットＡＭから現在のドメインＤに対応するセッション鍵を取得できなくなると、利用者ノードＮｕが所属しているドメインＤにあらかじめ定められた順番で他のドメインＤに対応するセッション鍵を要求するように構成される。

このように、利用者の利用するノードＮｕが認証手段ＡＭからセッション鍵を取得できなくなると、他のドメインＤの認証手段ＡＭからのセッション鍵の取得を試みる構成を採用すれば、セッション鍵を用いた通信が不通になった場合でも、優先度に従って通信を回復できる可能性が高くなる。たとえば、サービスに対価を支払っているドメインＤでセッション鍵を取得することができない場合に、対価が不要なサービスを行うドメインＤで用いるセッション鍵の取得を要求すれば、ノードに残されている秘密鍵を用いてセッション鍵が取得可能な場合があり、このような事例においてノードはセッション鍵を取得し、あらためてドメインＤの変更を要求することが可能になる。

また、サービスを提供するノードは複数種類のサービスを提供可能であって、認証用データベースは、各ノードが提供するサービスごとにアクセス制限を行う情報を持ち、認証手段は、ノードへのセッション鍵の配布を行う際にアクセス制限の情報をノードに設定するようにしてもよい。

すなわち、好ましい形態では、サービスノードＮｓは複数種類のサービスを提供するように構成される。認証用データベースＤＢ１〜ＤＢ３には、各サービスノードＮｓが提供するサービスごとにアクセス制限を行うためのアクセス制限情報が登録される。認証ユニットＡＭは、利用者ノードＮｕおよびサービスノードＮｓにセッション鍵を配布する際にアクセス制限情報を利用者ノードＮｕおよびサービスノードＮｓに設定するように構成される。

このように、サービスを提供するノードＮが複数種類のサービスを提供可能である場合には、認証用データベースＤＢ１〜ＤＢ３においてサービスごとにアクセス制限を行うようにすれば、サービスの提供範囲をドメインの範囲に制限することに加えて、サービスを単位としてアクセスの範囲を制限することになり、サービスをより限定した範囲で提供することが可能になる。したがって、サービスに対価を求めるドメインＤを規定している場合に、サービスの単位でアクセス制限を行うことにより、料金に応じてサービスの内容を異ならせるという対応が可能になる。

Claims (6)

1. 利用者が利用する利用者ノードと、
   所属するドメインに対応するサービスを提供する複数のサービスノードと、
   認証用データベース記憶ユニットと、
   認証ユニットと、
   ユーザ情報データベース記憶ユニットと、
   鍵配布ユニットと、を備え、
   上記認証用データベース記憶ユニットは、上記利用者ノードの秘密鍵が上記ドメインごとに予め登録された認証用データベースを記憶するように構成され、
   上記利用者ノードの秘密鍵は上記ドメイン毎に互いに異なっており、
   上記ユーザ情報データベース記憶ユニットは、上記利用者ノードに上記ドメインを関連付けるアカウントが登録されるユーザ情報データベースを記憶するように構成され、
   上記利用者ノードは、上記利用者ノードが所属している現在のドメインから上記利用者ノードが所属を希望する希望ドメインへの変更を要求するにあたって、ドメイン変更要求を上記鍵配布ユニットに上記情報通信網を通じて送信するように構成され、
   上記鍵配布ユニットは、上記利用者ノードから上記ドメイン変更要求を受け取った場合に、上記ユーザ情報データベースに上記利用者ノードに上記希望ドメインを関連付ける上記アカウントが登録されていれば、上記認証用データベースを利用して、上記希望ドメインに対応する上記利用者ノードの上記秘密鍵を取得して上記利用者ノードに上記情報通信網を通じて送信するように構成され、
   上記認証ユニットは、上記利用者ノードが上記希望ドメインに対応する上記秘密鍵を取得した後に、上記希望ドメインにおいて上記利用者ノードと上記希望ドメインに属する上記サービスノードとの間の暗号化通信に用いられるセッション鍵を発行し、上記発行されたセッション鍵を上記希望ドメインに対応する上記秘密鍵で暗号化して上記情報通信網を通じて上記利用者ノードに送信するように構成される
   ことを特徴とする認証システム。
2. 上記ユーザ情報データベース記憶ユニットに接続された登録ユニットを備え、
   上記登録ユニットは、上記利用者が操作する入力装置の操作により上記アカウントを上記ユーザ情報データベースに登録するように構成される
   ことを特徴とする請求項１記載の認証システム。
3. 上記複数のサービスノードのうちの連携サービスノードは、上記利用者ノードと連携して動作するサービスを提供するように構成され、
   上記登録手段は、上記利用者ノードと上記連携サービスノードとの組を上記入力装置の操作によりグループとして上記ユーザ情報データベースに登録する機能を有し、
   上記鍵配布ユニットは、
   上記利用者ノードから上記ドメイン変更要求を受け取った場合に、
   上記ユーザ情報データベースに上記利用者ノードと上記希望ドメインとを関連付ける上記アカウントが登録されており、かつ、上記利用者ノードと上記希望ドメインに属する上記連携サービスノードとの組が上記ユーザ情報データベースに上記グループとして登録されていれば、
   上記認証用データベース記憶手段に記憶された上記認証用データベースを利用して、上記希望ドメインに対応する上記利用者ノードの上記秘密鍵を取得して上記利用者ノードに上記情報通信網を通じて送信するように
   構成されている
   ことを特徴とする請求項２記載の認証システム。
4. 上記鍵配布ユニットは、上記ドメイン変更要求に応じて上記希望ドメインに対応する上記秘密鍵を上記利用者ノードに送信した後に、上記利用者ノードから確認応答を受け取ると、上記現在ドメインに対応する上記秘密鍵を上記認証用データベースから削除するように構成される
   ことを特徴とする請求項１記載の認証システム。
5. 上記利用者ノードは、上記認証ユニットから現在の上記ドメインに対応する上記セッション鍵を取得できなくなると、上記利用者ノードが所属している上記ドメインにあらかじめ定められた順番で他の上記ドメインに対応する上記セッション鍵を要求するように構成されている
   ことを特徴とする請求項１記載の認証システム。
6. 上記サービスノードは複数種類のサービスを提供するように構成され、
   上記認証用データベースには、上記各サービスノードが提供するサービスごとにアクセス制限を行うためのアクセス制限情報が登録され、
   上記認証ユニットは、上記利用者ノードおよび上記サービスノードに上記セッション鍵を配布する際に上記アクセス制限情報を上記利用者ノードおよび上記サービスノードに設定するように構成される
   ことを特徴とする請求項１記載の認証システム。

Images