JP5810168B2 - デバイスの妥当性確認、障害指示、および修復 - Google Patents
デバイスの妥当性確認、障害指示、および修復 Download PDFInfo
- Publication number
- JP5810168B2 JP5810168B2 JP2013537850A JP2013537850A JP5810168B2 JP 5810168 B2 JP5810168 B2 JP 5810168B2 JP 2013537850 A JP2013537850 A JP 2013537850A JP 2013537850 A JP2013537850 A JP 2013537850A JP 5810168 B2 JP5810168 B2 JP 5810168B2
- Authority
- JP
- Japan
- Prior art keywords
- component
- integrity
- network
- failed
- integrity check
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 230000008439 repair process Effects 0.000 title claims description 95
- 238000010200 validation analysis Methods 0.000 title description 50
- 238000000034 method Methods 0.000 claims description 146
- 238000005259 measurement Methods 0.000 claims description 101
- 238000004891 communication Methods 0.000 claims description 84
- 230000008569 process Effects 0.000 claims description 60
- 238000005067 remediation Methods 0.000 claims description 40
- 230000006870 function Effects 0.000 description 163
- 238000007726 management method Methods 0.000 description 87
- 238000010586 diagram Methods 0.000 description 27
- 230000004044 response Effects 0.000 description 26
- 238000013507 mapping Methods 0.000 description 23
- 238000005516 engineering process Methods 0.000 description 17
- 230000001010 compromised effect Effects 0.000 description 16
- 230000009471 action Effects 0.000 description 15
- 239000012634 fragment Substances 0.000 description 15
- 241000723573 Tobacco rattle virus Species 0.000 description 13
- 238000012795 verification Methods 0.000 description 12
- 238000012937 correction Methods 0.000 description 11
- 230000007246 mechanism Effects 0.000 description 9
- 230000004048 modification Effects 0.000 description 9
- JZEPSDIWGBJOEH-UHFFFAOYSA-N 4-decylbicyclo[2.2.1]hept-2-ene Chemical compound C1CC2C=CC1(CCCCCCCCCC)C2 JZEPSDIWGBJOEH-UHFFFAOYSA-N 0.000 description 7
- 238000004364 calculation method Methods 0.000 description 7
- 238000012986 modification Methods 0.000 description 7
- 230000000977 initiatory effect Effects 0.000 description 6
- 230000036961 partial effect Effects 0.000 description 6
- 241000760358 Enodes Species 0.000 description 5
- 238000004422 calculation algorithm Methods 0.000 description 5
- 238000013459 approach Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 4
- 238000013500 data storage Methods 0.000 description 4
- 238000011161 development Methods 0.000 description 4
- 230000003068 static effect Effects 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- 230000001413 cellular effect Effects 0.000 description 3
- 238000003745 diagnosis Methods 0.000 description 3
- 230000002452 interceptive effect Effects 0.000 description 3
- 230000007257 malfunction Effects 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 230000002093 peripheral effect Effects 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 230000027455 binding Effects 0.000 description 2
- 238000009739 binding Methods 0.000 description 2
- 238000003780 insertion Methods 0.000 description 2
- 230000037431 insertion Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000002955 isolation Methods 0.000 description 2
- 230000000670 limiting effect Effects 0.000 description 2
- 229910001416 lithium ion Inorganic materials 0.000 description 2
- 238000010295 mobile communication Methods 0.000 description 2
- 230000000750 progressive effect Effects 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- KJLPSBMDOIVXSN-UHFFFAOYSA-N 4-[4-[2-[4-(3,4-dicarboxyphenoxy)phenyl]propan-2-yl]phenoxy]phthalic acid Chemical compound C=1C=C(OC=2C=C(C(C(O)=O)=CC=2)C(O)=O)C=CC=1C(C)(C)C(C=C1)=CC=C1OC1=CC=C(C(O)=O)C(C(O)=O)=C1 KJLPSBMDOIVXSN-UHFFFAOYSA-N 0.000 description 1
- 208000033770 Device misuse Diseases 0.000 description 1
- HBBGRARXTFLTSG-UHFFFAOYSA-N Lithium ion Chemical compound [Li+] HBBGRARXTFLTSG-UHFFFAOYSA-N 0.000 description 1
- 229910005580 NiCd Inorganic materials 0.000 description 1
- 229910003962 NiZn Inorganic materials 0.000 description 1
- 241000700159 Rattus Species 0.000 description 1
- 230000003213 activating effect Effects 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 230000003190 augmentative effect Effects 0.000 description 1
- OJIJEKBXJYRIBZ-UHFFFAOYSA-N cadmium nickel Chemical compound [Ni].[Cd] OJIJEKBXJYRIBZ-UHFFFAOYSA-N 0.000 description 1
- 239000002131 composite material Substances 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 230000001186 cumulative effect Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000029087 digestion Effects 0.000 description 1
- 230000004064 dysfunction Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000037406 food intake Effects 0.000 description 1
- 239000000446 fuel Substances 0.000 description 1
- 238000010348 incorporation Methods 0.000 description 1
- 230000006698 induction Effects 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 230000001404 mediated effect Effects 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 229910052987 metal hydride Inorganic materials 0.000 description 1
- 229910052759 nickel Inorganic materials 0.000 description 1
- PXHVJJICTQNCMI-UHFFFAOYSA-N nickel Substances [Ni] PXHVJJICTQNCMI-UHFFFAOYSA-N 0.000 description 1
- -1 nickel metal hydride Chemical class 0.000 description 1
- QELJHCBNGDEXLD-UHFFFAOYSA-N nickel zinc Chemical compound [Ni].[Zn] QELJHCBNGDEXLD-UHFFFAOYSA-N 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 230000000246 remedial effect Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 238000007789 sealing Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000000153 supplemental effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B23/00—Testing or monitoring of control systems or parts thereof
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0751—Error or fault detection not based on redundancy
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/079—Root cause analysis, i.e. error or fault diagnosis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0793—Remedial or corrective actions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/575—Secure boot
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M1/00—Substation equipment, e.g. for use by subscribers
- H04M1/24—Arrangements for testing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/10—Integrity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/30—Security of mobile devices; Security of mobile applications
- H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
- H04W24/02—Arrangements for optimising operational condition
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2103—Challenge-response
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2111—Location-sensitive, e.g. geographical location, GPS
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Quality & Reliability (AREA)
- Technology Law (AREA)
- Multimedia (AREA)
- Computing Systems (AREA)
- Databases & Information Systems (AREA)
- Automation & Control Theory (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- Mobile Radio Communication Systems (AREA)
Description
本発明は、デバイスの妥当性確認、障害指示、および修復に関する。
ワイヤレス通信システムは、不必要なリソースを使用し、システム内のワイヤレス通信デバイス上でインテグリティーチェックおよび／またはインテグリティー障害の修正を実行することができる。現在のインテグリティーチェックを、コードの大きな一体型のブロック上で実行し、ワイヤレス通信デバイスのインテグリティーが危うくされているかどうかを判定することができる。たとえば、インテグリティーチェックを通じて、不正な修正、改ざん、および／または危うくされているソフトウェアをワイヤレス通信デバイス上で検知することができる。大きなブロックのコードに関してインテグリティー障害が判定されると、ネットワークは、その障害を修正するための更新を大きな一体型のブロックの形態でワイヤレス通信デバイスへダウンロードすることができる。このことによって、不必要な帯域幅が必要とされる場合があり、不要な計算負荷がシステム上に追加される場合がある。
加えて、多数のタイプおよび／またはモデルのワイヤレス通信デバイスを使用し、ネットワークと、またはネットワークを介して通信することができ、それらのワイヤレス通信デバイスはそれぞれ、さまざまな形態のソフトウェアおよびハードウェアを有している。これらのさまざまなデバイスによって、ワイヤレス通信デバイス上の障害が生じているコンポーネントの報告を標準化することが困難になる場合がある。なぜなら、ハードウェアおよびソフトウェアの開発慣行は、企業ごとに異なる場合があるためである。
この「発明の概要」は、以降の「発明を実施するための形態」でさらに説明されるさまざまなコンセプトを、簡略化された形式で紹介するために提供される。
本明細書においては、ワイヤレス通信デバイスの１つまたは複数のコンポーネントのインテグリティーチェックを実行するためのシステム、方法、および装置の実施形態について説明する。本明細書に記載されているように、ワイヤレス通信デバイスに関連付けられているコンポーネント上で第１のインテグリティーチェックを実行することができる。コンポーネントが第１のインテグリティーチェックに不合格になったと判定することができる。不合格になったコンポーネントに対応する機能の指示をネットワークエンティティーへ送信することができる。不合格になったコンポーネントのうちで、コンポーネントが第１のインテグリティーチェックに不合格になる原因となった部分を判定するために、不合格になったコンポーネント上で第２のインテグリティーチェックを実行したいという要求をネットワークエンティティーから受信することができる。ネットワークエンティティーによる修復用に不合格になったコンポーネントの部分を分離するために、不合格になったコンポーネント上で第２のインテグリティーチェックを実行することができる。
例示的な一実施形態によれば、ワイヤレス通信デバイスに関連付けられているコンポーネント上で第１のインテグリティーチェックを実行するようにローダを構成することができる。ローダは、コンポーネントが第１のインテグリティーチェックに不合格になったと判定し、ネットワークエンティティーによる修復用に不合格になったコンポーネントの一部分を分離するために、不合格になったコンポーネント上で第２のインテグリティーチェックを実行するように構成することもできる。
例示的な一実施形態によれば、不合格になったコンポーネントの指示をローダから受信し、不合格になったコンポーネントに対応するネットワーク機能を受信するようにＰＩＰＥ（ｐｌａｔｆｏｒｍ ｉｎｔｅｇｒｉｔｙ ｐｏｌｉｃｙ ｅｎｇｉｎｅ）を構成することができる。ＰＩＰＥは、不合格になったコンポーネントに対応する機能の指示をネットワークエンティティーに報告し、コンポーネントが第１のインテグリティーチェックに不合格になる原因となった不合格になったコンポーネントの部分を判定するために、不合格になったコンポーネント上で第２のインテグリティーチェックを実行したいという要求をネットワークエンティティーから受信するようにさらに構成することができる。
例示的な一実施形態によれば、デバイス修復サーバについて、本明細書において説明することができる。デバイス修復サーバは、ワイヤレス通信ネットワーク上に存在することができ、コンポーネントのうちで、ワイヤレス通信デバイス上のインテグリティーチェックに不合格になった部分を修復するように構成することができる。たとえば、デバイス修復サーバは、ワイヤレス通信デバイス上のインテグリティーチェックの不合格になったコンポーネントに関連付けられているネットワーク機能の指示をワイヤレス通信デバイスから受信するように構成することができる。不合格になったコンポーネントは、ネットワーク機能の受信された指示に基づいて判定することができる。デバイス修復サーバは、修復のために不合格になったコンポーネントの部分を分離するために、ワイヤレス通信デバイスに対する問合せを実行するように構成することもできる。デバイス修復サーバは、１つまたは複数の基準に基づいて、ワイヤレス通信デバイスへ送信されることになる不合格になったコンポーネントの部分のための修正または置換を判定するようにさらに構成することができる。基準に基づいて判定されると、次いでデバイス修復サーバは、不合格になったコンポーネントの部分のための修正または置換をワイヤレス通信デバイスへ送信することができる。不合格になったコンポーネントのための修正または置換を判定するために、さまざまな異なる基準を使用することができる。たとえば、基準は、不合格になったコンポーネントのサイズまたは他の何らかのファクタに基づくことができる。例示的な一実施形態においては、修復サーバは、ＯＳソフトウェアバージョンに基づいて特定のコンポーネントを置換することができる。その他の例示的な基準としては、バージョン番号、デバイス／コンポーネント／コード部分ごとの最新の更新または成功した修復の日付／時間、コードまたはコンポーネントの所有権、コードライセンスの状況（たとえば、デジタル権利マネージメント）、不合格になったコンポーネント、ビット、またはバイトの数、不合格になったコード部分のサイズ、およびコード部分またはコンポーネントの割り当てられたまたは計算されたリスクまたはダメージインパクト値が含まれるが、それらには限定されない。
この「発明の概要」は、以降の「発明を実施するための形態」でさらに説明されるコンセプトから抜粋したものを、簡略化された形式で紹介するために提供されている。この「発明の概要」は、特許請求される主題の鍵となる特徴または必要不可欠な特徴を特定することを意図されておらず、特許請求される主題の範囲を限定するために使用されることも意図されていない。さらに、特許請求される主題は、本開示の任意の部分に記載されているあらゆるまたはすべての不利な点を解決する制限に限定されるものではない。
以降の説明から、より詳細な理解を得ることができ、以降の説明は、例として添付の図面とともに与えられている。
１つまたは複数の開示されている実施形態を実施することができる例示的な通信システムを示す図である。
１つまたは複数の開示されている実施形態を実施することができる例示的なワイヤレス送信／受信ユニットを示す図である。
１つまたは複数の開示されている実施形態を実施することができる例示的なシステムラジオアクセスネットワーク（ｓｙｓｔｅｍ ｒａｄｉｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ）を示す図である。
ワイヤレス通信デバイス上のブートシーケンスの例示的な一実施形態を示す図である。
オブジェクトファイルと、実行可能イメージとの間におけるリンキングを示す図である。
オブジェクトファイルと、実行可能イメージとの間におけるリンキングを示す別の図である。
ファイルのコンポーネントＴＲＶセクションの一例を示す図である。
コンポーネントからネットワーク機能へのマッピングを示す図である。
ファイルのコンポーネントから機能へのマッピングセクションの一例を示す図である。
ブートシーケンスにおいて使用される能力およびポリシーのプラットフォーム構成（ｂｒｉｎｇ−ｕｐ）を示す図である。
インテグリティーチェックおよび／または報告の最中における本明細書に記載のテーブルまたはマップの使用を示す図である。
本明細書に記載されているような報告および修復プロセスの例示的な概観を示す図である。
実行することができるアクションを判定するためにデバイスにおける情報を収集するための例示的なコールフロー図である。
デバイスと、ネットワークエンティティーとの間における問合せに関する例示的なコールフロー図である。
ワイヤレス通信デバイスのコンポーネント上で実行される問合せの一例を示す図である。
ワイヤレス通信デバイスのコンポーネント上で実行される問合せの別の例を示す図である。
障害アラームおよびモノリシックなコードの置換に関連する例示的なコールフロー図である。
リモートソフトウェア障害／修復に関連する例示的なコールフロー図である。
ＳｅＧＷの認証の試みを伴う、リモートソフトウェア障害／修復に関連する例示的なコールフロー図である。
ネットワークがＳｅＧＷを通じた認証を許可しないことが可能である、リモートソフトウェア障害／修復に関連する例示的なコールフロー図である。
即時の限定されたアクセスおよび洗練されたアクセスの制御を伴う、リモートソフトウェア障害／修復に関連する例示的なコールフロー図である。
ＳｅＧＷアクセスを伴うワイヤレス通信デバイスソフトウェアコンポーネントの修復に関連する例示的なコールフロー図である。
能力の中継ノードブートストラッピング（ｒｅｌａｙ ｎｏｄｅ ｂｏｏｔｓｔｒａｐｐｉｎｇ ｏｆ ｃａｐａｂｉｌｉｔｉｅｓ）に関連する例示的なコールフロー図である。
認証されたマネージメント能力を用いた中継ノード修復に関連する例示的なコールフロー図である。
機能コンポーネントおよびコード／データストレージコンポーネントからなる例示的なシステムを示す図である。
ブートシーケンスの諸ステージの例示的な一実施形態と、それぞれのステージにおいて実施されるさまざまなエンティティーどうしの間における対話とを示す図である。
ＴＲＶを作成するために線形に結合されている測定値のシーケンスを示す図である。
ＴＲＶを作成するためにＭｅｒｋｌｅハッシュツリーを使用する値の組合せを示す図である。
図１Ａ〜図２４Ｂは、開示されているシステム、方法、および手段を実施することができる例示的な実施形態に関する。本明細書に記載されている実施形態は、例示的であること、および限定的でないことが意図されている。本明細書においては、プロトコルフローについて例示および説明する場合があるが、それらのフローの順序を変更することができ、一部を省略することができ、および／またはさらなるフローを追加することができる。
図１Ａ、図１Ｂ、および図１Ｃは、本明細書に記載されている実施形態において使用することができる例示的な通信システムおよびデバイスを示している。図１Ａは、１つまたは複数の開示されている実施形態を実施することができる例示的な通信システム１００の図である。通信システム１００は、コンテンツ、たとえば音声、データ、ビデオ、メッセージング、放送などを複数のワイヤレスユーザに提供するマルチプルアクセスシステムとすることができる。通信システム１００は、複数のワイヤレスユーザが、ワイヤレス帯域幅を含むシステムリソースの共有を通じてそのようなコンテンツにアクセスすることを可能にすることができる。たとえば、通信システム１００は、１つまたは複数のチャネルアクセス方法、たとえばＣＤＭＡ（ｃｏｄｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）、ＴＤＭＡ（ｔｉｍｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）、ＦＤＭＡ（ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）、ＯＦＤＭＡ（ｏｒｔｈｏｇｏｎａｌ ＦＤＭＡ）、ＳＣ−ＦＤＭＡ（ｓｉｎｇｌｅ−ｃａｒｒｉｅｒ ＦＤＭＡ）などを採用することができる。
図１Ａにおいて示されているように、通信システム１００は、ＷＴＲＵ（ｗｉｒｅｌｅｓｓ ｔｒａｎｓｍｉｔ／ｒｅｃｅｉｖｅ ｕｎｉｔ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、ＲＡＮ（ｒａｄｉｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ）１０４、コアネットワーク１０６、ＰＳＴＮ（ｐｕｂｌｉｃ ｓｗｉｔｃｈｅｄ ｔｅｌｅｐｈｏｎｅ ｎｅｔｗｏｒｋ）１０８、インターネット１１０、およびその他のネットワーク１１２を含むことができるが、開示されている実施形態では、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素が考えられるということがわかるであろう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのそれぞれは、ワイヤレス環境において動作および／または通信を行うように構成されている任意のタイプのデバイスとすることができる。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、ワイヤレス信号を送信および／または受信するように構成することができ、ＵＥ（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）、移動局、固定式または移動式のサブスクライバーユニット、ページャー、セルラー電話、ＰＤＡ（ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサ、家庭用電化製品などを含むことができる。
通信システム１００は、基地局１１４ａおよび基地局１１４ｂを含むこともできる。基地局１１４ａ、１１４ｂのそれぞれは、コアネットワーク１０６、インターネット１１０、および／またはネットワーク１１２などの１つまたは複数の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つとワイヤレスにインターフェースを取るように構成されている任意のタイプのデバイスとすることができる。例として、基地局１１４ａ、１１４ｂは、ＢＴＳ（ｂａｓｅ ｔｒａｎｓｃｅｉｖｅｒ ｓｔａｔｉｏｎ）、Ｎｏｄｅ−Ｂ、ｅＮｏｄｅ Ｂ、Ｈｏｍｅ Ｎｏｄｅ Ｂ、Ｈｏｍｅ ｅＮｏｄｅ Ｂ、サイトコントローラ、ＡＰ（ａｃｃｅｓｓ ｐｏｉｎｔ）、ワイヤレスルータなどとすることができる。基地局１１４ａ、１１４ｂは、それぞれ単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含むことができるということがわかるであろう。
基地局１１４ａは、ＲＡＮ１０４の一部とすることができ、ＲＡＮ１０４は、その他の基地局および／またはネットワーク要素（図示せず）、たとえばＢＳＣ（ｂａｓｅ ｓｔａｔｉｏｎ ｃｏｎｔｒｏｌｌｅｒ）、ＲＮＣ（ｒａｄｉｏ ｎｅｔｗｏｒｋ ｃｏｎｔｒｏｌｌｅｒ）、中継ノードなどを含むこともできる。基地局１１４ａおよび／または基地局１１４ｂは、特定の地理的領域内でワイヤレス信号を送信および／または受信するように構成することができ、この地理的領域は、セル（図示せず）と呼ばれることもある。セルは、複数のセルセクタへとさらに分割することができる。たとえば、基地局１１４ａに関連付けられているセルは、３つのセクタへと分割することができる。したがって一実施形態においては、基地局１１４ａは、３つのトランシーバ、すなわち、セルのそれぞれのセクタごとに１つのトランシーバを含むことができる。別の実施形態においては、基地局１１４ａは、ＭＩＭＯ（ｍｕｌｔｉｐｌｅ−ｉｎｐｕｔ ｍｕｌｔｉｐｌｅ ｏｕｔｐｕｔ）テクノロジーを採用することができ、したがって、セルのそれぞれのセクタごとに複数のトランシーバを利用することができる。
基地局１１４ａ、１１４ｂは、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数と通信することができ、エアインターフェース１１６は、任意の適切なワイヤレス通信リンク（たとえば、ＲＦ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）、マイクロ波、ＩＲ（ｉｎｆｒａｒｅｄ）、ＵＶ（ｕｌｔｒａｖｉｏｌｅｔ）、可視光など）とすることができる。エアインターフェース１１６は、任意の適切なＲＡＴ（ｒａｄｉｏ ａｃｃｅｓｓ ｔｅｃｈｎｏｌｏｇｙ）を使用して確立することができる。
より具体的には、上述したように、通信システム１００は、マルチプルアクセスシステムとすることができ、１つまたは複数のチャネルアクセススキーム、たとえばＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどを採用することができる。たとえば、ＲＡＮ１０４内の基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＵＴＲＡ（ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ）などの無線テクノロジーを実施することができ、この無線テクノロジーは、ＷＣＤＭＡ（登録商標）（ｗｉｄｅｂａｎｄ ＣＤＭＡ）を使用してエアインターフェース１１６を確立することができる。ＷＣＤＭＡは、ＨＳＰＡ（Ｈｉｇｈ−Ｓｐｅｅｄ Ｐａｃｋｅｔ Ａｃｃｅｓｓ）および／またはＨＳＰＡ＋（Ｅｖｏｌｖｅｄ ＨＳＰＡ）などの通信プロトコルを含むことができる。ＨＳＰＡは、ＨＳＤＰＡ（Ｈｉｇｈ−Ｓｐｅｅｄ Ｄｏｗｎｌｉｎｋ Ｐａｃｋｅｔ Ａｃｃｅｓｓ）および／またはＨＳＵＰＡ（Ｈｉｇｈ−Ｓｐｅｅｄ Ｕｐｌｉｎｋ Ｐａｃｋｅｔ Ａｃｃｅｓｓ）を含むことができる。
別の実施形態においては、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、Ｅ−ＵＴＲＡ（Ｅｖｏｌｖｅｄ ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ）などの無線テクノロジーを実施することができ、この無線テクノロジーは、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）および／またはＬＴＥ−Ａ（ＬＴＥ−Ａｄｖａｎｃｅｄ）を使用してエアインターフェース１１６を確立することができる。
その他の実施形態においては、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、無線テクノロジー、たとえばＩＥＥＥ ８０２．１６（すなわちＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、ＩＳ−２０００（Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ２０００）、ＩＳ−９５（Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ９５）、ＩＳ−８５６（Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ８５６）、ＧＳＭ（登録商標）（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、ＥＤＧＥ（Ｅｎｈａｎｃｅｄ Ｄａｔａ ｒａｔｅｓ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎ）、ＧＥＲＡＮ（ＧＳＭ ＥＤＧＥ）などを実施することができる。
図１Ａにおける基地局１１４ｂは、たとえばワイヤレスルータ、Ｈｏｍｅ Ｎｏｄｅ Ｂ、Ｈｏｍｅ ｅＮｏｄｅ Ｂ、またはアクセスポイントとすることができ、局所的なエリア、たとえば事業所、家庭、乗り物、キャンパスなどにおけるワイヤレス接続を容易にするために、任意の適切なＲＡＴを利用することができる。一実施形態においては、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＷＬＡＮ（ｗｉｒｅｌｅｓｓ ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）を確立するために、ＩＥＥＥ ８０２．１１などの無線テクノロジーを実施することができる。別の実施形態においては、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＷＰＡＮ（ｗｉｒｅｌｅｓｓ ｐｅｒｓｏｎａｌ ａｒｅａ ｎｅｔｗｏｒｋ）を確立するために、ＩＥＥＥ ８０２．１５などの無線テクノロジーを実施することができる。さらに別の実施形態においては、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ピコセルまたはフェムトセルを確立するために、セルラーベースのＲＡＴ（たとえば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用することができる。図１Ａにおいて示されているように、基地局１１４ｂは、インターネット１１０への直接接続を有することができる。したがって、基地局１１４ｂは、コアネットワーク１０６を介してインターネット１１０にアクセスすることを不要とすることができる。
ＲＡＮ１０４は、コアネットワーク１０６と通信状態にあることが可能であり、コアネットワーク１０６は、音声、データ、アプリケーション、および／またはＶｏＩＰ（ｖｏｉｃｅ ｏｖｅｒ ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数に提供するように構成されている任意のタイプのネットワークとすることができる。たとえば、コアネットワーク１０６は、コール制御、課金サービス、モバイルロケーションベースサービス、プリペイドコーリング、インターネット接続、ビデオ配信などを提供すること、および／またはユーザ認証などのハイレベルセキュリティー機能を実行することが可能である。図１Ａにおいては示されていないが、ＲＡＮ１０４および／またはコアネットワーク１０６は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを採用しているその他のＲＡＮと直接または間接の通信状態にあることが可能であるということがわかるであろう。たとえば、コアネットワーク１０６は、Ｅ−ＵＴＲＡ無線テクノロジーを利用している可能性があるＲＡＮ１０４に接続されていることに加えて、ＧＳＭ無線テクノロジーを採用している別のＲＡＮ（図示せず）と通信状態にあることも可能である。
コアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄがＰＳＴＮ１０８、インターネット１１０、および／またはその他のネットワーク１１２にアクセスするためのゲートウェイとして機能することもできる。ＰＳＴＮ１０８は、ＰＯＴＳ（ｐｌａｉｎ ｏｌｄ ｔｅｌｅｐｈｏｎｅ ｓｅｒｖｉｃｅ）を提供する回路交換電話ネットワークを含むことができる。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイートにおけるＴＣＰ（ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ）、ＵＤＰ（ｕｓｅｒ ｄａｔａｇｒａｍ ｐｒｏｔｏｃｏｌ）、およびＩＰ（ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ）など、共通の通信プロトコルを使用する相互接続されたコンピュータネットワークおよびデバイスからなるグローバルシステムを含むことができる。ネットワーク１１２は、その他のサービスプロバイダによって所有および／または運営されている有線またはワイヤレスの通信ネットワークを含むことができる。たとえば、ネットワーク１１２は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを採用している可能性がある１つまたは複数のＲＡＮに接続されている別のコアネットワークを含むことができる。
通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちのいくつかまたはすべては、マルチモード機能を含むことができ、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、別々のワイヤレスリンクを介して別々のワイヤレスネットワークと通信するために複数のトランシーバを含むことができる。たとえば、図１Ａにおいて示されているＷＴＲＵ１０２ｃは、セルラーベースの無線テクノロジーを採用している可能性がある基地局１１４ａ、およびＩＥＥＥ ８０２無線テクノロジーを採用している可能性がある基地局１１４ｂと通信するように構成することができる。
図１Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１Ｂにおいて示されているように、ＷＴＲＵ１０２は、プロセッサ１１８、トランシーバ１２０、送信／受信要素１２２、スピーカー／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、取り外し不能メモリ１３０、取り外し可能メモリ１３２、電源１３４、ＧＰＳ（ｇｌｏｂａｌ ｐｏｓｉｔｉｏｎｉｎｇ ｓｙｓｔｅｍ）チップセット１３６、およびその他の周辺機器１３８を含むことができる。ＷＴＲＵ１０２は、一実施形態との整合性を保持しながら、上述の要素どうしの任意の下位組合せを含むことができるということがわかるであろう。
プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、ＤＳＰ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ）、複数のマイクロプロセッサ、ＤＳＰコアと関連付けられている１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）回路、その他の任意のタイプのＩＣ（ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）、状態マシンなどとすることができる。プロセッサ１１８は、信号コーディング、データ処理、電力制御、入力／出力処理、および／またはＷＴＲＵ１０２をワイヤレス環境内で機能できるようにするその他の任意の機能を実行することができる。プロセッサ１１８は、トランシーバ１２０に結合することができ、トランシーバ１２０は、送信／受信要素１２２に結合することができる。図１Ｂは、プロセッサ１１８とトランシーバ１２０を別々のコンポーネントとして示しているが、プロセッサ１１８とトランシーバ１２０は、１つの電子パッケージまたはチップ内に統合することができるということがわかるであろう。
送信／受信要素１２２は、エアインターフェース１１６を介して、基地局（たとえば、基地局１１４ａ）に信号を送信するように、または基地局（たとえば、基地局１１４ａ）から信号を受信するように構成することができる。たとえば、一実施形態においては、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されているアンテナとすることができる。別の実施形態においては、送信／受信要素１２２は、たとえば、ＩＲ信号、ＵＶ信号、または可視光信号を送信および／または受信するように構成されているエミッタ／検知器とすることができる。さらに別の実施形態においては、送信／受信要素１２２は、ＲＦ信号と光信号との両方を送信および受信するように構成することができる。送信／受信要素１２２は、ワイヤレス信号の任意の組合せを送信および／または受信するように構成することができるということがわかるであろう。
加えて、送信／受信要素１２２は、図１Ｂにおいては単一の要素として示されているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含むことができる。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯテクノロジーを採用することができる。したがって、一実施形態においては、ＷＴＲＵ１０２は、エアインターフェース１１６を介してワイヤレス信号を送信および受信するために、複数の送信／受信要素１２２（たとえば、複数のアンテナ）を含むことができる。
トランシーバ１２０は、送信／受信要素１２２によって送信される信号を変調するように、また、送信／受信要素１２２によって受信される信号を復調するように構成することができる。上述したように、ＷＴＲＵ１０２は、マルチモード機能を有することができる。したがってトランシーバ１２０は、ＷＴＲＵ１０２が、たとえばＵＴＲＡおよびＩＥＥＥ ８０２．１１など、複数のＲＡＴを介して通信できるようにするために複数のトランシーバを含むことができる。
ＷＴＲＵ１０２のプロセッサ１１８は、スピーカー／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（たとえば、ＬＣＤ（ｌｉｑｕｉｄ ｃｒｙｓｔａｌ ｄｉｓｐｌａｙ）ディスプレイユニットまたはＯＬＥＤ（ｏｒｇａｎｉｃ ｌｉｇｈｔ−ｅｍｉｔｔｉｎｇ ｄｉｏｄｅ）ディスプレイユニット）に結合することができ、そこからユーザ入力データを受け取ることができる。プロセッサ１１８は、ユーザデータをスピーカー／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８へ出力することもできる。加えて、プロセッサ１１８は、取り外し不能メモリ１３０および／または取り外し可能メモリ１３２など、任意のタイプの適切なメモリからの情報にアクセスすること、およびそれらのメモリにデータを格納することが可能である。取り外し不能メモリ１３０は、ＲＡＭ（ｒａｎｄｏｍ−ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ＲＯＭ（ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）、ハードディスク、またはその他の任意のタイプのメモリストレージデバイスを含むことができる。取り外し可能メモリ１３２は、ＳＩＭ（ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ）カード、メモリスティック、ＳＤ（ｓｅｃｕｒｅ ｄｉｇｉｔａｌ）メモリカードなどを含むことができる。その他の実施形態においては、プロセッサ１１８は、サーバまたはホームコンピュータ（図示せず）上など、ＷＴＲＵ１０２上に物理的に配置されていないメモリからの情報にアクセスすること、およびそれらのメモリにデータを格納することが可能である。
プロセッサ１１８は、電源１３４から電力を受け取ることができ、また、ＷＴＲＵ１０２内のその他のコンポーネントへの電力を分配および／または制御するように構成することができる。電源１３４は、ＷＴＲＵ１０２に電力供給するための任意の適切なデバイスとすることができる。たとえば、電源１３４は、１つまたは複数の乾電池（たとえばＮｉＣｄ（ｎｉｃｋｅｌ−ｃａｄｍｉｕｍ）、ＮｉＺｎ（ｎｉｃｋｅｌ−ｚｉｎｃ）、ＮｉＭＨ（ｎｉｃｋｅｌ ｍｅｔａｌ ｈｙｄｒｉｄｅ）、Ｌｉ−ｉｏｎ（ｌｉｔｈｉｕｍ−ｉｏｎ）など）、太陽電池、燃料電池などを含むことができる。
プロセッサ１１８は、ＧＰＳチップセット１３６に結合することもでき、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在位置に関する位置情報（たとえば、経度および緯度）を提供するように構成することができる。ＧＰＳチップセット１３６からの情報に加えて、またはその情報の代わりに、ＷＴＲＵ１０２は、基地局（たとえば、基地局１１４ａ、１１４ｂ）からエアインターフェース１１６を介して位置情報を受信すること、および／または複数の近隣の基地局から受信されている信号のタイミングに基づいて自分の位置を特定することが可能である。ＷＴＲＵ１０２は、一実施形態との整合性を保持しながら、任意の適切な位置特定方法を通じて位置情報を得ることができるということがわかるであろう。
プロセッサ１１８は、その他の周辺機器１３８にさらに結合することができ、その他の周辺機器１３８は、さらなる特徴、機能、および／または有線接続もしくはワイヤレス接続を提供する１つまたは複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含むことができる。たとえば、周辺機器１３８は、加速度計、ｅ−コンパス、衛星トランシーバ、デジタルカメラ（写真またはビデオ用）、ＵＳＢ（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）ポート、振動デバイス、テレビジョントランシーバ、ハンドフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、ＦＭ（ｆｒｅｑｕｅｎｃｙ ｍｏｄｕｌａｔｅｄ）ラジオユニット、デジタルミュージックプレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含むことができる。
図１Ｃは、一実施形態によるＲＡＮ１０４およびコアネットワーク１０６のシステム図である。上述したように、ＲＡＮ１０４は、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＥ−ＵＴＲＡ無線テクノロジーを採用することができる。ＲＡＮ１０４は、コアネットワーク１０６と通信状態にあることも可能である。
ＲＡＮ１０４は、ｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃを含むことができるが、ＲＡＮ１０４は、一実施形態との整合性を保持しながら、任意の数のｅＮｏｄｅ−Ｂを含むことができるということがわかるであろう。ｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃはそれぞれ、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために１つまたは複数のトランシーバを含むことができる。一実施形態においては、ｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃは、ＭＩＭＯテクノロジーを実施することができる。したがって、ｅＮｏｄｅ−Ｂ１４０ａは、たとえば、ＷＴＲＵ１０２ａにワイヤレス信号を送信するために、およびＷＴＲＵ１０２ａからワイヤレス信号を受信するために、複数のアンテナを使用することができる。
ｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃのそれぞれは、特定のセル（図示せず）に関連付けることができ、無線リソース管理の決定、ハンドオーバの決定、アップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを取り扱うように構成することができる。図１Ｃにおいて示されているように、ｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃは、Ｘ２インターフェースを介して互いに通信することができる。
図１Ｃにおいて示されているコアネットワーク１０６は、ＭＭＥ（ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｇａｔｅｗａｙ）１４２、サービングゲートウェイ１４４、およびＰＤＮ（ｐａｃｋｅｔ ｄａｔａ ｎｅｔｗｏｒｋ）ゲートウェイ１４６を含むことができる。上述の要素のそれぞれは、コアネットワーク１０６の一部として示されているが、これらの要素のいずれかが、コアネットワークオペレータ以外のエンティティーによって所有および／または運営されることも可能であるということがわかるであろう。
ＭＭＥ１４２は、Ｓ１インターフェースを介してＲＡＮ１０４内のｅＮｏｄｅ−Ｂ１４２ａ、１４２ｂ、１４２ｃのそれぞれに接続することができ、制御ノードとして機能することができる。たとえば、ＭＭＥ１４２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラのアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの最初の接続中に特定のサービングゲートウェイを選択することなどを担当することができる。ＭＭＥ１４２は、ＲＡＮ１０４と、ＧＳＭまたはＷＣＤＭＡなどのその他の無線テクノロジーを採用しているその他のＲＡＮ（図示せず）との間における切り替えを行うための制御プレーン機能を提供することもできる。
サービングゲートウェイ１４４は、Ｓ１インターフェースを介してＲＡＮ１０４内のｅＮｏｄｅ Ｂ１４０ａ、１４０ｂ、１４０ｃのそれぞれに接続することができる。サービングゲートウェイ１４４は一般に、ユーザデータパケットをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃへ／ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃから回送および転送することができる。サービングゲートウェイ１４４は、その他の機能、たとえば、ｅＮｏｄｅ Ｂ間のハンドオーバ中にユーザプレーンを固定すること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにとってダウンリンクデータが利用可能である場合にページングをトリガーすること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理および記憶することなどを実行することもできる。
サービングゲートウェイ１４４は、ＰＤＮゲートウェイ１４６に接続することもでき、ＰＤＮゲートウェイ１４６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、ＩＰ対応デバイスとの間における通信を容易にするために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。
コアネットワーク１０６は、その他のネットワークとの通信を容易にすることができる。たとえば、コアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、従来の地上通信線の通信デバイスとの間における通信を容易にするために、ＰＳＴＮ１０８などの回路交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。たとえば、コアネットワーク１０６は、コアネットワーク１０６と、ＰＳＴＮ１０８との間におけるインターフェースとして機能するＩＰゲートウェイ（たとえば、ＩＭＳ（ＩＰ ｍｕｌｔｉｍｅｄｉａ ｓｕｂｓｙｓｔｅｍ）サーバ）を含むことができ、またはそうしたＩＰゲートウェイと通信することができる。加えて、コアネットワーク１０６は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができ、ネットワーク１１２は、その他のサービスプロバイダによって所有および／または運営されているその他の有線またはワイヤレスのネットワークを含むことができる。
本明細書に記載されている通信システムおよびデバイスは、通信デバイスのソフトウェアを管理するために、通信デバイスの構成を管理するために、ならびに／または、デバイスを元の状態に戻すためのソフトウェアおよび／もしくは構成の情報の修復を提供するために使用することができる。ソフトウェアツール、ネットワークプロトコル、デバイスポリシーおよびソフトウェア管理、ならびに／またはリモートデバッギングの技術の使用を通じた信頼済みコードベースのソフトウェアの側面の参照の自動的な生成および管理を通じた証明可能な報告および修復のためのメカニズムおよび参照をデバイス内に組み込むことができるソフトウェア開発およびコードリリースツールを使用するための実施態様も、本明細書に記載されている。障害を報告するためにデバイスを信頼することができる旨の指示の記述を含む、デバイスによるインテグリティーチェックの障害の指示を保証することができる技術が、本明細書にさらに記載されている。
本明細書に記載されているように、ワイヤレス通信デバイスは、マルチステージセキュアブートプロセス（ｍｕｌｔｉ−ｓｔａｇｅ ｓｅｃｕｒｅ ｂｏｏｔ ｐｒｏｃｅｓｓ）のそれぞれのステージにおいてインテグリティーチェックを実行するように構成することができる。マルチステージセキュアブートプロセス中に、それぞれのステージは、次のステージを検証することができ、それによって、信頼の連鎖が生じる。マルチステージセキュアブートプロセスのそれぞれのステージ中に、そのステージに関連付けられているコンポーネントを信頼することができるかどうかの判定を行うことができる。コンポーネントに関連付けられているインテグリティー測定値を測定することができる。コンポーネントは、関連付けられている信頼済み基準値を有することができる。コンポーネントの信頼性は、インテグリティー測定値を、信頼済み基準値と比較することによって、判定すること（たとえば、テストすること）ができる。インテグリティー測定値が、信頼済み基準値と一致する場合には、コンポーネントは、信頼できるとみなすことができる。インテグリティー測定値が、信頼済み基準値と一致しない場合には、コンポーネントは、信頼できない可能性がある。インテグリティー測定値を、信頼済み基準値と比較することによって、インテグリティーチェックを実行することができるということが、本明細書に記載されているが、インテグリティーチェックは、コンポーネントの信頼性を判定するためのその他の方法で実行することもできるということがわかるであろう。
コンポーネントは外部エンティティーによって認識することができないため、機能は、たとえば標準仕様に準拠するように、および／または実施態様独自の様式で、複数のネットワークおよび／またはデバイスにわたって定義および／または標準化することができる。コンポーネントは、機能に関連することができる。コンポーネントと機能との間における関係は、コンポーネントから機能へのマップにおいて提供することができる。機能障害は、障害の生じているコンポーネントを、コンポーネントから機能へのマップと比較することによって、識別することができる。
デバイスは、機能障害に関連付けられているアラームを外部エンティティーへ送信することができる。外部エンティティーは、障害の生じているコンポーネントを修正するかまたは置換するために使用することができる、機能に関連付けられている置換コードを特定することができる。すなわち、置換コードは、置換コンポーネントとすることができる。デバイスは、置換コンポーネントを受け取って、障害の生じているコンポーネントを置換コンポーネントと置換することができる。
セキュアブートプロセスは、妥当性確認手続のための基礎を提供することができる。不変のハードウェアＲｏＴ（ｒｏｏｔ ｏｆ ｔｒｕｓｔ）によって開始される信頼の連鎖は、ロードされた最初のコードの妥当性を検証することができる。ブートプロセスは、たとえば図２において示されているように、それぞれのステージが信頼の連鎖を通じて次のステージを検証するにつれて、継続することができる。
電源投入およびハードウェア初期化手続に続いて、デバイスは、たとえば図２において示されているように、セキュアブートプロセスを開始することができる。最初のＲｏＴは、ブートローダ２０２によって表すことができ、ブートローダ２０２は、ＲＯＭ内のセキュアなメモリ内に存在することができる。ＲＯＭブートローダ２０２は、はじめにいくつかの初期化機能を実行することができる。ＲＯＭブートローダ２０２は、（たとえば、外部メモリ内に存在する）第２ステージブートローダ２０４のインテグリティーを検証するために使用することができるセキュリティー証明書（たとえば、融合されたキー作成情報（ｆｕｓｅｄ ｋｅｙｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ））にアクセスすることができる。第２ステージローダ２０４は、自分のインテグリティーを確実にするために、ハードウェアまたはソフトウェアの暗号手段によるチェックを受けることができる。第２ステージローダ２０４の計算されたハッシュ測定値は、ＴＲＶ（ｔｒｕｓｔｅｄ ｒｅｆｅｒｅｎｃｅ ｖａｌｕｅ）測定値と比較することができ、ＴＲＶ測定値は、セキュリティー証明書によって署名すること、および外部メモリ内に格納することが可能である。計算された測定値が、署名されたＴＲＶと一致する場合には、第２ステージローダ２０４を検証して、内部メモリ（たとえば、ＲＡＭ）内にロードすることができる。ブートＲＯＭは、第２ステージローダ２０４のスタートにジャンプすることができ、信頼の連鎖は、継続することができる。検証プロセスの最初のステージにおける障害は、後続の検証が危うくされる可能性があることを示す場合がある（たとえば、最初のステージにおける障害は、信頼の連鎖における致命的な機能停止を示す場合がある）。検証プロセスの最初のステージにおいて示されている障害がある場合には、デバイスをシャットダウンすることができる。
第２ステージブートローダ２０４は、ＴｒＥ（ｔｒｕｓｔｅｄ ｅｘｅｃｕｔｉｏｎ ｅｎｖｉｒｏｎｍｅｎｔ）コードを、さらなるコードをチェックして内部メモリにロードすることができるコードとともに含むことができる。ＴｒＥは、さらなるインテグリティー基準値を計算して格納することができる信頼済み環境およびセキュアな格納エリアを確立することができる。ＴｒＥインテグリティーは、オペレーティングシステムおよび通信のコードをチェックすること、ロードすること、および／または始動することができる。信頼の連鎖は、それぞれのステージがチェックされてロードされるにつれて継続することができる（たとえば、図２において示されているボックス２０２、２０４、２０６、および２０８はそれぞれ、ステージを表すことができる）。たとえば、第２ステージローダ２０４は、ＯＳ／通信２０６および／またはデバイスソフトウェア２０８のインテグリティーを検証することができる。代替として、または追加として、ＯＳ／通信２０６が、デバイスソフトウェア２０８のインテグリティーを検証することもできる。ＯＳ／通信２０６は、ＯＳローダを含むことができる。一実施形態によれば、図２において示されているエンティティーは、信頼の連鎖を保持するために、実行の順に検証されること、および／または互いを検証することが可能である。
信頼の連鎖は、後続のプロセスをセキュアに検証する能力を有する実行プロセスによって保持することができる。検証プロセスは、暗号計算および／または信頼済み基準値の両方を使用することができる。セキュアでないメモリ内に存在するコードは、攻撃に対して弱くなる場合があり、ロードする前に検証することができる。第２ステージブートローダ２０４は、きめ細かい妥当性確認を伴わずに、残りのコードをバルク測定として検証することができる。測定された値が、モノリシックなブロックに関するＴＲＶと一致しない場合には、そのコードを信頼することはできず、そのコードをロードすることはできないと判定することができる。そのデバイスは、通信を行うことができない場合があり、その結果としては、高価なトラックロールまたは修正のためにデバイスを返送することを介したコードベース全体の修復が含まれる場合がある。
本明細書に記載されている方法、システム、および手段は、格納されているコードのより小さなコンポーネントの妥当性を確認すること、ならびに、どのコンポーネントに障害が生じているか、およびどれがリモートから修復可能かまたは修復可能でないかの詳細な説明を提供することをデバイスが行えるようにすることができる。このきめ細かい情報は、修復マネージャーにとって利用可能にすることができる。
障害の生じているどのコンポーネントをリモート修復可能とすることができるかを判定するポリシーを確立することができる。たとえば、デバイスがＴｒＥをチェックして通信コードの最小セットとともにロードした場合には、そのデバイスは、特定の障害の生じているコンポーネントの情報を識別して修復マネージャーに報告するために修復マネージャーのためのプロキシとして動作する機能を保持することができる。修復能力が存在し、デバイスのプロキシ機能の一部である場合には、後続のリモート修復手続を開始することができ、それによって、高価なオンサイトの個人的な更新の使用を減らすことができる。
一実施形態によれば、きめ細かい報告を可能にするために、実行可能イメージを分割して、その妥当性を確認することができる。実行可能イメージの生成は、複数のステージで行うことができる。コンポーネントは、サブルーチンおよび／またはパラメータ／データから構成されているファイルを参照することができる。開発者は、コンポーネントソースファイルおよびヘッダファイル内に取り込まれたプログラムを書くことができる。これらのコンポーネントソースファイルから、コンパイラおよびアセンブラは、マシンバイナリーコードおよびプログラムデータの両方を含むオブジェクトファイル（たとえば、＊．ｏ）を生成することができる。リンカーは、これらのオブジェクトファイルを入力として受け取り、実行可能イメージまたはオブジェクトファイルを生成することができ、このオブジェクトファイルは、その他のオブジェクトファイルとさらにリンクするために使用することができる。リンカーコマンドファイルは、オブジェクトファイルどうしをどのようにして結合するか、ならびにバイナリーコードおよびデータをターゲット組み込みシステム内のどこに配置するかをリンカーに指示することができる。
リンカーの機能は、複数のオブジェクトファイルを結合して、より大きな再配置可能なオブジェクトファイル、共有オブジェクトファイル、または最終的な実行可能イメージにすることであると言える。グローバル変数および静的でない機能は、グローバルシンボルと呼ばれる場合がある。最終的な実行可能バイナリーイメージにおいては、シンボルは、メモリ内のアドレスロケーションを参照することができる。このメモリロケーションの内容は、変数のためのデータまたは機能のための実行可能コードとすることができる。
コンパイラは、自分が生成するオブジェクトファイルの一部としてアドレスマッピングに対するシンボル名を有するシンボルテーブルを作成することができる。再配置可能な出力を生成する際に、コンパイラは、それぞれのシンボルごとに、コンパイルされているファイルに関連するアドレスを生成することができる。リンカーによって実行されるリンキングプロセスは、シンボルレゾリューションおよび／またはシンボルリロケーションを含むことができる。シンボルレゾリューションとは、リンカーがそれぞれのオブジェクトファイルを通って、そのオブジェクトファイルに関して、どの（他の）１つまたは複数のオブジェクトファイルの中で外部シンボルが定義されているかを判定するプロセスであると言える。シンボルリロケーションとは、リンカーがシンボル参照をその定義にマップするプロセスであると言える。リンカーは、リンクされているオブジェクトファイルのマシンコードを、シンボルへのコード参照が、それらのシンボルに割り当てられている実際のアドレスを反映するように、修正することができる。
オブジェクトおよび実行可能ファイルは、たとえばＥＬＦ（Ｅｘｅｃｕｔａｂｌｅ ａｎｄ Ｌｉｎｋｉｎｇ Ｆｏｒｍａｔ）およびＣＯＦＦ（Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ−Ｆｉｌｅ Ｆｏｒｍａｔ）など、いくつかのフォーマットが可能である。オブジェクトファイルは、複数のエリアまたはセクションへと分割することができる。これらのセクションは、たとえば、実行可能コード、データ、動的リンキング情報、デバッギングデータ、シンボルテーブル、リロケーション情報、コメント、文字列テーブル、または注のうちの１つまたは複数を保持することができる。これらのセクションを使用して、バイナリーファイルに命令を提供し、検査を可能にすることができる。機能セクションは、システム機能のアドレスを格納することができるＧＯＴ（Ｇｌｏｂａｌ Ｏｆｆｓｅｔ Ｔａｂｌｅ）、ＧＯＴへの間接的なリンクを格納することができるＰＬＴ（Ｐｒｏｃｅｄｕｒｅ Ｌｉｎｋｉｎｇ Ｔａｂｌｅ）、内部の初期化のために使用することができる．ｉｎｉｔ／ｆｉｎｉ、ならびにコンストラクタおよびデストラクタのために使用することができる．ｓｈｕｔｄｏｗｎ、または．ｃｔｏｒｓ／．ｄｔｏｒｓのうちの１つまたは複数を含むことができる。データセクションは、読み取り専用データのための．ｒｏｄａｔａ、初期化されたデータのための．ｄａｔａ、または初期化されていないデータのための．ｂｓｓのうちの１つまたは複数を含むことができる。ＥＬＦセクションは、スタートアップのための．ｉｎｉｔ、文字列のための．ｔｅｘｔ、シャットダウンのための．ｆｉｎｉ、読み取り専用データのための．ｒｏｄａｔａ、初期化されたデータのための．ｄａｔａ、初期化されたスレッドデータのための．ｔｄａｔａ、初期化されていないスレッドデータのための．ｔｂｓｓ、コンストラクタのための．ｃｔｏｒｓ、デストラクタのための．ｄｔｏｒｓ、グローバルオフセットテーブルのための．ｇｏｔ、または初期化されていないデータのための．ｂｓｓのうちの１つまたは複数を含むことができる。
いくつかのセクションは、プロセスイメージへとロードすることができる。いくつかのセクションは、プロセスイメージをビルドする際に使用することができる情報を提供することができる。いくつかのセクションは、オブジェクトファイルどうしをリンクする際の使用に限定することができる。いくつかのオブジェクトファイルは、その他のオブジェクトファイル内に配置されているシンボルへの参照を含むことができる。リンカーは、それぞれのオブジェクトファイルごとにテキストおよびデータのセグメント内のシンボル名およびそれらの対応するオフセットのリストを含むことができるシンボルテーブルを作成することができる。オブジェクトファイルどうしをリンクした後に、リンカーは、満たされていない可能性があるレゾルブされていないシンボルアドレスを見つけ出すためにリロケーションレコードを使用することができる。複数のソースファイル（たとえば、Ｃ／Ｃ＋＋ファイルおよびアセンブリファイル）がＥＬＦオブジェクトファイルへとコンパイルおよびアセンブルされた後に、リンカーは、たとえば、図３において示されているように、これらのオブジェクトファイルを結合し、別々のオブジェクトファイルからのセクションどうしをマージしてプログラムセグメントにすることができる。
図３において示されているように、オブジェクトファイル３０２、３０４、および３０６のテキストセクション３０８、３１６、および３２４をそれぞれマージして、実行可能イメージ３３８のテキストセグメント３３２にすることができる。追加として、または代替として、スタートアップセクション３１０、３１８、および３２６をマージして、実行可能イメージ３３８のテキストセグメント３３２にすることができる。同様に、オブジェクトファイル３０２、３０４、および３０６のデータセクション３１２、３２０、および３２８をそれぞれマージして、実行可能イメージ３３８のデータセグメント３３４にすることができる。最後に、オブジェクトファイル３０２、３０４、および３０６の初期化されていないデータセクション３１４、３２２、および３３０をそれぞれマージして、実行可能イメージ３３８の初期化されていないデータセグメント３３６にすることができる。図３は、マージして実行可能イメージ３３８内のセグメントにすることができるオブジェクトファイル３０２、３０４、および３０６のある数のセクションを示しているが、任意の数および／または組合せのセクションをマージして実行可能イメージのセグメントにすることができるということを理解されたい。
図３において示されているように、セグメントは、関連したセクションどうしをグループ化する方法を提供することができる。それぞれのセグメントは、同じまたは異なるタイプの１つまたは複数のセクション（たとえば、テキストセクション、データセクション、または動的なセクション）を含むことができる。オペレーティングシステムは、プログラムヘッダテーブルにおいて提供される情報に従ってファイルのセグメントを論理的にコピーすることができる。実行可能データセクションおよび読み取り専用データセクションを結合して、単一のテキストセグメントにすることができる。データセクションおよび初期化されていないデータセクションを結合して、データセグメントに、またはそれら自体の個々のセグメントにすることができる。これらのセグメントは、プロセスの作成時にメモリ内にロードすることができるため、ロードセグメントと呼ばれる場合がある。シンボル情報セクションおよびデバッギングセクションなどのその他のセクションどうしをマージして、その他の非ロードセグメントにすることができる。テキストセクションは、初期化された静的変数とともにソースコードを含むことができる。コンパイラによって定義された複数のセクションを、リンカーによって定義された単一の結合されたセグメントへとロードすることができる。
最終的な実行可能イメージは、リンカーがセクションどうしをどのように結合するか、および／またはセグメントをターゲットシステムメモリマップへどのように割り当てるかを制御するためのリンカーコマンド（リンカーディレクティブと呼ばれる場合もある）を使用して生成することができる。リンカーディレクティブは、リンカーコマンドファイル内に保持することができる。組み込み開発者は、リンカーコマンドファイルを使用して、実行可能イメージをターゲットシステムへとマップすることができる。
障害の生じているコンポーネントの妥当性確認およびきめ細かい報告を実行する能力は、実行可能イメージ内で利用可能なさらなる情報を使用することができ、開発およびコードリリースツールチェーン（ｄｅｖｅｌｏｐｍｅｎｔ ａｎｄ ｃｏｄｅ ｒｅｌｅａｓｅ ｔｏｏｌ ｃｈａｉｎｓ）に対する修正が存在することが可能である。それぞれのコンポーネントごとの基準測定値、ならびにその測定値がどのコンポーネントに関連付けられているかを識別する情報要素は、実行可能イメージ内で識別可能とすることができる。
障害の生じているコンポーネントの修復は、標準的機能障害を報告するデバイスの能力に依存することができる。機能、ならびに障害に基づいて取るべきアクションは、ネットワークオペレータによって定義することができる。ソフトウェア開発者は、オペレータによって定義された機能を自分のシステム内のソフトウェアコンポーネントにどのようにマップすることができるかを判定することができる。機能マッピングは、実行可能イメージ内で可視とすることができ、ツールチェーンの機能強化を使用することができる。
開発フェーズ中に使用されるソフトウェアツールチェーンは、コンポーネントセクションの生成、ＴＲＶのセキュアな生成および組み込み、コンポーネントから機能への定義の挿入、またはポリシーおよびポリシー構成ファイルの挿入のうちの１つまたは複数に対応するように修正することができる。
ローダ機能は、妥当性確認および／または修復に対応するように修正することができる。ローダは、コンポーネントがロードされる際にそれらのコンポーネントのインテグリティーチェックを実行すること、障害の生じているコンポーネントを隔離もしくはアンロードすること、ポリシーを管理すること、またはポリシーマネージャーが障害を報告するために、障害の生じているコンポーネントのＩＤをメモリ内に格納することのうちの１つまたは複数を行うように修正することができる。
所望の機能を例示するために本明細書に記載されているソフトウェア開発およびコードリリースツールチェーンに適用することができる例示的な実施形態が、本明細書に記載されている。しかし、それらの実施形態は、本明細書において提供されている例に限定されるものではない。
リンカーの役割は、入力オブジェクトを受け取り、さまざまなセクションを結合してセグメントにすることであると言える。オブジェクトコードはリンキングプロセス中に結合することができるため、オブジェクトファイル内の機能または変数を識別する能力は、シンボルテーブル情報内に保持することができる。結果として得られるマージされたコードセクションは、本明細書に記載されているような妥当性確認手続をトリガーするために使用することができる妥当性確認スキームを提供することができない。
個々のコンポーネントの識別を容易にするために、ローダは、どこでコードが始まったかを識別するための方法を有することができ、これは、コンポーネントを定義すること、またはローダによって識別することができる個々のコンポーネントに関するＴＲＶを生成することを含むことができる。実行可能イメージを生成するために使用されるツールチェーンは、たとえば、特定のコンポーネントを識別してインテグリティーチェックを実行するためのローダ妥当性確認機能のための特定のオブジェクトファイルコンポーネントに関連付けられているコードを識別できるように機能強化することができる。コードイメージを再構成することによって、入力オブジェクトに関するＴＲＶを変更することができる（たとえば、１つの入力オブジェクトを修正することによって、結果として、その他の入力オブジェクトに関するＴＲＶを変更することができる）。ＴＲＶの変更を除外するための最適化方法を使用することから、このツールチェーンを除外することができる。
インテグリティーチェックにとって望ましい可能性があるコンポーネントのために特定のセクション名を生成することができる。そのセクション名は、たとえば最終的なＥＬＦ実行可能ファイル内に含まれているセクションヘッダテーブル内に現れることができる。ユーザ定義セクションをグループ化することによって、ローダは、コンポーネントを識別し、インテグリティーチェックを実行することができる。ローダは、コンポーネントの合格または不合格のステータスをポリシーマネージャーに報告することができる。インテグリティーチェックに合格／不合格になっている特定の機能を分離することは、ポリシーマネージャーが、障害の生じているコンポーネントによって影響を受ける可能性がある機能をきめ細かいまたは詳細なレベルで報告することを可能にすることができる。
図４は、単一の実行可能イメージ４０６を形成するためにリンクすることができる２つのオブジェクトファイル４０２および４０４を示している。オブジェクトファイル４０２は、２つの別個のコードセグメント、コンポーネントファイルセクション４０８、およびテキストセクション４１０を有する。オブジェクトファイル４０４は、単一のコードセグメント、コンポーネントファイルセクション４１６を有し、コンポーネントファイルセクション４１６は、コードおよび／または定数データを含むことができる。ユーザ定義コードセクション、コンポーネントファイルセクション４０８、およびコンポーネントファイルセクション４１６は、自分がマップされるセグメントのタイプに関連するサイズおよび／またはメモリロケーションとともにセクションヘッダ内に表れることができる。そのようなマッピング関係の一例が、図４において矢印によって示されている。たとえば、オブジェクトファイル４０２のコンポーネントファイルセクション４０８、テキストセクション４１０、データセクション４１２、およびｂｓｓセクション４１４はそれぞれ、実行可能イメージ４０６のコンポーネントファイルセクション４２０、テキストセクション４２４、データセクション４２６、およびｂｓｓセクション４２８にマップすることができる。同様に、オブジェクトファイル４０４のコンポーネントファイルセクション４１６およびｂｓｓセクション４１８はそれぞれ、実行可能イメージ４０６のコンポーネントファイルセクション４２２およびｂｓｓセクション４２８にマップすることができる。実行可能イメージ４０６は、ユーザ定義セクションを、事前に定義されたロケーションの実行可能イメージ４０６の始まりに含むようにリンクすることができ、したがって、それらのセクションを順次チェックすることができる。妥当性確認によるインテグリティーに関するチェックは、コードベースのサブセットに限定することができる。より大きなテキストセグメントへとグループ化される残りのコードは、インテグリティーチェックされないことが可能であり、および／またはロードされることが可能である。
ユーザ定義セクションの追加は、たとえば、＃ＰＲＡＧＭＡをコンポーネントコード内に挿入することによって、識別可能にすることができる。図４の例をさらに参照すると、命令＃ＰＲＡＧＭＡセクション（たとえば、コンポーネントファイルセクション４０８）をソースファイルの最上部に挿入することができる。コンパイラフラグによってユーザ定義セクションを含むようにコンパイラを機能強化することができる。特定のフラグが設定された場合にＰＲＡＧＭＡを自動的に挿入するようにコンパイラを機能強化することができる。ユーザ定義セクションが、コンポーネント内のインテグリティーチェック可能な機能に制限されるように、ユーザ定義セクションのコンセプトを拡張することができる。デバイスの信頼済み実行のために使用することができる機能は、スタートアッププロセスの最初または早期にインテグリティーチェックすることができるコンポーネントへと分割または分離することができる。
セクションは、リンカーコマンドファイルを介してメモリの特定のセグメントにマップすることができる。ＥＬＦオブジェクトは、ソースアドレスおよびデスティネーションアドレスの点から見ることができる。セクションヘッダテーブルにおいて識別されるセクションは、移動するコードおよび／またはデータの始まりがどこで見つかるかをローダに知らせることができる。セグメントヘッダにおいて識別されるセグメントは、コンポーネントをコピーする場所をローダに知らせることができる。セクションヘッダおよびプログラムヘッダのフォーマットが、下に示されている。
セクションヘッダ プログラムヘッダ
typedef struct { typedef struct {
・ Elf32_Word sh_name; ・ Elf32_Word p_type;
・ Elf32_Word sh_type; ・ Elf32_Off p_offset;
・ Elf32_Word sh_flags; ・ Elf32_Addr p_vaddr;
・ Elf32_Addr sh_addr; ・ Elf32_Addr p_paddr;
・ Elf32_Off sh_offset; ・ Elf32_Word p_filesz;
・ Elf32_Word sh_size; ・ Elf32_Word p_memsz;
・ Elf32_Word sh_link; ・ Elf32_Word p_flags;
・ Elf32_Word sh_info; ・ Elf32_Word p_align;
・ Elf32_Word sh_addralign;
} Elf32_Phdr;
・ Elf32_Word sh_entsize;
} Elf32_Shdr;
セクションヘッダ プログラムヘッダ
typedef struct { typedef struct {
・ Elf32_Word sh_name; ・ Elf32_Word p_type;
・ Elf32_Word sh_type; ・ Elf32_Off p_offset;
・ Elf32_Word sh_flags; ・ Elf32_Addr p_vaddr;
・ Elf32_Addr sh_addr; ・ Elf32_Addr p_paddr;
・ Elf32_Off sh_offset; ・ Elf32_Word p_filesz;
・ Elf32_Word sh_size; ・ Elf32_Word p_memsz;
・ Elf32_Word sh_link; ・ Elf32_Word p_flags;
・ Elf32_Word sh_info; ・ Elf32_Word p_align;
・ Elf32_Word sh_addralign;
} Elf32_Phdr;
・ Elf32_Word sh_entsize;
} Elf32_Shdr;
ｓｈ＿ａｄｄｒは、ターゲットメモリ内でプログラムセクションが存在することができるアドレスであると言える。ｐ＿ｐａｄｄｒは、ターゲットメモリ内でプログラムセグメントが存在することができるアドレスであると言える。ｓｈ＿ａｄｄｒフィールドおよびｐ＿ｐａｄｄｒフィールドは、ロードアドレスを参照することができる。ローダは、セクションヘッダからのロードアドレスフィールドを、不揮発性メモリからＲＡＭへのイメージ転送のための開始アドレスとして使用することができる。
コンポーネントセクション識別のコンセプトを、１つのファイル内に含まれている複数の特定のコンポーネントへ拡張することが可能である場合がある。そのような拡張は、１つの完全なファイルよりも、インテグリティーに関してチェックされることになる特定のサブルーチンの識別を通じたポリシーマネージャーによるアクセス制御のさらなるきめ細かさを可能にすることができる。
ＴＲＶは、特定のコンポーネントまたはオブジェクトファイルの予測された測定値（たとえば、セキュアな方法で計算されたコンポーネントのハッシュ）であると言える。妥当性確認プロセスは、たとえば、実行可能イメージ内に存在することをチェックされることになる、またはインテグリティー検証の目的からセキュアな方法で別途ロードされることになるそれぞれのコンポーネントごとのＴＲＶに依存することができる。これは、多くの方法で達成することができる。例として、実行可能イメージをビルドするツールチェーンを修正して、コンポーネントまたはオブジェクトファイルのハッシュ値をセキュアに計算すること、および計算されたＴＲＶを同じオブジェクトファイルの適切なセクション内にセキュアに挿入することが可能である。この計算は、リンキングプロセスの一環として実行することができる。ＴＲＶハッシュが計算される順序は、コンポーネントがロードされて測定されることになる順序と一致することができ、さもなければ、測定値どうしは、正しく一致することができない。ハッシュ値は、ローダにとって利用可能であること、または実行ファイル内に含まれることが可能である。信頼の連鎖を保持するために、ＴＲＶをセキュアに生成および／または格納することができる。たとえば、公開キー、例としてはソフトウェア／ファームウェアの製造業者の公開キーなどに対応する秘密キーを用いて、ＴＲＶ値に署名することによって、ＴＲＶを保護することができる。
コンポーネントオブジェクトファイルは、図５において示されているように自分の関連付けられているＴＲＶのためのプレースホルダとして別個のユーザ定義セクションを含むことができる。たとえば、図５において示されているように、コンポーネントオブジェクトファイル４０８のＴＲＶを計算して、コンポーネントＴＲＶセクション５０２内に格納することができる。セクションヘッダは、本明細書に記載されているユーザ定義セクションを含むことができるセクションの開始アドレスおよび／またはサイズを識別することができる。オブジェクトファイル４０２において、リンカーは、シンボルレゾリューションフェーズの終わりにコンポーネントオブジェクトファイル４０８のハッシュ値を計算し、対応するコンポーネントＴＲＶセクション５０２を特定することができる。コンポーネントＴＲＶをメモリ内の指定されたロケーション（たとえば、コンポーネントＴＲＶセクション）において実行可能イメージ内に挿入することができる。セクションヘッダは、ローダが、妥当性確認プロセス中に特定のセクションに関するＴＲＶを特定することを可能にすることができる。
本明細書において説明する際、デバイスの妥当性確認は、コンポーネントのインテグリティーステータスに焦点を合わせることができる。障害の生じているコンポーネントの報告を標準化することは困難である場合がある。なぜなら、ソフトウェアの開発慣行は、企業ごとに異なる場合があるためである。
本明細書において開示されているのは、コンポーネントが実行する機能に関してそれらのコンポーネントをグループ化する方法を標準化するためのシステム、方法、および手段である。機能は、標準仕様に準拠するように、および／または実施態様独自の様式で、標準化することができる。標準化することができるデバイス機能に関して、機能のリストを事前に定義することができる。機能とコンポーネントとの間における参照を使用して、インテグリティーチェック中に見つかった障害を報告のための特定の機能にマップすることを可能にすることができ、その一例が、図６において示されている。
図６において示されているように、信頼済みドメイン６０２は、互いにマップするコンポーネントおよび機能を含むことができる。たとえば、信頼済みドメイン６０２は、ハイレベル機能６０４、中間機能６０６、および／またはＴｒＥ（ｔｒｕｓｔｅｄ ｅｎｖｉｒｏｎｍｅｎｔ）コア機能６０８を含むことができる。ハイレベル機能６０４は、機能６１０および機能６１２を含むことができる。中間機能６０６は、機能６１４および機能６１６を含むことができる。ＴｒＥコア機能６０８は、たとえばＲｏＴなどの機能６１８を含むことができる。機能６１２は、コンポーネント６２０および／または６２２にマップすることができ、コンポーネント６２０および／または６２２は、たとえばソフトウェアコンポーネントとすることができる。機能６１６は、コンポーネント６２４にマップすることができ、コンポーネント６２４も、たとえばソフトウェアコンポーネントとすることができる。機能６１８は、コンポーネント６２６にマップすることができ、コンポーネント６２６は、たとえばファームウェアコンポーネントとすることができる。信頼済みドメイン６０２のインテグリティーチェック中に、コンポーネント６２４において障害を判定することができる。コンポーネント６２４は機能６１６にマップしているため、ネットワーク機能６１６にも障害が生じていると判定することができる。結果として、デバイスは、障害の生じている機能６１６の指示を修復のためにネットワークへ送信することができる。
図６における機能とコンポーネントとの間におけるマッピングは、実施層マッピング（ｅｎｆｏｒｃｅｍｅｎｔ ｌａｙｅｒ ｍａｐｐｉｎｇ）として示されている。代替として、または追加として、コンポーネントと機能との間におけるマップを行う図６において示されている実施形態は、複数の層を有することができる。２つの層（たとえば、一方はコンポーネント用であり、他方は機能用である）よりも多い層を有するデータ構造を使用することができる。そのような構造においては、コンポーネントは、サブ機能のセットにマップすることができ、サブ機能は、さらにいっそう高いレベルのサブ機能のセットにマップすることができる。中間マッピングは、最終的なサブ機能層におけるサブ機能が、最終的な層における最終的な機能にマップされるまで、続くことができる。ツリーデータ構造またはツリーのようなデータ構造は、そのような多層のコンポーネントから機能へのマッピング関係を取り込むことができる構造の一例であると言える。
開発者は、コンポーネントが、標準化された機能にどのようにマップするかを判定することができる。一実施形態によれば、実行可能イメージは、コンポーネントから機能へのマッピングを含むことができる。これは、たとえば、コンパイルされたコードまたはソースコードを解析し、個々のファイルレイアウト、ファイル内の機能どうしの相互依存関係のうちの１つまたは複数を示し、コンポーネントから機能へのマッピングを可能にするグラフィカルツールを通じて、コンパイル時に達成することができる。機能は、テキストのフィールドおよび／または短縮されたＩＤ番号とすることができ、それは、ユーザによって入力すること、および／またはコンポーネント／ファイルに手動でマップすることが可能である。開発ツールは、コンポーネントから機能へのマッピングテーブルを参照するセクションを作成することができる。コンポーネント名、機能名、およびＩＤを、クロスリファレンスの相互のつながり（ｃｒｏｓｓ−ｒｅｆｅｒｅｎｃｅ ｉｎｔｅｒ−ｃｏｎｎｅｃｔ）とともに、テーブルの要素として含めることができる。
図７は、コンポーネントから機能へのマッピングを含むセクションの一例を示している。図７において示されているように、機能からコンポーネントへのマッピングセクション７０２は、たとえばオブジェクトファイル４０２などのオブジェクトファイル内の１つのセクションとして含めることができる。機能からコンポーネントへのマッピングセクション７０２は、本明細書において説明する際には、実行可能イメージ内の対応するセグメントにリンクすることもできる。
ローダの機能は、コードを外部から内部メモリへ持ってくることであると言える。信頼の連鎖は、コードのそれぞれのロードされるステージが、ＲｏＴから始まる前のステージおよびブートローダによって検証されていることに依存することができる。第２ステージローダは、次のステージを検証することができ、次のステージは、信頼済み環境およびＯＳローダのコアを含むことができる。ＯＳが初期化されて実行されると、残りのインテグリティーチェックは、標準ＯＳローダによって、本明細書に記載されているように実行することができる。実行可能イメージは、キャッシュに格納せずにＲＡＭへロードすることができる。本明細書において開示されているこれらのコンセプトは、実行可能イメージが、さらなる修正を伴って利用可能なＲＡＭよりも大きい、より制約の多い実施態様、たとえば、キャッシュメモリを使用することができる実施態様、およびコードを直接ＲＯＭから実行することができる実施態様などを含むように拡張することができる。
コードを外部から内部メモリへ持ってくるローダは、暗号インテグリティーチェックを実行する能力を含むことができる。インテグリティーチェックは、信頼済み環境内にセキュアに保持することができる暗号機能を遡って参照することができる。通常のオペレーションのもとで、ローダは、結合されたテキストセクション（たとえば、テキストセクション４１０）およびデータセクション（たとえば、データセクション４１２）内のコードおよびデータを、リンカーコマンドスクリプトおよびセグメントヘッダ情報によって定義されているように内部メモリへコピーすることができる。テキストセクション４１０およびデータセクション４１２をバルクロードする代わりに、ローダは、コードおよび／またはデータのユーザ定義セクションを識別することができる。この補足セクション情報のうちのいくつかは、インテグリティーチェックのために使用することができる。ローダは、コンポーネントに関するインテグリティー測定値を計算し、次いでそのコンポーネントに関するＴＲＶをその関連付けられているセクション内で特定することができる。セクションヘッダは、セクションの開始アドレスおよびサイズを提供することができる。測定された値は、同じコンポーネントに関する格納されたＴＲＶと比較することができる。それらの値が一致した場合には、コードを内部メモリへロードすることができる。それらのインテグリティー測定値が一致しない場合には、コードをロードすることはできず、障害をそのコンポーネントに関して記録すること、および／またはポリシーマネージャーに報告することが可能である。
それぞれのコンポーネントに関するローダの検証結果は、そのコンポーネントがチェック済みであることならびに合格または不合格のビット指示を示すビットフィールド内に格納することができる。コード全体が内部メモリに移された場合には、ポリシーマネージャーは、完了したインテグリティーチェックの結果に基づいてどんなアクセスをデバイスに許可するかを判定することができる。これを達成するための１つの方法は、ローダが、インテグリティー結果を追跡把握するためにセキュアなメモリロケーションにアクセスできるようにすることである。ＰＬＴ（ｐｒｏｃｅｄｕｒｅ ｌｉｎｋａｇｅ ｔａｂｌｅ）は、コンポーネントのインテグリティーがチェック済みおよび検証済みであるかどうかを追跡把握するためのさらなる情報要素で機能強化することができ、そのインテグリティーチェックの結果およびその情報は、それぞれのチェックされたコンポーネントが内部のＲＡＭへロードされるにつれて更新することができる。
限られたメモリを有する組み込みシステムにおいては、コードスワッピングを使用することができる。コードスワッピングは、実行のために使用することができる機能をＲＡＭ内へロードすることを含むことができる。サブコンポーネントが使用される場合に、そのサブコンポーネントのアドレスがＲＡＭにおいて利用可能でないならば、そのアドレスを特定するためにＰＬＴおよびＧＯＴテーブルを使用することができる。サブコンポーネントは、関連付けられているＴＲＶを有するさらに大きなコンポーネントの小さな一部分であると言える。サブコンポーネントがロードされるにつれてそれらのサブコンポーネントを動的にチェックするシステムにおいては、１つのサブコンポーネントがロードされることになるたびに、コンポーネント全体のインテグリティーチェックが使用される場合がある。そのような必要性は、システム上に不必要な計算負荷を加える場合がある。
コンポーネントは、そのサブコンポーネントへと分割することができ、それぞれのサブコンポーネントごとのインテグリティーをチェックするために使用することができる中間ＴＲＶを計算することができる。さらに、中間ハッシュを計算するために、最小ブロックサイズを実装することができる。サブコンポーネントのＴＲＶハッシュ生成のこのプロセスは、ＴＲＶダイジェスチョン（ＴＲＶ ｄｉｇｅｓｔｉｏｎ）と呼ばれる場合がある。たとえば、小さなサブコンポーネントハッシュをメモリページブロックサイズに基づいて計算することができる。このようにコンポーネントをサブコンポーネントへと分割することは、コンポーネントが、たとえばインストレーションまたはスタートアッププロセスの一環としてインテグリティーチェックされる場合に、行うことができる。ＧＯＴは、それぞれのサブコンポーネントの中間ＴＲＶを含むように機能強化することができる。
ＰＩＰＥ（Ｐｌａｔｆｏｒｍ Ｉｎｔｅｇｒｉｔｙ Ｐｏｌｉｃｙ Ｅｎｇｉｎｅ）は、全体的なプラットフォームトラストシステムアーキテクチャー（ｏｖｅｒａｌｌ ｐｌａｔｆｏｒｍ ｔｒｕｓｔ ｓｙｓｔｅｍ ａｒｃｈｉｔｅｃｔｕｒｅ）の一部であると言える。たとえば、ＰＩＰＥは、ネットワークが攻撃されること、デバイスが誤用されること、機密データが不正な方法でプラットフォーム上において通信または操作されることのうちの１つまたは複数を防止することができる。ＰＩＰＥは、ブートローダ、ポリシーマネージャー、および仮想化コンポーネントなどのさまざまなオペレーティングシステム機能に依存して、セキュアな信頼できるプラットフォームを制御および作成することができる。ＰＩＰＥは、セキュアブートプロセスのフロー、ソフトウェアコンポーネント上でのインテグリティーチェック測定値の処理、ポリシーに従ったその後の実施アクション、および／またはその後のソフトウェアロード制御のフローを含むさまざまな機能を制御することができる。ポリシーは、製造業者またはオペレータなどの外部利害関係者によって定義することができ、デバイス上に提供することができる。ポリシーは、リモート更新手続を通じてフィールド内で更新することができる。
ＰＩＰＥは、制御されたソフトウェアデータチェックおよびロードオペレーション、より機能的な能力を漸進的にインストールすること、またはランタイム中のコンポーネントの動的なローディングを保持することのうちの１つまたは複数を通じて、危うくされたソフトウェア機能がロードされるリスクを減らすことができる。ローディングオペレーションにおける漸進のステージに応じて、アクションは、プラットフォームのパワーダウン、（１つもしくは複数の）危うくされたコンポーネントのローディングを防止すること、または（１つもしくは複数の）コンポーネントを隔離すること、低いレベルの障害もしくは危うくされた機能を通知するためにネットワーク内のセキュリティーゲートウェイもしくは修復マネージャーなどの外部エンティティーへのアラームをトリガーすること、プラットフォーム上のセキュアな情報、たとえば認証キーなどへのアクセスを防止すること、プラットフォーム上のセキュアな機能、たとえば認証アルゴリズムなどへのアクセスを防止すること、バルクコードもしくはデータリロード／更新手続を実行すること、危うくされたソフトウェアコンポーネントおよび／もしくは構成データを置換すること、または改ざんの疑いがあるコンポーネントをより詳細に調査して（よりきめ細かい詳細を伴うインテグリティーチェックを含む）、そのコンポーネントにおける障害のロケーションを分離することのうちの１つまたは複数を含むことができる。
いくつかのケースにおいては、コアＴｒＥ機能が危うくされたために、信頼済み環境でさえ、プラットフォームにおける信頼を保証できないことがあるほど、障害が深刻である場合がある。低いレベルの障害は、インテグリティーおよびリプレイ保護ならびにコンフィデンシャリティー保護を含むことができる、デフォルトのルートオブトラスト署名済みアラームメッセージ（ｄｅｆａｕｌｔ ｒｏｏｔ−ｏｆ−ｔｒｕｓｔ ｓｉｇｎｅｄ ａｌａｒｍ ｍｅｓｓａｇｅ）を生成することなどの初歩的なオペレーションをトリガーすることができる。すなわち、クリティカルな低いレベルのセキュリティー障害が発生すると、利用可能とすることができる１つまたは複数の通信チャネルによって障害メッセージをネットワークにリリースすることができる。
ロードされた機能がビルドされて、ますます洗練されるにつれて、デバイスは、ネットワークエンティティーのためにセキュアな信頼できるプロキシとして機能することなど、さらに洗練されたアクションを実行することができ、それによって、危うくされたソフトウェアまたは構成データを診断し、報告し、および／または置換するための問合せ的な手続（ｉｎｔｅｒｒｏｇａｔｉｖｅ ｐｒｏｃｅｄｕｒｅ）を容易にすることができる。
成功裏に検証された機能のレベルに応じて、プラットフォーム上のリソースへのさまざまなアクセスを（たとえば、ＰＩＰＥによって）提供することができる。コンポーネントのインテグリティーチェックの結果、障害がある場合には、そのコンポーネントを信頼することはできない。この検知された障害は、セキュアにマークしてネットワークに（明示的にまたは黙示的に）示すことができ、ブートフローは、この障害の生じている状況に起因して分岐することができる。このタイプのインテグリティーチェック障害は、実行フロー障害と呼ばれる場合があり、これによって、チェックされたコンポーネントは信頼できないとすることができ、このコンポーネントを始動させると、悪意のある、危うくされた、障害の生じている、または誤って構成されたコードを実行する結果になる可能性があり、それによってデバイスは、ネットワーク機能を、指定されていないおよび／または予測されていない方法で実行することになる可能性がある。したがって、新たなコンポーネントおよび利用可能な機能をロードすることは、それまでにロードされたコンポーネントのインテグリティーによって影響を受ける可能性がある。
結果として、実行環境は、それぞれのブートステージおよびそれぞれのランタイムプロセスにおける制御実行プロセスおよび／またはアクセス特権に応じて変化する可能性がある。たとえば、ブートプロセスにおけるそれぞれのステージでは、その時点で行われたインテグリティー測定に基づいて判定を行うことができる。その後のステージおよびポリシーは、自分自身のオペレーションを判定するために、実行ステージを越えて情報を伝達または格納する任意の利用可能な保護された手段（状態、変数、パラメータ、レジスタ、ファイルなど）を通じて前のステージから渡された情報を使用することができる。たとえば、上位層アプリケーション認証機能は、たとえば外部エンティティーを成功裏に認証するのに使用されたキーのリリースのゲーティング（ｇａｔｉｎｇ）を含めて、自分自身のオペレーションを判定するために、それまでにロードされたコンポーネントのインテグリティーに関する情報を使用することができる。
例示的なＰＩＰＥ機能フローを、本明細書に記載されているように実行することができる。たとえば、ＲｏＴをインテグリティーチェックすることができ、および／またはそのインテグリティーを検証することができる。ベースラインＴｒＥ（ｂａｓｅｌｉｎｅ ＴｒＥ）をＲｏＴによってインテグリティーチェックすることができ、および／またはそのインテグリティーを検証することができる。ベースラインＴｒＥのインテグリティーチェックおよび／または検証において障害がある場合には、ＰＩＰＥは、ネットワークへの接続のために使用されたキーのリリースを防止すること、ネットワークへのアラームをトリガーすること、および／またはデバイスをパワーダウンすることが可能である。ＰＩＰＥがネットワークへのアラームをトリガーした場合には、そのアラームがネットワークへ送信されることを可能にすることができるフォールバックコードをロードすることができる。アラームは、ＴｒＥを置換するためのリモートバルク更新手続をトリガーすることができる。
ベースラインＴｒＥのインテグリティーチェックおよび／または検証において障害がない場合には、基本通信接続コードをロードすることができる。これは、ベースラインオペレーティングシステムモジュール（ｂａｓｅｌｉｎｅ ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ ｍｏｄｕｌｅ）のインテグリティーチェックおよびローディングを実行すること、ベースラインマネージメントクライアント（ｂａｓｅｌｉｎｅ ｍａｎａｇｅｍｅｎｔ ｃｌｉｅｎｔ）のインテグリティーチェックおよびローディングを実行すること、ならびに／または通信モジュールのインテグリティーチェックおよびローディングを実行することを含むことができる。オペレーティングシステムモジュール、ベースラインマネージメントクライアント、および／または通信モジュールのインテグリティーをチェックしている間に障害が識別された場合には、ＰＩＰＥは、ネットワークへの接続のために使用されたキーのリリースを防止すること、ネットワークへのアラームをトリガーすること、コンポーネントを置換するためのリモートバルク更新手続を実行すること、リモートコンポーネント更新手続を実行すること、および／またはデバイスをパワーダウンすることが可能である。ＰＩＰＥがリモートバルク更新手続をトリガーした場合には、アラームがネットワークへ送信されることを可能にすることができるフォールバックコードをロードすることができる。アラームは、基本コードを置換するためのリモートバルク更新手続をトリガーすることができる。
基本通信接続コードのインテグリティーチェックおよび／または検証において障害がない場合には、残りのオペレーティングシステムおよびマネージメントクライアントコンポーネントをインテグリティーチェックおよび／またはロードすることができる。これは、再配置可能なおよび／またはリロード可能な機能モジュールのインテグリティーチェックおよび／またはローディングを実行することを含むことができる。インテグリティーチェック中に識別された障害がある場合には、ＰＩＰＥは、ネットワークへの接続のために使用されたキーのリリースを防止すること、障害レポートをプロトコル内に含めてネットワークへ送信すること、アラームをトリガーすること、および／もしくはリモートコンポーネント更新手続を要求すること、ならびに／またはデバイスをパワーダウンすることが可能である。障害レポートは、たとえばネットワークによってリモートから更新することができる障害の生じているコンポーネントを示すことができる。
ＰＩＰＥのアクションは、成功裏に検証されたブートチェーンに応じて変化する可能性がある。ブートプロセスにおけるそれぞれのステージでは、その時点で（またはその時点までに）インテグリティーチェックされている基礎をなすプラットフォームの一部または全体の査定されたインテグリティーと、適用されることになるポリシーとに基づいて判定を行うことができる。これらのポリシーは、達成される信頼レベルに応じて、改変すること、またはその他のポリシーによって置換することが可能である。実行環境は、それぞれのブートステージにおける制御ポリシーに応じて変化する可能性がある。その後のステージおよび／またはポリシーは、実行ステージを越えて情報を伝達または格納する利用可能な保護された手段（たとえば、状態、変数、パラメータ、レジスタ、ファイルなど）を通じて前のステージから渡された情報を使用することができる。
本明細書において説明する際、たとえば、ＰＩＰＥは、ポリシーをプラットフォーム上に提供することができ、そのプラットフォーム上で、それらのポリシーは、たとえば、図８において示されているように、プラットフォームの構成および信頼状態の達成されるレベルに応じて改変または変化することができる。図８において示されているように、ＴｒＥ８０２を、対応するポリシー８１２に従ってインテグリティーチェックすること、ロードすること、および／または実行することが可能である。ＴｒＥ８０２が、信頼済みエンティティーとして確立され、実行されると、デバイスは、ブートシーケンスの次なるステージへ移ることができる。たとえば、能力８０４を、ポリシー８１４に従ってインテグリティーチェックすること、ロードすること、および／または実行することが可能である。能力８０４のインテグリティーチェック、ローディング、または実行は、ＴｒＥ８０２のインテグリティーチェック、ローディング、または実行に関連付けられている情報（たとえば、信頼状態）に基づくことができる。能力９０４のインテグリティーチェック、ローディング、および／または実行の最中に実施することができるポリシー８１４は、ブートシーケンスの前のステージにおいて実施されたポリシー８１２によって知らせることができる。能力８０４が、信頼済みエンティティーとして確立され、実行されると、デバイスは、ブートシーケンスの次なるステージへ移ることができる。ブートシーケンスは、能力８０６、８０８、および８１０をそれぞれ、それらの対応するポリシー８１６、８１８、および８２０に従ってチェックすること、ロードすること、および／または実行することによって継続することができる。ブートシーケンスのそれぞれのステージは、本明細書に記載されているように、ブートシーケンスの前のステージのうちの１つまたは複数によって知らせることができる。
本明細書に記載されているポリシーは、オペレータなどの信頼済み外部エンティティーによって提供することができる。プラットフォームの達成された信頼状態の結果は、プラットフォームの信頼状態について知る合法的な権益／権利を有することができる外部エンティティー、たとえば機密アプリケーションまたはサービスのオペレータまたはプロバイダなどに伝達可能とすることができる。プラットフォームのブートアップまたはオペレーションサイクルのおそらくは別々のステージにおいて査定されるプラットフォームのおそらくは別々の状態に関する情報の伝達先となることができる外部エンティティーは複数存在することができるということに留意されたい。
多層インテグリティーチェック、およびそのようなインテグリティーチェックをプラットフォームの信頼状態に結び付けることは、本明細書に記載されているように実行することができる。たとえば、そのようなインテグリティーチェックおよび結び付けは、デバイス上のキーがデバイスの達成された能力（たとえば、修復タスクを実行するネットワーク上のサーバなどの外部検証者に対するデバイス修復機能）を認証することをポリシーおよび実施によって確実にするために、多層インテグリティーチェックを使用することができる。認証のためにそのようなキーを使用するセキュリティーに敏感な機能は、所望の能力を達成するためのソフトウェアおよび／または構成ファイルのある特定の事前に知られているセットがインテグリティーチェックに合格した場合に、デバイスにとって利用可能となることができる。そのようなソフトウェアおよび／または構成ファイルは、たとえば、低いレベルのＯＳ機能、ドライバ、構成ファイル、および／または通信スタックコードの何らかのサブセットを含むことができる。
多層インテグリティーチェック、およびインテグリティーチェックの結び付けは、認証キーを保護するために使用されるポリシーを含むこともでき、それによって、そのキーを、許可された機能またはプロセスによる使用に制限することができる。そのキーが保護されていなければ、そのキーにアクセスするためにソフトウェアが危うくされる可能性がある。デバイスは、キーが、能力、機能の限定されたセット、または単一の機能による使用に制限されるようにキーを保護すること、そのキー上で動作する機能／プログラムを保護すること、および／または誰（たとえば、ユーザ、システム、スクリプトなど）がこれらの特権付きの機能のうちの１つを呼び出すことができるかを制限することのための信頼済み機能を提供することができる。
多層インテグリティーチェックおよび結び付けのための、本明細書に記載されている実施形態は、危うくされている可能性のあるデバイスが、外部エンティティーに対する自分の部分的な能力（たとえば、修復サーバ、またはそのようなサーバのためのＡＡＡエンティティーに対して障害を報告して修復アクションを実行する自分の能力）を認証できるようにするために使用することができる事前に知られているソフトウェアのセットを含むことができる。外部エンティティー（たとえば、修復サーバ）は、論理エンティティーとすることができ、デバイスマネージメントサーバ（たとえばＨ（ｅ）ＮＢの場合のＨ（ｅ）ＭＳなど）によってホストすることができる。
特定のプラットフォーム上の実際の実施態様から独立していることが可能であるポリシーを指定するメカニズムを提供するためには、特定のプラットフォーム能力のために所望される可能性がある機能を指定することによって、それらのポリシーを定義することができる。したがって、本明細書において開示されているコンポーネントから機能へのマッピングと同様の方法で、特定の能力に対応するポリシーを機能にマップすることもできる。外部利害関係者は、特定の能力に関するポリシーを単一の機能または複数の機能に対して指定することができる。能力を特定のポリシーに、およびプラットフォーム構成のステージにマップする際のポリシー要件を解釈することは、ＰＩＰＥの担当とすることができる。
特定の能力が機能の特定のセットを使用する場合には、それらの機能は、その特定の能力に合わせた対応するポリシー用に指定することができる。たとえば、修復を実行する能力が、ポリシーにマップされることを所望される場合には、修復を実行するために使用される機能は、対応するポリシーにマップすることができ、たとえば、修復能力を機能１、２、および３によってカバーすることができ、したがって、対応するポリシーは、機能１、２、および３にマップするように指定される。
いくつかの実施態様に関しては、プラットフォームの階層化された構成と、能力および機能との間に妥当なレベルの相関関係が存在することができる。能力は、機能とともに、層ごとに漸進的に構成することができる。たとえば、修復機能および能力は、プラットフォーム構成の初期のステージにおいて構成することができる。
多層インテグリティーチェックは、別々の機能のチェック済み対未チェックのステータスの順次的な判定ではないと言える。機能は、順次的な様式でチェックすることができる。しかし、別々の機能は、（その後に別々のステージにおいてロードすることができる）別々のコンポーネントにマップすることができるため、インテグリティーに関する機能単位の判定のプロセスは、順次的でない様式で、または、コンポーネント単位のインテグリティーチェックのアトミックプロセスのシーケンスに（持続時間において、または時間順序において）必ずしも同期化されていない順次的な様式で行うことができる。
ポリシー実施のためにシリアライゼーションを使用することができる。ポリシー実施は、所与のプラットフォーム能力に関して、対応する機能がインテグリティーチェックされているかどうか、および／または適用されるべきポリシーを判定することができる。
多範囲の認証（ｍｕｌｔｉ−ｓｃｏｐｅ ａｕｔｈｅｎｔｉｃａｔｉｏｎ）は、プラットフォームが、そのプラットフォームの達成された信頼レベルに基づいて１つまたは複数の外部エンティティーに対して認証を行うことを可能にすることができる。認証メカニズム（たとえば、認証チャレンジ応答メカニズム）を、デバイスのインテグリティーの結果として得られる範囲を外部エンティティーへ伝達するための手段として使用することができる。外部エンティティーは、認証を行い、そして同時に、デバイスのインテグリティーのレンジ／範囲の指示を得ることができる。
デバイスのＴｒＥは、多層インテグリティーチェックを経る間に、別々の目的で、認証チャレンジ応答に関する別々のパラメータまたはパラメータ値を生成することができる。パラメータのそのような生成は、成功したインテグリティーチェックの範囲に応じて外部認証エンティティーとの間で共有される同じ秘密証明書に基づくことができ、またはその秘密証明書を使用することができる。共通のチャレンジレスポンスコンピューティングアルゴリズムを使用することができる。しかし、そのようなアルゴリズムへの入力は、インテグリティーチェックの範囲、および／または認証の目的に応じて、異なるものとすることができる。たとえば、ＴｒＥがコードベース全体を成功裏にチェックした場合には、「ｅｎｔｉｒｅ ｃｏｄｅ ｂａｓｉｓ ｓｕｃｃｅｓｓｆｕｌｌｙ ｃｈｅｃｋｅｄ（コードベーシス全体が成功裏にチェックされた）」などのテキスト文字列を、認証チャレンジ応答コンピューティングアルゴリズムへの入力として使用することができる。ＴｒＥが、障害修復機能を実現するために使用されるコンポーネントを成功裏にチェックしたが、必ずしもコードベース全体のチェックは行っていない場合には、「ｃｏｄｅ ｂａｓｅ ｆｏｒ ｄｉｓｔｒｅｓｓ ｒｅｍｅｄｉａｔｉｏｎ ｓｕｃｃｅｓｓｆｕｌｌｙ ｃｈｅｃｋｅｄ（障害修復のためのコードベースが成功裏にチェックされた）」などの別の文字列を、入力として使用することができる。
外部認証者は、自分の認証チャレンジ要求をデバイスへ送信し終わると、「予測された」チャレンジ応答の２つのバージョンを計算することもできる。外部認証者は、デバイスにおけるチャレンジ応答の計算においてどの入力が使用されたかを知ることができないため、応答の両方のバージョンを計算しなければならない場合がある。デバイスから受信された応答を、応答の予測されたセットと比較することによって、外部認証者は、黙示的にデバイスインテグリティーの「範囲」を連続してテストすることができる。このエンティティーは、デバイスのインテグリティーのある特定の「範囲」がデバイス側で成功裏にチェックされていることを、帰納によって、認証および／または検証することができる。上記の例においては、機能のインテグリティーをチェックすることを条件として、デバイスの別の特定の（たとえば、部分的な）能力、ひいては、その能力を実現するために使用されるコンポーネントを認証するために、同じまたは同様の実施態様を使用することができる。
一例として、信頼を検証できる外部指示は、コードインテグリティー測定値を特定のブートサイクル実行および構成署名に結び付けるセキュアブートプロセス中の署名証明書の保護されたリリースとすることができる。セキュアなタイムスタンプ、ブートサイクルごとにインクリメントする保護されたモノトニックカウンタ、またはブートサイクルシークレット（ｂｏｏｔ ｃｙｃｌｅ ｓｅｃｒｅｔ）（たとえば、ブートサイクルごとに１回生成または導入されるノンスなどの隠されたランダムな値）を含むことができる。認証キーは、前提条件が満たされている場合に利用可能になることができ、現在の信頼できるプロセスは、次のリセットまで（たとえば、最初の測定の後に障害が検知された際に）障害の生じている状況へ戻ることに限定することができる、保護されたブートごとに１回限りのプログラム可能な「合格」フラグ（ｐｒｏｔｅｃｔｅｄ ｏｎｅ−ｔｉｍｅ ｐｅｒ ｂｏｏｔ ｐｒｏｇｒａｍｍａｂｌｅ “ｐａｓｓ” ｆｌａｇ）を設定する。ＴｒＥなど、（たとえば、ブート時だけでなく、ランタイム内に及ぶ）永続的な信頼済み環境は、外部エンティティーへのリリース前に、認証プロトコルノンスを使用して、ステータス情報に署名することができる。レポートのセクションには、現在検証されている信頼できるプロセスによって一時的なブートキーを用いて署名することができ、それによって、その後のプロセスは、このステータスを妥当性確認のために外部エンティティーに提示することができる。
認証プロトコル内に含めてやり取りされる修正された（１つまたは複数の）ランダムノンスを使用することができ、そのような修正された（１つまたは複数の）ノンスは、チャレンジ応答および予測されたチャレンジ応答の計算に対する入力として使用することができる。すなわち、デバイス自体の上で、デバイスのＴｒＥは、その認証応答を、通常は、（たとえば、インテグリティーチェックが合格した場合には、）応答計算に対する入力において認証サーバから受信された（１つまたは複数の）ランダムノンスを使用して、計算するよう試みることができる。デバイス全体のインテグリティーのチェックは不合格であるが、デバイスの部分的な機能のインテグリティーチェック、たとえば「障害／修復機能」のインテグリティーチェックなどが合格である場合には、ＴｒＥは、応答のための別の値を、今度は、受信されたノンスの修正されたバージョンを使用して、計算することができる。そのような修正がどこで／どのようにして実行されるかは、認証サーバに知らせることができる。そのような修正の例としては、オリジナルのノンスの既知の位置における１つのビットまたは複数のビットを変更することを含むことができる。こうすれば、デバイスおよび認証サーバの両方は、オリジナルの「デバイス認証」応答を計算することに加えて、修正されたノンス入力を使用して応答を計算することができる。受信側（たとえば、認証サーバ）では、サーバは、デバイスから受信する応答が「デバイス認証」応答と一致するかどうかをチェックすることができる。それらが一致しない場合には、認証失敗をすぐに公表する代わりに、認証サーバは、受信された応答を、修正されたノンスを使用して計算された別の値の応答と比較することができる。それらが一致する場合には、認証サーバは、たとえそのデバイスを全体として認証することができなくても、この例における「障害／修復機能」などの特定の機能を認証することができると判定することができる。
セキュアブートプロセス中に、デバイスは、それぞれのソフトウェアコンポーネントを、対応するＴＲＶと比較することによって、コンポーネントのインテグリティー障害を知ることができ、これは、コンポーネントのビットの正確さおよびソースの真正性を確実にする上で役立つことができる。
検知されたコンポーネントチェック障害は、インテグリティーチェックステータス情報要素内に取り込むことができる。このステータスデータの構造は、セキュリティーの目的で、ならびに報告および診断における効率のために、さまざまな形態のうちの任意の形態を取ることができる。この情報は、ポリシーマネージメント手続をサポートする現在およびその後のブートステージおよびランタイムプロセスによって読み取られることが可能である。デバイスのネットワーク機能およびその他の機能へのコンポーネントの依存関係を判定するために、コンポーネントから機能へのマップを使用することができる。機能は、接続しているエンティティー、たとえばネットワークオペレータが、またはデバイスによってサポートされている付加価値のあるアプリケーション、たとえばモバイルペイメントが依存することができる機能とすることができる。オペレータおよび／またはアプリケーションサービスプロバイダは、トラフィックを搬送すること、修復、マネージメントオペレーション、または付加価値のあるアプリケーション機能など、特定のタスクに関するデバイスの信頼済みオペレーションのためにどの機能を使用することができるかを定義することができ、特定のネットワークオペレーションのためにどの機能を使用することができるかを示すポリシーをデバイス上に設定することができる。
ネットワーク機能のセットは、ネットワークオペレータおよび／またはアプリケーションサービスプロバイダから期待される能力の標準セットから生じることができる。機能は、無線テクノロジー、プロトコルスタックにおける層、ネットワークプロトコル、マネージメント能力、セキュリティーおよび信頼メカニズム、付加価値のあるアプリケーション機能などを含むことができる。
デバイスのポリシーマネージャーは、デバイスコンポーネントに従ってネットワーク機能の依存関係を示すことができる（本明細書に記載されているような）組み込まれたコンポーネントから機能へのテーブルまたはマップを使用することができる。インテグリティーチェックおよび／または報告の最中におけるそのようなコンポーネントから機能へのテーブルまたはマップの使用が、図９において示されている。図９において示されているように、デバイスは、コンポーネント９０２のインテグリティー測定値をそれらの対応するＴＲＶ９０４と照合することによって、９１０においてインテグリティーチェックを実行することができる。インテグリティーチェックが実行された後に、デバイスポリシーマネージメントエンティティー９０８は、９１６において、インテグリティーチェックされた１つまたは複数のコンポーネントのコンポーネント識別子（たとえば、コンポーネントアドレス）を、および９１８において、それぞれのコンポーネントがインテグリティーチェックに合格したかまたは不合格だったかの指示を受信することができる。ポリシーマネージメントエンティティー９０８は、ネットワークエンティティーへ送信するためのコンポーネントに関連付けられている対応する機能を判定することができる。たとえば、修復を必要とする障害の生じている機能を送信することができ、または妥当性を確認された機能の指示を送信することができる。たとえば、ポリシーマネージメントエンティティー９０８は、所与のコンポーネントに対応するコンポーネント識別子を９２２において取り出すために、９２０においてコンポーネントアドレスを使用することができる。図９において示されているように、コンポーネント識別子は、コンポーネントアドレスからコンポーネント識別子へのマッピングを含むテーブル９０６から取り出すことができる。ポリシーマネージメントエンティティー９０８は、所与のコンポーネントに対応するコンポーネント機能を９２６において取り出すために、９２４においてコンポーネント識別子を使用することができる。コンポーネント機能は、コンポーネント識別子からコンポーネント機能へのマッピングを含むテーブル９１２から取り出すことができる。ポリシーマネージメントエンティティー９０８は、判定された機能（たとえば、インテグリティーチェックに合格したかまたは不合格だった機能）を使用して、９３２においてネットワークエンティティーと対話することができる。たとえば、ポリシーマネージメントエンティティーは、インテグリティーの報告を実行すること、デバイスポリシーを受信すること、または、判定された機能のうちの１つもしくは複数に対応するアクションおよび／もしくは制限を受信することが可能である。それぞれの機能は、１つまたは複数のポリシー９３０に関連付けることができる。１つまたは複数の機能の集合は、共同でデバイス内の特定の能力を可能にすることができる。これらの能力は、階層化することができる。たとえば、ベース層の能力は、次なる能力層のサブセットであることが可能であり、次なる能力層は、その次の能力層のサブセットである、といった具合である。能力の階層化は、典型的な層および信頼の連鎖に基づくセキュアブートシーケンスを反映することができる。層は、特定の能力を可能にする機能の任意の組合せとすることができ、または機能の階層化および特定の組合せのハイブリッドな組合せとすることもできる。ポリシーマネージメントエンティティー９０８は、所与の能力に対応する１つまたは複数のポリシーを９３０において取り出すために、コンポーネントからマップされた機能を９２８において使用することができる。ポリシーは、能力からさまざまなポリシーへのマッピングを含むテーブル９１４から取り出すことができる。ポリシーは、９３２において示されているようにネットワークエンティティーから受信することができる。
障害の生じているコンポーネントは、結果として、１つまたは複数の障害の生じている機能につながる可能性がある。ソフトウェア開発／ビルドツールによって組み込まれているコンポーネントから機能へのマップの情報は、機能のインテグリティーチェック障害の測定を確認する際に、ひいては、デバイスおよび製造業者の点で実施態様から独立していることが可能である障害、たとえば、認証機能またはベースバンド無線プロトコルスタック（ｂａｓｅｂａｎｄ ｒａｄｉｏ ｐｒｏｔｏｃｏｌ ｓｔａｃｋ）の障害を、標準化された方法で報告する際に、ポリシーマネージャーをサポートすることができる。デバイス上では、この情報を修正から保護することができ、不変のＲｏＴ（ｒｏｏｔ ｏｆ ｔｒｕｓｔ）によって保証することができる。
ポリシーマネージメントプロセスは、この情報をブートおよびランタイム環境において利用することができる。デバイス上のポリシーマネージメントプロセスは、インテグリティーチェックプロセスの結果を使用して、どのネットワーク機能に障害が生じているかを判定することができる。コンポーネントは、コードがローダによってチェックされているときにブート時間中に利用可能である参照（たとえば、シンボルテーブルまたはメモリアドレス）によって識別することができる。チェックされているコードは、インテグリティーおよびソースの真正性が検証されるまで、実行可能なメモリにおける使用から隔離することができる。同様に、チェックされるコードは、ロードされた時点から、チェックされて、実行中に至るまで（たとえば、保護された実行および格納、ハードウェア保護、暗号保護、仮想化などによって）保護することができる。実行は、メモリマップ、アクセス特権などの修正によって防止することができる。図９におけるテーブル９０６および９１２において示されている一例として、アドレスロケーションｘにおけるコードは、コンポーネントＡに対応することができ、コンポーネントＡは、ネットワーク機能Ｆ１、Ｆ５、およびＦ１４にマップすることができる。このコードは、たとえば、複数の通信プロトコルが依存するプリミティブハッシング関数（ｐｒｉｍｉｔｉｖｅ ｈａｓｈｉｎｇ ｆｕｎｃｔｉｏｎ）とすることができる。インテグリティーの報告および修復は、障害が生じているプリミティブに依存する場合がある。したがって、これらのインテグリティーの報告および修復の機能は、基礎をなすサポート機能としてネットワーク標準化リスト内に含めることができる。
機能障害の標準化されたリストは、デバイスの能力に関するきめ細かい情報をネットワークに提供することができる。リモートデバイスに関しては、そのデバイスが依然として何を達成することができるかに関する信頼できる理解は、問題を修復するためにリソースを適用する際に有用である場合がある。障害のケースにおいては、ネットワークが障害指示自体のインテグリティーの妥当性を確認することができるように（たとえば、ソース、時間、および正確さ）、保護され保証された方法で障害を示す能力を有することは、誤ったアラームのもとでの高価なネットワークリソースの不必要な使用を防止することができる。
図１０は、例示的なシステムコンポーネントを含む報告および修復システムの例示的な概観を提供する。図１０において示されているように、１００２において、デバイス１００４のコンポーネント上で障害を検知することができる。障害は、ネットワークに示すことができる。たとえば、障害は、１００８においてネットワークに報告されるデバイスレポート１００６内に含めることができる。障害は、たとえば、障害の生じているコンポーネントに関連付けられている障害の生じているネットワーク機能として示すことができる。障害がネットワークに報告された場合には、ネットワークは、アクセス制御に関してきめ細かい決定を行うことができる。たとえば、ネットワークプラットフォーム妥当性確認エンティティー１０１０は、報告された機能チェックレポート１００６に基づいて、アクセスを許可しないこと、部分的なアクセスを許可すること、または完全なアクセスを許可することが可能である。アクセス決定は、１０１６においてデバイス１００４によって受信することができる。デバイスレポート１００６において示されている障害がある場合には、ネットワークプラットフォーム妥当性確認エンティティーは、その機能レポートをデバイスマネージメントサーバ１０１２へ転送することができ、デバイスマネージメントサーバ１０１２は、機能からコンポーネントへのマッピング情報１０１４から、障害の生じている（１つまたは複数の）コンポーネントを判定することができる。この情報を使用して、デバイス１００４を修復すること、および障害の生じているソフトウェアコンポーネントをデバイス１００４内にリロードすることが可能である。たとえば、デバイスマネージメントサーバ１０１２は、障害の生じているコンポーネントに関連付けられている障害の生じている機能の範囲を絞り込むために、１０１８においてデバイス１００４に問合せを行うことができる。インテグリティー障害が、効率的な修復のためにデバイス１００４のあるセクションへ分離された後に、デバイスマネージメントサーバ１０１２は、１０２０において、たとえばコードビルドリリースエンティティー１０２２などから、ソフトウェアの更新（たとえば、置換コンポーネント）を要求することができる。デバイスマネージメントサーバ１０１２は、障害の生じているコンポーネントを修復するために、ソフトウェアの更新を１０２４においてデバイス１００４に提供することができる。製造業者のデバイス上での特定の障害の生じているコードのこの形態の抽出は、オペレータが（自分が接続している先の）デバイスを詳細に知る負担を減らし、その一方で同時に、障害の生じている機能に基づいて、きめ細かいアクセス制御および修復の決定を可能にすることができる。
実行フロー障害とは、プロセスチェーンにおいて呼び出すことができるコンポーネントに対する障害であると言える。コンポーネントの実行は、高いレベルの保証を保持する一方で、デバイスの能力を拡張することができる。現在の検証されているプロセスが、次なるプロセスのコードのインテグリティー（および場合によってはデバイスの構成）をチェックして、障害が生じていると判明した場合に、実行フロー障害を検知することができる。その後のブートコードにおける障害は、現在の信頼済みプロセスが、現在の状態を最後の知られている良好な状態としてロックダウンすること、障害を示すこと、プロセスの制御を待機モードで保持すること、制御を障害プロセスに渡すこと、および／または制御を信頼できないプロセスに渡すことのうちの１つまたは複数を実行することができるということを意味する場合がある。障害の生じているステージに関する認証および識別キーは、さらなるプロセスから締め出すことができ、したがって、信頼できないプロセスが、報告（たとえば、署名されたステータス）または認証技術（たとえば、自律的な妥当性確認）を通じて有効な状態をネットワークに示せないようにすることができる。
効率のために、デバイスからネットワークへ送信される障害レポートは、きめ細かいゲートウェイアクセス制御を実行して、デバイス障害をネットワークのデバイスマネージメントエンティティーに示すための、オペレータネットワーク妥当性確認機能からのアクションを促すために使用される最小限の量の情報を含むことができる。マネージメントエンティティーは、製造業者固有の情報を参照して、障害の根本原因を判定すること、およびどのコードを修復できるかを判定することが可能である。マネージメントエンティティーは、そのエンティティーがアクセス制御および／または修復に関してさらなるポリシー決定を行うことを可能にするためのさらなる情報をネットワーク妥当性確認機能に返すことができる。
障害レポート内に含めることができる障害の生じている機能の例示的なセットが、下記のテーブル１に記載されている。
結果、すなわち合格または不合格の機能レポートを送信することができる。テーブル２は、そのようなリストの一例を提供している。
機能レポートは、ゲートウェイ認証のために使用されるものなど、代替チャネル上で認証中にペイロード内に含めて移送することができ、したがって、たとえゲートウェイ認証が不合格であっても、レポートは、認証シーケンス内のペイロードとして送信することができる。ペイロードには、デバイスの信頼済み実行環境によって署名することができる。
ＴｒＥ（ｔｒｕｓｔｅｄ ｅｘｅｃｕｔｉｏｎ ｅｎｖｉｒｏｎｍｅｎｔ）は、（たとえば、便宜上または予備の目的で）自分自身の機能フィールドを有することができる。しかし、機能または障害ペイロードのリストがＴｒＥによって署名されているか、または認証キーがＴｒＥによって保護されている場合には、ＴｒＥのインテグリティーは、ネットワークへの接触時に知られることが可能である。ＴｒＥの（１つまたは複数の）署名キーは、フェイルセキュアシーリング方法（ｆａｉｌ−ｓｅｃｕｒｅ ｓｅａｌｉｎｇ ｍｅｔｈｏｄ）によって保護することができる。すなわち、ＴｒＥが危うくされている場合には、ＴｒＥの（１つまたは複数の）キーが利用可能ではない（たとえば、デバイスまたはその内部の機能およびインターフェースにとって利用可能ではない、Ｉ／Ｏおよびテストポートにとって利用可能ではない、ならびに外部ネットワークエンティティーにとって利用可能ではない）場合がある。
障害またはアラームのイベントにおいては、サービングネットワークエンティティーは、障害中のデバイスが、障害を確実に報告する機能を有していること、および障害中のデバイスのメカニズムには障害が生じていないことを検証することができる。２つの形態の保証によって、報告メカニズムが信頼できることをネットワークに示すことができる。１つめは、特定のタイプのデバイスが、信頼できる報告能力の特定のセットに準拠している旨の証明書など、信頼済みサードパーティーによる保証という静的な形態で生じることができる。この保証は、アラームおよび障害状況のメッセージを処理および送信するためのデバイスの能力および堅牢性（または信頼性）のレベルに関する情報を提供することができる。ネットワークオペレータは、障害アラームのイベントにおいて適切に自動的に対応するための手続を確立する保証された能力を使用することができる。
別の形態の保証は、デバイスとのオンライントランザクションを通じて生じることができる。デバイス内のメカニズムは、障害イベントの時点で報告メカニズムのインテグリティーの指示を提供することができる。この内部の能力は、サードパーティーが準拠の証明書を提供することを可能にすることができるという点で、静的な形態の保証に関連していると言える。
さまざまなプロトコルフローが、本明細書においては、Ｈ（ｅ）ＮＢのコンテキストにおけるデバイス障害および修復に関して説明されているかもしれない。しかし、本明細書において説明されているコンセプトは、そのような実施形態に限定されるものではなく、いかなる通信デバイスにも適用することができる。図１６において示されている例示的な一実施形態によれば、デバイスインテグリティー情報は、Ｈ（ｅ）ＮＢからＳｅＧＷを通じてマネージメントサーバ（Ｈ（ｅ）ＭＳ）へ送信することができる。図１７において示されている別の例示的な実施形態によれば、Ｈ（ｅ）ＮＢは、直接マネージメントサーバ（Ｈ（ｅ）ＭＳ）に接続することができる。図１８Ａおよび図１８Ｂにおいて示されている別の例示的な実施形態によれば、部分的な障害のイベントにおいてきめ細かいアクセス制御を可能にするようにデバイスインテグリティーチェックを補強することができる。それらの手続は、ネットワーク内の修復エンティティーから受信された修復データを使用してＤＲＦによって変更することができるＤＲＦの制御下でのコードまたはデータブロックの修復を可能にすることができる。これは、システムアーキテクチャーがそのような変更を可能にする場合には、ソフトウェア、およびまたソフトウェアまたはハードウェア構成データの変更を含むことができる。示されているフローは、ソフトウェア修復を対象としているかもしれないが、それに限定されるものではない。
ネットワークマネージメントエンティティーと、デバイス自体との間において問合せを実行することができ、その間に、デバイスの障害が生じているインテグリティーに関する詳細な情報が、はじめに報告されたよりもきめ細かな精度で抽出される。この情報は、障害の原因の発見につながることができ、コンポーネントのどの部分に障害が生じているかを示すことができ、また、ソフトウェアダウンロードのサイズを小さくすること、ひいては、ネットワーク帯域幅に対するニーズと、コードダウンロードのサイズとのバランスを取ることによる効率的なデバイスマネージメントのためのコードおよび／または構成のさらにきめ細かな修正を可能にすることができる。例示的な一実施形態によれば、ＩＰインターネットプロトコルを使用している管理されているネットワークデバイスは、デバイスマネージメントの目的でＴＲ−０６９（ＣＰＥ ＷＡＮ）を利用することができる。このプロトコルは、ＡＣＳ（「ａｕｔｏ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｓｅｒｖｅｒ」）へのアクセスを提供することができる。ＡＣＳアプリケーションは、テーブル３において示されているように、プロトコルスタックにおけるいくつかの能力を使用することができる。
このスタックは、ＲｏＴプロセスにとってアクセス可能とすることができ、ＲｏＴプロセスは、ＴＲ−０６９に接続されているマネージメントサーバに高い保証の障害指示を提供することができる。しかし、それぞれの層の機能の完全なリストは、障害状況において使用することができず、したがって、デバイスをセキュアにブートストラップして完全なマネージメントおよびデバイス機能へ戻すために使用される手続を実行するようにスタックを削って整えることができる。
図１１は、実行することができるアクションを判定するためにデバイスにおける情報を収集するための例示的なコールフロー図を示している。インテグリティー障害が生じた場合には、図１１において示されているシーケンスは、Ｈ（ｅ）ＮＢ１１０２などのデバイス（たとえば、ＴＲ−０６９デバイス）と、Ｈ（ｅ）ＭＳ１１０４などのネットワークエンティティーとの間において生じることができる。１１０６においては、Ｈ（ｅ）ＮＢ１１０２と、Ｈ（ｅ）ＭＳ１１０４との間において接続（たとえば、ＴＲ−０６９接続）を確立することができる。たとえば、Ｈ（ｅ）ＮＢ１１０２は、その接続を、１１０６において自分のＴｒＥまたはＲｏＴを使用して確立することができる。１１０８においては、Ｈ（ｅ）ＮＢ１１０２は、たとえば、Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔおよび／またはアラームを使用することによって、（１つまたは複数の）インテグリティー障害をＨ（ｅ）ＭＳ１１０４に報告することができる。Ｈ（ｅ）ＭＳ１１０４は、そのアラームを１１０８において受信することができ、１１１０においてＩｎｆｏｒｍａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージ（たとえば、ＴＲ−０６９通知応答）を用いてＨ（ｅ）ＮＢ１１０２に応答することができる。
大雑把に言って、デバイスのそれぞれのソフトウェアコンポーネントは、対応するＴＲＶを有することができる。本明細書に記載されているように、あるコンポーネントが基準に一致しない場合には、そのコンポーネントはインテグリティー障害を有していると言える。いくつかのコンポーネントは、きわめて大きい場合がある。たとえば、オペレーティングシステムは、単一のＴＲＶを有する単一のモノリシックなコードブロックとして供給することができる。
図１２は、コンポーネント内の（１つまたは複数の）障害の（１つまたは複数の）ロケーションを分離するための問合せに関する例示的なコールフロー図を示している。問合せプロセス中に、ネットワークマネージメントエンティティー１２０４（たとえばＨ（ｅ）ＭＳなど）は、検知された障害を修復するために実行することができるアクションを判定するためのさらなる情報を収集するために、デバイス１２０２（たとえばＨ（ｅ）ＮＢなど）と対話することができる。例示的な一実施形態によれば、デバイス１２０２は、ネットワークマネージメントエンティティー１２０４と対話するためにＴｒＥまたはＲｏＴを使用することができる。
ネットワークマネージメントエンティティー１２０４は、コードイメージ全体のモノリシックなダウンロードを実行することを決定することができる。このダウンロードは、現在のコードイメージまたは更新されたコードイメージのリロードから構成することができる。イメージ全体をネットワークマネージメントエンティティー１２０４へダウンロードすることができるため、ダウンロードされるイメージ内にＴＲＶ（オリジナルまたは更新）を含めることができる。ネットワークマネージメントエンティティー１２０４は、コードイメージ全体のモノリシックなダウンロードを行うよりも、障害が生じているとして報告されたコンポーネントをダウンロードすることを決定することができる。コンポーネント全体（更新のケースにおいてはＴＲＶを含む）をデバイス１２０２へダウンロードすることができるため、イメージは、現在のコンポーネントまたは更新されたコンポーネントのリロードとすることができる。更新されたコンポーネントのケースにおいては、クライアントマネージメントエンティティーは、既存のコードイメージを、イメージ全体のインテグリティーおよび構造が損なわれることが決してないように管理することができる。
図１２において示されているように、１２０６においてインテグリティー障害を検知することができる。たとえば、デバイス１２０２のコンポーネントにおいてインテグリティー障害を検知することができ、本明細書に記載されているように、インテグリティーチェックレポートをネットワークマネージメントエンティティー１２０４へ送信することができる。１２０８においては、デバイス１２０２と、ネットワークマネージメントエンティティー１２０４との間において接続（たとえば、ＴＲ−０６９接続）を確立することができる。１２１０においては、ネットワークマネージメントエンティティー１２０４は、デバイス１２０２におけるインテグリティー障害に関連付けられているアラームに関連するパラメータを求める要求をデバイス１２０２へ送信することができる。デバイス１２０２は、アラームの詳細を含むパラメータ応答を１２１２においてネットワークマネージメントエンティティー１２０４へ送信することができる。１２１４においては、ネットワークマネージメントエンティティー１２０４は、修復のためにデバイス上のコンポーネントのインテグリティー障害を絞り込むことを決定することができる。インテグリティー障害を絞り込む目的で、ネットワークマネージメントエンティティー１２０４は、さらにきめ細かい測定を行うために１２１６においてパラメータ要求をデバイス１２０２へ送信することができる。１２１８においては、デバイス１２０２は、デバイス１２０２上のコンポーネントの測定を行うことができる。１２２０においては、ネットワークマネージメントエンティティー１２０４は、基準上での測定を行うことができる。たとえば、ネットワークマネージメントエンティティー１２０４は、基準値をオンザフライで生成することができる。なぜなら、コンポーネントの測定は、コンポーネントメーカーによって提供することはできず、デバイス１２０２によって動的なきめ細かさを伴って行うことができるためである。ネットワークエンティティー１２０４によって行われた基準上の測定は、たとえば、デバイス１２０２によって行われたコンポーネントの測定と比較することができる。デバイス１２０２は、自分がさらにきめ細かいインテグリティー測定を行った、または行うことになる旨をネットワークマネージメントエンティティー１２０４に示すパラメータ応答を１２２２において送信することができる。
１２２４においては、ネットワークマネージメントエンティティーは、（１つまたは複数の）第１のノード（たとえば、（１つまたは複数の）コンポーネント）のインテグリティー測定値を求めるパラメータ要求を送信することができる。１２２６においては、デバイス１２０２は、（１つまたは複数の）第１のノードのインテグリティー測定値を示すパラメータ応答をネットワークマネージメントエンティティー１２０４へ送信することができる。ネットワークマネージメントエンティティー１２０４は、（１つまたは複数の）次なるノード（たとえば、（１つまたは複数の）コンポーネント）の測定値をデバイス１２０２に求めるパラメータ要求を１２２８において送信することができる。たとえばデバイス１２０２から受信された（１つまたは複数の）第１のノードの測定値に基づいて、（１つまたは複数の）次なるノードの測定値を要求することができる。加えて、（１つまたは複数の）次なるノードは、（１つまたは複数の）第１のノードのうちの部分またはサブコンポーネントとすることができる。１２３０においては、デバイス１２０２は、（１つまたは複数の）次なるノードの要求された測定値を含むパラメータ応答をネットワークマネージメントエンティティー１２０４へ送信することができる。ネットワークマネージメントエンティティー１２０４からのパラメータ要求、およびデバイス１２０２からのパラメータ応答は、たとえば、インテグリティー障害が効率的な修復のためにデバイス１２０２のうちのセクション（たとえば、コンポーネント、機能、またはそのうちの部分）に分離されるまで、１２３２において示されているように繰り返すことができる。インテグリティー障害が識別されて分離された後に、デバイス１２０２と、ネットワークマネージメントエンティティー１２０４との間における接続（たとえば、ＴＲ−０６９接続）を１２３４において閉じることができる。
ネットワークマネージメントエンティティー１２０４は、障害を検知した後にさらにいっそう問合せを行うこと、およびモノリシックなブロックまたはコンポーネントの複数の測定を行うことを決定することができる。デバイス１２０２は、インテグリティー測定を実行すること、および／またはそれらの測定を迅速な参照のためのデータ構造、たとえば、バイナリーツリーにアレンジすることが可能である。ネットワークマネージメントエンティティー１２０４も、同じことを行うことができる。このような構造は、単一のブロックにおける複数の障害を明らかにすることができ、それによって、ネットワークマネージメントエンティティー１２０４は、モノリシックなブロックまたはコンポーネントのうちのどの部分がインテグリティーチェックに不合格になったかを迅速に判定することができ、これによって、影響の範囲を絞り込むことができ、ソフトウェアダウンロードトラフィックを潜在的に少なくすることができる。図１２および図１３において示されているように、修正されたブロックの詳細をチェックして、コンポーネントまたはモノリシックなブロックに関するＴＲＶよりもきめ細かい精度で、悪くなった部分を分離することができる。
コンポーネント障害に関するレンジを絞り込むきめ細かい情報を用いて、ネットワークマネージメントエンティティーは、ブロック全体に関するよりも、コードのうちのそのセグメントに関するダウンロードイメージを作成することができる。たとえば、図１３において示されているように、複数の機能をサポートする１つの大きなモノリシックなコンポーネント１３０２内で障害が生じる場合がある。全体的な測定値１３０４は、コンポーネント全体１３０２に関連付けることができる。なぜなら、コンポーネント全体１３０２が、インテグリティーチェックに不合格になる場合があるためである。デバイスと、ネットワークマネージメントエンティティーとの間における問合せを通じて、１３０６において、きめ細かい測定値を生成することができる。問合せは、よりきめ細かいインテグリティー測定値によって、大きなモノリシックなコンポーネント１３０２内の１つのセグメント、たとえばセグメント１３０８などの障害が見つかるようにすることができる。問合せの後に、インテグリティーチェックの結果として得られる全体的な測定値１３１０は、たとえば大きなモノリシックなコンポーネント全体１３０２に関連付けられている測定値１３０４よりも、セグメント１３０８の測定値７を含むことができる。セグメント１３０８において障害が識別された後に、修正パッチをこのセグメントに局在させることができる。修正パッチは、セグメント１３０８における障害を、インテグリティーチェックに合格した、大きなモノリシックなコンポーネント１３０２内のその他のセグメントを使用して修正することに関する命令を含むことができる。
生成されるインテグリティー測定値の数は、デバイスのタイプに基づいて制限することができる。ダウンロードされるサブコンポーネントが、現在のコンポーネントのリロードである場合には、そのリロードを実行するためにデバイスによってさらなる情報を使用することはできない。しかし、サブコンポーネントダウンロードが、既存のコンポーネントに対する更新である場合には、そのサブコンポーネントに関する更新されたＴＲＶをダウンロード内に含めることができる。デバイスクライアントおよびネットワークマネージメントエンティティーを同期化して、同じ更新されたコンポーネントイメージを生成することができ、それによって、更新されたＴＲＶは、更新されたコンポーネントイメージのハッシュと一致する。デバイスマネージメントクライアントは、既存のコードイメージを、イメージ全体のインテグリティーが損なわれることが決してないように管理することができる。
問合せプロセスによって、報告された障害が生じている機能のリストのネットワークのバージョンが修正される結果になる場合があり、その修正は、デバイス上のネットワークアクセス制御を修正するためにネットワーク妥当性確認、認証、および／またはゲートウェイエンティティーにフィードバックすることができる。
問合せプロセスは、反復測定アプローチを使用することによってコンポーネント障害を分離することができ、反復測定アプローチによって、ネットワークマネージメントエンティティーおよびデバイスは、測定値を漸進的に生成して、障害を示しているサブセクション上のイメージ上で視野を絞り込むことができる。この方法は、所与のレゾリューションのために使用される測定値の数を減らすことができ、それによって、メモリ上の制約があるデバイスに関して測定とレゾリューションとの間におけるトレードオフが可能になる。たとえば、この問合せプロセスの例示的な一実施形態を図１４において示すことができる。図１４において示されているように、コンポーネント１４０２において障害を見つけることができ、全体的な測定値１４０４をコンポーネント全体１４０２に関連付けることができる。デバイスおよびネットワークは、コンポーネント１４０２において障害が見つかった後に問合せを実行することができ、その問合せに基づいて、デバイスは、コンポーネント１４０２上で測定の第１の反復を実行することができる。たとえば、測定の第１の反復において、デバイスは、コンポーネント１４０２のサブセクション１４０６およびサブセクション１４０８上で独立した測定を実行することができる。結果として、デバイスは、サブセクション１４０６がインテグリティーチェックに合格し、その一方でサブセクション１４０８がインテグリティー障害の原因を含んでいると判定することができる。これは、サブセクション１４０６に関連付けられている測定値１と、サブセクション１４０８に関連付けられている測定値２とによって示すことができる。サブセクション１４０８が依然としてインテグリティーチェックに不合格であるため、全体的な測定値１４０４は、コンポーネント１４０２がインテグリティー障害を含んでいることを依然として示すことができる。
インテグリティー障害がサブセクション１４０８に絞り込まれる一方で、デバイスおよびネットワークは、修復のためにさらにきめ細かい測定値を漸進的に生成するためのさらなる問合せ手続を実行することができる。問合せの結果として、デバイスは、コンポーネント１４０２上で測定の第２の反復を実行することができる。図１４において示されているように、測定の第２の反復は、サブセクション１４０８上で実行することができる。なぜなら、このサブセクション１４０８が、インテグリティー障害の原因であると判定されたサブセクションであったためである。デバイスは、第２の反復においてサブセクション１４１０および１４１２上で独立した測定を実行することができ、それらは、それぞれ測定値３および測定値４を生成することができる。サブセクション１４１０および１４１２は、サブセクション１４０８のサブセクションであると言える。測定値３は、サブセクション１４０８のサブセクション１４１０がインテグリティーチェックに合格であることを示すことができる。しかし測定値４は、サブセクション１４１２がインテグリティーチェックに不合格であり、コンポーネント１４０２のインテグリティーチェック障害の原因を含んでいることを示すことができる。
インテグリティー障害がサブセクション１４１２に絞り込まれる一方で、デバイスおよびネットワークは、修復のためにさらにきめ細かい測定値を漸進的に生成するためのさらなる問合せ手続を実行することができる。たとえば、デバイスは、測定の第３の反復を実行することができる。測定の第３の反復は、サブセクション１４１２上で実行することができる。なぜなら、サブセクション１４１２が、測定の第２の反復の後にインテグリティー障害の原因であると判定されたサブセクションであったためである。図１４において示されているように、デバイスは、サブセクション１４１４および１４１６上で独立した測定を実行することができる。デバイスは、サブセクション１４１４がインテグリティー障害の原因を含んでいると判定することができる。これは、たとえば測定値５によって示すことができる。測定の第３の反復の後に、サブセクション１４１４に関連付けられている機能を、インテグリティー障害の原因を含むコンポーネント１４０２のきめ細かいサブセクションに対応するものとして、ネットワークへ送信することができる。問合せの結果として、ネットワークは、サブセクション１４１４に局在させることができる修正パッチ（たとえば、サブコンポーネントの置換または修正）を判定して、その修正パッチをサブセクション１４１４の置換または修正のためにデバイスへ送信することができる。図１４は、ネットワークとデバイスとの間における問合せの結果としてデバイスにおいて実行される測定の３回の反復を示しているが、コンポーネントのうちでインテグリティー障害を含む部分を分離するために、測定の任意の回数の反復を実行することができる。例示的な一実施形態においては、反復の回数は、サービスプロバイダに基づく。別の例示的な実施形態においては、デバイスマネージメントサーバは、デバイス識別情報およびソフトウェアリリース番号を含むさまざまな基準に対応する障害のデータベースを保持する。この障害情報は、たとえば、デバイスマネージメントサーバが問合せ戦略を査定することを可能にすることができる。
ツリーの完全な生成などのその他のアルゴリズムと比べてこの漸進的なアプローチの価値を判定する際に、ネットワーク通信のコスト間の比較、測定値計算、および測定値計算のための値のローディングを重み付けすることができる。
この漸進的な方法においては、障害のフィールドが絞り込まれるにつれて測定を行うことができる。コード／データを繰り返し測定することができる。再測定される可能性があるコード／データの量を少なくするために、ハイブリッドなアプローチを使用することができ、このアプローチは、たとえば、はじめにイメージを何らかの最適な数のサブセクションへと分割することができる。何らかのファクタによってイメージを分割することによって、障害の生じている（１つまたは複数の）セクションを漸進的にさらにレゾルブすることができる。そのファクタは、最小の帯域幅および最小の消費電力を使用してネットワーク上での障害の分離および判定の度合いを最適化するために、反復ごとに、ならびにその他の時間遅延およびパフォーマンス上の考慮事項に基づいて決定することができる。障害分離プロセスを促進するために、ネットワークは、所与のコンポーネント障害に関するハッシュツリーなどのデータ構造での予測されたハッシュのセットを事前に生成して、サブＴＲＶ測定値（ｓｕｂ−ＴＲＶ ｍｅａｓｕｒｅｍｅｎｔ）のこのツリーをデバイスへ送信することができる。これは、デバイスが、この漸進的なアプローチにおける比較をツリーの最も高いレゾリューションまで行うことを可能にすることができる。ネットワークは、（たとえば、修正する必要があるデバイスの数に基づいて）修復手続を最適化するために、より多くのレゾリューションが必要とされているかどうかを判定することができる。より多くのレゾリューションが必要とされている場合には、より正確なロケーションから開始する新たなツリーを生成して、ネットワークによって送信することができ、または、対話式に比較を行うことができる。
ソフトウェアまたはデータの更新のケースにおいては、ソフトウェアマネージメントサーバは、更新を実行するために、ファイル内の単純なバイナリー差分上でコード／データの更新を実行することができる。デバイスマネージメントクライアントは、バイナリー更新を受信し、完全なコードイメージへの修正を実行して、そのインテグリティーを確実にすることができる。バイナリー差分の同じ原理を、ソフトウェア更新中のトラフィックの量を少なくするためのソフトウェアマネージメントエンティティー用の問合せ技術を含むように拡張することができる。すなわち、ソフトウェア更新手続は、バイナリーツリー検索を含めて、本明細書に記載されている同じ修復技術のうちの多くを包含することができる。
図１５は、障害アラームおよびモノリシックなコードの置換に関連する例示的なコールフロー図を示している。このコールフローについては、Ｈ（ｅ）ＮＢを使用して説明するが、その他のネットワークデバイスを使用することもできる。コールフローシーケンスは、本明細書に記載されているステップのうちの１つまたは複数を含むことができる。たとえば、図１５において示されているように、Ｈ（ｅ）ＮＢ１５０２は、１５１２においてセキュアブートシーケンスを実行することができる。インテグリティーチェックフェーズ１５１４中に、Ｈ（ｅ）ＮＢ１５０２は、オペレーションのために使用されるコード内でインテグリティー障害を見つけ出すことができ、したがって、Ｈ（ｅ）ＮＢの１５０２ ＴｒＥは、ＳｅＧＷ１５０４の認証のための秘密キーを利用可能にすることはできない。しかしＴｒＥは、Ｈ（ｅ）ＮＢ１５０２がＨ（ｅ）ＭＳ１５０６のオペレーションに関して合格であるということを認識することができる。たとえば、Ｈ（ｅ）ＮＢ１５０２は、アラームをＨ（ｅ）ＭＳ１５０６へ送信可能とすることができ、および／またはＨ（ｅ）ＮＢ１５０２にとって可能である手続に関するＨ（ｅ）ＭＳ１５０６の認証のための秘密キーを利用可能にすることができる。Ｈ（ｅ）ＭＳ１５０６は、１５１６においてＨ（ｅ）ＮＢ１５０２とのＩＰ接続（たとえば、ＳＳＬ／ＴＬＳイニシエーション）を確立することができる。１５１８においては、Ｈ（ｅ）ＮＢ１５０２は、Ｈ（ｅ）ＭＳ１５０６にインテグリティー障害を警告することができる。たとえば、Ｈ（ｅ）ＭＳ１５０６は、障害アラームをＨ（ｅ）ＮＢ１５０２から受信すること、および１５２０において（たとえば、リロードまたは更新を求める）コード修復要求をソフトウェア修復エンティティー１５１０へ送信することが可能である。ソフトウェア修復エンティティー１５１０は、１５２２においてソフトウェアビルドを実行することができる。１５２４においては、ソフトウェア修復エンティティー１５１０は、モノリシックなコンポーネントの代替品をＨ（ｅ）ＭＳ１５０６に提供することができる。たとえば、ソフトウェア修復エンティティー１５１０は、モノリシックな修復イメージをＨ（ｅ）ＭＳ１５０６に提供することができる。Ｈ（ｅ）ＭＳ１５０６は、Ｈ（ｅ）ＮＢ１５０２とのセキュアな接続を確立することができる。たとえば、Ｈ（ｅ）ＭＳ１５０６は、１５２６においてＨ（ｅ）ＮＢ１５０２との（たとえば、ＳＳＬ／ＴＬＳイニシエーションを介した）セキュアなＩＰ接続を確立することができる。Ｈ（ｅ）ＮＢ１５０２およびＨ（ｅ）ＭＳ１５０６は、Ｈ（ｅ）ＮＢ１５０２を修正するためのソフトウェア／ファームウェアダウンロードを可能にするように認証を行うことができる。１５２８においては、Ｈ（ｅ）ＭＳ１５０６は、Ｈ（ｅ）ＮＢ１５０２のソフトウェア／ファームウェアを更新することができ、Ｈ（ｅ）ＮＢ１５０２をリブートすることができる。Ｈ（ｅ）ＮＢ１５０２は、１５３０において、リブートすること、および／またはインテグリティーチェックを再開することが可能である。
図１６は、リモートソフトウェア障害／修復に関連する例示的なコールフロー図を示しており、ここでは、Ｈ（ｅ）ＮＢ１６０２は、Ｈ（ｅ）ＭＳ１６０６に障害を通知する。コールフローシーケンスは、本明細書に記載されているステップのうちの１つまたは複数を含むことができる。加えて、このコールフローについては、Ｈ（ｅ）ＮＢを使用して説明するが、その他のネットワークデバイスを使用することもできる。図１６において示されているように、Ｈ（ｅ）ＮＢ１６０２は、１６１２においてセキュアブートシーケンスを実行することができる。１６１４におけるインテグリティーチェックフェーズ中に、Ｈ（ｅ）ＮＢの１６０２ ＴｒＥは、通常のオペレーションのためのコード内で障害を見つけ出すことができ、したがって、Ｈ（ｅ）ＮＢの１６０２ ＴｒＥは、ＳｅＧＷ１６０４の認証のための秘密キーを利用可能にすることはできない。しかしＴｒＥは、Ｈ（ｅ）ＮＢ１６０２がＨ（ｅ）ＭＳ１６０６にセキュアに接続可能とすることができることを認識することができ、したがってＴｒＥは、Ｈ（ｅ）ＮＢ１６０２にとって可能である手続に関するＨ（ｅ）ＭＳ１６０６の認証のための秘密キーを利用可能にすることができる。Ｈ（ｅ）ＮＢ１６０２は、ＳｅＧＷ１６０４に対する認証を試みない場合がある（またはいくつかの障害においては、試みることができない）。１６１６においては、Ｈ（ｅ）ＮＢ１６０２は、Ｈ（ｅ）ＭＳ１６０６とのＩＰ接続（たとえば、セキュアなＳＳＬ／ＴＬＳセッション）を確立することができる。１６１８においては、Ｈ（ｅ）ＮＢ１６０２は、Ｈ（ｅ）ＭＳ１６０６にＨ（ｅ）ＮＢ１６０２のインテグリティーチェックステータス（たとえば、インテグリティー障害）を警告することができる。Ｈ（ｅ）ＭＳ１６０６は、Ｈ（ｅ）ＮＢ１６０２のインテグリティー情報の真正性を、たとえば認証によって、またはＴｒＥにより署名されたインテグリティーステータスペイロード情報の署名検証によって検証することができる。Ｈ（ｅ）ＮＢ１６０２においてインテグリティー障害があるということをインテグリティーチェックステータスが示している場合には、Ｈ（ｅ）ＭＳ１６０６は、１６２０において、示されている障害のためのソフトウェア修正を決定することができる。このソフトウェア修正は、インテグリティー障害のさらなる問合せを含むことができる。たとえば、１６２２においては、Ｈ（ｅ）ＭＳ１６０６は、Ｈ（ｅ）ＮＢ１６０２の診断および／または問合せを行うことができる。Ｈ（ｅ）ＭＳ１６０６は、障害の原因（たとえば、ロケーション）を詳細に判定することができ、１６２４においては、Ｈ（ｅ）ＭＳ１６０６は、リロードまたは更新のいずれかのためのものとすることができるコード修復要求をソフトウェア修復エンティティー１６１０へ送信することができる。ソフトウェア修復エンティティー１６１０は、１６２６においてソフトウェアビルドを実行すること、およびソフトウェア修正情報をＨ（ｅ）ＭＳ１６０６へ送信することが可能である。たとえば、ソフトウェア修正情報は、修復イメージを含むことができる。Ｈ（ｅ）ＭＳ１６０６は、１６３０においてＨ（ｅ）ＮＢ１６０２との（たとえば、ＩＰ接続を介した）セキュアな接続を確立することができる。Ｈ（ｅ）ＮＢ１６０２およびＨ（ｅ）ＭＳ１６０６は、Ｈ（ｅ）ＮＢ１６０２を修正するためのソフトウェア／ファームウェアダウンロードを可能にするように認証を行うことができる。１６３２においては、Ｈ（ｅ）ＭＳ１６０６は、Ｈ（ｅ）ＮＢ１６０２のソフトウェア／ファームウェアをダウンロードすること、および／またはＨ（ｅ）ＮＢ１６０２を再始動することが可能である。１６３４においては、Ｈ（ｅ）ＮＢ１６０２は、セキュアブートシーケンスを実行すること、および／またはインテグリティーチェックプロセスを再開することが可能である。１６３６におけるインテグリティーチェックフェーズ中に、Ｈ（ｅ）ＮＢの１６０２ ＴｒＥは、ＳｅＧＷ１６０４のオペレーションに関してインテグリティーチェックが合格であることを認識することができ、ＳｅＧＷ１６０４の認証のために使用される秘密キーを利用可能にすることができる。Ｈ（ｅ）ＮＢ１６０２およびＳｅＧＷ１６０４は、１６３８において互いに認証を行うことができ、ＳｅＧＷ１６０４は、認証が成功したことを１６４０においてＨ（ｅ）ＮＢ１６０２に示すことができる。
図１７は、ＳｅＧＷの認証の試みを伴う、リモートソフトウェア障害／修復に関連する例示的なコールフロー図を示している。コールフローシーケンスは、本明細書に記載されているステップのうちの１つまたは複数を含むことができる。加えて、このコールフローについては、Ｈ（ｅ）ＮＢを使用して説明するが、その他のネットワークデバイスを使用することもできる。図１７において示されているように、Ｈ（ｅ）ＮＢ１７０２は、１７１２においてセキュアブートシーケンスを実行することができる。１７１４におけるインテグリティーチェックフェーズ中に、Ｈ（ｅ）ＮＢ１７０２は、ＳｅＧＷ１７０４のオペレーションのために使用されるコード内でインテグリティー障害を見つけ出すことができ、したがって、Ｈ（ｅ）ＮＢの１７０２ ＴｒＥは、ＳｅＧＷ１７０４の認証のための秘密キーを利用可能にすることはできない。しかしＴｒＥは、Ｈ（ｅ）ＮＢ１７０２がＨ（ｅ）ＭＳ１７０６にセキュアに接続可能とすることができることを認識することができ、Ｈ（ｅ）ＮＢ１７０２にとって可能である手続に関するＨ（ｅ）ＭＳ１７０６の認証のための（１つまたは複数の）秘密キーを利用可能にすることができる。Ｈ（ｅ）ＮＢ１７０２は、たとえばＩＫＥｖ２プロトコルを使用することなどによって、１７１６においてＳｅＧＷ１７０４に対して認証を行うことを試みることができるが、（たとえば、秘密認証キーが利用可能ではないために）失敗する場合がある。１７１８においては、ＳｅＧＷ１７０４に対する認証が失敗した旨の指示をＨ（ｅ）ＮＢ１７０２に提供することができる。Ｈ（ｅ）ＮＢ１７０２は、１７２０においてＨ（ｅ）ＭＳ１７０６との（たとえば、ＳＳＬ／ＴＬＳイニシエーションを介した）セキュアなＩＰ接続を確立することができる。たとえば、そのセキュアなＩＰ接続は、Ｈ（ｅ）ＮＢ１７０２と、ＳｅＧＷ１７０４との間における失敗した認証の試みに基づいて確立することができる。１７２２においては、Ｈ（ｅ）ＮＢ１７０２は、Ｈ（ｅ）ＭＳ１７０６にＨ（ｅ）ＮＢ１７０２のインテグリティーチェックステータス（たとえば、インテグリティーの合格または不合格）を警告することができる。Ｈ（ｅ）ＭＳ１７０６は、Ｈ（ｅ）ＮＢ１７０２のインテグリティー情報の真正性を、認証によって、またはＴｒＥにより署名されたインテグリティーステータスペイロード情報の署名検証によって検証することができる。Ｈ（ｅ）ＮＢ１７０２においてコンポーネントのインテグリティー障害があるということをインテグリティーチェックステータスが示している場合には、Ｈ（ｅ）ＭＳ１７０６は、１７２４において、示されている障害のためのソフトウェア修正を決定することができる。このソフトウェア修正は、インテグリティー障害のさらなる問合せを含むことができる。たとえば、Ｈ（ｅ）ＭＳ１７０６は、Ｈ（ｅ）ＮＢ１７０２の診断および／または問合せを１７２６において行うことができる。Ｈ（ｅ）ＭＳ１７０６は、障害の原因を詳細に判定すること、および１７２８において（たとえば、リロードまたは更新のための）コード修復要求をソフトウェア修復エンティティー１７１０へ送信することが可能である。ソフトウェア修復エンティティー１７１０は、１７３０においてソフトウェアビルドを実行すること、および１７３２においてソフトウェア修正（たとえば、修復イメージ）をＨ（ｅ）ＭＳ１７０６に提供することが可能である。１７３４においては、Ｈ（ｅ）ＭＳ１７０６は、Ｈ（ｅ）ＮＢ１７０２とのセキュアなＩＰ接続（たとえば、ＳＳＬ／ＴＬＳイニシエーション）を確立することができる。Ｈ（ｅ）ＮＢ１７０２およびＨ（ｅ）ＭＳ１７０６は、Ｈ（ｅ）ＮＢ１７０２を修正するためのソフトウェア／ファームウェアダウンロードを可能にするように認証を行うことができる。Ｈ（ｅ）ＭＳ１７０６は、１７３６においてＨ（ｅ）ＮＢ１７０２のソフトウェア／ファームウェアをダウンロードすること、およびＨ（ｅ）ＮＢ１７０２を再始動することが可能である。Ｈ（ｅ）ＮＢ１７０２は、１７３８において、セキュアブートシーケンスを実行すること、および／またはインテグリティーチェックを再開することが可能である。１７４０におけるインテグリティーチェックフェーズ中に、Ｈ（ｅ）ＮＢ１７０２は、インテグリティーチェックが合格であることを認識すること、およびＳｅＧＷ１７０４の認証のための秘密キーを利用可能にすることができる。Ｈ（ｅ）ＮＢ１７０２およびＳｅＧＷ１７０４は、１７４２において互いに認証を行うことができ、ＳｅＧＷ１７０４は、認証が成功したことを１７４４において示すことができる。
図１８Ａは、ネットワークがＳｅＧＷを通じた認証を許可しないことが可能である、リモートソフトウェア障害／修復に関連する例示的なコールフロー図を示している。コールフローシーケンスは、本明細書に記載されているステップのうちの１つまたは複数を含むことができる。加えて、このコールフローについては、Ｈ（ｅ）ＮＢを使用して説明するが、その他のネットワークデバイスを使用することもできる。図１８Ａにおいて示されているように、Ｈ（ｅ）ＮＢ１８０２は、１８１２においてセキュアブートシーケンスを実行することができる。１８１４におけるインテグリティーチェックフェーズ中に、Ｈ（ｅ）ＮＢ１８０２は、オペレーションのために使用されるコード内で障害を見つけ出すことができ、したがって、Ｈ（ｅ）ＮＢの１８０２ ＴｒＥは、ＳｅＧＷ１８０４の認証のための秘密キーを利用可能にすることはできない。しかしＴｒＥは、Ｈ（ｅ）ＮＢ１８０２がＨ（ｅ）ＭＳ１８０６にセキュアに接続可能とすることができることを認識することができ、したがって、Ｈ（ｅ）ＮＢ１８０２にとって可能である手続に関するＨ（ｅ）ＭＳ１８０６の認証のための（１つまたは複数の）秘密キーを利用可能にする。１８１６においては、Ｈ（ｅ）ＮＢ１８０２は、（たとえば、ＩＫＥｖ２プロトコルを使用して）ＳｅＧＷ１８０４に対して認証を行うことを試みることができるが、（たとえば、秘密キーが利用不能であるために）失敗している。Ｈ（ｅ）ＮＢ１８０２は、認証の試み中にＨ（ｅ）ＮＢ１８０２のインテグリティーに関するＴｒＥによって署名された情報を提供することができる。１８１８においては、ＳｅＧＷ１８０４は、インテグリティー情報（たとえば、障害レポート）をネットワーク妥当性確認エンティティー１８０８へ転送することができる。ネットワーク妥当性確認エンティティー１８０８は、自分が受信する情報に基づいて、ＳｅＧＷ１８０４を通じた一部のＨ（ｅ）ＮＢ１８０２トラフィックを許可しないことを決定すること、およびＨ（ｅ）ＮＢ１８０２トラフィックのうちの一部またはすべてがＨ（ｅ）ＭＳ１８０６に限定されることを示すきめ細かいアクセス決定を１８２０において送信することが可能である。１８２２ａにおいては、ＳｅＧＷ１８０４は、認証失敗の指示を送信することができる。１８２４においては、ネットワーク妥当性確認エンティティー１８０８は、修復の目的でＨ（ｅ）ＮＢ１８０２のインテグリティー情報をＨ（ｅ）ＭＳ１８０６へ送信することができる。Ｈ（ｅ）ＭＳ１８０６は、１８２６においてＨ（ｅ）ＮＢ１８０２との（たとえば、ＳＳＬ／ＴＬＳイニシエーションを介した）セキュアなＩＰ接続を確立することができる。１８２８においては、Ｈ（ｅ）ＭＳ１８０６は、たとえば、認証失敗に基づいて、ソフトウェア修正を実行することを決定することができる。Ｈ（ｅ）ＮＢ１８０２およびＨ（ｅ）ＭＳ１８０６は、１８３０においてＨ（ｅ）ＭＳ１８０６による診断および問合せを可能にするように認証を行うことができる。Ｈ（ｅ）ＭＳ１８０６は、障害の原因を詳細に判定すること、および１８３２において（たとえば、リロードまたは更新のための）コード修復要求をソフトウェア修復エンティティー１８１０へ送信することが可能である。ソフトウェア修復エンティティー１８１０は、Ｈ（ｅ）ＮＢ１８０２のための代替ソフトウェアコンポーネント（たとえば、またはその一部）をビルドするために、１８３４においてソフトウェアビルドを実行することができる。１８３６においては、ソフトウェア修復エンティティー１８１０は、ソフトウェア修正情報（たとえば、修復イメージ）をＨ（ｅ）ＭＳ１８０６に提供することができる。Ｈ（ｅ）ＭＳ１８０６は、１８３８においてＨ（ｅ）ＮＢ１８０２との（たとえば、ＳＳＬ／ＴＬＳイニシエーションを介した）セキュアなＩＰ接続を確立することができる。Ｈ（ｅ）ＮＢ１８０２およびＨ（ｅ）ＭＳ１８０６は、Ｈ（ｅ）ＮＢ１８０２を修正するためのソフトウェア／ファームウェアダウンロードを可能にするように認証を行うことができる。Ｈ（ｅ）ＭＳ１８０６は、１８４０においてＨ（ｅ）ＮＢ１８０２のソフトウェア／ファームウェアをダウンロードすることができる。１８４２においては、Ｈ（ｅ）ＮＢ１８０２は、リブートすること、および／またはダウンロードされたコードをロードして実行することが可能である。
図１８Ｂは、即時の限定されたアクセスおよび洗練されたアクセスの制御を伴う、リモートソフトウェア障害／修復に関連する例示的なコールフロー図を示している。このコールフローについては、Ｈ（ｅ）ＮＢを使用して説明するが、その他のネットワークデバイスを使用することもできる。図１８Ｂのコールフローシーケンスは、図１８Ａにおいて示されているコールフローと同じ、または同様である多くのステップを含むことができる。しかし、図１８Ｂにおいて示されているように、ＳｅＧＷ１８０４に対するＨ（ｅ）ＮＢ１８０２の認証は、成功することができるが、ＳｅＧＷ１８０４は、Ｈ（ｅ）ＮＢ１８０２に対するアクセスを限定することができる。たとえば、１８１４におけるインテグリティーチェックフェーズ中に、Ｈ（ｅ）ＮＢ１８０２は、オペレーションのために使用されるコード内で障害を見つけ出すことができ、したがって、Ｈ（ｅ）ＮＢの１８０２ ＴｒＥは、ＳｅＧＷ１８０４の認証のための秘密キーを利用可能にすることはできない。しかしＴｒＥは、Ｈ（ｅ）ＮＢ１８０２がＨ（ｅ）ＭＳ１８０６にセキュアに接続可能とすることができることを認識することができ、したがって、Ｈ（ｅ）ＮＢ１８０２にとって可能である手続に関するＨ（ｅ）ＭＳ１８０６の認証のための（１つまたは複数の）秘密キーを利用可能にする。１８１６においては、Ｈ（ｅ）ＮＢ１８０２は、（たとえば、ＩＫＥｖ２プロトコルを使用して）ＳｅＧＷ１８０４に対して認証を行うことを試みることができる。Ｈ（ｅ）ＮＢ１８０２は、認証の試み中にＨ（ｅ）ＮＢ１８０２のインテグリティーに関するＴｒＥによって署名された情報を提供することができる。１８１８においては、ＳｅＧＷ１８０４は、インテグリティー情報をネットワーク妥当性確認エンティティー１８０８へ転送することができる。ネットワーク妥当性確認エンティティー１８０８は、受信された情報に基づいて、Ｈ（ｅ）ＮＢ１８０２に対する認証を決定することができ、これをＳｅＧＷ１８０４へ送信することができる。ＳｅＧＷ１８０４は、ネットワーク妥当性確認エンティティー１８０８からの情報に基づいて、Ｈ（ｅ）ＮＢ１８０２を認証することができるが、Ｈ（ｅ）ＮＢ１８０２のアクセスを限定することができる。１８２２ｂにおいては、ＳｅＧＷ１８０４は、認証は成功したが、ＳｅＧＷ１８０４はアクセスを限定している旨の指示をＨ（ｅ）ＮＢ１８０２へ送信することができる。図１８Ｂのプロトコルフローにおいて示されているステップのうちの残りは、図１８Ａのプロトコルフローにおいて示されているステップと同じ、または同様とすることができる。
図１９は、ＳｅＧＷアクセスを伴うＨ（ｅ）ＮＢソフトウェアコンポーネントの修復に関連する例示的なコールフロー図を示している。コールフローシーケンスは、本明細書に記載されているステップのうちの１つまたは複数を含むことができる。加えて、このコールフローについては、Ｈ（ｅ）ＮＢを使用して説明するが、その他のネットワークデバイスを使用することもできる。図１９において示されているように、Ｈ（ｅ）ＮＢ１９０２は、１９１２においてセキュアブートシーケンスを実行することができる。１９１４におけるインテグリティーチェックフェーズ中に、Ｈ（ｅ）ＮＢ１９０２は、デバイスコード内の障害を見つけ出すことはできないが、マップ内の障害、欠落しているコンポーネント、または構成の欠如を見つけ出すことができる。Ｈ（ｅ）ＮＢの１９０２ ＴｒＥは、ＳｅＧＷ１９０４の認証のための秘密キーを利用可能にすることができる。たとえば、Ｈ（ｅ）ＮＢ１９０２は、ＳｅＧＷ１９０４に対する秘密キーを含むステータスレポートを（たとえば、ＩＫＥを使用して）１９１６において送信することができる。ＳｅＧＷ１９０４は、インテグリティー情報を１９１８においてネットワーク妥当性確認エンティティー１９０８へ転送することができる。ネットワーク妥当性確認エンティティー１９０８は、受信された情報に基づいて、Ｈ（ｅ）ＮＢ１９０２に対する認証を決定することができ、これをＳｅＧＷ１９０４へ送信することができる。たとえば、ネットワーク妥当性確認エンティティー１９０８は、オペレータポリシーに従ったきめ細かいアクセス決定を１９２０においてＳｅＧＷ１９０４へ送信することができる。ＳｅＧＷ１９０４は、ネットワーク妥当性確認情報に基づいて、Ｈ（ｅ）ＮＢ１９０２を認証すること、および／またはオペレータポリシーに従ったアクセス許可を設定することが可能である。１９２２においては、ＳｅＧＷ１９０４は、認証の成功の指示をＨ（ｅ）ＮＢ１９０２へ送信することができる。ネットワーク妥当性確認エンティティー１９０８は、１９２４においてＨ（ｅ）ＮＢのインテグリティー情報をＨ（ｅ）ＭＳ１９０６へ送信することができる。たとえば、インテグリティー情報を、再構成の目的で送信することができる。Ｈ（ｅ）ＭＳ１９０６は、障害を修復するために使用することができる修復情報（たとえば、ソフトウェア／パラメータ）を１９２６において判定することができ、（たとえば、リロードまたは更新のための）修復要求を１９２８においてソフトウェア修復エンティティー１９１０へ送信することができる。ソフトウェア修復エンティティー１９１０は、Ｈ（ｅ）ＮＢ１８０２のための代替ソフトウェアコンポーネント（たとえば、またはその一部）をビルドするために、１９３０においてソフトウェアビルドを実行することができる。１９３２においては、ソフトウェア修復エンティティー１９１０は、修復情報（たとえば、修復イメージまたはソフトウェア／構成更新）をＨ（ｅ）ＭＳ１９０６に提供することができる。Ｈ（ｅ）ＭＳ１９０６は、１９３４において修復情報をＳｅＧＷ１９０４へ転送することができる。ＳｅＧＷ１９０４およびＨ（ｅ）ＮＢ１９０２は、１９３６において（たとえば、ＩＫＥｖ２またはＩＰｓｅｃを使用して）セキュアなＩＰ接続を認証して確立することができる。１９３８においては、ＳｅＧＷ１９０４は、修復情報（たとえば、修復イメージまたはソフトウェア／ファームウェアの更新）をＨ（ｅ）ＮＢ１９０２へダウンロードすることができる。たとえば、ＳｅＧＷ１９０４は、障害の生じているクリティカルでないソフトウェア／パラメータの更新（たとえば、ＩＫＥおよび／またはＩＰｓｅｃの更新）を送信することができる。
デバイスは、レガシーの能力および進化した能力の両方を有する場合がある。レガシー能力のためのネットワークサービスは、一般に利用可能であると言える。進化した能力のためのネットワークサービスは、まばらであり、および／または完全にはサポートされていないと言える。展開の問題を緩和する目的で、オペレータは、進化した能力に徐々に慣れるためにレガシーの能力を活用することができる。そのような活用は、本明細書に記載されているように用いることができる。たとえば、あるデバイスを、あるロケーションにおいてレガシーデバイスとしてネットワークに接続することができる。ネットワークは、そのデバイスを認証することと、自分のサブスクリプションにおいて、そのデバイスが、進化した能力、および／または進化した能力をセキュアにサポートする能力を有する可能性があることを認識することとが可能である。そのロケーションに関するネットワークが、進化した能力をサポートしている場合には、ネットワークマネージメントエンティティーは、そのデバイスのアクセスポイントに、更新サーバへのきめ細かいアクセスを提供することができる。そのデバイスは、レガシーアクセスポイントを通じて更新サーバにアクセスすることができる。いくつかの実施態様においては、デバイスのサブスクリプションは、レガシーサービスではなく進化機能へのアクセスを制限することができ、したがって、アクセスポイントは、レガシーネットワーク全般ではなく更新サーバへのデバイスのアクセスを制限することができる。更新サーバおよびデバイスは、互いに認証を行うことができる。更新サーバは、デバイスの進化した能力の妥当性を（たとえば、認証を通じて黙示的に、もしくは明示的に）確認すること、ならびに／または、デバイスが新たなタイプのデバイスとして直接再接続することを可能にするために、アクセス証明書、構成情報、アクセスポイントアドレス、および／もしくはコードをデバイスに供給することが可能である。デバイスは、ネットワークアクセス認証のために、共有されたまたは非対称のキーペアを生成する能力を有することができる。ネットワークは、新たなデバイス証明書によってデバイスサブスクリプションデータベースを更新することができる。デバイスは、進化したネットワークのロケーションのためのアクセス証明書を、保護された領域内に組み込む能力を有することができる。オンライン証明書生成は、進化したネットワークへの事前に妥当性を確認されたその後の接続を可能にすることができる。ネットワークは、進化したネットワーク（進化した能力をサポートするネットワーク）へのアクセスポイントに、特定の証明書のデバイスが、進化したネットワークに接続することができるということを知らせることができる。デバイスは、更新された証明書を使用して、進化したネットワークにアクセスすることができる。進化したネットワークのエンティティーは、そのデバイスを、進化したデバイスとして認証することができる。
マネージメント認証のための手続には、少なくとも２つのステージが存在することができる。一方は構成のためのものであり、他方は修復のためのものであることが可能である。構成のケースにおいては、ネットワークマネージメントエンティティーは、中継ノードの能力を、オペレータのコアネットワークに対するその後の認証手続のために、オペレータ証明書を確信を持ってインストールするデバイスとして認証することができる。その中継器は、プラットフォーム認証を使用したプラットフォームの自律的な妥当性確認の手段を通じて、ネットワークエンティティーに暗示的な証明を提供することができる。マネージメントエンティティーは、デバイスを認証すること、および／またはＲＮの製造業者の証明書の妥当性を確認することによって、ＲＮのインテグリティーが危うくされていないことを知ることができる（なぜなら、自律的な妥当性確認は、たとえばデバイスのインテグリティーに関する内部の検証が合格である場合には、秘密認証キーをリリースすることができるためである）。
修復のケースにおいては、ＲＮは、何らかのクリティカルでない障害によって完全なデバイスインテグリティーチェックが不合格になったことに起因して、マネージメントエンティティーとともにリモート修正手続を実行することができる。このケースにおいては、ＲＮのマネージメント能力が損なわれていない場合には、ＲＮは、完全なデバイスインテグリティー証明書ではなく、マネージメント能力証明書を認証の目的でマネージメントエンティティーへ送信することができる。ネットワークマネージメントエンティティーは、デバイスを認証すること、および証明書を検証することが可能である。合格すると、ネットワークマネージメントエンティティーは、中継器の能力をブートストラップするためのリモート手続を実行することができる。
その手続は、最初の限定された範囲のケースにおいてＲＮの能力をブートストラップするために使用することができる。このケースにおいては、第１の証明書は、マネージメントエンティティーとともに基本的なオペレーションを実行する能力を表すことができる。第２の証明書は、マネージメントエンティティーとともにさらに広いオペレーションを実行する能力を表すことができる。このケースにおいては、中継器は、増大された機能の範囲を伴うインテグリティー障害を検知することができない。インテグリティーチェックの範囲は、強化された機能に対応するためにさらなる更新されたポリシーを提供することによっても増大させることができる。この方法においては、デバイスの能力は、インテグリティーチェックの程度とともに増大することができる。
この技術は、セキュリティーゲートウェイ認証全般に適用することができる。デバイスの限定された範囲を表す証明書は、コアネットワークに対するゲートウェイ認証のケースにおいて使用することができ、それによって、そのネットワークは、認証中に、その認証の特権を判定することができる。ゲートウェイ（たとえば、ＨｅＮＢ認証におけるＳｅＧＷ、またはＲＮ認証に関するＤｅＮＢ）は、デバイスを認証すること、および証明書を検証することが可能である。証明書上の情報および特定のデバイスＩＤの認証の成功に基づいて、ゲートウェイは、修復または登録の目的でネットワークマネージメントエンティティーに対するアクセスを制限することができる。中継器が成功裏に構成、更新、および／または修復されると、認証キーを、認証ベースの機能強化のために利用可能とすることができる。
図２０は、能力の中継ノードブートストラッピングに関連する例示的なコールフロー図を示している。コールフローシーケンスは、本明細書に記載されているステップのうちの１つまたは複数を含むことができる。たとえば、図２０において示されているように、ＲＮ（Ｒｅｌａｙ Ｎｏｄｅ）２００２は、２０１４においてセキュアブートシーケンスを実行することができる。２０１６においては、ＲＮ２００２は、セキュアな環境を確立すること、および／または自律的な妥当性確認を実行することが可能である。自律的な妥当性確認の最中に、ＲＮ２００２は、障害を見つけ出すことができない。２０１８においては、ＲＮ２００２は、たとえばＭＭＥ／ＨＳＳ２０１２などにおいて、ｅＮＢ２００４を通じてＵＥとしてネットワークに接続することができる。ＭＭＥ２０１２は、２０２０において登録サーバ２００８への限定されたアクセスをＲＮ２００２に割り当てることができる。図２０において示されているように、その限定されたアクセスは、ｅＮＢ２００４を通じて割り当てることができる。ＲＮ２００２および登録サーバ２００８は、互いに認証を行うことができる。２０２２においては、ＲＮ２００２は、登録要求を登録サーバ２００８へ送信することができる。２０２４においては、登録サーバは、ＲＮ２００２に対する妥当性確認、構成、および／または証明書の発行を行うことができる。登録サーバ２００８は、ＲＮ２００２のセキュアな環境によるＲＮの２００２秘密登録サーバ認証キーの使用のリリースを通じて黙示的にＲＮ２００２の妥当性を確認することができ、または登録サーバ２００８は、ＲＮレポートの問合せによってＲＮ２００２の妥当性を確認することができる。登録サーバ２００８は、妥当性を確認されたＲＮ２００２をＤｅＮＢ２００６の接続用に構成することができ、証明書を発行することができる。登録サーバ２００８は、デバイス上のＲＮポリシーを更新して、その後のリブート上の登録ステップを迂回すること、および登録情報を自律的な妥当性確認プロセス内に含めること（たとえば、登録情報をカバーするＴＲＶを加えること）が可能である。新たな秘密キーを、ＲＮ２００２上にインストールすること、またはこのステージにおいてアクティブ化することが可能である。ＲＮ２００２は、キー生成能力を有することができ、そのケースにおいては、キーペアをＲＮ２００２上で生成することができる。ＲＮ２００２は、自分のセキュアな環境内に秘密キーをインストールすることができ、このキーのリリースを登録構成およびさらに低いレベルのセキュアブートステージに結び付けることができる。２０２６においては、登録サーバ２００８は、登録が完了したことを中継ノード２００２に示すことができる。２０２８においては、ＲＮ２００２は、ＤｅＮＢ２００６を通じてＲＮとしてネットワークに接続することができる。ＭＭＥ２０１２は、ＤｅＮＢ２００６を通じた構成サーバ２０１０への限定されたアクセスを２０３０においてＲＮ２００２に割り当てることができる。２０３２においては、ＲＮ２００２は、ＲＮ構成要求を構成サーバ２０１０へ送信することができる。構成サーバ２０１０は、２０３４においてＲＮ２００２に対する妥当性確認、構成、および／または証明書の発行を行うことができる。たとえば、構成サーバ２０１０は、妥当性を確認されたＲＮ２００２をオペレーション用に構成することができ、証明書を発行することができる。構成サーバ２０１０は、デバイス上のＲＮポリシーを更新して、その後のリブート上の構成ステップを迂回すること、および構成情報を自律的な妥当性確認プロセス内に含めること（たとえば、構成情報をカバーするＴＲＶを加えること）が可能である。ＤｅＮＢ２００６の認証のための新たな秘密キーを、このステージにおいてインストールまたはアクティブ化することができる。構成サーバ２０１０は、構成が完了したことを２０３６においてＲＮ２００２に示すことができる。２０３８においては、ＲＮ２００２は、ＤｅＮＢ２００６とのＳ１セットアップを開始することができる。２０４０においては、ＲＮ２００２は、ＤｅＮＢ２００６とのＸ２セットアップを開始することができる。ＲＮ２００２は、２０４２において中継ノードとして機能することができる。
２０４４においては、ＲＮ２００２上でリセットを行うことができる。このリセットは、たとえば、ネットワーク、デバイス、または停電によって開始されることがある。２０４６においては、ＲＮ２００２は、セキュアブートシーケンスを実行することができる。２０４８におけるセキュアな環境の確立および／または自律的な妥当性確認の最中に、ＲＮ２００２は、障害を見つけ出すことができない。登録サーバ２００８の情報および／または構成サーバ２０１０の情報を２０４８において自律的な妥当性確認プロセス内に含めることができるため、ＲＮ２００２は、サーバに関与する必要なく、Ｓ１インターフェースおよびＸ２インターフェースをそれぞれ２０５０および２０５２においてセットアップすることへ進むことができる。ＲＮ２００２は、２０５４においてＲＮとして機能することもできる。登録サーバの情報または構成サーバの情報上で障害が生じている場合には、ポリシーは、再構成が行われるまで、秘密認証キーのリリース、またはその後のネットワークプロセスの実行を許可すること、または許可しないことが可能である。
図２１は、認証されたマネージメント能力を用いた中継ノード修復に関連する例示的なコールフロー図を示している。コールフローシーケンスは、本明細書に記載されているステップのうちの１つまたは複数を含むことができる。たとえば、図２１において示されているように、ＲＮ（Ｒｅｌａｙ Ｎｏｄｅ）２１０２は、２１１４においてセキュアブートシーケンスを実行することができる。２１１６においては、ＲＮ２１０２は、セキュアな環境を確立すること、および／または自律的な妥当性確認を実行することが可能である。２１１６における自律的な妥当性確認の最中に、ＲＮ２１０２は、デバイスのクリティカルでないコンポーネントに対する障害を見つけ出すことができる。２１１８においては、ＲＮ２１０２は、ｅＮＢ２１０４を通じてＵＥとしてネットワーク（たとえば、ＭＭＥ／ＨＳＳ２１１２）に接続することができる。２１２０においては、ＭＭＥ２１１２は、登録サーバ２１０６および／または修復サーバ２１１０への限定されたアクセスをＲＮ２１０２に割り当てることができる。ＭＭＥ２１１２は、たとえばｅＮＢ２１０４を通じて、限定されたアクセスを割り当てることができる。ＲＮ２１０２および修復サーバ２１１０は、互いに認証を行うことができる。２１２２においては、ＲＮ２１０２は、アラーム（たとえば、修復要求）を修復サーバ２１１０へ送信することができる。修復サーバ２１１０は、２１２４においてＲＮ２１０２のセキュアな環境によるＲＮの２１０２秘密修復サーバ認証キーの使用のリリースを通じて黙示的にＲＮマネージメント能力の妥当性を確認することができ、および／または、修復サーバ２１１０は、（１つまたは複数の）ＲＮ２１０２インテグリティーステータスレポートの問合せによってＲＮ２１０２の妥当性を確認することができる。２１２６においては、ＲＮ２１０２および修復サーバ２１１０は、ＲＮ２１０２の問合せを（任意選択で）実行することができる。修復サーバ２１１０は、２１２８においてＲＮ２１０２を修復すること（たとえば、再構成すること、修正すること、または再プログラムすること）、および障害を修繕するために修復情報を２１３０においてＲＮ２１０２へ送信することが可能である。
修復サーバ２１１０は、２１３２においてセキュアにリブートするようにＲＮ２１０２にリモートから命令することができ、または、ＲＮ２１０２が電源投入ステージの第１のフェーズを既に実行しており、デバイスインテグリティーチェックが、たとえば単なるマネージメント認証ではなく、今回はプラットフォーム認証に関して合格しているため、ＲＮ２１０２は、ＲＮ２１０２電源投入シーケンスにおける次なるステップへ直接進むことができる。たとえば、２１３４においては、ＲＮ２１０２は、セキュアな環境を確立すること、および／または自律的な妥当性確認を実行することが可能である。２１３６においては、ＲＮ２１０２は、ｅＮＢ２１０４を通じてＵＥとしてネットワーク（たとえば、ＭＭＥ／ＨＳＳ２１１２）に接続することができる。２１３８においては、ＭＭＥ２１１２は、登録サーバ２１０６および／または修復サーバ２１１０への限定されたアクセスをＲＮ２１０２に割り当てることができる。ＲＮ２１０２は、２１４０において登録サーバ２１０６に登録要求を行うことができる。２１４２においては、登録サーバ２１０６は、ＲＮ２１０２に対する妥当性確認、構成、および／または証明書の発行を行うことができる。登録サーバ２１０６は、登録が完了したことを２１４４においてＲＮ２１０２に示すことができる。
インテグリティーチェック、報告、および修復用として本明細書に記載されている手続、システム、および手段は、本明細書に記載されているようなソフトウェア障害、ＴＲ−０６９、ソフトウェア修復、Ｈ（ｅ）ＮＢなどに限定されるものではないと言える。さらに、記載されているアクションは、例示的であることを意図されている。その他のアクションを使用することもでき、使用しない場合には省略することもでき、および／またはアクションを追加することもできるということを理解されたい。
いくつかの実施態様においては、障害は、ソフトウェアではなく、構成データまたはデバイス上のその他の何らかの測定可能なコンポーネントである場合がある。そのような一実施態様においては、マネージメントエンティティーは、更新をソフトウェア修復エンティティーから受信することはできず、たとえばネットワークデバイス構成データベースから受信することができる。すべての障害シナリオが、問合せ的な手続を使用することができるわけではない。これらのケースにおいては、はじめにデバイスからのアラームまたはレポートとして送信された情報は、障害の原因を判定するのに十分であるか、または少なくとも、マネージメントエンティティーが問合せを伴わずに修復手続を開始することができる何らかのアクションを実行することができると判定するのに十分である場合がある。たとえば、マネージメントエンティティーは、同様のデバイスの以前の障害から障害の生じているコンポーネント測定値を認識することができ、したがって、すぐに更新をデバイスへ提示することができる。おそらくは小さなコンポーネントに起因する、問合せと更新との間の時間およびトラフィックロードにおけるトレードオフは、完全なコンポーネント更新をトリガーすることができる。
以降の例においては、デバイスアーキテクチャーおよび修復更新手続について説明する。この例示的なデバイスアーキテクチャーおよび修復更新手続は、限定された複雑さおよびリソースを有する小さなフットプリントのデバイスとともに使用することができる。この例に関連付けられている制約について、本明細書において説明することができる。たとえば、デバイスのアプリケーションコードベースおよび信頼済みコードベースは、それらの開発および／または展開ライフサイクル、ならびにそれらのオペレーションに関して別々のものとすることができる。これらの２つのコードベースは、別々の当事者によって開発および／または展開することができる。デバイスの生産性機能を提供することができるデバイスのアプリケーションコードベースは、単一のコードおよびデータブロックとしてデバイスの不揮発性メモリの一部分内に展開することができる。アプリケーションコードベースは、修復に最小限関与することが可能であり、および／またはインテグリティーの妥当性確認に関与しないことが可能である。サービスサイクル（たとえば、デバイスのアプリケーションによって使用することができる、デバイスのコードベースのうちの複数の部分の更新どうしの間におけるアップタイム）は、長くなる場合がある。これは、たとえば、修復のためのリブートは任意の時点において無差別に強制することはできないということを意味すると言える。デバイスの通常のオペレーションは、修復またはデバイス更新手続のために中断することはできない。インテグリティーの妥当性確認および修復のための通信は、デバイススタートアップの初期のステージにおいて行うことができ、その間は、デバイスの内部リソースの使用および通信帯域幅に関する厳しい制限を適用することができる。コンポーネント（たとえば、プログラムおよびデータ）を１つずつ別々にロードして始動することができる典型的なブートサイクルという意味で複雑なシステムスタートアップはないと言える。
例示的なシステムモデルは、上記の制限を考慮に入れて、システムをＴｒＥおよび通常のコンポーネントへと一般的に分割した一バージョンとして説明することができる。システムアーキテクチャーの機能要素としては、下記のうちの１つまたは複数を含むことができる。
ＲｏＴ（Ｒｏｏｔ ｏｆ Ｔｒｕｓｔ）、これは、信頼の連鎖においてデバイスインテグリティーの妥当性確認が依存する不変の要素であると言える。
ＳＥＥ（Ｓｅｃｕｒｅ Ｅｘｅｃｕｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔ）、これは、システムのうちの残りの部分から分離された、実行可能なコードおよびデータのハードウェアおよび／またはソフトウェア保護を伴う特別な実行環境であると言える。可能な実現形態は、プロセッサのセキュアな実行モード、またはプロセッサ内の別個のカーネルとすることができる。ＳＥＥ上の制限としては、ランタイムメモリおよび利用可能な（ＳＥＥ専用の）ＮＶＳ（ｎｏｎ−ｖｏｌａｔｉｌｅ ｓｔｏｒａｇｅ）上の制限を含むことができる。
Ｃｏｍｍ ＩＦ（Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｉｎｔｅｒｆａｃｅ）コンポーネント、これは、基本的な通信能力をＳＥＥおよび／またはＮＥＥに露出することができる。ならびに／あるいは
ＮＥＥ（Ｎｏｒｍａｌ Ｅｘｅｃｕｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔ）、これは、デバイス内のアプリケーションコード、たとえば、ＴｒＥに属していないコードの実行環境であると言える。ＮＥＥは、ＳＥＥの能力への、たとえばこの通信能力を再使用するためにＣｏｍｍ ＩＦへの特定のインターフェースを有することができる。
これらの機能要素は、デバイスの能力およびコンポーネントを含むいくつかのコードベースによって使用することができる。ＴｒＥＣＢ（ＴｒＥ Ｃｏｄｅ Ｂａｓｅ）およびＤＡＣＢ（Ｄｅｖｉｃｅ Ａｐｐｌｉｃａｔｉｏｎ Ｃｏｄｅ Ｂａｓｅ）へと分割を行うことができる。ＴｒＥＣＢは、ＳＥＥに割り当てることができ、ＤＡＣＢは、ＮＥＥに割り当てることができる。ＤＡＣＢコンポーネントがＴｒＥの能力にアクセスする場合には、そのようなアクセスは、ＮＥＥとＳＥＥとの間における言及したインターフェースを介して実行することができる。ランタイムにおいて、たとえば、セキュアスタートアップの後に、ＮＥＥ上のＳＥＥから実行制御を行わないことが可能であり、その逆もまた同様である。ＴｒＥＣＢおよびＤＡＣＢは、ＮＶＳの別々の部分に格納することができる。
図２２は、機能コンポーネント２２０２（左側）およびコード／データストレージコンポーネント２２０４（右側）からなる例示的なシステムを示している。機能コンポーネント２２０２は、ＮＥＥ２２０６およびＳＥＥ２２０８を含むことができる。ＳＥＥ２２０８は、通信インターフェース２２１０および／またはＲＯＴ２２１２を含むことができる。コード／データストレージコンポーネント２２０４は、ＮＶＳコンポーネントを含むことができる。ＮＶＳコンポーネントＴＲＶ＿ｔｍｐ２２１４は、ＮＥＥ２２０６に関連付けられているＴＲＶを含むことができる。ＮＶＳコンポーネントＤＡＣＢ２２１６は、ＤＡＣＢを含むことができる。ＮＶＳコンポーネントＴＲＶ ＮＶＳ２２１８は、ＳＥＥ２２０８に関連付けられているＴＲＶを含むことができる。ＮＶＳコンポーネントＴｒＥＣＢ ＮＶＳ２２２０は、ＴｒＥＣＢを含むことができる。別々のセキュリティー測定を複数のＮＶＳ区画に別々に適用することができる。矢印は、図２２において示されているエンティティーどうしの間における読み取り／書き込みアクセスを示すことができる。ＴｒＥＣＢ ＮＶＳ２２２０は、ＩＶＣ（ｉｎｔｅｇｒｉｔｙ ｖａｌｉｄａｔｉｏｎ ｃａｐａｂｉｌｉｔｙ）、ＤＧＣ（ｄｅｖｉｃｅ ｇｅｎｅｒｉｃ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｃａｐａｂｉｌｉｔｙ）、ＦＢ／ＤＣ（ｆａｌｌ ｂａｃｋ／ｄｉｓｔｒｅｓｓ ｃａｐａｂｉｌｉｔｙ）、およびＲＣ（ｒｅｍｅｄｉａｔｉｏｎ ｃａｐａｂｉｌｉｔｙ）などのさまざまな能力を提供することができる。これらの能力については、本明細書においては図２２および図２３に関連して論じる。
図２２において示されているように、ＮＥＥ２２０６は、ＳＥＥ２２０８との間で通信状態にあること（たとえば、読み取りおよび／または書き込みを行うこと）が可能である。ＳＥＥ２２０８は、通信インターフェース２２１０を使用して通信を行うことができる。ＳＥＥ２２０８は、コード／データストレージコンポーネントを用いて実行されるインテグリティー妥当性確認のためにＲＯＴ２２１２を使用することができる。ＮＥＥ２２０６は、ＮＶＳコンポーネント２２１４への書き込み、およびＮＶＳコンポーネント２２１６からの読み取りを行うことができる。ＳＥＥ２２０８は、ＮＶＳコンポーネント２２１４からの読み取りを行うことができる。ＳＥＥ２２０８は、ＮＶＳコンポーネント２２１６、２２１８、および２２２０との間で読み取りおよび書き込みを行うこともできる。
図２３は、ブートシーケンスの諸ステージの例示的な一実施形態と、それぞれのステージにおいて実施されるさまざまなエンティティーどうしの間における対話とを示している。図２３において示されているように、ＮＥＥ２２０６およびＳＥＥ２２０８は、ブートシーケンスにおいて実施することができる。ＳＥＥ２２０８は、ブートシーケンスの第１および第２のステージのために使用することができる。第１のステージは、ＲＯＴ２２１２を組み込むことができる。第２のステージは、ＴｒＥＣＢ ＮＶＳ２２２０を組み込むことができ、ＴｒＥＣＢ ＮＶＳ２２２０は、ＩＶＣ（ｉｎｔｅｇｒｉｔｙ ｖａｌｉｄａｔｉｏｎ ｃａｐａｂｉｌｉｔｙ）２３１８、ＤＧＣ（ｄｅｖｉｃｅ ｇｅｎｅｒｉｃ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｃａｐａｂｉｌｉｔｙ）２３１４、ＦＢ／ＤＣ（ｆａｌｌ ｂａｃｋ／ｄｉｓｔｒｅｓｓ ｃａｐａｂｉｌｉｔｙ）２３２０、ＲＣ（ｒｅｍｅｄｉａｔｉｏｎ ｃａｐａｂｉｌｉｔｙ）２３２４、および／またはＴＲＶ２３２６を含むことができる。ＩＶＣ２３１８は、コンポーネントの測定値を取り、それらの測定値を、たとえばＴＲＶ２３２６などのＴＲＶに含まれている基準値と比較するというタスクを負うことができる。ＤＧＣ２３１４は、ＳＥＥ２２０８に基本的な通信機能を提供することができる（その通信機能は、ひいてはＮＥＥ２２０６に露出することができる）。ＤＧＣ２３１４は、ＦＢ／ＤＣ２３２０およびＲＣ２３２４によって修復および／または障害指示のために使用することができる。ＤＧＣ２３１４は、インターフェースを介してＤＡＣ２３２２に露出することもできる。ＦＢ／ＤＣ２３２０は、関連機能、すなわち、それぞれネットワークまたはデバイスユーザに障害状況を示す、フォールバックコードベースによるＤＡＣＢ２２１６の置換を実行するための特定の条件が満たされている場合に、アクティブ化することができる。ＲＣ２３２４は、コードベースの計画された変更および／または訂正のタスクを負ったオーソリティー（ａｕｔｈｏｒｉｔｙ）とすることができる。ＲＣ２３２４は、ＴＲＶ２３２６のマネージャーとすることもでき、ＲＣ２３２４は、ＴＲＶ２３２６の真正性をチェック可能とすることができる。
ＮＥＥ２２０６は、ブートシーケンスの第３のステージのために使用することができる。第３のステージは、ＤＡＣＢ２２１６を組み込むことができ、ＤＡＣＢ２２１６は、ＲＡＩＦ（ｒｅｍｅｄｉａｔｉｏｎ ａｐｐｌｉｃａｔｉｏｎ ＩＦ）２３１６および／またはＤＡＣ（ｄｅｖｉｃｅ ａｐｐｌｉｃａｔｉｏｎ ｃａｐａｂｉｌｉｔｉｅｓ）２３２２を含む。ＲＡＩＦ２３１６は、ネットワークからの入ってくる新たなＴＲＶのためのパススルーインターフェースとすることができる。ＲＡＩＦ２３１６は、入ってくる通信内のＴＲＶを認識して、それらのＴＲＶをＴＲＶ用の一時的な不揮発性ストレージに格納することができる。ＤＡＣ２３２２は、デバイスのアプリケーション固有の機能を具体化することができる。ＤＡＣがＣｏｍｍ ＩＦからの通信能力を使用したい場合には、Ｃｏｍｍ ＩＦへのアクセスは、特別なＮＥＥ−ＳＥＥ ＩＦを通じて仲介されることが可能である。
ＴＲＶ２３２６は、システム内の２つの異なる場所に格納することができる。ＴＲＶ＿ｔｍｐ２２１４は、ＲＡＩＦ２３１６によって受信された新たなＴＲＶのための一時的なストレージとすることができ、たとえば、ＴＲＶ＿ｔｍｐ２２１４は、ＮＥＥ２２０６から書き込み可能とすることができる。ＴＲＶ＿ｔｍｐは、ＳＥＥ２２０８から読み取り可能とすることができ、ＳＥＥ２２０８から、ＲＣ２３２４は、新たなＴＲＶを読み取ることができ、それらのＴＲＶが認証されると、それらのＴＲＶをＴＲＶ ＮＶＳ２２１８内に置くことができる。
図２３において示されているスタートアップシーケンスは、簡略化されたシステムアーキテクチャーにおけるインテグリティーチェックを伴う通常のスタートアップ、たとえば、障害／フォールバックまたは修復アクションを必要とすることがある障害状況が生じていないスタートアップに関連することができる。セキュアスタートアップの第１のステージにおいては、ＲｏＴ２２１２をアクティブ化することができる。セキュアスタートアップの第２のステージに関する前の説明とは異なり、ＲｏＴ２２１２は、ロードされて始動されるコンポーネント上でさらなるインテグリティーチェックを実行することができる信頼済みブートローダを検証してアクティブ化することはできない。そのようなローダ／実行コントローラは、簡略化されたシステムアーキテクチャーにおいては利用可能ではない場合がある。その代わりに、ＲｏＴ２２１２は、ＴｒＥＣＢ ＮＶＳ２２２０においてＩＶＣ２３１８コードおよびデータブロックをチェックすることができる。この構造においては、ＩＶＣ２３１８コードは不変とすることができる。なぜなら、ＲｏＴ２２１２は、ＴＲＶ２３２６を読み取る能力を有することができないためである。したがってＲｏＴ２２１２は、ＩＶＣ２３１８を、固定された（ＲｏＴ２２１２内に）組み込まれた基準値に照らしてチェックすることができる。
一実施形態においては、ＲｏＴ２２１２は、固定されたルート証明書を使用して、ＩＶＣ２３１８コードおよびデータブロックをチェックすることができる。このために、ＴｒＥＣＢ ＮＶＳ２２２０のうちのＩＶＣ２３１８の部分は、ＴｒＥＣＢ ＮＶＳ２２２０のうちのこの後者のＩＶＣ２３１８の部分に関する署名とともに格納することができる。ＲｏＴ２２１２がその署名をチェックする際に使用することができるキーは、言及した固定されたルート証明書内に存在することができる。ＩＶＣ２３１８コードの変更は、新たなＩＶＣ２３１８コードを、同じ固定されたキーを使用するその新たなコードに関する新たな署名とともにダウンロードすること、および後者のデータをＴｒＥＣｂ ＮＶＳ２２２０内に格納することによって実施することができる。ＩＶＣ２３１８は、ＳＥＥ２２０８内で実行することができる。ＩＶＣ２３１８は、ＴＲＶ＿ｔｍｐ ＮＶＳ２２１４が空であることをチェックすることができる（これは、簡略化されたシステムアーキテクチャーにおけるインテグリティーチェックを伴う通常のスタートアップに関する前提とすることができる）。ＩＶＣ２３１８は、ＤＧＣ２３１４のコードに関する指定されたＴＲＶをＴＲＶ ＮＶＳ２２１８からロードすることができる。
ＩＶＣ２３１８は、ＴＲＶ基準値および任意のさらなるデータに関する署名を検証することによって、ＴＲＶ２３２６のそれぞれのロードされたＴＲＶのインテグリティーをチェックすることができる。この署名は、ＴＲＶ内に存在することができ、ＩＶＣ２３１８がその署名をチェックする際に使用することができるキーは、ＩＶＣ２３１８コード／データブロック内に存在する。次いでＩＶＣ２３１８は、ＴｒＥＣＢ ＮＶＳ２２２０からＳＥＥ２２０８内へロードされたＤＧＣ２３１４コードを測定して、その測定値を後者のＴＲＶ内の基準値と比較することができる。合格すると、ＤＧＣ２３１４をアクティブ化することができる。アクティブ化とは、たとえば、ＳＥＥ２３０４のうちでＤＧＣ２３１４が存在するランタイムメモリ部分上に「実行可能」というフラグを設定し、ＮＥＥ２２０６コードがチェックされる場合は常にＳＥＥ２２０８プロセッサおよびＮＥＥ２２０６プロセッサがこのフラグを尊重することを前提とすることによって、ＤＧＣ２３１４が実行のために利用可能にされることを意味することができる。
ＩＶＣ２３１８は、ＲＡＩＦ２３１６のコードに関する指定されたＴＲＶをＴＲＶ ＮＶＳ２２１８からロードすることができる。ＩＶＣ２３１８は、ＤＡＣＢ ＮＶＳ２２１６からＮＥＥ２２０６内へロードされたＲＡＩＦ２３１６コードを測定して、その測定値を、後者のＴＲＶ内に含まれている基準値と比較することができる。合格すると、ＲＡＩＦ２３１６をアクティブ化することができる。
ＩＶＣ２３１８は、事前に決定されたシーケンスでＤＡＣＢ２２１６の諸部分に関連付けられているそれぞれのＴＲＶをロードすることができる。ＩＶＣ２３１８は、ＤＡＣＢ ＮＶＳ２２１６からＮＥＥ２３０６内へロードされた、ロードされたＴＲＶによって指定されているＤＡＣ２３２２のコードおよびデータの諸部分を測定して、その測定値を、後者のＴＲＶ内に含まれている基準値と比較することができる。
ＤＡＣＢ２２１６におけるチェックが（たとえば、ＤＡＣＢ２２１６のコードおよびデータに関する利用可能なＴＲＶのシーケンスを使い果たすことによって）実行された場合には、ＩＶＣ２３１８は、ＤＡＣ２３２２をアクティブ化すること、および実行をＮＥＥ２２０６プロセッサに渡すことが可能である（または、ＳＥＥ２２０８およびＮＥＥ２２０６プロセッサが同時に動作することが可能である場合には、ＮＥＥ２２０６プロセッサを始動する）。ＦＢ／ＤＣ２３２０およびＲＣ２３２４のコードおよびデータのブロックは、スタートアップ手続において特別な状況（たとえば、インテグリティーチェック障害）が生じていない場合には、チェックもアクティブ化もされないことが可能である。
セキュアブートなど、より複雑なシステムにおけるセキュアスタートアップに対する相違としては、ＩＶＣ２３１８がＴＲＶデータによって駆動されることが可能であることを含むことができる。すなわち、ＴＲＶは、さまざまなコードベースのコードおよびデータのどの断片をチェックすべきかに関する情報を有することができる。ＴＲＶ２３２６は、ＩＶＣ２３１８によって順次読み取ることができ、ＩＶＣ２３１８は、それらのＴＲＶ２３２６を評価して、ＴＲＶ基準インテグリティー値が当てはまるコードおよびデータの断片を見つけ出すこと、ならびに、このデータを読み取ることおよび／または測定すること、および照合された測定値を基準値と比較することが可能である。
単一のＴＲＶ基準値は、１つのコードベース内のコードおよびデータの複数の断片に対応することができるため、ＴＲＶは、マッピング、たとえば、そのコードベース内のそれらの断片のロケーションおよび長さのインジケータ、ならびに、それらの断片の測定値どうしをどのように結合して複合測定値にするかに関する指示を含むことができる。図２４Ａおよび図２４Ｂは、ＴＲＶをコードベース内のコードおよび／またはデータの断片にマップする例示的な実施態様を示している。
図２４Ａは、ＴＲＶを作成するために線形に結合することができる部分的な測定値のシーケンスを示す図である。図２４Ａにおいて示されているように、ＤＡＣＢのコード測定値２４０２、２４０４、２４０６、２４０８、および２４１０は、ＴＲＶ２４１２を作成するために線形に結合することができる。例示的な一実施形態によれば、コード測定値２４０２、２４０４、２４０６、２４０８、および２４１０は、ＴＣＧによって指定されたＴｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ ＭｏｄｕｌｅのＴＰＭ−Ｅｘｔｅｎｄコマンドを用いて実現されるようなハッシュチェイニングを適用することによって結合することができる。
図２４Ｂは、ＴＲＶを作成するためにＭｅｒｋｌｅハッシュツリーを使用する値の組合せを示す図である。図２４Ｂにおいて示されているように、ＤＡＣＢのコード測定値２４１６、２４１８、２４２０、２４２２、２４２４、および２４２６は、ＴＲＶ２４１４を作成するためにＭｅｒｋｌｅハッシュツリーを使用して結合することができる。
修復および／または更新を実行するデバイスエンティティーと、対応するネットワークエンティティー（たとえば、Ｈ（ｅ）ＭＳ）との間におけるインタラクティブな問合せ手続は、本明細書に記載されている、ＴＲＶからコード／データ断片へのマッピングを利用することができる。本明細書に記載されているようなそのような手続は、本明細書に記載されている一般的なデバイス問合せ手続の特別な例であると言える。
コードのそれぞれの断片を測定することができ、その測定値をネットワークエンティティーへ１つずつ送信することができ、ネットワークエンティティーでは、その測定値を、たとえば、断片基準値の順次的なリスト内の対応する断片基準値と比較することができ、その断片基準値から、ＴＲＶ基準値が、たとえばハッシュチェイニングなどの何らかの方法によって、それまでに計算されていた可能性がある。
Ｍｅｒｋｌｅハッシュツリーを介する検知を通じた多数の断片のケースにおいては、効率を高めることができる。これは、ツリーのレベルを下ることによって、インタラクティブな問合せ手続の形態で実行することができる。ここでは、ＴＲＶ内に含まれている基準値、およびコード／データから取られた測定値は両方とも、（グラフ理論的に）同じバイナリーツリーのルートを表すことができる。それらの値が一致しない場合には、デバイスは、２つの子ノード値をネットワークエンティティーへ送信することができ、ネットワークエンティティーは、どちらの子ノード値が不合格であるか、たとえば、ネットワークがＴＲＶ基準値をビルドするために使用した参照ツリー内の同じノード（それらのノードは、その参照ツリーのルートである可能性がある）と一致しないかを判定することができる。ネットワークは、どの（１つまたは複数の）分岐が不一致であるかを示すことができるメッセージをデバイスへ送信することができる。この手続は、測定ツリーのリーフを構成する測定値を有するコードの断片のうちで、参照（リーフ）値に対する不一致がある断片が判定されるまで、反復することができる。
再び図２３を参照すると、デバイス修復のために使用されるＴｒＥＣＢ２２２０の能力に基づいて、機能および手続を実行することができる。一実施形態においては、オペレーション中に１つまたは複数のＴＲＶ２３２６を更新すること、および次のスタートアップ時に実際のコード更新を実行することによって、計画されたコード更新を実行することができる。
下記の内容は、計画されたコード更新に関連することができる。デバイスが、本明細書に記載されているようにスタートアップを実行していると想定することができる。ＲＡＩＦ２３１６は、たとえばＣｏｍｍ ＩＦ２２１０および／またはＤＧＣ２３１４を介して、外部の当事者、たとえばＨ（ｅ）ＭＳから新たなＴＲＶを受信することができる。ＲＡＩＦ２３１６は、この新たに受信したＴＲＶをＴＲＶ＿ｔｍｐ ＮＶＳ２２１４内に格納することができる。その後に、デバイスは再始動することができる。ＩＶＣ２３１８は、本明細書に記載されているようにＳＥＥ２２０８内でインテグリティーチェックされて始動されることが可能である。ＩＶＣ２３１８は、ＴＲＶ＿ｔｍｐ ＮＶＳ２２１４をチェックして、ＴＲＶ＿ｔｍｐ ＮＶＳ２２１４が空ではないことを認識することができ、本明細書に記載されているように進むことができる。
ＴＲＶ＿ｔｍｐ２２１４は、単一の新たなＴＲＶを有することができる。第１の実施態様においては、ＴＲＶ＿ｔｍｐ内の新たなＴＲＶは、ＤＡＣＢ２２１６内のコードおよび／またはデータを参照することができる。第２の実施態様においては、ＴＲＶ＿ｔｍｐ内の新たなＴＲＶは、ＴｒＥＣＢ２２２０内のコードおよび／またはデータ、たとえば、ＤＧＣ２３１４、ＦＢ／ＤＣ２３２０、またはＲＣ２３２４のコード／データを参照することができる。
第１の実施態様においては、ＩＶＣ２３１８は、上述のようにＴＲＶの真正性を検証することができる。合格すると、ＩＶＣ２３１８は、新たなＴＲＶをＴＲＶ ＮＶＳ２２１８内に格納することができる。ＩＶＣ２３１８は、新たなＴＲＶによって取って代わられるべきものとみなすことができる、ＴＲＶ ＮＶＳ２２１８内の１つまたは複数の古いＴＲＶを削除することができる。これらの破棄されるＴＲＶがどのように判定されるかは、実施態様に応じて決めることができる。一意の識別子を、ＴＲＶ内のさらなるデータの一部として、ＴＲＶに割り当てることができる。このパラグラフに記載されているプロセスは、たとえばＴＲＶのインジェスチョン（ｉｎｇｅｓｔｉｏｎ）と呼ばれる場合がある。
ＩＶＣ２３１８は、ＴｒＥＣＢ ２２２０ ＮＶＳからＳＥＥ２２０８内へロードされたＤＧＣ２３１４コードを測定して、その測定値を、後者のＴＲＶ内に含まれている基準値と比較することができる。合格すると、ＤＧＣ２３１４をアクティブ化することができる。ＩＶＣ２３１８は、ＴＲＶ２３２６をＴＲＶ ＮＶＳからロードすることおよび／または検証することが可能であり、それらのＴＲＶ２３２６のそれぞれに関するコードおよびデータの指定された断片に関してＩＶを実行すること、たとえば、ＲＡＩＦ２３１６から開始して、ＤＡＣＢ２２１６のその他の部分へ進むことが可能である。ＩＶシーケンスにおいて、新たにインジェストされたＴＲＶに遭遇した場合には、ＤＡＣＢ２２１６のコードおよびデータの指定された部分の上で実行されたＩＶは、（たとえば、新たなＴＲＶが、破棄される（１つまたは複数の）ＴＲＶとは異なる基準値を有していると想定して）必然的に不合格になることができる。
ＩＶＣ２３１８は、ＲＣのコードに関する指定されたＴＲＶをＴＲＶ ＮＶＳ２２１８からロードすることができる。次いでＩＶＣ２３１８は、ＴｒＥＣＢ ２２２０ ＮＶＳからＳＥＥ２２０８内へロードされたＤＧＣ２３１４コードを測定して、その測定値を後者のＴＲＶ内の基準値と比較することができる。合格すると、ＲＣをアクティブ化することができる。
対応するネットワークエンティティー、たとえばＨ（ｅ）ＭＳに対する問合せ手続によって、ＲＣ２３２４は、新たにインジェストされたＴＲＶの基準値を再生するために、更新を必要としている可能性がある、たとえば、インテグリティー測定の不合格の一因となる可能性があるコードおよび／またはデータの断片を判定することができる。この問合せ手続は、たとえば本明細書に記載されているように実行することができる。
新たなＴＲＶとともに、デバイスは、コードおよび／またはデータのどの部分が置換を必要としている可能性があるかの詳細を受信していた可能性もある。これによって、ＲＣ２３２４とネットワークとの間における問合せ手続を回避することができる。問合せは、デバイスの通常のオペレーション中にダウンロードされるデバイスマネージメントおよび／または修復用のデータの量を最小限に抑えるように実行することができる。問合せは、デバイスが、その（１つの、新たな）ＴＲＶおよび／またはその指定されたコードの断片のいくつかの中間更新を「行っていない」という可能性を考慮するように実行することもできる。そのようなその後の更新が累積している場合には、それらの更新は、より多数のコード断片に影響を与える傾向を有する場合があり、それは、問合せ手続内で見つけることができる（しかし、デバイスによって行われなかった可能性がある、同じＴＲＶの更新のシーケンスの後の、最新のＴＲＶに限定された更新のために指定された断片のリスト内にあることを保証することはできない）。
ＲＣ２３２４は、対応するネットワークエンティティーから判定されたコードおよび／またはデータの判定された断片をダウンロードすることができる。一例によれば、ネットワークエンティティーは、ＴＲ−０６９の署名されたデータパッケージを集めること、および／またはそのデータパッケージをデバイスへ送信することが可能である。受信されたデータは、ＲＣ２３２４（または別法として、ＩＶＣ２３１８）によって、たとえば、新たにインジェストされたＴＲＶ内の署名証明書、（たとえば、ＩＶＣ２３１８によって）ＴＲＶ２３２６をチェックするために使用されるルート証明書、または（たとえば、ＲＣ２３２４コード／データベース内の）修復目的のための専用の証明書を使用してパッケージ署名を検証することによって、真正性に関してチェックすることができる。
コードおよび／またはデータのダウンロードされた断片の認証後に、ＲＣ２３２４は、それらの断片をＤＡＣＢ２２１６ ＮＶＳに、それまでに判定された断片のロケーションに書き込むことができる。ＤＧＣ２３１４は、実行をＩＶＣ２３１８へ返すことができ、ＩＶＣ２３１８は、ＴＲＶシーケンス内の同じＴＲＶ、たとえば、新たにインジェストされたＴＲＶにおいてＩＶを再開することができる。
上述の手続は、循環式になることができる。これは、少なくとも２つの理由のうちの１つから行うことができる。第１の理由としては、攻撃者が自分自身のコードを更新プロセス内に挿入した可能性があり、これは、ＴＲＶ基準値に合致しない可能性がある。さらなる理由としては、たとえばネットワーク側のコードビルドの機能不良に起因して、ＴＲＶ基準値および／またはダウンロードされたコードの不注意による不一致が存在する可能性がある。両方の実施態様においては、その状況を検知して、ネットワークに知らせることができる。これは、ＩＶＣ２３１８によってＴＲＶの使用に関するリピートカウンタを使用して達成することができる。高いセキュリティーのために、それらのカウンタは、ＴＲＶ ＮＶＳへの読み取りアクセスによってインクリメントされることが可能であるモノトニックハードウェアカウンタとすることができる。単一のＴＲＶ上でＩＶのあまりに多くの繰り返しが検知された場合には（それが何回かは、ポリシーに応じて決めることができる）、ＩＶＣ２３１８は、ＦＢ／ＤＣ２３２０をチェックしてアクティブ化すること、および／または、しかるべき信号をネットワークへ送信するために制御をその能力へ渡すことが可能である。
（ＴｒＥＣＢ２２２０内のコードおよび／またはデータを参照するＴＲＶ＿ｔｍｐ２２１４内の新たなＴＲＶに関する）上述の第２の実施態様に関連して、（ＤＡＣＢ２２１６内のコードおよび／またはデータを参照するＴＲＶ＿ｔｍｐ２２１４内の新たなＴＲＶに関する）第１の実施態様を使用することはできない。なぜなら、更新／修復は、更新／修復に関与しているアクティブなコンポーネント自体に関して要求することができるためである。そのようなケースにおいては、下記の手続の１つまたは複数のステップを適用することができる。ＩＶＣ２３１８は、新たなＴＲＶをインジェストすることができ、その一方で、対応する古いＴＲＶをＴＲＶ ＮＶＳ２２１８内に保持することができる。新たなＴＲＶは、それが新たなものであることを示す何らかのデータフラグ、たとえば「ＮＥＷ＿ＤＧＣ＿ＴＲＶ」という文字列でマークすることができる。ＩＶＣ２３１８は、古いＴＲＶを使用して、ＲＣ２３２４をチェックすることおよび／またはアクティブ化することが可能である。ＲＣ２３２４は、第１の実施態様において説明したのと同じ方法で使用することができるＴｒＥＣＢ２２２０部分の更新を実行することができるが、第２の実施態様においては、更新は、ＴｒＥＣＢ２２２０ ＮＶＳ内に書き込むことができる。ＩＶＣ２３１８は、新たなＴＲＶを使用して、ＴｒＥＣＢ２２２０の更新された部分をチェックすることができる。合格すると、古いＴＲＶをＴＲＶ ＮＶＳ２２１８から削除することができ、新たなＴＲＶに付けられているマークを外すことができる。これは、たとえばデバイスが次に再始動される後まで延期することができる。
ＲｏＴ２２１２がＩＶＣ２３１８コードをチェックする場合に、インテグリティーチェックの第１の不合格状況が生じることがある。このチェックが不合格である場合には、ＲｏＴ２２１２は、システムを停止することができ、さらに信号（たとえば、光信号）をユーザへ送信することができる。
一実施形態によれば、ＲｏＴ２２１２は、ＦＢ／ＤＣ２３２０の不変の部分（または可変の部分、そのインテグリティーは、ＩＣコードに関する類似した異形において記載されているような署名によって保護することができる）をチェックする能力、および／または障害／フォールバック手続のそのような限定された部分を呼び出す能力を有することができ、それは、この自律的にチェックされたコードを介して、たとえば、そのコードをＳＥＥ２２０８にロードして、そのコードをＳＥＥ２２０８において実行することによって、利用可能とすることができる。
不合格になる可能性がある次なるインテグリティーチェックは、ＤＧＣ２３１４および／またはＲＡＩＦ２３１６のインテグリティーチェックかもしれない。前者は、デバイスが、信頼できる通信能力を有していないことを意味することができる。このケースにおいては、ＩＶＣ２３１８は、ＦＢ／ＤＣ２３２０を検証してアクティブ化するよう試みることができる。ＦＢ／ＤＣ２３２０は、信頼できる通信をある程度まで回復できること、および障害信号をネットワークへ送信できることが可能である。そうでない場合には、ＦＢ／ＤＣ２３２０は、ユーザに知らせてシステムを停止することができる。上述の修復手続においてＲＣ２３２４のＩＶが不合格になった場合には、同じ手続を適用することができる。
上述の第２の実施態様において、ＲＡＩＦ２３１６のＩＶが不合格になった場合には、これは、デバイスが、ＴＲＶ更新を受信する能力を失っている可能性があることを意味することができる。次いでデバイスは、まず上述のような状況を修復するよう試みることができる。これが成功しない場合には、ＩＶＣ２３１８は、ＦＢ／ＤＣ２３２０を検証することおよび／またはアクティブ化することが可能であり、そしてＦＢ／ＤＣ２３２０は、特定のアクションを行うこと、たとえば、何らかのデフォルトコードによってＲＡＩＦ２３１６を置換することが可能である。
ＲＡＩＦ２３１６は、ＮＥＥ２２０６において露出されているコードの部分、および通常のコードベースの部分として、デバイス修復における最も弱いリンクであると言えるということを前述の説明から理解することができる。これは、デバイスインテグリティーに対する直接の脅威を提示するものではないかもしれないが、ＲＡＩＦ２３１６は、インテグリティーチェックに関与することができないため、更新／修復を無効にすること、したがってデバイスを非推奨の（たとえば、不合格の）状態に保持することによって、間接的な攻撃およびサービス妨害攻撃へと進む道を開く可能性がある。一実施形態によれば、ＲＡＩＦ２３１６によって具体化される機能は、ＴｒＥＣＢ２２２０の一部として提供されること、およびＳＥＥ２２０８において実行されることが可能である。これは、システムアーキテクチャー上の進化した構成を提示することができる。なぜなら、これは、ＳＥＥ２２０８の一部がアクティブであり、新たなＴＲＶを受信する用意ができているということを意味することができるためである。ＳＥＥのそのような永続的なアクティビティーは、たとえばＣｏｍｍ ＩＦ２２１０およびＤＧＣ２３１４において実現することができる。
上記では特徴および要素について特定の組合せで説明しているが、それぞれの特徴または要素は、単独で、または他の特徴および要素との任意の組合せで使用することができるということを当業者なら理解するであろう。加えて、本明細書に記載されている方法は、コンピュータまたはプロセッサによって実行するためにコンピュータ可読メディア内に組み込まれているコンピュータプログラム、ソフトウェア、またはファームウェアで実装することができる。コンピュータ可読メディアの例としては、（有線接続またはワイヤレス接続を介して伝送される）電子信号、およびコンピュータ可読ストレージメディアが含まれる。コンピュータ可読ストレージメディアの例としては、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび取り外し可能ディスクなどの磁気メディア、光磁気メディア、ならびにＣＤ−ＲＯＭディスクおよびＤＶＤ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ）などの光メディアが含まれるが、それらには限定されない。ソフトウェアと関連付けられているプロセッサは、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータにおいて使用するための無線周波数トランシーバを実装するために使用することができる。
Claims (19)
- ワイヤレス通信デバイスにより実行される方法であって、前記方法は、
ワイヤレス通信デバイスに関連付けられたコンポーネント上で第１のインテグリティーチェックを実行するステップと、
前記コンポーネントが前記第１のインテグリティーチェックに不合格になったと判定するステップと、
前記不合格になったコンポーネントに対応する機能を判定するステップと、
前記不合格になったコンポーネントに対応する前記機能の表示をネットワークエンティティーに送るステップと、
第２のインテグリティーチェックを前記不合格になったコンポーネント上で実行し、前記コンポーネントが前記第１のインテグリティーチェックに不合格になる原因となった前記不合格になったコンポーネントの部分を判定するための要求を前記ネットワークエンティティーから受信するステップと、
前記第２のインテグリティーチェックを前記不合格になったコンポーネント上で実行し、前記ネットワークエンティティーによる修復のために、前記不合格になったコンポーネントの前記部分を分離するステップと、
前記不合格になったコンポーネントの前記部分上での前記第２のインテグリティーチェックの１つまたは複数の繰り返しを実行するための要求を前記ネットワークエンティティーから受信するステップと、
前記不合格になったコンポーネントの前記部分上で前記第２のインテグリティーチェックの前記１つまたは複数の繰り返しを実行し、前記ネットワークエンティティーによる修復のために、前記不合格になったコンポーネントの前記部分をさらに分離するステップと
を備えたことを特徴とする方法。 - 前記コンポーネントが前記第１のインテグリティーチェックに不合格になる原因となった前記不合格になったコンポーネントの前記部分に対応する機能の表示を前記ネットワークエンティティーに送るステップと
をさらに備えたことを特徴とする請求項１に記載の方法。 - 前記不合格になったコンポーネントの前記部分を置換するための、前記ネットワークエンティティーを用いたリモート更新手続をトリガーするように構成されたアラームを前記表示は含むことを特徴とする請求項１に記載の方法。
- 前記不合格になったコンポーネントに対応する前記機能を、前記ワイヤレス通信デバイスにおいて格納されたコンポーネントから機能へのマップに基づいて判定するステップをさらに備えたことを特徴とする請求項１に記載の方法。
- 前記表示は、前記ネットワークエンティティーにセキュアに送られることを特徴とする請求項１に記載の方法。
- 前記コンポーネントが前記第１のインテグリティーチェックに不合格になったと判定するステップは、
前記コンポーネントに関連付けられたインテグリティー測定を判定するステップと、
前記インテグリティー測定を、前記コンポーネントに関連付けられた信頼済み基準値と比較するステップと、
前記インテグリティー測定が前記信頼済み基準値と一致しないと判定するステップと
をさらに備えたことを特徴とする請求項１に記載の方法。 - 前記不合格になったコンポーネントの前記部分に関連付けられた置換コンポーネントを受信するステップと、
前記不合格になったコンポーネントの前記部分を前記置換コンポーネントに置換するステップと
をさらに備えたことを特徴とする請求項１に記載の方法。 - 前記不合格になったコンポーネントの前記部分は、前記第１のインテグリティーチェックに合格し、前記ネットワークエンティティーに関連付けられた、他のコンポーネントを使用する前記置換コンポーネントに置換されることを特徴とする請求項７に記載の方法。
- 前記コンポーネントが前記第１のインテグリティーチェックに不合格になったと判定すると、前記ネットワークエンティティーへのアタッチメントのために使用されるキーのリリースを防止するステップをさらに備えたことを特徴とする請求項１に記載の方法。
- 前記不合格になったコンポーネントは、マルチステージセキュアブートプロセスの間に判定されることを特徴とする請求項１に記載の方法。
- 前記ネットワークエンティティーは、デバイス修復サーバを含み、および前記表示は、前記デバイス修復サーバに直接またはネットワークを介して送られることを特徴とする請求項１に記載の方法。
- 前記第１のインテグリティーチェックおよび前記第２のインテグリティーチェックは、信頼済み環境において実行されることを特徴とする請求項１に記載の方法。
- 前記機能は、前記第１のインテグリティーチェックの結果に基づいて適用されることになるネットワークポリシーに関連付けられることを特徴とする請求項１に記載の方法。
- 前記機能は、少なくとも１つの他のワイヤレス通信デバイス上の少なくとも１つの他のコンポーネントに関連付けられることによって、複数のワイヤレス通信デバイスにわたって標準化されることを特徴とする請求項１に記載の方法。
- 第１のインテグリティーチェックをワイヤレス通信デバイスに関連付けられたコンポーネント上で実行し、前記コンポーネントが前記第１のインテグリティーチェックに不合格になったと判定し、および第２のインテグリティーチェックを前記不合格になったコンポーネントの部分上で実行し、ネットワークエンティティーによる修復のために、前記不合格になったコンポーネントの部分を分離するように構成されたローダと、
前記不合格になったコンポーネントに対応するネットワーク機能を判定するように構成された、前記ワイヤレス通信デバイス上に存在しているポリシーマネージメントエンティティーと、
前記不合格になったコンポーネントの表示を前記ローダから受信し、前記不合格になったコンポーネントに対応する前記ネットワーク機能を受信し、前記不合格になったコンポーネントに対応する前記ネットワーク機能の表示をネットワークエンティティーに報告し、第２のインテグリティーチェックを前記不合格になったコンポーネント上で実行し前記コンポーネントが前記第１のインテグリティーチェックに不合格になる原因となった前記不合格になったコンポーネントの前記部分を判定するための要求を前記ネットワークエンティティーから受信し、前記不合格になったコンポーネントの前記部分上での前記第２のインテグリティーチェックの１つまたは複数の繰り返しを実行するための要求を前記ネットワークエンティティーから受信し、前記不合格になったコンポーネントの前記部分上で前記第２のインテグリティーチェックの前記１つまたは複数の繰り返しを実行し、前記ネットワークエンティティーによる修復のために、前記不合格になったコンポーネントの前記部分をさらに分離するように構成されたプラットフォームインテグリティーポリシーエンジン（ＰＩＰＥ）と
を備えたことを特徴とするシステム。 - 前記ローダは、
前記コンポーネントに関連付けられたインテグリティー測定を判定すること、
前記インテグリティー測定を、前記コンポーネントに関連付けられた信頼済み基準値と比較すること、および
前記インテグリティー測定が前記信頼済み基準値と一致しないと判定すること
を実行し、前記コンポーネントが前記第１のインテグリティーチェックに不合格になったと判定するようにさらに構成されることを特徴とする請求項１５に記載のシステム。 - 前記ＰＩＰＥは、前記不合格になったコンポーネントの前記表示を前記ローダから受信すると、前記システムの電源を切ること、前記不合格になったコンポーネントがロードされることを防止すること、前記ネットワークエンティティーを用いて前記ワイヤレス通信デバイスを認証するために使用される認証キーへのアクセスを防止すること、またはセキュアな機能へのアクセスを防止することのうちの１つまたは複数を実行するようにさらに構成されることを特徴とする請求項１５に記載のシステム。
- 前記ＰＩＰＥは、デバイスマネージメント機能を検証するようにさらに構成されており、前記デバイスマネージメント機能は、置換コンポーネントを前記ネットワークエンティティーから受信し、および前記不合格になったコンポーネントの前記部分を前記置換コンポーネントに置換するように構成されていることを特徴とする請求項１５に記載のシステム。
- 前記ＰＩＰＥは、ポリシーを外部エンティティーから受信し、および前記ネットワーク機能を前記ポリシーのうちの１つまたは複数にマップするようにさらに構成され、前記ポリシーは、前記第１のインテグリティーチェックの結果に基づいて適用されるように構成されることを特徴とする請求項１５に記載のシステム。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US41078110P | 2010-11-05 | 2010-11-05 | |
| US61/410,781 | 2010-11-05 | ||
| PCT/US2011/059274 WO2012061678A1 (en) | 2010-11-05 | 2011-11-04 | Device validation, distress indication, and remediation |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2015147227A Division JP2016006659A (ja) | 2010-11-05 | 2015-07-24 | デバイスの妥当性確認、障害指示、および修復 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2013545193A JP2013545193A (ja) | 2013-12-19 |
| JP5810168B2 true JP5810168B2 (ja) | 2015-11-11 |
Family
ID=45003068
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2013537850A Expired - Fee Related JP5810168B2 (ja) | 2010-11-05 | 2011-11-04 | デバイスの妥当性確認、障害指示、および修復 |
| JP2015147227A Pending JP2016006659A (ja) | 2010-11-05 | 2015-07-24 | デバイスの妥当性確認、障害指示、および修復 |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2015147227A Pending JP2016006659A (ja) | 2010-11-05 | 2015-07-24 | デバイスの妥当性確認、障害指示、および修復 |
Country Status (8)
| Country | Link |
|---|---|
| US (3) | US8914674B2 (ja) |
| EP (2) | EP2635991B1 (ja) |
| JP (2) | JP5810168B2 (ja) |
| KR (3) | KR101622447B1 (ja) |
| CN (2) | CN103202045B (ja) |
| AU (1) | AU2011323225B2 (ja) |
| TW (3) | TWI527474B (ja) |
| WO (1) | WO2012061678A1 (ja) |
Families Citing this family (80)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3346669A1 (en) | 2008-01-18 | 2018-07-11 | Interdigital Patent Holdings, Inc. | Method and apparatus for enabling machine to machine communication |
| SE533007C2 (sv) | 2008-10-24 | 2010-06-08 | Ilt Productions Ab | Distribuerad datalagring |
| RU2011140357A (ru) | 2009-03-05 | 2013-04-10 | Интердиджитал Пэйтент Холдингз, Инк. | Способ и устройство для проверки и подтверждения целостности h(e)nb |
| CN102342142A (zh) | 2009-03-06 | 2012-02-01 | 交互数字专利控股公司 | 无线设备的平台确认和管理 |
| KR101548041B1 (ko) * | 2009-04-15 | 2015-08-27 | 인터디지탈 패튼 홀딩스, 인크 | 네트워크와의 통신을 위한 장치의 검증 및/또는 인증 |
| EP2712149B1 (en) | 2010-04-23 | 2019-10-30 | Compuverde AB | Distributed data storage |
| US8914674B2 (en) | 2010-11-05 | 2014-12-16 | Interdigital Patent Holdings, Inc. | Device validation, distress indication, and remediation |
| US9553728B2 (en) * | 2011-02-25 | 2017-01-24 | Nokia Technologies Oy | Method and apparatus for providing end-to-end security for distributed computations |
| US8589996B2 (en) * | 2011-03-16 | 2013-11-19 | Azuki Systems, Inc. | Method and system for federated over-the-top content delivery |
| US8589735B2 (en) * | 2011-05-16 | 2013-11-19 | International Business Machines Corporation | Creating randomly ordered fields while maintaining the temporal ordering based on the value of the fields |
| US8645978B2 (en) | 2011-09-02 | 2014-02-04 | Compuverde Ab | Method for data maintenance |
| US9626378B2 (en) | 2011-09-02 | 2017-04-18 | Compuverde Ab | Method for handling requests in a storage system and a storage node for a storage system |
| US8769138B2 (en) | 2011-09-02 | 2014-07-01 | Compuverde Ab | Method for data retrieval from a distributed data storage system |
| WO2013037101A1 (en) * | 2011-09-13 | 2013-03-21 | Nokia Siemens Networks Oy | Authentication mechanism |
| KR101897605B1 (ko) * | 2012-02-24 | 2018-09-12 | 삼성전자 주식회사 | 휴대 단말기의 무결성 보호 방법 및 장치 |
| US8973138B2 (en) * | 2012-05-02 | 2015-03-03 | The Johns Hopkins University | Secure layered iterative gateway |
| US9007465B1 (en) * | 2012-08-31 | 2015-04-14 | Vce Company, Llc | Obtaining customer support for electronic system using first and second cameras |
| CN103049346B (zh) * | 2012-12-11 | 2015-03-18 | 工业和信息化部电子第五研究所 | 基于失效物理的元器件故障树构建方法和*** |
| JP6063317B2 (ja) * | 2013-03-26 | 2017-01-18 | 株式会社富士通エフサス | 端末装置および判定方法 |
| JP6054225B2 (ja) * | 2013-03-26 | 2016-12-27 | 株式会社富士通エフサス | 構成情報管理装置および構成情報管理方法 |
| US9792436B1 (en) * | 2013-04-29 | 2017-10-17 | Symantec Corporation | Techniques for remediating an infected file |
| JP2016523047A (ja) | 2013-05-06 | 2016-08-04 | コンヴィーダ ワイヤレス， エルエルシー | マシンツーマシンブートストラッピング |
| US20150019852A1 (en) * | 2013-07-12 | 2015-01-15 | International Games System Co., Ltd. | Verification method for system execution environment |
| US9686274B2 (en) * | 2013-10-11 | 2017-06-20 | Microsoft Technology Licensing, Llc | Informed implicit enrollment and identification |
| KR101468190B1 (ko) * | 2013-10-15 | 2014-12-05 | 순천향대학교 산학협력단 | Usim을 활용한 스마트워크 사용자 및 디바이스 인증 기법 |
| US9755831B2 (en) | 2014-01-22 | 2017-09-05 | Qualcomm Incorporated | Key extraction during secure boot |
| US9276803B2 (en) * | 2014-04-02 | 2016-03-01 | Ca, Inc. | Role based translation of data |
| KR101742666B1 (ko) * | 2014-05-29 | 2017-06-15 | 삼성에스디에스 주식회사 | 집적 회로 장치 및 상기 집적 회로 장치에서의 신호 처리 방법 |
| CN105302708A (zh) * | 2014-06-30 | 2016-02-03 | 联发科技（新加坡）私人有限公司 | 一种移动终端及其检测方法 |
| CN104503318B (zh) * | 2014-12-12 | 2017-03-22 | 清华大学 | 一种基于航天器无线网络的多线程控制方法 |
| FR3030831B1 (fr) * | 2014-12-23 | 2018-03-02 | Idemia France | Entite electronique securisee, appareil electronique et procede de verification de l’integrite de donnees memorisees dans une telle entite electronique securisee |
| US9830217B2 (en) * | 2015-01-29 | 2017-11-28 | Qualcomm Incorporated | Selective block-based integrity protection techniques |
| DE102015001801A1 (de) * | 2015-02-16 | 2016-08-18 | IAD Gesellschaft für Informatik, Automatisierung und Datenverarbeitung mbH | Autonom bootendes System mit einer Verschlüsselung des gesamten Datenspeichers und Verfahren hierfür |
| US20160246582A1 (en) * | 2015-02-25 | 2016-08-25 | Red Hat, Inc. | Generic Semantic Configuration Service |
| US10496974B2 (en) * | 2015-03-25 | 2019-12-03 | Intel Corporation | Secure transactions with connected peripherals |
| US9471285B1 (en) * | 2015-07-09 | 2016-10-18 | Synopsys, Inc. | Identifying software components in a software codebase |
| US10165457B2 (en) * | 2015-08-07 | 2018-12-25 | Telefonaktiebolaget Lm Ericsson (Publ) | System and method for root cause analysis of call failures in a communication network |
| US9860067B2 (en) * | 2015-10-29 | 2018-01-02 | At&T Intellectual Property I, L.P. | Cryptographically signing an access point device broadcast message |
| EP3384629B1 (en) * | 2015-12-02 | 2022-05-04 | PCMS Holdings, Inc. | System and method for tamper-resistant device usage metering |
| US10395200B2 (en) * | 2016-03-17 | 2019-08-27 | Ca, Inc. | Method and apparatus for repairing policies |
| CN107526647B (zh) * | 2016-06-21 | 2021-06-22 | 伊姆西Ip控股有限责任公司 | 一种故障处理方法、***和计算机程序产品 |
| DE102016009232A1 (de) * | 2016-07-28 | 2018-02-01 | Giesecke+Devrient Mobile Security Gmbh | Integriertes Teilnehmeridentitätsmodul mit Core-OS und Anwendungs-OS |
| US10496811B2 (en) | 2016-08-04 | 2019-12-03 | Data I/O Corporation | Counterfeit prevention |
| US10069633B2 (en) * | 2016-09-30 | 2018-09-04 | Data I/O Corporation | Unified programming environment for programmable devices |
| US10666443B2 (en) * | 2016-10-18 | 2020-05-26 | Red Hat, Inc. | Continued verification and monitoring of application code in containerized execution environment |
| WO2018194568A1 (en) | 2017-04-18 | 2018-10-25 | Hewlett-Packard Development Company, L.P. | Executing processes in sequence |
| CN115720358A (zh) * | 2017-05-05 | 2023-02-28 | 苹果公司 | 用于用户设备的方法、无线设备和计算机可读存储介质 |
| WO2018229657A1 (en) * | 2017-06-16 | 2018-12-20 | Telefonaktiebolaget Lm Ericsson (Publ) | Apparatuses and methods for handling of data radio bearer integrity protection failure in new radio (nr) network |
| US10462161B2 (en) * | 2017-06-21 | 2019-10-29 | GM Global Technology Operations LLC | Vehicle network operating protocol and method |
| US10938855B1 (en) * | 2017-06-23 | 2021-03-02 | Digi International Inc. | Systems and methods for automatically and securely provisioning remote computer network infrastructure |
| US10409685B2 (en) * | 2017-07-24 | 2019-09-10 | Uber Technologies, Inc. | Recovery of application functions via analysis of application operational requests |
| US10291498B1 (en) * | 2017-11-14 | 2019-05-14 | Sprint Communications Company L.P. | Mobile communication device diagnostic client and error remediation sharing |
| FR3074324B1 (fr) * | 2017-11-28 | 2020-01-17 | Schneider Electric Industries Sas | Procede d'inscription securisee d'un appareil electrique amovible lors de son installation au sein d'un systeme electrique |
| US10521662B2 (en) | 2018-01-12 | 2019-12-31 | Microsoft Technology Licensing, Llc | Unguided passive biometric enrollment |
| JP6706278B2 (ja) * | 2018-03-27 | 2020-06-03 | キヤノン株式会社 | 情報処理装置、及び情報処理方法 |
| US11860758B2 (en) * | 2018-05-07 | 2024-01-02 | Google Llc | System for adjusting application performance based on platform level benchmarking |
| EP3599567A1 (de) * | 2018-07-25 | 2020-01-29 | Siemens Aktiengesellschaft | Vorrichtung und verfahren für eine integritätsüberprüfung einer oder mehrerer gerätekomponenten |
| JP7084826B2 (ja) * | 2018-08-28 | 2022-06-15 | キヤノン株式会社 | 情報処理装置、その制御方法、およびそのプログラム |
| WO2020069168A1 (en) * | 2018-09-27 | 2020-04-02 | Landis+Gyr Innovations, Inc. | Validation and installation of a file system into a transient, non-persistent storage circuit |
| KR102665749B1 (ko) * | 2018-10-09 | 2024-05-16 | 구글 엘엘씨 | 클라우드 저하 모드에서 지속적인 디바이스 동작 안정성을 보장하기 위한 방법 및 장치 |
| US11056192B2 (en) * | 2018-12-21 | 2021-07-06 | Micron Technology, Inc. | Monotonic counters in memories |
| US20200220865A1 (en) * | 2019-01-04 | 2020-07-09 | T-Mobile Usa, Inc. | Holistic module authentication with a device |
| CN110032446B (zh) * | 2019-03-27 | 2021-05-04 | 中国科学院微电子研究所 | 一种应用于嵌入式***中分配内存空间的方法及装置 |
| US11386233B2 (en) | 2019-04-30 | 2022-07-12 | JFrog, Ltd. | Data bundle generation and deployment |
| US11886390B2 (en) | 2019-04-30 | 2024-01-30 | JFrog Ltd. | Data file partition and replication |
| US11106554B2 (en) | 2019-04-30 | 2021-08-31 | JFrog, Ltd. | Active-active environment control |
| US11340894B2 (en) | 2019-04-30 | 2022-05-24 | JFrog, Ltd. | Data file partition and replication |
| US11068333B2 (en) | 2019-06-24 | 2021-07-20 | Bank Of America Corporation | Defect analysis and remediation tool |
| US11461163B1 (en) * | 2019-06-28 | 2022-10-04 | Amazon Technologies, Inc. | Remote device error correction |
| US10972289B2 (en) | 2019-07-19 | 2021-04-06 | JFrog, Ltd. | Software release verification |
| RU2722239C1 (ru) * | 2019-11-26 | 2020-05-28 | Общество с ограниченной ответственностью «ПИРФ» (ООО «ПИРФ») | Способ создания и использования формата исполняемого файла с динамическим расширяемым заголовком |
| US11695829B2 (en) | 2020-01-09 | 2023-07-04 | JFrog Ltd. | Peer-to-peer (P2P) downloading |
| US11513817B2 (en) * | 2020-03-04 | 2022-11-29 | Kyndryl, Inc. | Preventing disruption within information technology environments |
| US11593209B2 (en) | 2020-04-01 | 2023-02-28 | Microsoft Technology Licensing, Llc | Targeted repair of hardware components in a computing device |
| US11907052B2 (en) * | 2020-04-20 | 2024-02-20 | Dell Products L.P. | Systems and methods for encrypting unique failure codes to aid in preventing fraudulent exchanges of information handling system components |
| US11470677B2 (en) * | 2020-08-27 | 2022-10-11 | Dish Network L.L.C. | Systems and methods for a computer network intermediate router |
| US11860680B2 (en) | 2020-11-24 | 2024-01-02 | JFrog Ltd. | Software pipeline and release validation |
| KR102432284B1 (ko) * | 2021-07-28 | 2022-08-12 | 인프라닉스 아메리카 코퍼레이션 | It관리대상의 이벤트 알람이나 장애 문제를 실시간 자동으로 조치하는 시스템 및 그 운용방법 |
| US11765604B2 (en) | 2021-12-16 | 2023-09-19 | T-Mobile Usa, Inc. | Providing configuration updates to wireless telecommunication networks |
| TWI823535B (zh) * | 2022-08-26 | 2023-11-21 | 新唐科技股份有限公司 | 空中下載裝置及空中下載方法 |
Family Cites Families (70)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8347086B2 (en) * | 2000-12-18 | 2013-01-01 | Citibank, N.A. | System and method for automatically detecting and then self-repairing corrupt, modified of non-existent files via a communication medium |
| US6731932B1 (en) | 1999-08-24 | 2004-05-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Methods and systems for handling subscriber data |
| US6779120B1 (en) | 2000-01-07 | 2004-08-17 | Securify, Inc. | Declarative language for specifying a security policy |
| US7076797B2 (en) | 2001-10-05 | 2006-07-11 | Microsoft Corporation | Granular authorization for network user sessions |
| FI114276B (fi) | 2002-01-11 | 2004-09-15 | Nokia Corp | Verkkovierailun järjestäminen |
| US6993760B2 (en) | 2001-12-05 | 2006-01-31 | Microsoft Corporation | Installing software on a mobile computing device using the rollback and security features of a configuration manager |
| US7240830B2 (en) | 2002-02-15 | 2007-07-10 | Telefonaktiebolaget Lm Ericsson (Publ) | Layered SIM card and security function |
| GB0211644D0 (en) | 2002-05-21 | 2002-07-03 | Wesby Philip B | System and method for remote asset management |
| DE10223248A1 (de) | 2002-05-22 | 2003-12-04 | Siemens Ag | Verfahren zum Registrieren eines Kommunikationsendgeräts |
| FI117586B (fi) | 2002-08-02 | 2006-11-30 | Nokia Corp | Menetelmä SIM-toiminteen järjestämiseksi digitaaliseen langattomaan päätelaitteeseen sekä vastaava päätelaite ja palvelin |
| DE60221911T2 (de) | 2002-08-22 | 2008-04-30 | Ntt Docomo Inc. | Rekonfiguration einer gruppe von netzknoten in einem ad-hoc netzwerk |
| JP2006513609A (ja) | 2002-12-31 | 2006-04-20 | モトローラ・インコーポレイテッド | 通信デバイスに対する分散認証及び無線経由プロビジョニングを行うシステム及び方法 |
| US7634807B2 (en) | 2003-08-08 | 2009-12-15 | Nokia Corporation | System and method to establish and maintain conditional trust by stating signal of distrust |
| DE60306931T2 (de) | 2003-09-16 | 2007-03-01 | Research In Motion Ltd., Waterloo | Aktualisierungsbereitsstellung auf Bedarfsbasis für eine mobile Kommunikationsvorrichtung |
| EP1533695B1 (en) | 2003-11-19 | 2013-08-07 | TELEFONAKTIEBOLAGET LM ERICSSON (publ) | Updating data in a mobile terminal |
| KR100554172B1 (ko) | 2003-11-27 | 2006-02-22 | 한국전자통신연구원 | 네트워크 보안성을 강화한 무결성 관리 시스템, 이를구비한 무결성 네트워크 시스템 및 그 방법 |
| US20050138355A1 (en) | 2003-12-19 | 2005-06-23 | Lidong Chen | System, method and devices for authentication in a wireless local area network (WLAN) |
| US7350072B2 (en) | 2004-03-30 | 2008-03-25 | Intel Corporation | Remote management and provisioning of a system across a network based connection |
| JP4144880B2 (ja) | 2004-04-09 | 2008-09-03 | インターナショナル・ビジネス・マシーンズ・コーポレーション | プラットフォーム構成測定装置、プログラム及び方法、プラットフォーム構成認証装置、プログラム及び方法、プラットフォーム構成証明装置、プログラム及び方法、並びに、プラットフォーム構成開示装置、プログラム及び方法 |
| WO2005125261A1 (en) | 2004-06-17 | 2005-12-29 | Telefonaktiebolaget Lm Ericsson (Publ) | Security in a mobile communications system |
| US7747862B2 (en) | 2004-06-28 | 2010-06-29 | Intel Corporation | Method and apparatus to authenticate base and subscriber stations and secure sessions for broadband wireless networks |
| JP4585002B2 (ja) * | 2004-08-20 | 2010-11-24 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | 高速ネットワーク接続機構 |
| US20060074600A1 (en) | 2004-09-15 | 2006-04-06 | Sastry Manoj R | Method for providing integrity measurements with their respective time stamps |
| US7653819B2 (en) | 2004-10-01 | 2010-01-26 | Lenovo Singapore Pte Ltd. | Scalable paging of platform configuration registers |
| US8266676B2 (en) | 2004-11-29 | 2012-09-11 | Harris Corporation | Method to verify the integrity of components on a trusted platform using integrity database services |
| US7818585B2 (en) | 2004-12-22 | 2010-10-19 | Sap Aktiengesellschaft | Secure license management |
| US7725703B2 (en) | 2005-01-07 | 2010-05-25 | Microsoft Corporation | Systems and methods for securely booting a computer with a trusted processing module |
| JP4293155B2 (ja) | 2005-03-31 | 2009-07-08 | サクサ株式会社 | コードレス電話機 |
| US7907531B2 (en) | 2005-06-13 | 2011-03-15 | Qualcomm Incorporated | Apparatus and methods for managing firmware verification on a wireless device |
| US7908483B2 (en) | 2005-06-30 | 2011-03-15 | Intel Corporation | Method and apparatus for binding TPM keys to execution entities |
| US7707480B2 (en) * | 2005-07-01 | 2010-04-27 | Qnx Software Systems Gmbh & Co. Kg | System employing data verification operations of differing computational costs |
| US7809777B2 (en) | 2005-07-01 | 2010-10-05 | Qnx Software Systems Gmbh & Co. Kg | File system having deferred verification of data integrity |
| US20070050678A1 (en) * | 2005-08-25 | 2007-03-01 | Motorola, Inc. | Apparatus for self-diagnosis and treatment of critical software flaws |
| JP4093494B2 (ja) | 2005-09-08 | 2008-06-04 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 秘密情報へのアクセスを制御するシステムおよびその方法 |
| CN1933651B (zh) | 2005-09-12 | 2010-05-12 | 北京三星通信技术研究有限公司 | Lte***中的会话接入方法 |
| JP4708143B2 (ja) | 2005-09-30 | 2011-06-22 | シスメックス株式会社 | 自動顕微鏡及びこれを備える分析装置 |
| GB0520254D0 (en) | 2005-10-05 | 2005-11-16 | Vodafone Plc | Telecommunications networks |
| US7580701B2 (en) | 2005-12-27 | 2009-08-25 | Intel Corporation | Dynamic passing of wireless configuration parameters |
| US8413209B2 (en) | 2006-03-27 | 2013-04-02 | Telecom Italia S.P.A. | System for enforcing security policies on mobile communications devices |
| US20070239748A1 (en) | 2006-03-29 | 2007-10-11 | Smith Ned M | Management of reference data for platform verification |
| US7930733B1 (en) | 2006-04-10 | 2011-04-19 | At&T Intellectual Property Ii, L.P. | Method and system for execution monitor-based trusted computing |
| US8108668B2 (en) | 2006-06-26 | 2012-01-31 | Intel Corporation | Associating a multi-context trusted platform module with distributed platforms |
| KR101055712B1 (ko) | 2006-06-30 | 2011-08-11 | 인터내셔널 비지네스 머신즈 코포레이션 | 모바일 장치에서의 메시지 핸들링 |
| US20080076425A1 (en) | 2006-09-22 | 2008-03-27 | Amit Khetawat | Method and apparatus for resource management |
| US7617423B2 (en) * | 2006-08-14 | 2009-11-10 | Kyocera Corporation | System and method for detecting, reporting, and repairing of software defects for a wireless device |
| US7711960B2 (en) | 2006-08-29 | 2010-05-04 | Intel Corporation | Mechanisms to control access to cryptographic keys and to attest to the approved configurations of computer platforms |
| US20080076419A1 (en) | 2006-09-22 | 2008-03-27 | Amit Khetawat | Method and apparatus for discovery |
| US20080101400A1 (en) * | 2006-10-30 | 2008-05-01 | Nokia Corporation | Managing attachment of a wireless terminal to local area networks |
| US7683630B2 (en) * | 2006-11-30 | 2010-03-23 | Electro Scientific Industries, Inc. | Self test, monitoring, and diagnostics in grouped circuitry modules |
| KR101368327B1 (ko) | 2006-12-22 | 2014-02-26 | 삼성전자주식회사 | 프로그램 실행흐름 보고 시스템 및 방법 |
| TWI493952B (zh) | 2006-12-27 | 2015-07-21 | Signal Trust For Wireless Innovation | 基地台自行配置方法及裝置 |
| CN101675678A (zh) | 2007-03-12 | 2010-03-17 | 诺基亚公司 | 用于提供辅助切换命令的设备、方法和计算机程序产品 |
| DE602007013701D1 (de) | 2007-04-17 | 2011-05-19 | Alcatel Lucent | Verfahren zur Verkoppelung eines Femto-Zellengeräts mit einem mobilen Kernnetzwerk |
| US8064597B2 (en) | 2007-04-20 | 2011-11-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and system for mobile device credentialing |
| CN100583768C (zh) | 2007-04-27 | 2010-01-20 | 中国科学院软件研究所 | 基于安全需求的远程证明方法及其*** |
| US8528058B2 (en) | 2007-05-31 | 2013-09-03 | Microsoft Corporation | Native use of web service protocols and claims in server authentication |
| WO2008156782A2 (en) * | 2007-06-19 | 2008-12-24 | Sand Holdings, Llc | Devices and methods for automatic reset of monitored network network equipment |
| KR101392697B1 (ko) * | 2007-08-10 | 2014-05-19 | 엘지전자 주식회사 | 이동통신 시스템에서의 보안 오류 검출방법 및 장치 |
| US7853804B2 (en) | 2007-09-10 | 2010-12-14 | Lenovo (Singapore) Pte. Ltd. | System and method for secure data disposal |
| US8200736B2 (en) | 2007-12-24 | 2012-06-12 | Qualcomm Incorporated | Virtual SIM card for mobile handsets |
| EP3346669A1 (en) | 2008-01-18 | 2018-07-11 | Interdigital Patent Holdings, Inc. | Method and apparatus for enabling machine to machine communication |
| US8300829B2 (en) | 2008-06-23 | 2012-10-30 | Nokia Corporation | Verification key handling |
| RU2011140357A (ru) | 2009-03-05 | 2013-04-10 | Интердиджитал Пэйтент Холдингз, Инк. | Способ и устройство для проверки и подтверждения целостности h(e)nb |
| CN102342142A (zh) | 2009-03-06 | 2012-02-01 | 交互数字专利控股公司 | 无线设备的平台确认和管理 |
| CN101651949B (zh) * | 2009-08-17 | 2011-10-26 | 中兴通讯股份有限公司 | 一种安全模式建立的方法及无线网络控制器 |
| EP2288195B1 (en) * | 2009-08-20 | 2019-10-23 | Samsung Electronics Co., Ltd. | Method and apparatus for operating a base station in a wireless communication system |
| CN101820619B (zh) * | 2010-01-15 | 2012-10-24 | 北京工业大学 | 无线传感器网络中高效节能的链路安全方法 |
| CN101771704B (zh) * | 2010-01-22 | 2016-03-30 | 中兴通讯股份有限公司 | 一种安全的数据传输的方法和*** |
| CN105468982A (zh) * | 2010-04-12 | 2016-04-06 | 交互数字专利控股公司 | 无线网络设备及将其完整性确认绑定至其它功能的方法 |
| US8914674B2 (en) | 2010-11-05 | 2014-12-16 | Interdigital Patent Holdings, Inc. | Device validation, distress indication, and remediation |
-
2011
- 2011-11-04 US US13/289,154 patent/US8914674B2/en not_active Expired - Fee Related
- 2011-11-04 KR KR1020137014322A patent/KR101622447B1/ko not_active IP Right Cessation
- 2011-11-04 EP EP11785854.8A patent/EP2635991B1/en not_active Not-in-force
- 2011-11-04 AU AU2011323225A patent/AU2011323225B2/en not_active Ceased
- 2011-11-04 EP EP15185046.8A patent/EP3002697A1/en not_active Withdrawn
- 2011-11-04 JP JP2013537850A patent/JP5810168B2/ja not_active Expired - Fee Related
- 2011-11-04 KR KR1020177002832A patent/KR20170016034A/ko not_active Application Discontinuation
- 2011-11-04 CN CN201180053416.4A patent/CN103202045B/zh not_active Expired - Fee Related
- 2011-11-04 KR KR1020147014163A patent/KR101703925B1/ko active IP Right Grant
- 2011-11-04 CN CN201610349706.8A patent/CN106055930A/zh active Pending
- 2011-11-04 WO PCT/US2011/059274 patent/WO2012061678A1/en active Application Filing
- 2011-11-07 TW TW100140585A patent/TWI527474B/zh not_active IP Right Cessation
- 2011-11-07 TW TW106108409A patent/TW201735675A/zh unknown
- 2011-11-07 TW TW104137770A patent/TWI596959B/zh not_active IP Right Cessation
-
2014
- 2014-12-15 US US14/570,301 patent/US9652320B2/en not_active Expired - Fee Related
-
2015
- 2015-07-24 JP JP2015147227A patent/JP2016006659A/ja active Pending
-
2017
- 2017-03-28 US US15/471,591 patent/US20170199777A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| AU2011323225B2 (en) | 2015-05-28 |
| EP2635991A1 (en) | 2013-09-11 |
| TW201735675A (zh) | 2017-10-01 |
| US8914674B2 (en) | 2014-12-16 |
| CN103202045B (zh) | 2016-06-01 |
| CN103202045A (zh) | 2013-07-10 |
| KR20140079865A (ko) | 2014-06-27 |
| KR101622447B1 (ko) | 2016-05-31 |
| KR101703925B1 (ko) | 2017-02-07 |
| TWI527474B (zh) | 2016-03-21 |
| TW201234877A (en) | 2012-08-16 |
| KR20170016034A (ko) | 2017-02-10 |
| TW201620318A (zh) | 2016-06-01 |
| AU2011323225A1 (en) | 2013-05-30 |
| KR20130084688A (ko) | 2013-07-25 |
| TWI596959B (zh) | 2017-08-21 |
| JP2016006659A (ja) | 2016-01-14 |
| EP2635991B1 (en) | 2015-09-16 |
| US20170199777A1 (en) | 2017-07-13 |
| US9652320B2 (en) | 2017-05-16 |
| US20150099510A1 (en) | 2015-04-09 |
| US20120290870A1 (en) | 2012-11-15 |
| JP2013545193A (ja) | 2013-12-19 |
| CN106055930A (zh) | 2016-10-26 |
| EP3002697A1 (en) | 2016-04-06 |
| WO2012061678A1 (en) | 2012-05-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5810168B2 (ja) | デバイスの妥当性確認、障害指示、および修復 | |
| US20170364685A1 (en) | Providing security to computing systems | |
| JP6231054B2 (ja) | 無線装置のプラットフォームの検証と管理 | |
| KR101760451B1 (ko) | Ｈ(ｅ)ＮＢ 무결성 검증 및 확인을 위한 방법 및 장치 | |
| El Jaouhari et al. | Secure firmware Over-The-Air updates for IoT: Survey, challenges, and discussions | |
| US20150261966A1 (en) | Secure factory data generation and restoration | |
| WO2021087221A1 (en) | Secure and flexible boot firmware update for devices with a primary platform | |
| AU2015221575A1 (en) | Device validation, distress indication, and remediation | |
| Pearson et al. | Secure Deployment of Containerized IoT Systems | |
| Schmidt et al. | Evolution of Trust Systems from PCs to Mobile Devices |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20140430 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20140610 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20140910 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20140918 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20141010 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20150324 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20150724 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20150803 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20150818 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20150914 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 5810168 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |