JP2005129045A - 信頼判定エンティティに対する実行可能ファイルの安全な識別 - Google Patents

Abstract

【課題】リソースレシピエントに、リソースを供給するリソースプロバイダがリソースレシピエントを認証するために使用する認証情報を供給する。
【解決手段】リソース１２は、コンピューティングデバイス１８上で動作しているリソースリクエスタ（ＲＲ）１４のために、リソースプロバイダ（ＲＰ）１０から取得される。ＲＲ１４は、ＲＲ１４が動作する環境を指定するセキュリティ関連情報を含むアイデンティティディスクリプタ（ｉｄ）２０を有す。コードアイデンティティ（コードＩＤ）２２は、ロードされたＲＲ１４およびｉｄ２０に基づいて、計算される。ＲＰ１０は、リソース１２の要求の中の計算されたコードＩＤが識別されたＲＲ１４に対する１つまたは複数の有効なコードＩＤ２２のうちの１つと一致することを検証してＲＲ１４およびｉｄ２０が信頼できるものと結論し、ＲＰ１０は要求されたリソース１２をＲＲ１４に供給し、転送された要求に対し応答する。
【選択図】図２

Description

本発明は、実行可能ファイルにリソースを供給することを望むような信頼判定エンティティ（ｔｒｕｓｔ−ｄｅｔｅｒｍｉｎｉｎｇ ｅｎｔｉｔｙ）に対し実行可能ファイルなどが自己を安全に識別するための方法およびメカニズムに関する。より具体的には、本発明は、信頼判定エンティティがリソースを供給する前に実行可能ファイルを認証するためのそのような方法およびメカニズムに関する。

多くのコンピュータの使用状況では、第１のコンピュータタイプのエンティティが何らかの種類のコンピュータタイプのリソースを第２のコンピュータタイプのエンティティに供給する。理解できるであろうが、第１および第２のエンティティはそれぞれ、コンピュータプログラムまたは実行可能ファイル、コンピュータの記憶デバイス、コンピュータのデータサーバなどのハードウェアまたはソフトウェアエンティティとすることができる。同様に、リソースは生データ、生データが整理された形で含まれるファイルなどである。

特に、リソースが、特別な価値を有するか、または事前に定義されている規則に従って処理される場合に、第１のエンティティつまり「リソースプロバイダ」は、第２のエンティティまたは関連するエンティティが認証情報を第１のエンティティに申し出、第１のエンティティがそれに基づき第２のエンティティを認証する場合に、リソースを第２のエンティティまたは「リソースレシピエント」（ｒｅｓｏｕｒｃｅ ｒｅｃｉｐｉｅｎｔ）に供給することだけができる。例えば、銀行機関（第１のエンティティ）にあるサーバがセキュリティキー（リソース）を、ユーザがコンピュータで銀行取引を遂行できるユーザのコンピュータ（第２のエンティティ）の銀行業務プログラムに供給している場合、サーバは、銀行業務プログラムが銀行に従った方法でセキュリティキーを採用することについて信頼できるという何らかの保証を受けることを要求できる。

つまり、サーバは、銀行業務プログラム自体または銀行業務プログラムに代わるオーセンティケータに、銀行業務プログラムが特定のタイプのものである、特定の変数に基づいて特定環境で稼働しているなどの認証情報を要求する。したがって、サーバは、実際には、提供された認証情報に基づいて認証した後でないと、セキュリティキーを銀行業務プログラムに供給しない。特に重要なのは、サーバが、認証情報に基づいて銀行業務プログラムを認証する際に、銀行業務プログラムが例えばセキュリティキーを悪用するなどの形で改変されていないことを確認することを望んでおり、また稼働中の銀行業務プログラムがドロボウなど不審なエンティティによるセキュリティキーの送出または読み出しが可能な環境で稼働している、または稼動していないことを確認することも望んでいることである。

そこで、コンピュータプログラム、実行可能ファイル、または他のリソースレシピエントに、リソースを供給するリソースプロバイダがリソースレシピエントを認証するために使用する認証情報を供給するための方法およびメカニズムが必要である。特に、リソースレシピエントのアイデンティティをリソースプロバイダに対して説明するためのアイデンティティディスクリプタが必要であり、アイデンティティディスクリプタは、とりわけ、リソースレシピエントの環境および認証する署名などを記述する一組の変数を含む。

前述の要件は、少なくとも一部は、コンピューティングデバイス上で稼働しているリソースリクエスタ（ＲＲ）に関してリソースプロバイダ（ＲＰ）からリソースが取得される本発明により満たされる。ＲＲは、それに関連付けられたアイデンティティディスクリプタ（ｉｄ）を有し、ｉｄはＲＲが動作する環境を指定するセキュリティ関連情報を含む。

ＲＲおよびＲＲに対応するｉｄはコンピューティングデバイス上にロードされ、ＲＲには、そのロードされたｉｄへの参照が供給される。コードアイデンティティ（コードＩＤ）は、ロードされたＲＲおよびロードされたｉｄに対応して、またそれらに基づいて、計算される。リソースに関してＲＲから要求を受け取ると、要求側ＲＲがリソースの権利を有し、そのリソースとともに信頼されることが確認される。その後、リソースに対する要求は、ＲＲからＲＰに転送される。

