管理エンジンで、サービスプロバイダのサーバから、前記管理エンジンに連結されているプラットフォームの機能をアクティベートせよとの要求を受信する段階と、前記要求に呼応して、前記サービスプロバイダが前記管理エンジンの製造業者によって、前記プラットフォームの機能の利用を許可されていることを示す、許可サーバからの証明書を含む、前記サービスプロバイダが前記プラットフォームを修正することができることを示す許可のプルーフを、セキュアな形態のプルーフによって、要求する段階と、前記証明をチェックして、別のサービスプロバイダが前記機能を利用しないようにする段階とを備える方法。前記サービスプロバイダの許可が無効化されているかをチェックする段階を備える、請求項1に記載の方法。前記プルーフを要求する段階は、前記管理エンジン内に、アクティベートされていない鍵を生成する段階を含む、請求項1に記載の方法。前記プルーフを要求する段階は、前記製造業者が前記管理エンジンに組み込んだ署名付き鍵を利用する段階を含む、請求項1に記載の方法。デバイスの所有者のプライバシーを保護しつつ、ハードウェアデバイスの遠隔認証を可能とする暗号スキームを利用してプルーフを要求して、前記管理エンジン内に埋め込まれた秘密鍵を利用して、前記サービスプロバイダが前記管理エンジンの前記製造業者によって証明されていることを示す段階を備える、請求項1に記載の方法。前記プルーフを要求する段階は、前記管理エンジンが本物であることを示すプルーフを提供する段階を含む、請求項1に記載の方法。前記要求する段階は、サービスプロバイダに対して、前記管理エンジンの鍵が本物か否かを証明する、署名付きの属性を含む、証明書署名要求を提供する段階を含む、請求項1に記載の方法。前記要求に応答して、前記サービスプロバイダに前記機能の利用を許可すべく、前記管理エンジンが許可証を受信して、鍵をアクティベートする段階を備える、請求項1に記載の方法。前記要求に応答して、前記管理エンジンで、サービスプロバイダの公開鍵または1回限りのパスワードシードをセキュアチャネル経由で受信する段階を備える、請求項1に記載の方法。前記管理エンジンに、少なくとも2つのサービスプロバイダのそれぞれについての別の公開鍵またはシードを格納して、前記鍵またはシードを利用して、前記機能を再度アクティベートするよう要求するサービスプロバイダを識別する段階を備える、請求項9に記載の方法。命令を備える非一時的なコンピュータによる読み取り可能な媒体であって、前記命令は、プロセッサに、サービスプロバイダの、前記プロセッサに連結されているプラットフォームの機能の利用の許可を検証せよとの要求を送信する段階と、前記サービスプロバイダが前記プロセッサの製造業者によって、前記機能の利用を許可されていることを検証する段階と、前記サービスプロバイダによる利用に限って、前記機能をアクティベートする段階とを実行させる、媒体。前記プロセッサに、サービスプロバイダのサーバから、前記プロセッサに連結されている前記プラットフォームの機能をアクティベートせよとの要求を受信する段階を実行させる命令をさらに格納する、請求項11に記載の媒体。前記プロセッサの製造業者が前記プロセッサに組み込んだ署名付き鍵を利用する段階を実行させる命令をさらに格納する、請求項11に記載の媒体。前記プラットフォームの所有者のプライバシーを保護しつつ、ハードウェアデバイスの遠隔認証を可能とする暗号スキームを利用して、前記プロセッサ内に埋め込まれた秘密鍵を利用して、前記サービスプロバイダが前記プロセッサの前記製造業者によって証明されていることを示す段階を実行させる命令をさらに格納する、請求項11に記載の媒体。前記プロセッサが本物であることを示すプルーフを提供する段階を実行させる命令をさらに格納する、請求項11に記載の媒体。サービスプロバイダに対して、前記プロセッサの鍵が本物か否かを証明する、署名付きの属性を含む、証明書署名要求を提供する段階を実行させる命令をさらに格納する、請求項11に記載の媒体。前記サービスプロバイダに前記機能の利用を許可すべく、許可証を受信して、鍵をアクティベートする段階を実行させる命令をさらに格納する、請求項11に記載の媒体。前記プロセッサで、サービスプロバイダの公開鍵または1回限りのパスワードシードをセキュアチャネル経由で受信する段階を実行させる命令をさらに格納する、請求項11に記載の媒体。前記プロセッサで、少なくとも2つのサービスプロバイダのそれぞれについての別の公開鍵またはシードを格納して、前記機能を再度アクティベートするよう要求するサービスプロバイダを識別する段階を実行させる命令をさらに格納する、請求項18に記載の媒体。前記サービスプロバイダの認証が無効化されているかを判断する段階を実行させる命令をさらに格納する、請求項11に記載の媒体。プロセッサの製造業者が提供した、署名付き鍵を格納して、前記プロセッサに連結されているプラットフォームの機能をアクティベートせよとの要求を受信して、前記要求に応答して、サービスプロバイダが前記プラットフォームを修正することを示す許可のプルーフをセキュアなチャネルで自動的に要求する前記プロセッサと、前記プロセッサに連結されているストレージとを備える装置。前記プロセッサは、管理エンジンである、請求項21に記載の装置。前記プロセッサは、前記サービスプロバイダからの証明書をチェックして、前記サービスプロバイダが、前記プロセッサの前記製造業者によって前記プラットフォームの機能を利用することを許可されているかを判断して、前記サービスプロバイダが、前に前記機能をアクティベートしたサービスプロバイダと同じであるかを判断する、請求項21に記載の装置。前記プロセッサは、前記サービスプロバイダの許可が無効化されているかをチェックする、請求項23に記載の装置。前記プロセッサは、デバイスの所有者のプライバシーを保護しつつ、ハードウェアデバイスの遠隔認証を可能とする暗号スキームを利用して、前記サービスプロバイダにプルーフを要求して、前記プロセッサは、管理エンジン内に埋め込まれた秘密鍵を利用して、前記サービスプロバイダが前記プロセッサの前記製造業者によって証明されていることを示し、前記埋め込まれた秘密鍵は、製造時点に埋め込まれる、請求項23に記載の装置。前記プロセッサは、真正なプルーフを提供する、請求項21に記載の装置。前記プロセッサは、サービスプロバイダに対して、前記プロセッサの鍵が本物か否かを証明する、署名付きの属性を含む、証明書署名要求を提供する、請求項21に記載の装置。前記プロセッサは、前記サービスプロバイダに前記機能の利用を許可すべく、許可証を受信して、鍵をアクティベートする、請求項21に記載の装置。前記プロセッサは、サービスプロバイダの公開鍵または1回限りのパスワードシードをセキュアチャネル経由で受信する、請求項21に記載の装置。前記プロセッサは、管理エンジンに、少なくとも2つのサービスプロバイダのそれぞれについての別の公開鍵またはシードを格納して、前記鍵またはシードを利用して前記機能を再度アクティベートするよう要求するサービスプロバイダを識別する、請求項29に記載の装置。本発明の一部の実施形態では、マルチテナントのサービスプロバイダによるダイナミックプラットフォーム再構成が可能である。言い換えると、一定のハードウェアデバイス製造業者が、1を超える数のサービスプロバイダに対して、製造業者のハードウェアのエンドユーザにサービスを提供する権限を与えることができる。これは、場合によっては、他のサービスプロバイダが、最初のサービスプロバイダがコストを負担する等によりアクティベートしたハードウェアの機能を利用する可能性から最初のサービスプロバイダを保護する鍵構造を利用して実装されてよい。一例としては、一定のサービスプロバイダが、製造業者が販売したプロセッサにもともとプロビジョンされているものよりも速いスキューレートを提供することを望む場合がある。サービスプロバイダは、許可サービスを利用してこれを行ってよい。サービスプロバイダは、コンポーネント製造業者に料金を払って、プロセッサ内の向上した機能をアクティベートする許可書を取得することができる。しかし、そのサービスプロバイダは、第2のサービスプロバイダが、同じ向上した機能を、より高いスキューレートでエンドユーザに利用させることを望まないだろう最初のサービスプロバイダはアップグレードのために支払っており、料金を払わずにその機能を得た第2のサービスプロバイダと同じ条件で競争できないから。同時に、ハードウェアデバイスの製造業者は、ハードウェアデバイスのアップグレード権を販売することを望む場合もある。これにより、製造業者の収入が増え、製造業者のエンドユーザ/顧客に対して、より多くのサービスを提供することができるようになる。一部の実施形態では、これらそれぞれ異なる機会は、それぞれ別のサービスプロバイダに、エンドユーザのプラットフォームの同じハードウェアデバイスと協働させることができる許可書および証明スキームの組み合わせによって達成されてよい。ハードウェアデバイスの機能がサービスプロバイダによって利用可能となったとき、これは、サービスプロバイダを特定する証明書によって利用可能とされ、第2のサービスプロバイダが、ハードウェアデバイスの製造業者に料金を支払わずに、同じアクティベートされた機能を単に利用することができないようにされる。図1の参照に戻ると、一実施形態では、クラウドまたは連続したコンピューティング環境を利用することができる。クラウド15は、任意の数のサービスプロバイダサーバ12と任意の数の許可サーバ14とを含んでよいが、この例では1つの許可サーバのみが示されている。一実施形態では、任意の数のプラットフォーム11が、クラウドを通じて、サービスプロバイダサーバと通信してよく、サービスプロバイダサーバは、許可サーバ1または複数と、クラウドを通じて通信してよい。ストレージ17は、管理エンジン10に連結されていてよい。ストレージは、光、半導体、または磁気メモリであってよい。したがって、サービスを一定のプラットフォーム11に提供することを望むサービスプロバイダは、サービスを提供する必要があるプラットフォーム11の機能のアクティベートを試みることができる。たとえばサービスプロバイダは、任意のプラットフォームの動作速度を向上させて、サービスプロバイダがプラットフォームにしてもらいたい一定の事柄を効率よくするために必要な速度で動作させようとするだろう。一実施形態では、サービスプロバイダは、許可サーバに接触して、向上のための許可証を得る。一部の場合には、許可は、サービスプロバイダが課すコストを支払うことで得られてよい。一実施形態では、第3者のプラットフォームをアップグレードするためにサービスプロバイダにより料金が課されてもよい。サービスプロバイダには、プラットフォーム11の所有者その他の実体からその料金が支払われるだろう。サービスプロバイダは、許可証をプラットフォーム11内の管理エンジン10に提示する。管理エンジン10は、サービスプロセッサまたは補助プロセッサであってよく、一部の実施形態では、これらは、プラットフォームの中央処理装置とは別の異なるseparateandapartfrom第2のプロセッサである。しかし他の構成もまた可能である。一部の実施形態では、管理エンジンは、プラットフォームの残りの部分によりアクセスが許可されなくてもよい。管理エンジン10は、次に、プラットフォーム11の機能を修正する前に、許可証が正しいかを検証してよい。これにより、プラットフォームの乱用が防がれ、プラットフォームおよび/または管理エンジンを販売した製造業者のための支払いスキームを、おそらくは低コストでプラットフォームの全ての機能がアクティベートされていないので実行してよい。次にプラットフォームの機能がアクティベートされると、一実施形態では、第2のサービスプロバイダはプラットフォーム11上のその機能を利用することができない、というのも、機能は、ある特定のサービスプロバイダに関連付けられている証明書との関連においてのみアクティベートできるからである。したがって、このような実施形態では、証明書を持たない他のサービスプロバイダは、プラットフォーム上でアクティベートされた機能の利用を可能とすることができない。これにより、無料でロードしたサービスプロバイダが、他のサービスプロバイダがアクティベートした機能からの利益を享受することがないようにして、不平等なコストに基づいて競争が行われないようにする。図2に示す一実施形態では、3つの実体が関係していてよい。これらは管理エンジンまたの名をME10、サービスプロバイダサーバ12、および許可サーバ14である。一部の実施形態では、管理エンジン10は、ホストつまりプラットフォームベースのネットワークの脅威から守られた処理を実行することができる。言い換えると、管理エンジンは、プラットフォーム11自身のみからではなく、プラットフォームの外部にあるが、それに対してネットワーク経由で接続されているデバイスからも隔離されている。管理エンジンは、サービスプロバイダおよび許可サーバの両方から信用されていてよく、これにより、プラットフォームのリソースおよび実行コンテキストを保護してよい。一部の実施形態では、サービスプロバイダは、非対称鍵と身元保護技術とに基づいてプラットフォームの所有者にサービスを提供する。許可サーバは、サービスプロバイダおよびプラットフォームエンドユーザのために、プラットフォームの機能のアクティベートを実行する前に、サービスプロバイダがプラットフォームまたは管理エンジンの製造業者と適切で積極的な取引関係appropriateactivebusinessrelationshipをもっていることを確認することができる。したがって、最初に、管理エンジン10でローカルに鍵が生成されてよい16で示すように。この鍵は、どの自由なトランザクションを実行するためにも利用できないことから、最初はアクティベートされていない。そして18に示すように、管理エンジンとサービスプロバイダとの間にセキュアなチャネルまたはシグマチャネルsigmachannelが構築される。シグマチャネルとは、IntelMediaVault技術で利用される用語であるが、本発明の一部の実施形態ではいずれのセキュアなチャネルを実装してもよい。たとえばシグマチャネルは、エンドユーザにリリースされる前に管理エンジンに内蔵された、署名付きのDiffie-Hellman鍵を利用してよい。一実施形態では、シグマチャネルが、IntelCorporationから入手可能な向上したプライバシー識別またはEPID技術を利用してよい。EPIDは、デバイスの所有者のプライバシーを保護しつつ、ハードウェアデバイスの遠隔認証を可能とする暗号スキームである。埋め込まれたEPID秘密鍵をもつハードウェアデバイスは、遠隔にある実体に、所有者の身元を明かさず、かつ、検証者が認証に関与することなく、自身が、ハードウェア製造業者の証明を受けた、有効なデバイスであることを証明する。同じ鍵を利用して、プラットフォームが本物であることを証明してよい。たとえば、本物である場合とは、許可サーバを制御し、プラットフォームの機能をアクティベートする権限をサービスプロバイダに与える製造業者が管理エンジンを含む製造したもののような場合である。鍵はさらに、管理エンジンの環境を報告するために利用されてよい遠隔位置に対するそのファームウェアのハッシュおよびバージョン情報を含む。加えて、鍵は、公開鍵をサービスプロバイダに開示する際に利用されることで、サービスプロバイダが鍵を検証して、プラットフォームが本物であると立証することができる。シグマチャネルは、Diffie-Hellman鍵交換を行い、管理エンジンとサービスプロバイダとの間で共有対称鍵を生成してよく、一方で、EPIDを利用して、管理エンジンが正規であることを証明してよい。サービスプロバイダは、管理エンジンの製造業者が発行する証明書を提示して、管理エンジンが、製造業者が許可したサービスプロバイダを検証することができるようにしてよい。そして20で示すように、サービスプロバイダは、鍵の無効化リストGRP-RL、PRIV‐RLおよびSIG-RLが特定するおよびサービスプロバイダの検証のための従来の無効リストCRLを提供するために、許可サーバ14を利用してよい。したがって、権利が無効化されているサービスプロバイダは、管理エンジンによって簡単に特定することができ、許可されたサービスプロバイダのみが、管理エンジンを含むプラットフォームの機能を修正できるようにしてよい。そして22で示すように、サービスプロバイダは、無効化リストを管理エンジンに供給して、EPID署名処理が、サービスプロバイダにEPID署名無効化ステータスを判断させるプルーフを含んでよい。管理エンジンは、サービスプロバイダの証明書の無効化ステータスを受信する。別の実施形態では、管理エンジンが、無効化リストを加工することができない場合、代わりに、サービスプロバイダ経由で代理をしているオンライン証明書ステータスプロトコルOCSP応答システムを利用することができる。RFC256011、X.509InternetPublicKeyInfrastructureOnlineCertificateStatusProtokcolNetworkWorkingGroupRequestforComments1999年6月を参照のこと。そして管理エンジンは、ノンスおよび無効化リストに署名をしてブロック24で示す、セキュアなプロトコルハンドシェークを完了する。加えて、許可サーバに転送するための、鍵に対する証明書署名要求CSRがサービスプロバイダに供給される。証明書署名要求には、一実施形態では、鍵およびそのデフォルトの構成属性の正当性を証明するためのEPID署名された属性が含まれてよい。管理エンジンは、次に、許可サーバから許可証の要求を開始する。次に、25で示すように、証明機関CAバックエンドとの関連で動作しているサービスプロバイダが、CSRを証明する。この検証は、鍵のEPID署名を検証することを含む。CA署名は、CSRに含まれる情報が正当であると主張するので、EPID証明も検証する必要がある。26で、CAバックエンドは、鍵の証明書を発行するが、これには、鍵がどのように保護されているかを示す拡大証明書が含まれてよい。これは、CSRに含まれているEPID証明をその証明書にコピーすることで達成されてよい。この後で、27で、サービスプロバイダは、許可要求を許可サーバに中継して、許可サーバが利用するために鍵をアクティベートすることを許可してよい。この許可証は、さらに、サービスプロバイダが、鍵の利用に影響を与えるポリシーに対して管理統制を行うことを許可してもよい。次に、28で、許可サーバは、許可要求を検証して、サービスプロバイダの取引契約書が、鍵のアクティベートをサポートしているか、および、管理エンジンの機能をサポートしているかをチェックする。許可サーバはさらに、一部の実施形態では、管理エンジンが、サービスプロバイダが要求する機能をサポートすることができるかを検証してもよい。許可サーバは、さらに、適切な場合に、管理エンジンが、サービスプロバイダで利用する鍵をアクティベートすることを許可する許可証30で示すを発行してよい。こうして、サービスプロバイダは、ユーザプラットフォーム、および、その他のプラットフォームが鍵を利用して交信することができる方法を制御するポリシーを構成することを許可される。これにより、サービスプロバイダは、事実上の、鍵のポリシーの所有者になる。31で、許可サーバは、サービスプロバイダおよびアクティベートイベントを詳述するログを更新するが、これは、一部の実施形態でサービスプロバイダに課金するために利用されてよい。次に、32で、許可サーバが発行する許可証がサービスプロバイダのサーバに提供される。許可証は、特定のプラットフォームおよび特定の鍵に固有であってよい。もしも第2または第3の鍵が作成された場合には、この第2または第3のサービスプロバイダを、鍵の所有者として利用することができる。一部の実施形態では、34で、サービスプロバイダが、許可サーバと管理エンジンとの間の許可フローを監視する。サービスプロバイダはさらに、許可証が、正当な許可サーバからのものであるか検証して、サービスプロバイダは、許可サーバのアクティベートのログ33で示すを更新してよい。許可サーバおよびサービスプロバイダのログは、オフラインで、なんらかの取引契約に従って会計の詳細を監査するために比較されてよい。最後に、管理エンジンは、鍵をアクティベートして、管理エンジンの機能を可能としたり、フィルタリングしたりすることで、許可証をインストールする。たとえばサービスプロバイダは、強い多要素認証strongmultifactorauthenticationを利用することが許されていてよく、これにより、セキュアな証明に関してサービスプロバイダが、一定のポリシーを構成できるように、管理エンジンを構成することができる。この一例が、WhatYouSeeIsWhatYouSignであり、この技術では、署名されたメッセージの内容が変更されないWYSIWYS。本発明の一実施形態では、図3に示すフローチャートが、管理エンジンに関するソフトウェア、ハードウェア、またはファームウェアで実装されてよい。ソフトウェアの実施形態では、命令シーケンスが不揮発性コンピュータ可読媒体に格納されてよいたとえば光、磁気、または半導体記憶素子など。ブロック40から、管理エンジンによってサービスプロバイダとの間でセキュアなセッションが構築されて、所望のサービスのためにレジスタ格納が行われてよい。管理エンジンは、サービスプロバイダの公開鍵を得てよく、または、別の例では、一回限りのパスワードOTPシード1度のみのログインについて有効であるを、セキュアなチャネルたとえばシグマチャネルでネゴシエートしてよいブロック42に示す。そして管理エンジンが、サービスプロバイダの公開鍵またはシードを所有者のプリンシパルオブジェクトに格納するブロック44に示す。次にブロック46で、管理エンジンが、プラットフォームの身元と構成とを鍵EPIDを利用して許可サーバに対して証明する。この証明は、サービスプロバイダによって中継される。そして管理エンジンは、一部の実施形態では、ブロック48で示すように、製造時に管理エンジンにプロビジョンされたアクティベートプリンシパルを利用してこのプリンシパルのための証明を得て、検証する。管理エンジンは次にダイアモンド52で、許可証が大丈夫かをチェックする。大丈夫ではない場合には、シグマチャネルを閉じてクリーンアップを実行することで72に示すトランザクションを無効にする。許可証が大丈夫な場合には、一実施形態で、管理エンジンが、プリンシパルメタデータにアクティブビットを真に設定することでブロック54で示す、このプリンシパルまたはサービスプロバイダをアクティベートする。管理エンジンは、このプリンシパルがアクティブなときに許可されたプラットフォーム機能のリストのインスタンスを作成することでinstantiate許可証をインストールするブロック56に示す。そして管理エンジンは、58で利用するプリンシパルを待つ。プリンシパルの構造も、60で管理エンジンにロードされる。ダイアモンド62のチェックは、プリンシパルがアクティベートされたかを判断する。アクティベートされている場合には、許可証の構造内の管理エンジンの機能のそれぞれについてブロック64、ダイアモンド63のチェックによって、該機能がアクティブかを判断する。アクティブな場合には、その機能をブロック66でアクティベートして、プリンシパル鍵またはシードにオペレーションを実行して、その後フローを戻す70。図2および図3に示すシーケンスは、ハードウェア、ソフトウェア、および/またはファームウェアで実装されてよい。ソフトウェアの実施形態では、シーケンスは、非一時的コンピュータ可読媒体たとえば光、磁気、または半導体メモリであって、例としてストレージ17を含むに格納されている命令により実装されてよい。ストレージ17は、さらに、製造業者が含む署名付き鍵と、プラットフォームの機能をアクティベートした特定のサービスプロバイダを特定する鍵またはシードとを格納してよい。したがって一部の実施形態では、プラットフォームリソースの所有権を複数のサービスプロバイダに拡張することができる。しかし一部のリソースは共有されないたとえば鍵またはシードが、他のリソースたとえば管理エンジンの実行環境等は共有される。許可証は、どのリソースが、サービスプロバイダによる利用を許可されているかを示す。プラットフォームはさらに、セキュアなインタフェースHECIhostembeddedcontrollerinterfaceなどに到達する要求に基づいて、リソースに対するアクセス制御をダイナミックに実行してよい。管理エンジンは、コマンドにサービス提供するとき利用される鍵およびシードの経過を追うことで、サービスプロバイダ間を区別することができる。したがって、鍵またはシードがセッションを認証する。セッションは、許可証を利用して、管理エンジンおよびプラットフォームのどのリソースがセッションに見えるかを知ることができる。認証されたセッションによって、サービスプロバイダはサービス提供物offeringをセット売りするbundleことができるたとえば、向上したプラットフォームが提供する他の技術とセットで売られる盗難防止サービスを提供する。一部の実施形態では、許可証が、セット売り構成を特定する。セット売りによって、各サービスプロバイダが、サービスプロバイダに固有のセキュリティおよび設定ポリシーを特定することができるようになる。たとえばあるサービスプロバイダが、2要素認証が必要であると指定したが、他のサービスプロバイダは、3要素認証を指定して、また別のサービスプロバイダは、認証を指定しない、という場合もある。図4は、ユーザまたはマシンのプリンシパルを表す管理リソースの一実施形態を示す。各プリンシパルは、他のプリンシパルおよび利用ポリシーと関連付けられていてよい。各オブジェクトクラスは、以下のように説明することができる。プリンシパルまたは主要なプリンシパルは、1..mの濃度cardinalityを有してよい。プリンシパルは、公開および秘密のコンポーネントを含んでいる鍵であってよい。秘密のコンポーネントは、鍵の値が管理エンジンの外部でとられるときはいつも、機密性を確保するためにラッピングされていてよいwrapped。公開鍵は、X.509の証明書のコンテキストで利用されるときSubjectPublicKeyとして知られているものであってよい。スイス、ジュネーブの国際電気通信連合から入手可能な、ITU-TRecommendationX.5092005InformationTechnologyOpenSystemsInterconnection、TheDirectoryAuthenticationFramework08/05を参照のこと。鍵が別のシステムまたはデバイスとの交信に利用される場合には、エンドポイントを示すのはプリンシパルの実体である。プリンシパルがユーザを認証するために利用される場合には、プリンシパルがユーザのために代弁する。プリンシパルに関連付けられているオブジェクトが、プリンシパルがユーザを代理または代弁する方法について制約を課す。所有者のプリンシパル80は1..1の濃度を有している。所有者のプリンシパルは、プリンシパルの管理統制権をもつサービスプロバイダのことである。所有者のプリンシパルは、所有者の実体を認証して所有者の実体と通信するために利用される鍵86を含んでいる。また、所有者の証明書を認証するために利用されるサービスプロバイダの公開鍵を含んでいてもよい。さらに、管理エンジンとサービスプロバイダとの間のセキュアなセッションに対応するセッション鍵SKとマスター鍵MKとを含んでもよい。アンカープリンシパル82は、0..mの濃度を有している。所有者のプリンシパルは、他のデバイスまたはサーバとセキュアな接続を構築する際に、このアンカープリンシパルが信任することができる信任アンカーを設定する。アクティベートプリンシパル84は、1..1の濃度を有している。アクティベートプリンシパルは、許可サーバを認証するために利用される認証情報credentialのことを示す。これら認証情報は、オンボードで、管理エンジンを含み、サービスプロバイダの遠隔制御によってチップセットの機能をON/OFF切り替えする機能をもつ特定のチップセットに提供されてよい。アクティベートトランザクション識別子たとえばTX1は、このコンテキストの一部であり、主要なプリンシパルのアクティベート状態を含む。デバイス識別子90は、0..mの濃度を有している。管理エンジンが、信任されているメッシュまたはクラウドの一部として認識しているデバイスは、デバイス識別子を有している場合がある。所有者のプリンシパルは、デバイス識別子を、予め設定されている設定ポリシーに従って構成してよい。プリンシパルメタデータ92は、1..1の濃度を有しており、鍵のマイクレーション、バックアップ、および復旧処理を記述する設定を含んでいる。利用の制約たとえば鍵を署名、暗号化、または鍵交換に利用することができるか否かが、プリンシパルメタデータの一部であってよい。利用ポリシー88は、0..1の濃度を有しており、鍵の利用においてポリシーにより制御される一群の制約のことである。これには、ユーザのプレゼンスを構築する方法のための多要素認証MFA規則を含んでよい。たとえばユーザのプレゼンスは、一実施形態では、ユーザが認識している、またはマウスの利用の署名パターンおよびコンピュータシステムに、コンピュータのユーザを特定させる表示により構築されてよい。プライバシーポリシーは、この鍵が署名または暗号化する情報量を制約することができる。デジタル権管理ポリシーも、この鍵で保護されているデータが他のデバイスによって再配信されるredistributed方法を制約することができる。ユーザのプレゼンス94は、0..mの濃度をもち、サービスプロバイダと、ユーザのプレゼンスにプルーフを与える技術のためのユーザ設定可能構成値とを含んでいてよい。これにはWYSIWYS、近距離無線通信NFC、トラステッド入出力IO、およびその他のプレゼンスポリシーが含まれてよい。濃度0..mをもつコンテキスト96は、主要なプリンシパルを利用するときに利用可能なプラットフォームの機能および性能を含む。コンテキストソースは、センサ入力たとえばほんの数例を挙げると、位置、向き、近接度、温度、電力、およびバッテリを含んでよい。タスク情報98は、0..mの濃度を持ち、主要プリンシパルを利用する管理エンジン環境を説明する証明コンテキストを含む。本明細書における1つの実施形態または一実施形態といった言い回しは、その実施形態との関連で記載されている特定の特徴、構造、または特性が、本発明に含まれる少なくとも1ついの実装例に含まれていることを示している。したがって1つの実施形態または一実施形態という言い回しは、必ずしも同じ実施形態のことを示しているわけではない。さらに、特定の特徴、構造、または特性が、示されている特定の実施形態以外の他の適切な形態で実装されてもよく、これらすべての形態が本願の請求項の範囲には含まれることが意図されている。本発明を、限られた数の実施形態を参照して説明してきたが、当業者には複数の変形例および修正例が明らかである。添付請求項では、これらすべての変形例および修正例を、本発明の真の精神および範囲内に含まれることが意図されている。