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

Abstract

プラットフォーム確認および管理(PVM)をインプリメントする方法、コンポーネントおよび装置が示す。PVMは、プラットフォーム確認実体の機能性およびオペレーションに装置管理コンポーネント、およびホーム・ノード-Bマネジメントシステムあるいはコンポーネントのようなシステムによる装置の遠隔の管理を供給する。
例PVMオペレーションは接続および中核ネットワークへのアクセスを許可する前に安全な目標状態へ装置を持って来る。

Description

本願は、それらの全体が参照によって本明細書に組み込まれる、２００９年３月６日に出願された米国特許仮出願第６１／１５８，２４２号、２００９年４月２８日に出願された米国特許仮出願第６１／１７３，４５７号、２００９年６月３０日に出願された米国特許仮出願第６１／２２２，０６７号、および２００９年８月２１日に出願された米国特許仮出願第６１／２３５，７９３号の利益を主張する。本出願は同時に出願された、発明の名称「Ｈ（ｅ）ＮＢの完全性の確認と立証のための方法と装置」の米国特許出願第１２／７１８，５７２に関係しており、その全体が参照によって本明細書に組み込まれる。

本出願は通信に関する。

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

プラットフォームの立証（検証、妥当性確認）と管理（ＰＶＭ：ｐｌａｔｆｏｒｍ ｖａｌｉｄａｔｉｏｎ ａｎｄ ｍａｎａｇｅｍｅｎｔ）を実施するための方法、コンポーネント、および装置を、開示す。ＰＶＭの実施は、ホームノードＢ（ｈｏｍｅ ｎｏｄｅ−Ｂ）管理システムのような装置管理システムにより、装置の遠隔管理を用いてプラットフォーム立証実体の機能とオペレーション（運用）を提供する。例えば、ＰＶＭは、コアーネットワークに対して接続やアクセスを許容する前において、装置を安全なターゲット状態に至らしめるオペレーションをする。

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

信頼された（信頼できる）サブシステムのドメイン（領域）分離の一例を示すブロック図である。 プラットフォーム間のトラスト（信頼）が組織的で技術的な方法により仲介されることの一例を示すブロック図である。 ホーム拡張ノードＢ（Ｈ（ｅ）ＮＢ）を用いた半独立的な立証の一例を示すフローチャートである。 ４ステージの安全な起動の方法の一例を示すフローダイアグラム（流れ図）である。 プラットフォームの立証と管理（ＰＶＭ）用の実体とそれらの関係とインターフェースの一組の一例を示すブロック図である。 ＰＶＭ用の実体とそれらの関係とインターフェースの組の一例を示す他のブロック図である。 プラットフォーム立証実体を用いて立証の一例を示す信号ダイアグラム（信号図）である。 プラットフォーム立証実体を用いて立証の一例を示す信号ダイアグラムである。 プラットフォーム立証実体を用いて立証の一例を示す信号ダイアグラムである。 Ｈ（ｅ）ＮＢの通信のシナリオ一例を示すブロック図である。 Ｈ（ｅ）ＮＢ内の「シン（ｔｈｉｎ；薄い、軽い）」信頼された環境（ＴｒＥ）の一例を示すブロック図である。 間接装置接続の方法と図解の一例を示す図である。 直接装置接続の方法と図解の一例を示す図である。 組み合わせ認証（ｓｅｐａｒａｔｅ ｃｅｒｔｉｆｉｃａｔｅｓ）の処理手続の一例を示すフローチャートである。 完全性の確認（検証、適合確認）の失敗に続いてフォールバック（ｆａｌｌｂａｃｋ）コードベース（ｃｏｄｅ ｂａｓｅ）により容易となる装置矯正の確認（検証）方法の一例を示す図である。 図１１Ａの方法に沿う一例のフローチャートである。 基準完全性メトリクス遮蔽ヘッダーのフォーマットの一例を示す図である。 仮想プラットフォームの設定登録値を用いた立証の一例を示すフローダイアグラムである。 全ての反独立的な立証（検証、妥当性確認）の間にコンポーネントをローディングする時のモジュールのヒエラルキー（上下関係）の一例を示す階層図である。 それぞれＰＶＭを提供し、実行し、実施するように構成された無線送信／受信装置と基地局の一例を示す機能ブロック図である。

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

プラットフォームの立証と管理（ＰＶＭ）の方法と装置を開示す。ＰＶＭはホームノードＢ管理システム（ＨＭＳ）のような装置管理システムによる装置の遠隔管理を伴なうプラットフォーム立証実体（ＰＶＥ）の機能性とオペレーション（操作、働き）を提供する。ＰＶＭはコアーネットワーク（ＣＮ）への接続性とアクセスが許容される前に、装置を安全なターゲット状態（ｓｅｃｕｒｅ ｔａｒｇｅｔ ｓｔａｔｅ）にオペレーションする。

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

本明細書の記述は、着手からのアーキテクチャが、信頼された・コンピューティング・グループ（ＴＣＧ：Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ； 国際業界標準規格制定のための米国の業界団体）により制定された技術標準（規格）、但しこれに限定はされないが、に関連する信頼されたコンピューティング技術（Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ ｔｅｃｈｎｏｌｏｇｙ）の最も中心的な考え方（最中心概念）を利用することが可能であると見なしているという意味で、全てをカバーしている。例えば、本明細書に記載された一実施形態は、ＰＶＭの全てのオペレーションと方法ついて基礎を築くための、信頼された環境（ＴｒＥ）と基準完全メトリックス（ＲＩＭ）によって実行される安全立ち上げに依存している。このことは、より少ない信頼された技術に基づく更なる変形の具現化を決して排除しない。他の実施形態はＰＶＭの色々なステージにおいてＲＩＭｓを用いるのを避けることができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

立証技術に関する技術の現状は、リモート立証であり、とりわけＴＣＧリモート証明のリモート立証である。リモート証明において、ＴＣＧの信頼されたプラットフォームは、認識識別キー（ＡＩＫ）により署名された、ＳＭＬとＰＣＲ、リモート証明の立証と確認のデータを、外部のバリデータに対して提示す。ＡＩＫは、立証のアイデンティティプロバイダーとして働くＰＣＡにより認証された短命な一対の非対称暗号鍵である。リモート証明で提供されるスードニム（匿名）は全ての場合では満足するものではないであろう。ＴＣＧはゼロ知識証明（ｚｅｒｏ−ｋｎｏｗｌｅｄｇｅ ｐｒｏｏｆ）に基づいた直接匿名認証(ＤＡＡ：Ｄｉｒｅｃｔ Ａｎｏｎｙｍｏｕｓ Ａｔｔｅｓｔａｔｉｏｎ）を追加定義する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ＰＶＮは、装置が最初に通信ネットワークに参加して、その後の装置完全性の監視し、信頼されたコンピューティング（Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ）からのセキュリティ技術の一部分に頼るということを試みる場合において、装置を認証し管理するための組織的（体系的）方法を提供する。ＰＶＭは、１）ネットワーク接続前に装置を認証すること；２）装置設定オーバ・ジ・エアー（ＯｔＡ：ｏｖｅｒ−ｔｈｅ−ａｉｒ）を管理すること； ３）コンポーネントロード／スタートでＲＩＭのようなＴＲＶをチェックすることでの安全（セキュア）スタートアップすること；および４）設定変更−ＴＲＶ摂取のために装置上に新しいＴＲＶ（例えばＲＩＭ）をインストールすること、を提供する。

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

装置に関して、装置は沢山の種類の中に、多くの名前によって入ることができる。ＰＶＭは、拡張ＵＭＴＳ地上波無線アクセスネットワーク（Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ （ＵＭＴＳ） Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ （Ｅ−ＵＴＲＡＮ））のＨ（ｅ）ＮＢとマシーン間通信（ｍａｃｈｉｎｅ ｔｏ ｍａｃｈｉｎｅ （Ｍ２Ｍ））装置に適用可能であり、また特定の前提条件を満たす多くの他のネットワーク接続装置に適用可能である。このような前提条件は本質的に高信頼化システム（Ｔｒｕｓｔｅｄ Ｓｙｓｔｅｍ （ＴＳ））である。ＰＶＭが適用される場合には、さまざまな装置がＰＶＭ方法で実行するように構成され、それによりＰＶＭ装置となる。

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

装置アイデンティＤｅｖ＿ＩＤが装置内の高信頼環境（Ｔｒｕｓｔｅｄ Ｅｎｖｉｒｏｎｍｅｎｔ （ＴｒＥ））、汎用ＩＣカード（Ｕｎｉｖｅｒｓａｌ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ （ＵＩＣＣ））あるいはスマートカードと結びついたアイデンティティである場合、あるいはその装置、例えば、Ｈ（ｅ）ＮＢ，それ自身、に対して結びついたアイデンティである場合には、それはＰＶＭの目的のためには、役立たない。装置はＤｅｖ＿ＩＤと関連する認証信用証明物を秘密に管理し、したがってＤｅｖ＿ＩＤ対して認証をすることができると想定している。Ｄｅｖ＿ＩＤは、完全修飾ドメイン名（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ（ＦＱＤＮ））、 統一資源識別子（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ））、 統一資源位置指定子（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ（ＵＲＬ））、 統一資源名（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｎａｍｅ（ＵＲＮ））、媒体アクセス制御（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ（ＭＡＣ））アドレス（例えば、拡張一意識別子（ｅｘｔｅｎｄｅｄ ｕｎｉｑｕｅ ｉｄｅｎｔｉｆｉｅｒ（ＥＵＩ−４８））、ＩＰｖ４またはＩＰＶ６アドレス、サブネット（ｓｕｂｎｅｔ）アドレスを包含するＩＰｖ６ホスト識別番号（例えば、６４ＬＳＢ）、国際移動体装置識別番号（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｅｑｕｉｐｍｅｎｔ Ｉｄｅｎｔｉｔｙ（ＩＭＥＩ））、ＩＭＥＩＳＶ（ＩＭＥＩ Ｓｏｆｔｗａｒｅ Ｖｅｒｓｉｏｎ）（ｇｓｍ／ｕｍｔｓのような）、電子シリアル番号（ｅｌｅｃｔｒｏｎｉｃ ｓｅｒｉａｌ ｎｕｍｂｅｒ（ＥＳＮ））、移動体装置識別番号（Ｍｏｂｉｌｅ Ｅｑｕｉｐｍｅｎｔ Ｉｄｅｎｔｉｆｉｅｒ（ＭＥＩＤ））（ｃｄｍａのような）、国際移動加入者識別番号（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ（ＩＭＳＩ））、テンポラリ移動加入者識別番号（Ｔｅｍｐｏｒａｒｙ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ （ＴＭＳＩ））（加入者と装置が１対１のマッピングだから、装置が加入者によって識別できる場合のもの）、ＩＭＳ加入者ｉｄ（例えば、Ｐ多重媒体非公開識別番号（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｐｒｉｖａｔｅ Ｉｄｅｎｔｉｔｙ （ＩＭＰＩ）Ｉ）またはＩＭＳ利用者公開識別番号（ＩＭＳ Ｕｓｅｒ Ｐｕｂｌｉｃ Ｉｄｅｎｔｉｔｙ（ＩＭＰＵ））のような）、移動局サービス統合デジタル網（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ （ＭＳＩＳＤＮ））、あるいはグローバル（世界的規模）、あるいは少なくともドメイン固有のような、固有（一意的）であり、例えば、各オペレータに関して、単一の装置の信頼できて一義的な識別表示を許容する、アルファニューメリック（英数字、（ａｌｐｈａｎｕｍｅｒｉｃａｌ）あるいは機械可読の電子フォーマット（ｍａｃｈｉｎｅ−ｒｅａｄａｂｌｅ ｆｏｒｍａｔ）内の他の識別子であってよい。

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

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

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

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

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

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

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

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

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

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

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

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

ポリシに基づいた微細粒度（ｆｉｎｅｒ ｇｒａｎｕｌａｒｉｔｙ）がステージ３で可能である。例えば、コンポーネントは、それらコンポーネントが検証に不合格になり、あるいはＲＩＭが利用できない場合に、サンドボックス環境にロードされることができる。３ａと３ｂ間の区別は信頼された（信頼）サービス間の一つと、及び携帯電話作業グループ（ｍｏｂｉｌｅ ｐｈｏｎｅ ｗｏｒｋ ｇｒｏｕｐ （ＭＰＷＧ））基準アーチテクチャの安全起動での測定されたサービスに対して類似している。

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

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

別の実施形態では、コンプロミス（ｃｏｍｐｒｏｍｉｓｅ：セキュリティを脅かすもの）が安全起動期間で検知されたという条件で、PVMを実行することを装置に許可する代替コードベース（ｆａｌｌｂａｃｋ ｃｏｄｅ ｂａｓｅ （ＦＢＣ））を使用してもよい。その後、装置は、コンプロミス協の検知時に、FBCを用いて再起動（リブート）し、ついで所定の状態を開始して装置修正を許可する。

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

PVMは次の用語を使用することができる。用語「確認（ｖｅｒｉｆｉｃａｔｉｏｎ）」が外部実体によって装置をチェックする全体のプロセスに使用されている一方、用語「立証（ｖａｌｉｄａｔｉｏｎ）」は安全起動に装置コンポーネントの内部立証に適用することができ。したがって、内部対「外部の」「確認」の導入は回避される。立証が暗号のチェックの通常の感覚に適用されるか、データに一致している場合、混乱が発生しないように、これは明示的に指摘される。

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

防犯ゲート（Ｓｅｃｕｒｉｔｙ ＧａｔｅＷａｙ （ＳｅＧＷ））プラットフォーム立証実体（Ｐｌａｔｆｏｒｍ Ｖａｌｉｄａｔｉｏｎ Ｅｎｔｉｔｙ （ＰＶＥ）） 装置管理サービス （Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｉｃｅ （ＤＭＳ）） integrated part 統合部 assess 評価 integrity 完全性 終端間セキュリティ（ｅｎｄ−ｔｏ−ｅｎｄ ｓｅｃｕｒｉｔｙ）

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

ＰＶＥに関して、それはＣＮの中の確認実体として働き、完全確認を行う。報告された値が知られており、よい場合には、それは完全確認データおよびチェックを受け取る。それは、ＣＮの中の他の実体への装置保全に関する声明を発表する。

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

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

PVMは、さらに装置構成の管理およびプロビジョニングを行なうコンフィギュレーション・ポリシ・マネージャ(CPman)を含む。さらに、それは、目標装置構成およびポリシの(オペレータ仕様)信頼された第三者(TTP)および生成から例えば項目(外国の配置およびポリシの摂取)の中で、ポリシを管理する。すなわち、CPmanは一義的な実体である。それは、配置ポリシデータベースC_DBを管理することを認められる。それがPVMに必要な(SHO-CN)外部信頼関係を管理するので、CPmanはセキュリティに関して特別に重要である。

図５Ａと図５Ｂが実体の最小のセット、それらの関係およびＰＶＭのためのインターフェースの例を示すと考える。認証のような追加の実体、認可＆説明する（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ， Ａｕｔｈｏｒｉｚａｔｉｏｎ ＆ Ａｃｃｏｕｎｔｉｎｇ （ＡＡＡ））サーバおよび無線伝送／受信ユニット（ＷＴＲＵ）また、それらのインターフェースが示される。

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

確認中にＰＶＥ ５２４と連絡をとるために、Ｉ−ｐｖｅインターフェース５２２はＳｅＧＷ ５２０によって適用することができ。ＰＶＥ ５２４は、ＳｅＧＷ ５２０への確認の結果を示す、Ｉ−ｐｖｅインターフェース５２２を使用することができる。装置構成に恐らく使用されたＩ−ｄｍｓインターフェース５３０は、ＤＭＳ ５３５とＳｅＧＷ ５２０に通信を関連づける。ＤＭＳ ５３５と、および逆に通信するために、Ｉ−ｐｄインターフェース５３２はＰＶＥ ５２４によって適用することができ。このインターフェース、Ｉ−ｐｄ ５３２は、装置ソフトウェア・アップデートおよび配置変更のためにのように装置管理手続鍵の間に適用することができる。

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

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

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

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

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

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

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

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

最初の変化では、データは信頼された第三者(TTP)で保存される。また、装置は、PVEが所望の情報を取り戻すかもしれないTTPにポインタを送る。ポインタはIKEv2の中で送られることができ、ペイロードに通知する。

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

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

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

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

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

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

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

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

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

認証失敗の修復は、失敗のことをそれに通知するＳｅＧＷに付く装置用の十分な機能性を許可するステージ1あるいはステージ2完全性チェックに、初期不良の後に例えば蓄えモードの活性化であり得る。その後、これは、装置ソフトウェアが診断で更新されることを可能にする操作・保守(OAM)手続きを引き起こすことができた。フォールバックコード（ｆａｌｌｂａｃｋ ｃｏｄｅ）は、TrEの監督の下の安全なやり方でコード化する完全な再構築が可能な十分な機能性を持つ必要があるだろう。

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

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

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

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

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

このメッセージの受取に際して、ＳｅＧＷ ６０７は、立証の場合にチェックし、提示の場合に結合すること（６２８）ができる。これは、確認データの本物であることを保証する。その後、ＳｅＧＷ ６０７はＰＶＭトークン（Ｔ＿ＰＶＭ）（６３０）を作成し、新鮮を保証し、かつ非同期メッセージを防ぐためにそれを送る（６３２）前に、Ｔ−ＰＶＭの上のタイムスタンプを適用する。

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

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

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

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

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

図６Ａ、図６Ｂおよび図６Ｃの中の処理に関しての詳細は、ここに記述される。プラットフォーム確認を行なうために、ＴｒＥは次のデータを集めて、確認メッセージにそれらを含めて、ＳｅＧＷにそれを伝える： ＲｏＴを含むＤｅｖ＿ＩＤ、メーカー、ＴｒＥ能力および特性のような装置情報； ＩＤを含むＴｒＥ＿ｉｎｆｏｒｍａｔｉｏｎ、証明情報（メーカー）、バージョンおよび随意的にモデル（形）を構築する、シリアルＮｏ； プラットフォーム設定レジスタ（ＰＣＲ）価値、単にローカルの立証に失敗したコンポーネントのリストあるいはローカルの立証に失敗したコンポーネントによって影響を受けた機能性のリストを含んでいるかもしれない確認データ； ＰＣＲ価値あるいは失敗したコンポーネントあるいは影響を受けた機能性のリストに関する署名のように拘束する立証； コンポーネントＣｌｉｓｔに構成要素の指標（ＣＩｎｄ）のリストを命じており、コンポーネント；またタイムスタンプ（信頼された、あるいはない）用パラメータを含むことができる。

コンポーネントへの指標の順序付きリストおよびそれらのパラメータは、次のデータ・フィールドのようなエントリを含んでよい: インデックス、component_indicator CInd、component_parameters。CIndはコンポーネントに参照を与えて、URNフォーマット(例えばURN://vendor.path.to/コンポーネント/証明書)にあるであってよい。コンポーネントのリストは、RIM証明書、RIMcsを指すことにより、例えば確認用のRIMを識別する役目をするであろう。

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

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

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

確認メッセージが安全なチャンネルによって認証に例えば結び付けられる場合、立証結合はオプションである。

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

装置とTrE_infoはオプションであってよい。Dev_IDは装置とTrE_infoに参照を与えてよい。すべてのMNOがネットワークに接続する装置を知っているとは限らないのであるべてのTrEの従ってすべてのTrE_infoデータ、およびそのような写像が、所定のDev_IDのためにTrE_infoを得るためにMNOによって尋ねられるかもしれないデータベースによって提供されることができる。TrE_infoはTrE_certificateにあってよい。TrE_certificateはTrEまたはTTPのベンダーによって署名されるべきである。

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

SeGWと装置の間の相互認証はこの変化の先行条件（必須）である。例えば、装置がオペレータを変更すれば、問題が発生する場合とそうでない場合が生じる。例えば、それは、遠隔の管理手続中に偽造されたSeGW/MNOから偽造されたRIMを以前に受け取ることがありうる。

それがRIMあるいはRIM証明書が取って来られるかもしれない、コンポーネントのこの一義的な識別および位置を同時に考慮に入れるので、コンポーネントへの指標としてのURNの使用は有利である。

装置確認中に、装置はSeGWに確認メッセージをSeGWへ送る。このメッセージの受取に際して、SeGWは立証をチェックする。このステップは、確認データの本物であることを保証する。その後、SeGWはPVMトークン(T_PVM)を作成する。トークンT_PVMは回転するトークンとして使用されてもよく、通信中に実体から実体まで渡される。すべての実体は新鮮を保証し、かつ非同期メッセージ・フローを防ぐためにそれを送る前に、トークン（トークン、証拠）にタイムスタンプを付ける。トークンの上のタイムスタンプはトークンの状態に続く方法を提供するために適用することができ。トークンはいくつかの巡回でさえ、実体から実体までCNの中で移動でき、したがって、実体によって追跡されることができる。

随意的に、実体IDは時間に型押しされた一連のデータに組み入れられるべきである。

T_PVMはDev_IDを含むことができる。信頼されようが信頼されまいが、オリジナルのタイムスタンプが存在しない場合、T_PVMはさらにSeGWによって出された新しいタイムスタンプを含むことができる。そうでなければ、T_PVMは、確認メッセージからのオリジナルのタイムスタンプを含むことができる。

タイムスタンプはリプレーアタック（攻撃再開）に対して保護するために適用することができる。それらは目下あるいは単音で増加するカウンタと結合されるか、あるいは目下とさらに取り替えられてよい。タイムスタンプも確認データの新鮮を評価するために適用することができ。両方の目的の組み合わせは有利で、タイムスタンプによって提供されることができる。

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

第１の変形において、後のために、DMSによる装置管理、T_PVMは、DMSとTrE(例えばTLS証明書)の間の安全なトンネルの建造のために通信秘密を含むことができる。

SeGWは確認メッセージから次のデータを抽出する:確認データ、TrE_infoおよびClist。トークンT_PVMと一緒にこのデータを送る前に、SeGWはT_PVMにタイムスタンプを置き、PVEへそれを転送する。SeGWは、malを決まったデータ攻撃からの脅威を緩和する、確認メッセージおよびその部分のフォーマットをチェックすることができる。そうでなければ、PVEのこのデータの純粋な検査がシステム・エラーか失敗に結びつくように、攻撃者は、危険にさらされたTrEの確認メッセージ中のデータを修正（改ざん）しようとするであろう。

Dev_IDsと対応するH(e)NB、H(e)NB_IDの同一性の間に分離することは役に立つであろう。両方間の関連性は相関関係であるけれども、そのような分離は、任務(SeGWがTrEsを知っている、PVEがH(e)NBを知っている)の分離の見解から、および恐らくアドレシング/管理から意味をなすと思える。この場合、PVEが受信H(e)NB_IDを使用して、データベースHNB_DBからDev_IDを取って来る中間のステップがあり得る。

PVEは装置の有効性を決める実体である。すなわちポリシシステムの言語では、それはポリシ決定ポイント(PDP)である。任務アプローチの厳密な分離の下では、それはPVMシステムでのただ一つのPDPである。それは、SeGW、およびポリシ施行ポイント(PEP)として働くようなポリシを強化するDMSに依存する。PVMはポリシがどのように生成されるか、また、それらがどこで格納されるか/管理されるかという問題に不可知論者で、その概要に、PVEがポリシを得るところで残る。下記に述べられた(特別のパラメータの確認および最小の確認の中で)、もっと詳細な変形および従属する方法のうちのいくつかでは、保険約款とアクションのいくつかの例は挙げられる。一般に、確認ポリシに関する決定は、。パラメータ(範囲)を与えられた項目、および恐らく評価されたロード(Clistが命じられる)の順序で、単一のコンポーネントの有効性だけでなくClistに含まれていた他方のデータに基づくことができる。

PVEによって実行された確認プロセスで生じるかもしれないいくつかの基本のクラスの不良状態がある。例えば、不良状態Flは「TrE無効」シナリオを示す。その確証されたDev_IDおよび伝えられたTrE_infoによって、PVEは、装置および(または)そのTrEを信頼できない一つであると確認する。

別の例は、「確認データ失敗」の3つのシナリオを示す不良状態F2である。シナリオF2aは完全測定/確認データmiマッチを示す。それは、装置の安全起動プロセスの失敗および(または)誤りのことの存在を示しかつ/またはRIMおよび(または)装置上のRIM証明書を吐き出す。その後、それは無効のコンポーネントを起動する。シナリオF2bはRIMを示す、見当たらない、つまり、コンポーネント用のRIMは見当たらず、他のところに取って来られる必要がある。シナリオF2cは吐き出されたRIM証明書を示す。

[00169] Another example is failure condition F2 which indicates three scenarios for "Verification data failure". Scenario F2a indicates integrity measurement/verification data mis-match. It indicates failure of the secure start-up process of the device, and/or presence of false and/or expired RIMs and/or RIM certificates on the device, which then starts an invalid component. Scenario F2b indicates RIM Missing, i.e., a RIM for a component is missing and needs to be fetched from elsewhere. Scenario F2c indicates an expired RIM certificate.

不良状態F3は、「Clistポリシ失敗」の2つのシナリオを示す。シナリオF3aについては、単一のコンポーネントは有効である。しかし、配置はロード・オーダー、望まれないコンポーネント、あるいはパラメータで例えばポリシに失敗する。シナリオF3bは、配置がClistに十分見合う「既知の価値」が利用可能でないそのように未知であることを示す。

不良状態F4は「前立証・装置認証失敗」を示し、認証が、どの装置認証が確認に先行するかに確認にある意味では結び付けられる場合に、当てはまってもよい。F4条件は、吐

検知および記述された不良状態のための治療法がここに記述される。不良状態Flについては、PVEは受信TrE_Infoを使用して、ローカルの確認データベース(V_DB)を問い合わせする。TrE_Info構造は、証明、メーカー、形、モデル、TrEの通し番号に関する詳細情報を含む。確認データベースV_DBは、TrEsが信頼できると考えることができる情報を格納する。例えば、あるベンダー、モデルあるいは他の同様の確認者を信頼するポリシをインプリメントすることは可能であってよい。TrEがTrE_Infoの評価の結果によって信頼できない場合、PVEはSeGWにこの情報を含んでいるメッセージを送ることができる。その後、SeGWは、このメッセージに適切に作用することができる。PVEは、悪/untrustedメーカーのような否定されたアクセスの原因を含んでいる、T_PVMトークン(例えば補足データ・フィールド)にステートメントを加える。PVEはT_PVMにタイムスタンプと署名を置きる。T_PVMはSeGWへ転送される。その後、SeGWは時間を確認することができる型押しをする(やり直し保護)また署名(偽の送り手を防ぐ)。その後、SeGWはネットワーク・アクセスおよび装置認証、およびブロックの将来の認証の試みを否定することとなる。

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

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

PVEは、さらにDev_IDとTrE_Infoを使用して、未知のTrEsのために、RIM更新処理と類似したV_DB更新処理を最初に引き起こしてもよい。

不良状態F2については、PVEは受信Clistからのすべてのコンポーネント用のV_DBからRIMを取って来る。確認データベースV_DBは単に保証されたRIMを格納する。V_DBに対応するRIM証明書を安全に格納すべきである。

1つの実施形態では、RIM証明書はV_DBへの摂取の前に検査され、次に、廃棄されることができる。あるいは、RIM証明書はセキュリティ目的のために格納されることができる。例えば、MNOは、MNOが信頼された第三者からRIMとそれらの証明書を得る際に勤勉に行なったという意味で、監査役に装置管理での従順を証明するためにそれらを使用することができる。

不良状態F2aについては、PVEは、検索されたRIMからの正確な確認データを再計算し、確認メッセージの中で受け取られた確認データにそれを一致させてよい。

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

F2aポリシによって、いくつかのオプションは適用可能である。拒絶の場合には、PVEが、SeGWへの確認の結果を示してよい。SeGWはネットワーク・アクセスを否定するか、あるいは隔離ネットワークの中に装置を受け入れてよい。最新版の場合には、確認データ失敗を示す確認結果(T_PVM)を受け取った後、DMSが、確認に失敗したコンポーネントを交換するために管理手続により、管理プロセスを始めてよい。DMSは、確認が失敗し、装置が再確認する指標を備えたSeGWへT_PVMを転送することができる。DMSは装置へ正確なRIMを送り、リブートを引き起こしてよい。リブートに際して、装置は、新しいRIMの使用して再確証し、再確認することができる。確認データが再び正しくない場合、装置は遠隔の管理手続によって回復されることができないとしてよい。無限の再起動の繰り返しを防ぐために、遠隔のリブート・トリガーを送る場合、DMSはタイムスタンプでDev_IDを格納してよい。

別の変化（バリエーション）では、PVEは、PCR価値のような確認データに基づいて、データベースV_DBの特別の部分を使用することができる。その貯蔵所はPCR価値によって配置を信頼する。PVEは、有効な配置をPCR価値の場合のハッシュ・テーブルのような確認データのテーブルを上へ捜すのであってよい。一致が見つかる場合、確認は直ちに成功することができる。ハッシュ値が同じになる場合、V_DBに有効な配置に対する予め計算されたPCR価値を格納することは同じ配置の中で作動している装置のクラスに役立つであろう。RIMに対するコンポーネントをすべて比較する代わりに、計算上のオーバーヘッドを低下させて確認のプロセスを促進することで、単一の合成ハッシュ値は比較することができる。

ポリシ不良状態が満たされない場合、装置は有効である。PVEはSeGWにこれを示すことができる。それは、CNへの接続を許可することができる。

不良状態F2bについては、RIMは信頼された第三者機関(TTP)から引き出されることができる。1つの(あるいは倍数)コンポーネント用のRIMがV_DBに格納されない場合、PVEはRIMmanへのRIMを外すリストを転送する。その後、RIMmanは、TTPから(認証された)RIMを取って来る。Clistは構成要素の指標CInd(URNのような)(RIMmanはそれによってコンポーネントを識別することができ、どこで対応するRIM証明書を見つけるべきかについての情報を得ることができる)を含む。RIMmanは、V_DBの中へのRIMcの立証を含む新しいRIMのためのRIM摂取を行う。RIMmanは、CInd、RIMおよびRIMcを格納するV_DBの最新版を行う。RIMmanは、その後、V_DBから見当たらないRIMを取って来ることができるPVEへのV_DB最新版を示す。

代案として、RIMは装置から取って来てよい。装置が確認メッセージの中でネットワークに格納されたRIMcs(RIMを含む)を供給する能力を示している場合、PVEはRIMとRIMcsを装置に求めてよい。これはRIMを取って来る背景方法として適用することができ。装置が安全起動にそれらをすべて使用したので、RIMはすべて装置の中にある。PVEがいくつかのコンポーネント用のRIMを見つけることができない場合、PVEは新しい時間と共に、RIMとT_PVMを逃すリストを進める。SeGWに、付けられて型押しをする。SeGWは、RIMcsを検索する装置を備えたプロトコルを行う。SeGWは、時間を備えた受信RIMcsを追加する。T_PVMおよび前方へPVEへのT_PVMトークンに型押しをする。PVEはRIMmanへ検索されたRIMcsを転送する。その後、RIMmanは、受信RIMcsが信頼された実体から出され有効であることを確認する。RIMmanは、V_DBの中へのRIMcsの立証を含む新しいRIMのためのRIM摂取を行う。RIMmanは、V_DBの最新版を行ない、次に、PVEへのV_DB最新版を示す。その後、PVEはV_DBから確認されたRIMを取って来て、確認を続けてよい。コンポーネント用のRIMが検索および摂取プロセスの後にまだ見当たらなければ、PVEは再びRIMcsを装置に求めないであろうが、ここに記述されるようにTTPからRIMを取って来るであろう。TTPの装置からどちらかを得られたどんなRIMも、電子証明書と同じラインに沿った信頼性のために確認されることができる。

PVMコンポーネント間の信頼モデルは、装置からのRIM摂取中のアクションのシーケンスを決定する。PVEは、装置からのRIM/RIMcsを信頼しないであろうが、そのデータの信頼性をチェックした後にRIMmanによってのみ行なわれて、V_DBへのそれらの摂取を待つであろう。PVEは、さらにRIMmanと同時にすることができる」s RIM摂取オペレーション、装置に基づいた確認データを再計算するスタートはRIMを受け取ったが、RIMmanのそれらの信頼性に関する決定を待たなければならないであろう。

RIMcsは、それがCNのみの内部で送られるので保護された完全である追加メッセージの中で送られることができる。RIMcsを含んでいるメッセージは、T_PVMにリンクすることができる。

装置については、RIM摂取プロセスは外部実体によって行なわれ、装置およびPVMインフラストラクチャの完全な摂取プロセスまで延長されることができる。これはPVMアーキテクチャ内の分配されたRIM摂取であると確認されることができる。

PVEからRIMmanまでのメッセージはすべて例えば、メッセージ攻撃に対して、メッセージ保全を保証し、かつ完全性と軽減を確実にするためにフォーマットと内容で制限される。本質的に、メッセージは、参照メトリクスが検索することができる位置を指すコンポーネント用の単一のURNを含むことができる。

不良状態F3については、PVEは、配置ポリシデータベースC_DBから許可された配置に関するポリシを取って来る。この配置ポリシデータベースC_DBはDev_IDによって許可された配置を含むであろう。C_DBはCPmanによって管理される。C_DBは、さらに分離され、しばらくの間有効にしなかった装置のための所望の最新版のようなポリシ的措置を含むことができる。PVEは、Clistの中の情報に基づいて、CPmanから受け取られたポリシを評価する。評価が不良状態F3aかF3bのうちのどれにも帰着する場合、異なるアクションが適用できる。

拒絶については、PVEは、T_PVMに失敗した配置ポリシに関するメッセージを加える、時間を置く-型押しをする、およびT_PVMの上の署名、またSeGWへそれを転送する。その後、SeGWはタイムスタンプ（やり直し -防護）と署名（偽の送り手を防ぐ）を検証することができる。SeGWはネットワーク・アクセスおよび装置認証(またブロックの将来の認証の試み)を否定することができる。確認と認証が境界である場合、これは認証プロセス

Clistが未知で、このようにC_DB(不良状態F3b)で見つからず、ポリシがClist(F3aの特殊なケース)にコンポーネントに対して存在しない場合、PVEは、TTPからの配置ポリシを探索するためにCPmanを呼ぶ。CPmanが新しい配置ポリシを検索することができる場合、CPmanはC_DBを更新し、最新の配置ポリシに指標を備えたPVEへメッセージを送る。

最新版が新しいコンポーネント(F3aを参照)を含んでいる場合、C_DBとV_DBを一貫しているようにしておくことは可能である、これはCPmanから新しい構成要素の確認者を含むPVEまで示されることができる。その後、コンポーネントのために最新のRIMあるいは新しいRIMを取って来るために、PVEは、RIMmanへ新しいコンポーネントについての必要な情報を転送する。ここで、コンポーネントCmanおよびC_DB、およびRIMmanおよびV_DBが独立して作動するように、私たちは個別の配置およびRIM管理のために管理プロセスを維持したい。ポリシが装置への最新版を要求する場合、PVEは更新処理を引き起こす。

単純なポリシの例として、C_DBは、許可された配置のリストを含むことができる。PVEは、格納された許可された配置と次にはそれを対抗させるCPmanへ受信Clistを転送する。一致が見つからない場合、不良状態F3bが検知される。現在の確認プロセスが装置管理プロセスの間に装置最新版の後の再確認かもしれないので、最新版のチェックは必要であろう。この管理手続中に、装置構成は変わるかもしれないし、C_DBからの新しい配置に対して確認されなければならないであろう。

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

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

ネットワークに始めた再確認の一例がここに記述される。ネットワークは再確認を始めた装置で周期的な基礎上で生じるかもしれないが、しかし、それはセキュリティの理由で必要であると考えられるネットワークでいつでも起こるであろう。装置中のモジュールがオペレータによってプログラムされた間隔で再確認を実行するようにプログラムされるように、再確認は、さらにポリシの一部としてオペレータによるセットアップであってよい。再確認は、再確認の要請を示す装置へIKEv2メッセージを送ることが引き金となって起きるであってよい。Notifyペイロードは装置のための新しく定義された再確認トリガー・コードを運ぶために適用することができる。

PVEは、定期的にSeGWに再確認指標を送ってよい。すべての送られた再確認リクエストを追跡するために、PVEはDEV_IDとタイムスタンプでそれらを格納する。その後、PVEは、いずれかの装置が再確認リクエストを無視したかどうかを周期的にチェックする。SeGWはIKEv2プロトコルによって装置へそのリクエストを転送することができる。再確認メッセージは集合パーティに基づいてセットアップしてよいし、停電の危険を減らすように設定の時に要求するとよい。

装置は、再確認の要請を示すNotifyペイロードを備えたIKEメッセージを受け取る。その後、ネットワークへの確認および認証が再建される場合、装置はリブート・シーケンスを始める。装置が再確認リクエストを無視するように、装置が危険にさらされる場合、PVEはすべてのアクティブな再確認リクエストのモニタリング中にこれを検知することができる。PVEは、隔離ネットワークに装置を入れることにより適切に作用するSeGWへの失敗した再確認を示してよい。

再起動を開始したネットワークのための別の方法では、装置へリブート信号を送って装置がリブートを引き起こし、それにより安全起動で再確認行うことを含む。

別の方法で、装置の再確認が、さらに他のネットワーク実体からのリクエストによって生じるのであってよい。彼らの装置が広く危険にさらされたのではないかと装置メーカーが考えれば、メーカーはMNOと連絡をとり、再確認を要求することができる。これは、再確認が生じるかもしれないかどうか決定するMNOを備えた後ろのオフィス・プロセスとして行われてよい。PVEまたはHMSは再確認および再認証を始めてよい。

プラットフォーム管理の一例がここに記述される。DMSは装置管理の原因である主な実体である。受信で格納された装置情報に基づいた、のように、ベンダー、ハードウェア/ソフトウェア配置、TrE能力など、DMSはソフトウェア・アップデート、配置変更およびOTA装置管理手続きを始めることができる。管理活動は、送信された確認データ、PVEからの確認結果、および所望の目標配置のようなC_DBの中のポリシによって一般に決定される。

DMSは、装置のTrEを備えた安全なトンネルを確立することができる。DMSは、装置用のDev_ID、最新の報告された確認データおよびClistを検索するためにT_PVMトークンを使用することができる。Dev_IDを使用して、DMSは、装置のステータスをセットするために指標を備えたT_PVMを送ることにより、装置のTrEへの安全なトンネルを確立するSeGWを問い合わせする「管理」に「アクティブ（活発である）」。例えば、したがって、SeGWはこのトークンを維持し、隔離によってバックホール（岐路、復路）接続を提供してはならないし、DMSが管理活動の終了を確認するのを待つ。

例えば、ソフトウェア・アップデートの後のリブートによって、DMSによる管理活動によって、装置は再確認することができる。その後、再確認は起こるであってよい。そこではPVMシステム状態は前の確認からのT_PVMの使用により維持され、新しいものを生成してはなりません。この場合、DMSは「再確認するべき」「管理」から変更された装置状態指標と共に、SeGWに最新のT_PVMトークンを送る。SeGWは、装置のリストを待つ再確認にしておきる。そこでは、それは、装置を彼らがいつネットワーク・アクセスを求めるかを調べる。その後、SeGWは、装置が一定の期間の間再確認するのを待つであってよい。その後、管理プロセスの無事完了を確認するために、再確認の結果はDMSに示される。

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

確立された装置のTrEへの安全なトンネルで、DMSは、新しい南西のコンポーネント、変更配置およびトリガー再確認のようなソフトウェア(SW)コンポーネントをインストールできる/インストール解除することができる。

別の変化では、装置は確認メッセージ中のフラグによって再確認を示すであってよい。これは、SeGWに接近する各装置の再確認リストを調査しないようにする。フラグは、TrEコンポーネントによって行なわれるプロセスのような安全なプロセスでセットされることができ、その結果、装置はそれをセットしないことにより再確認を回避できない場合がある。

これおよび前のステップはPVEでではなくSeGWで起ってよい。また、そうでなければ、SeGWは自動的に新しいトークンを生成するであろう。特に、これらのステップは、装置管理(その中でSeGWは再ブーツへの装置を要求する再確認の跡を追わなければならない)のために取られたプロトコル・ステップを含む。装置リブートの後、装置が再度接続するので、および従って、re-確証する、SeGWは、再確認のためにリブートする装置の跡をそうでなければ追わなければならないし、さもなくば、SeGWは最初の接続としての接続と認証の試みを考慮することとなり、それ故、新しいトークンを出すことになるであろう。したがって、再確認リストのメンテナンスはSeGWのために含まれている。

再確認の多くの巡回に関してT_PVMを連続的に使用することは再発する最新版失敗および他のパターンの不規則な振る舞いを検知するのに有用であってよい。

DMSが装置に新しいコンポーネントをインストールする場合、DMSからTrEまでの同じ管理メッセージにソフトウェア用のRIMが含まれることが保証されることができる。TrEは、RIMとそれらの現地管理職者の安全な記憶装置の原因であってよい。必要ならば、DMSはコンポーネントの設置の後に再確認を引き起こする。新しいソフトウェア用のRIMは、V_DBへRIMman経由でそれを格納するPVEに送られることができ。DMSはCPmanを使用して、配置ポリシデータベースC_DBを従って更新する。PVEが新しい配置を有効にするために再確認に従事する前に、新しいコンポーネント用のRIMはV_DBにおいて利用可能になるであってよい。配置変更の場合には、例えば、DMSが与えられたコンポーネントとパラメータを交換する場合、C_DBがCPmanによってDMSによって更新されることができる。

TrEは安全な最新版および管理機能に安全な実行環境を供給することができる。この機能は、失敗したソフトウェアか構成要素の最新版の場合の救助モードへ危険にさらされた装置が少なくとも送られるかもしれないことを保証する。フォールバックコード・ベース(FBC)は失敗の場合にはDMSによって装置復帰に適用することができ。これは、主なコードがDMS管理法によって更新されるかもしれない原始の状態に装置が戻ることを可能にする。

競合条件を回避するために、再確認はトークン・パッシングの後にDMSからTrEまでのメッセージが引き金となって起きるであってよい。そうでなければ、装置は、再確認の準備をするためにSeGW受理の前にトークンを再確認しようとすることができる。

別の変化では、SeGWは再確認リスト内の装置に関する、再確認の試みの、あるいは失敗した試みの数「n」を維持することができる、その後、装置はブラックリストに載せられる可能性があり、隔離させられて、インフィールドメンテナンスがトリガーされ、あるいはそれらと組み合わされる。

別のものの中で、異なる、安全なトンネルの構築のための通信機密が、SeGWの関与を回避するT_PVMに含まれ、T_PVMから抽出することができる。

補足方法は、装置に接続を与えずに、有効になることができず、PVMの中で交換され、更新することができないコンポーネントを不能にしてよい。本質的に、DMSはdisable CIndを送りメッセージを再確認することができる。それは、下記に述べられるようなオペレータ制約からの危険を緩和するのを支援する。PVMは装置とオペレータの間の「信頼の戦い」をするために適用することができ、「信頼の戦い」の発生を不能にする異なる方法は利用可能であってよい。1つの例示方法では、装置のコンポーネントはClistの中のこのコンポーネントのない再確認の強要により無効になるとしてよい。コンポーネントのための有効な最新版が利用可能でない場合、これは当てはまるであろう。別の方法では、ロード・オーダーは強制的に変更されることができる。別の方法では、強制的にパラメータ(それらはRIMに影響できるし、影響しないかもしれない)を変更する。パラメータの強制的な変更は、確認がそのためにPVEから失敗したもののためののみではなく、すべての装置コンポーネントについての必要な情報をすべて得ることをDMSに要求する。

PVMでは、装置へRIM証明書を送ることは一般に必要ではない。立証と管理は、示されたPVMアーキテクチャ(RIMmanにあるオペレータ・ネットワークのタスク)にある。それがネットワークを信頼するので、装置は管理プロセス中の受信RIMおよびCIndsを信頼することができる。信頼されたコンピューティング・グループ(TCG)モバイル・フォン・ワーキンググループ(MPWG)は、他方では、信頼された装置によってRIM摂取をdeに中心に集められたプロセス(MTMによって保護されて、それらをインストールする前に、装置はその中でRIMのための得られた証明書をさらに確認する)として定義する。両方の変形は相互に排他的だとは限らない。DMSは他方のデータと共にRIMcsを送ってよい。また、TCGのMPWGの従順な装置はTCG仕様書によってそれらをインストールすることができる。これは、PVMと、TCG MPWGによって定義された安全起動の装置管理の間の相違点であってよい。

確認データの一例がここに記述される。例えば確認データを送ること、認証用の確認データを拘束すると同様にPCR価値(それらは単一の測定の総計のハッシュ値である)の形式で、TCG仕様書によって提供される技術基準である。しかしながら、確認データのその生成およびTCG明細によって拘束することは、多くの測定されたコンポーネントを備えた装置上に、計算上、特に高価であってよい。これは、暗号のものによって通常行われる、ここに記述されたオペレーションを拡張する-2つの古いものから本質的に新しいハッシュ値を作成する。これは、装置の操業開始プロセスを著しく遅くすることができる。それは例えばホーム環境では好まれないであろう。

さらに、それらが測定の結果についての同様の情報を伝えるので、RIMと確認データの間に余剰がある。安全起動プロセスが正確に行なわれた場合、TrEは測定をRIMと比較し、単にコンポーネント(両方はそれのために一致する)をロードする。したがって、Clistの中の指定のRIMは、確認データの情報をすべて伝える。実際、確認データが言及された測定の総計であると思われるので、それらは確認データより多くの情報を伝えるであってよい。確認データは実測値用の暗号的に一義的な速記である。PCR価値は1つの実施形態の中で確認データとして適用することができる。

確認データに対する議論の基礎となる基本的仮定は、実測をRIMと比較する際に正確に操作された安全起動プロセスが、Clistを中へ示したということである。したがって、セキュリティの観点からすると、1つの主な理由があり、なぜ確認データは、確認中の装置の信頼性を増すであってよいか。装置に正しくないRIMがある場合、これはそうか、あるいは測定を偽のRIMと比較する。

安全、開始する、あるいはAuVのような安全で、実際、単独で開始する単細胞生物のアプローチの場合にさえ、確認データ(高い保護を備えたデータの感覚中の、生成された、安全、達成されたシステム状態をユニークに識別して開始する)を保存するさらなる議論がある。この場合、単に測定値のない構成要素のリストかもしれない他方の確認データの完全保護のためには何もしない。CIdsのこのリストは、さらにコンポーネント(例えばTTPからの)についての信頼情報をどこで、どのように得るべきであるか検証ソフトに伝える。

それほど信頼できないコンポーネントの確認者をもっと信頼できるもの(「構成要素の信頼高さ」)のCIdsに(捕らえられた)取り替えて、攻撃者は、確認データ(Clist)を操作してもよい。-それに確認データがない場合に、内部に操作を検知する手段なしで、有効にする装置(TrE)は改竄されたデータに署名し、正確に有効にする。

ある程度までこの攻撃を緩和する方法は、安全なものがエンジンを開始するということであってよい、状態(最後のPCR価値)にそれを密閉することによりデータを静的にする。確認については、その後、それを開封する必要がある。また、同じセキュリティ・ギャップは再び開きる。また、更に、システムはそのようなアプローチの柔軟性を制限して、SML密閉の後に静的に続ける必要がある。

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

ここの「確認データ」は「データは、さらに生の測定データから処理され(例えば、切り刻んで)、その後、それはRIMと一致したと確認される。」と同義的に使用される、確認データは、安全なスタートの完成の後に、識別する、とプラットフォームがユニークに述べる。正しくないRIMのプロビジョニングは例えば危険にさらされた出所からかもしれないし、PVMシステムに全体としてより大きな影響を及ぼすかもしれないし、このように重大な危険をもたらする。

具体的なシナリオは、もう一人のパーティによって、RIMの信頼された源(それはオペレータCNの外側にあってもよい)が、危険にさらされたか、例えばハイジャックされたか、からかわれたものである。これが検知され修正される前に、RIM出所は正常なPVMプラットフォーム管理で、危険にさらされたコンポーネントに加えて、多くの装置に偽のRIMを配達することができる。

そのような場合(すなわち公開鍵基盤(PKI)中の一般的慣習)での共通の治療は、一致するRIM証明書を無効にすることであろう。信頼された参考資料が装置上で存在できるので、そのような手続きは装置上のロードを招いてよい。ごく一部分だけが攻撃によって影響を受けた事実にあった間、TRV取り消しは全体の装置人口用のRIM、RIMcおよび構成要素の最新版を強要することができる。これは、ユーザのための激しいネットワーク交通および不便を引き起こすであろう。認可されたTRV取り消しがインプリメントされるかもしれないように、メカニズムとプロトコルは装置に支援される。

このシナリオでは、確認中の確認データの生成および使用は適用可能であってよい。PVMシステムは、各単一を有効にする装置用に、ポリシに基づいた確認データ使用法を起動することができる。その後、PVEは危険にさらされた装置を検知し、それらだけを管理することができる。これは、「最小の立証・ポリシ」とここに記載される。

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

1例において、トークン・パッシングはこれをするために適用することができ。SeGWは、確認プロセスにユニークに関連したトークンの生成および管理の原因である実体として形成されることができる。PVMトークンは、だけでなく有効にするTrEの同一性また問題の一義的な確認プロセスに結び付けられてよい。トークン・パッシング・アプローチはやり直し/再確認保護を含む。確認の試みは古い確認の一義的な防ぐやり直しになり、頻繁な再確認によるサービス強制停止攻撃を検知する手段を提供している。トークンによって、確認セッションは、PVM関係資料および一義的な確認へのメッセージの一義的な関連付けを考慮に入れて確立される。これはさらに新鮮性を評価する必須条件である。

確認トークンは(必ずではなく署名した)タイムスタンプに基づいて作ることができ、SeGWによって最初に生成され、確認トークンを通すすべての実体によって時間順序付きリストに追加されるので、確認データの新鮮さはコントロールすることができる。

新鮮を導入する別の方法は、RoTがロードされた直後に、安全な瞬時通信(RTC)から時間を読み、総計のハッシュ鎖を作成するためにこのタイムスタンプを使用してよい。別の選択肢は、あらゆる再起動サイクルをインクリメントされ、ハッシュ鎖を作成するためにRoTによって適用される命令カウンタを使用することができる。

しかし、新鮮を導入する別の方法は、ステージ1およびステージ2チェックを完成し、SeGWとPVEとの通信を始めて、次に、SeGWにステージ3確認データの結果を伝える前に、ステージ3チェックの再検証を拘束するためにSeGW/PVEによって供給された目下を使用することである。これは、確認データの新鮮を保証する。

標準PVM(再発する最新版失敗および他のパターンの不規則な振る舞いを検知するのに有用)でのように、再確認の多くの巡回に関してT_PVMを連続的に使用することができる。SeGWは確認トークンに基づいた様々な条件で検知し作用することができる。例えば、あまりに長い間活発に続けるトークンは、PVMの一般エラーを示すであってよい。SeGWは、トークンがそのステータスを見つけ出し、かつそれに作用するためにPVEとDMSを獲得することができる。これは確認タイムアウトであると確認されることができる。別の例で、トークンがアクティブな間、再確認が生じるであってよい。これは、予期しないリブート、停電あるいはサービス強制停止攻撃のような様々な条件を示すであってよい。別の例において、ランダムまたは周期行動のような時間ベースのパターンは、侵入検知システム(IDS)の静脈に検知されることができる。恐らく隔離された装置、ブラックリストに載せた、また、インフイールド保守は起きてよい。

トークンもPVMシステムでの実体、およびPVMシステムと装置間で渡されたデータの完全性を保護するために適用することができる。これについては、それは保護されるデータのハッシュ値を例えば含めるために十分であってよい、Clist、あるいは不良状態F2aの処理でのRIMを逃すことおよびそのデータへのポインタのリスト。これがそれに過負荷をかけるかもしれないし、無数のオーバーヘッドに結びつくかもしれないので、データ対象はT_PVMに全体として含まれていなくてよい。それは実際にあるサービス強制停止攻撃を可能にすることができる。

オペレータRIMを保護する方法の例がここに記述される。オペレータRIM遮蔽は、オペレータによって生成されるか、等しく「ホーム・オペレータを選んだ」(SHO)RIM証明書による様々な外部出所(装置はそれでバックホールリンクを確立したい)から来る装置コンポーネントのための多数のRIM証明書を交換する。利用可能な場合は常に、これらのSHO RIM証明書(SHORIMc)はV_DBの中の同じコンポーネントのために外国のRIM証明書上の確認の中で先行をとる。装置管理では、SHORIMSは、TrEによって装置の安全起動に装置上でさらにローカルに外国の証明書に優先する装置に、DMSによってインストール（押し下げられた)される。

SHORIMcsは、確認中のRIM証明書を取って来るための「第1レベルの貯蔵所」として役立つであってよい。それらは、V_DBの1つの技術的に分離された、高機能の、サブデータベースに対して本質的に指す特別のCIndsに関係しているとしてよい。

オペレータRIM遮蔽は、M2M設備(M2ME)のような任意のタイプの非常にモバイルの装置に役立つ。モバイルの装置が新しいオペレータの領域に入り、確認を行なう場合、新しいオペレータにもう一人のオペレータを指すCIndsが贈られてよい。ここに記述されるように、それはモバイルの装置のローミングと類似したやり方でこれらを受理するか、あるいはそれらを交換することができる。

オペレータRIM -遮蔽の変形の中で、SHOがSHOによって生成されたSHORIMcsの署名する鍵の公の部品をリリースしないことを決定する場合、そのSHOから来る装置のコンポーネントを有効にすることはもう一人のオペレータにとって難しいかもしれないし、あるいはできないかもしれない。そのようなスキームは、従来のSIMロック手続きが提供する制約の同じレベルまで延長されることができる。オペレータRIM遮蔽はライフ・サイクル管理手段としてSHOとの第1の接触で遠隔に「ブランド」装置へのフィールドで装置の最初の配備の中で適用することができる。

PVMに基づいて保護するオペレータRIMを確立するために、次の追加のステップは上に記述されたオリジナルのPVM手続きに言及して記述される。RIM遮蔽用のPVMセットアップでは、RIMmanは、オペレータRIM遮蔽のためのそれぞれの機能を行なうためにPVEとDMSを形成する。プラットフォーム確認では、PVEは、コンポーネントのリストを含んでいるメッセージを送る(あるいは別々に構成要素の有効性に関するメッセージと結合した)今、SHORIMはV_DBの中にどれのためのものであるか。DMSはそのために装置に新しいSHORIMcsがインストールされるコンポーネント上で証明書最新版アクション(必ずコンポーネント自体を更新することのない)を行なうように構成される。

確認中に、PVEは、SHORIMがV_DB(これは、コンポーネント用の任意のRIMおよびRIMcの有効性に直角である、のように、正常なPVMプロセス)の中にでないコンポーネントを識別する。PVEは、RIMmanに保護するオペレータRIMのためにCIndsおよび実際のRIM(RIMmanは、それらへの署名により対応するSHORIMcsを生成するためにそれらを本質的に必要とする)を含んでいる識別された候補コンポーネントのリストを送る。RIMmanは、オペレータRIM遮蔽を適用するためにそのために受け取られたもののコンポーネントがリストする、決定するローカルに利用可能なポリシを決める。

RIMmanは、それぞれのRIMへの署名によりこれらのコンポーネント用のSHORIMcsを生成する。有効期間のような証明書パラメータは市内扱者ポリシによって決定される。RIMmanは、V_DBの中のSHORIMcsを指すSHOCIndsを生成する。RIMmanは、新しいSHORIMcsおよびSHOCIndsを備えたV_DBを追加する。1つの実施形態では、「古い」データはすべて、後の追跡可能性用の、および蓄えとしてのV_DBの中のオリジナルのCIndsおよびRIMcsのように保存される。RIMmanは、問題の装置にRIM指標最新版を強要するようにそれに命じて、DMSにペアの(CInd、SHOCInd)リストを送る。正常な装置管理での、だが構成要素の最新版なしでのように、DMSは装置TrEにSHOデータを備えたRIM指標最新版メッセージを送る。このメッセージで、装置は、DMSによって確認の中でSHOCIndsだけを今後使用するように依頼されることができる。

SHOCIndsのインストールとは別に装置上で起こること、またSHORIMcsかもしれない、ローカルのポリシに依存する。利口な装置はその正規メーカーCIndsおよび恐らく、さらに対応するRIMcsを維持する。柔軟性については、それは、様々なオペレータおよびオリジナルの構成要素のメーカー/保証人のために、少なくとも各コンポーネントの異なるCIndsの数を維持しようとすることができる。

DMSは、装置の処理状態を把握する再確認を強要することができる。処理状態を把握する再確認はRIMc最新版が装置上で失敗する場合に、周期的挙動を回避するように要求される。

オペレータの構成要素の制約の一例がここに記述される。オペレータRIMの拡張が保護するように、オペレータは、外国のネットワーク中の装置あるいはそのコンポーネントのオペレーションをコントロールするか制限することができるであってよい。これは、オペレータまで次の方法で構成要素の制約を延長することができる。ロックされるものとするコンポーネントの一部は、SHOによって、対称鍵と共に、例えば暗号化される。オペレータRIM遮蔽はこの修正済のコンポーネントのために行なわれる。復号キーは、保護され抑制されたスペース(それは単にSHOから認可でアクセスされるかもしれない)でTrE(あるいはUICC)に転送される。確認の中で、PVEにそのようなコンポーネント用のSHOIndが贈られる場合、SHOはTrEに認可データをリリースする。その後、コンポーネントの暗号化された部分は、TrEの安全な実行スペースへ転送され、解読され、そこに実行される。

従って、同じ装置がもう一人のオペレータに有効にすることができないかもしれない間に、装置が特別のSHOの方へ有効にする場合のみ、SHOにロックされたコンポーネントは機能することができる。

一層の変形では、解読された部分は、TrEに外部の実行のためにリリースされる。その後、十分なコンポーネントが装置メモリのダンプにより回復されるかもしれないので、これは前の変形よりセキュリティの点からより弱い。得られた明瞭なコンポーネントで、RIMは再生成されることができる。また、制約を壊して、もう一人のオペレータへの確認は成功することができる。

構成要素の制約の別の変形は、TrEの中で管理されたか、ユニバーサルなICカード(UICC)のような他のセキュリティ要素によって保護された暗号化秘密なしでインプリメントされることができる。一つは、オペレータ一義的なSHORIM、SHORIMcsおよびCIndsを生成するためにコンポーネントの修正を使用することができる。その後、これはコード混乱およびすき入れ（ウォータマーキング）のフィールドへ当てはまるであってよい。

オペレータの構成要素の制約の1つの例は、もう一人のオペレータのコンポーネントあるいは全装置をハイジャックするローミング・オペレータを含むことができる。これからそうでなければ無料のユーザ装置を保護する、上記のTrEベースの方法は望ましい。本質的に、装置は、そのような手続き、、コンポーネントのための制約を許可するべき時間およびそれを却下するべき時間のユーザ/集合パーティ/オリジナルSHOに警報し、ポリシを維持するべきである。

装置の個別化のための例方法が、特定のPVMシステムおよびオペレータの特性に関してPVMを使用する装置管理にここに述べられている。PVMで管理された装置は、特定のPVMシステムおよび管理するオペレータと関連して信頼できる状態であってよい。それらが別のPVMシステムおよびオペレータの領域に入る場合、歩き回る装置で生じるかもしれない疑問は、誰がその配置と信頼性を以前に管理したことがあるか証明する装置向けである。その終了に証拠を供給する装置のための独立した手段を可能にする、1つの例方法は、装置へのアドレシングが署名されるデータを装置に供給することである。メッセージのこの個別化は、送信者による故意に署名することを証明する。1つの方法はオペレータによって署名されたデータにDev_IDを含むことであってよい。その後、そのような署名されたデータが贈られるかもしれないどんなパーティも、対応するメッセージおよびその内容が署名するオペレータによって特にその装置用に意図されたと考えてもよい。これは、署名するオペレータが装置(Dev_IDによるe.g)の確実性の立証を正確に行なったと依存するパーティが信じると条件の下で考える。これが維持可能でない場合、署名するオペレータはまだDev_IDの十分な認証信用証書に代わりに署名してもよい。署名されたデータはさらに、Dev_IDで拡張されて、これが別のRIMcを本質的に確立するのである余剰を加えて、実際のRIMを含むことができる。

PVMに基づいた個別化を確立する効率的な2つの方法が記述される。1つの方法では、RIMmanはSHORIMcにDev_IDを含む。RIMcsが装置によって維持され、従って、SHORIMcがDev_IDを含めて格納されるであろう場合のみ、それは装置の内部で適用可能である。別の方法では、RIMmanかDMSはペアに(Dev_ID、CInd)オペレータ署名を適用し、また、SHOCIndsが使用される場合、SHOCIndsの上の同じオペレータ署名する。

装置をブラックリストに載せる例がここに記述される。装置のためのブラックリストを確立し、ブラックリストに基づいたネットワーク・アクセスを却下することは可能であってよい。ブラックリストはDev_IDおよび随意的にTrE_Info(証明、形、メーカー、モデル、通し番号)を少なくとも含むことができる。そのようなリストは典型的にはDMSによってアクセス可能であろう。1つの実施形態では、すべてのMNOはそれ自身のブラックリストを維持する。また、DMSはこのリストまたはデータベースにアクセスすることができる。与えられた装置がそうかどうか確かめるDev_IDがブラックリストに載せた使用を問い合わせする。その後、ネットワーク・アクセスはこれらの装置に与えられません。別の実施形態では、グローバルなブラックリストは維持されることができる。そこでは、悪者とこのデータベースがすべてのMNOによって読まれるかもしれないとともに、すべてのMNOは装置をリストすることができる。すべてのMNOが自分の装置をブラックリストに載せるかもしれないだけであり、その一方でMNOがすべてエントリをすべて読んでいるかもしれないことが保証されるに違いはない。そのようなグローバルなデータベースはもっと管理とメンテナンスの努力を要求する。上記の実施形態は代替実施形態のために組み合わせられてよい。

PVEがトークンT_PVMを受け取る場合、PVEはT_PVMにタイムスタンプを追加し、DMSへそれを転送するが、ＤＭＳはトークンおよびオプションの利得TrE_InfoからDev_IDを抽出することができる。Dev_ID(またもし必要ならばTrE_Infoあるいは現在)を使用して、DMSはブラックリストを問い合わせする。装置がブラックリストに載った場合、DMSはSeGWへのブラックリスト・エントリとして、T_PVMを含んでいるメッセージを転送する。メッセージはDMSによってタイムスタンプを装備しているとしてよい。その後、SeGWは、CNへのアクセスを否定することができる。

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

ここに記述された、装置フォワイｔリストの例である。ホワイトリストに基づいたネットワーク・アクセスを許可する、装置用ホワイトリストが確立されることができる。ホワイトリストは典型的には形、メーカー、モデル、通し番号のようなDev_IDおよび随意的にTrE_Infoを少なくとも含むことができる。そのようなリストは典型的にはDMSによってアクセス可能であろう。

PVEがトークンT_PVMを受け取る場合、PVEはT_PVMにタイムスタンプを追加し、DMSへそれを転送する。DMSはトークンからDev_IDを抽出し、随意的に、TrE_Infoへのアクセスを獲得することができる。Dev_IDを使用することおよび随意的にもし必要ならばTrE_Info、あるいは現在、DMSはホワイトリストを問い合わせする。リストされて、装置が白い場合、DMSはT_PVM(SeGWへのホワイトリスト・エントリ)を含んでいるメッセージを転送する。メッセージはDMSによってタイムスタンプを装備しているとしてよい。その後、SeGWは、CNへのアクセスを許可することができる。

さらなる実施形態はTrE_Infoフィールドからの拡張情報の使用によりインプリメントされることができる。それは、ベンダー(モデル)が通し番号とその他同種のものに及ぶと確信するホワイトリストに可能であってよい。ホワイトリスト振る舞いの複雑さによって、ローカルの、MNO中心の解決は中央のホワイトリストよりインプリメントするのがより簡単であってよい。さらに、調整装置は、ホワイトリストの代わりのブラックリストを維持することをMNOに要求してもよい。

別の実施形態では、すべてのMNOはホワイトリストかデータベースを維持することができる。また、DMSはこのリストにアクセスすることができる。質問は、与えられた装置がリストされて白いかどうか確かめるためにDev_IDを使用することができる。その後、ネットワーク・アクセスはこれらの装置に与えられてよい。

まだ別の実施形態では、グローバルなホワイトリストは維持されることができる。そこでは、すべてのMNOは信頼されるようなそれ自身の装置をリストすることができる。また、このデータベースはすべてのMNOによって読まれてよいが、一方(すべてのMNO、できる、だけ)保証されるに違いない、ホワイトリスト、それ自身の装置、MNOがすべてエントリをすべて読むことができる一方、そのようなグローバルなデータベースはより多くの管理およびメンテナンス努力を要求することができる。白いリストされた装置のグローバルなデータベースは、それらの追加の信頼関係を築くことをMNOに要求することができる。MNO Aによって信頼できると考えられる装置はホワイトリストを入力し、MNO Bにアクセスするであろう。これ、1つの、標準化された、または装置の信頼レベルを比較する認定装置確認プロセスを必要とする。随意的に、上記の変形のコンビネーションはインプリメントされることができる。

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

隔離にある装置はCNに対してダイレクトアクセスを持っておらず、顧客に対する制限のあるサービスを提供する、または提供しない。確認データがPVEによって評価される場合、確認が生じる。新しいアクションは評価の結果に依存して起ることであってよい。例えば、装置は、信頼できると考えられてよく、CNに接続することができる。別の例において、危険にさらされ、治療できなかったように、装置は検知されることができる。それはブラックリストに置かれる。また、さらなるアクセスの試みが阻まれる。さらに次の例において、SeGWは、DMSへのDev_IDおよびTrEJnfoと一緒に、確認の結果を進める。DMSは、装置を回復するために適切な最新版/ソフトウェア変更を提供することができる。SeGWに最新版に関して通知されるかもしれないし、装置の再確認を引き起こする。最新版が成功裡に適用される場合、確認は成功する。また、ネットワーク・アクセスが与えられてよい。

上記のブラックリスト方法は隔離ネットワークと共に適用することができる。これは、オペレータができればOTAの上の最新版を供給することによってのように装置への接続を利用することを可能にすることができる。あるいは、例えば、OTA手段によって装置を回復することができない場合、ブラックリストは、ブロック装置に完全に慣れているとしてよい。そのような装置は、イン現場交換/サービスによって世話をされるのに違いはない。

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

パラメータの確認の例がここに記述される。PVMに、ロードしたコンポーネント用設定パラメータ上に立証結果の依存があるであってよい。これらのパラメータが頻繁に変わるかもしれないし、そうでなければ等価な装置間に異なるかもしれないので、PVMの基礎的な実施形態はパラメータが明瞭な耐える確認の中で送られることを可能にする。しかしながら、これは十分なパラメータ・データベースを維持することを要求できるし、装置に、および検証ソフトの終わりで記録する。これは次の効果があろう:1)パラメータ・セットは大きなデータベース・スペースを占領し、評価される場合、確認を遅くすること;および、万一それが外部で漏れれば、多くのパラメータが1つの装置当たり格納し評価した2)は第三者に装置構成に関して非常に明らかにすることができる。

PVMプロセスにパラメータを含める1つの方法は、ハッシュ値を拡張する((つまりコンポーネントの測定へのパラメータのハッシュ関数結果の連結によって))方法に基づく。パラメータ要約価値は、コンポーネントのパラメータ値の連続および2進法の表現に得られる。次に、そのコンポーネントの既存の測定値はこのパラメータ要約によって拡張される。従って、確認については、測定および基準値(RIMとRIMcs)はすべてパラメータの確認の様々なインプリメンテーションに結びついて、類似した方法で扱われてよい。

証明書(例えばX.509)の関係中の同様の問題、また証明書(のような、パラメータとの類似で見られた属性)(それらは参照メトリックおよびRIMcsにパラメータを含めることにより解決されるかもしれない)に帰着する、「属性証明書のための装備されたハッシュ値」としてここに表示される。

診断の確認の例がここに示される。PVM概念に基づいた確認のための実施形態は、コンポーネントが装置にRIMを持たずにロードされることを可能にするオプションを含む。それは可能であってよい、そのnon -重大なソフトウェアが展開したセキュリティ、装置およびそれ、特定のコンポーネントをロードすることは十分に安全である、しかし、ネットワークは変更に気づいている必要がある。別の実施形態の中で、MNOがあるコンポーネント(例えば頻繁な変更のために)が常に測定されるポリシを確立するところで、装置だが確認はネットワークによって起こる。更に、これは、未知のコンポーネントをロードし測定し、かつネットワークに確認タスクを残す装置のためのデフォルト・アクションであってよい。ネットワークは装置を検疫することができてよい。それは、次には装置の遠隔のOAM修理を可能にする。例えば、それは原始の状態(コンポーネントの除去)に返るか、あるいは他の手段を取ってよい。

