JP2013524385A - ブートプロセスでのリリースの段階化された制御 - Google Patents

Abstract

ネットワークデバイスの完全性妥当性検査を実行することができる。セキュアハードウェアモジュールを含むネットワークデバイスは、ルート鍵を受信することができる。セキュアハードウェアモジュールは、第１のコード測定を受信することもできる。セキュアハードウェアモジュールは、ルート鍵および第１のコード測定に基づいて第１の鍵を提供することができる。セキュアハードウェアモジュールは、第２のコード測定を受信し、第１の鍵および第２のコード測定に基づいて第２の鍵を提供することができる。コード測定に基づく鍵のリリースは、段階的な認証を提供することができる。

Description

本願発明は、ブートプロセスでのリリースの段階化された制御に関する。

関連出願の相互参照
本願は、その内容全体がこれによって参照によって組み込まれている、２０１０年４月１２日に出願した米国特許仮出願第６１／３２３２４８号明細書および２０１０年６月２２日に出願した米国特許仮出願第６１／３５７４７４号明細書に基づき、これらに対する優先権を主張するものである。

伝統的なセキュリティ方法は、リセットからセキュアブートが成功していることに基づいて、認証に使用される単一の鍵などのリソースのリリースに対するバイナリ判断を可能にすることができる。リセットからのブートが成功しないときに問題が生じる可能性がある。

ネットワークデバイスの完全性妥当性検査を実行するシステム、方法、および手段を開示する。ネットワークデバイスは、セキュアメモリを含むことができる。たとえば、セキュアメモリを、セキュアハードウェアモジュール内に含めることができる。セキュアメモリは、ルート鍵を受信することができる。たとえば、ルート鍵を、製造の時またはプロビジョニングの時にセキュアメモリによって受信することができる。ルート鍵を、セキュアメモリに格納することができ、ルート鍵は、セキュアハードウェアモジュールの外部のソフトウェアまたはハードウェアから不可視とすることができる。

セキュアハードウェアモジュールは、第１のコード測定（第１のコードの測定）を受信することができる。たとえば、セキュアハードウェアモジュールを含むネットワークデバイスに関連するプロセッサなどのプロセッサは、測定すべきコードの第１の部分を選択することができる。コードの第１の部分を、ネットワークデバイスに関連するメモリ、たとえばＲＯＭメモリ、ＲＡＭメモリなどに格納することができる。プロセッサは、コードの選択された第１の部分を測定し、第１のコード測定をもたらすことができる。プロセッサは、測定をセキュアハードウェアモジュールに提供することができる。

セキュアハードウェアモジュールは、ルート鍵および第１のコード測定に基づいて第１の鍵を生成することができる。たとえば、セキュアハードウェアモジュールは、第１の鍵を導出するかリリースすることができる。生成された第１の鍵は、第１のコード測定が有効であるときに有効であり、第１のコード測定が無効であるときに無効である。たとえば、セキュアハードウェアモジュールは、部分的に第１のコード測定に基づいて第１の鍵を導出することができる。第１のコード測定が無効である場合には、導出された第１の鍵も無効である。生成された第１の鍵を、リソースへのアクセスを提供するためにセキュアハードウェアモジュールによって生成することができる。コードがセキュアメモリに格納されるときに、リソースへのアクセスを、コード測定なしで提供することができる。

第１の鍵は、第１の機能に関連する信頼の第１のステージに関係することができる（たとえば、１つまたは複数のリソースを、第１の機能に関連付けることができる）。さらに、第１のステークホルダは、第１の機能にアクセスするために有効な第１の鍵を使用することができる。第１の鍵が有効ではない場合には、第１のステークホルダは、第１の機能にアクセスすることができない。すなわち、セキュアハードウェアモジュールは、第１のコード測定が無効であるときに第１の機能へのアクセスを防ぐことができる。

セキュアハードウェアモジュールは、第２のコード測定（第２のコードの測定）を受信することができる。セキュアハードウェアモジュールは、第１の鍵および第２のコード測定に基づいて第２の鍵を生成することができる。第２の鍵は、第２の機能に関連する信頼の第２のステージに関係することができる（たとえば、１つまたは複数のリソースを第２の機能に関連付けることができる）。さらに、第２のステークホルダは、第２の機能にアクセスするために有効な第２の鍵を使用することができる。鍵のリリースを、最後の既知のよいブートステージ（たとえば、それに関して成功の認証があった最後の既知のブートステージ）に制限することができる。

ハードウェア、コード、および／またはデータの完全性測定に基づく鍵および機能性などのリソースの生成および／またはリリースは、段階的な認証を提供することができる。たとえば、デバイスは、複数のレイヤを含むことができ、各レイヤは、それ自体の認証秘密を有する。各認証秘密は、製造業者ファームウェア、信頼された実行コード、オペレーティングシステム、およびサードパーティアプリケーションなどのデバイス能力のレイヤ内の特定のステークホルダに対応することができる。さらなる例として、有効な第１の鍵を、第１のブートステージに対する有効な認証に関連付けることができる。有効な第１の鍵を、ファームウェアに対する修正（remediation）を実行するためにネットワークデバイス上のファームウェアにアクセスするのに、デバイス製造業者（たとえば、第１のステークホルダ）によって使用することができる。有効な第２の鍵を、より後のブートステージ（たとえば、中間ブートステージ）中の１つまたは複数のソフトウェアコンポーネントの有効な認証に関連付けることができる。有効な第２の鍵を、ソフトウェアコンポーネントにアクセスするのに、たとえばソフトウェアに対する修正を実行するのに、デバイスマネージャ（たとえば、第２のステークホルダ）によって使用することができる。成功裏に認証されたステージの有効な鍵を提供することによって、アクセスを、認証に失敗しなかった最後のステージに相応して許可することができる。

開示されるマルチステージ認証のステージ数は、変更することができ、限定されない。さらに、複数の認証経路を提供することができる。すなわち、認証は、完全性検査の所与のステージで異なる形で分岐することができる。たとえば、各ステークホルダは、認証の１つまたは複数のステージに関係する１つまたは複数のポリシを提供することができる。各ステージでは、認証は、ステークホルダポリシに基づいて異なる形で分岐することができる。ステークホルダは、そのポリシを外部から管理できるものとすることができる。

より詳細な理解を、添付図面に関連して例として与えられる次の説明から得ることができる。

例のＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）無線通信システムを示す図である。 ＬＴＥ無線通信システムの例を示すブロック図である。 デバイス妥当性検査とデバイス認証との間のバインディングを有する例のデバイスを示す図である。 共通のＴｒＥ（ｔｒｕｓｔｅｄ ｅｎｖｉｒｏｎｍｅｎｔ）を使用する完全性検査と認証との物理バインディングの例を示す図である。 妥当性検査と事前に共有される秘密ベースのデバイス認証との間のバインディングの例を示す図である。 妥当性検査および事前に共有される鍵ベースの認証の例を示す図である。 ＴｒＥが条件付きアクセスを許可することに起因するバインディングの例を示す図である。 妥当性検査と証明書ベースのデバイス認証との間のバインディングの例を示す図である。 妥当性検査および証明書ベースの認証のバインディングの例を示す図である。 ＴｒＥが条件付きアクセスを許可することに起因するバインディングの例を示す図である。 ゲーティング機能を使用するバインディングの例を示す図である。 例示的なブートプロセスに関係する複数のステージでの認証の例を示す図である。 開示されるシステムおよび方法の実施形態を実施できる例示的なチップを示す図である。 開示されるシステムおよび方法の実施形態を実施できる例示的なチップを示す図である。 開示されるシステムおよび方法の実施形態を実施できる例示的なチップを示す図である。 例示的な鍵導出機能を示す図である。 署名する機構を含む例示的な鍵導出の詳細を示す図である。 例示的なマルチステージ鍵導出の詳細を示す図である。 例示的なブートするシーケンスを示す図である。 例示的なブートシーケンスフローを示す図である。 マルチステージ認証に関係する例示的なネットワーク通信を示す図である。 例示的なスタートアップおよびポストスタートアップ構成手順を示す図である。 開示されるシステムおよび方法を実施できる例示的なチップを示す図である。 完全性検査プロセスをＵＥ通信に拡張する例を示す図である。

図面は、開示されるシステム、方法、および手段を実施できる例示的実施形態に関係する場合がある。しかし、本発明を、例示的実施形態に関連して説明する場合があるが、本発明は、これに限定されず、他の実施形態を使用することができることまたは本発明から逸脱せずに本発明の同一の機能を実行するために説明される実施形態に対して変更および追加を行えることを理解されたい。開示されるシステムおよび方法の一部は、セキュア複数ステージ認証を提供することができる。無線デバイスおよびネットワークを参照して全体的に説明されるが、開示されるシステム、方法、および手段は、そのような応用例に限定されず、開示される認証を実施できるものとすることができる任意の適当なデバイス、ネットワーク、および／またはシステムに適用可能である可能性がある。さらに、次の開示は、ブートステージアクティビティに関連する複数ステージ認証を説明する場合がある。しかし、その説明は、例示のためであり、開示されるシステム、方法、および手段は、ブートステージ実施態様に限定されない。複数ステージ認証を、任意の適当なマルチステージプロセスでの実施態様に幅広く適用可能とすることができる。

以降、本明細書で言及するとき、用語「ＷＴＲＵ（無線送受信ユニット）」は、ＵＥ（ユーザ機器）、移動局（ＭＳ）、ＡＭＳ（ａｄｖａｎｃｅｄ ｍｏｂｉｌｅ ｓｔａｔｉｏｎ）、局（ＳＴＡ）、固定のまたはモバイルの加入者ユニット、ページャ、セルラ電話機、ＰＤＡ（携帯情報端末）、コンピュータ、または無線環境内で動作できる任意の他のタイプのデバイスを含むが、これらに限定されない。用語ＷＴＲＵおよびＵＥを、交換可能に使用することができる。以降、本明細書で言及するときに、用語「基地局」は、Ｎｏｄｅ−Ｂ、ＡＢＳ（ａｄｖａｎｃｅｄ ｂａｓｅ ｓｔａｔｉｏｎ）、サイトコントローラ、アクセスポイント（ＡＰ）、ＨｎＢ（ｈｏｍｅ Ｎｏｄｅ−Ｂ）、または無線環境内で動作できる任意の他のタイプのインターフェースするデバイスを含むが、これらに限定されない。用語「ＷＴＲＵ」および「基地局は」、相互に排他的ではない。

図１は、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ−Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）１０５を含む例のＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）無線通信システム／アクセスネットワーク１００の図である。Ｅ−ＵＴＲＡＮ １０５は、複数のＥ−ＵＴＲＡＮ Ｎｏｄｅ−Ｂ（ｅＮＢ）１２０、Ｈｏｍｅ ｅＮＢ（ＨｅＮＢ）１２２、およびＨｅＮＢゲートウェイ（ＨｅＮＢ ＧＷ）１３２を含むことができる。ＷＴＲＵ １１０は、ｅＮＢ １２０、ＨｅＮＢ １２２、またはこの両方と通信しているものとすることができる。ｅＮＢ １２０は、Ｘ２インターフェースを使用してお互いとインターフェースすることができる。ｅＮＢ １２０およびＨｅＮＢ ＧＷ １３２のそれぞれは、Ｓ１インターフェースを介してＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）／サービングゲートウェイ（Ｓ−ＧＷ）１３０とインターフェースすることができる。ＨｅＮＢ １２２は、Ｓ１インターフェースを介してＨｅＮＢ ＧＷ １３２と、Ｓ１インターフェースを介してＭＭＥ／Ｓ−ＧＷ １３０と、またはこの両方とインターフェースすることができる。単一のＷＴＲＵ １１０、単一のＨｅＮＢ、および３つのｅＮＢ １２０が図１に示されているが、無線デバイスおよび有線デバイスの任意の組合せを、無線通信システム／アクセスネットワーク１００に含めることができることを了解されたい。

図２は、ＷＴＲＵ １１０、ｅＮＢ １２０、およびＭＭＥ／Ｓ−ＧＷ １３０を含むＬＴＥ無線通信システム２００の例のブロック図である。ｅＮＢ １２０およびＭＭＥ／Ｓ−ＧＷ １３０が、単純さのために図示されているが、ＨｅＮＢ １２２およびＨｅＮＢ ＧＷ １３２の例が、実質的に類似する特徴を含むことができることは明白である。図２に示されているように、ＷＴＲＵ １１０、ｅＮＢ １２０、およびＭＭＥ／Ｓ−ＧＷ １３０を、モバイルから発する省エネルギモードをサポートするように構成することができる。

通常のＷＴＲＵに見られる可能性があるコンポーネントに加えて、ＷＴＲＵ １１０は、オプションのリンクされたメモリ２２２を有するプロセッサ２１６、少なくとも１つのトランシーバ２１４、オプションのバッテリ２２０、およびアンテナ２１８を含むことができる。プロセッサ２１６を、帯域幅管理を実行するように構成することができる。トランシーバ２１４は、無線通信の送信および受信を容易にするために、プロセッサ２１６およびアンテナ２１８と通信しているものとすることができる。オプションのバッテリ２２０を、ＷＴＲＵ １１０内で使用して、トランシーバ２１４およびプロセッサ２１６に電力を与えることができる。

