JP5745690B2 - マルチテナントサービスプロバイダによるダイナミックプラットフォームの再構成 - Google Patents

Description

本願は概してコンピュータシステムに係り、特に、サービスプロバイダによって、これらコンピュータシステムの機能を選択的に実行することに関する。

コンピュータシステムおよびそのコンポーネントの中には、１セットの機能を提供されているものがあり、そのなかにはエンドユーザによる購入時点にはアクティブではないものもある。購入後の、たとえば料金を貰った後などに、サービスプロバイダが、今はエンドユーザが所有しているプラットフォームの機能をアクティブにする権限を与えられている。

このような事例の１つとして、一定のプロセッサ速度を可能とするために一定のスキューレートで販売されるコンピュータがある。所定のサービスプロバイダは、サービスプロバイダが提供を目指すサービスを提供するためにより速いスピードを実現しようとするだろう。そしてサービスプロバイダは、プロセッサの製造業者と取決めを行い、サービスプロバイダが、販売時点の速度よりも速いスキューレートをアクティベートしようとするだろう。このような機能をアクティベートする際には、サービスプロバイダから製造業者への料金が発生することが想定される。サービスプロバイダは次に、アクティベートされた機能（高速になったスキューレートの場合）を、サービスプロバイダが提供する他の機能とセット売りする（bundle）ことができる。

本発明の一実施形態の概略を示す。

本発明の一実施形態のエンドツーエンドのアクティベートフローを示す。

本発明の一実施形態のフローチャートを示す。

本発明の一実施形態のサービスプロバイダの鍵となる構造を示す。

本発明の一部の実施形態では、マルチテナントのサービスプロバイダによるダイナミックプラットフォーム再構成が可能である。言い換えると、一定のハードウェアデバイス製造業者が、１を超える数のサービスプロバイダに対して、製造業者のハードウェアのエンドユーザにサービスを提供する権限を与えることができる。これは、場合によっては、他のサービスプロバイダが、最初のサービスプロバイダがコストを負担する等によりアクティベートしたハードウェアの機能を利用する可能性から最初のサービスプロバイダを保護する鍵構造を利用して実装されてよい。

一例としては、一定のサービスプロバイダが、製造業者が販売したプロセッサにもともとプロビジョンされているものよりも速いスキューレートを提供することを望む場合がある。サービスプロバイダは、許可サービスを利用してこれを行ってよい。サービスプロバイダは、コンポーネント製造業者に料金を払って、プロセッサ内の向上した機能をアクティベートする許可書を取得することができる。しかし、そのサービスプロバイダは、第２のサービスプロバイダが、同じ向上した機能を、より高いスキューレートでエンドユーザに利用させることを望まないだろう（最初のサービスプロバイダはアップグレードのために支払っており、料金を払わずにその機能を得た第２のサービスプロバイダと同じ条件で競争できないから）。

同時に、ハードウェアデバイスの製造業者は、ハードウェアデバイスのアップグレード権を販売することを望む場合もある。これにより、製造業者の収入が増え、製造業者のエンドユーザ／顧客に対して、より多くのサービスを提供することができるようになる。

一部の実施形態では、これらそれぞれ異なる機会は、それぞれ別のサービスプロバイダに、エンドユーザのプラットフォームの同じハードウェアデバイスと協働させることができる許可書および証明スキームの組み合わせによって達成されてよい。ハードウェアデバイスの機能がサービスプロバイダによって利用可能となったとき、これは、サービスプロバイダを特定する証明書によって利用可能とされ、第２のサービスプロバイダが、ハードウェアデバイスの製造業者に料金を支払わずに、同じアクティベートされた機能を単に利用することができないようにされる。

図１の参照に戻ると、一実施形態では、クラウドまたは連続したコンピューティング環境を利用することができる。クラウド１５は、任意の数のサービスプロバイダサーバ１２と任意の数の許可サーバ１４とを含んでよいが、この例では１つの許可サーバのみが示されている。一実施形態では、任意の数のプラットフォーム１１が、クラウドを通じて、サービスプロバイダサーバと通信してよく、サービスプロバイダサーバは、許可サーバ（１または複数）と、クラウドを通じて通信してよい。

ストレージ１７は、管理エンジン１０に連結されていてよい。ストレージは、光、半導体、または磁気メモリであってよい。

したがって、サービスを一定のプラットフォーム１１に提供することを望むサービスプロバイダは、サービスを提供する必要があるプラットフォーム１１の機能のアクティベートを試みることができる。たとえばサービスプロバイダは、任意のプラットフォームの動作速度を向上させて、サービスプロバイダがプラットフォームにしてもらいたい一定の事柄を効率よくするために必要な速度で動作させようとするだろう。

一実施形態では、サービスプロバイダは、許可サーバに接触して、向上のための許可証を得る。一部の場合には、許可は、サービスプロバイダが課すコストを支払うことで得られてよい。一実施形態では、第３者のプラットフォームをアップグレードするためにサービスプロバイダにより料金が課されてもよい。サービスプロバイダには、プラットフォーム１１の所有者その他の実体からその料金が支払われるだろう。

サービスプロバイダは、許可証をプラットフォーム１１内の管理エンジン１０に提示する。管理エンジン１０は、サービスプロセッサまたは補助プロセッサであってよく、一部の実施形態では、これらは、プラットフォームの中央処理装置とは別の異なる（separate and apart from）第２のプロセッサである。しかし他の構成もまた可能である。一部の実施形態では、管理エンジンは、プラットフォームの残りの部分によりアクセスが許可されなくてもよい。

管理エンジン１０は、次に、プラットフォーム１１の機能を修正する前に、許可証が正しいかを検証してよい。これにより、プラットフォームの乱用が防がれ、プラットフォームおよび／または管理エンジンを販売した製造業者のための支払いスキームを、おそらくは低コストで（プラットフォームの全ての機能がアクティベートされていないので）実行してよい。

次にプラットフォームの機能がアクティベートされると、一実施形態では、第２のサービスプロバイダはプラットフォーム１１上のその機能を利用することができない、というのも、機能は、ある特定のサービスプロバイダに関連付けられている証明書との関連においてのみアクティベートできるからである。したがって、このような実施形態では、証明書を持たない他のサービスプロバイダは、プラットフォーム上でアクティベートされた機能の利用を可能とすることができない。これにより、無料でロードしたサービスプロバイダが、他のサービスプロバイダがアクティベートした機能からの利益を享受することがないようにして、不平等なコストに基づいて競争が行われないようにする。

図２に示す一実施形態では、３つの実体が関係していてよい。これらは管理エンジンまたの名をＭＥ１０、サービスプロバイダサーバ１２、および許可サーバ１４である。

一部の実施形態では、管理エンジン１０は、ホスト（つまりプラットフォーム）ベースのネットワークの脅威から守られた処理を実行することができる。言い換えると、管理エンジンは、プラットフォーム１１自身のみからではなく、プラットフォームの外部にあるが、それに対してネットワーク経由で接続されているデバイスからも隔離されている。管理エンジンは、サービスプロバイダおよび許可サーバの両方から信用されていてよく、これにより、プラットフォームのリソースおよび実行コンテキストを保護してよい。

一部の実施形態では、サービスプロバイダは、非対称鍵と身元保護技術とに基づいてプラットフォームの所有者にサービスを提供する。許可サーバは、サービスプロバイダおよびプラットフォームエンドユーザのために、プラットフォームの機能のアクティベートを実行する前に、サービスプロバイダがプラットフォームまたは管理エンジンの製造業者と適切で積極的な取引関係（appropriate, active business relationship）をもっていることを確認することができる。

したがって、最初に、管理エンジン１０でローカルに鍵が生成されてよい（１６で示すように）。この鍵は、どの自由なトランザクションを実行するためにも利用できないことから、最初はアクティベートされていない。そして１８に示すように、管理エンジンとサービスプロバイダとの間にセキュアなチャネルまたはシグマチャネル（sigma channel）が構築される。シグマチャネルとは、Ｉｎｔｅｌ Ｍｅｄｉａ Ｖａｕｌｔ技術で利用される用語であるが、本発明の一部の実施形態ではいずれのセキュアなチャネルを実装してもよい。たとえばシグマチャネルは、エンドユーザにリリースされる前に管理エンジンに内蔵された、署名付きのＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵を利用してよい。一実施形態では、シグマチャネルが、Ｉｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎから入手可能な向上したプライバシー識別またはＥＰＩＤ技術を利用してよい。ＥＰＩＤは、デバイスの所有者のプライバシーを保護しつつ、ハードウェアデバイスの遠隔認証を可能とする暗号スキームである。埋め込まれたＥＰＩＤ秘密鍵をもつハードウェアデバイスは、遠隔にある実体に、所有者の身元を明かさず、かつ、検証者が認証に関与することなく、自身が、ハードウェア製造業者の証明を受けた、有効なデバイスであることを証明する。

同じ鍵を利用して、プラットフォームが本物であることを証明してよい。たとえば、本物である場合とは、許可サーバを制御し、プラットフォームの機能をアクティベートする権限をサービスプロバイダに与える製造業者が（管理エンジンを含む）製造したもののような場合である。鍵はさらに、管理エンジンの環境を報告するために利用されてよい（遠隔位置に対するそのファームウェアのハッシュおよびバージョン情報を含む）。加えて、鍵は、公開鍵をサービスプロバイダに開示する際に利用されることで、サービスプロバイダが鍵を検証して、プラットフォームが本物であると立証することができる。

シグマチャネルは、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵交換を行い、管理エンジンとサービスプロバイダとの間で共有対称鍵を生成してよく、一方で、ＥＰＩＤを利用して、管理エンジンが正規であることを証明してよい。サービスプロバイダは、管理エンジンの製造業者が発行する証明書を提示して、管理エンジンが、製造業者が許可したサービスプロバイダを検証することができるようにしてよい。そして２０で示すように、サービスプロバイダは、鍵の無効化リスト（ＧＲＰ−ＲＬ、ＰＲＩＶ‐ＲＬおよびＳＩＧ−ＲＬが特定する）およびサービスプロバイダの検証のための従来の無効リスト（ＣＲＬ）を提供するために、許可サーバ１４を利用してよい。したがって、権利が無効化されているサービスプロバイダは、管理エンジンによって簡単に特定することができ、許可されたサービスプロバイダのみが、管理エンジンを含むプラットフォームの機能を修正できるようにしてよい。

そして２２で示すように、サービスプロバイダは、無効化リストを管理エンジンに供給して、ＥＰＩＤ署名処理が、サービスプロバイダにＥＰＩＤ署名無効化ステータスを判断させるプルーフを含んでよい。管理エンジンは、サービスプロバイダの証明書の無効化ステータスを受信する。別の実施形態では、管理エンジンが、無効化リストを加工することができない場合、代わりに、サービスプロバイダ経由で代理をしているオンライン証明書ステータスプロトコル（ＯＣＳＰ）応答システムを利用することができる。ＲＦＣ２５６０.１１、Ｘ．５０９Ｉｎｔｅｒｎｅｔ Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｏｎｌｉｎｅ Ｃｅｒｔｉｆｉｃａｔｅ Ｓｔａｔｕｓ Ｐｒｏｔｏｋｃｏｌ Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ１９９９年６月を参照のこと。

そして管理エンジンは、ノンスおよび無効化リストに署名をして（ブロック２４で示す）、セキュアなプロトコルハンドシェークを完了する。加えて、許可サーバに転送するための、鍵に対する証明書署名要求（ＣＳＲ）がサービスプロバイダに供給される。証明書署名要求には、一実施形態では、鍵およびそのデフォルトの構成属性の正当性を証明するためのＥＰＩＤ署名された属性が含まれてよい。管理エンジンは、次に、許可サーバから許可証の要求を開始する。

次に、２５で示すように、証明機関（ＣＡ）バックエンドとの関連で動作しているサービスプロバイダが、ＣＳＲを証明する。この検証は、鍵のＥＰＩＤ署名を検証することを含む。ＣＡ署名は、ＣＳＲに含まれる情報が正当であると主張するので、ＥＰＩＤ証明も検証する必要がある。

２６で、ＣＡバックエンドは、鍵の証明書を発行するが、これには、鍵がどのように保護されているかを示す拡大証明書(certificate extension)が含まれてよい。これは、ＣＳＲに含まれているＥＰＩＤ証明をその証明書にコピーすることで達成されてよい。

この後で、２７で、サービスプロバイダは、許可要求を許可サーバに中継して、許可サーバが利用するために鍵をアクティベートすることを許可してよい。この許可証は、さらに、サービスプロバイダが、鍵の利用に影響を与えるポリシーに対して管理統制を行うことを許可してもよい。

次に、２８で、許可サーバは、許可要求を検証して、サービスプロバイダの取引契約書が、鍵のアクティベートをサポートしているか、および、管理エンジンの機能をサポートしているかをチェックする。許可サーバはさらに、一部の実施形態では、管理エンジンが、サービスプロバイダが要求する機能をサポートすることができるかを検証してもよい。

許可サーバは、さらに、適切な場合に、管理エンジンが、サービスプロバイダで利用する鍵をアクティベートすることを許可する許可証（３０で示す）を発行してよい。こうして、サービスプロバイダは、ユーザプラットフォーム、および、その他のプラットフォームが鍵を利用して交信することができる方法を制御するポリシーを構成することを許可される。これにより、サービスプロバイダは、事実上の、鍵のポリシーの所有者になる。３１で、許可サーバは、サービスプロバイダおよびアクティベートイベントを詳述するログを更新するが、これは、一部の実施形態でサービスプロバイダに課金するために利用されてよい。

次に、３２で、許可サーバが発行する許可証がサービスプロバイダのサーバに提供される。許可証は、特定のプラットフォームおよび特定の鍵に固有であってよい。もしも第２または第３の鍵が作成された場合には、この第２または第３のサービスプロバイダを、鍵の所有者として利用することができる。

一部の実施形態では、３４で、サービスプロバイダが、許可サーバと管理エンジンとの間の許可フローを監視する。サービスプロバイダはさらに、許可証が、正当な許可サーバからのものであるか検証して、サービスプロバイダは、許可サーバのアクティベートのログ（３３で示す）を更新してよい。許可サーバおよびサービスプロバイダのログは、オフラインで、なんらかの取引契約に従って会計の詳細を監査するために比較されてよい。

最後に、管理エンジンは、鍵をアクティベートして、管理エンジンの機能を可能としたり、フィルタリングしたりすることで、許可証をインストールする。たとえばサービスプロバイダは、強い多要素認証（strong multi-factor authentication）を利用することが許されていてよく、これにより、セキュアな証明に関してサービスプロバイダが、一定のポリシーを構成できるように、管理エンジンを構成することができる。この一例が、Ｗｈａｔ Ｙｏｕ Ｓｅｅ Ｉｓ Ｗｈａｔ Ｙｏｕ Ｓｉｇｎであり、この技術では、署名されたメッセージの内容が変更されない（ＷＹＳＩＷＹＳ）。

本発明の一実施形態では、図３に示すフローチャートが、管理エンジンに関するソフトウェア、ハードウェア、またはファームウェアで実装されてよい。ソフトウェアの実施形態では、命令シーケンスが不揮発性コンピュータ可読媒体に格納されてよい（たとえば光、磁気、または半導体記憶素子など）。

ブロック４０から、管理エンジンによってサービスプロバイダとの間でセキュアなセッションが構築されて、所望のサービスのためにレジスタ格納が行われてよい。管理エンジンは、サービスプロバイダの公開鍵を得てよく、または、別の例では、一回限りのパスワード（ＯＴＰ）シード（１度のみのログインについて有効である）を、セキュアなチャネル（たとえばシグマチャネル）でネゴシエートしてよい（ブロック４２に示す）。そして管理エンジンが、サービスプロバイダの公開鍵またはシードを所有者のプリンシパルオブジェクトに格納する（ブロック４４に示す）。

次にブロック４６で、管理エンジンが、プラットフォームの身元と構成とを鍵ＥＰＩＤを利用して許可サーバに対して証明する。この証明は、サービスプロバイダによって中継される。そして管理エンジンは、一部の実施形態では、ブロック４８で示すように、製造時に管理エンジンにプロビジョンされたアクティベートプリンシパルを利用してこのプリンシパルのための証明を得て、検証する。管理エンジンは次にダイアモンド５２で、許可証が大丈夫かをチェックする。大丈夫ではない場合には、シグマチャネルを閉じてクリーンアップを実行することで（７２に示す）トランザクションを無効にする。許可証が大丈夫な場合には、一実施形態で、管理エンジンが、プリンシパルメタデータにアクティブビットを真に設定することで（ブロック５４で示す）、このプリンシパルまたはサービスプロバイダをアクティベートする。

