JP4382659B2 - ネットワークセキュリティ - Google Patents

Description

本発明は、複数のデバイスを含み、各デバイスはネットワーク内の他のデバイスと無線通信できるネットワーク、およびネットワーク内で選択されたデバイスをドメイン内で関連付けできる方法に関する。

ＧＢ−Ａ−２３６９９６４、ＧＢ−Ａ−２３６６１３１、およびＷＯ−Ａ−００／６９１８６は、Ｂｌｕｅｔｏｏｔｈネットワークに関連する。Ｂｌｕｅｔｏｏｔｈは、ポイントツーポイント（マスターから１つのスレーブへ）とポイントツーマルチポイント（マスターから複数のスレーブへ）の両方の接続をサポートする。２つのスレーブが互いに通信できるのは、マスターを介して、あるいはスレーブツーマスタースイッチを使用してスレーブをマスターに変更する場合のみである。

本発明により、複数のデバイスを含み、各デバイスはネットワーク内の他のデバイスと無線通信できるネットワークが提供される。デバイスの１つは、各デバイスに識別データを提供することにより、選択されたデバイスをドメイン内で関連付けできる管理手段を備えている。各デバイスの識別データはドメイン内の他のデバイスのそれぞれによって解釈でき、こうした識別データを有するドメイン内のデバイス間に限り、特定の直接通信モードを利用できる。

また、本発明の別の側面により、ネットワーク内の選択されたデバイスをドメイン内で関連付けでき、各デバイスはドメイン内の他のデバイスと無線通信できる方法が提供される。この方法には各デバイスに識別データを提供するドメイン内の１つのデバイスを指定するステップが含まれており、各デバイスの識別データは他のデバイスのそれぞれによって解釈でき、特定の直接通信モードはこうした識別データを有するドメイン内のデバイス間でのみ許可される。

本発明についての理解を深めるために、ここで例として添付の図面に関連付けながら実施形態について説明する。

図１に、１人のユーザーに属する複数のデバイスを含むパーソナルエリアネットワーク（ＰＡＮ）１を示す。ＰＡＮ １内では、すべての個々のデバイスがそれぞれ同じユーザーに属する他のデバイスとシームレスに通信でき、リソースを共有できることが望まれる。セキュリティの立場からすれば、この場合は個々のデバイスがサービスを提供または要求する場合に所有するユーザーの同じ他のデバイスを識別する必要がある。さらに、データの機密性を保護するために、個々のデバイスは互いにセキュリティを保護しながら通信する必要がある。ＰＡＮ １内のデバイスの数とデバイスが提供するサービスによっては、こうした通信が非常に複雑になる場合がある。時間の経過に伴ってＰＡＮ ｌにデバイスが追加されたり削除がされたりしてデバイスの数が変化するので、問題はさらに複雑になる。

ＰＡＮは、デバイス間の通信がサーバーを経由しない従来の通信とは異なる。
ＰＡＮ内のこのように多くのデバイスが整合性のある動作をすることが見込まれる場合は、個々のデバイスが動作するために必要な所有権と特権を考慮した分散端末アーキテクチャに、すべてのデバイスが適合する必要がある。

図１で、パーソナルエリアネットワーク１内のデバイスは、ＧＰＲＳ移動電話３、ラップトップコンピュータ５、携帯情報端末（ＰＤＡ）装置７である。矢印で示すように、デバイス３、５、７はそれぞれＰＡＮ １内の他のデバイスと通信できる。この例では、デバイス３、５、７はそれぞれＢｌｕｅｔｏｏｔｈデバイスであり、デバイス３、５、７は相互運用可能である。デバイス３、５、７間のデータ通信は、赤外線通信、電波通信、あるいは他のいかなる無線通信でもよい。

たとえば、ＰＤＡ ７は移動電話３に接続してインターネットにアクセスし、ラップトップコンピュータ５に接続してユーザーのカレンダーの同期化やその他の理由によるファイル交換を行う。

従来、デバイス３、５、７の任意のペアが互いに通信するには、それらを別々に設定する必要があった。このためには、３つの個別の設定プロセスが必要である。たとえば、ラップトップ５とＰＤＡ ７、ラップトップ５と移動電話３、移動電話３とＰＤＡ ７の間の設定である。初期設定プロセスが完了すると、デバイス３、５、７は互いに通信できるが、このためには互いに通信する２つのデバイスのそれぞれからユーザーが手作業で通信モードを選択する必要がある。デバイスは、１組のデバイス間のファイル交換を開始する前に、ユーザーに個人識別番号（ＰＩＮ）の入力を要求するように設定してもよい。これは、たとえば好ましくないデバイスがデバイス３、５、７のいずれかに取って代わり、ＰＡＮ １内のデバイスからデータを取得したり上書きしたりするのを防ぐためである。

このようなＰＡＮ １でＭＰ３プレーヤー９などのデバイスの追加を希望する場合は、ＰＡＮ １内のデバイス３、５、７のそれぞれについてＭＰ３プレーヤー９と通信できるように別々に設定する必要がある。ＰＡＮ １内のデバイスの数が増えるに従って、ＰＡＮ １に新しいデバイスを追加することによる設定のステップ数も増えるのは言うまでもない。ｎ個のコンポーネントを含む従来のＰＡＮの場合、ＰＡＮを構成するには、ｎ＊（ｎ−１）／２個のコンポーネントの関連付けを行う必要がある。

