特許第5745690号(P5745690)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ インテル・コーポレーションの特許一覧

特許5745690マルチテナントサービスプロバイダによるダイナミックプラットフォームの再構成
<>
  • 特許5745690-マルチテナントサービスプロバイダによるダイナミックプラットフォームの再構成 図000002
  • 特許5745690-マルチテナントサービスプロバイダによるダイナミックプラットフォームの再構成 図000003
  • 特許5745690-マルチテナントサービスプロバイダによるダイナミックプラットフォームの再構成 図000004
  • 特許5745690-マルチテナントサービスプロバイダによるダイナミックプラットフォームの再構成 図000005
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】5745690
(24)【登録日】2015年5月15日
(45)【発行日】2015年7月8日
(54)【発明の名称】マルチテナントサービスプロバイダによるダイナミックプラットフォームの再構成
(51)【国際特許分類】
   H04L 9/32 20060101AFI20150618BHJP
   G06F 21/44 20130101ALI20150618BHJP
【FI】
   H04L9/00 675B
   G06F21/44
【請求項の数】21
【全頁数】13
(21)【出願番号】特願2014-512828(P2014-512828)
(86)(22)【出願日】2011年12月29日
(65)【公表番号】特表2014-516227(P2014-516227A)
(43)【公表日】2014年7月7日
(86)【国際出願番号】US2011067696
(87)【国際公開番号】WO2012161738
(87)【国際公開日】20121129
【審査請求日】2013年12月17日
(31)【優先権主張番号】13/116,698
(32)【優先日】2011年5月26日
(33)【優先権主張国】US
(73)【特許権者】
【識別番号】591003943
【氏名又は名称】インテル・コーポレーション
(74)【代理人】
【識別番号】110000877
【氏名又は名称】龍華国際特許業務法人
(72)【発明者】
【氏名】スミス、ネド、エム.
(72)【発明者】
【氏名】バクシ、サンジャイ
(72)【発明者】
【氏名】スグマー、スレシュ
【審査官】 青木 重徳
(56)【参考文献】
【文献】 特開2006−059141(JP,A)
【文献】 特表2007−505582(JP,A)
【文献】 特開2010−191946(JP,A)
【文献】 特表2010−520729(JP,A)
【文献】 特表平09−509026(JP,A)
【文献】 国際公開第2012/040247(WO,A1)
【文献】 古川 隆弘、滝澤 基行、湊 透、島田 裕一,“NGNに向けたホームゲートウェイとプラットフォームの検討”,電子情報通信学会技術研究報告,日本,社団法人電子情報通信学会,2006年10月12日,Vol.106、No.304,p.29−34
【文献】 Ernie Brickell and Jiangtao Li,“Enhanced Privacy ID: A Direct Anonymous Attestation Scheme with Enhanced Revocation Capabilities”,Cryptology ePrint Archive: Report 2007/194,[online],2007年 8月22日,Version: 20070822:145239,p.1-36,[retrieved on 2014-10-30]. Retrieved from the Internet,URL,<https://eprint.iacr.org/2007/194.pdf>
(58)【調査した分野】(Int.Cl.,DB名)
H04L 9/32
G06F 21/44
(57)【特許請求の範囲】
【請求項1】
管理エンジンで、サービスプロバイダのサーバから、前記管理エンジンに連結されているプラットフォームの機能をアクティベートせよとの要求を受信する段階と、
前記要求に呼応して、前記サービスプロバイダが前記管理エンジンの製造業者によって、前記プラットフォームの機能の利用を許可されていることを示す、許可サーバからの証明書を含む、前記サービスプロバイダが前記プラットフォームを修正できることを示す許可のプルーフを、セキュアな形態で前記サービスプロバイダに要求する段階と、
前記証明をチェックして、別のサービスプロバイダが前記機能を利用しないようにする段階と
を備える方法。
【請求項2】
前記サービスプロバイダが前記管理エンジンの製造業者によって前記機能を利用することが許可されていることを確認する段階と、
前記サービスプロバイダによる使用のみのために前記機能をアクティベートする段階と
を備える、請求項1に記載の方法。
【請求項3】
前記サービスプロバイダの許可が無効化されているかをチェックする段階を備える、請求項1または2に記載の方法。
【請求項4】
前記プルーフを要求する段階は、
前記管理エンジン内に、アクティベートされていない鍵を生成する段階を含む、請求項1から3のいずれか一項に記載の方法。
【請求項5】
前記製造業者が前記管理エンジンに組み込んだ署名付き鍵を利用して、前記プルーフを要求する段階を含む、請求項1からのいずれか一項に記載の方法。
【請求項6】
デバイスの所有者のプライバシーを保護しつつ、ハードウェアデバイスの遠隔認証を可能とする暗号スキームを利用し、かつ、前記サービスプロバイダが前記管理エンジンの前記製造業者によって証明されていることを示すべく前記管理エンジン内に埋め込まれた秘密鍵を利用して、プルーフを要求する段階を備える、請求項1からのいずれか一項に記載の方法。
【請求項7】
前記プルーフを要求する段階は、
前記管理エンジンが本物であることを示すプルーフを提供する段階を含む、請求項1からのいずれか一項に記載の方法。
【請求項8】
前記要求する段階は、
サービスプロバイダに対して、前記管理エンジンの鍵が本物か否かを証明する、署名付きの属性を含む、証明書署名要求を提供する段階を含む、請求項1からのいずれか一項に記載の方法。
【請求項9】
前記要求に応答して、前記サービスプロバイダに前記機能の利用を許可すべく、前記管理エンジンが許可証を受信して、鍵をアクティベートする段階を備える、請求項1からのいずれか一項に記載の方法。
【請求項10】
前記要求に応答して、前記管理エンジンで、サービスプロバイダの公開鍵または1回限りのパスワードシードをセキュアチャネル経由で受信する段階を備える、請求項1からのいずれか一項に記載の方法。
【請求項11】
前記管理エンジンに、少なくとも2つのサービスプロバイダのそれぞれについての別の公開鍵またはシードを格納して、前記鍵またはシードを利用して、前記機能を再度アクティベートするよう要求するサービスプロバイダを識別する段階を備える、請求項10に記載の方法。
【請求項12】
プロセッサの製造業者が提供した署名付き鍵を格納し、前記プロセッサに連結されているプラットフォームの機能をアクティベートせよとの要求を受信し、前記要求に応答して、サービスプロバイダが前記プラットフォームを修正できることを示す許可のプルーフをセキュアなチャネルで自動的に前記サービスプロバイダに要求し、前記サービスプロバイダからの前記プルーフに含まれる証明書をチェックして、別のサービスプロバイダが前記機能を利用しないようにする前記プロセッサと、
前記プロセッサに連結されているストレージと
を備える装置。
【請求項13】
前記プロセッサは、管理エンジンである、請求項12に記載の装置。
【請求項14】
前記プロセッサは、前記サービスプロバイダからの証明書をチェックして、前記サービスプロバイダが、前記プロセッサの前記製造業者によって前記プラットフォームの機能を利用することを許可されているかを判断する、請求項12または13に記載の装置。
【請求項15】
前記プロセッサは、前記サービスプロバイダの許可が無効化されているかをチェックする、請求項14に記載の装置。
【請求項16】
前記プロセッサは、デバイスの所有者のプライバシーを保護しつつ、ハードウェアデバイスの遠隔認証を可能とする暗号スキームを利用して、前記サービスプロバイダにプルーフを要求し、かつ、前記プロセッサは、製造時点に管理エンジン内に埋め込まれた秘密鍵を利用して、前記サービスプロバイダが前記プロセッサの前記製造業者によって証明されていることを示、請求項14または15に記載の装置。
【請求項17】
前記プロセッサは、真正なプルーフを提供する、請求項12から16のいずれか一項に記載の装置。
【請求項18】
前記プロセッサは、サービスプロバイダに対して、前記プロセッサの鍵が本物か否かを証明する、署名付きの属性を含む、証明書署名要求を提供する、請求項12から17のいずれか一項に記載の装置。
【請求項19】
前記プロセッサは、前記サービスプロバイダに前記機能の利用を許可すべく、許可証を受信して、鍵をアクティベートする、請求項12から18のいずれか一項に記載の装置。
【請求項20】
前記プロセッサは、サービスプロバイダの公開鍵または1回限りのパスワードシードをセキュアチャネル経由で受信する、請求項12から19のいずれか一項に記載の装置。
【請求項21】
前記プロセッサは、管理エンジンに、少なくとも2つのサービスプロバイダのそれぞれについての別の公開鍵またはシードを格納して、前記鍵またはシードを利用して前記機能を再度アクティベートするよう要求するサービスプロバイダを識別する、請求項20に記載の装置。
【発明の詳細な説明】
【背景技術】
【0001】
本願は概してコンピュータシステムに係り、特に、サービスプロバイダによって、これらコンピュータシステムの機能を選択的に実行することに関する。
【0002】
コンピュータシステムおよびそのコンポーネントの中には、1セットの機能を提供されているものがあり、そのなかにはエンドユーザによる購入時点にはアクティブではないものもある。購入後の、たとえば料金を貰った後などに、サービスプロバイダが、今はエンドユーザが所有しているプラットフォームの機能をアクティブにする権限を与えられている。
【0003】
このような事例の1つとして、一定のプロセッサ速度を可能とするために一定のスキューレートで販売されるコンピュータがある。所定のサービスプロバイダは、サービスプロバイダが提供を目指すサービスを提供するためにより速いスピードを実現しようとするだろう。そしてサービスプロバイダは、プロセッサの製造業者と取決めを行い、サービスプロバイダが、販売時点の速度よりも速いスキューレートをアクティベートしようとするだろう。このような機能をアクティベートする際には、サービスプロバイダから製造業者への料金が発生することが想定される。サービスプロバイダは次に、アクティベートされた機能(高速になったスキューレートの場合)を、サービスプロバイダが提供する他の機能とセット売りする(bundle)ことができる。
【図面の簡単な説明】
【0004】
図1】本発明の一実施形態の概略を示す。
【0005】
図2】本発明の一実施形態のエンドツーエンドのアクティベートフローを示す。
【0006】
図3】本発明の一実施形態のフローチャートを示す。
【0007】
図4】本発明の一実施形態のサービスプロバイダの鍵となる構造を示す。
【発明を実施するための形態】
【0008】
本発明の一部の実施形態では、マルチテナントのサービスプロバイダによるダイナミックプラットフォーム再構成が可能である。言い換えると、一定のハードウェアデバイス製造業者が、1を超える数のサービスプロバイダに対して、製造業者のハードウェアのエンドユーザにサービスを提供する権限を与えることができる。これは、場合によっては、他のサービスプロバイダが、最初のサービスプロバイダがコストを負担する等によりアクティベートしたハードウェアの機能を利用する可能性から最初のサービスプロバイダを保護する鍵構造を利用して実装されてよい。
【0009】
一例としては、一定のサービスプロバイダが、製造業者が販売したプロセッサにもともとプロビジョンされているものよりも速いスキューレートを提供することを望む場合がある。サービスプロバイダは、許可サービスを利用してこれを行ってよい。サービスプロバイダは、コンポーネント製造業者に料金を払って、プロセッサ内の向上した機能をアクティベートする許可書を取得することができる。しかし、そのサービスプロバイダは、第2のサービスプロバイダが、同じ向上した機能を、より高いスキューレートでエンドユーザに利用させることを望まないだろう(最初のサービスプロバイダはアップグレードのために支払っており、料金を払わずにその機能を得た第2のサービスプロバイダと同じ条件で競争できないから)。
【0010】
同時に、ハードウェアデバイスの製造業者は、ハードウェアデバイスのアップグレード権を販売することを望む場合もある。これにより、製造業者の収入が増え、製造業者のエンドユーザ/顧客に対して、より多くのサービスを提供することができるようになる。
【0011】
一部の実施形態では、これらそれぞれ異なる機会は、それぞれ別のサービスプロバイダに、エンドユーザのプラットフォームの同じハードウェアデバイスと協働させることができる許可書および証明スキームの組み合わせによって達成されてよい。ハードウェアデバイスの機能がサービスプロバイダによって利用可能となったとき、これは、サービスプロバイダを特定する証明書によって利用可能とされ、第2のサービスプロバイダが、ハードウェアデバイスの製造業者に料金を支払わずに、同じアクティベートされた機能を単に利用することができないようにされる。
【0012】
図1の参照に戻ると、一実施形態では、クラウドまたは連続したコンピューティング環境を利用することができる。クラウド15は、任意の数のサービスプロバイダサーバ12と任意の数の許可サーバ14とを含んでよいが、この例では1つの許可サーバのみが示されている。一実施形態では、任意の数のプラットフォーム11が、クラウドを通じて、サービスプロバイダサーバと通信してよく、サービスプロバイダサーバは、許可サーバ(1または複数)と、クラウドを通じて通信してよい。
【0013】
ストレージ17は、管理エンジン10に連結されていてよい。ストレージは、光、半導体、または磁気メモリであってよい。
【0014】
したがって、サービスを一定のプラットフォーム11に提供することを望むサービスプロバイダは、サービスを提供する必要があるプラットフォーム11の機能のアクティベートを試みることができる。たとえばサービスプロバイダは、任意のプラットフォームの動作速度を向上させて、サービスプロバイダがプラットフォームにしてもらいたい一定の事柄を効率よくするために必要な速度で動作させようとするだろう。
【0015】
一実施形態では、サービスプロバイダは、許可サーバに接触して、向上のための許可証を得る。一部の場合には、許可は、サービスプロバイダが課すコストを支払うことで得られてよい。一実施形態では、第3者のプラットフォームをアップグレードするためにサービスプロバイダにより料金が課されてもよい。サービスプロバイダには、プラットフォーム11の所有者その他の実体からその料金が支払われるだろう。
【0016】
サービスプロバイダは、許可証をプラットフォーム11内の管理エンジン10に提示する。管理エンジン10は、サービスプロセッサまたは補助プロセッサであってよく、一部の実施形態では、これらは、プラットフォームの中央処理装置とは別の異なる(separate and apart from)第2のプロセッサである。しかし他の構成もまた可能である。一部の実施形態では、管理エンジンは、プラットフォームの残りの部分によりアクセスが許可されなくてもよい。
【0017】
管理エンジン10は、次に、プラットフォーム11の機能を修正する前に、許可証が正しいかを検証してよい。これにより、プラットフォームの乱用が防がれ、プラットフォームおよび/または管理エンジンを販売した製造業者のための支払いスキームを、おそらくは低コストで(プラットフォームの全ての機能がアクティベートされていないので)実行してよい。
【0018】
次にプラットフォームの機能がアクティベートされると、一実施形態では、第2のサービスプロバイダはプラットフォーム11上のその機能を利用することができない、というのも、機能は、ある特定のサービスプロバイダに関連付けられている証明書との関連においてのみアクティベートできるからである。したがって、このような実施形態では、証明書を持たない他のサービスプロバイダは、プラットフォーム上でアクティベートされた機能の利用を可能とすることができない。これにより、無料でロードしたサービスプロバイダが、他のサービスプロバイダがアクティベートした機能からの利益を享受することがないようにして、不平等なコストに基づいて競争が行われないようにする。
【0019】
図2に示す一実施形態では、3つの実体が関係していてよい。これらは管理エンジンまたの名をME10、サービスプロバイダサーバ12、および許可サーバ14である。
【0020】
一部の実施形態では、管理エンジン10は、ホスト(つまりプラットフォーム)ベースのネットワークの脅威から守られた処理を実行することができる。言い換えると、管理エンジンは、プラットフォーム11自身のみからではなく、プラットフォームの外部にあるが、それに対してネットワーク経由で接続されているデバイスからも隔離されている。管理エンジンは、サービスプロバイダおよび許可サーバの両方から信用されていてよく、これにより、プラットフォームのリソースおよび実行コンテキストを保護してよい。
【0021】
一部の実施形態では、サービスプロバイダは、非対称鍵と身元保護技術とに基づいてプラットフォームの所有者にサービスを提供する。許可サーバは、サービスプロバイダおよびプラットフォームエンドユーザのために、プラットフォームの機能のアクティベートを実行する前に、サービスプロバイダがプラットフォームまたは管理エンジンの製造業者と適切で積極的な取引関係(appropriate, active business relationship)をもっていることを確認することができる。
【0022】
したがって、最初に、管理エンジン10でローカルに鍵が生成されてよい(16で示すように)。この鍵は、どの自由なトランザクションを実行するためにも利用できないことから、最初はアクティベートされていない。そして18に示すように、管理エンジンとサービスプロバイダとの間にセキュアなチャネルまたはシグマチャネル(sigma channel)が構築される。シグマチャネルとは、Intel Media Vault技術で利用される用語であるが、本発明の一部の実施形態ではいずれのセキュアなチャネルを実装してもよい。たとえばシグマチャネルは、エンドユーザにリリースされる前に管理エンジンに内蔵された、署名付きのDiffie−Hellman鍵を利用してよい。一実施形態では、シグマチャネルが、Intel Corporationから入手可能な向上したプライバシー識別またはEPID技術を利用してよい。EPIDは、デバイスの所有者のプライバシーを保護しつつ、ハードウェアデバイスの遠隔認証を可能とする暗号スキームである。埋め込まれたEPID秘密鍵をもつハードウェアデバイスは、遠隔にある実体に、所有者の身元を明かさず、かつ、検証者が認証に関与することなく、自身が、ハードウェア製造業者の証明を受けた、有効なデバイスであることを証明する。
【0023】
同じ鍵を利用して、プラットフォームが本物であることを証明してよい。たとえば、本物である場合とは、許可サーバを制御し、プラットフォームの機能をアクティベートする権限をサービスプロバイダに与える製造業者が(管理エンジンを含む)製造したもののような場合である。鍵はさらに、管理エンジンの環境を報告するために利用されてよい(遠隔位置に対するそのファームウェアのハッシュおよびバージョン情報を含む)。加えて、鍵は、公開鍵をサービスプロバイダに開示する際に利用されることで、サービスプロバイダが鍵を検証して、プラットフォームが本物であると立証することができる。
【0024】
シグマチャネルは、Diffie−Hellman鍵交換を行い、管理エンジンとサービスプロバイダとの間で共有対称鍵を生成してよく、一方で、EPIDを利用して、管理エンジンが正規であることを証明してよい。サービスプロバイダは、管理エンジンの製造業者が発行する証明書を提示して、管理エンジンが、製造業者が許可したサービスプロバイダを検証することができるようにしてよい。そして20で示すように、サービスプロバイダは、鍵の無効化リスト(GRP−RL、PRIV‐RLおよびSIG−RLが特定する)およびサービスプロバイダの検証のための従来の無効リスト(CRL)を提供するために、許可サーバ14を利用してよい。したがって、権利が無効化されているサービスプロバイダは、管理エンジンによって簡単に特定することができ、許可されたサービスプロバイダのみが、管理エンジンを含むプラットフォームの機能を修正できるようにしてよい。
【0025】
そして22で示すように、サービスプロバイダは、無効化リストを管理エンジンに供給して、EPID署名処理が、サービスプロバイダにEPID署名無効化ステータスを判断させるプルーフを含んでよい。管理エンジンは、サービスプロバイダの証明書の無効化ステータスを受信する。別の実施形態では、管理エンジンが、無効化リストを加工することができない場合、代わりに、サービスプロバイダ経由で代理をしているオンライン証明書ステータスプロトコル(OCSP)応答システムを利用することができる。RFC2560.11、X.509Internet Public Key Infrastructure Online Certificate Status Protokcol Network Working Group Request for Comments1999年6月を参照のこと。
【0026】
そして管理エンジンは、ノンスおよび無効化リストに署名をして(ブロック24で示す)、セキュアなプロトコルハンドシェークを完了する。加えて、許可サーバに転送するための、鍵に対する証明書署名要求(CSR)がサービスプロバイダに供給される。証明書署名要求には、一実施形態では、鍵およびそのデフォルトの構成属性の正当性を証明するためのEPID署名された属性が含まれてよい。管理エンジンは、次に、許可サーバから許可証の要求を開始する。
【0027】
次に、25で示すように、証明機関(CA)バックエンドとの関連で動作しているサービスプロバイダが、CSRを証明する。この検証は、鍵のEPID署名を検証することを含む。CA署名は、CSRに含まれる情報が正当であると主張するので、EPID証明も検証する必要がある。
【0028】
26で、CAバックエンドは、鍵の証明書を発行するが、これには、鍵がどのように保護されているかを示す拡大証明書(certificate extension)が含まれてよい。これは、CSRに含まれているEPID証明をその証明書にコピーすることで達成されてよい。
【0029】
この後で、27で、サービスプロバイダは、許可要求を許可サーバに中継して、許可サーバが利用するために鍵をアクティベートすることを許可してよい。この許可証は、さらに、サービスプロバイダが、鍵の利用に影響を与えるポリシーに対して管理統制を行うことを許可してもよい。
【0030】
次に、28で、許可サーバは、許可要求を検証して、サービスプロバイダの取引契約書が、鍵のアクティベートをサポートしているか、および、管理エンジンの機能をサポートしているかをチェックする。許可サーバはさらに、一部の実施形態では、管理エンジンが、サービスプロバイダが要求する機能をサポートすることができるかを検証してもよい。
【0031】
許可サーバは、さらに、適切な場合に、管理エンジンが、サービスプロバイダで利用する鍵をアクティベートすることを許可する許可証(30で示す)を発行してよい。こうして、サービスプロバイダは、ユーザプラットフォーム、および、その他のプラットフォームが鍵を利用して交信することができる方法を制御するポリシーを構成することを許可される。これにより、サービスプロバイダは、事実上の、鍵のポリシーの所有者になる。31で、許可サーバは、サービスプロバイダおよびアクティベートイベントを詳述するログを更新するが、これは、一部の実施形態でサービスプロバイダに課金するために利用されてよい。
【0032】
次に、32で、許可サーバが発行する許可証がサービスプロバイダのサーバに提供される。許可証は、特定のプラットフォームおよび特定の鍵に固有であってよい。もしも第2または第3の鍵が作成された場合には、この第2または第3のサービスプロバイダを、鍵の所有者として利用することができる。
【0033】
一部の実施形態では、34で、サービスプロバイダが、許可サーバと管理エンジンとの間の許可フローを監視する。サービスプロバイダはさらに、許可証が、正当な許可サーバからのものであるか検証して、サービスプロバイダは、許可サーバのアクティベートのログ(33で示す)を更新してよい。許可サーバおよびサービスプロバイダのログは、オフラインで、なんらかの取引契約に従って会計の詳細を監査するために比較されてよい。
【0034】
最後に、管理エンジンは、鍵をアクティベートして、管理エンジンの機能を可能としたり、フィルタリングしたりすることで、許可証をインストールする。たとえばサービスプロバイダは、強い多要素認証(strong multi-factor authentication)を利用することが許されていてよく、これにより、セキュアな証明に関してサービスプロバイダが、一定のポリシーを構成できるように、管理エンジンを構成することができる。この一例が、What You See Is What You Signであり、この技術では、署名されたメッセージの内容が変更されない(WYSIWYS)。
【0035】
本発明の一実施形態では、図3に示すフローチャートが、管理エンジンに関するソフトウェア、ハードウェア、またはファームウェアで実装されてよい。ソフトウェアの実施形態では、命令シーケンスが不揮発性コンピュータ可読媒体に格納されてよい(たとえば光、磁気、または半導体記憶素子など)。
【0036】
ブロック40から、管理エンジンによってサービスプロバイダとの間でセキュアなセッションが構築されて、所望のサービスのためにレジスタ格納が行われてよい。管理エンジンは、サービスプロバイダの公開鍵を得てよく、または、別の例では、一回限りのパスワード(OTP)シード(1度のみのログインについて有効である)を、セキュアなチャネル(たとえばシグマチャネル)でネゴシエートしてよい(ブロック42に示す)。そして管理エンジンが、サービスプロバイダの公開鍵またはシードを所有者のプリンシパルオブジェクトに格納する(ブロック44に示す)。
【0037】
次にブロック46で、管理エンジンが、プラットフォームの身元と構成とを鍵EPIDを利用して許可サーバに対して証明する。この証明は、サービスプロバイダによって中継される。そして管理エンジンは、一部の実施形態では、ブロック48で示すように、製造時に管理エンジンにプロビジョンされたアクティベートプリンシパルを利用してこのプリンシパルのための証明を得て、検証する。管理エンジンは次にダイアモンド52で、許可証が大丈夫かをチェックする。大丈夫ではない場合には、シグマチャネルを閉じてクリーンアップを実行することで(72に示す)トランザクションを無効にする。許可証が大丈夫な場合には、一実施形態で、管理エンジンが、プリンシパルメタデータにアクティブビットを真に設定することで(ブロック54で示す)、このプリンシパルまたはサービスプロバイダをアクティベートする。
【0038】
管理エンジンは、このプリンシパルがアクティブなときに許可されたプラットフォーム機能のリストのインスタンスを作成することで(instantiate)許可証をインストールする(ブロック56に示す)。そして管理エンジンは、58で利用するプリンシパルを待つ。プリンシパルの構造も、60で管理エンジンにロードされる。ダイアモンド62のチェックは、プリンシパルがアクティベートされたかを判断する。アクティベートされている場合には、許可証の構造内の管理エンジンの機能のそれぞれについて(ブロック64)、ダイアモンド63のチェックによって、該機能がアクティブかを判断する。アクティブな場合には、その機能をブロック66でアクティベートして、プリンシパル(鍵またはシード)にオペレーションを実行して、その後フローを戻す(70)。
【0039】
図2および図3に示すシーケンスは、ハードウェア、ソフトウェア、および/またはファームウェアで実装されてよい。ソフトウェアの実施形態では、シーケンスは、非一時的コンピュータ可読媒体(たとえば光、磁気、または半導体メモリであって、例としてストレージ17を含む)に格納されている命令により実装されてよい。ストレージ17は、さらに、製造業者が含む署名付き鍵と、プラットフォームの機能をアクティベートした特定のサービスプロバイダを特定する鍵またはシードとを格納してよい。
【0040】
したがって一部の実施形態では、プラットフォームリソースの所有権を複数のサービスプロバイダに拡張することができる。しかし一部のリソースは共有されない(たとえば鍵またはシード)が、他のリソース(たとえば管理エンジンの実行環境等)は共有される。許可証は、どのリソースが、サービスプロバイダによる利用を許可されているかを示す。プラットフォームはさらに、セキュアなインタフェース(HECI(host embedded controller interface)など)に到達する要求に基づいて、リソースに対するアクセス制御をダイナミックに実行してよい。管理エンジンは、コマンドにサービス提供するとき利用される鍵およびシードの経過を追うことで、サービスプロバイダ間を区別することができる。したがって、鍵またはシードがセッションを認証する。セッションは、許可証を利用して、管理エンジンおよびプラットフォームのどのリソースがセッションに見えるかを知ることができる。
【0041】
認証されたセッションによって、サービスプロバイダはサービス提供物(offering)をセット売りする(bundle)ことができる(たとえば、向上したプラットフォームが提供する他の技術とセットで売られる盗難防止サービスを提供する)。一部の実施形態では、許可証が、セット売り構成を特定する。セット売りによって、各サービスプロバイダが、サービスプロバイダに固有のセキュリティおよび設定ポリシーを特定することができるようになる。たとえばあるサービスプロバイダが、2要素認証が必要であると指定したが、他のサービスプロバイダは、3要素認証を指定して、また別のサービスプロバイダは、認証を指定しない、という場合もある。
【0042】
図4は、ユーザまたはマシンのプリンシパルを表す管理リソースの一実施形態を示す。各プリンシパルは、他のプリンシパルおよび利用ポリシーと関連付けられていてよい。各オブジェクトクラスは、以下のように説明することができる。プリンシパルまたは主要なプリンシパルは、1..mの濃度(cardinality)を有してよい。プリンシパルは、公開および秘密のコンポーネントを含んでいる鍵であってよい。秘密のコンポーネントは、鍵の値が管理エンジンの外部でとられるときはいつも、機密性を確保するためにラッピングされていてよい(wrapped)。公開鍵は、X.509の証明書のコンテキストで利用されるときSubjectPublicKeyとして知られているものであってよい。スイス、ジュネーブの国際電気通信連合から入手可能な、ITU−T Recommendation X.509(2005)Information Technology Open Systems Interconnection、The Directory Authentication Framework 08/05を参照のこと。鍵が別のシステムまたはデバイスとの交信に利用される場合には、エンドポイントを示すのはプリンシパルの実体である。プリンシパルがユーザを認証するために利用される場合には、プリンシパルがユーザのために「代弁」する。プリンシパルに関連付けられているオブジェクトが、プリンシパルがユーザを代理または代弁する方法について制約を課す。
【0043】
所有者のプリンシパル80は1..1の濃度を有している。所有者のプリンシパルは、プリンシパルの管理統制権をもつサービスプロバイダのことである。所有者のプリンシパルは、所有者の実体を認証して所有者の実体と通信するために利用される鍵86を含んでいる。また、所有者の証明書を認証するために利用されるサービスプロバイダの公開鍵を含んでいてもよい。さらに、管理エンジンとサービスプロバイダとの間のセキュアなセッションに対応するセッション鍵(SK)とマスター鍵(MK)とを含んでもよい。
【0044】
アンカープリンシパル82は、0..mの濃度を有している。所有者のプリンシパルは、他のデバイスまたはサーバとセキュアな接続を構築する際に、このアンカープリンシパルが信任することができる信任アンカーを設定する。
【0045】
アクティベートプリンシパル84は、1..1の濃度を有している。アクティベートプリンシパルは、許可サーバを認証するために利用される認証情報(credential)のことを示す。これら認証情報は、オンボードで、管理エンジンを含み、サービスプロバイダの遠隔制御によってチップセットの機能をON/OFF切り替えする機能をもつ特定のチップセットに提供されてよい。アクティベートトランザクション識別子(たとえばTX1)は、このコンテキストの一部であり、主要なプリンシパルのアクティベート状態を含む。
【0046】
デバイス識別子90は、0..mの濃度を有している。管理エンジンが、信任されているメッシュまたはクラウドの一部として認識しているデバイスは、デバイス識別子を有している場合がある。所有者のプリンシパルは、デバイス識別子を、予め設定されている設定ポリシーに従って構成してよい。
【0047】
プリンシパルメタデータ92は、1..1の濃度を有しており、鍵のマイクレーション、バックアップ、および復旧処理を記述する設定を含んでいる。利用の制約(たとえば鍵を署名、暗号化、または鍵交換に利用することができるか否か)が、プリンシパルメタデータの一部であってよい。
【0048】
利用ポリシー88は、0..1の濃度を有しており、鍵の利用においてポリシーにより制御される一群の制約のことである。これには、ユーザのプレゼンスを構築する方法のための多要素認証(MFA)規則を含んでよい。たとえばユーザのプレゼンスは、一実施形態では、ユーザが認識している、またはマウスの利用の署名パターンおよびコンピュータシステムに、コンピュータのユーザを特定させる表示により構築されてよい。プライバシーポリシーは、この鍵が署名または暗号化する情報量を制約することができる。デジタル権管理ポリシーも、この鍵で保護されているデータが他のデバイスによって再配信される(redistributed)方法を制約することができる。
【0049】
ユーザのプレゼンス94は、0..mの濃度をもち、サービスプロバイダと、ユーザのプレゼンスにプルーフを与える技術のためのユーザ設定可能構成値とを含んでいてよい。これにはWYSIWYS、近距離無線通信(NFC)、トラステッド入出力(IO)、およびその他のプレゼンスポリシーが含まれてよい。
【0050】
濃度0..mをもつコンテキスト96は、主要なプリンシパルを利用するときに利用可能なプラットフォームの機能および性能を含む。コンテキストソースは、センサ入力(たとえばほんの数例を挙げると、位置、向き、近接度、温度、電力、およびバッテリ)を含んでよい。
【0051】
タスク情報98は、0..mの濃度を持ち、主要プリンシパルを利用する管理エンジン環境を説明する証明コンテキストを含む。
【0052】
本明細書における「1つの実施形態」または「一実施形態」といった言い回しは、その実施形態との関連で記載されている特定の特徴、構造、または特性が、本発明に含まれる少なくとも1ついの実装例に含まれていることを示している。したがって「1つの実施形態」または「一実施形態」という言い回しは、必ずしも同じ実施形態のことを示しているわけではない。さらに、特定の特徴、構造、または特性が、示されている特定の実施形態以外の他の適切な形態で実装されてもよく、これらすべての形態が本願の請求項の範囲には含まれることが意図されている。
【0053】
本発明を、限られた数の実施形態を参照して説明してきたが、当業者には複数の変形例および修正例が明らかである。添付請求項では、これらすべての変形例および修正例を、本発明の真の精神および範囲内に含まれることが意図されている。
[項目1]
命令を備える非一時的なコンピュータによる読み取り可能な媒体であって、前記命令は、プロセッサに、
サービスプロバイダの、前記プロセッサに連結されているプラットフォームの機能の利用の許可を検証せよとの要求を送信する段階と、
前記サービスプロバイダが前記プロセッサの製造業者によって、前記機能の利用を許可されていることを検証する段階と、
前記サービスプロバイダによる利用に限って、前記機能をアクティベートする段階と
を実行させる、媒体。
[項目2]
前記プロセッサに、サービスプロバイダのサーバから、前記プロセッサに連結されている前記プラットフォームの機能をアクティベートせよとの要求を受信する段階を実行させる命令をさらに格納する、項目1に記載の媒体。
[項目3]
前記プロセッサの製造業者が前記プロセッサに組み込んだ署名付き鍵を利用する段階を実行させる命令をさらに格納する、項目1に記載の媒体。
[項目4]
前記プラットフォームの所有者のプライバシーを保護しつつ、ハードウェアデバイスの遠隔認証を可能とする暗号スキームを利用して、前記プロセッサ内に埋め込まれた秘密鍵を利用して、前記サービスプロバイダが前記プロセッサの前記製造業者によって証明されていることを示す段階を実行させる命令をさらに格納する、項目1に記載の媒体。
[項目5]
前記プロセッサが本物であることを示すプルーフを提供する段階を実行させる命令をさらに格納する、項目1に記載の媒体。
[項目6]
サービスプロバイダに対して、前記プロセッサの鍵が本物か否かを証明する、署名付きの属性を含む、証明書署名要求を提供する段階を実行させる命令をさらに格納する、項目1に記載の媒体。
[項目7]
前記サービスプロバイダに前記機能の利用を許可すべく、許可証を受信して、鍵をアクティベートする段階を実行させる命令をさらに格納する、項目1に記載の媒体。
[項目8]
前記プロセッサで、サービスプロバイダの公開鍵または1回限りのパスワードシードをセキュアチャネル経由で受信する段階を実行させる命令をさらに格納する、項目1に記載の媒体。
[項目9]
前記プロセッサで、少なくとも2つのサービスプロバイダのそれぞれについての別の公開鍵またはシードを格納して、前記機能を再度アクティベートするよう要求するサービスプロバイダを識別する段階を実行させる命令をさらに格納する、項目8に記載の媒体。
[項目10]
前記サービスプロバイダの認証が無効化されているかを判断する段階を実行させる命令をさらに格納する、項目1に記載の媒体。

図1
図2
図3
図4