JP4603167B2

JP4603167B2 - コンピューティング装置のモジュール間通信

Info

Publication number: JP4603167B2
Application number: JP2000598915A
Authority: JP
Inventors: プラウダー・グレイム・ジョン; チャン・デービッド
Original assignee: Hewlett Packard Co
Current assignee: HP Inc
Priority date: 1999-02-15
Filing date: 2000-02-15
Publication date: 2010-12-22
Anticipated expiration: 2020-02-15
Also published as: US7236455B1; EP1161715B1; WO2000048062A1; DE60044844D1; EP1161715A1; JP2002536756A

Description

【０００１】
【発明の属する技術分野】
この発明は、コンピューティング装置に関連し、具体的には、コンピューティング装置の様々なモジュール間の信用およびセキュリティを改良することに関連する。
【０００２】
【従来の技術】
ユーザによりロードされたソフトウェアまたはネットワーク通信を介してロードされたソフトウェアによる不正な修正に対して脆弱な環境に商業クライアント・プラットフォームがしばしばあるので、コンピュータ・プラットフォームの完全性（integrity）への関心が生じている。このため、ユーザは、重要なデータ操作のためにプラットフォームを信用することに消極的であり、コンピュータ・プラットフォーム内のセキュリティのレベルを改善することが望まれている。
【０００３】
コンピュータ・プラットフォームの従来技術の機能モジュール（ＣＰＵ、メモリ、ハードディスク・ドライブ、キーボード、ＣＤＲＯＭ、ＤＶＤ、スマートカード読み取り装置、ＩＳＡカード、ＥＩＳＡカード、ＰＣＩカード、その他）がこれらのモジュール間で通信される情報を確認せず、モジュールとの通信が秘密でないという事実から弱点が発生する。この弱点の主な理由を以下に示す。
【０００４】
・コンピュータ・プラットフォームのメイン・コンピューティング・エンジンが物理的にプラットフォーム内部で分散（ＣＰＵ、メモリ、長期記憶デバイス、その他を分離）されており、メイン・コンピューティング・エンジンの多くの個々の分散されたコンポーネントが通信するデータをセキュア（secure）にする機能を持たない。
【０００５】
・分散されたエンジンの要素間の通信と、他の機能モジュールとの通信の両方が共用された通信経路（共用通信インフラストラクチャ）を使用してなされる。
【０００６】
・機能モジュールのサービスがいくつかの他の機能モジュールによって潜在的に共用される。
【０００７】
したがって、主分散型コンピューティング・エンジンまたは別の機能モジュール上のローグ・ソフトウェア（rogue software）は、データを盗聴することができ、不適当なデータ操作を実行し、発生させることができる。
【０００８】
【発明が解決しようとする課題】
暗号セキュリティ機能の能力を持つ内蔵コンピューティング・エンジンを機能モジュールが有する場合、いかなる共用環境でも、セキュア通信（認証、完全性、信頼性、その他を有する）が可能である。その様なエンジンは、機能モジュールがデータ・ソースを認証し、データの完全性を検証し、データの信頼性を提供することを可能にするだろう。コンピュータ・プラットフォームの多くの機能モジュールは、既に内蔵型コンピューティング・エンジンを有し、これらのエンジンを修正して必要な暗号セキュリティ機能を提供することが可能である。その様な修正それ自体は、セキュリティおよび電子技術の分野の当業者に既知である。たとえそうしても、残る問題は、その様な暗号プロセスの全てが一般に鍵と呼ばれる秘密情報（secret）の利用に依存していることである。鍵は分配されなければならない。各機能モジュールは、それ自身の秘密情報を有し、他の機能モジュールの適当な秘密情報にアクセスしなければならない。これらの性質および問題（並びに特性および鍵の使用）は、それ自体、情報セキュリティの分野においてよく知られている。
【０００９】
【課題を解決するための手段】
信頼性のある測定および信頼性のある完全性測定基準の報告によってコンピュータのプラットフォームの完全性を検証することを可能にするためにコンピュータ・プラットフォームにおいて信用コンポーネントまたはモジュールを使用することが、信用通信の確立において特に有効な要素であることが分かった。信用モジュールは、権限の無い修正または内部データの検閲に対して本質的に免疫がある。それは、偽造を防ぐのに物理的であり、模造を防ぐのに耐タンパ性があり、距離のあるセキュア通信に対する暗号機能を有する。信用モジュールを作る方法、それ自体は、本分野の当業者に明らかである。信用モジュールは、暗号方法を使用して、それ自身に暗号のアイデンティティを与え、確実性、完全性、信頼性を提供し、リプレイ攻撃に対するガードをし、デジタル署名をし、必要に応じてデジタル証明書を使用する。これらおよび他の暗号方法並びにそれらの初期化、それ自体は、セキュリティの分野における当業者に既知のものである。その様な信用コンポーネントの役割は、「信用コンピューティング・プラットフォーム」と題され、本願と同日で同じ出願人による国際特許出願に記載される。
【００１０】
本発明によれば、信用ハードウェア・モジュールと、複数のさらなるハードウェア・モジュールと、それによりモジュールが互いに通信することができる共用通信インフラストラクチャ（例えば通常のＥＩＳＡおよびＰＣＩバスなど）と、通信インフラストラクチャとは異なる第１の通信経路と、を備えるコンピューティング装置が提供される。第１の通信経路によって、さらなるモジュールのうちの第１のモジュールは、信用モジュールと直接通信することができるが、さらなるモジュールのうちの他のいずれとも直接通信することはできない。（第１のさらなるモジュールは、それ自身、信用モジュールであってもよいしそうでなくてもよい。）したがって、信用モジュールおよび第１のさらなるモジュールは、暗号化および解読の必要性なく、かつ通信を盗聴する他のいずれかの装置の可能性なしに通信することができる。前記第１の通信経路は、シリアル通信を可能とする単一の専用物理ワイヤとして実施されてもよいし、複数のワイヤ、光接続、または様々な周波数上での短距離ワイヤレス通信、その他でもよい。本発明は、信用モジュールと第１のさらなるモジュールとの間で、私有の、暗黙の、認証された情報通信を可能にする。これは、私有の情報通信または信頼性を最重要とする情報通信を可能にする。これは、例えば共用通信インフラストラクチャ上で通信されるべきデータ自体、またはコマンド、標識、フラグ、若しくはデータのチェックサムを含む。
【００１１】
好ましくは、信用モジュールおよび第１のさらなるモジュールは、第１の通信経路を介する直接の通信に参加するそれぞれコンピューティング・エンジンを備える。この文脈において、フレーズ「コンピューティング・エンジン」は、データを操作する能力を有する任意のデバイスを意味し、プログラムされたデバイスおよびハードワイヤード・デバイスを含むことを理解されたい。全機能ブロックがその様な個別のコンピューティング・エンジンを必要とするわけではない。例えばハードディスク・ドライブは、ハードディスク・ドライブを制御する目的で、既にコンピューティング・エンジンを組み込んでおり、単に付加的通信経路の制御を提供するために特別の命令の追加を必要とする。他方で、通常のＰＣのＣＰＵ（例えばインテルのペンティアム・プロセッサ（商標）など）は、明らかにコンピューティング・エンジンであるが、明らかに別個のコンピューティング・エンジンを持たない。したがって、付加的なコンピューティング・エンジンまたはなんらかの他の方法を提供して、ＣＰＵの汎用目的コンピューティング・エンジンを「別個」のコンピューティング・エンジンとして使用することが可能になる。例えば既存のＣＰＵは、保護された通信経路上でデータを通信する新しい命令をおよび新しいハードウェアを有するよう修正されることができる。
【００１２】
第１のさらなるモジュールは、好ましくはデータ操作のリクエストを信用モジュールに供給するよう動作することができる。その様なリクエストに応答して、信用モジュールは、レスポンスを生成し、共用通信インフラストラクチャを介してではなく、第１の通信経路を介して第１のさらなるハードウェア・モジュールにレスポンスを供給するよう動作することができる。この場合、信用モジュールは、好ましくは許可することができる動作および／または許可することができない動作に関するポリシー情報を記憶するための手段を有し、そのポリシー情報を参照して、レスポンスを生成するよう動作することができる。これは、あるモジュールによって別のモジュールに提供されるサービスにおける信用を改善する。特に、第１のさらなるモジュールは、信用モジュールをうまく利用することができる。例えば信用モジュールは、暗号コプロセッサ（crypto-coprocessor）または「ハードウェア」暗号ＡＰＩとして作用することができ、例えば他の特許出願において記載されるコンピュータ・プログラムなどのような信用性が不可欠である他の非暗号機能（non-crypto function）も含むことができる。第１のさらなるモジュールは、共用通信インフラストラクチャを使用してデータおよびリクエストを信用モジュールに送信することができる。信用モジュールは、供給されたデータを使用してリクエストに基づいて動作することができ、第１の通信経路上で第１のさらなるモジュールに結果を戻して報告することができる。これは、例えばネットワーク・インターフェース・カードが必要な鍵を安全に記憶（または隠す）することなく外部メッセージの起源および完全性を検証することを可能にする。代替的に、リクエストは、ある秘密情報または供給されたデータについて保護機能を実行することであってもよい。全ての場合において、第１の通信経路を使用してレスポンスが受信されるという事実は、適当な信用モジュールが実際にリクエストを受信したことを第１のさらなるモジュールに示し、第１の通信経路上で受信されたレスポンスが適当な信用モジュールの実際の判断になる。
【００１３】
信用モジュールは、暗号および／または解読鍵を生成し、共用通信インフラストラクチャを介してではなく、第１の通信経路を介して第１のさらなるハードウェア・モジュールにその鍵を供給するよう動作することができる。この場合、第１のさらなるハードウェア・モジュールは、好ましくは、共用通信インフラストラクチャを介して通信されるデータの暗号化および解読のために鍵を使用するよう動作することができる。したがって、装置の他の部分が鍵の通信を盗聴する可能性なしに、鍵は、信用モジュールと第１のさらなるモジュールとの間で秘密に保持される。信用モジュールおよび第１のさらなるモジュールにおけるコンピューティング・エンジンは、第１の通信経路に沿ってプレーンテキストで鍵を交換することができる。第１の通信経路上で明確に明らかになることが鍵にとって全く受け入れられない場合、信用モジュールおよび第１のさらなるモジュールは、Diffie-Hellmanプロトコルを使用してそれらの間の鍵を設定することができる。Diffie-Hellmanの場合には、第１の通信経路の使用は、単に、Diffie-Hellmanプロセスに従事する「他」のエンティティのアイデンティティの暗黙のプルーフを提供する。装置は、鍵のメンテナンスおよび取り替えのためにも使用されることができる。その様な鍵の分配方法、それ自体は、情報セキュリティの分野における当業者によく知られている。一旦、鍵が交換されると、これらの鍵は、共用通信インフラストラクチャを使用する通信のためのセキュリティを提供するのに使用されることができる。例えばセキュア通信方法、それ自体は、情報セキュリティの分野における当業者によく知られている。鍵の生成／分配は、さらなるモジュールの全てが信用モジュールである場合でさえも有用である。
【００１４】
信用モジュールは、好ましくは、チャレンジを生成し、第１の通信経路を使用して設定された暗号化を使用して、第１の通信経路を介してまたは共用通信インフラストラクチャを介して第１のさらなるモジュールにチャレンジを供給するよう動作することができる。この場合、チャレンジに応答して、好ましくは、第１のさらなるモジュールがレスポンスを生成し、第１の通信経路を使用して設定された暗号化を使用して、第１の通信経路を介してまたは共用通信インフラストラクチャを介して、信用モジュールにレスポンスを供給するよう動作することができる。信用モジュールは、装置の完全性測定基準の生成においてレスポンスを使用するよう動作することができる。これは、ハードウェア「ウォッチドッグ」機能を可能にし、信用モジュールが、第１の通信経路上で、または第１の通信経路を使用して設定されたセキュア通信を使用して、第１の通信モジュールに合間合間にチャレンジすることができる。第１のさらなるモジュールは、第１の通信経路（または第１の通信経路を使用して設定された何らかの他の経路上のセキュア通信）を使用してリプライでチャレンジに応答する。その様なウォッチドッグ・チャレンジは、前述した先行特許出願に記載されるような完全性チャレンジを受信する結果としてなされることができる。
【００１５】
特定の適用することができるネットワーク・インターフェース・モジュールが第１のさらなるモジュールである１つの例では、第１のさらなるモジュールは、好ましくは、私有のデータのためのゾーンおよび非私有のデータのためのゾーンを有する。第１のさらなるモジュールは、共用通信インフラストラクチャを介してではなく、第１の通信経路を介して、私有データ・ゾーンから／へデータを供給および／または受信するよう動作することができる。この場合、好ましくは、第１のさらなるハードウェア・モジュールは、共用通信インフラストラクチャを介して、非私有のデータ・ゾーンから／へデータを供給および／または受信するよう動作することができる。さらに、第１のさらなるモジュールは、好ましくは、私有と非私有との間に、前記私有データ・ゾーンから非私有データ・ゾーンへのデータの通過を妨げるよう動作するインターフェースを有する。したがって、装置は、安全と非安全、すなわち非私有と私有のデータ・ゾーンとに整然と仕切られる。
【００１６】
装置は、当然、共用通信インフラストラクチャおよび第１の通信経路とは異なる第２の通信経路を備えることができる。これによって、さらなるモジュールのうちの第２のもの（例えば装置のメイン・プロセッサ・ユニットまたは不揮発性データ記憶モジュール）は、信用モジュールと直接通信することができる。この場合、第２のさらなるモジュールは、さらなるハードウェア・モジュールの他のいずれとも直接通信することはできない。
【００１７】
この場合には、第１のさらなるモジュールは、第１と第２のモジュールとの間で、信用モジュールにデータの転送のリクエストを供給するよう動作することができる。その様なリクエストに応答して、信用モジュールは、レスポンスを生成し、共用通信インフラストラクチャではなくて、場合に応じて第１または第２の通信経路を介して、第１または第２のさらなるモジュールにレスポンスを供給するよう動作することができる。この場合には、信用モジュールは、好ましくは、許可することができる転送およびまたは許可することができない転送に関するポリシー情報を記憶するための手段を有し、ポリシー情報を参照してレスポンスを生成するよう動作することができる。さらに、その様な適当な転送レスポンスに応答して、第１または第２のさらなるモジュールは、場合に応じて第１または第２の通信経路を介して、信用モジュールにデータを供給することができ、その様なデータの受信に応答して、信用モジュールは、場合に応じて第２または第１の通信経路を介して、場合に応じて第２または第１のさらなるハードウェア・モジュールにデータを中継する。
【００１８】
装置は、当然、共用通信インフラストラクチャおよび他の通信リンクとは異なる少なくとも第３の通信リンクを備える。それにより、さらなるモジュールのうちの第３のものは、信用モジュールと直接通信することができる。この場合、第３のさらなるモジュールは、さらなるモジュールの他のいずれとも直接通信することができない。
【００１９】
したがって、信用モジュールは、スイッチング能力を有することができ、個々の通信経路は、スター型通信ネットワークとして使用されることができる。これは、信用モジュールの制御下で、さらなるモジュール間の通信を可能とする。信用モジュールは、信用モジュールに記憶されたなんらかのポリシーに従って、さらなるモジュール間で情報を経路設定またはブロックすることができる。より具体的には、通信ネットワークがスター型であるので、信用モジュールは、関連するモジュールだけに情報を提示することができ、結果として、他のモジュールが盗聴する機会を阻むことができる。
【００２０】
【発明の実施の形態】
本発明の実施形態を説明する前に、先に述べた国際特許出願された信用デバイスを組み込んだコンピューティング・プラットフォームが最初に、図１〜図６を参照して述べられる。
【００２１】
この信用プラットフォーム（trusted platform）の例では、プラットフォームの完全性測定基準（integrity metric）を提供する信頼のある測定データにプラットフォームのアイデンティティを結び付ける機能を有する物理的な信用デバイスのコンピューティング・プラットフォームへの組み込みが提供される。アイデンティティおよび完全性測定基準は、プラットフォームの信用を保証するために用意された信用パーティ（ＴＰ;trusted party）により提供された期待値と比較される。合致すれば、完全性測定基準の範囲に応じて少なくともプラットフォームの部分が正しく動作していることを意味する。
【００２２】
ユーザは、プラットフォームと他のデータを交換する前に、プラットフォームの正しい動作を検証する。ユーザは、そのアイデンティティおよび完全性測定基準を提供するよう信用デバイスに要求することによってこれを行う（選択的に、信用デバイスは、それ自身がプラットフォームの正しい動作を検証することができなければ、アイデンティティの証拠を提供することを拒否する）。ユーザは、アイデンティティのプルーフ（proof;証拠）とアイデンティティの測定基準を受け取り、真であると信じる値に対してそれらを比較する。これらの適当な値は、ＴＰによってかまたはユーザが信用した別のエンティティによって提供される。信用デバイスにより報告されたデータがＴＰによって提供されたものと同じであれば、ユーザはプラットフォームを信用する。これは、ユーザがエンティティを信用するからである。エンティティは、以前にアイデンティティを検証し、プラットフォームの適当な完全性測定基準を求めているので、そのプラットフォームを信用する。
【００２３】
一旦、ユーザがプラットフォームの信用動作を確立したならば、他のデータをプラットフォームと交換する。ローカル・ユーザの場合、交換は、プラットフォーム上で走る任意のソフトウェア・アプリケーションと相互作用することによってなされるかもしれない。リモート・ユーザの場合、交換は、セキュア・トランザクション（secure transaction）を含むかもしれない。どちらの場合も、データ交換は、信用デバイスにより「署名（sign）」される。そのとき、ユーザは、信用できる振る舞いのプラットフォームとデータが交換されているという、より大きな信頼を持つことができる。
【００２４】
信用デバイスは、暗号プロセスを使用するが、必ずしも暗号プロセスへの外部インターフェースを提供するとはかぎらない。さらに、最も好ましい実施は、信用デバイスをタンパプルーフ（tamperproof）にして、プラットフォームの他の機能に対してアクセス不可能にすることによって秘密情報を保護し、権限の無い修正に対して実質的に免疫のある環境を提供することであろう。タンパプルーフ化（tamper-proofing）が不可能なので、最良の近似は、耐タンパ性（tamper-resistant）の信用デバイスまたはタンパ検出(tamper-detecting)する信用デバイスである。したがって、信用デバイスは、耐タンパ性である１つの物理的コンポーネントからなるのが好ましい。
【００２５】
耐タンパ性に関する技術は、セキュリティ技術における当業者に既知のものである。この技術は、不正変更（tampering）に抵抗する方法（例えば信用デバイスの適当なカプセル化など）、タンパ検出の方法（例えば仕様電圧、Ｘ線、または信用デバイスのケーシングにおける物理的な完全性の損失からの検出など）および不正変更を検出したときにデータを除去する方法を含む。適当な技術のさらなる説明は、http://www.cl.cam.ac.uk/~mgk25/tamper.htmlで見つけることができる。タンパプルーフが本発明の最も望ましい機能であるけれども、これは、本発明の通常の動作に入らず、したがって、本発明の範囲を超えるので、ここでは詳細に記載しない。
【００２６】
信用デバイスは、偽造困難でなければならないので、物理的デバイスであることが好ましい。これは、模造困難でなければならないので、耐タンパ性であることが最も好ましい。典型的には、ローカルおよびリモートの距離の両方でアイデンティティを証明する必要があるので、暗号プロセスを使用することができるエンジンを有し、関連するプラットフォームのなんらかの完全性測定基準を測定する少なくとも１つの方法を含む。
【００２７】
図１に信用プラットフォーム１０を図示する。プラットフォーム１０は、キーボード１４、マウス１６、および視覚表示ユニット（ＶＤＵ）１８の標準的機能を有し、これらがプラットフォームの物理的「ユーザ・インターフェース」を提供する。信用プラットフォームのこの実施形態は、スマートカード読み取り装置１２も有する（スマートカード読み取り装置は全ての信用プラットフォームの必須の要素ではないが、以下で説明する様々な好ましい実施形態において用いられる。）スマートカード読み取り装置１２の側に沿ってスマートカード１９が図示される。このスマートカードが、以下でさらに述べるように、信用ユーザが信用プラットフォームと相互に作用することを可能にする。プラットフォーム１０には複数のモジュール１５が存在する。これらは、そのプラットフォームに適する必須の任意の種類の信用プラットフォームの他の機能的要素である（その様な要素の機能的意義が本発明に関連しないので、ここではさらに説明しない）。
【００２８】
図２に示すように、信用コンピューティング・プラットフォーム１０のマザーボード２０は、（他の標準的コンポーネントの中の）メイン・プロセッサ２１、メイン・メモリ２２、信用デバイス２４、データバス２６、並びに各制御ライン２７およびライン２８を含む。さらにマザーボード２０は、プラットフォーム１０のためのＢＩＯＳプログラムを含むＢＩＯＳメモリ２９および入出力（ＩＯ）デバイス２３を含む。入出力デバイス２３は、マザーボードのコンポーネントと、スマートカード読み取り装置１２、キーボード１４、マウス１６、ＶＤＵ１８との間の相互作用を制御する。メイン・メモリ２２は、典型的にランダム・アクセス・メモリ（ＲＡＭ）である。動作中、プラットフォーム１０は、ハードディスク（図示せず）からＲＡＭにオペレーティング・システム（例えばWindows NT（商標）など）をロードする。さらに、動作中、プラットフォーム１０は、プラットフォーム１０により実行されるプロセスまたはアプリケーションをハードディスク（図示せず）からＲＡＭにロードする。
【００２９】
典型的には、パーソナル・コンピュータでは、ＢＩＯＳプログラムは、特別の予約メモリ領域（最初のメガバイトのうちの上部６４Ｋがシステムメモリ（アドレスＦ０００ｈ〜ＦＦＦＦｈ）を行う）に配置され、メイン・プロセッサは、工業的な規格に従って、このメモリの場所を最初に見るよう構成される。
【００３０】
このプラットフォームと従来技術のプラットフォームとの間の重大な差違は、リセット後にメイン・プロセッサが最初に信用デバイスによって制御され、それから、プラットフォームの特定のＢＩＯＳプログラムに制御を渡し、その次に通常通りに入出力デバイスを制御することである。ＢＩＯＳプログラムが実行された後で、ＢＩＯＳプログラムによって通常どおりに（例えばWindows NTなどの）オペレーティング・システム・プログラムに制御が渡され、このオペレーティング・システムは、典型的にはハードディスクデバイス（図示せず）からメイン・メモリ２２にロードされる。
【００３１】
明らかに、通常の手順からの変更は、工業規格の実施に修正を必要とし、それによってメイン・プロセッサ２１が信用デバイス２４をアドレス指定するよう指示されてその最初の命令を受信する。この変更は、メイン・プロセッサ２１に異なるアドレスをハード・コーディング(hard-coding)することによって簡単に行うことができる。もう１つの方法として、信用デバイス２４が標準ＢＩＯＳプログラムのアドレスに割り当てられてもよい。この場合、メイン・プロセッサのコンフィギュレーション（configuration）を修正する必要が無くなる。
【００３２】
信用デバイス２４内部にＢＩＯＳブート・ブロックが含まれることが非常に好ましい。これは、完全性測定基準の獲得をだめにすること（これは、ローグ・ソフトウェア・プロセス（rogue software process）が存在する場合に発生する）を防ぎ、オペレーティング・システムのためにＢＩＯＳが適当な環境を確立するのを（正しい場合にすら）失敗する状況を作るローグ・ソフトウェア・プロセスを防ぐ。
【００３３】
記載する好ましい実施形態では、信用デバイス２４は、単一のディスクリート・コンポーネントであるけれども、代替的に信用デバイス２４の機能がマザーボード上の複数のデバイスに分離されてもよいし、またはプラットフォームの１つまたは複数の既存の標準的デバイスに統合されてもよいことが分かる。例えば、機能およびそれらの通信をだめにすることなく、信用デバイスの１つまたは複数の機能をメイン・プロセッサそれ自体に統合することができる。しかしながら、これは、おそらくプロセッサ上に信用機能による別個の専用リード線を必要とする。さらにまたは代替的に、本発明の実施形態では、信用デバイスは、マザーボード２０への統合に適合したハードウェアデバイスであるけれども、信用デバイスは、例えばドングル（dongle）などの「リムーバブル（取り外し可能）」デバイス（これは、必要なときにプラットフォームに取り付けられる）として実施されてもよいことが考えられる。信用デバイスが統合されるかまたリムーバブルにされるかどうかは、設計の選択事項である。しかしながら、信用デバイスが分離可能である場合、信用デバイスとプラットフォームとの間の論理的結合を提供するメカニズムが存在すべきである。
【００３４】
図３に示すように、信用デバイス２４は、たくさんのブロックを含む。システムのリセットの後で、信用デバイス２４は、セキュア・ブート・プロセスを実行して、プラットフォーム１０のオペレーティング・システム（システムクロックおよびモニタ上の表示を含む）が適当かつセキュアな態様で走ることを確実にする。セキュア・ブート・プロセス中に、信用デバイス２４は、コンピューティング・プラットフォーム１０の完全性測定基準を獲得する。信用デバイス２４は、セキュア・データ転送（例えば暗号化／解読および署名／照合を介するスマートカードとそれとの間の認証）も実行することができる。信用デバイス２４は、例えばユーザ・インターフェースのロックなどの様々なセキュリティ制御ポリシーをセキュアに実現することもできる。
【００３５】
具体的には、信用デバイスは、信用デバイス２４の全体的動作を制御するようプログラムされ信用デバイス２４上の他の機能およびマザーボード２０上の他のデバイスと相互作用するようプログラムされたコントローラ３０と、プラットフォーム１０から完全性測定基準を獲得する測定機能３１と、規定されたデータを署名、暗号化または解読する暗号機能３２と、スマートカードを認証する認証機能３３と、マザーボードのデータバス２６、制御ライン２７、およびアドレス・ライン２８にそれぞれ信用デバイス２４を接続する適当なポート（３６、３７、３７）を有するインターフェース回路３４と、を含む。信用デバイス２４におけるそれぞれのブロックは、信用デバイス２４の適当な揮発性メモリ領域４および／または不揮発性メモリ領域３への（典型的にはコントローラ３０を介する）アクセス権を有する。さらに、信用デバイス２４は、既知の方法で耐タンパ性となるよう設計される。
【００３６】
パフォーマンスの理由から信用デバイス２４は応用特定集積回路（ＡＳＩＣ）として実施される。しかしながら、柔軟性のために、信用デバイス２４は適当にプログラムされたマイクロ・コントローラであることが好ましい。ＡＳＩＣとマイクロ・コントローラのどちらもマイクロ・エレクトロニクスの技術分野では既知のものであり、ここでは詳細に考察されない。
【００３７】
信用デバイス２４の不揮発性メモリ３に記憶されるデータの１項目は、証明書３５０（certificate）である。証明書３５０は、少なくとも信用デバイス２４の公開鍵３５１および信用パーティ（ＴＰ）によって測定されたプラットフォームの完全性測定基準の認証された値３５２を含む。証明書３５０は、信用デバイス２４に記憶される前に、ＴＰの私有鍵を使用してＴＰにより署名される。後の通信セッションでは、プラットフォーム１０のユーザは、獲得された完全性測定基準と認証された完全性測定基準３５２とを比較することによって、プラットフォーム１０の完全性を検証する。合致した場合、ユーザは、プラットフォーム１０が破壊されていないことを信用することができる。ＴＰの一般利用可能な公開鍵の知識は、証明書３５０の簡単な検証を可能にする。不揮発性メモリ３５は、アイデンティティ（ＩＤ）ラベル３５３も含む。ＩＤラベル３５３は、例えばシリアル番号などの従来技術のＩＤラベルであり、ある範囲で固有である。ＩＤラベル３５３は、信用デバイス２４に関するデータを索引付けし、ラベル付けするのに一般に使用されるが、それ自身では、信用条件下でプラットフォーム１０のアイデンティティを証明するのに不十分である。
【００３８】
信用デバイスは、関連するコンピューティング・プラットフォーム１０の完全性測定基準を高い信頼性で測定するかまたは獲得する少なくとも１つの方法を備える。本発明の実施形態では、完全性測定基準は、ＢＩＯＳメモリにおけるＢＩＯＳ命令のダイジェスト（digest）を生成することによる測定機能３１によって獲得される。その様に獲得された完全性測定基準は、前述のように検証されれば、プラットフォーム１０がハードウェアまたはＢＩＯＳプログラムの段階で破壊されていないという高いレベルの信用をプラットフォーム１０の潜在的ユーザに与える。他の既知のプロセス（例えばウイルス・チェッカー）が典型的には存在して、オペレーティング・システムおよびアプリケーション・プログラム・コードが破壊されていないことをチェックする。
【００３９】
測定機能３１は、ハッシュ・プログラム３５４および信用デバイス２４の私有鍵３５５を記憶する不揮発性メモリ３、並びに、ダイジェスト３６１の形態で獲得された完全性測定基準を記憶する揮発性メモリ４へのアクセス権を有する。適当な実施形態では、揮発性メモリ４は、公開鍵およびプラットフォーム１０へのアクセス権を与えるのに使用される１つまたは複数の認証スマートカード１９の関連するＩＤラベル３６０ａ〜３６０ｎを記憶するのにも使用される。
【００４０】
１つの好ましい実施では、ダイジェストおよび完全性測定基準は、ブール値を含み、これは、明白になるという理由で、測定機能３１により揮発性メモリ４に記憶される。
【００４１】
完全性測定基準を獲得する好ましいプロセスを図４を参照して説明する。
【００４２】
スイッチオンで、測定機能は、ステップ５００においてデータ、制御およびアドレス・ライン（２６、２７、２８）上でメイン・プロセッサ２１の活動を監視して、信用デバイス２４がアクセスされた最初のメモリであるかどうかを判断する。従来の動作の下では、メイン・プロセッサは、ＢＩＯＳプログラムを最初に実行するために、ＢＩＯＳメモリに最初に向けられていた。しかしながら、本発明の実施形態によれば、メイン・プロセッサ２１は、信用デバイス２４に向けられ、これがメモリとして作用する。ステップ５０５において信用デバイス２４が最初にアクセスされたメモリであれば、ステップ５１０で、測定機能３１は、信用デバイス２４がアクセスされた最初のメモリであったことを示すブール値を揮発性メモリ３に書き込む。そうでなければ、ステップ５１５において、測定機能は、信用デバイス２４がアクセスされた最初のメモリではなかったことを示すブール値を書き込む。
【００４３】
信用デバイス２４がアクセスされた最初のメモリではない場合、当然、信用デバイス２４が全くアクセスされないという機会が存在する。これは、例えばメイン・プロセッサ２１がＢＩＯＳプログラムを最初に走らすよう操作された場合であろう。これらの状況では、プラットフォームは、動作するだろうが、完全性測定基準を利用することができないので、要望に応じてその完全性を検証することができない。さらに、ＢＩＯＳプログラムがアクセスされた後で信用デバイス２４がアクセスされた場合、明らかに、ブール値は、プラットフォームの完全性の欠如を示す。
【００４４】
ステップ５２０においてメイン・プロセッサ２１によりメモリとしてアクセスされたとき（または場合）、メイン・プロセッサ２１は、ステップ５２５において測定機能３１から記憶されたネイティブ・ハッシュ命令３５４（native hash instruction）を読み取る。ハッシュ命令３５４は、メイン・プロセッサ２１による処理のためにデータバス２６を介して渡される。ステップ５３０では、メイン・プロセッサ２１は、ハッシュ命令３５４を実行し、それらを使用して、ステップ５３５において、ＢＩＯＳメモリ２９の内容を読み取り、これらの内容をハッシュ・プログラムに従って処理することによって、ＢＩＯＳメモリ２９のダイジェストを演算する。ステップ５４０では、メイン・プロセッサ２１は、信用デバイス２４における不揮発性メモリ４の適当な場所に演算されたダイジェスト３６１を書き込む。それから測定機能３１は、ステップ５４５において、ＢＩＯＳメモリ２９におけるＢＩＯＳプログラムを呼びだし、従来技術の態様で実行が続けられる。
【００４５】
明らかに、必要とされる信用の範囲に応じて、完全性測定基準を演算する多数の様々な態様が存在する。ＢＩＯＳプログラムの完全性の測定は、プラットフォームの基礎を成す処理環境の完全性についての基本的なチェックを提供する。完全性測定基準は、ブート・プロセスの検証についての推論を可能にするような形態であるべきである（正しいＢＩＯＳを使用してプラットフォームがブートされたかどうかを検証するのに完全性測定基準の値を使用することができる）。選択的にＢＩＯＳ内部の個々の機能ブロックはそれら自身のダイジェストの値を有し、全体的なＢＩＯＳのダイジェストはこれら個別のダイジェストのダイジェストである。これは、意図した目的にどの部分のＢＩＯＳ動作が重要であり、どれが無関係であるかをポリシーが言明することを可能にする（この場合、個別のダイジェストは、ポリシーの下での動作の有効性を確立するような態様で記憶されなければならない）。
【００４６】
他の完全性チェックは、プラットフォームに取り付けられた様々な他のデバイス、コンポーネント、または装置が存在し、正しく正常運転にあることを確立することを含む。１つの例では、周辺デバイスとの通信が信用されることを確実にするために、ＳＣＳＩコントローラに関連するＢＩＯＳプログラムが検証される。もう１つの例では、プラットフォーム上の他のデバイス（例えばメモリデバイスまたはコプロセッサなど）の完全性が、固定のチャレンジ／レスポンスの相互作用を成立させることによって検証されて、一貫性のある結果を確実にする。信用デバイス２４が別個のコンポーネントである場合、その様な相互作用のなんらかの形態は、信用デバイス２４とプラットフォームとの間での適当な論理的結合を提供する。さらに、本発明では信用デバイス２４はプラットフォームの他の部分との主通信手段としてデータバスを利用するけれども、（さほど便利ではないが）ハードワイアード経路または光学的経路などのような代替的な通信経路を提供することも可能である。さらに、本発明の実施形態では、信用デバイス２４がメイン・プロセッサ２１に完全性測定基準を検証するよう指示するけれども、他の実施形態では、信用デバイス自体が１つまたは複数の完全性測定基準を測定するよう構成される。
【００４７】
好ましくは、ＢＩＯＳブート・プロセスは、ブート・プロセスそれ自体の完全性を検証するメカニズムを有する。その様なメカニズムは、既に例えばインテルのドラフト「Wired for Management baseline specification v2.0 - BOOT Integrity Service」から分かり、ソフトウェアまたはファームウェアをロードする前にソフトウェアまたはファームウェアのダイジェストを演算することを含む。その様な演算されたダイジェストは、信用されたエンティティにより提供された証明書に記憶された値と比較される。これの公開鍵はＢＩＯＳに知られている。それから、演算された値が証明書からの期待値に合致し、かつ信用されたエンティティの公開鍵の使用によりその証明書が有効性を証明された場合にだけ、ソフトウェア／ファームウェアがロードされる。そうでなければ、適当な例外処理ルーチンが起動される。
【００４８】
選択的に、演算されたＢＩＯＳのダイジェストを受信した後で、信用デバイス２４は、証明書におけるＢＩＯＳの適当な値を検査することができ、演算されたダイジェストが適当な値に合致しない場合、ＢＩＯＳに制御を渡さないことができる。さらにまたは代替的に、信用デバイス２４は、ブール値を検査し、信用デバイス２４がアクセスされた最初のメモリでなかった場合にＢＩＯＳに戻る制御を渡さないことができる。これらの場合のどちらにおいても適当な例外処理ルーチンを起動することができる。
【００４９】
図５は、ＴＰ、プラットフォームに組み込まれた信用デバイス２４、および信用プラットフォームの完全性を検証したい（リモート・プラットフォームの）ユーザによる動作のフローを示す。ユーザがローカル・ユーザである場合、実質的に図５に示すのと同じステップが含まれることが考えられる。どちらの場合も、ユーザは、典型的には、検証を成立するソフトウェア・アプリケーションの形態に依存する。リモート・プラットフォームまたは信用プラットフォーム上でソフトウェア・アプリケーションを走らすことが可能である。しかしながら、リモート・プラットフォーム上でさえ、ソフトウェア・アプリケーションは何らかの方法で破壊される機会が存在する。したがって、高いレベルの完全性では、ユーザのスマートカード上にソフトウェア・アプリケーションが常駐し、そのユーザが検証目的のために適当な読み取り装置にスマートカードを挿入することが考えられる。図５は、一般的な場合についての動作のフローを示す。ユーザのスマートカードによる検証のための動作のより具体的なフローをさらに以下の図６を参照して説明する。
【００５０】
最初の例では、ＴＰ（これが信用プラットフォームを保証する）は、プラットフォームのタイプを検査して、それを保証するかどうかを判断する。これは、ポリシーの問題である。全てがよければ、ステップ６００において、ＴＰは、プラットフォームの完全性測定基準の値を測定する。それから、ＴＰは、ステップ６０５においてプラットフォームのために証明書を生成する。証明書は、信用デバイスの公開鍵、および選択的にそのＩＤラベルを完全性測定基準に追加し、ＴＰの私有鍵でストリングを署名することによってＴＰにより生成される。
【００５１】
信用デバイス２４は、次に信用デバイスの私有鍵を使用して、ユーザから受信されたなんらかの入力データを処理し、私有鍵の知識なしに入力／出力のペアを生成することが統計上不可能になるよう出力データを生成することによって信用デバイスのアイデンティティを証明することができる。そのため、私有鍵の知識は、この場合のアイデンティティの基礎をなす。アイデンティティの基礎をなすのに対象な暗号（symmetric encryption）を利用することが可能であることは明らかである。しかしながら、対象な暗号を使用する欠点は、ユーザが信用デバイスとユーザの秘密情報（secret）を共有する必要があるということである。さらに、ユーザと秘密情報を共有する必要性の結果、対象な暗号は、ユーザにアイデンティティを証明するのに原則として充分であるが、第三者にアイデンティティを証明するのには不十分であり。第三者は、信用デバイスまたはユーザから発生した検証を全く確認することができない。
【００５２】
ステップ６１０では、信用デバイス２４の不揮発性メモリの適当な場所３に証明書３５０を書き込むことによって、信用デバイス２４が初期化される。これは、好ましくは、マザーボード２０にインストールされた後で、信用デバイス２４とセキュア通信することによってなされる。信用デバイス２４に証明書を書き込む方法は、そこに私有鍵を書き込むことによってスマートカードを初期化するのに使用される方法に類似する。セキュア通信は、ＴＰだけに知られている「マスター鍵」によってサポートされ、製造中に信用デバイス（またはスマートカード）に書き込まれており、信用デバイス２４にデータの書き込みを可能にするのに使用される。マスター鍵の知識なしに信用デバイス２４にデータを書き込むことは不可能である。
【００５３】
プラットフォームの動作期間のどこか後の時点（例えばスイッチオンまたはリセットになるとき）で、ステップ６１５において、信用デバイス２４は、プラットフォームの完全性測定基準３６１を獲得し記憶する。
【００５４】
ユーザがプラットフォームと通信するのを望むとき、ステップ６２０において、ユーザは、例えば乱数などの臨時符号（nonce）を生成し、ステップ６２５において、信用デバイス２４にチャレンジする（プラットフォームのオペレーティング・システムまたは適当なソフトウェア・アプリケーションは、チャレンジを認識し、適当なやり方でＢＩＯＳタイプ・コールを介して信用デバイス２４にそれを渡すよう構成される）。臨時符号は、信用できないプラットフォームによる、古いが本物の署名のリプレイ（リプレイ攻撃と呼ばれる）によって生じるごまかし（deception）からユーザを保護するのに使用される。臨時符号を提供し、そのレスポンスを検証するプロセスは、既知のチャレンジ／レスポンス・プロセス（challenge/response protocol）の例である。
【００５５】
ステップ６３０において、信用デバイス２４は、チャレンジを受け取り、適当なレスポンスを生成する。これは、測定された完全性測定基準および臨時符号のダイジェストであってもよく、選択的にそのＩＤラベルであってもよい。それから、信用デバイス２４は、ステップ６３５においてその私有鍵を使用してダイジェストに署名し、証明書３５０に添えて署名されたダイジェストをユーザに返す。
【００５６】
ステップ６４０では、ユーザは、そのチャレンジのレスポンスを受け取り、ＴＰの既知の公開鍵を使用して証明書を検証する。それから、ユーザは、ステップ６５０において、証明書から信用デバイス２４の公開鍵を抽出し、それを使用して、チャレンジのレスポンスから署名されたダイジェストを解読する。それからステップ６６０において、ユーザは、チャレンジのレスポンス内の命令符号を検証する。次に、ステップ６７０において、ユーザは、演算された完全性測定基準（チャレンジのレスポンスから抽出する）と適当なプラットフォームの完全性測定基準（証明書から抽出する）とを比較する。ステップ６４５、６５５、６６５、または６７５における前述の検証ステップのいずれかが失敗した場合、全体のプロセスは、ステップ６８０で終わり、さらなる通信は発生しない。
【００５７】
全てがうまくいくと想定すると、ステップ６８５および６９０において、ユーザおよび信用プラットフォームは、他のプロトコルを使用して、他のデータのためにセキュア通信を設定する。ここで、プラットフォームからのデータは、信用デバイス２４によって署名されることが好ましい。
【００５８】
この検証プロセスのさらなる補強が可能である。チャレンジャー（challenger）は、チャレンジを通じて、プラットフォームの完全性測定基準の値とそれを得た方法の両方を認識することが好ましい。これら両方の情報部分は、チャレンジャーがプラットフォームの完全性について適当に判断することを可能にするのが望ましい。チャレンジャーは、利用することができる多くの異なる選択肢も有している。すなわち、チャレンジャーは、信用デバイス２４において完全性測定基準が有効として認識されることを受け入れる。またはチャレンジャーは、代替的に完全性測定基準の値がチャレンジャーによって保持された値（または、これら２つの場合において信用の異なるレベルになるようそこで保持してもよい）に等しい場合、関連するレベルの完全性をプラットフォームが有することだけを受け入れることができる。
【００５９】
証明書を署名し、使用する技術、およびそれらを使用してアイデンティティを証明する技術は、セキュリティの分野において既知であるので、ここでは詳細に述べる必要はない。
【００６０】
先に示すように、図６は、スマートカード１９を有する信用プラットフォームと相互に作用するユーザによるプラットフォームの完全性の検証の例における動作のフローを示す。先に述べたように、プロセスは、チャレンジ／レスポンスのルーチンを実装するのが便利である。利用することができる多くのチャレンジ／レスポンスのメカニズムが存在する。本発明の実施形態で使用される認証プロトコルの実施は、ＩＳＯ／ＩＥＣ９７９８−３「Information technology-Security techniques-Entity authentication mechanisms; Part 3; Entity authentication using a public key algorithm」(International Organization for Standardization, November 1993)に記載されるような、相互（または３ステップ）認証である。もちろん、例えばこの参照文献にも記載されるような２ステップまたは４ステップなどの他の認証プロシージャを利用することができない理由はない。
【００６１】
最初にステップ７００において、ユーザは、スマートカード１９をプラットフォームのスマートカード読み取り装置１２に挿入する。
【００６２】
事前に、この態様のユーザによる使用のためにコンフィギュレートされたプラットフォームは、典型的には、標準的なオペレーティング・システムの制御下で動作し、認証プロセスを実行し、ユーザがスマートカード１９を挿入するのを待っている。この態様でアクティブになるスマートカード読み取り装置１２とは別に、プラットフォームは、典型的には、ユーザ・インターフェース（すなわち、スクリーン、キーボード、およびマウス）をロックすることによってユーザがアクセスすることができない状態にある。しかしながら、これは、本発明の形態の全ての場合ではない。
【００６３】
スマートカード１９がスマートカード読み取り装置１２に挿入された場合、信用デバイス２４は、ステップ７０５において、臨時符号Ａを生成しスマートカード１９に転送することによって、ステップにおける相互認証を試みるようトリガーされる。例えば乱数などの臨時符号は、信用することができない第三者による、古いが本物のレスポンスのリプレイ（リプレイ攻撃と呼ばれる）によって生じるごまかしから発信者（originator）を保護するのに使用される。
【００６４】
それに応答して、ステップ７１０において、スマートカード１９は、レスポンスを生成して返す。このレスポンスは、プレーンテキストＡ、スマートカード１９により生成された新しい臨時符号Ｂ、信用デバイス２４のＩＤ、およびなんらかの冗長、スマートカード１９の私有鍵でプレーンテキストに署名することによって生成されたプレーンテキストの署名、並びにスマートカード１９のＩＤおよび公開鍵を含む証明書、の連結（concatenation）を含む。
【００６５】
信用デバイス２４は、ステップ７１５においてプレーンテキストの署名を検証するために証明書の公開鍵を使用することによってレスポンスを認証する。レスポンスが信用できなければ、プロセスはステップ７２０で終わる。レスポンスが信用できれば、ステップ７２５において信用デバイス２４は、さらなるレスポンスを生成し送信する。このさらなるレスポンスは、プレーンテキストＡ、臨時符号Ｂ、スマートカード１９のＩＤ、および獲得された完全性測定基準、信用デバイス２４の私有鍵を使用してプレーンテキストに署名することによって生成されたプレーンテキストの署名、並びにＴＰの私有鍵によって両方とも署名された信用デバイス２４の私有鍵および認証完全性測定基準、の連結を含む。
【００６６】
スマートカード１９は、ＴＰの公開鍵を使用し、認証完全性測定基準と獲得された完全性測定基準とを比較して、このレスポンスを認証する。ステップ７３０において、合致は検証の成功を示している。さらなるレスポンスが認証されなければ、プロセスは、ステップ７３５で終わる。
【００６７】
プロシージャが成功した場合、信用デバイス２４がログオンカード１９を認証し、スマートカード１９が信用プラットフォームの完全性を検証し、ステップ７４０において、認証プロセスがユーザのためにセキュア・プロセスを実行する。
【００６８】
ある種の相互作用では、認証プロセスはこの時点で終わる。しかしながら、セッションをユーザと信用プラットフォームとの間で続けるべきであれば、プラットフォームに認証されるのをユーザが維持することを確実にするのが望ましい。
【００６９】
続けられる認証が必要である場合、認証プロセスは、ステップ７４５においてインターバル・タイマを設定する。その後で、適当なオペレーティング・システムの割り込みルーチンを使用して、認証プロセスは、インターバル・タイマをサービスして、ステップ７５０において予め定めたタイムアウト周期にタイマが合うかまたは超過するときを周期的に検出する。
【００７０】
明らかに、認証プロセスおよびインターバル・タイマは、セキュア・プロセスと並列に走る。タイムアウト周期になるか超過するとき、認証プロセスは、信用デバイス２４をトリガーして、ステップ７６０においてスマートカード１９に対しチャレンジを転送しそれ自体を識別することによってスマートカード１９を再認証する。スマートカード１９は、ステップ７６５においてそのＩＤと公開鍵を含む証明書を返す。ステップ７７０では、レスポンスが無いか（例えばスマートカード１９が取り除かれた結果）または証明書がなんらかの理由によりもはや有効ではなければ（例えばスマートカードが異なるスマートカードと取り替えられた）、ステップ７７５において信用デバイス２４によってセッションが終了される。そうでなければ、ステップ７７０において、ステップ７４５からのプロセスがインターバル・タイマをリセットすることによって繰り返される。
【００７１】
さらにまたは代替的に、いくつかの実施形態では、ユーザ・プロファイルが暗号化され、プライバシーと完全性を保護するよう署名されることが必要とされる。その場合、セキュア・データ転送プロトコルが信用デバイス２４とスマートカード１９との間に必要とされる。２つのエンティティ間でセキュア証明書を転送するために、利用することができる多くのメカニズムが存在する。本発明の実施形態で使用することができる可能性のある実施は、ＩＳＯ／ＩＥＣＤＩＳ１１７７０−３「Information technology - Security techniques - Key management - Part3 : Mechanisms using asymmetric techniques」(International Organization for Standardization, March 1997)からのセキュア・キー・トランスポート・メカニズム(secure key transport mechanism)である。
【００７２】
他の既知のチャレンジおよびレスポンス技術を使用する検証プロセスの修正は、当業者によって容易に実現される。同様に、代替的な検証プロセスが様々な態様（すなわちスマートカードを備えたユーザ以外）におけるプラットフォームと相互に作用するパーティによって使用されることができる。
【００７３】
ここで、図７を参照して、本発明の特定の形態を説明する。図７では、ホスト・コンピュータ１００は、メインＣＰＵ１０２、ハードディスク・ドライブ１０４、ＰＣＩネットワーク・インターフェース・カード１０６、およびＤＲＡＭメモリ１０８を、それらの間にある従来技術（通常）の通信経路１１０（例えばＩＳＡ、ＥＩＳＡ、ＰＣＩ、ＵＳＢなど）と共に有する。ネットワーク・インターフェース・カード１０６は、ホスト・コンピュータ１００の外部の世界と通信する外部通信経路１１２も有する。
【００７４】
ネットワーク・インターフェース・カード１０６は、間にあるインターフェース１１８で「レッド」データ・ゾーンと「ブラック」データ・ゾーンとに論理的に分けられる。レッド・ゾーン１１４では、データは、通常、プレーンテキストであり、センシティブで、未検出の変更（undetected alteration）および好ましくない盗聴(eavesdropping)に対して脆弱である。ブラック・データ・ゾーン１１６では、データは、未検出の変更および好ましくない盗聴から保護される（標準暗号メカニズムにより暗号化されるのが好ましい）。インターフェース１１８は、レッド情報がブラック・ゾーン１１６に漏れないことを確実にする。インターフェース１１８は、好ましくは、標準暗号方法および電気的隔離技術（electronic isolation technique）を使用して、レッド・ゾーン１１４とブラック・ゾーン１１６とを分離する。その様なレッド・ゾーン１１４、ブラック・ゾーン１１６、およびインターフェース１１８の設計並びに構築は、セキュリティおよび電子技術の分野において（特に軍事分野において）既知である。通常の通信経路１１０および外部通信経路１１２は、ネットワーク・インターフェース・カード１０６のブラック・ゾーン１１６に接続する。
【００７５】
ホスト・コンピュータ１００は、信用モジュールを備え、この信用モジュールは、通常の通信経路１１０に接続されるだけでなく、それぞれ相互に分離された付加的通信経路１２２（１２２ａ、１２２ｂ、１２２ｃと参照する）によって、ＣＰＵ１０２、ハードディスク・ドライブ１０４およびネットワーク・インターフェース・カード１０６のレッド・ゾーン１１４に接続される。一例では、信用モジュール１２０は、メモリ１０８との別個の付加的通信経路１２２を持たない。
【００７６】
信用モジュール１２０は、付加的通信経路１２２ａ、ｂ、ｃをそれぞれ介して、ＣＰＵ１０２、ハードディスク・ドライブ１０４、およびネットワーク・インターフェース・カード１０６のレッド・ゾーン１１４と通信することができる。通常の通信経路１１０を介して、ＣＰＵ１０２、ハードディスク・ドライブ１０４、ネットワーク・インターフェース・カード１０６のブラック・ゾーン１１６、およびメモリ１０８と通信することもできる。信用モジュール１２０は１００ＶＧスイッチング・センター（100VG switching center）として作用して、信用モジュールに記憶されたポリシーの制御下で、信用モジュール１０２および付加的通信経路１２２を介して、ＣＰＵ１０２、ハードディスク・ドライブ１０４、およびネットワーク・インターフェース・カード１０６のレッド・ゾーン１１４に、情報を経路設定することもできる。信用モジュール１２０は、暗号鍵を生成し、付加的通信経路１２２ａ、ｂ、ｃを介して、これらの鍵を、ＣＰＵ１０２、ハードディスク・ドライブ１０４、およびネットワーク・インターフェース・カード１０６のレッド・ゾーン１１４にそれぞれ分配することができる。
【００７７】
図８は、信用モジュール１２０の物理的アーキテクチャを示す。第１のスイッチング・エンジン１２０は、付加的通信経路１２２ａ、ｂ、ｃに個別に接続され、信用モジュール１２０の内部通信経路１２６にも接続される。このスイッチング・エンジン１２４は、信用モジュール１２０にロードされたポリシーの制御下にある。信用モジュール１２０の他のコンポーネントを以下に示す。
【００７８】
・信用モジュール１２０を管理し、信用モジュール１２０のために演算する一般目的を実行するコンピューティング・エンジン１２８
・一時データを記憶する揮発性メモリ１３０
・長期データを記憶する不揮発性メモリ１３２
例えば暗号化および鍵生成などの特殊な暗号機能を実行する暗号エンジン１３４・暗号動作において主に使用される乱数ソース１３６
・信用モジュール１２０を通常通信経路１１０に接続する第２のスイッチング・エンジン１３８
・タンパ検出メカニズム１４０
これらの全てが信用モジュール１２０の内部通信経路１２６に接続される。信用モジュール１２０は、図１〜図６を参照して先述したような信用デバイスまたはモジュール１４に基づいている。
【００７９】
暗号鍵生成および分配に関しては、信用モジュール１２０が、乱数生成器１３６、ハッシュ・アルゴリズムおよび他のアルゴリズムを使用して暗号鍵を生成する。これら自体は、セキュリティの分野において既知である。信用モジュール１２０は、通常通信経路１１０ではなく付加的通信経路１２２ａ、ｂ、ｃを使用して、選ばれた鍵をＣＰＵ１０２、ハードディスク・ドライブ１０４、およびネットワーク・インターフェース・カード１０６のレッド・ゾーン１１４にそれぞれ分配する。鍵は、通常通信経路１１０によるプラットフォームの内部モジュール（１０２、１０４、１０６、１２０）間の通信に使用される。信用モジュール１２０の外部に明らかにしてはならない長期アイデンティティの秘密情報を使用するＳＳＬハンドシェーク・フェーズを信用モジュール１２０が完了した後で、他の一時的な鍵は、ＳＳＬプロトコルを使用する外部データのバルク暗号化または解読（bulk encryption or decryption）に（ネットワーク・インターフェース・カード１０６またはＣＰＵ１０２によって）使用されることができる。信用モジュール１２０の外部に明らかにしてはならない長期秘密情報を使用してそれらの一時的鍵が信用モジュール内部で生成されるかまたは明らかにされた後で、他の一時的な鍵は、ハードディスク・ドライブ１０４上に記憶されたデータのバルク暗号化または解読に（ハードディスク・ドライブ１０４またはＣＰＵ１０２によって）使用されることができる。
【００８０】
信用モジュール１２０は、暗号鍵の選択的分配によってモジュール間の通信上のポリシー制御を強化する。信用モジュール１２０は、モジュールのペアの間の共用インフラストラクチャ１１０にわたるセキュア通信を可能にする鍵を発行するのを拒否することによって、所与のモジュールのペアの間の通信でのポリシーバン（policy ban）を強化する。
【００８１】
図９は、信用モジュール１２０がウォッチドッグ機能を実行し、付加的通信経路１２２に接続されたモジュール１０２、１０４、１０６にピン（ping）するプロセスを示す。信用モジュールは、チャレンジ１４２を生成し、それを、ＣＰＵ１０２、ハードディスク・ドライブ１０４、およびネットワーク・インターフェース・カード１０６のレッド・ゾーン１１４にそれぞれ送信する。ＣＰＵ１０２、ハードディスク・ドライブ１０４、およびネットワーク・インターフェース・カード１０６のそれぞれは、それぞれの付加的通信経路１２２ａ、ｂ、ｃ上にレスポンス１４４ａ、ｂ、ｃでそれぞれ応答して、各モジュールがアクティブかどうか、および好ましくはモジュールが適当に動作していることを告げる。信用モジュール１２０は、レスポンス１４４ａ、ｂ、ｃを記録し、図１〜図６を参照して前述した完全性のチャレンジに応答して、それらを測定基準として使用する。
【００８２】
図１０は、信用モジュール１２０がプラットフォームにおいて暗号能力を有する唯一のモジュールであるときに外部のセキュア・メッセージの入来が処理されるプロセスを示す。外部メッセージ１４６は、外部通信経路１１２を使用してネットワーク・インターフェース・カード１０６のブラック・ゾーン１１６によって受信される。ネットワーク・インターフェース・カード１０６は、通常通信経路１１０を使用して、認証のためのいくつかのデータおよびリクエスト、並びに完全性チェックを含むプロトコル・データ・ユニット１４８（後でさらに詳細に述べる）を信用モジュール１２０に送信する。信用モジュール１２０は、信用モジュール１２０の外部に明らかにしてはならない信用モジュール１２０内の長期鍵を使用して、認証および完全性チェックを実行し、付加的通信経路１２２ｃを使用して、「ＯＫ」の標識を含むプロトコル・データ・ユニット１５０をネットワーク・インターフェース・カード１０６のレッド・ゾーン１１４に送信する。それから、ネットワーク・インターフェース・カード１０６は、通常通信経路１１０を使用して、解読のためのいくつかのデータおよびリクエストを含むプロトコル・データ・ユニット１５２を信用モジュール１２０に送信する。信用モジュール１２０は、信用モジュール１２０内の一時的または長期的鍵のいずれかを使用して、データを解読し、付加的通信経路１２２ａを使用して、解読されたデータを含むプロトコル・データ・ユニット１４５をＣＰＵ１０２に送信する。それからＣＰＵ１０２は、適当な動作をとる。
【００８３】
図１１は、ＣＰＵ１０２が信用モジュール１２０からポリシーの判断を要求するプロセスを示す。これは、例えば、あるデータを操作することまたはアプリケーションを実行することをポリシーが認めるかどうかをＣＰＵ１０２が判断する際に使用される。これは、本願と同日に国際特許出願したもう１つ明細書に詳細に記載されている。ＣＰＵ１０２は、通常通信経路１１０を使用して、リクエストを含むプロトコル・データ・ユニット１５６を送信する。信用モジュール１２０は、信用モジュール１２０内に記憶されたポリシーに従ってリクエスト１５６を処理する。信用モジュール１２０は、付加的通信経路１２２ａを使用して、リプライ（reply）を含むプロトコル・データ・ユニット１５８をＣＰＵ１０２に送信し、それにより、ＣＰＵ１０２は、認可が信用モジュールから来ることを確実にする。その動作が認証されれば、ＣＰＵ１０２は必要な動作をとる。そうでなければ、そのプロセスを中止する。
【００８４】
図１２は、モジュール間（１０２、１０４、１０６）で保護された通信にわたるポリシー制御の例を示す。この例における通信の全ては、付加的通信経路１２２を使用する。ネットワーク・インターフェース・カード１０６のレッド・ゾーン１１４は、ハードディスク・ドライブ宛のプロトコル・データ・ユニット１６０を付加的データ経路１２２ｃ上の信用モジュール１２０に送信する。ポリシーがこれを許さない場合、信用モジュール１２０が拒絶を含むプロトコル・データ・ユニット１６２を付加的データ経路１２２ｃ上でネットワーク・インターフェース・カード１０６に送信することによってリクエストを否定する。その後で、ＣＰＵ１０２は、ハードディスク・ドライブにアドレス指定されたプロトコル・データ・ユニット１６４を送信することによって、ハードディスク１０４からセンシティブなデータをリクエストするが、付加的データ経路１２２ａ上で信用モジュール１２０に送信する。信用モジュール１２０は、ポリシーがこれを認めるかチェックする。認めた場合、信用モジュール１２０は、付加的データ経路１２２ｂ上でハードディスク・ドライブ１０４にプロトコル・データ・ユニット１６４を中継する。ハードディスク・ドライブ１０４は、データを提供し、付加的データ経路１２２ｂ上のプロトコル・データ・ユニット１６６でそれを送信し、ＣＰＵ１０２にアドレス指定された信用モジュール１２０に戻す。信用モジュール１２０は、ポリシーがこれを認めるかをチェックし、認める場合、付加的データ経路１２２ａ上のＣＰＵ１０２にプロトコル・データ・ユニット１６６を中継する。
【００８５】
図１３は、付加的通信経路１２２を介してデータを引き渡すデータ・プロトコル・ユニット１７８のフォーマットを示す。
【００８６】
・プロトコル・データ・ユニットのタイプを示す識別フィールド１６８
・プロトコル・データ・ユニットの長さを示すレングス・フィールド１７０
・プロトコル・データ・ユニットのソースを示すソース・フィールド１７２
・プロトコル・データ・ユニットの宛先を示す宛先フィールド１７４
・多くの場合にデータフィールド１７６を示すその他
全てのフィールドが常に必要なわけではない。例えば、信用モジュール１２０内で作られない鍵プロトコル・データ・ユニットを中継するのを信用モジュール１２０のポリシーが禁止すると想定すると、ＣＰＵ１０２、ハードディスク・ドライブ１０４、およびネットワーク・インターフェース・カード１０６は、鍵が常に信用モジュール１２０からのものであると想定する。したがって、ソースおよび宛先フィールドは、鍵プロトコル・データ・ユニットにおいて必要ない。その様なプロトコル・データ・ユニットは、暗黙のうちに認証される。プロトコル・データ・ユニットの設計、構築および使用、それ自体は、通信の分野における当業者に既知のものである。
【００８７】
本発明の形態が単に例として述べられ、本発明の範囲で多くの変形および改良をすることができることに留意されたい。
【図面の簡単な説明】
【図１】本発明の実施形態を実施することができるシステムを示す図。
【図２】スマートカード読み取り装置を介してスマートカードおよび一連のモジュールと通信するよう構成された信用デバイスを含むマザーボードを示す図。
【図３】より詳細な信用デバイスを示す図
【図４】コンピューティング装置の完全性測定基準を獲得することを含むステップを示すフロー図。
【図５】完全性を検証する信用プラットフォームを含む信用コンピューティング・プラットフォームとリモート・プラットフォームとの間の通信を確立することを含むステップを示すフロー図。
【図６】スマートカードによるプラットフォームの潜在的なユーザによる信用コンピューティング・プラットフォームの検証を含むステップを示す図。
【図７】本発明を実施するホスト・コンピュータ・システムの模式的ブロック図。
【図８】図７のシステムにおける信用モジュールの模式的ブロック図。
【図９】そこで使用される様々な通信方法を示す図。
【図１０】そこで使用される様々な通信方法を示す図。
【図１１】そこで使用される様々な通信方法を示す図。
【図１２】そこで使用される様々な通信方法を示す図。
【図１３】図７のシステムで使用されるプロトコル・データ・ユニットのフォーマットを示す図。
【符号の説明】
２０マザーボード
２１メイン・プロセッサ
２２メイン・メモリ
２３ＩＯデバイス
２４信用デバイス
２９ＢＩＯＳメモリ