通常のｅＮＢに見られる可能性があるコンポーネントに加えて、ｅＮＢ １２０は、オプションのリンクされたメモリ２１５を有するプロセッサ２１７、トランシーバ２１９、およびアンテナ２２１を含むことができる。プロセッサ２１７を、帯域幅管理を実行するように構成することができる。トランシーバ２１９は、無線通信の送信および受信を容易にするために、プロセッサ２１７およびアンテナ２２１と通信しているものとすることができる。ｅＮＢ １２０を、オプションのリンクされたメモリ２３４を有するプロセッサ２３３を含むことができるＭＭＥ／サービングゲートウェイ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ／Ｓ−ＧＷ）１３０に接続することができる。

図１および２に示されたＬＴＥネットワークは、特定の通信ネットワークの一例にすぎず、他のタイプの通信ネットワークを使用することができる。さまざまな実施形態を、任意の無線通信技術で実施することができる。無線通信技術のいくつかの例のタイプは、ＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ）、８０２．ｘｘ、ＧＳＭ（登録商標）（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、符号分割多元接続（ＣＤＭＡ２０００）、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）、または任意の将来の技術を含むが、これに限定されない。

以降、本明細書で言及するとき、用語「マクロセル」は、基地局、ｅＮＢ（Ｅ−ＵＴＲＡＮ Ｎｏｄｅ−Ｂ）、または無線環境内で動作できる任意の他のタイプのインターフェースするデバイスを含むが、これに限定されない。以降、本明細書で言及するとき、用語法「ＨＮＢ（Ｈｏｍｅ Ｎｏｄｅ−Ｂ）」は、基地局、ＨｅＮＢ（Ｈｏｍｅ ｅｖｏｌｖｅｄ Ｎｏｄｅ−Ｂ）、フェムトセル、またはＣｌｏｓｅｄ Ｓｕｂｓｃｒｉｂｅｒ Ｇｒｏｕｐ無線環境内で動作できる任意の他のタイプのインターフェースするデバイスを含むが、これに限定されない。

説明のために、さまざまな実施形態を、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）の文脈で説明するが、さまざまな実施形態を、任意の無線通信技術で実施することができる。無線通信技術のいくつかの例のタイプは、ＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ）、８０２．ｘｘ、ＧＳＭ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、符号分割多元接続（ＣＤＭＡ２０００）、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）、または任意の将来の技術を含むが、これに限定されない。

用語クライアントおよびデバイスが、同義に使用される場合がある。さらに、用語「データ完全性妥当性検査」、「デバイス妥当性検査」、および「妥当性検査」も、同義に使用される場合がある。妥当性検査を、集合的に通信デバイスまたはコンピューティングデバイスを構成する部分またはコンポーネント全体の完全性を検証するプロセスとすることができる。部分またはコンポーネントを、たとえば、ハードウェア（ＨＷ）、ソフトウェア（ＳＷ）、ファームウェア（ＦＷ）、および／または構成データとすることができる。デバイス認証は、通信デバイスまたはコンピューティングデバイスのアイデンティティがその真正性についてベリファイヤに検証されるプロセスを指すことができる。

Ｈ（ｅ）ＮＢの文脈では、デバイス認証の手順または結果へのＨ（ｅ）ＮＢのデバイス完全性妥当性検査の結果のバインディングなど、手順のバインディングを実行することができる。さまざまな方法を使用して、デバイス妥当性検査およびデバイス認証のバインディングを実行することができる。

デバイス完全性妥当性検査およびデバイス認証に適用されるバインディング方法の例は、３ＧＰＰ Ｈ（ｅ）ＮＢに関するものであるが、これらの方法を、デバイス完全性妥当性検査ならびにデバイス認証に関する要件を有する任意の他の通信デバイスまたはアプリケーションデバイスに適用することができることを理解されたい。

Ｈ（ｅ）ＮＢでの通常のデバイス認証手順を、ＴｒＥ（Ｔｒｕｓｔｅｄ Ｅｎｖｉｒｏｎｍｅｎｔ）に含まれるＡＫＡ証明書の検証に限定することができる。これらの手順は、デバイス認証もしくはデバイス妥当性検査および／またはデバイス認証へのホスティングする当事者認証のバインディングの可能性に対処しない場合がある。

妥当性検査されたデバイスとデバイス認証のプロセスおよび／または結果との間のバインディングを実行することができる。２つのタイプのバインディングを実行することができる。論理的な対応を、デバイス妥当性検査のプロセスで使用されまたはこれによって使用される論理エンティティ（または複数のエンティティまたはプロセスまたはデータ）とデバイス認証のプロセスによって使用される論理エンティティ（または複数のエンティティまたはプロセスまたはデータ）との間で主張でき、検証できる論理バインディング。デバイス妥当性検査プロセスで使用されまたはこれによって使用される特定の物理エンティティ（物理ＴｒＥおよび／またはそれが有する特定の秘密もしくは鍵など）が、デバイス認証プロセスで使用されるかこれによって使用されるかのいずれかである物理エンティティ（アプリケーションソフトウェアファイルまたはデータまたは鍵など）に対する直接の対応する関係を有することができる物理バインディング。

図３に、デバイスの機能性として表された２つの異なるタイプのバインディングを示す。両方のケースで、実際のデバイス完全性妥当性検査手順を、信頼されるエンティティ、たとえばデバイスにセキュアに組み込まれるハードウェアベースのセキュア環境によって実行することができる。Ｈ（ｅ）ＮＢの文脈では、そのような信頼されるエンティティを、Ｈ（ｅ）ＮＢのＴｒＥと称する場合がある。図４は、１）デバイスの完全性検査ならびに２）デバイス認証のクリティカルなまたは機密の機能を実行する共通のＴｒＥを使用するバインディング機構の図である。

図４では、セキュアで信頼されるＴｒＥが、通信デバイスまたはコンピューティングデバイスの内部に常駐することができる。ＴｒＥは、次の機能のうちの１つまたは複数を実行することができる。妥当性検査をデバイス上でローカルに実行できる場合のデバイス完全性妥当性検査などのデバイス完全性検査。ＴｒＥは、図４のインターフェース（１）と、ＴｒＥ内でまたはＴｒＥによって格納される妥当性検査の証明書にアクセスし、使用する能力とを含むことができる。ＴｒＥは、図４のインターフェース（３）とＴｒＥ内でまたはＴｒＥによって格納されるデバイス認証の秘密証明書にアクセスし、使用する能力とを含むセキュア処理を必要とするデバイス認証プロセスの部分を安全にすることができる。他の能力は、セキュリティに敏感な処理を必要とする可能性がある、ＴｒＥの外部に常駐するアプリケーションをサポートするためのセキュア処理の実行を含むことができる。これらのアプリケーションは、それ自体の秘密の証明書（図４には図示せず）にアクセスしまたは使用することができる。ＴｒＥは、ＴｒＥの外部の、デバイスの機能／アプリケーションへのインターフェースを含むことができる。例は、デバイス上でのデバイス認証処理のための図４のインターフェース（２）、および／またはＴｒＥ内からのセキュア処理を必要とする可能性がある他の非認証アプリケーションのための図４のインターフェース（５）を含むが、これに限定されない。

さらに、デバイスの非ＴｒＥ部分は、次のタイプの機能のうちの１つまたは複数を実行することができる。１つの機能を、デバイス認証機能の非セキュア部分とすることができる。もう１つの機能を、ＴｒＥにセキュア処理を要求しないアプリケーションに関するものとすることができる。もう１つの機能を、ＴｒＥにセキュア処理を要求するアプリケーション（デバイス認証以外）に関するものとすることができる。デバイスの非ＴｒＥ部分は、デバイス認証に関する図４のインターフェース（４）、デバイスの能力の間のメッセージ交換（ｄ）、および／またはネットワークベースのＡＡＡサーバ（ｇ）を含むインターフェースをサポートすることができる。図４のインターフェース（６）を、デバイスの側のＴｒＥ内からのセキュア処理を要求する可能性がある機能に関するメッセージ交換に使用することができる。図４のインターフェース（７）を、デバイスの側のＴｒＥ内からのセキュア処理を要求しない可能性がある機能に関するメッセージ交換に使用することができる。デバイス認証に使用される証明書およびデバイス完全性妥当性検査に使用される証明書を、同一でないものとすることができる。しかし、そのような証明書を、お互いにバインドされるように構成することができる。

図４は、Ｈ（ｅ）ＮＢ内で物理バインディングを使用できるデバイスの例である。たとえば、物理バインディングを、妥当性検査とデバイス認証との両方に関してＴｒＥの使用によって実行することができる。Ｈ（ｅ）ＮＢ内では、たとえば、ＴｒＥを、デバイス妥当性検査に必要なプロセス全体を実行するように設計することができる。これらのプロセスは、少なくとも、プロセスのうちで、デバイス認証に必要なプロセスの最もセキュアなまたは信頼される処理を必要とする可能性がある部分、またはプロセス自体の全体を含むことができる。たとえば、デバイス認証プロトコルが、ＥＡＰ−ＡＫＡなどの事前に共有される鍵ベースの手法を使用するように設計される場合に、ＡＫＡ証明書を保持するＴｒＥおよびＨ（ｅ）ＮＢを、さらに、お互いにバインドすることができる。たとえば、Ｈ（ｅ）ＮＢは、データをＴｒＥに伝える前に暗号化解除をＴｒＥに制限できるように、デバイス認証に使用されるＡＫＡ証明書を計算するのに必要なデータを暗号化することができる。ＴｒＥは、このデータを暗号化解除するのに必要な鍵をセキュアに格納することができる。さらに、デバイス妥当性検査に関する情報とデバイス認証に関する情報とを、ＩＫＥｖ２などの共通のセキュリティプロトコルの同一セッション内で組み合わせることによって、さらなるバインディングを得ることができる。この場合に、そのようなバインディングに適切なデバイス妥当性検査を、Ｈ（ｅ）ＮＢ（およびそのＴｒＥ）とネットワークエンティティとの間のある種の相互作用およびメッセージ交換を必要とするようなものとすることができる。

上述したように、論理バインディングは、デバイス妥当性検査および認証に使用できるもう１つのタイプのバインディングである。論理バインディングの例は、デバイス妥当性検査およびデバイス認証のためにデバイスから転送される必要があるメッセージを実行するための、同一のまたは共通の通信プロトコルメッセージの同一のパケット、メッセージ、セッション、または連続するセッションの使用とすることができる。物理バインディング法および論理バインディング法を、お互いと組み合わせて使用することができることに留意されたい。

デバイス妥当性検査を、事前に共有される秘密ベースのクライアント認証にバインドすることができる。

Ｈ（ｅ）ＮＢのデバイス妥当性検査を、バインディングの次の物理的機構および／または論理的機構のうちの１つまたは任意の組合せで事前に共有される鍵ベースの認証にバインドするために実行することができる。ＴｒＥとＨ（ｅ）ＮＢの残りとの間のメッセージ交換に暗号鍵および証明書を使用することによってＴｒＥ（ｔｒｕｓｔｅｄ ｅｎｖｉｒｏｎｍｅｎｔ）をＨ（ｅ）ＮＢに物理的にバインドすることによって、鍵および証明書を、少なくともＴｒＥおよびＨ（ｅ）ＮＢの内部で保護することができる。これを、デバイス認証に関するＴｒＥとＨ（ｅ）ＮＢとの間のメッセージ交換に適用することができる。

図５を参照すると、ＴｒＥは、最初に、Ｈ（ｅ）ＮＢの完全性を検査することができる。成功の場合に、ＴｒＥは、図５のリンク（２）に進むことができ、成功ではない場合には、ＴｒＥは、リンク（２）に進むことができるのではなく、その代わりに、おそらくはＨ（ｅ）ＮＢのデバイス認証機能を含む機能性をロックすることができる。Ｈ（ｅ）ＮＢの完全性を検査するために、ＴｒＥは、ＴｒＥ内に格納されたデバイス妥当性検査証明書を使用することができる（図５のリンク（１）を参照されたい）。

リンク（２）では、ＴｒＥは、鍵対を備えることができ、この鍵対のプライベート部分は、ＴｒＥの内部でセキュアに格納され、パブリック部分は、Ｈ（ｅ）ＮＢから使用可能にされる。Ｈ（ｅ）ＮＢの製造業者は、この鍵対を生成し、パブリックキーをＨ（ｅ）ＮＢから使用可能にするために必要な証明書を提供することができる。ＴｒＥのデバイス妥当性検査機能性は、たとえば、ＴｒＥのＩＤ、ＴｒＥがＨ（ｅ）ＮＢの残りの完全性を成功して検証したことを示すメッセージ、および／またはＴｒＥがデバイス認証機能を認可し、デバイス認証の手順に進むことを認可され得ることを示す認可データのうちの１つまたは複数をＴｒＥの外部のデバイス認証機能に示すためのメッセージに署名するのにＴｒＥプライベートキー（ｐｒｉｖａｔｅ ｋｅｙ）を使用することができる（たとえば、図５に示されたリンク（２）で）。ＴｒＥプライベートキーを、この認可メッセージに署名するのに使用することができる。この認可メッセージは、Ｈ（ｅ）ＮＢデバイス上のデバイス認証機能によるＴｒＥのあるセキュア処理能力の使用を認可することができる。