ＲＰは受け取った要求を検証し、コードＩＤ、ｉｄ、および受け取った要求から要求されたリソースの定義を取得し、受け取った要求から要求側ＲＲのアイデンティティを決定する。さらに、ＲＰは、識別されたＲＲについて１つまたは複数の有効なコードＩＤのそれぞれを取得し、受け取った要求の中の計算されたコードＩＤが識別されたＲＲに対する有効なコードＩＤの１つと一致することを検証する。その後、ＲＰでは、ＲＲを信頼できると推定可能な知られているＲＲであるものとして信頼できると結論し、さらにＲＲの稼働に使用されるセキュリティ関連情報は信頼できると推定可能な知られているセキュリティ関連情報であると結論する。

その後、ＲＰは、要求されたリソースをＲＲに供給することにより転送された要求に応答する。ＲＲは、ＲＰによって供給されるとおりに要求されたリソースを受け取り、ＲＰによってＲＲに与えられた信頼に呼応する形で、ＲＲに対応するｉｄで規定されたセキュリティ関連情報に従って、それを使用する。

上述の説明とともに本発明の実施形態の以下の詳細な説明は、付属の図面とあわせて読むとよく理解できるであろう。本発明を例示するために、現在好ましい実施形態が図面に示されている。しかし、理解するであろうが、本発明は、図に示されている正確な配置および手段に限られない。

コンピュータ環境
図１および以下の説明は、本発明および／またはその一部を実装できる適当なコンピューティング環境の概要について簡潔に述べることにする。必要であるというわけではないが、クライアントワークステーションまたはサーバなどのコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的状況において本発明を説明する。一般に、プログラムモジュールには、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。さらに、本発明およびその一部が、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースのまたはプログラム可能な家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなど、他のコンピュータシステム構成でも実施できることは明白であろう。また、本発明は、通信ネットワークを通じてリンクされているリモート処理デバイスによりタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、ローカルとおよびリモートの両方のメモリ記憶デバイス内に配置することができる。

図１に示すように、汎用コンピューティングシステムの一例は、処理ユニット１２１、システムメモリ１２２、およびシステムメモリを含むさまざまなシステムコンポーネントを処理ユニット１２１に結合するシステムバス１２３を含む、従来のパーソナルコンピュータ１２０などを含む。システムバス１２３には、メモリバスまたはメモリコントローラ、周辺機器バス、およびさまざまなバスアーキテクチャを使用するローカルバスを含む数種類のバス構造がある。システムメモリは、読み取り専用メモリ（ＲＯＭ）１２４およびランダムアクセスメモリ（ＲＡＭ）１２５を含む。起動時などにパーソナルコンピュータ１２０内の要素間の情報伝送を助ける基本ルーチンを含む基本入出力システム１２６（ＢＩＯＳ）は、ＲＯＭ １２４に格納される。

パーソナルコンピュータシステム１２０は、さらに、ハードディスク（図に示されていない）への読み書きを行うためのハードディスクドライブ１２７、取り外し可能磁気ディスク１２９への読み書きを行うための磁気ディスクドライブ１２８、取り外し可能光ディスク１３１、例えば、ＣＤ−ＲＯＭまたはその他の光媒体への読み書きを行うための光ディスクドライブ１３０を備えることができる。ハードディスクドライブ１２７、磁気ディスクドライブ１２８、および光ディスクドライブ１３０は、ハードディスクドライブインターフェイス１３２、磁気ディスクドライブインターフェイス１３３、および光ドライブインターフェイス１３４によりそれぞれシステムバス１２３に接続される。ドライブおよび関連コンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびパーソナルコンピュータ２０用のその他のデータを格納する不揮発性記憶装置を備える。

本発明で説明している環境例ではハードディスク、取り外し可能磁気ディスク１２９、および取り外し可能光ディスク１３１を採用しているが、コンピュータからアクセス可能なデータを格納できる他のタイプのコンピュータ可読媒体もオペレーティング環境例で使用できることは理解されるであろう。このような他のタイプの媒体としては、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイカートリッジ、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）などがある。

ハードディスク、磁気ディスク１２９、光ディスク１３１、ＲＯＭ １２４、またはＲＡＭ １２５には、オペレーティングシステム１３５、１つまたは複数のアプリケーションプログラム１３６、その他のプログラムモジュール１３７、およびプログラムデータ１３８など、多数のプログラムモジュールを格納できる。ユーザはキーボード１４０およびポインティングデバイス１４２などの入力デバイスを通じてパーソナルコンピュータ１２０にコマンドおよび情報を入力することができる。他の入力デバイス（図に示されていない）としては、マイク、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどがある。これらの入力デバイスやその他の入力デバイスは、システムバスに結合されているシリアポートインターフェイス１４６を介して処理ユニット１２１に接続されることが多いが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェイスにより接続することもできる。モニタ１４７またはその他の種類のディスプレイデバイスも、ビデオアダプタ１４８などのインターフェイスを介してシステムバス１２３に接続される。モニタ１４７のほかに、パーソナルコンピュータは、通常、スピーカおよびプリンタなどの他の周辺出力デバイス（図に示されていない）を含む。図１のシステム例は、さらに、ホストアダプタ１５５、ＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）バス１５６、およびＳＣＳＩバス１５６に接続されている外部記憶デバイス１６２を含む。