管理エンジンは、このプリンシパルがアクティブなときに許可されたプラットフォーム機能のリストのインスタンスを作成することで（instantiate）許可証をインストールする（ブロック５６に示す）。そして管理エンジンは、５８で利用するプリンシパルを待つ。プリンシパルの構造も、６０で管理エンジンにロードされる。ダイアモンド６２のチェックは、プリンシパルがアクティベートされたかを判断する。アクティベートされている場合には、許可証の構造内の管理エンジンの機能のそれぞれについて（ブロック６４）、ダイアモンド６３のチェックによって、該機能がアクティブかを判断する。アクティブな場合には、その機能をブロック６６でアクティベートして、プリンシパル（鍵またはシード）にオペレーションを実行して、その後フローを戻す（７０）。

図２および図３に示すシーケンスは、ハードウェア、ソフトウェア、および／またはファームウェアで実装されてよい。ソフトウェアの実施形態では、シーケンスは、非一時的コンピュータ可読媒体（たとえば光、磁気、または半導体メモリであって、例としてストレージ１７を含む）に格納されている命令により実装されてよい。ストレージ１７は、さらに、製造業者が含む署名付き鍵と、プラットフォームの機能をアクティベートした特定のサービスプロバイダを特定する鍵またはシードとを格納してよい。

したがって一部の実施形態では、プラットフォームリソースの所有権を複数のサービスプロバイダに拡張することができる。しかし一部のリソースは共有されない（たとえば鍵またはシード）が、他のリソース（たとえば管理エンジンの実行環境等）は共有される。許可証は、どのリソースが、サービスプロバイダによる利用を許可されているかを示す。プラットフォームはさらに、セキュアなインタフェース（ＨＥＣＩ（host embedded controller interface）など）に到達する要求に基づいて、リソースに対するアクセス制御をダイナミックに実行してよい。管理エンジンは、コマンドにサービス提供するとき利用される鍵およびシードの経過を追うことで、サービスプロバイダ間を区別することができる。したがって、鍵またはシードがセッションを認証する。セッションは、許可証を利用して、管理エンジンおよびプラットフォームのどのリソースがセッションに見えるかを知ることができる。

認証されたセッションによって、サービスプロバイダはサービス提供物（offering）をセット売りする（bundle）ことができる（たとえば、向上したプラットフォームが提供する他の技術とセットで売られる盗難防止サービスを提供する）。一部の実施形態では、許可証が、セット売り構成を特定する。セット売りによって、各サービスプロバイダが、サービスプロバイダに固有のセキュリティおよび設定ポリシーを特定することができるようになる。たとえばあるサービスプロバイダが、２要素認証が必要であると指定したが、他のサービスプロバイダは、３要素認証を指定して、また別のサービスプロバイダは、認証を指定しない、という場合もある。

図４は、ユーザまたはマシンのプリンシパルを表す管理リソースの一実施形態を示す。各プリンシパルは、他のプリンシパルおよび利用ポリシーと関連付けられていてよい。各オブジェクトクラスは、以下のように説明することができる。プリンシパルまたは主要なプリンシパルは、１．．ｍの濃度（cardinality）を有してよい。プリンシパルは、公開および秘密のコンポーネントを含んでいる鍵であってよい。秘密のコンポーネントは、鍵の値が管理エンジンの外部でとられるときはいつも、機密性を確保するためにラッピングされていてよい（wrapped）。公開鍵は、Ｘ．５０９の証明書のコンテキストで利用されるときＳｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙとして知られているものであってよい。スイス、ジュネーブの国際電気通信連合から入手可能な、ＩＴＵ−Ｔ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｘ．５０９（２００５）Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ、Ｔｈｅ Ｄｉｒｅｃｔｏｒｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ ０８／０５を参照のこと。鍵が別のシステムまたはデバイスとの交信に利用される場合には、エンドポイントを示すのはプリンシパルの実体である。プリンシパルがユーザを認証するために利用される場合には、プリンシパルがユーザのために「代弁」する。プリンシパルに関連付けられているオブジェクトが、プリンシパルがユーザを代理または代弁する方法について制約を課す。