Claims

信用ハードウェア・モジュールと、
複数のさらなるハードウェア・モジュールと、
前記信用ハードウェア・モジュールおよび前記複数のさらなるハードウェア・モジュールが互いに通信することができる共用通信インフラストラクチャと、
前記信用ハードウェア・モジュールと、前記さらなるハードウェア・モジュールのうちの第１のハードウェア・モジュールとが互いに通信することができる、前記共用通信インフラストラクチャとは異なる第１の通信経路と、を備え、
前記信用ハードウェア・モジュールは、暗号鍵および解読鍵を生成し、前記共用通信インフラストラクチャを介してではなく、前記第１の通信経路を介して、前記第１のハードウェア・モジュールに前記暗号鍵および解読鍵を供給するよう動作し、
前記信用ハードウェア・モジュールおよび前記第１のハードウェア・モジュールは、前記共用通信インフラストラクチャを介して前記暗号鍵および解読鍵を使用して互いに通信する、コンピューティング装置。
前記信用ハードウェア・モジュールおよび前記第１のハードウェア・モジュールは、前記第１の通信経路を介する直接の通信に参加するコンピューティング・エンジンをそれぞれ含む、請求項１に記載のコンピューティング装置。
前記第１のハードウェア・モジュールがデータ操作のリクエストを前記信用ハードウェア・モジュールに供給するよう動作することができ、
前記リクエストに応答して、前記信用ハードウェア・モジュールが前記データ操作の許可または不許可のレスポンスを生成し、前記共用通信インフラストラクチャを介してではなく、前記第１の通信経路を介して前記第１のハードウェア・モジュールに該レスポンスを供給する、請求項１又は２に記載のコンピューティング装置。
前記信用ハードウェア・モジュールは、許可することができる動作および許可することができない動作に関するポリシー情報を記憶するための手段を含み、該ポリシー情報を参照して、前記レスポンスを生成するよう動作することができる、請求項３に記載のコンピューティング装置。
前記信用ハードウェア・モジュールは、チャレンジを生成し、前記第１の通信経路を使用して設定された暗号鍵を使用して、前記第１の通信経路を介して前記第１のハードウェア・モジュールに該チャレンジを供給する、請求項１乃至４のいずれかに記載のコンピューティング装置。
前記チャレンジに応答して、前記第１のハードウェア・モジュールがレスポンスを生成し、前記第１の通信経路を使用して設定された暗号鍵を使用して、該第１の通信経路を介して、前記信用ハードウェア・モジュールに該レスポンスを供給する、請求項５に記載のコンピューティング装置。
前記第１のハードウェア・モジュールが私有のデータのための私有データ・ゾーンおよび非私有のデータのための非私有データ・ゾーンを有し、
前記第１のハードウェア・モジュールが、前記共用通信インフラストラクチャを介してではなく、前記第１の通信経路を介して、前記私有データ・ゾーンとの間でデータを送信または受信するよう動作することができる、請求項１乃至６のいずれかに記載のコンピューティング装置。
前記第１のハードウェア・モジュールは、前記共用通信インフラストラクチャを介して、前記非私有データ・ゾーンとの間でデータを送信または受信するよう動作することができる、請求項７に記載のコンピューティング装置。
前記第１のハードウェア・モジュールは、前記私有データ・ゾーンと前記非私有データ・ゾーンとの間に、該私有データ・ゾーンから該非私有データ・ゾーンへのデータの通過を妨げるよう動作するインターフェースを有する、請求項７又は８に記載のコンピューティング装置。
前記第１のハードウェア・モジュールは、ネットワーク・インターフェース・モジュールである請求項１乃至９のいずれかに記載のコンピューティング装置。
前記共用通信インフラストラクチャおよび前記第１の通信経路とは異なる、前記信用ハードウェア・モジュールと、前記さらなるハードウェア・モジュールのうちの第２のハードウェア・モジュールとが互いに通信することができる、第２の通信経路をさらに備える、請求項１乃至１０のいずれかに記載のコンピューティング装置。
前記第１のハードウェア・モジュールは、前記第１と第２のハードウェア・モジュールとの間で、前記信用ハードウェア・モジュールにデータ転送のリクエストを供給するよう動作することができ、
前記データ転送のリクエストに応答して、前記信用ハードウェア・モジュールは、前記データ転送の許可または不許可のレスポンスを生成し、前記共用通信インフラストラクチャではなくて、場合に応じて前記第１または第２の通信経路を介して、前記第１または第２のハードウェア・モジュールに該レスポンスを供給するよう動作することができる、請求項１１に記載のコンピューティング装置。
前記信用ハードウェア・モジュールは、許可することができる転送およびまたは許可することができない転送に関するポリシー情報を記憶するための手段を有し、該ポリシー情報を参照して前記レスポンスを生成するよう動作することができる、請求項１２に記載のコンピューティング装置。
適当な転送レスポンスに応答して、前記第１または第２のハードウェア・モジュールは、場合に応じて前記第１または第２の通信経路を介して、前記信用ハードウェア・モジュールにデータを供給することができ、
当該データの受信に応答して、前記信用ハードウェア・モジュールは、場合に応じて前記第２または第１の通信経路を介して、場合に応じて前記第２または第１のハードウェア・モジュールに該データを中継するよう動作することができる、請求項１２又は１３に記載のコンピューティング装置。
前記第２のハードウェア・モジュールは、前記コンピューティング装置の主プロセッサまたは不揮発性データ記憶モジュールである、請求項１１又は１４に記載のコンピューティング装置。
前記共用通信インフラストラクチャはデータバスである、請求項１〜１５のいずれかに記載のコンピューティング装置。