パーソナルコンピュータ１２０は、リモートコンピュータ１４９などの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク環境で動作することも可能である。リモートコンピュータ１４９は、他のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、またはその他の共通ネットワークノードでもよく、通常は、パーソナルコンピュータ１２０に関係する上述の要素の多くまたはすべてを含むが、メモリ記憶デバイス１５０だけが図１に示されている。図１で説明されている論理接続は、ローカルエリアネットワーク（ＬＡＮ）１５１とワイドエリアネットワーク（ＷＡＮ）１５２を含む。このようなネットワーキング環境は、オフィス、企業全体にわたるコンピュータネットワーク、イントラネット、およびインターネットでは一般的なものである。

ＬＡＮネットワーキング環境で使用する場合は、パーソナルコンピュータ１２０はネットワークインターフェイスまたはアダプタ１５３を介してＬＡＮ １５１に接続される。ＷＡＮネットワーキング環境で使用する場合、パーソナルコンピュータ１２０は、通常、モデム１５４またはインターネットなどのワイドエリアネットワーク１５２上で通信を確立するためのその他の手段を含む。モデム１５４は、内蔵でも外付けでもよいが、シリアルポートインターフェイス１４６を介してシステムバス１２３に接続される。ネットワーク環境では、パーソナルコンピュータ１２０またはその一部に関して描いたプログラムモジュールは、リモートメモリ記憶デバイスに格納できる。図に示されているネットワーク接続は例であり、コンピュータ間に通信リンクを確立するのに他の手段を使用できることは理解されるであろう。

リソースレシピエントのアイデンティティディスクリプタ
そこで図２を参照すると、本発明は、コンピュータタイプのある種のリソース１２をリソースレシピエント（ＲＲ）１４に供給するリソースプロバイダ（ＲＰ）１０として動作する第１のコンピュータタイプのエンティティに関して述べられていることがわかる。理解できるであろうが、所定の状況に応じて、ＲＰ １０およびＲＲ １４はそれぞれ、ハードウェアまたはソフトウェアエンティティであるか、またはソフトウェアエンティティのハードウェア要素またはハードウェアエンティティのソフトウェア要素でよいが、すべて、本発明の精神および範囲から逸脱することはない。例えば、ＲＰ １０はデータ、ファイル、キー、コンテンツなどをリソース１２として供給するサーバとし、ＲＲ １４はそのようなリソースを必要とするソフトウェア構成物、データ記憶デバイス、コンピュータプログラムなどとすることができる。同様に、ＲＰ １０はプリンタ、ネットワークなどとし、ＲＲ １４はそのようなＲＰ １０へのリソースアクセスとして探索するプログラムまたは他の構成物とすることができる。

本発明の一実施形態では、リソース１２は特別の価値を有するか、またはあらかじめ定められた規則に従って処理されるべきであり、したがって、ＲＲ １４または関連するオーセンティケータ１６が認証情報をＲＰ １０に申し出、ＲＰ １０がそれに基づきＲＲ １４を認証した場合にのみ、ＲＰ １０はＲＲ １４にそのリソースを供給する。例えば、ＲＲおよびオーセンティケータ１６は、両方とも、ユーザのコンピューティングデバイス１８に常駐することができ、オーセンティケータ１６は信頼エバリュエータであるか、またはローダなどのコンピューティングデバイス１８上の他の何らかのシステムエンティティまたはコンピューティングデバイス１８上の他のオペレーティングシステムの一部である。

従来技術では、ＲＲ １４は、通常、ＲＲ １４のプロセスの内部の環境の記述、証明連鎖を検証することを伴う電子署名、ＲＲ １４の構成要素を検証するために使用できるキーなどの項目を含む、ＲＲ １４に関連する情報とともにマニフェストを含んでいた。そこで、動作時に、コンピューティングデバイス１８上で稼働している要素は、例えばＲＲ １４を検証するキーを取得する、またはＲＲ １４のプロセスが実際に特定の構成要素を含んでいるか否かを判定する、または動作の過程で従わなければならない特定の手順を取得するなどのために関連するマニフェストを参照していた。

したがって、ＲＲ １４のマニフェストでＲＲ １４、ＲＲ １４のセキュリティ環境、ＲＲ １４への入力などを記述していた。しかし、このようなマニフェストは以下の点で不十分である。

１）マニフェストで、単一プロセスにロードできる複数の実行可能ファイルを指定することが可能である。より大きな柔軟性に対応できるが、マニフェストを単一の実行可能ファイルに限定することは、１つのマニフェストを１つの実行可能ファイルに連結または他の何らかの手段で組み合わせることができ、単一コードアイデンティティつまり「コードＩＤ」をそのような１つの組み合わせに基づいて計算できるという点でより安全度が高い。理解されるであろうが、コードＩＤは組み合わせのダイジェスト、特にマニフェストと実行可能ファイル自体の中に記述されるようなセキュリティ関連入力のダイジェストである。以下で詳しく説明するが、本発明のアイデンティティディスクリプタまたは「ｉｄ」はそのようなセキュリティ関連入力を含むデータ構造である。

２）マニフェストは、拡張され複数の機能を含むようになったが、結果的に、複雑さが増し、他の望ましくない効果も生じるようになった。それと対照的に、本発明のｉｄは、マニフェストに直接組み込む、他のどこかから参照によりインポートする、またはマニフェストおよび／または他のどこかから実行時に導くことができ、特に対応する実行可能ファイルのみへの前述のセキュリティ関連入力を対象とし、アクセス制御システムの最低レベルでのセキュリティ関連性を有する。そこで、ｉｄは比較的単純な形式をとることができる。