ＴｒＥからＴｒＥの外部のデバイス認証機能への署名されたメッセージの転送を、図５のリンク（３）によって描くことができる。Ｈ（ｅ）ＮＢは、上のリンク（２）で説明した署名を検証するために必要とする可能性があるＴｒＥパブリックキーを使用することができる。このパブリックキーは、証明書で事前にプロビジョニングされるか、他の形で使用の前にデバイス認証機能から使用可能にされるかのいずれかとすることができる。パブリックキーの使用を、図５の線（４）によって描くことができる。

デバイス認証機能は、ＴｒＥがデバイス認証手順に必要である可能性があるセキュリティに敏感な機能を実行するために、ＴｒＥ内に常駐するデバイス認証のセキュア処理能力を使用することができる。このサービスを要求し、入手するためのこのインターフェースを、図５の線（５）によって描くことができる。デバイス認証のセキュア処理能力は、ＡＡＡサーバがＨ（ｅ）ＮＢデバイスを認証するためにデバイス認証機能がＡＡＡサーバに送信する必要がある可能性があるデータを計算するために、ＴｒＥ内に事前に格納された秘密のデバイス認証証明書を使用することができる。これを、図５の線（６）で描くことができる。

デバイス認証機能は、ＡＡＡサーバがＨ（ｅ）ＮＢデバイスのアイデンティティを認証できるように、ＴｒＥによって提供されるデバイス認証のセキュア処理能力から計算されたデータを含むデータをＡＡＡサーバと交換することに進むことができる。これを、図５の線（７）として描くことができる。この機能を、適切なメッセージ交換プロトコルで実行することができる。たとえば、Ｈ（ｅ）ＮＢの場合には、ＩＫＥｖ２プロトコル、ＴＬＳプロトコル、ＴＲ０６９プロトコル（アプリケーション層プロトコル）、ＯＭＡ−ＤＭプロトコルなどのプロトコル、またはＨＴＴＰＳなどのより上位の層のプロトコルさえ、検討することができる。デバイス認証機能が、それ自体でセキュリティ集中型機能を実行することができることに留意されたい。

妥当性検査およびデバイス認証を、Ｈ（ｅ）ＮＢおよびＴｒＥに集合的に同一パケットまたは同一メッセージを使用してデバイス妥当性検査の手順および認証の手順の指定された部分を実行させることによってバインドすることができる。これを、共通のセキュリティプロトコルの共通の通信セッションまたは連続するセッション（１つまたは複数）で実行することができる。そのようなプロトコルの例は、ＩＫＥｖ２プロトコル、ＴＬＳ、ＴＲ０６９、ＯＭＡ−ＤＭ、およびＨＴＴＰＳを含むことができる。プロトコルは、事前に共有される秘密ベースのプロトコル、非対称鍵ベースのプロトコル、対称鍵ベースのプロトコルなどを使用することができる。

図６は、妥当性検査データと認証データの一部とを同一のプロトコル／セッション／メッセージ内で送信できる、そのようなバインディング機構の例である。図６では、線（１）は、ＴｒＥの内部のデバイス妥当性検査機能（ＤＶＦ）が、デバイス妥当性検査証明書を使用して、Ｈ（ｅ）ＮＢのコンポーネントの完全性が保たれるか否かを検証するために、必要なデバイス完全性検査を実行することができることを示す。ＤＶＦが、デバイス完全性検査および検証に必要ないくつかの機能を実行するために、ＴｒＥの暗号能力（ＴＣＣ）によって提供される機能性を使用することができることに留意されたい。この関係を、図６の破線（Ａ）によって描くことができる。

後のある時に、Ｈ（ｅ）ＮＢの内部のデバイス認証機能（ＤＡＦ）は、それ自体と外部ＡＡＡサーバとの間の暗号化および署名のための認証されない共有される鍵をセットアップするためのＤｉｆｆｉｅ−Ｈｅｌｌｍａｎｎ（Ｄ−Ｈ）手順などの手順を実行することができる。線（７−ａ）によって描かれるこのステップは、デバイス認証の先駆ステップとすることができ、従うべきデバイス認証メッセージプロトコル中に使用される認証されない暗号鍵をセットアップすることができる。ＤＡＦが、Ｄ−Ｈ手順に必要な中間ステップのいくつかを実行するためにＴｒＥの暗号能力（ＴＣＣ）に頼ることができることに留意されたい。点線（Ｃ）は、ＴＣＣに暗号サービスを要求し、入手するためにＤＡＦが使用する、ＤＡＦとＴＣＣとの間のインターフェースとすることができる。

ＤＡＦは、ＡＡＡサーバにＤｅｖ＿Ａｕｔｈ＿Ｉｎｉｔ＿Ｒｅｑｕｅｓｔメッセージを送信することによってデバイス認証手順を開始することができる。たとえば、ＩＫＥｖ２プロトコルが使用される場合に、このメッセージを、ＩＫＥ＿ＳＡ＿ＩＮＩＴ要求メッセージ上で運ぶことができる。このＤｅｖ＿Ａｕｔｈ＿Ｉｎｉｔ＿Ｒｅｑｕｅｓｔメッセージ内に、ＤＡＦは、ヘッダ（ＨＤＲ）、たとえばとりわけセキュリティパラメータインデックス（ＳＰＩ）をＡＡＡサーバに提案するセキュリティ関連付け（ＳＡ）、Ｄ−Ｈプロセスから生成されたサーバのパブリックキーＫＥ＿ＤＨ、および／またはデバイス自体のＩＤ Ｄｅｖ＿ＩＤを含めることができる。このステップを、図６の線（７−ｂ）によって描くことができる。

ＡＡＡサーバは、デバイスのＤＡＦへのＤｅｖ＿Ａｕｔｈ＿Ｉｎｉｔ＿Ｒｅｓｐｏｎｓｅ（ＩＫＥｖ２がプロトコルとして使用される場合にはＩＫＥ＿ＳＡ＿ＩＮＩＴ応答メッセージ）をＤＡＦに送信することができる。このメッセージは、ヘッダ（ＨＤＲ）、Ｄ−Ｈプロセスから生成されたデバイスのパブリックキーＫＥ＿ＤＨ、およびサーバ自体のＩＤ Ｓｖｒ＿ＩＤなどの情報要素を含むことができる。このステップを、図６の線（７−ｃ）によって描くことができる。

ＤＡＦは、図６の線（７−ｄ）によって描かれるように、Ｄｅｖ＿Ａｕｔｈ＿Ｒｅｑｕｅｓｔメッセージ（ＩＫＥｖ２が選択されたプロトコルである場合にはＩＫＥ＿ＡＵＴＨ要求メッセージとすることができる）内で、ヘッダ、ＳＡ、Ｄｅｖ＿ＩＤ、構成（ＣＯＮＦＩＧ）、および／またはオプションのサーバ証明書要求（Ｓｖｒ＿Ｃｅｒ＿ＲＥＱ）をＡＡＡサーバに送信することができる。ここから、情報要素の一部を、Ｄ−Ｈプロセスから生成された鍵による暗号化および署名によって保護することができることに留意されたい。たとえば、Ｄｅｖ＿ＩＤ、Ｓｅｓｓｉｏｎ＿ＩＤ、ＣＯＮＦＩＧ、およびオプションのサーバ証明書要求のすべてを、Ｄ−Ｈプロセスから生成された鍵の使用によって、機密性および完全性のために保護することができる。ＤＡＦが、Ｄ−Ｈ生成された鍵を使用する暗号化および署名を実行するためにＴｒＥの暗号能力（ＴＣＣ）を使用することができることに留意されたい。この関係を、図６の線（Ｂ）によって描くことができる。

ＡＡＡサーバは、とりわけ、ヘッダ、Ｓｖｒ＿ＩＤ、Ｓｅｓｓｉｏｎ＿ＩＤ、およびオプションでＤＡＦによって要求された場合にサーバ証明書（Ｓｖｒ＿Ｃｒｔ）、Ｈ（ｅ）ＮＢとＡＡＡとの間で共有される認証秘密（図６ではＴｒＥ内に格納されて図示）に基づく認証チャレンジ（Ａｕｔｈ−Ｃｈａｌｌｅｎｇｅ）などを含むＤｅｖ＿Ａｕｔｈ＿Ｒｅｓｐｏｎｓｅメッセージ（ＩＫＥｖ２がプロトコルとして使用される場合にはＩＫＥ＿ＡＵＴＨ応答メッセージになるはずである）をＤＡＦに送信することができる。これを、図６の線（７−ｅ）として描くことができる。

ＤＡＦは、とりわけ、ヘッダ、Ｄｅｖ＿ＩＤ、Ｓｅｓｓｉｏｎ＿ＩＤ、認証チャレンジレスポンス（ＡＵＴＨ）、および／または妥当性検査データ（Ｖａｌｉｄａｔｉｏｎ＿Ｄａｔａ）を含むことができるＤｅｖ＿Ａｕｔｈ＿Ｒｅｑｕｅｓｔメッセージ（ＩＫＥｖ２が使用される場合にはもう１つのＩＫＥ＿ＡＵＴＨ要求メッセージとすることができる）をＡＡＡサーバに送信することができる。これを、図６の線（７−ｆ）によって描くことができる。ＤＡＦが、図６の線（３）によって描かれるように、ＡＵＴＨを計算し、転送するためにＴｒＥ内のデバイス認証のセキュア処理能力（ＳＰＣ＿ＤＡ）に頼ることができることに留意されたい。ＳＰＣ＿ＤＡが、図６の線（４）によって描かれるように、ＡＵＴＨを計算するためにＴｒＥ内に格納された事前に共有される認証秘密証明書を使用することができることに留意されたい。さらに、ＳＰＣ＿ＤＡは、ＴｒＥの暗号能力（ＴＣＣ）に頼ることができる（点線（Ｃ）を参照されたい）。ＳＰＣが、ＡＵＴＨを計算することができることに留意されたい。デバイス妥当性検査機能（ＤＶＦ）は、図６の線（５）によって表されるようにＤＡＦにＶａｌｉｄａｔｉｏｎ＿Ｄａｔａを転送する前に、ＴｒＥプライベートキーを使用してＶａｌｉｄａｔｉｏｎ＿Ｄａｔａおよび任意の追加の関連する補足データに署名することもできる。ＤＶＦとＴｒＥプライベートキーとの間のインターフェースを使用して、妥当性検査データをＤＡＦに転送する前にその妥当性検査データに署名することができ、このインターフェースは、線（２）によって表される。この例では、妥当性検査とデバイス認証（またはデバイス認証のあるセキュリティを必要とする部分）との両方を実行するための共通のＴｒＥおよびそのアセットの使用の物理バインディングに加えて、別の論理バインディング機構を使用することができる。同一のプロトコル、同一のセッション、および同一のメッセージを使用して、デバイス妥当性検査（すなわちＶａｌｉｄａｔｉｏｎ＿Ｄａｔａ）とデバイス認証（すなわち、ＡＵＴＨ）との両方の結果に関する情報要素をデバイスからＡＡＡサーバに送信することができる。

ＡＡＡは、（６を参照されたい）の以前のＤｅｖ＿Ａｕｔｈ＿ＲｅｑｕｅｓｔメッセージからＡＵＴＨパラメータおよびＶａｌｉｄａｔｉｏｎ＿Ｄａｔａを受信し、その後に評価した後に、ＡＡＡサーバが認証を成功として査定するか否かをデバイスのＤＡＦに示すために、Ｄｅｖ＿Ａｕｔｈ＿Ｒｅｓｐｏｎｓｅメッセージを送信することができる。これを、図６の線（７−ｇ）によって描くことができる。

バインディングの機構では、ＴｒＥは、アクセスが許可されるように最初に成功して完了したデバイス妥当性検査手順に対して条件付けることができる認証の成功の完了に関する必要な出力を計算するのに必要である可能性がある機密の機能または機密のデータへのアクセスを制御し、ＤＡＦまたはＳＰＣ＿ＤＡにリリースすることができる。このタイプのバインディング機構を、物理的なバインディング機構と論理的なバインディング機構との両方と考えることができる。図７は、そのようなバインディング機能の例の図である。

図７を参照すると、ＤＶＦは、ＴｒＥ内で保持される機能またはデータのいくつかへのアクセスを可能にすることに関して、２タイプのゲーティング手順を実行することができる。ゲーティング手順を、デバイス完全性妥当性検査結果のステータスに依存するものとすることができる。デバイス完全性妥当性検査結果が成功ではない場合には、ＤＶＦは、図７の線（Ａ：ゲーティング）によって表されるように、ＤＡＦがＴｒＥ内のＳＰＣ＿ＤＡにアクセスするのを防ぐことができる。ＤＶＦは、ＳＰＣ＿ＤＡがＡＡＡサーバに向かう成功の認証を実行するのに必要なデバイス認証証明書にアクセスするのを防ぐことができる。これらのタイプのゲーティング機能性は、デバイス妥当性検査とデバイス認証との間の他のタイプの論理バインディングを提供することができる。

デバイス妥当性検査を、証明書ベースのデバイス認証などの認証にバインドすることができる。