不良状態F2aのPVM診断の一例がここに記述される。PVEがDMSへのF2aに失敗するコンポーネントのリストを送信しないところで、失敗したコンポーネントは以下のように見つかるであろう。例えば、装置は、RIMと比較するためPVEに示すことができるSMLを維持しないであろう。この場合、DMSは失敗した(それがそれらを知らないかもしれないので)が、単に正常な管理手続中の正確なものでClistの中のコンポーネントすべてに取って代わる装置上のコンポーネントを実際に交換することを省略することができる。再始動と再確認においては、その後、それらが内部立証に失敗したので、装置は確認メッセージにさらにロードされなかったコンポーネントのリストを含めることができるであろう。PVEは、RIM最新版の後に前の確認のClistを一つと比較することにより、さらにこの診断をすることができる。正確なRIMに対してローカルに確認された時、今見当たらないコンポーネントは安全起動にロードされなかった。したがって、部品不足は置換を必要とするものである。その後、実際の置換を必要としているコンポーネントは別の管理サイクルの中で交換されることができる。

装置がコンポーネントをロードすることができないかもしれない(例えば見当たらないRIMあるいは悪)と報告し、CNにコンポーネントの測定値を送る場合、診断の確認を行なう別の方法は可能である。MNOポリシによって、OAM修理プロセスは一方の削除へ起きるか、あるいは部品を修理することができる。異なる別のもの、コンポーネント用のRIMが見当たらないか間違っていることをTrEが検知する場合に、装置がOAM修理を直接要求することを可能にする。

補足方法はコンポーネントを不能にすることができる。それは有効になることができず、PVMの中で交換される/更新することができないと必ず、装置に接続を与えない。この場合、DMSは送ってよい、1つの「CIndを不能にする」コンポーネントのためのメッセージ、また装置の再確認を引き起こする。未知のコンポーネントがロードされる場合、これは当てはまるであろう。

別の方法は、どのコンポーネントが特定の装置上で許可されるかDMSに明示させてよい。装置が許可されない(例えばセキュリティ欠陥が最近発見されており、最新版がまだ利用可能ではないので)コンポーネントを含む安全起動にコンポーネントをすべてロードし有効にする場合、DMSはそれがこのコンポーネントを不能にすることを可能にする装置へSeGW経由でメッセージを送ってよい。装置は、再確認することを要求される。コンポーネントが再確認中にロードされない場合、DMSはSeGWにこれを示す。それは、認証/確認が完成することを次には可能にする。

最小の確認ポリシ用の例がここに記述される。起動時間(例えば、PCR価値を伸びて、Clistが生産されるSMLに測定を書いて)中のコンポーネントの測定が、操業開始手続鍵のある遅れを生産できるので、最小の確認スキームはある状況の下ののみ装置確認を要求するであろう。RIMおよび格納された測定値(例えばPCR価値)が部分的に同じあるいは重複情報を伝えるので、この余剰の除去はメッセージと記憶容量を保存することができる。

ローカルの完全測定、立証および施行プロセスが装置上で(例えば、1つの安全-操業開始によって)確立されるかもしれない場合、このローカルの立証プロセスの中で使用された、確認データ(例えばPCR価値)がRIM自体と同じ情報を含んでいるかもしれないので、それはRIMだけを送るのに十分かもしれない。最小の確認は、確認データではなくローカルの立証プロセスの中で使用される基準値だけをこのように送ってよい。別の変形では、RIMを送る代わりに、RIMに一義的な確認者がある場合、および場合のみ、RIMに指標だけを送ることは可能であってよい。

最小の確認用の2つの必要条件が次のものを含む:1)局所測定、立証および施行(MVE)が処理することは信頼できる;および、RIMのためのRIM出所が装置上に格納したことは2)信頼できる。評価用の外部実体にローカルのMVEプロセス用の確認データを報告することは可能であってよい。これは信頼の明示的な設立向けである。それを危険にさらすことができないように、MVEプロセスが実行されることができる。装置が後でRIMを上に報告するという事実は、MVEプロセスが信頼できることを示唆する。これは信頼の暗黙の設立向けである。

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

調節は効率を獲得するためにRIMおよび確認データの余剰に行われてよい。例えば、装置はある状態中に、あるいはある頻度ののみのみ確認データを運ぶように要求されることができる。例えば、危険にさらされたRIMがPVMシステムによって検知されている場合、新しい装置はこのオペレータ領域へ歩き回る。あるいは、SHOはしばらくの間この装置を見ていない。別の例において、立証の配達は、すべての「N」確認の中で一度だけ必要であってよい。

改善の例が、PVMの用途のためにここに記述される。改善(すなわちソフトウェア・アップデート)は装置の勤続のための必要なオペレーションであってよい。装置が改善を必要とできる多数の理由がある。ソフトウェア改良、バグフィックスおよび増強の定期補修に加えて、改善は装置の一般的なセキュリティ・プロセスの不可欠な部分であってよい。確認手続きに、装置上のソフトウェアはその完全のために測定され確認される。これらの測定はTrEにあるRIMと比較される。立証が失敗する場合、コードは干渉された。あるいは、RIMは特にそのコード・ベースには正しくない。改善手順は装置の適切な確認を保証する、コード・ベースあるいはRIMのいずれかを更新するために始められてよい。

1つ以上のコンポーネント用の装置完全性チェックが失敗する場合、これは、それらのコンポーネントが危険にさらされるか、対応する信頼された基準値が装置上のコード・ベースと協調せずにあることを示唆する。改善手順は、装置がSeGWに確証することができないことをCNに少なくとも示し、かつインストールされたコード・ベースに対応するコード・ベースあるいは新しい信頼された基準値のネットワークに始められた最新版を恐らくさらに促進するために始めてよい。改善がSeGWによってDMSと装置の間に生じてよい。

任意の改善の開始については、いくつかの共通のセキュリティ要件は当てはまる。それらは失敗が生じるプロセスを上へ安全なスタートのステージによって決定される。TrEが構築されるが外部実体に対して接続を持っていないことを示す、考慮される最悪の場合は、安全なスタートのステージ2の失敗である。装置は (したがって)、1つの、正常、開始する、この状況の中で、リクエストは改善できない。FBCのような付加的なコード・ベースは、TrEに安全にロードされ、改善を行なうために使用されることができる。そのようなプロセスのためのセキュリティは下記が特徴である:1) FBCは完全にロードされ、TrEへ不変でろう；2) TrEはFBCを安全に実行することができる;3)DMSのようなネットワーク実体を備えた改善のための通信は、完全と秘密のために安全せいになるであろう;および、ネットワークへの改善アクセスのための信任状は4)プロセスの全体にわたって保護されることができる。あるいは、TrEにFBCをロードする必要はない。FBCは、TrEで(例えば改善の専用のもののための別の(信頼された)コード・ベースとして)共存することができる。FBCに対する信用は、それが安全になった記憶装置に格納されるか、HWを安全になった秘密によって保護されるという事実に由来するであろう。そのため、TrEはFBCを実行するためには必要ではないであろう。FBCは自立かもしれないし、TrEの設立なしで直接走っているとしてよい。

装置に始められた改善の一例がここに記述される。装置確認の範囲内で、改善は、エラーの検知上の装置を直ちに隔離することの代わりになるだろう。自律的立証の場合には、TrEが確認された初期である。それが正確に確認される場合、それは、装置が安全起動のあらかじめ定められた状態を達成したことを示す。この含意は、TrEが信頼できるということである。また、TrEに格納されたRIMは信頼できる。しかしながら、それは、RIMが装置に現在載せられるコードの特別のバージョンには正確であることを示さないであろう。

ネットワークに始められた改善の一例がここに記述される。自律的立証の場合には、装置が確認手続きに失敗する場合、FBCはRIMを含む主なコード・ベースのソフトウェア・アップデートを引き起こして始めてよい。装置は、装置が蓄えモードおよびニーズで即時の改善を実行していることを示すNotifyペイロードを備えたIKEv2メッセージを送ってよい。

準自律的立証方法については、改善手順は、必ずしもソフトウェアの十分な最新版を要さなかったか、あるいは基準値(TRV)を信頼する。装置がステージ1と2つ確認を通るが、ステージ3に失敗する時に、失敗したモジュールに関する情報はNotifyペイロード中のPVEに送られるか、あるいはIKEv2プロトコルを中へ証明することができる。非重大なものとしてそれらがモジュールに失敗したとPVEが思う場合、モジュールに失敗した、無効になった/負荷を軽くされた確認と認証はそれらを継続し続けるであってよい。しかしながら、失敗したモジュールが批判的な場合、PVEは改善が必要であることを示すDMSに情報を送ってよい。

別のシナリオは、TREに格納されたRIMが特定のコード・ベースには正しくないということであってよい。エラーがRIMにありTREの中でそれらの値だけを安全に更新する必要があることを情報の分析が示すところで、失敗した測定は、PVEに送られることができる。

遭難信号およびフォールバックコードの事例、および実施形態がここに記述される。装置はフォールバックコード(FBC)イメージを装備しているとしてよい。その目的は、それが装置完全性立証に失敗した場合に起こる装置の改善を促進することである。FBCは読み出し専用メモリ(ROM)のような安全なメモリに格納されることができる。ローカル装置完全性立証が失敗する場合、FBCが起動されることができる。FBCは、影響を受けた装置用改善の原因であるCNの中の実体との通信に必要とされた必要な機能、方法および信任状を少なくともすべて含むことができる。さらに、FBCはさらにネットワークから十分なソフトウェア・アップデートを受け取るのに必要な機能を含むことができる。1つの、特別、「改善」DMSが考慮されることができる。

装置とTrEは装置完全性チェックの失敗上で次の改善表示手続きを行なうことができるとしてよい。最初に、TrEは、フォールバックコード(FBC)として知られている、信頼されたコードの実行を始めてよい。FBCはROMのような安全なメモリに格納されることができる。次に、FBCは、1つの、あらかじめ指定された、「改善」DMSに安全な接続を確立することができる。第3に、FBCは、装置IDを含んでいるかもしれないDMSに遭難信号を送ってよい。遭難信号の受取上のDMSは、装置が例えば持っており完全性チェックに失敗し、メンテナンスを要求することを知っているとしてよい。随意的に、DMSは十分なファームアップ手続きを始めるか、あるいは部分コード/データ最新版を行なうために信号の受取上で、診断法を行なうことができる。

RIMのない確認の例がここに記述される。RIMのない確認は、安全なメモリーカードのようなロード上のTrEの管理の下で記憶を安全にするために構成要素のコードの安全な転送を含むことができる。RIMのない確認はさらに正常なメモリに、コードのような暗号化されたコンポーネントを格納するように要約価値を暗号化に取り替えることを含むことができる。さらに、それは、TrEによって保護され、DMSと共有されるキーを備えた暗号化、あるいはDMSとTrEに公のペアおよび秘密鍵ペアがあるかもしれないところで、非対称の暗号学アルゴリズムに由来した暗号鍵を含むことができる。暗号化されたコードはターゲットとされた変更を考慮に入れないであってよい。不正に変更されたデータの解読が無意味を産出するので、コードのどんな操作も、安全起動の変形中でのように解読で検知されることができる。そのような変更の検知は暗号化されたコードの中への要約価値の包含によって遂行されることができる。誤り訂正符号のようなさらなるオプションが適用されてよい。

位置に基づいた情報の包含物の例が、確認プロセスにここに述べられている。いくつかの装置は、適用シナリオ(位置に基づいた情報は窃盗保護、積荷トラッキング、艦隊モニタリングあるいは監視のような重要な役割を果たす)の中で適用することができ。装置は、地理的位置データを提供するために全地球測位システム(GPS)モジュールを典型的に装備しているとしてよい。その後、安全起動は位置に基づいた情報の信頼できる生成および記憶装置を保証するためにGPSのモジュールおよびコンポーネントを含むことができる。位置データは、TrEの安全な記憶装置にさらに安全に保存されることができる。その後、位置情報は確認メッセージに含まれているとしてよい。
これ、だろう、報告された位置が所望の位置と一致しない場合に、OAM手続きによって装置構成を変更するために例えば使用される。装置が新しい位置を報告する場合、それがネットワーク、伐採のようなトリガー・ソフトウェアの出来事、報告あるいはシャット・ダウンに接続するために異なるパラメータを使用するように、その配置が変更されることができる。位置情報は安全に信頼された適用によって扱われると仮定されることができる。

PVMの適用および実施形態が、既存で標準化されたネットワーク実体、プロトコルおよびメカニズムに一般的なPVMアーキテクチャの写像を供給するH(e)NBおよびM2Mシナリオにここに記述される。両方の適用は特定のセキュリティ要件を持ち出する。両方の適用は、装置がそうである共通に持っている、閉じたように、もはや熟慮していない；i)、記憶装置のための不変の環境および極秘データの取り扱い、携帯用ハンドセットが伝統的に見られたとともに;および、これらの特別の装置はii)携帯電話ネットワーク・オペレータ(MNO)と異なるステイクホルダーにコントロールされ、一般に、中核ネットワークに単に断続的に不安定なリンク上に接続される。

最初の適用は、フェムトセルとして一層よく名高いH(e)NBを指する。H(e)NBは、3Gネットワークに端末装置(携帯電話のような)アクセス接続を供給する小さくポータブル・アクセス・ポイントである。H(e)NBは、敷地に、あるいはホスティング・パーティ(HP)と呼ばれるステイクホルダーのホームの中で一般に置かれる。HPは、小さく指定された地域別区分の移動通信およびサービスのための仲裁人になる。これは組織内か工場環境のような従来アクセス不能なエリア(悪いラジオ条件による)のモバイルサービスを提供するために適用することができる。H(e)NBが広帯域インターネットと携帯電話ネットワークへの一体になったアクセス・ポイントかもしれないとともに、それは、さらに個人の世帯およびスモールオフィス・ホームオフィス(SOHO)セクターに対するオプションである。

H(e)のNBの使用法のシナリオの中で、3人のステイクホルダー、ユーザ(HP)MNOはサービスレベルおよび使用法の協定によって関連づけられる。H(e)NBは実施形態されて、HPの認証データのようなこのコンテキストに多くの極秘データを格納する、例えば、携帯電話ネットワーク予約として、リスト、無線、送信する、閉じた加入者グループ(CSG)およびアクセス・コントロール・リスト(ACL)として格納されて、H(e)NBに接続することを許されるユニット(WTRU)あるいはユーザ設備(UE)を受け取る。このデータのうちのいくつかはHPおよび(または)ユーザに個人であってよい。さらに、H(e)NBの位置は、妨害から携帯電話ネットワークを保護し、かつサービスの違法の拡張を防ぐようにコントロールされる必要がある。

図7は、H(e)NB、WTRUあるいはUE 710、ならびにオペレータ中核ネットワーク730の間の例通信・シナリオを示す。それは仕事がセキュリティで課されたもの、他方、H(e)NBのサービスである2つのネットワーク実体を導入する。オペレーション、管理およびメンテナンス735(OAM)は、H(e)NB 705に遠隔の管理機能性を供給する中核ネットワークのバックホールの中の機能である。特に、それはソフトウェア・ダウンロードおよび最新版、ラジオおよび他のパラメータのセッティングおよび他の同様の機能を提供する。セキュリティ・ゲートウエイ(SeGW)740は、オペレータの中核ネットワーク730の中へのH(e)NB 705のためのメインのエントリポイントであり、また、その主な目的は不法の接続、および悪者H(e)NBあるいはH(e)NBに扮する攻撃者から出るいかなる種類の攻撃からからネットワーク730を保護することである。

第2の意図した適用はM2M通信を指する。M2M設備(M2ME)用代表例は機械を売却しており札をつけている。もっと高度なシナリオは、特に、複合熱と発電所の遠隔測定、機械管理および設備管理を含みる。M2MEが携帯電話ネットワークによってバックアップ・システムに接続されれば、放送中の(OTA)管理から始まって、M2ME所有者にMNOによって付加価値サービスを提供することができるであろう。H(e)NBのように、M2MEがMNOと異なるステイクホルダーにコントロールされる。ステイクホルダーはあるセキュリティ要件をしている。それはMNOとは異なるであってよい。H(e)NBおよびM2MEのセキュリティは問題である。それぞれの脅威、危険および続いて起こるセキュリティ要件は両方の場合には比較可能である。

脅威（ｔｈｒｅａｔ： セキュリティの潜在的違反）は6つのトップレベルのグループへグループ化されることができる。グループ1は、信任状を危険にさらす方法から成る。これは、トークンおよび(弱い)認証アルゴリズム、物理的な侵入、側チャンネル攻撃の上のブルートフォース攻撃、また認証トークンのクローンを作る悪意のある集合パーティを含む。2をグループ化する、詐欺のソフトウェア(「再堰止め」)でけとばして、操作された装置に有効な認証トークンを挿入するような物理的な攻撃から成る、物理的な干渉、および環境上/側チャンネル攻撃する。3をグループ化する、配置から成る、詐欺のソフトウェア・アップデート/配置変更、HPかユーザによるmi配置、ACLのmi配置あるいは妥協のように攻撃する。グループ4は装置に対するプロトコル攻撃から成る。これらの攻撃は機能性を脅かし、HPとユーザに向けられる。主な例は第1のネットワーク・アクセスに対する仲裁者(MITM)攻撃である、否認の-サービス(DoS)攻撃、能動回路網サービスの弱点の開発による装置の妥協、またOAMとその交通の上で攻撃する。グループ5は中核ネットワークに対する攻撃から成る。これらはMNOに対する主な脅威である。それらは、モデム/ルーターに装置の物真似、それらの間の交通トンネリング、ファイアウォールのmi構成および中核ネットワークに対するサービス強制停止攻撃を含む。H(e)NBの場合には、それがさらに許可されていない方法で位置を変更することを指する。最後に、これは、悪者装置を使用して、ラジオ・アクセス網に対する攻撃を含む。6をグループ化する、別のユーザのユニバーサル・モバイル・テレ通信・システム(UMTS)の地球上のラジオ・アクセス・ネットワーク(UTRAN)あるいは発展したUTRAN(E - UTRAN)アクセス・データの立ち聞き、他のユーザを装うこと、H(e)NB所有者に知らせられたユーザのネットワークID、有効なH(e)NBを装い、CSGの上のラジオ・アクセス・サービスを提供することを含む利用者データと同一性のプライバシー攻撃から成る。