本発明の１つの側面により、ＰＡＮ内のデバイスのグループはＰＡＮセキュリティドメイン（ＰＳＤ）を構成する。ＰＳＤは、ＰＡＮ内のコンポーネントのグループであり、一般的なセキュリティ関連付けの手段により、各コンポーネントを自動的に認証し、信頼し、安全に通信することができる。このことにより、必要なコンポーネント関連手続きの数が少なくなる。

ＰＳＤでは、１つのデバイスがＰＳＤアドミニストレータの役割を果たす。このデバイスには、ＰＳＤに参加する他のデバイスに選択的に渡されるセキュリティデータ（たとえば、共有キーまたはパブリックキーとプライベートキーのペア）が含まれる。通信が正常に行われるのは、このセキュリティデータを有するデバイス間に限られる。デバイスがセキュリティデータを取得すると、ＰＳＤアドミニストレータを参照せずにＰＳＤ内の他のデバイスと通信できる。ＰＳＤにデバイスが追加されると、ＰＳＤアドミニストレータはＰＳＤに新しいデバイスが追加されたことを各デバイスに通知する。ＰＳＤ内にｎ個のデバイスがある場合は、ｎ−１とおりのデバイス間通信が必要である。新しいデバイスは、自らとＰＳＤ内の他のデバイスのそれぞれとの間で個別にペアを構成する必要もないし、関連付けを作成する必要もない。

セキュリティ関連付けは、パブリックキーテクノロジーに基づく共有秘密キーまたは共有グループキーの形式であり、ＰＳＤ内の個人認証機関（ＣＡ：ｃｅｒｔｉｆｉｃａｔｉｏｎ ａｕｔｈｏｒｉｔｙ）によってデバイス間に確立された相互「信頼」を伴う。ＰＳＤのすべてのメンバーに発行された証明書は、デバイスがそのＰＳＤのメンバーであることを示す。グループキーはＰＳＤ内の２デバイス間の安全な通信には使用されない。このような通信は、２デバイス間で確立されたキーを使用して行われる。つまり、ＡとＢとの２デバイス間の安全な通信を許可するＫＡＢ、ＢとＣとの２デバイス間の安全な通信を許可するＫＢＣ、およびＡとＣとの２デバイス間の安全な通信を許可するＫＡＣである。これらについては後で詳細に説明する。グループキーはＰＳＤのメンバーであることの証明、ＰＳＤ全体に及ぶ安全なブロードキャスト、およびＰＳＤ全体に及ぶ安全な通信のみに使用される。

デバイスがＰＳＤのメンバーかどうかの最初の決定はユーザーの判断に基づいており、パブリックキー構成インフラストラクチャ（ＰＫＩ：ｐｕｂｌｉｃ ｋｅｙ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）信頼ルート証明書に基づくデバイスのポジティブ認証が続く。あるいは、別の既知の認証方法を使用してもよい。

ＰＳＤ内では、１つのデバイスがＰＳＤアドミニストレータとして指名される。ＰＳＤアドミニストレータは、その役割を果たすために必要なハードウェア（たとえばセキュリティキーの記憶場所やディスプレイなど）を備えている場合に、ＰＳＤ内の任意のデバイスに対して想定できる役割である。アドミニストレータの役割は、１つのデバイスから別のデバイスに移動してもよい。アドミニストレータの役割が新しいデバイスに移動する場合は、必要なセキュリティデータを新しいデバイスに渡すか事前に保存すると、新しいデバイスがＰＳＤとして認められる。

ＰＳＤアドミニストレータは、ＰＳＤ内のデバイスの制御ポリシー（後述）の設定と管理について責任を負う。さらに、ＰＳＤ内の新しいメンバーの登録にも責任を負う。ＰＳＤアドミニストレータには、ＰＳＤメンバーへの証明書の発行を担当する個人ＣＡも含まれる。ＰＳＤアドミニストレータは、最大の処理能力と最適なユーザーインターフェイスを備えたデバイスであるのが有利である。図１に示すＰＡＮ １に基づくＰＳＤにおいて、アドミニストレータはラップトップ５である。

１人のユーザーがＰＳＤ内のすべてのデバイスを所有しており、そうしたデバイスを同等に処理する場合、このような構成にはデバイスの識別情報に基づく制限は一切含まれていない。すべての共有リソースは、ＰＳＤのメンバーであるすべてのデバイスが利用できるようになる。換言すれば、デバイス間にグループの「信頼」が存在する。デバイスがＰＳＤのメンバーであれば、他のデバイスはこのデバイスを信頼でき、このデバイスと通信できることを想定する。上に説明した従来のＰＡＮとは異なり、デバイスごとに他のデバイスのそれぞれとの間に個別の信頼関係を設定する必要はない。デバイスがＰＳＤアドミニストレータによってグループへの参加を許可された場合、他のデバイスは新しく参加したデバイスが信頼できることを想定する。