本発明のアイデンティティディスクリプタつまりｉｄを特に参照すると、ｉｄ ２０はプロセス内の実行可能ファイルへのセキュリティ関連入力用のパッケージであり、実行可能ファイルは図２のＲＲ １４と考えられる。理解できるであろうが、ｉｄ ２０は、実行可能ファイルに埋め込む、別ファイルから導く、または例えばマニフェストなどの他のドキュメントから抽出することができる。本質的に、ｉｄ ２０は、実行可能ファイル／ＲＲ １４（これ以降、「ＲＲ １４」と呼ぶ）が稼働する環境、特にセキュリティ環境を記述する入力変数を指定する環境ブロックであり、ＲＲ １４およびコンピューティングデバイス１８のオペレーティングシステムにより使用することができ、そのためＲＲ １４はそのようなＲＲ １４の起動および実行を制御するために存在し、リソース１２をそのようなＲＲ １４に供給するか否かを決定するときにＲＰ １０によって使用することもできる。コードアイデンティティまたは「コードＩＤ」２２は、ＲＲ １４およびｉｄ ２０のダイジェストから導くか、または計算することができ、通常は、電子署名で採用されているのに似た方法によるハッシュである。

注目に値すべきなのは、ＲＲ １４側で例えばファイルを読み込む、デバッギングポートを開くなどによりセキュリティ環境を修正したい場合、そのようなＲＲ １４はそれ自体そうする必要があるということである。しかし、ＲＲ １４を開発している開発者が特定の振る舞いをパラメータ化することを望んでおり、パラメータはセキュリティに関係する場合（例えば、プログラム入力に基づき異なるファイルを開く、またはプログラム入力に基づきデバッグする）、パラメータをｉｄ ２０に置き、ＲＲ １４をそのパラメータのｉｄ ２０のみを参照するように作成することができる。したがって、パラメータは、潜在的に、ｉｄ ２０内で、不埒な（ｎｅｆａｒｉｏｕｓ）エンティティにより修正される恐れがあるが、ｉｄ ２０が修正されると、計算されたコードＩＤ ２０は変化し、そのような変化は、ＲＰ １０などの利害関係者により、ＲＲ １４は信頼すべきでないという指示であるとして解釈される可能性がある。

本発明の一実施形態では、ｉｄ ２０は以下の機能形式をとる。

つまり、ｉｄ ２０はその中に、名前−値の一組のペアを含み、そのそれぞれにより、例えばドット付き英数字文字列などの名前が対応する値文字列にマッピングされる。ｉｄ ２０はＸＭＬドキュメントなどの形式のものとしても本発明の精神および範囲から逸脱することはないが、そのようなＸＭＬでは構文解析が不必要に複雑になる恐れがあることに注意されたい。また、変数の少なくとも一部は文字列として表されたＸＭＬドキュメントであることも可能であることに注意されたい。そこで、リストとして表されるｉｄ ２０は以下の形式である。

ｉｄ ２０の使用例を以下に示す。これらの例は説明を目的としており、必ずしも網羅しているわけではないことに注意されたい。「ｎａｍｅｓ」にドット付き名前空間を仮定すると、「＿Ｓｙｓｔｅｍ」名前空間は、コンピューティングデバイス１８のオペレーティングシステムによって使用されるように予約することが可能であり、ＲＲ １４のｉｄ ２０はその中に以下を含むことが可能である。

そのため、コンピューティングデバイス１８のオペレーティングシステムは、ｉｄ ２０を参照して、ｉｄ ２０に対応するＲＲ １４のプロセスがデバッグ可能であること、実行可能ファイルの名前が「Ｅｘｃｅｌ」であること、変数＿Ｓｙｓｔｅｍ．ＳｅａｌＴｏＬｏｃａｌＡｄｍｉｎが「ｔｒｕｅ」に設定されていることを判別することが可能である。

ＲＲ １４は、そのｉｄ ２０を使用し、セキュリティの性質のプログラム入力に基づきビヘイビアに関する決定を下すことができる。「ｎａｍｅｓ」にドット付き名前空間を仮定すると、「ＭｙＰｒｏｇ」名前空間は、ＲＲ １４によって使用されるように予約することが可能であり、ＲＲ １４のｉｄ ２０はその中に以下を含むことが可能である。

したがって、ＲＲ １４では、そのｉｄ ２０に基づいて、特定のプログラム名、プログラムスクリプト、ＸＭＬ形式のプログラムＵＩ（ユーザインターフェイス）、多数の許されたリソースファイル、およびＲＲ １４のプロセスをデバッグすることができる特定のキーホルダを決定することができる。

理解するであろうが、特定のｉｄ ２０内の実際の名前−値のペアは、本発明の精神および範囲を逸脱することなく適切な任意の名前−値のペアとすることができる。さらに、このような名前−値のペアは、例えば、有効なユーザの特定のプログラムスクリプトまたはリストなどのＲＲ １４同士で異なる値の型、さらに例えば、プログラム名およびＲＲ １４のプロセスがデバッグ可能か否かなどのほとんどすべてのＲＲ １４に共通の値の型を含む場合もある。通常、特定のｉｄ ２０内の名前−値のペアは、ｉｄ ２０が主に、動作しているＲＲ １４のセキュリティ環境を記述する入力変数を指定する環境ブロックである限り、セキュリティ関連であるが、セキュリティ関連でない名前−値のペアもまた本発明の精神および範囲を逸脱することなくｉｄ ２０内にありうることも理解されるであろう。

