JP4064914B2

JP4064914B2 - 情報処理装置、サーバ装置、情報処理装置のための方法、サーバ装置のための方法および装置実行可能なプログラム

Info

Publication number: JP4064914B2
Application number: JP2003403371A
Authority: JP
Inventors: 誠治宗藤; 宏丸山; フランク・セリガー; ナタラジ・ナガラタナム
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2003-12-02
Filing date: 2003-12-02
Publication date: 2008-03-19
Anticipated expiration: 2023-12-02
Also published as: US20120185694A1; JP2005167589A; CN100594692C; US20050120219A1; US8560857B2; CN1625105A; US8171295B2

Description

本発明は、コンピュータ・ネットワークにおけるセキュリティに関連し、特にリモート・ネットワーク環境において安全にプログラムを実行させる手段を含むネットワーク環境において有効な、情報処理装置、サーバ装置、情報処理装置のための方法、サーバ装置のための方法、およびこれら装置で実行可能なプログラムに関する。

近年では、機密情報、重要な情報またはコンピュータ自体を、予期されていない攻撃から保護するために、ネットワーク・システムの安全性が強く要求されている。この目的のため、例えばＰａｌｌａｄｉｕｍ（商標）といったいくつかの試みが提案されている（非特許文献１）。Ｐａｌｌａｄｉｕｍアーキテクチャでは、プラットホーム製造者は、いわゆるＮｕｂを、新規に製造されたＰＣにインストールさせると共に、Ｎｕｂとして参照されるカーネル内に、公開鍵／私有鍵ペアを生成させ、ＰＣが正当なＰａｌｌａｄｉｕｍプラットホームであることを認証するための製造者証明を与える。これらのプロセスは、このプロセスまたは製造者がＮｕｂとプラットホームとの間の信頼性のある結合を生成させるために、唯一信頼できると考えられる、製造プロセス中に完了されなければならない。

従来のＮｕｂシステムは、認証のために１つの制御ポイントを有している。すなわち、正当なＰａｌｌａｄｉｕｍ（商標）プラットホームの認証およびプラットホーム上で実行されるアプリケーションの認証である。上述したポリシーは、いくつかのタイプのプラットホーム上で実行されるゲーム・タイトルについて与えられた従来の環境に極めて類似するものである。

ネットワーク接続されたコンピュータ・システムに加え、サーバ・テクノロジーにおいては、サーバは、コンピュータ、ＰＤＡ、およびある場合には携帯電話などといった、多くの異なったタイプの情報処理装置（以下、本発明では、単にクライアントとして参照する）からの接続を受け付けるために、さらにフレキシビリティのある別のセキュリティ・ポリシーが要求される。サーバに加え、クライアントは、Ｐａｌｌａｄｉｕｍベースのプラットホームや他の信頼性アーキテクチャに基づいたプラットホームと対話することができる。サーバは、異なった種類のクライアントについてもサービスを提供することができる、より柔軟なポリシーを含むことができる。このため、サーバは、より柔軟でかつアプリケーションから独立したポリシーの下で、セキュリティに対して対応することが必要とされる。

ＯＳＧｉ（非特許文献３）は、個別的なサービスのための環境を提供するために設計されたフレームワークを規定しており、上述したようなサービスを提供し、管理し、ライフサイクル処理を行う機能を提供する。最も重要な点は、ＯＳＧｉは、他のバンドルからの干渉に対してサービス・バンドルを保護することにある。同様に、ユーザ管理サービスおよびプログラム化されたアクセス制御についてのサービスが利用可能である。

典型的には、クライアントおよびサーバといったプラットホームは、単一の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（一致性）チェッカ、３２…バス、３４…ルート・トラスト部、３８…レジスタ・アレイ、４０…システム（ＴＣＢ）、４２…管理ドメイン、４４…管理者、４６…アプリケーション・ドメイン１、４８…アプリケーション・ドメイン２、５０…ユーザ・ドメイン、５２…記憶装置（データベース）、５４…第２の記憶装置、５６…認証リスト、６０…クレーム部、６２、６４、６６…ＷＳセキュリティ・アーキテクチャにおけるエンティティ