図２に、Ａ〜Ｆという６つのデバイスを含むＰＡＮ １１を示す。図２に示すデバイスはすべてＰＤＡであるが、図１に示すように、他のタイプのデバイスでもよいこと、またはさまざまなデバイスの組合わせでもよいことは言うまでもない。デバイスＡ、Ｂ、Ｃは同一のユーザー（ユーザー１）が所有しており、ＤとＥは別のユーザー（ユーザー２）が所有している。３人目のユーザー（ユーザー３）はデバイスＦを所有している。これらのすべてのデバイスは、それぞれのローカルインターフェイスを使用して他のデバイスと通信できる。

第１のＰＳＤ １３にはデバイスＡ、Ｂ、Ｃが含まれる。これらのデバイスは、リソースを共有でき、互いに安全に通信できる。第２のＰＳＤ １５にはデバイスＤとＥが含まれる。この場合も、デバイスはリソースを共有でき、互いに安全に通信できる。
１つのＰＳＤのメンバーシップがデバイスＡ、Ｂ、Ｃのように１人のユーザーに限定される場合は、２人のユーザーが任意のリソースを共有することはできない。リソースの共有が可能なのは、既存のＰＳＤがＰＳＤ間でリソースを共有できるように設定されている場合である。

２人のユーザーがリソースを共有するためのより効果的で好ましい方法は、新しいＰＳＤを確立することである。状況に応じて、ＰＳＤは共有する必要のあるデバイスを含む一時的なＰＳＤでも永続的なＰＳＤでもよい。

図３に、デバイスＢ、Ｃ、Ｅ間に確立された新しいＰＳＤ １７を示す。この場合は、ユーザー１とユーザー２が所有する２つのデバイス間にセキュリティ関連付けが必要である。この関連付けは、新しいＰＳＤの一部になる全く同じデバイス間でなくてもよい。元のＰＳＤがそのすべてのメンバーデバイスに必要なデータを送信し、新しいデバイスをこのＰＳＤに導入してもよい。あるいは、ユーザー１とユーザー２が２つのデバイス（ユーザーごとに１つずつ）をペアにしてから、必要に応じて元のデバイスの１つをＰＳＤアドミニストレータとして使用してさらにデバイスを追加してもよい。

異なるユーザーが所有するデバイスを含むＰＳＤを構成する場合は、ＰＳＤアドミニストレータを指名するのは必ずしも容易ではない。ＰＳＤ内のすべてのパーティーによる相互同意が必要な場合もある。最初にＰＳＤを構成したデバイスがこの役割を果たしてもよい。しかし、必要に応じてＰＳＤ内の別のデバイスに役割を引き継ぐことができる。

これで、個々のユーザーは所有するデバイスが新しく構成されたＰＳＤのメンバーとの間で必要なリソースを共有するように設定できる。
ユーザー１はＢとＣのポリシーを設定し、ユーザー２はＥのポリシーを設定する。個々のデバイスには、ＰＳＤの別々のユーザーが起動できる多くの組み込みまたは事前の設定を含めることができる。

必要に応じて、同一のユーザーが所有するデバイスセット内にさまざまなグループを確立する場合にもＰＳＤを利用できる。
ユーザー１とユーザー２の間の一時的なＰＳＤ以外に、いずれかのユーザーが別のＰＳＤを確立してユーザー３とリソースを共有することもできる。ＰＳＤの概念をシンプルに維持するために、ユーザー２は所有するデバイスの１つ、たとえばＥを使用してユーザー１とユーザー３の間のＰＳＤを確立することはできない。つまり、Ｅは２つの別々のＰＳＤの間の信頼を橋渡しすることはできない。ただし、ＥをＰＳＤアドミニストレータとしてユーザー１とユーザー３のデバイスを含むＰＳＤを構成すれば可能である。

デバイスＢ、Ｃ、Ｅ（それぞれの識別情報をＩＤＢ、ＩＤＣ、ＩＤＥとする）間のＰＳＤの編成については、図４を参照しながら詳細に説明する。これらのデバイスがＰＳＤを構成するためには、３つのデバイス間に２つのセキュリティ関連付けが必要である。たとえば、｛Ｂ，Ｃ｝と｛Ｃ，Ｅ｝でもよい。これらの関連付けに基づいて、ＢとＣ、およびＣとＥは安全に通信できる。デバイスＣはＰＳＤアドミニストレータの役割を果たす。ここで、ＣはグループＰＳＤメンバーシップキーＫＰＳＤを生成する。さらに、ＣがＰＳＤのすべてメンバーの識別情報を他のデバイスのそれぞれに伝達する。つまり、ＩＤＢをＥに、ＩＤＥをＢにそれぞれ送信する。これで、ＫＰＳＤと共にＢとＥが互いに安全に通信するための別のキーＫＢＥを生成する準備が整う。図４は、デバイス間のデータ交換を示している。

あるいは、デバイスＣが個人ＣＡの役割を果たし、ＢとＥに対してローカルＰＫＩを使用して前述のキー交換を行うための証明書を発行することもできる。この証明書を所有することは、ＫＰＳＤにアクセスできるのと同等である。つまり、ＰＳＤのメンバーシップの証明である。

ただし、ＰＳＤ自体を構成するために個々のデバイス自体の動作に関する何らかのパターンやルールが要求されることはない。これらは、必ず適切な「ポリシー」を介して達成される。このポリシーは、動作に関するガイドラインを設定し、さまざまな環境でのリソースの使い方やデバイスの動作を説明する。

