JP2009518762A - インテグリティデータベースサービスを用いた、トラステッドプラットフォーム上のコンポーンテントのインテグリティの検証方法 - Google Patents

Abstract

クライアントプラットフォームは、ネットワーク上のリソースまたはサービスへのアクセスが許可される前に、クライアントプラットフォームにある個々のハードウェアまたはソフトウェアコンポーネントを検証して有効と判断することにより検証される。クライアントプラットフォームの複数のコンポーネントに対するダイジェストが生成される。これらのダイジェストは、集められてインテグリティレポートとなる。オーセンティケーターエンティティは、このインテグリティレポートを受信し、これらのダイジェストと、インテグリティオーソリティにあるローカルシグネチャデータベースまたはグローバルシグネチャデータベースのいずれかまたは両方に格納されているダイジェストとを比較する。もしくは、ダイジェストは、ポータブルダイジェストコレクタードングルに収集されて格納することも他のやり方としてできる。これらのダイジェストが有効であるか無効である場合には、全体のインテグリティ／トラストスコアが生成される。全体のインテグリティ／トラストスコアは、ポリシーを使って、クライアントプラットフォームのネットワーク上にあるリソースへのアクセスが許可されるべきか否かを決定するのに用いられる。
【選択図】図１

Description

本発明は、信頼できるコンピュータの使用およびネットワークのセキュリティに関し、より詳しくは、クライアントプラットフォームからのネットワーク上にあるリソースまたはサービスへのアクセスする許可を前に、そのクライアントプラットフォームの複数のコンポーネントのインテグリティ（integrity）を決めることに関する。

インターネットの拡大成長により、世界は変化した。１９７０年代の後期および１９８０年代の初期には、インターネットは、誕生したばかりであり、防衛省やいくつかの学術分野に専用の相互接続されたコンピュータの一部に位置づけられるものであった。１９９０年代の初期には、インターネットは、公衆の知るところとなった。公衆がインターネットにアクセスし易くなるほど、インターネットは、著しく大きく、複雑になった。その結果、インターネットは細分化して成長した。特に、ソフトウェアおよびハードウェア開発業者らは、インターネットに接続可能な多種多様なデバイスを開発した。これらのデバイスの開発は発展しながら続けられ、その結果、今日、インターネットに接続可能なデバイスは、多種多様なものとなっている。ＰＣクライアント、サーバ、ＰＤＡ(Personal Digital Assistants)、携帯電話、ルータや、他のネットワークに接続可能なデバイスは、すべてインターネットを経由して相互接続されているのが一般的である。セキュリティおよび認証の分野において、これらの相互接続可能なデバイスは、地域的規模および地球的規模で、変化をもたらしている。

インターネットの多くの未開拓の分野では、望まざる傾向が発生している。悪意をもった人々が、非合法に、偽物のハードウェアコンポーネントやソフトウェアコンポーネントを反合法的市場に売る。海賊版ソフトウェア、ウイルス、ワーム、そして他の危険な物も、また、脅威となっている。これらの脅威は、安全と、健全なインターネット、そのユーザー、およびそれらのデータを脅かしている。商取引の促進をインターネットに頼っている事業主は、事業の存続を最優先と考えると、これらの際限なく増大する脅威に直面しなければならないことに気づく。同様に個人のインターネットユーザーは、彼らの個人的な金融取引情報等の個人情報を含むデータの完全性(インテグリティ、integrity)や安全性について心配する。ネットワーク上におけるエンドポイントのインテグリティは、事業やネットワーク産業にとって、重大な懸案事項となってきている。

今日存在するアンチウイルスソフトウェア、スパムフィルター、そして他のソフトウェア製品は、コンピューターウイルスや、他の悪意のあるソフトウェア（マルウェア、malware）や他のユーザーにつけ込んだ試みを特定し、妨害し、除去することによって、上記の問題のいくつかに対して対処している。しかしながら、ウイルスを妨害すること自体は、クライアントプラットフォームのソフトウェアコンポーネントおよびハードウェアコンポーネントのインテグリティを保証するという問題を解決していない。特に、上述したソフトウェア製品は、ハードウェアやソフトウェアが信頼性のある公知の標準に依拠した真正のコンポーネントであるか否かを検証することができない。例えば、アンチウイルスソフトウェアは、問題のあるコンピュータシステムが例え悪意のあるソフトウェアを有していても、当該コンピュータシステムがネットワークにログインすることを阻止することができず、ハードウェアコンポーネントのインテグリティを検査することもない。また、アンチウイルスソフトウェアは、クライアントプラットフォームが違法のコンポーネントを有している可能性のある場合に、何ら予防措置をとらない。

アンチウイルスソフトウェア製造業者の努力にもかかわらず、“汚染された”マシンを通じて企業のネットワークにますます多くのマルウェアが取り込まれている。例えば、従業員が出張の際にラップトップコンピューターを携帯し、社内ネットワーク外にあるインターネット等のネットワークに接続する際に、このような“汚染”が起きる可能性がある。その結果、当該マシンは、ある種のマルウェアによって“汚染される”。それから、“汚染された”マシンは、社内ネットワークに戻され、社内ネットワーク全体のインテグリティを脅かす虞がある。最高情報責任者（ＣＩＯ）に対し、金融データを管理し、報告するシステムの安全性、正確性および信頼性について責任を負わせるサーベンス・オクスリー法（Sarbanes-Oxley Act）等の近年の法律制定を踏まえると、マシンインテグリティは特に重要である。

銀行は、マルウェアや違法のコンポーネントを有するクライアントプラットフォームに対して特に脆弱な業種のよい一例である。もともと、銀行は、慎重に扱うべき金融情報を保管しており、当然、当該情報が安全な状態であることを確保しようとしている。今日、銀行のネットワークにアクセスを要求している既知のクライアントプラットフォームが取引を行うために要求される全体のインテグリティを有し、上記ネットワークに深刻な脅威をもたらさないか否かについて、程度の差はあるが銀行は把握できていない。

従って、ネットワークサービスやリソースへのアクセス許可が与えられる前に、不適当な状態であるかもしれないクライアントプラットフォームのハードウェアコンポーネントおよびソフトウェアコンポーネントについて識別し、有効なコンポーネントを認証する方法が、依然として求められている。本発明は、上記の問題および上記先行技術に関連した他の問題を解決するものである。

本発明は、クライアントプラットフォームを認証し、クライアントプラットフォームの少なくとも１つのコンポーネントのインテグリティレポート（integrity report）を生成し、インテグリティに署名し、インテグリティレポートとインテグリティオーソリティ（integrity authority）のデータベースに格納されている複数のインテグリティ／トラストレコード（integrity/trust record）とを比較することによりネットワーク上にあるリソースやサービスへのアクセスを許可する方法および装置に関する。

本発明の前述した特徴、目的、利点およびそれら以外の特徴、目的、利点は、添付図面と関連して記載された以下の詳細な説明から明らかとなるであろう。

好ましい実施例の詳細な説明

本発明の実施例は、サプリカント（supplicant、クライアントプラットフォームとも言う）のソフトウェアおよびハードウェアのモジュールおよびコンポーネント（以下、これらのモジュールおよびコンポーネントを合わせて単に“コンポーネント”とも言う）のインテグリティを検証するものである。クライアントプラットフォームは、検証されるコンポーネントの情報（以下、“ダイジェスト”、“シグネチャ（signature）”とも言う）を収集する。ダイジェストは、クライアントインテグリティレポート（“インテグリティレポート”と言う）としてまとめられる。インテグリティレポートは、認証サーバ（authentication server）や他のオーセンティケーターエンティティ（authenticator entity）等のサーバに送信されることができる。それから、ダイジェストは、コンポーネントインテグリティ／トラストレコード（“インテグリティ／トラストレコード”とも言う）と比較される。インテグリティ／トラストレコードは、後述するインテグリティオーソリティによって前もって収集されていたものである。比較の結果、クライアントプラットフォームの信頼性の検証がなされる。

インテグリティオーソリティは、インテグリティ／トラストレコードを含むデータベースを有している。ある実施例では、グローバルシグネチャデータベース（global signature database、GSDB）が無数のソフトウェアおよびハードウェアのコンポーネントについての情報を含むインテグリティ／トラストレコードを供給する。当該情報は、前もってソフトウェアおよびハードウェア製造業者らから収集されたものであり、精製されており（refined）、かつ個々のインテグリティ／トラストスコア（integrity/trust score）が割り当てられている。別の実施例では、ローカルシグネチャデータベース（local signature database、LSDB）がインテグリティ／トラストレコードを供給する。LSDBは、定期的に更新されるか、GSDBと同期するように構成することができる。

ある実施例では、ダイジェストは、市販の製品から得ることができ、購入版からレコードを収集することにより得ることができる。また、別の実施例では、ダイジェストは、製造業者からアップロードされることにより、または直接的な手段で情報を得ることにより収集することができる。後者の方法は、一般に、コンポーネントの“流通過程の履歴（Chain-of-Custody）”についての確実性を考慮している。なぜなら、技術的防御方法を回避しようとして製品のコンポーネントを改ざんすることのできる仲介人（例えば、所有者）がより少ないからである。一般的に、流通過程の履歴における仲介人の人数が少ないと、製品のコンポーネントの改ざんが起こりにくい。とはいえ、改ざんが起こった場合、当業者であれば、真正の“基準（rule）”ではないと認識するであろう。また、当業者であれば、市販の製品または製造業者から直接得る以外の、ダイジェストを収集する方法があることを理解するであろう。

オーセンティケーターエンティティは、クライアントプラットフォームの信頼性のレベルを評価するためのデータベースにある情報を、使用することができる。クライアントプラットフォームの信頼性のレベルの評価は、データベースのインテグリティ／トラストレコードと、クライアントプラットフォームから受信したインテグリティレポートに格納された個々のコンポーネントとを比較し、クライアントプラットフォームについての全体のインテグリティ／トラストスコアを算出することにより行われる。全体のインテグリティ／トラストスコアは、いくつかの要因から影響を受けうる。例えば、ダイジェストがインテグリティレポートに格納されているコンポーネントの流通過程の履歴は、インテグリティ／トラストレコードのコンポーネントに割り当てられた個々のインテグリティ／トラストスコアに影響を与える可能性があり、最終的には、クライアントプラットフォームについて判断される全体のインテグリティ／トラストスコアに影響を与えうる。上述したように、直接製造業者から収集したダイジェストは、市販の製品からダイジェストとして収集したものよりも信頼性が高いと思われる。そして、ダイジェストがより信頼性の高いものであると、ダイジェストは、クライアントプラットフォームをより顕著に“信頼性が高いもの”に導く可能性がある。クライアントプラットフォームの“信頼性”を検証する別の要因として、インテグリティレポートの署名に用いられた認証方法が挙げられる。一旦全体のインテグリティ／トラストスコアが検証されると、当該スコアは、さらなる意思決定に用いられ、既定のポリシーに従って、ネットワーク上にあるリソースまたはサービスに、クライアントプラットフォームがアクセスすることを許可するか禁止するかの決定に用いられる。

図１は、パーソナルコンピュータ115、ネットワークエレメント120、携帯電話125そして携帯情報端末130等の種々のクライアントプラットフォーム110を含むシステム105を示している。また、当業者は、ノートブックコンピュータ、キオスク（kiosk）、デジタルカメラ等のシステム105に用いられうる他の種類のクライアントもあることがわかるであろう。各クライアントプラットフォーム110は、ネットワーク135に接続されることができる。ネットワーク135は、デバイスを相互接続することのできるあらゆるネットワークである。例えば、ネットワークとしては、ローカルエリアネットワーク（LAN）、ワイドエリアネットワーク（WAN）、メトロポリタンエリアネットワーク（MAN）、そしてインターネットのようなグローバルネットワークが挙げられる。さらに、ネットワークは、任意の接続形式を用いることができ、例えば、IEEE 802.3標準（イーサネット）のような有線接続、IEEE 802.11標準のいずれかの無線接続、また、任意の有線および無線接続の組み合わせを用いることができる。