H(e)NBおよびM2MEの両方には新しい中核機能条件書は、主として異なるステイクホルダーの認証、およびそれらの間の機能およびデータの分離を指す、つまり領域分離である。特に、HPかM2ME所有者の確実性はネットワークへの装置認証と無関係に作られてよい。更に、HPの機密データはもう一人のパーティ、MNOさえによってアクセスから保護されるに違いない。装置はセキュリティを行なわなければならない敏感なタスク、またアクセス網および接続しているWTRUの両方へのセキュリティ・ポリシを強化する。これは、サービス連続性を提供し、バックホールリンクを通じての不必要な通信を避けるために、少なくとも準自律の方法で可能でなければならない。別の重要なセキュリティ領域はそれぞれOAMまたはOTAによる遠隔の管理である。装置はソフトウェア・アップデート、データおよび適用を安全にダウンロードしインストールする必要がある。

必要なことは、認証役割を分離と、同時にコアーネットワークに対する最小変更とであり、および、従って、標準の3G認証プロトコルを再度使用することであり、拡張認証プロトコル−合意(EAP-AKA)のような標準の3G認証プロトコルを再使用することである。ここまで構想を描かれたアプローチは、HPおよび(または)M2M所有者の個別の認証持ち手を含む。それらは、後の場合に前者、あるいは管理された同一性(MID)中のいわゆるHPモジュール(HPM)で実施形態されることができる。両方は、ちょうどユニバーサルなICカード(つまり3G加入者識別モジュール(SIM)カード)(UICC)のための匿名であってよい。様々なセキュリティ上の問題はM2Mの場合での除去可能なスマート・カードの使用法に対して持ち出されている。一方では、そのようなスマート・カードの(例えば最新版あるいはオペレータ変更のために)交換がそれとして回避されることになっていることを必要とする保全業務は、地理的に分散したM2MEの大きな艦隊にとっては非常に高価であろう。用心深く最近熟慮した別のオプションは、装置中の安全な環境へのAKA信任状のダウンロードである。このオプションを考慮に入れる純粋なTC技術を使用する可能な1つのスキームは仮想SIMである。

どんな場合も、セキュリティ要件、またさらにOTAあるいは遠隔の管理を進めた、M2MEおよびH(e)のNBの上の特別のセキュリティ機能を要求する。TrEはこれらの目的に適用することができ。TrEは、システムの他の部分と安全に対話する必要がある。それらがTSのTCBがプラットフォームの残りとどのように通信するかための一般的なモデルであるので、これらのTrEインターフェースを見ることは面白い。基本的に、TrEインターフェースはすべてTrEの安全起動プロセスで初期化され、このように正確に作動すると仮定される。2つの広いセキュリティ・カテゴリーのTrEインターフェースがある。最初に、無防備のインターフェースがある。これらのインターフェースは、干渉かつ/または立ち聞きから守られるとは仮定されない、装置の一般資源を備えたTrEをさせる。無防備のインターフェースさえ、安全なブーツ中に、データ暗号化(すなわちTrEがインターフェースを横切ってその反部分資源のコードをチェックした後だけ、インターフェースを利用可能にすること)のような他のセキュリティ対策から例えば利益を得るであろう。

次に、インターフェースが保護される。これらのインターフェースは、一方のセキュリティ・プロトコルを使用して、それらを横切って運ばれたデータの完全性をよび(または)機密性の保護あるいは安全なハードウェアのいずれかを提供する。セキュリティ・プロトコルが使用される場合、さらに、それらは認証と通報認証、または機密性を提供することができる。

通信する実体が通信されたデータの保護を提供しない場合、無防備のインターフェースが選ばれてよい。データ保全性および(または)TrEが通信する必要のあるTrEと別の資源の間の機密性の保護を提供する必要がある場合、保護されたインターフェースが選ばれてよい。従って、TrEの能力は変わるであってよい。図8は、H(e)NB、およびそれが接続できる他のどんな資源の内のTrEのための実施形態を示す。これは、SeGWをH(e)NB、起動時間でH(e)NBの残りのコード完全性チェックを含むH(e)NB確認のための機能および最小の暗号の能力(真実の乱数発生器)の装置認証に必要とされたパラメータを計算し送る能力を含む最小の配置である。認証に関して、TrEが論理上HPMを含むかもしれないことは意図される。

一般的なPVM記述のアーキテクチャは、既存のH(e)NBアーキテクチャに容易に写像されることができる。データベース(V_DBとC_DB)およびそれらの管理コンポーネントは既存のH(e)NBインフラストラクチャに不慣れである。インターフェースI-hms_dによって9Aと9Bが両方のシナリオ、SeGWによるH(e)NB接続およびHMSへのH(e)NBの直接の接続を示すと考える。

図9AのPVMアーキテクチャまたはシステム900は、TrE 910があるH(e)NB 905を含む。WTRU 912(あるいはユーザ実体(UE))はI-ueインターフェース914経由でH(e)NB 905と通信できる。H(e)NB 905は、Iつのhインターフェース915経由でH(e)NB通路(GW)918(それはSeGW 920を含んでいる)と通信する。一般に、H(e)NB 905とSeGW 920の間のIつのインターフェースh 915は無防備の可能性がある。また、特別措置は確実性、完全性をよび随意的に機密性のためにこのチャンネルを安全にするために適用されてよい。Iつのh 915はH(e)NB 905とSeGW 920の間のリンクを、またしたがってCNを、確立するために適用することができる。例えば、SeGW 920はインターフェースI-aaa 975によってAAAのサーバと通信することができる。オペレータは、インターフェースのセキュリティを保証する適切な手段を確立できる。

確認中にPVE 924と連絡をとるために、I-pveインターフェース922はSeGW 920によって適用することができ。PVE 924は、SeGW 920への確認の結果を示す、I-pveインターフェース922を使用することができる。I-dmsインターフェース930は、H(e)NB管理システム(HMS)935とSeGW 920の間の装置構成に関連する通信に適用することができる。HMS 935と、および逆に通信するために、I-pdインターフェース932はPVE 924によって適用することができる。このインターフェース、Ｉ-pd 932は、装置ソフトウェア・アップデートおよび配置変更のためにのように装置管理手続鍵の間に適用することができる。

インターフェース、I-v 926およびI-d 938は、それぞれ、V_DB 940からのRIMを読むPVE 920によって、またC_DB 950からの許可された設定を読むＨＭＳ９３７によって、使用することができる。インターフェース、I-r 928およびIつのc 934は、V_DB 940の失敗するRIMの場合のように、RIMman 960に通信するPVE 920によって、またCPman 970と通信するHMS 935によって使用することができる。RIMman 960およびCPman 970は、それぞれ、データベースV_DB 940および配置ポリシデータベースC_DB 950の確認を読み書きし管理する-rdb 962およびI-cdb 972を使用することができる。

H(e)NB 905がDMS 935に直接接続できるところで、図9BはPVM 982を説明する。例えフォールバックモード（代替システムのモード）の場合には、H(e)NB 905がSeGWを備えたセキュリティ・プロトコルを行なうことができない。この場合、HMS 935は、インターフェースI-dms_d 984によってH(e)NB 905のための第1の接触のポイントとして働き、インターフェース経由でPVE 924と通信することができる、確認を行なうかあるいは少なくとも知り合うＩ-pve 986およびI-pd 988、コンポーネントは安全起動にそれに失敗する。HMS 935は改善のためのこの情報に基づいて行動することができる。

PVEを使用する確認は、様々な方法でH(e)NBシナリオに直接写像されることができる。DMS」機能はHMSあるいは適切に拡張実体によって行なわれる、HMS(eHMS)を発展させた、それはC_DBにアクセスするのに有能である。

更新に基づいたポリシのために、C_DBは、オペレーションといくらかには恐らく重大ないくつかのモジュールは提供しないであってよい、例えばモジュールの臨界、およびモジュールの様々なリリース・バージョンの相互運用性を指定するポリシを提供する。これは最新版のサイズの制限において有用で、完全なファームアップの代わりにパッチを提供する。ポリシは、H(e)NBのオペレーションには重大なものとしてモジュールをすべて定義するものと同じくらい単純にできる。したがって、完全なファームアップは終っている。

モジュールが測定に失敗する場合、その後、eHMSはモジュール、およびモジュールの相互運用性への任意の衝撃の臨界をチェックするポリシを検査する。これに基づいて、適用可能なパッチのリストは作成される。パッチは、適用のために装置へ集団的にあるいは個々に送られることができ。いずれの場合も、搬送単位はそれぞれ完全である。また、機密性は保護する。リンクは、順番にロスなしでパケットを運ばなければならない。もし要求されれば、終了するパッケージかフラグによるeHMSによって示された時のように、パッチをすべて受け取る際、装置は、最新版情報を確認するためにeHMSにそれらの測定と共に受信パッチのリストを送る、あるいは、集合的・個々のパッチ測定はそのときeHMSによって送られるか、パッチのローカルの立証を行ない、適用を始める。パッチの適用に続いて、システムは正規モードの中でけとばし、装置確認プロセスを始める。

メーカーからの新しいファームウェア・リリースがある場合は常に、この手続きも従ってよい。それは、ECBを備えた、装置および装置ブーツへeHMSが最新版通知を送り、eHMSに測定を送るというものである。eHMSはパッチあるいは完全なファームアップを提供する。また、同じ手続きは従いる。

更新に基づいた非ポリシの場合には、失敗したいかなる測定においても、HMSは、安全なリンクに関して送られる完全な新しいファームウェアを提供する。装置はファームウェアを確認し、正規モードのそれおよびブーツを適用する。

以前に既知のよい状態の場合には、H(e)NBがシステム状態を格納することを支援する場合、eHMSが測定に失敗したパッチが押し返される以前に既知の歓迎すべき状態へ返ってくれるようにそれに依頼することができる。この方法は工場状態へシステムを戻すために適用することができ。以前に既知のよい状態は、PVE、eHMSあるいはS(e)GWによって証明される状態であってよい。

H(e)NBは以前に既知のよい状態に返ることができるし、システム状態の完全保護を提供することができるし、以前に格納されたシステム状態のrestoreオペレーションを提供することができるし、危険にさらされた装置の場合には保護に対してこれにオペレーションを回復できる。

公のインターネット上に接続している装置の確認の例がここに記述する。SeGWにそれぞれ接続される装置のために、CN、公のインターネットのような不安定な最初のリンクに関して、特別の必要条件は確認の第一歩を安全にすることを申請できる。これらの特別の必要条件は、さらにSeGWにそのような接続を要請し、それによって有効にするH(e)NBタイプの装置に適用可能腕ある。PVMの総括的な実体の代わりにHMSのようなネットワーク実体のH(e)NB相当物は、ここに記述するが、同じ方法および装置が非H(e)NBセッティングに適用できることは明白に違いない。典型的には、確認と認証は最初の接続の最初の数ステップに、あるいは同じデータ構造へさえ結び付けられるように要求する。TLSとIKEv2のような特定のプロトコルへの拘束力のある確認および認証の2つの変形が記述する。

IKEの輸送プロトコル(ISAKMP)は、使用されるかもしれない多くの証明書プロフィールを定義する。また、それらはIDとして完全に資格のあるドメインネーム(FQDN)を許可する。装置証明書およびTrE証明書は個別にしておくことができる。しかしながら、装置証明書へTrE証明書を入れ子にすることは可能である。TrEに個別のID(TrEJD)があった場合、FQDNは使用されてもよい。しかし、TrEはオペレーター・ドメインネームではなくメーカーによって識別されることができる。

どこで、IKE_SA_INITプロセス、およびしたがって、Diffie-ヘルマン・キー、交換する、IKE会話のプロセス1に完成する、1つの方法は、SeGWにDev_CERTを要求するためにCERTREQペイロードを含んでいる最初の認証交換メッセージを送られせるだろう。その後、次のメッセージ中の2つのCERTのペイロードを備えた装置答え、1、TrE_CERTのためにDev_CERTを使用し1。この場合、TrE_CERTが確認され、確認データがPVEによって評価されるまで、SeGWは、Dev_CERTの立証を延期する。その後、認証は進む。答えが単にDev_CERTを含んでいた場合、SeGWはAuVに落ちる。

それぞれのIDが実践理性には異なる場合、Dev_CERTとTrE_CERTの相違は有利であろう。例えば、オペレーターはネットワーク・アドレスを割り当てたであろう、例えば、装置に、IPアドレスのようにそれは、直接IPSecトンネルを建造するDev_CERTによって確証する。あるタイプのネットワーク・アドレスはTrE_CERTに適さないであろう。したがって、2つのIDは装置に役立つであろう。それは、TrE_CERTに基づいた、上演できるPVMおよび補助の認証の適用により、Dev_CERTの交換として役立つ、SeGW/PVEインフラストラクチャーの一層のタスクであろう。

IKE認証メッセージは、任意のタイプのペイロードのどんな数も運ぶであろう。すべてのペイロードのヘッダーでは、それは「次のペイロード型」フィールドを含んでいるであろう。したがって、一続きの(全体の)ペイロードは1つのISAKMPメッセージの中で送られるであろう。これは最初のIKE会話のプロセス2の1つ以上のISAKMPメッセージのペイロード・フィールドに証明書を分けるために使用されてもよい。装置1005、とSeGW 1010、およびTrEおよび装置認証のための証明書を完全に分離するIKE会話を使用するPVE 1015の間の例プロセス1000は、図10に示す。メッセージを含むこと(TrE_Cert、VAL_DAT)は装置1005からSeGW 1010(1)まで送られる。SeGW 1010は抽出されたTrE証明書(TrE_Cert(2))を確認する。TrE_Certが成功裡に確認される場合、SeGW 1010はPVE 1015(3)に、validateデータ列(VAL_DAT)を送る。PVE 1015は、SeGW 1015(5)への装置1005(4)および信号成功を有効にする。SeGW 1015は装置1005(6)に、証明リクエスト(CERTREQ)を送る。証明リクエストに応じて、装置1005は少なくとも装置証明(Sig_Dev(Dev_ID)、Dev_Cert)を送る、SeGW 1010(7)に。SeGW 1010はシグ(Dev_ID)(8)を確認する。立証が成功する場合、装置証明(Dev_Cert)は装置が知られるかどうかで答えるAAAのインフラストラクチャーに送られる。この具体化に従って、有効にすると期待することができる装置だけが、TrE_CERTによって証明された同一性と共に、TrEによって署名された確認データを送信することによって、装置認証に認められる。これはSeGWの後ろのネットワーク要素に拡張保護を供給し、サービス強制停止攻撃を緩和するのを支援する。

別の例において、補足のデータのためのTLS握手メッセージは、TLSに対する拡張を定義する(こんにちは)手-メッセージを振る、それは送る適用に特定のデータを与える、のように、TLS握手でのPVMからの確認メッセージ。supplemental_dataは、TLSプロトコルによってではなくPVE確認エンジンのような適用によって使用されてもよい。単一のsupplemental_data握手メッセージが許可されているであろう。しかし、1つ以上を受け取ることは失敗として扱われるであろう。夢中になったデータのタイプおよびフォーマットはSupplementalDataTypeとして指定されるかもしれないし、送り手とレシーバーの両方に知られているであろう。

変化では、ダブルハンドシェークは行なわれ、それにより、SupplementalData握手メッセージに入れて運ばれた、上演できるPVMデータのために保護を提供できる。さらに、それは、一方のパーティーがSupplementalData情報を提供する前にパーティーが相互に確証されることを保証できる。

新しいSupplementalDataTypeは上演できるPVM確認メッセージを伝えると定義されることができる。その後、H(e)NBは、SeGWを備えた相互認証のための最初のTLS握手に従事する。その後、第2の握手は最初のTLSのセッションを使用して、保護されることができる。また、確認データはSeGWにSupplementalData分野で送られる。

別の変化では、確認データは最初の握手メッセージ中の補足のデータを送ることにより、2ではなく1つの握手交換に送られるであろう。確認接続に関して、TLSセッション・チケットに確認結果を格納するために、サーバがセッションを再開し、かつクライアントごとのセッション状態を維持する、クライアントへのセッション・チケットを出すことを可能にするTLS拡張は、TLSセッション・チケット拡張を使用して、SeGWによって確認の中で使用されてもよい。

そのようなセッション・チケットはPVMの中でプラットフォーム管理に使用されてもよい。確認が失敗したコンポーネントのあるリストで失敗する場合、SeGWはPVEからこの通知を受け取り、セッション・チケットを生成する。チケットは、128ビットのAESの対称鍵(それはH(e)NBに発表されない)を使用して、暗号化する。また、さらに、チケットはハッシュに基づいたメッセージ確認コード(HMAC)によって保護された完全である。したがって、それはH(e)NBによって変更することができない。また、H(e)NBによって示される場合、それは他のネットワーク実体によって認識されることができる。その後、TrEは安全にチケットを格納し、新しいTLSセッションにそれをプラットフォーム管理に使用できる、なしで、再び確認データを送らなければならずに、例えば、SeGWは、さらにセッション・チケットの一生を決めるであろう。

その後、AESチケット暗号鍵は一層の使用のためのT_PVMに含まれているかもしれないし、あるいは他の実体に直接渡されることができる。キーおよび例えばチケット・タイムスタンプ、また、詳細な確認結果はそのときできる、PVEからHMSへ転送されました。TLSセッション・チケットを使用して、H(e)NBは、直接プラットフォーム管理のための安全な接続を確立できる。これは、プラットフォーム管理タスクを上へ折よく続くH(e)NBに依存できる。また、チケットの前にHMSと連絡をとることは終了する。

セッション・チケットで確立された接続を使用して、H(e)NBがHMSで改善を終えたところで、その後、セッション・チケットは再確認に使用されてもよい。第一歩は、古いチケットを使用して、H(e)NBからSeGWまで新しいTLS接続を確立することであろう。
その後、SeGWはそれをコントロールできる、このチケットは、HMSで実際に管理サイクルを終えたH(e)NBから来る。それは好転し、チケット・データを終わった管理の後にHMSから返されたT_PVMと比較できる。正確なT_PVMが見つかる場合、TLSチケットを使用する再確認の試みは例えば、TLSチケットをやり直しに使用することによりマウントされたサービス強制停止攻撃に対して保護するために認められるであろう。TLSチケットは再確認のために受理されることができる。それはHMSを備えた改善ステップが長くかかるかもしれないので、吐き出されたとそうでなければ考えられるでしょう。SeGWに型押しされたもの(時間)があるので、これはセキュリティの主要損害なしで行われるであろう、比較に利用可能なT_PVMである。

自律の確認(AuV)を備えたPVMの一例がここに記述する。AuVは、SeGWにどんな確認データも配達せず、このように装置の最初のネットワーク付属用の既存のプロトコルの変更を要求しない方法である。したがって、PVMシステムは装置の安全な操業開始に立証の結果に関して何でも学習する。ただ一つの装置 - 転送された具体的情報はDev_IDである。

AuVは、プラットフォーム確認の結果に基づいた装置を管理する可能性を制限する。特に、ネットワークに最初に確証しており、最新版の後に再確認用のAuVを行なっている装置を識別する真直ぐな方法はありません。装置管理は、それがAuVに基づく場合、装置状態の歴史を運ぶネットワーク中のデータベースを要求する。AuVに基づいた基本的な装置管理を少なくとも行なうのに有効かもしれない例方法がここに記述する。

AuVのみの有能な装置用のH(e)NB改善の一例がここに記述する。AuVのみの有能な装置は、ローカル装置完全立証が成功する場合および場合のみ、装置が装置認証手続きを行なうことを可能にする安全な操業開始を実行する。コンポーネントのうちのどれかがそれらの完全性チェックに失敗する場合、装置はその完全性チェックに失敗したことと見なされることができる。しかしながら、FBCイメージの使用によって、装置は、装置改善を促進するために指定のHMSと連絡をとるであろう。

一旦改善HMSへの接続が確立されれば、H(e)NBおよび(または)信頼された基準値の正常なコード・イメージが交換されることができる。改善プロセスの完成に際して、H(e)NBはリブートするべきである。また、完全性チェック・プロセスは改めてもう一度スタートするべきである。

1セットの前もって定義した必要条件が適所にある場合、PVMはFBCを使用できる。1つの例要求は、FBCが装置内に安全に格納されるということであろう。別の要求は、FBCが失敗した安全な操業開始の場合にはロードされ始められるかもしれないということであろう。しかし、別の要求は、指定のH(e)MSのアドレスがFBCイメージに安全に格納されるということである。まだ、別の要求は、FBCが指定のH(e)MSのもとへ遭難信号を送るかもしれないということであろう。そのような信号は装置IDを含んでいるであろう。また、メッセージは、FBCの一部として安全に格納されたキーによって保護された完全であろう。一層の例要求は、装置が完全性チェックに失敗しておりメンテナンスを要求する、と信号の受取上のH(e)MSが確認することができるかもしれないことであろう。しかし、別の要求は、十分なコードを促進するためにFBCが機能性を含むかもしれないということであろう、ネットワークによって始められて復興する。別の要求は、ネットワークによって始められたTRV(s)の置換を促進するために、FBCが機能性を含むかもしれないということであろう。