ＰＳＤポリシーを使用すると、以下の任意の制限を課すことができる。
ａ．使用可能なリソース
ｂ．ＰＳＤのメンバーとなるための要件
ｃ．ＰＳＤアドミニストレータの役割を果たすための要件
ｄ．ユーザーインタラクション
ｅ．有料のサービスの使い方
ｆ．新しいアプリケーションのインストール
複数のユーザーが所有するデバイスがＰＳＤのメンバーになってもよい。

ＰＳＤポリシーファイルは、デバイス間での相互運用性を提供するために標準化された形式をとっており、所属するＰＳＤによってさまざまなデバイスで使用可能なリソースに関する情報を格納する。このファイルにリストアップされたすべてのリソースが、いつでもＰＳＤで利用できるわけではない。これらの項目には、該当するリソースがＰＳＤで利用できる場合に、さらに詳細な使い方を指定できる。

各デバイスは、その特定のデバイスに所属するどのリソースをＰＳＤのその他のメンバーが利用できるかを指定する独自のバージョンのポリシーファイルを所有する。したがって、リソースに関してＰＳＤへのかかわり方の異なる２つのデバイスのポリシーファイルは異なっている。リソースがＰＳＤに追加されたりＰＳＤから削除されたりすると、デバイスはポリシーファイルを更新または変更できる。あるいは、デバイスはデバイスに代わってこの作業をするようにＰＳＤアドミニストレータに依頼してもよい。

アクセスコントロールメカニズムによっては、ポリシーファイルをローカルに、つまりデバイス上に保存する必要がある。それでも、デバイスは信頼できるデバイスからポリシー情報を要求し、取得することができる。この信頼できるデバイスは、同じＰＳＤのメンバーでなくてもよい。

デバイスポリシー内の各項目の重要性について以下に説明する。

ＰＳＤポリシーファイルの例

「リソースの種類とＩＤ」
これには、リソースのＩＤと種類に関する情報が含まれる。コンポーネント内のリソースを一意に識別するには、ＩＤが必要である。リソースの種類は、リソースに適用できる「許可の種類」（後述）を指定する場合に重要である。

コンポーネント上のさまざまなリソースは、ホストコンポーネントとそのユーザーへの影響に基づいて、大きく４つの領域に分類できる。
１．ローカルサービス−プリンタ、プロジェクタなど
２．ネットワークインターフェイス−ＧＳＭ、ＧＰＲＳ、ＢＴ、ＩｒＤＡ、ＷＬＡＮなど、あるいは同様のネットワーク接続に関連するリソース
３．個人情報管理−カレンダー、電話帳、場所に関する情報など、個人的に重要であり、プライバシーの問題を伴う情報
４．実行可能ファイル−別のコンポーネントからターゲットデバイスにダウンロードできるコード
以上はリソースの例にすぎない。

「ターゲットＩＤ」
リソースが配置されているコンポーネントを一意に識別する。リソースがＰＳＤ内の複数のコンポーネントから使用できる場合に、ＰＳＤ内のリソースを識別するのに有効である。

「認証ＩＤ」
ＰＳＤのメンバーは、ポリシーファイルで使用可能とされたすべてのＰＳＤリソースにアクセスできる。ＰＳＤがＰＳＤアドミニストレータに依存する場合、認証ＩＤはＰＳＤアドミニストレータの役割を想定されるコンポーネントのＩＤである。コンポーネントが自らの所有するリソースへの他のコンポーネントによるアクセスを主体的に認証できる場合、認証ＩＤはターゲットＩＤと同じである。複数のユーザーが所有する複数のデバイスがある場合、デバイスはＰＳＤアドミニストレータに依存せず、独自に認証する機能を備えている。

図５にＰＳＤ １９内のデバイス１８を示す。このデバイスには、前述のＰＳＤポリシーデータを格納するＰＳＤポリシー命令（ＰＰ：ＰＳＤ ｐｏｌｉｃｙ）２０が含まれる。

デバイス１８は、ＰＳＤ １９内の他のデバイス３０および３２が利用できるリソース２２と２４への関連付けを行う。たとえば、デバイスがラップトップコンピュータならばこのようなリソースは液晶ディスプレイやプリンタでもよい。また、デバイスが移動電話ならばリソースは移動電話に保存されたＳＭＳ送信／受信や個人電話帳でもよい。もちろん、これらがデバイスとリソースの例にすぎないことは言うまでもない。

デバイス１８には、コンポーネントポリシー命令（ＣＰ：ｃｏｍｐｏｎｅｎｔ ｐｏｌｉｃｙ）２６も含まれる。これらの命令は、ローカル要求、すなわちデバイス１８自体からの要求に対するリソース２０、２４の割り当てを制御する。これらの命令は、一般的に従来の方法でローカルリソースの使い方を制御し、ＭＩＤＰ ２．０標準で使用するセキュリティポリシーに非常によく似た機能を提供する。

デバイス１８には、さらにコンポーネントＰＳＤプロファイル命令（ＣＰＰ：ｃｏｍｐｏｎｅｎｔ ＰＳＤ ｐｒｏｆｉｌｅ）２８が含まれる。これらの命令は、ＰＳＤ １９内の他のデバイス３０および３２によるリソース２２とおよび２４の使い方を制御する。デバイス１８が複数のＰＳＤのメンバーである場合は、複数のＰＳＤポリシー命令セットと複数のコンポーネントＰＳＤプロファイル命令を備えている。ただし、この例では簡単のためにデバイス１８がＰＳＤすなわちＰＳＤ １９の唯一のメンバーである。