また、インテグリティオーソリティ140およびオーセンティケーターエンティティ145は、ネットワーク135に接続されたものとして示されている。図２について後述するように、オーセンティケーターエンティティ145は、本発明の種々の実施例に応じて、認証サーバ（authentication server）、検証サーバ（verification server）、ポリシーサーバ等の１または複数のサーバを有することができる。同様に、インテグリティオーソリティ145も後述するような機能を果たす１または複数のサーバを有することができる。図１では、インテグリティオーソリティ140とオーセンティケーターエンティティ145とは別々に示されているものの、当業者は、インテグリティオーソリティ140およびオーセンティケーターエンティティ145の機能が、同一の物理的なマシンまたは同一の物理的なマシンによって実行される複数の仮想的なマシン（仮想化については後述する）によって、統合され、稼働されることも可能なことを理解するであろう。例えば、インテグリティオーソリティ140とオーセンティケーターエンティティ145との両方が１つの企業で制御される場合、両方のマシンの機能を実行する１つのサーバを有することは理にかなう。インテグリティオーソリティ140およびオーセンティケーターエンティティ145は、クライアントプラットフォームを有効にする際、または、リソース150へのアクセスを許可するか否かの決定を行う際に連動して機能する。リソース150は、様々なものを含むサービスでありうるが、中でも、ウエブサービス、またはそのアプリケーション、サーバ、ネットワーク（アクセス制御が提供される組織内でのネットワーク等）、プリンタ、フラッシュメモリーディスク、または他のソリッドステートメモリーデバイス、１または複数のストレージデバイス、そして、出力またはディスプレイを含むものでもよい。

インテグリティオーソリティ140は、上述したハードウェアおよびソフトウェアコンポーネントの両方のデータを格納する。このデータは、ネットワーク135上の他の構成要素（例えば、オーセンティケーターエンティティ145）に供給されることができる。インテグリティオーソリティ140については、後述する図３、図４の説明中で説明する。

イメージファイル155は、クライアントプラットフォーム110のようなクライアントプラットフォームにインストールされていてもよい。イメージファイル155をインストールする様々な方法および実施例については、後述する。図１に示す各種の構成要素は、システム105のマシン間での様々なデータを受信／送信するための受信装置および送信装置を有している。これらの操作については、後述する。

インテグリティオーソリティ140およびオーセンティケーターエンティティ145が複数のサーバで構成されていることを前述したが、当業者であれば、前述した他のマシンにあるインテグリティオーソリティ140およびオーセンティケーターエンティティ145も、すべて仮想化できることを理解するであろう。その上、下記の各マシンは、１または複数のコンピュータ上で稼動している複数の仮想マシンとしてインスタンス化（instantiate）することができる。１または複数のコンピュータは、任意の構成とすることができる。さらに、プラットフォームのインテグリティの検証に用いられるすべてのマシンは、１台のハードウェア上で稼動する複数の仮想マシンとしてインスタンス化することができる。この場合、複数の仮想マシンは、あたかもそれらがすべて別のハードウェアであるかのように情報のやりとりを行う。また、インテグリティオーソリティ140およびオーセンティケーターエンティティ145は、保護されたドメイン下にあるクライアントプラットフォーム110上で稼動する仮想マシンとしてインスタンス化することができる。当業者であれば、仮想マシンの他の可能性のある構成を理解するであろう。ハードウェア上でのマシンの仮想化は、明確に列挙できるか否かに関わらず、すべての下記のマシンに適用することもできる。

図２は、検証サーバ205、認証サーバ210およびポリシーサーバ215を備えたオーセンティケーターエンティティ145の実施例を示している。図２では、オーセンティケーターエンティティ145が１つの場所に設置され、検証サーバ205、認証サーバ210、ポリシーサーバ215が同一の場所に設置されているが、当業者ならば、各サーバは、別々の場所に設置してもよいことを理解するであろう。他の実施例では、オーセンティケーターエンティティ145は、検証サーバ205とポリシーサーバ215とを備えており、認証サーバ210の機能は、検証サーバ205によって達成される。さらに他の実施例では、オーセンティケーターエンティティ145は、１つのサーバを備え、認証サーバ210およびポリシーサーバ215の機能は、検証サーバ205によって達成される。当業者であれば、検証サーバ205、認証サーバ210およびポリシーサーバ215の各機能についての他の組み合わせがあることを理解するであろう。言い換えると、本発明のいくつかの実施例に照らすと、図２に示すいくつかのサーバの実体によって行われるどの機能も、１または複数のサーバによって行われることができる。ポリシーサーバ215は、ポリシーディシジョンポイント（Policy Decision Point、PDP）と呼ばれ、認証サーバ210は、ポリシーエンフォースメントポイント（Policy Enforcement Point、PEP）と呼ばれる。

検証サーバ205は、クライアントプラットフォーム110のインテグリティの状態を検証するように構成されている。各クライアントプラットフォーム(例えば、図１に示す115、120、125、130)は、各クライアントプラットフォームのコンポーネント160についての情報を収集する。当該情報は“ダイジェスト”または“シグネチャ”とも言われる。これらの情報は、トラステッドプラットフォームモジュール（Trusted Platform Module、TPM）チップにあるプラットホームコンフィギュレーションレジスタ（platform configuration register、PCR）から収集される。TPMチップは、トラステッドコンピューティンググループ（Trusted Computing Group、TCG）の団体によって標準化され、推奨されているセキュリティ−ハードウェアチップである。TPMチップのセキュリティ上の特徴は、スマートカードのような他のハードウェアを用いたセキュリティ技術とは区別される。例えば、TPMチップは、インテグリティの測定、メトリクス（metrics）の収集、報告の機能を有している。そして、メトリクスのダイジェストは、PCRに格納される。また、TPMチップは、“シールドロケーション（shield location）”をサポートしている。シールドロケーションは、データが失われる危険を冒すことなく、かつ認証されていない命令にさらすことなく、慎重に行うべき操作が行われることのできるメモリの安全な部位を用意するものである。さらに、TPMチップは、“プロテクテッドケイパビリティズ（protected capabilities）”をサポートしている。プロテクテッドケイパビリティズは、シールドロケーションへのアクセスが禁止されたコマンドのセットである。上記の特徴および他の特徴によって、TMPチップは、信頼性のあるコンピューティング環境にとって理想的なものとなる。

ダイジェストは、また、プラットフォームに特有な他の部位や特徴からも生成することができる。上記特徴は、例えば、TPMと関連しないレジスタや、アプリケーション、プロセス、サービス、スレッドや、これらと同様のものであり、クライアントプラットフォーム110のコンポーネント160についての信頼できる情報源からの信頼できる情報を提供するものであってもよい。アプリケーションソフトウェアのダイジェストを生成する際には、ダイジェストは、アプリケーションの部分であるいくつかのファイルから生成することができ、そのような各ファイルがコンポーネントとされる。例えば、ソフトウェアスイートがワードプロセッサ、スプレッドシート、e-メールパッケージを含んでいる場合、ダイジェストは、他の可能性も考えられるが、各実行ファイルや、スイートの部分である関連づけられた各ライブラリファイルから生成することができる。ある実施例では、ソフトウェアアプリケーションの一部であるすべてのファイルをコンポーネントと考えることができ、他の実施例では、コンポーネントは、より選択的に特定される。当業者ならば、他のソフトウェアアプリケーションのコンポーネントをどのように特定できるか理解するであろう。

ダイジェストは、コンポーネント160のハッシュを含んでいてもよい。コンポーネントのハッシュは、一方向暗号ハッシュ関数を用いて生成することができる。一方向暗号ハッシュ関数としては、MD5, SHA-1, SHA-256等が挙げられ、当業者であれば、他の使用できる一方向暗号ハッシュ関数を理解できるであろう。インテグリティレポートジェネレータ165は、ハッシュや他の生成された情報を含むダイジェストのすべてを収集し、インテグリティレポート170を生成する。図６の説明において後述するように、インテグリティレポート170には、インテグリティレポート170を送信したクライアントプラットフォームの同一性（identity）を検証するために、デジタル署名を行うことができる。

クライアントプラットフォーム110は、認証サーバ210と、プラットフォームインテグリティベリフィケーションハンドシェイクを行う。ある実施例では、プラットフォームインテグリティベリフィケーションハンドシェイクは、プラットフォーム認証セッション中にクライアントプラットフォーム110と認証サーバ210との間での複数の対話（interactions）を含むことができる。プラットフォーム認証セッションは、クライアントプラットフォーム110からの最初のリソース150へのアクセス要求に始まり、クライアントプラットフォーム110のリソース150へのアクセスの許可または拒否の決定で終わる。他の実施例では、認証サーバ210は、クライアントプラットフォーム110の認証の一環としてトラストレポート220を用いることができる。クライアントプラットフォーム110がアクセスを拒否された場合、最後の確認応答（acknowledgment）とセッションの終了が起こる。クライアントプラットフォーム110がアクセスを許可された場合、最後の確認応答とセッションの終了は後で起こる。当業者であれば、最後の確認応答とセッションの終了は延期され、場合によっては全く起こらないかもしれないことを理解するであろう。プラットフォームインテグリティベリフィケーションの間、検証サーバ205は、インテグリティレポートジェネレータ165によって生成されたインテグリティレポート170に含まれるコンポーネント160のダイジェストを評価する。

ある実施例では、検証サーバ205は、クライアントプラットフォーム110のトラストレベルを算定するための評価を行う。検証サーバ205は、また、トラストレポート220を生成する。トラストレポート220は、クライアントプラットフォーム110についての前記評価に従った全体のインテグリティ／トラストスコア225を含むものである。認証サーバ210は、全体のインテグリティ／トラストスコア225をポリシーサーバ215に供給する。ポリシーサーバ215は、クライアントプラットフォーム110のリソース150へのアクセスを許可するか否かを決定するものである。ポリシーサーバ215がクライアントプラットフォーム110のリソース150へのアクセスを拒否した場合、クライアントプラットフォーム110には、拒否の旨が通知されてもよい。例えば、クライアントプラットフォーム110がもはや信用できないほどに、クライアントプラットフォーム110のコンポーネント160が“ドリフトしている(drifted)”（コンポーネント160の認識されたダイジェストから変化している場合）場合、要求される修正は、クライアントプラットフォーム110がイメージファイル155を用いて再イメージ化されるか、さもなくば、やり直しである。あるいは、修正は、リソース150へのアクセスを許可する前に、“ドリフトした”コンポーネントの再インストールまたは削除することを伴うかもしれない。あるいは、クライアントプラットフォーム110は、リソース150へのアクセスを許可されるかもしれないが、もしかすると、そのアクセスは、クライアントプラットフォーム110が“ドリフト”に対処するまで低いレベルでのアクセスとなるかもしれない。当業者であれば、コンポーネントの“ドリフト”を取り扱うための他の可能性のある方法があることを理解するであろう。

他の実施例では、オーセンティケーターエンティティ145がトラストレポート220をクライアントプラットフォーム110に供給することができる。これによって、クライアントプラットフォーム110は、トラストレポート220を他のネットワークリソースやサービスへアクセスするための、“トラストチケット（trust ticket）”の一種として使うことができる。当該他のネットワークリソースやサービスも、トラストレポート220の有効性を検査するためのオーセンティケーターエンティティを有していてもよい。当業者であれば、無数のリソースやサービスが、トラストレポート220を用いるクライアントプラットフォーム110からアクセス可能であることを理解するであろう。