図１１Aおよび図１１Bは、FBCによって促進された装置改善が後続する完全立証の失敗のための例方法を示す。RoT 1100は遭難信号旗(1)をチェックする。フラグが明らかな場合、RoT 1100はTrE 1105(2)の完全をチェックする。フラグがセットされる場合、RoT 1100はFBC(3)をロードする。完全性チェックが成功する場合、RoT 1100はTrE 1105(4)をロードする。完全性チェックが失敗する場合、RoT 1100は遭難信号旗とリブートの(5)をセットする。一旦正常なコードがロードされれば、TrE 1105は正常なコード(6)の完全をチェックする。完全性チェックが成功する場合、TrE 1105は正常なコード・イメージ(7)をロードする。完全性チェックが失敗する場合、TrE 1105は遭難信号旗およびリブート(8)をセットする。RoTがFBCをロードしている場合、FBCはHMS(9)への改善のための遭難信号を送ることを始める。

AuVを備えた再確認および配置変更のための基礎方法の一例がここに記述する。AuVに、および潜在的にSeGWに転送されたプラットフォーム管理において使用可能なただ一つの個人情報、装置同一性である。したがって、1つの具体化は、信号するためにAuVの中でそれらを使用する装置に、多くの同一性を帰できる、1つの(有限数)構成要素の完全立証失敗のような状態の。別の具体化では、立証結果を示すためには任意の単一の装置に特有でないグループIDは使用されてもよい。管理同一性は安全な操業開始プロセスのステージによってグループ化されるでしょう。例えばステージ3bで失敗を示すためのDevM_ID3b、ステージ3aで失敗を示すためのDevM_ID3aおよびステージ2で失敗を示すためのDevM_ID2。ステージ1失敗はその時以来示すことができない、装置はコミュニケーション・キャパシティーを欠く。

AuV使用の場合用の別の例において、装置は、蓄えコードの失敗および実行に続く行動計画としてHMSに接続することを試みるであろう。

ステージ2の単一か複合成分の失敗は、装置が通信することができないだろうということを示唆しない。ステージはあるカテゴリーに属するコンポーネントのクラスとして理解する。ステージ2の最も本質的なコンポーネントがロードされる限り、装置はPVMシステムにその状態および失敗したコンポーネントを伝えることができるであろう。HMSによって養われて、装置上に政策マネージャーがいれば、これはそうであろう。それは、付属が可能な基準にフレームワークを提供する。

セキュリティについては、そうでなければ、攻撃者がからかう攻撃を行なうことにより管理プロセスを破壊してもよいので、DevM_IDnおよび関連する認証データ(例えば秘密鍵)はよく保護されるに違いない。管理IDが装置の大きなグループには同一であるので、これは危険な脅威である。1つのソリューションはこの情報だけを使用して、プラットフォーム管理プロセスをモデル化することであろう。最初の確認(それは未知の同一性のある装置の失敗を示す)を再確認に結び付けることは、一義的な装置用の管理プロセスの成功を示すべきである。これを決定論的にする様々な方法がある。1例において、装置が確証した後、管理同一性のうちの1つに、SeGWは、オリジナルのDev_IDに装置が確証しなければならない補充のプロトコルを実行する。別の方法中で、交換するある秘密によって、装置およびPVMシステム、また特にSeGW、管理セッションを確立する、最初の確認プロセスおよび第2を測ること、再確認(プロセス)。

補足の認証プロトコルの一例がここに記述する。装置とSeGWは、装置(装置はその中で管理同一性のうちの1つにDevM_IDnを確証した)を備えた最初の認証プロトコルを完成する。そこに、それは仮定する、それらは暗号化され確証されたコミュニケーション・セッションを確立する。その後、装置は、単にDev_IDのためにDev_IDと認証データを転送できる。例えば、署名されたメッセージおよび公開鍵証明書は、確立している安全なチャンネルによって転送されることができる。これは、他の誰も管理を要求する装置の同一性を知らないかもしれないし管理プロセスをからかうためにこの知識を使用しないかもしれないことを保証する、すなわち、再確認の前に装置を無効にするか、装置に扮する。

SeGWはPVEにDevM_IDとDev_IDを転送する。それは管理を必要としている装置のリストにそれを挿入する。その後、PVEは、DMSへの必要な装置管理アクションを例えば示す「ステージ2蓄えコードをインストールする。」DMSは、装置に、SeGWによって以前に確立されて、安全なチャンネル上の対応するコードをダウンロードする。正常なPVMでのように、その後、システムは装置の再確認を始める。

経営陣が成功する場合、装置は続いてそのオリジナルの方へAuVの中のDev_IDを確証する。これはPVEへのSeGWによって示す。この人は再確認リスト中のDev_IDを認識し、それを削除する。そうでなければ、装置は再び管理IDへ有効にできる。それはさらに認識され、政策に従って講じられた処置を促進できる。

管理セッション設立の一例がここに記述する。この具体化は、PVMが管理を単一の装置に特有にする点で別の具体化と異なる。管理セッションは装置とSeGWの間の通信プロトコルの中で確立されることができる。そのようなアプローチの影響は、装置同一性が匿名の確立により本質的にPVMシステムに知られていないままかもしれないということである。

実行された正常なプロトコル中のそのような執拗な秘密を確立する、プロトコルの能力は制限されているであろう。例えば、Diffie-ヘルマン(D-H)のような共通鍵設立プロトコルは、継ぎ目キー・コントロールと呼ばれる特性を満たする。それは確立しているキーが両方のパーティーに依存するほどのものである。すなわち、両方のパーティーはすべての実行の中の異なるキーに帰着して、プロトコルに任意の情報を挿入する(偽り)。多数の実行にまたがるセッションはそのようなプロトコルを使用して確立することができない。

このように、SeGWと装置は、挑戦レスポンスの使用により特別のプロトコル中の秘密を例えば確立しなければなりません。その挑戦は装置かSeGWのいずれかによって持ち出されることができる。また、レスポンスはそのようなものであるに違いない、第2の実行(再確認)での第2の答えは第一ラウンドの答えと同一である。重要でない具体化では、装置は、再確認中のSeGWから得られた目下をちょうど示す。また、SeGWはテーブルの中でそれを見上げる。目下はこのように匿名である。より多くの複雑な暗号のプロトコルが使用されてもよい。

その後、再確認は上記のように進むであろう。しかしながら、違いはこの中のそれである、異なる、SeGWと装置の間に再確認に属することが実行されたプロトコルの中で使用されてもよいので、SeGWは実践理性のために再確認する装置に関する情報を維持する。

H(e)NBのためのOMA装置管理(DM)に基づいたアーキテクチャーのための具体化がここに記述する。OMA DMは、オープンなモービル連合(OMA)装置管理(DM)作業グループおよびデータ同期(DS)作業グループによって共同で指定された装置管理プロトコルである。OMD DMは、電話またはPDAのような小さな足跡工事用機器のために開発されました。それは、設備およびDMサーバの間の広帯域のワイヤー・ライン接続の支援を欠き、単にUSBのような短距離輸送のインターネットを利用している接続あるいはGSM、CDMAあるいはWLANのようなRS232C(すなわち無線接続性)を支援する。しかしながら、それは、特にWTRUとしてさらに芯まで現われるH(e)NBのために、H(e)NBのための装置プロビジョニングおよび管理プロトコルのように有用であろう、CSGおよび非CSG WTRUへのbaeステーションとして現われる間のネットワーク、それはそれに接続する。

OMA DMは、初めての装置構成、許可する特徴あるいは不能にするフィーチュアを含むプロビジョニング、装置構成最新版、ソフトウェア改良および診断法報告のような使用の場合を支援するように意図され尋ねる。装置はすべてあるいはこれらの特徴の部分集合を任意にインプリメントできるが、OMA DMサーバ側はこれらの機能をすべて支援できる。

OMA明細は抑制された接続を備えた小さな足跡装置のための上記のリストされた特徴を支援するために最適化されることができる。さらに、それは、EAP-AKAのようなプロトコルの使用によってのように認証を使用して、統合セキュリティを支援する。

OMA DMはXML、あるいはより正確にSyncMLからの部分集合をデータ交換に使用する。これはstandardizeを提供するのに役立つであろう確認の目的で、ソフトウェア・モジュールのための属性あるいはH(e)NBのための機能性を定義し伝える有能であるが柔軟な方法。

装置管理は、DMサーバ(例えば装置用の管理する実体)と、管理されている装置のようなクライアントの間に起こる。OMA DMは、WAP、HTTPあるいはOBEXのようなトランスポート層あるいは同様の輸送を支援する。DMコミュニケーションは、通知か警告メッセージのいずれかを使用する、WAP押しあるいはSMSのようなどんな利用可能な方法も使用して、DMサーバによって非同期に始められる。一旦コミュニケーションがサーバとクライアントの間でセット・アップされれば、メッセージのシーケンスは与えられたDMタスクを終えるために交換することができる。

リクエストがDMサーバによって通常なされる場合、OMA DMコミュニケーションはリクエスト・レスポンス・プロトコルに基づきる。また、クライアントは応答メッセージで答えるであろう。特定のシーケンスにより交換されたどんなデータも意味して、両方ともサーバとクライアントは処理状態を把握する、後に生じるかもしれない、構築された-認証手続きで。

DMコミュニケーションがDMサーバによって始められるかもしれないので、DMの上のPVMのインプリメントは確認へのサーバ質問基づいたアプローチを要求できる。例えば、IKEv2を使用する装置認証手続きは使用されてもよい。それは装置によって始められるであろう。いくつかの異なるメッセージ・タイプは確認データのコンベアーと見なされることができる。例えば、それは失敗したソフトウェア・モジュールか装置機能性のリスト中で送られるであろう。別の例において、管理警告メッセージは装置からサーバに送信されることができる。あるいは、総括的な警告メッセージ(装置かサーバのいずれかからの少なくとも1つの管理警告メッセージの送信があった後、それは、単に装置からDMサーバに送信することができる)のユーザも考慮されることができる。警告メッセージを含むこれらのメッセージは、内容のために内容とメタデータを指定する際に柔軟性を提供するSyncMLフォーマットを使用できる。これは確認情報伝達に役立つであろう。DMはさらに分節から成るデータ転送を支援できる。最新版のサイズが大きいかもしれないところで、それはソフトウェア・アップデートに役立つであろう。

DMサーバはまさにその第1のDMコミュニケーションを始めなければならない、後のコミュニケーションは継続的なセッションを使用して、DMクライアントによって始められるであろう。DMクライアント(H(e)NBあるいはM2ME、例として)が、装置に始められた再確認あるいは装置に始められた確認メッセージ配信のような装置に始められたタスクに恐らく役立つインセッション・コミュニケーションを始めるそのような能力。

認証証明書中の確認の結合の例がここに記述する。認証証明書中の確認の結合は結合した確認および認証を考慮に入れて、それにより、装置の本物のIDを確認に自動的に結び付ける。その後、確認メッセージは補足分野に認証証明書に含まれている。例えば、IKEプロトコルを使用したところ、二者択一でNotifyペイロード分野にそのような立証データを埋め込んでいることができるであろう。

立証データが認証証明書の内部で保存される場合、装置構成が変わるごとに、新しい結合した認証/確認証明書が出されるに違いない。それがPVMの目的でDev_IDを確証するというチャージの中に実体であるので、SeGWによって証明書の生成をコントロールしなければなりません。これは少なくとも2つの方法で行われるであろう。最初に、SeGW、あるいは従属する実体はDMSから最新のClistを受け取った後に新しい証明書を生成できる。次に、装置は証明書自体を生成できる、SeGWとPVEにこれを送る、その後、それはそれに署名し、装置にそれを送る。

SeGWはある種類の成功した再確認の後にプロセス(一方の生成し、新しい証明書(すなわち装置によって生成された新しいものを認めること)を送)を終了できる。
これは、新しい配置が装置によって実際に到達することをPVMシステムに保証することである。

新しい証明書が装置構成変更で必要かもしれないので、このサイクルはCNと装置に3つの実体をすべて含んでいる。DMSは配置変更(例えばソフトウェアおよび(または)パラメーターの最新版)を引き起こし、政策データベースC_DBの中で新しい希望の状態を保存する。変更が装置に適用された後、再確認が生じなければならないでしょう。

例シナリオでは、装置は最新版を適用し、再確認を行ないる。新しいソフトウェアは使用する。しかし、再確認(特に成功した更新処理の)が完成するまで、新しい証明書は装置に展開することができない。この時に、装置は、実際の装置構成と一致しない古い証明書を備えた新しいソフトウェア配置を実行している。これを受けて、新しい証明書は装置への装置認証に提供する;最新版が適用されている場合および場合のみ、提供されました;。また、応用の最新版なしでは証明書を使用することができないことが保証する。

装置認証証明書取り消しの一例がここに記述する。装置認証中に、SeGWが装置認証のために装置から送られた装置証明書を無効にする必要があることを決める場合、SeGWは装置認証が証明書取り消しのために失敗したことを装置に示し、次に、ネットワークから装置を削除できる、ホワイトリストを維持した、あるいは、反対に、ネットワークはブラックリストを維持する。この表示の受取上の装置は、その証明書が無効にされており、その同一性がホワイトリストから取り除かれたか、反対に、ブラックリストに加えられたことを知っているであろう。その後、装置は、ネットワーク上の有効な実体としてそれ自体を再建する手続きを行なうであろう。

装置IDが無効の場合、SeGWは装置証明書を無効にすることができるか、あるいは装置証明書が終了する。あるいは、信頼された第三者オペレーターは、H(e)NB装置を出した実体を認可する。また、その関連する証明書は、証明書を無効にすることをネットワークに要求する。

証明書に基づいた確認基礎方法のための具体化がここに記述する。拘束力のある証明書は署名されたデータセットである。それは発行人、SHOあるいはそのSeGWによって署名する、あるいはこれらの証明書の管理の原因である従属する実体。証明書中の署名されたデータは少なくともDev_ID、認証と確認に使用された装置公開鍵、およびClistを含む。

この証明書はSeGWに結合した確認および認証メッセージの中で送られるであろう。後者は、認証と確認用のその秘密鍵を備えた装置によって署名されたメッセージ(どれがあるかに分かれる)である。メッセージは、時間のような他のデータを含んでいるであろう型押しをする、またはやり直し保護用の目下。SeGWは、メッセージと証明書の署名をチェックし、通常通り確認を続ける。

例証明書交換方法がここに記述する。一般に、2つの変形が適用されることができる。これらはpreとポストであると確認する証明書交換。それらは再確認が古いものあるいは新しい証明書を使用するかどうかにおいて異なる。両方の変形は、必須ステージがすべて原子力によって行なわれることを保証する、それはそれである、それらはすべて完成する、あるいはそれらの無。スタートする条件は、装置が古い証明書を備えた古い配置を実行する場所である。また、終了する条件は新しい装置構成および新しい装置証明書である。
認証証明書およびRIM証明書は、1人のオペレーターにそれらを結び付けるのではなく多くのネットワーク上の装置の使用のために許可する、独立したTTPあるいはメーカーによって作成され、管理され、扱われる必要があるであろう。あるいは、新しい装置証明書は装置管理(DM)のために例えばオープンなモバイル連合(OMA)によってアドレスされることができる。それは証明書を含めるために拡張されることができる。

preの中で-証明書交換方法、最新版は新しい証明書をこのように含んでいる、証明書は最新版の完成に先立って装置へもたらする。最新版を適用した後に、装置は再確認する、新しい証明書の使用。装置はCNの中で適切な記憶装置およびデータ構造を使用して、「進行中の最新版」として目立たさせられる。認証データベースの中で例えばフラグをセットすること。別の方法は確認トークンT_PVMを使用することである。

1つの例前証明書交換流はここに記述する。DMSは移る、更新された、または標準PVMでのような装置にコンポーネントを変更する。その後、DMSはSeGWに新しいClistを送る。DMSはT_PVMをSeGWへ渡する。これによって、SeGW(したがってPVMシステム)は、装置からそれが新しい配置を備えた再確認を予期する州に入る。SeGWは必要な情報(Clist、Dev_Id、装置公開鍵他)を収集し、新しい装置証明書を生成する。SeGWは必要な情報(Clist、Dev_Id、装置公開鍵他)を収集し、新しい装置証明書を生成する。その後、SeGWは装置へ新しい証明書を送り、次に、装置でコミュニケーション・セッションを閉じる。

SeGWは、今DMSから得られたT_PVMを所有しており、装置から再確認を期待するためにこのように知っている。それは内部再確認リスト中であるべてのそのような装置用にT_PVMを格納する。装置が最新版および新しい証明書、次に下記プロセスを正確にインストールすると仮定することは当てはまる。装置は確認メッセージ中の新しい証明書を送って、再確認を始める。SeGWは署名されたデータおよび装置証明書の確認により装置を確証する。SeGWは、再確認リスト中のT_PVMを調べる。再確認は起こる。そこではPVMシステム状態は、前の確認(また、新しいものを生成せずに)からのT_PVMの使用により維持する。これおよび前のステップはPVEでではなくSeGWで起こる。また、そうでなければ、SeGWは自動的に新しいトークンを生成するでしょう。したがって、再確認リストのメンテナンスはSeGWのために行なわれる。

標準PVM(再発する最新版失敗および他のパターンの不規則な振る舞いを検知するのに有用)でのように、再確認の多くの巡回に関してT_PVMを連続的に使用することはそうである。

一層の具体化では、TrEには装置へHMSがその後、安全で信頼できるプロセスで適用される最新版を送ることを可能にする信頼されたアップデート・サービスがある。TrEの中の最新版サービスの完全を保証するために恐らく依存された安全な操業開始。HMSが新しい最新版を展開させる場合、それは新しい最新の装置構成を含んでいるSeGWにトークンを送るであろう。その後、SeGWは、装置のための新しい認証証明書を作成し、HMSに送られるトークンにそれを追加できる。HMSは装置の最新版サービス用の最新版データと一緒に新しい証明書を含んでいる。このパッケージはTrEのために暗号化され、HMSによって署名されることができる。信頼されたアップデート・サービスは最新版パッケージを受け取り、署名を確認し、データを解読し、最新版を適用し、安全な記憶装置に新しい証明書を格納する。その後、TrEは、HMSへの成功した最新版を示す。信頼されたアップデート・サービスが安全な操業開始までに保護されるので、更新処理は信頼されることができる。その結果、再確認は必要ではありません。最新版のタイプによって、リブートは必要であろう。この場合、装置は確証できる、SeGWの新しい証明書で。したがって、HMSは、SeGWに生じる再確認に関して通知されることを確かめるに違いない。

別の具体化の中で、信頼された最新版サービスが装置で利用可能でない場合、証明書が最新版の成功した設置に結び付けられるキーで暗号化されるように、新しい証明書に新しいソフトウェア・アップデートが供給されることができる。この方法とその含意はより多くの考察を必要とできる。

ポスト証明書交換方法では、最新版は、新しい装置構成を含んでいる新しい証明書を含んでいないであろう。装置は古い証明書を使用し、再確認を行ないる。成功した再確認の後、CNは新しい証明書を活性化し、装置へ新しい証明書を送る。装置が安全な操業開始を行なうために新しい配置を持たないかもしれないので、それにまだ新しい証明書がありませんが、新しい配置は装置へ送られる。

オペレーターRIMの一例がここに記述する遮蔽。無線地域網(WAN)管理プロトコルは装置の遠隔の管理に使用されてもよい。図12は、発行人から装置までパッケージ・ソフトのダウンロードを考慮に入れる、署名されたメッセージ・フォーマット1200の例図形を示す。そのフォーマットは、ファームアップあるいは配置パッケージのような1ファイル以上が単一の署名されたパッケージの中で送られることを可能にする。受信装置は出所を確証することができ、内容をインストールする指示をすべて含んでいる。

ヘッダー1205はフォーマット・バージョン、および命令リストおよびペイロード・コンポーネントの長さを含んでいるであろう。命令リスト1210は、パッケージに含まれていたファイルをインストールするために実行されるかもしれない指示のシーケンスを含んでいる。署名フィールド1215は、その署名されたメッセージ・データがヘッダーと命令リストから成るデジタル署名を含んでいるであろう。署名されたメッセージ・データはパッケージ・ヘッダーおよび命令リストだけを含んでいるが、ペイロード・ファイル1220を指すコマンドがすべてファイル内容のハッシュを含んでいるので、署名は全パッケージの完全を保証する。

オペレーターRIM遮蔽の場合には、DMSが命令リストに署名し、メッセージのペイロードにパッケージ・ソフトおよびそれぞれのRIMを含んでいる。その後、装置のTrEは、DMSを確認するために公開鍵を使用する」署名。この公開鍵は製造か配備時にTrEに利用可能になるかもしれないか、あるいはオペレーターによってCAを信頼する。公開鍵を確認するために必要なルート証明書はすべて、TrEに安全に格納されることができる。
その後、命令リストは、ソフトウェアをインストールするコマンドを含んでいる、および装置の中へのRIM食物摂取のために。これは、オペレーターが装置の上にソフトウェアおよびRIMインストレーション・プロセスに対する十分なコントロールをする、有効な方法を提供する。装置へのRIMcsの明示的な輸送はこのインプリメンテーション変形に生じないであろう。

