モバイルインターネットデバイス（ＭＩＤ）でＵＥＦＩファームウェア及びＵＥＦＩアウェアなオペレーティングシステムのセキュアなブートのためのシステム及び方法
【課題】モバイルコンピューティングプラットフォームにおいて、オーナにより許可されたやり方でのみファームウェアが実行されるようにする。
【解決手段】システムは、ホストオペレーティングシステム及びホストアプリケーションを実行するホストプロセッサ９１０と、前記ホストプロセッサ９１０をブートするファームウェアであって、ブートの間に１以上の署名鍵を利用するファームウェアと、それぞれの署名鍵は、ブートの間に前記プラットフォームにロードされるソフトウェア画像９２１に関連され、前記ファームウェア及び他のホストプロセッサ９１０のアプリケーションにとってアクセス不可能であるセキュアメモリストア９２０に結合される前記プラットフォームのセキュリティプロセッサ９３１であって、前記１以上の署名鍵を管理してブートの間の画像のロードを制御するセキュリティプロセッサ９３１と、を有する。
【解決手段】システムは、ホストオペレーティングシステム及びホストアプリケーションを実行するホストプロセッサ９１０と、前記ホストプロセッサ９１０をブートするファームウェアであって、ブートの間に１以上の署名鍵を利用するファームウェアと、それぞれの署名鍵は、ブートの間に前記プラットフォームにロードされるソフトウェア画像９２１に関連され、前記ファームウェア及び他のホストプロセッサ９１０のアプリケーションにとってアクセス不可能であるセキュアメモリストア９２０に結合される前記プラットフォームのセキュリティプロセッサ９３１であって、前記１以上の署名鍵を管理してブートの間の画像のロードを制御するセキュリティプロセッサ９３１と、を有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施の形態は、モバイルコンピューティングプラットフォームに関し、より詳細には、本発明の実施の形態は、プラットフォームオーナ又はアドミニストレータのための機能を追加して、署名されたコンポーネントによるような、オーナにより許可されたやり方でのみファームウェアが実行されることを保証するものである。
【０００２】
本実施の形態は、ＣＲＴＭ（Core Root of Trust for Measurement）を、ＲＴＳ（Root-of-Trust for Storage）ＳＲＫ（Storage Root Key）としてモバイル装置における暗号化コプロセッサの使用を介して、ＵＥＦＩ（Unified Extensible Firmware Interface）ＰＩ（Platform Initialization）の画像認証及びブートマネージャに拡張する場合がある。
【０００３】
本実施の形態には、著作権保護を受けるマテリアルが含まれる。著作権者は、特許商標庁のファイル又はレコードに現れたときに任意の人物による特許の開示のファクシミリの複製に対して異論はなく、さもなければ、無断での複写・複製・転載を禁じる。
【背景技術】
【０００４】
セキュアなブート（secure booting）のための様々なメカニズムが存在する。ＵＥＦＩ（Unified Extensible Firmware Interface）仕様は、オペレーティングシステムとプラットフォームファームウェアとの間のインタフェース向けの新たなモデルを定義する。このインタフェースは、プラットフォームに関連する情報に加え、オペレーティングシステム及びそのローダにとって利用可能なブート及びランタイムのサービスコールを含むデータテーブルから構成される。同時に、これらは、オペレーティングシステムをブートし、プリブートアプリケーションを実行する標準的な環境を提供する。ＵＥＦＩに関する更なる情報は、ＵＲＬ www*uefi*org/homeでのパブリックなインターネットで発見される場合がある。不注意なハイパーリンクを防止するため、この文書ではピリオドはアスタリスクで置き換えられている。ＵＥＦＩ標準は、プラットフォームのセキュアなブートを支援するために使用される。
【０００５】
ＵＥＦＩ仕様２．１の２６節は、セキュアなブートのプロトコルを記載する。定義されたプロトコルは、特定のデバイスパスをもつ一般的な認証情報のためのアクセスを提供する。プロトコルは、物理的又は論理的なデバイスに関連する情報を取得するために任意のデバイスで使用される場合がある。公開鍵及び証明書は、ファームウェアで保持され、第三者の（Ｕ）ＥＦＩドライバ及びオペレーティングシステム（ＯＳ）ローダでデジタル署名をチェックする。プラットフォームに公開鍵を束縛することは、デプロイメントの問題となっている。セキュリティは、プラットフォームが公開鍵をセキュアに記憶することができるのと同様に良好である（すなわち、恐ろしい「鍵の管理の問題」）。公開鍵又は証明書のブートタイムでの失効は、可能ではない。サーバからの証明書失効リスト（ＣＲＬ）を解明することができないので、早期のブート環境は、ネットワークにアクセスすることができない。偽者のローダは、セキュリティを巧みに逃れるためにプラットフォームに挿入される場合がある。したがって、このセキュアなブート方法は、ブートタイムの間の攻撃に対して脆弱である場合がある。
【０００６】
モバイルデバイス、及びより詳細にはモバイルインターネットデバイス（ＭＩＤ）は、使用においてユビキタスになっている。モバイルデバイスをブートする様々なメカニズムが存在し、これらの方法は、デスクトップ及びラップトップシステムをブートするために使用される方法とは異なる。デスクトップ及びサーバプラットフォームでは、ＴＣＧ（Trusted Computing Group）により文書化されるチップのタイプであるＴＰＭ（Trusted Platform Module）コンポーネントは、バージョン１．２である承認された最新の変形によれば、セキュアなブートを支援するために使用される場合がある。ＴＰＭは、ＡＭＤ社のＰｒｅｓｉｄｉｏ及びそのＳＫＩＮＩＴインストラクション又はＩｎｔｅｌ社のＳＥＮＴＥＲインストラクションを使用したＴＸＴ（Trusted-eXecution-Technology）（aka LaGrande Technology）のようなプロセッサ／チップセット技術と結合されたとき、これらのタイプのプラットフォームでのファームウェアのブートをプロテクトする役割をする場合がある。しかし、ＭＩＤプロセッサは、ＴＸＴ（Trusted-eXecution-Technology）又はＴＣＧ１．２ＴＰＭをサポートせず、したがって、ファームウェアの「セキュアなブート」及びプラットフォームにおける信頼できる起点（root-of-trust）は、オペレーティングシステム（ＯＳ）ブートストラップの一部として必要とされる。追加されたセキュリティのため、オペレーティングシステムの始動の前にＭＩＤでのファームウェアのブートをプロテクトすることが望まれる場合がある。これは、音楽及び他のマルチメディアのようなハイバリューコンテンツがＭＩＤシステムで使用され、コンテンツプロバイダにより要求される高いプロテクションを必要とする場合があるために特に当てはまる。
【発明の概要】
【課題を解決するための手段】
【０００７】
本発明の実施の形態は、モバイルデバイスに関するシステム及び方法である。例示的な目的について、本発明の実施の形態は、モバイルインターネットデバイス（ＭＩＤ）に関連するものとして記載される。しかし、本発明の実施の形態は、携帯電話、ポータブルＭＰ３プレーヤ、パーソナルデジタルアシスタント（ＰＤＡ）又は、インターネットアクセスを有さない他のモバイルデバイスに適用可能な場合がある。本発明の実施の形態は、プラットフォームのオーナ又はアドミニストレータの能力を追加して、署名されたコンポーネントによるようなオーナーにより許可されたやり方でのみファームウェアが実行されることを保証する。本実施の形態は、測定のための信頼できるコアとなる起点（CRTM: Core Root of Trust for Measurement）を、記憶のための信頼できる起点（RTS: Root-of-Trust for Storage）の記憶の起点の鍵（SRK: Storage Root Key）として、モバイル装置における暗号化コプロセッサの使用を介して、ＵＥＦＩ（Unified Extensible Firmware Interface）のＰＩ（Platform Initialization）の画像認証及びブートマネージャに拡張する場合がある。
【０００８】
本発明の「１実施の形態」又は「実施の形態」に対する明細書における参照は、実施の形態との関連で記載される特定の特徴、構造又は特性が本発明の少なくとも１つの実施の形態に含まれることを意味する。したがって、明細書を通して様々な場所で現れるフレーズ「１実施の形態では」の登場は、必ずしも、同じ実施の形態を全て参照するものではない。
【０００９】
説明のために、本発明の全体的な理解を提供するために特定のコンフィギュレーション及び詳細が述べられる。しかし、本発明の実施の形態は、本明細書で与えられる特定の詳細なしに実施される場合があることが当業者にとって明らかであろう。さらに、公知の特徴は、本発明を曖昧にしないために省略又は簡略化される場合がある。様々な例は、この説明を通して与えられる場合がある。これらは、本発明の特定の実施の形態の単なる記載である。本発明の範囲は、与えられる例に限定されない。
【００１０】
本発明の実施の形態は、不透明な「ＯＥＭブートモジュール」を採用し、ＵＥＦＩのセキュアなブート及びプラットフォームの初期化（PI: Platform Initialization）に基づくファームウェアのポリシーに基づくディスパッチを適用してセキュリティのソリューションを実施し、ＭＩＤを市場に提供するＯＥＭ（Original Equipment Manufactures）及びＯＤＭ（Original Design Manufactures）を可能にする。特に、この技術分野は、セキュアなブートのプラットフォームドライバ、第三者のオプションのＲＯＭ（O-ROM）、並びに（Microsoft Windows（登録商標）向け）Winroad.efi及び（Linux向け）eLifo.efiのようなＯＳローダを含む。ｅＬｉｆｏは、ＥＦＩに基づくＰＣハードウェア用の標準的なＬｉｎｕｘブートローダである。実施の形態は、認証された可変のサービスを要求する前にプラットフォームのオーナがペイロードを署名しなければならないときに、秘密鍵を露出する危険を除く。また、実施の形態は、ＳＳＯ（Single Sign-On）シナリオ、及び１タッチの提供を実現する。たとえば、プラットフォームのオーナは、同じ認証データにより、ＯＳフェーズ及びプレＯＳフェーズの両者においてオーナシップを取得する場合がある。
【００１１】
本発明の実施の形態は、秘密の署名鍵を管理するためにＭＩＤのセキュリティプロセッサを利用する。これにより、セキュリティプロセッサのポリシーエンジンをもつＵＥＦＩのセキュリティブートは、マネージャビリティ及びプロビジョニングインフラストラクチャに継ぎ目なく統合することができる。
【図面の簡単な説明】
【００１２】
本発明の特徴及び利点は、本発明の以下の詳細な説明から明らかとなるであろう。
【図１】署名の技術を使用してシステムにおけるブート及びシステムインテグリティを保証するために使用される署名鍵の階層を例示するブロック図である。
【図２】本発明の実施の形態に係る、プラットフォームのオーナがオーナシップを取得し、セキュリティプロセッサによりプラットフォームの証明書を生成するときのフローを例示する図である。
【図３】本発明に係る、オーナシップを取得し、プラットフォームの証明書を登録する方法を例示するフローチャートである。
【図４】本発明の実施の形態を実現するために使用される例示的なＣコードを説明する図である。
【図５】本発明の実施の形態に係る、証明書のデータベースの例示的な構造を説明するブロック図である。
【図６】本発明の実施の形態に係る、プラットフォームのオーナが第三者の認証の証明書を登録する方法を説明するフローチャートである。
【図７】本発明の実施の形態に係る、プラットフォームのオーナがデジタル署名を登録する方法を説明するフローチャートである。
【図８】本発明の実施の形態に係る、実行可能なＵＥＦＩを許可する例示的な方法を説明するフローチャートである。
【図９】本発明の実施の形態に係る、プライマリプロセッサエレメント及びセキュリティ処理チップセットを有するプラットフォームを例示するブロック図である。
【図１０】本発明の実施の形態に係る、埋め込まれたセキュリティプロセッサを有する例示的な暗号化ユニットのブロック図である。
【発明を実施するための最良の形態】
【００１３】
図９を参照して、プライマリ又はホストプロセッサエレメント９１０及びセキュリティプロセッシングチップセット９３０を有するプラットフォーム９００を例示するブロック図が示される。本発明の実施の形態では、プラットフォーム９００は、マルウェアからプロテクトするためにセキュアなＯＳのブートを必要とするプライマリプロセッサ９１１をもつプライマリランタイム環境９１０を有する。プロセッサ９１１は、システムメモリ９０５に結合される。セキュリティプロセッサのチップセットユニット９３０は、セキュリティエンジン又はプロセッサ９３１、（ｘ８６ファームウェアをロードする前にプラットフォームの初期化の幾つかを行う）システムコントローラ（ＡＲＣ）９３３、及び専用のリードオンリメモリ（ＲＯＭ）９３５を有する。ＲＯＭは、コード及びデータを更に保護して、セキュアブートを保証するために使用され、リードオンリであるとき、コード及びデータは、悪意のある改ざんにより変更されない場合がある。フラッシュメモリ９２０は、セキュリティプロセッサに結合され、プライマリプロセッサ９１１をブートするためにブートソフトウェアの画像９２１を保持する。プライマリプロセッサ９１１にロードされるブートソフトウェア画像は認証され、マルウェアがないことが重要である。
【００１４】
実施の形態では、検証されたブートは、セキュリティチップセット９３０を使用して実現される場合がある。セキュリティエンジン９３１は、以下に説明されるように、鍵及び署名の手順を実現するために構成される。セキュリティプロセッサ９３１は、プライマリプロセッサ９１１によるアクセスから隔離される専用装置であるので、セキュリティエンジンは、改ざんからプロテクトされる。セキュリティエンジンは、プライマリプロセッサがブートするのを可能にする前に、プライマリプロセッサについてブートＲＯＭを検証するために構成される。たとえばＩｎｔｅｌ（登録商標）Ｃｏｒｅ（登録商標）２Ｄｕｏに基づくＰＣ（Personal Computer）といった既存のシステムでは、プライマリプロセッサは、検証することなしに、フラッシュの部分、すなわちブートＲＯＭにブート制御を自動的に移す。幾つかのデスクトップ、ラップトップ又は他のフル機能ＰＣでは、ＴＸＴ技術は、ブートＲＯＭ及び後続する処理を検証するのを介入する。プラットフォームは、ブートプロセスまでセキュアな状態になり、特に、ＳＥＮＴＥＲ命令により起動されるＴＸＴマイクロコードは、プラットフォーム上の全てのプロセッサを同期させ、測定された起動環境（MLE: Measured Launch Environment）について、オプションのＲＯＭ及びプラットフォームのＢＩＯＳを含めて、その前に実行したソフトウェアの全てに独立にすることができる。しかし、ＴＸＴ処理は、ＭＩＤ及び他の低コストプラットフォームで利用可能ではない。実施の形態では、セキュリティプロセッサは、他のシステムにおけるＴＸＴに対する代替として、ブートＲＯＭを検証するためにＭＩＤに追加される。しかし、セキュアプロセッサを有するＭＩＤの実施の形態では、ＯＥＭのブートモジュールのみが検証されることが可能である。
【００１５】
ＯＥＭブートモジュール９５１は、基本的にＵＥＦＩファームウェアである。セキュリティプロセッサ９３０は、ＯＥＭブートモジュール９５１を検証する。ひとたび検証されると、セキュリティプロセッサ９３０は、ＯＥＭブートモジュール９５１をプライマリプロセッサ９１１のＳＲＡＭ９０５にコピーする。ＯＥＭブートモジュールは、プレＥＦＩ初期化（ＰＥＩ）及びドライバ実行環境（ＤＸＥ）を包含する場合がある。これらのフェーズは、オペレーティングシステム（ＯＳ）が起動される前に実行される必要がある。幾つかのシステムでは、ひとたびＯＥＭブートモジュールが実行されると、ＯＳローダ９５３は、ＰＥＩフェーズから始動される。ＯＳローダ９５３は、信頼されたＯＳ９５５を始動する。しかし、ＯＳの信頼は、実際に検証されるのではなく、これらのシステムで前提とされる。本発明の実施の形態は、ＯＥＭブートモジュール９５１を検証することを超えて、ＯＳローダ及び他のＥＦＩモジュールを認証するためにイネーブルにされる。これは、多数の署名されたＯＳインスタンスを記憶し、署名されたアプリケーションを検証する機能を提供する。
【００１６】
既存のＭＩＤシステムでは、ＯＳローダ及びＯＳコードは、１つの実行可能な画像として記憶されることが理解される。ＭＩＤでＵＥＦＩアーキテクチャを実現することは、ブート及びＯＳロードのそれぞれのフェーズについて画像の分離を可能にする。本発明の実施の形態は、それぞれの個々の画像がそれ自身のデジタル署名を有し、独立に検証される場合があるように、ＵＥＦＩアーキテクチャの構築を利用する。また、これは、個々のコンポーネントが必要に応じて更新又は変更されるのを可能にする。
【００１７】
幾つかの実施の形態では、ＭＩＤにおいて代替的なオペレーティングシステムをブートする機能を提供することが望まれる場合がある。たとえば、多数のオペレーティングシステムが携帯電話に既にロードされているか、又は遠隔的にロードされて適切に認証されることができる場合に、同じスマートフォンでセルラーキャリアの間で、携帯電話のユーザにとってより便利である。この場合、ユーザに新たな携帯電話を購入させるのではなく、新たなキャリアから再ブートを要求し、カスタムソフトウェアによりキャリアにＭＩＤ（スマートフォン）を再ブートさせることがユーザにとって望ましい。また、同じキャリアを続ける間でさえ、装置の好適なソフトウェアに基づいて、異なるオペレーティングシステムをブートすることが望まれる場合がある。しかし、新たなオペレーティングシステムの始動が検証及び許可されることが重要である。例示する目的のため、モバイルインターネットデバイスを示すが、カメラ機能又はミュージックストレージ及び再生のような他のアプリケーションがモバイルデバイスに選択的にインストールされる場合があるが、インターネットアクセスは本発明を実現するために必要とされないことを理解されたい。
【００１８】
ＭＩＤがＵＥＦＩアーキテクチャを使用するとき、代替的なオペレーティングシステムは、ＵＥＦＩ ＯＳローダを利用し、ＵＥＦＩファームウェアは、セキュリティプロセッサと通信し、ＥＦＩドライバ及びローダを署名するため、認証された変数及び証明書を不揮発性メモリに記憶し、認証された変数は、セキュリティプロセッサの不揮発性メモリ及び／又はプラットフォームフラッシュのセキュアエリアに記憶され、セキュリティプロセッサのＲＳＡエンジンにより署名される。セキュリティプロセッサは、ドライバの実行環境（ＤＸＥ）及びプレＥＦＩ初期化環境（ＰＥＩ）コードが正しく、破壊されていないことを保証する場合がある。次いで、ＤＸＥフェーズは、セキュリティプロセッサの機能を使用して、ＵＥＦＩのセキュアなブートのために証明書及び許可証を管理する。
【００１９】
セキュリティプロセッサは、プライマリプロセッサにアクセス不可能なそれ自身のメモリストレージを有する場合がある。鍵及び証明書は、プライマリプロセッサで実行する悪意のあるコードによる改ざんの危険なしに、セキュリティプロセッサストレージにセキュアに記憶される。別の実施の形態では、鍵及び証明書は、ホストプロセッサにアクセス不可能なホストプロセッサのフラッシュメモリのセキュアなエリアに記憶される場合がある。この領域確保は、プラットフォームのチップセットによりイネーブルにされ、セキュリティプロセッサへのアクセスのみを可能にする。
【００２０】
ＯＥＭブートモジュールを検証するため、典型的に、ＯＥＭは、ＭＩＤのチップセットに公開鍵を記憶する。ＯＥＭブートモジュールは署名され、公開鍵でチェックされる場合がある。署名されたモジュールがセキュリティプロセッサにより検証されたとき、チップセットは、ブートを開始するためにプライマリプロセッサにモジュールを解放する。
【００２１】
セキュアなマルチメディアのスタック９６１、セキュアな管理容易性のスタック９６３（すなわちＲｅａｌＮｅｔｗｏｒｋｓ社からのＨｅｌｉｘのようなメディアプレーヤソフトウェア）を保持し、ＭＩＤで実行されるべき様々なアプリケーションのうちで署名されたアプリケーション９６５を検証することが望ましく、ＯＳローダまで及びＯＳローダを含めて、プリブート環境が信頼されない場合に、プラットフォームは、これらのアプリケーションにおいて信頼を構築することができない。本発明の実施の形態は、ＯＥＭブートモジュールに加えて、これらのアプリケーションが検証されたことを保証する。したがって、本発明の実施の形態は、ＭＩＤプライマリプロセッサで実行する全てのモジュールは、鍵及び署名技術を使用して検証及び認証されたことを保証し、この場合、鍵はセキュリティプロセッサにより管理される。
【００２２】
図１０を参照して、本発明の実施の形態に係る、埋め込まれたセキュリティプロセッサを有する暗号化ユニットが示される。暗号化セル１０００は、埋め込まれたセキュリティプロセッサ９３１を有する。セキュリティプロセッサ９３１は、ＲＯＭ９３５及びシステムＲＡＭ９３７の両者に接続される。暗号化セル１０００は、セキュアデバックマネージャ１０１０を含む場合がある。セキュアデバックマネージャは、ＪＴＡＧ（Joint Test Action Group）標準のテストアクセスポート１０１１、及びバンダリスキャンを使用してプリント回路ボードをテストするために使用されるテストアクセスポート用のバンダリスキャンアーキテクチャに結合される。暗号化コア１０２０は、典型的に、リング発振器１０２１に結合される固定された機能のハードウェアである。暗号化セル１０００は、それ自身のクロック１０３０及びパワー１０４０を有する。クロック１０３０は、外部クロック１０３１で駆動又は同期される。暗号化コア１０２０は、署名及び検証のために使用される非対称及び対称暗号化のためのＲＳＡアルゴリズム又は他のアルゴリズムにより使用されるモジュラー演算を加速する。暗号化のための固定された機能のハードウェアを使用することは、これらの機能のためにＸ８６プロセッサを使用するコストのため、ＭＩＤシステムにとって典型的であり、この場合、コストは、価格、サイズ、効率及び電力の要件により測定される。暗号化セル１０００への電力は、外部のパワーユニット１０４１及びリセットユニット１０４３により駆動又はリセットされる。暗号化セル１０００は、不揮発性メモリ（ＮＶＭ）ユニット１０５１を制御するため、不揮発性メモリ（ＮＶＭ）マネージャ１０５０を有する。
【００２３】
暗号化セル１０００は、ＡＨＢ（Advanced High-performance Bus）マスタ及びＡＰＢ（Advanced Peripheral Bus）スレーブをもつシステムインタフェース１０７０を有する。ＡＨＢは、インテリジェントセキュリティプロセッサとホストとの間の相互接続である。ＡＨＢは、幾つかの優れたコマンドを保持することができる。暗号化演算のようなこれらのコマンドの幾つかは、固定された機能のハードウェアでそれらを処理するため、ＡＰＢに送出される場合がある。暗号化のために固定化された機能のハードウェアを有することは、汎用プロセッサで暗号化を実行するよりも良好なＭＩＰＳ（Millions of Instructions Per Second）／ワット効率を有する。
【００２４】
実施の形態では、ＵＥＦＩのブートが検証及び認証されたことを保証するために使用される証明書は、セキュリティプロセッサにアクセス可能な不揮発性メモリ１０５１に記憶される。ｘ５０９ｖ２標準に準拠するような証明書は、ｎ組の情報をそれぞれ記憶する。この情報は、公開鍵、証明書がアクティブである日付／時間、Ｖｅｒｉｓｉｇｎ又はＯＳベンダのような信頼される第三者（ＴＴＰ）からの証明書の署名を含む。かかるように、公開鍵１０５３は、検証を支援するために暗号化セル１０００のチップセットＮＶＭ１０５１に記憶される場合がある。ブートを認証するために使用されるプロセスは、以下に更に記載される。実施の形態では、使用される証明書の署名及び鍵の技術は、署名の鍵を使用して既存のシステムで使用されるものに類似している。しかし、既存の方法は、改ざんの危険なしに、ＭＩＤプライマリプロセッサで直接的に使用することができない。
【００２５】
図１は、署名技術を現在使用するシステムにおけるブート及びシステムインテグリティを保証するために使用される署名の鍵の階層を例示する。この署名の階層は、ルート及びリーフをもつカノニカルなストアである。破線で輪郭が描かれた鍵は、書き込みがプロテクトされたストレージにある場合がある。本発明の実施の形態では、このプロテクトされたストレージは、プライマリプロセッサ又はデバイスオペレーティングシステムではなく、セキュリティデバイスにアクセス可能である。例示的なＵＥＦＩの実施の形態では、ＰＶ−００、ＰＶ−０１、ＰＶ−３０及びＰＶ−３１（１０１ａ−ｄ）は、ＵＥＦＩプロテクトされた変数をプロテクトする鍵を表す。これらプロテクトされた変数（ＰＶ）は、署名されたＵＥＦＩローダ及びドライバを示す。ＫｅＫ0pub，ＫｅＫ1pub，ＫｅＫ2pub及びＫｅＫ3pub（１０３ａ−ｄ）は、暗号化コアを記憶する公開鍵を表す。ＵＥＦＩファームウェアは、暗号化コアに送出されるコマンドを介して、署名が正しいかを調べるため、公開鍵１０３を使用してＵＥＦＩドライバ及びローダに埋め込まれたデジタル署名をチェックする。幾つかの鍵は、プロテクトされた変数に応答しない場合がある。それぞれのオペレーティングシステムのローダは、典型的に、それ自身の鍵を有する。たとえば、プラットフォームは、Ｗｉｎｄｏｗｓ（登録商標）ローダ及びＬｉｎｕｘローダの両者を有する場合がある。両者がプロテクトされる必要がある。それぞれのローダは、それ自身の公開鍵を有する。それぞれのＯＳベンダは、典型的に、それらのローダのプロダクツをデジタルで署名する。プラットフォームの鍵（ＰＫ）は、会社の情報技術（ＩＴ）部門のようなプラットフォームのオーナがプラットフォームに与える鍵である。プラットフォームは、ＰＫを使用して、全ての他の鍵を暗号化／署名する。たとえば、ＯＳベンダ又は独立したハードウェアベンダ（ＩＨＶ）からの鍵ＫＥＫ１０３は、ＰＫ１０５を使用して暗号化される。言い換えれば、プラットフォームのファームウェアは、ＰＫを使用して、ＫＥＫを保護する。
【００２６】
Platform_admin_r１０７は、システム又はプラットフォームのアドミニストレータ又はＩＴプロフェッショナルを表す。このアドミニストレータは、典型的に、鍵／署名／暗号化機能をオンにし、ＰＫ１０５をインストールする。幾つかのシステムでは、プラットフォームアドミニストレータ１０７は、マネージメントコンソールに存在し、Ｉｎｔｅｌアクティブマネージメントテクノロジ（ｉＡＭＴ）ネットワーキングを介するような、ネットワークを介してコマンドをＵＥＦＩマシンに送出することでセキュアなブート機能を遠隔的にインストール及び始動する。携帯電話のＭＩＤシステムについて、プラットフォームアドミニストレータは、アドミニストレイティブコンソールに対して（ＴＬＳ／ＳＳＬのような）信頼されるチャネルを想定するか、又はＯＭＡ（OpenMobileAlliance.org）プロトコルのような他の技術を使用して、ワイヤレスセルラー通信を介するか、又はインターネット接続を介して鍵／署名をオンにする。
【００２７】
リモートサーバ１１０は、プラットフォーム鍵１１３ａ又はＯＳローダ鍵１１３ｂのような秘密鍵、証明書及び廃止リストをアクティブなディレクトリ１１１に保持する。アクティブディレクトリ１１１は、企業のレジストリである。レジストリは、管理されるプラットフォームに関する情報を保持する。良好／有効な鍵のリストは、アクティブなディレクトリ１１１に記憶される場合がある。他のシステムでは、管理可能性エンジン（ME: Manageability Engine）又はＩｎｔｅｌアクティブマネージメントテクノロジ（ｉＡＭＴ）デバイスは、リモートサーバ１１０のアクティブディレクトリ１１１にアクセスし、鍵が有効であるか、又は鍵が取り消されているかを判定する。代替において、ＭＥは、たとえばパブリックなインターネットを介して、他のリモートサーバ又はネットワークにアクセスし、良好又は取り消された鍵のリストを検索する。本発明の実施の形態では、セキュリティプロセッサは、鍵及び証明書を管理するために使用される。証明書のリストは、プライマリプロセッサではなく、セキュリティプロセッサにアクセス可能な不揮発性メモリ（ＮＶＭ）に記憶される一方で、証明書は、ランタイムの間のインターネットのアクセスによる上述されたのと同じやり方で、又はプラットフォームアドミニストレータが無線通信経路を介してＭＩＤに新たな証明書のセットを送出することで更新又は取り消される場合がある。
【００２８】
実施の形態では、セキュリティプロセッサは、ＭＩＤ上のアクティブなハードウェアの部分である。ＵＥＦＩセキュアなブートは、セキュアなブートをイネーブルにする、検証の実施のための信頼できる起点（Root of Trust for Enforcement of Validation (RTE/RTV)）を追加する。ＲＴＥ及び「セキュアなブート」は、実際に、ホワイトリスト又はデジタル署名におけるハッシュのような幾つかのインテグリティメトリックにソフトウェアの状態が合致しない場合に、ブートを途中停止させる。ＵＥＦＩは、両方のケースをイネーブルにするか、後者を支持する。これは、可能性のあるハッシュのリストは際限がなく、管理上の悪夢となる可能性があるからである。公開鍵は、間接のレベル（a level of indirection）について、鍵を幾つかの信頼されるソースにマッピングすることを可能にし、したがってデプロイメントに関する管理の問題が解消される。
【００２９】
本発明の実施の形態により対処される問題は、（１）第三者のＵＥＦＩドライバ、アプリケーション及びＯＳローダの証明書を管理する１つのポリシーメカニズムを有すること、及び（２）ひとたびプラットフォームオーナがプレＯＳ又はＯＳの何れかにおいてシステムのオーナシップを取得すると、第三者のＵＥＦＩドライバ、アプリケーション及びＯＳローダの実行を許可すること、を含む。
【００３０】
セキュリティプロセッサは、プラットフォームオーナ、プラットフォームファームウェア、及び第三者（すなわちＯＳＶ、ＯＥＭ等）の間の信頼関係を可能にする。信頼関係を記述する２つのタイプの証明書が利用される場合がある。第一に、プラットフォームの証明書が使用され、プラットフォームのオーナとファームウェアとの間の信頼関係が確立される。プラットフォームのオーナは、オーナシップを取得して他の証明書を登録するために使用される、非対称鍵の対を含むルートの証明書としてプラットフォームの証明書を形成する。第二に、第三者の証明書は、第三者のベンダとファームウェアとの間の信頼関係を確立する。プラットフォームオーナは、信頼される第三者のベンダの証明書を登録する場合があり、この証明書は、第三者の実行ファイルの実行を許可するために使用される。この種類の証明書は、ベンダにより生成された公開鍵、及びベンダに特化した情報の両者を含む場合がある。
【００３１】
プラットフォームの証明書は秘密鍵を含み、第三者の証明書を登録するために使用されるので、ローカルマシンは、明示的な秘密鍵の操作（すなわちペイロードの署名）を必要とする。ＭＩＤでは、デスクトップシステム又は他の既存のシステムにおけるものとしてこれら２つの問題に対処することは困難である。したがって、本発明の実施の形態は、ストレージのための信頼できる起点（ＲＴＳ）としてセキュリティプロセッサを使用するクリエイティブなやり方を提供して、プラットフォームの証明書を生成し、第一の問題に係らず秘密鍵をセキュアに記憶する。後者の問題に関して、本実施の形態は、セキュリティプロセッサを使用して、署名の動作を内部的に実行するものであり、これは、秘密鍵を露出しない。
【００３２】
実施の形態では、プラットフォームのオーナの視点でＳＥＴＵＰ及びＵＳＥＲモードといった２つの動作モードが定義される。セキュリティポリシーは、後者のモードで強制される。特に、ＳＥＴＵＰは、証明書を提供させるためにコンピュータがオープンである場合であり、ＵＳＥＲモードは、ＵＥＦＩファームウェアが、検証のために信頼できる起点（ＲＴＶ）となり、デジタルで署名されたＵＥＦＩのＯＳローダ又はドライバのみを起動し、証明書における関連される検証の公開鍵は、ＭＩＤデバイスにインストールされる場合である。
【００３３】
図２は、プラットフォームのオーナがオーナシップを取得し、セキュリティプロセッサによりプラットフォームの証明書を生成するときのフローを説明する。図２は、例示的な実現を示す。ＳＥＴＵＰモード２０１は、オーナシップを取得し、プラットフォームの証明書を登録し、制御をＵＳＥＲモード２０３に移す。ＵＳＥＲモード２０３は、第三者の証明書を登録する。ＵＳＥＲモード２０３は、オーナシップをＳＥＴＵＰモード２０１に譲る。
【００３４】
この後者の動作は、ＭＩＤシステムが悪意のあるソフトウェアにより攻撃されたときに起こる場合があり、ＵＦＥＩファームウェアは、もはやコンピュータをブートせず、したがってコンピュータをドアストップと同様に実用的にする。自然の応答は、デバイスのオーナにとって、キャリア／サプライヤに返送することである。工場に戻って、特定のハードウェアの兆候／刺激／他のメカニズムが使用され、コンピュータがユーザモードからセットアップモードに移され、コンピュータへの証明書及び／又はソフトウェアのロードが再提供される。
【００３５】
図３は、本発明の実施の形態に係る、オーナシップを取得し、プラットフォームの証明書を登録する方法を説明するフローチャートである。これは、デバイスの証明書のデータベースを生成又は更新する１つの可能性のある方法を説明する。プラットフォームのアドミニストレータ３１０は、携帯電話の場合において携帯電話会社であり、オーナシップのインストールが必要であるかをブロック３０１で判定する。オーナシップのインストールが必要である場合、ブロック３０３で、アドミニストレータは、現在の所在をアサートする。これは、デバイスがアドミニストレータの制御を任せる前に、製造の間に典型的に実行される。幾つかの実施の形態では、証明書を登録するために現在の所在ではなくアウトオブバンドの所在が使用される。SecProcForceClearのコマンドは、オーナシップをクリアするためにセキュリティプロセッサに送出される。次いで、ブロック３０５において、秘密のプラットフォーム鍵（ＰＫ）を使用してオーナはクリアされる。セキュリティプロセッサでＳＥＴＵＰモードに入る。オーナが既にインストールされるとき、及びオーナシップをクリアして、ＳＥＴＵＰモードに入った後、ブロック３０７において、管理上のパスワードが送出される。ブロック３０９において、プラットフォームの証明書の一部として鍵の対が形成される。ブロック３１１で、公開のプラットフォーム鍵ＰＫpub、秘密のプラットフォーム鍵（ＰＫpri）の関数としての暗号化演算（ＥSRK）により、鍵の対３４０が形成される場合がある。用語ＥSRK（ＰＫpri）は、秘密のプラットフォーム鍵での暗号化演算を示す。暗号化は、秘密鍵（ＰＫpri）に影響を与え、この秘密鍵は、セキュリティプロセッサをそのままにぜず、これにより、公開鍵の暗号化の問題が解決され、誰かが君の秘密鍵を取得した場合、彼らはコンピュータを所有する。セキュリティプロセッサは、秘密鍵へのこれらの影響をプロキシするものであり、ｘ８６ＵＥＦＩコードが秘密鍵それ自身を扱う必要がない。鍵の対は、不揮発性ストレージ３３０に記憶される。SecProcCreateKeyコマンドは、鍵の対を生成するため、セキュリティプロセッサ３２０で実行される場合がある。ひとたび、鍵の対が形成されると、セキュリティプロセッサは、ＵＳＥＲモードに入る。ブロック３１３において、他の証明書が登録される場合がある。
【００３６】
図４は、本発明の実施の形態を実現するために使用される例示的なＣコードを説明する。それぞれの画像は、ロード及び起動されるのを許可される前に認証される必要がある。実施の形態では、ＵＥＦＩ画像は、典型的に、ＰＥ／ＣＯＦＦ（Portable Executable and Common Object File Format）実行可能な画像である。それぞれのＰＥ／ＣＯＦＦ画像は、セキュリティディレクトリとよばれる部分を有する。セキュリティディレクトリは、画像のデジタル署名及び関連される公開鍵を含む。ＰＥ／ＣＯＦＦ画像及び関連する公開鍵のハッシュは、画像を認証するためにセキュリティプロセッサに送出される。セキュリティプロセッサは、証明書のデータベースから適切な証明書を検索し、チップセットの暗号化ハードウェア機能を使用して画像を認証する。図４を参照して、それぞれのＵＥＦＩ画像について、機能AuthenticateImageWithSecProc() ４０１が実行され、セキュリティの違反（EFI_SECURITY_VIOLATION）がリターンされたかに関する判定４０３が行われる。セキュリティの違反がリターンされた場合、次の画像を認証するために次の画像（NextImage()）４０５機能が実行される。ブート、又はファームウェア、画像が認証された場合、LaunchImage()機能４０７を実行することで起動される。セキュリティプロセッサ（AuthenticateImageWithSecProc()）４０１による画像の認証は、画像の証明書（Image_Credential）が第三者の証明書データベース４０９にあるか、及び画像の証明書が第三者の認証の証明書のデータベース４１１により検証されるかを判定することを含む。画像の証明書が第三者の証明書データベース４０９にあり、画像の証明書が第三者の認証の証明書のデータベース４１１により検証される場合、機能は成功４１３をリターンする。これらのチェックの何れかが失敗した場合、機能は、セキュリティの違反（EFI_SECURITY_VIOLATION）４１５でリターンする。
【００３７】
これらの証明書は、ＵＥＦＩ ＥＦＩの証明書のデータベース（EFI_CERTIFICATE_DATABASE）のタイプ４４０に記憶され、持続性のある又は不揮発性のストレージに記憶される。また、本発明の実施の形態は、ネットワークでロードされるプリブート実行環境（PXE: Pre-boot Execution Environment）画像を認証するために使用される場合がある。セキュリティプロセッサは、提供されるＮＶＭ及び認証されたアクセスによりこのストレージを保護する。
【００３８】
なお、様々なオペレーティングシステム及びローダが様々なフォーマットを使用する場合があり、すなわち常にＰＥ／ＣＯＦＦを使用するものではないことを理解されたい。セキュリティプロセッサは、全ての許容可能なオペレーティングシステムについてフォーマットを受けるために構成される。フォーマットに係らず、画像は、デジタル署名と、セキュリティプロセッサにアクセス可能であってデバイスのプライマリプロセッサにアクセス不可能な証明書データベースと整合されるべき公開鍵とを含む。
【００３９】
証明書のデータベースのために使用されるデータ構造の例は、図４に示される。EFI_CERTIFICATE_DATABASE４４０は、データベースのサイズ、証明書のリストのカウント、及び証明書のリストデータを含む。証明書のリスト（EFI_CERTIFICATE_LIST）データ構造４５０は、証明書のリストのサイズ、証明書のカウント、証明書のタイプ、証明書のヘッダサイズ、証明書のヘッダ、及び証明書を含む場合がある。証明書のデータ構造は、識別子及びデータを含む場合がある。識別子は、グルーバル一意識別子（GUID）である場合がある。証明書データ（EFI_CERTIFICATE_DATA）６４０は、ＧＵＩＤ及び任意のサイズのテキストフィールドを有する構造である。
【００４０】
図５は、本発明の実施の形態に係る、ＵＥＦＩ証明書のデータベース５００の構造を更に視覚的に例示する。データベースの一般的な構造は、ヘッダ５０１及び３つの証明書のリスト５０３ａ〜ｃにより左に示される。証明書のリスト５１０は、リストサイズ５１１、証明書のカウント５１３、タイプ５１５、ヘッダサイズ５１７、証明書のサイズ５１９証明書のヘッダ５２０、及び、識別子５２１ａ〜ｎ及びデータ５２３ａ〜ｎを有するそれぞれの証明書５３０により右に示される。
【００４１】
図６は、本発明の実施の形態に係る、プラットフォームのオーナが第三者の認証の証明書を登録する方法を説明するフローチャートである。この登録は、たとえばＯＥＭにより提供される全てのＵＥＦＩドライバを認証する証明書といった、関連する第三者の実行ファイルのセットの１つの認証の実行のために使用される。ステップ６０１において、プラットフォームアドミニストレータ３１０は、プラットフォームの鍵（ＰＫ）が生成されたかを判定するためにチェックを始動する。ブロック６０３において、アドミニストレータを認証するためにパスワードのチャレンジが典型的に必要とされる。ブロック６０５において、アドミニストレータは、第三者の証明書の署名を認証する。この署名は、セキュリティプロセッサ３２０における鍵の形成（SecProcCreateKey）、署名（SecProcSign）及び鍵のアンロード（SecProcUnloadKey）の機能の実行を始動する。適切なストレージルートの鍵（ＥSRK）６４０の動作は、不揮発性ストレージ３３０からセキュリティプロセッサによりリターンされる。次いで、ブロック６０７において、第三者の証明書は登録され、ブロック６０９において、署名がデータベースに登録され、特に、署名の登録は、秘密鍵えおもつ証明書を改ざん防止の位置に記憶すること、又は、その後の画像の検証における使用のために実行ファイルのハッシュを保持することである。
【００４２】
図７は、本発明の実施の形態に係る、プラットフォームのオーナが署名を登録する方法を説明するフローチャートである。この登録は、他の実行ファイルに係らず、実行ファイルの実行を認証するために使用される場合がある。ブロック７０１において、プラットフォームアドミニストレータ３１０は、署名の登録を始動する。ブロック７０３において、署名は、Security_Arch_Protocolを使用して認証される。ブロック７０５で判定されるように認証が成功した場合、ブロック７０９において、パスワードのチャレンジがアドミニストレータに課される。認証が成功しない場合、ブロック７０７において、とにかく署名が追加されるべきかに関して、プラットフォームのベンダに特化したポリシーを使用した判定が行われる。署名が追加されるべきではない場合、ブロック７４０において、完了することなしに、登録が存在する。とにかく署名が追加されるべきである場合、ブロック７０９において、パスワードのチャレンジによる処理が継続する。ひとたび、アドミニストレータが正しいパスワードを入力すると、ブロック７１１において、セキュリティプロセッサ３２０により、鍵はロードされ（SecProcLoadKey）、署名され（SecProcSign）、次いで鍵はアンロードされる（SecProcUnloadKey）。次いで、ブロック７１３において、署名は、変数（SetVariable機能）を設定することでＮＶＭ３３０に登録される。プロセスは、ブロック７６０において完了する。これは、更なる署名をデータベースに追加する管理行為を実行するプロセスである。これは、デバイスのオーナが、デバイスの製造の間にその証明書が登録される新たなオペレーティングシステムのローダ又はアプリケーションを起動するのを望む場合に行われる場合がある。
【００４３】
図８は、本発明の実施の形態に係る、ＵＥＦＩ実行ファイルを認証する例示的な方法を説明するフローチャートである。ブロック８０１で、ＭＩＤは電源オンにされるか、又はリセットされる。ブロック８０３で、最初の鍵は記憶され、これは、工場が供給するＮＶＭ／データベースとすることができる。ブロック８０５において、上述されたように、セキュリティプロセッサは、公開鍵に対する署名をチェックすることで、ＵＥＦＩの検証が成功したかを判定する。検証が失敗した場合、ブロック８０９において、ＵＥＦＩの実行ファイルが認証されたかが判定される。許可されたアプリケーションは署名されたアプリケーションであり、関連される公開の検証鍵をプラットフォームに有し、ＵＥＦＩ画像におけるデジタル署名は、検証テストを通過する。検証のアクションは、たとえばブロック８２３において後に実行される場合があり、この場合、画像は、データベースにはない場合があるが、ＯＳのランタイムの間、ＯＳは、リモートオーソリティと通信し、画像の状態を問い合わせするか、又はユーザが次にこの画像を登録／実行するのを望むかを判定するためにユーザに問い合わせる場合がある。
【００４４】
ＵＥＦＩの実行ファイルが認証されない場合、ブロック８１３において、次のブートオプションが試みられる場合がある。あるケースでは、このブートオプションは、ブートするためのデバイスの完全な失敗である場合がある。他のケースでは、ブートオプションは、管理モードＯＳをブートするか、少なく機能するＯＳをブートする場合がある。ブロック８１５において、プラットフォームアドミニストレータがＵＥＦＩの署名をシステムのコンフィギュレーションテーブルに追加し、ブロック８１３において、次のブートオプションが試みられるまで、ブートが延期される場合がある。
【００４５】
検証が成功したとき、ブロック８０７において、ＵＥＦＩの実行ファイルは記憶される。検証が失敗したが、認証が許可されたとき、ＵＥＦＩの実行ファイルの署名は、ブロック８０７において実行ファイルが開始される前に、ブロック８１１において、データベース８３０に保存される。
【００４６】
ひとたび、ブロック８２１においてＯＳが起動されると、ブロック８２３において、ＯＳアプリケーションがＵＥＦＩ実行ファイルで検証されたかに関する判定が行われる。ＯＳアプリケーションがＵＥＦＩ実行ファイルで検証されない場合、プロセスはブロック８５０で終了する。検証された場合、ブロック８２５において、ＵＥＦＩの実行ファイルの署名データベースが更新され、プロセスは、ブロック８５０で終了する。
【００４７】
モバイルインターネットデバイスのアーキテクチャは、携帯電話の市場を更に厳密に目標とするため、意図的に「ＰＣ互換性」を避ける場合がある。そうすることにおいて、ＳＥＮＴＥＲのようなＴＸＴ ＧＥＴＳＥＣ命令のようなインバンドプロセッサの信頼されるプラットフォーム技術の幾つかを省略／除く。代わりに、ＭＩＤアーキテクチャは、上述されたように、専用の統合されたセキュリティプロセッサを選ぶ場合がある。そうすることにおいて、ＭＩＤは、「ＯＥＭブートモジュール」の充填に対するエコシステムのギャップを有する。この「ギャップ」は、ＢＩＯＳベンダがＰＣ／ＡＴプラットフォームのブートコードを構築することに慣れているためである。ＰＣ／ＡＴから発散することで、トラディショナルなＢＩＯＳは、ＭＩＤでもはや機能しない。早期の初期化のためのＵＥＦＩプラットフォームの初期化（ＰＩ）コード及びＯＳロードのためのＵＥＦＩインタフェースからなる、モジュール性のあるプラットフォームに独立な設計がここでは有利である。ＵＥＦＩ及びＰＩコードは、このノントラディショナルな（すなわちＰＣ／ＡＴではない）プラットフォームについて再びターゲットとされる。その点で、更に多くのフォームは、ＵＥＦＩを介して追加され、ＵＥＦＩのセキュアなブートの誘導的なセキュリティを使用して、手を携えてセキュリティプロセッサと機能し、ランタイム環境への製造者の信頼を維持する。特に、セキュリティプロセッサは、署名されたＵＥＦＩ ＰＩファームウェアボリュームを理解することが教示される。ＤＸＥにおけるＵＥＦＩの実現は、セキュリティプロセッサを使用して、（画像の検証のために使用される公開鍵と共に）証明書を記憶し、ＵＥＦＩ ＯＳローダ及びドライバを認証する（すなわち、ＳＨＡのような１方向ハッシュ関数及びＲＳＡのようなデジタル署名アルゴリズムを実行する）。
【００４８】
本発明の実施の形態は、記憶のための信頼できる起点（ＲＴＳ）としてセキュリティプロセッサを使用して、上述されたように秘密鍵を露出する危険なしに、ペイロードの署名のような暗号化の動作と同様に、鍵の生成及び記憶のような鍵の管理を実行する。既存のシステムでは、認証された変数の使用は、認証された変数のＡｕｔｈＩｎｆｏフィールドを幾つかのインバンドコードに署名させることを必要とし、これは、シールドされた位置を有することなしに危険となる可能性がある。セキュリティプロセッサは、シールドされた位置及びプラットフォームでの認証された変数を署名することを許容し、これは、コンピュータから離れてリモートの署名サーバで署名が行われる必要がある幾つかのスキームとは対照的である。この後者の、コンピュータから離れた署名は、更新又は管理行為が行われるときは何時でもモバイルデバイスとリモートサーバとの同期を必要とするために扱いにくい。
【００４９】
また、本発明の実施の形態は、上から下へ、言い換えれば、プラットフォームの証明書から第三者のａｕｔｈ−証明書及び第三者のｅｘｅ−証明書への方式で、証明書の階層を確立する。これにより、１つの証明書への依存を除き、同様に、証明書の発行者を区別する。さらに、本発明の実施の形態は、単一のサインオンのシナリオを実現する。たとえば、プラットフォームオーナは、同じ認証データでＯＳ及びプレＯＳフェーズの両者でオーナシップを取得する。
【００５０】
さらに、セキュリティプロセッサを利用する本発明の実施の形態は、マルウェアを実行することで引き起こされるダメージを回避するため、許可されないコードの実行を禁止する。
【００５１】
Ｉｔａｎｉｕｍ（登録商標）プラットフォーム及びＭＩＤは、ＴＸＴ又はＬＴ−ＳＸを有さないので、本発明の実施の形態は、ＯＳローダを含めて、プレＯＳ実行ファイルを検証するために使用される場合があり、これにより、アタックベクタ（attack vector）としてマルウェアがプレＯＳを利用することができない。
【００５２】
セキュリティプロセッサは、デジタル著作権管理（ＤＲＭ）、信頼されるブート及びセキュアな記憶のようなＭＩＤ使用のためのハードウェアに基づいたセキュリティエンジンである。セキュリティプロセッサは、暗号化機能（対称、ＰＫＩ）、ハッシュ機能及び認証のためのハードウェアの高速化（acceleration）を提供する。セキュリティプロセッサは、ＤＲＭライセンス／ライトオブジェクト（ＲＯ）（たとえばどの位長く映画を視聴することができるか、歌が再生されるか等）を分析し、コンテンツの復号のための鍵を抽出し、システムメモリに鍵を決して露出しない。また、セキュリティプロセッサは、ＤＲＭライセンス／ＲＯファイルからの抽出された鍵を使用してＤＲＭコンテンツを復号する場合がある。
【００５３】
本実施の形態で記載された技術は、特定のハードウェア又はソフトウェアコンフィギュレーションに限定されず、これらの技術は、計算、家電製品、又は処理環境における応用を発見する場合がある。これらの技術は、ハードウェア、ソフトウェア、又は２つの組み合わせで実現される場合がある。
【００５４】
シミュレーションについて、プログラムコードは、ハードウェア記述言語、又は設計されたハードウェアがどのように実行することが期待されるかに関するモデルを本質的に提供する別の機能記述言語を使用したハードウェアを表す場合がある。プログラムコードは、アセンブリ又はコンピュータ言語、或いは、コンパイル及び／又は解釈されるデータである場合がある。さらに、ソフトウェアについて、ある形式又は別の形式において動作を行うか又は結果を生じさせることは、当該技術分野において一般的である。係る表現は、プロセッサに動作を実行させるか又は結果を生じさせる処理システムにより、プログラムコードの実行を提示する簡単明瞭なやり方である。
【００５５】
それぞれのプログラムは、処理システムと通信するため、ハイレベルの手続き又はオブジェクト指向のプログラミング言語で実現される。しかし、プログラムは、望まれる場合、アセンブリ又はコンピュータ言語で実現される。何れのケースにおいて、言語はコンパイル又は解釈される場合がある。
【００５６】
プログラム命令は、命令でプログラムされた汎用又は特定用途の処理システムに本実施の形態で記載された動作を実行させるために使用される。代替的に、動作は、動作を実行するハードワイヤドロジックを含む特定のハードウェアコンポーネントによるか、プログラムされたコンピュータコンポーネントとカスタムハードウェアコンポーネントとの組み合わせにより実行される場合がある。本実施の形態で記載される方法は、本方法を実行するために処理システム又は他の電子装置をプログラムするために使用される命令を記憶したコンピュータによりアクセス可能な媒体を含むコンピュータプログラムプロダクトとして提供される場合がある。
【００５７】
プログラムコード、又は命令は、たとえば、コンピュータによりアクセス可能な生物学的状態を保持するストレージのような更にエキゾチックな媒体と同様に、固体メモリ、ハードドライブ、フロプティカルディスク、光ストレージ、テープ、フラッシュメモリ、メモリスティック、デジタルビデオディスク、デジタルバーサティルディスク（ＤＶＤ）等を含むストレージデバイス及び／又は関連されるコンピュータにより読取り可能又はコンピュータによりアクセス可能な媒体のような揮発性及び／又は不揮発性メモリに記憶される場合がある。コンピュータにより読み取り可能な媒体は、コンピュータにより読み取り可能な形式で情報を記憶、送信又は受信するメカニズムを含み、媒体は、電気、光、音又は他の形式のプログラムコードを符号化する伝播信号又は搬送波がアンテナ、光ファイバ、通信インタフェース等を通過する有形の媒体を含む場合がある。プログラムコードは、パケット、シリアルデータ、パラレルデータ、伝播信号等の形式で伝送され、圧縮又は暗号化された形式で使用される場合がある。
【００５８】
プログラムコードは、携帯型又は静止型コンピュータ、パーソナルデジタルアシスタント、携帯電話及びページャ、家電製品（ＤＶＤプレーヤ、パーソナルビデオレコーダ、パーソナルビデオプレーヤ、サテライトレシーバ、ステレオレシーバ、ケーブルＴＶレシーバを含む）、プロセッサ、プロセッサにより読み取り可能な揮発性及び／又は不揮発性メモリ、少なくとも１つの入力装置及び／又は１以上の出力装置を含む他の電子装置のようなプログラマブルコンピュータで実行するプログラムで実現される場合がある。プログラムコードは、記載された実施の形態を実行して出力情報を生成するために入力装置を使用して入力されるデータに印加される場合がある。出力情報は、１以上の出力装置に印加される場合がある。当業者であれば、開示された主題の実施の形態は、広汎性又はミニチュアコンピュータ、或いは任意の装置に仮想的に埋め込まれるプロセッサと同様に、マルチプロセッサ又はマルチコアプロセッサシステム、ミニコンピュータを含む様々なコンピュータシステムのコンフィギュレーションで実施することができることを理解されたい。開示された主題の実施の形態は、そのタスク又は部分が通信ネットワークを通してリンクされるリモート処理装置により実行される分散されたコンピュータ環境においても実施することができる。
【００５９】
動作は順次的なプロセスとして記載されたが、動作の幾つかは、並列、同時、及び／又は分散された環境で実行される場合があり、プログラムコードは、シングルプロセッサマシン又はマルチプロセッサマシンによるアクセスのためにローカル及び／又はリモートに記憶される。さらに、幾つかの実施の形態では、動作の順序は、開示された主題の精神から逸脱することなしに再配列される場合がある。プログラムコードは、埋め込まれたコントローラにより、又は埋め込まれたコントローラにより使用される場合がある。
【００６０】
本発明は例示的な実施の形態を参照して記載されたが、この記載は、限定的な意味で解釈されるべきではないことが意図される。本発明が属する当業者にとって明らかである本発明の他の実施の形態と同様に、例示的な実施の形態の様々な変更は、本発明の精神及び範囲にあるとみなされる。
【技術分野】
【０００１】
本発明の実施の形態は、モバイルコンピューティングプラットフォームに関し、より詳細には、本発明の実施の形態は、プラットフォームオーナ又はアドミニストレータのための機能を追加して、署名されたコンポーネントによるような、オーナにより許可されたやり方でのみファームウェアが実行されることを保証するものである。
【０００２】
本実施の形態は、ＣＲＴＭ（Core Root of Trust for Measurement）を、ＲＴＳ（Root-of-Trust for Storage）ＳＲＫ（Storage Root Key）としてモバイル装置における暗号化コプロセッサの使用を介して、ＵＥＦＩ（Unified Extensible Firmware Interface）ＰＩ（Platform Initialization）の画像認証及びブートマネージャに拡張する場合がある。
【０００３】
本実施の形態には、著作権保護を受けるマテリアルが含まれる。著作権者は、特許商標庁のファイル又はレコードに現れたときに任意の人物による特許の開示のファクシミリの複製に対して異論はなく、さもなければ、無断での複写・複製・転載を禁じる。
【背景技術】
【０００４】
セキュアなブート（secure booting）のための様々なメカニズムが存在する。ＵＥＦＩ（Unified Extensible Firmware Interface）仕様は、オペレーティングシステムとプラットフォームファームウェアとの間のインタフェース向けの新たなモデルを定義する。このインタフェースは、プラットフォームに関連する情報に加え、オペレーティングシステム及びそのローダにとって利用可能なブート及びランタイムのサービスコールを含むデータテーブルから構成される。同時に、これらは、オペレーティングシステムをブートし、プリブートアプリケーションを実行する標準的な環境を提供する。ＵＥＦＩに関する更なる情報は、ＵＲＬ www*uefi*org/homeでのパブリックなインターネットで発見される場合がある。不注意なハイパーリンクを防止するため、この文書ではピリオドはアスタリスクで置き換えられている。ＵＥＦＩ標準は、プラットフォームのセキュアなブートを支援するために使用される。
【０００５】
ＵＥＦＩ仕様２．１の２６節は、セキュアなブートのプロトコルを記載する。定義されたプロトコルは、特定のデバイスパスをもつ一般的な認証情報のためのアクセスを提供する。プロトコルは、物理的又は論理的なデバイスに関連する情報を取得するために任意のデバイスで使用される場合がある。公開鍵及び証明書は、ファームウェアで保持され、第三者の（Ｕ）ＥＦＩドライバ及びオペレーティングシステム（ＯＳ）ローダでデジタル署名をチェックする。プラットフォームに公開鍵を束縛することは、デプロイメントの問題となっている。セキュリティは、プラットフォームが公開鍵をセキュアに記憶することができるのと同様に良好である（すなわち、恐ろしい「鍵の管理の問題」）。公開鍵又は証明書のブートタイムでの失効は、可能ではない。サーバからの証明書失効リスト（ＣＲＬ）を解明することができないので、早期のブート環境は、ネットワークにアクセスすることができない。偽者のローダは、セキュリティを巧みに逃れるためにプラットフォームに挿入される場合がある。したがって、このセキュアなブート方法は、ブートタイムの間の攻撃に対して脆弱である場合がある。
【０００６】
モバイルデバイス、及びより詳細にはモバイルインターネットデバイス（ＭＩＤ）は、使用においてユビキタスになっている。モバイルデバイスをブートする様々なメカニズムが存在し、これらの方法は、デスクトップ及びラップトップシステムをブートするために使用される方法とは異なる。デスクトップ及びサーバプラットフォームでは、ＴＣＧ（Trusted Computing Group）により文書化されるチップのタイプであるＴＰＭ（Trusted Platform Module）コンポーネントは、バージョン１．２である承認された最新の変形によれば、セキュアなブートを支援するために使用される場合がある。ＴＰＭは、ＡＭＤ社のＰｒｅｓｉｄｉｏ及びそのＳＫＩＮＩＴインストラクション又はＩｎｔｅｌ社のＳＥＮＴＥＲインストラクションを使用したＴＸＴ（Trusted-eXecution-Technology）（aka LaGrande Technology）のようなプロセッサ／チップセット技術と結合されたとき、これらのタイプのプラットフォームでのファームウェアのブートをプロテクトする役割をする場合がある。しかし、ＭＩＤプロセッサは、ＴＸＴ（Trusted-eXecution-Technology）又はＴＣＧ１．２ＴＰＭをサポートせず、したがって、ファームウェアの「セキュアなブート」及びプラットフォームにおける信頼できる起点（root-of-trust）は、オペレーティングシステム（ＯＳ）ブートストラップの一部として必要とされる。追加されたセキュリティのため、オペレーティングシステムの始動の前にＭＩＤでのファームウェアのブートをプロテクトすることが望まれる場合がある。これは、音楽及び他のマルチメディアのようなハイバリューコンテンツがＭＩＤシステムで使用され、コンテンツプロバイダにより要求される高いプロテクションを必要とする場合があるために特に当てはまる。
【発明の概要】
【課題を解決するための手段】
【０００７】
本発明の実施の形態は、モバイルデバイスに関するシステム及び方法である。例示的な目的について、本発明の実施の形態は、モバイルインターネットデバイス（ＭＩＤ）に関連するものとして記載される。しかし、本発明の実施の形態は、携帯電話、ポータブルＭＰ３プレーヤ、パーソナルデジタルアシスタント（ＰＤＡ）又は、インターネットアクセスを有さない他のモバイルデバイスに適用可能な場合がある。本発明の実施の形態は、プラットフォームのオーナ又はアドミニストレータの能力を追加して、署名されたコンポーネントによるようなオーナーにより許可されたやり方でのみファームウェアが実行されることを保証する。本実施の形態は、測定のための信頼できるコアとなる起点（CRTM: Core Root of Trust for Measurement）を、記憶のための信頼できる起点（RTS: Root-of-Trust for Storage）の記憶の起点の鍵（SRK: Storage Root Key）として、モバイル装置における暗号化コプロセッサの使用を介して、ＵＥＦＩ（Unified Extensible Firmware Interface）のＰＩ（Platform Initialization）の画像認証及びブートマネージャに拡張する場合がある。
【０００８】
本発明の「１実施の形態」又は「実施の形態」に対する明細書における参照は、実施の形態との関連で記載される特定の特徴、構造又は特性が本発明の少なくとも１つの実施の形態に含まれることを意味する。したがって、明細書を通して様々な場所で現れるフレーズ「１実施の形態では」の登場は、必ずしも、同じ実施の形態を全て参照するものではない。
【０００９】
説明のために、本発明の全体的な理解を提供するために特定のコンフィギュレーション及び詳細が述べられる。しかし、本発明の実施の形態は、本明細書で与えられる特定の詳細なしに実施される場合があることが当業者にとって明らかであろう。さらに、公知の特徴は、本発明を曖昧にしないために省略又は簡略化される場合がある。様々な例は、この説明を通して与えられる場合がある。これらは、本発明の特定の実施の形態の単なる記載である。本発明の範囲は、与えられる例に限定されない。
【００１０】
本発明の実施の形態は、不透明な「ＯＥＭブートモジュール」を採用し、ＵＥＦＩのセキュアなブート及びプラットフォームの初期化（PI: Platform Initialization）に基づくファームウェアのポリシーに基づくディスパッチを適用してセキュリティのソリューションを実施し、ＭＩＤを市場に提供するＯＥＭ（Original Equipment Manufactures）及びＯＤＭ（Original Design Manufactures）を可能にする。特に、この技術分野は、セキュアなブートのプラットフォームドライバ、第三者のオプションのＲＯＭ（O-ROM）、並びに（Microsoft Windows（登録商標）向け）Winroad.efi及び（Linux向け）eLifo.efiのようなＯＳローダを含む。ｅＬｉｆｏは、ＥＦＩに基づくＰＣハードウェア用の標準的なＬｉｎｕｘブートローダである。実施の形態は、認証された可変のサービスを要求する前にプラットフォームのオーナがペイロードを署名しなければならないときに、秘密鍵を露出する危険を除く。また、実施の形態は、ＳＳＯ（Single Sign-On）シナリオ、及び１タッチの提供を実現する。たとえば、プラットフォームのオーナは、同じ認証データにより、ＯＳフェーズ及びプレＯＳフェーズの両者においてオーナシップを取得する場合がある。
【００１１】
本発明の実施の形態は、秘密の署名鍵を管理するためにＭＩＤのセキュリティプロセッサを利用する。これにより、セキュリティプロセッサのポリシーエンジンをもつＵＥＦＩのセキュリティブートは、マネージャビリティ及びプロビジョニングインフラストラクチャに継ぎ目なく統合することができる。
【図面の簡単な説明】
【００１２】
本発明の特徴及び利点は、本発明の以下の詳細な説明から明らかとなるであろう。
【図１】署名の技術を使用してシステムにおけるブート及びシステムインテグリティを保証するために使用される署名鍵の階層を例示するブロック図である。
【図２】本発明の実施の形態に係る、プラットフォームのオーナがオーナシップを取得し、セキュリティプロセッサによりプラットフォームの証明書を生成するときのフローを例示する図である。
【図３】本発明に係る、オーナシップを取得し、プラットフォームの証明書を登録する方法を例示するフローチャートである。
【図４】本発明の実施の形態を実現するために使用される例示的なＣコードを説明する図である。
【図５】本発明の実施の形態に係る、証明書のデータベースの例示的な構造を説明するブロック図である。
【図６】本発明の実施の形態に係る、プラットフォームのオーナが第三者の認証の証明書を登録する方法を説明するフローチャートである。
【図７】本発明の実施の形態に係る、プラットフォームのオーナがデジタル署名を登録する方法を説明するフローチャートである。
【図８】本発明の実施の形態に係る、実行可能なＵＥＦＩを許可する例示的な方法を説明するフローチャートである。
【図９】本発明の実施の形態に係る、プライマリプロセッサエレメント及びセキュリティ処理チップセットを有するプラットフォームを例示するブロック図である。
【図１０】本発明の実施の形態に係る、埋め込まれたセキュリティプロセッサを有する例示的な暗号化ユニットのブロック図である。
【発明を実施するための最良の形態】
【００１３】
図９を参照して、プライマリ又はホストプロセッサエレメント９１０及びセキュリティプロセッシングチップセット９３０を有するプラットフォーム９００を例示するブロック図が示される。本発明の実施の形態では、プラットフォーム９００は、マルウェアからプロテクトするためにセキュアなＯＳのブートを必要とするプライマリプロセッサ９１１をもつプライマリランタイム環境９１０を有する。プロセッサ９１１は、システムメモリ９０５に結合される。セキュリティプロセッサのチップセットユニット９３０は、セキュリティエンジン又はプロセッサ９３１、（ｘ８６ファームウェアをロードする前にプラットフォームの初期化の幾つかを行う）システムコントローラ（ＡＲＣ）９３３、及び専用のリードオンリメモリ（ＲＯＭ）９３５を有する。ＲＯＭは、コード及びデータを更に保護して、セキュアブートを保証するために使用され、リードオンリであるとき、コード及びデータは、悪意のある改ざんにより変更されない場合がある。フラッシュメモリ９２０は、セキュリティプロセッサに結合され、プライマリプロセッサ９１１をブートするためにブートソフトウェアの画像９２１を保持する。プライマリプロセッサ９１１にロードされるブートソフトウェア画像は認証され、マルウェアがないことが重要である。
【００１４】
実施の形態では、検証されたブートは、セキュリティチップセット９３０を使用して実現される場合がある。セキュリティエンジン９３１は、以下に説明されるように、鍵及び署名の手順を実現するために構成される。セキュリティプロセッサ９３１は、プライマリプロセッサ９１１によるアクセスから隔離される専用装置であるので、セキュリティエンジンは、改ざんからプロテクトされる。セキュリティエンジンは、プライマリプロセッサがブートするのを可能にする前に、プライマリプロセッサについてブートＲＯＭを検証するために構成される。たとえばＩｎｔｅｌ（登録商標）Ｃｏｒｅ（登録商標）２Ｄｕｏに基づくＰＣ（Personal Computer）といった既存のシステムでは、プライマリプロセッサは、検証することなしに、フラッシュの部分、すなわちブートＲＯＭにブート制御を自動的に移す。幾つかのデスクトップ、ラップトップ又は他のフル機能ＰＣでは、ＴＸＴ技術は、ブートＲＯＭ及び後続する処理を検証するのを介入する。プラットフォームは、ブートプロセスまでセキュアな状態になり、特に、ＳＥＮＴＥＲ命令により起動されるＴＸＴマイクロコードは、プラットフォーム上の全てのプロセッサを同期させ、測定された起動環境（MLE: Measured Launch Environment）について、オプションのＲＯＭ及びプラットフォームのＢＩＯＳを含めて、その前に実行したソフトウェアの全てに独立にすることができる。しかし、ＴＸＴ処理は、ＭＩＤ及び他の低コストプラットフォームで利用可能ではない。実施の形態では、セキュリティプロセッサは、他のシステムにおけるＴＸＴに対する代替として、ブートＲＯＭを検証するためにＭＩＤに追加される。しかし、セキュアプロセッサを有するＭＩＤの実施の形態では、ＯＥＭのブートモジュールのみが検証されることが可能である。
【００１５】
ＯＥＭブートモジュール９５１は、基本的にＵＥＦＩファームウェアである。セキュリティプロセッサ９３０は、ＯＥＭブートモジュール９５１を検証する。ひとたび検証されると、セキュリティプロセッサ９３０は、ＯＥＭブートモジュール９５１をプライマリプロセッサ９１１のＳＲＡＭ９０５にコピーする。ＯＥＭブートモジュールは、プレＥＦＩ初期化（ＰＥＩ）及びドライバ実行環境（ＤＸＥ）を包含する場合がある。これらのフェーズは、オペレーティングシステム（ＯＳ）が起動される前に実行される必要がある。幾つかのシステムでは、ひとたびＯＥＭブートモジュールが実行されると、ＯＳローダ９５３は、ＰＥＩフェーズから始動される。ＯＳローダ９５３は、信頼されたＯＳ９５５を始動する。しかし、ＯＳの信頼は、実際に検証されるのではなく、これらのシステムで前提とされる。本発明の実施の形態は、ＯＥＭブートモジュール９５１を検証することを超えて、ＯＳローダ及び他のＥＦＩモジュールを認証するためにイネーブルにされる。これは、多数の署名されたＯＳインスタンスを記憶し、署名されたアプリケーションを検証する機能を提供する。
【００１６】
既存のＭＩＤシステムでは、ＯＳローダ及びＯＳコードは、１つの実行可能な画像として記憶されることが理解される。ＭＩＤでＵＥＦＩアーキテクチャを実現することは、ブート及びＯＳロードのそれぞれのフェーズについて画像の分離を可能にする。本発明の実施の形態は、それぞれの個々の画像がそれ自身のデジタル署名を有し、独立に検証される場合があるように、ＵＥＦＩアーキテクチャの構築を利用する。また、これは、個々のコンポーネントが必要に応じて更新又は変更されるのを可能にする。
【００１７】
幾つかの実施の形態では、ＭＩＤにおいて代替的なオペレーティングシステムをブートする機能を提供することが望まれる場合がある。たとえば、多数のオペレーティングシステムが携帯電話に既にロードされているか、又は遠隔的にロードされて適切に認証されることができる場合に、同じスマートフォンでセルラーキャリアの間で、携帯電話のユーザにとってより便利である。この場合、ユーザに新たな携帯電話を購入させるのではなく、新たなキャリアから再ブートを要求し、カスタムソフトウェアによりキャリアにＭＩＤ（スマートフォン）を再ブートさせることがユーザにとって望ましい。また、同じキャリアを続ける間でさえ、装置の好適なソフトウェアに基づいて、異なるオペレーティングシステムをブートすることが望まれる場合がある。しかし、新たなオペレーティングシステムの始動が検証及び許可されることが重要である。例示する目的のため、モバイルインターネットデバイスを示すが、カメラ機能又はミュージックストレージ及び再生のような他のアプリケーションがモバイルデバイスに選択的にインストールされる場合があるが、インターネットアクセスは本発明を実現するために必要とされないことを理解されたい。
【００１８】
ＭＩＤがＵＥＦＩアーキテクチャを使用するとき、代替的なオペレーティングシステムは、ＵＥＦＩ ＯＳローダを利用し、ＵＥＦＩファームウェアは、セキュリティプロセッサと通信し、ＥＦＩドライバ及びローダを署名するため、認証された変数及び証明書を不揮発性メモリに記憶し、認証された変数は、セキュリティプロセッサの不揮発性メモリ及び／又はプラットフォームフラッシュのセキュアエリアに記憶され、セキュリティプロセッサのＲＳＡエンジンにより署名される。セキュリティプロセッサは、ドライバの実行環境（ＤＸＥ）及びプレＥＦＩ初期化環境（ＰＥＩ）コードが正しく、破壊されていないことを保証する場合がある。次いで、ＤＸＥフェーズは、セキュリティプロセッサの機能を使用して、ＵＥＦＩのセキュアなブートのために証明書及び許可証を管理する。
【００１９】
セキュリティプロセッサは、プライマリプロセッサにアクセス不可能なそれ自身のメモリストレージを有する場合がある。鍵及び証明書は、プライマリプロセッサで実行する悪意のあるコードによる改ざんの危険なしに、セキュリティプロセッサストレージにセキュアに記憶される。別の実施の形態では、鍵及び証明書は、ホストプロセッサにアクセス不可能なホストプロセッサのフラッシュメモリのセキュアなエリアに記憶される場合がある。この領域確保は、プラットフォームのチップセットによりイネーブルにされ、セキュリティプロセッサへのアクセスのみを可能にする。
【００２０】
ＯＥＭブートモジュールを検証するため、典型的に、ＯＥＭは、ＭＩＤのチップセットに公開鍵を記憶する。ＯＥＭブートモジュールは署名され、公開鍵でチェックされる場合がある。署名されたモジュールがセキュリティプロセッサにより検証されたとき、チップセットは、ブートを開始するためにプライマリプロセッサにモジュールを解放する。
【００２１】
セキュアなマルチメディアのスタック９６１、セキュアな管理容易性のスタック９６３（すなわちＲｅａｌＮｅｔｗｏｒｋｓ社からのＨｅｌｉｘのようなメディアプレーヤソフトウェア）を保持し、ＭＩＤで実行されるべき様々なアプリケーションのうちで署名されたアプリケーション９６５を検証することが望ましく、ＯＳローダまで及びＯＳローダを含めて、プリブート環境が信頼されない場合に、プラットフォームは、これらのアプリケーションにおいて信頼を構築することができない。本発明の実施の形態は、ＯＥＭブートモジュールに加えて、これらのアプリケーションが検証されたことを保証する。したがって、本発明の実施の形態は、ＭＩＤプライマリプロセッサで実行する全てのモジュールは、鍵及び署名技術を使用して検証及び認証されたことを保証し、この場合、鍵はセキュリティプロセッサにより管理される。
【００２２】
図１０を参照して、本発明の実施の形態に係る、埋め込まれたセキュリティプロセッサを有する暗号化ユニットが示される。暗号化セル１０００は、埋め込まれたセキュリティプロセッサ９３１を有する。セキュリティプロセッサ９３１は、ＲＯＭ９３５及びシステムＲＡＭ９３７の両者に接続される。暗号化セル１０００は、セキュアデバックマネージャ１０１０を含む場合がある。セキュアデバックマネージャは、ＪＴＡＧ（Joint Test Action Group）標準のテストアクセスポート１０１１、及びバンダリスキャンを使用してプリント回路ボードをテストするために使用されるテストアクセスポート用のバンダリスキャンアーキテクチャに結合される。暗号化コア１０２０は、典型的に、リング発振器１０２１に結合される固定された機能のハードウェアである。暗号化セル１０００は、それ自身のクロック１０３０及びパワー１０４０を有する。クロック１０３０は、外部クロック１０３１で駆動又は同期される。暗号化コア１０２０は、署名及び検証のために使用される非対称及び対称暗号化のためのＲＳＡアルゴリズム又は他のアルゴリズムにより使用されるモジュラー演算を加速する。暗号化のための固定された機能のハードウェアを使用することは、これらの機能のためにＸ８６プロセッサを使用するコストのため、ＭＩＤシステムにとって典型的であり、この場合、コストは、価格、サイズ、効率及び電力の要件により測定される。暗号化セル１０００への電力は、外部のパワーユニット１０４１及びリセットユニット１０４３により駆動又はリセットされる。暗号化セル１０００は、不揮発性メモリ（ＮＶＭ）ユニット１０５１を制御するため、不揮発性メモリ（ＮＶＭ）マネージャ１０５０を有する。
【００２３】
暗号化セル１０００は、ＡＨＢ（Advanced High-performance Bus）マスタ及びＡＰＢ（Advanced Peripheral Bus）スレーブをもつシステムインタフェース１０７０を有する。ＡＨＢは、インテリジェントセキュリティプロセッサとホストとの間の相互接続である。ＡＨＢは、幾つかの優れたコマンドを保持することができる。暗号化演算のようなこれらのコマンドの幾つかは、固定された機能のハードウェアでそれらを処理するため、ＡＰＢに送出される場合がある。暗号化のために固定化された機能のハードウェアを有することは、汎用プロセッサで暗号化を実行するよりも良好なＭＩＰＳ（Millions of Instructions Per Second）／ワット効率を有する。
【００２４】
実施の形態では、ＵＥＦＩのブートが検証及び認証されたことを保証するために使用される証明書は、セキュリティプロセッサにアクセス可能な不揮発性メモリ１０５１に記憶される。ｘ５０９ｖ２標準に準拠するような証明書は、ｎ組の情報をそれぞれ記憶する。この情報は、公開鍵、証明書がアクティブである日付／時間、Ｖｅｒｉｓｉｇｎ又はＯＳベンダのような信頼される第三者（ＴＴＰ）からの証明書の署名を含む。かかるように、公開鍵１０５３は、検証を支援するために暗号化セル１０００のチップセットＮＶＭ１０５１に記憶される場合がある。ブートを認証するために使用されるプロセスは、以下に更に記載される。実施の形態では、使用される証明書の署名及び鍵の技術は、署名の鍵を使用して既存のシステムで使用されるものに類似している。しかし、既存の方法は、改ざんの危険なしに、ＭＩＤプライマリプロセッサで直接的に使用することができない。
【００２５】
図１は、署名技術を現在使用するシステムにおけるブート及びシステムインテグリティを保証するために使用される署名の鍵の階層を例示する。この署名の階層は、ルート及びリーフをもつカノニカルなストアである。破線で輪郭が描かれた鍵は、書き込みがプロテクトされたストレージにある場合がある。本発明の実施の形態では、このプロテクトされたストレージは、プライマリプロセッサ又はデバイスオペレーティングシステムではなく、セキュリティデバイスにアクセス可能である。例示的なＵＥＦＩの実施の形態では、ＰＶ−００、ＰＶ−０１、ＰＶ−３０及びＰＶ−３１（１０１ａ−ｄ）は、ＵＥＦＩプロテクトされた変数をプロテクトする鍵を表す。これらプロテクトされた変数（ＰＶ）は、署名されたＵＥＦＩローダ及びドライバを示す。ＫｅＫ0pub，ＫｅＫ1pub，ＫｅＫ2pub及びＫｅＫ3pub（１０３ａ−ｄ）は、暗号化コアを記憶する公開鍵を表す。ＵＥＦＩファームウェアは、暗号化コアに送出されるコマンドを介して、署名が正しいかを調べるため、公開鍵１０３を使用してＵＥＦＩドライバ及びローダに埋め込まれたデジタル署名をチェックする。幾つかの鍵は、プロテクトされた変数に応答しない場合がある。それぞれのオペレーティングシステムのローダは、典型的に、それ自身の鍵を有する。たとえば、プラットフォームは、Ｗｉｎｄｏｗｓ（登録商標）ローダ及びＬｉｎｕｘローダの両者を有する場合がある。両者がプロテクトされる必要がある。それぞれのローダは、それ自身の公開鍵を有する。それぞれのＯＳベンダは、典型的に、それらのローダのプロダクツをデジタルで署名する。プラットフォームの鍵（ＰＫ）は、会社の情報技術（ＩＴ）部門のようなプラットフォームのオーナがプラットフォームに与える鍵である。プラットフォームは、ＰＫを使用して、全ての他の鍵を暗号化／署名する。たとえば、ＯＳベンダ又は独立したハードウェアベンダ（ＩＨＶ）からの鍵ＫＥＫ１０３は、ＰＫ１０５を使用して暗号化される。言い換えれば、プラットフォームのファームウェアは、ＰＫを使用して、ＫＥＫを保護する。
【００２６】
Platform_admin_r１０７は、システム又はプラットフォームのアドミニストレータ又はＩＴプロフェッショナルを表す。このアドミニストレータは、典型的に、鍵／署名／暗号化機能をオンにし、ＰＫ１０５をインストールする。幾つかのシステムでは、プラットフォームアドミニストレータ１０７は、マネージメントコンソールに存在し、Ｉｎｔｅｌアクティブマネージメントテクノロジ（ｉＡＭＴ）ネットワーキングを介するような、ネットワークを介してコマンドをＵＥＦＩマシンに送出することでセキュアなブート機能を遠隔的にインストール及び始動する。携帯電話のＭＩＤシステムについて、プラットフォームアドミニストレータは、アドミニストレイティブコンソールに対して（ＴＬＳ／ＳＳＬのような）信頼されるチャネルを想定するか、又はＯＭＡ（OpenMobileAlliance.org）プロトコルのような他の技術を使用して、ワイヤレスセルラー通信を介するか、又はインターネット接続を介して鍵／署名をオンにする。
【００２７】
リモートサーバ１１０は、プラットフォーム鍵１１３ａ又はＯＳローダ鍵１１３ｂのような秘密鍵、証明書及び廃止リストをアクティブなディレクトリ１１１に保持する。アクティブディレクトリ１１１は、企業のレジストリである。レジストリは、管理されるプラットフォームに関する情報を保持する。良好／有効な鍵のリストは、アクティブなディレクトリ１１１に記憶される場合がある。他のシステムでは、管理可能性エンジン（ME: Manageability Engine）又はＩｎｔｅｌアクティブマネージメントテクノロジ（ｉＡＭＴ）デバイスは、リモートサーバ１１０のアクティブディレクトリ１１１にアクセスし、鍵が有効であるか、又は鍵が取り消されているかを判定する。代替において、ＭＥは、たとえばパブリックなインターネットを介して、他のリモートサーバ又はネットワークにアクセスし、良好又は取り消された鍵のリストを検索する。本発明の実施の形態では、セキュリティプロセッサは、鍵及び証明書を管理するために使用される。証明書のリストは、プライマリプロセッサではなく、セキュリティプロセッサにアクセス可能な不揮発性メモリ（ＮＶＭ）に記憶される一方で、証明書は、ランタイムの間のインターネットのアクセスによる上述されたのと同じやり方で、又はプラットフォームアドミニストレータが無線通信経路を介してＭＩＤに新たな証明書のセットを送出することで更新又は取り消される場合がある。
【００２８】
実施の形態では、セキュリティプロセッサは、ＭＩＤ上のアクティブなハードウェアの部分である。ＵＥＦＩセキュアなブートは、セキュアなブートをイネーブルにする、検証の実施のための信頼できる起点（Root of Trust for Enforcement of Validation (RTE/RTV)）を追加する。ＲＴＥ及び「セキュアなブート」は、実際に、ホワイトリスト又はデジタル署名におけるハッシュのような幾つかのインテグリティメトリックにソフトウェアの状態が合致しない場合に、ブートを途中停止させる。ＵＥＦＩは、両方のケースをイネーブルにするか、後者を支持する。これは、可能性のあるハッシュのリストは際限がなく、管理上の悪夢となる可能性があるからである。公開鍵は、間接のレベル（a level of indirection）について、鍵を幾つかの信頼されるソースにマッピングすることを可能にし、したがってデプロイメントに関する管理の問題が解消される。
【００２９】
本発明の実施の形態により対処される問題は、（１）第三者のＵＥＦＩドライバ、アプリケーション及びＯＳローダの証明書を管理する１つのポリシーメカニズムを有すること、及び（２）ひとたびプラットフォームオーナがプレＯＳ又はＯＳの何れかにおいてシステムのオーナシップを取得すると、第三者のＵＥＦＩドライバ、アプリケーション及びＯＳローダの実行を許可すること、を含む。
【００３０】
セキュリティプロセッサは、プラットフォームオーナ、プラットフォームファームウェア、及び第三者（すなわちＯＳＶ、ＯＥＭ等）の間の信頼関係を可能にする。信頼関係を記述する２つのタイプの証明書が利用される場合がある。第一に、プラットフォームの証明書が使用され、プラットフォームのオーナとファームウェアとの間の信頼関係が確立される。プラットフォームのオーナは、オーナシップを取得して他の証明書を登録するために使用される、非対称鍵の対を含むルートの証明書としてプラットフォームの証明書を形成する。第二に、第三者の証明書は、第三者のベンダとファームウェアとの間の信頼関係を確立する。プラットフォームオーナは、信頼される第三者のベンダの証明書を登録する場合があり、この証明書は、第三者の実行ファイルの実行を許可するために使用される。この種類の証明書は、ベンダにより生成された公開鍵、及びベンダに特化した情報の両者を含む場合がある。
【００３１】
プラットフォームの証明書は秘密鍵を含み、第三者の証明書を登録するために使用されるので、ローカルマシンは、明示的な秘密鍵の操作（すなわちペイロードの署名）を必要とする。ＭＩＤでは、デスクトップシステム又は他の既存のシステムにおけるものとしてこれら２つの問題に対処することは困難である。したがって、本発明の実施の形態は、ストレージのための信頼できる起点（ＲＴＳ）としてセキュリティプロセッサを使用するクリエイティブなやり方を提供して、プラットフォームの証明書を生成し、第一の問題に係らず秘密鍵をセキュアに記憶する。後者の問題に関して、本実施の形態は、セキュリティプロセッサを使用して、署名の動作を内部的に実行するものであり、これは、秘密鍵を露出しない。
【００３２】
実施の形態では、プラットフォームのオーナの視点でＳＥＴＵＰ及びＵＳＥＲモードといった２つの動作モードが定義される。セキュリティポリシーは、後者のモードで強制される。特に、ＳＥＴＵＰは、証明書を提供させるためにコンピュータがオープンである場合であり、ＵＳＥＲモードは、ＵＥＦＩファームウェアが、検証のために信頼できる起点（ＲＴＶ）となり、デジタルで署名されたＵＥＦＩのＯＳローダ又はドライバのみを起動し、証明書における関連される検証の公開鍵は、ＭＩＤデバイスにインストールされる場合である。
【００３３】
図２は、プラットフォームのオーナがオーナシップを取得し、セキュリティプロセッサによりプラットフォームの証明書を生成するときのフローを説明する。図２は、例示的な実現を示す。ＳＥＴＵＰモード２０１は、オーナシップを取得し、プラットフォームの証明書を登録し、制御をＵＳＥＲモード２０３に移す。ＵＳＥＲモード２０３は、第三者の証明書を登録する。ＵＳＥＲモード２０３は、オーナシップをＳＥＴＵＰモード２０１に譲る。
【００３４】
この後者の動作は、ＭＩＤシステムが悪意のあるソフトウェアにより攻撃されたときに起こる場合があり、ＵＦＥＩファームウェアは、もはやコンピュータをブートせず、したがってコンピュータをドアストップと同様に実用的にする。自然の応答は、デバイスのオーナにとって、キャリア／サプライヤに返送することである。工場に戻って、特定のハードウェアの兆候／刺激／他のメカニズムが使用され、コンピュータがユーザモードからセットアップモードに移され、コンピュータへの証明書及び／又はソフトウェアのロードが再提供される。
【００３５】
図３は、本発明の実施の形態に係る、オーナシップを取得し、プラットフォームの証明書を登録する方法を説明するフローチャートである。これは、デバイスの証明書のデータベースを生成又は更新する１つの可能性のある方法を説明する。プラットフォームのアドミニストレータ３１０は、携帯電話の場合において携帯電話会社であり、オーナシップのインストールが必要であるかをブロック３０１で判定する。オーナシップのインストールが必要である場合、ブロック３０３で、アドミニストレータは、現在の所在をアサートする。これは、デバイスがアドミニストレータの制御を任せる前に、製造の間に典型的に実行される。幾つかの実施の形態では、証明書を登録するために現在の所在ではなくアウトオブバンドの所在が使用される。SecProcForceClearのコマンドは、オーナシップをクリアするためにセキュリティプロセッサに送出される。次いで、ブロック３０５において、秘密のプラットフォーム鍵（ＰＫ）を使用してオーナはクリアされる。セキュリティプロセッサでＳＥＴＵＰモードに入る。オーナが既にインストールされるとき、及びオーナシップをクリアして、ＳＥＴＵＰモードに入った後、ブロック３０７において、管理上のパスワードが送出される。ブロック３０９において、プラットフォームの証明書の一部として鍵の対が形成される。ブロック３１１で、公開のプラットフォーム鍵ＰＫpub、秘密のプラットフォーム鍵（ＰＫpri）の関数としての暗号化演算（ＥSRK）により、鍵の対３４０が形成される場合がある。用語ＥSRK（ＰＫpri）は、秘密のプラットフォーム鍵での暗号化演算を示す。暗号化は、秘密鍵（ＰＫpri）に影響を与え、この秘密鍵は、セキュリティプロセッサをそのままにぜず、これにより、公開鍵の暗号化の問題が解決され、誰かが君の秘密鍵を取得した場合、彼らはコンピュータを所有する。セキュリティプロセッサは、秘密鍵へのこれらの影響をプロキシするものであり、ｘ８６ＵＥＦＩコードが秘密鍵それ自身を扱う必要がない。鍵の対は、不揮発性ストレージ３３０に記憶される。SecProcCreateKeyコマンドは、鍵の対を生成するため、セキュリティプロセッサ３２０で実行される場合がある。ひとたび、鍵の対が形成されると、セキュリティプロセッサは、ＵＳＥＲモードに入る。ブロック３１３において、他の証明書が登録される場合がある。
【００３６】
図４は、本発明の実施の形態を実現するために使用される例示的なＣコードを説明する。それぞれの画像は、ロード及び起動されるのを許可される前に認証される必要がある。実施の形態では、ＵＥＦＩ画像は、典型的に、ＰＥ／ＣＯＦＦ（Portable Executable and Common Object File Format）実行可能な画像である。それぞれのＰＥ／ＣＯＦＦ画像は、セキュリティディレクトリとよばれる部分を有する。セキュリティディレクトリは、画像のデジタル署名及び関連される公開鍵を含む。ＰＥ／ＣＯＦＦ画像及び関連する公開鍵のハッシュは、画像を認証するためにセキュリティプロセッサに送出される。セキュリティプロセッサは、証明書のデータベースから適切な証明書を検索し、チップセットの暗号化ハードウェア機能を使用して画像を認証する。図４を参照して、それぞれのＵＥＦＩ画像について、機能AuthenticateImageWithSecProc() ４０１が実行され、セキュリティの違反（EFI_SECURITY_VIOLATION）がリターンされたかに関する判定４０３が行われる。セキュリティの違反がリターンされた場合、次の画像を認証するために次の画像（NextImage()）４０５機能が実行される。ブート、又はファームウェア、画像が認証された場合、LaunchImage()機能４０７を実行することで起動される。セキュリティプロセッサ（AuthenticateImageWithSecProc()）４０１による画像の認証は、画像の証明書（Image_Credential）が第三者の証明書データベース４０９にあるか、及び画像の証明書が第三者の認証の証明書のデータベース４１１により検証されるかを判定することを含む。画像の証明書が第三者の証明書データベース４０９にあり、画像の証明書が第三者の認証の証明書のデータベース４１１により検証される場合、機能は成功４１３をリターンする。これらのチェックの何れかが失敗した場合、機能は、セキュリティの違反（EFI_SECURITY_VIOLATION）４１５でリターンする。
【００３７】
これらの証明書は、ＵＥＦＩ ＥＦＩの証明書のデータベース（EFI_CERTIFICATE_DATABASE）のタイプ４４０に記憶され、持続性のある又は不揮発性のストレージに記憶される。また、本発明の実施の形態は、ネットワークでロードされるプリブート実行環境（PXE: Pre-boot Execution Environment）画像を認証するために使用される場合がある。セキュリティプロセッサは、提供されるＮＶＭ及び認証されたアクセスによりこのストレージを保護する。
【００３８】
なお、様々なオペレーティングシステム及びローダが様々なフォーマットを使用する場合があり、すなわち常にＰＥ／ＣＯＦＦを使用するものではないことを理解されたい。セキュリティプロセッサは、全ての許容可能なオペレーティングシステムについてフォーマットを受けるために構成される。フォーマットに係らず、画像は、デジタル署名と、セキュリティプロセッサにアクセス可能であってデバイスのプライマリプロセッサにアクセス不可能な証明書データベースと整合されるべき公開鍵とを含む。
【００３９】
証明書のデータベースのために使用されるデータ構造の例は、図４に示される。EFI_CERTIFICATE_DATABASE４４０は、データベースのサイズ、証明書のリストのカウント、及び証明書のリストデータを含む。証明書のリスト（EFI_CERTIFICATE_LIST）データ構造４５０は、証明書のリストのサイズ、証明書のカウント、証明書のタイプ、証明書のヘッダサイズ、証明書のヘッダ、及び証明書を含む場合がある。証明書のデータ構造は、識別子及びデータを含む場合がある。識別子は、グルーバル一意識別子（GUID）である場合がある。証明書データ（EFI_CERTIFICATE_DATA）６４０は、ＧＵＩＤ及び任意のサイズのテキストフィールドを有する構造である。
【００４０】
図５は、本発明の実施の形態に係る、ＵＥＦＩ証明書のデータベース５００の構造を更に視覚的に例示する。データベースの一般的な構造は、ヘッダ５０１及び３つの証明書のリスト５０３ａ〜ｃにより左に示される。証明書のリスト５１０は、リストサイズ５１１、証明書のカウント５１３、タイプ５１５、ヘッダサイズ５１７、証明書のサイズ５１９証明書のヘッダ５２０、及び、識別子５２１ａ〜ｎ及びデータ５２３ａ〜ｎを有するそれぞれの証明書５３０により右に示される。
【００４１】
図６は、本発明の実施の形態に係る、プラットフォームのオーナが第三者の認証の証明書を登録する方法を説明するフローチャートである。この登録は、たとえばＯＥＭにより提供される全てのＵＥＦＩドライバを認証する証明書といった、関連する第三者の実行ファイルのセットの１つの認証の実行のために使用される。ステップ６０１において、プラットフォームアドミニストレータ３１０は、プラットフォームの鍵（ＰＫ）が生成されたかを判定するためにチェックを始動する。ブロック６０３において、アドミニストレータを認証するためにパスワードのチャレンジが典型的に必要とされる。ブロック６０５において、アドミニストレータは、第三者の証明書の署名を認証する。この署名は、セキュリティプロセッサ３２０における鍵の形成（SecProcCreateKey）、署名（SecProcSign）及び鍵のアンロード（SecProcUnloadKey）の機能の実行を始動する。適切なストレージルートの鍵（ＥSRK）６４０の動作は、不揮発性ストレージ３３０からセキュリティプロセッサによりリターンされる。次いで、ブロック６０７において、第三者の証明書は登録され、ブロック６０９において、署名がデータベースに登録され、特に、署名の登録は、秘密鍵えおもつ証明書を改ざん防止の位置に記憶すること、又は、その後の画像の検証における使用のために実行ファイルのハッシュを保持することである。
【００４２】
図７は、本発明の実施の形態に係る、プラットフォームのオーナが署名を登録する方法を説明するフローチャートである。この登録は、他の実行ファイルに係らず、実行ファイルの実行を認証するために使用される場合がある。ブロック７０１において、プラットフォームアドミニストレータ３１０は、署名の登録を始動する。ブロック７０３において、署名は、Security_Arch_Protocolを使用して認証される。ブロック７０５で判定されるように認証が成功した場合、ブロック７０９において、パスワードのチャレンジがアドミニストレータに課される。認証が成功しない場合、ブロック７０７において、とにかく署名が追加されるべきかに関して、プラットフォームのベンダに特化したポリシーを使用した判定が行われる。署名が追加されるべきではない場合、ブロック７４０において、完了することなしに、登録が存在する。とにかく署名が追加されるべきである場合、ブロック７０９において、パスワードのチャレンジによる処理が継続する。ひとたび、アドミニストレータが正しいパスワードを入力すると、ブロック７１１において、セキュリティプロセッサ３２０により、鍵はロードされ（SecProcLoadKey）、署名され（SecProcSign）、次いで鍵はアンロードされる（SecProcUnloadKey）。次いで、ブロック７１３において、署名は、変数（SetVariable機能）を設定することでＮＶＭ３３０に登録される。プロセスは、ブロック７６０において完了する。これは、更なる署名をデータベースに追加する管理行為を実行するプロセスである。これは、デバイスのオーナが、デバイスの製造の間にその証明書が登録される新たなオペレーティングシステムのローダ又はアプリケーションを起動するのを望む場合に行われる場合がある。
【００４３】
図８は、本発明の実施の形態に係る、ＵＥＦＩ実行ファイルを認証する例示的な方法を説明するフローチャートである。ブロック８０１で、ＭＩＤは電源オンにされるか、又はリセットされる。ブロック８０３で、最初の鍵は記憶され、これは、工場が供給するＮＶＭ／データベースとすることができる。ブロック８０５において、上述されたように、セキュリティプロセッサは、公開鍵に対する署名をチェックすることで、ＵＥＦＩの検証が成功したかを判定する。検証が失敗した場合、ブロック８０９において、ＵＥＦＩの実行ファイルが認証されたかが判定される。許可されたアプリケーションは署名されたアプリケーションであり、関連される公開の検証鍵をプラットフォームに有し、ＵＥＦＩ画像におけるデジタル署名は、検証テストを通過する。検証のアクションは、たとえばブロック８２３において後に実行される場合があり、この場合、画像は、データベースにはない場合があるが、ＯＳのランタイムの間、ＯＳは、リモートオーソリティと通信し、画像の状態を問い合わせするか、又はユーザが次にこの画像を登録／実行するのを望むかを判定するためにユーザに問い合わせる場合がある。
【００４４】
ＵＥＦＩの実行ファイルが認証されない場合、ブロック８１３において、次のブートオプションが試みられる場合がある。あるケースでは、このブートオプションは、ブートするためのデバイスの完全な失敗である場合がある。他のケースでは、ブートオプションは、管理モードＯＳをブートするか、少なく機能するＯＳをブートする場合がある。ブロック８１５において、プラットフォームアドミニストレータがＵＥＦＩの署名をシステムのコンフィギュレーションテーブルに追加し、ブロック８１３において、次のブートオプションが試みられるまで、ブートが延期される場合がある。
【００４５】
検証が成功したとき、ブロック８０７において、ＵＥＦＩの実行ファイルは記憶される。検証が失敗したが、認証が許可されたとき、ＵＥＦＩの実行ファイルの署名は、ブロック８０７において実行ファイルが開始される前に、ブロック８１１において、データベース８３０に保存される。
【００４６】
ひとたび、ブロック８２１においてＯＳが起動されると、ブロック８２３において、ＯＳアプリケーションがＵＥＦＩ実行ファイルで検証されたかに関する判定が行われる。ＯＳアプリケーションがＵＥＦＩ実行ファイルで検証されない場合、プロセスはブロック８５０で終了する。検証された場合、ブロック８２５において、ＵＥＦＩの実行ファイルの署名データベースが更新され、プロセスは、ブロック８５０で終了する。
【００４７】
モバイルインターネットデバイスのアーキテクチャは、携帯電話の市場を更に厳密に目標とするため、意図的に「ＰＣ互換性」を避ける場合がある。そうすることにおいて、ＳＥＮＴＥＲのようなＴＸＴ ＧＥＴＳＥＣ命令のようなインバンドプロセッサの信頼されるプラットフォーム技術の幾つかを省略／除く。代わりに、ＭＩＤアーキテクチャは、上述されたように、専用の統合されたセキュリティプロセッサを選ぶ場合がある。そうすることにおいて、ＭＩＤは、「ＯＥＭブートモジュール」の充填に対するエコシステムのギャップを有する。この「ギャップ」は、ＢＩＯＳベンダがＰＣ／ＡＴプラットフォームのブートコードを構築することに慣れているためである。ＰＣ／ＡＴから発散することで、トラディショナルなＢＩＯＳは、ＭＩＤでもはや機能しない。早期の初期化のためのＵＥＦＩプラットフォームの初期化（ＰＩ）コード及びＯＳロードのためのＵＥＦＩインタフェースからなる、モジュール性のあるプラットフォームに独立な設計がここでは有利である。ＵＥＦＩ及びＰＩコードは、このノントラディショナルな（すなわちＰＣ／ＡＴではない）プラットフォームについて再びターゲットとされる。その点で、更に多くのフォームは、ＵＥＦＩを介して追加され、ＵＥＦＩのセキュアなブートの誘導的なセキュリティを使用して、手を携えてセキュリティプロセッサと機能し、ランタイム環境への製造者の信頼を維持する。特に、セキュリティプロセッサは、署名されたＵＥＦＩ ＰＩファームウェアボリュームを理解することが教示される。ＤＸＥにおけるＵＥＦＩの実現は、セキュリティプロセッサを使用して、（画像の検証のために使用される公開鍵と共に）証明書を記憶し、ＵＥＦＩ ＯＳローダ及びドライバを認証する（すなわち、ＳＨＡのような１方向ハッシュ関数及びＲＳＡのようなデジタル署名アルゴリズムを実行する）。
【００４８】
本発明の実施の形態は、記憶のための信頼できる起点（ＲＴＳ）としてセキュリティプロセッサを使用して、上述されたように秘密鍵を露出する危険なしに、ペイロードの署名のような暗号化の動作と同様に、鍵の生成及び記憶のような鍵の管理を実行する。既存のシステムでは、認証された変数の使用は、認証された変数のＡｕｔｈＩｎｆｏフィールドを幾つかのインバンドコードに署名させることを必要とし、これは、シールドされた位置を有することなしに危険となる可能性がある。セキュリティプロセッサは、シールドされた位置及びプラットフォームでの認証された変数を署名することを許容し、これは、コンピュータから離れてリモートの署名サーバで署名が行われる必要がある幾つかのスキームとは対照的である。この後者の、コンピュータから離れた署名は、更新又は管理行為が行われるときは何時でもモバイルデバイスとリモートサーバとの同期を必要とするために扱いにくい。
【００４９】
また、本発明の実施の形態は、上から下へ、言い換えれば、プラットフォームの証明書から第三者のａｕｔｈ−証明書及び第三者のｅｘｅ−証明書への方式で、証明書の階層を確立する。これにより、１つの証明書への依存を除き、同様に、証明書の発行者を区別する。さらに、本発明の実施の形態は、単一のサインオンのシナリオを実現する。たとえば、プラットフォームオーナは、同じ認証データでＯＳ及びプレＯＳフェーズの両者でオーナシップを取得する。
【００５０】
さらに、セキュリティプロセッサを利用する本発明の実施の形態は、マルウェアを実行することで引き起こされるダメージを回避するため、許可されないコードの実行を禁止する。
【００５１】
Ｉｔａｎｉｕｍ（登録商標）プラットフォーム及びＭＩＤは、ＴＸＴ又はＬＴ−ＳＸを有さないので、本発明の実施の形態は、ＯＳローダを含めて、プレＯＳ実行ファイルを検証するために使用される場合があり、これにより、アタックベクタ（attack vector）としてマルウェアがプレＯＳを利用することができない。
【００５２】
セキュリティプロセッサは、デジタル著作権管理（ＤＲＭ）、信頼されるブート及びセキュアな記憶のようなＭＩＤ使用のためのハードウェアに基づいたセキュリティエンジンである。セキュリティプロセッサは、暗号化機能（対称、ＰＫＩ）、ハッシュ機能及び認証のためのハードウェアの高速化（acceleration）を提供する。セキュリティプロセッサは、ＤＲＭライセンス／ライトオブジェクト（ＲＯ）（たとえばどの位長く映画を視聴することができるか、歌が再生されるか等）を分析し、コンテンツの復号のための鍵を抽出し、システムメモリに鍵を決して露出しない。また、セキュリティプロセッサは、ＤＲＭライセンス／ＲＯファイルからの抽出された鍵を使用してＤＲＭコンテンツを復号する場合がある。
【００５３】
本実施の形態で記載された技術は、特定のハードウェア又はソフトウェアコンフィギュレーションに限定されず、これらの技術は、計算、家電製品、又は処理環境における応用を発見する場合がある。これらの技術は、ハードウェア、ソフトウェア、又は２つの組み合わせで実現される場合がある。
【００５４】
シミュレーションについて、プログラムコードは、ハードウェア記述言語、又は設計されたハードウェアがどのように実行することが期待されるかに関するモデルを本質的に提供する別の機能記述言語を使用したハードウェアを表す場合がある。プログラムコードは、アセンブリ又はコンピュータ言語、或いは、コンパイル及び／又は解釈されるデータである場合がある。さらに、ソフトウェアについて、ある形式又は別の形式において動作を行うか又は結果を生じさせることは、当該技術分野において一般的である。係る表現は、プロセッサに動作を実行させるか又は結果を生じさせる処理システムにより、プログラムコードの実行を提示する簡単明瞭なやり方である。
【００５５】
それぞれのプログラムは、処理システムと通信するため、ハイレベルの手続き又はオブジェクト指向のプログラミング言語で実現される。しかし、プログラムは、望まれる場合、アセンブリ又はコンピュータ言語で実現される。何れのケースにおいて、言語はコンパイル又は解釈される場合がある。
【００５６】
プログラム命令は、命令でプログラムされた汎用又は特定用途の処理システムに本実施の形態で記載された動作を実行させるために使用される。代替的に、動作は、動作を実行するハードワイヤドロジックを含む特定のハードウェアコンポーネントによるか、プログラムされたコンピュータコンポーネントとカスタムハードウェアコンポーネントとの組み合わせにより実行される場合がある。本実施の形態で記載される方法は、本方法を実行するために処理システム又は他の電子装置をプログラムするために使用される命令を記憶したコンピュータによりアクセス可能な媒体を含むコンピュータプログラムプロダクトとして提供される場合がある。
【００５７】
プログラムコード、又は命令は、たとえば、コンピュータによりアクセス可能な生物学的状態を保持するストレージのような更にエキゾチックな媒体と同様に、固体メモリ、ハードドライブ、フロプティカルディスク、光ストレージ、テープ、フラッシュメモリ、メモリスティック、デジタルビデオディスク、デジタルバーサティルディスク（ＤＶＤ）等を含むストレージデバイス及び／又は関連されるコンピュータにより読取り可能又はコンピュータによりアクセス可能な媒体のような揮発性及び／又は不揮発性メモリに記憶される場合がある。コンピュータにより読み取り可能な媒体は、コンピュータにより読み取り可能な形式で情報を記憶、送信又は受信するメカニズムを含み、媒体は、電気、光、音又は他の形式のプログラムコードを符号化する伝播信号又は搬送波がアンテナ、光ファイバ、通信インタフェース等を通過する有形の媒体を含む場合がある。プログラムコードは、パケット、シリアルデータ、パラレルデータ、伝播信号等の形式で伝送され、圧縮又は暗号化された形式で使用される場合がある。
【００５８】
プログラムコードは、携帯型又は静止型コンピュータ、パーソナルデジタルアシスタント、携帯電話及びページャ、家電製品（ＤＶＤプレーヤ、パーソナルビデオレコーダ、パーソナルビデオプレーヤ、サテライトレシーバ、ステレオレシーバ、ケーブルＴＶレシーバを含む）、プロセッサ、プロセッサにより読み取り可能な揮発性及び／又は不揮発性メモリ、少なくとも１つの入力装置及び／又は１以上の出力装置を含む他の電子装置のようなプログラマブルコンピュータで実行するプログラムで実現される場合がある。プログラムコードは、記載された実施の形態を実行して出力情報を生成するために入力装置を使用して入力されるデータに印加される場合がある。出力情報は、１以上の出力装置に印加される場合がある。当業者であれば、開示された主題の実施の形態は、広汎性又はミニチュアコンピュータ、或いは任意の装置に仮想的に埋め込まれるプロセッサと同様に、マルチプロセッサ又はマルチコアプロセッサシステム、ミニコンピュータを含む様々なコンピュータシステムのコンフィギュレーションで実施することができることを理解されたい。開示された主題の実施の形態は、そのタスク又は部分が通信ネットワークを通してリンクされるリモート処理装置により実行される分散されたコンピュータ環境においても実施することができる。
【００５９】
動作は順次的なプロセスとして記載されたが、動作の幾つかは、並列、同時、及び／又は分散された環境で実行される場合があり、プログラムコードは、シングルプロセッサマシン又はマルチプロセッサマシンによるアクセスのためにローカル及び／又はリモートに記憶される。さらに、幾つかの実施の形態では、動作の順序は、開示された主題の精神から逸脱することなしに再配列される場合がある。プログラムコードは、埋め込まれたコントローラにより、又は埋め込まれたコントローラにより使用される場合がある。
【００６０】
本発明は例示的な実施の形態を参照して記載されたが、この記載は、限定的な意味で解釈されるべきではないことが意図される。本発明が属する当業者にとって明らかである本発明の他の実施の形態と同様に、例示的な実施の形態の様々な変更は、本発明の精神及び範囲にあるとみなされる。
【特許請求の範囲】
【請求項１】
モバイルプラットフォームでのセキュアなブートのシステムであって、
ホストオペレーティングシステム及びホストアプリケーションを実行するホストプロセッサと、
前記ホストプロセッサをブートするファームウェアであって、ブートの間に１以上の署名鍵を利用するファームウェアと、それぞれの署名鍵は、ブートの間に前記プラットフォームにロードされるソフトウェア画像に関連され、
前記ファームウェア及び他のホストプロセッサのアプリケーションにとってアクセス不可能であるセキュアメモリストアに結合される前記プラットフォームのセキュリティプロセッサであって、前記１以上の署名鍵を管理してブートの間の画像のロードを制御するセキュリティプロセッサと、
を有することを特徴とするシステム。
【請求項２】
前記セキュアメモリストアは、前記セキュリティプロセッサに結合される不揮発性メモリストアに存在する、
請求項１記載のシステム。
【請求項３】
前記セキュリティプロセッサは、デジタル署名を検証するのを支援する暗号化コアに結合されるチップセットに存在する、
請求項１記載のシステム。
【請求項４】
前記プラットフォームのチップセットに結合される公開鍵と、
前記セキュアメモリストアに記憶される証明書データベースとを更に有し、
前記証明書データベースは、複数の証明書を記憶し、それぞれの証明書は、前記ホストプロセッサにより実行可能な複数のソフトウェア画像のうちの１つに対応し、
前記セキュリティプロセッサは、前記証明書データベースにおける対応する証明書、前記ソフトウェア画像に埋め込まれたデジタル署名、前記チップセットに結合される前記公開鍵を使用する検証に基づいて、前記ホストコンピュータにロードされるそれぞれのソフトウェア画像を検証する、
請求項３記載のシステム。
【請求項５】
プラットフォームアドミニストレータによりモバイルプラットフォームのオーナシップを取得する手段と、
前記証明書のデータベースにおける証明書を登録する手段とを更に有し、
前記証明書は、プラットフォームの証明書と第三者の証明書の少なくとも１つを含む、
請求項４記載のシステム。
【請求項６】
前記ソフトウェア画像は、ＵＥＦＩ（Unified Extensible Firmware Interface）アーキテクチャと互換性がある、
請求項４記載のシステム。
【請求項７】
前記ファームウェアは、前記ソフトウェア画像の関連する署名が検証に失敗した場合、前記ソフトウェア画像をロード又は起動しない、
請求項１記載のシステム。
【請求項８】
検証の失敗は、期限切れの証明書、紛失した証明書、又は取り消された証明書の少なくとも１つの結果である、
請求項７記載のシステム。
【請求項９】
署名鍵は、プラットフォーム鍵、プロテクトされた可変鍵又は公開鍵の少なくとも１つを含む、
請求項１記載のシステム。
【請求項１０】
前記１以上の署名鍵は、上位の鍵が下位の鍵をプロテクトする署名鍵の階層を含む、
請求項９記載のシステム。
【請求項１１】
前記プラットフォーム鍵は、公開鍵よりも上位であるプロテクトされた可変鍵よりも上位にあり、
公開鍵は、ブートの間にロードされるそれぞれのソフトウェア画像に関連される、
請求項１０記載のシステム。
【請求項１２】
当該システムは、遠隔のプラットフォームのアドミニストレータが前記セキュリティプロセッサに結合される証明書のデータベースを更新するのを可能にする無線通信機能を有する、
請求項１記載のシステム。
【請求項１３】
モバイルプラットフォームでのセキュアなブート方法であって、
前記プラットフォームでホストプロセッサのセキュアなブートを始動するステップと、
ブートモジュールがデジタル署名され、前記ホストプロセッサにロードされることが許可されるかを前記プラットフォームのセキュリティプロセッサにより判定するステップと、
前記ブートモジュールがデジタル署名及び許可されたとき、前記ブートモジュールを前記ホストプロセッサにロードして実行し、前記ブートモジュールが前記ホストプロセッサにロードされることが許可された後に複数のソフトウェア画像がロードされるかを前記セキュリティプロセッサにより判定するステップと、前記複数のソフトウェア画像のうちの１つが許可されたとき、実行のために前記ホストプロセッサに前記複数のソフトウェア画像のうちの１つをロードするステップと、
前記デジタル署名されたブートモジュールが許可されない場合、プラットフォームのアドミニストレータにより前記ブート画像を許可するステップと前記プラットフォームをブートするのを失敗するステップの少なくとも１つを実行するステップと、前記複数のソフトウェア画像の１つが許可されないとき、前記複数のソフトウェア画像のうちの１つを前記ホストプロセッサにロードするのを失敗するステップと、
を含むことを特徴とする方法。
【請求項１４】
前記セキュリティプロセッサは、無線通信機能を有し、
当該方法は、前記セキュリティプロセッサにより、前記セキュリティプロセッサにとってアクセス可能な不揮発性メモリに記憶される証明書のデータベースにおける証明書を管理するステップを更に含み、
前記不揮発性メモリは、前記証明書に関する情報を有するリモートアドミニストレータとの無線通信を介して、前記ホストプロセッサにとってアクセス不可能である、
請求項１３記載の方法。
【請求項１５】
ブートモジュールがデジタル署名され、前記ホストプロセッサにロードされることが許可されるかを判定する前記ステップは、
前記ブートモジュールが前記証明書のデータベースにおける画像の証明書を有するかを判定するステップと、
前記ブートモジュールの画像の証明書が前記証明書のデータベースにおける画像の証明書に基づいて検証されたかを判定するステップと、
を更に含む請求項１３記載の方法。
【請求項１６】
前記ブートモジュールが前記ホストプロセッサにロードされることが許可された後に複数のソフトウェア画像がロードされるかを前記セキュリティプロセッサにより判定する前記ステップは、
前記ソフトウェア画像のそれぞれが前記証明書のデータベースにおける対応する画像の証明書を有するかを判定するステップと、
前記ソフトウェア画像の証明書のそれぞれが前記証明書のデータベースにおける画像の証明書に基づいて検証されたかを判定するステップと、
を含む請求項１５記載の方法。
【請求項１７】
前記セキュリティプロセッサと同じチップセットに存在する暗号化コアにより前記ブートモジュール及びソフトウェア画像におけるデジタル署名を検証するステップを更に含む、
請求項１３記載の方法。
【請求項１８】
モバイルプラットフォームでのセキュアなブートを利用するため、コンピュータがアクセス可能な記憶媒体に記憶された命令を含むコンピュータがアクセス可能な記憶媒体であって、
前記命令は、前記プラットフォームで実行されたとき、前記プラットフォームに、
前記プラットフォームでホストプロセッサのセキュアなブートを始動するステップと、
ブートモジュールがデジタル署名され、前記ホストプロセッサにロードされることが許可されるかを前記プラットフォームのセキュリティプロセッサにより判定するステップと、
前記ブートモジュールがデジタル署名及び許可されたとき、前記ブートモジュールを前記ホストプロセッサにロードして実行し、前記ブートモジュールが前記ホストプロセッサにロードされることが許可された後に複数のソフトウェア画像がロードされるかを前記セキュリティプロセッサにより判定するステップと、前記複数のソフトウェア画像のうちの１つが許可されたとき、実行のために前記ホストプロセッサに前記複数のソフトウェア画像のうちの１つをロードするステップと、
前記デジタル署名されたブートモジュールが許可されない場合、プラットフォームのアドミニストレータにより前記ブート画像を許可するステップと前記プラットフォームをブートするのを失敗するステップの少なくとも１つを実行するステップと、前記複数のソフトウェア画像の１つが許可されないとき、前記複数のソフトウェア画像のうちの１つを前記ホストプロセッサにロードするのを失敗するステップと、
を実行させることを特徴とする記録媒体。
【請求項１９】
前記セキュリティプロセッサは、無線通信機能を有し、
当該記録媒体は、前記プラットフォームに、
前記セキュリティプロセッサにより、前記セキュリティプロセッサにとってアクセス可能な不揮発性メモリに記憶される証明書のデータベースにおける証明書を管理するステップを実行させる命令を更に含み、
前記不揮発性メモリは、前記証明書に関する情報を有するリモートアドミニストレータとの無線通信を介して、前記ホストプロセッサにとってアクセス不可能である、
請求項１８記載の記録媒体。
【請求項２０】
ブートモジュールがデジタル署名され、前記ホストプロセッサにロードされることが許可されるかを判定する前記ステップを実行させる前記命令は、
前記ブートモジュールが前記証明書のデータベースにおける画像の証明書を有するかを判定するステップと、
前記ブートモジュールの画像の証明書が前記証明書のデータベースにおける画像の証明書に基づいて検証されたかを判定するステップと、
を実行させる命令を更に含む請求項１８記載の記録媒体。
【請求項２１】
前記ブートモジュールが前記ホストプロセッサにロードされることが許可された後に複数のソフトウェア画像がロードされるかを前記セキュリティプロセッサにより判定する前記ステップを実行させる前記命令は、
前記ソフトウェア画像のそれぞれが前記証明書のデータベースにおける対応する画像の証明書を有するかを判定するステップと、
前記ソフトウェア画像の証明書のそれぞれが前記証明書のデータベースにおける画像の証明書に基づいて検証されたかを判定するステップと、
を実行させる命令を更に含む請求項２０記載の記録媒体。
【請求項２２】
前記セキュリティプロセッサと同じチップセットに存在する暗号化コアにより前記ブートモジュール及びソフトウェア画像におけるデジタル署名を検証するステップを実行させる命令を更に含む、
請求項１８記載の記録媒体。
【請求項１】
モバイルプラットフォームでのセキュアなブートのシステムであって、
ホストオペレーティングシステム及びホストアプリケーションを実行するホストプロセッサと、
前記ホストプロセッサをブートするファームウェアであって、ブートの間に１以上の署名鍵を利用するファームウェアと、それぞれの署名鍵は、ブートの間に前記プラットフォームにロードされるソフトウェア画像に関連され、
前記ファームウェア及び他のホストプロセッサのアプリケーションにとってアクセス不可能であるセキュアメモリストアに結合される前記プラットフォームのセキュリティプロセッサであって、前記１以上の署名鍵を管理してブートの間の画像のロードを制御するセキュリティプロセッサと、
を有することを特徴とするシステム。
【請求項２】
前記セキュアメモリストアは、前記セキュリティプロセッサに結合される不揮発性メモリストアに存在する、
請求項１記載のシステム。
【請求項３】
前記セキュリティプロセッサは、デジタル署名を検証するのを支援する暗号化コアに結合されるチップセットに存在する、
請求項１記載のシステム。
【請求項４】
前記プラットフォームのチップセットに結合される公開鍵と、
前記セキュアメモリストアに記憶される証明書データベースとを更に有し、
前記証明書データベースは、複数の証明書を記憶し、それぞれの証明書は、前記ホストプロセッサにより実行可能な複数のソフトウェア画像のうちの１つに対応し、
前記セキュリティプロセッサは、前記証明書データベースにおける対応する証明書、前記ソフトウェア画像に埋め込まれたデジタル署名、前記チップセットに結合される前記公開鍵を使用する検証に基づいて、前記ホストコンピュータにロードされるそれぞれのソフトウェア画像を検証する、
請求項３記載のシステム。
【請求項５】
プラットフォームアドミニストレータによりモバイルプラットフォームのオーナシップを取得する手段と、
前記証明書のデータベースにおける証明書を登録する手段とを更に有し、
前記証明書は、プラットフォームの証明書と第三者の証明書の少なくとも１つを含む、
請求項４記載のシステム。
【請求項６】
前記ソフトウェア画像は、ＵＥＦＩ（Unified Extensible Firmware Interface）アーキテクチャと互換性がある、
請求項４記載のシステム。
【請求項７】
前記ファームウェアは、前記ソフトウェア画像の関連する署名が検証に失敗した場合、前記ソフトウェア画像をロード又は起動しない、
請求項１記載のシステム。
【請求項８】
検証の失敗は、期限切れの証明書、紛失した証明書、又は取り消された証明書の少なくとも１つの結果である、
請求項７記載のシステム。
【請求項９】
署名鍵は、プラットフォーム鍵、プロテクトされた可変鍵又は公開鍵の少なくとも１つを含む、
請求項１記載のシステム。
【請求項１０】
前記１以上の署名鍵は、上位の鍵が下位の鍵をプロテクトする署名鍵の階層を含む、
請求項９記載のシステム。
【請求項１１】
前記プラットフォーム鍵は、公開鍵よりも上位であるプロテクトされた可変鍵よりも上位にあり、
公開鍵は、ブートの間にロードされるそれぞれのソフトウェア画像に関連される、
請求項１０記載のシステム。
【請求項１２】
当該システムは、遠隔のプラットフォームのアドミニストレータが前記セキュリティプロセッサに結合される証明書のデータベースを更新するのを可能にする無線通信機能を有する、
請求項１記載のシステム。
【請求項１３】
モバイルプラットフォームでのセキュアなブート方法であって、
前記プラットフォームでホストプロセッサのセキュアなブートを始動するステップと、
ブートモジュールがデジタル署名され、前記ホストプロセッサにロードされることが許可されるかを前記プラットフォームのセキュリティプロセッサにより判定するステップと、
前記ブートモジュールがデジタル署名及び許可されたとき、前記ブートモジュールを前記ホストプロセッサにロードして実行し、前記ブートモジュールが前記ホストプロセッサにロードされることが許可された後に複数のソフトウェア画像がロードされるかを前記セキュリティプロセッサにより判定するステップと、前記複数のソフトウェア画像のうちの１つが許可されたとき、実行のために前記ホストプロセッサに前記複数のソフトウェア画像のうちの１つをロードするステップと、
前記デジタル署名されたブートモジュールが許可されない場合、プラットフォームのアドミニストレータにより前記ブート画像を許可するステップと前記プラットフォームをブートするのを失敗するステップの少なくとも１つを実行するステップと、前記複数のソフトウェア画像の１つが許可されないとき、前記複数のソフトウェア画像のうちの１つを前記ホストプロセッサにロードするのを失敗するステップと、
を含むことを特徴とする方法。
【請求項１４】
前記セキュリティプロセッサは、無線通信機能を有し、
当該方法は、前記セキュリティプロセッサにより、前記セキュリティプロセッサにとってアクセス可能な不揮発性メモリに記憶される証明書のデータベースにおける証明書を管理するステップを更に含み、
前記不揮発性メモリは、前記証明書に関する情報を有するリモートアドミニストレータとの無線通信を介して、前記ホストプロセッサにとってアクセス不可能である、
請求項１３記載の方法。
【請求項１５】
ブートモジュールがデジタル署名され、前記ホストプロセッサにロードされることが許可されるかを判定する前記ステップは、
前記ブートモジュールが前記証明書のデータベースにおける画像の証明書を有するかを判定するステップと、
前記ブートモジュールの画像の証明書が前記証明書のデータベースにおける画像の証明書に基づいて検証されたかを判定するステップと、
を更に含む請求項１３記載の方法。
【請求項１６】
前記ブートモジュールが前記ホストプロセッサにロードされることが許可された後に複数のソフトウェア画像がロードされるかを前記セキュリティプロセッサにより判定する前記ステップは、
前記ソフトウェア画像のそれぞれが前記証明書のデータベースにおける対応する画像の証明書を有するかを判定するステップと、
前記ソフトウェア画像の証明書のそれぞれが前記証明書のデータベースにおける画像の証明書に基づいて検証されたかを判定するステップと、
を含む請求項１５記載の方法。
【請求項１７】
前記セキュリティプロセッサと同じチップセットに存在する暗号化コアにより前記ブートモジュール及びソフトウェア画像におけるデジタル署名を検証するステップを更に含む、
請求項１３記載の方法。
【請求項１８】
モバイルプラットフォームでのセキュアなブートを利用するため、コンピュータがアクセス可能な記憶媒体に記憶された命令を含むコンピュータがアクセス可能な記憶媒体であって、
前記命令は、前記プラットフォームで実行されたとき、前記プラットフォームに、
前記プラットフォームでホストプロセッサのセキュアなブートを始動するステップと、
ブートモジュールがデジタル署名され、前記ホストプロセッサにロードされることが許可されるかを前記プラットフォームのセキュリティプロセッサにより判定するステップと、
前記ブートモジュールがデジタル署名及び許可されたとき、前記ブートモジュールを前記ホストプロセッサにロードして実行し、前記ブートモジュールが前記ホストプロセッサにロードされることが許可された後に複数のソフトウェア画像がロードされるかを前記セキュリティプロセッサにより判定するステップと、前記複数のソフトウェア画像のうちの１つが許可されたとき、実行のために前記ホストプロセッサに前記複数のソフトウェア画像のうちの１つをロードするステップと、
前記デジタル署名されたブートモジュールが許可されない場合、プラットフォームのアドミニストレータにより前記ブート画像を許可するステップと前記プラットフォームをブートするのを失敗するステップの少なくとも１つを実行するステップと、前記複数のソフトウェア画像の１つが許可されないとき、前記複数のソフトウェア画像のうちの１つを前記ホストプロセッサにロードするのを失敗するステップと、
を実行させることを特徴とする記録媒体。
【請求項１９】
前記セキュリティプロセッサは、無線通信機能を有し、
当該記録媒体は、前記プラットフォームに、
前記セキュリティプロセッサにより、前記セキュリティプロセッサにとってアクセス可能な不揮発性メモリに記憶される証明書のデータベースにおける証明書を管理するステップを実行させる命令を更に含み、
前記不揮発性メモリは、前記証明書に関する情報を有するリモートアドミニストレータとの無線通信を介して、前記ホストプロセッサにとってアクセス不可能である、
請求項１８記載の記録媒体。
【請求項２０】
ブートモジュールがデジタル署名され、前記ホストプロセッサにロードされることが許可されるかを判定する前記ステップを実行させる前記命令は、
前記ブートモジュールが前記証明書のデータベースにおける画像の証明書を有するかを判定するステップと、
前記ブートモジュールの画像の証明書が前記証明書のデータベースにおける画像の証明書に基づいて検証されたかを判定するステップと、
を実行させる命令を更に含む請求項１８記載の記録媒体。
【請求項２１】
前記ブートモジュールが前記ホストプロセッサにロードされることが許可された後に複数のソフトウェア画像がロードされるかを前記セキュリティプロセッサにより判定する前記ステップを実行させる前記命令は、
前記ソフトウェア画像のそれぞれが前記証明書のデータベースにおける対応する画像の証明書を有するかを判定するステップと、
前記ソフトウェア画像の証明書のそれぞれが前記証明書のデータベースにおける画像の証明書に基づいて検証されたかを判定するステップと、
を実行させる命令を更に含む請求項２０記載の記録媒体。
【請求項２２】
前記セキュリティプロセッサと同じチップセットに存在する暗号化コアにより前記ブートモジュール及びソフトウェア画像におけるデジタル署名を検証するステップを実行させる命令を更に含む、
請求項１８記載の記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１０−７３１９３（Ｐ２０１０−７３１９３Ａ）
【公開日】平成２２年４月２日（２０１０．４．２）
【国際特許分類】
【外国語出願】
【出願番号】特願２００９−１５２９８６（Ｐ２００９−１５２９８６）
【出願日】平成２１年６月２６日（２００９．６．２６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（５９３０９６７１２）インテル コーポレイション (931)
【Ｆターム（参考）】
【公開日】平成２２年４月２日（２０１０．４．２）
【国際特許分類】
【出願番号】特願２００９−１５２９８６（Ｐ２００９−１５２９８６）
【出願日】平成２１年６月２６日（２００９．６．２６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（５９３０９６７１２）インテル コーポレイション (931)
【Ｆターム（参考）】
[ Back to top ]