Ｈ（ｅ）ＮＢのデバイス妥当性検査を、証明書ベースのクライアントにバインドすることができ、認証を、上で説明した機構に似た機構を使用して達成することができる。可能な機構の一部を、下で説明する。図８は、物理バインディングを使用する例の図であり、共通のＴｒＥは、デバイス完全性検査と妥当性検査との両方ならびにデバイス認証に必要な機能の一部またはすべてを実行することができる。これらの機能を、たとえばデバイス証明書に基づくものとすることができる。デバイス認証のセキュア処理能力（ＳＰＣ＿ＤＡ）によってデバイス認証に使用される証明書を、デバイス認証のプライベートキー（Ｋｐｒｉｖ＿ＤＡ）とすることができ、デバイス認証機能（ＤＡＦ）が、Ｋｐｒｉｖ＿ＤＡによって計算されるいくつかの他の材料と一緒にデバイス証明書（ＤｅｖＣｅｒｔ）をＡＡＡサーバに送信できることを除いて、手順を、図５について説明したものと同一とすることができる。

図８を参照すると、鍵にアクセスすることおよびＳＰＣ＿ＤＡとＫｐｒｉｖ＿ＤＡとの間の関係を使用することを、線（６）に関して示すことができる。証明書にアクセスすることおよびＤＡＦとＤｅｖＣｅｒｔとの間の関係を使用することを、線（８）に関して示すことができる。

Ｈ（ｅ）ＮＢおよびＴｒＥは、集合的に、ＩＫＥｖ２プロトコルなどの共通のセキュリティプロトコルの同一のパケット、メッセージ、共通の通信セッション、または連続するセッション（１つまたは複数）内で、デバイス妥当性検査の手順および証明書ベースのクライアント認証の手順の指定された部分を実行することができる。効果的に、このバインディング機構のプロセスを、図６について説明した機構に類似するものとすることができる。戻って図６を参照すると、事前に共有される秘密ベースのデバイス認証が使用される場合と比較した差を、次とすることができる。ＡＡＡサーバからのＡＵＴＨチャレンジおよびＴｒＥが保持する事前に共有される秘密（およびＳＰＣ＿ＤＡは、計算し、ＤＡＦに計算結果に転送するのに使用する）に基づいて機密の中間結果を計算するのではなく、ＳＰＣ＿ＤＡは、ＡＡＡサーバからのＡＵＴＨチャレンジおよびＫｐｒｉｖ＿ＤＡに基づいて、ＡＵＴＨチャレンジから機密の中間結果を計算することができる。ＡＡＡサーバは、ＤＡＦにデバイス認証証明書（ＤｅｖＣｅｒｔ）を要求することができる。これに応答して、ＳＰＣ＿ＤＡと共に働くＤＡＦは、１）Ｋｐｒｉｖ＿ＤＡを使用して認証応答（ＡＵＴＨ）を、および／または２）ＤｅｖＣｅｒｔを計算し、ＡＡＡサーバに転送することができる。ＡＵＴＨおよびＤｅｖＣｅｒｔを受信したときに、ＡＡＡサーバは、まず、ＤｅｖＣｅｒｔの妥当性を検証することができ、その後、そのＤｅｖＣｅｒｔを使用して、ＡＵＴＨを検証することができる。検証が検査する場合に、検証は、デバイスを認証し終えていることができる。

この差にもかかわらず、論理バインディングに関する限り、論理バインディングを、事前に共有される秘密ベースの認証の場合に類似して実行することができる。たとえば、ＤＡＦは、ＡＵＴＨおよびＤｅｖＣｅｒｔをＡＡＡサーバに転送することができ、その同一のメッセージにＶａｌｉｄａｔｉｏｎ＿Ｄａｔａを含めることもできる。このＶａｌｉｄａｔｉｏｎ＿Ｍｅｓｓａｇｅを、ＴｒＥの内部のＤＶＦから入手することができ、ＴｒＥプライベートキーを使用してＤＶＦによって署名することができる。

図９は、例のバインディング機構の図である。この例では、ＡＡＡサーバからデバイスへの認証チャレンジ自体はない。そうではなく、サーバが、デバイスに、その証明書ＤｅｖＣｅｒｔを送信するように要求（線（７−ｃ）を参照されたい）した後に、デバイスは、線（７−ｄ）に描かれているように、そのＤｅｖＣｅｒｔおよびＡＵＴＨ（Ｋｐｒｉｖ＿ＤＡから計算された）をＡＡＡサーバに送信することができる。ＡＡＡサーバは、ＤｅｖＣｅｒｔに対してＡＵＴＨを検証し、認証のステータスの確認を送信することができる（７−ｅ）。

ゲーティングタイプのバインディングを、証明書ベースの認証の例で実施することができる。この例は、事前に共有される秘密ベースの認証の例に類似する。図１０は、そのようなバインディング機構の例の図である。図１０を参照すると、ＤＶＦは、デバイス完全性妥当性検査結果のステータスに応じて、ＴｒＥ内で保持される機能またはデータの一部へのアクセスを可能にすることに関して２タイプのゲーティング手順を実行することができる。

デバイス完全性妥当性検査結果が成功ではない場合には、ＤＶＦは、図１０の線（Ａ：ゲーティング）によって表されるように、ＤＡＦがＴｒＥ内のＳＰＣ＿ＤＡにアクセスするのを防ぐことができる。あるいは、ＤＶＦは、ＳＰＣ＿ＤＡがＡＡＡサーバに向かう成功の認証を実行するのに必要なＫｐｒｉｖ＿ＤＡにアクセスするのを防ぐことができる。これらのタイプのゲーティング機能性は、デバイス妥当性検査とデバイス認証との間のもう１つのタイプの論理バインディングを提供することができる。

他の本質的なデバイス機能に対するデバイス完全性妥当性検査の一般化されたバインディングを提供することができる。

デバイス完全性妥当性検査とデバイス認証との間のバインディングという概念は、上で説明したように、一般に、デバイス完全性妥当性検査のプロセス、使用される入力データおよび／もしくは中間データ、ならびに／または結果が、認証の手順またはプロセスを「ゲーティングする」ことができることを意味することができる。

バインディングの概念を、バインディングを実施できるデバイスのタイプと、デバイス完全性妥当性検査のプロセスにバインドできるデバイスの機能との両方に関して一般化することができる。最も一般的な意味で、一般に、それ自体でまたは外部エンティティとの相互作用プロセスを実行することによってそれ自体のデバイス完全性を検査し、報告し、かつ／もしくは検証する能力および／またはデバイスの本質的機能と考えることができる少なくとも１つの機能Ｘを実行する能力を有するデバイスＤが存在する場合に、バインディングが実施されると考えることができる。本質的機能を、意図された通りにそれを実行しなければ、デバイスＸが通常の有用な意味で動作可能であると考えることができない機能とすることができる。携帯電話機などのデバイスの本質的機能の例は、遭難アラーム（ｄｉｓｔｒｅｓｓ ａｌａｒｍ）を送信する能力、加入者認証（ネットワークに対する）、デバイス認証、コアアプリケーション、通信スタック実行、ユーザ認証（デバイスに対する）、デバイス管理機能、無線信号の送信もしくは受信、またはデバイス電源および管理機能のうちの１つまたは複数を含むことができる。

バインディングを、デバイス完全性妥当性検査プロセスのデータＤ＿Ｖ、手順Ｐ＿Ｖ、または結果Ｒ＿Ｖのいずれかが、本質的機能Ｘの成功の機能に向かってそのようなＤ＿Ｖ、Ｐ＿Ｖ、および／またはＲ＿Ｖの間の一意で偽造またはクローン作成が困難または不可能な関係を示すことができる手順として定義し、実施することができる。前の節で説明した３タイプのバインディング機構を、やはり、適用することができる。暗号手段の共有される存在および使用に起因するバインディング、同一のまたは連続する通信プロトコルパケット、メッセージ、セッション、もしくは複数のセッションの使用に起因するバインディング、および／またはデバイスＤの成功の妥当性検査に基づいて条件付けることのできる本質的機能Ｘの成功の機能に必須とすることができるデータＤ＿Ｘもしくは手順Ｐ＿Ｘへのゲーティングもしくは条件付きアクセスに起因するバインディング。

図１１は、第２のタイプのバインディングすなわちゲーティングタイプのバインディングを妥当性検査機能（ＤＶＦ）とデバイス上の機能（Ｘ）との間で使用できる例の図である。ＴｒＥは、その中に、機能Ｘのセキュア手順能力（ＳＰＣ＿Ｘ）および機能Ｘに必要な機密データ（ＳＤ＿Ｘ）を有することができる。ＤＶＦは、デバイス上の機能（Ｘ）自体ならびに、機能によって必要とされるデバイスの非ＴｒＥ部分上の任意のデータ（Ｄ＿Ｘ）と、デバイスＤ内に組み込まれるかデバイスＤに接続されたコンポーネント／モジュール上の機能（Ｘ＿ＥＣ）と、ネットワークベースの機能（Ｘ＿Ｎ）およびそれが使用できるデータ（Ｄ＿Ｘ＿Ｎ）とをゲーティングすることもできる。

図１１は、複数のタイプのゲーティング（ＡからＧ）を示し、ＤＶＦは、デバイス完全性妥当性検査の結果に応じて、Ａ）セキュア処理能力ＳＰＣ＿Ｘ、および／またはＢ）機能ＳＰＣ＿Ｘのために必要である可能性があるＴｒＥの内部の機密データＳＤ＿Ｘ、および／またはＣ）ＴｒＥの内部もしくは外部とすることができるデバイスＸ上の任意の機能、および／またはＤ）ＴｒＥの内部もしくは外部とすることができ、任意の機能Ｘによって必要とされる可能性があるデバイス上の任意のデータ、および／またはＥ）デバイス内の組み込まれたコンポーネント（たとえば、ＳｏＣなど）もしくはデバイスに接続されたディスクリートコンポーネント（たとえば、ＵＩＣＣなど）のいずれかの上の任意の機能Ｘ＿ＥＣ、および／またはＦ）外部エンティティによって実行される（たとえば、ネットワークから）任意の機能Ｘ＿Ｎ、および／またはＧ）任意のそのような外部機能Ｘ＿Ｎによって必要とされる任意のデータＤ＿Ｘ＿Ｎへのアクセスをゲーティングすることができる。

手順Ｘの例が、通信機能、たとえば、ラジオおよびベースバンドの送信および受信、デバイス電力管理（オン／オフを含む）、ユーザインターフェース、メディアプロセッサ機能、ＧＰＳおよび他のロケーション機能、タイマおよびタイミング同期化機能、ＷＬＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、およびセルラ通信などの通信機能、ウェブ機能、シングルサインオン、ならびにアイデンティファイフェデレーション（ｉｄｅｎｔｉｆｙ ｆｅｄｅｒａｔｉｏｎ）および管理機能などの高水準アプリケーション、コーデック機能、ゲーミング機能などの音声および他のメディア機能、加入者認証、デバイス認証、アプリケーションの認可、暗号化／暗号化解除、署名、および署名検証を含む暗号動作、ならびにデバイスの任意の他の機能などの機能を含むことができることに留意されたい。

ＳＰＣ＿Ｘは、暗号暗号化（暗号化解除）（cryptographic en(de)cryption）、署名生成もしくは検証、乱数生成もしくは使用、タイミング同期化およびタイムスタンピング、メッセージ認証コード生成および検証、暗号鍵生成、導出、もしくは管理（デプリケーション（ｄｅｐｒｅｃａｔｉｏｎ）または検疫を含む）、証明書検証、ならびに、ＴｒＥ、デバイスのユーザ、デバイス自体、またはデバイスの加入者および／もしくは所有者の認証または認可に必要な秘密材料の計算を含むことができるが、これに限定されない。

機能Ｘ＿ＥＣの例は、データ格納および処理機能、認証機能、鍵生成および使用、暗号化（暗号化解除）、署名生成および検証、構成管理などを含むことができるが、これに限定されない。

機能Ｘ＿Ｎの例は、データ格納および処理機能、デバイス管理、プロビジョニング、高水準アプリケーション（ウェブアクセスその他など）などのタスクに関するネットワーク提供アプリケーション、ＤＲＭ、音声およびマルチメディアサービスおよびゲーミング機能、デバイス管理サービス、通信サービス、シングルサインオンおよびアイデンティティフェデレーションおよび管理などを含むことができるが、これに限定されない。

ゲーティング手順を、カスケードとして実行することができる。すなわち、ＤＶＦが、あるアプリケーションへのアクセスをゲーティングすることができ、そのアプリケーションが、別のアプリケーションまたはデータへのアクセスをゲーティングすることができるなどである。ＤＶＦは、複数の手順またはデータをゲーティングすることができ、これらの手順またはデータの一部またはすべてが、因果関係または対応関係を有することができる。

特徴および要素を、上で特定の組合せで説明する場合があるが、各特徴または要素を、他の特徴または要素なしで単独で、または他の特徴および要素を伴うもしくは伴わないさまざまな組合せで、使用することができる。本明細書で提供される方法または流れ図を、汎用コンピュータまたはプロセッサによる実行のためにコンピュータ可読記憶媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアで実施することができる。コンピュータ可読記憶媒体の例は、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよびリムーバブルディスクなどの磁気媒体、光磁気媒体、ならびにＣＤ−ＲＯＭディスクおよびディジタル多用途ディスク（ＤＶＤ）などの光学媒体を含む。

適切なプロセッサは、たとえば、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、ＤＳＰ（ディジタル信号プロセッサ）、複数のマイクロプロセッサ、ＤＳＰコアに関連する１つもしくは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、ＡＳＩＣ（特定用途向け集積回路）、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）回路、任意の他のタイプのＩＣ（集積回路）、および／または状態機械を含む。