所有者のプリンシパル８０は１．．１の濃度を有している。所有者のプリンシパルは、プリンシパルの管理統制権をもつサービスプロバイダのことである。所有者のプリンシパルは、所有者の実体を認証して所有者の実体と通信するために利用される鍵８６を含んでいる。また、所有者の証明書を認証するために利用されるサービスプロバイダの公開鍵を含んでいてもよい。さらに、管理エンジンとサービスプロバイダとの間のセキュアなセッションに対応するセッション鍵（ＳＫ）とマスター鍵（ＭＫ）とを含んでもよい。

アンカープリンシパル８２は、０．．ｍの濃度を有している。所有者のプリンシパルは、他のデバイスまたはサーバとセキュアな接続を構築する際に、このアンカープリンシパルが信任することができる信任アンカーを設定する。

アクティベートプリンシパル８４は、１．．１の濃度を有している。アクティベートプリンシパルは、許可サーバを認証するために利用される認証情報（credential）のことを示す。これら認証情報は、オンボードで、管理エンジンを含み、サービスプロバイダの遠隔制御によってチップセットの機能をＯＮ／ＯＦＦ切り替えする機能をもつ特定のチップセットに提供されてよい。アクティベートトランザクション識別子（たとえばＴＸ１）は、このコンテキストの一部であり、主要なプリンシパルのアクティベート状態を含む。

デバイス識別子９０は、０．．ｍの濃度を有している。管理エンジンが、信任されているメッシュまたはクラウドの一部として認識しているデバイスは、デバイス識別子を有している場合がある。所有者のプリンシパルは、デバイス識別子を、予め設定されている設定ポリシーに従って構成してよい。

プリンシパルメタデータ９２は、１．．１の濃度を有しており、鍵のマイクレーション、バックアップ、および復旧処理を記述する設定を含んでいる。利用の制約（たとえば鍵を署名、暗号化、または鍵交換に利用することができるか否か）が、プリンシパルメタデータの一部であってよい。

利用ポリシー８８は、０．．１の濃度を有しており、鍵の利用においてポリシーにより制御される一群の制約のことである。これには、ユーザのプレゼンスを構築する方法のための多要素認証（ＭＦＡ）規則を含んでよい。たとえばユーザのプレゼンスは、一実施形態では、ユーザが認識している、またはマウスの利用の署名パターンおよびコンピュータシステムに、コンピュータのユーザを特定させる表示により構築されてよい。プライバシーポリシーは、この鍵が署名または暗号化する情報量を制約することができる。デジタル権管理ポリシーも、この鍵で保護されているデータが他のデバイスによって再配信される（redistributed）方法を制約することができる。

ユーザのプレゼンス９４は、０．．ｍの濃度をもち、サービスプロバイダと、ユーザのプレゼンスにプルーフを与える技術のためのユーザ設定可能構成値とを含んでいてよい。これにはＷＹＳＩＷＹＳ、近距離無線通信（ＮＦＣ）、トラステッド入出力（ＩＯ）、およびその他のプレゼンスポリシーが含まれてよい。

濃度０．．ｍをもつコンテキスト９６は、主要なプリンシパルを利用するときに利用可能なプラットフォームの機能および性能を含む。コンテキストソースは、センサ入力（たとえばほんの数例を挙げると、位置、向き、近接度、温度、電力、およびバッテリ）を含んでよい。

タスク情報９８は、０．．ｍの濃度を持ち、主要プリンシパルを利用する管理エンジン環境を説明する証明コンテキストを含む。

本明細書における「１つの実施形態」または「一実施形態」といった言い回しは、その実施形態との関連で記載されている特定の特徴、構造、または特性が、本発明に含まれる少なくとも１ついの実装例に含まれていることを示している。したがって「１つの実施形態」または「一実施形態」という言い回しは、必ずしも同じ実施形態のことを示しているわけではない。さらに、特定の特徴、構造、または特性が、示されている特定の実施形態以外の他の適切な形態で実装されてもよく、これらすべての形態が本願の請求項の範囲には含まれることが意図されている。

本発明を、限られた数の実施形態を参照して説明してきたが、当業者には複数の変形例および修正例が明らかである。添付請求項では、これらすべての変形例および修正例を、本発明の真の精神および範囲内に含まれることが意図されている。
［項目１］
命令を備える非一時的なコンピュータによる読み取り可能な媒体であって、前記命令は、プロセッサに、
サービスプロバイダの、前記プロセッサに連結されているプラットフォームの機能の利用の許可を検証せよとの要求を送信する段階と、
前記サービスプロバイダが前記プロセッサの製造業者によって、前記機能の利用を許可されていることを検証する段階と、
前記サービスプロバイダによる利用に限って、前記機能をアクティベートする段階と
を実行させる、媒体。
[項目２]
前記プロセッサに、サービスプロバイダのサーバから、前記プロセッサに連結されている前記プラットフォームの機能をアクティベートせよとの要求を受信する段階を実行させる命令をさらに格納する、項目１に記載の媒体。
[項目３]
前記プロセッサの製造業者が前記プロセッサに組み込んだ署名付き鍵を利用する段階を実行させる命令をさらに格納する、項目１に記載の媒体。
[項目４]
前記プラットフォームの所有者のプライバシーを保護しつつ、ハードウェアデバイスの遠隔認証を可能とする暗号スキームを利用して、前記プロセッサ内に埋め込まれた秘密鍵を利用して、前記サービスプロバイダが前記プロセッサの前記製造業者によって証明されていることを示す段階を実行させる命令をさらに格納する、項目１に記載の媒体。
[項目５]
前記プロセッサが本物であることを示すプルーフを提供する段階を実行させる命令をさらに格納する、項目１に記載の媒体。
[項目６]
サービスプロバイダに対して、前記プロセッサの鍵が本物か否かを証明する、署名付きの属性を含む、証明書署名要求を提供する段階を実行させる命令をさらに格納する、項目１に記載の媒体。
[項目７]
前記サービスプロバイダに前記機能の利用を許可すべく、許可証を受信して、鍵をアクティベートする段階を実行させる命令をさらに格納する、項目１に記載の媒体。
[項目８]
前記プロセッサで、サービスプロバイダの公開鍵または１回限りのパスワードシードをセキュアチャネル経由で受信する段階を実行させる命令をさらに格納する、項目１に記載の媒体。
[項目９]
前記プロセッサで、少なくとも２つのサービスプロバイダのそれぞれについての別の公開鍵またはシードを格納して、前記機能を再度アクティベートするよう要求するサービスプロバイダを識別する段階を実行させる命令をさらに格納する、項目８に記載の媒体。
[項目１０]
前記サービスプロバイダの認証が無効化されているかを判断する段階を実行させる命令をさらに格納する、項目１に記載の媒体。

Claims (21)

1. 管理エンジンで、サービスプロバイダのサーバから、前記管理エンジンに連結されているプラットフォームの機能をアクティベートせよとの要求を受信する段階と、
   前記要求に呼応して、前記サービスプロバイダが前記管理エンジンの製造業者によって、前記プラットフォームの機能の利用を許可されていることを示す、許可サーバからの証明書を含む、前記サービスプロバイダが前記プラットフォームを修正できることを示す許可のプルーフを、セキュアな形態で前記サービスプロバイダに要求する段階と、
   前記証明書をチェックして、別のサービスプロバイダが前記機能を利用しないようにする段階と
   を備える方法。
2. 前記サービスプロバイダが前記管理エンジンの製造業者によって前記機能を利用することが許可されていることを確認する段階と、
   前記サービスプロバイダによる使用のみのために前記機能をアクティベートする段階と
   を備える、請求項１に記載の方法。
3. 前記サービスプロバイダの許可が無効化されているかをチェックする段階を備える、請求項１または２に記載の方法。
4. 前記プルーフを要求する段階は、
   前記管理エンジン内に、アクティベートされていない鍵を生成する段階を含む、請求項１から３のいずれか一項に記載の方法。