一般に、リソース２０、２４を使用するためのコンポーネントポリシー命令２６における制限は、ＰＳＤ １９内の他のメンバー３０、３２からの要求にも適用されることが説明されている（ただし、本発明がこれに制限されるわけではない）。したがって、コンポーネントＰＳＤポリシー命令２８には、コンポーネントポリシー命令２６の制限が含まれる。

さらに、通常はコンポーネントＰＳＤプロファイル２８には、ＰＳＤ １９内の他のデバイス３０、３２によるリソース２０、２４の使い方に関する別の制限が課される。たとえば、デバイス１８がＧＰＲＳモバイル端末の場合、コンポーネントＰＳＤプロファイルを使用すると、モバイル端末をモデムとして使用してデバイス３０、３２にデータをダウンロードするが、特定の期間内（たとえば２４時間）にダウンロードされるデータのサイズは最大５００ ＫＢに制限される。

デバイス３０、３２からのサイズを超えるデータのダウンロード要求が受信された場合に、デバイス１８のユーザーに対して、サイズを超えるデータのダウンロードが要求されたことを示し、サイズを超えるデータのダウンロードに関する認証を求める（画像または音声による）プロンプトがモバイル端末に表示されるように、コンポーネントＰＳＤプロファイル２８を設定してもよい。たとえば、コンポーネントＰＳＤプロファイル２８を使用すると、モバイル端末に保存された個人電話帳にアクセスできるが、モバイル端末に保存されたＳＭＳメッセージにはアクセスできないようにすることもできる。

もちろん、これらがリソース共有の例にすぎないことは言うまでもない。コンポーネントＰＳＤプロファイル２８は、デバイス１８が提供する任意のリソースの共有を禁止するようにも許可するようにも設定できる。コンポーネントＰＳＤプロファイル２８は、リソースの使用量の制限やリソース使用の認可に関するユーザープロンプトの要求など、リソースの使い方に関する制限も設定する。もちろん、コンポーネント３０および３２は、ＰＳＤ １９内のデバイス１８と共有できる独自のリソースを所有しており、ＰＳＤポリシー命令、コンポーネントポリシー命令、およびコンポーネントＰＳＤプロファイル命令を含んでいる。ただし、簡単にするためにこのようなリソースは図５には示されていない。

デバイス１８の詳細な配置を図６に示す。セキュリティフレームワーク３４は、オペレーティングシステム３６を介してリソース２２および２４へのアクセスを制御する。このセキュリティフレームワークには、リソース２２および２４の使用に関するローカル要求（デバイス１８からの要求）を受け取る第１の入力ポート３８が含まれる。こうした要求を受け取ると、セキュリティフレームワーク３４はコンポーネントポリシー命令２６に問い合わせてリソース要求が許可されるかどうかを確認する。リソース要求が許可される場合、または条件付きで許可される場合は、この要求がオペレーティングシステム３６に渡され、ここでリソース２２、２４の適合する使い方が許可される。

セキュリティフレームワーク３４には、ＰＳＤ １９内の他のデバイス３０、３２からのリソース要求を受け取る入力ポート４０も含まれる。別のデバイスからのリソース２６、２５の使用に関する要求を受け取る手順については、図７に関連付けながら以下で詳細に説明する。

セキュリティフレームワーク３４には、さらにＰＳＤ １９内の他のデバイス３０、３２に対して外部リソースの使用に関する要求を送信するための出力ポート４２も含まれる。こうした要求に対するＰＳＤ １９の動作は、図７に関連付けながら以下の説明を参照することで明らかになる。

図７に、デバイス３０がデバイス１８のリソース２２を利用しようとする場合のＰＳＤ １９の動作を示す。図７に示すように、デバイス３０にはＰＳＤ １９内のリソース共有の処理に関して請求項１８と同様の構造が含まれる。図７で、デバイス３０の要素（デバイス１８の同様の要素に対応するもの）は、同じ参照番号で示し、後に「Ａ」を付ける。

図７の例で、デバイス１８はラップトップコンピュータであり、リソース２２はプリンタである。デバイス３０は移動電話であり、リソース２４ＡはＳＭＳメッセージの記憶領域である。デバイス３０のユーザーは、記憶領域２４Ａに保存されたＳＭＳメッセージを印刷しようとする。

デバイス３０のオペレーティングシステム３６Ａは、該当するＳＭＳと、ＳＭＳメッセージを印刷したいというメッセージをセキュリティフレームワーク３４Ａに渡す。セキュリティフレームワーク３４Ａは、ＰＳＤ １９内で利用できるリソースのリストが含まれるＰＳＤポリシー命令２０Ａに問い合わせる。ここに示す例では、ＰＳＤポリシー命令２０Ａはデバイス１８にプリンタリソース２２が含まれることを示している。ＳＭＳメッセージとこのメッセージを印刷する命令は、デバイス３０の出力ポート４２Ａとデバイス１８の入力ポート４０を介してデバイス１８に渡される。このデータは、前述の方法で、前述のようにキーを使用してエンコードされる。