トラストレポート220は、トラストスコア225とは別に、どのマシンがオーセンティケーターエンティティ145およびインテグリティオーソリティ140として機能していたかについての表示を含んでいる。この情報は、トラストスコア225の信頼性を検証するのに用いることができる。サードパーティーはこの情報を、どのマシンがトラストスコア225の生成を担っていたかを判断するために用いることができる。特殊な例として、オーセンティケーターエンティティ145および／またはインテグリティオーソリティ140が仮想マシンである場合、この情報は、仮想マシンがインスタンス化されている物理マシンの表示を含むものとすることができる。したがって、例えば、オーセンティケーターエンティティ145およびインテグリティオーソリティ140がともにクライアントプラットフォーム110上でインスタンス化されている場合、サードパーティーは、問題となっている仮想マシンが、信頼性について分析がなされた同じ物理ハードウェアプラットフォーム上でインスタンス化されたものであることに気づくであろう。

検証サーバ205は、プロファイルデータベース235にクライアントプラットフォームインフォメーション230を格納することができる。クライアントプラットフォームインフォメーション230は、様々なものを含むことができるが、とりわけ、インテグリティレポート170および全体のインテグリティ／トラストスコア225を有するトラストレポート220を含むことができる。また、クライアントプラットフォームインフォメーション230は、評価の日時、クライアントプラットフォームコンフィグレーションの情報、インテグリティプロファイル（ここでは、“スキャンポリシー”とも言う）、ユーザー情報、そして、マシンに特有の情報を含むことができる。検証サーバ205は、プロファイルデータベース235に格納された情報をスキャンポリシーを実行するために用いることができる。例えば、ある組織は、財務部門に所属しているような特定のユーザーに対し、クライアントプラットフォーム110にあるコンポーネントのセットを持つことを要求し、一方では、他の“通常”のユーザーに対しては異なるコンポーネントのセットを持つことを要求してもよい。加えて、サブポリシーは、最高財務責任者のような財務部門の特定の人物に対し、追加の所定のコンポーネントを持つことを要求することができる。スキャンポリシーは、どのコンポーネントが存在するかを検証するだけでなく、どの程度、どの方法によってあるクライアントがスキャンされたかを検証することができる。上述した例では、スキャンポリシーは、2つのセットの要件で実施されたが、当業者であれば、無数の要件およびスキャンポリシーの階層(tiers)を実施可能であることを理解するであろう。

ポリシーサーバ215は、所定の機関のためにカスタマイズされたポリシーを実施することができる。例えば、銀行について検討する。銀行の顧客が、クライアントプラットフォーム110を介して銀行の彼らのアカウントにアクセスすることを望む際には、ポリシーサーバ215は、全体のインテグリティ／トラストスコア225に従って、銀行の口座情報への段階的なアクセスを与えることを選択することができる。例えば、全体のインテグリティ／トラストスコア225が最初の閾値を超えていた場合、アクセスは、口座残高や、口座の明細等の口座情報や口座のリソースの一部まで許可される。全体のインテグリティ／トラストスコア225がより高い２番目の閾値を超えていた場合、アクセスは、電子送金を行えるような、より高いレベルの口座情報や口座のリソースまで許可される。上述の例では、ポリシーは、２つのトラストスコアの閾値を用いて、２つのセットのリソースへのアクセスを実施していたが、当業者であれば、無数の閾値とアクセスの段階を実施できることを理解するであろう。

図３は、本発明の実施例に係るインテグリティオーソリティ140を示す。インテグリティオーソリティ140は、複数のコンポーネント310から生情報（raw information）305を収集し、情報315（コンポーネントのダイジェストを含む）を検証するとともに精製し、精製情報315をインテグリティ／トラストレコード320としてグローバルシグネチャデータベース（GSDB）325に格納する。より具体的には、インテグリティオーソリティ140は、これらのコンポーネント310についての未加工の情報305をそれらの供給元（例えば、製造業者、ソフトウェアの販売元、ハードウェアの販売元等）から収集する。前述したように、ダイジェストは、市販の製品からレコードを収集することにより得ることができる。また、ダイジェストは、直接製造業者から、アップロードされることにより、または直接的な手段を通じて情報を得ることより、または他の手段を用いることにより得ることができる。コンポーネントの収集において、全体の信頼のレベルが最も高いものとなるような技術が用いられることが好ましい。例えば、コンポーネントの“流通過程の管理”ができるだけ安全なものとなる技術が用いられることが好ましい。オーセンティケーターエンティティ145（図１参照）は、クライアントプラットフォーム110の信頼性のレベルを評価するため、GSDB 325にある情報を用いることができる。この信頼性のレベルの評価は、GSDB 325のインテグリティ／トラストレコード320と、クライアントプラットフォーム110（図１）から受信したインテグリティレポート170（図１）に記載された個々のコンポーネントとを比較し、クライアントプラットフォーム110（図１）に全体のインテグリティ／トラストスコア225（図２）を割り当てることにより行われる。

情報を収集した後に、インテグリティオーソリティ140は、既定のヒューリスティックス（heuristics）を用いて、情報の正確さを検証する。ある実施例では、ヒューリスティックスは、コンピューターアプリケーションまたはプログラムによる自動的な手段を介して適用される。他の実施例では、権限が与えられた個人によってマニュアルの検証が行われる。また、他の実施例では、情報は、収集され、規格化されたフォーマット（精製情報）315の状態で格納される。例えば、生情報305の検証は、生情報を精製情報315に精製し、インテグリティ／トラストレコード320の形式で格納できるようになされてもよい。加えて、インテグリティ／トラストレコード320は、収集した情報を検証するために、元の製造業者に送り返すことによって、さらに検証がなされてもよい。これは、収集されたデータにおける“ループの閉鎖（closing the loop）”と言うことができる。

インテグリティ／トラストレコード320は、検索オペレーションに利用することができ、その場合、検証サーバは、図２で上述したように、クライアントプラットフォームインテグリティレポートを用いてクライアントプラットフォームのインテグリティを検証することを試みることができる。ある実施例では、検索オペレーションは、ウェブサービスインターフェイスを介して図２の検証サーバ205によって開始される。検索オペレーションは、コンポーネント毎を基本として、連続して行われることができる。あるいは、検索オペレーションは、１つのメッセージであってもよく、または複数の検索要求を含むバッチプロセスであってもよい。加えて、検索オペレーションは、GSDB 325に格納された情報およびダイジェストの制約が加えられたセットやカテゴリーについて行うことができる。これは、検索の範囲を制限するとともに、GSDB 325のパフォーマンスを改善するために行われる。当業者であれば、検索の範囲を制限することは、パターンマッチングや、集合論等を利用することにより遂行されることを理解するであろう。また、当業者であれば、例えば、直接的な接続、ウェブサービス以外のインターフェース、または他のネットワーク手段を介して検索オペレーションが行われる方法があることを理解できるであろう。

図４は、本発明の実施例に係るインテグリティ／トラストレコード320の拡大図である。インテグリティオーソリティ140は、上述した図３に記載の方法によってインテグリティ／トラストレコード320を生成する。各インテグリティ／トラストレコード320は、ハッシュ405を含むことができる。また、各インテグリティ／トラストレコード320は、インテグリティオーソリティ140を特定する情報410を含むことができる。コンポーネントインフォメーション415は、コンポーネントアイデンティティ、コンポーネントの説明、コンポーネントの製造業者、モデル番号、バージョンリリース、パッチバージョン、製造日、製造地（例えば、国名、場所）等を含むことができる。また、インテグリティオーソリティ140のインテグリティ／トラストレコード320は、下記のようなその他の情報420を含むことができる。
レコードインフォメーション
レコードシリアルナンバー
現在のインテグリティ／トラストレコードの有効期間の開始日
現在のインテグリティ／トラストレコードの有効期間の終了日
レコードの発行者
収集情報
収集者のアイデンティティ（harvester identity）
収集方法
収集日時
割り当てられたインテグリティ／トラストスコア
ハッシュ値
リファレンス
他のサブコンポーネントのインテグリティ／トラストレコードのリファレンス
元の原製造業者（raw manufacturer）のデータのリファレンス
標準仕様のリファレンス
署名者（サイナー、signer）の情報
署名者（インテグリティオーソリティ）のアイデンティティ
インテグリティオーソリティの証明書のリファレンス
インテグリティオーソリティのデジタル署名

図５は、本発明の実施例に係る検証サーバ205の拡大図である。また、トラストレポート220の拡大図が示されている。トラストレポート220は、全体のインテグリティ／トラストスコア225、クライアントプラットフォームアイデンティティ505（例えば、物理的なシリアルナンバー）、検証サーバ205のTPM証明書のリファレンス510、検証サーバアイデンティティ515を含むことができる。TPM証明書（およびTPMに関連した証明書）は、通常、改ざん耐性のあるハードウェアに格納されており、関連したレポートの内容のソースについての証明を供給する。トラストレポート220は、また、その他の情報520を含むことができ、その他の情報520は、クライアントプラットフォーム110のTPM証明書への１または複数のリファレンス、評価の日時、検証サーバ205の電子署名、クライアントプラットフォームから収集されたダイジェストが比較されたデータベースへのリファレンスを含むことができる。（通常、各データベースに格納されているダイジェストは、同一のものであるべきだが、同期の遅れや、データベースポリシーマネージメントのせいで、クライアントプラットフォームの信頼性を検証するのに用いられるデータベースは、潜在的に同期対象外（out-of-synch）であったものとすることができる。）加えて、その他の情報520は、１または複数のコンポーネント160のリストを含むことができ、その場合、コンポーネントは、GSDB 325（図３参照）にある当該各コンポーネント160と対応したインテグリティ／トラストレコード320へのリファレンスを有している。検証サーバ205は、クライアントプラットフォーム110についての評価に従って、トラストレポート220を生成する。

コンパレータ525は、インテグリティレポート170中のダイジェストと図３のGSDB 325にあるインテグリティ／トラストレコード320とを比較するために用いられる。インテグリティレポート170中のダイジェストとインテグリティ／トラストレコード320と比較することにより、検証サーバ205はクライアントプラットフォーム110の信頼性のレベルを判定することができる。この信頼性のレベルは、トラストレポート220において、全体のインテグリティ／トラストスコア225として表わされる。

ダイジェストの種類と量は、全体のインテグリティ／トラストスコア225に影響を与えうる。例えば、オペレーティングシステムに関するダイジェストは、ゲームソフトウェアに関するダイジェストよりも重要となる可能性がある。全体のインテグリティ／トラストスコア225は、クライアントプラットフォーム110から集められたダイジェストに関連したファクターだけでなく、インテグリティレコード320の信頼性に関連したファクターによっても影響を受ける。前述したように、インテグリティレコード320に記憶されたコンポーネントの流通履歴は、各インテグリティ／トラストレコード320に記載のコンポーネントに割り当てられた個々のインテグリティ／トラストスコア425（図４参照）に影響を与える。そして、インテグリティ／トラストレコード320は、最終的に、クライアントプラットフォーム110について判定された全体のインテグリティ／トラストスコア225に影響を与うる。インテグリティレポート170に署名する証明書の種類や、GSDB 325に格納されたダイジェストの合計数と比較したクライアントプラットフォーム110から収集されるダイジェストの合計数等の他のファクターも、全体のインテグリティ／トラストスコア225に影響を与える。加えて、その定義されたカテゴリーやセットに対してマッチしたダイジェストの数に制約を課すことによって、セット内とセット外のコンポーネントの数がわかり、また、どのコンポーネントがすっかりなくなっているかがわかる。

