JP2016012926A - 無線装置のプラットフォームの検証と管理 - Google Patents

Abstract

【課題】プラットフォームの検証および管理（ＰＶＭ：platform validation and management）を実施するための方法、コンポーネント、および装置を開示する。【解決手段】ＰＶＭの実施は、ホームノードＢ（home node-B）管理システムまたはコンポーネントなどの装置管理コンポーネントおよびシステムによって、プラットフォーム検証エンティティの機能とオペレーションに装置の遠隔管理を提供する。一例のＰＶＭオペレーションは、コア・ネットワークに対する接続性やアクセスを許容する前に、装置を安全なターゲット状態にする。【選択図】図５Ａ

Description

本願は、それらの全体が参照によって本明細書に組み込まれる、2009年3月6日に出願された米国特許仮出願第61/158,242号、2009年4月28日に出願された米国特許仮出願第61/173,457号、2009年6月30日に出願された米国特許仮出願第61/222,067号、および2009年8月21日に出願された米国特許仮出願第61/235,793号の利益を主張する。本出願は同時に出願された、発明の名称「Ｈ（ｅ）ＮＢの完全性の確認と立証のための方法と装置」の米国特許出願第12/718,572に関係しており、その全体が参照によって本明細書に組み込まれる。

本出願は通信に関する。

移動体通信の現存の技術あるいは標準化された技術は、装置の完全性を証明し確認するためのネットワークに関する方法を提供できていないことがある、あるいはそのような装置を管理し供給するための方法を提供できていないことがある。同様に、ネットワークにアタッチする必要がある装置は、自ら接続するネットワークが、実際に正当なあるいは信頼されたプロバイダネットワークであることを証明する能力を有していないことがある。

プラットフォームの検証および管理（ＰＶＭ：platform validation and management）を実施するための方法、コンポーネント、および装置を開示する。ＰＶＭの実施は、ホームノードＢ（home node-B）管理システムのような装置管理システムにより、装置の遠隔管理を用いてプラットフォーム検証エンティティの機能とオペレーション（運用）を提供する。一例のＰＶＭオペレーションは、コア・ネットワークに対して接続性やアクセスを許容する前において、装置を安全なターゲット状態にする。

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

信頼されたサブシステムのドメイン分離の一例を示すブロック図である。 プラットフォーム間のトラスト（信頼）が組織的で技術的な方法により仲介されることの一例を示すブロック図である。 拡張ホームノードＢ（Ｈ（ｅ）ＮＢ）を用いた半自律的な検証の一例を示すフローチャートである。 ４ステージの安全な起動の方法の一例を示すフロー図である。 プラットフォームの検証および管理（ＰＶＭ）用のエンティティとそれらの関係とインターフェースの一組の一例を示すブロック図である。 ＰＶＭ用のエンティティとそれらの関係とインターフェースの一組の一例を示す他のブロック図である。 プラットフォーム検証エンティティを用いる検証の一例の方法を示す信号ダイアグラムである。 プラットフォーム検証エンティティを用いる検証の一例の方法を示す信号ダイアグラムである。 プラットフォーム検証エンティティを用いる検証の一例の方法を示す信号ダイアグラムである。 Ｈ（ｅ）ＮＢの通信のシナリオの一例を示すブロック図である。 Ｈ（ｅ）ＮＢ内の「シン（thin；薄い、軽い）」トラステッド環境（ＴｒＥ）の一例を示すブロック図である。 間接装置接続の方法と図解の一例を示す図である。 直接装置接続の方法と図解の一例を示す図である。 セパレート認証（separate certificates）の処理手続の一例を示すフローチャートである。 完全性の確認の失敗に続いてフォールバック（fallback）コードベース（code base）により容易となる装置修正の検証の方法の一例を示す図である。 図１１Ａの方法に沿う一例のフローチャートである。 基準完全性メトリクス遮蔽ヘッダーのフォーマットの一例を示す図である。 仮想プラットフォームの設定登録値（configuration register value）を用いた検証の一例を示すフロー図である。 全ての半自律的な検証の間にコンポーネントをローディングする時のモジュールのヒエラルキーの一例を示す階層図である。 それぞれＰＶＭを提供し、実行し、実施するように構成された無線送信／受信装置と基地局の一例を示す機能ブロック図である。

本明細書では、用語「無線送信／受信装置（ＷＴＲＵ）」は、次のものに限定されるものではないが、ユーザ機器（ＵＥ）、移動局、固定あるいは移動加入者装置、ページャー、携帯電話、携帯情報端末（ＰＤＡ）、コンピュータ、あるいは無線環境で動作可能な他のタイプの装置を含む。また、用語「基地局」は、次のものに限定されるものではないが、ノードＢ（Ｎｏｄｅ−Ｂ）、サイトコントローラ、アクセスポイント（ＡＰ）、ゲートウェイ、加入者宅内機器（ＣＰＥ）、あるいは無線あるいは有線環境で動作可能な他のタイプのインターフェース装置を含む。また、用語「ＨＭＳ」は、次のものに限定されるものではないが、ホームノードＢ管理システム（ＨＭＳ）、拡張ホームノードＢ管理システム（ＨｅＭＳ）、ここで、これら２つはまとめてＨ（ｅ）ＭＳと称してもよい、装置管理システム（ＤＭＳ）、コンフィギュレーション・サーバ（ＣＳ：設定サーバ）、自動コンフィギュレーション・サーバ（ＡＣＳ）、あるいは「基地局」の設定あるいは機能性を管理する他のタイプのシステムを含む。用語「ＷＴＲＵ」と「基地局」は互いに排他的なものではない。例えば、ＷＴＲＵは拡張ホームノードＢ（Ｈ（ｅ）ＮＢ）であってもよい。また、用語「情報理論的安全性（information-theoretically secure）」は、完全に安全であること、無条件に安全であること、およびほぼ情報理論的に安全であることを含むが、これだけに限らない。以下に言及するとき、用語「トラスト（trust：信頼）」、「信頼された（trusted：信頼されている）」および「トラストワーシー（trustworthy：信頼できる）」は、それらのバリエーションと同様に、装置（ユニット）が特定のやり方で機能するかどうかの評価の定量化可能で観察可能な方法を示唆している。

プラットフォームの検証および管理（ＰＶＭ）の方法と装置を開示する。ＰＶＭは、ホームノードＢ管理システム（ＨＭＳ）のような装置管理システムによる装置の遠隔管理を伴うプラットフォーム検証エンティティ（ＰＶＥ）の機能性とオペレーションを提供する。ＰＶＭオペレーションは、コア・ネットワーク（ＣＮ）への接続性とアクセスが許容される前に、装置を安全なターゲット状態（secure target state）にする。

ＰＶＭオペレーションは、さまざまな異なる実施形態を、また色々な技術的文脈での多様な実施態様を自立的に同時に許容する。例えば、インターネット鍵交換（ＩＫＥ）のようなプロトコルのマッピングは、実施態様として記載する必要がある場合の特別な事例について提供されているが、本明細書で開示された全体の範囲内に制限され、あるいは限定されると解釈されるべきではない。ＰＶＭは、またＨ（ｅ）ＮＢが事例としていくつかの場所で用いられているが、Ｈ（ｅ）ＮＢに限定されるべきではない。ＰＶＭは、コンセプト（概念）を変えることなしに、また直接的な技術的適合により、マシーン対マシーン（Ｍ２Ｍ）や他の無線装置および／またはネットワーク装置に対して拡張する。

本明細書の記述は、当初からのアーキテクチャが、ＴＣＧ（Trusted Computing Group）により制定された技術標準（規格）、但しこれに限定はされないが、に関連するトラステッドコンピューティング技術（Trusted Computing technology）の最も中心的な考え方を利用することが可能であると見なしているという意味でトップダウンである。例えば、本明細書に記載された一実施形態は、ＰＶＭの全てのオペレーションと方法について基礎を築くための、トラステッド環境（ＴｒＥ）と参照整合性メトリックス（ＲＩＭ：Reference Integrity Metrics）によって実行されるセキュアスタートアップに依存している。このことは、より少ないトラステッド技術に基づく更なる変形の具現化を決して排除しない。他の実施形態はＰＶＭの色々なステージにおいてＲＩＭを用いるのを避けることができる。

一般に、ＰＶＭは技術的なシステムにおいてトラスト（安全）の統合定義（synthetic definition）にまとめられたトラストの概念を具現化し、ここでシステムにトラストを確立する手段が重要視される。ＰＶＭは、コアパラダイム（中心となる理論的枠組み）として責務（duty）の分散と分離を用いる。このことは、ノードが常に異種となり、もっとつかの間に接続するところで、通信ネットワークとインターネットを拡張させるために必要であるとして、拡張可能なトラストを許容する。

トラストについての以下の首尾一貫した操作説明（operational interpretation）は、ＰＶＭのような技術的システム間と、技術的システムと人間間での、関係と相互作用に対して適用され：「エンティティは、それが使用目的のために期待された方法で、予想された通りに、かつ顕著に運転する場合は、信頼されることができる」。操作説明は、３つの顕著な特徴、すなわち、予測可能性、観測可能性（可観測性）および状況依存性（contextuality：文脈性ともいう）を有する。

予測可能性は、ａ）そのシステムとの情報のやり取りで被るリスクを評価すること、およびｂ）観察上の推論により相互作用中のシステムについての知識が得られることに用いられうるシステムについて演繹的知識（先験的知識）を指定する。観測可能性は、システムについての知識が相互作用で得ることができる手段を定め、およびその範囲を定める。これは予測可能性と密接に関連付けられ、その観察において、予測とともに、システムの状態と将来の行動（動作）上の更なる知識をもたらす。状況依存性は、予測保留と観察をなし得るシステムと相互作用する範囲を線引きする情報を指定する。まとめると、それらはその信頼性の評価（アセスメント）を許容し、あるいは相互に、相互作用し合うエンティティに対してリスクが停止することを許容する。

運用のトラストを確立する手段を欠如していることを起因として、トラストと実施の間には概念上のギャップがある。このようなことは、クライアント・サーバ関係を超えて相互接続されたシステムの不均質性の増大にともなって、より顕在化されてきている。このような環境において、（安全）技術の最先端を考えると、実施や、トラストの運用ビューのいずれもが実現できていない。システムは、ａ）運用のトラストを確立するためのユビキタスな技術的手段と、ｂ）実施のための包括的なインフラストラクチャと、およびｃ）信頼性の情報と外部エンティティに対し適用できるセキュリティー・レベルとを伝達するため手段と、を欠いている。これらの基本的構成単位のみが、現実世界の要請を反映したトラストと実施の動的なバランス、すなわちシステムにおける拡張性の高いトラストを可能にすることができる。

ＰＶＭはまた本明細書に記載のビルディングブロック（基礎的要素）に基づいて構築される。トラステッドシステムのビルディングブロックは、そのトラストの境界を確立し、時にはその境界を拡張する方法を提供し、また外部エンティティにトラストを伝達することで、ある程度までその動作と運用を予測可能および観測可能にする。ビルディングブロックは、（ハードウェア）セキュリティアンカー、信頼のルーツ（ＲｏＴ：Roots of Trust）、トラステッド（サブ）システムとオーナーシップ（所有権）、安全な記憶とパス（経路）、承認、認証されたセキュアブートプロセス、およびアテステーション（attestation）とを含むことができる。これらの方法を組み合わせることによって、システムやさまざまコンポーネントは、多方面にわたるやり方でトラストと実施の特性を連結して構築することができ、それゆえこれらの２つの極（pole）間の技術をスケーリング（拡大縮小）することを可能にする。基本的な機能ビルディングブロックは以下に記述する。

ハードウェアセキュリティアンカーは、システム動作の保護にとって重要である。これは、システムに対する攻撃のリスクを効果的に和らげる意図された目的を十分に保護するための公知のハードウェア手段により、不正アクセス（unauthorized access）に対して防御するシステムの一部である。それは、特に、その安全運用（secure operation）についてのＲｏＴを保持する。ＲｏＴは、ａ）内部システムオペレーションのセキュリティと、およびｂ）安全で正式な方法で外部エンティティに対するシステムの（個別に、あるいは作成とモデル（make and model）のようなグループのメンバーとして）属性および／またはアイデンティティ（身分証明）の公開とを可能にする抽象システム構成要素である。

システムは別々の目的のために２つ以上のＲｏＴを含むことがある。ＲｏＴの事例は、それらについての信頼されたサードパーティのデジタル証明書と一緒での非対称暗号鍵の対（ペアー）である。また、セルラーネットワーク（携帯電話ネットワーク）での加入者識別モジュール（ＳＩＭ）カードは、ＳＩＭ（シム）カードにより具現された閉鎖的なトラステッドシステム用のＲｏＴと見なすことができる。

第２に、信頼されるべき、すなわち意図された目的のための明確な方法で動作すると考えられている、システムの機能ビルディングブロックは、システムのＴＣＢ（Trusted Computing Base）を形成する。ＴＣＢは、テストと認証に準拠し一致するような帯域外のプロセスによってのみ、現場で、かつ運用期間にシステムが展開される場合に、それらの運用安全属性について調べることのできないシステムのそのようなコンポーネント（構成要素）で構成されている。このような認証は、通常、例えば、ＴＣＢの特定の技術要素、あるいは全体としてＴＣＢの製造業者（manufacturer）のために、確定の機密保護評価規格（標準）に従って、独立の評価器（evaluator）、により遂行される。有用なこのような認証のために、ＴＣＢでは、それぞれ、その要素がそのように認定された技術の断片としてそれらを識別する情報で与えられるべきである。

定義済みのセキュリティアンカー、ＲｏＴ、およびＴＣＢを装備しているシステムは、トラステッドシステム（ＴＳ）と呼ばれる。これはトラステッドプラットフォームの共通概念の軽度の改良版であり、トラステッドプラットフォームは、「ソフトウェアプロセスについての信頼の基盤を作るのに用いる、たぶん内蔵ハードウェアの形での、トラステッドコンポーネントを有しているコンピュータプラットフォーム」である。あるＴＳ内に１つまたは２つ以上のトラステッドシステムが存在している場合は、それらはトラステッドサブシステム（ＴＳＳ）と呼ばれる。事例は、ホストのトラステッドプラットフォームモジュールハードウェア（ＴＰＭ）からの一定の信頼性を継承する、パーソナルコンピュータプラットフォーム上の仮想実行環境を含む。他の事例は、そのＴＣＢと組んだトラステッドエンジンの仕様である。下記において、「ＴＳ」は、別に明示的に述べていない場合には、「ＴＳまたはＴＳＳ」に対して簡略表現のように代替して用いている。ＴＳは、図１に示されているようなさまざまな装置に実装することができる。

以下では、ＴＳのトラステッドリソース（ＴＲ）の元でまとめられた、さまざまな機能、プロセス、およびアーキテクチャ構成要素が開示される。ＴＲの２つの種類は、一般的に、１）ＴＣＢに属するＴＲと、２）ＴＣＢの外部にあるＴＲとに、区別されるべきものである。後者の例は、オペレーティングシステム（基本ソフト）の信頼された部分とその機能を用いることによりＴＣＢを立ち上げる信頼されたアプリケーションである。ＴＣＢにおけるＴＲの信頼性についてのアサーション（判定）がＴＣＢの定義済みの安全に依存していると同時に、他のＴＲの信頼性は、多くとも、ＴＣＢのそれから導き出すことができる。このような場合には、ＴＣＢはトラスト境界（信頼の境目）、すなわち、ＴＣＢの外部のＴＲに対して所与のコンテクスト（文脈、前後関係）において信頼できると見なされる、例えば信頼できると証明され、あるいは下記のように安全に起動する、ＴＳの全体の構成要素の拡張を許容する特定の内部ＴＲを備えなければならない。ＴＣＢ内のＴＲはしばしば、例えば、同一の耐タンパ性（改ざん防止）チップ上に存在する、同じハードウェア保護をＲｏＴと共有する。ＴＣＢの外部のＴＲは、ソフトウェアの論理ユニット（論理装置）として実現できる。ＴＣＢの外部にあるＴＲを含むトラスト境界は、一時的に可能なものということに留意されたい。それらはいくつかの目的のためにしばらく存在することができ、およびその後に消滅することができる。

ＴＣＢを越えるトラスト境界を拡張するためのプロセスの一般的なモデルは、確認verification)である。これは確認プロセスを実行するＴＲ自身である。これは、外部エンティティ、すなわち、バリデータ（validator）によってＴＳの検証（validation）のプロセスからそれを区別するための、確認プロセスや対応するＴＲ確認エンティティ、あるいはベリファイア（verifier）として識別される。プロセスとしての確認は、少なくとも２つの異なる形態で入ってくることができるトラスト境界における新たなコンポーネントを含む。まず、ベリファイアがその初期設定のときに新たなコンポーネントを測定する。すなわち、そのコンポーネント、その状態および設定は一意的に識別される。その測定結果は次に格納される。この拡張として、ベリファイアは、その測定値と基準値とを比較してトラスト境界を延長するか否かを決定してもよい。すなわち、ベリファイアは方針決定を行い執行してもよい。運用の観点から、確認は、それが確認プロセス完了後の一定の、所定の状態であると考えられるとして、ＴＳの予測可能性に相当する。他方では、検証は、その特性を観測可能にし、その結果、信頼性を作り出す。報告エンティティは、別のパーティに確認結果を移動させることを意味する。第３に、報告エンティティにより実行される中間ステップはアテステーションのステップである。アテステーションは、確認の論理結果と検証についての論理前提条件である。それは、測定情報の正確さについての保証のプロセスであり、信頼するパーティであるバリデータは、自身が遠隔のＴＳを信頼するか否かを決定するのにそれを用いることができる。確認、アテステーションおよび検証は、ＴＳのライフサイクルに関係する運用トラストについてのコアコンセプトである。

ＴＳは、トラスト境界内の一定のＴＲ、例えばＲｏＴにアクセスするのを認可されたエンティティ（人あるいは他の技術的システム）に所有されている。所有権はＴＳの物理的占有、すなわちそれを含むプラットフォームにより暗に、または明示的に、例えば一定の認証情報を介しての所有者の認証により実現されてもよい。トラステッドコンピューティンググループ（ＴＣＧ）のトラステッドプラットフォームモジュール（ＴＰＭ）の仕様のコンテキストにおいて、このような認証データの提供は、所有権の取得と呼ばれる。ＴＳと直接互いに影響し合う所有者はローカルオーナーと呼ばれる一方で、ＴＳと相互作用する所有者が多少なりとも例えば通信ネットワークを介して取り次がれる場合はリモートオーナーと呼ばれる。２以上のＴＳＳが１つのＴＳ内に含まれている場合は、それぞれが異なるオーナーを有してもよいし、同一のオーナーを有してもよい。

図１はいくつかのＴＳＳ１１０、１３０、１５０および１７０のコンピューティングドメイン（計算対象領域）の区分を示す。ＴＳＳ１１０、１３０、１５０および１７０はそれぞれ個別に専用のモバイルトラステッドモジュール（ＭＴＭ）１１２、１３２、１５２および１７２から構成されている。モバイルホーンワークグループ（ＭＰＷＧ：Mobile Phone Work Group）仕様のハードウェアセキュリティアンカーは、記載したＲｏＴ、ＴＲ（トラステッドリソース１１４、１３４、１５４および１７４）とトラステッドサービス１１６、１３６、１５６および１７６を含む。標準のソフトウェアサービスとコンポーネント１１８、１３８、１５８および１７８は、それぞれトラスト境界１２０、１４０、１６０および１８０の外部にある。それらの全てにある、それぞれの所謂トラステッドエンジン１２２、１４２、１６２および１８２は、特にそれぞれの異なるＴＳＳ１１０、１３０、１５０および１７０の区分および制御された通信を与えるＲｏＴに基づく、安全なコンピューティング環境である。ＴＳＳは、インタードメイン検証（ドメイン間検証）と認証により条件つけられた、それらＴＲと他のＴＳＳとともにＭＴＭの機能さえも共有することができる。トラステッドエンジンは、ただしＭＴＭの一部もまた、ＲｏＴで保護される少なくとも１つのハードウェアが存在する限りは、ソフトウェアで実現することができ、そのハードウェアからＭＴＭに基づくソフトウェアのＲｏＴが抽出される。各ＴＳＳはローカルあるいはリモートの利害関係者あるいは所有者の制御下にあってよい。モバイル機器のライフサイクルにおいて、すべて利害関係者のＴＳＳが現存するとは限らず、またプロセスが存在するとは限らないし、そのライフサイクルにおいて、（リモートの）利害関係者が新たなＴＳＳの構築を初期化しその所有権を得ることも可能である。

ＰＶＭは、ある程度、トラスト（信頼）の構築に基づいている。トラストと実施間の、主要なブリッジコンセプト（関連基本構想）はタスクの分離である。タスクの分離は、実施上のタスクに帰すると通常は理解されている。しかし、トラストに対する自然の関係がある。信頼するパーティ（当事者）は、他のシステムが操作上信頼に足る場合はその他のシステムに対して実施を委任することができる。ＴＳ間の操作上のトラストの構築は可観測および予測可能性の予めの設立を可能にするため情報の制御交換に依存している。後者はＴＳの外側のみで行うことができる。

図２は、ＴＳ２００、２０２に対して組織的な保証を提供する外部エンティティの役割を提示する例示的モデルを示す。ＴＳ２００、２０２は、トラスト境界２７０、２７２の外部にある標準的なアプリケーション２６０、２６２を含む。トラスト境界２７０、２７２の内側は、ＲｏＴ２０８、２１０とＴＲ２１２、２１４を順番に含むＴＣＢ２１６、２１８である。トラスト境界２７０、２７２は、信頼されたオペレーティングシステム２３０、２３２、あるいは保護を必要とするその部分、および信頼されたアプリケーション２３４、２３６をさらに含むことができる。

ＴＳ２００、２０２のセキュリティ特性は、ハードウェアトラストアンカー２０４、２０６およびＲｏＴ２０８、２１０に根差している。これらの技術的コンポーネント（構成要素）は、システムが配置され、運転中の間は検査を受けることができない。それ故、それらは設計と開発の期間に機密保護評価（security evaluation）を受ける。これは独立機関（independent authority）より実行されるが、この独立機関は、成功した評価のときに、セキュリティの重要な要素の製造者に対してセキュリティの証明書を発行する。

ＲｏＴ２０８、２１０とトラストアンカー２０４、２０６以外に、セキュリティプロセス（機密保護処理）はＴＣＢ２１６、２１８内の他のＴＲ２１２、２１４も含んでもよく、また異なる認証機関（certification authorities）２２０、２２２を含んでもよい。評価プロセスと異なる認証機関の均質な品質を保証するために、それらは認定機関２２４により交代で評価され認定されるが、その認定機関は、例えば、国家の許可証を持つ半民半官の、あるいは民間の団体であってもよい。認定機関２２４は、認証機関２２０、２２２間の関連情報（ブリッジ情報）を提供する働きをすることもできる。

認証機関２２０、２２２あるいはそれらにより報告を受けた技術団体は、ＴＲ２１２、２１４により使用されるＴＳ２００、２０２に対して証明書２２６、２２８を発行する。これらの証明書２２６、２２８は、それらがそれらの完全性と出所について検証できるという意味で認証される。主要例は、プラットフォーム証明書および他のコンポーネント（構成要素）の証明書と同様に、その製造者によりＴＰＭの主ＲｏＴ（ＥＫ）宛に発行されたエンドースメントキー（ＥＫ：Endorsement Key）の証明書である。暗号化手段によりそれらから導出される証明書と機密は、その後、外部エンティティ、とりわけ他のＴＳとのインタラクション（相互作用）にも使用される。ＴＳ２００、２０２の検証２４０は、通常認証を、また多くの場合、機密保持も必要とする。さらに、ＴＳ証明書から受け継ぐトラスト（信頼）をもつシークレットと証明書は、セキュリティアソシエーション２４２、２４４をそれぞれ構築するためのオペレーティングシステム２３０、２３２とトラステッドアプリケーション２３４、２３６に不可欠であり、すなわち、認証、機密保持、および通信の完全性を提供するチャネルに対して不可欠である。セキュリティアソシエーション２４２、２４４の上部の、拡張されたトラスト境界内のアプリケーションは、明確な運用トラスト特性で安全な通信チャネルを構築することができる。

仲介エンティティ２５０は、図２に示された色々なインタラクション間の信頼構築を促進する。プライバシー認証機関（ＰＣＡ：Privacy Certification Authority）は、仲介エンティティ２５０の一例である。仲介エンティティ２５０は、他のＴＳあるいは依拠当事者（relying party：証明書を利用する主体）にＴＳの信頼性について基本的なステートメント（声明）を発行する。仲介エンティティは、ＴＣＢ２１６、２１８、または選択された要素、例えば、信頼され認定されたコンポーネントのようなトラストアンカー２０４、２０６を確認する。この目的を達するために、仲介エンティティ２５０は、認証エンティティより発行された証明書を知る必要があり、ＴＳからその証明書を受信したときにそれらをベリファイし、依拠当事者に保証ステートメントを発行する必要がある。仲介エンティティ２５０は、公開鍵基盤（ＰＫＩ）の認証機関（ＣＡ）と同様に、その後のセキュリティアソシエーションと秘密通信を円滑にすることができる。

ＰＶＭに必要であるような信頼構築の基本的要素はここに記載される。

確認は、基本的に、所望の精度でＴＳの状態変化を記録し、制御することである。このような事情のため、ＴＳが存在しているプラットフォームの運用サイクル、つまり初期化からシャットダウンまでに強固に拘束され得る。従って、実用的な確認方法は、ブート処理（boot process）と、ＷＴＲＵのような物理装置の１つ以上のプロセッサ（処理装置）により使用されるプラットフォームの運用サイクルと、ほとんど一体化される。

ＴＳの内部確認の一つの方法は、認証済みブートであり、ＴＣＢの機能を用いて、ＴＳが初期化された時点で、例えば、ＷＴＲＵを電源投入したときのロード（取り込み）あるいは開始ソフトウェアあるいはハードウェアコンポーネントの信頼性を評価する。認証済みブートは、ＴＳの他の部分を開始する前に、ＲｏＴおよびＴＣＢの特定の機能を開始することにより実現される。これらの部分はＲＴＭ（RoT for Measurement：測定の信頼基点）として動作する。このことは、開始しあるいはその後にロードされたコンポーネントが測定されることを意味し、すなわち、例えばハードウェアコンポーネントの埋め込みコードとロード済みプログラムの（２進）表示を超える暗号ダイジェスト値（例えば暗号ハッシュ値）を形成することにより、開始が一意的に確認されたあと、それら、およびそれらの状態と設定が測定されることを意味する。規定の要求に従って、その測定値を保証格納領域（secure storage）に格納してもよい。それらから、例えば、ソフトウェア名とバージョンから、システム状態を見直すのに必要なデータとともに、それらはＴＳの格納測定ログ（ＳＭＬ）を形成する。ＰＣプラットフォーム上に、認証済みブートは、ＢＩＯＳからオペレーションシステム（ＯＳ）ローダーおよびＯＳ自身までの全てのコンポーネントを含んでもよい。

認証済みブートの一例において、システム状態は、測定値を受信し、ハッシュ値を用いて状態の一意表現（unique representation）を計算する、主管担当部門としてのＴＰＭを用いて報告プロセスにより測定される。説明の目的上、１）ＴＰＭは、アプリケーションまたはファイルのハッシュ値、すなわち、外部（ソフトウェア）実装により算出された、アプリケーションの測定値を受信してもよく、あるいは、２）ＴＰＭは、ハッシュ値、すなわち内部ハッシュアルゴリズム実装を用いて測定値を計算してもよいとする。このために、ＴＰＭはいくつかの保護されたプラットフォーム構成レジスタ（ＰＣＲ：特殊な更新操作でのみ書き換え可能な記憶領域）を有している。パワーアップ（出力上昇）時のシステム初期化を発端に、各ロード済みの、あるいは開始されたコンポーネントについての、測定値、例えばＢＩＯＳを通してのハッシュ値は、ＲＴＭを用いて、ＴＰＭへ報告され、ＳＭＬ内に安全に格納される。同時に、アクティブ（アクセスできる状態の）ＰＣＲは、拡張プロシージャ（手続）により更新されるが、このことは、測定値が現在のＰＣＲ値に追加され、ダイジェスト値がこのデータで建て直され、ＰＣＲに格納されることを意味する。このようにして、信頼の過渡的な鎖が、全ての開始された、およびロードされたコンポーネントを包含して構築される。単一のＰＣＲがたった１つの値のみ格納する場合には、「フットプリントのような」完全性検証データを提供することだけができる。この値は、ＳＭＬと連動してのみ、このフットプリントを計算し直すことにより、この信頼の鎖をベリファイ（検証）することをバリデータ（validator）に許容する。

セキュアブート（secure boot）は、認証済みブートの拡張（発展型）である。これは、いくぶんスタンドアロン（独立型）でオフライン機能の必要条件を必然的に有する、セットトップボックスや携帯電話機（携帯用ハンドセット）のような装置にとっては特に重要である。セキュアブートを備えている装置の共通の特徴は、例えばネットワークにアクセスする前のように、それら装置が自身の信頼性のアサーション（表明）を外部へ通信できないときに、それら装置は状態が信頼できるセットにおいて動作しなければならないことである。セキュアブートにおいて、ＴＳはローカルベリファイア（確認エンティティ）およびブートプロセスを監督するローカルエンフォーサ（local enforcer）を備えており、セキュアブートプロセスを制御するためにポリシー施行点（ＰＥＰ：Policy Enforcement Point）およびポリシー決定点（ＰＤＰ：Policy Decision Point）の組み合わせを確立する。ローカルベリファイア（local verifier）は、新たにロードされ、または開始されたコーポネントの測定値と、ＴＣＢ内に存在するか、あるいはＴＲによってＴＳ内に保護されている、例えば保護記憶領域にある、信頼された参照値（ＴＲＶ：Trusted Reference Value）とを比較し、かつそれらコンポーネントがロードされたか、開始されたか、あるいは開始されていないかを判定する。このようにして、システムは、定義済みの、信頼できる状態にブートすることを保証される。

信頼された参照データは、検証データと既知の正常な値（known good value）とを比較するために用いられるデータである。信頼された参照データを構成するそれらの値は、信頼された参照値（ＴＲＶ）と呼ばれる。それらの最もよく知られた例として、ＴＣＧのＭＰＷＧ規格に仕様を定められているような、参照整合性メトリック（測定基準）（ＲＩＭ）が挙げられる。それらは、真に、a）その測定値がＴＲＶに適合するコンポーネントのみが開始されるということを確実にするために、セキュア起動時にプラットフォーム自身により、あるいは、b）バリデータにより用いられ、検証データと既知の正常な値とを比較して、それにより検証時のプラットフォーム状態を評価する。用語ＲＩＭは、信頼された参照データの限定されない例として本明細書本文で用いられてよい。

そういう次第なので、信頼された参照データは、そのデータについての一定の安全声明（security assertion）を通じて信頼されることになり、その声明は該当のＴＲＶを用いてバリデータあるいはエージェントによりベリファイでき得る。このようにベリファイできるアサーション（声明）は、例えば所謂ＲＩＭ証明書を生み出す、信頼された第三者機関（ＴＴＰ）により発行されたデジタル証明書により現に実現されることができる。信頼された参照データの信頼声明は、たとえば、コンポーネントあるいはプラットフォームの（例えば、共通基準の評価保証レベル、ＥＡＬに従う）外部評価についての一定の追加情報も含んでもよい。

ＴＲＶの二重様相（dual aspect）に留意することは重要である。一方においては、それらはセキュアブートプロセスにおいてローカル確認を果たす。それらは、許容するＴＲＶプロビジョニング基盤により補完されているので、例えば、更新したソフトウェアに対応する新規のＴＲＶをＴＳに提供することにより、測定したコンポーネントの更新をする。セキュアブートの後でＴＳを検証する外部エンティティのために、受信した検証データ、例えばＴＲＶに格納されている所謂事象（イベント）構造を比較し、関連するＴＲＶ証明書を確認する必要がある。従って、ＴＲＶと、一致した証明書は、結果の確認時ばかりでなく、仕様の検証時にも、重要な役目を行う。

アテステーション情報の新鮮さは検証についての重要な論点である。このことは、確認プロセスをブートからＴＳの動作時間（オペレーションタイム）へ拡張することを必要とするものであり、この拡張は複合オープンシステムにおいて技術的に困難な仕事である。

記載されたデューティ（責務）の分離はＴＳを検証する（validating）プロセス上でもまた存在している。すなわち、確認の結果に基づいて、システムの信頼性は、評価されてよく、また検証を作りだすことのできるポリシー判断（policy decision）に従って評価されてもよい。ＴＳとバリデータ間のこのプロセスにおけるタスクの分離は、検証の３つのカテゴリ（分類上の区分）につながる。どんな種類の検証に関しても必要な共通基本コンセプト（概念）をここにまず記載する。

ＴＳの検証プロセスは、バリデータに対して提示される検証アイデンティティ（本人証明）によりサポート（支援）されなければならない。検証アイデンティティは、ＲｏＴ、すなわち、報告用の信頼ルート（ＲＴＲ：RoT for Reporting）から直接的にまたは間接的に生じなければならない。検証はメディエイター（仲介者）なしではあり得ないかもしれない。この検証アイデンティティの提供者（プロバイダ）は、検証アイデンティティの所有者がＴＳであると断言するためのタスクを有する。検証アイデンティティの提供はアイデンティティ管理（ＩｄＭ）システムにおけるアイデンティティ提供の拡張である。提供者は、ＴＣＢ内のＴＲの一部あるいは全部を含むＴＳの信用証明書（credentials）についてチェック（照査）を行う必要があり、ＴＳが検証のために信頼できる状態であるかを評価する。さらに、検証アイデンティティの提供はセキュアプロセス、例えば専用のセキュアチャネル上でのセキュリティ（機密保持）プロトコルで行われなければならない。遠隔の検証の場合では、検証アイデンティティが、ＴＳのグローバルアイデンティティと一致してもよい。

一意的な永続的検証アイデンティティを用いた検証は、セキュリティに関して重要である。検証は、さまざまな目的のために沢山のバリデータに対して高い頻度で、また無差別に、起きてよい。用いられた検証アイデンティティが、それぞれユーザのアイデンティティと簡単に関係があるのではないにしても、それらはＴＳの行動の追跡をおおむね許容する。ＴＳのグループあるいは全てのＴＳについての同一の検証アイデンティティを用いることは、機密保持の理由により、これを解決するためのオプション（選択肢）ではない。そのようなグループアイデンティは、単一攻撃点／単一障害点（single point of attack/failure）となるであろう、すなわち、そのグループの１つのＴＳが信用できなくなったとすると、その後は他の全てのＴＳも、もはや同様に検証を行うことができない。他の選択肢は、事例としての、それぞれのブートサイクルごとに、または確定周波数で、または各検証についてＲＴＲにより、生成された一時的検証アイデンティティを使用することである。

自律的検証は、ＴＳの検証は完全に局所で、すなわち装置自身の領域内で、すなわち外部のエンティティに依存しない方法で、実行されなければならないという前提に基づいて、外部バリデータによるＴＳの検証が暗黙のうちに行われるプロシージャ（手続）である。この際、成功する検証は、ＴＳが外部操作あるいは他の操作を用いてさらに通信を試みることを可能にする前に、起るものと考えられる。従って、検証プロセスは、検証の直接証拠が外部へ提供されないけれども、この場合に完全に保証されると考えられる。その仕様が定められ実行されるＴＳの方法に起因して、確認を失敗するＴＳは、そのＴＣＢにより外部へ見える他のタスク、例えば、ネットワークへそれ自身をアタッチすること、あるいは遠隔エンティティへの認証連結を取得すること、の実行を禁じられることとなると、外部は推測することとなるであろう。自律的検証（autonomous validation）はＴＳの全ての施行任務を築く。

自律的検証は、本質的にスマートカード（メモリ内蔵カード）に用いられるトラストモデルである、閉じた、不変のシステムモデルをＴＳに適用する。ＴＳはＴＣＢを用いてＴＳ自身をベリファイ（検証）するが、その結果は「成功」または「失敗」の２値である。検証は、従って暗黙のプロセスであり、その暗黙のプロセスによってＴＳはネットワークアタッチメントのような外部との特定の対話を許容する。代表的実施例は、スマートカードによる、認証シークレット、例えば、暗号鍵の解放（リリース）である。

装置上でのみ存在するセキュリティは、これまでに壊されており、例えば、モバイル機器がコンピュータプラットフォームになるにつれて、壊されやすい。ＴＳが部分的に信用できなくなり、外部がその状態について何らかの知見を得ることができないときに、自律的検証は高度なセキュリティ要求のための情報をほとんど配布できない。不正な装置（rogue device）のラベリング（標識化、標示付け）はしたがって不可能であり、セキュリティ上の弱点を突く手段（exploit）は、気が付かれることなしに急増するはずであり、それが阻止されることが可能となる前に、ネットワークオペレータのような他の利害関係者に対して顕著なダメージを引き起こす。ベリフィケーションが特定の条件に対して反応する、例えば障害ポリジーに依存して、特定の機能を許可しないことにより、あるいは装置を閉じて再起動を行うというような方法で、自律的検証は実現可能である。このことはネットワーク接続を回避し、有利であるように見える。しかし、これはＤｏＳ（denial-of service）攻撃に関するベクター（運び屋）でもある。装置は、改ざんされた状態（compromised state）でネットワークにアタッチしてはならないし、また、従って、安全状態へ復帰するチャンスはほとんどない。遠隔管理（リモート管理）はまた困難である；特に不正な装置に対して価値あるもの（ソフトウェア、秘密）を配信する可能性があるので、ソフトウェアのダウンロードと実行とでセキュリティを失う可能性がある。従って、自律的検証は帯域外のメンテナンス（保守）を必要とする傾向がある。例えば、ＴＲのソフトウェアの更新の失敗は、ネットワーク接続が不可能となる状態につながる可能性がある。

自律的検証を用いて、認証データの新鮮さは、それ自身が保証されるものではない。実行されるべきこのセキュリティプロパティ（属性）のために、自律的検証は色々なシステム状態の変更時に自律的に開始されなければならない。自律的検証は実際にはまれに起るものとすると、例えばネットワークのアタッチメント中で、ＴＳの運用中にバリデータにより知覚できない形で、ＴＳ状態は大きく変化する可能性がある。従って、アッタカー（攻撃者）はこの間隙（ギャップ）を利用して、例えば、悪意のあるソフトウェアを導入できる。自律的検証はこの種のタイミング攻撃（timing attack）を極めて受けやすい。

遠隔検証において、バリデータは、自身が受信する、確認に係る証拠に基づいてＴＳの妥当性（バリディティ）を直接評価する。確認はこの事例では受動的だけであり、完全ＳＭＬがバリデータへ伝達されねばならない。このためのモデルケースは、認証されたブートによる確認であり、それに続く検証である。全てのポリシーの決定はバリデータ次第である。

検証技術に関する技術の現状は、リモート検証であり、とりわけＴＣＧリモート認証（attestation）である。リモート認証において、ＴＣＧトラステッドプラットフォームは、認証識別キー（ＡＩＫ）により署名された、ＳＭＬとＰＣＲ、リモート認証の検証データおよび確認データを、外部のバリデータに対して提示する。ＡＩＫは、検証アイデンティティプロバイダーとして働くＰＣＡにより認証された短命な一対の非対称暗号鍵である。リモート認証で提供されるハンドルネーム（pseudonym）は全ての場合で満足するものではないであろう。ＴＣＧはゼロ知識証明（zero-knowledge proof）に基づいた直接匿名認証（ＤＡＡ：Direct Anonymous Attestation）を追加定義する。

リモートと自律の両方の検証は、準自律的検証に組み込まれたオプション（選択肢）の周波数帯の極限であるため、リモート検証は不利点も有する。リモート認証により表されたものとしてのリモート検証は、拡張性と複雑性に関する実際上の問題、それがネットワークまたはサービスに対しての（中央）アクセスポイント上の検証に関する全ての計算負荷に重なるものとして、問題を引き起こす。特に、ＳＭＬの検証は、幾多のバージョンと設定での沢山のソフトウェアとハードウェア部品を持つパーソナルコンピュータのようなプラットフォームに対して非常にコスト高となる可能性がある。これはまた、利害関係者にＴＳの所望の目標設定を定めさせるために、インフラストラクチャと共に、ＲＩＭのようなＴＲＶの非常に大量のデータベースを必要とする。同様な議論が、ＴＳのリモート管理、すなわち、リモート検証に伴う、制御されかつ有効な設定の変更、非実用的なことについてなされる。更に、ランタイム（実行時間）確認は、ブート（起動）がバリデータに対して提示された後の場合を除くほか、リモート検証と一体になるのが望ましい。ＳＭＬは検証に際して「枯れている（withered）」ことが可能である。従って、ランタイム確認は、もしそれがリモート検証を非常に頻繁に起させる必要があるであろう、検証により直接的に付随されるものでない場合には、無意味なものとなる。最終的に、複雑なオープンＴＳのリモート検証は、顕示化したＳＭＬがＴＳに対してほとんど唯一のものであるであろうから、ＰＣＡの使用にもかかわらず、プライバシー（個人の秘密）を危険にさらす。同様の、実用的な議論はリモート認証による識別の可能性に関するものである、すなわち、他のプログラムのユーザに対して、それらのサービスアクセス、あるいは無規律なサービスアクセスに切り替えさせることで、主要なベンダー（供給メーカー）のソフトウェアの最新バージョンのみがＲＩＭデータベースのようなＴＰＶデータベースに入るという脅威である。いくつかの不利益は、具体的な実装よりもむしろコンポーネントの特性を表示することを目標とする、意味論的認証あるいは特性に基づく認証のような、リモート認証の洗練された形態によって軽減されることができる。

準自律的検証は、外部のエンティティに依存することなしに、それ自身の範囲内で装置上の局所的な確認の期間においてＴＳの妥当性が評価される場合の、もう一つの手続き（プロシージャ）であり、ポリシーの決定は確認の期間で行われる。しかし、この事例では、ここでは「検証メッセージ」と称する、確認の結果と所要の証拠のような、特定の情報が、バリデータに信号伝達され、バリデータがＴＳからの検証メッセージの内容に基づいて決定することができる。ＴＳからバリデータへのシグナリング（信号伝達）は、必要に応じて、認証、完全性および秘密性を提供するように、保護されなければならない。準自律的検証のモデルケースは、バリデータに対する、ＲＩＭのような、ＴＲＶのイベント構造およびインジケーションのシグナリングが続く、安全な起動（secure boot）である。準自律的検証は、ＴＳとバリデータ間に確認と施行タスクを配信する。具体的に言うと、安全な起動において、前者はコンポーネントのロードタイムで決定を行い、一方、後者は、与えられた状態証拠に基づいて、検証時に、許容された対話の決定をＴＳにさせることができる。

準自律的検証は他の２つのオプション（任意選択）を通じて利点を提供できる。これは、確認で用いられたＲＩＭのインジケータ（指標）の形式でさらに効率よく検証情報を潜在的に運ぶことができる。これは、例えば、インジケーション（指示）が一群のコンポーネントを（バージョンのような）同一の機能性と信頼性で指定するような場合に、プライバシー（個人の秘密）を保護するために使用できる。このことは、語義的で特性に基づく認証と似ており、また準自律的検証はリモート検証の記述された拡張形態で結合されることができる。バリデータ側の確認における実行の相互作用は、ＴＳのリモート管理用のオプションも提供する。

技術的に実用的な修正（remediation）の道を歩むことで、“完全性確認の失敗が原因でネットワークアクセス許可を得る目的を達成できないＡＲ（アクセスリクエスタ）の隔離と修正のためのサポート”を得ることが利用可能となる。このことは、原則として、承認のための現在のポリシーによって規定されているような、全ての完全性関連情報（integrity-related information）の最新の状態にＡＲを至らせることを許容する。例示はＯＳパッチ（patch）、アンチウイルス（ＡＶ）最新版、ファームウェアアップグレード（版）および他の同様なソフトウェア、あるいはファームウェア最新版を含む。リモート管理の実用化のための具体的なコンセプトは、ＰＶＭについてこの明細書で記載されているような、ＲＩＭ情報のような、効果的な表明とＴＲＶ情報の通信についての基盤（インフラ）に依存しなければならないであろう。

準自律的検証のＲＩＭ認証により行われる役割を重視することは重要である。ＲＩＭ認証は、直接的に、あるいは委任によって、対応するＴＲを評価する認証機関により提供される。認証の方法と機構は、多種多様であってよく、運用信頼性の異なるレベルに導くことができる。これは、ＴＳ上のよりきめ細かい情報を獲得する準自律バリデータに関して更なる柔軟性に導く。ここで述べたように、ＲＩＭ認証は、例えばコンポーネントのオンデバイス（on-device）検証をサポートすることができるデータとして用いられる。ＳＡＶ方法をベースとしたＲＩＭ認証がここでは記述されているけれども、他のＳＡＶバリエーション（変形）を使用してもよい。

準自律的検証は、ａ）自律的検証を行うための処理能力を欠き、またｂ）リモート検証に必要な豊富なレポート作成を実行するための記憶能力及び／通信能力を欠いている、リソース制限されたシステムにとっての唯一の実用的な検証のオプションである。例えば、ワイヤレスセンサネットワークの状況で、両方の制限事項はセンサーノードについて保持しているであろう。こうした環境の下で、一つのアプローチは、検証のために基地局へ戻される予見可能な結果へ導くスタティック記憶内容（コードとパラメータ）のダイジェスト値を算出するセンサへメモリのプロービングコード（probing code）を送ることである。攻撃者は、正しい結果を生ずる、保存された、原記憶内容を用いることで、この「認証」を回避することを明らかに試みることもあり得た。この攻撃がセンサ自身上で実行される限りは、ランダム化、自己書き換えプロービング（probing：探査）ルーチン、および難読化の方法（obfuscation method）によって増加する可能性のある遅延を必然的に引き起こすこととなる。従って、センサの解決策で顕著な遅延が一定の閾値越えた場合は、そのセンサは無効とする。

準自律的検証において、Ｈ（ｅ）ＮＢの妥当性は、安全な立ち上げ期間において、外部エンティティに頼ることなしに内部で評価され、ポリシーの決定は、特にそれらの測定された完全性に基づいて、コンポーネントをロード／開始する、あるいはしない、との評価をする間に行われる。準自律的検証において、評価の結果と必要な証拠は、プラットフォーム検証エンティティ（ＰＶＥ）へ信号伝達され、ＰＶＥは検証メッセージの内容に基づいてそれ自身の意思決定を行うことができる。ＰＶＥへのシグナリング（信号伝達）は、認証、完全性、および、必要ならば、新しさおよび機密性を提供するために、保護されるべきである。準自律的検証は、Ｈ（ｅ）ＮＢとＰＶＥのような外部バリデーティングエンティティ間に完全性確認と施行タスクを配信する。特に安全起動においてＨ（ｅ）ＮＢはコンポーネントのロード／スタート時にローカルに（局所的に）決定を行うが、ＰＶＥは与えられた状況証拠に基づいて、検証のときに、Ｈ（ｅ）ＮＢに対して許容された対話により決定させることが可能である。ＰＶＥの決定の結果次第で、ネットワークとサービスへのフルアクセスが許可されるか、あるいは孤立したネットワークアクセスと強制的な設定変更のような、より制限された対策が与えられるかもしれない、のいずれかとなる。

トラステッド環境（ＴｒＥ）と称されている信頼されたエンティティは、準自律的検証にとって重要である。準自律的検証のプロシージャはさまざまなものであってよい。一実施形態として、Ｈ（ｅ）ＮＢは、図３のフローチャート３００により図解したようなＨ（ｅ）ＮＢの完全性の準自律的検証を実行することができる。装置認証プロシージャを実行する手続の前に、Ｈ（ｅ）ＮＢのＴｒＥはまず、（ブートコードのような）特定の予め指定されたコンポーネントの完全性のチェックを実行する。完全性チェック結果は次に少なくとも一時的に登録あるいは記憶される（３１０）。これは、Ｈ（ｅ）ＮＢのパワーオン（電源投入）の後に、（例えば、高信頼バックホール回線を構築する目的で）認証の最初のインスタンスの前にＴｒＥ自身により自律的に開始されることができる。このことは、「安全起動（secure boot）」として考えることもできる。登録されたコンポーネントのみが完全性証明済み状態でロードされ、および／または開始されることを強制することによって、ＴｒＥはＨ（ｅ）ＮＢの完全性を保証する。例えば、Ｈ（ｅ）ＮＢの設定変更が前回の成功したネットワーク接続セッション後になされたという理由で、構築された信頼性が再評価されねばならない必要がある場合は、次に、この完全性証明済み起動状態で達成したもののチェックが二通りの方法で再発し得る。最初の事例では、このチェックはＴｒＥ自身により自律的に開始されることができる。その代替として、そのチェックは、要求をかなえるＴｒＥを求める、ネットワーク（例えば、セキュアゲートウェイ（ＳｅＧＷ：Secure Gateway）またはプラットフォーム検証エンティティ（ＰＶＥ））からの要求で開始してもよい。

次に、ＴｒＥはＨ（ｅ）ＮＢの残りの既定の部分が安全な起動状態を達成したかどうかをチェックしてもよい（３１５）。さらなるチェックが、ＴｒＥ自身あるいはＨ（ｅ）ＮＢの外部の計測コンポーネントのいずれかによって、ＴｒＥに対して、TｒＥによる完全性保護済みのものを除いて、行われることができる（３２０）。そのような後期のチェックにおいて、Ｈ（ｅ）ＮＢの残りの他のコンポーネント、設定、あるいはパラメータがロードされ、あるいは開始される場合、あるいは他の、既定のランタイムイベント（実行時間事象）のとき、そのようなことが計測コンポーネントに対して利用可能であろうとも、それらコンポーネント等の完全性が、チェックされる。安全な開始チェックの結果は、少なくとも一時的に記録あるいは記憶される（３２５）。完全性チェック結果と同様に、安全開始チェック結果は、好ましくは、ＴｒＥにより提供された保護された記憶を利用するようなやり方で、あるいは鍵つきハッシュ値のような健全性保護の他の形態で、登録される。

更なる変形として、その結果、すなわち、単一測定結果自身が、ＰＶＥでプロトコルにすでに定められている新鮮さに加えて、新鮮さを提供するためにセキュアタイムスタンプを付加的に備えてもよいし、また測定結果自身についての保護を再生してもよい。このような新鮮さ情報は例えば、ハッシュ機能を働かせてからその結果を、例えばＰＣＲのような保護付きレジスタに格納する前に、タイムスタンプの値を測定結果の値に連結することによって測定結果に含ませることによって達成することができる。

次に、ＴｒＥはチェックの結果を処理して、そのような結果から、ＰＶＥに伝達されるべき検証メッセージを形成する（３３０）。ＰＶＥは、そのようなメッセージを受信したときには、次に、そのメッセージを用いて、Ｈ（ｅ）ＮＢのトラストステート（信頼状態）を評価する（３３５）。一つの処理手続の実施形態として、ＴｒＥは、ＴｒＥにより保護された署名鍵を用いて、Ｈ（ｅ）ＮＢが自律的検証チェックに合格したというステートメントに署名し、それによりそのステートメントの完全性を保護する。ステートメントは状態、またはＨ（ｅ）ＮＢの既定のコンポーネント上のＴｒＥにより実行された正当性チェックの結果を評価するためにＰＶＥによって使用されることのできる証拠も含んでおり、また自律的検証チェック間の何らかの結合の結果と後続の装置認証のプロシージャの結果も含んでいる。ＴｒＥは、また新鮮さを確実にするためのそのようなステートメントにタイムスタンプを付けることもできる。そのような署名されたステートメントは、ＴｒＥのメッセージがＨ（ｅ）ＮＢのＴｒＥからもたらされたデータや結果を整理しなおして、安全立ち上げ手続の後にＰＶＥへ転送するという事実を証明する。署名のベリフィケーションのために、検証は装置認証に結合されねばならない、さもなければ個々のＴｒＥのアイデンティテイ（身元証明）が用いられねばならない。この署名は、多少の追跡可能性を加えることによって、あるいはＮ（ｅ）ＮＢ開始設定のＴｒＥの自律チェックの結果が信頼されるという事実によって裏打ちされることによって、純粋に自律の検証チェックのセキュリティを加える。

ＴｒＥは署名付きステートメントをＳｅＧＷを介してＰＶＥに送り、次いでＰＶＥは、Ｈ（ｅ）ＮＢからの署名付きステートメントを使用することが可能となり、認証を用いて前方へ移るのをＨ（ｅ）ＮＢに許可するか否かを決断できる。ＰＶＥは色々な方法で署名付きステートメント内の情報を利用できる。一実施形態として、ＰＶＥは単一で、静的な設定に対してＴｒＥ自身の完全性をチェックでき、失敗の場合にアクセス接続を拒絶することができる。もう一つの実施形態として、ＰＶＥはアクセス制御できめ細かな判断をするように設定されてもよい。このことは、特に、アクセスが、ＴｒＥの内側あるいは外側で、存在／不在する単一／複合コンポーネントの完全性に基づいて、断られる可能性があることを意味する。さらに別の実施形態として、バリデータステートメントに含まれる指示に基づいて、ＰＶＥは、信頼された第三者機関からのＨ（ｅ）ＮＢのコンポーネントの完全性とセキュリティ属性（プロパティ）の情報をフェッチ（取得）するように設定してもよい。これは、ＰＶＥが、装置上のコンポーネントのための、参照値、すなわち、検証データの情報をフェッチするように設定されてよいことを意味する。次に、コンポーネントの実際の完全性の情報が、検証データと装置から受信したデータとの比較処理により生成される。ＰＶＥは、ＴＲＶのみを除いて、ＴＴＰからのコンポーネントの完全性のステートメントを直接的にフェッチしなかったであろうが、報告された値はそのステートメントと比較されることができる。さらに別の実施形態として、ＰＶＥはアクセスが許可される前に設定変更を命令するように設定されてよい。そのような修正手続は強制的なソフトウェア更新に含まれることができる。

示されているように、ＴｒＥは、信頼されかつ正確なタイムスタンプを作成することができるとしてよく、ＴｒＥ内であるいはＴｒＥにより保護された鍵でそれらタイムスタンプを署名することができる。一実施形態として、外部のバリデータは、ローカル自律装置の完全性チェックがＴｒＥにより実行されたという場合には「タイム」を検証するということもあり得る。このことは、１つのタイムスタンプが最初の、または最後の計測の時点で受け取られることを意味する。別案として、タイムスタンプがＰＶＥでプロトコルの実行時点で適用されることを意味するとしてもよい。それは全ての測定でのタイムスタンプの封入も意味するとしてもよい。望ましい「時間粒度（time-granularity）」は、代替物が適用可能であるということを案内できる。別の実施形態として、ＴｒＥは２つのタイムスタンプを挿入するように構成されてもよく、その１つのタイムスタンプは、ローカル自律装置の完全性チェックがＴＲＥによって実行される前に取り込まれ、他のタイムスタンプは、ローカル自律装置の完全性チェックがＴＲＥによって実行された後に取り込まれるとすることができる。ローカル自律装置の完全性チェックが実際に起ったときに、このような一対のタイムスタンプが時間域を効果的に「結合（bind）」し、ＴｒＥは、ローカル自律装置の完全性チェックの結果あるいはプロセスを示すデータと一緒にそのようなタイムスタンプを送ることによって、外部のバリデータに、装置の完全性状態を評価するだけでなく、Ｈ（ｅ）ＮＢの完全性が、いつの時刻に、及びどの様にして、ＴｒＥによってローカル的に測定され、証明されたかの時間的履歴（テンポラリヒストリ）を知ることも可能にできる。このことは、１）バリデータがタイムスタンプを付された検証メッセージを受信したときに、バリデータ自身のタイムのマーキングと同時にそのようなステートメント（第２の、より最新のタイムスタンプにより示されているステートメント）が得られ、および、２）ローカル自律完全性チェック（これは２つのタイムスタンプから示された２つの時間間で結ばれている）が発生した場合において、自身の「タイムウインドウ（時間窓）」を用いて、装置完全性の状態に関するＴｒＥから受信された署名付きステートメントが時間に依存してどのように処理されることができるかを判断することがバリデータにとって可能であるように作りだすことができる。

ＰＶＭは、ＰＶＭ方法、ここに記載された装置・機構およびアーキテクチャを介してここに記載された戦略（方策）と方法を実行するのに使われることができる。ＰＶＭは通常、アクティブ（活性化）エンティティ間のデューティ（責務）の最大限の分離を採用する。このアプローチ（やり方）は、プラットフォーム検証と管理プロセスに含まれるあらゆるエンティティの活動のフィールド（領域）を明確に定義する。このＰＶＭアプローチの利点は、１）全てのエンティティが分離して実行されるため最適化できること；２）ＰＶＭを使用できる装置が非同期的に（限定つきで）動作可能であること；３）含まれているネットワークエンティティの可能な範囲までは、ＰＶＭの方法がステートレスに（statelessly）実行することができること；４）エンティティが分離して保守され管理されること；および５）冗長と障害回避が容易に実施できること、である。特に、パフォーマンス（性能、動作）とアベイラビリティ（有用性）は、装置の効果的な検証の実行とリモート管理のための基幹である。具体的なシナリオにおいて、選択ホームオペレータ（ＳＨＯ：selected home operator）を変更する、装置コンポーネントあるいは多数の装置の大量の更新のイベント（事象）の可能性がある。ＰＶＭアーキテクチャは、一つのオペレータ、通例はＳＨＯにより単一装置の検証と管理を実行するように構成することが可能である。例外として、ＰＶＭの特別な変形は、ここで記載されているように、ローミングアクセスとオペレータ変更に衝撃（インパクト）を与える可能性がある。

ＰＶＭは、装置が最初に通信ネットワークに参加して、その後の装置完全性を監視し、トラステッドコンピューティング（Trusted Computing）からのセキュリティ技術の一部分に頼るということを試みる場合において、装置を認証し管理するための組織的（体系的）方法を提供する。ＰＶＭは、１）ネットワーク接続前に装置を認証すること；２）装置設定を無線で（ＯｔＡ：over-the-air）管理すること；３）コンポーネントロード／スタートでＲＩＭのようなＴＲＶをチェックすることでのセキュアスタートアップすること；および４）設定変更−ＴＲＶ摂取のために装置上に新しいＴＲＶ（例えばＲＩＭ）をインストールすること、を提供する。

ここに記載されたようなＰＶＭの例示的実施形態において、検証装置と当該装置が検証を行うネットワークについての以下の技術的前提と前提条件がある。ネットワークに関して、最初は、全てのエンティティは、同じコア・ネットワーク（ＣＮ）の一部として同一のモバイルネットワークオペレータ（ＭＮＯ）により動作すると想定する。従って、チャネルの構築（確立）とそれらのエンティティ間の実際の通信についての追加的なセキュリティ（例えば、共通の認証、メッセージの完全性保護、暗号化）は必要とされないであろう。必要であれば、追加的なセキュリティの特徴は、それらが特別な用途である場合に、記載されている。しかしながら、ＰＶＭのアプローチはＭＮＯのＣＮの外側のエンティティについて利用でき、あるいはそのＭＮＯよりもむしろ他のパーティ（当業者）によってなお一層ホストされる可能性があるので、ＰＶＭの適用の範囲は広範囲である。

検証装置に関して、装置は沢山の種類の中に、多くの名前によって入ることができる。ＰＶＭは、Ｅ−ＵＴＲＡＮ（拡張ＵＭＴＳ（Evolved Universal mobile Telecommunications System） Terrestrial Radio Access Network）のＨ（ｅ）ＮＢとマシーン間通信（machine to machine：Ｍ２Ｍ）装置に適用可能であり、また特定の前提条件を満たす多くの他のネットワーク接続装置に適用可能である。このような前提条件は、本質的に高信頼化システム（Trusted System：ＴＳ）のものである。ＰＶＭが適用される場合には、さまざまな装置がＰＶＭ方法で実行するように構成され、それによりＰＶＭ装置となる。

検証は、検証処理のための前提条件として、アイデンティティ（識別番号）を要求し、装置はアイデンティティに対して認証することができる。ＣＮのための装置の認証で混乱することが無いこの認証は、（検証の後で、あるいは検証処理と連結した後で起こる）、偽の装置による一定の攻撃からＰＶＭのインフラストラクチャを保護するのに必要なものである。このことは、ＰＶＭが、装置アイデンティティに対して認証する場合に、未知の装置を回避して、装置がＰＶＭに対して唯一許可されることを示し、装置は、ＰＶＭプロトコルを実行して例えばＤｏＳ攻撃をＰＶＭシステムにマウントすることが可能である。

装置アイデンティＤｅｖ＿ＩＤが装置内のトラステッド環境（ＴｒＥ）、汎用ＩＣカード（Universal Integrated Circuit Card：ＵＩＣＣ）あるいはスマートカードと結びついたアイデンティティである場合、あるいはその装置、例えば、Ｈ（ｅ）ＮＢそれ自身に対して結びついたアイデンティである場合には、それはＰＶＭの目的のためには役立たない。装置はＤｅｖ＿ＩＤと関連する認証信用証明物を秘密に管理し、したがってＤｅｖ＿ＩＤ対して認証をすることができると想定している。Ｄｅｖ＿ＩＤは、ＦＱＤＮ（Fully Qualified Domain Name）、ＵＲＩ（Uniform Resource Identifier）、ＵＲＬ（Uniform Resource Locator）、ＵＲＮ（Uniform Resource Name）、ＭＡＣ（medium access control）アドレス（ＥＵＩ−４８、ＥＵＩ−６４など）、ＩＰｖ４またはＩＰＶ６アドレス、サブネット・アドレスを包含するＩＰｖ６ホスト識別番号（例えば、６４ＬＳＢ）、ＩＭＥＩ（International mobile Equipment Identity）、（ｇｓｍ／ｕｍｔｓなどの）ＩＭＥＩＳＶ、ＥＳＮ（electronic serial number）、（ｃｄｍａなどの）ＭＥＩＤ（mobile Equipment Identifier）、ＩＭＳＩ（International mobile Subscriber Identity）、ＴＭＳＩ（Temporary mobile Subscriber Identity）（加入者と装置が１対１のマッピングだから、装置が加入者によって識別できる場合のもの）、ＩＭＳ加入者ｉｄ（例えば、ＩＭＰＩ（IP Multimedia Private Identity）またはＩＭＰＵ（IMS User Public Identity）のような）、ＭＳＩＳＤＮ（mobile Station Integrated Services Digital Network）、あるいはグローバル、あるいは少なくともドメイン固有のような、固有（一意的）であり、例えば、各オペレータに関して、単一の装置の信頼できて一義的な識別表示を許容する、英数字あるいは機械可読の電子フォーマットの他の識別子であってよい。

装置は信頼できるＴｒＥを持つことができる。装置内のＴｒＥは、不変のルートオブトラスト（Root of Trust：ＲｏＴ）からの安全な起動プロセスで立ち上げることができる。それは安全な実行環境と他の必須の保護された機能とを提供する。ＴｒＥはマネージドコンポーネント（managed component）、例えば、不変でなく、ＲｏＴのみ不変にとどまるような、マネージドコンポーネントであってもかまわない。

トラステッドコンピューディングの観点から、ＴｒＥは、若干のセキュアな実行環境と特定の保護されたインターフェースにより拡張されたＴＰＭまたはＭＴＭからのＴＣＢビルト（built）として考えることができる。ＴＰＭあるいはＭＴＭからのＴＣＢビルトとしてのＴｒＥは、限定されない事例として適用でき、他のトラスト環境でも適用できる。

ＰＶＭのために、ＴｒＥはＴＣＢを提供するが、このＴＣＢは無条件に信頼できる。しかしながら、従来のトラステッドコンピューティングでの不一致（相違）として、ＴｒＥにより構成要素となるＴＣＢはＰＶＭにおいて不変ではない。ＰＶＭにおいて、ＴｒＥと装置内のその環境は異なっているというのがこの理由である。両方の部分における特定の、および異なる情報がインフラストラクチャへ転送されて、異なったポリシーに従ってそれらを認証し、管理するのに使われる。ＴｒＥはＰＶＭインフラストラクチャの主通信パートナーであり、ＰＶＭと正確に関連するタスクの実行を担う。

Ｈ（ｅ）ＮＢとＴｒＥは起動してからコア・ネットワークあるいはＨ（ｅ）ＮＢとＨ（ｅ）ＮＢ管理システム（ＨＭＳ）とを接続する前に、装置完全性チェックを実行することができる。装置完全性チェックは１または複数の信頼された参照値とＴｒＥに基づいていてよい。ＴｒＥはどんな時でも全ての信頼された参照値を安全に格納することを必要とすることができる。ＴｒＥは安全に起動することを必要とすることができる。ＴｒＥはまた単一コンポーネントあるいは複合コンポーネントのいずれか一方の完全性チェックをサポート（支援）することを必要とすることができる。

単一コンポーネント完全性チェックにおいて、ＴｒＥは単一コンポーネントして装置の信頼されたオペレーション（信頼のある操作）をするために必要な全コードをロードすることを必要とすることができる。このコンポーネントの開始前に、ＴｒＥは、例えば、コンポーネントの暗号化ハッシュ測定値と格納された信頼された参照値を比較することによって、コンポーネントの完全性を判断することにより、完全性チェックを実行することを必要とすることができる。単一コンポーネントの完全性チェックが合格となった場合には、そのコンポーネントは起動することができる。その完全性チェックが失敗した場合には、そのコンポーネントは起動できない。

複合コンポーネントの完全性チェックにおいて、装置の信頼されたペレーションにとって必要なその装置の全コードの基部が、装置の機能性に基づいてさまざまなコンポーネント内にセグメント化され、順序付けされる必要がある。ＴｒＥは各コンポーネントを連続して順次にロードする必要があるとすることができ、また個々のコンポーネントが起動する前に、ＴｒＥは、例えば、コンポーネントの暗号化ハッシュ測定値と格納された信頼された参照値を比較することによって、コンポーネントの完全性を判断することにより、整合性チェックを実行することを必要としているとすることができる。個々のコンポーネントはその整合性チェックが合格のときは、そのコンポーネントが起動され、ＴｒＥが次のコンポーネントの整合性チェックを続けるとしてよい。いずれかのコンポーネントが整合性チェックを失敗した場合は、そのコンポーネントは起動されないが、ＴｒＥが次のコンポーネントの整合性チェックを続けるとしてよい。

コンポーネント完全性チェックのそれぞれについて、ＴｒＥは、ＴＲＶに対する完全性の保護を提供するセキュアメモリから対応する信頼された参照値を読み出して、完全性測定値と信頼された参照値を比較することを必要とすることができる。セキュアメモリは、これだけではないが、ＴｒＥの保護記憶域を含む。装置の完全性は、その装置の信頼オペレーションに必要な全てのコンポーネントが確認される場合に、確認される。

安全起動について、安全起動は、一連の信頼を確立することによって、ＲｏＴから複数ステージでの全機能状態へ進行する。図４は、４ステージ安全起動（Four-Stage Secure Start-Up）方法４００の流れ図の一例を示す。ステージ１において、ＴｒＥ４１０は、安全起動でＲｏＴ４０５から確立される。ロードされまたは開始した全てのコンポーネントは検証され、検証を通過した（合格した）コーポネントのみが、ロードされ、起動される。制御はＴｒＥ４１０へ渡され、ＴｒＥはステージ１が成功した場合にのみ安全起動のステージ２を実行する。

ステージ２において、ＴｒＥ４１０は、ＰＶＭの実行のために必須の更なるコンポーネントを検証し、ロードし、起動する。例えば、これは、通信とプロトコル・スタック、および無線アクセスネットワーク（radio access network：ＲＡＮ）通信モジュールを含んでよい。ロードされ開始される全てのコンポーネントは検証を受け、検証をパスしたコンポーネントのみが、ロードされて起動される。

安全起動のステージ３は、ステージ２が成功した場合にのみ開始される。ステージ３ａにおいて、ＴｒＥ４１０は更なるコンポーネントを検証し、ロードし、起動する。検証を通過したコンポーネントのみがロードされ起動される。ステージ３ｂにおいて、ＴｒＥは更なるコンポーネントを測定し、ロードする。

コンポーネントの確認は、それらの測定値を取り（４１５で表示されている）、かつそれらをＲＩＭ記憶域４２０に格納されたＲＩＭと比較する（４２５で表示されている）ことによって実行されると想定している。図示したように、図４は一例示あるいは一実施形態としてのＲＩＭ記憶装置を含んでいる。しかしながら、ここで記載するように、ＲＩＭとＲＩＭの認証は構造化データの一例の形態であって、構造化データの他の形態も使用できる。ここでの説明は、ＲＩＭ以外の構造化検証データの変異型と実施形態を用いることを許容している。全ての記憶域におけるロード順位（ロードオーダ）はローカルに利用可能なリストにより管理されていると想定する。ステージ３ａと３ｂにおけるコンポーネントの区別は、ローカルに利用可能なリストにより管理されていると想定する。任意選択で、ロードの実行と確認は一つのステップに結合してもかまわない。

図４において、用語「ＴｒＥ」は、ＰＶＭにとって必要な最小限の機能を含む、安全起動にとって必要な全ての設備を含む、測定値実行４１５、ＲＩＭ記憶域４２０、ＲＩＭと実測値を比較する確認エンジン４２５のような、エンティティの説明として使用されている。ＴｒＥのこの記述は簡易なものとして用いられるもので、ＴｒＥがこれよりも複雑化でき、鍵発生器または乱数発生器（random number generator：ＲＮＧ）のような、他のコンポーネントを含むことが可能である、とはっきり理解できるはずである。ＴｒＥは、図示したように、安全起動を実施するのに必要な全ての設備を含むことができる。ＲＩＭは、完全性、および任意選択で、機密保持のためＴｒＥよって保護される以外は、ＴｒＥの外側に格納されてよい。測定と確認のためのエンジンはＴｒＥに対して外部のコンポーネントとして実装することもできる。ＴｒＥは、従って、それらのコンポーネントの完全性を確保し、コンポーネントが修正されない方法で安全実行環境を提供することができる。

ポリシーに基づいた微細粒度（finer granularity）がステージ３で可能である。例えば、コンポーネントは、それらコンポーネントが検証に不合格になり、あるいはＲＩＭが利用できない場合に、サンドボックス環境にロードされることができる。ステージ３ａと３ｂ間の区別は信頼されたサービス間の一つと、及びＭＰＷＧ（mobile phone work group）基準アーチテクチャの安全起動での測定されたサービスに対して類似している。

第４のステージは、ユーザスペース（ユーザ空間）内の未証明のコンポーネントのために加えてもよい。

ステージ２（通信モジュールおよび他の同様のモジュール）の単一か複合のコンポーネントの失敗は、装置が通信することができないことを示唆していない。ステージはあるカテゴリーに属するコンポーネントのクラスとして理解される。ステージ２の最も本質的なコンポーネントがロードされる限り、装置はＰＶＭシステムにその状態および失敗したコンポーネントを伝えることができる。この設計は、コンポーネントのうちのいくつかが内部確認に失敗する場合、装置が再起動なしでＰＶＭ（したがって改善プロセス）を行うことを可能にする。

別の実施形態では、セキュリティ侵害（compromise）が安全起動期間で検知されたという条件で、ＰＶＭを実行することを装置に許可するフォールバックコード・ベース（fallback code base：ＦＢＣ）を使用してもよい。装置は、セキュリティ侵害の検知時に、ＦＢＣを用いて再起動（リブート）し、ついで所定の状態を開始して装置修正を許可する。

安全起動の期間において、ＴｒＥは次の情報：１）ロードしたコンポーネントのリスト（Ｃｌｉｓｔ）；２）ロードしたコンポーネントのパラメータ；３）コンポーネントのうちのいくつかあるいはすべてと関係する測定値；および４）ユニークに識別する確認データ、例えば暗号的に、いくらか、またはすべての結果、プラットフォーム状態のような測定値、を不正に変更することに対して記録し保護する。ＰＶＭのために使用された確認方法に依存して、これらのレコードのいくらかあるいはすべては、オプションであってよい。例えば、自律的検証（ＡｕＶ）は、それらのどれも使用しない。

ＰＶＭは、次の用語を使用することができる。用語「確認（verification）」は、安全起動中の装置コンポーネントの内部検証のために使用されうる一方、用語「検証（validation）」は、外部エンティティによって装置をチェックする全体のプロセスに使用される。したがって、「内部」対「外部」の検証の導入は回避される。確認が暗号のチェックの通常の感覚に適用されるか、データに一致している場合、混乱が発生しないように、これは明示的に指摘される。

ＰＶＭは、少なくともセキュリティ・ゲートウエイ（ＳｅＧＷ：Security GateWay）、プラットフォーム検証エンティティ（ＰＶＥ：Platform Validation Entity）および装置管理サービス（ＤＭＳ：Device Management Service）を使用する。装置中のＴｒＥが確認を行うので、装置の内部の重大なタスク、一般に、ＴｒＥは他のエンティティと通信する。この通信に必要とされる装置（例えばネットワークインターフェイス）の他のコンポーネントは、必ずしもＴｒＥの統合部分ではないが、末端間セキュリティ（end-to-end security）を保証するこれらのコンポーネントの完全性を評価することはＴｒＥにとって可能であるべきである。

責務の厳密な分離は、エンティティがそれぞれその中核タスクに制限されることを必要とする。例えば、ＳｅＧＷは、（非）信頼された装置とＭＮＯのＣＮの間の安全なインターフェースを構築する。それは、障壁およびＭＮＯのＣＮのためのネットワークアクセスコントロールおよび施行実例として働く。さらに、それは、認証、装置との通信の暗号化／解読、セキュリティ関連性およびセッション確立を含む障壁をそういうものとして実行するのに必要な、セキュリティに関連する機能をすべて行う。ＳｅＧＷは、ＭＮＯのＣＮと、外部装置のような外部の世界の間の境界を構築するネットワークエンティティの例として適用することができる。ＳｅＧＷの必要なしでＰＶＭ方法を使用して、装置確認を行うことができる。そうすることは、ＴＬＳ（Transport Layer Security）のような安全な接続を使用する、ＤＭＳへの装置の直接の接続を含むことができる。

ＰＶＥに関して、それはＣＮの中の確認エンティティとして働き、完全確認を行う。報告された値が知られており、よい場合には、それは完全確認データおよびチェックを受け取る。それは、ＣＮの中の他のエンティティに装置完全性に関するステートメントを発行する。

ＤＭＳに関して、それは、ソフトウェア・アップデート、構成変更、ＯＴＡ管理および故障モード改善を含む装置コンポーネントの管理用の中央のエンティティとして働く。ＤＭＳは、プラットフォーム確認（ＨＭＳの増強されたバージョンに似ている）に基づいたこの機能を着手する。

上記のエンティティに加えて、ＰＶＭはさらにＲＩＭマネージャ（ＲＩＭｍａｎ）を含む。ＲＩＭｍａｎは、確認中の比較のための信頼された参考データおよびＴＲＶの管理およびプロビジョニングを含む次のタスクを行う。さらに、それは、証明書の管理、具体的には、外国のＲＩＭ証明書の摂取、ＲＩＭ証明書の確認、ＲＩＭ証明書の（オペレータ仕様）生成、および、例えば、取り消し、タイム・リミットおよび信頼関係による証明書有効性のチェックの摂取、を行う。すなわち、ＲＩＭマネージャは一義的なエンティティであり、確認データベース（Ｖ＿ＤＢ）を管理することを認められる。Ｖ＿ＤＢとＲＩＭｍａｎは保護されたＣＮコンポーネントである。Ｖ＿ＤＢへの書き込みアクセスはＲＩＭｍａｎのみに制限される。その結果、ＰＶＥはＶ＿ＤＢに書くことができない。ＲＩＭｍａｎは、ＰＶＭに必要な（ＳＨＯ−ＣＮ）外部信頼関係を管理するので、セキュリティに関して特別に重要である。ここに注意されるように、ＲＩＭｍａｎは一実施形態であり、基準値のためのマネージャの他の実施形態をカバーするのに拡張可能で、構造化データの（階層的に）基準値を証明する。

ＰＶＭは、さらに装置構成の管理およびプロビジョニングを行うコンフィギュレーション・ポリシー・マネージャ（ＣＰｍａｎ）を含む。さらに、それは、（オペレータ仕様の）目標装置構成およびポリシーの信頼された第三者（ＴＴＰ）および生成からのポリシーの管理、具体的には外国の構成およびポリシーの摂取、を行う。すなわち、ＣＰｍａｎは一義的なエンティティであり、設定ポリシーデータベースＣ＿ＤＢを管理することを認められる。それがＰＶＭに必要な（ＳＨＯ−ＣＮ）外部信頼関係を管理するので、ＣＰｍａｎはセキュリティに関して特別に重要である。

図５Ａと図５Ｂは、エンティティの最小のセット、それらの関係およびＰＶＭのためのインターフェースの例を示す。ＡＡＡ（Authentication, Authorization & Accounting）サーバ、無線送受信ユニット（ＷＴＲＵ）およびそれらのインターフェースなどの追加のエンティティが示される。

図５ＡのＰＶＭアーキテクチャ、すなわちシステム５００は、ＴｒＥ５１０を有する装置５０５を含む。ＷＴＲＵ５１２はＩ−ｕｅインターフェース５１４経由で装置５０５と通信できる。装置５０５は、Ｉ−ｈインターフェース５１５経由でＳｅＧＷ５２０と通信する。一般に、装置５０５とＳｅＧＷ５２０の間のＩ−ｈインターフェース５１５は無防備の可能性がある。また、特別措置は確実性、完全性および随意的に機密性のためにこのチャネルを安全にするために適用されてよい。Ｉ−ｈ５１５は装置５０５とＳｅＧＷ５２０の間、およびしたがってＣＮとのリンクを確立するために使用されうる。例えば、ＳｅＧＷ５２０は、インターフェースＩ−ａａａ５７５によってＡＡＡのサーバと通信することができる。オペレータは、インターフェースのセキュリティを保証する適切な手段を確立できる。

検証中にＰＶＥ５２４と連絡をとるために、Ｉ−ｐｖｅインターフェース５２２は、ＳｅＧＷ５２０によって使用されることができる。ＰＶＥ５２４は、ＳｅＧＷ５２０に確認の結果をシグナルするためにＩ−ｐｖｅインターフェース５２２を使用することができる。Ｉ−ｄｍｓインターフェース５３０は、ＤＭＳ５３５とＳｅＧＷ５２０との間の装置構成の関連通信のために使用されうる。ＤＭＳ５３５と、および逆に通信するために、Ｉ−ｐｄインターフェース５３２は、ＰＶＥ５２４によるＤＭＳ５３５との通信およびその逆方向の通信に使用されうる。このインターフェース、Ｉ−ｐｄ５３２は、装置ソフトウェア・アップデートおよび構成変更などのために、装置管理プロシージャの間に使用されうる。

インターフェースＩ−ｖ５２６およびＩ−ｄ５３８は、それぞれ、Ｖ＿ＤＢ５４０からＲＩＭを読むＰＶＥ５２０によって使用されることができ、Ｃ＿ＤＢ５５０から許可された設定を読むＤＭＳ５３５によって使用されることができる。インターフェースＩ−ｒ５２８およびＩ−ｃ５３４は、Ｖ＿ＤＢ５４０のＲＩＭが見つからないような場合にＲＩＭｍａｎ５６０に通信するＰＶＥ５２０によって使用されることができ、およびＣＰｍａｎ５７０と通信するＤＭＳ５３５によって使用されることができる。ＲＩＭｍａｎ５６０およびＣＰｍａｎ５７０はインターフェースＩ−ｒｄｂ５６２およびＩ−ｃｄｂ５７２を使用することができ、それぞれデータベースＶ＿ＤＢ５４０および構成ポリシーデータベースＣ＿ＤＢ５５０の検証を読み書きし管理する。

図５Ｂは、装置５０５がＤＭＳ５３５に直接接続することができる場合でのＰＶＭ５８２を説明する。例えば装置５０５がＳｅＧＷを備えたセキュリティ・プロトコルを行うことができないフォールバックモードの場合には、ＤＭＳ５３５は、インターフェースＩ−ｄｍｓ＿ｄ５８４によって装置５０５のための第１の接触のポイントとして働き、検証を行うか、あるいは少なくともどのコンポーネントが安全起動中に失敗したかを知るようにするためにインターフェースＩ−ｐｖｅ５８６およびＩ−ｐｄ５８８によってＰＶＥ５２４と通信することができる。ＤＭＳ５３５は修正のためのこの情報に基づいて行動することができる。

一般に、ＴｒＥ５１０、ＳｅＧＷ５２０、ＰＶＥ５２４およびＤＭＳ５３５を含む装置５０５のようなそれぞれのコンポーネントはすべて、アクティブなエンティティ間の責務アプローチのＰＶＭの最大のタイプ分離を使用するように好ましくは構成される。より完全に下に説明されるように、様々なエンティティ間のある情報を通すために、これはＰＶＭトークンの使用を通じて促進される。

ここに述べられるように、ＰＶＭは検証のどんなバージョンも使用することができる。ＰＶＭで働く準自律的検証（ＳＡＶ）の実施形態がここに記述される。この実施形態では、装置はＴｒＥとＲｏＴを含んでおり、安全起動ができる。装置はＲＩＭを装備しており、ＲＩＭは、ＴｒＥコンポーネントおよびＴｒＥの外側のコンポーネントのローカルの検証を考慮に入れる。この実施形態では、装置はＨ（ｅ）ＮＢであってよい。ここに注意されるように、ＲＩＭは構造化データの形式および例であり、また制限しない例としてここに使用される。

装置は、ロードされるコンポーネントのローカルの検証が成功する場合、およびその場合のみ、コンポーネントがそれぞれロードされることを保証して、３つのステージの安全起動を行うことができる。ステージ１では、ＴｒＥはＲｏＴに依存する安全起動によってロードされる。ステージ２では、ＳｅＧＷとの基礎的な通信を行うように要求される、ＴｒＥの外側のコンポーネントはすべてロードされる。ステージ３では、装置の残りのコンポーネントはすべてロードされる。

その後、装置はＳｅＧＷでネットワーク認証を始めることができる。認証中に、次のデータ：Ｄｅｖ＿ＩＤ；装置のセキュリティ・ポリシー；安全起動中にＴｒＥによってチェックされたインテグリティである装置モジュールについての情報；ハードウェア／ソフトウェア構造バージョン番号；装置のメーカー；モデルとバージョン番号；装置とＴｒＥについての証明情報；またＴｒＥ能力および特性、の１つまたは複数が送られる。

異なるオプションは、（ＳｅＧＷを介して）ＰＶＥにこのデータを送ることを申請することができる。このデータは、インターネット鍵交換バージョン２（ＩＫＥｖ２）認証プロトコルのＮｏｔｉｆｙフィールドで送られてよく、次に、ＳｅＧＷによってＰＶＥへ転送される。その後、ＰＶＥは受信情報をチェックする。ＰＶＥは、Ｄｅｖ＿ＩＤがブラックリストにリストされるかどうかをチェックし、リストされるならば、アクセスは次に否定される。それは、セキュリティ・ポリシーがその装置用の所望のポリシーで誤って組合せられるかどうかチェックする。それらが誤って組合せられる場合、改善ステップが実行されることができる。ＰＶＥは、未確認の／望まれないモジュールおよびコンポーネントがロードされたかもしれないかどうかチェックすることができる。

上記のチェックの各々では、装置のＴＳの失敗した確認を示す肯定的な答えの場合には、ＰＶＥは、装置のネットワークアクセスを拒絶する、または制限（例えば、制限された使用あるいはリソースへの隔離）することができる。ＰＶＥは、ＳｅＧＷに装置の有効性および信頼性に関する決定に関するメッセージを送る。ＳｅＧＷはメッセージに従って作用する。

最初の変形の実施形態では、データは信頼された第三者（ＴＴＰ）で保存される。また、装置は、ＰＶＥが所望の情報を検索することができるＴＴＰにポインタを送る。ポインタはＩＫＥｖ２のＮｏｔｉｆｙペイロード中で送られることができる。

別の変形の実施形態で、データがすべて静的な限り、それは認証中に（恐らく増強された）装置証明書に含まれているとしてよい。測定への変更を意味するコンポーネント、およびしたがって安全起動に使用されるＲＩＭへのどんなアップデートも、新しい装置証明書を要求するであろう。

遠隔の検証、あるいはＰＶＭで働く十分な準自律的検証（Ｆ−ＳＡＶ）の実施形態がここに記述される。ステージ１では、ＴｒＥは安全起動のＲｏＴから構築されることができる。ＴｒＥの全てのコンポーネントは、確認が成功すると完全性が検証され、ロードされうる。ステージ２では、ＴｒＥは、装置の残りのあらかじめ定められた部分の完全性を確認できるし、それらをロードすることができる。完全性がチェックされたコードは、例えば基礎的なＯＳ、ＳｅＧＷへの基礎的な通信、およびメッセージを報告する、実行するＰＶＭをフォーマットするコードから成ることができる。測定値はＴｒＥの中の安全な記憶域に格納されることができる。

ステージ１あるいはステージ２のチェックが失敗する場合、ＴｒＥは手続きからの認証をブロックすることができる。ステージ１および２が成功する場合、ステージ３は進行することができる。例えば、無線アクセスコードを含むコードの残りの装置モジュールは、完全性をチェックされるが、ロードされなくてよい。検証データは、準備されて、適切な通信プロトコルでＳｅＧＷに送られることができる。データは、データの確実性および完全性を提供するために、例えば、ＴｒＥに格納されたキーによって署名されることができる。データは、完全性チェックに失敗したステージ３モジュールのリストを含むことができる。

データは、ＩＫＥｖ２ ＡＵＴＨ＿ＲＥＱメッセージのＮｏｔｉｆｙペイロードを使用して送られることができる。Ｎｏｔｉｆｙペイロード中のデータは、ＩＫＥセキュリティ関連性によって提供される全面的なメッセージ保護に加えてそのデータの確実性および完全性を提供する、ＴｒＥの署名キーによって署名されることができる。Ｎｏｔｉｆｙペイロードは、完全性チェックに失敗したステージ３モジュールのリストを含むことができる。検証データは、適切なＩＫＥｖ２メッセージの他の適切なペイロードやフィールド、あるいはＴＬＳ、ＴＲ０６９、ＯＭＡ−ＤＭ、ＨＴＴＰ、ＨＴＴＰＳあるいは他の同様のプロトコルのようなＩＫＥｖ２プロトコルのもの以外に適切なプロトコルのメッセージの他の適切なペイロードやフィールドを使用して送られることができる。

ＳｅＧＷは決定用のＰＶＥへデータを転送することができる。認証プロセスは進むことができる。しかし、ＰＶＥが検証メッセージを検査し、検証テストに失敗したとして報告されたあらゆるモジュールに関するネットワークに基づいたポリシー決定をした（あるいは得る）後まで、ネットワーク接続を認可する決定は遅れうる。

３番目の変形の実施形態では、コードを測定し実行する代わりに、コードの測定および完全性確認はロードされるコードなしでロードされることができる。ＳｅＧＷは受信リストを有効にするＰＶＥへの検証メッセージをＰＶＥに転送することができる。装置によるＰＶＥからの成功した検証の受信により、残るステージ３モジュールはロードされうる。

完全性を測定し、ＰＶＥがコードが実行されることができるかどうか決定するのを待つプロセスは、一旦コードが測定されたならばコードが変更されないかもしれないし、ＰＶＥがそうする認可を与える場合にコードが実行されるかもしれない、と規定することを含むことができる。したがって、ステージ３のすべての構成要素のコード用の安全な記憶装置は含まれているとしてよい。さらに、実行環境は、コードが最初にロードされ、後で認可の後にそれを実行することを可能にする、認可された実行を支援することができる。大量のコードはロードされることができ、よって、安全な記憶装置および実行環境は適切なサイズであるべきである。

「ローカルの完全性チェック」で実際に進んだものに気づいているために、Ｆ−ＳＡＶはＣＮに柔軟性を供給することができる。装置は、ステージ１と２のコードの通過／失敗のインジケーション、および、オプションで失敗したモジュールのリスト（もしあれば）を送ることができる。Ｆ−ＳＡＶは、装置セキュリティ特性および検証測定により細かな粒度およびより多くの可視性（visibility）を提示することができ、自律的検証に匹敵するローカル装置リソースを許可することができ、セキュリティ侵害にさらされた装置のより速くより容易な検知に備えることができ、セキュリティ侵害にさらされた装置用のネットワークにより始められた改善をサポートすることができ、また装置セキュリティ管理中のオペレータのための柔軟性を提供することができる。

ＴｒＥは、新鮮さを保証するメッセージに、タイムスタンプを付けることができる。タイムスタンプの代わりは、ネットワークアクセス用のプロトコルがスタートした後、ネットワークが、前述のメッセージと結合するためにＴｒＥによって使用されるノンス（nonce）を供給することであってもよい。それはさらに装置認証を検証に結び付ける工夫であってもよい。

認証失敗の修復は、失敗のことをそれに通知するＳｅＧＷにアタッチする装置用の十分な機能性を許可するステージ１あるいはステージ２完全性チェックの最初の失敗の後に例えばフォールバックモードの活性化であり得る。その後、これは、装置ソフトウェアが診断すると更新されることを可能にする操作・保守（ＯＡＭ）手続きを引き起こすことができた。フォールバックコード（fallback code）は、ＴｒＥの監督の下の安全なやり方でコードの完全な再構築を可能にする十分な機能性を持つ必要があるだろう。

最初の変形の実施形態では、測定メッセージ・データは、（装置証明書に加えて）ＩＫＥｖ２ ＡＵＴＨ＿ＲｅｑｕｅｓｔのＮｏｔｉｆｙフィールドで送られることができる。別の変形の実施形態では、測定メッセージ・データは、装置認証に基づくＩＫＥｖ２のスタートに先立って適切な保護プロトコルによって送られることができる。３番目の変形の実施形態では、ステージ１あるいは２の任意の部分でチェックが失敗する、また、失敗するモジュールが補助的機能（基礎的な装置機能には重大でない）である場合、装置は、これらのモジュールをロードせずに、進む／アタッチすることを許されることができる。一方、あるＯＡＭ手続きは、装置ソフトウェアを更新すると予定されてもよい。

すべての含まれるエンティティの機能のハイ・レベルの概観がここに提供される。検証および遠隔の管理が重要な役割を果たすかもしれない、Ｈ（ｅ）ＮＢ装置のシステム・アーキテクチャが記述される。記述された方法は、Ｈ（ｅ）ＮＢネットワーク・アーキテクチャ中のエンティティに直接適用されてよい。より多くの一般的方法の使用によって、責務の分離による役割の定義で、プラットフォーム検証および管理のための示された解決法は、他のネットワーク接続装置に容易に適用され、拡張されることができる。エンティティがそれらの機能によってマッピングされる場合、Ｍ２Ｍのような他のシナリオへのトランスファーは同様の方法で実行されることができる。

ＰＶＭ機能の本明細書に記述された実施形態では、準自律的検証（ＳＡＶ）は使用される。ＳＡＶは、ＣＮが完全に悪者装置から保護されることを可能にする。ＳＡＶ中に、隔離ネットワークは、ＳｅＧＷによって有効に確立されることができる。直接の脅威は装置からのＰＶＥおよびＤＭＳにもたらされない。というのも、ＰＶＥおよびＤＭＳは、それらのタスクに制限されるデータのみを、およびＳｅＧＷとの、あるいはＳｅＧＷによって確立される安全な接続を介してのみ受信するからである。遂行ＰＶＭの中の検証プロセスは、ＣＮの中の装置と任意のエンティティの間の直通通信を要求しない。ＳＡＶを使用する成功した検証の後にだけ、ＣＮへの接続は許可される。これは、証明された安全な状態の装置だけがＣＮの内部のエンティティに通信することができることを保証する。

図６Ａ、図６Ｂおよび図６Ｃは、ＰＶＭインフラストラクチャを備えたＳＡＶ検証方法の一例の図を示す。ＰＶＭインフラストラクチャは、ＴｒＥ６０５、ＳｅＧＷ６０７、ＰＶＥ６０９、ＤＭＳ６１１、Ｖ＿ＤＢ６１３およびＣ＿ＤＢ６１５を含めて、ここに記述されたエンティティを含む。相互認証（６２０）に続いて、ＴｒＥ６０５は、次のデータのうちのいくつかあるいはすべてを集める：Ｄｅｖ＿ＩＤ、メーカー、およびサポートされるデータ転送速度、送信電力レベル、シグナル特徴および他の能力、ＲｏＴを含むＴｒＥ能力および特性などの通信能力を含むがこれらに限定されない装置能力などの装置情報；ＩＤ、証明情報、メーカー、構造バージョンおよびモデル、型、シリアルＮｏを含むＴｒＥ＿情報、；プラットフォーム設定レジスタ（ＰＣＲ）値を含む確認データ；ＰＣＲ値を介した署名のようなベリフィケーションバインディング；コンポーネントに対するコンポーネントインジケータ（ＣＩｎｄ）の順序付きリストＣｌｉｓｔであって、コンポーネント用パラメータを含むリスト；またタイムスタンプ（信頼された、あるいは信頼されてない）（６２２）。ＴｒＥ６０５からＳｅＧＷ６０７までの検証メッセージ／データは、上記データ（６２４）を含むことができる。

ＳｅＧＷ６０７は、変化（６２６）を検知するためにローカルタイムで受け取られたタイムスタンプをチェックし／比較しなければならない。これは、報告されたタイムスタンプと、ローカルタイムとが一致しない場合は、ＳｅＧＷは報告されたタイムスタンプの属性によって動作する。装置のタイムスタンプが信頼されたタイムスタンプであり、変化を示す場合、ＳｅＧＷ６０７はＴｒＥおよびその信頼されたタイムリソースの再検証を引き続き行うべきである。信頼されていないタイムスタンプの場合には、ＳｅＧＷ６０７がメッセージにそれ自身の信頼されたタイムスタンプを加える。装置が信頼されたタイムスタンプを提供することができない場合、ＳｅＧＷ６０７はリプレーアタックに対する保護として信頼されたタイムスタンプを加えてもよい。

このメッセージを受け取ると、ＳｅＧＷ６０７は、ベリフィケーションバインディングが存在するかをチェックすること（６２８）ができる。これは、確認データの信頼性を保証する。その後、ＳｅＧＷ６０７はＰＶＭトークン（Ｔ＿ＰＶＭ）（６３０）を作成し、新鮮さを保証し、かつ非同期メッセージ・フローを防ぐためにＴ＿ＰＶＭを送る（６３２）前に、Ｔ−ＰＶＭにタイムスタンプを適用する。

ＳｅＧＷ６０７は、ＰＶＥ６０９へＴ＿ＰＶＭを転送し、ＰＶＥ６０９は、ＴｒＥ情報を使用してＶ＿ＤＢ６１３に問い合わせをする（６３６）。信頼できない決定がＰＶＥ６０９に返される場合（６３８）、ＰＶＥは、Ｔ＿ＰＶＭにタイムスタンプを適用し（６４０）、ＳｅＧＷ６０７へそれを転送する（６４２）。その後、ＳｅＧＷ６０７は装置認証を止めて、装置のネットワークアタッチメントを防ぎ、ＴｒＥ６０５に警報する（６４４）。

信頼できる決定がＰＶＥ６０９に返される場合（６４６）、ＰＶＥは、Ｄｅｖ＿ＩＤ（６４８）を使用してＣ＿ＤＢに問い合わせを行い、Ｃ＿ＤＢは、ＰＶＥ６０９に設定ポリシーを返す（６５０）。ＰＶＥ６０９はポリシーの設定を評価する（６５２）。

設定が信頼できない（６５４）ことをＰＶＥ６０９が決める場合、ＰＶＥ６０９はＴ＿ＰＶＭを修正し、タイムスタンプを適用する（６５６）。その後、ＰＶＥ６０９はＳｅＧＷ６０７へＴ＿ＰＶＭを転送し（６５８）、ＳｅＧＷ６０７は、装置認証を止め、装置のネットワークアタッチメントを防ぎ、ＴｒＥ６０５に警報する（６６０）。

設定が信頼できて、設定を許可することをＰＶＥ６０９が決める場合（６６２）、ＰＶＥ６０９は、Ｖ＿ＤＢ６１３からＣｌｉｓｔまたはＣ＿Ｌｉｓｔの中のすべてのエントリ用のＲＩＭＳを検索する（６６４）。ＰＶＥ６０９は、ＲＩＭからの正確な確認データを再計算し（６６６）、計算された確認データを報告された確認データと比較する（６６８）。ＰＶＥ６０９は、Ｔ＿ＰＶＭを修正し、タイムスタンプを適用する（６７０）。ＰＶＥ６０９は、ＳｅＧＷ６０７へＴ＿ＰＶＭを転送する（６７２）。ＳｅＧＷ６０７は、ＰＶＥ検証結果（６７４）についてＴ＿ＰＶＭ（あるいはＴ＿ＰＶＭからの抜粋）を検査する。ＳｅＧＷ６０７は、ＴｒＥ６０５に装置認証の否認か承認を送る（６７６）。ＰＶＥ検証結果が否定の場合、ＴｒＥ６０５はリブートを行い、再検証を行う（６９０）。

随意的に、ＰＶＥ６０９は、計算された確認データと報告された確認データとを比較した（６６８）後、ＰＶＥ６０９はＤＭＳ６１１に失敗したコンポーネントのリストを送ってよい（６７８）。ＤＭＳ６１１は、更新版が適用可能であるかを判断し（６８０）、そうである場合ＯＴＡの更新を準備する（６８２）。ＤＭＳ６１１は、さらに更新版用のＲＩＭがＶ＿ＤＢ６１３に存在することを保証する（６８４）。ＤＭＳ６１１は、ＳｅＧＷ６０７に再検証のインジケーションを備えたＴ＿ＰＶＭを送り（６８６）、ＴｒＥ６０５（６８８）に再検証トリガーを送る。ＴｒＥ６０５はリブートを行い、再検証を行う（６９０）。

図６Ａ、図６Ｂおよび図６Ｃの中の処理に関しての詳細は、ここに記述される。プラットフォーム検証を行うために、ＴｒＥは次のデータを集めて、検証メッセージにそれらを含めて、ＳｅＧＷに検証メッセージを伝える：Ｄｅｖ＿ＩＤ、メーカー、ＴｒＥ能力およびＲｏＴを含む特性のような装置情報；ＩＤ、証明情報、メーカー、構造バージョンおよび随意的にモデル、型、シリアルＮｏを含むＴｒＥ情報；プラットフォーム設定レジスタ（ＰＣＲ）値、単にローカルの確認に失敗したコンポーネントのリストあるいはローカルの検証に失敗したコンポーネントによって影響を受けた機能性のリストを含みうる確認データ；ＰＣＲ値あるいは失敗したコンポーネントのリストあるいは影響を受けた機能性のリストに関する署名などのベリフィケーションバインディング；コンポーネントに対するコンポーネントインジケータ（ＣＩｎｄ）の整列されたリストＣｌｉｓｔであって、コンポーネント用パラメータを含むリストコンポーネントに対するコンポーネントインジケータ（ＣＩｎｄ）の順序付きリストＣｌｉｓｔであって、コンポーネント用パラメータを含むリスト；またタイムスタンプ（信頼された、あるいは信頼されない）。

コンポーネントおよびそれらのパラメータに対する指標の順序付きリストは、インデックス、component_indicator CInd、component_parametersといったデータ・フィールドのようなエントリを含んでよい。ＣＩｎｄはコンポーネントに参照を与えて、ＵＲＮフォーマットであってよい。コンポーネントのリストは、ＲＩＭ証明書（ＲＩＭｃｓ）を指すことにより、例えば検証用のＲＩＭを識別する役目をするであろう。

装置の場合には、検証メッセージがさらにＩＤ、証明情報、メーカー、モデル、バージョン、型、シリアルＮｏなどの装置情報、ＲｏＴを含むＴｒＥ機能およびプロパティ、装置のセキュリティ・ポリシー、ステージ（１、２、３）で完全性チェックを行うモジュール、ハードウェア（ＨＷ）構造バージョン番号を含むことができ、ソフトウェア（ＳＷ）バージョン番号および完全性測定データを含むことができる。

ＴｒＥ−具体的情報は必要な場合、それはＴｒＥが装置の中でどのようにインプリメントされるかの記述であってよい。さらに、例えば、ＴｒＥが保証されたＩＰコンポーネントである場合、ＴｒＥ情報は装置についての情報および信頼環境についての個別の情報を提供することができる。したがって、装置の認証機関は有用な情報となろう。

検証のためのＲＩＭの使用はＳＡＶのための推奨方法であるが、それは実際にオプションである。それは、基礎の場合（他のオプションはそれから外れて逸脱する）としてここで使用される。例えば、ＲＩＭからの確認データを再計算せずに検証がある。また、完全にＲＩＭなしで実行するＰＶＭを行う可能性さえある。

例えば、検証メッセージが安全なチャンネルによって認証に結び付けられる場合、ベリフィケーションバインディングはオプションである。

ＳｅＧＷは、変化を検知するためにローカルタイムで受け取られたタイムスタンプをチェック／比較する。報告されたタイムスタンプがローカルタイムと一致しない場合、ＳｅＧＷは報告されたタイムスタンプの特性によって作用する。装置のタイムスタンプが信頼されたタイムスタンプであり、変化を示す場合、ＳｅＧＷはＴｒＥおよびその信頼されたタイムリソースの再検証を引き起こす。信頼されていないタイムスタンプの場合には、ＳｅＧＷがメッセージにそれ自身の信頼されたタイムスタンプを加える。装置が信頼されたタイムスタンプを提供することができない場合、ＳｅＧＷはリプレーアタックに対する保護として信頼されたタイムスタンプを加えることができる。

装置とＴｒＥ情報（TrE_info）はオプションであってよい。Ｄｅｖ＿ＩＤは、装置とＴｒＥ情報に参照を与えることができる。全てのＭＮＯが、ネットワークに接続する装置、全てのＴｒＥ、および全てのＴｒＥ情報データを知っているとは限らないので、そのようなマッピングは、所定のＤｅｖ＿ＩＤについてのＴｒＥ情報を得るためにＭＮＯによって問い合わせされることができるデータベースによって提供されることができる。ＴｒＥ情報は、TrE_certificateにあってよい。TrE_certificateは、ＴｒＥまたはＴＴＰのベンダーによって署名されるべきである。

最初の変化で、確認データ／結合が検証メッセージに含まれていない場合、実行するＰＶＭの単純なバージョンは実行されることができる。もしＴｒＥの特性が確認されることになっていれば、これが行われてよい。ポリシー決定はコンポーネントだけのＴｒＥ情報およびリストに依存すべきである。

ＳｅＧＷと装置の間の相互認証はこの変化の先行条件（必須）である。例えば、装置がオペレータを変更すれば、信頼の問題が発生する。例えば、それは、遠隔の管理手続中に偽造されたＳｅＧＷ／ＭＮＯから偽造されたＲＩＭを以前に受け取ることがありうる。

コンポーネントへの指標としてのＵＲＮの使用は、その使用がコンポーネントのこの一義的な識別およびＲＩＭあるいはＲＩＭ証明書がフェッチされうる位置を同時に考慮に入れるので、有利である。

装置検証中に、装置は、ＳｅＧＷに検証メッセージを送る。このメッセージを受信すると、ＳｅＧＷは、もしあればベリフィケーションバインディングをチェックする。このステップは、確認データの信頼性を保証する。その後、ＳｅＧＷはＰＶＭトークン（Ｔ＿ＰＶＭ）を作成する。トークンＴ＿ＰＶＭは、回転するトークンとして使用されてもよく、通信中にエンティティからエンティティに渡される。すべてのエンティティは新鮮さを保証し、かつ非同期メッセージ・フローを防ぐためにトークンを送る前に、トークンにタイムスタンプを付ける。トークンの上のタイムスタンプはトークンの状態に続く方法を提供するために適用することができる。トークンは、いくつかの巡回でさえ、エンティティからエンティティにＣＮの中で移動でき、したがって、エンティティによって追跡されることができる。

随意的に、エンティティＩＤは、タイムスタンプを押された一連のデータに組み入れられる。

Ｔ＿ＰＶＭはＤｅｖ＿ＩＤを含むことができる。オリジナルのタイムスタンプが存在しないあるいは信頼されない場合、Ｔ＿ＰＶＭはさらにＳｅＧＷによって出された新しいタイムスタンプを含むことができる。そうでなければ、Ｔ＿ＰＶＭは、検証メッセージからのオリジナルのタイムスタンプを含むことができる。

タイムスタンプは、リプレーアタックに対して保護するために使用されることができる。タイムスタンプは、ノンス（nonce）または単調に増加するカウンタと結合されるか、あるいは置き換えられてよい。タイムスタンプはまた、検証データの新鮮さを評価するために使用されることができる。両方の目的の組み合わせは有利で、タイムスタンプによって提供されることができる。

ＳｅＧＷとＰＶＥおよびＤＭＳの間の通信がすべて完全性、確実性および機密性に関して安全であると仮定される。したがって、これらのセキュリティ特性を確立する手段は任意の内部メッセージには義務的ではない。しかしながら、もし望まれればその完全なメッセージあるいは部分に適切な手段を適用することは可能である。そのような手段は、メッセージ上の暗号化通信チャネル、相互認証および署名を含むことができる。ＳｅＧＷは、アクティブなＴ＿ＰＶＭをすべて含むトークンデータベースＴ＿ＤＢを維持する。

第１の変形において、後のために、ＤＭＳによる装置管理、Ｔ＿ＰＶＭは、ＤＭＳとＴｒＥの間の安全なトンネルの構築のために通信秘密（例えば、ＴＬＳ証明書）を含むことができる。

ＳｅＧＷは、検証メッセージから次のデータ、すなわち、検証データ、ＴｒＥ情報およびＣｌｉｓｔを抽出する。トークンＴ＿ＰＶＭと一緒にこのデータを送る前に、ＳｅＧＷは、Ｔ＿ＰＶＭにタイムスタンプを付け、ＰＶＥへそれを転送する。ＳｅＧＷは、検証メッセージおよびその一部分のフォーマットをチェックし、不良フォーマットデータ攻撃（mal-formed data attack）からの脅威を緩和することができる。そうでなければ、ＰＶＥでのこのデータの純粋な検査がシステム・エラーか失敗に結びつくように、攻撃者は、セキュリティ侵害にさらされたＴｒＥの検証メッセージ中のデータを修正（改ざん）しようとするであろう。

Ｄｅｖ＿ＩＤと対応するＨ（ｅ）ＮＢのアイデンティティであるＨ（ｅ）ＮＢ＿ＩＤを区別することは役に立つであろう。両者間のアソシエーションは１対１であるけれども、そのような分離は、責務（ＳｅＧＷがＴｒＥを知っている、ＰＶＥがＨ（ｅ）ＮＢを知っている）の分離の見解から、および恐らくアドレッシング／管理から意味をなすだろう。この場合、ＰＶＥが受信Ｈ（ｅ）ＮＢ＿ＩＤを使用して、データベースＨＮＢ＿ＤＢからＤｅｖ＿ＩＤをフェッチする中間のステップがあり得る。

ＰＶＥは装置の有効性を決めるエンティティである。すなわち、ポリシーシステムの言語では、それはポリシー決定ポイント（ＰＤＰ）である。責務アプローチの厳密な分離の下では、それはＰＶＭシステムでのただ一つのＰＤＰである。それは、ＳｅＧＷ、およびポリシー施行ポイント（ＰＥＰ）として働くようなポリシーを実行するＤＭＳに依存する。ＰＶＭは、ポリシーがどこから得られるかなど、ポリシーがどのように生成されるか、また、それらがどこで格納されるか／管理されるかという問題にとらわれないままである。もっと詳細な変形および従属する方法のうちのいくつかでは（具体的には、パラメトリック検証および最小限の検証）、ポリシー条件およびアクションのいくつかの例が挙げられる。一般に、検証ポリシーに関する決定は、単一のコンポーネントの有効性だけでなくＣｌｉｓｔに含まれる他のデータに基づくことができる。具体的には、許可されたパラメータ（範囲）およびロードの順序（Ｃｌｉｓｔが順序付けられる）が評価されることができる。

ＰＶＥによって実行された検証プロセスで生じうる、いくつかの基本のクラスの不良状態がある。例えば、不良状態Ｆ１は「ＴｒＥ無効」シナリオを示す。その認証されたＤｅｖ＿ＩＤおよび伝えられたＴｒＥ情報によって、ＰＶＥは、装置および／またはそのＴｒＥを信頼できないものとして識別する。

別の例は、「確認データ失敗」の３つのシナリオを示す不良状態Ｆ２である。シナリオＦ２ａは、完全性測定／確認データのミスマッチを示す。シナリオＦ２ａは、装置の安全起動プロセスの失敗、および／または失敗の存在、および／または失効したＲＩＭ、および／または装置上のＲＩＭ証明書を示し、その後、無効のコンポーネントを起動する。シナリオＦ２Ｂは、ＲＩＭが見当たらないこと、つまり、コンポーネント用のＲＩＭは見当たらず、他のところからフェッチする必要があることを示す。シナリオＦ２ｃは、失効したＲＩＭ証明書を示す。

不良状態Ｆ３は、「Ｃｌｉｓｔポリシー失敗」の２つのシナリオを示す。シナリオＦ３ａについては、単一のコンポーネントは有効である。しかし、設定は、ロード・オーダー、望まれないコンポーネント、あるいはパラメータでのポリシーに失敗する。シナリオＦ３Ｂは、設定が未知であり、そしてＣｌｉｓｔの「既知の価値」が利用可能でないことを示す。

不良状態Ｆ４は、「プレ検証・装置認証失敗」を示し、およびどの装置認証が検証に先行するかというやり方で認証が検証につながる場合に、当てはめることができる。Ｆ４条件は、失効した装置証明書を示すＦ４ａシナリオを含むことができる。

不良状態のための検知および処理方法がここに記述される。不良状態Ｆ１については、ＰＶＥは、受信ＴｒＥ情報を使用して、ローカルの検証データベース（Ｖ＿ＤＢ）に問い合わせる。ＴｒＥ情報構造は、証明、メーカー、型、モデル、ＴｒＥのシリアル番号に関する詳細情報を含む。検証データベースＶ＿ＤＢは、ＴｒＥが信頼できると考えることができる情報を格納する。例えば、あるベンダー、モデルあるいは他の同様の確認者を信頼するポリシーをインプリメントすることは可能であってよい。ＴｒＥがＴｒＥ情報の評価の結果によって信頼できない場合、ＰＶＥはＳｅＧＷにこの情報を含むメッセージを送ることができる。その後、ＳｅＧＷは、このメッセージに適切に作用することができる。ＰＶＥは、悪い／信頼できないメーカーのような否定されたアクセスの原因を含む、Ｔ＿ＰＶＭトークン（例えば補足データ・フィールド）にステートメントを加える。ＰＶＥはＴ＿ＰＶＭにタイムスタンプと署名を付ける。Ｔ＿ＰＶＭはＳｅＧＷへ転送される。その後、ＳｅＧＷは、タイムスタンプ（やり直し保護）および署名（偽の送り手を防ぐ）を確認することができる。その後、ＳｅＧＷは、ネットワークアクセスおよび装置認証、およびブロックの将来の認証の試みを否定することとなる。

ネットワークアクセスおよび装置認証の否定の場合には、検証と認証が境界ならば、このことは、認証プロセスが壊れることを要求するであろう。

最初の変化では、メーカー、装置バージョンおよび他の属性のような特定の特性にしたがって装置をブラックリストに載せることは可能であってよい。

ＰＶＥは、さらにＤｅｖ＿ＩＤとＴｒＥ情報を使用して、未知のＴｒＥのために、ＲＩＭ更新処理と類似したＶ＿ＤＢ更新処理を最初に引き起こしてもよい。

不良状態Ｆ２については、ＰＶＥは、受信Ｃｌｉｓｔからのすべてのコンポーネント用のＶ＿ＤＢからＲＩＭをフェッチする。検証データベースＶ＿ＤＢは、単に保証されたＲＩＭを格納する。対応するＲＩＭ証明書は、Ｖ＿ＤＢに安全に格納すべきである。

１つの実施形態では、ＲＩＭ証明書は、Ｖ＿ＤＢへの取り込みの前に検査され、廃棄されることができる。あるいは、ＲＩＭ証明書は、セキュリティ目的のために格納されることができる。例えば、ＭＮＯは、ＭＮＯが信頼された第三者からＲＩＭとそれらの証明書を得る際に勤勉に行ったという意味で、監査役（auditor）に装置管理の適合性（compliance）を証明するためにＲＩＭ証明書を使用することができる。

不良状態Ｆ２ａについては、ＰＶＥは、検索されたＲＩＭからの正確な確認データを再計算し、検証メッセージの中で受け取られた確認データにそれを一致させてよい。

計算された正確な確認データが、検証確認メッセージからの確認データと一致しない場合、装置上の安全起動プロセスは危険にさらされる可能性があり、あるいは、間違ったＲＩＭが装置に格納されることがありえ、また、無効なコンポーネントが安全起動プロセスでロードされてしまったかもしれない。ＰＶＥは、失敗したコンポーネントを検知するために、検証メッセージの中で、あるいはＰＶＥからの個別のリクエストに答えて送信される測定値をＲＩＭと比較することができる。

Ｆ２ａポリシーによって、いくつかのオプションは適用可能である。拒絶の場合には、ＰＶＥが、ＳｅＧＷへの検証の結果をシグナルすることができる。ＳｅＧＷは、ネットワークアクセスを否定するか、あるいは隔離ネットワークの中に装置を受け入れることができる。更新版の場合には、確認データ失敗を示す検証結果（Ｔ＿ＰＶＭ）を受け取った後、ＤＭＳが、検証に失敗したコンポーネントを交換するために、管理プロシージャにしたがって管理プロセスを始めることができる。ＤＭＳは、検証が失敗し、装置が再検証するという指標を備えたＴ＿ＰＶＭをＳｅＧＷに転送することができる。ＤＭＳは装置へ正確なＲＩＭを送り、リブートをトリガーすることができる。リブートに際して、装置は、新しいＲＩＭを使用して再認証し、再検証することができる。確認データが再び正しくない場合、装置は遠隔の管理プロシージャによって回復されることができないとしてよい。無限の再起動の繰り返しを防ぐために、遠隔のリブート・トリガーを送る場合、ＤＭＳはタイムスタンプでＤｅｖ＿ＩＤを格納してよい。ＤＭＳが更新を行う命令を再び受信する場合、ＤＭＳは、Ｄｅｖ＿ＩＤが既に格納されているかどうかをチェックすることができる。いくつかの記憶装置のエントリが存在する場合、タイムスタンプは、短いリブートサイクルを示すことができ、それは装置が正常な状態に戻らないことを示す。不良状態のクラスＦ２ａについての記述される方法は、ＲＩＭが検証に使用されない場合に、任意のものとすることができる。

別の変形（バリエーション）では、ＰＶＥは、ＰＣＲ値のような確認データに基づいて、データベースＶ＿ＤＢの特別の部分を使用することができる。その部分はＰＣＲ値による信頼された設定をキャッシュする。ＰＶＥは、有効な設定について、ＰＣＲ値の場合のハッシュ・テーブルのような確認データのテーブルを検索することができる。一致が見つかる場合、検証は直ちに成功することができる。ハッシュ値が同じになる場合、Ｖ＿ＤＢに有効な設定に対する予め計算されたＰＣＲ値を格納することは同じ構成の中で作動している装置のクラスに役立つであろう。ＲＩＭに対するコンポーネントをすべて比較する代わりに、計算上のオーバーヘッドを低下させて検証のプロセスを促進することで、単一の合成ハッシュ値は比較されることができる。

ポリシー不良状態が満たされない場合、装置は有効である。ＰＶＥは、ＳｅＧＷにこのことをシグナルすることができ、それは、ＣＮへの接続を許可することができる。

不良状態Ｆ２ｂについては、ＲＩＭは、信頼された第三者機関（ＴＴＰ）からフェッチされることができる。１つの（あるいは複数の）コンポーネント用のＲＩＭがＶ＿ＤＢに格納されていない場合、ＰＶＥは、ＲＩＭｍａｎに見当たらないＲＩＭのリストを転送する。その後、ＲＩＭｍａｎは、ＴＴＰから（認証された）ＲＩＭをフェッチする。Ｃｌｉｓｔは、コンポーネントインジケータＣＩｎｄ（ＵＲＮのような）を含み、ＲＩＭｍａｎは、そのインジケータによってコンポーネントを識別し、どこで対応するＲＩＭ証明書を見つけるべきかについての情報を得ることができる。ＲＩＭｍａｎは、Ｖ＿ＤＢの中にＲＩＭｃの確認を含む新しいＲＩＭのためのＲＩＭ取り込みを行う。ＲＩＭｍａｎは、ＣＩｎｄ、ＲＩＭおよびＲＩＭｃを格納するＶ＿ＤＢの更新を行う。ＲＩＭｍａｎは、その後、Ｖ＿ＤＢから見当たらないＲＩＭをフェッチすることができるＰＶＥにＶ＿ＤＢの更新についてのシグナルを送る。

代案として、ＲＩＭは装置からフェッチされることができる。装置が、検証メッセージの中で、ネットワークに格納されたＲＩＭｃｓ（ＲＩＭを含む）を供給する能力を示している場合、ＰＶＥは、検証のために欠けているＲＩＭとＲＩＭｃｓを装置に求めることができる。これはＲＩＭのフェッチについての背景方法として適用することができる。装置が安全起動にそれらをすべて使用したので、ＲＩＭはすべて装置の中にある。ＰＶＥがいくつかのコンポーネント用のＲＩＭを見つけることができない場合、ＰＶＥは新しいタイムスタンプを付けられた、見当たらないＲＩＭとＴ＿ＰＶＭのリストをＳｅＧＷに転送する。ＳｅＧＷは、ＲＩＭｃｓを検索する装置でプロトコルを行う。ＳｅＧＷは、タイムスタンプを備えた受信ＲＩＭｃｓをＴ＿ＰＶＭに追加し、Ｔ＿ＰＶＭトークンをＰＶＥに転送する。ＰＶＥは、ＲＩＭｍａｎへ検索されたＲＩＭｃｓを転送する。その後、ＲＩＭｍａｎは、受信されたＲＩＭｃｓが信頼されたエンティティから出されたものであり、また有効であることを確認する。ＲＩＭｍａｎは、Ｖ＿ＤＢの中にＲＩＭｃｓの確認を含む新しいＲＩＭのためのＲＩＭ取り込みを行う。ＲＩＭｍａｎは、Ｖ＿ＤＢの更新を行い、ＰＶＥにＶ＿ＤＢ更新についてのシグナルを送る。ＰＶＥは、Ｖ＿ＤＢから確認されたＲＩＭをフェッチし、検証を続けることができる。コンポーネント用のＲＩＭが検索および取り込みプロセスの後にまだ見当たらなければ、ＰＶＥは、再びＲＩＭｃｓを装置に求めず、ここに記述されるようにＴＴＰからＲＩＭをフェッチする。ＴＴＰの装置から得られるＲＩＭは、電子証明書と同じラインに沿って信頼性について確認されることができる。

ＰＶＭコンポーネント間の信頼モデルは、装置からのＲＩＭ取り込みにおけるアクションのシーケンスを決定する。ＰＶＥは、装置からのＲＩＭ／ＲＩＭｃｓを信頼せず、そのデータの信頼性をチェックした後にＲＩＭｍａｎによってのみ行われる、Ｖ＿ＤＢへのそれらの取り込みを待つであろう。ＰＶＥは、さらにＲＩＭｍａｎのＲＩＭ取り込みオペレーションと同時に、装置受信ＲＩＭに基づいて確認データの再計算を開始するが、ＲＩＭｍａｎのそれらの信頼性に関する決定を待たなければならないであろう。

ＲＩＭｃｓは、それがＣＮ内のみで送られるので完全性が保護された追加メッセージの中で送られることができる。ＲＩＭｃｓを含むメッセージは、Ｔ＿ＰＶＭにリンクすることができる。

装置については、ＲＩＭ取り込みプロセスは外部エンティティによって行われ、装置およびＰＶＭインフラストラクチャの完全な取り込みプロセスまで拡張されることができる。これはＰＶＭアーキテクチャ内の分配されたＲＩＭ取り込みであると識別されることができる。

ＰＶＥからＲＩＭｍａｎまでのメッセージはすべて、メッセージ完全性を保証し、および、例えば正しくない形式のメッセージ攻撃を軽減するためにフォーマットと内容で制限される。本質的に、メッセージは、参照メトリクスが検索されることができる位置を指すコンポーネント用の単一のＵＲＮを含む。

不良状態Ｆ３については、ＰＶＥは、設定ポリシーデータベースＣ＿ＤＢから許可された設定に関するポリシーをフェッチする。この設定ポリシーデータベースＣ＿ＤＢは、Ｄｅｖ＿ＩＤによって許可された設定を含む。Ｃ＿ＤＢはＣＰｍａｎによって管理される。Ｃ＿ＤＢは、分離されてしばらくの間認証されなかった装置のための所望の更新のようなポリシーアクションも含むことができる。ＰＶＥは、Ｃｌｉｓｔの中の情報に基づいて、ＣＰｍａｎから受け取られたポリシーを評価する。評価が不良状態Ｆ３ａかＦ３ｂのうちのいずれかに帰着する場合、このことは認証プロセスを中断することが適用できる。

拒絶については、ＰＶＥは、失敗した設定ポリシーに関するメッセージをＴ＿ＰＶＭに加え、Ｔ＿ＰＶＭにタイムスタンプを付けて署名し、ＳｅＧＷへそれを転送する。ＳｅＧＷは、タイムスタンプ（やり直し防護）と署名（偽の送り手を防ぐ）を確認することができる。ＳｅＧＷは、ネットワークアクセスおよび装置認証（またブロックの将来の認証の試み）を拒否することができる。検証と認証が境界である場合、このことは認証プロセスを中断することができる。

Ｃｌｉｓｔが未知であり、Ｃ＿ＤＢで見つからない（不良状態Ｆ３ｂ）場合、またはコンポーネントのポリシーがＣｌｉｓｔに存在しない（Ｆ３ａの特殊なケース）場合、ＰＶＥは、ＴＴＰからの設定ポリシーを探索するためにＣＰｍａｎを呼ぶ。ＣＰｍａｎが新しい設定ポリシーを検索することができる場合、ＣＰｍａｎはＣ＿ＤＢを更新し、更新された設定ポリシーへのインジケータを備えたメッセージをＰＶＥに送る。

更新版が新しいコンポーネント（Ｆ３ａを参照）を含む場合、Ｃ＿ＤＢとＶ＿ＤＢを一致させておくことは可能であり、このことは、ＣＰｍａｎからＰＶＥまで、新しいコンポーネントの識別子を含めて、シグナルされることができる。その後、コンポーネントのための更新されたＲＩＭあるいは新しいＲＩＭをフェッチするために、ＰＶＥは、ＲＩＭｍａｎへ新しいコンポーネントについての必要な情報を転送する。ここで、コンポーネントＣｍａｎ、Ｃ＿ＤＢ、ＲＩＭｍａｎおよびＶ＿ＤＢが独立して作動するように、設定およびＲＩＭ管理の管理プロセスを区別しておきたい。ポリシーが装置への更新版を要求する場合、ＰＶＥは更新処理を引き起こす。

単純なポリシーの例として、Ｃ＿ＤＢは、許可された設定のリストを含むことができる。ＰＶＥは、ＣＰｍａｎに受信Ｃｌｉｓｔを転送し、ＣＰｍａｎは、格納された許可された設定とそれをマッチさせる。一致が見つからない場合、不良状態Ｆ３ｂが検知される。現在の検証プロセスが装置管理プロセスの間に装置最新版の後の再検証かもしれないので、更新版のチェックは必要であろう。この管理手続中に、装置構成は変わるかもしれないし、Ｃ＿ＤＢからの新しい設定に対して確認されなければならないであろう。

再検証プロセスの一例がここに記述される。装置は、それがネットワークによって認証されたら、電力損失のような予定外の出来事がなければめったにリブート（再起動）されないであろう。装置の再検証は、実行環境のルーチン部分であってよい。周期的な再検証のおかげで、ネットワークは、悪者コード実行の危険が減少した定義された状態で装置が働いているという確信を抱くことができるであろう。再検証は、認証プロシージャが再開することができるようさせ、それによって、鍵交換を新しくし、安全な通信トンネルを再構築できる。装置再検証のための２つのトリガーがあり、１つはネットワークによるものであり、他方はデバイスによるものである。ここに記述された再検証の方法は、検証方法のうちのどれに対しても適用可能である。

装置が開始する再検証の一例がここに記述される。装置が開始する再検証は、周期的な方式で生じてよい。装置の使用頻度によって、ＭＮＯは、装置セットアップ手続の間に周期的な再検証スケジュールを決めることができる。予定された時間に、装置は、認証に加えて、再開する検証プロセスを引き起こすリブート・シーケンスを始めることができる。この時に、ソフトウェア・アップデートが装置に必要な場合、対応するＯＡＭプロセスも開始することができる。装置が所望の時間枠内で再認証／再検証をしない場合には、ＣＮは再検証を引き起こすことができる。オペレータは、装置のみが開始する再検証を備えた再検証プロセスに対するコントロールを有さなくてよい。大量の装置が、月の1日目のような同じスケジュールで実行する場合、このことは、ＣＮインフラストラクチャ上のロードを増加させるであろう。

ネットワークが開始する再検証の一例がここに記述される。ネットワークが開始する再検証は、装置が開始する再検証のケースのような周期的な基準で生じるかもしれないが、しかし、それは、ネットワークがセキュリティの理由で必要であると判断する時はいつでも起こるであろう。装置中のモジュールがプログラムされた間隔で再検証を実行するようにオペレータによってプログラムされるように、再検証は、ポリシーの一部としてオペレータによってセットアップされることができる。再検証は、再検証の要請を示すＩＫＥｖ２メッセージを装置に送ることによってトリガーされることができる。Ｎｏｔｉｆｙペイロードは、装置のための新しく定義された再検証トリガー・コードを運ぶために使用されることができる。

ＰＶＥは、定期的にＳｅＧＷに再検証インジケータを送ることができる。すべての送られた再検証リクエストを追跡し続けるために、ＰＶＥは、ＤＥＶ＿ＩＤとタイムスタンプとともにそれらを格納する。その後、ＰＶＥは、いずれかの装置が再検証リクエストを無視したかどうかを周期的にチェックする。ＳｅＧＷはＩＫＥｖ２プロトコルを介して装置にそのリクエストを転送することができる。再検証メッセージは、サービス中断の危険を減らすように、インストール時のホスティング・パーティの要求に基づいて設定されることができる。

装置は、再検証の要請を示すＮｏｔｉｆｙペイロードを備えたＩＫＥメッセージを受け取る。装置は、リブート・シーケンスを始め、そこで、検証およびネットワークへの認証が再確立される。装置が再検証リクエストを無視するように、装置が危険にさらされる場合、ＰＶＥは、すべてのアクティブな再検証リクエストのモニタリング中にこれを検知することができる。ＰＶＥは、隔離ネットワークに装置を入れることにより適切に作用するＳｅＧＷに失敗した再検証をシグナルすることができる。

ネットワークが開始する再検証のための別の方法は、装置にリブート信号を送ることを含み、リブート信号は、リブート、およびそれによる安全起動中の再検証を引き起こす。

別の方法では、装置の再検証は、他のネットワークエンティティからのリクエストによって生じるのであってもよい。自身の装置が広く危険にさらされたのではないかと装置メーカーが考えれば、メーカーはＭＮＯと連絡をとり、再検証を要求することができる。これは、再検証が生じるかもしれないかどうか決定するＭＮＯを備えたバックオフィス・プロセスとして行われてよい。ＰＶＥまたはＨＭＳは、再検証および再認証を始めることができる。

プラットフォーム管理の一例がここに記述される。ＤＭＳは、装置管理に関与する主なエンティティである。ベンダー、ハードウェア／ソフトウェア構成、ＴｒＥ能力などの、受信され、および格納された装置情報に基づいて、ＤＭＳは、ソフトウェア・アップデート、設定変更およびＯＴＡ装置管理手続きを始めることができる。管理アクションは、送信された検証データ、ＰＶＥからの検証結果、および所望の目標構成のようなＣ＿ＤＢの中のポリシーによって一般に決定される。

ＤＭＳは、装置のＴｒＥを備えた安全なトンネルを確立することができる。ＤＭＳは、装置のＤｅｖ＿ＩＤ、最新の報告された検証データおよびＣｌｉｓｔを検索するためにＴ＿ＰＶＭトークンを使用することができる。Ｄｅｖ＿ＩＤを使用して、ＤＭＳは、ＳｅＧＷに問い合わせを行い、装置のステータスを「アクティブ」から「管理」にセットするインジケータを備えたＴ＿ＰＶＭを送ることにより、装置のＴｒＥへの安全なトンネルを確立する。したがって、ＳｅＧＷは、このトークンを維持し、隔離によってバックホール接続を提供することができず、およびＤＭＳが管理活動の終了を確認するのを待つ。

ＤＭＳによる管理活動次第で、装置は、例えば、ソフトウェア・アップデートの後のリブートによって再検証することができる。その後、再検証は行われてよく、そこではＰＶＭシステム状態は、前の検証からのＴ＿ＰＶＭの使用により維持され、新しいものを生成することはできない。この場合、ＤＭＳは、「管理」から「再検証」に変更された装置状態インジケータと共に、更新されたＴ＿ＰＶＭトークンをＳｅＧＷに送る。ＳｅＧＷは、再検証を待つ装置のリストを維持し、装置がネットワークアクセスを要求する時に装置を調べる。ＳｅＧＷは、装置が一定の期間の間再検証するのを待つことができる。その後、管理プロセスの無事完了を確認するために、再検証の結果は、ＤＭＳにシグナルされる。

再検証の必要は、装置用のシステムモデルの中で発生することができる。ＤＭＳからダウンロードされた新しいコンポーネントは、次の安全起動プロセス後に装置構成に正確に挿入される。したがって、プラットフォーム管理の最終段階として再検証を引き起こすことが必要である。装置がリブートしなければならないので、およびプラットフォーム検証がプラットフォームの認証に更に結び付けられる場合、再検証は、プラットフォームの検証および管理のために既存の接続をカットすることを含むことができる。ＳｅＧＷは、この場合、最終節に述べられているような再検証のための状態を維持することができる。

装置のＴｒＥへの安全なトンネルが確立されると、ＤＭＳは、新しいソフトウェアコンポーネント、変更する設定およびトリガー再検証などのソフトウェア（ＳＷ）コンポーネントをインストール／アンインストールすることができる。

別の変形では、装置は検証メッセージ中のフラグによって再検証を示すことができる。これは、ＳｅＧＷに接近する各装置の再検証リストを調査することを避ける。フラグは、ＴｒＥコンポーネントによって行われるプロセスのような安全なプロセスにセットされることができ、装置は、それをセットしないことにより再検証を回避できない場合がある。

これおよび前のステップはＰＶＥでではなくＳｅＧＷで起ってよい。そうでなければ、ＳｅＧＷは自動的に新しいトークンを生成するであろう。特に、これらのステップは、装置管理で行われるプロトコル・ステップを含み、その中でＳｅＧＷは、装置にリブートを要求する再検証の経過を追わなければならない。装置リブートの後、装置が再接続および再認証を行うので、ＳｅＧＷは、再検証のためにリブートする装置の経過を追わなければならず、さもなくば、ＳｅＧＷは最初の接続としてその接続と認証の試みを考慮することとなり、新しいトークンを出すことになるであろう。したがって、再検証リストのメンテナンスはＳｅＧＷのために含まれている。

再検証の多くのラウンドに関してＴ＿ＰＶＭを連続して使用することは、更新失敗の再発および他のパターンの不規則な振る舞いを検知するのに有用となりうる。

ＤＭＳが装置に新しいコンポーネントをインストールする場合、ＤＭＳからＴｒＥまでの同じ管理メッセージにソフトウェアについてのＲＩＭが含まれることが保証されることができる。ＴｒＥは、ＲＩＭの安全な記憶装置とＲＩＭのローカル管理に関与することができる。必要ならば、ＤＭＳはコンポーネントのインストール後に再検証を引き起こす。新しいソフトウェアについてのＲＩＭはＰＶＥに送られ、ＰＶＥはＶ＿ＤＢにＲＩＭｍａｎを介してそのＲＩＭを格納することができる。ＤＭＳは、ＣＰｍａｎを使用して、設定ポリシーデータベースＣ＿ＤＢを更新する。装置が再検証に従事する前に、新しいコンポーネントについてのＲＩＭは、新しい設定を有効にするＰＶＥのためにＶ＿ＤＢにおいて利用可能になりうる。設定変更の場合には、例えば、ＤＭＳが所与のコンポーネントについてのパラメータを変更する場合、Ｃ＿ＤＢがＣＰｍａｎを介してＤＭＳによって更新されることができる。

ＴｒＥは、安全な更新および管理機能のための安全な実行環境を供給することができる。この機能は、危険にさらされた装置が失敗したソフトウェアまたはコンポーネントの更新の場合のレスキューモードに少なくとも送られるかもしれないことを保証する。フォールバックコード・ベース（ＦＢＣ）は、失敗の場合にはＤＭＳによる装置復帰に使用されることができる。これは、主なコードがＤＭＳ管理法を介して更新されることができる原始状態に装置が戻ることを可能にする。

競合条件を回避するために、再検証は、トークン・パッシング後にＤＭＳからＴｒＥへのメッセージが引き金となって起きうる。そうでなければ、装置は、ＳｅＧＷが再検証の準備をするためにトークンを受け取る前に、再検証しようとすることができる。

別の変形では、ＳｅＧＷは、装置がブラックリストに載せられ、隔離され、インフィールドメンテナンスがトリガーされ、あるいはそれらの組み合わせの後の再検証リスト内の各装置に関する、再検証の試み、あるいは失敗した試みの数「ｎ」を維持することができる。

別の変形の中で、安全なトンネルの確立のための通信機密が、ＳｅＧＷの関与を回避するＴ＿ＰＶＭに含まれ、Ｔ＿ＰＶＭから抽出することができる。

さらなる方法は、装置に接続性を与えずに、有効になることができず、またＰＶＭの中で交換され、更新されることができないコンポーネントをディセーブルにすることとしてよい。本質的に、ＤＭＳは、無効なＣＩｎｄを送りメッセージを再検証することができ、下記に述べられるようなオペレータ・ロックインからの危険を緩和するのを支援する。ＰＶＭは、装置とオペレータの間の「信頼の戦い」をするために使用されることができる。「信頼の戦い」の発生を停止させる異なる方法は利用可能であってよい。１つの例示方法では、装置のコンポーネントは、Ｃｌｉｓｔの中のこのコンポーネントなしで再検証を強要することにより無効になりうる。コンポーネントのための有効な更新が利用可能でない場合、これは当てはまるであろう。別の方法では、ロード・オーダーは強制的に変更されることができる。別の方法では、強制的にパラメータ（それらはＲＩＭに影響を与えるし、影響を与えないかもしれない）を変更する。パラメータの強制的な変更は、検証が失敗したＰＶＥからのもののみではなく、すべての装置コンポーネントについての必要な情報をすべて得ることをＤＭＳに要求する。

ＰＶＭでは、装置へＲＩＭ証明書を送ることは一般に必要ではない。確認と管理は、示されたＰＶＭアーキテクチャにおいて、ＲＩＭｍａｎにあるオペレータ・ネットワークのタスクである。装置は、ネットワークを信頼するので、管理プロセス中の受信ＲＩＭおよびＣＩｎｄを信頼することができる。トラステッドコンピューティング・グループ（ＴＣＧ）モバイル・フォン・ワーキンググループ（ＭＰＷＧ）は、他方では、信頼された装置によるＲＩＭ取り込みを非集中プロセスとして定義し、そこでは、装置は、ＭＴＭによって保護されたＲＩＭについての得られた証明書を、それらをインストールする前に、確認する。両方の変形は相互に排他的だとは限らない。ＤＭＳは、他のデータと共にＲＩＭｃｓを送ることができ、ＴＣＧ ＭＰＷＧ準拠装置は、ＴＣＧ規格にしたがってそれらをインストールすることができる。これは、ＰＶＭと、ＴＣＧ ＭＰＷＧによって定義された安全起動の装置管理の間の相違点であってよい。

確認データの一例がここに記述される。例えば、認証用の確認データをバインディングすることと同様にＰＣＲ値（単一の測定値のハッシュ値を合計したもの）の形式で確認データを送ることは、ＴＣＧ規格によって提供される技術基準である。しかしながら、ＴＣＧ規格に準じた確認データのその生成およびバインディングは、多くの測定コンポーネントを備えた装置上では特に計算上コスト高になりうる。このことは、本明細書に記述された暗号化拡張オペレーション、基本的に、２つの古いハッシュ値から新しいハッシュ値を作成すること、によって通常行われる。これは、例えばホーム環境では望ましくないが、装置の起動プロセスを著しく遅くする可能性がある。

さらに、それらが測定の結果についての同様の情報を伝えるので、ＲＩＭと確認データの間に冗長がある。安全起動プロセスが正確に行われた場合、ＴｒＥは、測定値をＲＩＭと比較し、（両者が一致する）コンポーネントを単にロードする。したがって、Ｃｌｉｓｔの中の指定されたＲＩＭは、確認データの情報をすべて伝える。実際、確認データが言及された測定値を集めたものであると思われるので、指定されたＲＩＭは確認データより多くの情報を伝えることができる。確認データは、実測値の暗号的に一義的な省略表現である。ＰＣＲ値は、一実施形態において確認データとして使用されることができる。

確認データに対する議論の基礎となる基本的仮定は、安全起動プロセスが、実測値をＣｌｉｓｔに示されたＲＩＭと比較する際に正しく動作したということである。したがって、セキュリティの観点からすると、１つの主な理由があるが、それは、確認データが確認中の装置の信頼性を増大したということである。これは、装置に正しくないＲＩＭがある場合、あるいは測定値を偽のＲＩＭと比較する場合のケースである。

高度に保護され、安全起動中に生成され、達成されたシステム状態をユニークに識別するデータという意味において、安全起動、あるいはＡｕＶ（自律的検証）のような単項的アプローチの場合にさえ、確認データを保存するためのさらなる議論がある。この場合、安全起動自体は、単に測定値のないコンポーネントのリストかもしれない他の検証データの完全性保護のためには何もしない。ＣＩｄｓのこのリストは、コンポーネントについての信頼情報をどこで、どのように得るべきであるか（例えばＴＴＰから）をバリデータに伝える。

攻撃者は、検証データ（Ｃｌｉｓｔ）を操作し、それほど信頼できないコンポーネントの確認者をもっと信頼できるもの（「コンポーネントの信頼の高さ」）の（得られた）ＣＩｄｓに取り替えることができる。確認データがない場合に、内部的に操作を検知する手段なしで、検証を行う装置（ＴｒＥ）は改竄されたデータに署名し、正確に有効にする。

ある程度までこの攻撃を緩和する方法は、安全起動エンジンがデータをその状態（最後のＰＣＲ値）に密閉することによりデータを静的にすることである。検証については、その後、密閉を解かれる必要があり、同じセキュリティ・ギャップは再びオープンになる。また、更に、システムはＳＭＬ密閉の後に静的なままでいる必要があり、そのようなアプローチの柔軟性を制限する。

結論として、装置とバリデータの両方は、安全起動の場合においてさえ、確認データで検証データを支援する十分な理由を持っている。

ここで「確認データ（verification data）」は、「その後、ＲＩＭのデータと一致することを確認される、生の測定データからさらに処理されたデータ（例えば、ハッシュ処理）」と同義的に使用される。確認データは、安全起動の完了後、プラットフォームの状態をユニークに識別する。正しくないＲＩＭのプロビジョニングは、例えば危険にさらされたソースからかもしれないし、ＰＶＭシステムに全体としてより大きな影響を及ぼすかもしれず、そのため、重大なリスクをもたらす。

具体的なシナリオは、ＲＩＭの信頼されたソース（それはオペレータのＣＮの外側にあってもよい）が、例えば他のパーティによってハイジャックされたまたはなりすまされて信用できなくなったというものである。このことが検知されて修正される前に、ＲＩＭのソースは、正常なＰＶＭプラットフォーム管理において、信用できなくなったコンポーネントとともに、多くの装置に偽のＲＩＭを配達することができる。

そのような場合（すなわち、公開鍵基盤（ＰＫＩ）中の一般的方法）での一般的な対処法は、一致するＲＩＭ証明書を無効にすることであろう。信頼された参照データが装置上に存在できるので、そのようなプロシージャは装置に負荷を招く可能性がある。ごく一部分だけが攻撃によって影響を受けるとはいえ、一方で、信頼された参照値（ＴＲＶ）の取り消しは、ＲＩＭ、ＲＩＭｃおよびコンポーネントを装置全体についてアップデートすることを余儀なくさせうる。これは、ネットワークトラフィックが大量に消費され、ユーザに不便を引き起こすであろう。認可されたＴＲＶの取り消しが実行されうるように、メカニズムとプロトコルは装置によってサポートされる。

このシナリオでは、検証における確認データの生成および使用は適用可能であってよい。ＰＶＭシステムは、それぞれの検証装置について、ポリシーに基づいて確認データの使用を起動することができる。その後、プラットフォーム検証エンティティ（ＰＶＥ）は、危険にさらされた装置を検知し、それらだけを管理することができる。これは、「最小の検証ポリシー」として本明細書に記載される。

ＰＶＭの一例のトークン・パッシングに基づいたオペレーションがここに記述される。ここに記述されるようなＰＶＭは非同期処理である。したがって、様々なエンティティによって含まれるＰＶＭシステムは、処理状態を把握する（stateful）べきであり、分散システムとそれらの不良状態に対する様々な既知の攻撃を緩和するために、プロセスの現状を回復することは可能であるべきである。

一例において、トークン・パッシングは、これをするために使用されることができる。ＳｅＧＷは、検証プロセスにユニークに関連したトークンの生成および管理に関与するエンティティとして構成されることができる。ＰＶＭトークンは、有効なＴｒＥのアイデンティティに結合されるだけでなく、問題になっているユニークな検証プロセスに結び付けられることができる。トークン・パッシング・アプローチは、やり直し／再検証保護を含む。検証の試みは、古い検証の一義的なやり直しを防ぎ、頻繁な再検証によるＤｏＳ攻撃を検知する手段を提供する。トークンによって、検証セッションは確立され、ＰＶＭ関連データおよび一義的な検証へのメッセージの一義的な関連付けを可能にさせる。これはさらに新鮮性を評価する必須条件である。

検証トークンは、（必ずしも署名される必要はない）タイムスタンプに基づいて作られることができるが、それらはＳｅＧＷによって最初に生成され、その検証トークンを通すすべてのエンティティによって時間順序付きリストに追加されるので、検証データの新鮮さはコントロールされることができる。

新鮮さを導入する別の方法は、ＲｏＴがロードされた直後に安全なリアルタイムコミュニケーション（ＲＴＣ）から時間を読み、このタイムスタンプを使用して集約されたハッシュチェーンを作成することでありうる。別の選択肢は、あらゆるリブートサイクルでインクリメントされ、ハッシュチェーンを作成するためにＲｏＴによって適用されるシーケンスカウンタを使用することでありうる。

しかし、新鮮を導入する別の方法は、ステージ１およびステージ２チェックを完了し、ＳｅＧＷとＰＶＥとの通信を始めて、次に、ＳｅＧＷにステージ３検証データの結果を伝える前に、ステージ３チェックのさらなる検証に結び付けるためにＳｅＧＷ／ＰＶＥによって供給されるノンスを使用することである。これは、検証データの新鮮さを保証する。

再検証の多くのラウンドに関してＴ＿ＰＶＭを連続的に使用することは、標準ＰＶＭでのように、繰り返される更新失敗および他のパターンの不規則な振る舞いを検知するのに有用である。ＳｅＧＷは、検証トークンに基づいて様々な条件で検知し作用することができる。例えば、あまりに長い間アクティブであり続けるトークンは、ＰＶＭの一般エラーを示すかもしれない。ＳｅＧＷは、トークンがそのステータスを見つけ出し、かつそれに作用するためにＰＶＥとＤＭＳをポーリングすることができる。これは検証タイムアウトとして識別されることができる。別の例で、トークンがアクティブな間、再検証が生じる可能性がある。これは、予期しないリブート、停電あるいはＤｏＳ攻撃のような様々な条件を示しうる。別の例において、ランダムまたは周期的行動のような時間ベースのパターンは、侵入検知システム（ＩＤＳ）のフローにおいて検知されることができる。装置は、隔離され、ブラックリストに載せられ、また、インフィールド保守は起きてよい。

トークンはまた、ＰＶＭシステムでのエンティティ間、およびＰＶＭシステムと装置間で渡されたデータの完全性を保護するために使用されることができる。これについては、保護されるデータのハッシュ値を例えばＣｌｉｓｔに、あるいは不良状態Ｆ２ａの処理での見当たらないＲＩＭおよびそのデータへのポインタのリストに含めるために十分であってよい。このデータオブジェクトは、Ｔ＿ＰＶＭに過負荷をかけ、無数のオーバーヘッドに結びつくかもしれず、そして実際にあるＤｏＳ攻撃を可能にするかもしれないので、Ｔ＿ＰＶＭに全体として含まれないかもしれない。

オペレータＲＩＭ保護方法の例がここに記述される。オペレータＲＩＭ保護は、様々な外部ソースから来る装置コンポーネントについての多数のＲＩＭ証明書を、オペレータあるいは同等のものとしてＳＨＯ（selected home operator）（装置はそれとバックホールリンクを確立したい）によって生成されるＲＩＭ証明書と交換する。利用可能な場合は常に、これらのＳＨＯＲＩＭ証明書（ＳＨＯＲＩＭｃ）は、検証において、Ｖ＿ＤＢの中の同じコンポーネントの外部のＲＩＭ証明書に優先する。装置管理では、ＳＨＯＲＩＭは、ＤＭＳによって装置にインストールされ（押し下げられ）、ＴｒＥによる装置の安全起動において装置上のローカルな外部の証明書に優先する。

ＳＨＯＲＩＭｃは、検証中のＲＩＭ証明書をフェッチするための「第1レベルのキャッシュ」としての機能を果たすことができる。それらは、Ｖ＿ＤＢの技術的に分離された、高機能の、サブデータベースを本質的に指す特別のＣＩｎｄに関係しうる。

オペレータＲＩＭ保護は、Ｍ２ＭＥ（M2M equipment）のような任意のタイプの高度なモバイル装置に役立つ。モバイル装置が新しいオペレータの領域に入り、検証を行う場合、新しいオペレータは、別のオペレータを指すＣＩｎｄを提示されることができる。ここに記述されるように、それはモバイル装置のローミングと類似したやり方でこれらを受理するか、あるいはそれらを交換することができる。

オペレータＲＩＭ保護の変形の中で、ＳＨＯがＳＨＯによって生成されたＳＨＯＲＩＭｃの署名鍵の公開部分をリリースしないことを決定する場合、そのＳＨＯから来る装置のコンポーネントを他のオペレータが有効にすることは困難であり、あるいは不可能かもしれない。そのようなスキームは、従来のＳＩＭロック手続きが提供する制約の同じレベルまで拡張されることができる。オペレータＲＩＭ保護は、ライフサイクル管理手段としてＳＨＯとの第１の接触で遠隔に「ブランド」装置へのフィールドで装置の最初の配備の中で使用されることができる。

ＰＶＭに基づいてオペレータＲＩＭ保護を確立するために、次の追加のステップは上記されたオリジナルのＰＶＭプロシージャを参照して記述される。ＲＩＭ保護用のＰＶＭセットアップでは、ＲＩＭｍａｎは、オペレータＲＩＭ保護のためのそれぞれの機能を行うためにＰＶＥとＤＭＳを構成する。プラットフォーム検証では、ＰＶＥは、ＳＨＯＲＩＭが今、Ｖ＿ＤＢの中にあるコンポーネントのリストを含むメッセージを（コンポーネントの有効性に関するメッセージと別々に、または結合して）送る。ＤＭＳは、そのために装置に新しいＳＨＯＲＩＭｃがインストールされるコンポーネントに対して（必ずしもコンポーネント自体を更新することなく）証明書更新アクションを行うように構成される。

検証中に、ＰＶＥは、ＳＨＯＲＩＭがＶ＿ＤＢ（これは、正常なＰＶＭプロセスのように、コンポーネントの任意のＲＩＭおよびＲＩＭｃの有効性（availability）に直交である）の中にないコンポーネントを識別する。ＰＶＥは、オペレータＲＩＭ保護についてのＣＩｎｄおよび実際のＲＩＭ（ＲＩＭｍａｎは、基本的にそれらへの署名により対応するＳＨＯＲＩＭｃを生成するためにそれらを必要とする）を含む、識別された候補コンポーネントのリストをＲＩＭｍａｎに送る。ＲＩＭｍａｎは、受信されたリストのどのコンポーネントがオペレータＲＩＭ保護を利用するかについて決定するために、ローカルに利用可能なポリシーを決める。

ＲＩＭｍａｎは、それぞれのＲＩＭを署名することによりこれらのコンポーネント用のＳＨＯＲＩＭｃを生成する。有効期間のような証明書パラメータは、ローカルオペレータポリシーによって決定される。ＲＩＭｍａｎは、Ｖ＿ＤＢの中のＳＨＯＲＩＭｃを指すＳＨＯＣＩｎｄを生成する。ＲＩＭｍａｎは、新しいＳＨＯＲＩＭｃおよびＳＨＯＣＩｎｄを備えたＶ＿ＤＢを追加する。１つの実施形態では、「古い」データはすべて、後の追跡可能性用に、およびフォールバックとして、Ｖ＿ＤＢの中のオリジナルのＣＩｎｄおよびＲＩＭｃのように保存される。ＲＩＭｍａｎは、ＤＭＳにペアの（ＣＩｎｄ、ＳＨＯＣＩｎｄ）リストを送り、問題の装置にＲＩＭインジケータをアップデートさせるようにＤＭＳに命じる。正常な装置管理での、だがコンポーネントのアップデートなしでのように、ＤＭＳは装置ＴｒＥにＳＨＯデータを備えたＲＩＭインジケータ更新メッセージを送る。このメッセージで、装置は、ＤＭＳによって検証の中でＳＨＯＣＩｎｄだけを今後使用するように依頼されることができる。

ＳＨＯＣＩｎｄのインストールとは別に装置上で起こること、およびＳＨＯＲＩＭｃかもしれないことは、ローカルのポリシーに依存する。クレバーな装置は、その正規メーカーのＣＩｎｄおよび恐らく対応するＲＩＭｃを維持する。柔軟性については、それは、様々なオペレータおよびオリジナルのコンポーネントのメーカー／保証人のために、少なくとも各コンポーネントの異なるＣＩｎｄの数を維持しようとすることができる。

ＤＭＳは、装置の処理状態を把握する再検証（stateful revalidation）を強要することができる。処理状態を把握する再検証は、ＲＩＭｃ更新が装置上で失敗する場合に、周期的挙動（cyclic behavior）を回避するように要求される。

オペレータのコンポーネントのロックインの一例がここに記述される。オペレータＲＩＭ保護の拡張のように、オペレータは、外部ネットワーク中の装置あるいはそのコンポーネントのオペレーションをコントロールするか制限することができるてもよい。これは、次の方法でオペレータのコンポーネントのロックインに拡張することができる。ロックされるコンポーネントの一部は、ＳＨＯによって、例えば対称鍵で暗号化される。オペレータＲＩＭ保護は、この修正されるコンポーネントのために行われる。復号キーは、保護され抑制されたスペース（それは単にＳＨＯから認可でアクセスされるかもしれない）でＴｒＥ（あるいはＵＩＣＣ）に転送される。検証の中で、ＰＶＥがそのようなコンポーネント用のＳＨＯＩｎｄで提示される場合、ＳＨＯはＴｒＥに認可データをリリースする。その後、コンポーネントの暗号化された部分は、ＴｒＥの安全な実行スペースへ転送され、解読され、そこで実行される。

従って、同じ装置が他のオペレータに対して有効にすることができないかもしれない間に、装置が特定のＳＨＯに対して有効にする場合のみ、ＳＨＯにロックされたコンポーネントは機能することができる。

一層の変形では、解読された部分は、ＴｒＥに外部での実行のためにリリースされる。十分なコンポーネントが装置メモリのダンプにより回復されるかもしれないので、これは前の変形よりセキュリティの点からより弱い。得られた明瞭なコンポーネントで、ＲＩＭは再生成されることができ、および別のオペレータに対する検証は成功することができ、ロックインを壊す。

コンポーネントのロックインの別の変形の実施形態は、ＴｒＥの中で管理されるか、ＵＩＣＣ（Universal Integrated Circuit Card）のような他のセキュリティ要素によって保護される暗号化秘密なしで実行されることができる。オペレータ一義的なＳＨＯＲＩＭ、ＳＨＯＲＩＭｃおよびＣＩｎｄを生成するためにコンポーネントの修正を使用することができる。これは、コード難読化（code obfuscation）および透かし（ウォータマーキング）の分野に適用することができる。

オペレータのコンポーネントのロックインの１つの例は、もう一人のオペレータのコンポーネントあるいは全装置をハイジャックするローミング・オペレータを含むことができる。このことから他の無料ユーザの装置を保護する、上記のＴｒＥベースの方法は望ましい。本質的に、装置は、そのようなプロシージャのユーザ／ホストパーティ／オリジナルのＳＨＯに警告し、コンポーネントのロックインをいつ許容し、およびいつ許容しないかのポリシーを維持するべきである。

特定のＰＶＭシステムおよびオペレータの特性に関してＰＶＭを使用する装置管理における装置の個別化のための一例の方法が、本明細書に述べられている。ＰＶＭで管理される装置は、特定のＰＶＭシステムおよび管理するオペレータと関連して信頼できる状態にあるだろう。ローミング装置で生じるかもしれない疑問は、それらが別のＰＶＭシステムおよびオペレータの領域に入る場合に、当該装置が、誰がその構成および信頼性を以前に管理したことがあるかを証明することである。装置の独立した手段がそのエンドに証拠を提供することを可能にする一例の方法は、装置へのアドレッシングが署名されたデータを装置に提供することである。メッセージのこの個別化は、送信者による故意の署名を証明する。１つの方法はオペレータによって署名されたデータにＤｅｖ＿ＩDを含めることであってよい。そのような署名されたデータが提示されうるパーティは、対応するメッセージおよびその内容が署名オペレータによって特にその装置用に意図されたと考えてもよい。これは、署名オペレータが装置の信頼性の確認を（例えば、Ｄｅｖ＿ＩＤを介して）正確に行ったと依存パーティ（relying party）が信じるという条件の下で有効である。これが維持可能でない場合、署名オペレータは、Ｄｅｖ＿ＩＤの十分な認証信用証書に代わりに署名することができる。署名されたデータは、Ｄｅｖ＿ＩＤで拡張される別のＲＩＭｃを基本的に確立するので、実際のＲＩＭも含むことができ、ある冗長性をもたらす。

ＰＶＭに基づいた個別化を確立する効率的な２つの方法が記述される。１つの方法では、ＲＩＭｍａｎはＳＨＯＲＩＭｃにＤｅｖ＿ＩＤを含むが、これは、ＲＩＭｃが装置によって維持され、従って、ＳＨＯＲＩＭｃがＤｅｖ＿ＩＤを含んで装置内に格納される場合のみ適用可能である。別の方法では、ＲＩＭｍａｎまたはＤＭＳは、（Ｄｅｖ＿ＩＤ、ＣＩｎｄ）ペアにオペレータ署名を適用し、また、ＳＨＯＣＩｎｄが使用される場合に、ＳＨＯＣＩｎｄに同じオペレータ署名を適用する。

装置をブラックリストに載せる例がここに記述される。装置についてのブラックリストを確立し、ブラックリストに基づいてネットワークアクセスを許可しないことは可能であってよい。ブラックリストはＤｅｖ＿ＩＤおよび随意的にＴｒＥ情報（証明、型、メーカー、モデル、通し番号）を少なくとも含むことができる。そのようなリストは典型的にはＤＭＳによってアクセス可能であろう。１つの実施形態では、全てのＭＮＯはそれ自身のブラックリストを維持し、ＤＭＳはこのリストまたはデータベースにアクセスすることができる。クエリは、Ｄｅｖ＿ＩＤを使用して所与の装置がブラックリストに載せられたかどうかを調べる。そして、ネットワークアクセスはこれらの装置に対して拒否される。別の実施形態では、グローバルなブラックリストは維持されることができるが、そこでは、全てのＭＮＯは装置を不良（rogue）としてリストすることができ、このデータベースはすべてのＭＮＯによって読まれることができる。全てのＭＮＯがそれら自身の装置をブラックリストに載せ、その一方でＭＮＯがすべてのエントリを読むことができることが保証されるに違いない。そのようなグローバルなデータベースは、もっと管理とメンテナンスの努力を要求する。上記の実施形態は、代替実施形態のために組み合わせられてよい。

ＰＶＥがトークンＴ＿ＰＶＭを受け取る場合、ＰＶＥはＴ＿ＰＶＭにタイムスタンプを追加し、ＤＭＳへそれを転送するが、ＤＭＳは、トークンからＤｅｖ＿ＩＤを抽出し、オプションでＴｒＥ情報を得ることができる。Ｄｅｖ＿ＩＤ（および、もし必要ならば、または存在すれば、ＴｒＥ情報）を使用して、ＤＭＳはブラックリストに問い合わせる。装置がブラックリストに載った場合、ＤＭＳは、ブラックリスト・エントリとしてＴ＿ＰＶＭを含むメッセージをＳｅＧＷに転送する。メッセージは、ＤＭＳによるタイムスタンプを備えることができる。ＳｅＧＷは、ＣＮへのアクセスを拒否することができる。

さらなる変形は、ＴｒＥ情報フィールドからの拡張情報の使用により実行されることができる。それは、あるベンダー、モデル、シリアル番号の範囲などをブラックリストに載せることであってよい。ブラックリストの振る舞いの複雑さによって、ローカルのＭＮＯ中心の解決法は、中央のブラックリストよりも実行するのがより簡単であろう。

装置をホワイトリストに載せる一例が本明細書に記述される。ホワイトリストに基づいたネットワークアクセスを許可する装置用ホワイトリストが確立されることができる。ホワイトリストは典型的には、Ｄｅｖ＿ＩＤ、および型、メーカー、モデル、シリアル番号のようなオプションのＴｒＥ情報を少なくとも含むことができる。そのようなリストは典型的には、ＤＭＳによってアクセス可能であろう。

ＰＶＥがトークンＴ＿ＰＶＭを受け取る場合、ＰＶＥはＴ＿ＰＶＭにタイムスタンプを追加し、ＤＭＳへそれを転送する。ＤＭＳはトークンからＤｅｖ＿ＩＤを抽出し、随意的にＴｒＥ情報へのアクセスを獲得することができる。Ｄｅｖ＿ＩＤおよびオプションでもし必要ならば、あるいは存在すれば、ＴｒＥ情報を使用して、ＤＭＳはホワイトリストに問い合わせる。装置がホワイトリストに載せられる場合、ＤＭＳは、Ｔ＿ＰＶＭおよびホワイトリスト・エントリを含むメッセージをＳｅＧＷに転送する。メッセージは、ＤＭＳによるタイムスタンプを備えることができる。その後、ＳｅＧＷは、ＣＮへのアクセスを許可することができる。

さらなる実施形態は、ＴｒＥ情報フィールドからの拡張情報の使用により実行されることができる。それは、あるベンダー、型、シリアル番号の範囲などをホワイトリストに載せることが可能であってよい。ホワイトリストの振る舞いの複雑さによって、ローカルのＭＮＯ中心の解決法は、中央のホワイトリストより実行するのがより簡単であってよい。さらに、調整装置（regulator）は、ホワイトリストの代わりにブラックリストを維持することをＭＮＯに要求してもよい。

別の実施形態では、すべてのＭＮＯはホワイトリストまたはデータベースを維持することができ、ＤＭＳはこのリストにアクセスすることができる。クエリーは、Ｄｅｖ＿ＩＤを使用して所与の装置がホワイトリストに載せられたかどうかを調べることができる。そして、ネットワークアクセスはこれらの装置に与えられることができる。

また別の実施形態では、グローバルなホワイトリストが維持されることができ、そこでは、すべてのＭＮＯは、それ自身の装置を信頼されるものとしてリストすることができ、このデータベースはすべてのＭＮＯによって読まれることができる。すべてのＭＮＯはそれ自身の装置をホワイトリストに載せることができるにすぎないが、一方、すべてのＭＮＯはすべてのエントリを読むことができるということが保証されるに違いない。そのようなグローバルなデータベースは、より多くの管理およびメンテナンス努力を要求することができる。ホワイトリストに載せられた装置のグローバルなデータベースは、ＭＮＯに対してＭＮＯ間の追加の信頼関係を築くことを要求することができる。ＭＮＯ Ａによって信頼できると考えられる装置はホワイトリストに入り、ＭＮＯ Ｂにアクセスするであろう。これは、装置の信頼レベルを比較するために、標準化された、および／または保証された装置検証プロセスを必要とする。オプションで、上記の変形の組み合わせは実行されることができる。

装置用の隔離ネットワークの一例がここに記述される。装置用の隔離ネットワークはオペレータのネットワークへの追加の変更を要求して確立されることができる。この新しいネットワークでは、ＳｅＧＷは、ＣＮのための施行障壁として働くであろう。ＳｅＧＷは、どの装置が隔離ネットワークに入れられるかを決定する。

隔離ネットワークにある装置はＣＮに対して直接アクセスできず、顧客に対してサービスを提供しない、あるいは制限のあるサービスを提供する。確認データがＰＶＥによって評価される場合、検証が生じる。新しいアクションは評価の結果に依存して引き起こされうる。例えば、装置は、信頼できると考えられることができ、ＣＮに接続することができる。別の例では、装置は、危険にさらされ、および修正不能であるとして検知されることができる。その装置はブラックリストに載せられ、さらなるアクセスの試みがブロックされる。さらに次の例では、ＳｅＧＷは、検証の結果をＤｅｖ＿ＩＤおよびＴｒＥ情報と一緒にＤＭＳに転送する。ＤＭＳは、装置を回復するために適切なアップデート／ソフトウェア変更を提供することができる。ＳｅＧＷは、アップデートに関して通知されることができ、および装置の再検証を引き起こす。アップデートが成功裡に適用される場合、検証は成功し、ネットワークアクセスが与えられることができる。

上記のブラックリスト方法は隔離ネットワークと共に使用されることができる。これは、オペレータに、できればＯＴＡの上でアップデートを供給することによってのように装置への接続を利用することを可能にさせることができる。あるいは、ブラックリストは、装置を完全にブロックするために使用されることができる。例えば、ＯＴＡ手段によって装置を回復することができない場合に。そのような装置は、インフィールド交換／サービスによって管理されなければならない。

他の装置は、それらがグレーリスト上にある場合、隔離ネットワークに入れられる。グレーリストは、例えば、ネットワークに対して新参の装置（別のＭＮＯから来る装置）、長期間接続されていなかった装置、疑わしい振る舞いを備えた装置、およびセキュリティ警告（ベンダーおよび独立した研究者による）が存在する装置、を含む。

パラメトリック検証の例がここに記述される。ＰＶＭの間、ロードしたコンポーネント用の設定パラメータについての確認結果の依存があってよい。これらのパラメータが頻繁に変わるかもしれないし、そうでなければ等価な装置間において異なるかもしれないので、ＰＶＭの基礎的な実施形態は、パラメータが検証中に明瞭にされることを可能にする。しかしながら、ＰＶＭの基礎的な実施形態は、十分なパラメータ・データベース、並びに装置上およびバリデータ側の両方の記録を維持することを要求できる。ＰＶＭの基礎的な実施形態は、次のような影響があろう：１）パラメータ・セットは、大きなデータベース・スペースを占有し、評価される場合に検証を遅くする可能性がある、および、２）装置ごとに格納され評価される多数のパラメータは、万一それが外部で漏れれば、装置構成についての多くをサードパーティに公開する可能性がある。

ＰＶＭプロセスにパラメータを含める１つの方法は、ハッシュ値を拡張する（つまりコンポーネントの測定値へのパラメータのハッシュ関数結果の連結によって）方法に基づく。パラメータダイジェスト値は、コンポーネントのパラメータ値の連続および２進法の表現で得られ、そのコンポーネントの既存の測定値はこのパラメータダイジェスト値によって拡張される。従って、検証については、全ての測定値および基準値（ＲＩＭとＲＩＭｃ）は、パラメトリック検証の様々な実施形態に結びついて、類似した方法で扱われうる。

証明書（例えばＸ．５０９）および属性証明書（例えば、パラメータとの類似で見られる属性）の関係中の同様の問題（それらは参照メトリックおよびＲＩＭｃにパラメータを含めることにより解決されうる）は、「属性証明書のための装備されたハッシュ値」としてここに表示される。

診断の検証（diagnostic validation）の例がここに示される。ＰＶＭ概念に基づいた検証のための実施形態は、コンポーネントが装置にＲＩＭを持たずにロードされることを可能にするオプションを含む。セキュリティ面で重大でないソフトウェアが展開されてしまったこと、および特定のコンポーネントをロードすることは十分に安全であるが、ネットワークは変更に気づいている必要があることは起こりうるかもしれない。別の実施形態の中で、ＭＮＯが、あるコンポーネント（例えば頻繁な変更のために）が常に装置によって測定されるポリシーを確立する場合、検証はネットワークによって行われる。更に、これは、未知のコンポーネントをロードし測定し、かつネットワークに検証タスクを残す装置のためのデフォルト・アクションであってよい。ネットワークは装置を隔離することができてよく、それは、次には装置の遠隔のＯＡＭ修理を可能にする。例えば、それは原始の状態（コンポーネントの除去）に返るか、あるいは他の手段を取ってよい。

不良状態Ｆ２ａのＰＶＭ診断の一例がここに記述される。ＰＶＥがＦ２ａを失敗するコンポーネントのリストをＤＭＳに送信しない場合、失敗したコンポーネントは以下のように見つかるであろう。例えば、装置は、ＲＩＭと比較するためＰＶＥに示されることができるＳＭＬを維持しないであろう。この場合、ＤＭＳは、失敗した装置上のコンポーネントを（ＤＭＳはそれらを知らないかもしれないので）実際に交換することを省略することができるが、Ｃｌｉｓｔの中のコンポーネントすべてを正常な管理プロシージャ中の正確なもので単に置き換えることができる。再起動と再検証においては、ロードされなかったコンポーネントが内部検証に失敗したので、装置は、ロードされなかったコンポーネントのリストも検証メッセージに含めることができるであろう。ＰＶＥは、前の検証のＣｌｉｓｔをＲＩＭアップデート後のものと比較することにより、さらにこの診断をすることができる。現在見当たらないコンポーネントは、正確なＲＩＭに対してローカルに確認された時、安全起動でロードされなかった。したがって、見当たらないコンポーネントは、交換を必要とするコンポーネントである。その後、実際の交換を必要とするコンポーネントは、別の管理サイクルの中で交換されることができる。

装置が、コンポーネントがロードされることができなかった（例えば、ＲＩＭが見当たらない、あるいは誤っている）と報告し、およびＣＮにコンポーネントの測定値を送る場合、診断の検証を行う別の方法は可能である。ＭＮＯのポリシーに応じて、ＯＡＭ修理プロセスは、コンポーネントを削除するか、あるいは修理するためにトリガされることができる。異なる変形の実施形態は、コンポーネント用のＲＩＭが見当たらないか間違っていることをＴｒＥが検知する場合に、装置がＯＡＭ修理を直接要求することを可能にする。

さらなる方法はコンポーネントを無効にすることができるが、そのコンポーネントは、有効にならず、および装置に対する接続性を拒否することなくＰＶＭの中で交換される／更新されることができない。この場合、ＤＭＳは、コンポーネントのメッセージ「ＣＩｎｄを無効にする（disable CInd）」を送ることができ、および装置の再検証を引き起こす。未知のコンポーネントがロードされる場合、これは当てはまるであろう。

別の方法は、どのコンポーネントが特定の装置上で許可されるかをＤＭＳに明示させることができる。装置が許可されない（例えばセキュリティ欠陥が最近発見されており、アップデートがまだ利用可能ではないので）コンポーネントを含む全てのコンポーネントを安全起動中にロードし有効にする場合、ＤＭＳは、このコンポーネントを無効にすることを可能にする装置にＳｅＧＷ経由でメッセージを送ることができる。装置は、再検証することを要求される。コンポーネントが再検証中にロードされない場合、ＤＭＳは、ＳｅＧＷにこのことをシグナルする。ＳｅＧＷは、認証／検証が完了することを可能にする。

最低限の検証ポリシーの例がここに記述される。起動時間中のコンポーネントの測定（例えば、ＰＣＲ値を拡大すること、およびＣｌｉｓｔが生成されるＳＭＬに測定値を書くこと）が起動プロシージャにおいて幾分の遅延をもたらすので、最低限の検証スキームは、ある状況の下でのみ装置検証を要求するであろう。ＲＩＭおよび格納された測定値（例えばＰＣＲ値）が部分的に同じあるいは重複情報を伝えるので、この重複情報の除去は、メッセージおよびストレージ容量を節約することができる。

ローカルの完全性測定、確認および施行プロセスが装置上で（例えば、１つの安全起動によって）確立されうる場合、確認データ（例えば、ＰＣＲ値）がＲＩＭ自体と同じ情報を含んでいるかもしれないので、このローカルの確認プロセスの中で使用されたＲＩＭだけを送ることは十分かもしれない。最低限の検証は、確認データを送るだけではなく、ローカルの確認プロセスの中で使用される基準値だけを送ることができる。別の変形では、ＲＩＭを送る代わりに、ＲＩＭが固有の識別子を持つ場合、およびその場合のみ、ＲＩＭにインジケータだけを送ることは可能であってよい。

最低限の検証用の２つの必要条件は、１）局所測定、確認および施行（ＭＶＥ）プロセスは信頼できること、および、２）装置上に格納されたＲＩＭのためのＲＩＭソースは信頼できること、を含む。評価用の外部エンティティにローカルのＭＶＥプロセス用の確認データを報告することは可能であってよい。これは信頼の明示的な確立のためのものである。それを危険にさらすことができないように、ＭＶＥプロセスが実行されることができる。装置が後でＲＩＭに報告するという事実は、ＭＶＥプロセスが信頼できることを示唆する。これは信頼の暗黙の確立のためのものである。

報告されたＲＩＭの信頼性を評価するために、ベンダー、他のＭＮＯ、ＴＴＰおよび他のパーティによって署名されたＲＩＭ証明書は、代わりに送られることができる。ＲＩＭ証明書の署名者が信頼できれば、ＲＩＭが信頼できると考えられる。報告されたＲＩＭのうちのどれも信頼することができない場合、装置を隔離ネットワーク中に置くこと、あるいはブラックリストに載せることなどの手段は適用されることができる。

調節は、効率を獲得するためにＲＩＭおよび確認データの冗長部分に行われることができる。例えば、装置はある状態中にのみ、あるいはある周波数でのみ確認データを運ぶように要求されることができる。例えば、危険にさらされたＲＩＭがＰＶＭシステムによって検知されている場合、新しい装置はこのオペレータ領域へローミングし、あるいは、ＳＨＯはしばらくの間この装置を見ていない。別の例において、確認の配信は、すべての「Ｎ」検証の中で一度だけ必要であってよい。

修正の例が、ＰＶＭとともに使用するためにここに記述される。修正（すなわちソフトウェア・アップデート）は、装置の継続サービスのための必要なオペレーションとすることができる。装置が修正を必要とする可能性のある多数の理由がある。ソフトウェアアップグレード、バグフィックスおよび拡張の定期保守に加えて、修正は装置の一般的なセキュリティ・プロセスの不可欠な部分とすることができる。検証プロシージャ中に、装置上のソフトウェアはその完全性のために測定され確認される。これらの測定はＴｒＥにあるＲＩＭと比較される。確認が失敗する場合、コードは改ざんされ、あるいは、ＲＩＭはその特定のコード・ベースには正しくない。修正手順は、コード・ベースあるいはＲＩＭのいずれかを更新し、装置の適切な検証を保証するために、開始されることができる。

１つ以上のコンポーネントについての装置の完全性チェックが失敗する場合、これは、それらのコンポーネントが危険にさらされるか、または対応する信頼された基準値が装置上のコード・ベースと協調せずにあることを示唆する。修正手順は、装置がＳｅＧＷに認証することができないことをＣＮに少なくとも示し、かつインストールされたコード・ベースに対応するコード・ベースあるいは新しい信頼された基準値のネットワークによって開始されるアップデートを恐らくさらに促進するために開始されることができる。修正がＳｅＧＷによってＤＭＳと装置の間に生じうる。

任意の修正の開始については、いくつかの共通のセキュリティ要件が適用される。それらの要件は、失敗が生じるセキュアスタートアッププロセスのステージによって決定される。考慮される最悪の場合は、ＴｒＥが構築されるが外部エンティティに対して何ら接続していないことを示すセキュアスタートアップのステージ２の失敗である。したがって、装置は、通常のスタートアップにおいて、この状況の中で修正を要求することはできない。ＦＢＣのような付加的なコード・ベースは、ＴｒＥに安全にロードされ、および修正を行うために使用されることができる。そのようなプロセスのセキュリティは以下のことが特徴である：１）ＦＢＣは完全にロードされ、ＴｒＥに変更されなくてよい；２）ＴｒＥはＦＢＣを安全に実行することができる；３）ＤＭＳのようなネットワークエンティティとの修正のための通信は、完全性と秘密のために保護されうる；４）ネットワークへの修正アクセスのための認証情報は、プロセスの全体にわたって保護されうる。あるいは、ＦＢＣは、ＴｒＥにロードされる必要はない。ＦＢＣは、例えば、修正専用の別の（信頼された）コード・ベースとして、ＴｒＥとともに共存することができる。ＦＢＣにおける信用は、それが保護された記憶装置に格納されるか、またはＨＷで保護された秘密によって保護されるという事実によって導かれるだろう。そのため、ＴｒＥはＦＢＣを実行するためには必要ではないであろう。ＦＢＣは、自立できるかもしれないし、ＴｒＥの確立なしで直接実行することができる。

装置によって開始される修正の一例がここに記述される。装置検証の範囲内で、修正は、エラーを検知時に装置を直ちに隔離することの代わりになるだろう。自律的検証の場合には、ＴｒＥが確認された最初のステージである。それが正確に確認される場合、それは、装置がセキュアスタートアップの所定の状態を達成したことを示す。このことが暗に示すのは、ＴｒＥが信頼できる、また、ＴｒＥに格納されたＲＩＭは信頼できるということである。しかしながら、それは、ＲＩＭが装置上に現在ロードされているコードの特別のバージョンについては正確であることを示さないであろう。

ネットワークによって開始される修正の一例がここに記述される。自律的検証の場合には、装置が検証プロシージャに失敗する場合、ＦＢＣは、開始されて、ＲＩＭを含む主なコード・ベースのソフトウェア・アップデートを引き起こすことができる。装置は、装置がフォールバックモードで実行しており、および即時の修正を必要としていることを示すＮｏｔｉｆｙペイロードを備えたＩＫＥｖ２メッセージを送ることができる。

準自律的検証方法については、修正手順は、必ずしもソフトウェアの完全なアップデート、あるいは信頼された基準値（ＴＲＶ）を必ずしも伴わないだろう。装置がステージ１と２の検証を通ったが、ステージ３に失敗する時に、失敗したモジュールに関する情報は、Ｎｏｔｉｆｙペイロード、あるいはＩＫＥｖ２プロトコルの証明書で中のＰＶＥに送り返されることができる。ＰＶＥがそれらの失敗したモジュールを重要ではないものと思う場合、検証および認証は、それらの失敗したモジュールを無効に／アンロードにし続けることができる。しかしながら、失敗したモジュールが重要である場合、ＰＶＥは、修正が必要であることを示す情報をＤＭＳに送ることができる。

別のシナリオは、ＴｒＥに格納されたＲＩＭが特定のコード・ベースについては正しくないということであるかもしれない。エラーがＲＩＭにあり、およびＴｒＥの中でそれらの値だけを安全に更新する必要があることを情報の分析が示す場合に、失敗した測定は、ＰＶＥに送り返されることができる。

ディストレス信号（distress signal）およびフォールバックコードの事例および実施形態がここに記述される。装置は、フォールバックコード（ＦＢＣ）イメージを備えていてよく、その目的は、それが装置の完全性確認に失敗した場合に起こる装置の修正を促進することである。ＦＢＣは、読み出し専用メモリ（ＲＯＭ）のような安全なメモリに格納されることができる。ローカルの装置の完全性確認が失敗する場合、ＦＢＣが起動されることができる。ＦＢＣは、影響を受けた装置の修正に関与するＣＮ中のエンティティとの通信に必要とされる少なくとも全ての必要な機能、方法および認証情報を含むことができる。さらに、ＦＢＣはネットワークから十分なソフトウェア・アップデートを受け取るのに必要な機能を含むことができる。特別な「修正」ＤＭＳが考慮されることができる。

装置およびＴｒＥは、装置の完全性チェックの失敗時に次の修正表示手続きを行うことができてよい。最初に、ＴｒＥは、フォールバックコード（ＦＢＣ）として知られている、信頼されたコードの実行を始めることができる。ＦＢＣは、ＲＯＭのような安全なメモリに格納されることができる。次に、ＦＢＣは、あらかじめ指定された「修正」ＤＭＳに安全な接続を確立することができる。第３に、ＦＢＣは、装置ＩＤを含むことができるディストレス信号をＤＭＳに送ることができる。ディストレス信号の受信時にＤＭＳは、装置が例えば完全性チェックに失敗し、メンテナンスを要求することを知っていることができる。随意的に、ＤＭＳは、十分なファームウェアアップデート手続きを始めることができ、あるいは部分的なコード／データのアップデートを行うために信号の受信時に診断を行うことができる。

ＲＩＭのない検証の例がここに記述される。ＲＩＭのない検証は、安全なメモリーカードのような、ロード状態のＴｒＥの管理下での記憶装置を安全にするためにコンポーネントのコードの安全な転送を含むことができる。ＲＩＭのない検証は、正常なメモリに、コードのような暗号化されたコンポーネントを格納するようにダイジェスト値を暗号化で置き換えることを含むことができる。さらに、ＲＩＭのない検証は、ＴｒＥによって保護され、およびＤＭＳと共有されるキー、あるいはＤＭＳおよびＴｒＥが公開鍵および秘密鍵のペアを持つ場合に、非対称の暗号化アルゴリズムから導出される暗号鍵を使った暗号化を含むことができる。暗号化されたコードはターゲットとされた変更を考慮に入れなくてもよい。改ざんされたデータの解読が無意味を生じさせるので、コードのどんな操作も、セキュアスタートアップの変形中でのように解読時に検知されることができる。そのような変更の検知は、ダイジェスト値を暗号化されたコードの中に包含することによって達成されることができる。誤り訂正符号のようなさらなるオプションが適用されてよい。

検証プロセスのロケーションベースの情報の包含物（inclusion）の例が、ここに述べられている。いくつかの装置は、アプリケーションシナリオの中で適用することができ、ロケーションベースの情報は、盗難防止、カーゴトラッキング、フリートモニタリングあるいは監視のような重要な役割を果たす。装置は、地理的位置データを提供する全地球測位システム（ＧＰＳ）モジュールを典型的に備えることができる。セキュアスタートアップは、ロケーションベースの情報の信頼できる生成および記憶を保証するためにＧＰＳのモジュールおよびコンポーネントを含むことができる。位置データは、ＴｒＥの安全な記憶装置にさらに安全に保存されることができる。位置情報は、検証メッセージに含まれることができる。これは、報告された位置が所望の位置と一致しない場合に、ＯＡＭ手続きによって装置構成を変更するために例えば使用される。装置が新しい位置を報告する場合、装置が異なるパラメータを使用して、ネットワークに接続し、ロギング、報告、シャットダウンのようなソフトウェアイベントを引き起こすように、装置構成が変更されることができる。位置情報は、信頼されたアプリケーションによって安全に扱われると見なされることができる。

既存の標準化されたネットワークエンティティ、プロトコルおよびメカニズムに一般的なＰＶＭアーキテクチャのマッピングを提供するＨ（ｅ）ＮＢおよびＭ２ＭシナリオへのＰＶＭの適用および実施形態がここに記述される。両方の適用は、特定のセキュリティ要件を提示する。両方の適用は、次のような共通点を持っている。ｉ）携帯電話機が伝統的に見られていたように、装置は、記憶および機密データの扱いについての閉じられた不変の環境とはもはや考えられておらず、および２）これらの特別の装置は、モバイルネットワーク・オペレータ（ＭＮＯ）とは異なるステイクホルダーの制御下にあり、また一般的にコア・ネットワークに単に断続的に不安定なリンクを介して接続される。

最初の適用は、フェムトセルとしてよく知られているＨ（ｅ）ＮＢに言及する。Ｈ（ｅ）ＮＢは、３Ｇネットワークへのアクセス接続を（携帯電話などの）端末装置に提供する小さなポータブル・アクセスポイントである。Ｈ（ｅ）ＮＢは、一般的に、敷地上に、あるいはホスティング・パーティ（ＨＰ）と呼ばれるステイクホルダーの住居の中に置かれる。ＨＰは、小さく指定された地理的領域における移動通信およびサービスのためのメディエイターになる。これは、組織内か工場環境のような従来アクセス不能なエリア（無線状態が悪いため）のモバイルサービスを提供するために使用されうる。Ｈ（ｅ）ＮＢがブロードバンドインターネットおよび携帯電話ネットワークへの統合アクセスポイントでありうるので、それは、個人宅およびスモールオフィス・ホームオフィス（ＳＯＨＯ）セクターに対するオプションでもある。

Ｈ（ｅ）ＮＢの使用法のシナリオの中で、３つのステイクホルダーであるユーザ−ＨＰ−ＭＮＯは、サービスレベルおよび使用法の取り決めによって関連づけられる。Ｈ（ｅ）ＮＢは、このコンテキストにおいて多くの機密データ、例えば、携帯電話ネットワークサブスクリプションとして具現化されるようなＨＰの認証データ、クローズド加入者グループ（ＣＳＧ）として格納される、Ｈ（ｅ）ＮＢに接続することを許される無線送受信ユニット（ＷＴＲＵ）あるいはユーザ端末（ＵＥ）のリスト、およびアクセス・コントロール・リスト（ＡＣＬ）を格納する。このデータのうちのいくつかは、ＨＰおよび／またはユーザに非公開であってよい。さらに、Ｈ（ｅ）ＮＢの位置は、携帯電話ネットワークを干渉から保護し、かつ違法なサービスの拡張を防ぐようにコントロールされる必要がある。

図７は、Ｈ（ｅ）ＮＢ、ＷＴＲＵあるいはＵＥ７１０、ならびにオペレータのコア・ネットワーク７３０の間の例示の通信シナリオを示す。図７は、２つのネットワークエンティティを紹介するが、一方は、セキュリティを有する状態でタスクを課されており、他方は、Ｈ（ｅ）ＮＢにサービスを行うようにタスクを課されている。オペレーション、管理およびメンテナンス７３５（ＯＡＭ）は、Ｈ（ｅ）ＮＢ７０５に遠隔の管理機能性を供給するコア・ネットワークのバックホールの機能である。具体的に言うと、ＯＡＭ７３５は、ソフトウェアのダウンロードおよびアップデート、ラジオおよび他のパラメータのセッティング、並びに他の同様の機能を提供する。セキュリティ・ゲートウエイ（ＳｅＧＷ）７４０は、オペレータのコア・ネットワーク７３０の中へのＨ（ｅ）ＮＢ７０５のためのメインのエントリポイントであり、また、その主な目的は不正接続の試み、および悪者Ｈ（ｅ）ＮＢあるいはＨ（ｅ）ＮＢに扮する攻撃者から出る可能性のあるいかなる種類の攻撃からネットワーク７３０を保護することである。

第２の意図した適用はＭ２Ｍ通信を指す。Ｍ２Ｍ設備（Ｍ２ＭＥ）用代表例は、自動販売機および発券機である。もっと高度なシナリオは、特に、熱電供給プラントの遠隔測定、機械管理および設備管理を含む。Ｍ２ＭＥが携帯電話ネットワーク経由でバックアップ・システムに接続されれば、ＭＮＯは、無線（ＯＴＡ）管理を始めとして、Ｍ２ＭＥの所有者に付加価値サービスを提供することができるようにされるであろう。Ｈ（ｅ）ＮＢのように、Ｍ２ＭＥがＭＮＯと異なるステイクホルダーにコントロールされる。ステイクホルダーは、ＭＮＯのものとは異なりうるセキュリティ要件を有する。Ｈ（ｅ）ＮＢおよびＭ２ＭＥのセキュリティは問題の核心である。それぞれの脅威、危険および続いて起こるセキュリティ要件は、両方の場合について比較可能である。

脅威（threat）は６つのトップレベルのグループへグループ化されることができる。グループ１は、認証情報を危険にさらす方法を含む。これは、トークンおよび（弱い）認証アルゴリズム上の総当たり攻撃、物理的な侵入、サイドチャネル攻撃、また認証トークンのクローンを作る悪意のあるホスティング・パーティを含む。グループ２は、操作される装置に有効な認証トークンを挿入すること、不正なソフトウェアを用いたブート（再フラッシュ）、物理的な改ざん、および環境上の／サイドチャネル攻撃などの物理的な攻撃を含む。グループ３は、詐欺的なソフトウェア・アップデート／設定変更、ＨＰやユーザによる間違い設定、ＡＣＬの間違い設定やセキュリティ侵害などのコンフィギュレーション攻撃を含む。グループ４は、装置に対するプロトコル攻撃を含む。これらの攻撃は、機能性を脅かし、ＨＰとユーザに向けられる。それらの主な例は、最初のネットワークアクセスに対するマン・イン・ザ・ミドル攻撃（ＭＩＴＭ）、ＤｏＳ攻撃、アクティブなネットワークサービスの弱点を突くことによる装置の情報漏洩、またＯＡＭとそのトラフィック上での攻撃である。グループ５はコア・ネットワークに対する攻撃を含む。これらはＭＮＯに対する主な脅威である。それらは、装置のなりすまし攻撃、装置間のトラフィックトンネリング、モデム／ルータのファイアウォールの間違い設定、およびコア・ネットワークに対するＤｏＳ攻撃を含む。Ｈ（ｅ）ＮＢの場合には、それが許可されていない方法で位置を変更することを指す。最後に、これは、悪者装置を使用する無線アクセスネットワークに対する攻撃を含む。グループ６は、別のユーザのＵＴＲＡＮ（UMTS Terrestrial rado access network）あるいは発展型ＵＴＲＡＮ（Ｅ−ＵＴＲＡＮ）アクセス・データの傍受、他のユーザになりすますこと、Ｈ（ｅ）ＮＢ所有者に知らされたユーザのネットワークＩＤ、有効なＨ（ｅ）ＮＢになりすますこと、ＣＳＧを介して無線アクセスサービスを提供することを含む利用者データと同一性のプライバシー攻撃を含む。

Ｈ（ｅ）ＮＢおよびＭ２ＭＥの両方にとって新しい中核機能要件は、主として異なるステイクホルダーの認証、並びにそれらの間の機能およびデータの分離、つまり領域分離を指す。特に、ＨＰやＭ２ＭＥ所有者の信頼性は、ネットワークへの装置認証と無関係に作られてよい。更に、ＨＰの機密データは、他のパーティ、ＭＮＯさえによってアクセスから保護されなければならない。装置は、セキュリティに敏感なタスクを行わなければならず、またアクセスネットワークおよび接続しているＷＴＲＵの両方へのセキュリティ・ポリシーを実行する。これは、サービス連続性を提供し、およびバックホールリンクを通じての不必要な通信を避けるために、少なくとも準自律的な方法で可能でなければならない。別の重要なセキュリティ領域は、それぞれＯＡＭまたはＯＴＡによる遠隔管理である。装置は、ソフトウェア・アップデート、データおよびアプリケーションを安全にダウンロードしインストールする必要がある。

必要なことは、コア・ネットワークに対する変更を並行して最小化しながら認証役割を分離すること、および、従って、ＥＡＰ−ＡＫＡ（Extensible Authentication Protocol - Authentication and Key Agreement）のような標準の３Ｇ認証プロトコルを再使用することである。ここまで想定されたアプローチは、ＨＰおよび／またはＭ２Ｍ所有者の個別の認証ベアラを含む。それらは、前者の場合のいわゆるＨＰモジュール（ＨＰＭ）、あるいは後者の場合の管理アイデンティティ（ＭＩＤ）で具体化されることができる。両者は、ＵＩＣＣ（Universal Integrated Circuit Card）、すなわち、３Ｇ用のＳＩＭ（Subscriber Identity Module）カードのための仮名であってよい。様々なセキュリティ上の問題は、Ｍ２Ｍの場合での除去可能なスマートカードの使用法に対してあげられている。一方では、地理的に分散したＭ２ＭＥの大きな艦隊にとっては非常にコスト高であるので、そのようなスマートカードの交換（例えば、アップデート最新版あるいはオペレータ変更のために）を必要とするメンテナンスオペレーションは、避けられることになる。注意深く最近考慮された別のオプションは、装置中の安全な環境へのＡＫＡ認証情報のダウンロードである。このオプションを可能にさせる純粋なＴＣ技術を使用する可能な１つのスキームは仮想ＳＩＭである。

どんな場合も、セキュリティ要件、および進化したＯＴＡあるいは遠隔管理は、Ｍ２ＭＥおよびＨ（ｅ）ＮＢの上の特別のセキュリティ機能を要求する。ＴｒＥはこれらの目的に適用することができる。ＴｒＥは、システムの他の部分と安全に対話する必要がある。これらのＴｒＥインターフェースは、ＴＳのＴＣＢがプラットフォームの残りとどのように通信するかについての一般的なモデルであるので、これらのＴｒＥインターフェースを考察することは興味深い。基本的に、全てのＴｒＥインターフェースは、ＴｒＥのセキュアスタートアッププロセスで初期化され、正確に動作すると仮定される。２つの広いセキュリティ・カテゴリーのＴｒＥインターフェースがある。第１に、無防備のインターフェースがある。これらのインターフェースは、ＴｒＥを、改ざんおよび／または傍受に対して安全であるとは想定されない装置の一般リソースを備えた状態にする。無防備のインターフェースは、データ暗号化、またはＴｒＥが例えば安全なブート中にインターフェースを通してその対応するリソースのコードをチェックした後だけインターフェースを利用可能にすること、などの他のセキュリティ対策から利益を得るであろう。

第２に、保護されたインターフェースがある。これらのインターフェースは、セキュリティ・プロトコルまたは安全なハードウェアを使用して、それらのインターフェースを通して運ばれるデータの完全性および／または機密性の保護を提供する。セキュリティ・プロトコルが使用される場合、セキュリティ・プロトコルは、認証、並びにメッセージ認証および／または機密性を提供することができる。

通信するエンティティが通信データの保護を提供しない場合、無防備のインターフェースが選ばれうる。ＴｒＥとＴｒＥが通信する必要のある別のリソースとの間のデータ完全性および／または機密性の保護を提供する必要がある場合、保護されたインターフェースが選ばれうる。従って、ＴｒＥの機能は変わりうる。図８は、Ｈ（ｅ）ＮＢ内のＴｒＥ、およびそれが接続できる他のリソースについての実施形態を示す。これは最小限の構成であり、Ｈ（ｅ）ＮＢの装置認証に必要なパラメータを計算してＳｅＧＷに送信する機能、ブート時におけるＨ（ｅ）ＮＢの残りのコード完全性チェックを含むＨ（ｅ）ＮＢ検証のための機能、および最小の暗号機能（真の乱数発生器）含んでいる。認証に関して、ＴｒＥが論理上ＨＰＭを含むかもしれないことは予想される。

一般的なＰＶＭ記述のアーキテクチャは、既存のＨ（ｅ）ＮＢアーキテクチャに容易にマッピングされることができる。データベース（Ｖ＿ＤＢとＣ＿ＤＢ）およびそれらの管理コンポーネントは、既存のＨ（ｅ）ＮＢインフラストラクチャにとっては新参のものである。図９Ａおよび図９Ｂは、両方のシナリオ、つまり、ＳｅＧＷを通したＨ（ｅ）ＮＢ接続およびインターフェースＩ−ｄｍｓ＿ｄを介したＨＭＳへのＨ（ｅ）ＮＢの直接接続を示す。

図９ＡのＰＶＭアーキテクチャつまりシステム９００は、ＴｒＥ９１０を有するＨ（ｅ）ＮＢ９０５を含む。ＷＴＲＵ９１２（すなわちユーザエンティティ（ＵＥ））は、Ｉ−ｕｅインターフェース９１４経由でＨ（ｅ）ＮＢ９０５と通信できる。Ｈ（ｅ）ＮＢ９０５は、Ｉ−ｈインターフェース９１５経由でＳｅＧＷ９２０を含むＨ（ｅ）ＮＢゲートウェイ（ＧＷ）９１８と通信する。一般に、Ｈ（ｅ）ＮＢ９０５とＳｅＧＷ９２０との間のＩ−ｈインターフェース９１５は、無防備の可能性があり、特別な措置が信頼性、完全性および随意的に機密性のためにこのチャネルを安全にするために適用されることができる。Ｉ−ｈインターフェース９１５は、Ｈ（ｅ）ＮＢ９０５とＳｅＧＷ９２０とＣＮとの間のリンクを確立するために使用されることができる。例えば、ＳｅＧＷ９２０は、インターフェースＩ−ａａａ９７５によってＡＡＡサーバと通信することができる。オペレータは、インターフェースのセキュリティを保証する適切な手段を確立できる。

検証中にＰＶＥ９２４と連絡をとるために、Ｉ−ｐｖｅインターフェース９２２はＳｅＧＷ９２０によって使用されることができる。ＰＶＥ９２４は、Ｉ−ｐｖｅインターフェース９２２を使用して検証結果をＳｅＧＷ９２０に信号を送ることができる。Ｉ−ｄｍｓインターフェース９３０は、Ｈ（ｅ）ＮＢ管理システム（ＨＭＳ）９３５とＳｅＧＷ９２０との間の装置構成に関連する通信のために使用されることができる。Ｉ−ｐｄインターフェース９３２は、ＨＭＳ９３５と通信するためにＰＶＥ９２４によって使用され、またＰＶＥ９２４と通信するためにＨＭＳ９３５によって使用されることができる。このインターフェース、Ｉ−ｐｄ９３２は、装置ソフトウェア・アップデートおよび構成変更のためなどの装置管理プロシージャの間に使用されることができる。

インターフェース、Ｉ−ｖ９２６およびＩ−ｄ９３８は、それぞれ、Ｖ＿ＤＢ９４０からＲＩＭを読むためにＰＶＥ９２４によって使用され、またＣ＿ＤＢ９５０から許可された設定を読むためにＨＭＳ９３５によって使用されることができる。インターフェース、Ｉ−ｒ９２８およびＩ−ｃ９３４は、Ｖ＿ＤＢ９４０においてＲＩＭが見当たらない場合のように、ＲＩＭｍａｎ９６０に通信するＰＶＥ９２４によって使用され、またＣＰｍａｎ９７０と通信するＨＭＳ９３５によって使用されることができる。ＲＩＭｍａｎ９６０およびＣＰｍａｎ９７０は、それぞれ、Ｉ−ｒｄｂ９６２およびＩ−ｃｄｂ９７２を使用してデータベースＶ＿ＤＢ９４０および設定ポリシーデータベースＣ＿ＤＢ９５０の読み出し、書き込み、および検証の管理を行うことができる。

図９Ｂは、Ｈ（ｅ）ＮＢ９０５がＤＭＳ９３５に直接接続できる場合のＰＶＭ９８２を説明する。例えばフォールバックモード（代替システムのモード）の場合には、Ｈ（ｅ）ＮＢ９０５がＳｅＧＷを備えたセキュリティ・プロトコルを行うことができない。この場合、ＨＭＳ９３５は、インターフェースＩ−ｄｍｓ＿ｄ９８４によってＨ（ｅ）ＮＢ９０５のための第１の接触のポイントとして働き、並びにインターフェースＩ−ｐｖｅ９８６およびＩ−ｐｄ９８８経由でＰＶＥ９２４と通信し、および検証を行い、あるいはどのコンポーネントがセキュアスタートアップ中に失敗したかを少なくとも知るようになる。ＨＭＳ９３５は、改善のためのこの情報に基づいて行動することができる。

ＰＶＥを使用する検証は、様々な方法でＨ（ｅ）ＮＢシナリオに直接マッピングされることができる。ＤＭＳ機能は、ＨＭＳあるいは適切に拡張されたエンティティ、つまり、Ｃ＿ＤＢにアクセスすることができる進化型ＨＭＳ（ｅＨＭＳ）によって行われる。

ポリシーベースのアップデートに関して、Ｃ＿ＤＢは、例えば、あるモジュールはオペレーションにとって重要であり得、あるモジュールはそうではないといった、モジュールの重要性、およびモジュールの様々なリリース・バージョンの相互運用性を指定するポリシーを提供する。これは、アップデートのサイズ制限において有用であり、完全なファームウェアアップデートの代わりにパッチを提供する。ポリシーは、全てのモジュールをＨ（ｅ）ＮＢのオペレーションにとって重要なものと定義し、そのため完全なファームウェアアップデートがなされることを示すものと同じくらい単純にできる。

モジュールが測定に失敗する場合、ｅＨＭＳは、モジュールの重要性、およびモジュールの相互運用性への任意の影響をチェックするためにポリシーを検査する。これに基づいて、適用可能なパッチのリストは作成される。パッチは、適用のために装置へまとめてあるいは個々に送られることができる。いずれの場合も、搬送単位は、それぞれ完全性および機密性が保護される。リンクは、順番にロスなしでパケットを運ばなければならない。パッチをすべて受け取る際、例えば、終了パッケージまたはフラグによりｅＨＭＳによって示される時など、装置は、必要であればアップデート情報を確認するためにｅＨＭＳにそれらの測定値と共に受信パッチのリストを送り、または、集合的および個々のパッチ測定値がｅＨＭＳによって送信される場合に、パッチのローカル確認を行い、適用を始める。パッチの適用に続いてシステムは正規モードでブートし、装置検証プロセスを始める。

メーカーからの新しいファームウェア・リリースがある場合は常にこの手続きが起こってよく、ｅＨＭＳは更新通知を装置に送り、装置は、ＥＣＢでブートし、ｅＨＭＳに測定値を送る。ｅＨＭＳは、パッチあるいは完全なファームウェアアップデートを提供し、同じ手続きが起こる。

非ポリシーベースのアップデートの場合には、失敗したいかなる測定においても、ＨＭＳは、安全なリンクを介して送信される完全な新しいファームウェアを提供する。装置はファームウェアを確認して適用を行い、正規モードでブートする。

以前の既知のよい状態の場合には、Ｈ（ｅ）ＮＢがシステム状態を格納することを支援する場合、ｅＨＭＳは、測定に失敗したパッチがロールバックされる場合に以前の既知のよい状態へ返ってくれるようにそれに依頼することができる。この方法は、工場出荷時点の状態へシステムを戻すために使用されることができる。以前の既知のよい状態は、ＰＶＥ、ｅＨＭＳあるいはＳ（ｅ）ＧＷによって保証される状態であってよい。

Ｈ（ｅ）ＮＢは、以前の既知のよい状態に返ることができ、システム状態の完全性保護を提供することができ、以前に格納されたシステム状態のリストアオペレーションを提供することができ、および障害が起きた装置の場合にはこのリストアオペレーションを保護することができる。

公のインターネット上に接続している装置の検証の例がここに記述される。公のインターネットのような不安定な最初のリンクを介してＳｅＧＷにそれぞれ接続される装置に関して、特別の必要条件は検証の初期ステップを安全にすることを求めることができる。これらの特別の必要条件は、さらにＳｅＧＷにそのような接続を要請し、それによって検証するＨ（ｅ）ＮＢタイプの装置に適用可能である。ＰＶＭの総括的なエンティティの代わりにＨＭＳのようなネットワークエンティティのＨ（ｅ）ＮＢ相当物はここに記述されるが、同じ方法および装置が非Ｈ（ｅ）ＮＢセッティングに適用できることは明白に違いない。典型的には、検証と認証は、最初の接続の最初の数ステップに、あるいは同じデータ構造へさえ結び付けられるように要求される。ＴＬＳとＩＫＥｖ２のような特定のプロトコルへの拘束力のある検証および認証の２つの変形が記述される。

ＩＫＥのトランスポートプロトコル（ＩＳＡＫＭＰ）は、使用されるかもしれない多くの証明書プロフィールを定義する。また、それらはＩＤとして完全修飾ドメイン名（ＦＱＤＮ）を許可する。装置証明書およびＴｒＥ証明書は個別にしておくことができる。しかしながら、装置証明書へＴｒＥ証明書を入れ子にすることは可能である。ＴｒＥに個別のＩＤ（ＴｒＥＪＤ）があった場合、ＦＱＤＮは使用されてもよい。しかし、ＴｒＥはオペレーター・ドメインネームではなくメーカーによって識別されることができる。

ＩＫＥ＿ＳＡ＿ＩＮＩＴフェーズおよびDiffie-Hellman鍵交換がＩＫＥカンバセーションのフェーズ１において完了する場合、１つの方法は、ＳｅＧＷにＤｅｖ＿ＣＥＲＴを要求するためにＣＥＲＴＲＥＱペイロードを含む最初の認証交換メッセージを送らせるだろう。その後、装置は、次のメッセージ中の２つのＣＥＲＴのペイロードで答えるが、そのうちの１つはＤｅｖ＿ＣＥＲＴを使用し、もう１つは、ＴｒＥ＿ＣＥＲＴについてのものである。この場合、ＴｒＥ＿ＣＥＲＴが確認され、および検証データがＰＶＥによって評価されるまで、ＳｅＧＷは、Ｄｅｖ＿ＣＥＲＴの確認を延期する。その後、認証は進む。答えが単にＤｅｖ＿ＣＥＲＴTを含む場合、ＳｅＧＷはＡｕＶにフォールバックする。

それぞれのＩＤが実際上の理由で異なる場合、Ｄｅｖ＿ＣＥＲＴとＴｒＥ＿ＣＥＲＴの相違は有利であろう。例えば、オペレータは、ＩＰアドレスのようなネットワーク・アドレスを装置に割り当てることができたが、装置は、直接ＩＰＳｅｃトンネルを形成するＤｅｖ＿ＣＥＲＴによって認証される。あるタイプのネットワーク・アドレスはＴｒＥ＿ＣＥＲＴに適さないであろう。したがって、２つのＩＤは装置において役立つであろう。ＴｒＥ＿ＣＥＲＴに基づいて実行できるＰＶＭおよび補助の認証を適用することにより、Ｄｅｖ＿ＣＥＲＴの交換として役立つことは、ＳＥＧＷ／ＰＶＥインフラストラクチャのさらなるタスクであろう。

ＩＫＥ認証メッセージは、任意のタイプの任意の数のペイロードを運ぶことができる。すべてのペイロードのヘッダーでは、「次のペイロード型」フィールドを含むことができる。したがって、ペイロードの一続きのつながりは１つのＩＳＡＫＭＰメッセージの中で送信されることができる。これは、最初のＩＫＥカンバセーションのフェーズ２の１つ以上のＩＳＡＫＭＰメッセージのペイロードフィールドに証明書を分けるために使用されることができる。ＴｒＥの証明書および装置認証を完全に分離するＩＫＥカンバセーションを使用する、装置１００５、ＳｅＧＷ１０１０およびＰＶＥ１０１５の間の例示的なプロセス１０００が図１０に示される。（ＴｒＥ＿Ｃｅｒｔ、ＶＡＬ＿ＤＡＴ）を含むメッセージは、装置１００５からＳｅＧＷ１０１０に送信される（１）。ＳｅＧＷ１０１０は、抽出されたＴｒＥ証明書（ＴｒＥ＿Ｃｅｒｔ）を確認する（２）。ＴｒＥ＿Ｃｅｒｔが成功裡に確認される場合、ＳｅＧＷ１０１０はＰＶＥ１０１５に有効なデータメッセージ列（ＶＡＬ＿ＤＡＴ）を送る（３）。ＰＶＥ１０１５は、装置１００５を検証し（４）、ＳｅＧＷ１０１５に成功を信号送信する（５）。ＳｅＧＷ１０１５は、装置１００５に証明書リクエスト（ＣＥＲＴＲＥＱ）を送る（６）。証明書リクエストに応じて、装置１００５は、少なくとも装置証明書（Ｓｉｇ＿Ｄｅｖ（Ｄｅｖ＿ＩＤ）、Ｄｅｖ＿Ｃｅｒｔ）をＳｅＧＷ１０１０に送る（７）。ＳｅＧＷ１０１０は、Ｓｉｇ（Ｄｅｖ＿ＩＤ)を確認する（８）。確認が成功する場合、装置証明書（Ｄｅｖ＿Ｃｅｒｔ）は、装置が既知かどうかで反応するＡＡＡのインフラストラクチャに送られる。本実施形態に従って、有効であると信頼されうる装置だけが、ＴｒＥによって署名された検証データをＴｒＥ＿ＣＥＲＴによって証明された同一性と共に送信することによって、装置認証に認められる。これは、ＳｅＧＷの後ろのネットワーク要素に拡張された保護を提供し、ＤｏＳ攻撃を緩和するのを支援する。

別の例において、補足データについてのＴＬＳハンドシェイク（応答確認）メッセージは、ＴＬＳハンドシェイクにおける詳細なデータ（例えば、ＰＶＭからの検証メッセージ）を送信アプリケーションに与えるＴＬＳ ｈｅｌｌｏハンドシェイクメッセージに対する拡張を定義する。補足データは、ＴＬＳプロトコルによって使用されないかもしれないが、ＰＶＥ検証エンジンのようなアプリケーションによって使用されることができる。許可された単一の補足データのハンドシェイクメッセージが存在することができるが、１つ以上の当該メッセージを受け取ることは失敗として扱われるであろう。運ばれるデータのタイプおよびフォーマットは、SupplementalDataTypeとして指定されることができ、送信側と受信側の両方に知られることができる。

変形の実施形態では、ダブルハンドシェークが行われ、それにより、補足データのハンドシェイクメッセージにて運ばれる実行可能ＰＶＭデータに保護を提供できる。さらに、それは、一方のパーティが補足データの情報を提供する前にパーティが相互に認証されることを保証できる。

新しいSupplementalDataTypeは、実行可能ＰＶＭ検証メッセージを伝えるために定義されることができる。Ｈ（ｅ）ＮＢは、ＳｅＧＷとの相互認証のための最初のＴＬＳハンドシェイクに携わる。第２のハンドシェイクは、最初のＴＬＳセッションを使用して保護されることができ、検証データはＳｅＧＷに補足データ・フィールドで送られる。

別の変形の実施形態では、最初のハンドシェイクメッセージ中で補足データを送ることにより、検証データは、２つのハンドシェイク交換ではなく１つのハンドシェイク交換で送信されることができる。ＴＬＳセッション・チケット拡張を使用する検証接続に関して、セッションを再開し、かつクライアントごとのセッション状態を維持するための、クライアントへのセッション・チケットを出すことをサーバに可能にさせるＴＬＳ拡張は、ＴＬＳセッション・チケットに検証結果を格納するためにＳｅＧＷによって検証の中で使用されることができる。

そのようなセッション・チケットはＰＶＭの中でプラットフォーム管理に使用されてもよい。失敗したコンポーネントのリストを備えた状態で検証が失敗する場合、ＳｅＧＷはＰＶＥからこの通知を受け取り、セッション・チケットを生成する。チケットは、１２８ビットのＡＥＳ対称鍵（それはＨ（ｅ）ＮＢに開示されない）を使用して暗号化され、さらに、チケットは、ＨＭＡＣ：Hash-based Message Authentication Code）によって保護される完全性である。したがって、チケットはＨ（ｅ）ＮＢによって変更することができず、およびＨ（ｅ）ＮＢによって示される場合、他のネットワークエンティティによって認識されることができる。その後、ＴｒＥは安全にチケットを格納し、および、例えば、再び検証データを送らなくてもチケットをプラットフォーム管理のための新しいＴＬＳセッションに使用できる。ＳｅＧＷは、セッション・チケットの存続期間を決めることもできる。

ＡＥＳチケット暗号鍵は、さらなる使用のためにＴ＿ＰＶＭに含まれることができ、あるいは他のエンティティに直接渡されることができる。キー並びに例えばチケット・タイムスタンプおよび詳細な検証結果は、ＰＶＥからＨＭＳへ転送されることができる。ＴＬＳセッション・チケットを使用して、Ｈ（ｅ）ＮＢは、プラットフォーム管理のための安全な接続を直接確立できる。これは、プラットフォーム管理タスクをタイムリーに行い、およびチケットの期限満了前にＨＭＳにコンタクトするＨ（ｅ）ＮＢに依存しうる。

セッション・チケットで確立された接続を使用して、Ｈ（ｅ）ＮＢがＨＭＳで改善を終えたところで、セッション・チケットは再検証のために使用されてもよい。第１のステップは、古いチケットを使用して、Ｈ（ｅ）ＮＢからＳｅＧＷへの新しいＴＬＳ接続を確立することとしてよい。ＳｅＧＷは、このチケットがＨＭＳで実際に管理サイクルを終えたＨ（ｅ）ＮＢに由来することをコントロールすることができる。ＳｅＧＷは、検索を行い、およびチケット・データを管理完了後にＨＭＳから返されたＴ＿ＰＶＭと比較することができる。正確なＴ＿ＰＶＭが見つかる場合、ＴＬＳチケットを使用する再検証の試みは例えば、ＴＬＳチケットをやり直しのために使用することによりマウントされたＤｏｓ攻撃に対して保護するために認められうる。ＴＬＳチケットは再検証のために受理されることができるが、そうでなければ、ＨＭＳを使った修正ステップが長くかかるかもしれないので失効したと考えられうる。ＳｅＧＷは、タイムスタンプを押された、比較に利用可能なＴ＿ＰＶＭを有しているので、これはセキュリティを大きく損うことなく行われることができる。

自律的検証（ＡｕＶ）を備えたＰＶＭの一例がここに記述される。ＡｕＶは、ＳｅＧＷにどんな検証データも配達せず、装置の最初のネットワークアタッチメントのために既存のプロトコルの変更を要求しない方法である。したがって、ＰＶＭシステムは装置のセキュアスタートアップ中に確認結果に関して何でも学習する。転送されるただ一つの装置固有の情報は、Ｄｅｖ＿ＩＤである。

ＡｕＶは、プラットフォーム検証の結果に基づいて装置を管理する可能性を制限する。特に、ネットワークに最初に認証を行い、アップデートの後に再検証のためにＡｕＶを行っている装置を識別する直接的な方法はない。装置管理は、それがＡｕＶに基づく場合、装置状態のヒストリーを運ぶネットワークにデータベースを必要とする。ＡｕＶに基づいて基本的な装置管理を少なくとも行うのに有効でありうる例示的な方法がここに記述される。

ＡｕＶのみ対応装置のＨ（ｅ）ＮＢ修正の一例がここに記述される。ＡｕＶのみ対応装置は、ローカル装置完全性確認が成功する場合およびその場合のみ、装置が装置認証手続きを行うことを可能にするセキュアスタートアップを実行する。コンポーネントのうちのどれかがそれらの完全性チェックに失敗する場合、装置はその完全性チェックに失敗したと見なされうる。しかしながら、ＦＢＣイメージの使用によって、装置は、装置修正を促進するために指定のＨＭＳとコンタクトをとることができる。

一旦修正ＨＭＳへの接続が確立されれば、Ｈ（ｅ）ＮＢの正常なコード・イメージおよび／または信頼された基準値が交換されることができる。修正プロセスが完了すると、Ｈ（ｅ）ＮＢはリブートし、完全性チェック・プロセスは改めてもう一度スタートするべきである。

所定の要件が適所にある場合ＰＶＭはＦＢＣを使用できる。一例の要件は、ＦＢＣが装置内に安全に格納されるということである。別の要件は、失敗したセキュアスタートアップの場合に、ＦＢＣがロードされ開始されうるということであろう。しかし、別の要件は、指定のＨ（ｅ）ＭＳのアドレスがＦＢＣイメージに安全に格納されるということである。また、別の要件は、ＦＢＣが指定のＨ（ｅ）ＭＳのもとへディストレス信号を送ることができるということである。そのような信号は装置ＩＤを含むことができ、また、メッセージは、ＦＢＣの一部として安全に格納されるキーによって保護される完全性である場合がある。さらなる例示的な要件は、装置が完全性チェックに失敗しておりメンテナンスを要求するということを信号受信時にＨ（ｅ）ＭＳが確認することができることである。しかし、別の要件は、ネットワークによって開始されるフル・コードの復元を促進するためにＦＢＣが機能性を含みうるということであろう。別の要件は、ネットワークによって開始されるＴＲＶの置換を促進するためにＦＢＣが機能性を含みうるということであろう。

図１１Ａおよび図１１Ｂは、完全性確認の失敗に続いてＦＢＣによって促進された装置修正改善が起こる一例の方法を示す。ＲｏＴ１１００はディストレスフラグをチェックする（１）。フラグがクリアされる場合、ＲｏＴ１１００はＴｒＥ１１０５の完全性をチェックする（２）。フラグがセットされる場合、ＲｏＴ１１００はＦＢＣをロードする（３）。完全性チェックが成功する場合、ＲｏＴ１１００はＴｒＥ１１０５をロードする（４）。完全性チェックが失敗する場合、ＲｏＴ１１００はディストレスフラグをセットし、リブートする（５）。一旦正常なコードがロードされれば、ＴｒＥ１１０５は正常なコードの完全性をチェックする（６）。完全性チェックが成功する場合、ＴｒＥ１１０５は正常なコード・イメージをロードする（７）。完全性チェックが失敗する場合、ＴｒＥ１１０５はディストレスフラグをセットし、リブートする（８）。ＲｏＴがＦＢＣをロードした場合、ＦＢＣはＨＭＳに修正についてのディストレス信号を送ることを始める（９）。

ＡｕＶを使用した再検証および構成変更のための基礎的な方法の一例がここに記述される。ＡｕＶの間にＳｅＧＷに転送され、および潜在的にプラットフォーム管理において使用可能なただ一つの個別情報は、装置アイデンティティである。したがって、一実施形態は、コンポーネントの完全性確認失敗などの（有限数の）状態をシグナルするために、多数のアイデンティティを装置に割り当ててＡｕＶの中でそれらを使用することができる。別の実施形態では、確認結果をシグナルするために任意の単一の装置に特有でないグループＩＤは使用されることができる。管理アイデンティティは、セキュアスタートアッププロセスのステージによってグループ化される。例えば、ステージ３ｂで失敗をシグナルするためのＤｅｖＭ＿ＩＤ３ｂ、ステージ３ａで失敗をシグナルするためのＤｅｖＭ＿ＩＤ３ａおよびステージ２で失敗をシグナルするためのＤｅｖＭ＿ＩＤ２である。ステージ１の失敗は、装置が通信能力を欠くので、シグナルすることができない。

ＡｕＶ使用の場合の別の例において、装置は、フォールバックコードの失敗および実行に続く一連の行動としてＨＭＳに接続することを試みることができる。

ステージ２の単一または複合コンポーネントの失敗は、装置が通信することができないことを示唆しない。ステージはあるカテゴリーに属するコンポーネントのクラスとして理解される。ステージ２の最も本質的なコンポーネントがロードされる限り、装置はＰＶＭシステムにその状態および失敗したコンポーネントを伝えることができる。アタッチメントが可能な元での基準にフレームワークを提供する、ＨＭＳによって維持される、装置にポリシーマネージャがいれば、これは当てはまるであろう。

セキュリティについては、もしそうでなければ、攻撃者がスプーフィング攻撃を行うことにより管理プロセスを破壊することができるので、ＤｅｖＭ＿ＩＤｎおよび関連する認証データ（例えば秘密鍵）は十分保護されなければならない。管理ＩＤが装置の大きなグループには同一であるので、これは危険な脅威である。１つのソリューションは、この情報だけを使用してプラットフォーム管理プロセスをモデル化することであろう。最初の検証（それは未知のアイデンティティのある装置の失敗をシグナルする）を再検証に結び付けることは、固有の装置の管理プロセスの成功をシグナルすべきである。これを決定論的に行う様々な方法がある。一例において、装置が管理アイデンティティの１つに認証した後、ＳｅＧＷは、オリジナルのＤｅｖ＿ＩＤに装置が認証しなければならない補充のプロトコルを実行する。別の方法では、ある秘密を交換することによって、装置およびＰＶＭシステム、並びに特にＳｅＧＷは、最初の確認プロセスおよび第２の再検証プロセスに及ぶ管理セッションを確立する。

補足の認証プロトコルの一例がここに記述される。装置とＳｅＧＷは、装置で最初の認証プロトコルを完了したが、装置はその内部で管理アイデンティティＤｅｖＭ＿ＩＤｎの１つに認証した。装置とＳｅＧＷは、暗号化され確証された通信セッションを確立したと考えられる。その後、装置は、Ｄｅｖ＿ＩＤおよびＤｅｖ＿ＩＤについての認証データを単に転送することができる。例えば、署名されたメッセージおよび公開鍵証明書は、確立している安全なチャネルを介して転送されることができる。これは、他の誰も、管理を要求する装置のアイデンティティ知らず、管理プロセスをスプーフするためにこの知識を使用することができないこと、すなわち、再検証の前に装置を無効にすることができず、または装置になりすますことができないことを保証する。

ＳｅＧＷは、ＰＶＥにＤｅｖＭ＿ＩＤとＤｅｖ＿ＩＤを転送するが、ＰＶＥは、管理を必要としている装置のリストにそれを挿入する。ＰＶＥは、例えば「ステージ２のフォールバックコードをインストールする」といった、必要な装置管理アクションをＤＭＳにシグナルする。ＤＭＳは、ＳｅＧＷによって以前に確立された安全なチャネル上で対応するコードを装置にダウンロードする。正常なＰＶＭでのように、システムは装置の再検証を始める。

管理が成功する場合、装置は続いてＡｕＶにおいてそのオリジナルのＤｅｖ＿ＩＤに対して認証を行う。このことはＳｅＧＷによってＰＶＥにシグナルされるが、ＰＶＥは再検証リスト中のＤｅｖ＿ＩＤを認識し、それを削除する。そうでなければ、装置は再び管理ＩＤに検証を行い、管理ＩＤは認識され、ポリシーに従ってアクションが取られる。

管理セッション確立の一例がここに記述される。この実施形態は、ＰＶＭが管理を単一の装置に特有なものにする点で別の実施形態と異なる。管理セッションは、装置とＳｅＧＷとの間の通信プロトコルで確立されることができる。そのようなアプローチの影響は、装置のアイデンティティがハンドルネームを確立することにより本質的にＰＶＭシステムに未知のままとすることができることである。

実行された正常なプロトコルにおいてそのような持続的な秘密を確立するプロトコルの機能は制限されうる。例えば、Diffie-Hellman鍵交換（Ｄ−Ｈ）のような共通鍵確立プロトコルは、ジョイントキー・コントロールと呼ばれる特性を満たし、確立されたキーは両方のパーティに依存する。すなわち、両方のパーティは、実行ごとに異なるキーをもたらすプロトコルに（擬似）乱数情報を挿入する。多数の実行にまたがるセッションは、そのようなプロトコルを使用して確立されることができない。

このように、ＳｅＧＷと装置は、例えばチャレンジ・レスポンスの使用により特別のプロトコル中で秘密を確立しなければならない。チャレンジは装置かＳｅＧＷのいずれかによって提示されることができる。また、レスポンスは、第２の実行（再検証）での第２の答えは第１ラウンドの答えと同一であるほどであるに違いない。普通の実施形態では、装置は、再検証においてＳｅＧＷから得られるノンス（nonce）をちょうど示し、また、ＳｅＧＷはテーブル中でそれを検索する。ノンスは匿名（ハンドルネーム）である。より多くの複雑な暗号のプロトコルが使用されてもよい。

再検証は上記のように進むことができる。しかしながら、違いは、この変形の実施形態において、ＳｅＧＷは、ＳｅＧＷと装置の間で再検証に属する実行されたプロトコルの中で使用されうるので、ＳｅＧＷは、実質的な理由で再検証を行う装置に関する情報を維持するという点である。

Ｈ（ｅ）ＮＢのためのＯＭＡ装置管理（ＤＭ）に基づいたアーキテクチャのための実施形態がここに記述される。ＯＭＡ ＤＭは、オープンなモバイルアライアンス（ＯＭＡ）装置管理（ＤＭ）作業グループおよびデータ同期（ＤＳ）作業グループによって共同で指定された装置管理プロトコルである。ＯＭＡ ＤＭは、電話またはＰＤＡのような小型のモバイル機器のために開発された。それは、機器およびＤＭサーバの間の広帯域の有線接続のサポートを欠き、ＵＳＢまたはＲＳ−２３２Ｃのような短距離の有線接続、あるいはＧＳＭ（登録商標）、ＣＤＭＡまたはＷＬＡＮのような無線接続をサポートするだけである。しかしながら、それは、Ｈ（ｅ）ＮＢ、特に、自身に接続するＣＳＧ（クローズド加入者グループ）および非ＣＳＧのＷＴＲＵに基地局として自身を示すと同時にコア・ネットワークに対するＷＴＲＵとして自身を示すこともできるＨ（ｅ）ＮＢのための装置プロビジョニングおよび管理プロトコルとして有益でありうる。

ＯＭＡ ＤＭは、最初の装置構成および許可する特徴あるいは不能にする特徴を含むプロビジョニング、装置構成アップデート、ソフトウェアアップグレード、並びに診断レポートおよびクエリのような使用事例をサポートすることを目的とする。装置はこれらの特徴の全てまたは一部を任意に実行できるが、ＯＭＡ ＤＭサーバ側はこれらの機能をすべてサポートできる。

ＯＭＡの仕様は、制約された接続性を備えた小型装置のための上記のリストされた特徴をサポートするために最適化されることができる。さらに、その仕様は、ＥＡＰ−ＡＫＡのようなプロトコルの使用によってのように認証を使用して統合セキュリティをサポートする。

ＯＭＡ ＤＭは、ＸＭＬあるいはより正確にはＳｙｎｃＭＬからのサブセットをデータ交換に使用する。これは、検証の目的でソフトウェア・モジュールの属性やＨ（ｅ）ＮＢの機能を定義して伝えるために、標準化可能で柔軟な方法を提供するのに役立ちうる。

装置管理は、ＤＭサーバ（例えば装置用の管理エンティティ）と、管理される装置のようなクライアントとの間で行われる。ＯＭＡ ＤＭは、ＷＡＰ、ＨＴＴＰあるいはＯＢＥＸのようなトランスポート層あるいは同様のトランスポートをサポートする。ＤＭ通信は、通知か警告メッセージのいずれかを使用するＷＡＰプッシュあるいはＳＭＳのような任意の利用可能な方法を使用して、ＤＭサーバによって非同期に始められる。一旦、通信がサーバとクライアントの間でセットアップされれば、メッセージのシーケンスは所与のＤＭタスクを終えるために交換することができる。

リクエストがＤＭサーバによって通常になされる場合、ＯＭＡ ＤＭ通信はリクエスト・レスポンス・プロトコルに基づく。また、クライアントは応答メッセージで応えることができる。サーバとクライアントは、共にステートフルであり、これは、特定のシーケンスに起因する任意のデータ交換が固有の認証手続きの後で生じうることを意味する。

ＤＭ通信がＤＭサーバによって始められうるので、ＤＭを介してＰＶＭを実行することは、検証にサーバ・クエリベースのアプローチを要求できる。例えば、ＩＫＥｖ２を使用する装置認証手続きは使用されることが可能だが、それは装置によって始められうる。いくつかの異なるメッセージ・タイプは、検証データのコンベアー（conveyer）と見なされうる。例えば、それは失敗したソフトウェア・モジュールまたは装置機能性のリスト中で送られうる。別の例において、管理警告メッセージは装置からサーバに送信されることができる。あるいは、総括的な警告メッセージ（装置かサーバのいずれかからの少なくとも１つの管理警告メッセージの送信があった後、それは、単に装置からＤＭサーバに送信されうる）のユーザも考慮されることができる。警告メッセージを含むこれらのメッセージは、コンテンツおよび当該コンテンツのメタデータを指定する際に柔軟性を提供するＳｙｎｃＭＬフォーマットを使用できる。このフォーマットは、検証情報伝達に役立ちうる。ＤＭはさらにセグメント化されたデータ転送をサポートでき、これは、アップデートのサイズが大きい場合のソフトウェア・アップデートに役立ちうる。

まさに最初のＤＭ通信はＤＭサーバによって開始されなければならないが、後続の通信は継続セッションを使用して、ＤＭクライアントによって開始されることができる。イン・セッション通信を開始するＤＭクライアント（例えば、Ｈ（ｅ）ＮＢあるいはＭ２ＭＥ）の能力は、装置により始められる再検証あるいは装置により始められる検証メッセージ配信のような、装置により始められるタスクに役立ちうる。

認証証明書中の検証の結合の例がここに記述される。認証証明書中の検証の結合は、結合した検証および認証を考慮に入れて、装置の本物のＩＤを検証に自動的に結び付ける。検証メッセージは、認証証明書において追加のフィールドに含まれている。例えば、ＩＫＥプロトコルを使用すると、二者択一でＮｏｔｉｆｙペイロードフィールドにそのような確認データが埋め込まれることができる。

確認データが認証証明書の内部で保存される場合、装置構成が変わるごとに、新しい結合した認証／検証証明書が出されなければならない。ＳｅＧＷはＰＶＭの目的でＤｅｖ＿ＩＤを認証することを担当するエンティティであるので、ＳｅＧＷによって証明書の生成が制御されなければならない。これは少なくとも２つの方法で行われるであろう。最初に、ＳｅＧＷ、あるいは従属するエンティティは、ＤＭＳからアップデートされたＣｌｉｓｔを受け取った後に新しい証明書を生成できる。次に、装置は証明書自体を生成でき、ＳｅＧＷとＰＶＥにこれを送るが、証明書は署名され、装置に送り返される。

ＳｅＧＷは、何らかの成功した再検証の後に、プロセス（新しい証明書を生成して送ること、あるいは装置により生成された新しい証明書を肯定応答すること）を終了できる。これは、新しい構成が装置によって実際に達成されることをＰＶＭシステムに保証することである。

新しい証明書が装置構成変更で必要かもしれないので、このサイクルはＣＮと装置に３つのエンティティをすべて含む。ＤＭＳは、構成変更（例えばソフトウェアおよび／またはパラメータのアップデート）を引き起こし、ポリシーデータベースＣ＿ＤＢに新しい所望の状態を保存する。変更が装置に適用された後、再検証が生じなければならない。

例示のシナリオでは、装置はアップデートを適用し、再検証を行う。新しいソフトウェアは使用されるが、再検証（特に成功した更新処理の）が完了するまで、新しい証明書は装置に展開することができない。この時に、装置は、実際の装置構成と一致しない古い証明書で新しいソフトウェア構成を実行している。これを受けて、アップデートが適用されている場合およびその場合のみ、新しい証明書は装置への装置認証に対して提供され、証明書は、アップデートが適用されることなく使用されることができないことを保証する。

装置認証証明書取り消しの一例がここに記述される。装置認証中に、ＳｅＧＷが装置認証のために装置から送られた装置証明書を無効にする必要があることを決める場合、ＳｅＧＷは装置認証が証明書取り消しのために失敗したことを装置に示し、次に、ネットワークにより維持されたホワイトリストまたは逆にネットワークにより維持されたブラックリストから装置を削除できる。このインジケーションを受け取ると、装置は、その証明書が無効にされており、そのアイデンティティがホワイトリストから取り除かれたか、反対に、ブラックリストに加えられたことを知ることができる。その後、装置は、ネットワーク上の有効なエンティティとしてそれ自体を再確立する手続きを行うことができる。

装置ＩＤが無効の場合、装置証明書が満了する場合、またはＨ（ｅ）ＮＢ装置およびその関連する証明書を発行した、信頼される第三者オペレータの公認エンティティが、証明書を無効にすることをネットワークに要求する場合、ＳｅＧＷは装置証明書を無効にすることができる。

証明書に基づいた検証基礎方法についての実施形態がここに記述される。バインディングされた証明書は、署名されたデータセットである。それは、発行人であるＳＨＯ、そのＳｅＧＷ、またはこれらの証明書を管理することに関与する従属エンティティによって署名される。証明書中の署名されたデータは、少なくともＤｅｖ＿ＩＤ、認証と検証に使用される装置公開鍵、およびＣｌｉｓｔを含む。

この証明書は、結合した検証および認証メッセージの中でＳｅＧＷに送信されうる。後者は、認証と検証用にその秘密鍵で装置によって署名されたメッセージ（部分）である。メッセージは、タイムスタンプおよび／またはリプレー保護のためのノンスのような他のデータを含むことができる。ＳｅＧＷは、メッセージと証明書の署名をチェックし、通常通り検証を続ける。

例示の証明書交換方法がここに記述される。一般に、２つの変形の実施形態が適用されうる。これらは、プレ証明書交換およびポスト証明書交換と識別される。それらは、再検証が古い証明書あるいは新しい証明書を使用するかどうかにおいて異なる。両方の変形の実施形態は、必須のステップがすべてアトミックに行われること、つまり、それら全てが完了すること、あるいはそれらのどれもが完了していないことを保証する。スタートする条件は、装置が古い証明書で古い構成を実行することであり、終了する条件は、新しい装置構成および新しい装置証明書である。認証証明書およびＲＩＭ証明書は、１つのオペレータにそれらを拘束するのではなく多くのネットワーク上で装置の使用を可能にさせるために、独立したＴＴＰあるいは製造者によって生成され、管理され、扱われる必要がありうる。あるいは、新しい装置証明書は、証明書を含めるために拡張されることができる、例えば装置管理（ＤＭ）のためのオープンなモバイルアライアンス（ＯＭＡ）によってアドレスされることができる。

プレ証明書交換方法において、アップデートは新しい証明書を含み、証明書はアップデートの完了より前に装置にもたらされる。アップデートを適用した後に、装置は、新しい証明書を使用して再検証する。装置は、ＣＮの中で適切な記憶装置およびデータ構造を使用して、「進行中のアップデート」としてマーク付けされる。例えば、認証データベースにフラグをセットすること。別の方法は、検証トークンＴ＿ＰＶＭを使用することである。

一例のプレ証明書交換のフローがここに記述される。ＤＭＳは、標準ＰＶＭにおけるように、更新された、および／または変更されたコンポーネントを装置に移す。ＤＭＳは、ＳｅＧＷに新しいＣｌｉｓｔを送る。ＤＭＳは、Ｔ＿ＰＶＭをＳｅＧＷへ渡す。これによって、ＳｅＧＷ（したがってＰＶＭシステム）は、自身が装置からの新しい構成を用いた再検証を予期する状態に入る。ＳｅＧＷは必要な情報（Ｃｌｉｓｔ、Ｄｅｖ＿Ｉｄ、装置の公開鍵など）を収集し、新しい装置証明書を生成する。ＳｅＧＷは、装置へ新しい証明書を送り、装置との通信セッションを閉じる。

ＳｅＧＷは、ＤＭＳから得られたＴ＿ＰＶＭを現在所有しており、装置から再検証を期待することを知っている。ＳｅＧＷは、内部再検証リスト中に全てのそのような装置用のＴ＿ＰＶＭを格納する。装置がアップデートおよび新しい証明書を正しくインストールするとすれば、以下のプロセスが適用される。装置は、再検証を開始し、検証メッセージ中の新しい証明書を送る。ＳｅＧＷは、署名されたデータおよび装置証明書の確認により装置を認証する。ＳｅＧＷは、再検証リスト中のＴ＿ＰＶＭを調べる。再検証が行われ、ＰＶＭシステム状態は、前の検証（および新しいものを生成せずに）からのＴ＿ＰＶＭの使用により維持される。このステップおよび前のステップはＰＶＥでではなくＳｅＧＷで行われ、そうでなければ、ＳｅＧＷは自動的に新しいトークンを生成する。したがって、再検証リストのメンテナンスはＳｅＧＷのために行われる。

再検証の多くのラウンドに関してＴ＿ＰＶＭを連続的に使用することは、標準ＰＶＭでのように、更新失敗および不規則な振る舞いの他のパターンの再発を検知するのに有用である。

さらなる実施形態では、ＴｒＥにはＨＭＳが安全で信頼できるプロセスで適用されるアップデートを装置に送ることを可能にするトラステッド・アップデート・サービスがある。セキュアスタートアップは、ＴｒＥのアップデート・サービスの完全性を保証することを当てにされうる。ＨＭＳが新しいアップデートを展開する場合、ＨＭＳは新しい更新された装置構成を含むトークンをＳｅＧＷに送ることができる。その後、ＳｅＧＷは、装置のための新しい認証証明書を生成し、ＨＭＳに送られるトークンにそれを追加できる。ＨＭＳは、装置のアップデート・サービス用のアップデートデータと一緒に新しい証明書を含む。このパッケージはＴｒＥのために暗号化され、ＨＭＳによって署名されることができる。トラステッド・アップデート・サービスは、アップデートパッケージを受け取り、署名を確認し、データを解読し、アップデートを適用し、安全な記憶装置に新しい証明書を格納する。その後、ＴｒＥは、ＨＭＳに成功したアップデートをシグナルする。トラステッド・アップデート・サービスがセキュアスタートアップによって保護されるので、更新処理は信頼されることができ、その結果、再検証は必要ではない。アップデートのタイプによって、リブートは必要でありうる。この場合、装置は、ＳｅＧＷにて新しい証明書で認証することができる。したがって、ＨＭＳは、ＳｅＧＷが生じる再検証確認に関して通知されることを確認しなければならない。

別の実施形態において、トラステッド・アップデート・サービスが装置で利用可能でない場合、証明書がアップデートの成功したインストールに結びつけられるキーで暗号化されるように、新しい証明書は、新しいソフトウェア・アップデートを供給されることができる。この方法とその関連事項はより多くの考察を必要としうる。

ポスト証明書交換方法では、アップデートは、新しい装置構成を含む新しい証明書を含むことができない。装置は、古い証明書を使用し、再検証を行う。成功した再検証の後、ＣＮは新しい証明書をアクティベートし、装置に新しい証明書を送る。装置がセキュアスタートアップを行うために新しい構成を持たないかもしれないので、新しい構成は、新しい証明書を有していないけれども、装置に送られる。

オペレータＲＩＭ保護の一例がここに記述される。無線地域網（ＷＡＮ）管理プロトコルは、装置の遠隔管理に使用されることができる。図１２は、発行人（issuer）から装置へのパッケージ・ソフトのダウンロードを可能にさせる、署名されたメッセージ・フォーマット１２００のダイアグラムの一例を示す。そのフォーマットは、ファームウェアのアップデートあるいはコンフィギュレーションパッケージのような１つまたは複数のファイルが単一の署名されたパッケージで送られることを可能にする。受信装置は、ソースを認証することができ、コンテンツをインストールする全ての指示を含む。

ヘッダー１２０５はフォーマット・バージョン並びに命令リストおよびペイロード・コンポーネントの長さを含むことができる。命令リスト１２１０は、パッケージに含まれるファイルをインストールするために実行されうる指示のシーケンスを含む。署名フィールド１２１５は、その署名されたメッセージ・データがヘッダーと命令リストから成るデジタル署名を含むことができる。署名されたメッセージ・データはパッケージ・ヘッダーおよび命令リストだけを含むが、ペイロード・ファイル１２２０を参照するコマンドがすべてファイルコンテンツのハッシュを含むので、署名は全パッケージの完全性を保証する。

オペレータＲＩＭ保護の場合には、ＤＭＳは、命令リストに署名し、メッセージのペイロードにソフトウェア・パッケージおよびそれぞれのＲＩＭを含む。その後、装置のＴｒＥは、ＤＭＳの署名を確認するために公開鍵を使用する。この公開鍵は製造時または展開時に、またはオペレータに信頼された認証機関（ＣＡ）によってＴｒＥに利用可能にされうる。公開鍵を確認するために必要なルート証明書はすべて、ＴｒＥに安全に格納されることができる。その後、命令リストは、ソフトウェアをインストールするコマンドおよび装置の中へのＲＩＭ取り込みのコマンドを含む。これは、装置上のソフトウェアおよびＲＩＭインストレーション・プロセスに対する十分なコントロールをする有効な方法をオペレータに提供する。装置へのＲＩＭｃの明示的なトランスポートは、この実施形態の変形において発生することができない。

修正（remediation）用の別のコード・ベースの使用の一例がここに記述される。総括的なＰＶＭ装置モデルのステージ２失敗のような、ＴｒＥを越えてセキュアスタートアップの失敗から生じる問題は、ＴｒＥが正常な実行スペースにロードされた修正コンポーネントまで信頼を拡張することは信頼されることができないということである。したがって、修正を開始するために、ＦＢＣは、起動されることができるが、少なくとも最も重大な機能性暗号および修正プロトコル・スタックのためにＴｒＥ内で実行する必要がある。

ある状況において、ここでＦＢＣキャリアーと呼ばれる外部の安全なソースからＦＢＣを得ることは意味をなすであろう。これは、部分的に帯域外にあるプロセスによって行われることができ、またＨ（ｅ）ＮＢ装置にスマートカードを挿入するような人間の介在を要求してもよい。このプロシージャは、別の安全な要素（スマートカード）をＦＢＣキャリアー（それは安全にＦＢＣコードを格納し保護する）として使用することを介して、あるいは単純で自動化されたＤｏＳ攻撃を緩和する修正開始プロシージャでの人間の介在を明示的に要求することにより、増強されたセキュリティを提供することができ、また、ＨＰからの勤勉として契約上必要になりうる。外部キャリアーＦＢＣは、装置を単純で安くしておき、ＴｒＥを薄く（thin）しておく手段でありうる。外部キャリアーＦＢＣは、修正についての全ての必要な秘密を含むＦＢＣの実行可能バイナリを運ぶことができ、また必要な場合にＦＢＣについてのセキュアな実行環境を提供することができる。別個のＦＢＣキャリアーの使用は、装置がリモートにある場合または位置に到達するのに困難な状況で適用可能ではないであろう。ここで記述された３つのエンティティ間の信頼確立のプロセスは、以前に記述された様々な「過渡的な信頼（transitive trust）」プロシージャに似ている。

下記手続きは、ＵＩＣＣ、スマートカードまたはそれ自身の処理装置を備えた安全なメモリーカードのような外部ＦＢＣキャリアーで当てはまるだろう。ＴｒＥは、認可され認証されたＦＢＣコードがロードされることを要求する依存パーティである。他方では、修正のための認証情報が保護され続ける限り、無認可のパーティにＦＢＣコードを知らせることは危険のより少ないことである。ＴｒＥと装置が実際には完全に信頼されない帯域外プロセスが行われるので、ＦＢＣキャリアーへのＴｒＥの認証はそれほど問題ではない。そのため、キャリアーは、ＨＭＳアクセスに使用される認証情報を装置に知らせるべきではない。ＦＣＢを明らかにすることは必要かもしれないが、重要ではないだろう。

したがって、次の認可または通信シーケンスは適用されることができる。帯域外ステップまたは人間の介在ステップは、特殊の使用事例の場合には単に実例となり、例えば、ＦＢＣキャリアーがＨ（ｅ）ＮＢに埋め込まれている場合、他の変形の実施形態で自動化され、または統合されることができる。通信は、フォールバックコード・ベースのプロシージャにおいて非常に単純でありうるし、認証と認可は単一のプロトコル・ステップで組み合わせられうる。

最初に、ステージ１のスタートアップが成功し、ステージ２のスタートアップが失敗する。ＴｒＥは「ＦＢＣを待つ」状態に止まり、ＬＥＤを光らせ、または失敗の他の同様のインジケータを提供する。ユーザ／ＨＰはＦＢＣキャリアーを挿入する。この実施形態では、ＦＢＣキャリアー（例えばホスティング・パーティ・モジュール（ＨＰＭ）のようなスマートカード）は、特別の物理インターフェースを使用してＴｒＥにそれ自体を認認し、ＦＢＣキャリアーの存在を示し、および／または認可秘密（例えばＯＴＰ、署名されたノンス）を提出する。暗号化され完全性保護された通信セッションであるセキュリティ・アソシエーション（ＳＡ）は、ＴｒＥとＦＢＣの間で設定される。ＦＢＣは、ＴｒＥあるいはＦＢＣキャリアーによって提供されうる、または両方の環境の能力の任意のコンビネーションでありうる安全な環境にロードされる。ＦＢＣは、必要に応じて完全性チェックされることができ、次に、ダウンロードされて、始められる。

安全なスタートの後、ＦＢＣは、キャリアーにその成功したロードを示すために秘密を使用し、ＴｒＥ（ＦＢＣ）およびキャリアーの間のフレッシュなＳＡを生成する。修正のための認証情報はキャリアーに残るが、ＦＢＣは、ＨＭＳ発見用データを含んでいる。ＦＢＣはＨＭＳと連絡をとる。スマートカードとＨＭＳの間のエンドツーエンドＳＡは、ＴｒＥ（ＦＢＣ）に完全に利用不可能なままである、スマートカードに保護された認証情報を使用して確立される。ＨＭＳは、有効なＴｒＥ（ＦＢＣ）が修正を要求していることを現在知っている。スマートカードは、ＴｒＥ（ＦＢＣ）に通信セッションを渡し、ＴｒＥ（ＦＢＣ）はＨＭＳにそのＩＤを示す。ＨＭＳは修正プロシージャを始める。この種の接続が多くの装置に適用されることができ、ブリーチ（breach）が破滅的かもしれないので、認可秘密（authorization secret）はよく保護されることができる。認可をインプリメントする１つの方法は、所有権取得プロシージャで作成されるように１６０ビットのＨＷに保護された値のようなＴＰＭに保護された認可秘密を使用することである。インプリメンテーションによって、ＦＢＣは、ＦＢＣキャリアーから直接始められることができるが、それは安全かつ着実な実行環境を提供しなければならない。この場合、危険にさらされたＴｒＥは恐らく交換されうる。１つの例は、ＦＢＣキャリアーが、ＦＢＣを独立して実行するために、安全な要素、超小型演算処理装置およびメモリから構成される場合であろう。ＦＢＣキャリアーは共通のインターフェース（例えばＵＳＢ、ＪＴＡＧ）経由で装置にアタッチされることができ、装置内のコンポーネントに直接認証し、危険にさらされたコンポーネントおよびＴｒＥの部分を交換する。別の変形の実施形態中で、署名されたコード・イメージが使用される場合、ＦＢＣキャリアーは署名を含むイメージを交換できる。

ＴｒＥは、ある場合にはＦＢＣを正しくロードし実行するのには完全に信頼できないかもしれないし、ほとんどの場合ＦＢＣキャリアーにロードするＦＢＣを有効にすることができないかもしれないので、あるセキュリティ拡張は、ＦＢＣキャリアーが遠隔のコード・ベース実行に対する信用を確立しなければならないように含まれている。例えば、ＦＢＣキャリアーは、１回限りの秘密を生成し、難読化（obfuscation）方法を使用してＦＢＣにそれを埋め込む。あるいは、ＦＢＣと一緒に、あるいはＦＢＣの後直接、キャリアーは別の認可秘密を送信できるが、それは成功裡に始められたＦＢＣによってのみ認識され使用されることができる。この秘密は、通信のまさに次のステップの通信秘密をＴｒＥの中のある保護された場所から得るために、成功裡に始められたＦＢＣによって使用される。

フォールバックコードについての内部並列コード・ベースを使用する例がここに記述される。内部並列コード・ベースは、トリガー機構、および修正を促進するために必要とされるフォールバックコード・ベースを含むことができる。例えば、Ｈ（ｅ）ＮＢは２つのコード・イメージ、１つは正規モードおよび１つはフォールバックコード・イメージ（ＦＢＣ）を含むことができる。正規モードの提示は、複数ステージにおいてＡｕＶとＳＡＶの両方について実行されることができる。ステージ１では、ＲＯＭの中のＲｏＴはＴｒＥを確認する。ＴｒＥが有効な場合、次のステージコンポーネントがチェックされることができる。その後のいずれかのコンポーネントがその完全性チェックに失敗する場合、コードはＴｒＥコードのスタートにアンロードされる。この時に、ＴｒＥは、修正などのフォールバックコードをチェックし始めることができる。フォールバックコードが完全性チェックに合格する場合、フォールバックコードはロードされ、始められることができる。フォールバックコードは、ＨＭＳとの接続を確立するように装置管理（ＤＭ）コードのある最小のセットを含むことができる。一旦ＨＭＳへの接続が確立されれば、失敗したモジュールは識別され、アップデートがＨＮＢに送られることができる。修正プロセスが完了すると、Ｈ（ｅ）ＮＢはリブートされ、検証プロセスが改めてもう一度始められる。フォールバックコード・サイズはＨＭＳとの通信を促進するために小さくしておくことができる。コードはＴｒＥにロールバックされ、フォールバックコードとともにロードされうるのでトリガー機構またはレジスタの必要はないであろう。

付加的な変形の実施形態「ハイブリッド（内部／外部の）コード・ベース」がここに記述される。ＦＢＣは、上述された並列コード・ベースの場合でのように装置内部で格納されることができるが、ＦＢＣは暗号化され、装置上での完全性は保護される。ＴｒＥ自身はＦＢＣを解読するために使用することができず、そうでなければ、危険にさらされたＴｒＥは、ＦＢＣ自体のセキュリティ侵害に結びつくであろう。ハイブリッド解決は、スマートカードかＵＩＣＣのような外部の安全な要素上にＦＢＣイメージのための解読および確認キーを格納する。スタート失敗の場合には、ＴｒＥがこの失敗をシグナルし、ユーザ／ＨＰは、装置に認証トークン（つまりスマートカード）を挿入することを要求される。装置特性によって、２つのオプションが利用可能である。第１のオプションでは、認証トークンは単に重要な資料を格納し、ＴｒＥが必要な重要な資料を受信する際、あるいはその後にＴｒＥとの相互認証を行う。ＴｒＥは、ＦＢＣの完全性チェックおよび解読を行い、次に、ＦＢＣをロードし、スタートする。第２のオプションでは、認証トークンは装置上に格納されたＦＢＣを自律的に確認し解読して、次に、装置のリソースだけを使用して（例えば、安全な実行環境を提供するためにＴｒＥの部分を使用して）、あるいはＦＢＣが実行されうる場合に認証トークン自体の内部の安全な実行環境を提供することによってＦＢＣを実行するという意味で認証トークンは強化される。この変形の実施形態によれば、追加的な外部の安全要素のセキュリティを組み合わせて、ユーザにＦＢＣストレージ記憶装置用の、装置のより大きな記憶容量を与える。

内部のシーケンシャルなコード・ベースを使用する実施形態がここに記述される。装置管理プロトコルは、リモート装置上のソフトウェア構成をインストールし変更するプロトコルおよびコマンドを定義することができ、および「リブート」コマンドを含むことができる。装置管理プロトコルは、「修正必要」メッセージを送信する装置についての概念を含むことができない。しかしながら、ＳＡＶなどの検証の結果および装置管理プロトコルを組み合わせると、ＨＭＳは、装置管理プロトコルを使用してソフトウェアコンポーネント再インストールまたはリセットを開始し、再検証のためにリブート・コマンドを発行することができる。

あるいは、ＦＢＣは、正常なコードの残りだけを残して、正常なコードの一部を削除するかアンインストールし、およびリブートして再検証を始めることができる。ＦＢＣは、削除されるかアンインストールされる必要のある正常なコードのリストが予め設定されることができる。あるいは、ＦＢＣは、スマートカード（例えばＨＰＭ）のような外部の安全な要素からそのようなリストを得ることができる。あるいは、ＦＢＣは、Ｈ（ｅ）ＭＳのようなネットワークベースのエンティティからそのようなリストを得ることができる。

安全に働くこのメカニズムに関して、それは、次のプロパティを含みうる装置上の信頼されたアプリケーションを持っているであろう：保護された完全性；装置に安全に格納された；失敗したセキュアスタートアップの場合に始められることが可能；ＨＭＳへの（安全な）接続を確立する；ＨＭＳからのソフトウェアおよびコマンド上の署名を確認することが可能；ソフトウェアを装置にインストールする／アンインストールすることが可能；および装置が修正を必要とすると報告することが可能。

第２のコード・ベースイメージは、恐らく重複するが、このアプリケーションをホストするために使用されることができる。説明に従い、および上述した要件を厳守して、第２のコード・ベースは、いくらかの付加的で・余分のコードを装置の中にもたらす。このコード・ベースによって提供される特徴はすべて、装置中の正常で成功したセキュアスタートアップの場合には必要であろう。第２のコード・ベースのすべての特徴はプライマリー・コード・ベースに存在することができる。

別の変形の実施形態は、並列デザインをシーケンシャルデザインで置き換えることである。これは次のシーケンスを含むことができる。ＲｏＴはＴｒＥを確認し、成功したら開始する。成功したら、ＴｒＥは修正コードを確認する。成功したらＴｒＥは残りのソフトウェアコンポーネントを確認する。そうでなければ、ＴｒＥは失敗したモジュールを格納し、装置が修正を必要とするというフラグをセットする。その後、ＴｒＥは、装置のリブートをトリガーする。リブートに際して、修正コードの確認の後、ＴｒＥは、修正コードにコントロールを伝えて、失敗したモジュールのリストをリリースする。修正コードは、このリストを使用して、装置修正プロセスのためにＨＭＳとコンタクトできる。

セキュリティ・ポリシー属性を使用するＳＡＶの一例がここに記述される。どのモジュールが内部完全性チェックに失敗したかをＰＶＥに通知することは、Ｈ（ｅ）ＮＢのすべての型およびモデルについての全てのＳＷモジュールの標準化リストを生成することを含むことができる。セキュリティ・ポリシー属性（ＳＰＡ）の標準化リストを生成することは容認可能である。ＳＰＡは、特定のＳＷモジュールがその完全性チェックに失敗する場合にどんなアクションがとられるかをＰＶＥに伝えるポリシーでありうる。ＰＶＥは、失敗したモジュールに関して他に何も知る必要はない。

ＳＰＡのコードは、標準化され、次のコードを含むことができる。「００」モジュール失敗は、ネットワークアクセスを否定しなければならないことを示すことができる。このタイプの全てのモジュールはステージ２にありうるが、このコーディングをステージ３モジュールの中で行うことは柔軟性を可能にする。「０１」モジュール失敗は、一時的ネットワークアクセスを許可することを示すことができる。修正についてのセクションにて述べられているように、この一時的ネットワークアクセスは、例えば、失敗したＳＷモジュールの修復用の修正センターを使用して、修正を行う装置によって使用されることができ、修正が成功しない場合、それはネットワークアクセスを止めることができる。「０２」モジュール失敗は、ネットワークアクセスを許可することを示すことができる。これは、失敗したＳＷモジュールの修復のために修正センターを参照し、修正が成功しない場合、ネットワークアクセスを継続できる。「０３」モジュール失敗は、ネットワークアクセスを許可することを示すことができる。それは、失敗したＳＷモジュールを削除／無効／隔離することができ、アクションが成功しない場合、ネットワークアクセスを止めることができる。「０４」モジュール失敗は、ネットワークアクセスを許可することを示すことができる。それは、失敗したＳＷモジュールを削除／無効／隔離することができ、アクションが成功しない場合、ネットワークアクセスを継続することができる。「０５」モジュール失敗は、ネットワークアクセスを許可することを示し、ＳＷの完全性失敗を無視できる。「０６」モジュール失敗は、他の失敗を示すことができる。

単一のＳＰＡは、Ｈ（ｅ）ＮＢの中でそれぞれのステージ３のＳＷモジュールに関連しうる。実際のＳＷモジュール識別子は、Ｈ（ｅ）ＮＢのそれぞれの形およびモデルに専用でありうる。ＳＡＶでは、Ｈ（ｅ）ＮＢは、既にＳｅＧＷにＨ（ｅ）ＮＢ＿ＩＤを送るが、Ｈ（ｅ）ＮＢ＿ＩＤは、Ｈ（ｅ）ＮＢの型、モデルおよびシリアルナンバーを識別するためにネットワークによって使用されうる。各ステージ３の完全性チェック失敗について、Ｈ（ｅ）ＮＢは、Ｎｏｔｉｆｙペイロードの中に、専用のＳＷモジュールＩＤおよび対応するＳＰＡを置く。私たちの既存のＳＡＶスキームごとにのように、ペイロードはＰＶＥに転送される。

ＰＶＥはＳＰＡを検査し、ＳＰＡ＝００がある場合、ＳｅＧＷは、Ｈ（ｅ）ＮＢへのアクセスを与えることを認められない。ＳＰＡ＝０１かＳＰＡ＝０２がある場合、修正プロセスがトリガーされる。ＰＶＥは、Ｈ（ｅ）ＮＢ＿ＩＤおよびＳＷモジュールＩＤを送る。修正センターは、専用のＳＷモジュールＩＤを相互参照するためにＨ（ｅ）ＮＢ＿ＩＤを使用でき、Ｈ（ｅ）ＮＢに正確なアップデートをダウンロードすることができる。

ＳＰＡ＝０３かＳＰＡ＝０４がある場合、ＰＶＥはＳｅＧＷに適切な指示を送ることができる。ＳＰＡ＝０５がある場合、Ｈ（ｅ）ＭＳまたは他のネットワーク構成要素は、管理目的のためにデータを格納することができる。

任意で、再ブート／再検証すること、および非００のＳＰＡに含まれるＡＣＫメッセージングがありうる。ＳＰＡ＝００は、ネットワークが悪いＨ（ｅ）ＮＢに関する情報を有し、管理アクションが行われうる以外は、ＡｕＶと同じ最終結果を持っている。任意で、ＰＶＥは、それらの完全性チェックを通すモジュールのことを伝えられないであろう。

ＦＢＣが基礎的な通信をサポートする場合、ＰＶＭはステージ２モジュールの失敗を含むように拡張できる。ＳＰＡは、ＳＷモジュールＩＤを含むオブジェクトの一部でありうる。それらはＴｒＥに格納されなければならない。それらはＳＷモジュールの一部として格納されないであろうし、それらは、ＳＷモジュールの失敗した完全性チェックの場合には信頼されないであろう。

個々のＳＷモジュールに割り当てられたＳＰＡは、リスク評価プロセスに基づいて、ＳＷスタックの型式承認の一部として各Ｈ（ｅ）ＮＢサプライヤーに同意できる。一旦サプライヤーがオペレータとの関係を確立したならば、新しいＳＷモジュールにＳＰＡを割り当てることは単純であろう。確立したサプライヤーは前の成功した承認に基づいて適切なＳＰＡを割り当てるように信頼されることができる。

Ｈ（ｅ）ＮＢ構造のＳＷ構造の標準化の必要性を減少させるために、ブロックが完全性チェックの点から、および何が修正されうるのかという点から最小のアトミックな塊あるいは量として定義される場合、Ｈ（ｅ）ＮＢのＳＷ構造はコードのブロックの点から定義されることができる。個々のブロック関数は定義されないであろう。例えば、ステージ３ＳＷのすべては、完全性チェックの観点から単一のブロックでありうる。あるいは、ブロックは実際のＳＷアプリケーション、またはアプリケーション内のセンシティブなオブジェクト上に１：１にマッピングできる。ＳＰＡはＳＷブロックに適用されることができる。修正センターがＳＰＡ０１または０２のために起動される場合、それは必要なブロックをダウンロードする。ブロックのＩＤはベンダーに関連してもよく、アーキテクチャは標準化されないかもしれない。

ＳＰＡが装置検証の中で使用される場合、ＳＰＡは、ＴｒＥに安全に格納されることができ、およびＳＷ識別子に結合しうる。例えば、０５−ＳＰＡが００−ＳＰＡとともに別のコンポーネントのためにリプレーされないかもしれないことが保証されうる。したがって、ＰＶＥは、Ｈ（ｅ）ＮＢの中のロードされたコンポーネントに受信ＳＰＡが実際に属することを確認することができる。

装置の最初の初期ネットワーク接続時に開始される登録プロセスは、装置からＣ＿ＤＢにＳＰＡを安全に転送し、かつ将来の使用のためにそれらを格納するために使用されることができる。その後、装置は、失敗したコンポーネントのＳＷ＿ＩＤを報告することができ、また、ＰＶＥはローカル・データベースから対応するＳＰＡのポリシーアクションを検索することができる。これは低帯域幅で接続している装置に役立つであろう。

ＳＰＡをグループ化するための実施形態がここに記述される。ＳＰＡがＴｒＥ上にローカルに格納されれば、ＴｒＥは全ての失敗したコードおよびそれらのＳＰＡを検査でき、それらを処理し、およびもっと要約されたステージ完全性チェックを送ることができる。失敗したモジュールおよびそれらのＳＰＡは、表１に示されるものを含むことができる。

ＴｒＥは、表２に示されるようなデータを処理できる。

異なる程度に失敗したモジュールのリスト（それはＳＰＡによって示される）は、すべてのＳＰＡ値の代わりに送られることができる。

したがって、Ｎｏｔｉｆｙメッセージ中のいくつかのビットブロックが定義される場合、表３に示されるようなマッピングを持っているであろう。

データのコンパクトさは、期待される失敗したモジュールの数に依存するであろう。例えば、平均で１つを超えるモジュールがほとんどのＳＰＡについて失敗すれば、データはよりコンパクトとなろう。

図１３は、遠隔のアテステーションを介した検証方法の一例の図を示す。検証エンティティ１３００は、ＳＭＬおよび署名されたＰＣＲ値を受け取る。ＳＭＬは、それぞれのＰＣＲへ拡張されたすべてのファイルの順序付きリストを含む。検証エンティティ１３００は、ＳＭＬの中のすべてのエントリ用の次のステップを行う。検証エンティティ１３００は、所定のファイル名が既知の良好なハッシュ値のローカル・データベース１３１０に存在するかどうかを問い合わせる（１）。このデータベース１３１０は、全てのファイル名、および信頼できると考えられるバイナリのＲＩＭ（ハッシュのような）を含む。データベースでファイル名を見つけることができない場合、そのファイル名は信頼できないと考えられる（２）。検証エンティティ１３００は、ＲＩＭをＳＭＬからの報告された測定値と比較できる（３）。それらが一致しない場合、プラットフォーム上のバイナリは（ユーザ、マルウェアあるいは他のエンティティによって）変更された。この場合、プラットフォームは信頼されることができない（４）。検証エンティティ１３００は、仮想ＰＣＲ上で拡張オペレーションを行うことができる。本質的に、検証エンティティはプラットフォームが実行と測定の間に行ったのとまったく同じステップを行う。このプロセスの終わりに、仮想ＰＣＲの値は、プラットフォームからの報告された値と比較される（６）。それらが一致しない場合、ＳＭＬは、改ざんされたものである（例えば、ＳＭＬからのラインが削除されるが、ハッシュ値がＰＣＲまで拡張されたならば、仮想ＰＣＲおよび報告されたＰＣＲはミスマッチであろう）。その後、プラットフォームは信頼できないと考えられる（７）。

ロードしたコンポーネントのリストをＣｌｉｓｔの中でのように報告するため、Ｆ−ＳＡＶの場合の失敗したモジュールのリストを報告するため、あるいは測定値を報告するための変形の実施形態として、モジュール間の階層関係は、報告された要素の数を減らすため、および待ち時間要件のために利用されることができる。例示の配置は図１４に示される。そのような配置は、自動的にモジュールへの自然な指令を引き起こす。可能なモジュールの数がＯＳ、プロトコル・スタック、管理モジュールおよび他のモジュールにより非常に高いかもしれないので、モジュールの数は大きくなりうる。

成功したセキュアスタートアップの後、ＰＶＥまたはＳｅＧＷは、成功したスタートアップを示す証明書を装置に発行しなければならない。そのような証明書は、ＴｒＥ＿ＩＤ、（ソフトウェア、ハードウェアの）バージョン番号あるいはソフトウェアのハッシュのような情報要素および安全なタイムスタンプ、装置の位置、モジュールのハッシュ、モジュールのＣｌｉｓｔおよび他の関連情報を含む。

そのような証明書は失敗したスタートアップに役立つであろう。この場合、情報はＰＶＥに送られ、また、ＰＶＥは、報告されたバージョン番号が正確であることを真正に確認できる。ＰＶＥは、証明書の発行者であるので、適切なステップを取ることができる。違いは、ＰＶＥが装置が成功したスタートアップステータスを示す場合ほど信頼のために装置に依存しないということである。しかしながら、その失敗したスタートアップケースに関する装置から受け取った何らかの情報を少なくともＰＶＥが信頼することができる場合、これは単に機能するであろう。したがって、装置はこの場合設計されることができ、その機能性は、失敗したスタートアップの状態を検知し、および装置がまだ完全であり、侵害を受けていないというステータスをＰＶＥに報告する。

証明書はまた、成功したスタートアップに役立つであろう。この場合、後続のセキュアスタートアッププロセスでは、装置は、測定値のハッシュ値または測定値、およびＰＶＥまたはそれへのポインタによって発行された最近のセキュアスタートアップの証明書のハッシュ値を送ることができる。そうする際に、ＰＶＥは、悪意のある変更があるかどうかを確認できる。

証明書は、さらに１つの地理的区分あるいはオペレータ領域でブートする装置が新しいオペレータ領域へ移動する時に役立つであろう。これは地理追跡装置の場合に起こる。トラッキング・データを確認するために、装置が成功裡にブートし、生成されるデータが本物であるかどうかを知る必要がある。成功したスタートアップのそのような証明書は、装置によって生成されたデータを提供されることができる。証明書内では、スタートアップが成功裡に達成された時の装置の位置が含まれうる。その後、そのような証明書の第三者受取人が証明書の信頼性を確認しようとする場合、それは、装置のその当時の位置をチェックし（好ましくは、装置自身内の位置情報の処理に依存しない方法、例えばＧＰＳベースの方法を使用して）、および得られたその当時の位置が証明書に含まれる位置に一致するかどうかを確かめることができる。誤った組合せがある場合、証明書の受取人は、装置あるいは装置の再検証を管理するネットワークエンティティのいずれかに、装置の新しいセキュアスタートアップおよび装置の完全性の後続の再検証を要求することができる。目的のネットワークが最後の成功したスタートアップの（位置を含む）コンテキストおよび構成のことを知っている必要がある場合、最後の成功したスタートアップが起こった位置についての情報を含むそのような証明書は、途中での失敗の場合に役に立つであろう。

ここに記述されるように、ＰＶＭは検証のどんな形式も使用できる。一般に、３つの主な方法は、ＡｕＶ、ＳＡＶおよびリモート検証（ＲＶ）である。それぞれの方法は、装置の完全性検証に異なるように関連付けられる測定、報告および施行のステップを扱う。ＡｕＶは、装置上で３ステップをすべてローカルに行う。ＲＶは測定をローカルに行い、外部エンティティに測定を報告する。施行は外部エンティティによって行われる。ＳＡＶはセキュアスタートアップをローカルに施行し、外部エンティティにメトリクスを報告し、再検証を可能にさせる。

特に、ＳＡＶを使用する装置は、信頼状態測定の直接推定を行い、最初のネットワーク接続を確立できる。関係のある参照メトリクスと共に評価の結果は、セキュリティゲートウェイ（ＳｅＧＷ）のような外部エンティティに報告されることができる（以下で、検証報告書という）。任意に、測定値と参照メトリクスの部分集合は報告されることができる。

検証報告書は、そのプラットフォーム・アーキテクチャ、セキュリティ・アーキテクチャ、セキュリティ・ポリシーおよび装置証明書のようなＨ（ｅ）ＮＢの特性に基づいてＨ（ｅ）ＮＢの信頼状態の評価を可能にする。検証報告書は、Ｈ（ｅ）ＮＢ、ＴｒＥ能力、測定と確認の実行、ＴｒＥのセキュリティ・ポリシー・マネージャ能力、測定結果、プラットフォーム・レベル証明情報、最後の起動時間あるいはブート・カウンタについての情報を含むことができる。

装置についての情報は例えば、メーカー、型、型番、バージョン番号、ハードウェアビルドつまりバージョン番号、あるいはソフトウェアビルドつまりバージョン番号を含むことができる。ＴｒＥ能力は例えば、測定、ベリフィケーション、報告および施行能力を含むことができる。

測定および内部確認実行情報は、セキュアスタートアップ中に信頼状態測定および内部確認を行う方法を含むことができる。例えば、ロードしたコンポーネントの名前、タイプおよびシーケンスのような対象範囲が含まれうる。確認に対する信用のチェーンの数および範囲のようなコンポーネントの確認方法が含まれうる。セキュアハッシュアルゴリズム１（ＳＨＡ−１）拡張のような、測定および確認に使用されるアルゴリズムが含まれうる。スタートアップの確認においてカバーされるプラットフォーム構成レジスタ（ＰＣＲ）のような登録の範囲も含まれうる。

ＴｒＥのセキュリティ・ポリシー・マネージャ能力は、セキュリティ・ポリシーのインプリメンテーションおよび施行に関する情報を含むことができる。測定結果は、署名されたＰＣＲ値のような、内部的に報告され、確認される実測値を含むことができる。プラットフォーム・レベル証明情報は、一般にＨ（ｅ）ＮＢに関する情報、あるいは特にＴｒＥに関する情報を含むことができる。最後のブート時間は、最後の安全なブートがいつ実行されたかの安全なタイムスタンプを含むことができる。

ブート・カウンタは、パワー・サイクルが生じ、安全なブート・オペレーションが実行される度にインクリメントするカウンタの値を含むことができる。カウンタは、リセットまたはリバースされることができず、カウントを進める保護されたカウンタでありうる。装置が最初に初期化される場合、カウンタ値は０に初期化されることができる。

検証報告書は、ＩＫＥｖ２（Internet Key Exchange version 2）プロトコルのような認証プロトコルに情報をバインディングすることにより、結合した認証および検証手続きを介してＨ（ｅ）ＮＢに結び付けられうる。検証報告書は証明書を含むことができる。任意に、情報のいくつかは証明書に含まれうる。

あるいは、検証報告書は、信頼状態情報を提供する信頼された第三者（ＴＴＰ）へのポインタあるいは参照を含むことができ、また、外部エンティティはＴＴＰから信頼状態情報を得る。例えば、検証報告書は、信頼状態情報を含む個別の装置信用証明書への参照を含むことができる。

評価の間に遭遇した例外に応じて、外部エンティティはネットワークアクセスを拒絶できる。外部エンティティはさらに測定値と参照メトリクスを評価し、およびＨ（ｅ）ＮＢによって検知され報告されたエラーを検知できる。あるいは、Ｈ（ｅ）ＮＢは制限のあるネットワークアクセス（隔離された）を与えられうる。そうでなければ、Ｈ（ｅ）ＮＢはネットワークアクセスを与えられうる。Ｈ（ｅ）ＮＢは、外部装置からのリクエストに応じて信頼状態測定を行い、評価し、報告することができる。そのリクエストは、オペレータによって開始されうる。再検証は、スタートアップ中に有効にならなかった要素を有効にできる。主要ではない検証エラーが検知される場合に改善策を行うために、外部エンティティはＨ（ｅ）ＮＢにリクエストを送ることができる。例えば、Ｈ（ｅ）ＮＢは、改善のリクエストに応じて所定の状態に戻ることができる。

セキュリティ上の弱点がセキュアスタートアップ時に検知されないとしても、ＳＡＶは、インジケータを介してセキュリティ侵害の検知を考慮する。セキュリティ属性によって、障害が起きた装置で修正ステップが行われることができる。これは、ネットワークに送信されたインジケータが、コアとなるセキュアスタートアップがセキュリティ侵害されておらず、セキュリティ属性が通信されることを示す限りは可能である。障害が起きた装置は、リブートまたは再検証の要求によって検知される。よって、検知の可能性はより高い。ソフトウェア・アップデートはＯＴＡで提供されることができ、サービス技術者が装置を置き換えるのに必要とされないかもしれない。ＳＡＶは、きめの細かいアクセス制御をＣＮに許可し、インジケータおよびローカル施行の使用によるＲＶよりも低い帯域幅の使用を提供する。

ＳＡＶは、装置セキュリティ特性および検証測定の中に、よりきめの細かい、可視性につながるＡｕＶとＲＶの利点を組み合わせる。それは、低い帯域幅使用法、自律検証に相当するローカル装置のリソース、障害が起きた装置のより速くより容易な検知を提供し、障害が起きた装置のための隔離ネットワークの使用を可能にする。

図１５は、ＷＴＲＵ１５１０、Ｈ（ｅ）ＮＢ１５２０およびＨ（ｅ）ＭＳ１５３０を含む、無線通信ネットワーク１５００の例示的なブロック図である。図１５に示されるように、ＷＴＲＵ１５１０、Ｈ（ｅ）ＮＢ１５２０およびＨ（ｅ）ＭＳ１５３０は、プラットフォーム検証および管理を行うように構成される。

典型的なＷＴＲＵで見つかるかもしれないコンポーネントに加えて、ＷＴＲＵ１５１０は、オプションのリンクしたメモリ１５２２を備えたプロセッサ１５１６、少なくとも１つのトランシーバ１５１４、オプションのバッテリー１５２０およびアンテナ１５１８を含む。プロセッサ１５１６は、Ｈ（ｅ）ＮＢ１５２０のような基地局経由でそれに伝えられるＰＶＭ機能に関して補足的なプラットフォーム検証および管理機能を行うように構成される。トランシーバ１５１４は、プロセッサ１５１６およびアンテナ１５１８と通信を行い、無線通信の送受信を促進する。バッテリー１５２０は、ＷＴＲＵ１５１０の中で使用される場合、トランシーバ１５１４およびプロセッサ１５１６に電力を供給する。

典型的なＨ（ｅ）ＮＢで見つかるかもしれないコンポーネントに加えて、Ｈ（ｅ）ＮＢ１５２０は、オプションのリンクしたメモリ１５１５を備えたプロセッサ１５１７、トランシーバ１５１９およびアンテナ１５２１を含む。プロセッサ１５１７は、ＰＶＭ方法論を実行するプラットフォーム検証および管理機能を行うように構成される。トランシーバ１５１９は、プロセッサ１５１７およびアンテナ１５２１と通信を行い、無線通信の送受信を促進する。Ｈ（ｅ）ＮＢ１５２０は、オプションのリンクしたメモリ１５３４を備えたプロセッサ１５３３を含むＨ（ｅ）ＭＳ１５３０に接続する。

図１５に示されないが、典型的なＳｅＧＷおよびＰＶＥで見つかるようなコンポーネントに加えて、ＳｅＧＷおよびＰＶＥは、オプションのリンクしたメモリを備えたプロセッサ、トランシーバ、アンテナ、また通信ポートを含むことができる。プロセッサは、ＰＶＭ方法論を実行するプラットフォーム検証および管理機能を行うように構成される。トランシーバと通信ポートは、プロセッサおよびアンテナと通信を行い、必要に応じて通信の送受信を促進する。

ネットワーク構成要素は、様々な例に関して詳細に本明細書で示された所望のＰＶＭ機能を行うように選択的に構成される。さらに、ＰＶＭ対応のネットワークおよびリソースへのそれらの信頼できるアクセスおよび使用を促進するために、ＷＴＲＵは、確認、検証および他の信頼要因に関してのような補足的なＰＶＭ機能性で構成されることができる。

例として、それぞれのコンポーネントはすべてアクティブなエンティティ間の責務アプローチのＰＶＭの最大のタイプ分離を使用するように構成される。本明細書で説明されるように、様々なエンティティ間のある情報を通すために、これはＰＶＭトークンの使用を通じて促進されることができる。

実施形態
１．プラットフォームの検証および管理（ＰＶＭ）のための方法であって、装置からの検証メッセージに応答してＰＶＭトークンを受信するステップであって、前記ＰＶＭトークンは少なくとも前記装置からの確認情報を含む、ステップを備える方法。

２．ＰＶＭトークンからの所定の情報を使用して検証を行うステップをさらに含む実施形態１の方法。

３．失敗したコンポーネントに応答して、装置管理システム（ＤＭＳ）に異常レポートを送り、改善および再検証を開始するステップをさらに含む前述のいずれかの実施形態の方法。

４．検証結果を備えた変更されたＰＶＭトークンを送るステップをさらに含む前述のいずれかの実施形態の方法。

５．検証を行うステップは、少なくとも１つの異常状態の適用可能性を判定することを含む前述のいずれかの実施形態の方法。

６．検証は、リモート検証（ＲＶ）、自律的検証（ＡｕＶ）、準自律的検証（ＳＡＶ）、完全−ＳＡＶ（Ｆ−ＳＡＶ）、最小の検証あるいはパラメータ検証のうちの少なくとも１つを使用して行われる、前述のいずれかの実施形態の方法。

７．確認情報は、装置アイデンティティ、装置情報、トラステッド環境（ＴｒＥ）情報、確認データ、確認結合、およびコンポーネントへのコンポーネント指標の順序づけられたコンポーネント・リストのうちの少なくとも１つを含む、前述のいずれかの実施形態の方法。

８．検証を行うステップは、ＴｒＥを信頼できないと判定すること、完全性測定／確認データのミスマッチを判定すること、コンポーネントについての見当たらない参照完全性メトリクス（ＲＩＭ）を判定すること、ロードしたコンポーネントのポリシー失敗のリストを判定すること、失効した装置またはＲＩＭ証明書を判定することのうち少なくとも１つを含む、前述のいずれかの実施形態の方法。

９．ＰＶＭトークンは、検証ＴｒＥのアイデンティティおよび検証プロセスに結び付けられる、前述のいずれかの実施形態の方法。

１０．検証のフレッシュネスは、ＰＶＭトークンにタイムスタンプを押すこと、およびＰＶＭトークンを通るすべてのエンティティによって時系列のリストを追加することによって制御される、前述のいずれかの実施形態の方法。

１１．ＲＩＭ証明書中の装置アイデンティティを使用することにより個別化を確立することをさらに含む、前述のいずれかの実施形態の方法。

１２．隔離、ホワイトリスト、ブラックリストおよびグレーリストの適用可能性を判定するためにＰＶＭトークンをＤＭＳに送ることをさらに含む、前述のいずれかの実施形態の方法。

１３．グレーリストがネットワークにとって新しい装置、長期間の間接続されていない装置、疑わしい振る舞いを備えた装置、およびセキュリティ警告が存在する装置の少なくとも１つを含む、前述のいずれかの実施形態の方法。

１４．オペレータＲＩＭ保護は、様々な外部ソースから来る装置コンポーネントの所定のＲＩＭ証明書をオペレータＲＩＭ証明書で交換する前述のいずれかの実施形態の方法。

１５．ＰＶＭトークンの中で受け取られる情報をチェックするために、検証データベースにクエリが送られる、前述のいずれかの実施形態の方法。

１６．所定の識別子に基づいて構成ポリシーを検索するために、構成データベースにクエリが送られる、前述のいずれかの実施形態の方法。

１７．検索された構成ポリシーが評価される、前述のいずれかの実施形態の方法。

１８．不良状態に応じてメッセージが検証データベース・マネージャに送られる、前述のいずれかの実施形態の方法。

１９．プラットフォームの検証および管理（ＰＶＭ）に結合される装置の検証を行う方法であって、装置の少なくとも１つの以前に指定されたコンポーネントの完全性チェックを行うことと、完全性チェックの結果を格納することと、を備える方法。

２０．装置上でセキュアスタートアップチェックを行うことと、セキュアスタートアップチェックの結果を格納することと、をさらに備える実施形態１９の方法。

２１．完全性チェックの結果およびセキュアスタートアップチェックの結果に基づいて検証メッセージを形成することをさらに含む実施形態１９乃至２０のうちのいずれか１つに記載の方法。

２２．ＰＶＭに検証メッセージを転送することをさらに含む実施形態１９乃至２１のうちのいずれか１つに記載の方法。

２３．ステージにおいてセキュアスタートアップを行うことと、ＴｒＥコンポーネントのローカル検証が成功する条件で、それぞれのトラステッド環境（ＴｒＥ）コンポーネントがロードされることを保証することと、をさらに含む実施形態１９乃至２２のうちのいずれか１つに記載の方法。

２４．第１のステージにて、信頼のルーツ（ＲｏＴ）に依存するセキュアスタートアップを介してＴｒＥのコンポーネントをロードすることをさらに含む実施形態１９乃至２３のうちのいずれか１つに記載の方法。

２５．第２のステージにて、ＰＶＭとの通信を許すためにＴｒＥの外側でコンポーネントをロードすることをさらに含む実施形態１９乃至２４のうちのいずれか１つに記載の方法。

２６．装置の残りのコンポーネントをロードすることをさらに含む実施形態１９乃至２５のうちのいずれか１つに記載の方法。

２７．完全性チェックを行うことが少なくとも１つの信頼された基準値およびＴｒＥに基づく、実施形態１９乃至２６のうちのいずれか１つに記載の方法。

２８．検証メッセージは、第１および第２のステージ中に確立した完全性の測定結果としてローカルのパス／失敗のインジケータを含む、実施形態１９乃至２７のうちのいずれか１つに記載の方法。

２９．フォールバックコード・ベースをさらに含む、実施形態１９乃至２８のうちのいずれか１つに記載の方法。

３０．フォールバックコード・ベースを開始することは、ＲＩＭを含む主なコード・ベースのソフトウェア・アップデートをトリガーすることを含む、実施形態１９乃至２９のうちのいずれか１つに記載の方法。

３１．フォールバックコード・ベースがロードされるという条件でディストレス信号を送ることをさらに含む、実施形態１９乃至３０のうちのいずれか１つに記載の方法。

３２．フォールバックコード（ＦＢＣ）イメージは、装置の修正を促進し、および安全なメモリに格納される、実施形態１９乃至３１のうちのいずれか１つに記載の方法。

３３．登録されたコンポーネントだけが活性化されることを完全性チェックが判定する、実施形態１９乃至３２のうちのいずれか１つに記載の方法。

３４．メモリにロードすることにより、登録されたコンポーネントが活性化される、実施形態１９乃至３３のうちのいずれか１つに記載の方法。

３５．完全性が証明された状態へスタートすることにより、登録されたコンポーネントが活性化される、実施形態１９乃至３４のうちのいずれか１つに記載の方法。

３６．第２の完全性チェックを行うことをさらに含む、実施形態１９乃至３５のうちのいずれか１つに記載の方法。

３７．装置がネットワーク接続を成功裏に完了したという条件で第２の完全性チェックを行うことをさらに含む、実施形態１９乃至３６のうちのいずれか１つに記載の方法。

３８．第２の完全性チェックは、装置のうちの１つによって、あるいはメッセージに応じて開始される、実施形態１９乃至３７のうちのいずれか１つに記載の方法。

３９．完全性チェックの結果を格納することは、保護された記憶位置にある、実施形態１９乃至３８のうちのいずれか１つに記載の方法。

４０．検証メッセージは暗号で署名されたステートメントを含む、実施形態１９乃至３９のうちのいずれか１つに記載の方法。

４１．検証メッセージは、完全性チェックと後続の認証手続きの間にバインディングの証拠を含む、実施形態１９乃至４０のうちのいずれか１つに記載の方法。

４２．検証メッセージは、セキュアスタートアップのチェックと後続の認証手続きの間にバインディングの証拠を含む、実施形態１９乃至４１のうちのいずれか１つに記載の方法。

４３．検証メッセージがタイムスタンプを含む、実施形態１９乃至４２のうちのいずれか１つに記載の方法。

４４．検証メッセージは、完全性チェックおよびスタートアップチェックの前に得られる第１のタイムスタンプ、および完全性チェックおよびスタートアップチェックの後に得られる第２のタイムスタンプを含む、実施形態１９乃至４３のうちのいずれか１つに記載の方法。

４５．検証メッセージは、装置構成のインジケーションを含む、実施形態１９乃至４４のうちのいずれか１つに記載の方法。

４６．検証メッセージは、装置コンポーネントのセキュリティ特性のインジケーションを含む、実施形態１９乃至４５のうちのいずれか１つに記載の方法。

４７．検証メッセージに応じてＰＶＭから判定メッセージを受け取ることをさらに含む、実施形態１９乃至４６のうちのいずれか１つに記載の方法。

４８．判定メッセージが装置と関連付けられるネットワーク権限のインジケーションを含む、実施形態１９乃至４７のうちのいずれか１つに記載の方法。

４９．完全性チェックを行う信頼されたリソース（ＴＲ）をさらに含む、実施形態１９乃至４８のうちのいずれか１つに記載の方法。

５０．セキュアスタートアップチェックを行う信頼されたリソース（ＴＲ）をさらに含む、実施形態１９乃至４９のうちのいずれか１つに記載の方法。

５１．検証メッセージを形成する信頼されたリソース（ＴＲ）をさらに含む、実施形態１９乃至５０のうちのいずれか１つに記載の方法。

５２．ＰＶＭから判定メッセージを受け取る信頼されたリソース（ＴＲ）をさらに含む、実施形態１９乃至５１のうちのいずれか１つに記載の方法。

５３．ＦＢＣは、正常なコードの一部を削除またはアンインストールし、再検証のために装置をリブートする、実施形態１９乃至５２のうちのいずれか１つに記載の方法。

５４．プラットフォームの検証および管理（ＰＶＭ）を促進するプラットフォーム検証エンティティ（ＰＶＥ）であって、装置からの検証メッセージに応じてＰＶＭトークンを受け取るように構成されたＰＶＥであって、ＰＶＭトークンは少なくとも装置からの確認情報を含む、ＰＶＥを備えたＰＶＥ。

５５．ＰＶＭトークンからの所定の情報を使用して検証を行うように構成されたＰＶＥをさらに含む、実施形態５４の方法。

５６．失敗したコンポーネントに応じて修正および再検証を開始するために装置管理システム（ＤＭＳ）に異常報告を送るように構成されたＰＶＥをさらに含む、実施形態５４乃至５５のうちのいずれか１つに記載の方法。

５７．検証結果を備えた変更済のＰＶＭトークンを送るように構成されたＰＶＥをさらに含む、実施形態５４乃至５６のうちのいずれか１つに記載の方法。

５８．確認情報は、少なくともセキュリティ・ポリシー属性を含む、実施形態５４乃至５７のうちのいずれか１つに記載の方法。

５９．プラットフォームの検証および管理（ＰＶＭ）を介して検証を行う装置であって、装置の少なくとも１つの予め指定されたコンポーネントの完全性チェックを行うように構成され、完全性チェックの結果をメモリに格納するように構成されたプロセッサを備えた装置。

６０．装置でセキュアスタートアップチェックを行い、セキュアスタートアップチェックの結果をメモリに格納するように構成されたプロセッサをさらに含む、実施形態５９の方法。

６１．完全性チェックの結果およびセキュアスタートアップチェックの結果に基づいて検証メッセージを形成するように構成されたプロセッサをさらに含む、実施形態５９乃至６０のうちのいずれか１つに記載の方法。

６２．検証メッセージをＰＶＭに送信するためのトランスミッタをさらに含む、実施形態５９乃至６１のうちのいずれか１つに記載の方法。

６３．プラットフォームの検証および管理（ＰＶＭ）を促進する装置管理システム（ＤＭＳ）であって、装置からの検証メッセージに応じて、プラットフォーム検証エンティティ（ＰＶＥ）から異常報告およびＰＶＭトークン（装置からの確認情報を少なくとも含む）の少なくとも１つを受信し、失敗したコンポーネントに応じて修正および再検証を開始するように構成されたＤＭＳを備えたＤＭＳ。

６４．少なくとも失敗したコンポーネントのアップデートの有効性（availability）を判定するように構成されたＤＭＳをさらに含む実施形態６３の方法。

６５．利用可能なアップデートのために無線でのアップデートを準備するように構成されたＤＭＳをさらに含む、実施形態６３乃至６４のうちのいずれか１つに記載の方法。

６６．確認データベース中の利用可能なアップデートについての信頼された基準値の存在を保証するように構成されたＤＭＳをさらに含む、実施形態６３から６５のうちのいずれか１つに記載の方法。

６７．変更済のＰＶＭトークンおよび再検証のインジケーションをセキュリティ・ゲートウエイ（ＳｅＧＷ）に送るように構成されたＤＭＳをさらに含む、実施形態６３乃至６６のうちのいずれか１つに記載の方法。

６８．再検証トリガーを装置に送るように構成されたＤＭＳをさらに含む、実施形態６３乃至６６のうちのいずれか１つに記載の方法。

６９．無線通信で使用される方法であって、プラットフォームの検証および管理（ＰＶＭ）を行うことを含む方法。

７０．ＰＶＭを行うことは、準自律的検証（ＳＡＶ）を行うことを含む、実施形態６９の方法。

７１．ＰＶＭを行うことは、プラットフォーム検証エンティティ（ＰＶＥ）の中でインプリメントされた無線装置の検証を含む、実施形態６９乃至７０のいずれか１つに記載の方法。

７２．ＰＶＭを行うことは、次のものを含む、実施形態６９乃至７１のいずれか１つに記載の方法。

７３．各ステージにおいてセキュアスタートアップを行うことと、ロードされるコンポーネントのローカルの検証が成功するという条件で、それぞれのトラステッド環境コンポーネントがロードされることを保証することと、をさらに含む、実施形態６９乃至７２のいずれか１つに記載の方法。

７４．第１のステージにて、信頼のルーツ（ＲｏＴ）に依存するセキュアスタートアップを介してトラステッド環境のコンポーネントをロードすることをさらに含む、実施形態６９乃至７３のいずれか１つに記載の方法。

７５．第２のステージにて、セキュリティゲートウェイ（ＳｅＧＷ）との基礎的な通信を行うように要求されるトラステッド環境の外側でコンポーネントをロードすることをさらに含む、実施形態６９乃至７４のいずれか１つに記載の方法。

７６．装置の残りのコンポーネントをロードすることをさらに含む、実施形態６９乃至７５のいずれか１つに記載の方法。

７７．データを収集し、ＳｅＧＷにそれを伝えることであって、そのデータは、装置のアイデンティ、Ｈ（ｅ）ＮＢに関係する情報、トラステッド環境（ＴｒＥ）に関係する情報、確認データ、ベリフィケーションバインディング、コンポーネントへのコンポーネントインジケーションの順序づけられたコンポーネント・リストの少なくとも１つを含む、ことをさらに備える、実施形態６９乃至７６のいずれか１つに記載の方法。

７８．認証されたＨ（ｅ）ＮＢに接続されないようになることに応じて装置を再検証することをさらに含む、実施形態６９乃至７７のいずれか１つに記載の方法。

７９．ＰＶＥによって行われる検証中に不良状態を判定することであって、当該不良状態は、伝えられたＴｒＥ情報に基づいてＴｒＥを信頼できないと判定すること、完全性測定／確認データのミスマッチを判定すること、コンポーネントについての見当たらない参照完全性メトリクス（ＲＩＭ）を判定すること、ロードしたコンポーネントのリスト（Ｃｌｉｓｔ）のポリシー失敗を判定すること、失効した装置またはＲＩＭ証明書を判定すること、およびＳｅＧＷがネットワークアクセスおよび装置認証を拒絶し、将来の認証の試みをブロッキングすること、の少なくとも１つを含む、ことをさらに含む、実施形態６９乃至７８のうちのいずれか１つに記載の方法。

８０．有効なＴｒＥの同一性および検証プロセスに結び付けられるＰＶＭトークンを生成することをさらに含む、実施形態６９乃至７９のうちのいずれか１つに記載の方法。

８１．検証フレッシュネスは、ＳｅＧＷによって最初に生成されたトークンをタイムスタンプで基礎付け、エンティティがトークンを渡す度に時系列のリストに追加することにより、制御される、実施形態６９乃至８０のうちのいずれか１つに記載の方法。

８２．検証フレッシュネスは、第１および第２のステージを完了し、ＳｅＧＷおよびＰＶＥとの通信を開始し、またＳｅＧＷにステージ３検証データの結果を通信する前に、ＳｅＧＷ／ＰＶＥによって供給されるノンスを使用してステージ３チェックの更なる検証をバインディングすることによって、制御される、実施形態６９乃至８１のうちのいずれか１つに記載の方法。

８３．オペレータによってＲＩＭ証明書を生成することをさらに含み、装置がＲＩＭ証明書でバックホールリンクを確立することを望む、実施形態６９乃至８２のうちのいずれか１つに記載の方法。

８４．ＲＩＭマネージャは、プラットフォーム検証のためにＰＶＥおよびＤＭＳを構成し、ＤＭＳは、ＲＩＭ証明書がインストールされるコンポーネント上で証明書アップデート処理を行うように構成され、前記方法は、装置のステートフルな再検証を強要するＤＭＳをさらに含む、実施形態６９乃至８３のうちのいずれか１つに記載の方法。

８５．対称鍵でロックされるコンポーネントの一部を暗号化すること、保護され制御されたスペースのＴｒＥであって、オペレータからの許可でアクセスされうるＴｒＥに復号キーを転送すること、ＰＶＥがそのようなコンポーネントのインジケータを提示される場合に、許可データをＴｒＥにリリースすること、のうちの少なくとも１つを行うことにより、オペレータが装置のオペレーションを制御することを更に含む、実施形態６９乃至８４のうちのいずれか１つに記載の方法。

８６．ＲＩＭ証明書中の装置アイデンティティを使用することによりＰＶＭに基づいて個別化を確立することをさらに含む、実施形態６９乃至８５のうちのいずれか１つに記載の方法。

８７．オペレータ署名を装置アイデンティティおよびコンポーネントインジケータのペアに適用することに基づいて個別化を確立することをさらに含む、実施形態６９乃至８６のうちのいずれか１つに記載の方法。

８８．装置についてのブラックリストを確立し、ブラックリストに基づいてネットワークアクセスを許可しないことであって、ブラックリストは少なくとも装置アイデンティティを含む、ことをさらに含む、実施形態６９乃至８７のうちのいずれか１つに記載の方法。

８９．装置用の隔離ネットワークを確立することであって、ＳｅＧＷがコア・ネットワークの施行障壁として働く、ことをさらに含む、実施形態６９乃至８８のうちのいずれか１つに記載の方法。

９０．隔離された装置のグレーリストを確立することであって、当該リストは、ネットワークにとって新しい装置、長期間の間接続されていない装置、疑わしい振る舞いを備えた装置、セキュリティ警告が存在する装置を少なくとも１つを含む、ことをさらに含む、実施形態６９乃至８９のうちのいずれか１つに記載の方法。

９１．未知のコンポーネントのローディング、未知のコンポーネントのローディング拒絶、およびコンポーネントを不能にすることの少なくとも１つを含む診断の検証を行うことをさらに含む、実施形態６９乃至９０のうちのいずれか１つに記載の方法。

９２．ローカルの確認プロセスの中で使用されるインジケータまたは基準値を送ることを含む最小限の検証を行うことをさらに含む、実施形態６９乃至９１のうちのいずれか１つに記載の方法。

９３．認証証明書中の検証のバインディングをさらに含む、実施形態６９乃至９２のうちのいずれか１つに記載の方法。

９４．証明書は、イシュア、そのＳｅＧＷ、またはこれらの証明書を管理することに関与する従属エンティティによって署名される署名データセットであり、証明書中の署名データは、装置アイデンティティ、認証および検証に使用される装置公開鍵、およびコンポーネントのリストを少なくとも含む、実施形態６９乃至９３のうちのいずれか１つに記載の方法。

９５．どんな検証データもＳｅＧＷに配信しない自律的検証を行うこと、セキュアスタートアッププロセスのステージによって管理アイデンティティをグループ化することをさらに含む、実施形態６９乃至９４のうちのいずれか１つに記載の方法。

９６．装置とＳｅＧＷが、管理アイデンティティの１つに認証した装置で第１の認証プロトコルを完了したという条件で、確立された安全なチャネルを介して装置アイデンティティおよび認証データを転送することをさらに含む、実施形態６９乃至９５のうちのいずれか１つに記載の方法。

９７．コンポーネントのコードのメモリーカードへのトランスファーを安全にすることをさらに含む、実施形態６９乃至９６のうちのいずれか１つに記載の方法。

９８．ダイジェスト値を暗号化に置き替えることをさらに含む、実施形態６９乃至９７のうちのいずれか１つに記載の方法。

９９．装置位置情報を検証メッセージに含めることをさらに含む、実施形態６９乃至９８のうちのいずれか１つに記載の方法。

１００．装置が装置識別子（Ｄｅｖ＿ＩＤ）によって識別される、実施形態６９乃至９９のうちのいずれか１つに記載の方法。

１０１．Ｄｅｖ＿ＩＤは、ＦＱＤＮ（Fully Qualified Domain Name）、ＵＲＬ（Uniform Resource Locator）、ＵＲＮ（Uniform Resource Name）、ＵＲＩ（Uniform Resource Identifier）、ＭＡＣ（medium access control）アドレス、ＩＰアドレス、ＩＰホスト識別子、サブネット・アドレス、ＩＭＥＩ（International mobile Equipment Identity）、ＩＭＥＩＳＶ（IMEI Software Version）、ＥＳＮ（electronic serial number）、ＭＥＩＤ（mobile Equipment Identifier）、ＩＰマルチメディア・コア・ネットワーク・サブシステム加入者ＩＤ、または移動局統合サービス・データ網ＩＤである、実施形態６９乃至１００のうちのいずれか１つに記載の方法。

１０２．Ｄｅｖ＿ＩＤは、装置の一義的に信頼でき、かつ明示的な識別を可能にさせる英数字または機械可読フォーマットである、実施形態６９乃至１０１のうちのいずれか１つに記載の方法。

１０３．１つまたは複数の信頼された基準値およびＴｒＥに基づいてスタートアップ時に装置完全性チェックを行うことをさらに含む、実施形態６９乃至１０２のいずれか１つに記載の方法。

１０４．ＴｒＥは、ＰＶＭに必要な最小限の機能を含むエンティティである、実施形態６９乃至１０３のうちのいずれか１つに記載の方法。

１０５．ＳｅＧＷでネットワーク認証を行うことと、装置アイデンティティを含むデータを送信することをさらに含む、実施形態６９乃至１０４のうちのいずれか１つに記載の方法。

１０６．第１および第２のステージ中に確立される完全性の測定として、ローカルのパス／失敗のインジケータを含む測定メッセージを準備することをさらに含む、実施形態６９乃至１０５のうちのいずれか１つに記載の方法。

１０７．ＰＶＭを行うことは基礎的なＳＡＶを含む、実施形態６９乃至１０６のうちのいずれか１つに記載の方法。

１０８．ＰＶＭを行うことは完全なＳＡＶを含む、実施形態６９乃至１０７のうちのいずれか１つに記載の方法。

１０９．ＰＶＭを行うことはプラットフォーム・バリデーションを含む、実施形態６９乃至１０８のうちのいずれか１つに記載の方法。

１１０．プラットフォーム・バリデーションはコア・ネットワーク（ＣＮ）が違法装置から保護されることを可能にする、実施形態６９乃至１０９のうちのいずれか１つに記載の方法。

１１１．ＰＶＭを行うことは装置とＣＮ間の間接通信を使用することを含む、実施形態６９乃至１１０のうちのいずれか１つに記載の方法。

１１２．プラットフォーム検証は、証明された安全な状態の装置がＣＮ内のエンティティに通信することができることを保証する、実施形態６９乃至１１１のうちのいずれか１つに記載の方法。

１１３．ＰＶＭを行うことはバリデーション・データの報告を含む、実施形態６９乃至１１２のうちのいずれか１つに記載の方法。

１１４．検証データの報告は、検証データを集めることと、ＳｅＧＷにそれを報告することを含む、実施形態６９乃至１１３のうちのいずれか１つに記載の方法。

１１５．ＰＶＭを行うことはＰＶＥを使用する検証を含む、実施形態６９乃至１１４のうちのいずれか１つに記載の方法。

１１６．ＰＶＥは装置の有効性を判定する、実施形態６９乃至１１５のうちのいずれか１つに記載の方法。

１１７．ＰＶＥはＰＤＰ（policy decision point）である、実施形態６９乃至１１６のうちのいずれか１つに記載の方法。

１１８．ＰＶＥは不良状態（failure condition）を報告する、実施形態６９乃至１１７のうちのいずれか１つに記載の方法。

１１９．不良状態は、ＴｒＥ無効、確認データ失敗、Ｃｌｉｓｔポリシー失敗またはプレ検証装置認証失敗である実施形態６９乃至１１８のうちのいずれか１つに記載の方法。

１２０．ＰＶＭを行うことは再検証を含む、実施形態６９乃至１１９のうちのいずれか１つに記載の方法。

１２１．再検証は周期的な再検証を含む、実施形態６９乃至１２０のうちのいずれか１つに記載の方法。

１２２．周期的な再検証は、装置が悪者コード実行のリスクを減らした定義された状態で機能することを有効にすることを含む、実施形態６９乃至１２１のうちのいずれか１つに記載の方法。

１２３．再検証は認証プロシージャを開始することを含む、実施形態６９乃至１２２のうちのいずれか１つに記載の方法。

１２４．ＰＶＭを行うことは装置が開始した再検証を含む、実施形態６９乃至１２３のうちのいずれか１つに記載の方法。

１２５．装置が開始した再検証は周期的に行われる、実施形態６９乃至１２４のうちのいずれか１つに記載の方法。

１２６．ＰＶＭを行うことはネットワークが開始した再検証を含む、実施形態６９乃至１２５のうちのいずれか１つに記載の方法。

１２７．ネットワークが開始した再検証は周期的に行われる、実施形態６９乃至１２６のうちのいずれか１つに記載の方法。

１２８．ネットワークが開始した再検証はセキュリティに必要なように行われる、実施形態６９乃至１２７のうちのいずれか１つに記載の方法。

１２９．ＰＶＭを行うことはプラットフォーム管理を含む、実施形態６９乃至１２８うちのいずれか１つに記載の方法。

１３０．プラットフォーム管理は装置管理を行うＤＭＳを含む、実施形態６９乃至１２９のうちのいずれか１つに記載の方法。

１３１．プラットフォーム管理は受信され格納された装置情報に基づく、実施形態６９乃至１３０のうちのいずれか１つに記載の方法。

１３２．装置はＨ（ｅ）ＮＢである、実施形態６９乃至１３１のうちのいずれか１つに記載の方法。

１３３．ＰＶＭを行うことはトークン・パッシングを含む、実施形態６９乃至１３２のうちのいずれか１つに記載の方法。

１３４．ＰＶＭは非同期処理である、実施形態６９乃至１３３のうちのいずれか１つに記載の方法。

１３５．ＳｅＧＷが、検証プロセスに一義的に関連したトークンの生成および管理に関与する、実施形態６９乃至１３４のうちのいずれか１つに記載の方法。

１３６．ＰＶＭを行うことは公衆インターネットを介した検証を含む、実施形態６９乃至１３５のうちのいずれか１つに記載の方法。

１３７．公衆インターネットを介した検証は、最初の検証を安全にするための特別の要件を満足することを含む、実施形態６９乃至１３６のうちのいずれか１つに記載の方法。

１３８．ＰＶＭを行うことは、オペレータＲＩＭ保護を含む、実施形態６９乃至１３７のうちのいずれか１つに記載の方法。

１３９．オペレータＲＩＭ保護は、様々な外部ソースから来る装置コンポーネントのための多数のＲＩＭ証明書を、装置がバックホールリンクを確立することを望むオペレータによって生成されるＲＩＭ証明書で置き換える、実施形態６９乃至１３８のうちのいずれか１つに記載の方法。

１４０．ＰＶＭを行うことはオペレータ・コンポーネントのロックインを含む、実施形態６９乃至１３９のうちのいずれか１つに記載の方法。

１４１．オペレータ・コンポーネントのロックインは、装置または外部ネットワークにおけるそのコンポーネントのオペレーションを制御するオペレータを含む、実施形態６９乃至１４０のうちのいずれか１つに記載の方法。

１４２．ＰＶＭを行うことは個別化を含む、実施形態６９乃至１４１のうちのいずれか１つに記載の方法。

１４３．個別化は、誰が装置の構成および信頼性を管理したかを証明することを含む、実施形態６９乃至１４２のうちのいずれか１つに記載の方法。

１４４．個別化が装置へのアドレッシングが署名されたデータを装置に提供することを含む、実施形態６９乃至１４３のうちのいずれか１つに記載の方法。

１４５．ＰＶＭを行うことは装置をブラックリストに載せることを含む、実施形態６９乃至１４４のうちのいずれか１つに記載の方法。

１４６．装置をブラックリストに載せることは、装置のブラックリストを確立することと、ブラックリストに基づいてネットワークアクセスを拒絶することを含む、実施形態６９乃至１４５のうちのいずれか１つに記載の方法。

１４７．ブラックリストは装置の特定のブラックリストである、実施形態６９乃至１４６のうちのいずれか１つに記載の方法。

１４８．ブラックリストがネットワーク全体に広がるブラックリストである、実施形態６９乃至１４７のうちのいずれか１つに記載の方法。

１４９．ＰＶＭを行うことは装置をホワイトリストに載せることを含む、実施形態６９乃至１４８のうちのいずれか１つに記載の方法。

１５０．装置をホワイトリストに載せることは装置のホワイトリストを確立することと、ホワイトリストに基づいてネットワークアクセスを許可することを含む、実施形態６９乃至１４９のうちのいずれか１つに記載の方法。

１５１．ホワイトリストが装置の特定のホワイトリストである、実施形態６９乃至１５０のうちのいずれか１つに記載の方法。

１５２．ホワイトリストがネットワーク全体に広がるホワイトリストである、実施形態６９乃至１５１のうちのいずれか１つに記載の方法。

１５３．ＰＶＭを行うことは隔離ネットワークを含む、実施形態６９乃至１５２のうちのいずれか１つに記載の方法。

１５４．どの装置が隔離に入れられるかをＳｅＧＷが判定する、実施形態６９乃至１５３のうちのいずれか１つに記載の方法。

１５５．隔離の装置は、ＣＮに対してダイレクトアクセスせず、制限のあるサービスを提供する、実施形態６９乃至１５４のうちのいずれか１つに記載の方法。

１５６．ＰＶＭを行うことはパラメータのバリデーションを含む、実施形態６９乃至１５５のうちのいずれか１つに記載の方法。

１５７．パラメータの検証は、検証中にプレーンテキストでパラメータを送ることを含む、実施形態６９乃至１５６のうちのいずれか１つに記載の方法。

１５８．ＰＶＭを行うことは診断の検証を含む、実施形態６９乃至１５７のうちのいずれか１つに記載の方法。

１５９．ＰＶＭを行うことは未知のコンポーネントのローディングを含む、実施形態６９乃至１５８のうちのいずれか１つに記載の方法。

１６０．未知のコンポーネントのローディングは、装置のＲＩＭを持たずにコンポーネントがロードされることを可能にする、実施形態６９乃至１５９のうちのいずれか１つに記載の方法。

１６１．ＰＶＭを行うことは不良状態のＰＶＭ診断を含む、実施形態６９乃至１６０のうちのいずれか１つに記載の方法。

１６２．ＤＭＳは装置上の失敗したコンポーネントを置き換えることを省略するように構成される、実施形態６９乃至１６１のうちのいずれか１つに記載の方法。

１６３．ＤＭＳはＣｌｉｓｔの全てのコンポーネントを正しいものに置き替えるように構成される、実施形態６９乃至１６２のうちのいずれか１つに記載の方法。

１６４．ＰＶＭを行うことは未知のコンポーネントのローディングを拒絶することを含む、実施形態６９乃至１６３のうちのいずれか１つに記載の方法。

１６５．診断の検証は、コンポーネントがロードされることができなかったことを報告することと、コンポーネントの測定値をＣＮに送ることとを含む、実施形態６９乃至１６４のうちのいずれか１つに記載の方法。

１６６．ＰＶＭを行うことはコンポーネントをディセーブルにすることを含む、実施形態６９乃至１６５のうちのいずれか１つに記載の方法。

１６７．コンポーネントをディセーブルにすることは、ディセーブルＣＩｎｄを送ることと、有効にされることができず、装置への接続を拒絶することなくＰＶＭの中で置き換え、または更新されることができないコンポーネントのメッセージを再検証することとを含む、実施形態６９乃至１６６のうちのいずれか１つに記載の方法。

１６８．ＰＶＭを行うことは最小限のバリデーション・ポリシーを含む、実施形態６９乃至１６７のうちのいずれか１つに記載の方法。

１６９．最小限の確認ポリシーはある状況の下でのみ装置検証を行うことを含む、実施形態６９乃至１６８のうちのいずれか１つに記載の方法。

１７０．ＰＶＭを行うことは、バリデーションを認証証明書にバインディングすることを含む、実施形態６９乃至１６９のうちのいずれか１つに記載の方法。

１７１．バリデーションを認証証明書にバインディングすることは、装置の本物のＩＤを検証に自動的にバインディングことを含む、実施形態６９乃至１７０のうちのいずれか１つに記載の方法。

１７２．ＰＶＭを行うことは装置認証証明書の取り消しを含む、実施形態６９乃至１７１のうちのいずれか１つに記載の方法。

１７３．装置認証証明書の取り消しは、装置認証のために装置から送られた装置証明書を無効にするべきかどうかを判定することを含む、実施形態６９乃至１７２のうちのいずれか１つに記載の方法。

１７４．装置認証証明書の取り消しは、装置認証が証明書の取り消しにより失敗したことを装置に示すことと、ホワイトリストから装置を削除すること、またはブラックリストに装置を加えることとを含む、実施形態６９乃至１７３のうちのいずれか１つに記載の方法。

１７５．自律的検証（ＡｕＶ）を行うＰＶＭをさらに含む、実施形態６９乃至１７４のうちのいずれか１つに記載の方法。

１７６．ＡｕＶはＳｅＧＷへの検証データの配信を省略することを含む、実施形態６９乃至１７５のうちのいずれか１つに記載の方法。

１８０．修正は装置の継続サービスのための必要なオペレーションである、実施形態６９乃至１７９のうちのいずれか１つに記載の方法。

１８１．ＰＶＭを行うことは装置によって開始される修正を含む、実施形態６９乃至１８０のうちのいずれか１つに記載の方法。

１８２．装置によって開始される修正は、エラーの検知時に装置を隔離する代わりに行われる、実施形態６９乃至１８１のうちのいずれか１つに記載の方法。

１８３．ＰＶＭを行うことはネットワークによって開始される修正を含む、実施形態６９乃至１８２のうちのいずれか１つに記載の方法。

１８４．ＰＶＭを行うことはフォールバックコード・ベースを開始することを含む、実施形態６９乃至１８３のうちのいずれか１つに記載の方法。

１８５．フォールバックコード・ベースを開始することはＲＩＭを含む主なコード・ベースのソフトウェア・アップデートをトリガーすることを含む、実施形態６９乃至１８４のうちのいずれか１つに記載の方法。

１８６．ＰＶＭを行うことはディストレス信号を送ることを含む、実施形態６９乃至１８５のうちのいずれか１つに記載の方法。

１８７．フォールバックコード（ＦＢＣ）イメージは、装置の修正を促進し、安全なメモリに格納される、実施形態６９乃至１８６のうちのいずれか１つに記載の方法。

１８８．ＰＶＭを行うことはＲＩＭなしの検証を含む、実施形態６９乃至１８７のうちのいずれか１つに記載の方法。

１８９．ＰＶＭを行うことはロケーションベースの情報を含む、実施形態６９乃至１８８のうちのいずれか１つに記載の方法。

１９０．位置情報は、盗難防止、カーゴトラッキング、フリートモニタリングまたは監視に使用される、実施形態６９乃至１８９のうちのいずれか１つに記載の方法。

１９１．装置がＧＰＳモジュールを含む、実施形態６９乃至１９０のうちのいずれか１つに記載の方法。

１９２．セキュアスタートアップは、ＧＰＳモジュールおよびコンポーネントを有効にすることを含む、実施形態６９乃至１９１のうちのいずれか１つに記載の方法。

１９３．ＰＶＭを行うことはＩＫＥｖ２プロトコルを使用するバリデーション接続を含む、実施形態６９乃至１９２のうちのいずれか１つに記載の方法。

１９４．ＰＶＭを行うことはトランスポートプロトコルを使用することを含む、実施形態６９乃至１９３のうちのいずれか１つに記載の方法。

１９５．トランスポートプロトコルはＩＫＥまたはＩＳＡＫＭＰである、実施形態６９乃至１９４のうちのいずれか１つに記載の方法。

１９６．トランスポートプロトコルは使用可能な多くの証明書プロフィールを定義する、実施形態６９乃至１９５のうちのいずれか１つに記載の方法。

１９７．ＰＶＭを行うことはトランスポート・レイヤー・セキュリティ（ＴＬＳ）ハンドシェイクを含む、実施形態６９乃至１９６のうちのいずれか１つに記載の方法。

１９８．ＰＶＭを行うことはＴＬＳセッション・チケット拡張を使用することを含む、実施形態６９乃至１９７のうちのいずれか１つに記載の方法。

１９９．ＴＬＳセッション・チケット拡張は、サーバがクライアントにセッション・チケットを発行することを可能にし、セッション・チケットは、セッションを再開し、およびクライアントごとのセッション状態を維持するために使用される、実施形態６９乃至１９８のうちのいずれか１つに記載の方法。

２００．ＰＶＭを行うことは補足の認証プロトコルを含む、実施形態６９乃至１９９のうちのいずれか１つに記載の方法。

２０１．補足の認証プロトコルは、確立される安全なチャネルを介してＤｅｖ＿ＩＤおよびＤｅｖ＿ＩＤの認証データを転送することを含む、実施形態６９乃至２００のうちのいずれか１つに記載の方法。

２０２．ＰＶＭを行うことは管理セッション確立を含む、実施形態６９乃至２０１のうちのいずれか１つに記載の方法。

２０３．管理セッション確立は装置とＳｅＧＷの間で通信プロトコルを使用することを含む、実施形態６９乃至２０２のうちのいずれか１つに記載の方法。

２０４．ＰＶＭを行うことは証明書ベースの検証を含む、実施形態６９乃至２０３のうちのいずれか１つに記載の方法。

２０５．ＰＶＭを行うことは、装置管理（ＤＭ）ベースのアーキテクチャについてのオープンモバイルアライアンス（ＯＭＡ）を使用することを含む、実施形態６９乃至２０４のうちのいずれか１つに記載の方法。

２０６．ＰＶＭを行うことは証明書交換方法を使用することを含む、実施形態６９乃至２０５のうちのいずれか１つに記載の方法。

２０７．証明書交換方法は、検証と認証を組み合わせることと、装置の認証ＩＤを検証に自動的にバインディングすることを含む、実施形態６９乃至２０６のうちのいずれか１つに記載の方法。

２０８．バインディング証明書は署名されたデータセットである、実施形態６９乃至２０７のうちのいずれか１つに記載の方法。

２０９．バインディング証明書はイシュアによって署名される、実施形態６９乃至２０８のうちのいずれか１つに記載の方法。

２１０．ＰＶＭを行うことはプレ証明書交換を含む、実施形態６９乃至２０９のうちのいずれか１つに記載の方法。

２１１．ＰＶＭを行うことはポスト証明書交換を含む、実施形態６９乃至２１０のうちのいずれか１つに記載の方法。

２１２．ＰＶＭを行うことは、イシュアから装置へのソフトウェア・パッケージのダウンロードのために署名されたメッセージ・フォーマットを使用することを含む、実施形態６９乃至２１１のうちのいずれか１つに記載の方法。

２１３．署名されたメッセージ・フォーマットは、ファイルが単一の署名されたパッケージの中で送られることを可能にする、実施形態６９乃至２１２のうちのいずれか１つに記載の方法。

２１４．署名されたメッセージ・フォーマットは、受信装置がソースを認証することを可能にし、コンテンツをインストールする命令を含む、実施形態６９乃至２１３のうちのいずれか１つに記載の方法。

２１５．署名されたメッセージ・フォーマットは、フォーマット・バージョンおよびコマンドリストの長さを含むヘッダーおよびペイロード・コンポーネントを含む、実施形態６９乃至２１４のうちのいずれか１つに記載の方法。

２１６．ＰＶＭを行うことは修正用の第２のコード・ベースを使用することを含む、実施形態６９乃至２１５のうちのいずれか１つに記載の方法。

２１７．ＰＶＭを行うことは外部ＦＢＣを使用することを含む、実施形態６９乃至２１６のうちのいずれか１つに記載の方法。

２１８．外部ＦＢＣは、修正を始めるために使用され、ＴｒＥ内部で実行される、実施形態６９乃至２１７のうちのいずれか１つに記載の方法。

２１９．ＰＶＭを行うことは内部並列のコード・ベースの使用を含む、実施形態６９乃至２１８のうちのいずれか１つに記載の方法。

２２０．ＰＶＭを行うことは、トリガー機構、および円滑な修正に必要なフォールバックコード・ベースの使用を含む、実施形態６９乃至２１９のうちのいずれか１つに記載の方法。

２２１．ＰＶＭを行うことは内部連続するコード・ベースの使用を含む、実施形態６９乃至２２０のうちのいずれか１つに記載の方法。

２２２．内部連続するコード・ベースは、リモート装置上でソフトウェア構成をインストールまたは変更するためのプロトコルおよびコマンドを定義する、実施形態６９乃至２２１のうちのいずれか１つに記載の方法。

２２３．内部連続するコード・ベースの使用は、ＰＶＭ実行の結果およびプロトコルを組み合わせることを含む、実施形態６９乃至２２２のうちのいずれか１つに記載の方法。

２２４．ＰＶＭを行うことはセキュリティポリシー・アトリビュートを使用することを含む、実施形態６９乃至２２３のうちのいずれか１つに記載の方法。

２２５．セキュリティ・ポリシー属性の使用がセキュリティ・ポリシー・アトリビュート（ＳＰＡ）の標準化されたリストを生成することを含む、実施形態６９乃至２２４のうちのいずれか１つに記載の方法。

２２６．ＳＰＡは、特定のモジュールがその完全性チェックに失敗する場合にどんなアクションが取られるかをＰＶＥに伝えるポリシーである、実施形態６９乃至２２５のうちのいずれか１つに記載の方法。

ＰＶＭの特徴および要素は特定の組み合わせで説明したが、特徴あるいは要素はそれぞれ、他の特徴および要素なしで単独で、あるいは他の特徴および要素を備えた、あるいは備えない様々な組み合わせの中で使用することができる。本明細書で提供される方法やフローチャートは、コンピュータ・プログラム、ソフトウェア、あるいは汎用コンピュータやプロセッサによる実行用にコンピュータ可読記憶媒体に組み入れられたファームウェアの中で実現されることができる。コンピュータ可読記憶媒体の例には、ＲＯＭ、ＲＡＭ、レジスタ、キャッシュ・メモリ、半導体記憶装置、内蔵ハードディスクおよびリムーバブル・ディスクのような磁気メディア、光磁気メディア、およびＣＤ−ＲＯＭおよびＤＶＤのような光学メディアが含まれる。

適切なプロセッサは、一例として、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、ＡＳＩＣ、ＦＰＧＡ回路、他の種類の集積回路（ＩＣ）、および／または状態機械を含む。

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

Claims (3)

1. プラットフォーム検証エンティティ（ＰＶＥ）に結合される無線送信／受信装置（ＷＴＲＵ）の検証を実行する方法であって、
   前記ＷＴＲＵの少なくとも１つの事前指定されたコンポーネントを測定し、前記ＷＴＲＵの前記少なくとも１つの事前指定されたコンポーネントの完全性測定値を生じさせることと、
   前記ＷＴＲＵの前記少なくとも１つの事前指定されたコンポーネントについての信頼された参照値を検索することと、
   無線送信／受信装置（ＷＴＲＵ）にあるトラステッド環境（ＴｒＥ）を使用して、前記ＷＴＲＵの前記少なくとも１つの事前指定されたコンポーネントの完全性チェックを実行し、および完全性チェックの結果を格納することであって、前記完全性チェックは、前記ＴｒＥが、前記少なくとも１つの事前指定されたコンポーネントの前記測定された完全性測定値と前記ＷＴＲＵの前記少なくとも１つの事前指定されたコンポーネントについての前記信頼された参照値とを比較することを含む、ことと、
   前記ＴｒＥを使用して、前記ＷＴＲＵ上でセキュアスタートアップチェックを実行し、およびセキュアスタートアップチェックの結果を格納することと、
   前記ＴｒＥを使用して、前記完全性チェックの結果および前記セキュアスタートアップチェックの結果に基づいて検証メッセージを形成することと、
   前記ＴｒＥを使用して、前記検証メッセージを前記ＷＴＲＵから前記ＰＶＥに転送することであって、前記ＰＶＥは前記ＷＴＲＵの外にある、ことと、
   失敗時に、メインコードベースのソフトウェアアップデートをトリガするフォールバックコードベースのオペレーションを開始することと
   を備える方法。
2. 前記ＴｒＥを使用して、複数のステージにおけるセキュアスタートアップを実行し、第１のＴｒＥコンポーネントおよび第２のＴｒＥコンポーネントが、それぞれのＴｒＥコンポーネントのローカル検証が成功するという条件でロードされることを保証する、ことと、
   第１のステージにて、ＲｏＴ（Root of Trust）に依存するセキュアスタートアップを介して前記ＴｒＥコンポーネントをロードすることと、
   第２のステージにて、前記ＰＶＥとの通信を許可するために前記ＴｒＥの外側で第２のコンポーネントをロードすることと
   をさらに備える、請求項１の方法。
3. 前記検証メッセージは、前記第１および第２のステージの間に確立された完全性の測定値としてローカルの合／否のインジケータを含む、請求項２の方法。

Images