デバイス１８のセキュリティフレームワーク３４は、ポート４０で受け取ったデータをデコードする。セキュリティフレームワーク３４は、コンポーネントＰＳＤプロファイル命令２６に問い合わせてリソース要求が許可されるかどうかを確認する。リソース要求が許可される場合は、要求がオペレーティングシステム３６を経由してリソース（プリンタ）２２に渡される。

ＰＳＤ内の個々のデバイスは同等に信頼可能でもよい。この場合、ＰＳＤ内のすべてのデバイスは同じ情報またはリソースにアクセスできる。逆に、ＰＳＤ内のデバイスはさまざまな「特権」を持っていてもよい。この場合、１つのデバイスは情報またはリソースにアクセスできるが、ＰＳＤ内の別のデバイスはこれらにアクセスできない。たとえば、１つのＰＳＤには２台のパーソナルコンピュータＰＣ ＡとＰＣ Ｂが含まれていてもよい。これらのパーソナルコンピュータは、ＰＣ ＡのみがＰＳＤユーザーの電子メール（保管場所はＰＣ Ａ上でもそれ以外の場所でもよい）にアクセスできるように設定できる。ＰＳＤ内の情報のアクセスに関するこうした制限（または特権）は、そのＰＳＤのポリシーファイルに保存できる。こうした制限または特権は、必要に応じてＰＳＤ内で変更できるのが好ましい。こうした変更は、通常はＰＳＤアドミニストレータの制御下で実行される。

「ＰＳＤには次のような利点がある。」
＊ＰＳＤの新しいメンバーは、他の既存のＰＳＤメンバーすべてとセキュリティ関連付けを共有し、信頼できる通信を確立する必要はない。たとえば、デバイスＤがＡ、Ｂ、Ｃで構成される既存のＰＳＤに参加する場合、このＰＳＤはグループキーＫＡＢＣで定義される。ＤがＡ（ＰＳＤアドミニストレータ）によって認証され、２デバイス（ＡとＤ）間の通信キーＫＡＤが確立すると、ＡはキーＫＡＤによる保護の下でＫＡＢＣをＤに送信する。これで、ＤはＰＳＤのメンバーであることを証明できるので、さらにＢとＣの２デバイス間の安全な通信キーを確立できる。

＊インプリンティングイベントが少なくなるので、必要なユーザーインタラクションも減少する。ｎ個のコンポーネントで構成されるＰＳＤでは、ｎ−１回のインプリンティングセッションのみが必要である。一方、ＰＳＤという概念のない従来のＰＡＮではｎ（ｎ−１）／２回である。

＊最適なユーザーインターフェイスを備えたデバイスをＰＳＤアドミニストレータとして使用して新しいメンバーを登録すると、常にユーザーが最も使いやすいインプリンティングプロトコルを利用できる。

＊失効確認機能を備えぬＰＳＤアドミニストレータを使用すると、証明書を有する新しいデバイスが登録されるときに失効確認が行われる。
＊一貫したリソース情報がすべてのデバイスに提供される。

＊自らが所有するデバイス間の対話に支障を来すことなく、他のユーザーとリソースを共有できる。
＊以下に示すグループの役割を指定できる。
・ＰＳＤ内の全てのデバイスと外部のデバイスの間でゲートウェイの役割を果たす１台のデバイス
・たとえば、カレンダー同期、失効確認のような専門のタスクを実行するデバイス

＊安全なブロードキャストを実行するための共有セキュリティ関連付けを使用できる。
＊ユーザーの代わりに管理タスクを実行するデバイス、すなわちＰＳＤアドミニストレータをユーザーが指定できる。

＊リンクレイヤセキュリティの最上位に別のセキュリティレイヤを確立できる。
＊ＰＡＮ内のさまざまな信頼グループについてさまざまなＰＳＤを作成し、特定のアクセス制御の問題を解決できる。

前述のＰＳＤの概念は、ＰＡＮ以外のネットワークにも適用できる。ネットワーク（およびドメイン）内のデバイスは、ｌａｒｇｅ ｄｉｓｔａｎｃｅｓによって分割してもよい。

デバイスは、特定のＰＳＤに自動的に登録されるように製造または事前設定が可能である。たとえば、移動電話は特定のＰＳＤの通信領域に入ると、そのＰＳＤに自動的に登録されるように設定できる。ただし、こうした自動登録が提供された場合は、個人情報がＰＳＤ内の他のデバイスに漏れないように、ＰＳＤ内のデバイス間のデータ交換は制限されるのが一般的である。

たとえば、列車運行会社でＰＳＤを配置し、適切にプログラミングされた移動電話を駅に自動的に登録すると、この電話に列車の運行情報を送信でき、ユーザーがこれを利用できる。

１人のユーザーに属する複数のデバイスを含むパーソナルエリアネットワーク（ＰＡＮ：ｐｅｒｓｏｎａｌ ａｒｅａ ｎｅｔｗｏｒｋ）を示す図である。 本発明によって構成される２つのＰＡＮセキュリティドメイン（ＰＳＤ：ＰＡＮ Ｓｅｃｕｒｉｔｙ Ｄｏｍａｉｎ）を有するパーソナルエリアネットワーク（ＰＡＮ）を示す図である。 図２に示すＰＡＮのもう１つのＰＳＤの構成を示す図である。 ＰＳＤ内のデバイス間のデータ交換を示す図である。 ＰＳＤ内のリソース共有に必要な構造を含むＰＳＤを示す図である。 ＰＳＤ内のデバイス間でリソースを共有する構造をさらに詳細に示す図である。 ＰＳＤ内のリソースを共有する２つのデバイス間の相互作用を示す図である。