改善用の別のコード・ベースの使用のための例がここに記述する。失敗から生じる問題、安全、総括的なPVM素子モデル中のステージ2失敗のようなTrEを越えて開始する、TrEが正常な実行スペースにロードされた改善コンポーネントまで信頼を延長するとは期待されないかもしれないということである。したがって、改善を始めるために、FBCは起動されることができるが、少なくとも最も重大な機能性暗号学および改善プロトコル・スタックのためにTrEの内部で走る必要があるであろう。

ある状況で、ここでFBCキャリアーと呼ばれて、外部の安全な出所からFBCを得ることは意味をなすであろう。これは、部分的に外にあるプロセスによって行われるであろうバンドの、またH(e)NB装置にスマート・カードを挿入するような人間の介在を要求してもよい。このプロシージャは、FBCキャリアー(それは安全にFBCコードを格納し保護する)として、あるいは単純で、緩和するべき改善開始プロシージャでの人間の介在を明示的に要求することにより別の安全な要素(スマート・カード)の使用によって増強されたセキュリティを提供することができるし、サービス強制停止攻撃を自動化し、HPからの勤勉として契約上必要であろう。外部キャリアーFBCは、装置を単純で、安くしておく手段および薄いTrEであろう。外部キャリアーFBCは達できる、実行可能、改善のために、およびさらに必要な秘密をすべて含むFBCに2進法、必要だった時FBCに安全な実行環境を供給してもよい。個別のFBCキャリアーの使用は、装置がある状況で適用可能ではないであろう、の中で、1つの、遠隔か、位置に到着するのに困難な。ここで記述された3つの実体間の信頼設立のプロセスは、以前に記述された様々な「過渡的な信頼」プロシージャに似ている。

下記手続きは、それ自身の処理装置を備えた、UICC、スマート・カードあるいは安全なメモリーカードのような外部FBCキャリアーで当てはまるであろう。TrEは、認可され確証されたFBCコードにロードされることを要求する、依存するパーティーである。
他方では、改善のための信任状が保護され続ける限り、無認可の団体にFBCコードを知らせることは危険のより少ない数量である。バンド外プロセスがそうであるので、FBCキャリアーへのTrEの認証は問題のより少ない数量である、行なう、その中でTrEと装置が実際に完全にはありません、信じました。そのため、キャリアーは、装置にHMSアクセスに使用された信任状を知らせるべきではありません。FCBを明らかにすることは必要かもしれないしそれほど批判的ではないであろう。

したがって、次の認可かコミュニケーション・シーケンスは適用されることができる。
バンド外介在ステップあるいは人間の介在ステップは特殊用途の場合には単に実例となり、例えば、FBCキャリアーがH(e)NBに埋め込まれている場合、他の変化で自動化されるかもしれないし、統合されることができる。そのコミュニケーションはそのような蓄えコード基礎手続きで非常に単純であろう。したがって、認証と認可は単一のプロトコル・ステップで組み合わせられるであろう。

最初に、ステージ1、開始する、成功する、また2を行なう、開始する、失敗する。TrEは「FBCを待つ」ことへ状態およびフラッシュLEDを小屋に入れるか、あるいは失敗の他の同様の指標を提供する。ユーザ/HPはFBCキャリアーを挿入する。この具体化では、FBCキャリアー(例えばホスティング・パーティー・モジュール(HPM)のようなスマート・カード)は、FBCキャリアー存在を示すために特別の物理インターフェースを使用して、TrEにそれ自体を認可し、かつ、または認可秘密(例えばOTP、署名された目下)を提出する。暗号化され完全保護されたコミュニケーション・セッションであるセキュリティ協会(SA)は、TrEとFBCの間で設立する。その後、FBCは、TrEあるいはFBCキャリアーによって提供されるかもしれない、安全な環境あるいは両方の環境の能力の任意のコンビネーションにロードする。その後、FBCは完全であろう。もし望まれればチェックし、次に、ダウンロードされ、始められる。

安全なスタートの後、FBCは、キャリアーにその成功したロードを示すために秘密を使用し、TrE(FBC)およびキャリアーの間の新鮮なSAを作成する。改善のための信任状はキャリアーに残る。しかし、FBCは、HMS発見用データを含んでいる。FBCはHMSと連絡をとる。スマート・カードとHMSの間の末端間SAは、TrE(FBC)に利用不可能なままである、スマート・カードに保護された信任状を全面的に使用して確立する。HMSは、有効なTrE(FBC)が改善を要求していることを今知っている。スマート・カードはTrE(FBC)にコミュニケーション・セッションを渡する。また、TrE(FBC)はHMSにそのIDを示す。HMSは改善手順を始める。この種の接続が多くの装置に当てはまるかもしれないし、したがって、違反が破滅的かもしれないので、認可秘密はよく保護されることができる。認可をインプリメントする1つの方法は、取り分所有権手続きで作成されるように160ビットのHWに保護された値のようなTPMに保護された認可秘密を使用することである。インプリメンテーションによって、FBCは、FBCキャリアーから直接始められるであろう。その後、それは安全かつ着実な実行環境を提供しなければなりません。この場合、危険にさらされたTrEさえ恐らく交換されることができる。1例は、FBCを独立して実行するために安全な要素、超小型演算処理装置およびメモリからFBCキャリアーが成る場所であろう。FBCキャリアーは共通のインターフェース(例えばUSB、JTAG)経由で装置に付けられ確証できる、装置の内部のコンポーネントに直接、および次に、TrEの危険にさらされたコンポーネントおよび恐らく部分を交換する別の変形の中で、署名されたコード・イメージが使用される場合、FBC搬送装置は署名を含むイメージを交換できる。

TrEが正確にいくつかの場合でのFBCをロードし実行するのには完全に信頼できないかもしれないし、FBCキャリアーにロードするFBCをほとんどの場合有効にすることができないかもしれないので、ある警備強化はFBCキャリアーが遠隔のコード基礎実行に対する信用を確立しなければならないそのように含まれているであろう。例えば、FBCキャリアーは生成できる、1つの、一度だけ-秘密、また混乱方法を使用して、FBCへそれを埋め込む。あるいは、FBCと一緒に、あるいは直接、FBCの後、キャリアーは別の認可秘密を送信できる。それは成功裡に始められたFBCによってのみ認識され使用されることができる。この秘密は、TrE(コミュニケーションの非常に次のステップのコミュニケーション秘密)の中のある保護された場所から得るべき、成功裡に始められたFBCによって使用する。

例が、内部並列のコード基礎を蓄えコードに使用するためにここに記述する。
内部並列のコード基礎はトリガー機構、および改善を促進するために必要とされる蓄えコード・ベースを含むであろう。例えば、H(e)NBは2つのコード・イメージ、1つの正規モードおよび1つの蓄えコード・イメージ(FBC)を含んでいるであろう。正規モード、もたらす、AuVとSAVの両方のためにステージ的にインプリメントされることができる。
ステージ1では、ROMの中のRoTはTrEを確認する。TrEが有効な場合、次のステージコンポーネントがチェックされることができる。その後のいずれかのコンポーネントがその完全性チェックに失敗する場合、コードはTrEコードのスタートに負荷を軽くする。この時に、TrEは、改善(コード)のような、蓄えをチェックし始めるであろう。蓄えコードがそれをロードし始めることができることをチェックする完全を通る場合。蓄えコードは、HMSとの接続を確立するように装置管理(DM)コードのある最小のセットを含んでいるであろう。一旦HMSへの接続が確立されれば、失敗したモジュールは識別されることができる。また、最新版はHNBに送られる。改善プロセス、恐らくリブートされたH(e)NB、および改めてもう一度始められた確認プロセスの完成で。蓄えコード・サイズはHMSとのコミュニケーションを促進するために小さくしておくことができる。トリガー機構の必要はないであろう、あるいは「コードを回転することができるので登録する、後退する」TrEに、および次に、蓄えコードでロードした。

付加的な異なる「ハイブリッド(内部/外部の)コード・ベース」はここに記述する。FBCは、上に記述された並列のコード基礎の場合でのような装置の内部で格納されることができる。しかし、FBCは暗号化する。また、完全は装置上で保護する。TrEはそれ自身FBCをそうでなければ解読するために使用することができない、危険にさらされたTrEは、FBC自体の妥協に結びつくであろう。ハイブリッド解決は、スマート・カードかUICCのような外部の安全な要素上にFBCイメージのために解読と立証のキーを格納する。スタート失敗の場合には、TrEがこの失敗を示す。また、ユーザ/HPは、装置に認証トークン(つまりスマート・カード)を挿入することを要求する。素子特性によって、2つのオプションが利用可能である。優先買受権では、認証トークンは単に重要な資料を格納し、TrEを備えた相互認証を行ないる、どの中で、あるいは、その後にTrEは必要な重要な資料を受け取る。TrEは、FBCの完全性チェックおよび解読を行ない、次に、FBCをロードし、始める。別のオプションでは、それが装置上に格納されたFBCを自主的に確認し解読することができるし、次に、それを実行してもよいという意味で、認証トークンは改善する、装置の資源だけ(例えば、安全な実行環境を提供するためにTrEの部分を使用して)の使用、あるいはFBCが実行されるかもしれない場合に、認証トークン自体の内部の安全な実行環境を提供することによって。異なるこれ、使用にFBC記憶装置用の装置のより大きな記憶容量を与える、補足外部のセキュリティと安全な要素を組み合わせる。

具体化が、内部連続するコード基礎の使用のためにここに記述する。装置管理プロトコルはプロトコルおよびソフトウェア構成を遠隔装置にインストールし変更するコマンドを定義することができるし、「リブート」コマンドを含んでいるであろう。それは、装置についての概念を含んでいないであろう、送ること、1つの「改善-必要だった」メッセージ。しかしながら、SAVおよび装置管理プロトコルのような確認の結果を組み合わせると、HMSは、再装置を始めるかあるいはリセットするためにソフトウエアコンポーネントに、装置管理プロトコルを使用し、次に、再確認のためのリブート・コマンドを出すことができる。

あるいは、FBCは、正常なコードの残りだけを残して、正常なコードの一部を削除するかアンインストールし、再確認が後続するリブートを始めることができるかもしれないこと。
FBCは、削除されるかアンインストールされる必要のある正常なコードのリストがあらかじめ供給されているであろう。あるいは、FBCは、スマート・カード(例えばHPM)のような外部の安全な要素からそのようなリストを得るであろう。あるいは、FBCは、H(e)MSのようなネットワークベースの実体からそのようなリストを得るであろう。

メカニズム(この)が安全に作動するために、それは、次の特性を含んでいるかもしれない装置の上に信頼された適用を持っているであろう:完全は保護する;装置に安全に格納されました;失敗した安全な操業開始の場合には始められることが有能;HMSへの(安全)接続を確立する;HMSからのソフトウェアおよびコマンド上の署名を確認するのに有能;
ソフトウェアを装置にインストールする/インストール解除するのに有能;および装置が改善を必要とすると報告するのに有能。

別および恐らく余分のコード基礎イメージはこの適用を主催するために使用されてもよい。記述に続き必要条件を厳守することは述べました、第2のコード・ベースはいくらかもたらする、付加的で・余分の、装置の中へのコード。このコード・ベースによって提供される特徴はすべて、装置中の正常で成功した安全な操業開始の場合には必要であろう。
第2のコード・ベースのすべての特徴は主要なコード・ベースに存在できる。

別の変化は並列の設計を逐次計画に取り替えることでしょう。これは次のシーケンスを含んでいるであろう。RoTは成功で、TrEを確認し始める。その後、TrEは成功で、改善コードを確認する。TrEは成功で、残りのソフトウエアコンポーネントを確認する。
そうでなければ、TrEは失敗したモジュールを格納し、装置が必要とするフラグをセットする、改善。その後、TrEは、装置のリブートを引き起こする。リブートに際して、改善コードの立証の後、TrEは改善コードにコントロールを伝えて、失敗したモジュールのリストを公表する。その後、改善コードはこのリストとコンタクトのHMSを装置改善プロセスに使用できる。

セキュリティ・ポリシー属性を使用するSAVのための例がここに記述する。モジュールが内部完全性チェックに失敗したPVEへの通知はすべての形のためのすべての南西のモジュールの標準化されたリストおよびH(e)NBのモデルを作成することを含んでいるであろう。セキュリティポリシー・アトリビュート(SPA)の標準化されたリストを生産することは受理可能腕ある。SPAは、特定の南西のモジュールがその完全性チェックに失敗する場合に得られるために、アクションは何かPVEに伝える政策であろう。
PVEは失敗したモジュールに関してほかにものは何も知る必要はありません。

SPAのコードは標準化されるかもしれないし、次のコードを含んでいるであろう。
「00」モジュール失敗は、ネットワーク・アクセスを否定しなければならないことを示すであろう。このタイプのすべてのモジュールはステージ2にあるであろう。しかし、これをステージ3モジュールの中でコード化するすることは柔軟性を考慮に入れる。「01」モジュール失敗は許可する一時的ネットワーク・アクセスを示すであろう。改善についてのセクションに述べられているように、この一時的ネットワーク・アクセスは改善を行なう装置によって使用されてもよい、例えば、失敗したSWモジュールの修理用の改善センターおよびそれの使用は、ネットワークを止めるであろう、アクセスする、改善が成功しない場合。「02」モジュール失敗は許可するネットワーク・アクセスを示すであろう。これは失敗したSWモジュールの修理のために改善センターを指すかもしれないし、改善が成功しない場合、ネットワーク・アクセスを継続できる。「03」モジュール失敗は許可するネットワーク・アクセスを示すであろう。それは失敗したSWモジュールを削除することができる/不能にすることができる/隔離することができるし、アクションが成功しない場合、ネットワーク・アクセスを止めてもよい。「04」モジュール失敗は許可するネットワーク・アクセスを示すであろう。それは失敗したSWモジュールを削除することができる/不能にすることができる/隔離することができるし、アクションが成功しない場合、ネットワーク・アクセスを継続してもよい。「05」モジュール失敗は許可するネットワーク・アクセスを示すかもしれないし、南西の完全失敗を無視できる。「06」は他の失敗を示すであろう。

単一のSPAはH(e)NBの中で各ステージ3 SWモジュールに関係しているであろう。その後、実際の南西のモジュール識別子はH(e)NBの各形およびモデルに所有者であろう。SAVでは、H(e)NBは、既にSeGWにH(e)NB_IDを送る。H(e)NBの形、モデルおよび通し番号を識別するために、それはネットワークによって使用されてもよい。各ステージ3保全のために-チェック失敗、Notifyペイロードの中へのH(e)NB場所、所有者の南西のモジュールIDおよび対応するSPA。私たちの既存のSAVスキームごとでのように、ペイロードはPVEへ転送する。

PVEはSPAを検査する。次に、何らかのSPA=OOがある場合、SeGWはH(e)NBへのアクセスを与えることを認められません。何らかのSPAの=01か02がある場合、改善プロセスは起きる。PVEはH(e)NB_IDおよび南西のモジュールIDを送る。改善センターは、それがH(e)NBに正確な最新版をダウンロードすることができるように、所有者の南西のモジュールIDを相互参照するためにH(e)NB_IDを使用できる。

何らかのSPAの=03か04がある場合、PVEはSeGWに適切な指示を送るであろう。何らかのSPA=05がある場合、H(e)MS(すなわち他のネットワーク構成要素)は経営目的のためにデータを格納してもよい。

任意に、いくらかがあるであろう、再けとばす/再有効にすること、また非00 SPAのために含まれて通信するACK。SPA=00は、ネットワークに今悪いH(e)NBに関するある情報がある以外は、AuVと同じ最終結果を持っている。したがって、ある管理活動が得られるであろう。任意に、PVEは、それらの完全性チェックを通るモジュールのことを伝えられないであろう。

FBCが基礎的なコミュニケーションを支援する場合、PVMはステージ2モジュールの失敗を含めるために拡張できる。SPAは南西のモジュールIDを含んでいるオブジェクトの一部であろう。それらはTrEに格納されなければならないでしょう。それらは南西のモジュールの一部として格納されないであろう。また、それらは、南西のモジュールの失敗した完全性チェックの場合には信頼されないであろう。

危険に基づいて、南西のものの型式承認プロセスの一部が積み重ねるとともに、個々の南西のモジュールに割り当てられたSPAは、各H(e)NBサプライヤーと意見が一致できる - 評価プロセス。一旦サプライヤーがオペレーターとの関係を築いたならば、その後、新しい南西のモジュールにSPAを割り当てることは単純であろう。確立しているサプライヤーは前の成功した承認に基づいた適切なSPAを割り当てると期待されることができる。

H(e)NB構造の南西の構造の標準化の必要を減少させるために、ブロックが完全性チェックの点から、および再度調停するものの点から最小の原子の塊あるいは定量として定義される場合、H(e)NBの南西の構造はコードのブロックの点から定義されることができる。個々のブロック関数は定義されないであろう。例えば、ステージ3 SWのすべて、恐らく、完全をチェックする見解からの単滑車。あるいは、ブロックは実際の南西の適用、どころか適用内の敏感なオブジェクト上に1:1を写像できる。SPAは南西のブロックに適用されることができる。改善センターが01または02のSPAのために起動される場合、それは必要なブロックをダウンロードする。ブロックのIDはベンダーと関係のあるであろう。また、アーキテクチャーは標準化されないであろう

SPAが装置確認の中で使用されれば、SPAが南西の確認者へのTrEおよび境界に安全に格納されることができる。例えば、05-SPAが00-SPAと別のコンポーネントのために再び行われないかもしれないことが保証されることができる。したがって、PVEは、H(e)NBの中のロードしたコンポーネントに受信SPAが実際に属することを確認することができるであろう。

1番目で始められる登録プロセス、最初のネットワーク、装置に接続する、C_DBへ装置からSPAを安全に転送し、かつ将来の使用のためにそれらを格納するために使用されることができる。その後、装置は、失敗したコンポーネントのSW_IDsを報告することができました。また、PVEはローカル・データベースから対応するSPAの政策的措置を検索することができる。これは低い帯域幅の接続している装置に役立つであろう。

具体化が、SPAのグループ化のためにここに記述する。SPAがTrEの上にローカルに格納されれば、TrEはすべてを検査できる、コードとそれらのSPAに失敗した、プロセス、それら、またもっと要約されたステージ完全性チェックを送る。失敗したモジュールおよびそれらのSPAは、テーブル1に示されるものを含んでいるであろう。

TrEはデータを処理できる(として、テーブル2に示されたこと)。

異なる程度に失敗したモジュールのリスト(それはSPAによって示される)は、すべてのSPAの価値の代わりに送られるであろう。

したがって、Notifyメッセージ中のいくつかのビットブロックが定義される場合、テーブル3に示されるような写像を持っているであろう。

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

図13は、遠隔の証言によって確認の方法の例の図形を示す。確認実体1300はSMLおよび署名されたPCR価値を受け取る。SMLは、それぞれのPCRへ拡張されたすべてのファイルの順序付きリストを含んでいる。確認実体1300は、SMLの中のすべてのエントリー用の次のステップを行ないる。確認実体1300は、知られていた(よいと)ハッシュ値(1)のローカル・データベース1310に与えられたファイル名が存在するかどうか疑いる。
このデータベース1310はファイル名、および信頼できると考えられるバイナリーのRIM(ハッシュのような)をすべて含んでいる。データベースでファイル名を見つけることができない場合、それは信頼できない(2)と考えられる。確認実体1300はRIMをSML(3)からの報告された測定値と比較できる。それらが一致しない場合、プラットフォーム上の2進法のものは変更されました(ユーザ、マルウェアあるいは他の実体によって)。この場合、プラットフォームは信頼された(4)でありえません。確認実体1300は仮想PCR(5)上でextendオペレーションを行なうであろう。本質的に、確認実体はプラットフォームが実行と測定の間に行なったのと非常に同じステップを行ないる。このプロセスの終わりに、仮想PCRの値はプラットフォーム(6)からの報告された値と比較する。それらが一致しない場合、SMLは、(例えば、SMLからのラインが削除されるが、ハッシュ値がPCRまで延長されたならば、仮想PCRおよび報告されたPCRはmi一致するでしょう)干渉されました。その後、プラットフォームは信頼できない(7)と考えられる。

ロードしたコンポーネントのリストを報告するための変形として、として、Clistの中で、あるいはF-SAVの場合の失敗したモジュールのリストの報告のために、あるいは測定の報告のために、モジュール中の階層関係は報告された要素の数を減らすために開発されるかもしれない、また潜在必要条件のために。例配置は図14に示す。そのような配置は、自動的にモジュールへの自然律を引き起こする。可能なモジュールの数がOS、プロトコル・スタック、管理モジュールおよび他のモジュールにより非常に高いかもしれないので、モジュールの数は大きいであろう。

成功した安全な操業開始の後、PVEまたはSeGWは、装置への成功した操業開始を示す証明書を出すに違いない。そのような証明書は、TrE_ID、バージョン番号(ソフトウェア、ハードウェアの)あるいはソフトウェアのハッシュのような情報要素および安全なタイムスタンプ(装置の位置、モジュールのハッシュ、モジュールのClistおよび他の関連情報)を含むでしょう。

そのような証明書は失敗した操業開始に役立つであろう。この場合、情報はPVEに送られるであろう。また、PVEは、報告されたバージョン番号が正確であることを真正に確認できる。PVEが証明書を出した人であるので、したがって、それは適切なステップを取るであろう。違いは、PVEが装置が成功した操業開始ステータスを示す時でのような信頼のために装置に同じほどには依存しないということである。しかしながら、PVEが少なくともそれを信頼することができる場合、これは単に働くであろう、その失敗した操業開始ケースに関する装置からそれが得るあらゆる情報。したがって、装置はこの場合設計されることができる、その結果、その機能性は、失敗した操業開始の状態を検知する、およびPVEへのそれがまだ完全であるのと同じステータスを報告するために、また妥協しない。