本件出願人に譲渡されたU.S. Patent Application Serial No. 11/288/820では、インテグリティ／トラストスコア225を決定することのできる方法について詳しく説明している。インテグリティ／トラストスコアは、コンピュータシステムの全体のインテグリティの指標、またはコンピュータシステムが信頼に値するものとみなすことができるか否かの指標となる。インテグリティ／トラストスコアは多くの異なる方法によって生成できる。ある実施例では、インテグリティ／トラストスコアは、コンピュータシステムのコンポーネント全部（有効とされたか否かに関わらず）の数に対するコンピュータシステム上の有効とされたコンポーネントの数の比である。他の実施例では、インテグリティ／トラストスコアは、０から１０００の間の数字で評価される。ここで、０は、全く信用できないコンピュータシステムを示し、１０００は、完全に信用できるコンピュータシステムを示す。さらに、他の実施例では、重要なコンポーネントは、他のコンポーネントよりも大きく重み付けをすることができる。このため、より多くの有効とされた重要なコンポーネントを有するコンピュータシステムが、より少ない有効とされた重要なコンポーネントを有するコンピュータシステムより高いスコアを得ることができる。（“重要な”の定義は、潜在的なすべてのユーザーにすべての状況で“必要”とされるコンポーネントを示すことは意図していない。むしろ、問題となっている組織で重要であると特定されるコンポーネントを示すことを意図している。このため、ある組織は、オペレーティングシステムに関するファイルが“重要”であると考えるかもしれず、一方で、他の組織は、内部で特別に開発したコンポーネント（どのような目的のためであっても）を“重要”であると考えるかもしれない。あるコンポーネントが“必要”かつ“重要”であることはありうるが、一方の性質が他方の性質を示唆するものではない。）

インテグリティ／トラストスコア225を計算することができる他の方法がある。他の実施例では、シグネチャデータベース内での様々な有効とされたコンポーネントの位置をファクターとして用いることができる。例えば、シグネチャデータベース内において先にリストに挙げられたコンポーネントは、シグネチャデータベース内において後で生じたコンポーネントよりも重要なものと考えることができる。同様に、インテグリティレポートジェネレータ165（図１）がどのコンポーネントがクライアントプラットフォームの総合的なインテグリティにとってより重要かを示して、コンポーネントのダイジェストを収集する場合（例えば、インテグリティレポート170に、重要度の順番でダイジェストをリスト化する場合）、当該情報もまた、インテグリティ／トラストスコア225に組み込むことができる。他の実施例では、インテグリティ／トラストスコア225は、コンポーネントの識別子に組み込むことができる。ある製造業者によって製造されたコンポーネントは、他の製造業者によって製造されたコンポーネントより、より重要でありうる。例えば、アプリケーションと共同で機能するコンポーネントを考えるとよい。アプリケーションの製造業者によって製造されたコンポーネントは、サードパーティーによって製造されたコンポーネントよりも重要と考えることができる。

さらに、他の実施例では、コンポーネントのバージョンおよび／またはパッチのレベルは、インテグリティ／トラストスコアの計算を行う際のファクターとして用いられることができる。例えば、コンポーネントがいくつかのバージョンを有すると仮定すると、より最新のバージョンは、古いバージョンよりも重要であると考えることができる。もし、有効とされたコンポーネントが期限切れとなると、その結果としてのインテグリティ／トラストスコアは、より最新のバージョンの同じコンポーネントを有している他の同一のコンピュータシステムよりも低くなりうる。一方で、新しいコンポーネントに信頼性を疑う理由がある場合（例えば、当該コンポーネントは、欠陥があると知られている場合）、当該新しいバージョンのコンポーネントを有することは、インテグリティ／トラストスコアをより低いものとするかもしれない。

上記の比較オペレーションにおいて、検証サーバ205は、インテグリティレポート170を解析し、インテグリティレポート170の各ダイジェストについてインテグリティオーソリティ140（図３）のGSDB 325への検索オペレーションを行う。この検索オペレーションは、コンポーネント単位で連続して行うことができる。もしくは、検索オペレーションは、それぞれが複数の検索要求を含む１または複数のメッセージであってもよい。また、検索オペレーションは、よりきめ細かい結果を提供するとともに、GSDB 325の総合的なパフォーマンスを向上させるために、情報のあるカテゴリーやセットに対して範囲を絞るものであってもよい。

ある実施例では、クライアントプラットフォーム110がネットワーク135のリソース150へのアクセスを許可される前に、検証サーバ205は、クライアントプラットフォーム110のインテグリティを検証することができる。他の実施例では、コンパレータ525は、一定時間の間、定期的に比較オペレーションを行うことができるが、最初のアクセスを許可された後に初めて比較オペレーションを行うようにしてもよい。例えば、ホームコンピュータのユーザーは、コンポーネント160の評価をするように指示しながら、ネットワーク135へのアクセスを得ようとするかもしれない。しかしながら、常時接続であるブロードバンド接続は、ホームコンピュータのユーザーの間でもありふれたものとなってきている。ブロードバンド接続は、ユーザーがネットワークにログインする回数を減らすことができる。また、このことは、法人および企業のコンピュータユーザーにも同様にあてはまる。結果として、コンパレータ525は、クライアントプラットフォーム110のネットワーク135への最初の接続の試みと同時ではなく、それからしばらくたって、比較オペレーションを行うことができる。

図６は、本発明の実施例に係るインテグリティレポート170の拡大図である。クライアントプラットフォーム110は、通常、XMLのような標準的な形式または言語で、インテグリティレポート170を生成する。しかしながら、当業者であれば、標準的でないフォーマットや言語も用いることができることを理解するであろう。インテグリティレポート170は、TPM証明書610を用いてデジタル署名605がなされる。当業者であれば、TPMチップを含むどのような証明書でも用いることができ、このため、TPM証明書610は、Endorsement Key（EK）証明書、Attestation Identity Keys (AIK)証明書、またはSubject Key Attestation Evidence (SKAE)証明書とすることができることを理解するであろう。さらに、当業者であれば、インテグリティレポート170は、必ずしもTPM証明書ではなくても、TPMに規定された証明書から派生した証明書によって署名されることもできるし、他の証明書によって署名されることもできることを理解するであろう。

上述したように、インテグリティレポート170は、クライアントプラットフォームにある複数のコンポーネントの複数のダイジェストを含むことができる。ある実施例では、これらのダイジェストは、それらのコンポーネント160のハッシュ615として計算される。他の実施例では、これらのダイジェストは、GSDB 325（図３）のインテグリティ／トラストレコード320に保存されたコンポーネントに関連付けられたダイジェストと比較されることができる。他の実施例では、ダイジェストは、図７において後述するローカルシグネチャデータベース（LSDB）のインテグリティ／トラストレコードに保存されたコンポーネントに関連付けられたダイジェストのサブセットと比較される。そして、その中で見つからない場合は、ローカルデータベースで照合されなかったダイジェストについてGSDB 325を参照することができる。さらに、他の実施例では、ローカルデータベースは、完全にグローバルデータベスのダイジェストと同期し（正確に照合され）、場合によってGSDB 325を参照する必要性をなくすことができる。

図７は、本発明の実施例に係るシステム705を示しており、システム705は、企業ネットワーク710のオーセンティケーターエンティティ145に接続されたクライアントプラットフォーム110を含む。オーセンティケーターエンティティ145は、インテグリティオーソリティ140と相互にやりとりを行うことができる。企業ネットワーク710は、インターネット715や上述したような他の任意のネットワークを介してインテグリティオーソリティ140と接続されることができる。図７に示すように、クライアントプラットフォーム110は、企業のワイヤレスアクセスポイント720を経由して無線でオーセンティケーターエンティティ145と接続されている。しかしながら、当業者であれば、クライアントプラットフォーム110は、IEEE 802.3規格（イーサネット）のような有線接続、IEEE 802.11規格のような無線接続や、任意の有線または無線のネットワークの組み合わせ等の、任意の形式の接続を用いて企業ネットワーク710に接続可能であることを理解するであろう。

上述したように、オーセンティケーターエンティティ145は、クライアントプラットフォーム110の評価をする。この評価は、クライアントプラットフォーム110が企業ネットワーク710にアクセスを求めたときに行われる。すなわち、評価は、クライアントプラットフォーム110を認証の一部であり、クライアントプラットフォームが特定のリソースへのアクセスを要求する前である。オーセンティケーターエンティティ145は、クライアントプラットフォーム110を他の期間に評価することができる。例えば、オーセンティケーターエンティティ145は、場合によっては、企業のポリシーに従って、定期的にクライアントプラットフォーム110を再評価してもよい。ある実施例では、オーセンティケーターエンティティ145は、クライアントプラットフォーム110からのインテグリティレポート170を要求することにより、クライアントプラットフォーム110のコンポーネント160を評価することができる。クライアントプラットフォーム110は、インテグリティレポートジェネレータ165を用いて、インテグリティレポート170を生成する。インテグリティレポート170にあるコンポーネント160を表す各ダイジェストに対して、オーセンティケーターエンティティ145は、後に詳述するLSDB 720から前記ダイジェストに対応するインテグリティ／トラストレコード725を特定する。クライアントプラットフォーム110の信頼性のレベルを評価するために、インテグリティ／トラストレコード725は、コンポーネント160のハッシュと比較される。

他の実施例では、オーセンティケーターエンティティ145は、例えばクライアントにトンネリングする適当なサーバによって、クライアントプラットフォーム110を遠隔で評価することができ、そのため、クライアントプラットフォーム110からのインテグリティレポート170を要求しない。その代りに、オーセンティケーターエンティティ145は、遠隔の評価を基にしてインテグリティレポート170を生成する。この遠隔の評価は、様々な機構を用いて行うことができる。例えば、「Intel vPro」 technologyを用いることができる（「Intel vPro」は、アメリカおよびその他の国におけるIntel Corporationおよびその子会社の登録商標である）。当業者であれば、他の機構を用いることができることを理解するであろう。

LSDB 720にあるインテグリティ／トラストレコード725は、定期的に、アップデートされ、GSDB 325にあるインテグリティ／トラストレコード320と同期させられる。これは、LSDB 720が最新のインテグリティ／トラストレコードを利用できることを確保するためである。ある実施例では、企業ネットワーク710での評価オペレーションに関連するインテグリティ／トラストレコード320のみがLSDB 720に転送される。GSDB 325の一部を格納することにより、ネットワークトラフィックを減らすことができ、また、LSDB 720のサイズを最小化することができる利点がある。LSDB 720の特定のインテグリティ／トラストレコードが、不使用になったり、他の理由でもはや必要でなくなる場合、当該レコードは、LSDB 720から削除され、将来において必要とされる時や、将来必要になる場合、当該レコードは後にGSDB 325から再取得される。例えば、企業のポリシーがその企業で用いられる最新のバージョンの仮想プライベートネットワーク（virtual private network、"VPN"）のみが許可されると規定されている場合、旧式のVPNに関連するインテグリティ／トラストレコードは、LSDB 720から削除される。GSDB 325およびLSDB 720もまた、仮想化することができる。例えば、各データベースは、同一または異なる物理マシンにある異なる仮想マシンに設置することができる。仮想マシンは、クライアントプラットフォーム110に設置することもできる。