Claims

ネットワークを通してオンデマンドに処理されたデータを提供するため、前記ネットワークに接続されたサーバ装置であって、前記サーバ装置は、
装置信頼性ルートとして機能する管理ドメインにより信頼性を与え、かつ前記サーバ装置のスタートまたはリセットに際してディジタル署名に付される署名付きの一致性値であって前記一致正値が前記サーバ装置がスタート、またはリセットされた場合クリアされ、セットアップ処理のコードが呼び出されるごとに前記セットアップ処理で必要なコードのすべてが完了するまで拡張されることにより生成し、前記一致性値により前記サーバ装置の構成の一致性を与える信頼性付与部と、
前記ネットワークからリクエストを受け取り、かつ前記サーバ装置の署名された前記一致性値および処理されたデータを前記ネットワークへと送出する通信部とを含み、
前記サーバ装置は、サーバｉｄと、前記一致性値をディジタル署名するための検査一致性鍵（ＡＩＫ）のうち、公開鍵を第３者による電子署名して与えられる証明値と、前記一致性値とに対応付けてドメイン識別値を割当てることにより前記リクエストに対応して新規な排他的ドメインを生成し、かつ他のリクエストを受け取ると前記署名された一致性値に対応するドメイン識別値により前記サーバ装置が生成する前記排他的ドメインのリソースへのアクセスを許可する、サーバ装置。
前記サーバ装置は、スタートまたはリセットまたはそれら双方に際して管理を開始させ、リソースへのアクセスを可能とするルート鍵へのアクセスを許可する、請求項１に記載のサーバ装置。
前記サーバ装置のリソースは、暗号化された形式として格納され、前記サーバ装置は、前記ルート鍵の復号により前記リソースへのアクセスを許可する、請求項２に記載のサーバ装置。
前記署名を生成するために、検査一致性鍵の公開鍵部分を認証した認証付き証明を生成するための通信が行われ、前記サーバ装置の格納部には、前記認証付き証明が格納されているか、または前記サーバ装置は、前記認証付き証明を、遠隔エンティティを通じて問い合わせて生成する、請求項１に記載のサーバ装置。
ネットワークに接続されたサーバ装置が情報処理装置に対し、前記ネットワークを通じて処理されたデータをオンデマンドに提供させるための方法であって、前記方法は、
前記サーバ装置に対して、装置の一致性を与え、前記サーバ装置がスタート、またはリセットされた場合クリアされ、セットアップ処理のコードが呼び出されるごとに前記セットアップ処理で必要なコードのすべてが完了するまで拡張されることにより生成される一致性値に基づいて信頼性の付与された管理ドメインを生成するステップと、
検査一致性鍵の公開鍵部分を認証した認証付き証明を参照して前記一致性値を認証し、ディジタル署名を付するステップと、
前記サーバ装置のサービスを受け取るため、前記ネットワークから前記サーバ装置にアクセスするための認証リクエストを受け取るステップと、
ディジタル署名を伴う少なくとも１つの一致性値を通信するステップと、
前記認証リクエストに対応し、前記サーバ装置が、サーバｉｄと、前記一致性値をディジタル署名するための検査一致性鍵（ＡＩＫ）のうち、公開鍵を第３者による電子署名して与えられる証明値と、前記一致性値とに対応付けてドメイン識別値を割当てることにより前記認証リクエストに対応して新規な排他的ドメインを生成し、かつ他のリクエストを受け取ると前記署名された一致性値に対応するドメイン識別値により前記サーバ装置が生成する前記排他的ドメインのリソースへのアクセスを許可するステップと
を実行させる方法。
前記管理ドメインは、ルート鍵に対するアクセスを許可するステップを実行して、前記サーバ装置のリソースへのアクセスを制御させる、請求項５に記載の方法。
前記サーバ装置のリソースは、暗号化された形式で格納され、前記方法は、さらに前記ルート鍵を使用して前記リソースを復号して情報処理装置による前記リソースへのアクセスを許可するステップを含む、請求項６に記載の方法。
請求項５〜７のいずれか1項に記載の方法を前記サーバ装置に対して実行させるための装置実行可能なプログラム。