Claims (29)

1. 複数のデバイス（Ａ．．．Ｆ；１８，３０，３２）を含み、各デバイスはネットワーク内の他のデバイスと無線通信できるネットワーク（１１）であって、前記デバイスの少なくともいくつかは前記ネットワーク内の他のデバイスと共有できる１つまたは複数のリソースを備えており、前記ネットワークは各デバイス（Ａ，Ｂ，Ｃ；ＤＥ；ＢＣＥ；１８，３０，３２）に識別データを提供することにより、選択されたデバイス（Ａ，Ｂ，Ｃ；ＤＥ；ＢＣＥ；１８，３０，３２）を前記デバイスの少なくとも３つを含むドメイン（１３；１５；１７；１９）内で関連付けできる管理手段を含み、前記各デバイス（Ａ，Ｂ，Ｃ；ＤＥ；ＢＣＥ；１８，３０，３２）の識別データは前記ドメイン（１３；１５；１７；１９）内の他のデバイス（Ａ，Ｂ，Ｃ；ＤＥ；ＢＣＥ；１８，３０，３２）のそれぞれによって解釈でき、特定の通信モードはこうした識別データを有するドメイン（１３；１５；１７；１９）内のデバイス（Ａ，Ｂ，Ｃ；ＤＥ；ＢＣＥ；１８，３０，３２）間でのみ許可され、前記管理手段は前記ドメイン（１９）内の前記デバイス間で前記リソースの共有を選択的に有効にする手段を含み、前記管理手段は前記ドメイン（１９）内の個々のデバイス間で共有できる前記リソースを示す記憶を保持することと前記ドメイン（１９）内のデバイスにリソースの選択的な共有を有効にするデータを提供することが可能であるネットワーク。
2. 前記管理手段から受け取る前記識別データがキー（ＫＰＳＤ）を含む、請求項１に記載のネットワーク。
3. 前記キー（ＫＰＳＤ）が共有キーである、請求項２に記載のネットワーク。
4. 前記キー（ＫＰＳＤ）がパブリックキーとプライベートキーのペアであり、前記プライベートキーが前記管理手段に保存される、請求項２に記載のネットワーク。
5. 各デバイス（Ａ，Ｂ，Ｃ；ＤＥ；ＢＣＥ；１８，３０，３２）がドメイン（１３；１５；１７；１９）のメンバーシップを示すセキュリティ証明書を関連付けられた、請求項１乃至４のいずれか１項に記載のネットワーク。
6. 前記ドメイン（１３；１５；１７；１９）内の前記デバイス（Ａ，Ｂ，Ｃ；ＤＥ；ＢＣＥ；１８，３０，３２）間で暗号化通信を可能にするさらなるキー（ＫＡＢ，ＫＢＣ，ＫＣＡ，ＫＢＥ，ＫＣＥ）を含む、請求項２乃至５のいずれか１項に記載のネットワーク。
7. 前記管理手段が前記ドメイン（１３；１５；１７；１９）内の各デバイス（Ａ，Ｂ，Ｃ；ＤＥ；ＢＣＥ；１８，３０，３２）に前記ドメイン（１３；１５；１７；１９）内の他のデバイス（Ａ，Ｂ，Ｃ；ＤＥ；ＢＣＥ；１８，３０，３２）の使用可能なリソースを示すデータを送信する、請求項１乃至６のいずれか１項に記載のネットワーク。
8. 前記管理手段が１つのデバイスから別のデバイスに転送可能である、請求項１乃至７のいずれか１項に記載のネットワーク。
9. 前記ドメイン（１３；１５；１７；１９）内の複数のデバイスが管理手段を含んでおり、前記管理手段を一度に１つのみ選択的に有効にする手段が提供される、請求項１乃至７のいずれか１項に記載のネットワーク。
10. 前記複数のドメイン（１３；１５；１７；１９）を含む、請求項１乃至９のいずれか１項に記載のネットワーク。
11. デバイス（Ｂ，Ｃ，Ｅ）が前記複数のドメイン（１３；１５；１７；１９）のそれぞれに関連付けられる、請求項１０に記載のネットワーク。
12. 前記ドメイン（１９）内の前記デバイスの少なくとも１つ（１８）は前記ドメイン（１９）内の他のデバイス（３０，３２）による前記リソースの使い方を制御するために提供された制御手段（２８，３４，４０）を含む、請求項１乃至１１のいずれか１項に記載のネットワーク。
13. 前記制御手段（２８，３４，４０）が前記他のデバイス（３０，３２）によるアクセスを前記リソースの選択されたもののみに制限する、請求項１２に記載のネットワーク。
14. 前記制御手段（２８，３４，４０）が前記他のデバイス（３０，３２）による前記リソースの使用量を制限する、請求項１２または１３に記載のネットワーク。
15. 前記制御手段（２８，３４，４０）が、リソースの使用に関する要求を受信した場合に、前記他のデバイス（３０，３２）による前記リソースの使用を認可するように、前記リソースを使用可能にする前記デバイス（ｌ８）のオペレータを促す、請求項１２、１３、１４のいずれか１項に記載のネットワーク。
16. ネットワーク（１１）内の選択されたデバイス（Ａ．．．Ｆ；１８，３０，３２）を前記デバイスの少なくとも３つを含むドメイン（１３；１５；１７；１９）内で関連付けできるようにする方法であって、各デバイス（Ａ．．．Ｆ；１８，３０，３２）はドメイン内の他のデバイス（Ａ．．．Ｆ；１８，３０，３２）と無線通信でき、前記デバイスの少なくともいくつかはドメイン内の他のデバイスと共有できる１つまたは複数のリソースを備えており、前記方法は前記ドメイン（１３；１５；１７；１９）内の他のデバイス（Ａ，Ｂ，Ｃ；ＤＥ；ＢＣＥ；１８，３０，３２）のそれぞれに識別データを提供するように前記ドメイン（１３；１５；１７；１９）内の１つのデバイス（Ｃ；１８）を適合させるステップを含み、前記各デバイス（Ａ，Ｂ，Ｃ；ＤＥ；ＢＣＥ；１８，３０，３２）の識別データが前記ドメイン（１３；１５；１７；１９）内の他のデバイス（Ａ，Ｂ，Ｃ；ＤＥ；ＢＣＥ；１８，３０，３２）のそれぞれによって解釈でき、特定の通信モードはこうした識別データを有する前記ドメイン（１３；１５；１７；１９）内のデバイス（Ａ，Ｂ，Ｃ；ＤＥ；ＢＣＥ；１８，３０，３２）間でのみ許可され、前記指定されたデバイス（Ｃ；１８）がドメイン（１９）内の個々のデバイス間で共有できるリソースを示す記憶を保持することと前記ドメイン（１３；１５；１７；１９）内のデバイスにリソースの選択的な共有を有効にするデータを提供することによってドメイン（１９）内のデバイス間で前記リソースの共有を選択的に有効にする方法。
17. 前記識別データがキー（ＫＰＳＤ）を含む請求項１６に記載の方法。
18. 前記キー（ＫＰＳＤ）が共有キーである請求項１７に記載の方法。
19. 前記キー（ＫＰＳＤ）がパブリックキーとプライベートキーのペアであり、前記プライベートキーが前記指定されたデバイスに格納される、請求項１７に記載の方法。
20. 各デバイス（Ａ，Ｂ，Ｃ；ＤＥ；ＢＣＥ；１８，３０，３２）が前記ドメイン（１３；１５；１７；１９）のメンバーシップを示すセキュリティ証明書を関連付けられた、請求項１６乃至１９のいずれか１項に記載の方法。
21. 前記ドメイン（１３；１５；１７；１９）内の前記デバイス（Ａ，Ｂ，Ｃ；ＤＥ；ＢＣＥ；１８，３０，３２）間で暗号化通信を可能にするさらなるキー（ＫＡＢ，ＫＢＣ，ＫＣＡ，ＫＢＥ，ＫＣＥ）を含む、請求項１７乃至２０のいずれか１項に記載の方法。
22. 前記適合されたデバイス（Ａ，Ｂ，Ｃ；ＤＥ；ＢＣＥ；１８，３０，３２）が前記ドメイン（１３；１５；１７；１９）内の各デバイス（Ａ，Ｂ，Ｃ；ＤＥ；ＢＣＥ；１８，３０，３２）に前記ドメイン（１３；１５；１７；１９）内の他のデバイス（Ａ，Ｂ，Ｃ；ＤＥ；ＢＣＥ；１８，３０，３２）の使用可能なリソースを示すデータを送信する、請求項１６乃至２１のいずれか１項に記載の方法。
23. 他のデバイスのそれぞれに識別データを提供する前記ドメイン内の前記デバイスを変更するステップを含む、請求項１６乃至２２のいずれか１項に記載の方法。
24. 前記複数のドメイン（１３；１５；１７；１９）のフォーメーションを可能にするステップを含む、請求項１６乃至２３のいずれか１項に記載の方法。
25. デバイス（Ｂ，Ｃ，Ｅ）が前記複数のドメイン（１３；１５；１７；１９）のそれぞれに関連付けられる、請求項２４に記載の方法。
26. 前記ドメイン（１９）内の少なくとも１つのデバイス（１８）が所有する前記リソース（２２，２４）の、前記ドメイン（１８）内の他のデバイス（３０，３２）による使い方が制御される請求項１６乃至２５のいずれか１項に記載の方法。
27. 前記制御のステップが前記他のデバイス（３０，３２）によるアクセスを前記リソースの選択されたもののみに制限する、請求項２６に記載の方法。
28. 前記制御のステップが前記他のデバイス（３０，３２）による前記リソースの使用量を制限する、請求項２６または２７に記載の方法。
29. 前記制御のステップが、リソースの使用に関する要求を受信した場合に、前記リソースを使用可能にする前記デバイス（ｌ８）のオペレータに対して、前記他のデバイス（３０，３２）による前記リソースの使用を認可するように促す、請求項２６、２７、２８のいずれか１項に記載の方法。

Images