5. 前記製造業者が前記管理エンジンに組み込んだ署名付き鍵を利用して、前記プルーフを要求する段階を含む、請求項１から４のいずれか一項に記載の方法。
6. デバイスの所有者のプライバシーを保護しつつ、ハードウェアデバイスの遠隔認証を可能とする暗号スキームを利用し、かつ、前記サービスプロバイダが前記管理エンジンの前記製造業者によって証明されていることを示すべく前記管理エンジン内に埋め込まれた秘密鍵を利用して、プルーフを要求する段階を備える、請求項１から５のいずれか一項に記載の方法。
7. 前記プルーフを要求する段階は、
   前記管理エンジンが本物であることを示すプルーフを提供する段階を含む、請求項１から６のいずれか一項に記載の方法。
8. 前記要求する段階は、
   サービスプロバイダに対して、前記管理エンジンの鍵が本物か否かを証明する、署名付きの属性を含む、証明書署名要求を提供する段階を含む、請求項１から７のいずれか一項に記載の方法。
9. 前記要求に応答して、前記サービスプロバイダに前記機能の利用を許可すべく、前記管理エンジンが許可証を受信して、鍵をアクティベートする段階を備える、請求項１から８のいずれか一項に記載の方法。
10. 前記要求に応答して、前記管理エンジンで、サービスプロバイダの公開鍵または１回限りのパスワードのシードをセキュアチャネル経由で受信する段階を備える、請求項１から９のいずれか一項に記載の方法。
11. 前記管理エンジンに、少なくとも２つのサービスプロバイダのそれぞれについての別の公開鍵またはシードを格納して、前記鍵またはシードを利用して、前記機能を再度アクティベートするよう要求するサービスプロバイダを識別する段階を備える、請求項１０に記載の方法。
12. プロセッサの製造業者が提供した署名付き鍵を格納し、前記プロセッサに連結されているプラットフォームの機能をアクティベートせよとの要求を受信し、前記要求に応答して、サービスプロバイダが前記プラットフォームを修正できることを示す許可のプルーフをセキュアなチャネルで自動的に前記サービスプロバイダに要求し、前記サービスプロバイダからの前記プルーフに含まれる証明書をチェックして、別のサービスプロバイダが前記機能を利用しないようにする前記プロセッサと、
    前記プロセッサに連結されているストレージと
    を備える装置。
13. 前記プロセッサは、管理エンジンである、請求項１２に記載の装置。
14. 前記プロセッサは、前記サービスプロバイダからの証明書をチェックして、前記サービスプロバイダが、前記プロセッサの前記製造業者によって前記プラットフォームの機能を利用することを許可されているかを判断する、請求項１２または１３に記載の装置。
15. 前記プロセッサは、前記サービスプロバイダの許可が無効化されているかをチェックする、請求項１４に記載の装置。
16. 前記プロセッサは、デバイスの所有者のプライバシーを保護しつつ、ハードウェアデバイスの遠隔認証を可能とする暗号スキームを利用して、前記サービスプロバイダにプルーフを要求し、かつ、前記プロセッサは、製造時点に管理エンジン内に埋め込まれた秘密鍵を利用して、前記サービスプロバイダが前記プロセッサの前記製造業者によって証明されていることを示す、請求項１４または１５に記載の装置。
17. 前記プロセッサは、真正なプルーフを提供する、請求項１２から１６のいずれか一項に記載の装置。
18. 前記プロセッサは、サービスプロバイダに対して、前記プロセッサの鍵が本物か否かを証明する、署名付きの属性を含む、証明書署名要求を提供する、請求項１２から１７のいずれか一項に記載の装置。
19. 前記プロセッサは、前記サービスプロバイダに前記機能の利用を許可すべく、許可証を受信して、鍵をアクティベートする、請求項１２から１８のいずれか一項に記載の装置。
20. 前記プロセッサは、サービスプロバイダの公開鍵または１回限りのパスワードのシードをセキュアチャネル経由で受信する、請求項１２から１９のいずれか一項に記載の装置。
21. 前記プロセッサは、管理エンジンに、少なくとも２つのサービスプロバイダのそれぞれについての別の公開鍵またはシードを格納して、前記鍵またはシードを利用して前記機能を再度アクティベートするよう要求するサービスプロバイダを識別する、請求項２０に記載の装置。

Images