ソフトウェアに関連するプロセッサを使用して、ＷＴＲＵ（無線送受信ユニット）、ＵＥ（ユーザ機器）、端末、基地局、ＲＮＣ（無線ネットワーク制御装置）、または任意のホストコンピュータ内で使用されるラジオ周波数トランシーバを実施することができる。ＷＴＲＵを、カメラ、ビデオカメラモジュール、ビデオ電話、スピーカホン、振動デバイス、スピーカ、マイクロホン、テレビジョントランシーバ、ハンズフリーヘッドセット、キーボード、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、ＦＭ（周波数変調）ラジオユニット、液晶ディスプレイ（ＬＣＤ）表示ユニット、有機発光ダイオード（ＯＬＥＤ）表示ユニット、ディジタル音楽プレイヤ、メディアプレイヤ、ビデオゲームプレイヤモジュール、インターネットブラウザ、および／または任意の無線ローカルエリアネットワーク（ＷＬＡＮ）モジュールもしくはＵＷＢ（ウルトラワイドバンド）モジュールなど、ハードウェアおよび／またはソフトウェアで実施されるモジュールに関連して使用することができる。

ネットワークデバイスの完全性妥当性検査を実行するシステム、方法、および手段を開示する。ネットワークデバイスは、セキュアメモリを含むことができる。たとえば、セキュアメモリを、セキュアハードウェアモジュール内に含めることができる。セキュアメモリは、ルート鍵を受信することができる。たとえば、ルート鍵を、製造の時またはプロビジョニングの時にセキュアメモリによって受信することができる。ルート鍵を、セキュアメモリに格納することができ、ルート鍵は、セキュアハードウェアモジュールの外部のソフトウェアまたはハードウェアから不可視とすることができる。

セキュアハードウェアモジュールは、第１のコード測定（第１のコードの測定）を受信することができる。たとえば、セキュアハードウェアモジュールを含むネットワークデバイスに関連するプロセッサなどのプロセッサは、測定すべきコードの第１の部分を選択することができる。コードの第１の部分を、ネットワークデバイスに関連するメモリ、たとえばＲＯＭメモリ、ＲＡＭメモリなどに格納することができる。プロセッサは、コードの選択された第１の部分を選択し、第１のコード測定をもたらすことができる。プロセッサは、測定をセキュアハードウェアモジュールに提供することができる。

セキュアハードウェアモジュールは、ルート鍵および第１のコード測定に基づいて第１の鍵を生成することができる。たとえば、セキュアハードウェアモジュールは、第１の鍵を導出するかリリースすることができる。生成された第１の鍵は、第１のコード測定が有効であるときに有効であり、第１のコード測定が無効であるときに無効である。たとえば、セキュアハードウェアモジュールは、部分的に第１のコード測定に基づいて第１の鍵を導出することができる。第１のコード測定が無効である場合には、導出された第１の鍵も無効である。生成された第１の鍵を、リソースへのアクセスを提供するためにセキュアハードウェアモジュールによって生成することができる。コードがセキュアメモリに格納されるときに、リソースへのアクセスを、コード測定なしで提供することができる。

第１の鍵は、第１の機能に関連する信頼の第１のステージに関係することができる（たとえば、１つまたは複数のリソースを、第１の機能に関連付けることができる）。さらに、第１のステークホルダは、第１の機能にアクセスするために有効な第１の鍵を使用することができる。第１の鍵が有効ではない場合には、第１のステークホルダは、第１の機能にアクセスすることができない。すなわち、セキュアハードウェアモジュールは、第１のコード測定が無効であるときに第１の機能へのアクセスを防ぐことができる。

セキュアハードウェアモジュールは、第２のコード測定（第２のコードの測定）を受信することができる。セキュアハードウェアモジュールは、第１の鍵および第２のコード測定に基づいて第２の鍵を生成することができる。第２の鍵は、第２の機能に関連する信頼の第２のステージに関係することができる（たとえば、１つまたは複数のリソースを第２の機能に関連付けることができる）。さらに、第２のステークホルダは、第２の機能にアクセスするために有効な第２の鍵を使用することができる。鍵のリリースを、最後の既知のよいブートステージ（たとえば、それに関して成功の認証があった最後の既知のブートステージ）に制限することができる。

ハードウェア、コード、および／またはデータの完全性測定に基づく鍵および機能性などのリソースの生成および／またはリリースは、段階的な認証を提供することができる。たとえば、デバイスは、複数のレイヤを含むことができ、各レイヤは、それ自体の認証秘密を有する。各認証秘密は、製造業者ファームウェア、信頼される実行コード、オペレーティングシステム、およびサードパーティアプリケーションなどのデバイス能力のレイヤ内の特定のステークホルダに対応することができる。さらなる例として、有効な第１の鍵を、第１のブートステージに対する有効な認証に関連付けることができる。有効な第１の鍵を、ファームウェアに対する矯正を実行するためにネットワークデバイス上のファームウェアにアクセスするのに、デバイス製造業者（たとえば、第１のステークホルダ）によって使用することができる。有効な第２の鍵を、より後のブートステージ（たとえば、中間ブートステージ）中の１つまたは複数のソフトウェアコンポーネントの有効な認証に関連付けることができる。有効な第２の鍵を、ソフトウェアコンポーネントにアクセスするのに、たとえばソフトウェアに対する矯正を実行するのに、デバイスマネージャ（たとえば、第２のステークホルダ）によって使用することができる。成功して認証されたステージの有効な鍵を提供することによって、アクセスを、認証に失敗しなかった最後のステージに釣り合って許可することができる。

開示されるマルチステージ認証のステージ数は、変更することができ、限定されない。さらに、複数の認証経路を提供することができる。すなわち、認証は、完全性検査の所与のステージで異なる形で分岐することができる。たとえば、各ステークホルダは、認証の１つまたは複数のステージに関係する１つまたは複数のポリシを提供することができる。各ステージでは、認証は、ステークホルダポリシに基づいて異なる形で分岐することができる。ステークホルダは、そのポリシを外部から管理できるものとすることができる。

図１２に、デバイス１２００の例示的なブートプロセスに関係する複数のステージでの認証を示す。デバイス１２００を、階層化ブートステージ能力（たとえば、１つまたは複数のステージ認証に関連する１つまたは複数の有効な鍵をリリースするため）を有して構成することができる。デバイス１２００が、第１のブートステージに認証するときに、デバイス１２００は、１２０１で、有効な第１の鍵を製造業者などの第１のステークホルダに提供することができる。第１のブートステージを、低水準認証とすることができ、第１のブートステージに関連する鍵は、製造業者に関連するファームウェアに制限されたアクセスを提供することができる。デバイス１２００が、第２のブートステージに認証するときに、デバイス１２００は、１２０２で、有効な第２の鍵をデバイスマネージャなどの第２のステークホルダに提供することができる。第２のブートステージを、第１のブートステージより後のブートステージとすることができ、第２のブートステージに関連する鍵は、認証されたソフトウェアに制限されたアクセスを提供することができる。デバイス１２００が、最終ブートステージに認証するときに、デバイス１２００は、１２０３で、有効な第３の鍵を、コアネットワーク、セキュリティゲートウェイなどへのアクセスを提供できる第３のステークホルダに提供する。

例としてブートプロセスを使用すると、制限されたオンチップリソースと、ブート実行での最後の既知のよいブートステージに関する認証秘密とへのアクセスを、リリースすることができる。そのような段階的リリースは、デバイスに対する信頼されるリモートデバイス管理更新手順に、より下位のレイヤを使用する、コードのより上位のレイヤに対する信頼されるデバイスソフトウェア／ファームウェア矯正を可能にすることができる。これは、セキュアで不変のオンチップの信頼のルートから発する信頼のチェーンに頼ることができる。一例として、リセット時に、第１の鍵をリリースするために、特定のチップ構成を期待することができる。この構成は、プロセッサが正しい内部実行コードにジャンプし、このコードが、信頼実行のチェーン内の次のステージの前に、測定すべきコードの収集を開始できることを保証することができる。たとえばジャンプベクトルが内部ＲＯＭコードへのものではないなど、初期チップ構成が正しくない場合には、初期のおよび後続の完全性測定が、期待されるものとは異なる可能性があり、デバイスが、次の有効なステージに進むことができない可能性がある。

制御の形は、オンチップリソースのハードウェアアンカリングされたゲーティング、コンポーネント（１つまたは複数）の測定された完全性の比較、および／またはシステムの実際の測定された完全性に基づく鍵の導出を含むことができる。たとえば、後者の場合に、開示されるシステムおよび方法を使用して、他の使用のための複数の信頼される制御実行経路を生成することができる。というのは、結果の鍵を、通常動作に必要なものとは異なるものとすることができるからである。したがって、一例として、外部エンティティは、異なるブートシーケンスを、したがって、信頼のルートにも基づく異なる鍵をもたらすことができるデバイス上のピンに対する直接制御を有することができる。

認証を、たとえば、従来のパラメータに加えて、ブートレベルごとに認証の２つの追加要因を課すことによって提供することができる。外部エンティティに対する認証は、１）ブートステージ固有の暗号化された署名する秘密または暗号化する鍵の知識を要求することができ、この秘密または鍵は、２）ブートステージ固有コードが正しい（完全性検査に合格する）場合に明らかにされるものとすることができる。

結果の応用例は、外部エンティティが、そのエンティティによって要求される機能性に従ってデバイスの完全性をリモートに妥当性検査できることとすることができる。さらに、独立のステークホルダ（たとえば、デバイスまたはデバイス製造業者のハードウェアまたはさまざまなファームウェアおよびソフトウェアレイヤの）に、他のエンティティがデバイス機能をディスエーブルせずに独立のステークホルダの対応するファームウェアまたはソフトウェアを変更できないものとすることができることを保証することができる。

例示的な段階的ブートシーケンスは、オンチップリソースと、ブートプロセスの次のステージに関する暗号化する鍵、署名する鍵、および完全性測定などのプロビジョニングされる秘密とを暗号鍵がアンロックすることを強制するために信頼されるハードウェア機構を検出し、利用することによって始まることができる。各ステージが成功して検査されるときに、オンチップリソース、新しい秘密、および新しい測定が、使用のために使用可能になることができる。

いくつかの場合に、情報が、コアの信頼されるドメイン内にある場合があり、ソフトウェア／ファームウェアによるビューイングまたは所有のためではなくハードウェアによる使用のために使用可能にされる場合があり、コードベースの各ステージが検査され、信頼できると検証される（たとえば、コード検査、データ検査、ハードウェア検査などに基づいて信頼できると検証される）ときに、オンチップリソースおよび他の情報を実行環境にリリースすることができる。

各ブートステージは、セキュアブートプロセス内のそのステージの位置に対応する特権および制御の必要を有する場合がある。排他的にあるステージのために生成された証明書を有することは、たとえば外部エンティティに対する認証のために、プラットフォームの内部を超えて制御を拡張することを可能にすることができる。

一例として、デバイス管理およびデバイス認証の場合に、製造業者は、ファームウェアを更新する特権を有する必要がある場合があり、ネットワークオペレータは、ファームウェアではなくソフトウェアおよび／または構成データを矯正しもしくは更新する必要がある場合がある。デバイスが、ファームウェアの完全性検査に合格するがソフトウェアに関して合格しない場合には、使用可能な鍵を、ソフトウェアを更新するためにネットワークオペレータがデバイスを認証することを可能にする鍵とすることができる。しかし、デバイスがファームウェア検査にも合格しない場合には、ネットワークに対して認証するのに必要な鍵ではなく、管理システムに対してデバイスを認証する鍵をリリースすることができ、これは、デバイスを非セキュアな形すなわち信頼プロセスのルートの外でブートすることができないように、プリミティブプロセスが、ファームウェアをリモートにセキュアに矯正／インストールするために定位置にあるものとすることができることを意味する。ファームウェア障害は、矯正を助けるための代替機能のリリースをトリガすることができる（たとえば、認証が、障害に起因して異なる分岐をたどることができる）。信頼のルート立証（ｒｏｏｔ ｏｆ ｔｒｕｓｔ ａｔｔｅｓｔａｔｉｏｎ）を提供することの利益は、デバイスのファームウェア信頼コードベースのリモート管理を可能にすることができることとすることができる。

オペレータおよびアプリケーションプロバイダなどの異なるステークホルダが、ブートシーケンス中の測定の結果によって特徴を表されるシステムの「信頼性」レベルに基づいて異なる鍵を使用することを許可することができる。これは、いくつかのオペレータまたはデバイスの所有者が、それでも、システムがおそらくは複数のステージで部分的に信頼されるが部分的に信頼されない状態にブートすることを許可することができることを意味する。そのような状態であっても、デバイスに、ある種の暗号鍵を生成し、使用することを要求することができる（たとえば、デバイスの状態に関して外部ユーザに示すため、または、デバイスのそのような部分的に信頼される状態の下であっても許可されることのできるアプリケーションにセキュリティを提供するために）。１つのオプションは、ブートシーケンスでより高いレベルの信頼を確立できる場合により高い強度の鍵を生成し、使用し、ブートシーケンス結果に基づいて比較的低いレベルの信頼が確立される場合に比較的低い強度の鍵の使用に制限することとすることができる。ポリシを、事前にプロビジョニングすることができ、信頼のルートは、確立できる信頼のレベルに対応するものとすることができる適当な鍵強度を強制することができる。信頼性の異なるレベルに固有のそのような複数の鍵の生成および使用は、準最適信頼検証されたシステムが、ブートされるシステムの信頼性レベルに一致しない可能性がある鍵の強度の過度なレベルを要求せずに、外部当事者にある種の情報を送信するために暗号リソースを使用する必要がある可能性があるときに、有用である可能性がある。

