(57)【要約】【課題】  情報処理装置、サーバ装置、情報処理装置のための方法、サーバ装置のための方法および装置実行可能なプログラムを提供する。【解決手段】  情報処理装置は、ソフトウェア構成に固有であり、ネットワークに接続されたサーバの初期コードの一致性を保証する、署名付き一致性値を使用する。サーバ装置は、サーバ装置を証明する鍵を生成し（Ｓ８１０、Ｓ８２０、Ｓ８３０）を生成する。鍵の１つは、第３者により証明され手織り、ディジタル署名を生成させる（Ｓ８４０）。ディジタル署名は、一致性値に付され、署名付き一致性値が情報処理装置へと通信され手、情報処理装置がネットワークを介した安全なサービスを受け取ることを可能としている（Ｓ８５０、Ｓ８６０）。【選択図】  図８
2005167589.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを通じてサービスを受け取るための情報処理装置であって、前記情報処理装置は、ハードウェア構成を反映する一致性値の少なくとも１つと共にディジタル署名を受け取る通信部と、少なくとも前記一致性値の同一性を検証するためのチェック部とを含み、前記情報処理装置は、前記一致性値の決定に応答して前記ネットワークを通して前記情報処理装置のための排他的ドメインを形成させるリクエストを発行する、情報処理装置。
【請求項２】
前記チェック部は、格納されたディジタル署名または格納された値に関連して前記ディジタル署名または一致性値を検査する、請求項１に記載の情報処理装置。
【請求項３】
前記情報処理装置は、前記ネットワークからサービスを受け取るクライアントである、請求項１に記載の情報処理装置。
【請求項４】
ネットワークを通してオンデマンドに処理されたデータを提供するため、前記ネットワークに接続されたサーバ装置であって、前記サーバ装置は、装置信頼性ルートに基づいて信頼性を与え、かつ前記サーバ装置のスタートまたはリセットに際してディジタル署名に付される署名付き一致性値を生成し、前記一致性値が前記サーバ装置の構成の一致性を与える信頼性付与部と、前記ネットワークからリクエストを受け取り、かつ前記サーバ装置の署名された一致性値および処理されたデータを前記ネットワークへと送出する通信部とを含み、前記サーバ装置は、新規ドメインを生成し、かつ他のリクエストを受け取ると前記署名された一致性値に応答して前記サーバ装置へのリソースへのアクセスを許可するサーバ装置。
【請求項５】
前記サーバ装置は、スタートまたはリセットまたはそれら双方に際して管理を開始させ、リソースへのアクセスを可能とするルート鍵へのアクセスを許可する、請求項４に記載のサーバ装置。
【請求項６】
前記サーバ装置のリソースは、暗号化された形式として格納され、前記サーバ装置は、前記ルート鍵の復号により前記リソースへのアクセスを許可する、請求項４に記載のサーバ装置。
【請求項７】
前記署名を生成するために、認証付き証明が通信され、前記サーバの格納部には、前記認証付き証明が格納されているか、または前記サーバ装置は、前記認証付き証明を、遠隔エンティティを通じて問い合わせる、請求項４に記載のサーバ装置。
【請求項８】
情報処理装置をしてネットワークを通じてサーバ装置と通信させるための方法であって、前記方法は、前記情報処理装置に対して、ハードウェア構成に依存する署名された一致性値を受け取るステップと、前記署名された一致性値の少なくとも１つの同一性を決定するステップと、前記一致性値の前記決定に応答して前記ネットワークを通じて前記情報処理装置のための排他的ドメインを生成するリクエストを送出させるステップとを実行させる方法。
【請求項９】
前記サーバ装置は、前記署名された一致性値と処理されたデータとを前記ネットワークを通して、前記リクエストを発行した情報処理装置に対して送出する、請求項８に記載の方法。
【請求項１０】
ネットワークを介してサーバ装置に通信を実行させるための方法であって、前記方法は、前記サーバ装置に対して、前記サーバ装置が段階的に実行するセットアップのための初期コードをメモリから呼出すステップと、前記サーバ装置のソフトウェア構成に関連して不変に維持される一致性値を生成し、前記一致性値をレジスタ・アレイに格納させるステップと、前記サーバ装置の一致性を認証することにより前記一致性値に付すべきディジタル署名を生成するステップと、前記一致性値に前記生成されたディジタル署名を付するステップと、前記サーバ装置の認証を証明するために、前記一致性値を前記ディジタル署名と共に送出するステップとを実行させる方法。
【請求項１１】
前記生成ステップは、前記ソフトウェア構成に関連するハードウェアの一致性値のための私有鍵および認証を検証するための私有鍵を生成するステップと、前記鍵の認証に応答して前記一致性値に対してディジタル署名を与えるか否かを決定するステップと、前記検証のための鍵が認証された場合には、前記一致性値に対して前記ディジタル署名を付するステップとを含む、請求項１０に記載の方法。
【請求項１２】
前記方法は、さらに、前記検証のための鍵を使用して前記ディジタル署名を生成させるステップを含む、請求項１１に記載の方法。
【請求項１３】
ネットワークに接続されたサーバ装置に対して、前記ネットワークを通じて処理されたデータをオンデマンドに提供させるための方法であって、前記方法は、前記サーバ装置に対して、装置一致性に応答する一致性値に基づいて信頼性の付与された管理ドメインを生成するステップと、認証証明を参照して前記一致性値を認証し、ディジタル署名を付するステップと、前記サーバ装置のサービスを受け取るために前記ネットワークから前記サーバ装置にアクセスするためのリクエストを受け取るステップと、ディジタル署名を伴う少なくとも１つの一致性値を通信するステップと、前記リクエストに対応する排他的ドメインを生成させる他のリクエストを受け取るステップとを実行させる方法。
【請求項１４】
前記管理ドメインは、ルート鍵に対するアクセスを許可するステップを実行して、前記サーバ装置のリソースへのアクセスを制御させる、請求項１３に記載の方法。
【請求項１５】
前記サーバ装置のリソースは、暗号化された形式で格納され、前記方法は、さらに前記ルート鍵を使用して前記リソースを復号して情報処理装置による前記リソースへのアクセスを許可するステップを含む、請求項１４に記載の方法。
【請求項１６】
請求項８または請求項９に記載の方法を前記情報処理装置に対して実行させるための装置実行可能なプログラム。
【請求項１７】
請求項１０から請求項１５のいずれか１項に記載の方法を前記サーバ装置に実行させるための装置実行可能なプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ・ネットワークにおけるセキュリティに関連し、特にリモート・ネットワーク環境において安全にプログラムを実行させる手段を含むネットワーク環境において有効な、情報処理装置、サーバ装置、情報処理装置のための方法、サーバ装置のための方法、およびこれら装置で実行可能なプログラムに関する。
【背景技術】
【０００２】
近年では、機密情報、重要な情報またはコンピュータ自体を、予期されていない攻撃から保護するために、ネットワーク・システムの安全性が強く要求されている。この目的のため、例えばＰａｌｌａｄｉｕｍ（商標）といったいくつかの試みが提案されている（非特許文献１）。Ｐａｌｌａｄｉｕｍアーキテクチャでは、プラットホーム製造者は、いわゆるＮｕｂを、新規に製造されたＰＣにインストールさせると共に、Ｎｕｂとして参照されるカーネル内に、公開鍵／私有鍵ペアを生成させ、ＰＣが正当なＰａｌｌａｄｉｕｍプラットホームであることを認証するための製造者証明を与える。これらのプロセスは、このプロセスまたは製造者がＮｕｂとプラットホームとの間の信頼性のある結合を生成させるために、唯一信頼できると考えられる、製造プロセス中に完了されなければならない。
【０００３】
従来のＮｕｂシステムは、認証のために１つの制御ポイントを有している。すなわち、正当なＰａｌｌａｄｉｕｍ（商標）プラットホームの認証およびプラットホーム上で実行されるアプリケーションの認証である。上述したポリシーは、いくつかのタイプのプラットホーム上で実行されるゲーム・タイトルについて与えられた従来の環境に極めて類似するものである。
【０００４】
ネットワーク接続されたコンピュータ・システムに加え、サーバ・テクノロジーにおいては、サーバは、コンピュータ、ＰＤＡ、およびある場合には携帯電話などといった、多くの異なったタイプの情報処理装置（以下、本発明では、単にクライアントとして参照する）からの接続を受け付けるために、さらにフレキシビリティのある別のセキュリティ・ポリシーが要求される。サーバに加え、クライアントは、Ｐａｌｌａｄｉｕｍベースのプラットホームや他の信頼性アーキテクチャに基づいたプラットホームと対話することができる。サーバは、異なった種類のクライアントについてもサービスを提供することができる、より柔軟なポリシーを含むことができる。このため、サーバは、より柔軟でかつアプリケーションから独立したポリシーの下で、セキュリティに対して対応することが必要とされる。
【０００５】
ＯＳＧｉ（非特許文献３）は、個別的なサービスのための環境を提供するために設計されたフレームワークを規定しており、上述したようなサービスを提供し、管理し、ライフサイクル処理を行う機能を提供する。最も重要な点は、ＯＳＧｉは、他のバンドルからの干渉に対してサービス・バンドルを保護することにある。同様に、ユーザ管理サービスおよびプログラム化されたアクセス制御についてのサービスが利用可能である。
【０００６】
典型的には、クライアントおよびサーバといったプラットホームは、単一のJava（登録商標）仮想マシンのインスタンスを含んでおり、単一のＯＳＧｉフレームワークのインスタンスが他のサービスのすべてを実行させながら実行されている。各サービスのバンドルは、自己のクラス・ローダを有しており、このクラス・ローダは、バンドル・クラスの干渉を避けるように構築されている。ＯＳＧｉは、標準的なJava（登録商標）２のセキュリティ機構の上に成り立つ。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
分散コンピューティング・システムでは、アプリケーションを構成するいくつかのコンポーネントは、サーバ、またはある場合にはクライアントといった遠隔したプラットホームにおいて実行する必要がある。遠隔したプラットホームは、ユーザの要求に応じて保護された実行ドメインを提供することができる。これらのコンポーネントが機密事項を含む情報を処理する場合には、実行の機密性および一致姓が同一のプラットホーム上で実行されている他のプログラムから適切に保護されているか否かという疑問が生じる。この場合、以下に示す２つの状況が考えられる。
【０００８】
（ｉ）遠隔情報処理装置（クライアント）
ＰＤＡや携帯電話といったモバイル・クライアントは、ますます強力になっている。１つの方向として、オンライン・バンキング、ｅ−チケット発行およびオンライン・ゲームなど、多くのサービス・プロバイダは、より機能を充実させ、ユーザーに使いやすくなるように、クライアントに対してそれらのアプリケーションの一部を「プッシュ」ようと試みる。これらのアプリケーションは、いくつかのアプリケーションが競合する可能性のある場合には機密保持されねばならない情報を有しているので、互いに分離される必要がある。上述したクライアント上でアプリケーションを実行させることを希望するサービス・プロバイダは、クライアントが機密性のデータやプログラムをサーバへとクライアントが送信する前に、他のアプリケーションに対して充分保護されているか否かを確認する必要がある。
【０００９】
（ｉｉ）遠隔オンデマンド・サーバ装置
グリッド・コンピューティング環境は、「オンデマンド」コンピューティングを実現する１つの方法である。グリッド・コンピューティングのノードは、通常、異なるセキュリティ・ポリシーを有し、かつ異なるセキュリティ能力を有する複数のグリッド・サービス・プロバイダにより維持されている。グリッド・コンピューティング・ユーザは、ノードに対してジョブを登録する前に、ノード上で実行されているシステム・ソフトウェアのバージョンおよび構成を検証することができなければならず、このことによってユーザは、ノードが提供する保護レベルに満足することができる。これらの項目に対応するために、下記の２つの問題が解決される必要がある。
【００１０】
（ａ）装置信頼性
この問題は、どのようにすれば、装置がユーザの考えている装置であるか、および装置がユーザの期待通りの振る舞いをするかを、ユーザが確認することができるかということである。この問題は、ユーザが装置の同一性および一致性を検証する必要があることを示す。プラットホームがユーザの考えるものでない場合には、信頼性の関係が壊される。また、例えばウイルス、スパイウェア、トロイの木馬の存在、または違うオペレーティング・システム上で実行されているエミュレータであっても同様である。
【００１１】
（ｂ）ドメイン分離およびアクセス制御
遠隔サーバは、異なるアプリケーションを提供するために、複数のプログラムを実行することができる。各アプリケーションは、分離されなければならず、かつ他のアプリケーションから保護されなければならない。いくつかの場合には、アプリケーションは、いくつかのリソースを他のアプリケーションと共用することを必要とし、このため、アプリケーションは、どのデータを他のアプリケーションと共用でき、どのデータが保護されるべきであるかの制御を保持することが必要とされる。この要求は、また、例えばマルチアプリケーション・スマート・カードにおいても見いだされ、これは、またJava（登録商標）カード・アーキテクチャおよびグローバル・プラットホーム・アーキテクチャにより対応されている（非特許文献２）。
【００１２】
本発明は、部分的には、セキュリティ・ハードウェア、安全なオペレーティング・システムのカーネル、およびエンド・ツウ・エンドの信頼性関係を提供するオープン・セキュリティ・プロトコルを含む新規な技術を組み合わせることにより、ネットワークされたプラットホームの基本的な信頼性を高めることができるという着想のもとになされたものである。本発明において使用される一致性値、すなわち、ＰＣＲ値は、システムのパワーオン・リセットから開始されるプラットホームのブートストラップ・シーケンスにおいて生成され、TPMとして参照されるハードウェア・セキュリティ・モジュールにより外部侵入から安全に保護される。このため、本発明における一致性値は、高い安全性を有する。これらの高度に安全な一致性値は、二つの公開鍵暗号の鍵と組み合わされ、高度な安全性を有するネットワーク環境が提供できる。１つ目の鍵は、セキュリティ・モジュールのハードウェア製造者正当性を示す“エンドーズメント鍵”であり、網一つの鍵は、プラットホーム証明に基づき信頼性ある第三者により認証される“検査一致性鍵(Attestation Integrity Key)”である。両方の鍵は、セキュリティ・モジュール内に格納され、かつ使用される。一致性値は、“検査一致性鍵”によりチップ内部で署名され、リモート・エンティティへと安全に転送される。
【００１３】
本発明の目的は、リモート・プラットホーム上で安全にプログラムを実行させる手段を含むネットワーク環境を提供することにある。例えば、サービス・プロバイダは、クライアント装置上でアプリケーションを実行させる必要がある。また、グリッド・コンピューティングのユーザは、リモート・グリッド・コンピューティング・ノードにジョブを登録することを希望する。これらの場合には、遠隔の情報処理機械での実行の機密性および一致姓を維持することが要求される。
【００１４】
さらに、本発明の目的は、ネットワーク内のコンピュータに対して、高い安全性を与える方法およびネットワーク内のコンピュータに対して高い安全性を付与することができる方法をコンピュータに対して実行させるコンピュータ実行可能なプログラムを提供することにある。
【課題を解決するための手段】
【００１５】
信頼性あるブートストラップ
例として、PCプラットホームが起動に伴ってブートストラップを行う場合、ＢＩＯＳ（ＣＲＴＭとして参照する。）の書き込み保護された部分は、ＢＩＯＳイメージの一致性（一致性）（イメージのＳＨＡ１ハッシュ値）を”測定”し、ＰＣＲ内にこれらの値が書き込まれる。ＢＩＯＳは、ＯＳブート・ローダをメモリ内にロードし、同時に、ブート・ローダの一致性を検査し、ＰＣＲへと格納する。ＯＳブート・ローダは、ＯＳカーネルおよびいかなる関連する本質的ファイルをロードし、それらの検査し、ＰＣＲへと検査された値を格納させる。その後、Ｏ／Ｓは、そのブートプロセスを開始させる。ＰＣＲ値は、一度書き込まれると、任意の値へと値を変更することが不可能であり、このためこれらの値は、装置の一致性を与える優れた指標を与える。
【００１６】
このため、信頼性を与える次のような連鎖を与える：ＣＲＴＭは、工場においてインストールされ、置き換えることができないので、ＣＲＴＭが信頼できる：ＢＩＯＳイメージは、そのPCR値が、期待されるように、信頼性のあるＣＲＴＭの検査によりアップデートされた物である場合には、信頼することができる：ＯＳブート・ローダは、そのPCR値が、期待されるように、信頼されるＢＩＯＳにより検査されアップデートされたことを示す場合には、信頼することができる。ＯＳカーネルはおよび随伴するファイルは、そのPCR値が信頼されるＯＳブート・ローダにより検査されアップデートされた場合に、信頼される。
【００１７】
これらのＰＣＲ値は、リモート・ベリファイアにより問い合わされる（または参照される）。このＰＣＲ値は、TPM内に安全に格納されかつ実行される検査一致性鍵（以後、単にＡＩＫとして参照する。）によりディジタル署名され、リモート・ベリファイアが報告された値を信頼することができる。ベリファイアは、これらの値を、知られた信頼性のある構成値と比較する。これらの値が一致する場合には、ベリファイアは、知られたセキュリティ・ポリシーで純正のトラステッド・ドメイン・モデル（ＴＤＭ）プラットホームと対話する。
【００１８】
これは、プラットホームの一致性を元にきわめて柔軟な信頼関係を可能にする。例えば、セキュリティの脆弱性が見出され、モバイル・デバイスのオペレーティング・システムが修正されたものとする。このデバイスへアプリケーションとデータとを送ろうとするリモート・ベリファイアは、信頼性のあるＰＣＲ値のデータベースをアップデートする必要があるだけである。または、より現実的な解は、信頼された第三者（認証エンティティ）に対して、データベースを保持するように依頼することである。サービス・プロバイダは、リスクを考慮して、脆弱性が重大ではない場合には、パッチが当てられていないプラットホームに対しても信頼性を与えることさえできる。異なったサービス・プロバイダは、異なったプラットホーム・ポリシーをもって信頼性を与えることができる。バンク・アプリケーションは、きわめて制限的なアクセス制御ポリシーを必要とするが、ネットワーク・ゲーム・アプリケーションは、より厳密ではないポリシーで信頼性を与えることができる。サービスは、ＰＣＲ値を問い合わせることにより、有効な正確なポリシーを知ることができる。
【００１９】
このアーキテクチャは、本発明による新規なトラステッド・ドメイン・モデル（ＴＤＭ）を実装するため、利用できるハードウェアおよびソフトウェアおよび他の要素に依存する多くの方法があるために、抽象的なものとして説明する。
【発明を実施するための最良の形態】
【００２０】
１．概説
本発明は、２００１年１月に発行されたオープン・インダストリー規格であるTCPA１．１（現在では、TCPAは、その承継機関であるトラステッド・コンピューティング・グループ（TCG）として認識されている。）により与えられるアーキテクチャを使用する。TCPA／TCGは、組み込みセキュリティ・チップ（トラステッド・プラットホーム・モジュールすなわちTPMとして参照される。）を規定し、TPMは、ソフトウェア一致性の追跡を維持するレジスタ：プラットホーム・コンフィグレーション・レジスタ；PCRに加え公開鍵暗号鍵を保持している。トラステッド・ドメイン・モデルは、TCPA／TCGにより与えられる信頼性のあるブートおよびプラットホーム検査能力と、SELinuxにより有効化される統合アクセス制御ポリシーとを必要とする（非特許文献３、非特許文献４、非特許文献５、非特許文献６、非特許文献７、非特許文献８、非特許文献９）。後述する説明においては、同様の機能部には、同一の数字が付されている。TPMを簡単に説明すると、AIK（より詳細には後述する。）の値自体は、プラットホームの一致性を正当化するのではなく、プラットホームの一致性およびPCRがTPMモジュールに由来するものであることを証明する。AIKに対する認証は、AIKがTPMモジュール内に含まれていることを証明する。したがって、特定の用途に応じて、一致性の値は、一致性自体の確認の後、AIKによる証明を発行するために使用される。本発明においては、特定の実装形態について説明するが、本発明は説明する実施の形態に限定されることはなく、AIK、TPM、CRTMアーキテクチャを含むいかなる特定の装置実装形態においても実装することができる。
【００２１】
１−１．トラステッド・ドメイン・モデル（TDM）
図１には、ネットワーク・システム１０の例示的な実施の形態を示す。このネットワーク・システムは、LAN、WAN、および／またはインターネットといった適切なネットワーク基盤１４サーバ装置（以下、単にサーバとして参照する。）１２を含んでいる。クライアント装置（以下、単にクライアントとして参照する。）１６は、また、ネットワーク基盤１４に接続されていて、クライアントは、サーバ１２へとサービスを要求し、サーバ１２からその応答を受け取ることができる。クライアントとしては、例えば、ワイヤレス通信またはＩＲ通信によりネットワーク基盤１４に接続されるＰＤＡ、またはノートブック型のパーソナル・コンピュータおよび携帯電話を挙げることができる。記憶装置１８は、サーバ１２へと接続されていて、信頼性のあるプロトコルの下でオンデマンドにサービスを提供している。後述する説明においては、サーバ１２が本発明のトラステッド・プラットホーム・アーキテクチャとして構成されており、かつクライアントは、これまで知られたいかなるアーキテクチャ・タイプとすることができる。しかしながら、これに制限されることはなく、クライアントを、また、トラステッド・プラットホーム・アーキテクチャとして構成することもできる。サーバ１２がクライアント１６からのリクエストを受け取ると、サーバ１２は、サーバ１２に格納されたアプリケーションのサービスのため、クライアントに対応するもう一つのドメインを生成する。
【００２２】
１−２．プラットホーム・アーキテクチャ（クライアントおよびサーバ）
図２は、本発明によるクライアント１６の典型的なハードウェア構成を示した図である。クライアント１６は、有線またはワイヤレス接続により、ネットワーク１４へと接続することができ、通信デバイス２２と、中央処理装置（CPU）２４と、メモリ（ROMまたはRAM）２６と、ハードディスク・ユニット２８とを含んでいる。
【００２３】
ハードディスク・ユニット２８は、ブート・コード、オペレーティング・システムおよびアプリケーション・ファイルなどを含んでいる。また、ソフトウェア・モジュールおよびCRTM（BIOS)は、フラッシュメモリなど、適切なメモリ内に格納されており、RAMまたはROMなどへと、リクエストに応じてバスライン３２を通じて読み込まれて、ユーザに通常の機能を提供させている。クライアント１６は、署名された一致性チェッカ３０を含んでおり、一致性チェッカ３０は、ディジタル署名と共に署名されたＰＣＲ値を受け取る。署名された一致性チェッカ３０の機能は、下記のようにまとめることができる。
参照されたPCR値は、署名された時点でのプラットホームのソフトウェア構成を示す。クライアント１６のいずれかに以前に格納されたものとの比較により、PCR値に関連していかなる疑問がある場合には（例えば、署名がなされた時点でウイルスが活性化していた場合など。）、署名された一致性チェッカ３０は、署名に伴われたPCR値が、特定のプラットホーム構成における知られた脆弱性であるか否かを判断する（BIOSおよびOS修正、構成ファイル、アンチウィルス定義ファイルなど）。格納されたPCR値と最近に受け取ったPCR値との間に正しい対応が見出されない場合には、クライアント１６は、サーバとの間のトランザクションを停止させる。
【００２４】
図３は、トラステッド・ドメイン・サービスを提供するために構成されたサーバ１２の典型的な構成を示した図である。サーバ１２は、ルート・トラスト部３４を含んで構成されている。ルート・トラスト部３４は、さらに、TPM３６と、スタートまたはリセットのＰＣＲ値を格納するレジスタ・アレイ３８と、ＣＲＴＭとを含んでいる。TPM３６およびレジスタ・アレイ３８は、ＡＩＫにより署名された一致性通知（quote)を生成させるための本質的部分であり、これについては後述する。クライアントからのサービスに対する検査リクエストを受け取ると、ルート・トラスト部３４は、クライアントに対してＡＩＫにより署名されたＰＣＲｓを送り、安全なドメイン・アクセスを提供する。
【００２５】
２．トラステッド・ドメイン機能
２−１．プロトコル概要
図４は、サーバ１２に形成されるトラステッド・ドメインの概略構成を示した図である。サーバ１２は、強制アクセス制御ポリシーでの安全なドメイン・サービスのため、TCPA／TCGシステム４０に基づいている。サーバ空間内に形成されるドメインは、管理ドメイン、アプリケーション・ドメインおよびユーザ・ドメインといったドメインである。管理ドメイン４２は、システム管理者４４によりアクセスされて、ルート・トラスト部（図示せず）と共に、トラステッド・ドメイン・サービスを管理している。アプリケーション・ドメイン１（４６）、アプリケーション・ドメイン２（４８）およびモバイル・ユーザ・ドメイン５０は、クライアントに通信された証明の認証の後に生成され、クライアントに対してトラステッド・ドメイン環境を享受することを可能とさせている。ドメインはそれぞれ、適切な記憶装置５２に格納された秘密データおよび／またはポリシーを伴っていて、ユーザのプライバシー・ポリシーを保護している。サーバは、安全なオペレーティング・システム（しばしば、トラステッド・コンピューティング・ベース、すなわちTCBとして参照される。）により制御されているので、システム全般にわたる強制アクセス制御ポリシーの適応を向上させている。各ドメインは、それ自体個別的なアクセス制御ポリシーを有している。
【００２６】
TCBは、信頼性を有し、かつ完全に認証されている必要があるが、ＴＣＢにおいてまったく脆弱性が見出されないと仮定することは現実的ではない。本発明は、いかなるセキュリティ上の問題がある場合にでもＴＣＢをアップデートする方法を提供する。これは、必要に応じてＴＣＢを変更することができる管理者エンティティが存在することを意味する。これは、サーバまたはクライアント（必要に応じて）が、ＴＣＢをアップデートする新規な機能を有することを必要とするが、この管理者エンティティの機構は、すべてのセキュリティ上の仮定を壊してしまうのできわめて慎重に取り扱うことなる。
【００２７】
上述した目的に対応するために、本発明では、管理ドメイン４２として参照される特別のドメインを導入する。この管理ドメイン４２は、（１）クライアントからの要求に応じてアプリケーション・ドメインの生成および消去を可能とし、（２）強制アクセス制御ポリシーを含むＴＣＢのアップデートを可能とする。管理ドメインは、強制アクセス制御ポリシーの変更を可能とされているので、管理ドメインの悪意ある所有者が強制アクセス制御ポリシーを迂回してしまうことを防止する必要がある。このような攻撃を防止するため、その時点で実行されているドメイン・インスタンスは、そのすべての実行ステータスが、強制アクセス制御ポリシーが変更される前に暗号化された形式で第２の記憶装置５４へと保存される。変更の後、プラットホーム全体がリセットされる。サーバのリブート後、PCRは、TCBの新たな構成を反映した新たな値を含んでいる。それぞれのドメイン所有者は、ドメインのインスタンス化を実行させて、新たなシステム構成が信頼できるものであるか否かを確認する。信頼できる場合にだけ、ドメイン所有者は、ドメイン・シークレットの使用に対する権限が与えられる。
【００２８】
管理ドメイン４２は、（１）TCBが信頼できる状態ではない場合（例えば、ドメイン・インスタンスが実行されていない場合または電力が切断されている場合）に、ドメイン・シークレットが後述するセクションで説明するように、TCPAにより保護されていること、および（２）ＴＣＢがリカバリの後に信頼できる状態とされ、ドメイン・インスタンスが実行されて強制アクセス制御ポリシーにより保護されている場合には、いかなる時点でも他のドメインのドメイン・シークレットにアクセスすることができないことに留意するべきである。管理ドメインは、別のドメインの私的データには、ドメイン所有者による特別の許可がなければアクセスすることができない。この点では、管理ドメインは、Unix（登録商標）のスーパー・ユーザとは異なるものである。
【００２９】
本発明のサーバは、複数のアプリケーションの実行ホストとされる。各アプリケーションは、プラットホームの保護された実行環境下、すなわちドメインで実行されている。本明細書においては、ドメインは、そのドメイン所有者に帰属されるものと仮定する。ドメイン所有者は、ドメインのセキュリティ・ポリシーを決定するリモート・クライアントである。グリッド・コンピューティングでは、ドメイン所有者は、グリッド・コンピューティング・サービスのユーザとなる。複数のアプリケーションが実行されているモバイル・プラットホームの場合には、ドメイン所有者は、クライアントおよび／またはモバイル・プラットホームまたはクライアントにアプリケーションおよびデータを送るリモート・サービス・プロバイダ（例えばｅ−チケット・サービス）となる。
【００３０】
本発明の管理機能では、非システムプログラムごとにドメイン内において実行される。ドメインは、サーバ、すなわちプラットホーム上の他のドメインから、データおよび実行を保護する。クライアント（ドメイン所有者）がそのドメインがそのリソースのいくつかを他のドメインと共用することができることを決定する場合には、適切なアクセス制御ポリシーを設定することにより、クライアントが制御することができる。
【００３１】
本発明においては、２つのレベルのアクセス制御ポリシーが、実装される。すなわち、
（１）サーバ８プラットホーム）のすべてのドメインにわたってシステム上の運用を行う、強制アクセス制御ポリシー、および
（２）各ドメイン所有者、すなわちクライアントにより制御される任意アクセス制御ポリシーである。
【００３２】
強制アクセス制御ポリシーは、ドメインにおいて実行されているアプリケーションがセキュリティの脆弱性を有している場合であっても、重要なリソース（暗号鍵など）を強力に保護する。他方では、任意アクセス制御ポリシーは、所望に応じたアプリケーション間のデータの柔軟な交換を可能とする。
【００３３】
２レベルのアクセス制御にしたがい、ドメインは、２種類の保護データを有する。ドメイン・シークレットは、TPMのハードウェアにより保護され、強制アクセス制御ポリシーによる保護の対象とされるデータである。暗号鍵は、ハードディスク・ドライブのドメイン・データを暗号化するために使用され、ドメイン・シークレットの例である。他方、ドメイン私有データは、個別ポリシーの対象とされ、ドメインの任意アクセス制御ポリシーが許可する場合には、他のアプリケーションにより共用することができる。モバイル・デバイスの場合には、ユーザのアドレス・ブックは、多数のアプリケーションにより共用されるドメイン・プライベート・データとなる。
【００３４】
クライアントのタイプに依存し、異なるタイプのドメインが存在する。通常のアプリケーションは、アプリケーション・サービス・プロバイダにより提供され、アプリケーション・ドメイン内において実行される。管理ドメイン４２は、管理タスクを実行させる本質的な部分である。すべての他のドメインは、ドメイン所有者により所有される。ユーザが所有するすべてのデータおよびプログラムは、ユーザ・ドメイン内に置かれ、プライベート・データを保証している。
【００３５】
管理ドメインは、クライアントすなわちドメイン・ユーザからの要求を受け取るとドメインの生成および削除を実行する。図５は、クライアントとサーバの間においてクライアントに対する新たなドメインが生成されるまでの処理を示した図である。図５に示されるように、ステップＳ５００においてクライアントは、サーバへと認証要求を送る。ステップＳ５１０において、サーバはこのリクエストを受け取り、サーバは、クライアントへと検証（ＴＣＧ検証）の結果を署名付き一致性値として送る。
【００３６】
ステップＳ５２０では、クライアントは、署名付き一致性値を受け取り、検証の結果が署名および／またはＰＣＲ値に依存して許容されるか否かを決定する。検証の結果がネガティブである場合には、ステップＳ５３０において、さらなるトランザクションが停止される。検証の結果がポジティブである場合には、処理は、ステップＳ５４０へと進み、クライアントは、サーバへとドメイン生成のためのリクエストを送る（以下、説明の便宜のため、ｃ−リクエストとして参照する）。サーバがｃ−リクエストを受け取ると、サーバは、対応するクライアントのための新規なドメインを生成すると共に、ステップＳ５５０において固有のドメインｉｄを割り当て、ｃ−リクエストを送ったクライアントが新規なドメインを排他的に支配できるようにさせる。
【００３７】
図６は、クライアントに対してドメインを認証させ、割り当てるために使用される例示的なデータ構造を示す。図６に示されるデータ構造は、例えば、図４に示した認証リスト内に格納させておくことができるが、これに限られるものではなく、このデータ構造は、サーバのドメインの割り当てを制御するために、クライアント１６内のいずれかに格納させておくことができる。サーバが、クライアントからリクエストを受け取ると、サーバは、クライアントに対して、一致性値と共にAIK(秘密鍵)による署名をクライアントに送る。AIKの公開鍵部分は信頼される第３者により署名され、認証された証明は、サーバ内のいずれかに予め格納されているか、または、遠隔した第３者から得ることもできる。
【００３８】
図６に示す表は、サーバｉｄと、証明値と、PCR値とドメインｉｄとが行としてリストされている。PCR値は、本発明における証明のために本質的な一致性を示す値であり、サーバといったプラットホームの構成により固有的に決定される。このように構成により固有に決定される一致性の値（PCR）は、単一の値として使用することもできるし、一致性の値のセットとして使用することもできる。PCR値の生成の詳細については、より詳細に後述する。クライアント１６は、図６に示したアロケーション・テーブルにしたがい、トラステッド・ドメイン・サービスを享受することができる。
【００３９】
図７は、一致性値（PCR）を生成するための処理を示した図である。図７において、TPM、CPUにおける処理および格納されたコードの呼び出し処理を説明している。サーバがスタート、またはリセットされた場合、TPM内のPCRレジスタは、ステップＳ７１０においてクリアされる。ステップＳ７２０において、サーバは、CRTMコード（BIOS）を他のメモリへと、ROMまたはフラッシュメモリから呼び出し、CRTMコードを実行させ、ステップＳ７４０でCRTMコードのハッシュ値をPCRレジスタのいずれかに格納させ、さらにステップＳ７３０において次の実行コードを呼び出す。ステップＳ７３０において次のコードを呼び出す前に、計算されたPCR値は、ステップＳ７５０においてさらに他のレジスタへと格納される。PCR値は、ステップＳ７６０〜Ｓ７９０において説明するように、セットアップ処理における必要なコードのすべてが完了するまで拡張されてゆく。
【００４０】
PCRの値は、初期セットアップのコードの一致性を示し、書き込まれたPCR値は、サーバがシャットダウンまたはリセットの後、再度起動されるまで、他の任意の値に変更することができない。このため、PCR値は、サーバの一致性を確証する。本発明が、クライアント装置に適用された場合、同一の検査処理がクライアント内で進行し、ネットワーク内のセキュリティは、より向上される。これらの実施の形態においては、クライアントは、クライアント構成に適合するTPMモジュールまたはチップを含んでいる。
【００４１】
図８は、サーバおよびクライアント（クライアントがそのように実装されている場合）が、クライアントへとトラステッド・ドメイン・アクセスを可能とするTPMの機能を示す。TPMは、TPM_CreateEndosementKeyPair、TPM_MakeIdentityおよびTPM_Quoteを実行する。TPM_CreateEndosementKeyPairは、テップＳ８１０において、私有鍵および公開鍵とを使用する知られた技術に基づいてエンドーズメント鍵を生成する。エンドーズメント鍵が生成されると、責任ある製造者のディジタル署名が、ステップＳ８２０においてエンドーズメント鍵に付される。このエンドーズメント鍵は、TPMの信頼性を保証する。また、一致性値であるPCRのためのディジタル署名を与えるために使用されるAIKは、ステップＳ８３０において、TPM_MakeIdentity処理で生成され、AIKは、また、私有鍵と公開鍵とを含んでいる。AIK公開鍵は信頼できる第３者により証明され、このAIK証明書とともに、AIKは、ステップS８４０でPCRｓに付されるディジタル署名として使用される。
【００４２】
コードTPM_Quoteは、図５に示した遠隔したクライアントへと送付される署名付き一致性値（TCG検証）を生成する。TPM_Quoteは、ステップＳ８６０において、PCRｓから呼び出しを実行し、AIKによる、署名付きPCRｓを生成する。コードTPM_Quoteは、ついで図８に示すように、リクエストされたように署名付きPCRｓを遠隔したクライアントへとネットワークを通して送り、クライアントがPCR検査処理を実行することができるようにさせる。
【００４３】
２−２．一致性の検査を伴う署名
上述したように、一致性の検査の結果は、TPM内のPCRｓに格納され、quote機能により報告される。実際に、Quote機能のこのような使用は、サーバーに対する使用に限定するものではない。プラットホームの一致性尺度の使用の１つの方法は、ディジタル署名中にこの尺度を含ませることである。上記機能をプラットホームに実装するために、本発明者らは、PCR値へと署名を付する機能を含む、ＸＭＬ署名機能のための署名アルゴリズムを採用した。
【００４４】
２−３．署名機能部（署名アルゴリズムの実行により実装される）
本発明者らは、新規な署名アルゴリズムを、その時点でのPCR値(quoteInfo)を示す構造とその構造への署名値との連結(concatenation)として、下記のように規定した。
SignatureValue = quoteInfo | SignatureOnQuoteInfo
ここで、署名値の第１の部分(qoteInfo)は、TCPA_QUOTE_INFOにより規定される４８バイトデータ・オブジェクトであり、下記のように規定される。
typedef struct tdTCPA_QUOTE_INFO{
TCPA_VERSION version;
BYTE fixed;
TCPA_COMPOSITE_HASH digestValue;
TCPA_NONCE externalData,
} TCPA_QUOTE_INFO;
上記コード中、versionは、ＴＣＰＡのバージョンを意味し、TCPA1.1bのセクション４．５において規定されている。特に、第１の２つのオクテットは、0x01および0x01とされる。“fixed”は、常にASCIIストリングの“Quote”である。“digestValue”は、要求されたPCR指標の現在値を使用する複合hashアルゴリズムの結果である。“externalData”は、＜SignedInfo＞のカノニカル化の２０バイト（オクテット）ストリームのSHA-1hashである。
【００４５】
署名値の第２の部分は、TCPA_QOATE_INFOデータ構造上のRSASSA-PKCS1-v1.5署名値である。この部分は、検査鍵が少なくとも２０４８ビットを有するので、少なくとも２５６バイト長である。
【００４６】
２−４．証明アルゴリズム
説明する特定の実施の形態では、TCPAによるPCR値のXML署名の証明アプリケーションには、ベース６４デコードされた＜SingatureValue＞を２つの部分へと分ける必要が生じる。第１の部分は、オクテット・ストリングの第１の４８バイトであり、第２の部分は、その残りである。証明アプリケーションは、下記の事項を証明する。
【００４７】
第１の部分は、正規なTCPA_QUOTE_INFOの構造である。これは、バージョン・フィールドの第１の２つのオクテットが0x01および0x01でなければならず、かつ固定されたフィールドがASCIIの“QUOTE”でなければならないことを意味する。
【００４８】
第１の部分のexternalDataは、カノニカル化された＜SingalInfo＞のSHA-1hash値である。
【００４９】
第２の部分は、所与の公開鍵にしたがった第１の部分のRSASSA-PKCS1-v1.5署名となる。
【００５０】
証明アプリケーションは、その後、TCPA_QUATE_INFO構造内のPCR値（digestValueフィールド)を、知られた信頼性値に対して証明する。この値が信頼できると判断された場合には、サーバは、信頼すべきプラットホームと通信していると、結論することができる。それ以外には、サーバは、ポリシーにしたがって、要求を排除する。
【００５１】
２−５．JCEにおけるPCR付き署名の実装
本発明においては、上述の署名処理が新規な署名アルゴリズム（SHA1withRSATcpaとして参照する）としてJava（登録商標）暗号環境（JCE）プロバイダ（サーバ）に実装された。この方法では、アプリケーションは、PCR値と共に署名を使用するべく変更する必要はない。
【００５２】
３．ドメイン・インスタンスの生成および削除
図９は、クライアントからのリクエストを受け取った場合に新規なドメインの生成を示した図である。サーバが、リクエストを受け取ると、サーバの認証部または通信部といった適切な部分は、リクエストを解析してAIK証明書および署名付きPCRを取得する。認証部は、認証リストまたはテーブルをルックアップして、受け取ったリクエストがサーバへのアクセスを許可されるかを判断する。サーバは、ルックアップの結果を含むレスポンス・パケットを返す。ついで、クライアントは、図５のステップＳ５３０の認証に依存して、新規ドメイン生成のためのｃ−リクエストを送り、図９に示すように、クライアントのためのアプリケーション・ドメイン１（４６）といった、排他的な新規ドメインを生成する。
【００５３】
クライアントがサーバ上に新規なドメイン・インスタンスを生成する場合には、プラットホームが依然として信頼できることを確認することが重要である。この信頼性は、トラスト層から得られ、このトラスト層は、プラットホームの同一性および一致性の認証を与える。図５に示されるように、クライアントはまず、ドメインのインスタンス化前に、図５に示すTCG検査の結果と共に送信されるPCR値を使用してサーバの同一性と一致性とを認証する。クライアントがソフトウェア・スタックのバージョンおよび強制アクセス制御ポリシーの内容に満足するまで、クライアントは、それ以上処理を進ませない。
【００５４】
このドメイン・インスタンス化プロトコルは、また、相互認証プロトコルであり、プラットホームは、ドメイン所有者の同一性を認証することができる。いかなる信頼性あるプラットホームであっても、所有者の同一性が認証される前にはドメイン・シークレットの使用権限を与えられない。一度、ドメイン所有者が同一性および一致性に満足し、プラットホームがクライアントの同一性に満足すると、クライアントは、通常、認証プロトコル（オブジェクト特有の認証プロトコル、またはオブジェクトと独立した認証プロトコル）のうちの１つを実行し、クライアントによる、暗号化鍵（ルート鍵）を含むドメイン・シークレットの使用が可能となる。ドメインが、第２の記憶装置に格納された持続性データを有する場合、プラットホームのTCBは、この暗号化鍵を使用して暗号化された外部データをインポートする。
【００５５】
ドメイン・インスタンスにおけるプログラムの実行が終了した後、ドメイン・インスタンスは、図５に示すように消去される。ここで、メモリ内容およびシステム上の一時ファイルのすべてが消去される。
【００５６】
図１０は、クライアントとサーバとの間で新規ドメインをインスタンス化させるための処理を示す。図１０に示す処理は、ステップＳ１０１０およびステップＳ１０２０においてクライアントとサーバとの間の認証プロトコルが完了する。認証プロトコルが成功裏に完了する場合には、次に、クライアントは、ステップＳ１０３０において、TCG／OIAPプロトコルでサーバへと、ドメイン・スタート・リクエスト（ｃ−リクエスト）を送信する。サーバは、ｃ−リクエストを受け取り、ステップＳ１０４０においてクライアントのために新規なイネーブル・ドメインを生成する。その後、ステップＳ１０５０において、ドメイン・インスタンスが生成される。
インスタンス化されたドメインおよびクライアントは、ステップＳ１０６０において、登録されたジョブおよび対応する結果のトランザクションを通信する。クライアントがその目的とする結果を取得した場合には、クライアントは、ステップＳ１０７０において、TCG／OIAPによりサーバへとドメイン離脱リクエストを送信する。サーバは、ステップＳ１０８０においてドメイン離脱リクエストを受け取り、対応するドメインの終了を指令する。サーバは、さらに、クライアントに対して、ドメイン閉鎖の通知を送り、本発明のプロトコルを完了させる。
【００５７】
ドメイン・インスタンスが存在しなくなると、持続性記憶装置に格納されたドメインの私有データはすべて、ドメイン鍵により暗号化される。したがって、ドメイン・インスタンスが存在しない場合には、ドメインの私有データには、何人もアクセスすることができない。ドメイン・インスタンスが存在する場合には、システムは、ドメイン所有者は、インスタンス化の時点でTCBの一致性がチェックされているので、システムは安全である。したがって、ドメイン所有者は、TCBによりドメイン私有データが適切に保護されていることがわかる。
【００５８】
４．ＴＣＧ保護記憶階層でのドメイン・シークレットの保護
図１１は、各ドメインの本質的なデータ保護を示した図である。プラットホームがシャットダウンされた場合や信頼性のある状態ではない場合、ドメイン・シークレットは、安全に保護される必要がある。これは、TCG保護記憶階層を使用して行われる。図１１に示すように、TCGの保護する対象は、木構造として組織化されている。ルート・ノードは、記憶ルート鍵（SRK）として参照され、TPM内に持続的に格納された唯一の鍵である。TPMは、廉価なデバイスとして構成され、かつ制限された内部メモリを有しており、他のすべての鍵は、使用されない場合にはそれらの親鍵により暗号化されてTPMの外に保持されている。鍵を使用する場合には、それらの親鍵のすべては、TPM内にすでに読み込まれていなければならない。本発明においては、各ドメインは、SRKの下の副木に割り当てられている。この副木は、ドメインのドメイン・シークレットを保持している。このことは、ドメイン・シークレットがTPMへと副木がロードされるために副木のルート鍵が使用できない限り、使用できないことを意味する。
【００５９】
各鍵には、その認証のためのシークレットが伴われており、これは、１６０ビットのデータである。TPMは、鍵が使用される場合に、このシークレットの所有証明を必要とする。本発明の実施の形態では、ドメイン所有者がプラットホームにログインする場合には、ドメイン所有者は、それらの鍵の認証シークレットを知っていることを証明する。TCGのオブジェクト特定認証プロトコル（OSAP）を使用して、TCBに対してもシークレットを開示すること無く、これが達成される。
【００６０】
図１２は、本発明によるドメイン・シークレット・データの保護の処理を示す。保護処理は、まず、ステップＳ１２１０〜Ｓ１２４０において新規なドメインを生成させる。その後、ステップＳ１２５０へと進んで、認証処理の完了の後ルート鍵を取得する。許可されたドメインでは、生成されたドメインに必要な暗号化された形式でのシークレット・データは、ドメインへと適切な記憶領域から呼び出され、ステップＳ１２６０においてルート鍵による復号後、要求されたジョブへと提供される。復号されたシークレット・データ必要に応じて、再度、予め規定された処理により、暗号化され、ステップＳ１２７０において管理ドメインにより管理される適切な記憶領域に格納され、その後、ドメインのインスタンスが削除されて、クライアントとサーバとの間のトランザクションが、ステップＳ１２８０〜Ｓ１２９０において完了する。
【００６１】
５．ドメイン分離の改善
ドメイン分離およびアクセス制御ポリシーを向上させることは、実際の実装においては多くの異なる方法において実現することができる。例えば、Unix（登録商標）アクセス制御およびJava（登録商標）のJAASは、あるレベルの保護を提供するソフトウェア・ベースの技術である。WebSphereといったミドルウェアは、アプリケーションレベルにおける付加的な分離を提供する。しかしながら、アプリケーションがより強力な保護を必要とする場合には、我々は、より強力なドメイン分離機構を必要とする。これは、COTS（Commercially Off-The-Shelf)ソフトウェアとして知られているオペレーティング・システムおよびミドルウェアは、専門家による注意深い検査の後にも多くのセキュリティ・バグを有している傾向にあることが知られている。この問題に対応するために、２つのアプローチが存在するものと考えられる。
【００６２】
１つは、きわめて小さな、かつ完全に検査され信頼性のあるソフトウェアを組み合わせたハードウェア・サポートを使用することである。例えば、最新のハイエンド・プロセッサは、本来のカーネル・モードよりも高い、付加的な特権レベルを有している。信頼性のあるマイクロ・カーネルまたはこのモードにおいて実行されるハイパーバイザは、ドメイン間におけるきわめて安全な分離を提供することができる。このようなハイパーバイザは、最小のコードのみを含み、したがって、残された脆弱性もより少ない。
【００６３】
６．実装の変更例
これ以外のアプローチは、良好な技術および証明（Common Criteria Certification)を使用するか、またはオペレーティング・システムのカーネルにさらなる保護を追加するかにより、既存のオペレーティング・システムを頑健化することである。トラステッド・ドメイン・モデルのアーキテクチャは、要求されたセキュリティ・レベルに応じて上述したアプローチのいずれも可能とする。
【００６４】
本発明のトラステッド・ドメイン・アーキテクチャは、既存の技術に適切に実装することができる。このセクションでは、本発明者らは、TPMチップおよびLinuxセキュリティ・モジュールを含むPCに基づく構成を示す。この実装例の全体の構成を、図１２に示す。
【００６５】
６−１．ブート・ローダにおけるLinuxカーネルの検査
IBM（登録商標）社のTCPAイネーブル・システムは、現在、BIOSの変更できない部分(CRTM)は、残りのBIOSを測定し、BIOSはまた、ブートストラップされるデバイス（通常では、ハードディスク・ドライブ）のMBR（マスタ・ブート・レコード）の基準となる点で、基準ブートストラップをサポートしている。しかしながら、我々が知っている市販のオペレーティング・システムにおいては、さらなる基準は、まったく採用されていない。
【００６６】
ＢＩＯＳは、オペレーティング・システムの一致性を検査するために、直接オペレーティング・システムをロードしないので、BIOSがTCPAのPC特有のインプリメンテーション規格にしたがった役割を担わなければならない。この代わりに、ＢＩＯＳは、ブート・ローダの一部（ＭＢＲに存在する）をメモリにロードし、その制御をロードされたコードへと渡す。ブート・ローダが適切にオペレーティング・システムの一致性を検査するために、ブート・ローダは、下記の要求を満足する必要がある。
（１）ブート・ローダが多重のステージを有する場合、実行されているステージは、次のステージを検査することができなければならず、かつ制御をO／S渡す前に、PCR値に検査結果を記録することができなければならない。
（２）ブート・ローダは、O／Sに制御を渡す前に、O／Sイメージおよびすべてのセキュリティ上重要な構成ファイルを検査することが可能でなければならない。これには、ブート・ローダは、これらのファイルが格納されるファイル・システムを少なくとも一部に実装することが必要とされる。
【００６７】
PCのためのUnix（登録商標）のようなオペレーティング・システムに対しては、GPLライセンスの下で、例えばLILO（LInux LOader)、GRUB(GRand Unified Bootloader)およびXOSL(Extended Operating System Loader)といった、いくつかのブート・ローダが現在では利用できる。説明する実施の形態では、広く使用されており、かつ変更するに適していて変更されたブート・ローダが上述した規格を満足するので、我々のトラステッド・ブート・ローダのプロトタイプとしてGRUBを採用した。
【００６８】
６−２．GRUBにおけるブート・シーケンス
図１３は、GRUBのブート・シーケンスの詳細を、多重のステージ、すなわち、ステージ１、ステージ１．５、ステージ２に分割して示した図である（図１３（ａ））。これは、現在のPCアーキテクチャのディスク空間のサイズが制限されているためである。ステージ１コードは、４４６バイト長のMBRに適合するように設計した。ステージ１．５は、ファイル・システムの実装を含み、著しく大きく（概ね、１０ＫＢである）、通常使用されていない空間であるMBRの直後のセクタに配置されている。ステージ１．５は、ファイル・システム内のいずれかに配置されるステージ２コードおよびＧＲＵＢ設定ファイルにアクセスする。
【００６９】
ＢＩＯＳは、ステージ１（MBR）データを、ハードディスク・ドライブからメモリへと読み込み、ステージ１のスタート・ポイントへとジャンプする。ステージ１は、まず、ステージ１．５の最初のセクタをロードし、ステージ１．５へとジャンプする。このステージ１．５は、さらにステージ１．５の残りのセクタをメモリへとロードし、それにジャンプする。ここで、ステージ１．５は、ファイル・システムのインタフェースを含み、ステージ２を見出してメモリにステージ２をロードし、その後ステージ２のスタート・アドレスへとジャンプする。この時点で、GRUBは、構成ファイルをチェックし、O／S選択メニューをユーザに表示する。ユーザがO／Sを選択した後、ＧＲＵＢは、選択されたO／Sイメージをメモリに読み込み、O／Sブート処理を開始する。
【００７０】
６−３．GRUBにおける検査ステップ
図１３には、また、ＧＲＵＢにおける検査ステップのためのコードを示す（図１３（ｂ））。検査の連鎖はまた、このブートストラップ・シーケンスを反映しなければならない。ステージ１は、ステージ１．５の第１のセクタを検査し、ステージ１．５の第１のブロックは、ステージ１．５の残りを検査する。その後、ステージ１．５は、ステージ２を検査し、これがオペレーティング・システムの最後の検査である。ステージ１と、ステージ１の第１のセクタは、厳密なサイズ制限があるので、これらのステージへの一致性検査コードを挿入することが、本発明における主要な課題である。
【００７１】
ステージ１コードは、MBRからロードされ、ステージ１．５の第１のセクタを検査する必要がある。これは、ロードされたセクタのhashを計算し、TPMのTPM_Extend機能を呼び出すことが必要である。しかしながら、元々のGRUBコードは、すでにMBRに割り当てられた４４６バイトのすべてをすでに使用している。幸いにも、BIOSサービスは、これを行うように呼び出すことができる。依然として、本発明においては、古いドライブフォーマット（LBAモードに対するC．H．Sモード）のサポートを廃棄するように実装することができる。
【００７２】
基本的に、トラステッド・ブートの各ステップは、１）ハードディスク・ドライブからメモリへと次のステージをロードし、２）ロードされたメモリのイメージを検査して、検査された値を使用してPCR値の拡張を行い、３）次のステージのエントリ・ポイントへとジャンプさせることである。
【００７３】
次のステージ、すなわちステージ１．５の第１のセクタは、ステージ１と同一の空間制限があるが、ステージ１とほとんど同様に変更することができる。ステージ１．５の残りの部分は、上述したような空間制限がなく、次のステージであるステージ２の検査能力を追加することは容易である。ステージ２は、いくつかの対象を検査する役割を有する。まず、ステージ２は、GRUBの構成ファイル(grub.conf)を検査する。このファイルは、選択メニューにおいて表示されるブート可能なO／Sイメージを特定するために使用される。第２に、ステージ２は、ブートするべく選択されたO／Sイメージを検査する必要がある。第３に、ステージ２は、また、いかなる他のセキュリティ上重要なファイル（構成ファイル、ライブラリ・ファイルなど）を検査することが必要である。これらの検査を可能とするために、grub.confを、本発明にしたがい下記のように変更した。
（１）“kernel”などのすべてのローディング・コマンドが、自動的にターゲット・イメージを検査し、（２）その問い合わせを行ういかなる特定のファイルについても検査を実行する“measure”コマンドを追加する。これらのステップの間、PCRの８番目のレジスタの値が、ステージ１．５、ステージ２、およびO／Sファイルを検査するために使用された。
【００７４】
６−４．ＯＳカーネルおよび構成の検査
上述した実装において、検査の連鎖処理は、OSカーネル、OS構成ファイルとセキュリティ・ポリシー・ファイルといったセキュリティ上重要なファイルおよびいくつかの実行可能なJava（登録商標）仮想マシンなどをカバーする。しかしながら、膨大な数のファイルを検査した場合、信頼できる構成の可能なPCR値の数が連結され、したがって、信頼できるPCR値のサーバ全体のデータベースが管理できなくなる。これに変わって、OSカーネルを、セキュリティ上重要ではないファイルおよびリソースを少なくして、一致性を保持させるように実装した。ここで、カーネルに対して、Linux SecurityモジュールおよびセキュリティエンハンスドLinux(SELinux）を適用した。適切なSELinuxポリシー・ファイルを使用した場合、LSMとSELinuxの組み合わせは、実行可能なライブラリおよび他のデータ・ファイルといったシステムのいかなる部分に対する望まれない変更に対してより良好な保護を提供する。
【００７５】
ブートストラップ時点で実行される一致性検査は、ブートストラップ後の検査の一致性を保証するものではない。O／Sがシステムのいくつかのプログラムがすでに測定された部分を変更することを可能とする場合、TPMに格納されたPCR値は、もはや正確なステータスを反映しない。したがって、OSレベルにおける不法な変更に対応する強力な保護がきわめて重要である。
【００７６】
６−５．LSM/SELinuxおよびJava（登録商標）における強制アクセス制御
この実施の形態では、トラステッド・ドメイン・モデルの実装は、保護層についてセキュリティエンハンスドオペレーシング・システム、すなわちLinuxセキュリティ・モジュール（LSM）およびSELinuxを選択した。この組み合わせは、従来のUnix（登録商標）アクセス制御よりも基本的に強力なアクセス制御を提供する。図１４は、LSM/SELinuxアーキテクチャに基づいたトラスト・プラットホーム・モデルの実装例を示す。
【００７７】
図１４においては、Linuxセキュリティ・モジュール（LSM）は、汎用目的のアクセス制御を可能とするLinuxカーネル・パッチである。LSMは、カーネルの重要なリソースすべてに対して、アクセス・パッチにフックを配置し、プラグ−インモジュール（ポリシー・モジュールとして参照される）に対して、アクセス制御の決定を行わせる。これは、従来のUnix（登録商標）セキュリティモデルがセキュリティの充分なレベルを提供するために不充分であると考えられているので、Linuxオペレーティング・システムをセキュリティ化する重要なステップである。標準的なUnix（登録商標）の最も大きな制約は、ユーザにより実行されるすべてのプログラムは、ユーザに与えられたすべての権利を承継し（これは、特にユーザがルートである場合に問題である）、不正なソフトウェアからのオペレーティング・システムの保護をきわめて困難にする。
【００７８】
NSAにより開発されたセキュリティ向上Linux(SELinux)は、LSM用のポリシー・モジュールである。これは、強制アクセス制御（MAC)ポリシーを向上させるので、システムにわたるセキュリティ・ポリシーがユーザの不用意な操作、アプリケーション・プログラムのセキュリティ脆弱性、または不正なソフトウェアに関わらず向上できる。
【００７９】
これらの技術を結合し、本発明者らは、システムにわたるセキュリティ・ポリシーを向上させた。ドメインは、ユーザ・アカウントとして実装され、これは、別のユーザ・アカウントおよびルートユーザのもとで実行されるアプリケーションから良好に保護される。ドメイン・インスタンスは、リモートシェルである。リモート所有者が、プラットホーム（すなわち、ドメイン・インスタンスを生成させる）にログインすると、Pluggable Authentication Module (PAM)は、TCPAチップと作用し、暗号化鍵をアンロックする。
【００８０】
また、プラットホームは、取り外し可能な記憶装置を有しており、暗号化されたファイル・システムが必須とされる。サービスにより所有されるすべてのファイルは、TPMに格納されたサーバの鍵により暗号化されるので、ファイルは、所有者のドメインからアクセス可能とされるだけである。
オペレーティング・システムレベルの分離に加えて、実装はまた、Java（登録商標）レベルでのアプリケーション・分離を有している。これは、Java（登録商標）の本来的なアクセス制御機構（JAAS)またはOSGiにより規定される許可およびユーザ管理機構により行われる。
【００８１】
７．別のプロトコル−ＷＳセキュリティ
OASIS-WSセキュリティ標準の最初に規定されるプロトコルを使用することもできる。
【００８２】
WSセキュリティは、ウェブサービスのためのセキュリティ構築ブロックの規格のセットである。これは、通信パーティの間で渡され、かつ第３者（セキュリティ・トークン・サービスとして参照される）により信頼性が与えられる、“security tokens”として表現される“Claim”という汎用的な概念を規定することにより一致性、信頼性、認証およびSOAPメッセージのための認証といったセキュリティ機能といったセキュリティ機能を提供する。
【００８３】
図１５は、ＷＳセキュリティ・アーキテクチャに基づいて構成された本発明の例示的な実施の形態を示す。プラットホームの一致性検査は、セキュリティ・トークンとして、クレーム部６０に実装され、各エンティティ６２、６４、６６に含まれている。クライアントといったリクエスタ６２は、は、本発明にしたがい構成されている。また、ウェブサービス・サイト６は、また、本発明にしたがい構成されている。リクエスタ６２が、ウェブサービスをウェブサービス・サイト６４へと要求すると、署名付き証明を含むトークンが例えばウェブサービス・サイトからセキュリティ・トークン・サービス・サイト６６へと送られる。
【００８４】
セキュリティ・トークン・サービス・サイト６４は、アクセス許可データをウェブサービス・サイト６４へと発行し、ウェブサービス・サイト６４は、リクエスタ６２からのリクエストがトラステッド・ドメイン・サービスにおいて許容されるかを決定する。プラットホーム認証といったプラットホーム証明およびソフトウェア証明（このトークンに含まれた値が信頼できるか）は、またセキュリティ・トークン・サービスにより発行されるセキュリティ・トークンとして表される。これは、本発明の信頼性のあるインフラ構造の頑強なフレームワークを提供する。
【００８５】
【非特許文献１】http://www.microsoft.com/presspass/features/2002/jul02/0724palladiumwp.asp
【非特許文献２】Open Services Gatewayinitiative (OSGi), http://www.osgi.org/
【非特許文献３】Chris Wright, Crispin Cowan, James Morris, Stephen Smalley,Greg Kroah-Hartman, “Linux SecurityModules: General Security Support for the Linux Kernel,” USENIX SecuritySymposium, 2002.
【非特許文献４】Stephen Smalley, ChrisVance, and Wayne Salamon, “Implementing SELinux as a Linux Security Module,” http://www.nsa.gov/selinux/module-abs.html,Dec., 2001.
【非特許文献５】IBM 4758 PCI Cryptographic Coprocessor. http://www.ibm.com/security/cryptocards/
【非特許文献６】Trusted Computing Platform Alliance, TCPA Main Specification v.1.1b, February,2002. http://www.trustedcomputing.org/docs/main%20v1_1b.pdf
【非特許文献７】Trusted ComputingPlatform Alliance, TCPA PC Specific Implementation Specification v1.00,September 2001. http://www.trustedcomputing.org/docs/TCPA_PCSpecificSpecification_v100.pdf
【非特許文献８】David Safford, “Clarifying Misinformation on TCPA”, Oct, 2002, http://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdf
【非特許文献９】David Safford, “ClarifyingMisinformation on TCPA”, Oct, 2002, http://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdf
【００８６】
これまで本発明を図面に示した特定の実施の形態をもって説明してきたが、以下に本発明をまとめて開示する。
（１）ネットワークを通じてサービスを受け取るための情報処理装置であって、前記情報処理装置は、ハードウェア構成を反映する一致性値の少なくとも１つと共にディジタル署名を受け取る通信部と、少なくとも前記一致性値の同一性を検証するためのチェック部とを含み、前記情報処理装置は、前記一致性値の決定に応答して前記ネットワークを通して前記情報処理装置のための排他的ドメインを形成させるリクエストを発行する、情報処理装置。
（２）前記チェック部は、格納されたディジタル署名または格納された値に関連して前記ディジタル署名または一致性値を検査する、（１）に記載の情報処理装置。
（３）前記情報処理装置は、前記ネットワークからサービスを受け取るクライアントである、（１）に記載の情報処理装置。
（４）ネットワークを通してオンデマンドに処理されたデータを提供するため、前記ネットワークに接続されたサーバ装置であって、前記サーバ装置は、
装置信頼性ルートに基づいて信頼性を与え、かつ前記サーバ装置のスタートまたはリセットに際してディジタル署名に付される署名付き一致性値を生成し、前記一致性値が前記サーバ装置の構成の一致性を与える信頼性付与部と、
前記ネットワークからリクエストを受け取り、かつ前記サーバ装置の署名された一致性値および処理されたデータを前記ネットワークへと送出する通信部とを含み、
前記サーバ装置は、新規ドメインを生成し、かつ他のリクエストを受け取ると前記署名された一致性値に応答して前記サーバ装置のリソースへのアクセスを許可するサーバ装置。
（５）前記サーバ装置は、スタートまたはリセットまたはそれら双方に際して管理を開始させ、リソースへのアクセスを可能とするルート鍵へのアクセスを許可する、（４）に記載のサーバ装置。
（６）前記サーバ装置のリソースは、暗号化された形式として格納され、前記サーバ装置は、前記ルート鍵の復号により前記リソースへのアクセスを許可する、（４）に記載のサーバ装置。
（７）前記署名を生成するために、認証付き証明が通信され、前記サーバの格納部には、前記認証付き証明が格納されているか、または前記サーバ装置は、前記認証付き証明を、遠隔エンティティを通じて問い合わせる、（４）に記載のサーバ装置。
（８）情報処理装置をしてネットワークを通じてサーバ装置と通信させるための方法であって、前記方法は、前記情報処理装置に対して、
ハードウェア構成に依存する署名された一致性値を受け取るステップと、前記署名された一致性値の少なくとも１つの同一性を決定するステップと、
前記一致性値の前記決定に応答して前記ネットワークを通じて前記情報処理装置のための排他的ドメインを生成するリクエストを送出させるステップと
を実行させる方法。
（９）前記サーバ装置は、前記署名された一致性値と処理されたデータとを前記ネットワークを通して、前記リクエストを発行した情報処理装置に対して送出する、（８）に記載の方法。
（１０）ネットワークを介してサーバ装置に通信を実行させるための方法であって、前記方法は、前記サーバ装置に対して、
前記サーバ装置が段階的に実行するセットアップのための初期コードをメモリから呼出すステップと、
前記サーバ装置のソフトウェア構成に関連して不変に維持される一致性値を生成し、前記一致性値をレジスタ・アレイに格納させるステップと、
前記サーバ装置の一致性を認証することにより前記一致性値に付すべきディジタル署名を生成するステップと、
前記一致性値に前記生成されたディジタル署名を付するステップと、
前記サーバ装置の認証を証明するために、前記一致性値を前記ディジタル署名と共に送出するステップと
を実行させる方法。
（１１）前記生成ステップは、
前記ソフトウェア構成に関連するハードウェアの一致性値のための私有鍵および認証を検証するための私有鍵を生成するステップと、
前記鍵の認証に応答して前記一致性値に対してディジタル署名を与えるか否かを決定するステップと、
前記検証のための鍵が認証された場合には、前記一致性値に対して前記ディジタル署名を付するステップと
を含む、（１０）に記載の方法。
（１２）前記方法は、さらに、前記検証のための鍵を使用して前記ディジタル署名を生成させるステップを含む、（１１）に記載の方法。
（１３）ネットワークに接続されたサーバ装置に対して、前記ネットワークを通じて処理されたデータをオンデマンドに提供させるための方法であって、前記方法は、前記サーバ装置に対して、
装置一致性に応答する一致性値に基づいて信頼性の付与された管理ドメインを生成するステップと、
認証証明を参照して前記一致性値を認証し、ディジタル署名を付するステップと、
前記サーバ装置のサービスを受け取るために前記ネットワークから前記サーバ装置にアクセスするためのリクエストを受け取るステップと、
ディジタル署名を伴う少なくとも１つの一致性値を通信するステップと、
前記リクエストに対応する排他的ドメインを生成させる他のリクエストを受け取るステップと
を実行させる方法。
（１４）前記管理ドメインは、ルート鍵に対するアクセスを許可するステップを実行して、前記サーバ装置のリソースへのアクセスを制御させる、（１３）に記載の方法。
（１５）前記サーバ装置のリソースは、暗号化された形式で格納され、前記方法は、さらに前記ルート鍵を使用して前記リソースを復号して情報処理装置による前記リソースへのアクセスを許可するステップを含む、（１４）に記載の方法。
（１６）上記（８）または（９）に記載の方法を前記情報処理装置に対して実行させるための装置実行可能なプログラム。
（１７）上記（１０）から（１５）のいずれか１項に記載の方法を前記サーバ装置に実行させるための装置実行可能なプログラム。
【図面の簡単な説明】
【００８７】
【図１】本発明のネットワーク・システムの例示的な実施の形態を示した図。
【００８８】
【図２】本発明のクライアントの典型的なハードウェア構成を示した図。
【００８９】
【図３】トラステッド・ドメイン・サービスを提供するサーバの講師絵の典型的なハードウェア構成を示した図。
【００９０】
【図４】サーバに生成されるトラステッド・ドメインの概略的な構成を示した図。
【００９１】
【図５】新規なドメインがクライアントへと生成されるまでのクライアントとサーバとの間の処理を示した図。
【００９２】
【図６】認証とクライアントへのドメインの割り当てについて使用される差例示的なデータ構造を示した図。
【００９３】
【図７】ハードウェアの一致性に固有の一致性値を生成するための処理を示した図。
【００９４】
【図８】サーバへのトラステッド・ドメイン・アクセスを可能とするクライアントのTPMの機能を示した図。
【００９５】
【図９】クライアントからのリクエストを受け取り、新規なドメインの生成を示した図。
【００９６】
【図１０】クライアントとサーバとの間の新規なドメインのインスタンス化のための処理を示した図。
【００９７】
【図１１】各ドメインにおける本質的なデータ保護を示した図。
【００９８】
【図１２】本発明によるドメイン・シークレット・データの保護のための処理を示した図。
【００９９】
【図１３】GRUBを多重のステージに分割してGRUBのブート・シーケンスを詳細に示した図。
【０１００】
【図１４】LSM/SELinuxアーキテクチャに基づくトラステッド・プラットホーム・モデルの実装の実施の形態を示した図。
【０１０１】
【図１５】ＷＳセキュリティ・アーキテクチャに基づいて構成された本発明の例示的な実施の形態を示した図。
【符号の説明】
【０１０２】
１０…ネットワーク・システム、１２…サーバ、１４…ネットワーク基盤、１６…クライアント、１８…記憶装置（データベース）、２０…リモート・ベリファイア、２２…通信デバイス、２４…ＣＰＵ、２６…メモリ、２８…ハードディスク、３０…PCR（一致性）チェッカ、３２…バス、３４…ルート・トラスト部、３８…レジスタ・アレイ、４０…システム（ＴＣＢ）、４２…管理ドメイン、４４…管理者、４６…アプリケーション・ドメイン１、４８…アプリケーション・ドメイン２、５０…ユーザ・ドメイン、５２…記憶装置（データベース）、５４…第２の記憶装置、５６…認証リスト、６０…クレーム部、６２、６４、６６…ＷＳセキュリティ・アーキテクチャにおけるエンティティ
【図１】
2005167589.tif 000003
【図２】
2005167589.tif 000004
【図３】
2005167589.tif 000005
【図４】
2005167589.tif 000006
【図５】
2005167589.tif 000007
【図６】
2005167589.tif 000008
【図７】
2005167589.tif 000009
【図８】
2005167589.tif 000010
【図９】
2005167589.tif 000011
【図１０】
2005167589.tif 000012
【図１１】
2005167589.tif 000013
【図１２】
2005167589.tif 000014
【図１３】
2005167589.tif 000015
【図１４】
2005167589.tif 000016
【図１５】
2005167589.tif 000017
【外国語明細書】
【Title of Invention】  An information processing apparatus, a server apparatus, a method of an information processing apparatus, a method of a server apparatus, and an apparatus executable program
【０００１】
【Technical Field】
【０００２】
The present invention relates to computer network security, and more particularly, the present invention relates to an information processing apparatus, a server apparatus, a method of an information processing apparatus, a method of a server apparatus, an apparatu executable program useful in a networked environment with a means of securely executing programs on remote network environment.
【Background Art】
【０００３】
In recent years, security of a network system is strongly requested for protecting secret information, important information or computers itself in the network from non-certified attacks.  For this purpose, several attempts are proposed such as Palladium (Trade Mark)[1].  In Palladium architecture, platform manufactures would install the so-called Nub in a newly manufactured PC while generating a public key／private key pair within a kernel called as the Nub and obtaining maker’s certificate for certifying that the PC has a genuine Palladium platform.  These processes must be completed during the manufacturing process because the process or the manufacturer is regarded to be the only reliable for making a trusted binding between the Nub and the platform.
【０００４】
The conventional Nub system will have two control points in terms of certification, i.e., certifying the genuine Palladium (Trade Mark)platform and certifying the applications running thereon.  The above policy is very similar to some conventional environment provided such as game titles running on some types of platform.
【０００５】
However, in a server technology as well as a networked computer systems, other security policies with further flexibilities are requested, because the server may receive many different types of information processing apparatuses (hereafter referred to simply clients) including computers, PDAs and sometimes cellular phones.  The clients as well as servers may be configured to have to talk the Palladium-based platforms or other trusted architecture-based platforms and then the server may include more flexible policy upon providing services with different kind of clients.  Therefore, it is required for the server to address the security requirement in more flexible and application independent policy.
【０００６】
The OSGi [3] specifies a framework designed for providing an environment for independent services and offers function for provision, administration and life-cycle managements of such services.  Most importantly, the OSGi provides the protection of service bundles against interference from other bundles.  Services for user management and for programmatic access control are available as well.
【０００７】
Typically, a platform such as clients and servers contains one single Java Virtual Machine instance, in which one single OSGi Framework instance is executed while executing all of the services.  Each service bundle has its own class loader and the class loader is configured to avoid interference of bundle classes.  OSGi builds on top of the standard Java 2 security mechanisms.
【Disclosure of Invention】
【Problem to be Solved by Invention】
【０００８】
In a distributed computing system, some components of an application need to run in a remote platform such as a server or sometimes a client.  The remote platform may provide a protected execution domain on demand of users.  If these components process sensitive information, a question arises whether the confidentiality and the integrity of the execution are properly protected from other programs running on the same platform.  In this case, two typical situations are given below:
【０００９】
(i) Remote Information Processing Apparatus (Client)
Mobile clients such as PDAs and cellular phones becomes more and more powerful.  One trend is that a number of service providers, such as online banking, e-ticketing, and online games, try to “push”a part of their applications to the client in order to provide more functionality and better user experience.  These applications need to be isolated against each other because some application may have sensitive information that needs to be kept confidential from potential competitors.  The service provider who wants to run an application on such a client should verify if the client has enough protection against other applications before sending sensitive data and programs to the server.
【００１０】
(ii) Remote on Demand Server Apparatus
A grid computing environment is one way to realize “on demand” computing.  Grid computing nodes are usually maintained by grid service providers who may have different security policies and different levels of security skills.  A grid computing user should be able to verify the versions and configuration of the system software running on the node before submitting a job to the node, so that the user can be comfortable about the level of protection that the node provides.  In order to address these issues, the following two problems need to be addressed.
【００１１】
(a) Apparatus Trust
This problem is provided how users can assure that the apparatus is the one that user think it is, and that the apparatuses will behave as users expectation.  This problem implies that users need to verify identity and integrity of the apparatuses.  If the platform is not the one you think it is, the trust relationship is broken.  Likewise, if the platform’s integrity is compromised, e.g., through viruses, spywares, Trojan horses, or even emulators running underneath the operating system．
【００１２】
(b) Domain Separation and Access Control
The remote server may run multiple programs for serving different applications.  Each application must be isolated and protected from other applications.  In some cases, applications may want to share some resources with other applications, thus they have to have controls over which data can be shared with other applications and over which data need to be protected.  This requirement is also found in multi-application smart cards for example and is addressed by the Java Card architecture and the Global Platform Architecture [2].
【００１３】
The present invention has been made partly dependent on an architecture that makes networked platform fundamentally trust worthier by combining novel technologies with security hardware, secure operating system kernel, and open security protocol to provide end-to-end trust relationships.  The integrity values, i.e., PCR values, used in the present invention are generated at the bootstrap sequence of platform started from the system power-on-reset and securely protected from outside invasion by hardware security module called TPM.  Then the integrity values of the present invention are quite secure; these quite secure integrity values are combined with two level keys including a public and private key so that the quite secure network environment is provided.  The key of one of the level is referred to “Endosement Key” which is provided by hardware manufacturer presenting legitimacy of security module; and the key of another level is “Attestation Integrity Key” certificated by a Trusted Third Party based on the Platform Credential. Both keys are stored and used in the security module. The integrity values are signed by Attestation Integrity Key” and securely transferred to the remote entity.
【００１４】
An object of the present invention is to provide a networked environment with a means of securely executing programs on remote platforms.  For example, a service provider needs to execute an application on client apparatuses.  Or, a grid computing user may want to submit a job to a remote grid computing node. In these cases, it is allowed to maintain confidentiality and integrity of the execution of remote information processing machines.
【００１５】
Further another object of the present invention is to provide a method for providing high security with a computer in a network and to provide a computer executable program for making a computer to execute a method for providing high security with a computer in a network.
【Means for Solving Problem】
【００１６】
Trusted Bootstrap
When the platform is bootstrapped, the write protected portion of BIOS (called CRTM) “measures” the integrity (SHA1 hash) of the BIOS image and stores the value into the PCRs. The BIOS loads the OS boot loader into memory, concurrently it measures the integrity of the boot loader and stores it into the PCR. Then jump to the OS boot loader. The OS boot loader loads the OS kernel and any related essential files, measures them, and stores the measured values to the PCRs. Then the O／S start its boot process. Once a PCR is written, it is impossible to change the value to an arbitrary value, and hence these values will provide an excellent indicator to the integrity of the appratuses.
【００１７】
Thus following chain of trust is established: the CRTM can be trusted because it was installed at the factory and cannot be replaced.  The BIOS image can be trusted, if the PCR values, which indicate the trusted CRTM has updated measuring it, are as expected. The OS boot loader can be trusted, if the PCR register, which the trusted BIOS has updated measuring it, is as expected.  The OS kernel and associated files is trusted, if the PCR register which the trusted OS boot loader has updated measuring it, is as expected.
【００１８】
These PCR values can later be inquired (or “quoted”) by a remote verifier.  This quote message is digitally signed by an Attestation Identity Key (hereafter simply referred to AIK) that is securely stored and executed in the TPM, so the remote verifier can trust the reported values.  The verifier matches these values to the known trusted configuration values.  If the values match, then the verifier is in fact talking to a genuine Trusted Domain Model platform with a known security policy.
【００１９】
This allows very flexible trust relationships regarding the platform integrity.  For example, suppose that security vulnerability was found and corrected in an operating system of a mobile device.  A remote verifier who wants to send applications and data to this device only needs to update the database of the trusted PCR values. Or, a more practical solution would be to ask for a trusted third party (validation entity) to maintain such a database.  The Service providers may even choose to trust an unpatched platform if the vulnerability is not a serious one considering the value at risk.  Different service providers can trust different platform policies; bank applications would require a very restrictive access control policy while network game applications may trust a less strict policy.  The service will know the exact policy in effect through an inquiry of the PCR values.
【００２０】
The architecture is abstract because there are a number of ways to implement so-called novel Trusted Domain Model of the present invention which depends on available hardware and software, required level of security, and other novel factors.
【Best Mode of Invention】
【００２１】
1. Overview
The present invention utilizes an architecture provided by TCPA 1.1 is an open industry standard published in January 2001 (now TCPA recognizes the Trusted Computing Group (TCG) as the successor organization to TCPA).  TCPA／TCG defines an embedded chip (called Trusted Platform Module or TPM) that holds cryptographic keys as well as registers to keep track of software integrity (called Platform Configuration Registers, or PCRs).  Trusted Domain Model requires a Trsuted Boot and Platform Attestation capability provided by TCPA／TCG and Mandatory Access Control policy enforcement by SELinux [3][4][5][6][7][8][9].  In the description below, similar functional parts are associated with the same numerals.    When TPM is reviewed briefly, a value of AIK (described hereinafter in detail) proofs that platform integrity and PCR are originated from TPM module rather than verifying the platform integrity.  Certification to the value of AIK proofs that the AIK is included in the TPM module.  Therefore, depending on particular applications, the values of integrity may be used to issue credential with the AIK after verification of the integrity.  In the present invention, particular implementations will be described, but not limited to the described embodiments, the present invention may be implemented in any particular apparatus implementation including comprise AIK, TPM, and CRTM architecture.
【００２２】
1-1. Trusted Domain Model
Fig. 1 depicts an exemplary embodiment of the network system 10.  The network system comprises a server apparatus (hereafter simply referred to as “server”) 12 connected to an appropriate network infra 14 such as LAN, WAN, and／or Internet.  Client apparatus (hereafter   simply referred to “client”) 16 are also connected to the network infra 14 such that the clients may request services to the server 12 and may receive response thereof from the server 12.  Clients may include information processing apparatuses such as for example, a PDA or a notebook type personal computer, and a cellular phone which are connected to the network infra 14 through wireless or IR communications.  A storage device 18 is connected to the server 12 so as to provide services on demand under the trusted protocol.  In the following description, it is assumed that the server 12 is configured to be Trusted Platform architecture according to the present invention and the client may be any type of architectures known in the art; however, but not limited thereto, the clients may also be configured as Trusted Platform architecture.  When the server 12 receives requests from the clients 16, the server 12 creates or destroys another domain corresponding to the clients for servicing applications stored in the server 12.
【００２３】
1-2. Platform Architecture (Client and Server)
Fig. 2 shows a typical hardware construction of the client 16 according to the present invention.  The client 16 may be connected to the network 14 through wired or wireless connections and generally comprises a communication device 22, a central processing unit (CPU) 24, a memory (ROM or RAM) 26, and a hard disk unit 28.
【００２４】
The hard disk unit 28 stores a boot code, an operating system, and application files etc.  The stored software modules and CRTM (BIOS) stored in an adequate memory such as a flash memory are together read into the memory such as RAM or ROM upon request through bus lines 32 to provide normal functions with a user thereof.  The client 16 includes the signed integrity checker 30 which checks received signed PCR values together with the digital signature.  The function of the signed integration checker 30 is summarized as below: 
The quoted PCR values represent the software configuration of the platform at the time of the signing.  If there is any question about the PCR values (such as a virus might have been active when the signature was done) by comparing previously stored in elsewhere of the client 16, the signed integration checker 30 is able to examine the PCR values associated with the signature whether there have been known vulnerabilities in the specific platform configuration (BIOS and OS revisions, configuration files, antivirus definition files etc.).  If there is not found correspondence  between the PCR values stored and the recently received PCR values, the client 16 terminates transaction between the server.
【００２５】
Fig. 3 shows a typical functional construction of the server 12 configured to provide the Trusted Domain Service.  The server 12 comprises the root trust part 34.  The root trust part 34 further comprises a TPM 36, a register array 38 or storing PCR values of the server upon starting or resetting thereof and CRTM.  The TPM 36 and the register array 38 are essential part for generating the integrity report (PCRs) that signed by AIK as described herein below.  Upon receiving the attestation requests from the client for services, the root trust part 34 send the PCRs with signature of the AIK to clients so as to provide secure domain accesses.
【００２６】
2. Trusted Domain Function
2-1. General Protocols
Fig. 4 shows a schematic structure of the trusted domains created in the server 12.  The server 12 is based upon a TCPA／TCG system 40 for serving secure domain services with a Mandatory Access Control  policy.  The domains created in the server space are domains such as the administrative domain, application domains, and a user domain.  The administrative domain 42 is accessed with the system administrator 44 so as to administrate the Trusted Domain Services together with the root trust part (not shown).  The application domain 1 (46), the application domain 2 (48) and the mobile user domain 50 are created after verifications of credentials transmitted to the clients and allows the clients to enjoy the trusted domain circumstance.  Each of the domains is associated with secret data and／or the policy stored in an appropriate storage device 52 so as to protect privacy policies of users.  The server is controlled by a secure operating system (sometimes called as Trusted Computing Base, or TCB), which enforces the system-wide Mandatory Access Control Policy. Each domain has its own Discretionary Access Control Policy.
【００２７】
Although the TCB needs to be trusted and it should be thoroughly verified, it is not realistic to assume that no vulnerability will ever be found in the TCB.  The present invention provides a way to update the TCB if there is any security problem.  This means that there must be an administrative entity who can modify the TCB if necessary.  This requires the server or clients (if necessary) to have novel mechanism to update the TCB; however this mechanism is may be quite sensitive ones because a compromise on this administrative entity could break all the security assumptions.
【００２８】
To cope with the objectives described above, the present invention introduces a special domain called administration domain 42.  The administration domain 42 is the only domain that is allowed to (1) create／destroy an application domain on demand from the clients and (2) update the TCB, including updating the mandatory AC policy.  Because the administration domain is allowed to modify the mandatory AC policy, it is necessary to prevent that a malicious owner of administration domain bypasses the mandatory AC policy.  To prevent this attack, any currently running domain instances should be terminated or suspended with all the execution status being saved to a secondary storage 54 in an encrypted form before the mandatory AC policy is modified.  After the modification, the entire platform is reset.  After rebooting the server, the PCR contains a new value reflecting the new configuration of the TCB. Each domain owner performs the domain instantiation protocol again to make sure that the new system configuration can be trusted.  Only if it is trusted, the domain owner will provide an authorization of using the domain secret.
【００２９】
Note that the administration domain 42 cannot access domain secrets of another domain at any time because (1) when the TCB is not in a trusted state (i.e, no domain instance is running, or the electric power is off), the domain secret is protected by the TCPA chip as described in the next section, and (2) when the TCB is in a trusted state after recovered and a domain instance is running, it is protected by the mandatory policy.  It cannot access domain private data of another domain unless explicitly allowed by the domain owner.  In this respect, administration domain is different from Unix super-user.
【００３０】
The server according to the present invention may host multiple applications.  Each application runs in its protected execution environment, or domain, on the platform.  It is assumed here that a domain belongs to its domain owner.  A domain owner is a remote client that determines the security policy of the domain.  In the case of grid computing, a domain owner would be the user of the grid computing service.  In the case of mobile platforms on which multiple applications are running, the domain owner would be a remote service provider (e.g., e-ticket service) who pushes application and data to the client and／or movile platforms or clients.
【００３１】
On the administration function according to the present invention, every non-system program runs in a domain.  The domain protects data and execution from other domains on the server or the platform.  If a client (domain owner) decides that the domain can share some of its resources with other domains, it can do so by setting appropriate access control policy.
【００３２】
In the present invention, two levels of access control policy are implemented, that is;
(1) mandatory access control policy that is enforced system-wide on all the domains of the server (platform) and
(2) discretionary access control policy that can be controlled by each domain owner or client.
【００３３】
The mandatory policy provides strong protection of critical resources (such as cryptographic keys) even if applications running in the domain have security vulnerabilities. On the other hand, the discretionary policy allows flexible data exchange among applications if so desired.
【００３４】
According to these two levels of access control, a domain has two types of protected data.  Domain secret is data that is protected by the TPM’s hardware and subject to the mandatory policy.  An encryption key that is used for encrypting the domain’s data in the hard drive is an example of domain secret.  On the other hand, domain private data is subject to discretionary policy and can be shared by other applications if the domain’s discretionary policy allows doing so.  In the mobile device scenario, the user’s address book would be domain private data that is shared by multiple applications.
【００３５】
Depending on the type of the clients, there may be different types of domain.  Normal applications that are provided by application service providers run in Application Domains.  The administration domain 42 is an essential part for executing administration tasks.  All other domains are “owned” by a domain owner.  User domains are owned by the device user.  All the data and programs, which a user owns, are in the user domain to assure private data.
【００３６】
The administration domain executes creation or destruction of domains upon receiving requests from clients or domain users.  Fig. 5 shows the process between the client and the server till a new domain to the client is created.  As shown in Fig. 5, the client sends the verify request in the step S500 to the server or the server.  The server receives the request and the server sends to the client the result of attestation (TCG Attestation) in the step S510 as signed integrity values.
【００３７】
In the step S520, the client received the signed integrity values determines whether or not the result of the attestation is acceptable depending on the signature and／or the PCR values.  If the result of the attestation is negative, further transactions are terminated in the step S530.  If the result of the attestation is positive, the process proceeds to the step S540 and the client sends to the server the request for domain creation (hereafter referred to c-request for easiness of the description).  When the server receives the c-request, the server creates a new domain for the corresponding client while allocating a unique domain id in the step S550 such that the clients sent the c-request dominates the new domain exclusively.
【００３８】
Fig. 6 shows sample data structures used for the verification and allocation of domains to the clients.  The data structure shown in Fig. 6 may be stored, for example, in the verification list shown in Fig. 4; however, but not limited thereto, the data structure may be stored in elsewhere of the client 16 in order to manage allocations of domains of the server.  When the server receives the request from the client, the server sends to the client the AIK credential as the signature together with the integrity values.  The AIK credential may be generated from public keys provided by a certified third party and certified credential values may be stored beforehand in elsewhere of the server, or alternatively, it may be possible to obtain the certified credential values from the remote third party that accumulating certified digital signature, i.e., credentials upon receiving the request from the client.
【００３９】
The table shown in Fig. 6 includes the server ids, the credential values, the PCR values and the domain id are listed in lines.  The PCR value is the essential integrity value for the certification of the present invention which is uniquely determined by configurations of the platforms such as the server.  The integrity value (PCR) uniquely determined by the configuration may be used as single value or may be used a set of integrity values.  Details of creation of the PCR values will be discussed later.  The client 16 may enjoy the Trusted Domain Services according to the allocation table shown in Fig. 6.
【００４０】
Fig. 7 shows a process for generating the integrity values (PCR).  In Fig. 7, processes in TPM, CPU, and invocations of stored codes are described.  When a server is started or reset, PCR registers in TPM are cleared in the step S710.  The server invokes CRTM code (BIOS) into another memory area from ROM or a flash memory and executes CRTM code in the step S720 and stores hashed values of CRTM code in any one of PCR registers in the step S740 and invokes the next execution code in the step S730.  Prior to invoking of the next code in the step S730, the computed PCR value is stored further another register in the step and S750.  PCR values are extended until all of the necessary codes in the setup procedure is completed as described in the steps S760-S790.
【００４１】
The values of the PCR represent the integrity of the codes for initial setup and the written PCR values can not changed other values in the sequence of the server until the server will be powered on after the shutdown or reset.  Therefore, the PCR values assure the integrity of the server.  When the present invention is applied to the client machine, the same attestation process can be progressed in the client so that securities within the network may become more enhanced.  In these embodiment, the implementation of the client will include the TPM module or tip with suitable configuration to the client.
【００４２】
Fig. 8 shows a function of TPM of the server and client (if the client is implemented as is) for enabling the trusted domain access to the client.  TPM executes TPM_CreateEndosementKeyPairTPM-makeid and TPM_Quote.  The TPM_CreateEndosementKeyPair generates endosement keys based on known  techniques which comprise a private key and a public key in the step S810.  When the endosement key is generated, a digital signature of the responsible manufacturer is attached to the endosement key in the step S820.  The endosement key assures the confidence of TPM.  Also an AIK used for providing the digital signature for the  integrity values PCR is generated in TPM_makeid operation and AIK comprises also a private key and a public key in the step S830.  When the AIK public key is certified by the third party, the AIK is used as the certified credential and also as the digital signature attached to the PCRs in the step S840.
【００４３】
The code TPM_Quote generates the signed integrity values to be sent to the remote client (TCG Attestation) in Fig. 5.  The TPM_Quote invokes from the PCRs and attaches a digital signature with the AIK credentials to generate signatured PCRs in the step S860.  The code TPM_Quote next send the signed PCRs as the request to remote client through the network infra as shown in Fig. 8 such that the client may execute the PCR check operation.
【００４４】
2-2. Signature with integrity measurement values
As described above, the results of integrity measurements are stored in the PCRs inside the TPM and are reported by the quote function. Actually, this usage of the quote function is not limited to the response to the server challenge.  One of the ways to use the platform integrity metric is to include the metric in a digital signature.  To implement the above functions to the platform, the inventors defined a signature algorithm for XML signing functional part that includes the function to attaching the signature to the PCR values.
【００４５】
2-3. Signing Functional part (Implemented by execution of signing algorithm)
The inventors have defined our new signature algorithm as a concatenation of a structure representing the current PCR values (quoteInfo) and the signature value on the structure as follows. 
SignatureValue = quoteInfo | SignatureOnQuoteInfo
The first part of the signature value (quoteInfo) is a 48 byte data object as defined by TCPA_QUOTE_INFO as follows:
typedef struct tdTCPA_QUOTE_INFO{
TCPA_VERSION version;
BYTE fixed;
TCPA_COMPOSITE_HASH digestValue;
TCPA_NONCE externalData,
} TCPA_QUOTE_INFO;
in which version is TCPA version as defined in Section 4.5 of TCPA 1.1b. Specifically, its first two octets may be selected be 0x01 and 0x01.
The “fixed” is always the ASCII string “QUOT”.  The “digestValue” is the result of the composite hash algorithm using the current values of the requested PCR indices.  The “externalData” is the SHA-1 hash of the octet stream of the canonicalization of ＜SignedInfo＞
【００４６】
The second part of the signature value is the actual RSASSA-PKCS1-v1.5 signature value on the TCPA_QUOTE_INFO data structure. This part is at least 256 byte long because the length of an attestation key is at least 2048 bits.
【００４７】
2-4. Verification algorithm
In an particular embodiment explained, a verifying application of XML Signature with TCPA PCR Values needs to split the base64-decoded ＜SingatureValue＞ into two parts. The first part consists of the first 48 bytes of the octet string and the second part is the rest. The verifying application verifies the following things.
【００４８】
The first part contains a valid TCPA_QUOTE_INFO structure. This means the first two octets of the version field must be 0x01 and 0x01, and the fixed field must be ASCII “QUOT”.
【００４９】
The externalData field of the first part is the SHA-1 hash value of the canonicalized ＜SignedInfo＞.
【００５０】
The second part may be the RSASSA-PKCS1-v1.5 signature of the first part according to the given public key.
【００５１】
The verifying application can then verify the PCR values (the digestValue field) in the TCPA_QUOTE_INFO structure against known trusted values. If the value is known to be trusted, the server can conclude that it is communicating with a trusted platform.  Otherwise, the server may reject the request according to its policy.
【００５２】
2-5. Implementing PCR-enabled signature in JCE
In the present invention, the above signature procedure has been implemented as a new signature algorithm (called “SHA1withRSATcpa”) in a Java Crypto Environment (JCE) provider. This way, the application does not need to be modified to use the signature with PCR values.
【００５３】
3. Creating and Destroying Domain Instance
Fig. 9 shows the creation of a new domain upon receiving the request from the client.  When the server receives the request, an appropriate part such as the verify part or the communication part of the server analyze the request to obtain the AIK credential and the signed PCRs.  Then the verify part looks-up the verification list or table and determines that the received request should be allowed to access to the server.  The server returns a response packet including the result of the look-up.  Next the client sends the c-request for creation of a new domain depending on the verification of the step S530 of Fig. 5 to create the exclusive new domain such as the application domain 1 (46) for the client as shown in Fig. 9.
【００５４】
When the client creates a new domain instance on the server, it is important to make sure that the platform is indeed trusted.  This trust comes from the Trust Layer, which provides the verifiability of the identity and the integrity of the platform.  As shown in Figure 5, the client first verifies the identity and integrity of the server using the server’s PCR values which may be transmitted together with the result of TCG Attestation shown in Fig. 5 before instantiating its domain.  Unless the client is satisfied with the versions of the software stack and also the contents of the mandatory policy, the client should not proceed.
【００５５】
This domain instantiation protocol is also a mutual authentication protocol, so that the platform can verify the domain owner’s identity.  Any trusted platform must not authorize the use of the domain secret before the owner’s identity is verified. Once the domain owner is satisfied with the identity and integrity of the platform and the platform is satisfied with the client’s identity, the client conducts one of the authorization protocols (either Object Specific Authorization Protocol or Object Independent Authorization Protocol) so that the client can use the domain secret, which usually contains an encryption key (root key).  If the domain has persistent data that are stored in a secondary storage, the platform TCB imports the external data that is encrypted using this encryption key.
【００５６】
After finishing the execution of a program in the domain instance, the domain instance is destroyed as described in Fig. 5.  Here, all of the memory contents and the temporary files on the system are erased.
【００５７】
Fig. 10 shows the process for instantiating the new domain between the client and server.  The process described in Fig 10 completes the verification protocol between the client and the server in the steps S1010 and S1020.  If the verification protocol is successfully passed, next the client send the domain start request (c-request) to the server in TCG OSAP／OIAP protocol in the step S1030.  The server receives the c-request and instructs to create a new enable domain for the client in the step S1040.  Then the instance of the domain is created in the step S1050.
The instantiated domain and the client communicates transaction with respect to jobs submitted and corresponding results in the step S1060.  When the client obtains his or hers results objected, the client sends the request for domain exit to the server by TCG OSAP／OIAP protocol in the step S1070.  The server receives the request for domain exit and instructs the termination of the corresponding domain in the step S1080.  The server further sends an acknowledgment of close of the domain to the client to complete the protocol according to the present invention.
【００５８】
When the domain instance is not present, the entire domain private data stored in the persistent storage is encrypted by the domain key. Therefore, nobody can access the domain’s private data while a domain instance is not present.  When a domain instance is present, the system is a secure state because the domain owner has checked the integrity of the TCB at the time of instantiation. Therefore, the domain owner knows that the domain private data is properly protected by the TCB.
【００５９】
4. Protecting Domain Secret with TCG Protected Storage Hierarchy
Fig. 11 shows essential data protection of each of the domains.  When the platform is shut down or is in an untrusted state, the domain secrets need to be securely protected.  This is done by using the TCG’s Protected Storage Hierarchy.  As shown in Fig.10, TCG’s protected objects are organized as a tree.  The root node, called Storage Root Key (SRK), is the only key that is permanently stored in the TPM.  Because the TPM is intended to be an inexpensive device and has a limited internal memory, all the other keys are kept outside of the TPM by encrypting their parent key when they are not used.  When using a key, all its ancestor keys may be needed if they are not already loaded in the TPM.  In the present invention, each domain is assigned a subtree under the SRK.  This subtree holds the domain secret of the domain.  This means that the domain secret cannot be used unless the subtree’s root key is available to load the subtree to the TPM.
【００６０】
Each key is associated with its authorization secret, which is a 160 bit data. The TPM requires a proof of possession of this secret when a key is to be used. In our model, when the domain owner logs in to the platform, the domain owner proves that he／she knows the authorization secret of the key. Using TCG’s Object Specific Authorization Protocol (OSAP), this can be done without revealing the secret even to the TCB.
【００６１】
Fig. 12 shows the process for protecting the domain secret data according to the present invention.  The protection process first executes from the steps S1210 to S1240 the creation of a new domain.  Then proceeds to the step S1250 to obtain a root key after completion of the verification process.  In the accepted domain, the secret data in encrypted form necessary for the created domain are invoked from an adequate storage area into the domain and provided to proceed the requested job after the decription by the root key in the step S1260.  The decrypted secret data are, if necessary, encrypted again in a predetermined process and stored in an appropriate storage area administrated by the administration domain in the Step S1270, and then the instance of the domain is destroyed to complete the transactions between the client and server in the step S1280-1290.
【００６２】
5. Enforcement of Domain Separation
Providing domain separation and enforcing access control policies can be realized in many different ways in actual implementations. For example, UNIX access control and Java’s JAAS are software-based technologies that provide a certain level of protection.  Middleware such as WebSphere provides additional separation at the application level. In many situations, these domain separation models provide adequate level of application protection. However, if the applications need stronger protection, we need a stronger domain separation mechanism. It is well known that the complex software such as COTS (Commercially Off-The-Shelf) operating systems and middleware tend to have many security bugs even after careful examination by experts. There seem to be two approaches to remedy this problem.
【００６３】
One is to employ hardware support combined with very small, thoroughly examined trusted software. For example, latest high-end processors have an additional privilege level that is higher than the ordinary kernel mode. A trusted microkernel or hypervisor running in this mode can provide very secure isolation between domains. Such a hypervisor has minimal code only and therefore contains fewer residual vulnerabilities.
【００６４】
6. Implementation Variation
The other approach is to harden the existing operating systems either through a good engineering and certification (such as Common Criteria certification) or by adding additional protection in the operating system kernel (sometime called reference monitor). The Trusted Domain Model architecture allows any of the above approaches depending on the required level of security.
【００６５】
The Trusted Domain architecture of the present invention can be implemented by properly combining existing technologies.  In this section we show a design based on PC with TPM chip and Linux Security Module.  The overall structure of this implementation is shown in Fig. 12.
【００６６】
6-1. Linux Kernel Measurement in Boot Loader
IBM’s TCPA-enabled system currently supports measured bootstrap in the sense that its un-modifiable part of the BIOS measures the remainder of the BIOS and the BIOS also measures the MBR (Master Boot Record) of the bootstrap device (usually the hard drive). However, no further measurement is done for any commercial operating systems today to our knowledge.
【００６７】
For measuring the integrity of an operating system, an OS boot loader should take the responsibility according to the TCPA PC Specific Implementation specification because the BIOS does not usually directly load the operating system.  Instead, the BIOS loads a portion of a boot loader (which resides in the MBR) into the memory and transfers the control to the loaded code. In order for the boot loader to properly measure the integrity of the operating system, the boot loader needs to satisfy the following requirements:
(1)If the boot loader has multiple stages, an executing stage must be able to measure the next stage and extend the PCR value prior to transferring the control to it.
(2)The boot loader should be able to measure the O／S image and all security-critical configuration files before transferring the control to the O／S.  This implies that the boot loader must have at least a partial implementation of the file system on which these files are stored. .
【００６８】
For Unix-like operating systems for PC, several boot loaders are available now under the GPL license, such as LILO (LInux LOader),  GRUB (GRand Unified Bootloader) and XOSL (Extended Operating System Loader).  In the embodiment explained, GRUB for our prototyping of a trusted boot loader is adopted because it is widely used and it looked feasible to modify it so that the modified boot loader satisfies the above requirements.
【００６９】
6-2. Boot Sequence in GRUB
Fig. 13 shows the detail of the boot sequence of the GRUB is divided into multiple stages, that is, Stage 1, Stage1.5, and Stage 2 (Fig. 13 (a)).  This is due to the restricted size of disk space in the current PC Architecture.  Stage 1 code was designed to fit in the MBR space that is 446 bytes long. Stage 1.5 contains the file system implementation,  so it is significantly larger (approximately 10KB) and placed in the sectors right after the MBR which are normally unused space.  Since Stage 1.5 can now access the file system, Stage 2 code and the GRUB configuration file can be placed anywhere in the file system. 
【００７０】
BIOS loads Stage 1 (MBR) data from the hard drive into memory and jumps to the starting point of Stage 1. Stage 1 loads the first sector of Stage 1.5 and jumps to it. This Stage 1.5 loads the rest of Stage 1.5 sectors into memory and jumps to it. Now Stage 1.5 has filesystem interface and finds and loads Stage 2 into memory, and then jumps to the start address of Stage 2. At this point, GRUB checks the configuration file and displays an O／S selection menu to the users. After the user selects an O／S, GRUB loads the selected O／S image into memory and starts the O／S boot process.
【００７１】
6-3. Measurement Steps in GRUB
Fig. 13 also shows the code for measurement step in GRUB (Fig. 13(b).  The chain of measurement must also reflect this bootstrap sequence: The Stage 1 must measure the first  sector of the Stage 1.5, and the first block of the Stage 1.5 must measure the rest of the Stage 1.5. Then the Stage 1.5 measure the stage 2, which finally measures the operating system. Because the Stage 1 and the first sector of the Stage 2 have a severe size limitation, inserting integrity measurement codes to these stages was our major challenge.
【００７２】
Stage 1 code, which is loaded from the MBR, has to measure the first sector of the Stage1.5. This means that we must compute the hash of the loaded sector and call the TPM_Extend function of the TPM.  However, the original GRUB code already used up almost all of the 446 bytes allocated for the MBR.  Fortunately, a BIOS service could be called that does exactly this.  Still, the present invention may be implemented to discard the support of an older drive format (the C.H.S. mode as opposed to the LBA mode).
【００７３】
Basically, each step of a trusted boot must 1) load the next stage data from the hard drive into memory, 2) measure the loaded memory image and extend the PCR value using the measured value, and 3) jump to the entry point of the next stage. 
【００７４】
The next stage, the first sector of Stage 1.5, has the same space limitation as Stage 1 and was modified in the almost same way as Stage 1. The remaining part of Stage 1.5 has no such space limitation and it was easier to add the capability of measuring the next stage, Stage 2.
Stage 2 is responsible for measuring several things. First, Stage 2 measures the configuration file of GRUB (grub.conf). This file is used for specifying bootable O／S images that will be presented in the selection menu. Second, Stage 2 is required to measure the O／S image that is selected to boot. Third, Stage 2 is also responsible for measuring any other security-critical files (configuration files, library files, etc.).  To enable these measurements, grub.conf has been modified according to the present invention in the following two ways; (1) all loading commands such as “kernel” measures the target image automatically, and (2) we added the “measure” command that measures any file specified in its argument.  During these steps, the eighth register value of PCR was used for measuring Stage 1.5, Stage 2, and the O／S files.
【００７５】
6-4. Measuring OS Kernel and Configurations
In the above implementation, the chain of the measurement process covers OS kernel, security-critical files such as OS configuration files, security policy files, and, a few executables such as Java virtual machine. However, if a large number of files were measured, the number of possible PCR values of trusted configuration would be combinatorial and therefore the server-side database of the trusted PCR values would be unmanageable. Instead, the OS kernel was implemented to be responsible for maintaining the integrity of less security-critical files and resources.  Here, the Linux Security Module and the Security-Enhanced Linux (SELinux) to the kernel were applied.  If an appropriate SELinux policy file is used, the combination of LSM and SELinux should provide a better protection against unwanted modifications on any parts of the system, such as executables, libraries, and other data files.
【００７６】
Note that the integrity measurement done at the bootstrap time does not guarantee the integrity of the measured code after bootstrap. If the O／S does allow some program to modify the already-measured portion of the system, the PCR values stored in the TPM no longer reflect the correct integrity status. Therefore, a strong protection against illegal modification at the OS level is very important.
【００７７】
6-5. Mandatory Access Control based on LSM／SELinux and Java
In this embodiment, Trusted Domain Model implementation, we chose a security-enhanced operating system for the Protection Layer, that is, a combination of Linux Security Module (LSM) and SELinux.  This combination provides a fundamentally stronger access control than the conventional Unix access control.  Fig. 14 shows a particular implementation example of the Trust Platform Model structure based on LSM／SELinux architecture.
【００７８】
In Fig. 14, Linux Security Module (LSM) is a Linux kernel patch that enables general purpose access control.  LSM places a hook at the access path to every important resource of the kernel and allows a plug-in module (called a policy module) to make access control decisions. This is an important step to securing the Linux operating system because the traditional Unix security model is considered insufficient for providing a reasonable level of security. One of the biggest limitations of standard Unix is that every program run by a user inherits all the permissions granted to the user (this is especially problematic if the user is root) and thus it is very hard to protect the operating system from malicious software. 
【００７９】
Security-Enhanced Linux (SELinux) which has developed by NSA, is a policy module for LSM.  It enforces the Mandatory Access Control (MAC) policy so that a system-wide security policy can be enforced regardless of the user’s careless operations, security vulnerabilities of application programs, or malicious software.
【００８０】
Combining these technologies, we can enforce a system-wide security policy. A domain is realized as a user account, which is well protected from applications running under another user account and even from the root user. A domain instance is a remote shell. When a remote owner logs in to the platform (i.e., creates a domain instance), Pluggable Authentication Module (PAM) interacts with the TCPA chip and unlock the encryption key. 
【００８１】
Also if the platform has removable storage, an encrypted file system is necessary. All the private files owned by a service would be encrypted by the service’s key stored securely in the TPM so that the files can only be accessible from the owner’s domain.
In addition to having an operating system-level separation, the implementation also has application separation at the Java level. This can be done by Java’s native access control mechanism (JAAS) or by the permission and user administration mechanisms defined in OSGi.
【００８２】
7. Another Protocols-WS-Security 
The implementation uses protocols that are defined on top of the OASIS WS-Security standards.
【００８３】
WS-Security is a set of specifications of security protocol building blocks for Web Services. It provides basic security functionality such as integrity, confidentiality, authentication, and authorization for SOAP messages by defining a generic concept of “claims” represented as “security tokens” to be passed around among the communicating parties and trusted third parties (called Security Token Services).
【００８４】
Fig. 15 shows an exemplary embodiment of the present invention configured based on WS-security architecture.  Note that a platform integrity measurement is implemented in a claim part 60 are included in each of entities 62, 64, and 66 that can be represented as a security token.  The requester 62 such as clients is implemented according to the present invention.  The Web service site 64 ia also implemented according to the present invention.  When the requester 62 requests the Web service to the Web service site 64, the token including signatured credential is sent to the security token service site 66 from, for example, the Web service site 64.
【００８５】
The security token service site 64 issues access permission data to the Web service site 64 and the Web service site 64 determines whether or not the access request from the requester 62 is permitted in Trusted domain service.  The platform credentials, such as platform certification and software certification (whether the values contained in this token are trusted), can also be represented as a security token that is issued by a security token service.  This provides a sound framework of trust infrastructure of the present invention.
【Disclosure of Prior Literatures】
【００８６】
【Non-Patent Literature1】  http:／／www.microsoft.com／presspass／features／2002／jul02／0724palladiumwp.asp
【Non-Patent Literature2】  Global Platform specification, http:／／www.globalplatform.org／
【Non-Patent Literature3】  Open Services Gateway initiative (OSGi), http:／／www.osgi.org／
【Non-Patent Literature4】  Chris Wright, Crispin Cowan, James Morris, Stephen Smalley, Greg Kroah-Hartman, “Linux Security Modules: General Security Support for the Linux Kernel,” USENIX Security Symposium, 2002.
【Non-Patent Literature5】  Stephen Smalley, Chris Vance, and Wayne Salamon, “Implementing SELinux as a Linux Security Module,” http:／／www.nsa.gov／selinux／module-abs.html, Dec., 2001.
【Non-Patent Literature6】  IBM 4758 PCI Cryptographic Coprocessor. http:／／www.ibm.com／security／cryptocards／
【Non-Patent Literature7】  Trusted Computing Platform Alliance, TCPA Main Specification v.1.1b, February, 2002. http:／／www.trustedcomputing.org／docs／main%20v1_1b.pdf
【Non-Patent Literature8】  Trusted Computing Platform Alliance, TCPA PC Specific Implementation Specification v1.00, September 2001. http:／／www.trustedcomputing.org／docs／TCPA_PCSpecificSpecification_v100.pdf
【Non-Patent Literature9】  David Safford, “Clarifying Misinformation on TCPA”, Oct, 2002, http:／／www.research.ibm.com／gsal／tcpa／tcpa_rebuttal.pdf
【００８７】
The present invention has been described in detail using particular embodiment depicted in the drawings, however the present invention will be hereby summarized as follows:
(1) An information processing apparatus for obtaining services through a network, said information processing apparatus comprising:
a communication part for accepting a digital signature together with at least one of integrity values depending on hardware configurations; and
a check part for identity of at least said integrity values;
wherein said information processing apparatus dispatches a request for creating an exclusive domain for said information processing apparatus through said network depending on said determination by said integrity value.
(2) The information processing apparatus according to (1), wherein said check part examines said digital signature or integrity values with respect to stored digital signature or stored said integrity values.
(3) The information processing apparatus according to (1), said information processing apparatus is a client for obtaining services through said network.
(4) A server apparatus connected to a network for providing processed data on demand through said network, said server apparatus comprising:
a trust enabling part trusted based on apparatus root of trust and upon starting or resetting of said server apparatus for generating a signed integrity values to attach a digital signature, said integrity values representing integrity of configurations of said server; and
a communication part for receiving a request through said network and transmitting a signed integrity values of said server apparatus and processed data to said network;
wherein said server apparatus creates a new domain and permits accesses to resources of said server apparatus upon receiving another request in response to said signed integrity values.
(5) The server apparatus according to (4), wherein said server apparatus creates administration upon stating and／or resetting thereof and submits accesses to a root key for enabling accesses to resources.
(6) The server apparatus according to (4), wherein said resources of the server apparatus are stored as encripted forms and said server apparatus permits accesses to said resources through decription with said root key.
(7) The server apparatus according to (4), wherein sertified credentials are transmitted and stored in a storage part of said server apparatus for generating signatures, or alternatively, said server apparatus inquires said certified credentials through a remote entity for generating of said signatures.
(8) A method for making an information processing apparatus execute communications through a network, said method making said information processing apparatus execute the steps of:
accepting a signed integrity values depending on hardware configurations;
determining identity of at least one of said signed integrity values; and
dispatching a request for creating an exclusive domain for said information processing apparatus through said network depending on said determination by said integrity value.
(9) The method according to (8), wherein said server apparatus  dispatches said signed integrity values and processed data through said network to an information processing apparatus issued said request.
(10) A method for making a server apparatus execute communications through a network, said method making said server execute the steps of:
invoking from a memory initial codes for setting up the information processing apparatus stepwise execution of initial codes;
generating integrity values kept unique with respect to software configuration of said server apparatus and storing said integrity values in register array;
generating a digital signature to be attached to said integrity values by certifying integrity of said server apparatus;
providing said generated digital signature with the integrity values; and
dispatching the integrity values together with said digital signature so as to prove certification of said server apparatus.
(11) The method according to claim 10, wherein the generation step comprising the steps of:
generating private keys for a hardware integrity with respect to said software configurations and for attestation for certifications;
determining whether or not providing the digital signature to said integrity values in response to certifications of said keys; and
if the key for said attestation is certified, providing said digital signature with the integrity values.
(12) The method according to (11), wherein the method further comprising the step of:
creating said digital signature using said key for said attestation.
(13) A method for making a server apparatus connected to a network to providing processed data on demand through said network, said method making said server apparatus execute the steps of:
creating an administration domain trusted based on integrity values depending on apparatus integrity;
verifying said integrity values to provide a digital signature by referring to certified credentials;
receiving a request from said network for accessing to server apparatus to obtain services of said server apparatus
transmitting at least one integrity value associated with a digital signature; and
accepting another request for creating an exclusive domain corresponding to said request.
(14) The method according to (13), wherein said administration domain executes the step of permitting accesses to a root key so as to control accesses to resources of said server.
(15) The method according to (14), wherein said resources of the server apparatus are stored as encripted forms and said method further comprising the step of decripting said resources using said root key to permit accesses of said information processing apparatus to said resources.
(16) An apparatus executable program for making said information processing apparatus execute the method according to (8) or (9).
(17) An apparatus executable program for making said server apparatus execute the method according to any one of (10) to (15).
【Brief Explanation of Drawings】
【００８８】
【Fig. 1】  Fig. 1 depicts an exemplary embodiment of the present network system.
【００８８】
【Fig. 2】  Fig. 2 shows a typical hardware construction of the client according to the present invention.
【００８９】
【Fig. 3】  Fig. 3 shows a typical hardware construction of the server configured to provide the Trusted Domain Service.
【００９０】
【Fig. 4】  Fig. 4 shows a schematic structure of the trusted domains created in the server.
【００９１】
【Fig. 5】  Fig. 5 shows the process between the client and the server till a new domain to the client is created.
【００９２】
【Fig. 6】  Fig. 6 shows sample data structures used for the verification and allocation of domains to the clients.
【００９３】
【Fig. 7】  Fig. 7 shows a process for generating integrity values unique to hardware integrity.
【００９４】
【Fig. 8】  Fig. 8 shows a function of TPM of the client for enabling the trusted domain access to the server.
【００９５】
【Fig. 9】  Fig. 9 shows the creation of a new domain upon receiving the request from the client.
【００９６】
【Fig. 10】  Fig. 10 shows the process for instantiating the new domain between the client and server.
【００９７】
【Fig. 11】  Fig. 11 shows essential data protection of each of the domains.
【００９８】
【Fig. 12】  Fig. 12 shows the process for protecting the domain secret data according to the present invention.
【００９９】
【Fig. 13】  Fig. 13 shows the detail of the boot sequence of the GRUB is divided into multiple stages.
【０１００】
【Fig. 14】  Fig. 14 shows a particular implementation example of the Trust Platform Model structure based on LSM／SELinux architecture.
【０１０１】
【Fig. 15】  Fig. 15 shows an exemplary embodiment of the present invention configured based on WS-security architecture.
【０１０２】
【Explanation of Numerals】
【０１０３】
10-network system, 12-server, 14-network infra, 16-client, 18-database, 20-remote verifier, 22-communication device, 24-CPU, 26-memory, 28-harddisk, 30-PCR checker, 32-bus, 34- root trust part, 38-register array, 40-system (TCB), 42-administration domain, 44-administrator, 46-application domain1, 48-application domain2, 50-user domain, 52-database, 54-secondary storage, 56-verification list, 60-claim part, 62, 64, and 66- entities in WS-security architecture
【Claim 1】 An information processing apparatus for obtaining services through a network, said information processing apparatus comprising:
a communication part for accepting a digital signature together with at least one of integrity values depending on hardware configurations; and
a check part for identity of at least said integrity values;
wherein said information processing apparatus dispatches a request for creating an exclusive domain for said information processing apparatus through said network depending on said determination by said integrity value.
【Claim 2】 The information processing apparatus according to claim 1, wherein said check part examines said digital signature or integrity values with respect to stored digital signature or stored said integrity values.
【Claim 3】 The information processing apparatus according to claim 1, said information processing apparatus is a client for obtaining services through said network.
【Claim 4】 A server apparatus connected to a network for providing processed data on demand through said network, said server apparatus comprising:
a trust enabling part trusted based on apparatus root of trust and upon starting or resetting of said server apparatus for generating a signed integrity values to attach a digital signature, said integrity values representing integrity of configurations of said server; and
a communication part for receiving a request through said network and transmitting a signed integrity values of said server apparatus and processed data to said network;
wherein said server apparatus creates a new domain and permits accesses to resources of said server apparatus upon receiving another request in response to said signed integrity values.
【Claim 5】 The server apparatus according to claim 4, wherein said server apparatus creates administration upon stating and／or resetting thereof and submits accesses to a root key for enabling accesses to resources.
【Claim 6】 The server apparatus according to claim 4, wherein said resources of the server apparatus are stored as encripted forms and said server apparatus permits accesses to said resources through decription with said root key.
【Claim 7】 The server apparatus according to claim 4, wherein sertified credentials are transmitted and stored in a storage part of said server apparatus for generating signatures, or alternatively, said server apparatus inquires said certified credentials through a remote entity for generating of said signatures.
【Claim 8】 A method for making an information processing apparatus execute communications through a network, said method making said information processing apparatus execute the steps of:
accepting a signed integrity values depending on hardware configurations;
determining identity of at least one of said signed integrity values; and
dispatching a request for creating an exclusive domain for said information processing apparatus through said network depending on said determination by said integrity value.
【Claim 9】 The method according to claim 8, wherein said server apparatus  dispatches said signed integrity values and processed data through said network to an information processing apparatus issued said request.
【Claim 10】 A method for making a server apparatus execute communications through a network, said method making said server execute the steps of:
invoking from a memory initial codes for setting up the information processing apparatus stepwise execution of initial codes;
generating integrity values kept unique with respect to software configuration of said server apparatus and storing said integrity values in register array;
generating a digital signature to be attached to said integrity values by certifying integrity of said server apparatus;
providing said generated digital signature with the integrity values; and
dispatching the integrity values together with said digital signature so as to prove certification of said server apparatus.
【Claim 11】 The method according to claim 10, wherein the generation step comprising the steps of:
generating private keys for a hardware integrity with respect to said software configurations and for attestation for certifications;
determining whether or not providing the digital signature to said integrity values in response to certifications of said keys; and
if the key for said attestation is certified, providing said digital signature with the integrity values.
【Claim 12】 The method according to claim 11, wherein the method further comprising the step of:
creating said digital signature using said key for said attestation.
【Claim 13】 A method for making a server apparatus connected to a network to providing processed data on demand through said network, said method making said server apparatus execute the steps of:
creating an administration domain trusted based on integrity values depending on apparatus integrity;
verifying said integrity values to provide a digital signature by referring to certified credentials;
receiving a request from said network for accessing to server apparatus to obtain services of said server apparatus
transmitting at least one integrity value associated with a digital signature; and
accepting another request for creating an exclusive domain corresponding to said request.
【Claim 14】 The method according to claim 13, wherein said administration domain executes the step of permitting accesses to a root key so as to control accesses to resources of said server.
【Claim 15】 The method according to claim 14, wherein said resources of the server apparatus are stored as encripted forms and said method further comprising the step of decripting said resources using said root key to permit accesses of said information processing apparatus to said resources.
【Claim 16】 An apparatus executable program for making said information processing apparatus execute the method according to claim 8 or claim 9.
【Claim 17】 An apparatus executable program for making said server apparatus execute the method according to any one of claims from 10 to 15.
【Abstract】
【Problem】  To provide an information processing apparatus, a server apparatus, a method of an information processing apparatus, a method of a server apparatus, and an apparatus executable program.
【Means to Solve Problem】  An information processing apparatus uses signed integrity values unique to software configuration and asserting integrity of initial codes of a networked server.  The server apparatus generates keys used for certifying the server apparatus(S810, S820, S830).  One of the keys are certified by a third party to generate a digital signature (S840).  The digital signature is attached to the integrity values and the signed integrity values are transmitted to the information processing apparatus for allowing the information processing apparatus to have secure services through the network (S850, S860).
【Selected Drawing】  Fig. 8
【Fig. 1】
2005167589.tif 000018
【Fig. 2】
2005167589.tif 000019
【Fig. 3】
2005167589.tif 000020
【Fig. 4】
2005167589.tif 000021
【Fig. 5】
2005167589.tif 000022
【Fig. 6】
2005167589.tif 000023
【Fig. 7】
2005167589.tif 000024
【Fig. 8】
2005167589.tif 000025
【Fig. 9】
2005167589.tif 000026
【Fig. 10】
2005167589.tif 000027
【Fig. 11】
2005167589.tif 000028
【Fig. 12】
2005167589.tif 000029
【Fig. 13】
2005167589.tif 000030
【Fig. 14】
2005167589.tif 000031
【Fig. 15】
2005167589.tif 000032