したがって、また特にセキュリティ関連の事柄に関して、特定のｉｄ ２０がオペレーティングシステム、仮想マシン、実際のマシン、および／またはＲＲ １４が動作するコンピューティングデバイス１８のようなもの、ＲＲ １４がデバッガなどにより監視できない孤立したプロセスで動作するのかまたは実際にそのように監視できるデバッグ可能なプロセス内で動作するかという情報、ＲＲ １４にアクセスするために使用される各エントリポイント、および他のセキュリティ関連の事柄の中でも特にＲＲ １４に供給されるセキュリティ関連の入力を記述する名前−値のペアを含むことができる。理解されるであろうが、そのようなセキュリティ関連の事柄は一般に、ＲＲ １４の動作の仕方、ＲＲ １４がデータおよびその他の入力を受け取り場所、およびＲＲ １４がとりわけ外部から影響を受けることが可能なのかあるいは監視できるのかということに影響を及ぼす事柄である。したがって、また一般的に、ｉｄ ２０内の情報は、ＲＲ １４を記述し、ＲＲ １４が動作するオペレーティングシステムおよびコンピューティングデバイス１８を記述し、ＲＲ １４のセキュリティ関連の態様を記述する。しかし、ＲＲ １４のコードＩＤ ２２が一部そのｉｄ ２０に基づいている限り、またコードＩＤ ２２が、以下でさらに詳しく説明するように、よく知られている限り、ｉｄ ２０は特定のコンピューティングデバイス１８上のＲＲ １４の特定のインスタンス化に固有の名前−値のペアを含まないことに注意されたい。

本発明の一実施形態では、特定のＲＲ １４に対応するコードアイデンティティまたは「コードＩＤ」２２は、そのｉｄ ２０と連結されたＲＲ １４のハッシュとして定義される。例えば、このハッシュは、ＳＨＡ−１およびＳＨＡ−２５６などの、いくつかの知られているＳＨＡアルゴリズムのどれかに基づくことができる。
コードＩＤ ２２＝ＳＨＡ （ＲＲ １４｜ｉｄ ２０）

特定の一実施形態では、コードＩＤ ２２は、前述のハッシュのうちの２つを連結したものであり、一方のハッシュはＳＨＡ−１に基づき、他方のハッシュはＳＨＡ−２５６に基づく。
コードＩＤ ２２＝ＳＨＡ−１（ＲＲ １４｜ｉｄ ２０）｜ＳＨＡ−２５６（ＲＲ １４｜ｉｄ ２０）

したがって、理解されるであろうが、ＲＲ １４およびそのｉｄ ２０を知っていることに基づいて、またコードＩＤ ２２の計算に使用する方法を知っていることに基づいて、ＲＲ １４または関連するオーセンティケータ１６はそのようなＲＲ １４に対応するコードＩＤ ２２を計算し、電子署名の形でＲＰ １０に提示することができる。注目に値すべきなのは、ＲＲ １４の１つまたは複数の有効なコードＩＤ ２２のそれぞれが、特にリソース１２をＲＲ １４に供給するよう求められるＲＰ １０によりよく知られているということである。ＲＲ １４は、特にＲＲ １４に複数のバージョンがある、ＲＲ １４が複数のオペレーティングシステム上で稼働可能であるなどの状況で、そのそれぞれがＲＲ １４および／またはそのｉｄ ２０の変更形態を必要とする場合に、複数の有効なコードＩＤ ２２を持つことに注意されたい。すると、おそらくＲＰ １０はＲＲ １４およびそのＲＲ １４に対するそれぞれの有効なコードＩＤ ２２を知っており、またそのようなＲＰ １０は、ＲＲ １４の有効なコードＩＤ ２２がそのようなＲＲ １４に代わってＲＰ １０に送られる場合のみ、リソース１２をＲＲ １４に供給する。

本発明の一実施形態では、図３を参照すると、ＲＲ １４に対応するｉｄ ２０およびコードＩＤ ２２は以下のようにして使用される。予備的に、ＲＲ １４は、コンピューティングデバイス１８のオペレーティングシステム上のプロセスでインスタンス化させられるが、その際に使用するインスタンス化はユーザまたは他のプロセスにより作動される（ステップ３０１）。通常、そのようなインスタンス化は、コンピューティングデバイス１８のオペレーティングシステム上で動作するローダ２４を使用して実行されるが、そのようなインスタンス化は、本発明の精神および範囲を逸脱することなく他の適切なエンティティを使って達成することが可能である。

ＲＲ １４をインスタンス化する一環として、ローダ２４はそのようなＲＲ １４を配置可能な場所からＲＲ １４を取得し、それをロードする（ステップ３０３）。理解されるであろうが、ローダ２４は本発明の精神および範囲を逸脱することなく適切な方法でＲＲ １４のそのような取得およびロードを実行でき、その場合、取得する特定の方法は当業者に知られているか、または当業者には明らかであろうから、本明細書で詳細に開示する必要はない。