GSDB 325とLSDB 720との間での同期またはアップデートは、安全で認証された回線（channel）を通じて行うことができ、企業のポリシーの示す適正なタイミングで行うことができる。例えば、LSDB 720が常に最も新しい関連したレコードを含むべきであると企業のポリシーが示す場合、GSDB 325は、これらのレコードが利用可能になり次第、当該レコードを供給することができる（例えば、LSDB 720に新しいレコードがあり、回収待ちであることを伝えることにより、または、レコードをLSDB 720にプッシュすることにより供給される）。一方、十分な数のレコードがGSDB 325から回収できるときにLSDB 720はアップデートされるべきと企業のポリシーが指示する場合、または企業の雇用者への不都合をできるだけ少なくすべきと企業のポリシーが指示する場合、ネットワークまたはインフォメーションテクノロジー（information technology、"IT"）の管理者が指示する適正なタイミングで、アップデート／同期が行われる。これらは、マニュアルであってもよく、スケジュール化されていてもよく、あるいは自動であってもよい。

LSDB 720のアップデートでは、LSDB 720に存在するインテグリティ／トラストレコードと入れ替えることなく、新しいインテグリティ／トラストレコードをLSDB 720に追加することができる。同様に、GSDB 325も、新しい情報が収集され、新しいインテグリティ／トラストレコード725が生成された際に、アップデートされるようにすることができる。GSDB 325の新しいインテグリティ／トラストレコード725は、必ずしも古いものを置き換える必要はなく、GSDB 325の既存のレコードに追加することができる。

他の実施例では、企業ネットワーク710に特有であり、ローカルにのみ関連するインテグリティ／トラストレコード725を、権限が与えられたネットワーク管理者が、LSDB 720に追加することができる。この場合、LSDB 720は、GSDB 325に類似するものがないレコードを含む。例えば、企業ネットワーク710内でのみ生成され、かつ、使用されるファイル（コンフィグレーションファイルやその他の企業システムデータ等）や、他の企業のシステムデータは、例えば、企業ネットワーク710のネットワーク管理者等のリーガルオペレータ（legal operator）によって認証されたインテグリティ／トラストレコード725を有することができる。これは、クライアントプラットフォーム110の評価を行うための、企業ネットワーク710に特有のものを含めたすべての必要なインテグリティ／トラストレコード725に対して、オーセンティケーターエンティティ145がアクセスすることを保証するものである。

LSDB 720については、企業ネットワーク710内でローカルに格納された一部のインテグリティ／トラストレコード725は、クライアントプラットフォーム110への図１のイメージファイル155のインストール後に、クライアントプラットフォーム110のインテグリティレポート170に格納されたハッシュを用いて、相関性をチェックすることができる。比較（相関性のチェック）において、クライアントプラットフォーム110にある１または複数のコンポーネントのハッシュがLSDB 720に格納されたハッシュと異なる場合、ユーザーは、クライアントプラットフォーム110をイメージファイル155を用いて再イメージ化することを要求されることができる。他のやり方として、ハッシュが異なるコンポーネントを再インストールするか削除することで修正してもよい。あるいは、クライアントプラットフォーム110は、リソース150へのアクセスを許可されるかもしれないが、クライアントプラットフォーム110が問題を解決するまでは、おそらく、低いレベルでのアクセスとなるであろう。当業者であれば、他の修正法が用いられることが可能であることを理解するであろう。もし、照合されないハッシュの数が重要でない場合、オーセンティケーターエンティティ145（図１）は、リソース150（図１）へのアクセスを許可することができる。ここで、“重要でない”とは、インテグリティレポート170のハッシュの十分な数が、インテグリティ／トラストレコード725に格納されたハッシュと対応して照合されることを意味する。イメージファイル155を伴った追加の使用例は、後に詳述する。

他の実施例では、財務上のデータを保護するように特殊設計された企業ネットワーク710を含むことができる。例えば、サーベンス・オクスリー法（Sarbanes-Oxley Act）のような連邦法は、
コンピューターネットワーク（特に重要な金融データの保管に関して）の安全性、正確性、信頼性について、最高情報責任者（CIO）が責任を負うことを要求している。システム705を採用することにより、CIO達は、LSDB 720と連動するオーセンティケーターエンティティ145によって行われる評価に失敗した場合、クライアントプラットフォーム110の企業ネットワーク710へのアクセスを拒否することによって信頼でき安全なネットワークを維持できる。さらに、異なるクライアントプラットフォームに対して、異なるレベルのセキュリティを設定することができる。例えば、CIOのクライアントプラットフォームは、ハードドライブ上のすべてのデータを暗号化することが要求されるのに対し、通常の従業員のクライアントプラットフォームは、そのような特徴は要求されない。

さらに、他の実施例では、インテグリティレポート170を生成し、クライアントプラットフォーム110によるリソースへのアクセスを制御するモジュールはクライアントプラットフォーム110に組み込まれておらず、クライアントプラットフォーム110の外部にある。図８は、図１のクライアントプラットフォーム110と、図２のオーセンティケーターエンティティ145とともに、ポータブルダイジェストコレクタードングル805を示している。図８に示された種々の構成要素は、マシン間で様々なデータを送受信するための種々の受信部と送信部を有しており、これらについては、他の実施例で説明されている。ドングル805は、特に限定されず、USBメモリードライブ810、スマートカード、トークン（token）、メモリスティック、外部ハードドライブや周辺機器等の任意の形式をとることができる。当業者であれば、他の使用可能な機器を理解できるであろう。ドングル805は、セキュリティを追加することで、改ざん耐性を持つことができる。ドングル805が改ざん耐性を有する場合、ドングル805をどのように逆アセンブル（disassemble）しようと試みても、結果として、ドングル805は操作不可能なものとなる。クライアントプラットフォーム上に当該クライアントプラットフォームを検証するのに使用される種々の構成要素を有する代わりにドングル805を使用する１つの利点としては、ドングル805は、人に優しく、しかも、ユーザーの物理的な存在とクライアントプラットフォーム110の認証とをより密接に結びつけることである。例えば、ユーザーは、１つのコンピュータに制限されるのではなく、公共の図書館にあるコンピュータのような任意のコンピュータに対してドングル805を適用することができる。クライアントが他のマシンやネットワークに帰属していない場合であっても、ドングル805は、クライアントプラットフォーム110に取り付けられることができ、自己の有するプラットフォームのインテグリティの検証を行うことができる。この実施例は、下記の図９において詳述する。

ドングル805は、ダイジェストコレクター815、トラストエンジン820、セキュアストレージ825、クレデンシャル（credential）830、セキュアインターフェース835を有することができる。ダイジェストコレクター815は、セキュアインターフェース835を介してクライアントプラットフォーム110にあるダイジェストコレクタープロキシ840とやり取りを行うことができる。ダイジェストコレクタープロキシ840は、Microsoft Corporationのシステム正常性エージェント（the System Health Agent 、"SHA"）のような、クライアントプラットフォーム110にある標準の仮想マシン（virtual machine 、"VM"）のコンポーネントとすることができる。また、ダイジェストコレクタープロキシ840は、プラットフォームのインテグリティの検証を開始する前に、ドングル805からクライアントプラットフォーム110へ転送された、標準品でなく専売品の（proprietary）VMコンポーネントであってもよい。トラストエンジン820は、ドングル805内のソフトウェアが信頼して実行されるようにすることを可能にするための、１または複数の実行ファイル（executable）またはルーチン（routine）を供給する。セキュアストレージ825は、限定されたコマンドや物理的な接触点のセットのみを公開することにより、プライベートキー845のような慎重に扱うべきデータを格納するための改ざん耐性のあるロケーション（location）を提供する。また、ドングル805は、セキュアストレージでないスペースを有していてもよい（図示せず）。ユーザークレデンシャル830は、１または複数の証明書850を含むことができる。証明書850は、X509フォーマットに従うことができる。X509フォーマットは、証明書内のフィールド（field）を示す取り決めである。証明書の例としては、セキュアIDやTPM証明書等を挙げることができ、その他ものもあるが、これらは、ユーザーをオーセンティケーターエンティティ145に対し認証することを補助するものである。証明書850は、プライベートキー845を含んでおり、これは、後に詳述する。

ある実施例では、ダイジェストコレクター815は、クライアントプラットフォーム110のダイジェストコレクタープロキシ840を介して最終的にオーセンティケーターエンティティ145のダイジェストエバリュエータープラグイン855へインテグリティレポート170を送信する前に、プライベートキー845を用いてインテグリティレポート170を暗号化することにより、ユーザークレデンシャル830を用いることができる。ユーザークレデンシャル830の使用により、インテグリティレポート170の送信中におけるさらなる保護層（保護階層）を追加することができる。すなわち、ユーザークレデンシャル830が証明書850を含む場合、証明書850に対応するプライベートキー845が、インテグリティレポート170のデジタル署名に用いられる。当業者であれば、ダイジェストエバリュエータープラグイン855は、オペレーティングシステムの標準のソフトウェアコンポーネントであってもよいことが理解できるであろう。また、ダイジェストエバリュエータープラグイン855は、標準品でなく専売品のソフトウェアコンポーネントであってもよい。

他の実施例では、オーセンティケーターエンティティ145にある証明書865のパブリックキー860
にダイジェストコレクター815がアクセスした場合、ダイジェストコレクター815は、パブリックキー860を用いてインテグリティレポート170を暗号化することができる。これにより、インテグリティレポート170をオーセンティケーターエンティティ145のダイジェストエバリュエータープラグイン855へ送信する際に、より一層の機密性が付与される。さらに、他の実施例では、ユーザークレデンシャル830とオーセンティケーターエンティティ145とがプライベートキーを共有している場合、ダイジェストコレクター815は、インテグリティレポート170を、共有しているプライベートキーで暗号化することができる。

さらに、他の実施例では、ドングル805は、インテグリティレポート170（図１）をオーセンティケーターエンティティ145へ送信するために、セキュアトンネル（例えば、セキュアインナートンネル870、セキュアアウタートンネル875）を構築することができる。セキュアインナートンネル870およびセキュアアウタートンネル875は、ドングル805からオーセンティケーターエンティティ145までの端から端までのセキュアな回線を、基礎をなす物理的な通信手段（例えば、IEEE 802.3イーサネット、 IEEE 802.11 WiFi等）に関わりなく、構築することができる。セキュアアウタートンネル875は、クライアントプラットフォーム110とオーセンティケーターエンティティ145との間で、好ましくはインテグリティエージェント880とインテグリティサーバ／ブローカー885とを連結するように確立されることができる。インテグリティエージェント880およびインテグリティサーバ／ブローカー885は、標準のトラステッドネットワークコネクション（trusted network connection、"TNC"）の端点とすることができる。TNCは、分離したパブリック／プライベートの暗号化鍵を用い、IPパケットを安全に信頼できる方法で送信することができる。

クライアントプラットフォーム110とオーセンティケーターエンティティ145との間の通信は、
クライアント側にあるネットワークアクセスリクエスター890およびサーバ側にあるネットワークアクセスオーソリティ895によって補助されることができる。ネットワークアクセスリクエスター890およびネットワークアクセスオーソリティ895は、ともに、IEEE 802.3（イーサネット）や、IEEE 802.11のような無線（wireless/radio）のような物理的なパケットレベルでの媒体を備え、これらの媒体を介して通信が行われる。セキュアアウタートンネル875は、拡張認証プロトコル（Extensible Authentication Protocol、"EAP"）、ラディウス（Radius）、TLS(Transport Layer Security)のような標準プロトコルを用いることができる。当業者であれば、非標準プロトコルを含む他のプロトコルを用いることができることが理解できるであろう。セキュアアウタートンネル875が構築されたあと、セキュアインナートンネル870がドングル805とオーセンティケーターエンティティ145との間で構築される。セキュアインナートンネル870は、好ましくは、ダイジェストコレクター815とダイジェストエバリュエータープラグイン855とを連結するものである。セキュアインナートンネル870は、他のコンポーネント（潜在的に存在するセキュアアウタートンネル875を含む場合でも）にセキュリティを委ねる必要がないように、ドングル805とクライアントプラットフォーム110またはオーセンティケーターエンティティ145との間で、または任意のマシンの任意のソフトウェアコンポーネント間で、構築することができる。セキュアインナートンネル870の構築については、図９を参照しつつ、以下に詳述する。