証明書は、さらに成功した操業開始に役立つであろう。この場合、後の安全な操業開始プロセスでは、装置は、それにPVEまたはポインターによって出された測定あるいは測定および最後の安全な新進の証明書のハッシュ値を送るであろう。そうする際に、PVEは、悪意のある変更があるかどうか確認できる。

証明書は、さらに1つの地域別区分あるいはオペレーター領域でけとばす装置が新しいオペレーター領域へ移動する時に役立つであろう。これはgeo追跡装置の場合には起こる。トラッキング・データを確認するために、1つは、装置が成功裡にけとばしたかどうか知る必要がある。また、生成されたデータは純粋である。成功した操業開始のそのような証明書には装置によって生成されたデータが提供されることができる。証明書内では、操業開始が成功裡に達成された時の装置の位置は含まれているであろう。その後、そのような証明書の第三者受取人が証明書の確実性を確認しようとする場合、それは装置(むしろ、装置のそれ自体の内の位置情報の処理に依存しない方法を使用して、例えばGPSベースの方法)の現行の位置をチェックし、得られた現行の位置が証明書に含まれた位置に一致するかどうか確かめるであろう。誤った組合せがある場合、証明書の受取人は装置、あるいは装置の再確認を管理するネットワーク実体のいずれかへの装置の完全の新しい安全な操業開始と後の再確認を要求してもよい。目的地ネットワークが最後の成功した操業開始のコンテキストおよび配置(位置を含む)のことを知っている必要がある場合、最後の成功した操業開始が起こった位置についての情報を含んでいるような証明書は、さらに失敗の場合には途中で役に立つであろう。

ここに記述されるように、PVMは確認のどんな形式も使用できる。一般に、3つの主な方法はAuV、SAVおよび遠隔の確認(RV)である。方法はそれぞれ、装置完全確認に違った風に関係している測定、報告および施行のステップを扱いる。AuVは、装置上で3ステップをすべてローカルに行ないる。RVは測定をローカルに行ない、次に、外部実体に測定を報告する。施行は外部実体によって行なわれる。SAVは安全な操業開始をローカルに強化し、外部実体にメトリクスを報告し、再確認を考慮に入れる。

特に、SAVを使用する装置は、信頼州測定の直接推定を行ない、最初のネットワーク接続を確立できる。評価の結果、適切な参照メトリクスと共に、セキュリティ通路(SeGW)のような外部実体に報告されるかもしれない(以下に確認報告書)。任意に、測定と参照のメトリクスの部分集合は報告されることができる。

確認報告書は、そのプラットフォーム・アーキテクチャー、セキュリティー体系、セキュリティ・ポリシーおよび装置証明のようなH(e)NBの特性に基づいたH(e)NBの信頼状態の評価を可能にできる。確認報告書は、H(e)NB、TrE能力、測定と立証の実行、TrEのセキュリティ・ポリシー・マネージャー能力、測定結果、プラットフォーム・レベル証明情報、最後の起動時間あるいはブーツ・カウンターについての情報を含んでいるであろう。

装置についての情報は例えば、メーカー、形、型番、バージョン番号、ハードウェア構造か、バージョン番号、あるいはソフトウェア構造か、バージョン番号を含んでいるであろう。TrE能力は例えば、測定、立証、報告および施行能力を含んでいるであろう。

測定および内部立証実行情報は、安全な操業開始に信頼州測定および内部立証を行なう方法を含んでいるであろう。例えば含まれて、恐らくロードしたコンポーネントの名前、タイプおよびシーケンスのような報道の範囲。恐らく含まれた立証に対する信用のチェーンの数および範囲のようなコンポーネントの立証の方法。セキュアハッシュアルゴリズム1(SHA-I)拡張のような測定および立証に使用されたアルゴリズムが含まれているであろう。プラットフォーム機器構成レジスタ(PCR)のような登録の範囲(操業開始立証でカバーされる)も含まれているであろう。

TrEのセキュリティ・ポリシー・マネージャー能力は、セキュリティ・ポリシーのインプリメンテーションおよび施行に関する情報を含んでいるであろう。測定結果は、署名されたPCR価値のように、報告されと確認されて、実測値を内部に含んでいるであろう。プラットフォーム・レベル証明情報は、一般にH(e)NBに関する情報、あるいは特効薬中のTrEを含んでいるであろう。最後の起動時間は、最後の安全なブーツがいつ実行されたかの安全なタイムスタンプを含んでいるであろう。

ブーツ・カウンターは、パワー・サイクルが生じるごとにインクリメントするカウンターの値を含んでいるであろう。また、安全なブーツ・オペレーションが実行する。カウンターは、リセットされ、逆にすることができず、および、常に前に数える、保護されたカウンターであろう。装置が最初に初期化される場合、対価は0まで初期化されることができる。

確認報告書は、情報をくくってインターネット鍵交換プロトコル・バージョン2(IKEv2)のような認証プロトコルにすることにより、結合した認証および確認手続きによってH(e)NBに結び付けられるであろう。確認報告書は証明書を含んでいるであろう。任意に、情報のうちのいくらかはtに含まれているであろう。

あるいは、確認報告書はポインターあるいは信頼状態情報を提供する信頼された第三者(TTP)への言及を含んでいるであろう。また、外部実体はTTPから信頼状態情報を得るであろう。例えば、確認報告書は、信頼状態情報を含んでいる個別の装置信託証券への言及を含んでいるであろう。

評価の間に遭遇した例外に応じて、外部実体はネットワーク・アクセスを否定できる。
外部実体はさらに測定と参照のメトリクスを評価することができるし、H(e)NBによって検知されないか報告されたエラーを検知できる。あるいは、H(e)NBは制限のあるネットワーク・アクセス(隔離された)を与えられるであろう。そうでなければ、H(e)NBはネットワーク・アクセスを与えられるであろう。H(e)NBは外部装置からのリクエストに応じて信頼州測定を行ない、評価し、報告できる。オペレーターによって恐らく始められたリクエスト。再確認は、スタートの間に有効にならなかった要素を有効にできる。非芯確認エラーが検知される場合に、改善策を行なうために、外部実体はH(e)NBにリクエストを送るであろう。例えば、H(e)NBは治療のリクエストに応じて前もって定義した状態に戻るであろう。

評価の間に遭遇した例外に応じて、外部実体はネットワーク・アクセスを否定できる。
外部実体はさらに測定と参照のメトリクスを評価することができるし、H(e)NBによって検知されないか報告されたエラーを検知できる。あるいは、H(e)NBは制限のあるネットワーク・アクセス(隔離された)を与えられるであろう。そうでなければ、H(e)NBはネットワーク・アクセスを与えられるであろう。H(e)NBは外部装置からのリクエストに応じて信頼州測定を行ない、評価し、報告できる。オペレーターによって恐らく始められたリクエスト。再確認は、スタートの間に有効にならなかった要素を有効にできる。非芯確認エラーが検知される場合に、改善策を行なうために、外部実体はH(e)NBにリクエストを送るであろう。例えば、H(e)NBは治療のリクエストに応じて前もって定義した状態に戻るであろう。

SAVは、装置セキュリティ特性および確認測定の中へのより素晴らしい粒度およびより多くの視界に結びつくAuVとRVの利点を組み合わせる。それは、危険にさらされた装置の低い帯域幅使用法、自律の確認に匹敵するローカル装置資源、より速くより容易な検知を提供し、危険にさらされた装置のための隔離ネットワークの使用を可能にする。

図15は、WTRU 1510、H(e)NB 1520およびH(e)MS 1530を含む、無線通信ネットワーク1500の典型的なブロックダイヤグラムである。図15に示されるように、WTRU 1510、H(e)NB 1520およびH(e)MS 1530はプラットフォーム確認および管理を行なうように構成する。

典型的なWTRUで見つかるかもしれないコンポーネントに加えて、WTRU 1510は、オプションのリンクしたメモリ1522および少なくとも1トランシーバー1514、オプションのバッテリー1520およびアンテナ1518を備えたプロセッサー1516を含んでいる。プロセッサー1516はH(e)NB 1520のような基地局経由でそれに伝えられたPVM機能に関して補足的なプラットフォーム確認および管理機能を行なうように構成する。無線通信の送信および受理を促進するために、トランシーバー1514はプロセッサー1516およびアンテナ1518とのコミュニケーションにある。バッテリー1520がWTRU 1510の中で使用された場合、それはトランシーバー1514およびプロセッサー1516に動力を供給する。

典型的なH(e)NBで見つかるかもしれないコンポーネントに加えて、H(e)NB 1520は、オプションのリンクしたメモリ1515、トランシーバー1519およびアンテナ1521を備えたプロセッサー1517を含んでいる。プロセッサー1517はPVM方法論をインプリメントするプラットフォーム確認および管理機能を行なうように構成する。無線通信の送信および受理を促進するために、トランシーバー1519はプロセッサー1517およびアンテナ1521とのコミュニケーションにある。H(e)NB 1520は、オプションのリンクしたメモリ1534を備えたプロセッサー1533を含むH(e)MS 1530に接続する。

SeGWおよびPVE、図15に示されませんでしたが、コンポーネントに加えて、それは典型的なSeGWおよびPVEで見つかるかもしれない、オプションのリンクしたメモリを備えたプロセッサーを含んでいるかもしれない、トランシーバー(s)、アンテナ、またコミュニケーション・ポート。プロセッサーはPVM方法論をインプリメントするプラットフォーム確認および管理機能を行なうように構成する。コミュニケーションの送信および受理を促進するために必要なように、トランシーバーとコミュニケーション・ポートはプロセッサーとアンテナとのコミュニケーションにある。

ネットワーク要素、また様々な例に関して詳細にここに示された希望のPVM機能を行なうように選択的に構成する。さらに、PVM対応のネットワークおよび資源へのそれらの信頼できるアクセスおよび使用を促進するために、WTRUは、立証、確認および他の信頼要因に関してのように補足的なPVM機能性で形成されることができる。

例として、それぞれのコンポーネントはすべて活発な実体間の義務アプローチのPVMの最大のタイプ分離を使用するように構成する。ここに説明されるように、様々な実体間のある情報を通るために、これはPVMトークンの使用を通じて促進されることができる。
実施形態

本願は、それらの全体が参照によって本明細書に組み込まれる、２００９年３月６日に
出願された米国特許仮出願第６１／１５８，２４２号、２００９年４月２８日に出願され
た米国特許仮出願第６１／１７３，４５７号、２００９年６月３０日に出願された米国特
許仮出願第６１／２２２，０６７号、および２００９年８月２１日に出願された米国特許
仮出願第６１／２３５，７９３号の利益を主張する。本出願は同時に出願された、発明の
名称「Ｈ（ｅ）ＮＢの完全性の確認と立証のための方法と装置」の米国特許出願第１２／
７１８，５７２に関係しており、その全体が参照によって本明細書に組み込まれる。

本出願は通信に関する。

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

プラットフォームの検証および管理（ＰＶＭ：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）となるであろう、すなわち、そのグループの１つのＴＳが信用できなくなったとすると、その後は他の全てのＴＳも、もはや同様に検証を行うことができない。他の選択肢は、事例としての、それぞれのブートサイクルごとに、または確定周波数で、または各検証についてＲＴＲにより、生成された一時的検証アイデンティティを使用することである。

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

1. .プラットフォーム確認および管理(PVM)のための方法であって、、
   装置からの少なくとも立証情報を含むPVMトークンからの確認メッセージに応じてPVMトークンを受け取ること;
   PVMトークンからの前もって定義した情報を使用して、確認を行なうこと;
   失敗したコンポーネントに応じて、修理と再確認のために失敗した報告を装置管理システム(DMS)
   へ送ること、
   確認結果を備えた修正済のPVMトークンを送ること
   を含むことを特徴とする方法。
2. 請求項１に記載のそう方法において、確認を行なうことは少なくとも1つの不良状態の適用可能性を決定することを含んでいることを特徴とする方法。
3. 前記確認は遠隔の確認(RV)の少なくとも1つを使用して、行なわれる、自律の確認(AuV)、semi -自律の確認(SAV)、十分-SAV(F-SAV)、最小の確認あるいはパラメータの確認であることを特徴とする請求項１に記載のそう方法。
4. 前記立証情報は、装置同一性、装置情報、信頼された環境(TrE)情報、立証データ、立証結合、およびコンポーネントへの構成要素の指標の順序づけられたコンポーネント・リストの少なくとも1つを含んでいることを特徴とする請求項１に記載の方法。
5. 前記確認を行なうことは、インテグリティ測定/立証データ誤った組合せを決定しており、コンポーネントのために見当たらないレファレンス・インテグリティ・メトリクス(RIM)を決定しており、ロードしたコンポーネント政策失敗のリストを決定しており、吐き出された装置かRIM証明書を決定して信頼できないためにTrEを決定する少なくとも1つを含んでいることを特徴とする請求項１に記載の方法。
6. 前記PVMトークンは有効にするTrEの同一性および確認プロセスに結び付けられることを特徴とする請求項１に記載の方法。
7. 確認新鮮は、時間にPVM印に型押しをしPVM印を通るすべての実体によって時系列のリストを追加することにより制御されることを特徴とする請求項１に記載の方法。
8. 時間にPVMトークンに型押しをしPVMトークンを通るすべての実体によって時系列のリストを追加することにより、確認新鮮は制御されることを特徴とする請求項１に記載の方法。
9. クレーム1、DMSに隔離を決定するためにPVMトークンを送ることをさらに含むこと、ホワイトリスト、ブラックリストおよびグレーリスト適用可能性を特徴とする請求項１に記載の方法。
10. グレーリストはネットワークに不慣れな装置、長期間の間接続されていない装置、疑わしい振る舞いを備えた装置、およびセキュリティ警告が存在する装置の少なくとも1つを含んでいることを特徴とする請求項９に記載の方法。
11. オペレータRIM遮蔽はオペレータRIM証明書を備えた様々な外部出所から来る装置コンポーネントのための前もって定義したRIM証明書を交換することを特徴とする請求項１に記載の方法。
12. 情報がPVMトークンの中で受け取ったことをチェックするために、確認データベースへ質問は送られることを特徴とする請求項１に記載の方法。
13. 前もって定義した確認者に基づいた配置政策を検索するために、配置データベースへ質問は送られることを特徴とする請求項１に記載の方法。
14. 検索された配置ポリシーは評価されることを特徴とする請求項１３に記載の方法。
15. メッセージは不良状態に応じて確認データベース・マネージャのもとへ送られることを特徴とする請求項１に記載の方法。
16. プラットフォーム確認および管理（ＰＶＭ）につながれた装置の確認を行なう方法であって、
    装置の少なくとも１つのあらかじめ指定のコンポーネントの完全性チェックを行ない、結果をチェックして、完全性を格納すること、
    装置の安全な操業開始チェックを行ない、結果をチェックして、安全な操業開始を格納すること、
    完全チェック結果に基づいた確認メッセージの形成および安全な操業開始を行い、その結果をチェックすること、
    ＰＶＭへの確認メッセージを転送すること
    ことを特徴とする請求項に記載の方法。
17. ＴｒＥコンポーネントのローカルの確認が成功するという条件に信頼された環境（ＴｒＥ）コンポーネントがそれぞれ載せられることを保証して、安全な操業開始を段階的に行なうこと；
    トラスト（ＲｏＴ）のルートに依存する安全な操業開始によってＴｒＥのコンポーネントをロードする初期で；
    ＰＶＭとの許可コミュニケーションへのＴｒＥの外側のコンポーネントをロードする別の段階で；
    また装置の残りのコンポーネントをロードすること
    ことを特徴とする請求項に記載の方法。
18. 少なくとも１つの信頼された基準値およびＴｒＥに完全性チェックを行なうことに基づくことを特徴とする請求項１６に記載の方法。
19. 確認メッセージはどこで含んでいるか、１つの、ローカル、パス／完全の測定が１番目と２番目段階中に確立したとともに、指標に失敗することを特徴とする請求項に１６記載の方法。
20. さらにフォールバック・コード・ベースを含むことを特徴とする請求項１６に記載の方法。
21. フォールバック・コード・ベースを始めることはＲＩＭを含む主なコード・ベースのソフトウェア・アップデートを引き起こすことを含んでいることを特徴とする請求項２０に記載の方法。
22. フォールバック・コード・ベースがロードされるという条件で遭難信号を送ることをさらに含むことを特徴とする請求項１６に記載の方法。
23. ２３． クレーム１６の方法（そこでは蓄えコード（ＦＢＣ）イメージは装置の改善を促進し、安全なメモリに格納されることを特徴とする請求項に記載の方法。
24. 完全チェックは公認のコンポーネントのみが活性化されることを決めることを特徴とする請求項１６に記載の方法。
25. メモリへロードすることにより、登記済みのコンポーネントは活性化されることを特徴とする請求項２４に記載の方法。
26. 完全に証明された状態へスタートすることにより、登記済みのコンポーネントは活性化されることを特徴とする請求項２４に記載の方法。
27. 別の完全チェックを行なうことをさらに含むことを特徴とする請求項１６に記載の方法。
28. 装置が成功したネットワーク接続を完成したという条件上で別の完全チェックを行なうことをさらに含むことを特徴とする請求項１６に記載の方法。
29. 装置のうちの１つによって、あるいはメッセージに応じて第２の完全チェックは始められることを特徴とする請求項２７に記載の方法。
30. 完全チェック結果の格納は保護記憶位置にあることを特徴とする請求項１６に記載の方法。
31. 確認メッセージは暗号的に署名されたステートメントを含むことを特徴とする請求項１６に記載の方法。
32. 確認メッセージは完全チェックと後の認証手続きの間に拘束する証拠を含むことを特徴とする請求項１６に記載の方法。
33. 確認メッセージは安全な操業開始チェックと後の認証手続きの間に拘束する証拠を含むことを特徴とする請求項１６に記載の方法。
34. 確認メッセージはタイムスタンプを含むことを特徴とする請求項１６に記載の方法。
35. 確認メッセージは、完全チェックおよび操業開始チェックの前に得られた最初のタイムスタンプ、および完全チェックおよび操業開始チェックの後に得られた別のタイムスタンプを含むことを特徴とする請求項１６に記載の方法。
36. 確認メッセージは装置構成の表示を含むことを特徴とする請求項１６に記載の方法。
37. 確認メッセージは装置コンポーネントのセキュリティ特性の表示を含むことを特徴とする請求項１６に記載の方法。
38. 確認メッセージに応じてＰＶＭから決定メッセージを受け取ることをさらに含むことを特徴とする請求項１６に記載の方法。
39. 決定メッセージは装置に関連したネットワーク特権の表示を含むことを特徴とする請求項１６に記載の方法。
40. 完全チェックを行なう、信頼された資源（ＴＲ）をさらに含むことことを特徴とする請求項１６に記載の方法。
41. 安全な操業開始チェックを行なう、信頼された資源（ＴＲ）をさらに含むことを特徴とする請求項１６に記載の方法。
42. 確認メッセージを形成する、信頼された資源（ＴＲ）をさらに含むことを特徴とする請求項１６に記載の方法。
43. ＰＶＭから決定メッセージを受け取る、信頼された資源（ＴＲ）をさらに含むことを特徴とする請求項３８に記載の方法。
44. ＦＢＣは正常なコードの一部を削除するかアンインストールし、そして、再確認用の装置をリブートすることを特徴とする請求項２４に記載の方法。
45. プラットフォーム確認および管理（ＰＶＭ）を促進するためのプラットフォーム確認実体（ＰＶＥ）と、
    装置少なくとも装置からの立証情報を含むＰＶＭ印）からの確認メッセージに応じてＰＶＭ印を受け取るように構成されたＰＶＥ；
    ＰＶＭ印からの前もって定義した情報を使用して、確認を行なうように構成されたＰＶＥ；
    失敗したコンポーネントに応じて改善と再確認を始めるために装置管理システム（ＤＭＳ）に異常報告書を送るように構成されたＰＶＥ；
    また、確認を備えた修正済のＰＶＭ印を送るように構成されたＰＶＥは生じます。
    ことを特徴とする請求項に記載の方法。
46. 立証情報は少なくともセキュリティ・ポリシー属性を含んでいることを特徴とする請求項４５に記載の方法。
47. プラットフォーム確認および管理（ＰＶＭ）によって確認を行なうための装置であって、
    少なくとも１ ｐｒｅの完全チェックを行なうように構成されたプロセッサー−装置の指定のコンポーネント、また完全を格納するように構成された、チェックする、メモリに帰着する；
    装置の安全な操業開始チェックを行ない、かつ安全な新進のチェックを格納するように構成されたプロセッサーは、メモリに帰着することと、
    完全性チェック結果に基づいた確認メッセージを形成するように構成されたプロセッサー、および安全な操業開始は、結果をチェックすることと、
    ＰＶＭへの確認メッセージを送信するための発信機と
    を含むことを特徴とする装置。。
48. プラットフォーム確認および管理（ＰＶＭ）を促進するための装置管理システム（ＤＭＳ）であって、
    装置からの確認メッセージに応じて、失敗したコンポーネントに応じて改善と再確認を始める、プラットフォーム確認実体（ＰＶＥ）から、異常報告書およびＰＶＭ印の少なくとも１つを受け取るように構成されたＤＭＳ（少なくとも装置からの立証情報を含むＰＶＭ印）と、
    少なくとも失敗したコンポーネントのための最新版の有効性を決定するように構成されたＤＭＳと、
    利用可能な最新版のために放送中の最新版を準備するように構成されたＤＭＳと、
    確認データベース中の利用可能な最新版に信頼された基準値の存在を保証するように構成されたＤＭＳと、
    セキュリティ・ゲートウエイ（ＳｅＧＷ）へ修正済のＰＶＭ印および再確認表示を送るように構成されたＤＭＳと、
    装置へ再確認トリガーを送るように構成されたＤＭＳと
    を含むことを特徴とする装置。

Images