さらにＲＲ １４をインスタンス化する一環として、ローダ２４はそのようなＲＲ １４に対応するｉｄ ２０をそのようなｉｄ ２０を配置可能な場所から取得し、さらにそれを適切な場所にロードする（ステップ３０５）。上で説明したように、そのようなｉｄ ２０は、ＲＲ １４に埋め込まれるか、別のファイルから引き出すか、または例えばマニフェストなどの他のドキュメントから抽出することができる。いずれにせよ、ローダ２４は本発明の精神および範囲を逸脱することなくそのような場所に対応するモードでその場所からｉｄ ２０を取得することができ、その場合、取得する特定の方法は当業者に知られているか、または当業者には明らかであろうから、本明細書で詳細に開示する必要はない。ローダがｉｄ ２０をロードする場所は、本発明の精神および範囲を逸脱することなく、例えば、テーブル、ｉｄキャッシュ、ＲＲ １４のプロセスなど任意の適切な場所とすることができる。

ＲＲ １４およびＲＲ １４が動作するコンピューティングデバイス１８のオペレーティングシステムは両方とも、ロードされたｉｄ ２０へのアクセスを必要とする場合があることに注意されたい。したがって、ｉｄ ２０をロードした後、ローダ２４は、少なくともＲＲ １４にｉｄ ２０の場所へのポインタまたは参照を供給する（ステップ３０７）。そこで、ＲＲ １４は、そのようなｉｄ ２０内で関係するセキュリティ関連情報を見つけることができる。さらに、オペレーティングシステムは、ＲＲ １４を使って、またはさらにそのようなポインタまたは他の参照を受け取ることによりそのようなセキュリティ関連情報を見つけることもできる。

おそらく、ＲＲ １４の動作中のある時点で、そのようなＲＲ １４は上述のようにＲＲ １４の有効なコードＩＤ ２２がそのようなＲＲ １４に代わってＲＰ １０に提示される場合のみリソース１２をそのようなＲＲ １４に供給するＲＰ １０からのリソース１２を必要とするようになる。したがって、ＲＲ １４および対応するｉｄ ２０をロードした後、そのようなロードされたＲＲ １４およびｉｄ ２０に対応するコードＩＤ ２２が計算される（ステップ３０９）。そのようなコードＩＤ ２２は、ローダ２４または認証情報をＲＰ １０に申し出る前述のオーセンティケータ１６により計算することができる。理解できるであろうが、オーセンティケータ１６は、実際にはローダ２４の一部であるか、またはローダ２４は、実際にはオーセンティケータ１６の一部であってもよい。ここでもまた、コードＩＤは、計算されたコードＩＤ ２２がＲＰ １０によって認識されることが予想される形式である限り、本発明の精神および範囲を逸脱することなく適切な方法で計算することができる。

したがって、ＲＲ １４の動作中のある時点に、そのようなＲＲ １４は、実際に、ＲＰ １０からのリソース１２を必要とし、したがって、オーセンティケータ１６に対し、ＲＲ １４に代わってそのようなリソース１２を取得するよう要求する（ステップ３１１）。そのようなリソース１２の取得を試みる前に、オーセンティケータ１６はＲＲ １４に関してさまざまな認証機能を実行して、ＲＲ １４に、リソース１２の権利があり、とりわけリソース１２について信頼できることを確認することができることに注意されたい（ステップ３１３）。そうする際に、オーセンティケータ１６は、それ自身、ＲＲ １４に対応するｉｄ ２０内のセキュリティ関連情報を参照することができ、またＲＲ １４は、とりわけ、その信頼を無効にすることになるようないかなる方法でも修正されていないことを確認することができる。一般に、オーセンティケータ１６は、本発明の精神および範囲を逸脱することなく、ＲＲ １４に関して任意の認証機能を実行することができる。そのような認証機能は、当業者に知られているか、または当業者には明らかであろうから、本明細書で詳しく説明する必要はない。

オーセンティケータ１６がＲＲ１４に満足していると仮定すると、オーセンティケータ１６はリソース１２の要求をＲＲ １４からＲＰ １０に転送する（ステップ３１５）。そのような転送される要求は、ＲＲ １４からのそのままの要求のコピーであるか、またはその修正とすることができる。したがって、転送された要求は、本発明の精神および範囲を逸脱することなく適切な形式をとることができる。例えば、要求側ＲＲ １４に対する計算で求められたコードＩＤ ２２、要求側ＲＲ １４のｉｄ ２０、およびとりわけ、ＲＲ １４によって要求されたリソース１２の定義を含む事前に定義されているクオート機能（ｑｕｏｔｉｎｇ ｆｕｎｃｔｉｏｎ）などのフォームがありえる。理解されるであろうが、クオート機能はさらに、電子署名またはそのようなアイテムのうち１つまたは複数に基づくようなものを含むことができ、その署名は、オーセンティケータ１６とＲＰ １０との間で共有されるセキュリティキーに基づいて検証可能である。

受け取ったクオート機能またはその他の転送された要求に対する応答として、図４を参照すると、ＲＰ １０は、リソースについてＲＲ １４からの要求を実際に受けるか否かを決定する。特に、ＲＰ １０は、クオート機能の場合に共有されているセキュリティキーに基づきその署名を検証することを含む転送された要求（ステップ４０１）を、とりわけ検証する。さらに、ＲＰ １０は、転送された要求からコードＩＤ ２２、ｉｄ ２０、および要求されたリソース１２の定義を取得し（ステップ４０３）、その転送された要求から要求側ＲＲ １４のアイデンティティを判別し（ステップ４０５）、識別されたＲＲ １４のそれぞれの有効なコードＩＤ ２２を取得し（ステップ４０７）、転送された要求の中の計算で求めたコードＩＤ ２２が識別されたＲＲ １４に対する有効なコードＩＤ ２２のうちの１つと一致することを検証する（ステップ４０９）。