図９は、ポータブルダイジェストコレクタードングル（ドングル）805にGSDB 325が含まれている図８のシステムを示す。本実施例では、ドングル805は、オーセンティケーターエンティティ145を参照することなく、クライアントプラットフォーム110のインテグリティを検証することができる。ドングル805は、クライアントが他のマシンやネットワークに接続されていなくても、クライアントプラットフォーム110に接続されることができる。そして、ドングル805は、自己完結したプラットフォームのインテグリティの検証を行うことができる。GSDB 325の情報の全部または一部は、セキュアストレージ825または、非セキュアストレージ（図示せず）のどちらかに格納されることができる。トンネル870は、実質的に、図８にて上述したセキュアインナートンネル870と同じように動作するものである。その一方で、図９の構成では、トンネル870は、アウタートンネルを通過せずに、クライアントプラットフォーム110にドングル805を接続している点で、図９の構成と、相違する（図８の構成では、ドングル805はオーセンティケーターエンティティ145に接続されていない）。したがって、ローカルのドングル805がアクセスしやすいGSDB 325のインテグリティ／トラストレコード320を有することによって、実質的に上述した他の実施例のようなプラットフォームのインテグリティの検証プロセスが、自己完結する方法で、読み込まれ、起動される。言いかえると、クライアントプラットフォーム110は、検証が行われるために、ネットワークや、他のマシンへ接続されることが要求されない。まだどのネットワークにも接続されていない多数のマシンを検証したいIT管理者にとっては、これは、特に便利で効率よいものである。

図１０は、クライアントプラットフォーム110（図１）を配備するプロセス中における、クライアントプラットフォーム110のコンポーネント160のインテグリティの検証を行うための手順のフローチャートを示す。IT管理者や他の適当な権限を有する人間は、企業のドメイン内に新しいプラットフォームを提供するという状況の中で、クライアントプラットフォーム110のコンポーネントおよび構成（configuration）を検証したがるかもしれない。ステップ1005では、IT管理者は、配備するクライアントプラットフォーム110を受け取る。すなわち、納入業者、製造業者、ＯＥＭ（original equipment manufacturer）、あるいは他の供給源から、クライアントプラットフォーム110（例えば、ＰＣクライアント、サーバ、ルータ、スイッチ、PDA、携帯電話等）を受け取る。

ステップ1010では、IT管理者は、イメージファイル155からクライアントプラットフォーム110へ少なくとも１つのコンポーネントをインストールする。当業者であれば、コンポーネントは、イメージファイル155を使用することなく、インストールされることが可能であることが理解できるであろう。例えば、IT管理者は、コンポーネントの製造業者から供給されたツールや、他の専売品の機器構成管理ツール（configuration management tool）を用いてコンポーネントをインストールすることができる。ステップ1015では、クライアントプラットフォーム110にコンポーネント160が（イメージファイル155からかもしれないが）インストールされた後に、クライアントプラットフォーム110上のインテグリティレポートジェネレータ165は、インテグリティレポート170（図１）を生成する。ステップ1020では、全体のインテグリティ／トラストスコア225（図２）を含むトラストレポート220が生成される。ステップ1025では、インテグリティレポート170が少なくとも１つの検証されるためのコンポーネント160を有しているか否かを判断する。最後に、ステップ1030では、少なくとも１つの検証されるコンポーネント160がある場合、コンポーネント160の検証が上述したようにして行われる。これは、図１１に示すように、クライアントプラットフォーム110のコンポーネント160（ソフトウェアおよびハードウェア）に対応するインテグリティオーソリティ140（図３）の検索要求をGSDB 325へ送信することによって行われる。

図１１は、図７のシグネチャデータベースへの検索要求を送信するのに用いられる手順のフローチャートを示す。ステップ1105では、オーセンティケーターエンティティ145（図１）は、クライアントプラットフォーム110（図１）からインテグリティレポート170（図１）を受信することができる。ステップ1110では、インテグリティレポート170にある各ダイジェストが、LSDB 720に対応するインテグリティ／トラストレコード725を有しているか否かをチェックする。対応するインテグリティ／トラストレコードが見つからない場合、ステップ1115において、GSDB 325（図３および図７）への参照が行われる。必要に応じて、ステップ1120では、LSDB 720のGSDB 325とのアップデート／同期を行うことができる。アップデート／同期の手順の他の実施例は、特に、図７との関連で説明できる。対応するインテグリティ／トラストレコード725が、LSDB 720またはGSDB 325のいずれかにおいて検出されたかに関わらず、ステップ1125では、対応するインテグリティ／トラストレコード725は、インテグリティレポート170（図１）のコンポーネント160（図１）を表わす各ダイジェストと比較される。ステップ1130では、クライアントプラットフォーム110の信頼性のレベルが、全体のインテグリティ／トラストスコア225（図２）を評価することによって決定される。

図１２は、ユーザープラットフォームが最初の使用のために配備される過程においてイメージファイルをインストールする前に、イメージファイル155のコンポーネントのインテグリティを検証するのに用いられる他の手順のフローチャートを示す。まず、ステップ1205において、クライアントプラットフォーム110（図１）が、供給、配備されるために、受け取られる。ステップ1210では、IT管理者または適当な権限を有する人間が、クライアントプラットフォーム110にイメージファイル155をインストールする前に、イメージファイル155（図１）の少なくとも１つのコンポーネントを検証することを決定することができる。本方法と、図１０についての記載の処理との違いは、タイミングの相違である。IT管理者は、図１０に記載されているようにイメージファイル155のインストールの後でコンポーネントの検証を行うか、図１２に記載されているようにイメージファイル155のインストール（ステップ1215）の前にコンポーネントの検証を行うかを決定することができる。

図１３は、図１のオーセンティケーターエンティティ145側の観点からの、クライアントプラットフォーム110にあるコンポーネント160のインテグリティを検証する手順のフローチャートを示す。ステップ1305では、クライアントプラットフォーム110が認証される。ステップ1310では、クライアントプラットフォーム110から、インテグリティレポート170を受信する。ステップ1315では、インテグリティレポート170中のコンポーネント160は、インテグリティオーソリティ140によって検証される。上述したように、検証は、検証サーバ205を用いて実行される。ステップ1320では、全体のインテグリティ／トラストスコア225を含むトラストレポート220がインテグリティオーソリティのGSDB 325（図３）にあるインテグリティ／トラストレコード320を用いて生成される。ステップ1325では、全体のインテグリティ／トラストスコア225が既定の閾値を超えたか否かを調べるために、チェックが行われることができる。

全体のインテグリティ／トラストスコア225が既定の閾値を超えていた場合、クライアントプラットフォーム110は、ネットワーク135（図１）上のリソース150へのアクセスを許可される。全体のインテグリティ／トラストスコア225が既定の閾値を超えていない場合、クライアントプラットフォーム110は、ネットワーク135（図１）上のリソース150へのアクセスを拒否される。もしくは、クライアントプラットフォーム110は、修正が要求されることを通知される。例えば、クライアントプラットフォーム110のコンポーネント160が、クライアントプラットフォーム110がもはや全体的に信頼できないほど“ドリフトしている”場合、要求される修正は、クライアントプラットフォーム110がイメージファイル155を用いて再イメージ化されるようにするものか、さもなければ、やり直しをする。他のやり方として、リソース150へのアクセスを許可する前に、“ドリフトした”コンポーネントの再インストールまたは削除することで修正してもよい。あるいは、クライアントプラットフォーム110は、リソース150へのアクセスを許可されるかもしれないが、もしかすると、そのアクセスは、クライアントプラットフォーム110が“ドリフト”に対処するまで低いレベルでのアクセスとなるかもしれない。当業者であれば、コンポーネントの“ドリフト”を取り扱うための他の可能性のある方法を理解するであろう。

図１４は、クライアントプラットフォーム110（図１）に、第１、第２、第３の閾値に従って複数のアクセスの段階を許可するのに用いられる手順のフローチャートを示す。図１４では、３つのアクセスの段階が提案されているが、当業者であれば、いくつもの閾値および段階を用いることができることを理解するであろう。ステップ1405では、全体のインテグリティ／トラストスコア225（図２）が第１の閾値を超えているか否かのチェックが行われる。もし、第１の閾値を超えていたならば、高い段階でのアクセスがクライアントプラットフォーム110に対し許可される（ステップ1410）。例えば、前述した銀行のシナリオにおいては、これは、外部の口座への電子送金を行うことができ、他の第２、第３の閾値（下記に議論する）について後述するような他のタスクを行うことができること意味する。ステップ1415では、全体のインテグリティ／トラストスコア225が第２の閾値を超えているか否かの第２のチェックが行われる。もし、第２の閾値を超えていたならば、中くらいの段階でのアクセスがクライアントプラットフォーム110に対し許可される（ステップ1420）。例えば、これは、内部の口座間の資産の閲覧および移送はできるが、外部の口座への電子送金を行うことができないことを意味する。ステップ1425では、全体のインテグリティ／トラストスコア225が第３の閾値を超えているか否かの第３のチェックが行われる。もし、第３の閾値を超えていたならば、低い段階でのアクセスがクライアントプラットフォーム110に対し許可される（ステップ1430）。これは、例えば、口座の残高をみることができるが、資金を内部の口座、外部の口座へ移送できないことを意味する。図１４では、高い段階でのアクセスを許可されたクライアントプラットフォームは、より低い段階のアクセスを許可されるように示されており、通常そのような状況になるが、当業者であれば、アクセスの段階はネスト化されてなくてもよいと理解するであろう。すわなち、異なる段階は異なるレベルのアクセスを供給するかもしれず、２つの異なるアクセスの段階が与えられた場合、どちらの段階も、もう一方の段階の一部とならないかもしれない。当業者であれば、全体のインテグリティ／トラストスコア225を基礎に階層化されたアクセスの許可は、上述した銀行の例以外の、他のケースに適用できることが理解できるであろう。例えば、企業ネットワーク、ファイル共有ネットワーク、オンラインデータベース等が挙げられる。

図１５、図１６は、クライアントプラットフォーム110（図１）におけるコンポーネント160のインテグリティを検証するのに用いられる手順のオペレーションフローを示すフローチャートである。ステップ1505では、クライアントプラットフォーム110は、リソース150へのアクセスを要求することにより、図２に示される認証サーバ210のオーセンティケーターエンティティ145と、ハンドシェイクを開始する。ステップ1510では、認証サーバ210は、クライアントプラットフォーム110に対してプラットフォームのインテグリティの検証を開始することにより、クライアントプラットフォーム110の要求に対して応答する。ステップ1515では、クライアントプラットフォーム110と認証サーバ210との間で、必要に応じて、セキュアチャンネルが構築される。これは、公知のフレームワーク（例えば、802.1X/EAP）を、適当なクレデンシャル（例えば、SSL認証）を用いる標準プロトコル（例えば、SSL、IKE）と一緒に用いることにより達成される。ある実施例では、クライアントプラットフォーム110と認証サーバ210の両方がトラステッドプラットフォームモジュール(TPM)チップを有しており、両方がTPM証明書（または、EK証明書、AIK証明書、SKAE証明書、または他の同様な証明書）を有している。これらの証明書は、セキュアチャンネルを構築するのに用いられる。他の実施例では、マシンの１つは、TPMチップを有しているが、他のマシンは、有していない。異なるプロトコルの共通点を利用することにより、クライアントプラットフォーム110と認証サーバ210との間のセキュアチャンネルを構築するも可能である。