異なる鍵の導出を、有効なステージの複数のセットがあるものとすることができるように、異なるブートシーケンスおよび異なるコードに基づいて許可することができる。異なるブートシーケンスから生じる可能なデバイス一意秘密鍵は、信頼の同一のルート（同一のルート鍵を使用することができる）から発することができ、したがって、同様に信頼できるが、明確に異なり、相互に排他的であり、これは、役割の分離（たとえば、信頼されるテストモード対信頼される通常動作）を可能にすることができる。

鍵導出機構および署名する機構のアルゴリズム選択を提供することができる。次のステージの鍵導出および／または現在のステージの署名もしくは認証のための特定のアルゴリズムの実施を、提供することができる。これらの制御は、暗号化解除の際に、フィールド値を、実施制御をセットできるブートステージ認証モジュール内の対応するレジスタに挿入できるように、暗号化された証明書パッケージ内の専用の制御レジスタフィールド内に常駐することができる。ブートステージ認証モジュールを、ＴｒＥとすることができる。

図１３Ａ、１３Ｂ、および１３Ｃに、開示されるシステム、方法、および手段の実施形態をそれを用いて実施できる例示的なチップを示す。

セキュア複数ステージブート認証を、たとえば、ブートステージ認証モジュール１３００などのセキュアハードウェア内で実施することができる。ブートステージ認証モジュール１３００は、４つのコンポーネントすなわち、ルートデバイス一意秘密鍵（ルート鍵）、制御信号およびステージ固有鍵導出機能（ＫＤＦ）、暗号エンジン、ならびに署名する機構を含むことができる。モジュールへのインターフェースは、構成インターフェースおよびデータバスインターフェースを含むことができる。構成レジスタは、ＭＭＵまたはブート実行ベクトル、チップ入出力などの制御などの命令およびデータフローを実施することができる。鍵経路を、ブートステージ認証モジュール１３００の内部であることによって、ソフトウェア／ファームウェアによるビューから保護することができる。ブートステージ構成インターフェースは、チップがセキュアブートプロセスを開始するために正しい構成であることを保証することができる。

セキュアブートプロセスが正しく開始しない場合、たとえば、構成が代替ブートシーケンスに関するものである場合には、オンチップリソースおよびデバイス一意秘密鍵への結果のステージアクセスは、存在しないものとすることができ、これは、次のブートステージおよびその特定のステージの署名する鍵の暗号化解除への進行を防ぐことができ、したがって、外部エンティティは、デバイスの信頼状態を立証することができない。

次のうちの１つまたは複数を組み合わせることができる：有鍵暗号ハッシュ化アルゴリズム、デバイス一意秘密鍵、フィードバック鍵経路、および署名する機構。認証秘密のレイヤを、特定のデバイスならびに実行コードおよびブート構成制御などの測定された情報の完全性に暗号的にバインドすることができる。測定された情報が完全性を欠く場合には、実行の後続の従属レイヤが、認証秘密にアクセスしまたは暗号化解除することができない可能性がある。たとえば、デバイスが、そのプロセッサジャンプベクトルを適当にセットされていないか、内部的にブートしないか、デバッグモードである場合には、ビットパターンの相違を検出することができ、これが、その後に外部の関心を持つ当事者に認証することのできない不正な鍵を生成する可能性がある。

デバイスは、一意秘密鍵を含むことができる。デバイスの一意秘密鍵を、以前のブートステージ鍵および測定されたコードから導出することができる。デバイス一意鍵が、デバイス上に存在しない場合があるが、コード自体から生成できるので、コードが変更された場合には、デバイス一意秘密鍵が不正である可能性がある。ルートデバイス一意秘密鍵（ルート鍵）を、初期プロビジョニングまたは製造時にデバイス内に秘密に埋め込むことができ、デバイスに一意とすることができる。ルートデバイス一意秘密鍵は、特定のデバイスブート構成が利用されない限り、使用可能でないものとすることができる。このルート鍵を、ソフトウェア／ファームウェアから可視でないものとすることができ、このルート鍵は、後続のブートステージデバイス一意鍵のシードを提供することができ、このシードは、やはりソフトウェア／ファームウェアから可視でないものとすることができるが、鍵の存在を、したがってブートシーケンス内のそのステージに対するデバイスの完全性を検証できる認証または署名する機構内で利用することができる。

ルートデバイス一意秘密鍵を、ソフトウェア／ファームウェア、チップ信号に対する盗聴、プロービング、単純な電力分析および差分電力分析などから秘密であり隠されることができるように、たとえば１回プログラム可能ヒューズとしてまたはメモリ内で、製造プロセス中に構成することができる、適当な強度（たとえば、現在は約２５６ビットとすることができる）の鍵とすることができる。ルートデバイス一意秘密鍵は、デバイスに一意であり、誰にも知られないものとすることができ、当初にリセット時に鍵導出機能にシードを与えることができる。

図１４に、例示的な鍵導出機能を示す。

鍵導出機能は、２つの機能のために働くことができる。鍵導出機能は、後続のステージ鍵を生成することができ、後続のブートコードを測定することができる。鍵導出機能は、その一方向特性のゆえに、より後のステージの鍵を入手することが、より以前の鍵に関する情報を全く明らかにせず、測定されたデータのすべてのビットエラーが、正しい鍵への相関を有しない可能性がある非常に異なる鍵をもたらす可能性があることを保証することができる、ＨＭＡＣ−ＳＨＡ−２５６などの有鍵暗号ハッシュ関数とすることができる。暗号化されたステージ固有の署名する秘密を、完全性情報と共に与えることができる。完全性情報は、コンポーネントまたは機能の測定された完全性検査値を妥当性検査し、したがって、機能性の次のステージをリリースするように働くことができる。

図１５に、署名する機構を含む例示的な鍵導出の詳細を示す。

頑健なデバイス認証のために、鍵導出機能は、オンチップソフトウェア／ファームウェアおよび外部エンティティから直接に可読ではないものとすることができるブートステージデバイス一意秘密鍵を生成することができる。したがって、デバイス一意鍵を、直接経路内で認証機構または署名する機構に送信することができる。外部エンティティおよびソフトウェアは、認証機構または署名する機構にチャレンジメッセージを提供して、オフチップインターフェースを介するデバイスのブート状態の新鮮さ（ｆｒｅｓｈｎｅｓｓ）を妥当性検査することができる。

図１６に、例示的なマルチステージ鍵導出の詳細を示す。

ブートフローが、初期ブートおよびプログラムローダシーケンスからオペレーティングシステムおよびアプリケーションのロードに進むときに、コードの各ブートステージの完全性を、そのコードが実行される前に測定することができる。コードを、各ステージで鍵導出機能に供給することができ、デバイス一意秘密鍵を、各ステージで生成することができる。たとえば、当初に、ルートデバイス一意秘密鍵（ルート鍵）および第１のコード測定を、鍵導出機能に供給することができ、第１の鍵（初期ステージ鍵）を生成することができる。これを、最後のよい証明書が判定されるまで、複数のステージについて繰り返すことができる。

図１７に、例示的なブートシーケンスを示す。図１６の例示的な図は、鍵を複数のステージでどのように導出でき、最後のよい証明書をどのように判定できるのかを示す。初期ステージ鍵は、ハードウェアが信頼実行のルートのために構成されたことを、たとえば、内部ＲＯＭへのプロセッサベクトル、ハードウェア完全性テスト結果が正しい可能性があること、およびセキュリティに敏感な入出力ピンが正しくセットされ、たとえばテストモードではないことを検証することができる。

ブートステージが、正しいブート構成（１つまたは複数）およびコードに従って実行される場合に、最終的な結果を、デバイスが信頼できる形でブートしたことを検証するのにネットワークエンティティによって外部で使用できる暗号化する鍵または署名する鍵とすることができる。そうではなく、あるステージブートコードが失敗する場合には、最終的な署名する鍵が不正であり、外部／リモートの認証の失敗につながる可能性がある。

実行のチェーンが、署名する鍵のチェーンを追跡する必要がないものとすることができる。ブートシーケンスは、検査するシーケンス（たとえば、ハードウェアベースの）に実行制御を渡すことができ、この検査するシーケンスは、デバイスの信頼できる動作に必要なコード測定をロードすることができる。測定が正しい場合には、その結果を、デバイスの信頼できる動作を外部から妥当性検査するのに使用できる最後の鍵とすることができる。

有効なブートステージから導出された鍵および制御は、ランタイム動作まで永続する残りの暗号化する鍵または署名する鍵をアンロックすることができる。デバイス管理サーバは、この残りの署名する鍵を使用して、サーバが安全にアプリケーションコードをダウンロードできるかどうかを判定するために、デバイスが信頼できる状態にセキュアにブートしたことを検証することができる。その一方で、各ブートステージで鍵へのアクセスを除去することは、たとえば認可されたデバイスパーソナライゼーション、プロビジョニング、デバッギング、テスティングなどのための、特定のブートステージコードの特定のベンダがアクセス可能でなければならないチップのハードウェア保護されたドメインに対する特権付き制御を維持するのを助けることができる。

実行するブートコードは、完全性障害が次のステージ測定で発生したことを検出する必要がある場合がある。たとえば、次のブートステージの暗号化された秘密パケットに埋め込まれるのは、暗号化された秘密パケットの特定のフィールドに配置された既知の「完全性表示メッセージ」などの完全性障害の表示とすることができる。次のブートステージ測定でのエラーが、完全性障害が発生したことを実行するブートコードに示す、期待される値と一致しない可能性があるパケットのフィールド内の混同された完全性表示メッセージをもたらす場合がある。

ブートステージ認証モジュール（たとえば、図１３Ａ〜Ｃを参照されたい）内のハードウェア比較器は、たとえば完全性依存ハードウェア構成、チップ秘密、ヒューズ、入出力ピンおよびテストピン、ＬＥＤなどへのアクセスを制御するハードウェア制御信号を生成するために、（ＨＷ保護され、ソフトウェアまたはファームウェアに不可視の）期待される完全性値と結果の完全性値との間の一致を検出することができる。

制御するブートシーケンスは、障害が発生したことを外部の世界に示すアラートをチップから発行することを選択することができる。または、制御するブートコードは、外部エンティティに認証することを試みるためにチップインターフェース（ネットワークまたはピン）からの入力を待って、アイドルに留まることができる。

１つの動作で、ブートステージ認証モジュールは、暗号化されたステージの署名する秘密（パケット）を暗号化解除することができる。しかし、ステージの証明する秘密を暗号化し、インストールする形の必要がある場合がある。モジュールは、１）製造するステージのみのプロビジョン方法のための１回プログラム可能ヒューズによってロックされ、かつ／または２）チップ上の認可するハードウェアによってアクセス可能にされることができる、「プロビジョニングモード」入力信号、「認可されたアクセスが許容されない」入力信号、および「認可されたステージ」入力信号を有することができる。

チップは、これらの入力が製造するプロセスでヒューズによってロックされない場合にこれらの入力を保護する別の機構を提供する必要がある場合がある。これらの入力がヒューズによってロックダウンされていない場合には、ブートステージ認証モジュールは、デバイスが本明細書で説明するようにそれ自体の検出機構によってセキュアにブートされた場合に、プロビジョニングモードを許可することができる。これは、非セキュアブートコードがプロビジョニングモードに入るのを防ぐことができる。しかし、プロビジョニングモード入力への認可されないアクセスに対して保護するのは、セキュアブートコード、ハードウェア構成、およびチップ上の他の「認可」ハードウェア次第である可能性がある。言い替えると、ブートステージ認証モジュールは、プロビジョンモードへのアクセスを保護する認可ハードウェアを管理するブートコード認可シーケンスを保護するためにセキュアブートコードが実行されることを保証することができる。一実施形態では、セキュアブートプロセスは、バインドされた鍵（たとえば、パブリック、プライベートなど）およびチャレンジレスポンスプロトコルを利用して、プロビジョニングプロセスおよびプロビジョニングモード入力へのアクセスを有することを主張するものを認証し、認可することができる。

プロビジョニングモード入力は、署名する秘密パケットの後続ステージを暗号化解除し、ブートステージ認証モジュールに内部的に、ソフトウェアから使用不能でありプロビジョナに不可視の保護されたレジスタ内に格納することを可能にすることができる。その後、プロビジョニングモード状態を、暗号化モードに切り替えることができる。新しいブートステージコードを、鍵導出機能にロードすることができる。コードがロードされるときに、新しいデバイス一意秘密鍵を自動的に生成することができる（しかし、ユーザまたはソフトウェアには不可視）。その後、新しいブートコードに対応する新しい署名する秘密を、暗号エンジンに挿入し、新しいデバイス一意秘密鍵を用いて暗号化することができる。その結果を、前の版を置換する位置に格納することができる。