ＲＰ １０は、本発明の精神および範囲を逸脱することなく、適切な方法により転送された要求から要求側ＲＲ １４のアイデンティティを判別することができることに注意されたい。例えば、そのようなアイデンティティは、転送された要求の中のｉｄ ２０内で特定の名前−値のペアとして指定することができる。もちろん、不埒なエンティティは、ＲＰ １０からリソース１２を不適切に取得しようとする際にｉｄ ２０内のそのようなアイデンティティ情報を変更する場合がある。しかし、オーセンティケータ１６により計算されるようなコードＩＤ ２２は、一部ｉｄ ２０に基づいているため、そのような計算で求められたコードＩＤはＲＰ １０に知られているどの有効なコードＩＤとも一致しないであろう。さらに、オーセンティケータ１６は、適切に動作するものとしてＲＰ １０により信頼されており、したがって、コードＩＤ ２２を損なわないことを信頼できることに注意すべきである。

また、ＲＰ １０は、ＲＲ １４に対しそれぞれ有効なコードＩＤ ２２を持つものと仮定され予想されることに注意されたい。ここでもまた、ＲＲ １４の１つまたは複数の有効なコードＩＤ ２２のそれぞれが、特にリソース１２をＲＲ １４に供給するよう求められるＲＰ １０によりよく知られているべきである。最後に、転送された要求内の有効なコードＩＤ ２２を見つけることにより、ＲＰ １０は、ＲＲ １４およびそのｉｄ ２０から導かれる、有効なコードＩＤ ２２に基づき、ＲＲ １４が信頼に値すると想定できる知られている改変されていないＲＲ １４であると信頼できること、およびさらに、ＲＲ １４が動作する際に基づくセキュリティ関連情報が信頼に値するものであると想定できる知られている改変されていないセキュリティ関連情報であることを結論することができることに留意されたい。さらに、コードＩＤ ２２を使用することにより、損なわれた特定のＲＲ １４は、ＲＰ １０によるその関連するすべてのコードＩＤの利用を単にできなくすることにより、受け付けないようにできることは理解されるであろう。

要求の計算で求められたコードＩＤ ２２の妥当性を確認するほかに、ＲＰ １０では、他の情報に基づきその転送された要求の妥当性を確認することもできる（ステップ４１１）。例えば、コードＩＤ ２２の妥当性が確認されても、ＲＰ １０は、例えばＲＲ １４が孤立プロセスで動作しているか否かなどｉｄ ２０内の特定の情報に基づき要求を受け入れるか、または拒絶するかについてプログラムすることが可能である。同様に、転送された要求がＲＲ １４のコンピューティングデバイス１８のユーザの識別を含む場合、識別されたユーザに基づき要求を受け付けるか、または拒絶するようにＲＰ １０をプログラムすることができる。もちろん、ＲＰ １０は、本発明の精神および範囲を逸脱することなく、任意の基準に基づき転送された要求の妥当性を確認することができる。

転送された要求の妥当性がステップ４０９および４１１でのように確認された場合、ＲＰ １０は、その要求されたリソース１２が利用可能であり、かつ／または供給できると判定する（ステップ４１３）。例えば、リソース１２がデータであれば、ＲＰ １０はそのデータが実際に利用可能であると判断し、あるいはとりわけ、リソースがプリンタへのアクセスであれば、ＲＰ １０はプリンタが実際にオンラインであり、用紙が入っており、新しい印刷要求を受け付けていると判断する。

その後、転送された要求の妥当性がステップ４０９および４１１で確認され、ステップ４１３でのように要求されたリソース１２が利用可能であり、かつ／または供給できると仮定すると、ＲＰ １０は要求されたリソース１２を供給することにより転送された要求に応答する（ステップ４１５）。そこで、リソース１２はオブジェクトである場合、ＲＰ １０はそのようなオブジェクトを供給し、リソース１２がサービスに対するアクセスである場合、ＲＰ １０は、例えば、セキュリティキーまたはアクセスを示す他の何らかのものを使ってそのようなアクセスを準備し、そのセキュリティキーまたはアクセスを示す他の何らかのものを供給する。

ＲＲ １４は、ＲＰ １０により与えられた要求されたリソース１２へのそのような応答を、オーセンティケータ１６を使って直接的にまたは間接的に受け取り（図３のステップ３１７）、その後ＲＲ １４は適宜応答を送ったリソース１２を使用することができる（ステップ３１９）。少なくとも暗黙のうちに、ＲＰ １０は実際に要求されたリソース１２をＲＲ １４に供給したので、ＲＲ １４およびそのコンピューティングデバイスは、そのような信頼と矛盾しない方法でのみ、また特にＲＲ １４に対応するｉｄ ２０で規定されているセキュリティ関連情報に従って、ＲＰ １０により信頼され、供給されたリソース１２を使用することができる。