ステップ1520は、図１５および図１６の両方において示されており、これらの図におけるステップ1520は、インテグリティレポート170を認証サーバ210（図２）へ移送する同様のステップを示している。図１６のステップ1605では、インテグリティレポート170は検証サーバ205へ転送され、クライアントプラットフォーム110（図１）から得られたインテグリティレポート170を用いたクライアントプラットフォーム110の評価が行われる。ある実施例では、検証サーバ205とクライアントプラットフォーム110との間での１往復の問答による対話が行われる。他の実施例では、問答による対話は、複数回の往復となる。問答による対話の間、認証サーバ210は、検証サーバ205（図２）のために仲介を行う。認証サーバ210は、クライアントプラットフォーム110と認証サーバ210との間でのメッセージング機能を供与する。

ステップ1525は、図１５および図１６の両方において示されており、これらの図におけるステップ1525は、インテグリティオーソリティ140（図３、図７）のGSDB 325（またはLSDB 720）へのクライアントプラットフォーム110のコンポーネント160についての検索オペレーションを行う、同様のステップを示している。検索オペレーションは、コンポーネント毎を単位とした連続で行われるものであってもよいし（例えば、複数回のメッセージ（multi-round messages）を用いる）、複数の検索オペレーションを含んだ１つのメッセージであってもよい。

図１５に示されるステップ1530は、GSDB 325（図３）からコンポーネントのインテグリティ／トラストレコード320を取得するオペレーションを説明するものである。検索した後にインテグリティ／トラストレコード320が見つかった場合、インテグリティオーソリティ140は、図１５、図１６の両方に示されるように、ステップ1535において、関連性のあるインテグリティ／トラストレコード320を検証サーバに返信する。

図１６のステップ1610では、コンパレータ525（図５）は、インテグリティレポート170（図２）のダイジェストをGSDB 325から返信されたインテグリティ／トラストレコード320（図３）と比較する。インテグリティレポート170のダイジェストと、GSDB 325から返信されたインテグリティ／トラストレコード320とを比較することにより、検証サーバ205は、クライアントプラットフォーム110（図２）の信頼性のレベルを決定する。信頼性のレベルは、全体のインテグリティ／トラストスコア225（図２）を含むトラストレポート220として具体化される。ステップ1615では、検証サーバ205は、全体のインテグリティ／トラストスコア225を含むトラストレポート220を、認証サーバ210（図２）へ供給する。その後、検証サーバ205は、プロファイルデータベース235（図２）に、トラストレポート220を評価の日時のような情報とともに格納する。ステップ1620では、認証サーバ210は、全体のインテグリティ／トラストスコア225を受信した後に、それをポリシーサーバ215（図２）に転送する。ステップ1625では、ポリシーサーバ215は、全体のインテグリティ／トラストスコア225を既定のポリシーまたは閾値と比較し、クライアントプラットフォーム110のリソース150（図２）へのアクセスを許可するか拒否するかを決定する。クライアントプラットフォーム110が十分に高いインテグリティ／トラストスコアを有していない場合、クライアントプラットフォーム110は、アクセスが許可された後に、修正が必要であると通知される場合がある。ステップ1630では、ポリシーサーバ215は、認証サーバ210に許可／拒否の結果を転送する。それから、認証サーバ210は、図１５および図１６に記載されているステップ1540において、クライアントプラットフォーム110へ結果を転送する。最終的に、ステップ1545（図１５および図１６の両方に記載されている）では、クライアントプラットフォーム110は、許可／拒否の結果を受信したことについて応答（aknowledge）し、プラットフォームの認証セッションを終了させる。もしくは、認証サーバ210は、クライアントプラットフォーム110が一定期間経過後にセッションを終了することに失敗した場合に認証セッションを終了させるためのタイムアウト機構（time-out mechanism）のセッションを、実施していてもよい。

以下に、本発明の一定の態様を実施する適切なマシンの簡単な一般的な説明をする。通常、マシンは、例えばプロセッサ、メモリ（例えば、ランダムアクセスメモリ（RAM）やリードオンリーメモリ（ROM）や他の状態格納媒体）、記憶装置、映像インターフェースおよび出力／入力インターフェースポートなどが取り付けられるシステムバスを含む。マシンは、少なくとも一部分において、キーボード、マウスなどの従来の入力デバイスからの入力および別のマシンから受けた指示、バーチャルリアリティ（VR）環境、生体フィードバックまたは他の入力信号との情報交換によって制御することが可能である。本件明細書で使用されるマシン（machine）という語は、単一のマシン、仮想マシン、または、一緒に作動するマシン、仮想マシンやデバイスと結合するコミュニケーションシステムを広く包含することを意図する。典型的なマシンは、自動車、列車、タクシーなどの個人的または公共の交通機関といった移動手段と同様に、パーソナルコンピュータ、ワークステーション、サーバ、ポータブルコンピュータ、携帯端末、電話、タブレットなどのコンピュータデバイスを含む。

また、マシンは、プログラマブルまたは非プログラマブル理論デバイスやアレイのような内臓コントローラやASIC（Application Specific Integrated Circuits）や内蔵コンピュータやスマートカードなどを含んでもよい。また、マシンは、ネットワーク・インターフェース、モデムまたは他のコミュニケーションのカップリングを介して、１つまたは複数のリモートマシンへの１つまたは複数の接続を利用してもよい。さらに、マシンは、イントラネット、インターネット、ローカルエリアネットワーク、広域ネットワークなどのような物理的、および/または論理的なネットワークを通して相互接続され得る。当業者であれば、ネットワークコミュニケーションが、無線周波数（RF）、衛星、マイクロ波、電気電子技術学会（IEEE） 545.11、ブルートゥース、光学、赤外、ケーブル、レーザなどを含む様々な有線／およびまたは無線の短距離または長距離キャリアとプロトコルを利用できることがわかるであろう。

本発明は、機能、手順、データ構造、アプリケーションプログラムなどを含む関連データを参照するか、あるいはそれらとの関連で説明することができる。これらの関連データは、マシンによりアクセスされたとき、当該マシンにタスクを実行させるか、あるいは抽象データ型か低レベルのハードウェアコンテキストを定義することになる。関連データは、例えば、RAM、ROM等の揮発性および／または不揮発性メモリ、またはハードドライブ、フロッピーディスク、光記憶装置、テープ、フラッシュメモリ、メモリスティック、デジタルビデオディスク、生物学的記憶装置などを含む他の記憶装置と、それらの関連記憶媒体に格納することができる。関連データは、物理的および／または論理的なネットワークを含む伝送環境で、パケット、シリアルデータ、並列データ、伝播された信号などの形で送信され、圧縮または暗号化された形式で使用できる。また、関連データは、分散環境で使用され、マシンのアクセスのために、局所的および／または遠隔的に格納されうる。

図示された実施例に基づいて本発明の原理を記載しかつ説明したが、図示された実施例がかかる原理から逸脱することなくその構成と詳細において変更してもよく、かつどのような望ましいやり方で組み合わせてもよいことを理解されたい。そして、以上の説明は特定の実施例に焦点を合わせたが、他の構成も考えることができる。特に、「本発明のある実施例に係る」という表現、または同様の表現がここで使用されるが、これらの語句は、一般に参考実施例となりうることを意味し、本発明を特定の実施例の構成に限定することは意図していない。ここに使用されるように、これらの語句は、他の実施例と組み合わせることができる同一または異なる実施例を表わしてもよい。

結論として、ここに説明された実施例へ多種多様に置き換えることができることを鑑みると、この詳細な説明および添付図面は例示のみを意図しており、発明の範囲を限定するものとして解するべきではない。したがって、本発明により主張されることはすべて、請求項とその均等物の範囲および精神を逸脱しないようなすべての変更を含むものである。

本発明の実施例に基づいた、クライアントプラットフォームバリデーションを用いてインテグリティが検証された種々のクライアントプラットフォームを含むシステムを示している。 図１のオーセンティケーターエンティティの詳細を示している。 図１のインテグリティオーソリティがコンポーネントから生情報を収集することを示している。 図３のインテグリティ／トラストレコードの詳細を示している。 図２の検証サーバの詳細を示している。 図１のインテグリティレポートの詳細を示している。 本発明の実施例に基づいた、グローバルおよびローカルのシグネチャデータベースを含むシステムを示している。 本発明の実施例に基づいた、ポータブルダイジェストコレクタードングルを含むシステムを示している。 グローバルシグネチャデータベースがあるポータブルダイジェストコレクタードングルを含むが、オーセンティケーターエンティティを有さない図８のシステムを示している。 図１のクライアントプラットフォームのコンポーネントのインテグリティを検証するのに用いられる手順のフローチャートを示す。 図７のシグネチャデータベースへ検索要求を送信するのに用いられる手順のフローチャートを示す。 イメージファイルをインストールする前にイメージファイルのコンポーネントのインテグリティを検証するのに用いられる手順のフローチャートを示す。 図２のオーセンティケーターエンティティの側から見たクライアントプラットフォームにあるコンポーネントのインテグリティを検証するのに用いられる手順のフローチャートを示す。 第１、第２、第３の閾値に従って複数の階層のアクセスを許可するのに用いられる手順のフローチャートを示す。 図１のクライアントプラットフォームのコンポーネントのインテグリティを検証するのに用いられる手順のオペレーションフローのフローチャートを示す。 図１のクライアントプラットフォームのコンポーネントのインテグリティを検証するのに用いられる手順のオペレーションンフローのフローチャートを示す。

Claims (46)

1. ネットワークに接続可能であり、インテグリティレポートを生成するインテグリティレポートジェネレータを有するクライアントプラットフォームと、
   前記ネットワークに接続可能であり、複数のインテグリティレコードを格納するデータベースを含むインテグリティオーソリティと、
   前記ネットワークに接続可能であり、前記クライアントプラットフォームを認証する認証サーバと、
   前記ネットワークに接続可能であり、前記インテグリティレポートを前記クライアントプラットフォームから受信し、前記インテグリティオーソリティから受信する複数の前記インテグリティレコードと前記インテグリティレポートとを比較し、前記認証サーバにトラストレポートを提供する検証サーバとを有することを特徴とするシステム。
2. 前記ネットワークで入手可能なリソースと、
   前記ネットワークに接続可能であり、インテグリティ／トラストスコアに従って、前記クライアントプラットフォームによる前記リソースへのアクセスを制御するポリシーサーバとをさらに有する請求項１に記載のシステム。
3. 前記検証サーバは、前記クライアントプラットフォームに関する情報を格納するプロファイルデータベースを有する請求項１に記載のシステム。
4. 前記インテグリティレポートは、デジタル署名がされている請求項１に記載のシステム。
5. 前記インテグリティレポートは、トラステッドプラットフォームモジュール（TPM）証明書を用いてデジタル署名されている請求項４に記載のシステム。
6. 前記インテグリティレポートは、前記クライアントプラットフォームの少なくとも１つのコンポーネントのハッシュを含む請求項１に記載のシステム。
7. 前記検証サーバは、前記トラストレポートを生成するために、前記インテグリティレポートと複数の前記インテグリティレコードとを比較するコンパレータを有する請求項１に記載のシステム。
8. 前記トラストレポートは、インテグリティ／トラストスコアを含む請求項１に記載のシステム。
9. 前記トラストレポートは、前記クライアントプラットフォームの識別を行うクライアントプラットフォームアイデンティティと、
   前記検証サーバの識別を行う検証サーバアイデンティティとをさらに含む請求項８に記載のシステム。
