ネットワークデバイスの完全性妥当性検査を実行する方法であって、前記ネットワークデバイスのメモリに格納された第1のコードの測定を受信するステップと、前記ネットワークデバイスのセキュアメモリに格納されたルート鍵および前記第1のコード測定に基づいて第1の鍵を生成するステップであって、前記第1の鍵は、前記第1のコード測定が有効であるときに有効であり、前記第1の鍵は、前記ネットワークデバイスの第1の機能に関連する信頼の第1のステージに関係し、有効な第1の鍵は、前記第1の機能にアクセスするために第1のステークホルダによって使用されることができる、ステップとを含むことを特徴とする方法。前記第1のコード測定が無効であるときに、前記第1の機能へのアクセスを防ぐステップをさらに含むことを特徴とする請求項1に記載の方法。前記ネットワークデバイスの前記メモリに格納された第2のコードの測定を受信するステップと、前記第1の鍵および前記第2のコード測定に基づいて第2の鍵を提供するステップであって、前記第2の鍵は、前記第2のコード測定が有効であるときに有効である、ステップとをさらに含むことを特徴とする請求項1に記載の方法。前記第2のコード測定が無効であるときに第2の機能へのアクセスを防ぐステップをさらに含むことを特徴とする請求項3に記載の方法。前記第2の鍵は、第2の機能に関連する信頼の第2のステージに関係し、有効な第2の鍵は、前記第2の機能にアクセスするために第2のステークホルダによって使用されることができることを特徴とする請求項3に記載の方法。ナンスを受信するステップと、前記ナンスに応答して署名されたメッセージを送信するステップであって、前記署名されたメッセージは、信頼できない状態、部分的に信頼できる状態、または信頼できる状態を示す、ステップとをさらに含むことを特徴とする請求項1に記載の方法。前記部分的に信頼できる状態が示されるときに、最後の有効な証明書を提供するステップをさらに含み、前記最後の有効な証明書は、最後の有効なコード測定に関連する最後の有効な鍵を含むことを特徴とする請求項6に記載の方法。前記署名されたメッセージは、ブート状態の新鮮さをさらに示し、前記ナンスは、シーケンスカウンタまたは日付およびタイムスタンプ機能のうちの少なくとも1つを介してローカルに導出されることを特徴とする請求項6に記載の方法。前記ルート鍵は、製造の時またはプロビジョニングの時に前記セキュアメモリに格納されることを特徴とする請求項1に記載の方法。前記セキュアメモリは、セキュアハードウェアモジュールの一部であり、前記ルート鍵は、前記セキュアハードウェアモジュールの外部のソフトウェアに可視ではないことを特徴とする請求項1に記載の方法。ネットワークデバイスの完全性妥当性検査を実行するセキュアハードウェアモジュールであって、前記セキュアハードウェアモジュールは、少なくとも部分的に、前記ネットワークデバイスのメモリに格納された第1のコードの測定を受信し、前記ネットワークデバイスのセキュアメモリに格納されたルート鍵および前記第1のコード測定に基づいて第1の鍵を生成するように構成され、前記第1の鍵は、前記第1のコード測定が有効であるときに有効であり、前記第1の鍵は、前記ネットワークデバイスの第1の機能に関連する信頼の第1のステージに関係し、有効な第1の鍵は、前記第1の機能にアクセスするために第1のステークホルダによって使用されることができることを特徴とするセキュアハードウェアモジュール。前記セキュアハードウェアモジュールは、前記第1のコード測定が無効であるときに、前記第1の機能へのアクセスを防ぐようにさらに構成されることを特徴とする請求項11に記載のセキュアハードウェアモジュール。前記セキュアハードウェアモジュールは、前記ネットワークデバイスの前記メモリに格納された第2のコードの測定を受信し、前記第1の鍵および前記第2のコード測定に基づいて第2の鍵を提供するようにさらに構成され、前記第2の鍵は、前記第2のコード測定が有効であるときに有効であることを特徴とする請求項11に記載のセキュアハードウェアモジュール。前記セキュアハードウェアモジュールは、前記第2のコード測定が無効であるときに第2の機能へのアクセスを防ぐようにさらに構成されることを特徴とする請求項13に記載のセキュアハードウェアモジュール。前記第2の鍵は、第2の機能に関連する信頼の第2のステージに関係し、有効な第2の鍵は、前記第2の機能にアクセスするために第2のステークホルダによって使用されることができることを特徴とする請求項13に記載のセキュアハードウェアモジュール。前記セキュアハードウェアモジュールは、ナンスを受信し、前記ナンスに応答して署名されたメッセージを送信するようにさらに構成され、前記署名されたメッセージは、信頼できない状態、部分的に信頼できる状態、または信頼できる状態を示すことを特徴とする請求項11に記載のセキュアハードウェアモジュール。前記セキュアハードウェアモジュールは、前記部分的に信頼できる状態が示されるときに、最後の有効な証明書を提供するようにさらに構成され、前記最後の有効な証明書は、最後の有効なコード測定に関連する最後の有効な鍵を含むことを特徴とする請求項16に記載のセキュアハードウェアモジュール。前記署名されたメッセージは、ブート状態の新鮮さをさらに示し、前記ナンスは、シーケンスカウンタまたは日付およびタイムスタンプ機能のうちの少なくとも1つを介してローカルに導出されることを特徴とする請求項16に記載のセキュアハードウェアモジュール。前記ルート鍵は、製造の時またはプロビジョニングの時に前記セキュアメモリに格納されることを特徴とする請求項11に記載のセキュアハードウェアモジュール。前記セキュアメモリは、前記セキュアハードウェアモジュールの一部であり、前記ルート鍵は、前記セキュアハードウェアモジュールの外部のソフトウェアに可視ではないことを特徴とする請求項11に記載のセキュアハードウェアモジュール。図面は、開示されるシステム、方法、および手段を実施できる例示的実施形態に関係する場合がある。しかし、本発明を、例示的実施形態に関連して説明する場合があるが、本発明は、これに限定されず、他の実施形態を使用することができることまたは本発明から逸脱せずに本発明の同一の機能を実行するために説明される実施形態に対して変更および追加を行えることを理解されたい。開示されるシステムおよび方法の一部は、セキュア複数ステージ認証を提供することができる。無線デバイスおよびネットワークを参照して全体的に説明されるが、開示されるシステム、方法、および手段は、そのような応用例に限定されず、開示される認証を実施できるものとすることができる任意の適当なデバイス、ネットワーク、および/またはシステムに適用可能である可能性がある。さらに、次の開示は、ブートステージアクティビティに関連する複数ステージ認証を説明する場合がある。しかし、その説明は、例示のためであり、開示されるシステム、方法、および手段は、ブートステージ実施態様に限定されない。複数ステージ認証を、任意の適当なマルチステージプロセスでの実施態様に幅広く適用可能とすることができる。以降、本明細書で言及するとき、用語WTRU無線送受信ユニットは、UEユーザ機器、移動局MS、AMSadvancedmobilestation、局STA、固定のまたはモバイルの加入者ユニット、ページャ、セルラ電話機、PDA携帯情報端末、コンピュータ、または無線環境内で動作できる任意の他のタイプのデバイスを含むが、これらに限定されない。用語WTRUおよびUEを、交換可能に使用することができる。以降、本明細書で言及するときに、用語基地局は、Node-B、ABSadvancedbasestation、サイトコントローラ、アクセスポイントAP、HnBhomeNode-B、または無線環境内で動作できる任意の他のタイプのインターフェースするデバイスを含むが、これらに限定されない。用語WTRUおよび基地局は、相互に排他的ではない。図1は、E-UTRANEvolved-UniversalTerrestrialRadioAccessNetwork105を含む例のLTELongTermEvolution無線通信システム/アクセスネットワーク100の図である。E-UTRAN105は、複数のE-UTRANNode-BeNB120、HomeeNBHeNB122、およびHeNBゲートウェイHeNBGW132を含むことができる。WTRU110は、eNB120、HeNB122、またはこの両方と通信しているものとすることができる。eNB120は、X2インターフェースを使用してお互いとインターフェースすることができる。eNB120およびHeNBGW132のそれぞれは、S1インターフェースを介してMMEMobilityManagementEntity/サービングゲートウェイS-GW130とインターフェースすることができる。HeNB122は、S1インターフェースを介してHeNBGW132と、S1インターフェースを介してMME/S-GW130と、またはこの両方とインターフェースすることができる。単一のWTRU110、単一のHeNB、および3つのeNB120が図1に示されているが、無線デバイスおよび有線デバイスの任意の組合せを、無線通信システム/アクセスネットワーク100に含めることができることを了解されたい。図2は、WTRU110、eNB120、およびMME/S-GW130を含むLTE無線通信システム200の例のブロック図である。eNB120およびMME/S-GW130が、単純さのために図示されているが、HeNB122およびHeNBGW132の例が、実質的に類似する特徴を含むことができることは明白である。図2に示されているように、WTRU110、eNB120、およびMME/S-GW130を、モバイルから発する省エネルギモードをサポートするように構成することができる。通常のWTRUに見られる可能性があるコンポーネントに加えて、WTRU110は、オプションのリンクされたメモリ222を有するプロセッサ216、少なくとも1つのトランシーバ214、オプションのバッテリ220、およびアンテナ218を含むことができる。プロセッサ216を、帯域幅管理を実行するように構成することができる。トランシーバ214は、無線通信の送信および受信を容易にするために、プロセッサ216およびアンテナ218と通信しているものとすることができる。オプションのバッテリ220を、WTRU110内で使用して、トランシーバ214およびプロセッサ216に電力を与えることができる。通常のeNBに見られる可能性があるコンポーネントに加えて、eNB120は、オプションのリンクされたメモリ215を有するプロセッサ217、トランシーバ219、およびアンテナ221を含むことができる。プロセッサ217を、帯域幅管理を実行するように構成することができる。トランシーバ219は、無線通信の送信および受信を容易にするために、プロセッサ217およびアンテナ221と通信しているものとすることができる。eNB120を、オプションのリンクされたメモリ234を有するプロセッサ233を含むことができるMME/サービングゲートウェイMobilityManagementEntity/S-GW130に接続することができる。図1および2に示されたLTEネットワークは、特定の通信ネットワークの一例にすぎず、他のタイプの通信ネットワークを使用することができる。さまざまな実施形態を、任意の無線通信技術で実施することができる。無線通信技術のいくつかの例のタイプは、WiMAXWorldwideInteroperabilityforMicrowaveAccess、802.xx、GSM登録商標GlobalSystemforMobilecommunications、符号分割多元接続CDMA2000、UMTSUniversalMobileTelecommunicationsSystem、または任意の将来の技術を含むが、これに限定されない。以降、本明細書で言及するとき、用語マクロセルは、基地局、eNBE-UTRANNode-B、または無線環境内で動作できる任意の他のタイプのインターフェースするデバイスを含むが、これに限定されない。以降、本明細書で言及するとき、用語法HNBHomeNode-Bは、基地局、HeNBHomeevolvedNode-B、フェムトセル、またはClosedSubscriberGroup無線環境内で動作できる任意の他のタイプのインターフェースするデバイスを含むが、これに限定されない。説明のために、さまざまな実施形態を、LTELongTermEvolutionの文脈で説明するが、さまざまな実施形態を、任意の無線通信技術で実施することができる。無線通信技術のいくつかの例のタイプは、WiMAXWorldwideInteroperabilityforMicrowaveAccess、802.xx、GSMGlobalSystemforMobilecommunications、符号分割多元接続CDMA2000、UMTSUniversalMobileTelecommunicationsSystem、または任意の将来の技術を含むが、これに限定されない。用語クライアントおよびデバイスが、同義に使用される場合がある。さらに、用語データ完全性妥当性検査、デバイス妥当性検査、および妥当性検査も、同義に使用される場合がある。妥当性検査を、集合的に通信デバイスまたはコンピューティングデバイスを構成する部分またはコンポーネント全体の完全性を検証するプロセスとすることができる。部分またはコンポーネントを、たとえば、ハードウェアHW、ソフトウェアSW、ファームウェアFW、および/または構成データとすることができる。デバイス認証は、通信デバイスまたはコンピューティングデバイスのアイデンティティがその真正性についてベリファイヤに検証されるプロセスを指すことができる。HeNBの文脈では、デバイス認証の手順または結果へのHeNBのデバイス完全性妥当性検査の結果のバインディングなど、手順のバインディングを実行することができる。さまざまな方法を使用して、デバイス妥当性検査およびデバイス認証のバインディングを実行することができる。デバイス完全性妥当性検査およびデバイス認証に適用されるバインディング方法の例は、3GPPHeNBに関するものであるが、これらの方法を、デバイス完全性妥当性検査ならびにデバイス認証に関する要件を有する任意の他の通信デバイスまたはアプリケーションデバイスに適用することができることを理解されたい。HeNBでの通常のデバイス認証手順を、TrETrustedEnvironmentに含まれるAKA証明書の検証に限定することができる。これらの手順は、デバイス認証もしくはデバイス妥当性検査および/またはデバイス認証へのホスティングする当事者認証のバインディングの可能性に対処しない場合がある。妥当性検査されたデバイスとデバイス認証のプロセスおよび/または結果との間のバインディングを実行することができる。2つのタイプのバインディングを実行することができる。論理的な対応を、デバイス妥当性検査のプロセスで使用されまたはこれによって使用される論理エンティティまたは複数のエンティティまたはプロセスまたはデータとデバイス認証のプロセスによって使用される論理エンティティまたは複数のエンティティまたはプロセスまたはデータとの間で主張でき、検証できる論理バインディング。デバイス妥当性検査プロセスで使用されまたはこれによって使用される特定の物理エンティティ物理TrEおよび/またはそれが有する特定の秘密もしくは鍵などが、デバイス認証プロセスで使用されるかこれによって使用されるかのいずれかである物理エンティティアプリケーションソフトウェアファイルまたはデータまたは鍵などに対する直接の対応する関係を有することができる物理バインディング。図3に、デバイスの機能性として表された2つの異なるタイプのバインディングを示す。両方のケースで、実際のデバイス完全性妥当性検査手順を、信頼されるエンティティ、たとえばデバイスにセキュアに組み込まれるハードウェアベースのセキュア環境によって実行することができる。HeNBの文脈では、そのような信頼されるエンティティを、HeNBのTrEと称する場合がある。図4は、1デバイスの完全性検査ならびに2デバイス認証のクリティカルなまたは機密の機能を実行する共通のTrEを使用するバインディング機構の図である。図4では、セキュアで信頼されるTrEが、通信デバイスまたはコンピューティングデバイスの内部に常駐することができる。TrEは、次の機能のうちの1つまたは複数を実行することができる。妥当性検査をデバイス上でローカルに実行できる場合のデバイス完全性妥当性検査などのデバイス完全性検査。TrEは、図4のインターフェース1と、TrE内でまたはTrEによって格納される妥当性検査の証明書にアクセスし、使用する能力とを含むことができる。TrEは、図4のインターフェース3とTrE内でまたはTrEによって格納されるデバイス認証の秘密証明書にアクセスし、使用する能力とを含むセキュア処理を必要とするデバイス認証プロセスの部分を安全にすることができる。他の能力は、セキュリティに敏感な処理を必要とする可能性がある、TrEの外部に常駐するアプリケーションをサポートするためのセキュア処理の実行を含むことができる。これらのアプリケーションは、それ自体の秘密の証明書図4には図示せずにアクセスしまたは使用することができる。TrEは、TrEの外部の、デバイスの機能/アプリケーションへのインターフェースを含むことができる。例は、デバイス上でのデバイス認証処理のための図4のインターフェース2、および/またはTrE内からのセキュア処理を必要とする可能性がある他の非認証アプリケーションのための図4のインターフェース5を含むが、これに限定されない。さらに、デバイスの非TrE部分は、次のタイプの機能のうちの1つまたは複数を実行することができる。1つの機能を、デバイス認証機能の非セキュア部分とすることができる。もう1つの機能を、TrEにセキュア処理を要求しないアプリケーションに関するものとすることができる。もう1つの機能を、TrEにセキュア処理を要求するアプリケーションデバイス認証以外に関するものとすることができる。デバイスの非TrE部分は、デバイス認証に関する図4のインターフェース4、デバイスの能力の間のメッセージ交換d、および/またはネットワークベースのAAAサーバgを含むインターフェースをサポートすることができる。図4のインターフェース6を、デバイスの側のTrE内からのセキュア処理を要求する可能性がある機能に関するメッセージ交換に使用することができる。図4のインターフェース7を、デバイスの側のTrE内からのセキュア処理を要求しない可能性がある機能に関するメッセージ交換に使用することができる。デバイス認証に使用される証明書およびデバイス完全性妥当性検査に使用される証明書を、同一でないものとすることができる。しかし、そのような証明書を、お互いにバインドされるように構成することができる。図4は、HeNB内で物理バインディングを使用できるデバイスの例である。たとえば、物理バインディングを、妥当性検査とデバイス認証との両方に関してTrEの使用によって実行することができる。HeNB内では、たとえば、TrEを、デバイス妥当性検査に必要なプロセス全体を実行するように設計することができる。これらのプロセスは、少なくとも、プロセスのうちで、デバイス認証に必要なプロセスの最もセキュアなまたは信頼される処理を必要とする可能性がある部分、またはプロセス自体の全体を含むことができる。たとえば、デバイス認証プロトコルが、EAP-AKAなどの事前に共有される鍵ベースの手法を使用するように設計される場合に、AKA証明書を保持するTrEおよびHeNBを、さらに、お互いにバインドすることができる。たとえば、HeNBは、データをTrEに伝える前に暗号化解除をTrEに制限できるように、デバイス認証に使用されるAKA証明書を計算するのに必要なデータを暗号化することができる。TrEは、このデータを暗号化解除するのに必要な鍵をセキュアに格納することができる。さらに、デバイス妥当性検査に関する情報とデバイス認証に関する情報とを、IKEv2などの共通のセキュリティプロトコルの同一セッション内で組み合わせることによって、さらなるバインディングを得ることができる。この場合に、そのようなバインディングに適切なデバイス妥当性検査を、HeNBおよびそのTrEとネットワークエンティティとの間のある種の相互作用およびメッセージ交換を必要とするようなものとすることができる。上述したように、論理バインディングは、デバイス妥当性検査および認証に使用できるもう1つのタイプのバインディングである。論理バインディングの例は、デバイス妥当性検査およびデバイス認証のためにデバイスから転送される必要があるメッセージを実行するための、同一のまたは共通の通信プロトコルメッセージの同一のパケット、メッセージ、セッション、または連続するセッションの使用とすることができる。物理バインディング法および論理バインディング法を、お互いと組み合わせて使用することができることに留意されたい。デバイス妥当性検査を、事前に共有される秘密ベースのクライアント認証にバインドすることができる。HeNBのデバイス妥当性検査を、バインディングの次の物理的機構および/または論理的機構のうちの1つまたは任意の組合せで事前に共有される鍵ベースの認証にバインドするために実行することができる。TrEとHeNBの残りとの間のメッセージ交換に暗号鍵および証明書を使用することによってTrEtrustedenvironmentをHeNBに物理的にバインドすることによって、鍵および証明書を、少なくともTrEおよびHeNBの内部で保護することができる。これを、デバイス認証に関するTrEとHeNBとの間のメッセージ交換に適用することができる。図5を参照すると、TrEは、最初に、HeNBの完全性を検査することができる。成功の場合に、TrEは、図5のリンク2に進むことができ、成功ではない場合には、TrEは、リンク2に進むことができるのではなく、その代わりに、おそらくはHeNBのデバイス認証機能を含む機能性をロックすることができる。HeNBの完全性を検査するために、TrEは、TrE内に格納されたデバイス妥当性検査証明書を使用することができる図5のリンク1を参照されたい。リンク2では、TrEは、鍵対を備えることができ、この鍵対のプライベート部分は、TrEの内部でセキュアに格納され、パブリック部分は、HeNBから使用可能にされる。HeNBの製造業者は、この鍵対を生成し、パブリックキーをHeNBから使用可能にするために必要な証明書を提供することができる。TrEのデバイス妥当性検査機能性は、たとえば、TrEのID、TrEがHeNBの残りの完全性を成功して検証したことを示すメッセージ、および/またはTrEがデバイス認証機能を認可し、デバイス認証の手順に進むことを認可され得ることを示す認可データのうちの1つまたは複数をTrEの外部のデバイス認証機能に示すためのメッセージに署名するのにTrEプライベートキーprivatekeyを使用することができるたとえば、図5に示されたリンク2で。TrEプライベートキーを、この認可メッセージに署名するのに使用することができる。この認可メッセージは、HeNBデバイス上のデバイス認証機能によるTrEのあるセキュア処理能力の使用を認可することができる。TrEからTrEの外部のデバイス認証機能への署名されたメッセージの転送を、図5のリンク3によって描くことができる。HeNBは、上のリンク2で説明した署名を検証するために必要とする可能性があるTrEパブリックキーを使用することができる。このパブリックキーは、証明書で事前にプロビジョニングされるか、他の形で使用の前にデバイス認証機能から使用可能にされるかのいずれかとすることができる。パブリックキーの使用を、図5の線4によって描くことができる。デバイス認証機能は、TrEがデバイス認証手順に必要である可能性があるセキュリティに敏感な機能を実行するために、TrE内に常駐するデバイス認証のセキュア処理能力を使用することができる。このサービスを要求し、入手するためのこのインターフェースを、図5の線5によって描くことができる。デバイス認証のセキュア処理能力は、AAAサーバがHeNBデバイスを認証するためにデバイス認証機能がAAAサーバに送信する必要がある可能性があるデータを計算するために、TrE内に事前に格納された秘密のデバイス認証証明書を使用することができる。これを、図5の線6で描くことができる。デバイス認証機能は、AAAサーバがHeNBデバイスのアイデンティティを認証できるように、TrEによって提供されるデバイス認証のセキュア処理能力から計算されたデータを含むデータをAAAサーバと交換することに進むことができる。これを、図5の線7として描くことができる。この機能を、適切なメッセージ交換プロトコルで実行することができる。たとえば、HeNBの場合には、IKEv2プロトコル、TLSプロトコル、TR069プロトコルアプリケーション層プロトコル、OMA-DMプロトコルなどのプロトコル、またはHTTPSなどのより上位の層のプロトコルさえ、検討することができる。デバイス認証機能が、それ自体でセキュリティ集中型機能を実行することができることに留意されたい。妥当性検査およびデバイス認証を、HeNBおよびTrEに集合的に同一パケットまたは同一メッセージを使用してデバイス妥当性検査の手順および認証の手順の指定された部分を実行させることによってバインドすることができる。これを、共通のセキュリティプロトコルの共通の通信セッションまたは連続するセッション1つまたは複数で実行することができる。そのようなプロトコルの例は、IKEv2プロトコル、TLS、TR069、OMA-DM、およびHTTPSを含むことができる。プロトコルは、事前に共有される秘密ベースのプロトコル、非対称鍵ベースのプロトコル、対称鍵ベースのプロトコルなどを使用することができる。図6は、妥当性検査データと認証データの一部とを同一のプロトコル/セッション/メッセージ内で送信できる、そのようなバインディング機構の例である。図6では、線1は、TrEの内部のデバイス妥当性検査機能DVFが、デバイス妥当性検査証明書を使用して、HeNBのコンポーネントの完全性が保たれるか否かを検証するために、必要なデバイス完全性検査を実行することができることを示す。DVFが、デバイス完全性検査および検証に必要ないくつかの機能を実行するために、TrEの暗号能力TCCによって提供される機能性を使用することができることに留意されたい。この関係を、図6の破線Aによって描くことができる。後のある時に、HeNBの内部のデバイス認証機能DAFは、それ自体と外部AAAサーバとの間の暗号化および署名のための認証されない共有される鍵をセットアップするためのDiffie-HellmannD-H手順などの手順を実行することができる。線7-aによって描かれるこのステップは、デバイス認証の先駆ステップとすることができ、従うべきデバイス認証メッセージプロトコル中に使用される認証されない暗号鍵をセットアップすることができる。DAFが、D-H手順に必要な中間ステップのいくつかを実行するためにTrEの暗号能力TCCに頼ることができることに留意されたい。点線Cは、TCCに暗号サービスを要求し、入手するためにDAFが使用する、DAFとTCCとの間のインターフェースとすることができる。DAFは、AAAサーバにDev_Auth_Init_Requestメッセージを送信することによってデバイス認証手順を開始することができる。たとえば、IKEv2プロトコルが使用される場合に、このメッセージを、IKE_SA_INIT要求メッセージ上で運ぶことができる。このDev_Auth_Init_Requestメッセージ内に、DAFは、ヘッダHDR、たとえばとりわけセキュリティパラメータインデックスSPIをAAAサーバに提案するセキュリティ関連付けSA、D-Hプロセスから生成されたサーバのパブリックキーKE_DH、および/またはデバイス自体のIDDev_IDを含めることができる。このステップを、図6の線7-bによって描くことができる。AAAサーバは、デバイスのDAFへのDev_Auth_Init_ResponseIKEv2がプロトコルとして使用される場合にはIKE_SA_INIT応答メッセージをDAFに送信することができる。このメッセージは、ヘッダHDR、D-Hプロセスから生成されたデバイスのパブリックキーKE_DH、およびサーバ自体のIDSvr_IDなどの情報要素を含むことができる。このステップを、図6の線7-cによって描くことができる。DAFは、図6の線7-dによって描かれるように、Dev_Auth_RequestメッセージIKEv2が選択されたプロトコルである場合にはIKE_AUTH要求メッセージとすることができる内で、ヘッダ、SA、Dev_ID、構成CONFIG、および/またはオプションのサーバ証明書要求Svr_Cer_REQをAAAサーバに送信することができる。ここから、情報要素の一部を、D-Hプロセスから生成された鍵による暗号化および署名によって保護することができることに留意されたい。たとえば、Dev_ID、Session_ID、CONFIG、およびオプションのサーバ証明書要求のすべてを、D-Hプロセスから生成された鍵の使用によって、機密性および完全性のために保護することができる。DAFが、D-H生成された鍵を使用する暗号化および署名を実行するためにTrEの暗号能力TCCを使用することができることに留意されたい。この関係を、図6の線Bによって描くことができる。AAAサーバは、とりわけ、ヘッダ、Svr_ID、Session_ID、およびオプションでDAFによって要求された場合にサーバ証明書Svr_Crt、HeNBとAAAとの間で共有される認証秘密図6ではTrE内に格納されて図示に基づく認証チャレンジAuth-Challengeなどを含むDev_Auth_ResponseメッセージIKEv2がプロトコルとして使用される場合にはIKE_AUTH応答メッセージになるはずであるをDAFに送信することができる。これを、図6の線7-eとして描くことができる。DAFは、とりわけ、ヘッダ、Dev_ID、Session_ID、認証チャレンジレスポンスAUTH、および/または妥当性検査データValidation_Dataを含むことができるDev_Auth_RequestメッセージIKEv2が使用される場合にはもう1つのIKE_AUTH要求メッセージとすることができるをAAAサーバに送信することができる。これを、図6の線7-fによって描くことができる。DAFが、図6の線3によって描かれるように、AUTHを計算し、転送するためにTrE内のデバイス認証のセキュア処理能力SPC_DAに頼ることができることに留意されたい。SPC_DAが、図6の線4によって描かれるように、AUTHを計算するためにTrE内に格納された事前に共有される認証秘密証明書を使用することができることに留意されたい。さらに、SPC_DAは、TrEの暗号能力TCCに頼ることができる点線Cを参照されたい。SPCが、AUTHを計算することができることに留意されたい。デバイス妥当性検査機能DVFは、図6の線5によって表されるようにDAFにValidation_Dataを転送する前に、TrEプライベートキーを使用してValidation_Dataおよび任意の追加の関連する補足データに署名することもできる。DVFとTrEプライベートキーとの間のインターフェースを使用して、妥当性検査データをDAFに転送する前にその妥当性検査データに署名することができ、このインターフェースは、線2によって表される。この例では、妥当性検査とデバイス認証またはデバイス認証のあるセキュリティを必要とする部分との両方を実行するための共通のTrEおよびそのアセットの使用の物理バインディングに加えて、別の論理バインディング機構を使用することができる。同一のプロトコル、同一のセッション、および同一のメッセージを使用して、デバイス妥当性検査すなわちValidation_Dataとデバイス認証すなわち、AUTHとの両方の結果に関する情報要素をデバイスからAAAサーバに送信することができる。AAAは、6を参照されたいの以前のDev_Auth_RequestメッセージからAUTHパラメータおよびValidation_Dataを受信し、その後に評価した後に、AAAサーバが認証を成功として査定するか否かをデバイスのDAFに示すために、Dev_Auth_Responseメッセージを送信することができる。これを、図6の線7-gによって描くことができる。バインディングの機構では、TrEは、アクセスが許可されるように最初に成功して完了したデバイス妥当性検査手順に対して条件付けることができる認証の成功の完了に関する必要な出力を計算するのに必要である可能性がある機密の機能または機密のデータへのアクセスを制御し、DAFまたはSPC_DAにリリースすることができる。このタイプのバインディング機構を、物理的なバインディング機構と論理的なバインディング機構との両方と考えることができる。図7は、そのようなバインディング機能の例の図である。図7を参照すると、DVFは、TrE内で保持される機能またはデータのいくつかへのアクセスを可能にすることに関して、2タイプのゲーティング手順を実行することができる。ゲーティング手順を、デバイス完全性妥当性検査結果のステータスに依存するものとすることができる。デバイス完全性妥当性検査結果が成功ではない場合には、DVFは、図7の線A:ゲーティングによって表されるように、DAFがTrE内のSPC_DAにアクセスするのを防ぐことができる。DVFは、SPC_DAがAAAサーバに向かう成功の認証を実行するのに必要なデバイス認証証明書にアクセスするのを防ぐことができる。これらのタイプのゲーティング機能性は、デバイス妥当性検査とデバイス認証との間の他のタイプの論理バインディングを提供することができる。デバイス妥当性検査を、証明書ベースのデバイス認証などの認証にバインドすることができる。HeNBのデバイス妥当性検査を、証明書ベースのクライアントにバインドすることができ、認証を、上で説明した機構に似た機構を使用して達成することができる。可能な機構の一部を、下で説明する。図8は、物理バインディングを使用する例の図であり、共通のTrEは、デバイス完全性検査と妥当性検査との両方ならびにデバイス認証に必要な機能の一部またはすべてを実行することができる。これらの機能を、たとえばデバイス証明書に基づくものとすることができる。デバイス認証のセキュア処理能力SPC_DAによってデバイス認証に使用される証明書を、デバイス認証のプライベートキーKpriv_DAとすることができ、デバイス認証機能DAFが、Kpriv_DAによって計算されるいくつかの他の材料と一緒にデバイス証明書DevCertをAAAサーバに送信できることを除いて、手順を、図5について説明したものと同一とすることができる。図8を参照すると、鍵にアクセスすることおよびSPC_DAとKpriv_DAとの間の関係を使用することを、線6に関して示すことができる。証明書にアクセスすることおよびDAFとDevCertとの間の関係を使用することを、線8に関して示すことができる。HeNBおよびTrEは、集合的に、IKEv2プロトコルなどの共通のセキュリティプロトコルの同一のパケット、メッセージ、共通の通信セッション、または連続するセッション1つまたは複数内で、デバイス妥当性検査の手順および証明書ベースのクライアント認証の手順の指定された部分を実行することができる。効果的に、このバインディング機構のプロセスを、図6について説明した機構に類似するものとすることができる。戻って図6を参照すると、事前に共有される秘密ベースのデバイス認証が使用される場合と比較した差を、次とすることができる。AAAサーバからのAUTHチャレンジおよびTrEが保持する事前に共有される秘密およびSPC_DAは、計算し、DAFに計算結果に転送するのに使用するに基づいて機密の中間結果を計算するのではなく、SPC_DAは、AAAサーバからのAUTHチャレンジおよびKpriv_DAに基づいて、AUTHチャレンジから機密の中間結果を計算することができる。AAAサーバは、DAFにデバイス認証証明書DevCertを要求することができる。これに応答して、SPC_DAと共に働くDAFは、1Kpriv_DAを使用して認証応答AUTHを、および/または2DevCertを計算し、AAAサーバに転送することができる。AUTHおよびDevCertを受信したときに、AAAサーバは、まず、DevCertの妥当性を検証することができ、その後、そのDevCertを使用して、AUTHを検証することができる。検証が検査する場合に、検証は、デバイスを認証し終えていることができる。この差にもかかわらず、論理バインディングに関する限り、論理バインディングを、事前に共有される秘密ベースの認証の場合に類似して実行することができる。たとえば、DAFは、AUTHおよびDevCertをAAAサーバに転送することができ、その同一のメッセージにValidation_Dataを含めることもできる。このValidation_Messageを、TrEの内部のDVFから入手することができ、TrEプライベートキーを使用してDVFによって署名することができる。図9は、例のバインディング機構の図である。この例では、AAAサーバからデバイスへの認証チャレンジ自体はない。そうではなく、サーバが、デバイスに、その証明書DevCertを送信するように要求線7-cを参照されたいした後に、デバイスは、線7-dに描かれているように、そのDevCertおよびAUTHKpriv_DAから計算されたをAAAサーバに送信することができる。AAAサーバは、DevCertに対してAUTHを検証し、認証のステータスの確認を送信することができる7-e。ゲーティングタイプのバインディングを、証明書ベースの認証の例で実施することができる。この例は、事前に共有される秘密ベースの認証の例に類似する。図10は、そのようなバインディング機構の例の図である。図10を参照すると、DVFは、デバイス完全性妥当性検査結果のステータスに応じて、TrE内で保持される機能またはデータの一部へのアクセスを可能にすることに関して2タイプのゲーティング手順を実行することができる。デバイス完全性妥当性検査結果が成功ではない場合には、DVFは、図10の線A:ゲーティングによって表されるように、DAFがTrE内のSPC_DAにアクセスするのを防ぐことができる。あるいは、DVFは、SPC_DAがAAAサーバに向かう成功の認証を実行するのに必要なKpriv_DAにアクセスするのを防ぐことができる。これらのタイプのゲーティング機能性は、デバイス妥当性検査とデバイス認証との間のもう1つのタイプの論理バインディングを提供することができる。他の本質的なデバイス機能に対するデバイス完全性妥当性検査の一般化されたバインディングを提供することができる。デバイス完全性妥当性検査とデバイス認証との間のバインディングという概念は、上で説明したように、一般に、デバイス完全性妥当性検査のプロセス、使用される入力データおよび/もしくは中間データ、ならびに/または結果が、認証の手順またはプロセスをゲーティングすることができることを意味することができる。バインディングの概念を、バインディングを実施できるデバイスのタイプと、デバイス完全性妥当性検査のプロセスにバインドできるデバイスの機能との両方に関して一般化することができる。最も一般的な意味で、一般に、それ自体でまたは外部エンティティとの相互作用プロセスを実行することによってそれ自体のデバイス完全性を検査し、報告し、かつ/もしくは検証する能力および/またはデバイスの本質的機能と考えることができる少なくとも1つの機能Xを実行する能力を有するデバイスDが存在する場合に、バインディングが実施されると考えることができる。本質的機能を、意図された通りにそれを実行しなければ、デバイスXが通常の有用な意味で動作可能であると考えることができない機能とすることができる。携帯電話機などのデバイスの本質的機能の例は、遭難アラームdistressalarmを送信する能力、加入者認証ネットワークに対する、デバイス認証、コアアプリケーション、通信スタック実行、ユーザ認証デバイスに対する、デバイス管理機能、無線信号の送信もしくは受信、またはデバイス電源および管理機能のうちの1つまたは複数を含むことができる。バインディングを、デバイス完全性妥当性検査プロセスのデータD_V、手順P_V、または結果R_Vのいずれかが、本質的機能Xの成功の機能に向かってそのようなD_V、P_V、および/またはR_Vの間の一意で偽造またはクローン作成が困難または不可能な関係を示すことができる手順として定義し、実施することができる。前の節で説明した3タイプのバインディング機構を、やはり、適用することができる。暗号手段の共有される存在および使用に起因するバインディング、同一のまたは連続する通信プロトコルパケット、メッセージ、セッション、もしくは複数のセッションの使用に起因するバインディング、および/またはデバイスDの成功の妥当性検査に基づいて条件付けることのできる本質的機能Xの成功の機能に必須とすることができるデータD_Xもしくは手順P_Xへのゲーティングもしくは条件付きアクセスに起因するバインディング。図11は、第2のタイプのバインディングすなわちゲーティングタイプのバインディングを妥当性検査機能DVFとデバイス上の機能Xとの間で使用できる例の図である。TrEは、その中に、機能Xのセキュア手順能力SPC_Xおよび機能Xに必要な機密データSD_Xを有することができる。DVFは、デバイス上の機能X自体ならびに、機能によって必要とされるデバイスの非TrE部分上の任意のデータD_Xと、デバイスD内に組み込まれるかデバイスDに接続されたコンポーネント/モジュール上の機能X_ECと、ネットワークベースの機能X_Nおよびそれが使用できるデータD_X_Nとをゲーティングすることもできる。図11は、複数のタイプのゲーティングAからGを示し、DVFは、デバイス完全性妥当性検査の結果に応じて、Aセキュア処理能力SPC_X、および/またはB機能SPC_Xのために必要である可能性があるTrEの内部の機密データSD_X、および/またはCTrEの内部もしくは外部とすることができるデバイスX上の任意の機能、および/またはDTrEの内部もしくは外部とすることができ、任意の機能Xによって必要とされる可能性があるデバイス上の任意のデータ、および/またはEデバイス内の組み込まれたコンポーネントたとえば、SoCなどもしくはデバイスに接続されたディスクリートコンポーネントたとえば、UICCなどのいずれかの上の任意の機能X_EC、および/またはF外部エンティティによって実行されるたとえば、ネットワークから任意の機能X_N、および/またはG任意のそのような外部機能X_Nによって必要とされる任意のデータD_X_Nへのアクセスをゲーティングすることができる。手順Xの例が、通信機能、たとえば、ラジオおよびベースバンドの送信および受信、デバイス電力管理オン/オフを含む、ユーザインターフェース、メディアプロセッサ機能、GPSおよび他のロケーション機能、タイマおよびタイミング同期化機能、WLAN、Bluetooth登録商標、およびセルラ通信などの通信機能、ウェブ機能、シングルサインオン、ならびにアイデンティファイフェデレーションidentifyfederationおよび管理機能などの高水準アプリケーション、コーデック機能、ゲーミング機能などの音声および他のメディア機能、加入者認証、デバイス認証、アプリケーションの認可、暗号化/暗号化解除、署名、および署名検証を含む暗号動作、ならびにデバイスの任意の他の機能などの機能を含むことができることに留意されたい。SPC_Xは、暗号暗号化暗号化解除cryptographicencryption、署名生成もしくは検証、乱数生成もしくは使用、タイミング同期化およびタイムスタンピング、メッセージ認証コード生成および検証、暗号鍵生成、導出、もしくは管理デプリケーションdeprecationまたは検疫を含む、証明書検証、ならびに、TrE、デバイスのユーザ、デバイス自体、またはデバイスの加入者および/もしくは所有者の認証または認可に必要な秘密材料の計算を含むことができるが、これに限定されない。機能X_ECの例は、データ格納および処理機能、認証機能、鍵生成および使用、暗号化暗号化解除、署名生成および検証、構成管理などを含むことができるが、これに限定されない。機能X_Nの例は、データ格納および処理機能、デバイス管理、プロビジョニング、高水準アプリケーションウェブアクセスその他などなどのタスクに関するネットワーク提供アプリケーション、DRM、音声およびマルチメディアサービスおよびゲーミング機能、デバイス管理サービス、通信サービス、シングルサインオンおよびアイデンティティフェデレーションおよび管理などを含むことができるが、これに限定されない。ゲーティング手順を、カスケードとして実行することができる。すなわち、DVFが、あるアプリケーションへのアクセスをゲーティングすることができ、そのアプリケーションが、別のアプリケーションまたはデータへのアクセスをゲーティングすることができるなどである。DVFは、複数の手順またはデータをゲーティングすることができ、これらの手順またはデータの一部またはすべてが、因果関係または対応関係を有することができる。特徴および要素を、上で特定の組合せで説明する場合があるが、各特徴または要素を、他の特徴または要素なしで単独で、または他の特徴および要素を伴うもしくは伴わないさまざまな組合せで、使用することができる。本明細書で提供される方法または流れ図を、汎用コンピュータまたはプロセッサによる実行のためにコンピュータ可読記憶媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアで実施することができる。コンピュータ可読記憶媒体の例は、読取り専用メモリROM、ランダムアクセスメモリRAM、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよびリムーバブルディスクなどの磁気媒体、光磁気媒体、ならびにCD-ROMディスクおよびディジタル多用途ディスクDVDなどの光学媒体を含む。適切なプロセッサは、たとえば、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、DSPディジタル信号プロセッサ、複数のマイクロプロセッサ、DSPコアに関連する1つもしくは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、ASIC特定用途向け集積回路、FPGAフィールドプログラマブルゲートアレイ回路、任意の他のタイプのIC集積回路、および/または状態機械を含む。ソフトウェアに関連するプロセッサを使用して、WTRU無線送受信ユニット、UEユーザ機器、端末、基地局、RNC無線ネットワーク制御装置、または任意のホストコンピュータ内で使用されるラジオ周波数トランシーバを実施することができる。WTRUを、カメラ、ビデオカメラモジュール、ビデオ電話、スピーカホン、振動デバイス、スピーカ、マイクロホン、テレビジョントランシーバ、ハンズフリーヘッドセット、キーボード、Bluetooth登録商標モジュール、FM周波数変調ラジオユニット、液晶ディスプレイLCD表示ユニット、有機発光ダイオードOLED表示ユニット、ディジタル音楽プレイヤ、メディアプレイヤ、ビデオゲームプレイヤモジュール、インターネットブラウザ、および/または任意の無線ローカルエリアネットワークWLANモジュールもしくはUWBウルトラワイドバンドモジュールなど、ハードウェアおよび/またはソフトウェアで実施されるモジュールに関連して使用することができる。ネットワークデバイスの完全性妥当性検査を実行するシステム、方法、および手段を開示する。ネットワークデバイスは、セキュアメモリを含むことができる。たとえば、セキュアメモリを、セキュアハードウェアモジュール内に含めることができる。セキュアメモリは、ルート鍵を受信することができる。たとえば、ルート鍵を、製造の時またはプロビジョニングの時にセキュアメモリによって受信することができる。ルート鍵を、セキュアメモリに格納することができ、ルート鍵は、セキュアハードウェアモジュールの外部のソフトウェアまたはハードウェアから不可視とすることができる。セキュアハードウェアモジュールは、第1のコード測定第1のコードの測定を受信することができる。たとえば、セキュアハードウェアモジュールを含むネットワークデバイスに関連するプロセッサなどのプロセッサは、測定すべきコードの第1の部分を選択することができる。コードの第1の部分を、ネットワークデバイスに関連するメモリ、たとえばROMメモリ、RAMメモリなどに格納することができる。プロセッサは、コードの選択された第1の部分を選択し、第1のコード測定をもたらすことができる。プロセッサは、測定をセキュアハードウェアモジュールに提供することができる。セキュアハードウェアモジュールは、ルート鍵および第1のコード測定に基づいて第1の鍵を生成することができる。たとえば、セキュアハードウェアモジュールは、第1の鍵を導出するかリリースすることができる。生成された第1の鍵は、第1のコード測定が有効であるときに有効であり、第1のコード測定が無効であるときに無効である。たとえば、セキュアハードウェアモジュールは、部分的に第1のコード測定に基づいて第1の鍵を導出することができる。第1のコード測定が無効である場合には、導出された第1の鍵も無効である。生成された第1の鍵を、リソースへのアクセスを提供するためにセキュアハードウェアモジュールによって生成することができる。コードがセキュアメモリに格納されるときに、リソースへのアクセスを、コード測定なしで提供することができる。第1の鍵は、第1の機能に関連する信頼の第1のステージに関係することができるたとえば、1つまたは複数のリソースを、第1の機能に関連付けることができる。さらに、第1のステークホルダは、第1の機能にアクセスするために有効な第1の鍵を使用することができる。第1の鍵が有効ではない場合には、第1のステークホルダは、第1の機能にアクセスすることができない。すなわち、セキュアハードウェアモジュールは、第1のコード測定が無効であるときに第1の機能へのアクセスを防ぐことができる。セキュアハードウェアモジュールは、第2のコード測定第2のコードの測定を受信することができる。セキュアハードウェアモジュールは、第1の鍵および第2のコード測定に基づいて第2の鍵を生成することができる。第2の鍵は、第2の機能に関連する信頼の第2のステージに関係することができるたとえば、1つまたは複数のリソースを第2の機能に関連付けることができる。さらに、第2のステークホルダは、第2の機能にアクセスするために有効な第2の鍵を使用することができる。鍵のリリースを、最後の既知のよいブートステージたとえば、それに関して成功の認証があった最後の既知のブートステージに制限することができる。ハードウェア、コード、および/またはデータの完全性測定に基づく鍵および機能性などのリソースの生成および/またはリリースは、段階的な認証を提供することができる。たとえば、デバイスは、複数のレイヤを含むことができ、各レイヤは、それ自体の認証秘密を有する。各認証秘密は、製造業者ファームウェア、信頼される実行コード、オペレーティングシステム、およびサードパーティアプリケーションなどのデバイス能力のレイヤ内の特定のステークホルダに対応することができる。さらなる例として、有効な第1の鍵を、第1のブートステージに対する有効な認証に関連付けることができる。有効な第1の鍵を、ファームウェアに対する矯正を実行するためにネットワークデバイス上のファームウェアにアクセスするのに、デバイス製造業者たとえば、第1のステークホルダによって使用することができる。有効な第2の鍵を、より後のブートステージたとえば、中間ブートステージ中の1つまたは複数のソフトウェアコンポーネントの有効な認証に関連付けることができる。有効な第2の鍵を、ソフトウェアコンポーネントにアクセスするのに、たとえばソフトウェアに対する矯正を実行するのに、デバイスマネージャたとえば、第2のステークホルダによって使用することができる。成功して認証されたステージの有効な鍵を提供することによって、アクセスを、認証に失敗しなかった最後のステージに釣り合って許可することができる。開示されるマルチステージ認証のステージ数は、変更することができ、限定されない。さらに、複数の認証経路を提供することができる。すなわち、認証は、完全性検査の所与のステージで異なる形で分岐することができる。たとえば、各ステークホルダは、認証の1つまたは複数のステージに関係する1つまたは複数のポリシを提供することができる。各ステージでは、認証は、ステークホルダポリシに基づいて異なる形で分岐することができる。ステークホルダは、そのポリシを外部から管理できるものとすることができる。図12に、デバイス1200の例示的なブートプロセスに関係する複数のステージでの認証を示す。デバイス1200を、階層化ブートステージ能力たとえば、1つまたは複数のステージ認証に関連する1つまたは複数の有効な鍵をリリースするためを有して構成することができる。デバイス1200が、第1のブートステージに認証するときに、デバイス1200は、1201で、有効な第1の鍵を製造業者などの第1のステークホルダに提供することができる。第1のブートステージを、低水準認証とすることができ、第1のブートステージに関連する鍵は、製造業者に関連するファームウェアに制限されたアクセスを提供することができる。デバイス1200が、第2のブートステージに認証するときに、デバイス1200は、1202で、有効な第2の鍵をデバイスマネージャなどの第2のステークホルダに提供することができる。第2のブートステージを、第1のブートステージより後のブートステージとすることができ、第2のブートステージに関連する鍵は、認証されたソフトウェアに制限されたアクセスを提供することができる。デバイス1200が、最終ブートステージに認証するときに、デバイス1200は、1203で、有効な第3の鍵を、コアネットワーク、セキュリティゲートウェイなどへのアクセスを提供できる第3のステークホルダに提供する。例としてブートプロセスを使用すると、制限されたオンチップリソースと、ブート実行での最後の既知のよいブートステージに関する認証秘密とへのアクセスを、リリースすることができる。そのような段階的リリースは、デバイスに対する信頼されるリモートデバイス管理更新手順に、より下位のレイヤを使用する、コードのより上位のレイヤに対する信頼されるデバイスソフトウェア/ファームウェア矯正を可能にすることができる。これは、セキュアで不変のオンチップの信頼のルートから発する信頼のチェーンに頼ることができる。一例として、リセット時に、第1の鍵をリリースするために、特定のチップ構成を期待することができる。この構成は、プロセッサが正しい内部実行コードにジャンプし、このコードが、信頼実行のチェーン内の次のステージの前に、測定すべきコードの収集を開始できることを保証することができる。たとえばジャンプベクトルが内部ROMコードへのものではないなど、初期チップ構成が正しくない場合には、初期のおよび後続の完全性測定が、期待されるものとは異なる可能性があり、デバイスが、次の有効なステージに進むことができない可能性がある。制御の形は、オンチップリソースのハードウェアアンカリングされたゲーティング、コンポーネント1つまたは複数の測定された完全性の比較、および/またはシステムの実際の測定された完全性に基づく鍵の導出を含むことができる。たとえば、後者の場合に、開示されるシステムおよび方法を使用して、他の使用のための複数の信頼される制御実行経路を生成することができる。というのは、結果の鍵を、通常動作に必要なものとは異なるものとすることができるからである。したがって、一例として、外部エンティティは、異なるブートシーケンスを、したがって、信頼のルートにも基づく異なる鍵をもたらすことができるデバイス上のピンに対する直接制御を有することができる。認証を、たとえば、従来のパラメータに加えて、ブートレベルごとに認証の2つの追加要因を課すことによって提供することができる。外部エンティティに対する認証は、1ブートステージ固有の暗号化された署名する秘密または暗号化する鍵の知識を要求することができ、この秘密または鍵は、2ブートステージ固有コードが正しい完全性検査に合格する場合に明らかにされるものとすることができる。結果の応用例は、外部エンティティが、そのエンティティによって要求される機能性に従ってデバイスの完全性をリモートに妥当性検査できることとすることができる。さらに、独立のステークホルダたとえば、デバイスまたはデバイス製造業者のハードウェアまたはさまざまなファームウェアおよびソフトウェアレイヤのに、他のエンティティがデバイス機能をディスエーブルせずに独立のステークホルダの対応するファームウェアまたはソフトウェアを変更できないものとすることができることを保証することができる。例示的な段階的ブートシーケンスは、オンチップリソースと、ブートプロセスの次のステージに関する暗号化する鍵、署名する鍵、および完全性測定などのプロビジョニングされる秘密とを暗号鍵がアンロックすることを強制するために信頼されるハードウェア機構を検出し、利用することによって始まることができる。各ステージが成功して検査されるときに、オンチップリソース、新しい秘密、および新しい測定が、使用のために使用可能になることができる。いくつかの場合に、情報が、コアの信頼されるドメイン内にある場合があり、ソフトウェア/ファームウェアによるビューイングまたは所有のためではなくハードウェアによる使用のために使用可能にされる場合があり、コードベースの各ステージが検査され、信頼できると検証されるたとえば、コード検査、データ検査、ハードウェア検査などに基づいて信頼できると検証されるときに、オンチップリソースおよび他の情報を実行環境にリリースすることができる。各ブートステージは、セキュアブートプロセス内のそのステージの位置に対応する特権および制御の必要を有する場合がある。排他的にあるステージのために生成された証明書を有することは、たとえば外部エンティティに対する認証のために、プラットフォームの内部を超えて制御を拡張することを可能にすることができる。一例として、デバイス管理およびデバイス認証の場合に、製造業者は、ファームウェアを更新する特権を有する必要がある場合があり、ネットワークオペレータは、ファームウェアではなくソフトウェアおよび/または構成データを矯正しもしくは更新する必要がある場合がある。デバイスが、ファームウェアの完全性検査に合格するがソフトウェアに関して合格しない場合には、使用可能な鍵を、ソフトウェアを更新するためにネットワークオペレータがデバイスを認証することを可能にする鍵とすることができる。しかし、デバイスがファームウェア検査にも合格しない場合には、ネットワークに対して認証するのに必要な鍵ではなく、管理システムに対してデバイスを認証する鍵をリリースすることができ、これは、デバイスを非セキュアな形すなわち信頼プロセスのルートの外でブートすることができないように、プリミティブプロセスが、ファームウェアをリモートにセキュアに矯正/インストールするために定位置にあるものとすることができることを意味する。ファームウェア障害は、矯正を助けるための代替機能のリリースをトリガすることができるたとえば、認証が、障害に起因して異なる分岐をたどることができる。信頼のルート立証rootoftrustattestationを提供することの利益は、デバイスのファームウェア信頼コードベースのリモート管理を可能にすることができることとすることができる。オペレータおよびアプリケーションプロバイダなどの異なるステークホルダが、ブートシーケンス中の測定の結果によって特徴を表されるシステムの信頼性レベルに基づいて異なる鍵を使用することを許可することができる。これは、いくつかのオペレータまたはデバイスの所有者が、それでも、システムがおそらくは複数のステージで部分的に信頼されるが部分的に信頼されない状態にブートすることを許可することができることを意味する。そのような状態であっても、デバイスに、ある種の暗号鍵を生成し、使用することを要求することができるたとえば、デバイスの状態に関して外部ユーザに示すため、または、デバイスのそのような部分的に信頼される状態の下であっても許可されることのできるアプリケーションにセキュリティを提供するために。1つのオプションは、ブートシーケンスでより高いレベルの信頼を確立できる場合により高い強度の鍵を生成し、使用し、ブートシーケンス結果に基づいて比較的低いレベルの信頼が確立される場合に比較的低い強度の鍵の使用に制限することとすることができる。ポリシを、事前にプロビジョニングすることができ、信頼のルートは、確立できる信頼のレベルに対応するものとすることができる適当な鍵強度を強制することができる。信頼性の異なるレベルに固有のそのような複数の鍵の生成および使用は、準最適信頼検証されたシステムが、ブートされるシステムの信頼性レベルに一致しない可能性がある鍵の強度の過度なレベルを要求せずに、外部当事者にある種の情報を送信するために暗号リソースを使用する必要がある可能性があるときに、有用である可能性がある。異なる鍵の導出を、有効なステージの複数のセットがあるものとすることができるように、異なるブートシーケンスおよび異なるコードに基づいて許可することができる。異なるブートシーケンスから生じる可能なデバイス一意秘密鍵は、信頼の同一のルート同一のルート鍵を使用することができるから発することができ、したがって、同様に信頼できるが、明確に異なり、相互に排他的であり、これは、役割の分離たとえば、信頼されるテストモード対信頼される通常動作を可能にすることができる。鍵導出機構および署名する機構のアルゴリズム選択を提供することができる。次のステージの鍵導出および/または現在のステージの署名もしくは認証のための特定のアルゴリズムの実施を、提供することができる。これらの制御は、暗号化解除の際に、フィールド値を、実施制御をセットできるブートステージ認証モジュール内の対応するレジスタに挿入できるように、暗号化された証明書パッケージ内の専用の制御レジスタフィールド内に常駐することができる。ブートステージ認証モジュールを、TrEとすることができる。図13A、13B、および13Cに、開示されるシステム、方法、および手段の実施形態をそれを用いて実施できる例示的なチップを示す。セキュア複数ステージブート認証を、たとえば、ブートステージ認証モジュール1300などのセキュアハードウェア内で実施することができる。ブートステージ認証モジュール1300は、4つのコンポーネントすなわち、ルートデバイス一意秘密鍵ルート鍵、制御信号およびステージ固有鍵導出機能KDF、暗号エンジン、ならびに署名する機構を含むことができる。モジュールへのインターフェースは、構成インターフェースおよびデータバスインターフェースを含むことができる。構成レジスタは、MMUまたはブート実行ベクトル、チップ入出力などの制御などの命令およびデータフローを実施することができる。鍵経路を、ブートステージ認証モジュール1300の内部であることによって、ソフトウェア/ファームウェアによるビューから保護することができる。ブートステージ構成インターフェースは、チップがセキュアブートプロセスを開始するために正しい構成であることを保証することができる。セキュアブートプロセスが正しく開始しない場合、たとえば、構成が代替ブートシーケンスに関するものである場合には、オンチップリソースおよびデバイス一意秘密鍵への結果のステージアクセスは、存在しないものとすることができ、これは、次のブートステージおよびその特定のステージの署名する鍵の暗号化解除への進行を防ぐことができ、したがって、外部エンティティは、デバイスの信頼状態を立証することができない。次のうちの1つまたは複数を組み合わせることができる:有鍵暗号ハッシュ化アルゴリズム、デバイス一意秘密鍵、フィードバック鍵経路、および署名する機構。認証秘密のレイヤを、特定のデバイスならびに実行コードおよびブート構成制御などの測定された情報の完全性に暗号的にバインドすることができる。測定された情報が完全性を欠く場合には、実行の後続の従属レイヤが、認証秘密にアクセスしまたは暗号化解除することができない可能性がある。たとえば、デバイスが、そのプロセッサジャンプベクトルを適当にセットされていないか、内部的にブートしないか、デバッグモードである場合には、ビットパターンの相違を検出することができ、これが、その後に外部の関心を持つ当事者に認証することのできない不正な鍵を生成する可能性がある。デバイスは、一意秘密鍵を含むことができる。デバイスの一意秘密鍵を、以前のブートステージ鍵および測定されたコードから導出することができる。デバイス一意鍵が、デバイス上に存在しない場合があるが、コード自体から生成できるので、コードが変更された場合には、デバイス一意秘密鍵が不正である可能性がある。ルートデバイス一意秘密鍵ルート鍵を、初期プロビジョニングまたは製造時にデバイス内に秘密に埋め込むことができ、デバイスに一意とすることができる。ルートデバイス一意秘密鍵は、特定のデバイスブート構成が利用されない限り、使用可能でないものとすることができる。このルート鍵を、ソフトウェア/ファームウェアから可視でないものとすることができ、このルート鍵は、後続のブートステージデバイス一意鍵のシードを提供することができ、このシードは、やはりソフトウェア/ファームウェアから可視でないものとすることができるが、鍵の存在を、したがってブートシーケンス内のそのステージに対するデバイスの完全性を検証できる認証または署名する機構内で利用することができる。ルートデバイス一意秘密鍵を、ソフトウェア/ファームウェア、チップ信号に対する盗聴、プロービング、単純な電力分析および差分電力分析などから秘密であり隠されることができるように、たとえば1回プログラム可能ヒューズとしてまたはメモリ内で、製造プロセス中に構成することができる、適当な強度たとえば、現在は約256ビットとすることができるの鍵とすることができる。ルートデバイス一意秘密鍵は、デバイスに一意であり、誰にも知られないものとすることができ、当初にリセット時に鍵導出機能にシードを与えることができる。図14に、例示的な鍵導出機能を示す。鍵導出機能は、2つの機能のために働くことができる。鍵導出機能は、後続のステージ鍵を生成することができ、後続のブートコードを測定することができる。鍵導出機能は、その一方向特性のゆえに、より後のステージの鍵を入手することが、より以前の鍵に関する情報を全く明らかにせず、測定されたデータのすべてのビットエラーが、正しい鍵への相関を有しない可能性がある非常に異なる鍵をもたらす可能性があることを保証することができる、HMAC-SHA-256などの有鍵暗号ハッシュ関数とすることができる。暗号化されたステージ固有の署名する秘密を、完全性情報と共に与えることができる。完全性情報は、コンポーネントまたは機能の測定された完全性検査値を妥当性検査し、したがって、機能性の次のステージをリリースするように働くことができる。図15に、署名する機構を含む例示的な鍵導出の詳細を示す。頑健なデバイス認証のために、鍵導出機能は、オンチップソフトウェア/ファームウェアおよび外部エンティティから直接に可読ではないものとすることができるブートステージデバイス一意秘密鍵を生成することができる。したがって、デバイス一意鍵を、直接経路内で認証機構または署名する機構に送信することができる。外部エンティティおよびソフトウェアは、認証機構または署名する機構にチャレンジメッセージを提供して、オフチップインターフェースを介するデバイスのブート状態の新鮮さfreshnessを妥当性検査することができる。図16に、例示的なマルチステージ鍵導出の詳細を示す。ブートフローが、初期ブートおよびプログラムローダシーケンスからオペレーティングシステムおよびアプリケーションのロードに進むときに、コードの各ブートステージの完全性を、そのコードが実行される前に測定することができる。コードを、各ステージで鍵導出機能に供給することができ、デバイス一意秘密鍵を、各ステージで生成することができる。たとえば、当初に、ルートデバイス一意秘密鍵ルート鍵および第1のコード測定を、鍵導出機能に供給することができ、第1の鍵初期ステージ鍵を生成することができる。これを、最後のよい証明書が判定されるまで、複数のステージについて繰り返すことができる。図17に、例示的なブートシーケンスを示す。図16の例示的な図は、鍵を複数のステージでどのように導出でき、最後のよい証明書をどのように判定できるのかを示す。初期ステージ鍵は、ハードウェアが信頼実行のルートのために構成されたことを、たとえば、内部ROMへのプロセッサベクトル、ハードウェア完全性テスト結果が正しい可能性があること、およびセキュリティに敏感な入出力ピンが正しくセットされ、たとえばテストモードではないことを検証することができる。ブートステージが、正しいブート構成1つまたは複数およびコードに従って実行される場合に、最終的な結果を、デバイスが信頼できる形でブートしたことを検証するのにネットワークエンティティによって外部で使用できる暗号化する鍵または署名する鍵とすることができる。そうではなく、あるステージブートコードが失敗する場合には、最終的な署名する鍵が不正であり、外部/リモートの認証の失敗につながる可能性がある。実行のチェーンが、署名する鍵のチェーンを追跡する必要がないものとすることができる。ブートシーケンスは、検査するシーケンスたとえば、ハードウェアベースのに実行制御を渡すことができ、この検査するシーケンスは、デバイスの信頼できる動作に必要なコード測定をロードすることができる。測定が正しい場合には、その結果を、デバイスの信頼できる動作を外部から妥当性検査するのに使用できる最後の鍵とすることができる。有効なブートステージから導出された鍵および制御は、ランタイム動作まで永続する残りの暗号化する鍵または署名する鍵をアンロックすることができる。デバイス管理サーバは、この残りの署名する鍵を使用して、サーバが安全にアプリケーションコードをダウンロードできるかどうかを判定するために、デバイスが信頼できる状態にセキュアにブートしたことを検証することができる。その一方で、各ブートステージで鍵へのアクセスを除去することは、たとえば認可されたデバイスパーソナライゼーション、プロビジョニング、デバッギング、テスティングなどのための、特定のブートステージコードの特定のベンダがアクセス可能でなければならないチップのハードウェア保護されたドメインに対する特権付き制御を維持するのを助けることができる。実行するブートコードは、完全性障害が次のステージ測定で発生したことを検出する必要がある場合がある。たとえば、次のブートステージの暗号化された秘密パケットに埋め込まれるのは、暗号化された秘密パケットの特定のフィールドに配置された既知の完全性表示メッセージなどの完全性障害の表示とすることができる。次のブートステージ測定でのエラーが、完全性障害が発生したことを実行するブートコードに示す、期待される値と一致しない可能性があるパケットのフィールド内の混同された完全性表示メッセージをもたらす場合がある。ブートステージ認証モジュールたとえば、図13A~Cを参照されたい内のハードウェア比較器は、たとえば完全性依存ハードウェア構成、チップ秘密、ヒューズ、入出力ピンおよびテストピン、LEDなどへのアクセスを制御するハードウェア制御信号を生成するために、HW保護され、ソフトウェアまたはファームウェアに不可視の期待される完全性値と結果の完全性値との間の一致を検出することができる。制御するブートシーケンスは、障害が発生したことを外部の世界に示すアラートをチップから発行することを選択することができる。または、制御するブートコードは、外部エンティティに認証することを試みるためにチップインターフェースネットワークまたはピンからの入力を待って、アイドルに留まることができる。1つの動作で、ブートステージ認証モジュールは、暗号化されたステージの署名する秘密パケットを暗号化解除することができる。しかし、ステージの証明する秘密を暗号化し、インストールする形の必要がある場合がある。モジュールは、1製造するステージのみのプロビジョン方法のための1回プログラム可能ヒューズによってロックされ、かつ/または2チップ上の認可するハードウェアによってアクセス可能にされることができる、プロビジョニングモード入力信号、認可されたアクセスが許容されない入力信号、および認可されたステージ入力信号を有することができる。チップは、これらの入力が製造するプロセスでヒューズによってロックされない場合にこれらの入力を保護する別の機構を提供する必要がある場合がある。これらの入力がヒューズによってロックダウンされていない場合には、ブートステージ認証モジュールは、デバイスが本明細書で説明するようにそれ自体の検出機構によってセキュアにブートされた場合に、プロビジョニングモードを許可することができる。これは、非セキュアブートコードがプロビジョニングモードに入るのを防ぐことができる。しかし、プロビジョニングモード入力への認可されないアクセスに対して保護するのは、セキュアブートコード、ハードウェア構成、およびチップ上の他の認可ハードウェア次第である可能性がある。言い替えると、ブートステージ認証モジュールは、プロビジョンモードへのアクセスを保護する認可ハードウェアを管理するブートコード認可シーケンスを保護するためにセキュアブートコードが実行されることを保証することができる。一実施形態では、セキュアブートプロセスは、バインドされた鍵たとえば、パブリック、プライベートなどおよびチャレンジレスポンスプロトコルを利用して、プロビジョニングプロセスおよびプロビジョニングモード入力へのアクセスを有することを主張するものを認証し、認可することができる。プロビジョニングモード入力は、署名する秘密パケットの後続ステージを暗号化解除し、ブートステージ認証モジュールに内部的に、ソフトウェアから使用不能でありプロビジョナに不可視の保護されたレジスタ内に格納することを可能にすることができる。その後、プロビジョニングモード状態を、暗号化モードに切り替えることができる。新しいブートステージコードを、鍵導出機能にロードすることができる。コードがロードされるときに、新しいデバイス一意秘密鍵を自動的に生成することができるしかし、ユーザまたはソフトウェアには不可視。その後、新しいブートコードに対応する新しい署名する秘密を、暗号エンジンに挿入し、新しいデバイス一意秘密鍵を用いて暗号化することができる。その結果を、前の版を置換する位置に格納することができる。新しい後続のデバイス一意秘密鍵を導出する後続のブートステージコードを、ロードすることができ、この新しい後続のデバイス一意秘密鍵を、内部的に格納された後続のステージの署名する鍵秘密を暗号化するのに使用することができる。このプロセスは、完了まで継続することができる。デバイスは、新しいブートステージコードおよびそれに対応する署名する鍵を用いてリブートすることができる。後続のブートステージコードおよび鍵は、同一で未知でステージデバイス一意秘密鍵の新しいチェーンにバインドされたままになることができる。変更されたステージの前のブートステージは、変更されないままであることができる。図18に、その強度または暗号アルゴリズム自体などの他のセキュリティの強度特性もしくはアルゴリズムのモードなどがブートシーケンス中に実行される完全性検査手順によって明示されるシステムの信頼性のレベルの結果に依存する可能性がある鍵を生成し、使用するデバイスの例示的なブートシーケンスフローを示す。開示されるシステムおよび方法を、単一のステークホルダたとえば、リモートユーザ実施形態で使用することができ、この実施形態は、単一のステークホルダに、変化する度合の機能性の下でデバイスをセキュアに管理する柔軟性を与えることができる。たとえば、リモートユーザは、セキュリティにクリティカルな複雑な機能にデバイスを使用する前に、デバイスがフルレベルのデバイス完全性および/または機能性を正しく入手したかどうかを妥当性検査することを望む場合がある。達成されたデバイス完全性および/または機能性のレベルを判定するために、ユーザは、デバイスにナンスnonceをサブミットすることと、その後に署名されたレスポンスを取り出すこととによってデバイスにチャレンジすることができるたとえば、ナンスは結果の新鮮さを保証することができる。その後、ユーザは、デバイスが完全性および健全性検査実行のどのステージに合格したのかを判定するために、レスポンスを検査することができる。その結果に基づいて、ユーザは、完全性が検証されている機能1つまたは複数についてそのデバイスとセキュアに相互作用できることの保証を有することができる。一例として、レスポンスが、セキュアブートプロセスが行われなかったたとえば、完全性検査なしことを表す場合に、ユーザは、デバイスが非セキュアな形で構成されており、機密データの処理のためにそのデバイスに頼ることができないことを知ることができる。また、いくつかのデバイス完全性にバインドされた鍵が使用不能である可能性があるので、セキュアブートプロセスにバインドされた暗号化されたデータも、使用不能である可能性がある。プロセスの第1のステージが達成される場合には、デバイスは、それ自体の障害を発生した機能の一部を立証し、リプレイ保護されたおよび/または署名された遭難信号を送出する能力など、あるセキュリティ能力を有することができる。リモートユーザは、そのような信号から、受信された遭難信号が偽ではなく、かつ/または他のデバイスによって成りすまされていないことを判定でき、デバイスが遭難信号を送信したことを知ってデバイスを矯正するアクションを行うことができる。この例を続けると、第2のステージが達成される場合に、ユーザがデバイス上の障害を発生しているコードをリモートからセキュアに変更することを可能にすることができる、より高いレベルの能力/デバイス完全性を表す認証鍵の新しいセットを、デバイス上で使用可能にすることができる。これの変形は、そのような完全性の第2のステージを達成するデバイスが、リモートユーザのOAMまたはデバイス管理DMサーバまたはそのようなサーバアプリケーションに認証することを可能にすることができる鍵へのローカルアクセスを得ることができる場合とすることができる。この例のこのステージでは、デバイスは、リモートユーザまたは彼のOAMサーバもしくはDMサーバまたはそのようなサーバアプリケーションを認証する能力を有することができ、したがって、デバイス上のいくつかのデータおよびコードを、ロードし、達成された完全性のステージに関連する使用可能な鍵を使用して署名することができる。能力の他のレベルに関連する他のステージを達成することもできる。最終的な成功のステージは、デバイスが、リモートユーザがセキュアにアクセスし使用することを必要とする可能性がある機能を完全に実行することができることを表すことができる。本発明は、機能性の複数のステージを含む必要がなく、1つまたは複数のいずれのステークホルダにも限定されない。1つの形態では、デバイスは、リモートユーザの展望から自律的妥当性検査のための単一の認証鍵をもたらす単一の代表的な結果を伴う検査の単一のステージを実行することができる。これを、たとえばネットワークに接続することを試みるデバイスを妥当性検査するのに使用することができる。開示されるシステムおよび方法を、デバイスの信頼状態の表現での柔軟性を可能にし、デバイスレベル、サービスレベル、および/またはアプリケーションレベルでの遭難表示、デバイス監視、デバイス管理機能診断および矯正、ならびに認証手順を可能にするために、拡張可能とすることもできる。好ましいネットワークへのデバイスのアクセスに必要な主鍵とは異なる目的に必要な認証鍵などの他の認証情報を、完全性検査プロセスにバインドすることができる。そのような他の認証の例を、OAMの認証、アプリケーションレベルサービスの認証、またはアクセスレイヤ以外のレイヤでのセキュリティプロトコルIPsecまたはTLSなどの認証とすることができる。他の例は、デバイスおよび/もしくはそのプロファイルたとえば、グループメンバシップなど、加入者/ユーザ、サービス1つまたは複数、またはアプリケーション1つまたは複数の認証を含むことができる。たとえば、図13Cを参照すると、サービスサブスクリプション鍵をKDFに送信することができる。結果の鍵を、サービスプロバイダへの認証に使用できるデバイス一意秘密鍵とすることができる。デバイスへのチャレンジは、加入者とデバイス完全性との両方を認証することができる。その場合に、サービスサブスクリプション鍵を、適当なステージで追加することができる。一実施形態では、完全性バックドintegrity-backedサブスクリプション鍵が、早期のステージで提供され、完全性バックドアプリケーション鍵が、より後のステージで提供される。他の情報をKDF入力で組み合わせて、必要な情報へのバインディングを保証することができる。他の認証情報を完全性検査プロセスにバインドすることによって、認証の複数の独立のソースを提供することができる。開示されるシステム、方法、および手段は、デバイスのセキュアなリモート構成を可能にするための信頼の動的拡張を可能にすることができる。たとえば、工場から出たデバイスは、既知の未構成状態にセキュアにブートすることができる。そのようなデバイスは、まず、ベンダ証明書に含まれる証明書を使用することができる。このステージで使用可能な認証鍵は、外部管理エンティティOAMまたはDMサーバなどがデバイス上の構成データ構造にリモートにアクセスすることを可能にし、認証された外部管理エンティティが新しい証明書たとえば、新しい署名する鍵または新しい署名する鍵を含むことができるオペレータの証明書などを挿入することを可能にすることができる。そのような新しい証明書を、本明細書で説明する方法を使用して保護することができる。新しい構成データに、新しい鍵を用いて署名することができ、新しい実行ステージを、挿入することができ、この新しい実行ステージにも、成功のステージ鍵によって署名することができる。認証鍵を追加することができ、この認証鍵を、この最終的な構成検査の成功の完了によって保護することができる。たとえば、デバイスがリセットされる場合に、デバイスは、新しい構成データを検査できる新しいステージへ自動的に再ブートすることができる。新しい構成データが一致する場合には、結果の認証鍵を使用可能とすることができる。その後、外部エンティティは、デバイスを認証することができる。認証に合格する場合には、外部エンティティに、デバイスが正しく構成されていることを保証することができる。図19に、マルチステージ認証に関係する例示的なネットワーク通信を示す。3GPPRN中継ノードは、DeNBドナーeNBに対するUEすなわち、中継UEならびにそれに接続するUEに対するeNBすなわち、中継eNBの両方として働くことができる。中継ノードを、緊急応答または一時的にカバレージギャップを満たす任務などの使用シナリオでオンサイトで展開することができるので、中継ノードは、展開時に完全には構成されない可能性があり、完全に機能するためにすべての機能性を有していない場合がある。しかし、RNはネットワークデバイスなので、デバイスセキュリティ要件を含むセキュリティ要件は、段階的動作ステータスの達成を可能にする完全性検査の必要をもたらす高いものである必要がある場合がある。そのような段階的動作ステータスが、展開後の構成および証明書エンロールメントのために必要である可能性がある。図20に、例示的な3GPP中継ノードを使用するマルチステージ認証および証明書構成をも含む例示的なスタートアップおよびポストスタートアップ構成手順を示す。この例では、RNは、完全性のある種のステージ1つまたは複数に合格する場合に、既知のオペレータOP管理ボックスたとえば、OAMまたはDMサーバボックスなどならびにベンダのOAM/DMサーバにアクセスできるようにされる。しかし、RNが、さらなるステージに合格しない場合には、RNは、OPMMEMobilityManagementEntityへのフルアクセスに必要な証明書RN上に既に存在してもしなくてもよいにアクセスすることを可能にされない可能性がある。したがって、RNは、OPMMEに対するフルアクセス認証の試みに失敗する可能性がある。しかし、複数の連続するそのような失敗に伴って、RNを、既知のOPOAM/DMへの認証に制限することができ、事前にプロビジョニングされたベンダ証明書を使用してベンダOAM/DMによって再構成されるように指示することができる。RNが、再構成され、その後に完全性検査のさらなるステージに合格する場合には、RNは、今や、OPMMEにアクセスするのに必要な証明書へのアクセスを得ることができる。開示されるシステムおよび方法を、改竄およびランタイム障害に敏感にすることができる。別々の改竄監視プロセスを、デバイスの完全性が確立されるたとえば、監視プロセスを信頼のルートに連鎖させる前またはそのときに確立することができる。このモニタは、コード、ポート、または侵入もしくは改竄イベントを示すことができるすべてのものを検査することができる。そのようなイベントの際には、確立されたデバイス一意秘密鍵の値が、自動的に除去され、認証鍵を使用不能にする。開示されるシステムおよび方法をそれを用いて実施できる例示的なチップを示す図21を参照されたい。完全性ベースの認証鍵を使用してデバイスとのセキュア接続を再確立する試みは、失敗する可能性がある。これは、デバイスのセキュリティに頼る外部エンティティの連続保護を提供することができる。図22に、完全性検査プロセスをどのようにしてUE通信に拡張できるのかを示す。ネットワークは、完全性バインドされた認証鍵を使用して中継ノードにUE鍵を渡すことができる。中継ノードが、完全性または改竄イベントに起因してもはや安全にされない場合には、中継ノードは、暗号化された鍵を暗号化解除できない可能性があり、UEからの通信のセキュリティが維持される。開示されるシステムおよび方法は、デバイスの信頼性の部分的なまたは段階的なリモート判定を可能にすることができるデバイスの署名する鍵のステージングの機構、デバイスの現在のブートステージのコード、構成情報、およびセキュアブートプロセスの状態の成功の測定を使用して制御信号を直接に導出でき、この制御信号がオンチップリソースへのさらなるアクセスを可能にし、認証に関する秘密をリリースできる、オンチップリソースおよび認証秘密の段階的リリースの方法、外部エンティティと部分的に障害を発生している可能性があるデバイスとの間の信頼できる報告、管理、および矯正の使用可能化、ブートプロセス中の明示的な完全性検査手順の必要の除去およびブートコード参照値を格納し保護する必要を除去する、またはチップ境界もしくは公衆インターネットなどの公衆インターフェースにまたがるさまざまなステークホルダへの認証されたアクセスのうちの1つまたは複数を提供することができる。プラットフォーム完全性ポリシエンジンPIPEを、全体的なプラットフォーム信頼システムアーキテクチャの一部とすることができる。PIPEは、マルチステージ認証および鍵リリースのプロセスを制御することができる。PIPEは、セキュアブートプロセスのフロー、ソフトウェアおよび/もしくはデータコンポーネントに対する完全性検査測定の処理、ポリシに従う後続の実施アクション、ならびに/または後続のソフトウェアロード制御のフローを含むさまざまな機能を制御することができる。ポリシを、製造業者および/またはオペレータなどの1つまたは複数の外部ステークホルダによって定義することができ、デバイス上でプロビジョニングし、リモート更新手順を介して現場で更新することができる。PIPEは、1つまたは複数の機能能力を漸進的にインストールすることと、ランタイム中のコンポーネントの動的ローディングを維持することとによって、制御されたソフトウェアおよびデータの検査動作およびロード動作を介して、危険にさらされたソフトウェア機能性がロードされる危険性を制御することができる。例示的な例として、ロード動作での進行のステージに依存して、PIPEは、認証失敗に応答して、プラットフォームをパワーダウンする、危険にさらされたコンポーネント1つまたは複数のロードを防ぐかコンポーネント1つまたは複数を検疫する、低レベル障害もしくは危険にさらされた機能性を通知するためにネットワーク内のセキュリティゲートウェイもしくは矯正マネージャなどの外部エンティティへのアラームをトリガする、認証鍵その他などのプラットフォーム上の機能またはセキュア情報へのアクセスを防ぐ、または、認証アルゴリズムその他などのプラットフォーム上のセキュア機能へのアクセスを防ぐ、のうちの1つまたは複数を実施することができる。いくつかの場合に、障害が非常に深刻であり、信頼される環境でさえ、コアTrE機能性が危険にさらされているのでプラットフォーム内の信頼を保証できない可能性がある場合がある。低レベルでの障害は、完全性およびリプレイ保護と機密性保護とを含むことができるデフォルト信頼のルート署名されたアラームメッセージの生成などの基本的な動作をトリガすることができる。すなわち、低レベルセキュリティ障害の発生時には、遭難メッセージを、使用可能とすることができる1つまたは複数の通信チャネルによってネットワークに公開することができる。ロードされる機能性が作成され、ますます洗練されるにつれて、デバイスは、ネットワークエンティティの代わりにセキュアで信頼できるプロキシとして働くなど、危険にさらされたソフトウェアおよび/もしく構成データの診断、報告、および/もしくは置換のための疑問手順を容易にする、より洗練されたアクションを実行し、バルクコードまたはデータの再ロード/更新手順を実行し、または、コンポーネントの障害の位置を分離するために、より微細な粒度の詳細での完全性検査を含めて改竄が疑われるコンポーネントをより詳細に調査することができる。プラットフォーム上のリソースへの変化するアクセスを、成功して検証された機能性のレベルに応じて提供することができるたとえば、PIPEによって。コンポーネント完全性検査が失敗する場合には、そのコンポーネントを信頼されないものとすることができる。この検出された失敗を、セキュアにマークし、ネットワークに示す明示的にまたは暗黙のいずれかでことができ、その後、ブートフローは、この失敗した条件に起因して分岐することができる。このタイプの完全性検査失敗を、実行フロー障害と称する場合があり、これによって、検査されたコンポーネントを、信頼されないものとすることができ、このコンポーネントの始動は、悪意のある、危険にさらされた、障害のある、または誤って構成されたコードの実行をもたらす可能性があり、デバイスに指定されず期待されない形で機能を実行させる可能性がある。したがって、新しいコンポーネントのロードおよび使用可能な機能性は、以前にロードされたコンポーネントの完全性によって影響を受ける可能性がある。その結果、実行環境が、各ブートステージでの制御する実行プロセスおよびアクセス特権と各ランタイムプロセスとに依存して変化する可能性がある。たとえば、ブートプロセス内の各ステージでは、その時に行われた完全性測定に基づいて判断を行う必要がある可能性がある。後続のステージおよびポリシは、それ自体の動作を判定するために、実行ステージを超える情報伝達または格納の任意の使用可能な安全にされた手段状態、変数、パラメータ、レジスタ、ファイルなどを介して前のステージから渡された情報を使用することができる。たとえば、より上のレイヤのアプリケーション認証機能は、以前にロードされたコンポーネントの完全性に関する情報を使用して、外部エンティティとの成功の認証に必要な鍵のリリースのゲーティングを含むそれ自体の動作を決定することができる。例示的なPIPE機能フローは、次のうちの1つまたは複数を含むことができる。RoTを検査することができ、その完全性を検証することができる。ベースラインTrEをRoTによって検査することができ、その完全性を検証することができる。TrE検査で障害がある場合には、ネットワークへのアタッチメントに必要な鍵のリリースを防ぐ、ネットワークへのアラームをトリガするアラームをネットワークに送信することを可能にすることができるフォールバックコードをロードすることができ、かつ/またはアラームが、TrEを置換するためのリモートバルク更新手順をトリガすることができる、またはデバイスをパワーダウンする、のうちの1つまたは複数を実施することができる。基本的な通信接続性コードをロードすることができ、このコードは、ベースラインオペレーティングシステムモジュールを検査し、ロードする、ベースライン管理クライアントを検査し、ロードする、または通信モジュールを検査し、ロードする、のうちの1つまたは複数を含むことができる。障害が発生する場合には、ネットワークへのアタッチメントに必要な鍵のリリースを防ぐ、アラームを介して、コンポーネントを置換するためのリモートバルク更新手順をトリガするアラームをネットワークに送信することを可能にすることができるフォールバックコードをロードすることができ、かつ/またはアラームが、基本コードを置換するためのリモートバルク更新手順をトリガすることができる、アラームおよびリモートコンポーネント更新手順を開始する、またはデバイスをパワーダウンする、のうちの1つまたは複数を実施することができる。残りのオペレーティングシステムおよび管理クライアントコンポーネントを検査し、ロードする。動的、再配置可能、および/もしくは再ロード可能な機能モジュールを検査し、ロードし、障害がある場合には、ネットワークへのアタッチメントに必要な鍵のリリースを防ぐ、傷害レポートをプロトコルでネットワークに送信する傷害レポートは、ネットワークによってリモートに更新できる障害を発生したコンポーネントを示すことができる、アラームを送信し、リモートコンポーネント更新手順を要求する、またはデバイスをパワーダウンする、のうちの1つまたは複数を実施することができる。PIPEのアクションは、成功して検証されたブートチェーンに依存して変化することができる。ブートプロセスの各ステージでは、その時にまたはその時までに完全性検査された基礎になるプラットフォームの部分または全体の査定された完全性および適用されるポリシに基づいて、判断を行うことができる。これらのポリシは、達成された信頼レベルに応じて、適合し、または新しいポリシによって置換されるものとすることができる。実行環境は、各ブートステージで制御するポリシに応じて変化することができる。後続のステージおよびポリシは、実行ステージを超える情報伝達または格納の使用可能な安全にされた手段状態、変数、パラメータ、レジスタ、ファイルなどを介して前のステージから渡された情報を使用することができる。PIPEポリシを、1つまたは複数のステークホルダによってプロビジョニングすることができる。例として、あるステークホルダが、ポリシのそれぞれへのアクセスを有することができ、各ステークホルダが、ポリシの一部へのアクセスを有することができるたとえば、優先順位レベルまたは特定の機能との関連付けに応じてなどである。もう1つの例として、製造業者は、低レベルコードポリシを制御することができ、オペレータは、ソフトウェアおよび構成のポリシを制御することができ、アプリケーションサービスプロバイダは、より上のレベルの機能モジュールを制御することができる。特徴および要素が、上で特定の組合せで説明されるが、当業者は、各特徴または要素を、単独でまたは他の特徴および要素とのさまざまな組合せで使用することができることを了解するであろう。さらに、本明細書で提供される方法を、コンピュータまたはプロセッサによる実行のためにコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアで実施することができる。コンピュータ可読媒体の例は、電気信号有線接続または無線接続を介して送信されるおよびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、読取り専用メモリROM、ランダムアクセスメモリRAM、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよびリムーバブルディスクなどの磁気媒体、光磁気媒体、ならびにCD-ROMディスクおよびディジタル多用途ディスクDVDなどの光学媒体を含むが、これに限定されない。ソフトウェアに関連するプロセッサを使用して、WTRU、UE、端末、基地局、RNC、または任意のホストコンピュータで使用されるラジオ周波数トランシーバを実施することができる。