結論
本発明は、リソースリクエスタＲＲ １４およびリソースプロバイダＲＰ １０に関して実施することができる。より具体的には、本発明を使用することにより、例えば、ＰＣのワードプロセッサがプロテクトされている文書処理ドキュメントを受け取ること、専用再生デバイスの音楽プレーヤーがレンダリングされた音楽をスピーカーシステムに送ること、無線デバイスがローカル無線ネットワークにアクセスすることなどが可能になる。したがって、ＲＲ １４は、リソース１２を要求するデバイスとして解釈され、ＲＰ １０は、システム内のリソース１２を供給するデバイスとして解釈され、そこでは、ＲＲ １４はｉｄ ２０内のセキュリティ関連情報に基づき動作し、ＲＰ １０は一部そのｉｄ ２０に基づいてＲＲ １４の信頼性の妥当性を確認する。

本発明に関して実行されるプロセスを実現するために必要なプログラミングは、比較的簡単であり、プログラミングを行う当業者には明白であろう。したがって、このようなプログラミングについては、本明細書では取り上げない。どのような特定のプログラミングを使用しても、本発明の精神および範囲を逸脱することなく本発明を実施することができる。

前記の説明では、本発明は、リソース１２を供給するリソースプロバイダＲＰ １０がＲＲ １４を認証するために使用するｉｄ ２０などの認証情報をコンピュータプログラム、実行可能ファイル、または他のリソースレシピエントＲＲ １４に供給するための新しくかつ有用な方法およびメカニズムを含む。ｉｄ ２０は、ＲＰ １０へのＲＲ １４のアイデンティティを記述し、とりわけ、ＲＲ １４の環境を記述する一組の変数を含む。

本発明の概念から逸脱することなく上述の実施形態に対し変更を加えることが可能であることは理解されるであろう。したがって、本発明は開示されている特定の実施形態に制限されず、付属の請求項により定義されているように本発明の精神および範囲内の修正形態を対象とすることを目的としていることは理解されるであろう。

信頼ベースのシステムの実施アーキテクチャを示すブロック図である。 本発明の一実施形態により配置され稼働するリソースリクエスタ、リソースレシピエント、リソースレシピエントのアイデンティティディスクリプタ、および関連するエンティティを示すブロック図である。 本発明の一実施形態により図２のリソースプロバイダにリソースを要求する際に図２のリソースレシピエントおよび関連するエンティティにより実行される主要ステップを示す流れ図である。 本発明の一実施形態により図２のリソースレシピエントにリソースを供給する際に図２のリソースプロバイダにより実行される主要ステップを示す流れ図である。

符号の説明

１２０ コンピュータ
１２２ システムメモリ
１３６ アプリケーションプログラム
１３７ その他のプログラム
１３８ プログラムデータ
１２１ 処理ユニット
１４８ ビデオアダプタ
１５５ ホストアダプタ
１５６ ＳＣＳＩバス
１２３ システムバス
１３２ ハードディスクドライブＩ／Ｆ
１３３ 磁気ディスクドライブＩ／Ｆ
１３４ 光ドライブＩ／Ｆ
１４６ シリアルポートＩ／Ｆ
１５３ ネットワークＩ／Ｆ
１２７ ハードドライブ
１３７ その他のプログラム
１３６ アプリケーションプログラム
１３８ プログラムデータ
１２８ フロッピー（登録商標）ドライブ
１３０ 光ドライブ
１４７ モニタ
１６２ 記憶デバイス
１５４ モデム
１４０ キーボード
１２９ 記憶装置
１３１ 記憶装置
１４２ マウス
１５０ メモリ
１４９ リモートコンピュータ
１０ リソースプロバイダ（ＲＰ）
１２ リソース
２２ コードＩＤ
１６ オーセンティケータ
１４ リソースレシピエント（ＲＲ）
２４ ローダ
１８ コンピューティングデバイス

Claims (36)

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. 前記転送された要求は、前記要求側ＲＲの前記計算されたコードＩＤ、前記要求側ＲＲの前記ｉｄ、および前記ＲＲにより要求された前記リソースの前記定義の少なくとも１つに基づく電子署名をさらに含み、前記方法は前記署名を検証するステップをさらに備えることを特徴とする請求項２７に記載の媒体。
30. 前記方法は、前記転送された要求の妥当性をその中の他の情報に基づいて確認するステップをさらに備えることを特徴とする請求項２７に記載の媒体。
31. 前記方法は、前記要求されたリソースが利用可能であり、かつ／または供給できると判定するステップをさらに備えることを特徴とする請求項２７に記載の媒体。
32. 前記ｉｄはその中に前記ＲＲ、前記ＲＰ、および前記ＲＲが動作する前記コンピューティングデバイス上のオペレーティングシステムのうちの少なくとも１つへの入力として利用可能な一組のセキュリティ関連名前−値のペアを含むことを特徴とする請求項２７に記載の媒体。
33. 前記名前−値のペアは、前記ＲＲが動作する環境、前記ＲＲが孤立プロセスで動作するか否か、および前記ＲＲにアクセス可能な各エントリポイントのうちの少なくとも１つを記述することを特徴とする請求項３２に記載の媒体。
34. 前記コードＩＤは前記ＲＲおよび前記ｉｄのダイジェストから計算されることを特徴とする請求項２７に記載の媒体。
35. 前記コードＩＤは前記ｉｄと連結された前記ＲＲのハッシュであることを特徴とする請求項３４に記載の媒体。
36. 前記コードＩＤは２つのハッシュの連結であり、各ハッシュは前記ｉｄと連結された前記ＲＲのハッシュであることを特徴とする請求項３５に記載の媒体。

Images