10. 前記トラストレポートは、前記クライアントプラットフォームのTPM証明書へのリファレンスをさらに含む請求項９に記載のシステム。
11. 前記インテグリティ／トラストスコアは、一部が前記TPM証明書によって決定される請求項１０に記載のシステム。
12. 前記インテグリティオーソリティは、前記コンポーネントの生情報を収集し、前記生情報の正確性を検証し、前記生情報を精製して精製情報とし、当該精製情報を格納するように動作する請求項１に記載のシステム。
13. 前記複数のインテグリティレコードは、それぞれ、コンポーネントの少なくとも１つのハッシュを含む請求項１に記載のシステム。
14. 前記複数のインテグリティレコードは、それぞれ、インテグリティオーソリティを識別する情報を含む請求項１に記載のシステム。
15. 前記クライアントプラットフォームは、携帯電話、パーソナルデジタルアシスタント、ネットワークエレメント、ルータ、スイッチ、サーバ、およびパーソナルコンピュータから構成されるセットから選択される請求項１に記載のシステム。
16. クライアントプラットフォームの複数のコンポーネントのインテグリティを検証するコンピュータで実施される方法であって、
    前記クライアントプラットフォームを配備のために受け取るステップと、
    前記クライアントプラットフォームに少なくとも１つのコンポーネントをインストールするステップと、
    前記少なくとも１つのコンポーネントに対するインテグリティレポートを生成するステップと、
    前記インテグリティレポートから、前記少なくとも１つのコンポーネントを検証するためのインテグリティ／トラストスコアを生成するステップと、
    を有することを特徴とするコンピュータで実施される方法。
17. 前記少なくとも１つのコンポーネントをインストールするステップは、イメージファイルから前記クライアントプラットフォームに前記少なくとも１つのコンポーネントをインストールすることを含む請求項１６に記載のコンピュータで実施される方法。
18. 前記イメージファイルにある複数のコンポーネントのセットを検証するステップを有する請求項１７に記載のコンピュータで実施される方法。
19. クライアントプラットフォームの複数のコンポーネントのインテグリティを検証するコンピュータで実施される方法であって、
    前記クライアントプラットフォームを認証するステップと、
    前記クライアントプラットフォームからインテグリティレポートを受信するステップと、
    インテグリティオーソリティによってインテグリティレポートに記載の複数のコンポーネントを検証するステップとを有することを特徴とするコンピュータで実施される方法。
20. 前記インテグリティオーソリティに格納されたインテグリティレコードを用いて、インテグリティ／トラストスコアを含むトラストレポートを生成するステップと、
    前記インテグリティ／トラストスコアが閾値を超えた場合に、前記クライアントプラットフォームにリソースへのアクセスを許可するステップとをさらに有する請求項１９に記載のコンピュータで実施される方法。
21. 前記インテグリティオーソリティに格納されたインテグリティレコードを用いて、インテグリティ／トラストスコアを含むトラストレポートを生成するステップと、
    前記インテグリティ／トラストスコアが閾値を超えない場合に、前記クライアントプラットフォームにリソースへのアクセスを拒否するステップとをさらに有する請求項１９に記載のコンピュータで実施される方法。
22. 複数のコンポーネントのインテグリティを検証するコンピュータで実施される方法であって、
    少なくとも１つのコンポーネントからインテグリティレポートを生成するステップと、
    前記インテグリティレポートを用いて、インテグリティ／トラストスコアを含むトラストレポートを生成するステップとを有し、
    前記インテグリティ／トラストスコアは、前記インテグリティレポートの署名に用いられたトラステッドプラットフォームモジュール（TPM）証明書によって、一部が決定されることを特徴とするコンピュータで実施される方法。
23. クライアントプラットフォームの少なくとも１つのコンポーネントを検証するステップをさらに有し、前記検証するステップでは、前記インテグリティレポートおよび前記トラストレポートを生成する請求項２２に記載のコンピュータで実施される方法。
24. 前記クライアントプラットフォームを認証するステップと、
    前記クライアントプラットフォームから前記インテグリティレポートを受信するステップと、
    前記インテグリティレポートに記載のコンポーネントをインテグリティオーソリティで検証するステップとを有する請求項２３に記載のコンピュータで実施される方法。
25. 前記インテグリティオーソリティに格納されているインテグリティレコードを用いて前記インテグリティ／トラストスコアを含む前記トラストレポートを生成するステップと、
    前記インテグリティ／トラストスコアが閾値を超えている場合に、前記クライアントプラットフォームのリソースへのアクセスを許可するステップをさらに有する請求項２４に記載のコンピュータで実施される方法。
26. 前記インテグリティオーソリティに格納されているインテグリティレコードを用いて前記インテグリティ／トラストスコアを含む前記トラストレポートを生成するステップと、
    前記インテグリティ／トラストスコアが閾値を超えない場合に、前記クライアントプラットフォームのリソースへのアクセスを拒否するステップをさらに有する請求項２４に記載のコンピュータで実施される方法。
27. イメージファイルの少なくとも１つのコンポーネントを検証するステップをさらに有し、
    前記検証するステップでは、前記インテグリティレポートおよび前記トラストレポートを生成する請求項２２に記載のコンピュータで実施される方法。
28. 配備するためのクライアントプラットフォームを受け取るステップと、
    前記イメージファイルを検証する前に、前記クライアントプラットフォームに、前記イメージファイルの前記少なくとも１つのコンポーネントをインストールするステップとをさらに有する請求項２７に記載のコンピュータで実施される方法。
29. 配備するためのクライアントプラットフォームを受け取るステップと、
    前記イメージファイルを検証した後に、前記クライアントプラットフォームに、前記イメージファイルの前記少なくとも１つのコンポーネントをインストールするステップとをさらに有する請求項２７に記載のコンピュータで実施される方法。
30. クライアントプラットフォームの複数のコンポーネントのインテグリティを検証するコンピュータで実施される方法であって、
    前記クライアントプラットフォームを認証するステップと、
    前記クライアントプラットフォームの少なくとも１つのコンポーネントについてインテグリティレポートを生成するステップと、
    前記インテグリティレポートにデジタル署名を行うステップと、
    前記インテグリティレポートに従ってリソースへのアクセスを得るステップとを有することを特徴とするコンピュータで実施される方法。
31. 前記インテグリティレポートを生成するステップは、前記クライアントプラットフォームにある前記少なくとも１つのコンポーネントの少なくとも１つのハッシュを前記インテグリティレポートに追加するステップを含む請求項３０に記載のコンピュータで実施される方法。
32. マシンがアクセス可能な媒体を含む物品であって、前記媒体はアクセスされた際にマシンとして機能する関連づけされたデータを有しており、前記データは、
    配備するためのクライアントプラットフォームを受け取り、
    前記クライアントプラットフォームに少なくとも１つのコンポーネントをインストールし、
    前記少なくとも１つのコンポーネントに対してインテグリティレポートを生成し、
    前記少なくとも１つのコンポーネントを検証するために、前記インテグリティレポートからインテグリティ／トラストスコアを生成する手順を実行するデータを含むことを特徴とする前記物品。
33. 前記少なくとも１つのコンポーネントをインストールする手順を実行するデータは、イメージファイルから、前記クライアントプラットフォームに、前記少なくとも１つのコンポーネントをインストールする手順を含むデータである請求項３２に記載の物品。
34. 前記イメージファイルにある複数のコンポーネントのセットを検証する手順を実行するデータさらに含む請求項３３に記載の物品。
35. ネットワークに接続可能であり、複数のインテグリティレコードを格納するデータベースを含むインテグリティオーソリティと、
    前記ネットワークに接続可能であり、クライアントプラットフォームを認証する認証サーバと、
    前記ネットワークに接続可能であり、前記クライアントプラットフォームからインテグリティレポートを受信し、前記インテグリティオーソリティから受信する複数の前記インテグリティレコードと前記インテグリティレポートとを比較し、前記認証サーバにトラストレポートを提供する検証サーバとを有することを特徴とするシステム。
36. 前記ネットワークで入手可能なリソースと、
    前記ネットワークに接続可能であり、インテグリティ／トラストスコアに従って、前記クライアントプラットフォームによる前記リソースへのアクセスを制御するポリシーサーバとを有する請求項３５に記載のシステム。
37. ネットワークに接続可能なクライアントプラットフォームを有するシステムであって、
    前記クライアントプラットフォームは、
    前記クライアントプラットフォームの少なくとも１つのコンポーネントの少なくとも１つのハッシュを含む、当該少なくとも１つのコンポーネントのインテグリティレポートを生成するインテグリティレポートジェネレータと、
    前記インテグリティレポートに署名するデジタルサイナー（digital signer）と、
    前記インテグリティレポートに従って、前記ネットワークのリソースへのアクセスを受信する手段とを有することを特徴とするシステム。
38. 前記インテグリティレポートは、トラステッドプラットフォームモジュール（TPM）証明書を用いて署名される請求項３７に記載のシステム。
39. マシンがアクセス可能な媒体を含む物品であって、前記媒体はアクセスされた際にマシンとして機能する関連づけされたデータを有しており、前記データは、
    少なくとも１つのコンポーネントに対するインテグリティレポートを生成し、
    前記インテグリティレポートを用いてインテグリティ／トラストスコアを含むトラストレポートを生成する手順を実行するデータを含み、
    当該インテグリティ／トラストスコアは、前記インテグリティレポートの署名に用いられたトラステッドプラットフォームモジュール（TPM）証明書によって、一部が決定されるようになっている特徴とする前記物品。
40. さらに、前記データは、クライアントプラットフォームの少なくとも一部を検証する手順を実行するデータを含み、
    前記検証する手順では、前記インテグリティレポートおよび前記トラストレポートを生成することを含む請求項３９に記載の物品。
41. 前記データは、さらに、
    クライアントプラットフォームを認証し、
    前記クライアントプラットフォームから前記インテグリティレポートを受信し、
    前記インテグリティレポートに記載のコンポーネントをインテグリティオーソリティで検証する手順を実行するデータを含む請求項４０に記載の物品。
42. 前記データは、さらに、
    前記インテグリティオーソリティに格納されている複数のインテグリティレコードを用いて前記インテグリティ／トラストスコアを含む前記トラストレポートを生成し、
    前記インテグリティ／トラストスコアが閾値を超えている場合には、前記クライアントプラットフォームのリソースへのアクセスを許可する手順を実行するデータを含む請求項４１に記載の物品。
43. 前記データは、さらに、
    前記インテグリティオーソリティに格納されている複数のインテグリティレコードを用いて前記インテグリティ／トラストスコアを含む前記トラストレポートを生成し、
    前記インテグリティ／トラストスコアが閾値を超えない場合には、前記クライアントプラットフォームのリソースへのアクセスを拒否する手順を実行するデータを含む請求項４１に記載の物品。
44. 前記データは、さらに、
    イメージファイルの少なくとも１つのコンポーネントを検証する手順を実行するデータを含み、
    前記検証する手順では、生成した前記インテグリティレポートおよび前記トラストレポートを生成する請求項３９に記載の物品。
45. 前記データは、さらに、
    配備するためのクライアントプラットフォームを受け取り、
    前記イメージファイルを検証する前に、前記クライアントプラットフォームに、前記イメージファイルの前記少なくとも１つのコンポーネントをインストールする手順を実行するデータを含む請求項４４に記載の前記物品。
46. 前記データは、さらに、
    配備するためのクライアントプラットフォームを受け取り、
    前記イメージファイルを検証した後に、前記クライアントプラットフォームに、前記イメージファイルの前記少なくとも１つのコンポーネントをインストールする手順を実行するデータを含む請求項４４に記載の前記物品。

Images