新しい後続のデバイス一意秘密鍵を導出する後続のブートステージコードを、ロードすることができ、この新しい後続のデバイス一意秘密鍵を、内部的に格納された後続のステージの署名する鍵秘密を暗号化するのに使用することができる。このプロセスは、完了まで継続することができる。デバイスは、新しいブートステージコードおよびそれに対応する署名する鍵を用いてリブートすることができる。後続のブートステージコードおよび鍵は、同一で未知でステージデバイス一意秘密鍵の新しいチェーンにバインドされたままになることができる。変更されたステージの前のブートステージは、変更されないままであることができる。

図１８に、その強度（または暗号アルゴリズム自体などの他のセキュリティの強度特性もしくはアルゴリズムのモードなど）がブートシーケンス中に実行される完全性検査手順によって明示されるシステムの信頼性のレベルの結果に依存する可能性がある鍵を生成し、使用するデバイスの例示的なブートシーケンスフローを示す。

開示されるシステムおよび方法を、単一のステークホルダ（たとえば、リモートユーザ）実施形態で使用することができ、この実施形態は、単一のステークホルダに、変化する度合の機能性の下でデバイスをセキュアに管理する柔軟性を与えることができる。たとえば、リモートユーザは、セキュリティにクリティカルな複雑な機能にデバイスを使用する前に、デバイスがフルレベルのデバイス完全性および／または機能性を正しく入手したかどうかを妥当性検査することを望む場合がある。

達成されたデバイス完全性および／または機能性のレベルを判定するために、ユーザは、デバイスにナンス（ｎｏｎｃｅ）をサブミットすることと、その後に署名されたレスポンスを取り出すこととによってデバイスにチャレンジすることができる（たとえば、ナンスは結果の新鮮さを保証することができる）。その後、ユーザは、デバイスが完全性および健全性検査実行のどのステージに合格したのかを判定するために、レスポンスを検査することができる。その結果に基づいて、ユーザは、完全性が検証されている機能（１つまたは複数）についてそのデバイスとセキュアに相互作用できることの保証を有することができる。

一例として、レスポンスが、セキュアブートプロセスが行われなかった（たとえば、完全性検査なし）ことを表す場合に、ユーザは、デバイスが非セキュアな形で構成されており、機密データの処理のためにそのデバイスに頼ることができないことを知ることができる。また、いくつかのデバイス完全性にバインドされた鍵が使用不能である可能性があるので、セキュアブートプロセスにバインドされた暗号化されたデータも、使用不能である可能性がある。

プロセスの第１のステージが達成される場合には、デバイスは、それ自体の障害を発生した機能の一部を立証し、リプレイ保護されたおよび／または署名された遭難信号を送出する能力など、あるセキュリティ能力を有することができる。リモートユーザは、そのような信号から、受信された遭難信号が偽ではなく、かつ／または他のデバイスによって成りすまされていないことを判定でき、デバイスが遭難信号を送信したことを知ってデバイスを矯正するアクションを行うことができる。

この例を続けると、第２のステージが達成される場合に、ユーザがデバイス上の障害を発生しているコードをリモートからセキュアに変更することを可能にすることができる、より高いレベルの能力／デバイス完全性を表す認証鍵の新しいセットを、デバイス上で使用可能にすることができる。これの変形は、そのような完全性の第２のステージを達成するデバイスが、リモートユーザのＯＡＭまたはデバイス管理（ＤＭ）サーバ（またはそのようなサーバアプリケーション）に認証することを可能にすることができる鍵へのローカルアクセスを得ることができる場合とすることができる。この例のこのステージでは、デバイスは、リモートユーザ（または彼のＯＡＭサーバもしくはＤＭサーバまたはそのようなサーバアプリケーション）を認証する能力を有することができ、したがって、デバイス上のいくつかのデータおよびコードを、ロードし、達成された完全性のステージに関連する使用可能な鍵を使用して署名することができる。能力の他のレベルに関連する他のステージを達成することもできる。

最終的な成功のステージは、デバイスが、リモートユーザがセキュアにアクセスし使用することを必要とする可能性がある機能を完全に実行することができることを表すことができる。

本発明は、機能性の複数のステージを含む必要がなく、１つまたは複数のいずれのステークホルダにも限定されない。１つの形態では、デバイスは、リモートユーザの展望から自律的妥当性検査のための単一の認証鍵をもたらす単一の代表的な結果を伴う検査の単一のステージを実行することができる。これを、たとえばネットワークに接続することを試みるデバイスを妥当性検査するのに使用することができる。開示されるシステムおよび方法を、デバイスの信頼状態の表現での柔軟性を可能にし、デバイスレベル、サービスレベル、および／またはアプリケーションレベルでの遭難表示、デバイス監視、デバイス管理機能（診断および矯正）、ならびに認証手順を可能にするために、拡張可能とすることもできる。

好ましいネットワークへのデバイスのアクセスに必要な主鍵とは異なる目的に必要な認証鍵などの他の認証情報を、完全性検査プロセスにバインドすることができる。そのような「他の認証」の例を、ＯＡＭの認証、アプリケーションレベルサービスの認証、またはアクセスレイヤ以外のレイヤでのセキュリティプロトコル（ＩＰｓｅｃまたはＴＬＳなど）の認証とすることができる。他の例は、デバイスおよび／もしくはそのプロファイル（たとえば、グループメンバシップなど）、加入者／ユーザ、サービス（１つまたは複数）、またはアプリケーション（１つまたは複数）の認証を含むことができる。たとえば、図１３Ｃを参照すると、サービスサブスクリプション鍵をＫＤＦに送信することができる。結果の鍵を、サービスプロバイダへの認証に使用できるデバイス一意秘密鍵とすることができる。デバイスへのチャレンジは、加入者とデバイス完全性との両方を認証することができる。その場合に、サービスサブスクリプション鍵を、適当なステージで追加することができる。一実施形態では、完全性バックド（ｉｎｔｅｇｒｉｔｙ−ｂａｃｋｅｄ）サブスクリプション鍵が、早期のステージで提供され、完全性バックドアプリケーション鍵が、より後のステージで提供される。他の情報をＫＤＦ入力で組み合わせて、必要な情報へのバインディングを保証することができる。他の認証情報を完全性検査プロセスにバインドすることによって、認証の複数の独立のソースを提供することができる。

開示されるシステム、方法、および手段は、デバイスのセキュアなリモート構成を可能にするための信頼の動的拡張を可能にすることができる。たとえば、工場から出たデバイスは、既知の未構成状態にセキュアにブートすることができる。そのようなデバイスは、まず、ベンダ証明書に含まれる証明書を使用することができる。このステージで使用可能な認証鍵は、外部管理エンティティ（ＯＡＭまたはＤＭサーバなど）がデバイス上の構成データ構造にリモートにアクセスすることを可能にし、認証された外部管理エンティティが新しい証明書（たとえば、新しい署名する鍵または新しい署名する鍵を含むことができるオペレータの証明書など）を挿入することを可能にすることができる。そのような新しい証明書を、本明細書で説明する方法を使用して保護することができる。新しい構成データに、新しい鍵を用いて署名することができ、新しい実行ステージを、挿入することができ、この新しい実行ステージにも、成功のステージ鍵によって署名することができる。認証鍵を追加することができ、この認証鍵を、この最終的な構成検査の成功の完了によって保護することができる。たとえば、デバイスがリセットされる場合に、デバイスは、新しい構成データを検査できる新しいステージへ自動的に再ブートすることができる。新しい構成データが一致する場合には、結果の認証鍵を使用可能とすることができる。その後、外部エンティティは、デバイスを認証することができる。認証に合格する場合には、外部エンティティに、デバイスが正しく構成されていることを保証することができる。

図１９に、マルチステージ認証に関係する例示的なネットワーク通信を示す。

３ＧＰＰ ＲＮ（中継ノード）は、ＤｅＮＢ（ドナーｅＮＢ）に対するＵＥ（すなわち、中継ＵＥ）ならびにそれに接続するＵＥに対するｅＮＢ（すなわち、中継ｅＮＢ）の両方として働くことができる。中継ノードを、緊急応答または一時的にカバレージギャップを満たす任務などの使用シナリオでオンサイトで展開することができるので、中継ノードは、展開時に完全には構成されない可能性があり、完全に機能するためにすべての機能性を有していない場合がある。しかし、ＲＮはネットワークデバイスなので、デバイスセキュリティ要件を含むセキュリティ要件は、段階的動作ステータスの達成を可能にする完全性検査の必要をもたらす高いものである必要がある場合がある。そのような段階的動作ステータスが、展開後の構成および証明書エンロールメントのために必要である可能性がある。

図２０に、例示的な３ＧＰＰ中継ノードを使用するマルチステージ認証および証明書構成をも含む例示的なスタートアップおよびポストスタートアップ構成手順を示す。

この例では、ＲＮは、完全性のある種のステージ（１つまたは複数）に合格する場合に、既知のオペレータ（ＯＰ）管理ボックス（たとえば、ＯＡＭまたはＤＭサーバボックスなど）ならびにベンダのＯＡＭ／ＤＭサーバにアクセスできるようにされる。しかし、ＲＮが、さらなるステージに合格しない場合には、ＲＮは、ＯＰ ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）へのフルアクセスに必要な証明書（ＲＮ上に既に存在してもしなくてもよい）にアクセスすることを可能にされない可能性がある。したがって、ＲＮは、ＯＰ ＭＭＥに対するフルアクセス認証の試みに失敗する可能性がある。しかし、複数の連続するそのような失敗に伴って、ＲＮを、既知のＯＰ ＯＡＭ／ＤＭへの認証に制限することができ、事前にプロビジョニングされたベンダ証明書を使用してベンダＯＡＭ／ＤＭによって再構成されるように指示することができる。ＲＮが、再構成され、その後に完全性検査のさらなるステージに合格する場合には、ＲＮは、今や、ＯＰ ＭＭＥにアクセスするのに必要な証明書へのアクセスを得ることができる。

開示されるシステムおよび方法を、改竄およびランタイム障害に敏感にすることができる。別々の改竄監視プロセスを、デバイスの完全性が確立される（たとえば、監視プロセスを信頼のルートに連鎖させる）前またはそのときに確立することができる。このモニタは、コード、ポート、または侵入もしくは改竄イベントを示すことができるすべてのものを検査することができる。そのようなイベントの際には、確立されたデバイス一意秘密鍵の値が、自動的に除去され、認証鍵を使用不能にする。開示されるシステムおよび方法をそれを用いて実施できる例示的なチップを示す図２１を参照されたい。完全性ベースの認証鍵を使用してデバイスとのセキュア接続を再確立する試みは、失敗する可能性がある。これは、デバイスのセキュリティに頼る外部エンティティの連続保護を提供することができる。

図２２に、完全性検査プロセスをどのようにしてＵＥ通信に拡張できるのかを示す。ネットワークは、完全性バインドされた認証鍵を使用して中継ノードにＵＥ鍵を渡すことができる。中継ノードが、完全性または改竄イベントに起因してもはや安全にされない場合には、中継ノードは、暗号化された鍵を暗号化解除できない可能性があり、ＵＥからの通信のセキュリティが維持される。

開示されるシステムおよび方法は、デバイスの信頼性の部分的なまたは段階的なリモート判定を可能にすることができるデバイスの署名する鍵のステージングの機構、デバイスの現在のブートステージのコード、構成情報、およびセキュアブートプロセスの状態の成功の測定を使用して制御信号を直接に導出でき、この制御信号がオンチップリソースへのさらなるアクセスを可能にし、認証に関する秘密をリリースできる、オンチップリソースおよび認証秘密の段階的リリースの方法、外部エンティティと部分的に障害を発生している可能性があるデバイスとの間の信頼できる報告、管理、および矯正の使用可能化、ブートプロセス中の明示的な完全性検査手順の必要の除去およびブートコード参照値を格納し保護する必要を除去する、またはチップ境界もしくは公衆インターネットなどの公衆インターフェースにまたがるさまざまなステークホルダへの認証されたアクセスのうちの１つまたは複数を提供することができる。

プラットフォーム完全性ポリシエンジン（ＰＩＰＥ）を、全体的なプラットフォーム信頼システムアーキテクチャの一部とすることができる。ＰＩＰＥは、マルチステージ認証および鍵リリースのプロセスを制御することができる。ＰＩＰＥは、セキュアブートプロセスのフロー、ソフトウェアおよび／もしくはデータコンポーネントに対する完全性検査測定の処理、ポリシに従う後続の実施アクション、ならびに／または後続のソフトウェアロード制御のフローを含むさまざまな機能を制御することができる。ポリシを、製造業者および／またはオペレータなどの１つまたは複数の外部ステークホルダによって定義することができ、デバイス上でプロビジョニングし、リモート更新手順を介して現場で更新することができる。

ＰＩＰＥは、１つまたは複数の機能能力を漸進的にインストールすることと、ランタイム中のコンポーネントの動的ローディングを維持することとによって、制御されたソフトウェアおよびデータの検査動作およびロード動作を介して、危険にさらされたソフトウェア機能性がロードされる危険性を制御することができる。例示的な例として、ロード動作での進行のステージに依存して、ＰＩＰＥは、認証失敗に応答して、プラットフォームをパワーダウンする、危険にさらされたコンポーネント（１つまたは複数）のロードを防ぐかコンポーネント（１つまたは複数）を検疫する、低レベル障害もしくは危険にさらされた機能性を通知するためにネットワーク内のセキュリティゲートウェイもしくは矯正マネージャなどの外部エンティティへのアラームをトリガする、認証鍵その他などのプラットフォーム上の機能またはセキュア情報へのアクセスを防ぐ、または、認証アルゴリズムその他などのプラットフォーム上のセキュア機能へのアクセスを防ぐ、のうちの１つまたは複数を実施することができる。

