(57)【要約】【課題】大幅に簡略化されたアクセス制御インフラストラクチャを有する情報セキュリティシステムを提供する。【解決手段】コンピュータシステムドメイン内の秘密の数が最小化されるが、個別のユーザの識別は可能で、アプリケーションへのアクセスも個別に制御可能である。コンピュータシステムの複数の各プラットフォーム（１００、２００、２０２、２０３）内の信頼されるエンティティは、プラットフォーム（１００、２００、２０２、２０３）の身元の秘密を格納し、プラットフォーム（１００、２００、２０２、２０３）が正しいソフトウェアを実行してその情報ラベルに関連付けられた特定のサービスの提供かつ／またはサービスへの参加を行うときに限り、情報ラベルと併せてその秘密を使用することについて、そのエンティティを信頼することができる。
2004537095.tif 000002
【特許請求の範囲】
【請求項１】
信頼されているエンティティと
少なくとも１つのラベルを含む少なくとも１つのプラットフォームと
を含むコンピュータシステムであって、
前記信頼されているエンティティによる前記ラベルまたは前記各ラベルの使用は、前記プラットフォームまたは前記各プラットフォーム内の所定のソフトウェア状態の存在または潜在的な存在によって決まるように、前記エンティティが動作可能である
コンピュータシステム。
【請求項２】
前記少なくとも１つのラベルは、前記プラットフォームまたは前記各プラットフォーム内の前記所定のソフトウェア状態の前記存在または前記潜在的存在を示すまたは宣伝するようになっている
請求項１に記載のコンピュータシステム。
【請求項３】
前記所定のソフトウェア状態は、前記ラベルまたは前記各ラベルにより直接的または間接的に記述される計算リソースおよび／またはソフトウェアの特定の構成を含む
請求項１に記載のコンピュータシステム。
【請求項４】
前記ラベルまたは前記各ラベルは、前記少なくとも１つのプラットフォームが潜在的に提示可能なサービスを記述する
請求項３に記載のコンピュータシステム。
【請求項５】
少なくとも２つのプラットフォーム内の前記ラベルが、計算リソースおよび／またはソフトウェアの本質的に同一の構成を記述する場合、前記ラベルは、同一である
請求項１に記載のコンピュータシステム。
【請求項６】
前記２つのプラットフォーム内の前記ラベルが、同一の分散計算エンジンまたは分散サービスに関連する計算リソースおよび／またはソフトウェアの特定の構成を記述している場合、前記ラベルは、本質的に同一である
請求項５に記載のコンピュータシステム。
【請求項７】
前記ラベルまたは前記各ラベルは、広く公開され、
該公開されたラベルの１形式は、前記プラットフォームが知る秘密を使用して署名されている
請求項１に記載のコンピュータシステム。
【請求項８】
前記ラベルまたは前記各ラベルは、広く公開され、
該公開されたラベルの１形式は、記述情報を含み、信頼されているエンティティにより署名されている
請求項１に記載のコンピュータシステム。
【請求項９】
前記ラベルまたは前記各ラベルは、広く公開され、
該公開されたラベルの１形式は、前記ラベルに関連付けられた計算リソースおよび／またはソフトウェアの構成についての記述情報を含み、信頼されているエンティティにより署名されている
請求項１に記載のコンピュータシステム。
【請求項１０】
前記ラベルまたは前記各ラベルは、広く公開され、
該公開されたラベルの１形式は、前記ラベルに関連付けられた計算リソースおよび／またはソフトウェアの構成を提供する提示を含む
請求項１に記載のコンピュータシステム。
【請求項１１】
前記ラベルまたは前記各ラベルは、前記プラットフォームが知る秘密を使用して署名されている
請求項１０に記載のコンピュータシステム。
【請求項１２】
第２のプラットフォームから前記少なくとも１つのラベルのうちの１つが組み込まれた暗号チャレンジを前記プラットフォームが受け取ることにより、前記ラベルに関連付けられた前記計算リソースおよび／またはソフトウェアを前記プラットフォームが提供可能であるかどうかが、前記プラットフォームにより判断される
請求項１に記載のコンピュータシステム。
【請求項１３】
プラットフォームによるラベルの所持の証拠は、別のエンティティが、前記ラベルにより記述される前記計算リソースおよびまたはソフトウェアを使用かつ／または提供する目的のために前記プラットフォームと協調するには十分である
請求項１に記載のコンピュータシステム。
【請求項１４】
前記ラベルにより記述される前記計算リソースおよび／またはソフトウェアを使用する権利は、
プラットフォームの秘密の所持の証拠、
ユーザの秘密の所持の証拠、
使用によりユーザが要求していることが示されていることがわかるそのユーザに関連付けられた秘密性のない認証値の表示、および、
使用によりユーザが支払いに合意していることが示されていることがわかるそのユーザに関連付けられた秘密性のない認証値の表示
のうちの１つまたは複数の提示により決まるように動作可能な
請求項３に記載のコンピュータシステム。
【請求項１５】
セキュリティおよびプライバシに少なくとも実質的に考慮しないアプリケーションであって、かつ少なくとも１つのプラットフォームに割り当てられたリソースから少なくとも１つの他のプラットフォームに割り当てられた前記リソースへ情報を流すことを許可するには前記少なくとも１つの他のプラットフォームからの許可が必要なアプリケーションに対して、セキュリティおよびプライバシを透過的に提供する信頼できる強制執行制御とセキュリティ能力を、該プラットフォームは有する
請求項１に記載のコンピュータシステム。
【請求項１６】
信頼されているエンティティと少なくとも１つのラベルを含む少なくとも１つのプラットフォームからなり、
前記信頼されているエンティティによる前記ラベルまたは前記各ラベルの使用は、前記プラットフォームまたは前記各プラットフォーム内の所定のソフトウェア状態の存在または潜在的な存在により決まるように前記エンティティが動作可能であり、
前記少なくとも１つのラベルは、前記プラットフォームまたは前記各プラットフォーム内の前記所定のソフトウェア状態の該存在または潜在的存在を示すかまたは宣伝するように動作可能であり、
前記ラベルまたは前記各ラベルは、広く公開されて前記少なくとも１つのプラットフォームにより潜在的に提示可能なサービスまたはリソースを記述する
コンピュータシステム。
【請求項１７】
信頼されているエンティティと少なくとも１つのラベルを含む少なくとも１つのプラットフォームを含み、
前記ラベルは、前記プラットフォームまたは前記各プラットフォーム内の所定のソフトウェア状態を記述し、
前記ラベルにより記述された前記所定のソフトウェア状態が、前記プラットフォームまたは前記各プラットフォーム内に存在するかまたは潜在的に存在する場合、前記信頼されているエンティティは、前記ラベルを使用するように動作可能である
コンピュータシステム。
【請求項１８】
前記少なくとも１つのプラットフォーム内に前記所定のソフトウェア状態が存在するかまたは潜在的に存在する場合にだけ、前記信頼されているエンティティは、前記プラットフォームが知る秘密により前記少なくとも１つのラベルに署名する
請求項１７に記載のコンピュータシステム。
【請求項１９】
前記少なくとも１つのラベルは、前記所定のソフトウェア状態を公に開示し、前記プラットフォームまたは前記各プラットフォーム上のサービスまたはリソースの可用性を示す
請求項１７に記載のコンピュータシステム。
【請求項２０】
信頼されているエンティティと少なくとも１つのアプリケーションを含む少なくとも１つのプラットフォームを含むコンピュータシステムであって、
前記プラットフォームは、該コンピュータシステムのためのセキュリティ機能を実行するために動作可能である
コンピュータシステム。
【請求項２１】
前記プラットフォームは、実質的にすべてのセキュリティ機能を実行し、
前記アプリケーションは、実質的にセキュリティ機能は実行しない
請求項２０に記載のコンピュータシステム。
【請求項２２】
前記プラットフォームは、コンピュータシステムからの通信に対して強制セキュリティ制御を適用するように動作可能である
請求項２０に記載のコンピュータシステム。
【請求項２３】
セキュリティ機能の更新は、コンピュータシステム全体にわたり前記少なくとも１つのプラットフォームにブロードキャストされる
請求項２０に記載のコンピュータシステム。
【請求項２４】
コンピュータシステムに計算リソースまたはサービスの潜在的な可用性を信号で知らせる方法であって、
信頼されているエンティティを含むプラットフォームに少なくとも１つのラベルを提供すること
を含み、
前記ラベルは、前記プラットフォーム内に所定のソフトウェア状態が存在するかまたは潜在的に存在するときにだけ前記プラットフォームにより使用される
方法。
【請求項２５】
前記ラベルは、前記所定のソフトウェア状態により定義される前記計算リソースまたはサービスを記述する
請求項２４に記載の可用性を信号で知らせる方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、主に商業ドメインで使用されるが、商業ドメインでの使用には限定されない情報セキュリティシステムに関する。
【０００２】
本発明は、セキュリティサービスを使用しているドメインに対してコストと複雑さを減少させる情報セキュリティシステムの簡略化に関する。
【背景技術】
【０００３】
［背景］
営利企業が情報セキュリティシステムの採用に消極的な理由の１つは、保守が比較的困難で費用がかかる複雑なオンラインインフラストラクチャが情報セキュリティシステムに必要なためである。
第２の理由は、セキュリティを使用するアプリケーションが、セキュリティを活用するために個別に書かれていなければならないことである。
そのため、アプリケーションの購入により費用がかかるようになり、保守のコストが上昇する。
第３の理由は、オペレータが間違いを犯して、セキュリティ機構を危険にさらすことが比較的簡単であることである。
【０００４】
情報セキュリティについての当業者は、秘密を証明および認証の情報として使用することを思い付くであろう。
秘密の所持は、サービスの使用または提供の権利の証拠とされる。
何らかの秘密（パスワードなど）がサービスのユーザとサービスのプロバイダとの間で秘密裏に通信されるシステムも存在する。
しかし、秘密の所持は、その秘密を開示せずに証明されることが好ましい。
そのような方法がいくつか存在し、包括的には入力を出力から統計的に推論するのが不可能なアルゴリズムへの入力として秘密を使用することを含む。
ハッシュアルゴリズム（ＳＨＡ−１など）と対称または非対称暗号アルゴリズム（３ＤＥＳまたはＲＳＡ）を伴うチャレンジ／レスポンスプロトコルをそのような目的に使用することができる。
【０００５】
そのようなシステムでは、当事者間で秘密を配布する必要がある。
パスワードや対称鍵などの秘密の配布には、たとえばセキュアソケット層（ＳＳＬ）プロトコルなどこれらの秘密の機密保持を行うチャネルの使用が必要である。
そのような配布システムは多数存在する。
そのような秘密は、既存の秘密により提供される機密チャネルを使用して配布可能である（そのため、秘密が階層となることにつながる）。
そのような秘密は、機密「帯域外」チャネルを介して配布することもできる。
情報セキュリティについての当業者は、ＰＫＩ(Public Key Infrastructures)も思い付くことであろう。
そのようなシステムは、非対称暗号アルゴリズムの公開鍵を配布する信頼ベースの方法である。
１つのエンティティが非対称鍵対を生成し、その対のうち私有鍵を秘密にしておくのが好ましい。
それからエンティティはＰＫＩを使用してその鍵の対のうち公開鍵を配布する。
ＰＫＩは、エンティティの公開鍵の記述とそのエンティティのラベルを含む「デジタル証明書」を公開し、それらはすべて何らかの認証局（ＣＡ）の（秘密の）私有鍵により署名されている。
ＣＡの公開鍵は広く公表されている。
そのため、第三者は証明書を受け取ると、ＣＡの公開鍵を使用して証明書の内容を検証することができる。
そのような方法で証明書が検証されると、第三者はＣＡを信頼しているため、第三者は、記述された公開鍵が記述されたエンティティに属していることを認める。
その結果、第三者は、証明書の公開鍵を使用して、記載されたエンティティにより署名されたデータの真正性と完全性を検証することができる。
【０００６】
なんらかの静的なＰＫＩインフラストラクチャがエンティティを識別するためには通常必要である。
しかし、複数の秘密を配布して各ユーザ／アプリケーションの対のために格納しなければならないとき、特に、各プラットフォームがすべてのアクセス制御情報を格納することができないために秘密を動的に検証しなければならないときには、インフラストラクチャの複雑さは急速に増大する。
【０００７】
既存のセキュリティシステムは、何らかのセキュリティ機能をプラットフォーム内と個別のアプリケーション内に有する傾向にある。
プラットフォームは、たとえば、暗号アクセラレータ、または暗号ライブラリ、または秘密用ストア、ＳＳＬエンジンなどの共有セキュリティリソース有する場合がある。
セキュリティ対応アプリケーションは、そのセキュリティ機能の実行時にこれらの共有リソースを使用することができる。
これらのセキュリティ機能には、機密性、完全性、認証、否認防止などの提供が含まれる。
このような共有サービスと個別機能は、情報セキュリティの当業者には周知である。
各アプリケーションはそれ自身のセキュリティのための秘密が必要になることが多い。
セキュリティサービスを複製することは、セキュリティを扱う機構の数をできるだけ少なく、かつできるだけ試験して設計不良や不十分な構造の危険性を最小にする好ましいセキュリティの慣例とは矛盾する。
【０００８】
サービスへのアクセスの管理は、サービスの複雑さと大きさの増大につれてますます困難になっている。
各カスタマ（ユーザ）には認証データが提供されて、そのようなサービスへのアクセスが許可される。
ユーザ認証の方法は、当業者には周知である。
そのようなユーザ認証データは、たとえば、単純なパスワード、生体測定値、または（好ましくは）暗号鍵の形式をとることができる。
サービスを提供する各コンピュータプラットフォームは、正規のユーザにサービスを限定するために、そのような認証されたユーザを認識できなければならない。
そのような各コンピュータプラットフォームには、サービスが正規であることをユーザが確信できるように、ユーザがサービスを確認できる認証データも提供されなければならない。
サービスを提供するそのような各コンピュータプラットフォームには、そのような各コンピュータプラットフォームがそのような他の各コンピュータプラットフォームを識別し確認できるようにする認証データも提供されなければならない。
これは、サービスを複数の正規のコンピュータプラットフォームを介して分散することができるようにするために必要である。
そのような分散は、信頼性の増加とより経済効率の高い負荷分散を可能にするので商業的に有利である。
そのため、大量の認証情報が必要になる可能性があることは明らかである。
このオンライン認証情報の分散と管理の必要性は、電子サービスへの入り口点での識別と検証を行う既存の方法の大きな欠点である。
そのようなシステムの１つに、周知の「Ｋｅｒｂｅｒｏｓ」システムがある（たとえば、「Kerberos: an authentication service for computer networks」、Neuman and T'so、IEEE Comms、September 1994を参照）。
これは、長期の秘密に基づいてアクセス権を検証し、リソースへの短期アクセスを提供する一時秘密を分散するために使用されるゲートキーパ機構である。
【０００９】
秘密を使用してユーザを識別し、ドメインに登録し、計算エンジンやサービスを使用するトークンを取得し、リソースを実際に使用するためにトークンを提出する前述の従来のセキュリティモデルから商業顧客も商業ドメインも常に恩恵を受けるわけではない。
複雑さが加わることにより時間と金が必要になり、その両方が欠点となっている。
【００１０】
情報セキュリティについての当業者は、Trusted Computing Platform Alliance（TCPA）（その詳細は、www. trustedpc. org（非特許文献２）およびＷＯ  ００／４８６０６３号においても見ることができ、その内容は参照により本明細書に援用される）にも思い当たることであろう。
この業界団体は、Trusted Computing Platformの概念を定義している。
本質的に、２つの信頼の根源(root-of-trust)が各プラットフォームに組み込まれている。
その１つは、計測のための信頼の根源であり、プラットフォーム内のソフトウェア環境の計測処理を開始する。
２番目は、報告のための信頼の根源であり、これは、計測のための信頼の根源による計測の概要を格納し報告する。
報告のための信頼の根源は、通常、Ｔｒｕｓｔｅｄ  Ｐｌａｔｆｏｒｍ  Ｍｏｄｕｌｅ（ＴＰＭ）と呼ばれるが、これは通常は単一の集積回路として実装されるためである。
ＴＰＭはその方法を妨害から保護する。
また、ＴＰＭはその秘密を覗き見と妨害から保護する。
ＴＰＭは、乱数生成、鍵生成、暗号化、復号化などのいくつかの暗号機能を備える。
ＴＣＰＡプロトコルにより、ＴＰＭは複数の匿名の信頼されている暗号の身元を得ることができる。
そのＴＰＭの所有者により選択されたＣＡは、そのような信頼されている身元を保証する。
そのような各信頼された身元を使用して、特定のデータが信頼できる計算エンジン（ＴＰＭ）から送られてきたことを暗号的に証明することができる。
前述のＴＣＰＡ仕様は、プラットフォームから完全性応答を得る方法についても記述している。
完全性応答は、計測のための信頼の根源により行われた計測の概要を（特に）報告することにより、そのプラットフォームのソフトウェア状態の証拠を提供する。
信頼されている身元により署名されている完全性応答は、プラットフォームからの信頼性応答が信頼できることを証明するのに十分である（信頼されている身元に属する私有鍵がその身元を含むプラットフォームからの完全性応答に署名するのに使用されている）。
完全性応答の受け取り側は、プラットフォームが信頼状態にある場合に取得されるべき計測値の組と応答とを比較しなければならない。
そのような比較値の取得方法は、前述のＴＣＰＡ仕様に記載されているので、ここでは記載しない。
しかし、正常に動作しているプラットフォーム内で計測のための信頼の根源によって行われた計測の概要の署名された記述は、完全性応答を簡単に検証できる便利な方法であることに注意しなければならない。
ＴＣＰＡシステムは、ＰＫＩに依存している。
すなわち、ＴＣＰＡシステムは、ＴＰＭの製造元、プラットフォームの製造元、準拠試験機関（国際「Ｃｏｍｍｏｎ  Ｃｒｉｔｅｒｉａ」セキュリティ記載書への準拠を扱う試験機関など）、プラットフォームのコンポーネント（プラットフォーム内のソフトウェアを含む）の製造元を含むいくつかのエンティティにより公開されたいくつかの証明書に依存している。
ＴＣＰＡ仕様は、プラットフォームのソフトウェア状態の計測方法と、プラットフォームのそれ以外の部分よりも妨害や覗き見からはるかに適切に物理的に保護されているＴｒｕｓｔｅｄ  Ｐｌａｔｆｏｒｍ  Ｍｏｄｕｌｅ内の複数のＰｌａｔｆｏｒｍ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｒｅｇｉｓｔｅｒ（ＰＣＲ）としてその状態の概要の作成方法を公開している。
ＴＣＰＡ仕様は、ＴＰＭ＿ＳＥＡＬ（ＴＰＭ封印）とＴＰＭ＿ＵＮＳＥＡＬ（ＴＰＭ封印解除）の一対のコマンドを記載している。
コマンドＴＰＭ＿ＳＥＡＬ（平文、ｐｃｒインデックス、ｐｃｒ値）を受け取ったＴＰＭは、平文データをｐｃｒインデックスとｐｃｒ値と共に暗号化する。
コマンドＴＰＭ＿ＵＮＳＥＡＬ（暗号文）を受け取ったＴＰＭは、暗号文データを内部で復号化してデータ［平文、ｐｃｒインデックス、ｐｃｒ値］を取得する。
この段階で、平文データはＴＰＭ内部に秘匿される。
プラットフォーム内の現在のｐｃｒインデックスのｐｃｒ値が［ｐｃｒインデックス、ｐｃｒ値］の復号値と一致した場合にだけＴＰＭは平文データをＴＰＭからエクスポートする。
したがって、平文データが暗号化されたときに記述された状態に現在プラットフォームがある場合にだけデータはＴＰＭにより出力される。
【００１１】
既存のセキュリティサービスは、従来の方法を使用してセキュリティサービスを管理し提供する。
秘密は、鍵配布システムとＰＫＩの機能を使用して分散されロードされる。
サービスを提供する各プラットフォームは、それ自身の秘密を持ち、その他のそのようなプラットフォームはそれらの秘密を使用して、サービスを提供するプラットフォームを識別し検証する。
サービスの各ユーザは、サービスへのアクセスを可能にする秘密を与えられる。
サービスを提供する各プラットフォームは、個別にまたは別のプラットフォームを介して、権利を有すると見込まれるユーザが実際にそのサービスにアクセスする権利を証明する秘密を有するという証拠を要求する。
ＴＣＰＡの信頼されているプラットフォームが展開されているときには、既存のサービスを、
（１）プラットフォームを、信頼されている身元により識別することが可能になり、
（２）プラットフォームは、サービスの提供、サービスの使用、または共同でのサービスの提供の前に相互の完全性を検証することが可能になる
ように修正することができる。
【００１２】
以前の特許出願（Trusted States）ＰＣＴ／ＧＢ００／０３６１３号では、参照により本明細書に援用される内容は、プラットフォームがさまざまな異なる状態にある様子を記載していて、各状態は、何らかの電子サービスの有効性を保証するように最適化されている。
プラットフォームにより提供される完全性応答は、プラットフォームがそのサービスを安全に提供するのに適した特定の状態にあることを、権利を有すると見込まれるユーザに対して証明する。
電子サービスの提供についての当業者は、単一のプラットフォームによりサービスが提供されるか、少なくとも１つの別のプラットフォームと協調する１つのプラットフォームにより提供され、様々なサービスが同一のプラットフォーム上で実施されることに気付くであろう。
同じく参照により本明細書に援用される以前の特許出願（Performing a service on a computer）ＧＢ  ００  ２０４４１．  ２号は、強化されたコンパートメントを使用して、そのようなサービスの指定、隔離、監査を行うことを記載している。
【００１３】
既存のセキュリティシステムは、特定アクションの実施と特定のデータの使用のためにユーザと計算エンジンが権利と特権を持つ軍用モデルに従う。
そのような軍用モデルは、計算リソースの提供を望む商業ドメインには必ずしも必要ないという欠点が存在する。
そのような商業ドメインは、従来の電子サービスを提供しているか、またはユーザが自身のデータとアプリケーションを実行可能な計算エンジンだけを提供している場合がある。
実際、そのようなドメインでは、そのプラットフォームを任意の計算エンジンの組に分割するために、そのドメイン自体用にエンジンサービスを提供することが必要である。
そのような多くのドメインの重要な関心事は、使用したリソースの代金をユーザが支払うことである。
企業の会計モデルはしばしば個別のプロジェクトや個別の部門に企業リソースの使用について課金するので、ユーザがそのようなドメインに属しているときでも、このような事が当てはまることがある。
もちろん、「顧客」またはユーザがサービスおよび／またはリソースを使用する権利があり、支払いが必要ないことをドメインが確認するだけでよい場合もある。
この従来のセキュリティモデルでも、権利として自分のＩＤにより特定のリソースにアクセスすることが許可される会社の従業員や国の市民に対しては適切である。
【００１４】
計算リソースが必要な所与のユーザは、そのリソースにより提供されるアプリケーションとデータを使用したいと考えたり、新規の計算エンジンや、アプリケーションを全くあるいはほぼ含まないオペレーティングシステムなどの何らかの限定された量のソフトウェアを実行する計算エンジンへのアクセスを取得したいと考えることがある。
ユーザは、セキュリティ／プライバシのレベルに従って自分の処理要件を分割し、それらのセキュリティ／プライバシ基準に従ってタスクをドメイン内に分散することができる。
秘密性のない計算スレッドは、データセンタにより実行するのではなく、企業ネットワークやインターネットなどに接続された個別のワークステーションなど任意のプラットフォームで実行可能である。
ユーザは（ドメインでも）、別の時間帯に計算リソースの余裕がない場合、ある時間帯内の使用されていない計算リソースを利用することができる。
個人は、秘密データを自分自身のプラットフォームで実行し、そのプラットフォームがアイドル状態の眠っている個人に属する任意のプラットフォーム上で秘密性のないデータを実行することを相互取り決めを有することもできる。
移動する個人は、秘密データを自分自身のパーソナルデジタルアシスタント（ＰＤＡ）上で実行して、秘密度が低いデータを論理的にローカルな環境内の任意のプラットフォーム上で実行するような取り決めを有することもできる。
多国籍企業は、従業員が机にいない場合は、世界中のデスクトップワークステーションリソースをその企業の処理に使用することができる。
同一の秘密性のないスレッドを複数のプラットフォーム上で実行して結果を比較することで、任意のプラットフォームから取得された結果の信頼性を向上させることができる。
【特許文献１】
ＥＰ１  ０８５  ３９６  Ａ
【特許文献２】
米国特許第５５８８１４６号
【特許文献３】
国際公開公報Ｗ０  ９７  ２９４１６  Ａ
【特許文献２】
米国特許第５４４８０４５号
【非特許文献１】
「Kerberos: an authentication service for computer networks」、Neuman and T'so、IEEE Comms、September 1994
【非特許文献２】
www. trustedpc. org
【発明の開示】
【発明が解決しようとする課題】
【００１５】
そのため、従来のセキュリティシステムにより提供される絶対的なセキュリティのレベルよりもレベルが低くなったとしても、従来のセキュリティシステムの複雑さを減少させることには利点がある。
基本となるプラットフォームは、アプリケーションがセキュリティに配慮しないですむようにセキュリティを提供しなければならない。
また、ゲートキーパ認証機構の使用なしに計算リソースとサービスへ高速にアクセスできなければならない。
【課題を解決するための手段】
【００１６】
本発明によると、コンピュータシステムは、信頼されているエンティティと少なくとも１つのラベルを含む少なくとも１つのプラットフォームを含み、信頼されているエンティティによるラベルまたは各ラベルの使用がプラットフォームまたは各プラットフォーム内の所定のソフトウェア状態の存在または潜在的な存在により決まるようにエンティティが動作可能である。
【００１７】
少なくとも１つのラベルは、プラットフォームまたは各プラットフォーム内の所定のソフトウェア状態の存在または潜在的存在を示すかまたは宣伝するようになっていてもよい。
【００１８】
所定のソフトウェア状態の存在は、信頼されているエンティティが特定の計算リソースまたはサービスを提供可能であることを示すものであってもよい。
所定のソフトウェア状態の潜在的存在は、信頼されているエンティティが特定の計算リソースまたはサービスを提供可能であることを示すものであってもよい。
【００１９】
ラベルまたは各ラベルは、少なくとも１つのプラットフォームが潜在的に提示可能なサービスを記述してもよい。
【００２０】
コンピュータシステムは、信頼されているエンティティの特定の計算リソースまたはサービスが利用可能になったことを示すように動作可能な信頼されている装置を提供できる利点がある。
【００２１】
所定のソフトウェア状態は、ラベルまたは各ラベルにより直接的または間接的に記述される計算リソースおよび／またはソフトウェアの特定の構成を含んでもよい。
【００２２】
少なくとも２つのプラットフォーム内のラベルが計算リソースおよび／またはソフトウェアの本質的に同一の構成を記述している場合、これらのラベルは同一であってもよい。
２つのプラットフォーム内のラベルが同一の分散計算エンジンまたは分散サービスに関連する計算リソースおよび／またはソフトウェアの特定の構成を記述している場合、これらのラベルは本質的に同一であってもよい。
【００２３】
ラベルまたは各ラベルが広く公開され、公開されたラベルの１形式がプラットフォームが知る秘密を使用して署名されていてもよい。
公開されたラベルの１形式は、記述情報を含んでもよく、信頼されているエンティティにより署名されている。
公開されたラベルの１形式は、ラベルに関連付けられた計算リソースおよび／またはソフトウェアの構成についての記述情報を含んでもよく、信頼されているエンティティにより署名されている。
公開されたラベルの１形式は、ラベルに関連付けられた計算リソースおよび／またはソフトウェアの構成を提供する提示を含んでいてもよい。
ラベルまたは各ラベルは、プラットフォームが知る秘密を使用して署名されていてもよい。
【００２４】
第２のプラットフォームから少なくとも１つのラベルが組み込まれた暗号チャレンジをプラットフォームが受け取ることにより、ラベルに関連付けられた計算リソースおよび／またはソフトウェアをプラットフォームが提供可能であるかどうかを判定してもよい。
【００２５】
プラットフォームによるラベルの所持の証拠は、別のエンティティが、ラベルにより記述される計算リソースおよびまたはソフトウェアを使用または提供する目的のためにそのプラットフォームと協調するには十分であってもよい。
【００２６】
ラベルにより記述される計算リソースおよびまたはソフトウェアを使用する権利は、プラットフォームの秘密の所持の証拠、ユーザの秘密の所持の証拠、使用することによりユーザが要求していることを示すことがわかるそのユーザに関連付けられた秘密性のない認証値の表示、使用によりユーザが支払いに合意していることを示すことがわかるそのユーザに関連付けられた秘密性のない認証値の表示のうちの１つまたは複数の提示により決まるようにコンピュータシステムが動作可能であってもよい。
【００２７】
セキュリティとプライバシに少なくとも実質的に配慮しないアプリケーションであって、少なくとも１つのプラットフォームに割り当てられたリソースから少なくとも１つの他のプラットフォームに割り当てられたリソースへの情報の流れを許可するのに、前述の他のプラットフォームからの許可が必要なアプリケーションに対して、セキュリティとプライバシを透過的に提供する信頼できる強制執行制御とセキュリティ能力をその少なくとも１つのプラットフォームが含んでもよい。
【００２８】
本発明の別の一態様によると、コンピュータシステムは、信頼されているエンティティと少なくとも１つのラベルを含む少なくとも１つのプラットフォームを含む。
信頼されているエンティティによるラベルまたは各ラベルの使用がプラットフォームまたは各プラットフォーム内の所定のソフトウェア状態の存在または潜在的な存在により決まるように、信頼されているエンティティは動作可能である。
少なくとも１つのラベルは、プラットフォームまたは各プラットフォーム内の所定のソフトウェア状態の存在または潜在的存在を示すかまたは宣伝するようになっている。
ラベルまたは各ラベルは、広く公開されて、少なくとも１つのプラットフォームにより潜在的に提示可能なサービスまたはリソースを記述する。
【００２９】
本発明のさらに別の一態様によると、コンピュータシステムは、信頼されているエンティティと少なくとも１つのラベルを含む少なくとも１つのプラットフォームを含み、ラベルはプラットフォームまたは各プラットフォーム内の所定のソフトウェア状態を記述し、ラベルにより記述された所定のソフトウェア状態がプラットフォームまたは各プラットフォーム内に存在するかまたは潜在的に存在する場合、信頼されているエンティティはラベルを使用するように動作可能である。
【００３０】
少なくとも１つのプラットフォーム内に所定のソフトウェア状態が存在するか潜在的に存在する場合にだけ、信頼されているエンティティは、プラットフォームが知る秘密により少なくとも１つのラベルに署名してもよい。
【００３１】
少なくとも１つのラベルは、プラットフォームまたは各プラットフォーム上のサービスまたはリソースの可用性を示すために所定のソフトウェア状態を公に開示してもよい。
【００３２】
本発明によると、コンピュータシステムは、信頼されているエンティティと少なくとも１つのアプリケーションを含む少なくとも１つのプラットフォームを含み、プラットフォームはコンピュータシステムのためのセキュリティ機能を実行するために動作可能である。
【００３３】
プラットフォームは実質的にすべてのセキュリティ機能を実行することが好ましく、アプリケーションは実質的にセキュリティ機能は実行しないことが好ましい。
【００３４】
プラットフォームは、コンピュータシステムからの通信に対して強制セキュリティ制御を適用するように動作可能であってもよい。
セキュリティ機能の更新はコンピュータシステム全体にわたり少なくとも１つのプラットフォームにブロードキャストされてもよい。
【００３５】
本発明によると、コンピュータシステムに計算リソースの潜在的な可用性を信号で知らせる方法は、信頼されているエンティティを含むプラットフォームに少なくとも１つのラベルを提供することを含み、プラットフォーム内に所定のソフトウェア状態が存在するときにだけプラットフォームによりラベルが使用される。
【００３６】
ラベルは、所定のソフトウェア状態により定義される計算リソースまたはサービスを記述してもよい。
【００３７】
厳密に把握された状況によっては、情報セキュリティシステムは、全体のセキュリティのレベルが従来のセキュリティシステムよりわずかに低くてもよいが、そのようなセキュリティのレベルでも商用目的には適切であると考えられる。
【００３８】
本発明の一態様は、ドメインにより提供されなければならないアクセス制御インフラストラクチャの簡素化に関連する。
ドメイン内の秘密の数が最小化されるが、個別のユーザの識別は可能で、なおアプリケーションへのアクセスは個別に制御可能である。
その際に、個別に各プラットフォームとやりとりすることなしに、ブロードキャスト機構によりドメイン全体にわたり安全なアプリケーションを維持することができる。
リソースに対する支払いの機構は、システムに一体化した部分である。
ドメインでのオンラインＰｕｂｌｉｃ  Ｋｅｙ  Ｉｎｔｅｒｆａｃｅ  （ＰＫＩ）への要件は減少するかまたは消滅する。
【００３９】
別の一態様は、アプリケーションから離れた、プラットフォームへのすべてのセキュリティ機構の移行である。
この移行により、アプリケーションがセキュリティ機能を適切に実装する必要がなくなるため、アプリケーションが簡素化され、危険が減少する。
この移行により、セキュリティに対応していない旧来のアプリケーションにセキュリティを適用することもできる。
また、この移行により、プラットフォームは強制セキュリティ制御を提供することが可能になり、セキュリティ機構と制御を設計し構築するのに必要な人員数も減少するので、危険性も減少する。
【００４０】
本発明は、計算エンジン上のユーザのデータとアプリケーションが他のユーザに「漏洩」しないことが、そのようなドメインのユーザの主な要求であることも認識している。
ユーザが（期間の長さにかかわらず）アプリケーションと情報をドメインにキャッシュすることを選択する場合、ドメインは、それらのアプリケーションとデータがユーザとそのエージェントにだけ使用できるようにそれらのアプリケーションとデータに対してアクセス制御を提供する必要がある。
【００４１】
本発明が開示するアーキテクチャは、アプリケーションがセキュリティに対応する必要性を潜在的に除外し、プラットフォーム内の秘密の数を最小化し（プラットフォームあたり１つだけ）、ユーザを識別するための秘密の数を最小化し（ユーザあたり１つの秘密／値だけ）、すべての秘密を製造時または初期化時に組み込むことができるようにし、しかも個々のユーザに対して個々のサービスやドメインへの個別のアクセス制御を可能にし、プラットフォームの身元によらずドメイン内のすべてのプラットフォームに保守情報をブロードキャストすることを可能にし、かつオンラインＰＫＩインフラストラクチャを必ずしも必要としない。
【００４２】
本発明の主要な一態様では、複数のプラットフォームの各々の信頼されているエンティティがプラットフォームの身元の秘密を格納している。
プラットフォームが正しいソフトウェアを実行してラベルに関連付けられた特定のサービスを提供および／またはそのサービスに参加しているときに限り、そのラベルと併せて秘密を使用することについて、そのエンティティを信頼することができる。
【００４３】
本発明の第２の態様は、サービスと計算エンジンを記述するグローバルラベルの公開である。
各グローバルラベルは、エンジンおよび／またはそのエンジン上で実行されるサービスの属性を識別する役割を持つことが好ましく、エンジン／サービスをホストするプラットフォームにより署名されることが好ましい。
そのようなラベルとそのラベルの解釈は、データベース上、またはＷＷＷ上で公開され、ドメイン内でまたはグローバルに使用可能であってもよい。
そのようなラベルとラベルの解釈は、信頼されているエンティティ、好ましくはドメイン自体によりデジタル署名されるのが好ましい。
プラットフォームは、そのプラットフォームがそのエンジンおよび／またはサービスを現在提供していない場合や、提供する状態にない場合でも、潜在的に提供可能なエンジンおよび／またはサービスのグローバルラベルを公開するのが好ましい。
【００４４】
本発明の第３の態様は、プラットフォームがラベルに関連付けられた特定のエンジンおよび／またはサービスの提供を要求されたときにだけ、ラベルに関連付けられたエンジンおよび／またはサービスを実際にプラットフォームが提供可能かどうかを判断する。
【００４５】
本発明の第４の態様は、他のプラットフォームが所有するラベルの認識だけに基づいて、他のプラットフォームに関連付けられたエンジンおよび／またはサービスを、プラットフォームが提供かつ／または使用することが可能である。
【００４６】
本発明の第５の主要な態様では、ドメインは、自身のオンラインＰＫＩを提供して、秘密を使用してユーザを確認する必要はない。
その代わりに、ドメインは、真の秘密を使用可能な外部のオンラインサービスを使用するか、疑似秘密を使用することができる。
オンラインサービスはユーザの識別に使用可能であることが好ましく、オンラインＰＫＩはオンラインクレジット検証と支払いに使用可能なことがさらに好ましい。
【００４７】
本発明の第６の態様では、複数のプラットフォームの各々が、プラットフォーム上の個別のアプリケーションが組み込まなければならないセキュリティ機能のレベルを（なくすことはできないまでも）大幅に減少させるセキュリティ／プライバシ機能を提供する統合セキュリティサービスを有する。
セキュリティサービスは、オペレータおよび／またはユーザが、プラットフォーム上で実行されるエンジンおよび／またはサービスに与えられるセキュリティとプライバシのレベルを管理するポリシーを設定できるようにすることが好ましい。
各プラットフォームは、プラットフォームが特定の状態にあるときにだけ公開される１つまたは複数の暗号の身元を有するとみなすことができる。
各暗号の身元は、異なるグローバルラベルと、暗号アルゴリズムで使用するための同一の共有秘密からなることが好ましい。
また、身元とグローバルレベルを公開する機構は、信頼されていて、プラットフォームがその身元をエクスポートしたときにプラットフォームが適切な状態にあり特定のエンジンおよび／またはサービスを提供することを第三者が確信できることが好ましい。
さらに、ユーザのデータとアプリケーションに強制制御が適用される環境に、そのような各状態が対応することが好ましい。
さらに、これらの制御が、ユーザのデータとアプリケーションを必要に応じて隔離することが好ましい。
そのような状態は、そのような環境で実行されるサービスに対応しても良い。
【００４８】
同一のエンジンおよび／またはサービスを公開するすべての身元は、少なくともドメイン内のすべてプラットフォームにわたり同一のラベルを有することが好ましい。
それにより、それらのエンジンおよび／またはサービスを提供するために協調可能なプラットフォームの識別が容易になる。
しかし、ラベルを変えることで、プラットフォームが、たとえば、クライアント−サーバプロセスのクライアント部分、クライアント−サーバプロセスのサーバ部分、またはピア−ピアプロセスのピア部分を実行中であることを示すことができる。
前述のように、同一のプラットフォームに属するすべての身元は、同一の暗号秘密を使用するが異なるラベルを有することが好ましい。
プライバシの懸念がある場合は、同一のプラットフォームに属するいくつかのまたはすべての身元が異なる暗号秘密を有するようにすることもできるが、このことで複雑さも増大する。
異なるプラットフォームおよび／またはシステムに属する身元は、（統計的に）異なる暗号秘密を持つべきことが好ましい。
身元は、プラットフォームの身元を取得するＴＣＰＡプロトコルを介して取得することもできるが、直接あらかじめロードされているか、ドメイン自体により保守されることが好ましい。
【００４９】
各身元の秘密は、関連付けられた保証書をデジタル証明書の形態で有することが好ましい。
その保証書は、秘密を含むプラットフォームの名前および／または性質を証明することが好ましい。
その保証書は、身元の秘密を含むプラットフォームとやりとりすることを希望している第三者が信頼できるとみなしているエンティティによりデジタル署名されていることが好ましい。
信頼されているエンティティは、ドメイン自体であることが好ましい。
【００５０】
各ラベルは、関連付けられた保証書をデジタル証明書の形態で有することが好ましい。
その保証書は、そのラベルにより記述されるエンジンおよび／またはサービスの名前および／または性質を証明することが好ましい。
その保証書は、そのエンジンおよび／または秘密を提供しているプラットフォームとやりとりすることを希望している第三者が信頼できるとみなしているエンティティによりデジタル署名されていることが好ましい。
信頼されているエンティティは、ドメイン自体であることが好ましい。
【００５１】
プラットフォームがエンジンおよび／またはサービスを提供できると主張する場合、プラットフォームはその身元の秘密を使用して少なくともそのエンジンおよび／またはサービスを記述するラベルとそのデータが広告であることの表示からなる広告データに署名することが好ましい。
プラットフォームは、好ましくはそのラベルに関連付けられたそのエンジンおよび／またはサービスを提供する能力があるかどうかにより、適切な広告を（たとえば）Ｗｅｂサイトに掲示するかまたはＷｅｂサイトから削除する。
各広告は、アドレス（ＩＰアドレスなど）に関連付けられることにより、プラットフォームとの通信を可能にすることが好ましい。
そのような広告の存在は、プラットフォームがそのサービスを提供することを意味するわけではなく、そのサービスを提供できる能力があることを意味している。
要求を受け取ると、プラットフォームは、好ましくはＴＣＰＡ機構を使用して信頼できる方法で計測されてきたそのプラットフォームの内部状態を評価することが好ましい。
プラットフォーム（厳密にはプラットフォームのＴＰＭ）は、その身元の秘密を使用して、プラットフォームの状態がエンジンおよび／またはサービスを提供する正常な状態にある場合にだけエンジンおよび／またはサービスの可用性の確認に署名することが好ましい。
そのような確認データは、エンジンおよび／またはサービスを記述するラベルと、データが確認であることの表示を少なくとも含むことが好ましい。
【００５２】
ユーザとホストの両方が、そのアーキテクチャが本発明に準拠したプラットフォームを使用することが好ましい。
そうではない場合、１つのプラットフォームは、サービスの提供と利用が可能であるが、２つのプラットフォームが協調することおよび／または協調して本発明で意図している方法で分散サービスを第３のプラットフォームに提供することはできない。
【００５３】
ユーザが特定のエンジン／サービスを使用することを望む場合には、ユーザまたはそのエージェントがＷｅｂサイトをブラウジングして、その特定の種類のエンジンおよび／またはサービスの広告を検索することが好ましい。
ユーザが適切なラベルを発見すると、関連付けられた保証書を検証して、その証明内容が信頼できるかどうか判断する。
ユーザが、証明内容が手持ちの業務に十分であることを信頼する場合、ユーザは、表示されたドメイン内の表示されたプラットフォームに連絡し、目的のエンジン／サービスを記述し、必要となり得るすべての支払い情報や識別情報を提示し、関連するポリシー情報をすべて提示することが好ましい。
ドメインプラットフォームは、ユーザの保証書に基づいてアクセスを許可するかどうかを判断することができる。
その代わりに、ドメインはユーザの保証書には関係なくアクセスを許可することもできる。
【００５４】
２つのプラットフォームが協調することに同意した後、それらのプラットフォームは、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ（ＤＨ）プロトコルやセキュアソケット層（ＳＳＬ）などの従来の暗号方法を使用して両者間の通信の機密を提供することが好ましい。
それにより、プラットフォーム内の長期の身元の秘密がプラットフォームの識別を提供する一方、ＤＨプロトコルまたはＳＳＬにより作成されたより短期の秘密がプラットフォームおよび／またはプラットフォームにより提供されるエンジンとサービスの機密を提供することが好ましい。
ユーザは、データおよびドメインにより実行されるアプリケーションとに適用されるセキュリティとプライバシの状態を記述するポリシーステートメントをそのドメインに送信することが好ましい。
そのようなポリシーは、既定値を使用すべきであることだけを示していることが多い。
そのような既定値は、すべてのユーザのデータとアプリケーションがホスト上にあるときには他のユーザのデータとアプリケーションから隔離されていることであることが好ましい。
ユーザは、特定のデータとアプリケーションをドメインのプラットフォームにキャッシュすることを望む場合もある。
その場合、ホストは、ユーザの身元またはユーザのプラットフォームの身元に基づいて、そのユーザだけがそのようなデータとアプリケーションにアクセスできるようにそれらを隔離し、格納し、保護しなければならない。
これらの保護機構は、ユーザの関与を要求しない。
ドメインは、必要な保護、おそらくは暗号プロセスおよびドメインとそのエージェントだけが知る秘密のためのストレージであるが必ずしもこれらではない保護を提供する、信頼されている機能を有することができる。
既定のポリシーは、ユーザのプラットフォームが正しい身元ラベルを有し、ユーザが同一の一般的支払い／アクセス情報を提示した場合、ユーザがそれらのデータとアプリケーションへアクセスできることであってもよい。
【００５５】
好ましい１つの使用方法では、ドメインは実際の単数または複数のユーザの身元を認識しない。
ドメイン内の分散サービスまたは分散計算エンジンを構成するプラットフォームは、その分散サービスまたは計算エンジンを記述し、ドメインにより署名されたグローバルラベルを有する他のプラットフォームと協調することが好ましい。
このモデルは、特に、ドメイン用の計算センターなどの特定のプラットフォームの組に属するように構成されたプラットフォーム群に適用可能である。
【００５６】
別の好ましい１つの使用方法では、ドメインは、あるプラットフォームまたは特定のプラットフォームで単数または複数のユーザの存在を要求することがある。
その場合、ユーザのプラットフォームは、ユーザの保証書をそのドメインに渡すことができる。
しかし、プラットフォームは、特定の単数または複数のユーザが存在しているときにだけ特定のラベルをエクスポートできることが好ましく、これはユーザが実際に存在していることを検証するためのプラットフォームの役割である。
プラットフォームは、パスワード、生体測定値、位置、スマートカードなどのセキュリティトークンを含む任意の従来の認識方法を使用して、ユーザが存在していることを証明することができる。
このモデルは、ユーザがＰＤＡを所有していて、ドメイン内の計算リソースを使用したいと望むときに特に適用可能である。
ある意味では、ユーザのプラットフォームは、ネットワークに関する限りユーザのトークンになり得る。
【００５７】
プラットフォームには、身元の秘密とグローバルラベルの使用を制御するための信頼されている機構が必要である。
身元の秘密は、プラットフォームがラベルに関連付けられているエンジン／サービスに対応する状態にある場合にだけ、所与のラベルに署名のためにＴＰＭに使用されることが好ましい。
１つの適切な機構は、ＴＣＰＡのＴＰＭ＿ＳＥＡＬ機構とＴＰＭ＿ＵＮＳＥＡＬ機構との適合形態である。
プラットフォーム内の現在のｐｃｒインデックスのｐｃｒ値が［ｐｃｒインデックス、ｐｃｒ値］の復号値と一致した場合にだけＴＰＭはＵＮＳＥＡＬ（封印解除）されている平文データをＴＰＭからエクスポートすることを思い出す必要がある。
本発明の目的のために、ラベルが平文データとして使用され、ｐｃｒインデックスとｐｃｒ値はラベルに関連付けられているエンジン／サービスのソフトウェア状態に対応する値となる。
その代わりに、ＴＰＭは、ラベルとＰＣＲを格納しているだけで、正しいソフトウェア状態が検出されたときにだけそれらを公開するように設定することもできる。
ラベルとＰＣＲの組が、プラットフォームの展開前にＴＰＭにあらかじめロードされていることが好ましい。
あらかじめロードされていることにより、プラットフォームには有用な身元の組が提供済みであるため、プラットフォームのユーザの負担が減少する。
これらの身元のあらゆる更新または保守は、エンティティ、好ましくはプラットフォームとやりとりするすべての第三者から信頼されているドメインにより実行されることが好ましい。
更新や保守を実行するためには、ドメインは何らかの特定のエンジン／サービスと対応させたいと望んでいるプラットフォームの状態を決定して、同一の情報をドメイン内のすべてのプラットフォームにブロードキャストすることが好ましい。
ブロードキャストの一部は、新規または更新されたアプリケーション／ドメインソフトウェアの配布であることが好ましい。
ブロードキャストの別の一部は、対応する新規または更新されたソフトウェア計測値（ＰＣＲ）のＴＰＭへの配布であることが好ましく、そのような情報はドメインの私有鍵を使用して署名される。
各ＴＰＭは、ＴＰＭに製造時または初期化時にあらかじめロードされている同一の公開鍵を使用して、新規の情報を同一の方法で検証することが好ましい。
【００５８】
プラットフォームのソフトウェア状態が、プラットフォームが最小限の要件の組（エンジンおよび／またはサービスの保護）を執行し、プラットフォームがセキュリティ処理を実行して、そのセキュリティ処理をプラットフォーム上のアプリケーションから隠すエンティティを含む状態でない限り、プラットフォームの身元によりラベルが承認されないことが好ましい。
このような処理を実行するラベルで、所与のエンジン／サービスに関連付けられていないラベルは、プラットフォームの「ルートラベル」と呼ばれる。
このラベルは、プラットフォームが最低限の要件を満たすときの署名に使用可能である。
他のラベルを組み込んだ署名の作成は、ラベルに関連付けられた計算エンジンおよび／またはサービスの存在により決まることが好ましい。
宣伝だけの場合は、プラットフォームは任意の既存のエンジンおよび／またはサービスと潜在的なエンジンと潜在的なサービスとの組み合わせからなることが好ましい。
適切なチャレンジ（「量子チャレンジ」という名前が適切なのは明白であろう）をプラットフォームが受け取ると、チャレンジはプラットフォームに、プラットフォームが実際にサポートしている状態が何かを判断させることが好ましい。
プラットフォームは、すべての実際の状態をチャレンジ元に対して見えるようにしてもよい。
その代わりに、チャレンジを受けたプラットフォームは、（可能なら）チャレンジを受けたエンジン／サービスをインスタンス化し、従来の暗号応答をチャレンジ元に返してラベルに関連付けられたエンジン／サービスの提供を認めるだけでもよい。
【００５９】
第１のプラットフォームが目的のプラットフォームが特定のサービスを提供することを検証したいときには、第１のプラットフォームは「量子チャレンジ」を目的のプラットフォームに送る。
目的のプラットフォーム内のＴＭＰは、その（ＰＣＲ）状態の計測値を調べる。
所望の状態が存在する場合、チャレンジの受け取りに際してプラットフォームがその状態に入るか、あるいはすでにその状態にあるため、ＴＰＭは適切なラベルをＵＮＳＥＡＬできることが好ましく、そのラベルに対応するプラットフォームの身元の秘密を使用して（ラベルを含む）その応答に署名することが好ましい。
つまり、ＴＰＭは、プラットフォームの身元の秘密（またはその身元ラベルに特に割り当てられた秘密）を使用して、（量子チャレンジ内で受け取った）ナンスと所望のサービスに対応するラベルに署名する。
第１のプラットフォームは応答を受け取り、ナンスを確認し、ラベルを確認する。
それから第１のプラットフォームは信頼されている認証局、好ましくはドメインの公開鍵を使用して署名を確認する。
この署名の確認はオンラインでも可能であるが、製造時または初期化時にロードされた公開鍵を使用してオフラインで行うことが好ましい。
すべての確認に合格すると、第１のプラットフォームは目的のプラットフォームが特定のサービスを実行していると確信し、目的のプラットフォームと協調してサービスを使用または実行することを決定することができる。
検証されたプラットフォームの身元とラベルが十分な信頼を提供する場合、そのような確認だけが必要ある。
組織および／またはドメインの内部にあるサービスの場合にも、このような確認ですむことがある。
【００６０】
サービスの使用または提供に認証や識別ではなく支払いが要求され、サービスを要求する側がお金を電子形式で有する場合、必要な額の電子マネーがある位置のプラットフォーム間で送金されるだけであることが好ましい。
【００６１】
サービスの使用または実行に支払いが必要な場合、サービスを要求する側は、支払い情報を提供することが求められる。
これは、クレジットカード番号やクレジットカードの署名の形態をとることが好ましい。
クレジットカード番号は、プラットフォームに属していたり、ユーザに属していることがある。
プラットフォームに属している場合、クレジットカード番号がプラットフォームに格納されていることが好ましく、ＴＰＣＡのＴＰＭ＿ＳＥＡＬコマンドにより提供される形態のような安全な形態で格納されることが好ましい。
クレジットカード番号がユーザに属する場合、番号はプラットフォームに格納することが可能であり、安全な形態で格納され、ユーザからの許可後に公開されることが好ましい。
その代わりに、ユーザがプラットフォームに番号を提供することもできる。
クレジットカードの署名の秘密がプラットフォームに属する場合、秘密はプラットフォームに格納され、ＴＰＣＡのＴＰＭ＿ＳＥＡＬコマンドにより提供されるような安全な形態で格納されることが好ましく、要求への署名に使用される。
クレジットカードの秘密がユーザに属する場合、秘密をプラットフォームに格納し、ユーザのプラットフォームによる識別時および／またはプラットフォームによるユーザの識別時および／またはユーザによる許可時に、要求への署名に使用することができる。
クレジットカードの秘密がユーザに属する場合、スマートカードなどのトークンに秘密を格納し、ユーザのプラットフォームによる識別時および／またはプラットフォームによるユーザの識別時に要求への署名に使用することができる。
使用しなければならないプロトコルは、ＰＯＳ端末で使用されるプロトコルと同様のまたは同じプロトコルとすることができる。
次に、支払いを要求しているエンティティは既存のＶＩＳＡ（商標）またはＭａｓｔｅｒｃａｒｄ（商標）ネットワークなどの既存の信販会社を使用して支払いの承認を検証する。
【００６２】
ユーザ認証が必要な場合は、同じ認証がそのユーザのすべての承認に使用されることが好ましい（もちろん、複数の認証／承認値を使用することもできるが、より複雑になる）。
このユーザ認証がサービスに対する支払いの能力と意思も示していることが好ましい。
ただし、本発明では、ユーザ認証を提供する値は、必ずしも真の秘密である必要はなく、ユーザにより保護され、ユーザが何らかのプロセスに許可を与える環境で使用され、ユーザと検証側以外のエンティティにも潜在的に見える値であればよい。
【００６３】
したがって、このユーザ認証は、単純な番号（たとえば磁気カード上に格納された値）であれ署名の秘密（たとえばスマートカード上に格納されている）であれ、クレジットカードの属性を有することが好ましい。
【００６４】
サービスの使用または実行に支払いは必要ないが認証および／または識別が必要な場合は、支払いと本質的に同一のプロセスが使用可能である。
違いは、信販会社は、支払いを要求するのではなく、認証／識別情報を検証するのに使用されるだけである。
信販会社は、このサービスの提供に何らかの課金をすることもある。
実際、信販会社は、信販会社が提供しない場合ドメインが提供しなければならないＰＫＩを提供することで支払いを受けている。
使用しなければならないプロトコルは、ＰＯＳ端末で使用されるプロトコルと同様のまたは同じプロトコルとすることができる。
その代わりに、単純なプロトコルを使用することもできる。
カードの署名の秘密の場合には、たとえば、ドメインおよび／または信販会社により作成されたナンスの署名にカードが要求されることもある。
【００６５】
サービスの使用または実行に支払いは必要ないが認証および／または識別が必要な場合は、支払いプロセスと同様のプロセスが使用可能である。
違いは、何らかの識別および／または認証サーバを使用して、支払いを要求するのではなく、認証／識別情報を検証するだけである。
【００６６】
プラットフォームが、ラベルに、たとえルートラベルにでも、関連付けられた振る舞いをしている場合、そのソフトウェア環境は、ユーザのデータとアプリケーションを他のユーザに属しているデータやアプリケーションによる妨害や覗き見から保護することが好ましい。
当業者は、この処理にコンパートメントや仮想マシンが適していることに気付くであろう。
１つのコンパートメントまたは仮想マシンの情報は、他のコンパートメントまたは仮想マシン上での不正な妨害や覗き見から保護される。
【００６７】
プラットフォームが、ラベルに、たとえルートラベルにでも、関連付けられた振る舞いをしている場合、そのソフトウェア環境は、コンパートメントおよび／または仮想マシンを提供する機構と協調するセキュリティサービスを含むことが好ましい。
このセキュリティサービスは、コンパートメントおよび／または仮想マシン内で実行されているエンジンとサービスのためにすべてのセキュリティサービスを実行することが好ましい。
また、セキュリティサービスは、このプラットフォームと通信している他のプラットフォームのラベルを検証することが好ましい。
セキュリティサービスは、受信メッセージが正しいラベルを含む正しい署名を有することを確認することもできる。
セキュリティサービスは、プラットフォームのＴＰＭと協調して、正しいラベルを組み込みながら送信メッセージに署名することもできる。
セキュリティサービスは、プラットフォーム間のＤｉｆｆｉｅ−Ｈｅｌｌｍａｎプロトコルを管理し、必要に応じて安全なチャネルを設定したり廃棄することが好ましい。
セキュリティサービスは、アクティブなセッションの合間に、別のプラットフォームおよび／またはユーザに属するデータおよび／またはアプリケーションを格納するために使用される秘密のためのすべてのストレージを管理することが好ましい。
さらに、セキュリティサービスは、以前の特許出願「Performing a service on a computer」（前述）で記述されたように、アプリケーション用に他のセキュリティサービスを実行することが好ましい。
セキュリティサービスは、そのホストコンピュータ上のアプリケーションにより管理されることが好ましいが、ローカルプラットフォーム上でリモートプラットフォーム用のデータとアプリケーションとエンジンとサービスを管理しているそのリモートプラットフォームからポリシーを受け入れることが好ましい。
ローカル管理アプリケーションは、それらのポリシーに優先する手段を提供しないことが好ましいが、受け入れられない条件下でのプロセスの実行を拒否することができる。
【００６８】
本発明の一態様は、クライアントとサーバ間の区別を取り除くことで、本発明をピアツーピアアーキテクチャに移行する修正である。
本発明のこの態様は、クライアントがその能力を宣伝することで、特定のサービスに参加する。
クライアントは、クライアントが特定のサービスに参加可能であることを記述した署名された証明書を作成することが好ましい。
証明書は、クライアントのＴＰＭの身元を使用してサービスのラベルに署名することにより作成されることが好ましい。
証明書は、クライアントがサービスに参加可能であることを示しているが、証明書が掲示された時点でクライアントが参加を望んでいることや、さらには参加可能であることを示していないことが好ましい。
クライアントは証明書を宣伝サービスに掲示することが好ましい。
このプロセスは、前述のサーバが従う手続きに類似していて、その手続きでは、サーバはサービスを記述しているラベルに署名して、証明書を宣伝サービスに掲示して、サーバがサービスを提供可能であることを示すが、サーバがサービスを実際に提供していることは示さない。
クライアントは、宣伝サービスに追加の証明書を掲示することも好ましく、その証明書は信頼されているドメインによって署名されたクライアントの公開鍵であり、クライアントが参加可能なサービス（ラベル）をクライアントが正確に記述していることについて信頼可能であることを示したドメインによる証明書である。
この場合も、この動作は、前述のサーバの動作に類似している。
【００６９】
別の態様は、従来の取り消し機構と許可機構を提供する修正である。
前述のシステムでは、サーバが参加可能なサービス（ラベル）をサーバが記述していることについて信頼可能であるというドメインによる証明内容を宣伝サービスに掲示することが好ましい。
本発明のこの態様では、ドメインが宣伝サービスを制御して、自身がクライアントとサーバの両方の証明内容を掲示することが好ましい。
これにより、ドメインは特定のコンピュータがサービスに参加可能かどうかを動的に制御することができる。
ドメインが宣伝サービスを制御しない場合、クライアントとサーバは、証明内容を宣伝サービスに掲示することが好ましいが、ドメインは取り消し証明書を宣伝サービスに掲示することが好ましい。
従って、コンピュータは、宣伝サービスを訪問しているときには、クライアントおよび／またはサーバがサービスに参加するかどうかと、クライアントおよび／またはサーバがサービスへの参加を許可されているかどうかとを知ることができる。
クライアントとサーバの両方が宣伝サービスを定期的に訪問し、証明内容と取り消し証明書の存在および／または不在を使用して、クライアントとサーバの所与のサービスへの参加の提供の許可を更新することが好ましい。
【００７０】
本明細書で説明するすべての特徴は、前述の任意の態様と任意に組み合わせることができる。
【発明を実施するための最良の形態】
【００７１】
本発明の具体的な実施形態を実例として添付の図面を参照して以降で説明する。
【００７２】
図１は、好ましくはシステムの製造時または初期化時のいずれかに、プラットフォーム−ｎ  １００、保証証明書１１４、保証書１１６、クレジットカード番号１２３、保証書１１９からなるシステム内に存在する情報を示している。
プラットフォーム−ｎ  １００内のＴＰＭ  １０１は、信頼されているドメイン−Ａの公開鍵１０２を有する。
ＴＰＭ  １０１は、非対称鍵対の秘密（身元）鍵１０３である、プラットフォームの身元の証明に使用される統計学的に一意の秘密も有する。
対応する公開（身元）鍵１１２は、信頼されているドメイン−Ａにより署名されている（１１３）保証書（証明書）１１４内に存在する。
ＴＰＭ  １０１は、ラベル１０４、１０６も有する（ただし、すべてのＴＰＭがすべてのラベルを有するわけではない）。
１つのラベル１０４は、サービス−Ｘを表す。
別のラベル１０６は、エンジン−Ｙを表す。
ＴＰＭ  １０１は、サービス−Ｘに関連する計測値に対応する値１０５を有している。
ＴＰＭ  １０１は、エンジン−Ｙに関連する計測値に対応する値１０７を有している。
各エンジン／サービスの各ラベル１０４、１０６は、エンジン／サービスに関連する計測値に対応する値の組１０５、１０７に関連付けられている（１０８、１０９）。
プラットフォーム−ｎ  １００は、プログラム１２５も備えている。
プログラムの組１１０は、サービス−Ｘを提供する。
プログラムの組１１１は、エンジン−Ｙを提供する。
ラベル１０４に関連付けられた値の組１０５は、プラットフォーム１００がプログラム１１０を実行している場合に取得されなければならない計測結果に対応する。
ラベル１０６に関連付けられた値の組１０７は、プラットフォーム１００がプログラム１１１を実行している場合に取得されなければならない計測結果に対応する。
各プラットフォームは、プラットフォームがラベルの意味に合致した構成であることを保証するすべてのプログラム１１５も備える。
ラベル１０４は、信頼されているドメイン−Ａにより署名された（１１８）（Ｘ．５０９標準証明書の形態の）内部保証書１１６でもあり、ラベル１０４で表されるサービス−Ｘの記述への参照１１７を含んでいる。
ラベル１０６は、信頼されているドメイン−Ａにより署名された（１２１）内部保証書１１９（同じくＸ．５０９証明書）でもあり、ラベル１０６で表されるエンジン−Ｙの記述への参照１２０を含んでいる。
ユーザ１２３は、クレジットカード番号１２２および／またはクレジットカードの署名の秘密１２４を有する。
【００７３】
図２は、プラットフォーム−１  １００、プラットフォーム−２  ２００、プラットフォーム−３  ２０２、プラットフォーム−４  ２０３の４つのプラットフォームを示している。
プラットフォーム−１  １００は、ＴＰＭ  １０１とプログラム１２５を備える。
プラットフォーム−２  ２００は、ＴＰＭ  ２０５とプログラム２０６を備える。
プラットフォーム−３  ２０２は、ＴＰＭ  ２０７とプログラム２０８を備える。
プラットフォーム−４  ２０３は、ＴＰＭ  ２０９とプログラム２１０を備える。
各ＴＰＭ  １０１、２０５、２０７、２０９は、関連付けられたプラットフォーム１００、２００、２０２、２０３がエンジンを提供することおよび／またはサービスに参加することについて信頼可能なことを証明することができる。
外部クレジット検証サービス２０４も図示されている。
通信設備２０１（たとえばインターネットまたはＬＡＮ）は、すべての４つのプラットフォームとクレジット検証サービスを接続する。
各プラットフォーム１００、２００、２０２、２０３内のプログラム１２５、２０６、２０８、２１０は、それぞれ少なくともセキュリティサービス（たとえば、図１のプラットフォーム−１  １００用の１１５）とサービスを提供するためのアプリケーション（たとえば、同じく図１のプラットフォーム−１  １００用の１１０、１１１）を提供する。
【００７４】
図３は、Ｗｅｂサービスページを示している。
各プラットフォーム（１００、２００、２０２、２０３）は、潜在的に提供可能なエンジンとサービスを（Ｗｅｂページを使用して）宣伝する。
この特定のサービスページ３０１の情報は、サービス−Ｘを提供可能なプラットフォームを宣伝している。
情報の組３０３は、プラットフォーム−１  １００からのサービス−Ｘの潜在的な可用性を宣伝している。
情報は、プラットフォーム−１により署名されたラベル−Ｘ  １０４の証明書３０９、ドメイン−Ａにより署名されたプラットフォーム−１の公開鍵の証明書１１４、プラットフォーム−１  １００のＩＰアドレス３０２を含んでいる。
別の情報の組３０６は、プラットフォーム−２  ２００からのサービス−Ｘの潜在的な可用性を宣伝している。
情報は、プラットフォーム−２により署名されたラベル−Ｘの証明書３０８、ドメイン−Ａにより署名されたプラットフォーム−２の公開鍵の証明書３０４、プラットフォーム−２  ２００のＩＰアドレス３０５を含んでいる。
他のプラットフォームの同様の情報３０７が使用可能な場合もある。
情報は、ドメイン−Ａにより署名されたラベル−Ｘの証明書１１６とその記述を含んでいる
【００７５】
図４は、プラットフォーム−１  １００がＷｅｂページ３０１の参照後、プラットフォーム−２  ２００上でサービス−Ｘを使用するプロセスを示した流れ図である。
列４０１は、プラットフォーム−１  １００でのイベントを示している。
列４０２は、プラットフォーム−２  ２００でのイベントを示している。
列４０３は、Ｗｅｂサーバでのイベントを示している。
【００７６】
ステップ−１  ４０４では、プラットフォーム−１  １００がＷｅｂサービスページ３０１を訪問する。
サービスページ３０１は、たとえば、周知のアドレスで広く公開されている、かつ／または使用可能である。
【００７７】
ステップ−２  ４０５では、プラットフォーム−１  １００は、証明書３０９、１１３、３０８、３０４、１１６と他のプラットフォームの証明書が正しく署名されていることを検証する。
【００７８】
ステップ−３  ４０６では、信頼されているドメイン−Ａが証明書３０４内のプラットフォーム２の公開鍵に署名し、信頼されているドメイン−Ａが証明書１１６内のラベルＸとサービス−Ｘの記述に署名し、プラットフォーム−２の私有鍵により証明書３０８内のサービス−Ｘのラベルが署名されているため、プラットフォーム−１  １００は、プラットフォーム−２  ２００がサービス−Ｘを提供可能なことを知る。
【００７９】
ステップ−４  ４０７では、プラットフォーム−１  １００は、ＩＰアドレス３０５を使用してプラットフォーム−２  ２００に連絡して、プラットフォーム−１からプラットフォーム−２へのチャレンジを使用してサービス−ＸのラベルＸに対応するサービスの提供を要求する。
【００８０】
ステップ−５  ４０８では、プラットフォーム−２  ２００は、プログラム１１０を使用してサービス−Ｘを開始しようと試みる。
試みが成功すると、次にプラットフォーム−２  ２００内のＴＰＭ  ２０５による計測により、サービス−Ｘに関連付けられたラベルＸ  １０４の使用が許可されたことがＴＰＭ  ２０５に示される。
【００８１】
ステップ−６  ４０９では、プラットフォーム−２  ２００は、（受け取ったチャレンジの）ラベルＸとナンス４１０にその秘密鍵を使用して署名して、結果４１１をプラットフォーム−１  １００に送り返す。
【００８２】
ステップ−７  ４１２では、プラットフォーム−１  １００は、プラットフォーム−２  ２００の署名を検証し、それにより、プラットフォーム−２  ２００がサービス−Ｘの存在を認めていることを検証する。
【００８３】
ステップ−８  ４１５では、プラットフォーム−２  ２００が任意選択で同様の試験をプラットフォーム−１  １００上で実施して、プラットフォーム−１  １００もサービス−Ｘを備えていることを検証する。
【００８４】
ステップ−９  ４１６では、プラットフォーム−１  １００とプラットフォーム−２  ２００は協調して、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎプロトコルを使用して安全なチャネルを設定する。
【００８５】
ステップ−１０  ４１７では、プラットフォーム−１  １００とプラットフォーム−２  ２００は、サービスを実行し、それぞれの秘密鍵で署名されラベルＸを含むデータ４１８、４１９を渡すことでサービス−Ｘを提供し、使用する。
【００８６】
図５は、プラットフォーム−３  ２０２がプラットフォーム−４  ２０３上でエンジン−Ｙを使用するプロセスを示す流れ図である。
列５０１は、プラットフォーム−３  ２０２のユーザのイベントを示している。
列５０２は、プラットフォーム−３  ２０２でのイベントを示している。
列５０３は、プラットフォーム−４  ２０３でのイベントを示している。
列５０４は、Ｗｅｂサイトでのイベントを示している。
列５０５は、クレジット検証サービス２０４でのイベントを示している。
エンジン−Ｙの使用ではユーザ認証が必要なため、プロトコルは、図４のステップ−１  ４０４からステップ−９  ４１６をステップ１０  ４１７まで実行する。
【００８７】
図５のステップ−１０  ５０７では、プラットフォーム３  ２０２はそのユーザにユーザに関連付けられたクレジットカード番号の使用を許可するかどうかを質問する。
【００８８】
ステップ−１１  ５０８では、ユーザは、クレジットカード番号をプラットフォーム−３  ２０２に入力することで許可を与える。
【００８９】
ステップ−１２  ５０９では、プラットフォーム−３  ２０２は、ステップ９  ４１６で設定されたプラットフォーム−３  ２０２とプラットフォーム−４  ２０３との間の安全なチャネルを介してクレジットカード番号をプラットフォーム−４  ２０３に送る。
【００９０】
ステップ−１３  ５１０では、プラットフォーム−４  ２０３は、本発明の範囲外のプロトコルにより信販会社２０４に連絡する。
【００９１】
ステップ−１４  ５１１では、信販会社２０４は、プラットフォーム−４  ２０３に対してクレジットカード番号の有効性を認める。
この場合、信販会社２０４は、クレジットカード番号の所有者に簡単に課金できるが、プラットフォーム−４  ２０３にこのサービスについて課金する。
【００９２】
最後に、ステップ−１５  ５１２では、プラットフォーム−３  ２０２とプラットフォーム−４  ２０３は、プラットフォーム−４上でエンジンをインスタンス化し、エンジン上でプラットフォーム−３により提供されるデータとアプリケーションを実行することでエンジン−Ｙを提供して利用する。
送受信されるデータ５１３は、それらの私有鍵で署名され、ラベルＹを含んでいる。
【００９３】
図６は、プラットフォーム−２がサービス−Ｘを提供し、プラットフォーム−４がエンジン−Ｙを提供する好ましいアーキテクチャを示している。
この例では、プラットフォーム−２  ２００とプラットフォーム−４  ２０３がコンパートメント−１  ６０２内でサービス−Ｘ（プログラム１、２、３  １１０により提供される）を実行し、コンパートメント−２  ６０３内でエンジン−Ｙ（プログラム１、６、８  １１１により提供される）を実行する。
セキュリティサービス６０５もコンパートメント６０４内で実行することができる。
おそらくカーネルソフトウェアを含んでいる他のソフトウェア処理６０１は、プラットフォーム１と２のコンパートメント属性を実現し提供する。
セキュリティサービス６０５は、サービス−Ｘとエンジン−Ｙ用のすべてのセキュリティを提供する。
セキュリティサービス６０５は、外界とサービス−Ｘとの間に介入してメッセージ６０６、６０７を受け取る。
セキュリティサービス６０５は、外界とエンジン−Ｙとの間に介入してメッセージ６０６、６０８を受け取る。
【００９４】
図７は、プラットフォームを保守かつ／または更新するプロセスを示す流れ図である。
列７０１は、ドメイン−Ａのイベントを示している。
列７０２は、ドメイン−Ａ内のプラットフォームのイベントを示している。
【００９５】
ステップ−１  ７０３では、ドメイン−Ａは、既存のラベル−ｎに関連付けられる新規の値に署名し、｛ラベル−ｐとその関連付けられた値｝の新規の組に署名し、新規のプログラムに署名する。
【００９６】
ステップ−２  ７０４では、ドメイン−Ａは、それらの新規のデータをそのドメイン内のすべてのプラットフォームに送る。
【００９７】
ステップ−３  ７０５では、各プラットフォームのＴＰＭ  １０１、２０５、２０７、２０９は、受け取るデータの署名を各ＴＰＭに格納されたドメイン−Ａの公開鍵を使用して検証する。
ステップ−４  ７０６では、プログラムはプラットフォームに格納され、ＴＰＭ  １０１、２０５、２０７、２０９内のラベル−ｎに関連付けられた値は、新規の値に置き換えられ、｛ラベル−Ｐとそれに関連付けられた値｝の新規の組がＴＰＭ  １０１、２０５、２０７、２０９内に組み込まれる。
【００９８】
前述の説明では、１つのドメインがプラットフォームを管理し、サービスを提供／管理していることを仮定している。
しかし、そのような仮定が必要なわけではない。
その代わりに、１つのドメインがプラットフォームを管理し、別のドメインがサービスを定義／提供することも実現可能である。
さらに、重要な変更点の１つは、ラベルを使用するときに、プラットフォームはプラットフォームによるラベルの解釈の記述に署名して提供しなければならないことである。
これは、第２のプラットフォームが第１のプラットフォームの特定のラベルの意味を確実に推理できるようにするために必要になる。
プラットフォーム−１は、たとえば保証書３０８（ここではプラットフォーム−１により署名されたラベル）を修正して保証書３０８がプラットフォーム−１により実施されたとおりのラベルの正確な意味を含むようにすることで、この記述を提供することができる。
これは、たとえば、保証書３０８を修正して、署名されたラベルの意味の記述である別の保証書１１６への参照を含むようにすることで実施可能である。
【００９９】
さまざまなドメインがプラットフォームとサービスを提供している場合、プラットフォームのドメインにより提供されるサービスを使用して、プラットフォームに外部のサービスを組み込んで更新することができる。
【０１００】
また、さまざまなドメインがプラットフォームとサービスを提供している場合、プラットフォームのドメインにより提供されるエンジンサービスを使用して、プラットフォーム内でサービスドメインのためにサービスを提供することができる。
【０１０１】
本明細書で説明したシステムとプロトコルにより、セキュリティ要件が大幅に減少し、システム内の秘密の総数が減少し、そのためセキュリティシステムの簡素化を有利に行うことができるので、大きな利点を持つ。
また、セキュリティインフラストラクチャが、アプリケーションとエンジンから独立しているため、アプリケーションとエンジンの効率が高まる。
【０１０２】
本明細書では、ＴＣＰＡの仕様を具体的に参照して計算プラットフォームを説明した。
しかし、ＴＣＰＡの仕様は計算プラットフォームの信頼されるコンポーネントの例に過ぎず、他の種類の信頼されるコンポーネントも、本明細書にて説明した本発明に同様に適用可能である。
【産業上の利用可能性】
【０１０３】
本発明は、情報セキュリティシステムとして利用可能である。
【図面の簡単な説明】
【０１０４】
【図１】計算プラットフォーム内の情報を示す概略図である。
【図２】４つの計算プラットフォーム間の関係を示す概略図である。
【図３】潜在的に使用可能なサービスを示したＷＷＷサービスページの概略図である。
【図４】第１と第２の計算プラットフォーム間の通信プロセスを示す流れ図である。
【図５】第３と第４の計算プラットフォーム間の通信を示す流れ図である。
【図６】第２と第４の計算プラットフォームがサービス／エンジンを提供するアーキテクチャの概略図である。
【図７】プラットフォームを保守または更新するプロセスを示す流れ図である。
【符号の説明】
【０１０５】
１００・・・プラットフォーム、
１０２・・・公開鍵ドメインＡ、
１０３・・・プラットフォーム−秘密身元鍵、
１０４，１０６・・・ラベル、
１１０，１１１・・・プログラム、
１１２，１１８，１２１・・・公開身元鍵、
１１３・・・ドメイン、
１１５・・・セキュリティサービス、
１２２・・・番号、
１２４・・・秘密、
１００，２００，２０２，２０３・・・プラットフォーム、
１２５，２０６，２０８，２１０・・・プログラム、
２０１・・・ネットワーク、
２０４・・・クレジットサービス、
３０１・・・サービスＸ、
３０２，３０５・・・ＩＰアドレス、
１１６・・・ラベル、
【図１】
2004537095.tif 000003
【図２】
2004537095.tif 000004
【図３】
2004537095.tif 000005
【図４】
2004537095.tif 000006
【図５】
2004537095.tif 000007
【図６】
2004537095.tif 000008
【図７】
2004537095.tif 000009
【国際公開パンフレット】
2004537095.tif 000010
2004537095.tif 000011
2004537095.tif 000012
2004537095.tif 000013
2004537095.tif 000014
2004537095.tif 000015
2004537095.tif 000016
2004537095.tif 000017
2004537095.tif 000018
2004537095.tif 000019
2004537095.tif 000020
2004537095.tif 000021
2004537095.tif 000022
2004537095.tif 000023
2004537095.tif 000024
2004537095.tif 000025
2004537095.tif 000026
2004537095.tif 000027
2004537095.tif 000028
2004537095.tif 000029
2004537095.tif 000030
2004537095.tif 000031
2004537095.tif 000032
2004537095.tif 000033
2004537095.tif 000034
2004537095.tif 000035
2004537095.tif 000036
2004537095.tif 000037
2004537095.tif 000038
2004537095.tif 000039
2004537095.tif 000040
2004537095.tif 000041
2004537095.tif 000042
2004537095.tif 000043
2004537095.tif 000044
2004537095.tif 000045
2004537095.tif 000046
2004537095.tif 000047
2004537095.tif 000048
2004537095.tif 000049
2004537095.tif 000050
2004537095.tif 000051
2004537095.tif 000052
2004537095.tif 000053
2004537095.tif 000054
2004537095.tif 000055
2004537095.tif 000056
2004537095.tif 000057
2004537095.tif 000058
2004537095.tif 000059
2004537095.tif 000060
2004537095.tif 000061
【国際公開パンフレット（コレクトバージョン）】
2004537095.tif 000062
【国際調査報告】
2004537095.tif 000063
2004537095.tif 000064
2004537095.tif 000065
2004537095.tif 000066
2004537095.tif 000067