いくつかの場合に、障害が非常に深刻であり、信頼される環境でさえ、コアＴｒＥ機能性が危険にさらされているのでプラットフォーム内の信頼を保証できない可能性がある場合がある。低レベルでの障害は、完全性およびリプレイ保護と機密性保護とを含むことができるデフォルト信頼のルート署名されたアラームメッセージの生成などの基本的な動作をトリガすることができる。すなわち、低レベルセキュリティ障害の発生時には、遭難メッセージを、使用可能とすることができる１つまたは複数の通信チャネルによってネットワークに公開することができる。

ロードされる機能性が作成され、ますます洗練されるにつれて、デバイスは、ネットワークエンティティの代わりにセキュアで信頼できるプロキシとして働くなど、危険にさらされたソフトウェアおよび／もしく構成データの診断、報告、および／もしくは置換のための疑問手順を容易にする、より洗練されたアクションを実行し、バルクコードまたはデータの再ロード／更新手順を実行し、または、コンポーネントの障害の位置を分離するために、より微細な粒度の詳細での完全性検査を含めて改竄が疑われるコンポーネントをより詳細に調査することができる。

プラットフォーム上のリソースへの変化するアクセスを、成功して検証された機能性のレベルに応じて提供することができる（たとえば、ＰＩＰＥによって）。コンポーネント完全性検査が失敗する場合には、そのコンポーネントを信頼されないものとすることができる。この検出された失敗を、セキュアにマークし、ネットワークに示す（明示的にまたは暗黙のいずれかで）ことができ、その後、ブートフローは、この失敗した条件に起因して分岐することができる。このタイプの完全性検査失敗を、実行フロー障害と称する場合があり、これによって、検査されたコンポーネントを、信頼されないものとすることができ、このコンポーネントの始動は、悪意のある、危険にさらされた、障害のある、または誤って構成されたコードの実行をもたらす可能性があり、デバイスに指定されず期待されない形で機能を実行させる可能性がある。したがって、新しいコンポーネントのロードおよび使用可能な機能性は、以前にロードされたコンポーネントの完全性によって影響を受ける可能性がある。

その結果、実行環境が、各ブートステージでの制御する実行プロセスおよびアクセス特権と各ランタイムプロセスとに依存して変化する可能性がある。たとえば、ブートプロセス内の各ステージでは、その時に行われた完全性測定に基づいて判断を行う必要がある可能性がある。後続のステージおよびポリシは、それ自体の動作を判定するために、実行ステージを超える情報伝達または格納の任意の使用可能な安全にされた手段（状態、変数、パラメータ、レジスタ、ファイルなど）を介して前のステージから渡された情報を使用することができる。たとえば、より上のレイヤのアプリケーション認証機能は、以前にロードされたコンポーネントの完全性に関する情報を使用して、外部エンティティとの成功の認証に必要な鍵のリリースのゲーティングを含むそれ自体の動作を決定することができる。

例示的なＰＩＰＥ機能フローは、次のうちの１つまたは複数を含むことができる。ＲｏＴを検査することができ、その完全性を検証することができる。ベースラインＴｒＥをＲｏＴによって検査することができ、その完全性を検証することができる。ＴｒＥ検査で障害がある場合には、ネットワークへのアタッチメントに必要な鍵のリリースを防ぐ、ネットワークへのアラームをトリガする（アラームをネットワークに送信することを可能にすることができるフォールバックコードをロードすることができ、かつ／またはアラームが、ＴｒＥを置換するためのリモートバルク更新手順をトリガすることができる）、またはデバイスをパワーダウンする、のうちの１つまたは複数を実施することができる。基本的な通信接続性コードをロードすることができ、このコードは、ベースラインオペレーティングシステムモジュールを検査し、ロードする、ベースライン管理クライアントを検査し、ロードする、または通信モジュールを検査し、ロードする、のうちの１つまたは複数を含むことができる。障害が発生する場合には、ネットワークへのアタッチメントに必要な鍵のリリースを防ぐ、アラームを介して、コンポーネントを置換するためのリモートバルク更新手順をトリガする（アラームをネットワークに送信することを可能にすることができるフォールバックコードをロードすることができ、かつ／またはアラームが、基本コードを置換するためのリモートバルク更新手順をトリガすることができる）、アラームおよびリモートコンポーネント更新手順を開始する、またはデバイスをパワーダウンする、のうちの１つまたは複数を実施することができる。残りのオペレーティングシステムおよび管理クライアントコンポーネントを検査し、ロードする。動的、再配置可能、および／もしくは再ロード可能な機能モジュールを検査し、ロードし、障害がある場合には、ネットワークへのアタッチメントに必要な鍵のリリースを防ぐ、傷害レポートをプロトコルでネットワークに送信する（傷害レポートは、ネットワークによってリモートに更新できる障害を発生したコンポーネントを示すことができる）、アラームを送信し、リモートコンポーネント更新手順を要求する、またはデバイスをパワーダウンする、のうちの１つまたは複数を実施することができる。

ＰＩＰＥのアクションは、成功して検証されたブートチェーンに依存して変化することができる。ブートプロセスの各ステージでは、その時に（またはその時までに）完全性検査された基礎になるプラットフォームの部分または全体の査定された完全性および適用されるポリシに基づいて、判断を行うことができる。これらのポリシは、達成された信頼レベルに応じて、適合し、または新しいポリシによって置換されるものとすることができる。実行環境は、各ブートステージで制御するポリシに応じて変化することができる。後続のステージおよびポリシは、実行ステージを超える情報伝達または格納の使用可能な安全にされた手段（状態、変数、パラメータ、レジスタ、ファイルなど）を介して前のステージから渡された情報を使用することができる。ＰＩＰＥポリシを、１つまたは複数のステークホルダによってプロビジョニングすることができる。例として、あるステークホルダが、ポリシのそれぞれへのアクセスを有することができ、各ステークホルダが、ポリシの一部へのアクセスを有することができる（たとえば、優先順位レベルまたは特定の機能との関連付けに応じて）などである。もう１つの例として、製造業者は、低レベルコードポリシを制御することができ、オペレータは、ソフトウェアおよび構成のポリシを制御することができ、アプリケーションサービスプロバイダは、より上のレベルの機能モジュールを制御することができる。

特徴および要素が、上で特定の組合せで説明されるが、当業者は、各特徴または要素を、単独でまたは他の特徴および要素とのさまざまな組合せで使用することができることを了解するであろう。さらに、本明細書で提供される方法を、コンピュータまたはプロセッサによる実行のためにコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアで実施することができる。コンピュータ可読媒体の例は、電気信号（有線接続または無線接続を介して送信される）およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよびリムーバブルディスクなどの磁気媒体、光磁気媒体、ならびにＣＤ−ＲＯＭディスクおよびディジタル多用途ディスク（ＤＶＤ）などの光学媒体を含むが、これに限定されない。ソフトウェアに関連するプロセッサを使用して、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータで使用されるラジオ周波数トランシーバを実施することができる。

Claims (20)

1. ネットワークデバイスの完全性妥当性検査を実行する方法であって、
   前記ネットワークデバイスのメモリに格納された第１のコードの測定を受信するステップと、
   前記ネットワークデバイスのセキュアメモリに格納されたルート鍵および前記第１のコード測定に基づいて第１の鍵を生成するステップであって、前記第１の鍵は、前記第１のコード測定が有効であるときに有効であり、前記第１の鍵は、前記ネットワークデバイスの第１の機能に関連する信頼の第１のステージに関係し、有効な第１の鍵は、前記第１の機能にアクセスするために第１のステークホルダによって使用されることができる、ステップと
   を含むことを特徴とする方法。
2. 前記第１のコード測定が無効であるときに、前記第１の機能へのアクセスを防ぐステップをさらに含むことを特徴とする請求項１に記載の方法。
3. 前記ネットワークデバイスの前記メモリに格納された第２のコードの測定を受信するステップと、
   前記第１の鍵および前記第２のコード測定に基づいて第２の鍵を提供するステップであって、前記第２の鍵は、前記第２のコード測定が有効であるときに有効である、ステップと
   をさらに含むことを特徴とする請求項１に記載の方法。
4. 前記第２のコード測定が無効であるときに第２の機能へのアクセスを防ぐステップをさらに含むことを特徴とする請求項３に記載の方法。
5. 前記第２の鍵は、第２の機能に関連する信頼の第２のステージに関係し、有効な第２の鍵は、前記第２の機能にアクセスするために第２のステークホルダによって使用されることができることを特徴とする請求項３に記載の方法。
6. ナンスを受信するステップと、
   前記ナンスに応答して署名されたメッセージを送信するステップであって、前記署名されたメッセージは、信頼できない状態、部分的に信頼できる状態、または信頼できる状態を示す、ステップと
   をさらに含むことを特徴とする請求項１に記載の方法。
7. 前記部分的に信頼できる状態が示されるときに、最後の有効な証明書を提供するステップをさらに含み、前記最後の有効な証明書は、最後の有効なコード測定に関連する最後の有効な鍵を含むことを特徴とする請求項６に記載の方法。
8. 前記署名されたメッセージは、ブート状態の新鮮さをさらに示し、前記ナンスは、シーケンスカウンタまたは日付およびタイムスタンプ機能のうちの少なくとも１つを介してローカルに導出されることを特徴とする請求項６に記載の方法。
9. 前記ルート鍵は、製造の時またはプロビジョニングの時に前記セキュアメモリに格納されることを特徴とする請求項１に記載の方法。
10. 前記セキュアメモリは、セキュアハードウェアモジュールの一部であり、前記ルート鍵は、前記セキュアハードウェアモジュールの外部のソフトウェアに可視ではないことを特徴とする請求項１に記載の方法。
11. ネットワークデバイスの完全性妥当性検査を実行するセキュアハードウェアモジュールであって、前記セキュアハードウェアモジュールは、少なくとも部分的に、
    前記ネットワークデバイスのメモリに格納された第１のコードの測定を受信し、
    前記ネットワークデバイスのセキュアメモリに格納されたルート鍵および前記第１のコード測定に基づいて第１の鍵を生成するように構成され、前記第１の鍵は、前記第１のコード測定が有効であるときに有効であり、前記第１の鍵は、前記ネットワークデバイスの第１の機能に関連する信頼の第１のステージに関係し、有効な第１の鍵は、前記第１の機能にアクセスするために第１のステークホルダによって使用されることができることを特徴とするセキュアハードウェアモジュール。
12. 前記セキュアハードウェアモジュールは、前記第１のコード測定が無効であるときに、前記第１の機能へのアクセスを防ぐようにさらに構成されることを特徴とする請求項１１に記載のセキュアハードウェアモジュール。
13. 前記セキュアハードウェアモジュールは、
    前記ネットワークデバイスの前記メモリに格納された第２のコードの測定を受信し、
    前記第１の鍵および前記第２のコード測定に基づいて第２の鍵を提供するようにさらに構成され、前記第２の鍵は、前記第２のコード測定が有効であるときに有効であることを特徴とする請求項１１に記載のセキュアハードウェアモジュール。
14. 前記セキュアハードウェアモジュールは、前記第２のコード測定が無効であるときに第２の機能へのアクセスを防ぐようにさらに構成されることを特徴とする請求項１３に記載のセキュアハードウェアモジュール。
15. 前記第２の鍵は、第２の機能に関連する信頼の第２のステージに関係し、有効な第２の鍵は、前記第２の機能にアクセスするために第２のステークホルダによって使用されることができることを特徴とする請求項１３に記載のセキュアハードウェアモジュール。
16. 前記セキュアハードウェアモジュールは、
    ナンスを受信し、
    前記ナンスに応答して署名されたメッセージを送信するようにさらに構成され、前記署名されたメッセージは、信頼できない状態、部分的に信頼できる状態、または信頼できる状態を示すことを特徴とする請求項１１に記載のセキュアハードウェアモジュール。
17. 前記セキュアハードウェアモジュールは、前記部分的に信頼できる状態が示されるときに、最後の有効な証明書を提供するようにさらに構成され、前記最後の有効な証明書は、最後の有効なコード測定に関連する最後の有効な鍵を含むことを特徴とする請求項１６に記載のセキュアハードウェアモジュール。
18. 前記署名されたメッセージは、ブート状態の新鮮さをさらに示し、前記ナンスは、シーケンスカウンタまたは日付およびタイムスタンプ機能のうちの少なくとも１つを介してローカルに導出されることを特徴とする請求項１６に記載のセキュアハードウェアモジュール。
19. 前記ルート鍵は、製造の時またはプロビジョニングの時に前記セキュアメモリに格納されることを特徴とする請求項１１に記載のセキュアハードウェアモジュール。
20. 前記セキュアメモリは、前記セキュアハードウェアモジュールの一部であり、前記ルート鍵は、前記セキュアハードウェアモジュールの外部のソフトウェアに可視ではないことを特徴とする請求項１１に記載のセキュアハードウェアモジュール。

Images