図1A〜図24Bは、開示されているシステム、方法、および手段を実施することができる例示的な実施形態に関する。本明細書に記載されている実施形態は、例示的であること、および限定的でないことが意図されている。本明細書においては、プロトコルフローについて例示および説明する場合があるが、それらのフローの順序を変更することができ、一部を省略することができ、および/またはさらなるフローを追加することができる。
図1A、図1B、および図1Cは、本明細書に記載されている実施形態において使用することができる例示的な通信システムおよびデバイスを示している。図1Aは、1つまたは複数の開示されている実施形態を実施することができる例示的な通信システム100の図である。通信システム100は、コンテンツ、たとえば音声、データ、ビデオ、メッセージング、放送などを複数のワイヤレスユーザに提供するマルチプルアクセスシステムとすることができる。通信システム100は、複数のワイヤレスユーザが、ワイヤレス帯域幅を含むシステムリソースの共有を通じてそのようなコンテンツにアクセスすることを可能にすることができる。たとえば、通信システム100は、1つまたは複数のチャネルアクセス方法、たとえばCDMA(code division multiple access)、TDMA(time division multiple access)、FDMA(frequency division multiple access)、OFDMA(orthogonal FDMA)、SC−FDMA(single−carrier FDMA)などを採用することができる。
図1Aにおいて示されているように、通信システム100は、WTRU(wireless transmit/receive unit)102a、102b、102c、102d、RAN(radio access network)104、コアネットワーク106、PSTN(public switched telephone network)108、インターネット110、およびその他のネットワーク112を含むことができるが、開示されている実施形態では、任意の数のWTRU、基地局、ネットワーク、および/またはネットワーク要素が考えられるということがわかるであろう。WTRU102a、102b、102c、102dのそれぞれは、ワイヤレス環境において動作および/または通信を行うように構成されている任意のタイプのデバイスとすることができる。例として、WTRU102a、102b、102c、102dは、ワイヤレス信号を送信および/または受信するように構成することができ、UE(user equipment)、移動局、固定式または移動式のサブスクライバーユニット、ページャー、セルラー電話、PDA(personal digital assistant)、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサ、家庭用電化製品などを含むことができる。
通信システム100は、基地局114aおよび基地局114bを含むこともできる。基地局114a、114bのそれぞれは、コアネットワーク106、インターネット110、および/またはネットワーク112などの1つまたは複数の通信ネットワークへのアクセスを容易にするために、WTRU102a、102b、102c、102dのうちの少なくとも1つとワイヤレスにインターフェースを取るように構成されている任意のタイプのデバイスとすることができる。例として、基地局114a、114bは、BTS(base transceiver station)、Node−B、eNode B、Home Node B、Home eNode B、サイトコントローラ、AP(access point)、ワイヤレスルータなどとすることができる。基地局114a、114bは、それぞれ単一の要素として示されているが、基地局114a、114bは、任意の数の相互接続された基地局および/またはネットワーク要素を含むことができるということがわかるであろう。
基地局114aは、RAN104の一部とすることができ、RAN104は、その他の基地局および/またはネットワーク要素(図示せず)、たとえばBSC(base station controller)、RNC(radio network controller)、中継ノードなどを含むこともできる。基地局114aおよび/または基地局114bは、特定の地理的領域内でワイヤレス信号を送信および/または受信するように構成することができ、この地理的領域は、セル(図示せず)と呼ばれることもある。セルは、複数のセルセクタへとさらに分割することができる。たとえば、基地局114aに関連付けられているセルは、3つのセクタへと分割することができる。したがって一実施形態においては、基地局114aは、3つのトランシーバ、すなわち、セルのそれぞれのセクタごとに1つのトランシーバを含むことができる。別の実施形態においては、基地局114aは、MIMO(multiple−input multiple output)テクノロジーを採用することができ、したがって、セルのそれぞれのセクタごとに複数のトランシーバを利用することができる。
基地局114a、114bは、エアインターフェース116を介してWTRU102a、102b、102c、102dのうちの1つまたは複数と通信することができ、エアインターフェース116は、任意の適切なワイヤレス通信リンク(たとえば、RF(radio frequency)、マイクロ波、IR(infrared)、UV(ultraviolet)、可視光など)とすることができる。エアインターフェース116は、任意の適切なRAT(radio access technology)を使用して確立することができる。
より具体的には、上述したように、通信システム100は、マルチプルアクセスシステムとすることができ、1つまたは複数のチャネルアクセススキーム、たとえばCDMA、TDMA、FDMA、OFDMA、SC−FDMAなどを採用することができる。たとえば、RAN104内の基地局114aおよびWTRU102a、102b、102cは、UTRA(UMTS(Universal Mobile Telecommunications System)Terrestrial Radio Access)などの無線テクノロジーを実施することができ、この無線テクノロジーは、WCDMA(登録商標)(wideband CDMA)を使用してエアインターフェース116を確立することができる。WCDMAは、HSPA(High−Speed Packet Access)および/またはHSPA+(Evolved HSPA)などの通信プロトコルを含むことができる。HSPAは、HSDPA(High−Speed Downlink Packet Access)および/またはHSUPA(High−Speed Uplink Packet Access)を含むことができる。
別の実施形態においては、基地局114aおよびWTRU102a、102b、102cは、E−UTRA(Evolved UMTS Terrestrial Radio Access)などの無線テクノロジーを実施することができ、この無線テクノロジーは、LTE(Long Term Evolution)および/またはLTE−A(LTE−Advanced)を使用してエアインターフェース116を確立することができる。
その他の実施形態においては、基地局114aおよびWTRU102a、102b、102cは、無線テクノロジー、たとえばIEEE 802.16(すなわちWiMAX(Worldwide Interoperability for Microwave Access))、CDMA2000、CDMA2000 1X、CDMA2000 EV−DO、IS−2000(Interim Standard 2000)、IS−95(Interim Standard 95)、IS−856(Interim Standard 856)、GSM(登録商標)(Global System for Mobile communications)、EDGE(Enhanced Data rates for GSM Evolution)、GERAN(GSM EDGE)などを実施することができる。
図1Aにおける基地局114bは、たとえばワイヤレスルータ、Home Node B、Home eNode B、またはアクセスポイントとすることができ、局所的なエリア、たとえば事業所、家庭、乗り物、キャンパスなどにおけるワイヤレス接続を容易にするために、任意の適切なRATを利用することができる。一実施形態においては、基地局114bおよびWTRU102c、102dは、WLAN(wireless local area network)を確立するために、IEEE 802.11などの無線テクノロジーを実施することができる。別の実施形態においては、基地局114bおよびWTRU102c、102dは、WPAN(wireless personal area network)を確立するために、IEEE 802.15などの無線テクノロジーを実施することができる。さらに別の実施形態においては、基地局114bおよびWTRU102c、102dは、ピコセルまたはフェムトセルを確立するために、セルラーベースのRAT(たとえば、WCDMA、CDMA2000、GSM、LTE、LTE−Aなど)を利用することができる。図1Aにおいて示されているように、基地局114bは、インターネット110への直接接続を有することができる。したがって、基地局114bは、コアネットワーク106を介してインターネット110にアクセスすることを不要とすることができる。
RAN104は、コアネットワーク106と通信状態にあることが可能であり、コアネットワーク106は、音声、データ、アプリケーション、および/またはVoIP(voice over internet protocol)サービスをWTRU102a、102b、102c、102dのうちの1つまたは複数に提供するように構成されている任意のタイプのネットワークとすることができる。たとえば、コアネットワーク106は、コール制御、課金サービス、モバイルロケーションベースサービス、プリペイドコーリング、インターネット接続、ビデオ配信などを提供すること、および/またはユーザ認証などのハイレベルセキュリティー機能を実行することが可能である。図1Aにおいては示されていないが、RAN104および/またはコアネットワーク106は、RAN104と同じRATまたは異なるRATを採用しているその他のRANと直接または間接の通信状態にあることが可能であるということがわかるであろう。たとえば、コアネットワーク106は、E−UTRA無線テクノロジーを利用している可能性があるRAN104に接続されていることに加えて、GSM無線テクノロジーを採用している別のRAN(図示せず)と通信状態にあることも可能である。
コアネットワーク106は、WTRU102a、102b、102c、102dがPSTN108、インターネット110、および/またはその他のネットワーク112にアクセスするためのゲートウェイとして機能することもできる。PSTN108は、POTS(plain old telephone service)を提供する回路交換電話ネットワークを含むことができる。インターネット110は、TCP/IPインターネットプロトコルスイートにおけるTCP(transmission control protocol)、UDP(user datagram protocol)、およびIP(internet protocol)など、共通の通信プロトコルを使用する相互接続されたコンピュータネットワークおよびデバイスからなるグローバルシステムを含むことができる。ネットワーク112は、その他のサービスプロバイダによって所有および/または運営されている有線またはワイヤレスの通信ネットワークを含むことができる。たとえば、ネットワーク112は、RAN104と同じRATまたは異なるRATを採用している可能性がある1つまたは複数のRANに接続されている別のコアネットワークを含むことができる。
通信システム100内のWTRU102a、102b、102c、102dのうちのいくつかまたはすべては、マルチモード機能を含むことができ、すなわち、WTRU102a、102b、102c、102dは、別々のワイヤレスリンクを介して別々のワイヤレスネットワークと通信するために複数のトランシーバを含むことができる。たとえば、図1Aにおいて示されているWTRU102cは、セルラーベースの無線テクノロジーを採用している可能性がある基地局114a、およびIEEE 802無線テクノロジーを採用している可能性がある基地局114bと通信するように構成することができる。
図1Bは、例示的なWTRU102のシステム図である。図1Bにおいて示されているように、WTRU102は、プロセッサ118、トランシーバ120、送信/受信要素122、スピーカー/マイクロフォン124、キーパッド126、ディスプレイ/タッチパッド128、取り外し不能メモリ130、取り外し可能メモリ132、電源134、GPS(global positioning system)チップセット136、およびその他の周辺機器138を含むことができる。WTRU102は、一実施形態との整合性を保持しながら、上述の要素どうしの任意の下位組合せを含むことができるということがわかるであろう。
プロセッサ118は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、DSP(digital signal processor)、複数のマイクロプロセッサ、DSPコアと関連付けられている1つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、ASIC(Application Specific Integrated Circuit)、FPGA(Field Programmable Gate Array)回路、その他の任意のタイプのIC(integrated circuit)、状態マシンなどとすることができる。プロセッサ118は、信号コーディング、データ処理、電力制御、入力/出力処理、および/またはWTRU102をワイヤレス環境内で機能できるようにするその他の任意の機能を実行することができる。プロセッサ118は、トランシーバ120に結合することができ、トランシーバ120は、送信/受信要素122に結合することができる。図1Bは、プロセッサ118とトランシーバ120を別々のコンポーネントとして示しているが、プロセッサ118とトランシーバ120は、1つの電子パッケージまたはチップ内に統合することができるということがわかるであろう。
送信/受信要素122は、エアインターフェース116を介して、基地局(たとえば、基地局114a)に信号を送信するように、または基地局(たとえば、基地局114a)から信号を受信するように構成することができる。たとえば、一実施形態においては、送信/受信要素122は、RF信号を送信および/または受信するように構成されているアンテナとすることができる。別の実施形態においては、送信/受信要素122は、たとえば、IR信号、UV信号、または可視光信号を送信および/または受信するように構成されているエミッタ/検知器とすることができる。さらに別の実施形態においては、送信/受信要素122は、RF信号と光信号との両方を送信および受信するように構成することができる。送信/受信要素122は、ワイヤレス信号の任意の組合せを送信および/または受信するように構成することができるということがわかるであろう。
加えて、送信/受信要素122は、図1Bにおいては単一の要素として示されているが、WTRU102は、任意の数の送信/受信要素122を含むことができる。より具体的には、WTRU102は、MIMOテクノロジーを採用することができる。したがって、一実施形態においては、WTRU102は、エアインターフェース116を介してワイヤレス信号を送信および受信するために、複数の送信/受信要素122(たとえば、複数のアンテナ)を含むことができる。
トランシーバ120は、送信/受信要素122によって送信される信号を変調するように、また、送信/受信要素122によって受信される信号を復調するように構成することができる。上述したように、WTRU102は、マルチモード機能を有することができる。したがってトランシーバ120は、WTRU102が、たとえばUTRAおよびIEEE 802.11など、複数のRATを介して通信できるようにするために複数のトランシーバを含むことができる。
WTRU102のプロセッサ118は、スピーカー/マイクロフォン124、キーパッド126、および/またはディスプレイ/タッチパッド128(たとえば、LCD(liquid crystal display)ディスプレイユニットまたはOLED(organic light−emitting diode)ディスプレイユニット)に結合することができ、そこからユーザ入力データを受け取ることができる。プロセッサ118は、ユーザデータをスピーカー/マイクロフォン124、キーパッド126、および/またはディスプレイ/タッチパッド128へ出力することもできる。加えて、プロセッサ118は、取り外し不能メモリ130および/または取り外し可能メモリ132など、任意のタイプの適切なメモリからの情報にアクセスすること、およびそれらのメモリにデータを格納することが可能である。取り外し不能メモリ130は、RAM(random−access memory)、ROM(read−only memory)、ハードディスク、またはその他の任意のタイプのメモリストレージデバイスを含むことができる。取り外し可能メモリ132は、SIM(subscriber identity module)カード、メモリスティック、SD(secure digital)メモリカードなどを含むことができる。その他の実施形態においては、プロセッサ118は、サーバまたはホームコンピュータ(図示せず)上など、WTRU102上に物理的に配置されていないメモリからの情報にアクセスすること、およびそれらのメモリにデータを格納することが可能である。
プロセッサ118は、電源134から電力を受け取ることができ、また、WTRU102内のその他のコンポーネントへの電力を分配および/または制御するように構成することができる。電源134は、WTRU102に電力供給するための任意の適切なデバイスとすることができる。たとえば、電源134は、1つまたは複数の乾電池(たとえばNiCd(nickel−cadmium)、NiZn(nickel−zinc)、NiMH(nickel metal hydride)、Li−ion(lithium−ion)など)、太陽電池、燃料電池などを含むことができる。
プロセッサ118は、GPSチップセット136に結合することもでき、GPSチップセット136は、WTRU102の現在位置に関する位置情報(たとえば、経度および緯度)を提供するように構成することができる。GPSチップセット136からの情報に加えて、またはその情報の代わりに、WTRU102は、基地局(たとえば、基地局114a、114b)からエアインターフェース116を介して位置情報を受信すること、および/または複数の近隣の基地局から受信されている信号のタイミングに基づいて自分の位置を特定することが可能である。WTRU102は、一実施形態との整合性を保持しながら、任意の適切な位置特定方法を通じて位置情報を得ることができるということがわかるであろう。
プロセッサ118は、その他の周辺機器138にさらに結合することができ、その他の周辺機器138は、さらなる特徴、機能、および/または有線接続もしくはワイヤレス接続を提供する1つまたは複数のソフトウェアモジュールおよび/またはハードウェアモジュールを含むことができる。たとえば、周辺機器138は、加速度計、e−コンパス、衛星トランシーバ、デジタルカメラ(写真またはビデオ用)、USB(universal serial bus)ポート、振動デバイス、テレビジョントランシーバ、ハンドフリーヘッドセット、Bluetooth(登録商標)モジュール、FM(frequency modulated)ラジオユニット、デジタルミュージックプレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含むことができる。
図1Cは、一実施形態によるRAN104およびコアネットワーク106のシステム図である。上述したように、RAN104は、エアインターフェース116を介してWTRU102a、102b、102cと通信するためにE−UTRA無線テクノロジーを採用することができる。RAN104は、コアネットワーク106と通信状態にあることも可能である。
RAN104は、eNode−B140a、140b、140cを含むことができるが、RAN104は、一実施形態との整合性を保持しながら、任意の数のeNode−Bを含むことができるということがわかるであろう。eNode−B140a、140b、140cはそれぞれ、エアインターフェース116を介してWTRU102a、102b、102cと通信するために1つまたは複数のトランシーバを含むことができる。一実施形態においては、eNode−B140a、140b、140cは、MIMOテクノロジーを実施することができる。したがって、eNode−B140aは、たとえば、WTRU102aにワイヤレス信号を送信するために、およびWTRU102aからワイヤレス信号を受信するために、複数のアンテナを使用することができる。
eNode−B140a、140b、140cのそれぞれは、特定のセル(図示せず)に関連付けることができ、無線リソース管理の決定、ハンドオーバの決定、アップリンクおよび/またはダウンリンクにおけるユーザのスケジューリングなどを取り扱うように構成することができる。図1Cにおいて示されているように、eNode−B140a、140b、140cは、X2インターフェースを介して互いに通信することができる。
図1Cにおいて示されているコアネットワーク106は、MME(mobility management gateway)142、サービングゲートウェイ144、およびPDN(packet data network)ゲートウェイ146を含むことができる。上述の要素のそれぞれは、コアネットワーク106の一部として示されているが、これらの要素のいずれかが、コアネットワークオペレータ以外のエンティティーによって所有および/または運営されることも可能であるということがわかるであろう。
MME142は、S1インターフェースを介してRAN104内のeNode−B142a、142b、142cのそれぞれに接続することができ、制御ノードとして機能することができる。たとえば、MME142は、WTRU102a、102b、102cのユーザを認証すること、ベアラのアクティブ化/非アクティブ化、WTRU102a、102b、102cの最初の接続中に特定のサービングゲートウェイを選択することなどを担当することができる。MME142は、RAN104と、GSMまたはWCDMAなどのその他の無線テクノロジーを採用しているその他のRAN(図示せず)との間における切り替えを行うための制御プレーン機能を提供することもできる。
サービングゲートウェイ144は、S1インターフェースを介してRAN104内のeNode B140a、140b、140cのそれぞれに接続することができる。サービングゲートウェイ144は一般に、ユーザデータパケットをWTRU102a、102b、102cへ/WTRU102a、102b、102cから回送および転送することができる。サービングゲートウェイ144は、その他の機能、たとえば、eNode B間のハンドオーバ中にユーザプレーンを固定すること、WTRU102a、102b、102cにとってダウンリンクデータが利用可能である場合にページングをトリガーすること、WTRU102a、102b、102cのコンテキストを管理および記憶することなどを実行することもできる。
サービングゲートウェイ144は、PDNゲートウェイ146に接続することもでき、PDNゲートウェイ146は、WTRU102a、102b、102cと、IP対応デバイスとの間における通信を容易にするために、インターネット110などのパケット交換ネットワークへのアクセスをWTRU102a、102b、102cに提供することができる。
コアネットワーク106は、その他のネットワークとの通信を容易にすることができる。たとえば、コアネットワーク106は、WTRU102a、102b、102cと、従来の地上通信線の通信デバイスとの間における通信を容易にするために、PSTN108などの回路交換ネットワークへのアクセスをWTRU102a、102b、102cに提供することができる。たとえば、コアネットワーク106は、コアネットワーク106と、PSTN108との間におけるインターフェースとして機能するIPゲートウェイ(たとえば、IMS(IP multimedia subsystem)サーバ)を含むことができ、またはそうしたIPゲートウェイと通信することができる。加えて、コアネットワーク106は、ネットワーク112へのアクセスをWTRU102a、102b、102cに提供することができ、ネットワーク112は、その他のサービスプロバイダによって所有および/または運営されているその他の有線またはワイヤレスのネットワークを含むことができる。
本明細書に記載されている通信システムおよびデバイスは、通信デバイスのソフトウェアを管理するために、通信デバイスの構成を管理するために、ならびに/または、デバイスを元の状態に戻すためのソフトウェアおよび/もしくは構成の情報の修復を提供するために使用することができる。ソフトウェアツール、ネットワークプロトコル、デバイスポリシーおよびソフトウェア管理、ならびに/またはリモートデバッギングの技術の使用を通じた信頼済みコードベースのソフトウェアの側面の参照の自動的な生成および管理を通じた証明可能な報告および修復のためのメカニズムおよび参照をデバイス内に組み込むことができるソフトウェア開発およびコードリリースツールを使用するための実施態様も、本明細書に記載されている。障害を報告するためにデバイスを信頼することができる旨の指示の記述を含む、デバイスによるインテグリティーチェックの障害の指示を保証することができる技術が、本明細書にさらに記載されている。
本明細書に記載されているように、ワイヤレス通信デバイスは、マルチステージセキュアブートプロセス(multi−stage secure boot process)のそれぞれのステージにおいてインテグリティーチェックを実行するように構成することができる。マルチステージセキュアブートプロセス中に、それぞれのステージは、次のステージを検証することができ、それによって、信頼の連鎖が生じる。マルチステージセキュアブートプロセスのそれぞれのステージ中に、そのステージに関連付けられているコンポーネントを信頼することができるかどうかの判定を行うことができる。コンポーネントに関連付けられているインテグリティー測定値を測定することができる。コンポーネントは、関連付けられている信頼済み基準値を有することができる。コンポーネントの信頼性は、インテグリティー測定値を、信頼済み基準値と比較することによって、判定すること(たとえば、テストすること)ができる。インテグリティー測定値が、信頼済み基準値と一致する場合には、コンポーネントは、信頼できるとみなすことができる。インテグリティー測定値が、信頼済み基準値と一致しない場合には、コンポーネントは、信頼できない可能性がある。インテグリティー測定値を、信頼済み基準値と比較することによって、インテグリティーチェックを実行することができるということが、本明細書に記載されているが、インテグリティーチェックは、コンポーネントの信頼性を判定するためのその他の方法で実行することもできるということがわかるであろう。
コンポーネントは外部エンティティーによって認識することができないため、機能は、たとえば標準仕様に準拠するように、および/または実施態様独自の様式で、複数のネットワークおよび/またはデバイスにわたって定義および/または標準化することができる。コンポーネントは、機能に関連することができる。コンポーネントと機能との間における関係は、コンポーネントから機能へのマップにおいて提供することができる。機能障害は、障害の生じているコンポーネントを、コンポーネントから機能へのマップと比較することによって、識別することができる。
デバイスは、機能障害に関連付けられているアラームを外部エンティティーへ送信することができる。外部エンティティーは、障害の生じているコンポーネントを修正するかまたは置換するために使用することができる、機能に関連付けられている置換コードを特定することができる。すなわち、置換コードは、置換コンポーネントとすることができる。デバイスは、置換コンポーネントを受け取って、障害の生じているコンポーネントを置換コンポーネントと置換することができる。
セキュアブートプロセスは、妥当性確認手続のための基礎を提供することができる。不変のハードウェアRoT(root of trust)によって開始される信頼の連鎖は、ロードされた最初のコードの妥当性を検証することができる。ブートプロセスは、たとえば図2において示されているように、それぞれのステージが信頼の連鎖を通じて次のステージを検証するにつれて、継続することができる。
電源投入およびハードウェア初期化手続に続いて、デバイスは、たとえば図2において示されているように、セキュアブートプロセスを開始することができる。最初のRoTは、ブートローダ202によって表すことができ、ブートローダ202は、ROM内のセキュアなメモリ内に存在することができる。ROMブートローダ202は、はじめにいくつかの初期化機能を実行することができる。ROMブートローダ202は、(たとえば、外部メモリ内に存在する)第2ステージブートローダ204のインテグリティーを検証するために使用することができるセキュリティー証明書(たとえば、融合されたキー作成情報(fused keying information))にアクセスすることができる。第2ステージローダ204は、自分のインテグリティーを確実にするために、ハードウェアまたはソフトウェアの暗号手段によるチェックを受けることができる。第2ステージローダ204の計算されたハッシュ測定値は、TRV(trusted reference value)測定値と比較することができ、TRV測定値は、セキュリティー証明書によって署名すること、および外部メモリ内に格納することが可能である。計算された測定値が、署名されたTRVと一致する場合には、第2ステージローダ204を検証して、内部メモリ(たとえば、RAM)内にロードすることができる。ブートROMは、第2ステージローダ204のスタートにジャンプすることができ、信頼の連鎖は、継続することができる。検証プロセスの最初のステージにおける障害は、後続の検証が危うくされる可能性があることを示す場合がある(たとえば、最初のステージにおける障害は、信頼の連鎖における致命的な機能停止を示す場合がある)。検証プロセスの最初のステージにおいて示されている障害がある場合には、デバイスをシャットダウンすることができる。
第2ステージブートローダ204は、TrE(trusted execution environment)コードを、さらなるコードをチェックして内部メモリにロードすることができるコードとともに含むことができる。TrEは、さらなるインテグリティー基準値を計算して格納することができる信頼済み環境およびセキュアな格納エリアを確立することができる。TrEインテグリティーは、オペレーティングシステムおよび通信のコードをチェックすること、ロードすること、および/または始動することができる。信頼の連鎖は、それぞれのステージがチェックされてロードされるにつれて継続することができる(たとえば、図2において示されているボックス202、204、206、および208はそれぞれ、ステージを表すことができる)。たとえば、第2ステージローダ204は、OS/通信206および/またはデバイスソフトウェア208のインテグリティーを検証することができる。代替として、または追加として、OS/通信206が、デバイスソフトウェア208のインテグリティーを検証することもできる。OS/通信206は、OSローダを含むことができる。一実施形態によれば、図2において示されているエンティティーは、信頼の連鎖を保持するために、実行の順に検証されること、および/または互いを検証することが可能である。
信頼の連鎖は、後続のプロセスをセキュアに検証する能力を有する実行プロセスによって保持することができる。検証プロセスは、暗号計算および/または信頼済み基準値の両方を使用することができる。セキュアでないメモリ内に存在するコードは、攻撃に対して弱くなる場合があり、ロードする前に検証することができる。第2ステージブートローダ204は、きめ細かい妥当性確認を伴わずに、残りのコードをバルク測定として検証することができる。測定された値が、モノリシックなブロックに関するTRVと一致しない場合には、そのコードを信頼することはできず、そのコードをロードすることはできないと判定することができる。そのデバイスは、通信を行うことができない場合があり、その結果としては、高価なトラックロールまたは修正のためにデバイスを返送することを介したコードベース全体の修復が含まれる場合がある。
本明細書に記載されている方法、システム、および手段は、格納されているコードのより小さなコンポーネントの妥当性を確認すること、ならびに、どのコンポーネントに障害が生じているか、およびどれがリモートから修復可能かまたは修復可能でないかの詳細な説明を提供することをデバイスが行えるようにすることができる。このきめ細かい情報は、修復マネージャーにとって利用可能にすることができる。
障害の生じているどのコンポーネントをリモート修復可能とすることができるかを判定するポリシーを確立することができる。たとえば、デバイスがTrEをチェックして通信コードの最小セットとともにロードした場合には、そのデバイスは、特定の障害の生じているコンポーネントの情報を識別して修復マネージャーに報告するために修復マネージャーのためのプロキシとして動作する機能を保持することができる。修復能力が存在し、デバイスのプロキシ機能の一部である場合には、後続のリモート修復手続を開始することができ、それによって、高価なオンサイトの個人的な更新の使用を減らすことができる。
一実施形態によれば、きめ細かい報告を可能にするために、実行可能イメージを分割して、その妥当性を確認することができる。実行可能イメージの生成は、複数のステージで行うことができる。コンポーネントは、サブルーチンおよび/またはパラメータ/データから構成されているファイルを参照することができる。開発者は、コンポーネントソースファイルおよびヘッダファイル内に取り込まれたプログラムを書くことができる。これらのコンポーネントソースファイルから、コンパイラおよびアセンブラは、マシンバイナリーコードおよびプログラムデータの両方を含むオブジェクトファイル(たとえば、*.o)を生成することができる。リンカーは、これらのオブジェクトファイルを入力として受け取り、実行可能イメージまたはオブジェクトファイルを生成することができ、このオブジェクトファイルは、その他のオブジェクトファイルとさらにリンクするために使用することができる。リンカーコマンドファイルは、オブジェクトファイルどうしをどのようにして結合するか、ならびにバイナリーコードおよびデータをターゲット組み込みシステム内のどこに配置するかをリンカーに指示することができる。
リンカーの機能は、複数のオブジェクトファイルを結合して、より大きな再配置可能なオブジェクトファイル、共有オブジェクトファイル、または最終的な実行可能イメージにすることであると言える。グローバル変数および静的でない機能は、グローバルシンボルと呼ばれる場合がある。最終的な実行可能バイナリーイメージにおいては、シンボルは、メモリ内のアドレスロケーションを参照することができる。このメモリロケーションの内容は、変数のためのデータまたは機能のための実行可能コードとすることができる。
コンパイラは、自分が生成するオブジェクトファイルの一部としてアドレスマッピングに対するシンボル名を有するシンボルテーブルを作成することができる。再配置可能な出力を生成する際に、コンパイラは、それぞれのシンボルごとに、コンパイルされているファイルに関連するアドレスを生成することができる。リンカーによって実行されるリンキングプロセスは、シンボルレゾリューションおよび/またはシンボルリロケーションを含むことができる。シンボルレゾリューションとは、リンカーがそれぞれのオブジェクトファイルを通って、そのオブジェクトファイルに関して、どの(他の)1つまたは複数のオブジェクトファイルの中で外部シンボルが定義されているかを判定するプロセスであると言える。シンボルリロケーションとは、リンカーがシンボル参照をその定義にマップするプロセスであると言える。リンカーは、リンクされているオブジェクトファイルのマシンコードを、シンボルへのコード参照が、それらのシンボルに割り当てられている実際のアドレスを反映するように、修正することができる。
オブジェクトおよび実行可能ファイルは、たとえばELF(Executable and Linking Format)およびCOFF(Common Object−File Format)など、いくつかのフォーマットが可能である。オブジェクトファイルは、複数のエリアまたはセクションへと分割することができる。これらのセクションは、たとえば、実行可能コード、データ、動的リンキング情報、デバッギングデータ、シンボルテーブル、リロケーション情報、コメント、文字列テーブル、または注のうちの1つまたは複数を保持することができる。これらのセクションを使用して、バイナリーファイルに命令を提供し、検査を可能にすることができる。機能セクションは、システム機能のアドレスを格納することができるGOT(Global Offset Table)、GOTへの間接的なリンクを格納することができるPLT(Procedure Linking Table)、内部の初期化のために使用することができる.init/fini、ならびにコンストラクタおよびデストラクタのために使用することができる.shutdown、または.ctors/.dtorsのうちの1つまたは複数を含むことができる。データセクションは、読み取り専用データのための.rodata、初期化されたデータのための.data、または初期化されていないデータのための.bssのうちの1つまたは複数を含むことができる。ELFセクションは、スタートアップのための.init、文字列のための.text、シャットダウンのための.fini、読み取り専用データのための.rodata、初期化されたデータのための.data、初期化されたスレッドデータのための.tdata、初期化されていないスレッドデータのための.tbss、コンストラクタのための.ctors、デストラクタのための.dtors、グローバルオフセットテーブルのための.got、または初期化されていないデータのための.bssのうちの1つまたは複数を含むことができる。
いくつかのセクションは、プロセスイメージへとロードすることができる。いくつかのセクションは、プロセスイメージをビルドする際に使用することができる情報を提供することができる。いくつかのセクションは、オブジェクトファイルどうしをリンクする際の使用に限定することができる。いくつかのオブジェクトファイルは、その他のオブジェクトファイル内に配置されているシンボルへの参照を含むことができる。リンカーは、それぞれのオブジェクトファイルごとにテキストおよびデータのセグメント内のシンボル名およびそれらの対応するオフセットのリストを含むことができるシンボルテーブルを作成することができる。オブジェクトファイルどうしをリンクした後に、リンカーは、満たされていない可能性があるレゾルブされていないシンボルアドレスを見つけ出すためにリロケーションレコードを使用することができる。複数のソースファイル(たとえば、C/C++ファイルおよびアセンブリファイル)がELFオブジェクトファイルへとコンパイルおよびアセンブルされた後に、リンカーは、たとえば、図3において示されているように、これらのオブジェクトファイルを結合し、別々のオブジェクトファイルからのセクションどうしをマージしてプログラムセグメントにすることができる。
図3において示されているように、オブジェクトファイル302、304、および306のテキストセクション308、316、および324をそれぞれマージして、実行可能イメージ338のテキストセグメント332にすることができる。追加として、または代替として、スタートアップセクション310、318、および326をマージして、実行可能イメージ338のテキストセグメント332にすることができる。同様に、オブジェクトファイル302、304、および306のデータセクション312、320、および328をそれぞれマージして、実行可能イメージ338のデータセグメント334にすることができる。最後に、オブジェクトファイル302、304、および306の初期化されていないデータセクション314、322、および330をそれぞれマージして、実行可能イメージ338の初期化されていないデータセグメント336にすることができる。図3は、マージして実行可能イメージ338内のセグメントにすることができるオブジェクトファイル302、304、および306のある数のセクションを示しているが、任意の数および/または組合せのセクションをマージして実行可能イメージのセグメントにすることができるということを理解されたい。
図3において示されているように、セグメントは、関連したセクションどうしをグループ化する方法を提供することができる。それぞれのセグメントは、同じまたは異なるタイプの1つまたは複数のセクション(たとえば、テキストセクション、データセクション、または動的なセクション)を含むことができる。オペレーティングシステムは、プログラムヘッダテーブルにおいて提供される情報に従ってファイルのセグメントを論理的にコピーすることができる。実行可能データセクションおよび読み取り専用データセクションを結合して、単一のテキストセグメントにすることができる。データセクションおよび初期化されていないデータセクションを結合して、データセグメントに、またはそれら自体の個々のセグメントにすることができる。これらのセグメントは、プロセスの作成時にメモリ内にロードすることができるため、ロードセグメントと呼ばれる場合がある。シンボル情報セクションおよびデバッギングセクションなどのその他のセクションどうしをマージして、その他の非ロードセグメントにすることができる。テキストセクションは、初期化された静的変数とともにソースコードを含むことができる。コンパイラによって定義された複数のセクションを、リンカーによって定義された単一の結合されたセグメントへとロードすることができる。
最終的な実行可能イメージは、リンカーがセクションどうしをどのように結合するか、および/またはセグメントをターゲットシステムメモリマップへどのように割り当てるかを制御するためのリンカーコマンド(リンカーディレクティブと呼ばれる場合もある)を使用して生成することができる。リンカーディレクティブは、リンカーコマンドファイル内に保持することができる。組み込み開発者は、リンカーコマンドファイルを使用して、実行可能イメージをターゲットシステムへとマップすることができる。
障害の生じているコンポーネントの妥当性確認およびきめ細かい報告を実行する能力は、実行可能イメージ内で利用可能なさらなる情報を使用することができ、開発およびコードリリースツールチェーン(development and code release tool chains)に対する修正が存在することが可能である。それぞれのコンポーネントごとの基準測定値、ならびにその測定値がどのコンポーネントに関連付けられているかを識別する情報要素は、実行可能イメージ内で識別可能とすることができる。
障害の生じているコンポーネントの修復は、標準的機能障害を報告するデバイスの能力に依存することができる。機能、ならびに障害に基づいて取るべきアクションは、ネットワークオペレータによって定義することができる。ソフトウェア開発者は、オペレータによって定義された機能を自分のシステム内のソフトウェアコンポーネントにどのようにマップすることができるかを判定することができる。機能マッピングは、実行可能イメージ内で可視とすることができ、ツールチェーンの機能強化を使用することができる。
開発フェーズ中に使用されるソフトウェアツールチェーンは、コンポーネントセクションの生成、TRVのセキュアな生成および組み込み、コンポーネントから機能への定義の挿入、またはポリシーおよびポリシー構成ファイルの挿入のうちの1つまたは複数に対応するように修正することができる。
ローダ機能は、妥当性確認および/または修復に対応するように修正することができる。ローダは、コンポーネントがロードされる際にそれらのコンポーネントのインテグリティーチェックを実行すること、障害の生じているコンポーネントを隔離もしくはアンロードすること、ポリシーを管理すること、またはポリシーマネージャーが障害を報告するために、障害の生じているコンポーネントのIDをメモリ内に格納することのうちの1つまたは複数を行うように修正することができる。
所望の機能を例示するために本明細書に記載されているソフトウェア開発およびコードリリースツールチェーンに適用することができる例示的な実施形態が、本明細書に記載されている。しかし、それらの実施形態は、本明細書において提供されている例に限定されるものではない。
リンカーの役割は、入力オブジェクトを受け取り、さまざまなセクションを結合してセグメントにすることであると言える。オブジェクトコードはリンキングプロセス中に結合することができるため、オブジェクトファイル内の機能または変数を識別する能力は、シンボルテーブル情報内に保持することができる。結果として得られるマージされたコードセクションは、本明細書に記載されているような妥当性確認手続をトリガーするために使用することができる妥当性確認スキームを提供することができない。
個々のコンポーネントの識別を容易にするために、ローダは、どこでコードが始まったかを識別するための方法を有することができ、これは、コンポーネントを定義すること、またはローダによって識別することができる個々のコンポーネントに関するTRVを生成することを含むことができる。実行可能イメージを生成するために使用されるツールチェーンは、たとえば、特定のコンポーネントを識別してインテグリティーチェックを実行するためのローダ妥当性確認機能のための特定のオブジェクトファイルコンポーネントに関連付けられているコードを識別できるように機能強化することができる。コードイメージを再構成することによって、入力オブジェクトに関するTRVを変更することができる(たとえば、1つの入力オブジェクトを修正することによって、結果として、その他の入力オブジェクトに関するTRVを変更することができる)。TRVの変更を除外するための最適化方法を使用することから、このツールチェーンを除外することができる。
インテグリティーチェックにとって望ましい可能性があるコンポーネントのために特定のセクション名を生成することができる。そのセクション名は、たとえば最終的なELF実行可能ファイル内に含まれているセクションヘッダテーブル内に現れることができる。ユーザ定義セクションをグループ化することによって、ローダは、コンポーネントを識別し、インテグリティーチェックを実行することができる。ローダは、コンポーネントの合格または不合格のステータスをポリシーマネージャーに報告することができる。インテグリティーチェックに合格/不合格になっている特定の機能を分離することは、ポリシーマネージャーが、障害の生じているコンポーネントによって影響を受ける可能性がある機能をきめ細かいまたは詳細なレベルで報告することを可能にすることができる。
図4は、単一の実行可能イメージ406を形成するためにリンクすることができる2つのオブジェクトファイル402および404を示している。オブジェクトファイル402は、2つの別個のコードセグメント、コンポーネントファイルセクション408、およびテキストセクション410を有する。オブジェクトファイル404は、単一のコードセグメント、コンポーネントファイルセクション416を有し、コンポーネントファイルセクション416は、コードおよび/または定数データを含むことができる。ユーザ定義コードセクション、コンポーネントファイルセクション408、およびコンポーネントファイルセクション416は、自分がマップされるセグメントのタイプに関連するサイズおよび/またはメモリロケーションとともにセクションヘッダ内に表れることができる。そのようなマッピング関係の一例が、図4において矢印によって示されている。たとえば、オブジェクトファイル402のコンポーネントファイルセクション408、テキストセクション410、データセクション412、およびbssセクション414はそれぞれ、実行可能イメージ406のコンポーネントファイルセクション420、テキストセクション424、データセクション426、およびbssセクション428にマップすることができる。同様に、オブジェクトファイル404のコンポーネントファイルセクション416およびbssセクション418はそれぞれ、実行可能イメージ406のコンポーネントファイルセクション422およびbssセクション428にマップすることができる。実行可能イメージ406は、ユーザ定義セクションを、事前に定義されたロケーションの実行可能イメージ406の始まりに含むようにリンクすることができ、したがって、それらのセクションを順次チェックすることができる。妥当性確認によるインテグリティーに関するチェックは、コードベースのサブセットに限定することができる。より大きなテキストセグメントへとグループ化される残りのコードは、インテグリティーチェックされないことが可能であり、および/またはロードされることが可能である。
ユーザ定義セクションの追加は、たとえば、#PRAGMAをコンポーネントコード内に挿入することによって、識別可能にすることができる。図4の例をさらに参照すると、命令#PRAGMAセクション(たとえば、コンポーネントファイルセクション408)をソースファイルの最上部に挿入することができる。コンパイラフラグによってユーザ定義セクションを含むようにコンパイラを機能強化することができる。特定のフラグが設定された場合にPRAGMAを自動的に挿入するようにコンパイラを機能強化することができる。ユーザ定義セクションが、コンポーネント内のインテグリティーチェック可能な機能に制限されるように、ユーザ定義セクションのコンセプトを拡張することができる。デバイスの信頼済み実行のために使用することができる機能は、スタートアッププロセスの最初または早期にインテグリティーチェックすることができるコンポーネントへと分割または分離することができる。
セクションは、リンカーコマンドファイルを介してメモリの特定のセグメントにマップすることができる。ELFオブジェクトは、ソースアドレスおよびデスティネーションアドレスの点から見ることができる。セクションヘッダテーブルにおいて識別されるセクションは、移動するコードおよび/またはデータの始まりがどこで見つかるかをローダに知らせることができる。セグメントヘッダにおいて識別されるセグメントは、コンポーネントをコピーする場所をローダに知らせることができる。セクションヘッダおよびプログラムヘッダのフォーマットが、下に示されている。
セクションヘッダ プログラムヘッダ
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;
sh_addrは、ターゲットメモリ内でプログラムセクションが存在することができるアドレスであると言える。p_paddrは、ターゲットメモリ内でプログラムセグメントが存在することができるアドレスであると言える。sh_addrフィールドおよびp_paddrフィールドは、ロードアドレスを参照することができる。ローダは、セクションヘッダからのロードアドレスフィールドを、不揮発性メモリからRAMへのイメージ転送のための開始アドレスとして使用することができる。
コンポーネントセクション識別のコンセプトを、1つのファイル内に含まれている複数の特定のコンポーネントへ拡張することが可能である場合がある。そのような拡張は、1つの完全なファイルよりも、インテグリティーに関してチェックされることになる特定のサブルーチンの識別を通じたポリシーマネージャーによるアクセス制御のさらなるきめ細かさを可能にすることができる。
TRVは、特定のコンポーネントまたはオブジェクトファイルの予測された測定値(たとえば、セキュアな方法で計算されたコンポーネントのハッシュ)であると言える。妥当性確認プロセスは、たとえば、実行可能イメージ内に存在することをチェックされることになる、またはインテグリティー検証の目的からセキュアな方法で別途ロードされることになるそれぞれのコンポーネントごとのTRVに依存することができる。これは、多くの方法で達成することができる。例として、実行可能イメージをビルドするツールチェーンを修正して、コンポーネントまたはオブジェクトファイルのハッシュ値をセキュアに計算すること、および計算されたTRVを同じオブジェクトファイルの適切なセクション内にセキュアに挿入することが可能である。この計算は、リンキングプロセスの一環として実行することができる。TRVハッシュが計算される順序は、コンポーネントがロードされて測定されることになる順序と一致することができ、さもなければ、測定値どうしは、正しく一致することができない。ハッシュ値は、ローダにとって利用可能であること、または実行ファイル内に含まれることが可能である。信頼の連鎖を保持するために、TRVをセキュアに生成および/または格納することができる。たとえば、公開キー、例としてはソフトウェア/ファームウェアの製造業者の公開キーなどに対応する秘密キーを用いて、TRV値に署名することによって、TRVを保護することができる。
コンポーネントオブジェクトファイルは、図5において示されているように自分の関連付けられているTRVのためのプレースホルダとして別個のユーザ定義セクションを含むことができる。たとえば、図5において示されているように、コンポーネントオブジェクトファイル408のTRVを計算して、コンポーネントTRVセクション502内に格納することができる。セクションヘッダは、本明細書に記載されているユーザ定義セクションを含むことができるセクションの開始アドレスおよび/またはサイズを識別することができる。オブジェクトファイル402において、リンカーは、シンボルレゾリューションフェーズの終わりにコンポーネントオブジェクトファイル408のハッシュ値を計算し、対応するコンポーネントTRVセクション502を特定することができる。コンポーネントTRVをメモリ内の指定されたロケーション(たとえば、コンポーネントTRVセクション)において実行可能イメージ内に挿入することができる。セクションヘッダは、ローダが、妥当性確認プロセス中に特定のセクションに関するTRVを特定することを可能にすることができる。
本明細書において説明する際、デバイスの妥当性確認は、コンポーネントのインテグリティーステータスに焦点を合わせることができる。障害の生じているコンポーネントの報告を標準化することは困難である場合がある。なぜなら、ソフトウェアの開発慣行は、企業ごとに異なる場合があるためである。
本明細書において開示されているのは、コンポーネントが実行する機能に関してそれらのコンポーネントをグループ化する方法を標準化するためのシステム、方法、および手段である。機能は、標準仕様に準拠するように、および/または実施態様独自の様式で、標準化することができる。標準化することができるデバイス機能に関して、機能のリストを事前に定義することができる。機能とコンポーネントとの間における参照を使用して、インテグリティーチェック中に見つかった障害を報告のための特定の機能にマップすることを可能にすることができ、その一例が、図6において示されている。
図6において示されているように、信頼済みドメイン602は、互いにマップするコンポーネントおよび機能を含むことができる。たとえば、信頼済みドメイン602は、ハイレベル機能604、中間機能606、および/またはTrE(trusted environment)コア機能608を含むことができる。ハイレベル機能604は、機能610および機能612を含むことができる。中間機能606は、機能614および機能616を含むことができる。TrEコア機能608は、たとえばRoTなどの機能618を含むことができる。機能612は、コンポーネント620および/または622にマップすることができ、コンポーネント620および/または622は、たとえばソフトウェアコンポーネントとすることができる。機能616は、コンポーネント624にマップすることができ、コンポーネント624も、たとえばソフトウェアコンポーネントとすることができる。機能618は、コンポーネント626にマップすることができ、コンポーネント626は、たとえばファームウェアコンポーネントとすることができる。信頼済みドメイン602のインテグリティーチェック中に、コンポーネント624において障害を判定することができる。コンポーネント624は機能616にマップしているため、ネットワーク機能616にも障害が生じていると判定することができる。結果として、デバイスは、障害の生じている機能616の指示を修復のためにネットワークへ送信することができる。
図6における機能とコンポーネントとの間におけるマッピングは、実施層マッピング(enforcement layer mapping)として示されている。代替として、または追加として、コンポーネントと機能との間におけるマップを行う図6において示されている実施形態は、複数の層を有することができる。2つの層(たとえば、一方はコンポーネント用であり、他方は機能用である)よりも多い層を有するデータ構造を使用することができる。そのような構造においては、コンポーネントは、サブ機能のセットにマップすることができ、サブ機能は、さらにいっそう高いレベルのサブ機能のセットにマップすることができる。中間マッピングは、最終的なサブ機能層におけるサブ機能が、最終的な層における最終的な機能にマップされるまで、続くことができる。ツリーデータ構造またはツリーのようなデータ構造は、そのような多層のコンポーネントから機能へのマッピング関係を取り込むことができる構造の一例であると言える。
開発者は、コンポーネントが、標準化された機能にどのようにマップするかを判定することができる。一実施形態によれば、実行可能イメージは、コンポーネントから機能へのマッピングを含むことができる。これは、たとえば、コンパイルされたコードまたはソースコードを解析し、個々のファイルレイアウト、ファイル内の機能どうしの相互依存関係のうちの1つまたは複数を示し、コンポーネントから機能へのマッピングを可能にするグラフィカルツールを通じて、コンパイル時に達成することができる。機能は、テキストのフィールドおよび/または短縮されたID番号とすることができ、それは、ユーザによって入力すること、および/またはコンポーネント/ファイルに手動でマップすることが可能である。開発ツールは、コンポーネントから機能へのマッピングテーブルを参照するセクションを作成することができる。コンポーネント名、機能名、およびIDを、クロスリファレンスの相互のつながり(cross−reference inter−connect)とともに、テーブルの要素として含めることができる。
図7は、コンポーネントから機能へのマッピングを含むセクションの一例を示している。図7において示されているように、機能からコンポーネントへのマッピングセクション702は、たとえばオブジェクトファイル402などのオブジェクトファイル内の1つのセクションとして含めることができる。機能からコンポーネントへのマッピングセクション702は、本明細書において説明する際には、実行可能イメージ内の対応するセグメントにリンクすることもできる。
ローダの機能は、コードを外部から内部メモリへ持ってくることであると言える。信頼の連鎖は、コードのそれぞれのロードされるステージが、RoTから始まる前のステージおよびブートローダによって検証されていることに依存することができる。第2ステージローダは、次のステージを検証することができ、次のステージは、信頼済み環境およびOSローダのコアを含むことができる。OSが初期化されて実行されると、残りのインテグリティーチェックは、標準OSローダによって、本明細書に記載されているように実行することができる。実行可能イメージは、キャッシュに格納せずにRAMへロードすることができる。本明細書において開示されているこれらのコンセプトは、実行可能イメージが、さらなる修正を伴って利用可能なRAMよりも大きい、より制約の多い実施態様、たとえば、キャッシュメモリを使用することができる実施態様、およびコードを直接ROMから実行することができる実施態様などを含むように拡張することができる。
コードを外部から内部メモリへ持ってくるローダは、暗号インテグリティーチェックを実行する能力を含むことができる。インテグリティーチェックは、信頼済み環境内にセキュアに保持することができる暗号機能を遡って参照することができる。通常のオペレーションのもとで、ローダは、結合されたテキストセクション(たとえば、テキストセクション410)およびデータセクション(たとえば、データセクション412)内のコードおよびデータを、リンカーコマンドスクリプトおよびセグメントヘッダ情報によって定義されているように内部メモリへコピーすることができる。テキストセクション410およびデータセクション412をバルクロードする代わりに、ローダは、コードおよび/またはデータのユーザ定義セクションを識別することができる。この補足セクション情報のうちのいくつかは、インテグリティーチェックのために使用することができる。ローダは、コンポーネントに関するインテグリティー測定値を計算し、次いでそのコンポーネントに関するTRVをその関連付けられているセクション内で特定することができる。セクションヘッダは、セクションの開始アドレスおよびサイズを提供することができる。測定された値は、同じコンポーネントに関する格納されたTRVと比較することができる。それらの値が一致した場合には、コードを内部メモリへロードすることができる。それらのインテグリティー測定値が一致しない場合には、コードをロードすることはできず、障害をそのコンポーネントに関して記録すること、および/またはポリシーマネージャーに報告することが可能である。
それぞれのコンポーネントに関するローダの検証結果は、そのコンポーネントがチェック済みであることならびに合格または不合格のビット指示を示すビットフィールド内に格納することができる。コード全体が内部メモリに移された場合には、ポリシーマネージャーは、完了したインテグリティーチェックの結果に基づいてどんなアクセスをデバイスに許可するかを判定することができる。これを達成するための1つの方法は、ローダが、インテグリティー結果を追跡把握するためにセキュアなメモリロケーションにアクセスできるようにすることである。PLT(procedure linkage table)は、コンポーネントのインテグリティーがチェック済みおよび検証済みであるかどうかを追跡把握するためのさらなる情報要素で機能強化することができ、そのインテグリティーチェックの結果およびその情報は、それぞれのチェックされたコンポーネントが内部のRAMへロードされるにつれて更新することができる。
限られたメモリを有する組み込みシステムにおいては、コードスワッピングを使用することができる。コードスワッピングは、実行のために使用することができる機能をRAM内へロードすることを含むことができる。サブコンポーネントが使用される場合に、そのサブコンポーネントのアドレスがRAMにおいて利用可能でないならば、そのアドレスを特定するためにPLTおよびGOTテーブルを使用することができる。サブコンポーネントは、関連付けられているTRVを有するさらに大きなコンポーネントの小さな一部分であると言える。サブコンポーネントがロードされるにつれてそれらのサブコンポーネントを動的にチェックするシステムにおいては、1つのサブコンポーネントがロードされることになるたびに、コンポーネント全体のインテグリティーチェックが使用される場合がある。そのような必要性は、システム上に不必要な計算負荷を加える場合がある。
コンポーネントは、そのサブコンポーネントへと分割することができ、それぞれのサブコンポーネントごとのインテグリティーをチェックするために使用することができる中間TRVを計算することができる。さらに、中間ハッシュを計算するために、最小ブロックサイズを実装することができる。サブコンポーネントのTRVハッシュ生成のこのプロセスは、TRVダイジェスチョン(TRV digestion)と呼ばれる場合がある。たとえば、小さなサブコンポーネントハッシュをメモリページブロックサイズに基づいて計算することができる。このようにコンポーネントをサブコンポーネントへと分割することは、コンポーネントが、たとえばインストレーションまたはスタートアッププロセスの一環としてインテグリティーチェックされる場合に、行うことができる。GOTは、それぞれのサブコンポーネントの中間TRVを含むように機能強化することができる。
PIPE(Platform Integrity Policy Engine)は、全体的なプラットフォームトラストシステムアーキテクチャー(overall platform trust system architecture)の一部であると言える。たとえば、PIPEは、ネットワークが攻撃されること、デバイスが誤用されること、機密データが不正な方法でプラットフォーム上において通信または操作されることのうちの1つまたは複数を防止することができる。PIPEは、ブートローダ、ポリシーマネージャー、および仮想化コンポーネントなどのさまざまなオペレーティングシステム機能に依存して、セキュアな信頼できるプラットフォームを制御および作成することができる。PIPEは、セキュアブートプロセスのフロー、ソフトウェアコンポーネント上でのインテグリティーチェック測定値の処理、ポリシーに従ったその後の実施アクション、および/またはその後のソフトウェアロード制御のフローを含むさまざまな機能を制御することができる。ポリシーは、製造業者またはオペレータなどの外部利害関係者によって定義することができ、デバイス上に提供することができる。ポリシーは、リモート更新手続を通じてフィールド内で更新することができる。
PIPEは、制御されたソフトウェアデータチェックおよびロードオペレーション、より機能的な能力を漸進的にインストールすること、またはランタイム中のコンポーネントの動的なローディングを保持することのうちの1つまたは複数を通じて、危うくされたソフトウェア機能がロードされるリスクを減らすことができる。ローディングオペレーションにおける漸進のステージに応じて、アクションは、プラットフォームのパワーダウン、(1つもしくは複数の)危うくされたコンポーネントのローディングを防止すること、または(1つもしくは複数の)コンポーネントを隔離すること、低いレベルの障害もしくは危うくされた機能を通知するためにネットワーク内のセキュリティーゲートウェイもしくは修復マネージャーなどの外部エンティティーへのアラームをトリガーすること、プラットフォーム上のセキュアな情報、たとえば認証キーなどへのアクセスを防止すること、プラットフォーム上のセキュアな機能、たとえば認証アルゴリズムなどへのアクセスを防止すること、バルクコードもしくはデータリロード/更新手続を実行すること、危うくされたソフトウェアコンポーネントおよび/もしくは構成データを置換すること、または改ざんの疑いがあるコンポーネントをより詳細に調査して(よりきめ細かい詳細を伴うインテグリティーチェックを含む)、そのコンポーネントにおける障害のロケーションを分離することのうちの1つまたは複数を含むことができる。
いくつかのケースにおいては、コアTrE機能が危うくされたために、信頼済み環境でさえ、プラットフォームにおける信頼を保証できないことがあるほど、障害が深刻である場合がある。低いレベルの障害は、インテグリティーおよびリプレイ保護ならびにコンフィデンシャリティー保護を含むことができる、デフォルトのルートオブトラスト署名済みアラームメッセージ(default root−of−trust signed alarm message)を生成することなどの初歩的なオペレーションをトリガーすることができる。すなわち、クリティカルな低いレベルのセキュリティー障害が発生すると、利用可能とすることができる1つまたは複数の通信チャネルによって障害メッセージをネットワークにリリースすることができる。
ロードされた機能がビルドされて、ますます洗練されるにつれて、デバイスは、ネットワークエンティティーのためにセキュアな信頼できるプロキシとして機能することなど、さらに洗練されたアクションを実行することができ、それによって、危うくされたソフトウェアまたは構成データを診断し、報告し、および/または置換するための問合せ的な手続(interrogative procedure)を容易にすることができる。
成功裏に検証された機能のレベルに応じて、プラットフォーム上のリソースへのさまざまなアクセスを(たとえば、PIPEによって)提供することができる。コンポーネントのインテグリティーチェックの結果、障害がある場合には、そのコンポーネントを信頼することはできない。この検知された障害は、セキュアにマークしてネットワークに(明示的にまたは黙示的に)示すことができ、ブートフローは、この障害の生じている状況に起因して分岐することができる。このタイプのインテグリティーチェック障害は、実行フロー障害と呼ばれる場合があり、これによって、チェックされたコンポーネントは信頼できないとすることができ、このコンポーネントを始動させると、悪意のある、危うくされた、障害の生じている、または誤って構成されたコードを実行する結果になる可能性があり、それによってデバイスは、ネットワーク機能を、指定されていないおよび/または予測されていない方法で実行することになる可能性がある。したがって、新たなコンポーネントおよび利用可能な機能をロードすることは、それまでにロードされたコンポーネントのインテグリティーによって影響を受ける可能性がある。
結果として、実行環境は、それぞれのブートステージおよびそれぞれのランタイムプロセスにおける制御実行プロセスおよび/またはアクセス特権に応じて変化する可能性がある。たとえば、ブートプロセスにおけるそれぞれのステージでは、その時点で行われたインテグリティー測定に基づいて判定を行うことができる。その後のステージおよびポリシーは、自分自身のオペレーションを判定するために、実行ステージを越えて情報を伝達または格納する任意の利用可能な保護された手段(状態、変数、パラメータ、レジスタ、ファイルなど)を通じて前のステージから渡された情報を使用することができる。たとえば、上位層アプリケーション認証機能は、たとえば外部エンティティーを成功裏に認証するのに使用されたキーのリリースのゲーティング(gating)を含めて、自分自身のオペレーションを判定するために、それまでにロードされたコンポーネントのインテグリティーに関する情報を使用することができる。
例示的なPIPE機能フローを、本明細書に記載されているように実行することができる。たとえば、RoTをインテグリティーチェックすることができ、および/またはそのインテグリティーを検証することができる。ベースラインTrE(baseline TrE)をRoTによってインテグリティーチェックすることができ、および/またはそのインテグリティーを検証することができる。ベースラインTrEのインテグリティーチェックおよび/または検証において障害がある場合には、PIPEは、ネットワークへの接続のために使用されたキーのリリースを防止すること、ネットワークへのアラームをトリガーすること、および/またはデバイスをパワーダウンすることが可能である。PIPEがネットワークへのアラームをトリガーした場合には、そのアラームがネットワークへ送信されることを可能にすることができるフォールバックコードをロードすることができる。アラームは、TrEを置換するためのリモートバルク更新手続をトリガーすることができる。
ベースラインTrEのインテグリティーチェックおよび/または検証において障害がない場合には、基本通信接続コードをロードすることができる。これは、ベースラインオペレーティングシステムモジュール(baseline operating system module)のインテグリティーチェックおよびローディングを実行すること、ベースラインマネージメントクライアント(baseline management client)のインテグリティーチェックおよびローディングを実行すること、ならびに/または通信モジュールのインテグリティーチェックおよびローディングを実行することを含むことができる。オペレーティングシステムモジュール、ベースラインマネージメントクライアント、および/または通信モジュールのインテグリティーをチェックしている間に障害が識別された場合には、PIPEは、ネットワークへの接続のために使用されたキーのリリースを防止すること、ネットワークへのアラームをトリガーすること、コンポーネントを置換するためのリモートバルク更新手続を実行すること、リモートコンポーネント更新手続を実行すること、および/またはデバイスをパワーダウンすることが可能である。PIPEがリモートバルク更新手続をトリガーした場合には、アラームがネットワークへ送信されることを可能にすることができるフォールバックコードをロードすることができる。アラームは、基本コードを置換するためのリモートバルク更新手続をトリガーすることができる。
基本通信接続コードのインテグリティーチェックおよび/または検証において障害がない場合には、残りのオペレーティングシステムおよびマネージメントクライアントコンポーネントをインテグリティーチェックおよび/またはロードすることができる。これは、再配置可能なおよび/またはリロード可能な機能モジュールのインテグリティーチェックおよび/またはローディングを実行することを含むことができる。インテグリティーチェック中に識別された障害がある場合には、PIPEは、ネットワークへの接続のために使用されたキーのリリースを防止すること、障害レポートをプロトコル内に含めてネットワークへ送信すること、アラームをトリガーすること、および/もしくはリモートコンポーネント更新手続を要求すること、ならびに/またはデバイスをパワーダウンすることが可能である。障害レポートは、たとえばネットワークによってリモートから更新することができる障害の生じているコンポーネントを示すことができる。
PIPEのアクションは、成功裏に検証されたブートチェーンに応じて変化する可能性がある。ブートプロセスにおけるそれぞれのステージでは、その時点で(またはその時点までに)インテグリティーチェックされている基礎をなすプラットフォームの一部または全体の査定されたインテグリティーと、適用されることになるポリシーとに基づいて判定を行うことができる。これらのポリシーは、達成される信頼レベルに応じて、改変すること、またはその他のポリシーによって置換することが可能である。実行環境は、それぞれのブートステージにおける制御ポリシーに応じて変化する可能性がある。その後のステージおよび/またはポリシーは、実行ステージを越えて情報を伝達または格納する利用可能な保護された手段(たとえば、状態、変数、パラメータ、レジスタ、ファイルなど)を通じて前のステージから渡された情報を使用することができる。
本明細書において説明する際、たとえば、PIPEは、ポリシーをプラットフォーム上に提供することができ、そのプラットフォーム上で、それらのポリシーは、たとえば、図8において示されているように、プラットフォームの構成および信頼状態の達成されるレベルに応じて改変または変化することができる。図8において示されているように、TrE802を、対応するポリシー812に従ってインテグリティーチェックすること、ロードすること、および/または実行することが可能である。TrE802が、信頼済みエンティティーとして確立され、実行されると、デバイスは、ブートシーケンスの次なるステージへ移ることができる。たとえば、能力804を、ポリシー814に従ってインテグリティーチェックすること、ロードすること、および/または実行することが可能である。能力804のインテグリティーチェック、ローディング、または実行は、TrE802のインテグリティーチェック、ローディング、または実行に関連付けられている情報(たとえば、信頼状態)に基づくことができる。能力904のインテグリティーチェック、ローディング、および/または実行の最中に実施することができるポリシー814は、ブートシーケンスの前のステージにおいて実施されたポリシー812によって知らせることができる。能力804が、信頼済みエンティティーとして確立され、実行されると、デバイスは、ブートシーケンスの次なるステージへ移ることができる。ブートシーケンスは、能力806、808、および810をそれぞれ、それらの対応するポリシー816、818、および820に従ってチェックすること、ロードすること、および/または実行することによって継続することができる。ブートシーケンスのそれぞれのステージは、本明細書に記載されているように、ブートシーケンスの前のステージのうちの1つまたは複数によって知らせることができる。
本明細書に記載されているポリシーは、オペレータなどの信頼済み外部エンティティーによって提供することができる。プラットフォームの達成された信頼状態の結果は、プラットフォームの信頼状態について知る合法的な権益/権利を有することができる外部エンティティー、たとえば機密アプリケーションまたはサービスのオペレータまたはプロバイダなどに伝達可能とすることができる。プラットフォームのブートアップまたはオペレーションサイクルのおそらくは別々のステージにおいて査定されるプラットフォームのおそらくは別々の状態に関する情報の伝達先となることができる外部エンティティーは複数存在することができるということに留意されたい。
多層インテグリティーチェック、およびそのようなインテグリティーチェックをプラットフォームの信頼状態に結び付けることは、本明細書に記載されているように実行することができる。たとえば、そのようなインテグリティーチェックおよび結び付けは、デバイス上のキーがデバイスの達成された能力(たとえば、修復タスクを実行するネットワーク上のサーバなどの外部検証者に対するデバイス修復機能)を認証することをポリシーおよび実施によって確実にするために、多層インテグリティーチェックを使用することができる。認証のためにそのようなキーを使用するセキュリティーに敏感な機能は、所望の能力を達成するためのソフトウェアおよび/または構成ファイルのある特定の事前に知られているセットがインテグリティーチェックに合格した場合に、デバイスにとって利用可能となることができる。そのようなソフトウェアおよび/または構成ファイルは、たとえば、低いレベルのOS機能、ドライバ、構成ファイル、および/または通信スタックコードの何らかのサブセットを含むことができる。
多層インテグリティーチェック、およびインテグリティーチェックの結び付けは、認証キーを保護するために使用されるポリシーを含むこともでき、それによって、そのキーを、許可された機能またはプロセスによる使用に制限することができる。そのキーが保護されていなければ、そのキーにアクセスするためにソフトウェアが危うくされる可能性がある。デバイスは、キーが、能力、機能の限定されたセット、または単一の機能による使用に制限されるようにキーを保護すること、そのキー上で動作する機能/プログラムを保護すること、および/または誰(たとえば、ユーザ、システム、スクリプトなど)がこれらの特権付きの機能のうちの1つを呼び出すことができるかを制限することのための信頼済み機能を提供することができる。
多層インテグリティーチェックおよび結び付けのための、本明細書に記載されている実施形態は、危うくされている可能性のあるデバイスが、外部エンティティーに対する自分の部分的な能力(たとえば、修復サーバ、またはそのようなサーバのためのAAAエンティティーに対して障害を報告して修復アクションを実行する自分の能力)を認証できるようにするために使用することができる事前に知られているソフトウェアのセットを含むことができる。外部エンティティー(たとえば、修復サーバ)は、論理エンティティーとすることができ、デバイスマネージメントサーバ(たとえばH(e)NBの場合のH(e)MSなど)によってホストすることができる。
特定のプラットフォーム上の実際の実施態様から独立していることが可能であるポリシーを指定するメカニズムを提供するためには、特定のプラットフォーム能力のために所望される可能性がある機能を指定することによって、それらのポリシーを定義することができる。したがって、本明細書において開示されているコンポーネントから機能へのマッピングと同様の方法で、特定の能力に対応するポリシーを機能にマップすることもできる。外部利害関係者は、特定の能力に関するポリシーを単一の機能または複数の機能に対して指定することができる。能力を特定のポリシーに、およびプラットフォーム構成のステージにマップする際のポリシー要件を解釈することは、PIPEの担当とすることができる。
特定の能力が機能の特定のセットを使用する場合には、それらの機能は、その特定の能力に合わせた対応するポリシー用に指定することができる。たとえば、修復を実行する能力が、ポリシーにマップされることを所望される場合には、修復を実行するために使用される機能は、対応するポリシーにマップすることができ、たとえば、修復能力を機能1、2、および3によってカバーすることができ、したがって、対応するポリシーは、機能1、2、および3にマップするように指定される。
いくつかの実施態様に関しては、プラットフォームの階層化された構成と、能力および機能との間に妥当なレベルの相関関係が存在することができる。能力は、機能とともに、層ごとに漸進的に構成することができる。たとえば、修復機能および能力は、プラットフォーム構成の初期のステージにおいて構成することができる。
多層インテグリティーチェックは、別々の機能のチェック済み対未チェックのステータスの順次的な判定ではないと言える。機能は、順次的な様式でチェックすることができる。しかし、別々の機能は、(その後に別々のステージにおいてロードすることができる)別々のコンポーネントにマップすることができるため、インテグリティーに関する機能単位の判定のプロセスは、順次的でない様式で、または、コンポーネント単位のインテグリティーチェックのアトミックプロセスのシーケンスに(持続時間において、または時間順序において)必ずしも同期化されていない順次的な様式で行うことができる。
ポリシー実施のためにシリアライゼーションを使用することができる。ポリシー実施は、所与のプラットフォーム能力に関して、対応する機能がインテグリティーチェックされているかどうか、および/または適用されるべきポリシーを判定することができる。
多範囲の認証(multi−scope authentication)は、プラットフォームが、そのプラットフォームの達成された信頼レベルに基づいて1つまたは複数の外部エンティティーに対して認証を行うことを可能にすることができる。認証メカニズム(たとえば、認証チャレンジ応答メカニズム)を、デバイスのインテグリティーの結果として得られる範囲を外部エンティティーへ伝達するための手段として使用することができる。外部エンティティーは、認証を行い、そして同時に、デバイスのインテグリティーのレンジ/範囲の指示を得ることができる。
デバイスのTrEは、多層インテグリティーチェックを経る間に、別々の目的で、認証チャレンジ応答に関する別々のパラメータまたはパラメータ値を生成することができる。パラメータのそのような生成は、成功したインテグリティーチェックの範囲に応じて外部認証エンティティーとの間で共有される同じ秘密証明書に基づくことができ、またはその秘密証明書を使用することができる。共通のチャレンジレスポンスコンピューティングアルゴリズムを使用することができる。しかし、そのようなアルゴリズムへの入力は、インテグリティーチェックの範囲、および/または認証の目的に応じて、異なるものとすることができる。たとえば、TrEがコードベース全体を成功裏にチェックした場合には、「entire code basis successfully checked(コードベーシス全体が成功裏にチェックされた)」などのテキスト文字列を、認証チャレンジ応答コンピューティングアルゴリズムへの入力として使用することができる。TrEが、障害修復機能を実現するために使用されるコンポーネントを成功裏にチェックしたが、必ずしもコードベース全体のチェックは行っていない場合には、「code base for distress remediation successfully checked(障害修復のためのコードベースが成功裏にチェックされた)」などの別の文字列を、入力として使用することができる。
外部認証者は、自分の認証チャレンジ要求をデバイスへ送信し終わると、「予測された」チャレンジ応答の2つのバージョンを計算することもできる。外部認証者は、デバイスにおけるチャレンジ応答の計算においてどの入力が使用されたかを知ることができないため、応答の両方のバージョンを計算しなければならない場合がある。デバイスから受信された応答を、応答の予測されたセットと比較することによって、外部認証者は、黙示的にデバイスインテグリティーの「範囲」を連続してテストすることができる。このエンティティーは、デバイスのインテグリティーのある特定の「範囲」がデバイス側で成功裏にチェックされていることを、帰納によって、認証および/または検証することができる。上記の例においては、機能のインテグリティーをチェックすることを条件として、デバイスの別の特定の(たとえば、部分的な)能力、ひいては、その能力を実現するために使用されるコンポーネントを認証するために、同じまたは同様の実施態様を使用することができる。
一例として、信頼を検証できる外部指示は、コードインテグリティー測定値を特定のブートサイクル実行および構成署名に結び付けるセキュアブートプロセス中の署名証明書の保護されたリリースとすることができる。セキュアなタイムスタンプ、ブートサイクルごとにインクリメントする保護されたモノトニックカウンタ、またはブートサイクルシークレット(boot cycle secret)(たとえば、ブートサイクルごとに1回生成または導入されるノンスなどの隠されたランダムな値)を含むことができる。認証キーは、前提条件が満たされている場合に利用可能になることができ、現在の信頼できるプロセスは、次のリセットまで(たとえば、最初の測定の後に障害が検知された際に)障害の生じている状況へ戻ることに限定することができる、保護されたブートごとに1回限りのプログラム可能な「合格」フラグ(protected one−time per boot programmable “pass” flag)を設定する。TrEなど、(たとえば、ブート時だけでなく、ランタイム内に及ぶ)永続的な信頼済み環境は、外部エンティティーへのリリース前に、認証プロトコルノンスを使用して、ステータス情報に署名することができる。レポートのセクションには、現在検証されている信頼できるプロセスによって一時的なブートキーを用いて署名することができ、それによって、その後のプロセスは、このステータスを妥当性確認のために外部エンティティーに提示することができる。
認証プロトコル内に含めてやり取りされる修正された(1つまたは複数の)ランダムノンスを使用することができ、そのような修正された(1つまたは複数の)ノンスは、チャレンジ応答および予測されたチャレンジ応答の計算に対する入力として使用することができる。すなわち、デバイス自体の上で、デバイスのTrEは、その認証応答を、通常は、(たとえば、インテグリティーチェックが合格した場合には、)応答計算に対する入力において認証サーバから受信された(1つまたは複数の)ランダムノンスを使用して、計算するよう試みることができる。デバイス全体のインテグリティーのチェックは不合格であるが、デバイスの部分的な機能のインテグリティーチェック、たとえば「障害/修復機能」のインテグリティーチェックなどが合格である場合には、TrEは、応答のための別の値を、今度は、受信されたノンスの修正されたバージョンを使用して、計算することができる。そのような修正がどこで/どのようにして実行されるかは、認証サーバに知らせることができる。そのような修正の例としては、オリジナルのノンスの既知の位置における1つのビットまたは複数のビットを変更することを含むことができる。こうすれば、デバイスおよび認証サーバの両方は、オリジナルの「デバイス認証」応答を計算することに加えて、修正されたノンス入力を使用して応答を計算することができる。受信側(たとえば、認証サーバ)では、サーバは、デバイスから受信する応答が「デバイス認証」応答と一致するかどうかをチェックすることができる。それらが一致しない場合には、認証失敗をすぐに公表する代わりに、認証サーバは、受信された応答を、修正されたノンスを使用して計算された別の値の応答と比較することができる。それらが一致する場合には、認証サーバは、たとえそのデバイスを全体として認証することができなくても、この例における「障害/修復機能」などの特定の機能を認証することができると判定することができる。
セキュアブートプロセス中に、デバイスは、それぞれのソフトウェアコンポーネントを、対応するTRVと比較することによって、コンポーネントのインテグリティー障害を知ることができ、これは、コンポーネントのビットの正確さおよびソースの真正性を確実にする上で役立つことができる。
検知されたコンポーネントチェック障害は、インテグリティーチェックステータス情報要素内に取り込むことができる。このステータスデータの構造は、セキュリティーの目的で、ならびに報告および診断における効率のために、さまざまな形態のうちの任意の形態を取ることができる。この情報は、ポリシーマネージメント手続をサポートする現在およびその後のブートステージおよびランタイムプロセスによって読み取られることが可能である。デバイスのネットワーク機能およびその他の機能へのコンポーネントの依存関係を判定するために、コンポーネントから機能へのマップを使用することができる。機能は、接続しているエンティティー、たとえばネットワークオペレータが、またはデバイスによってサポートされている付加価値のあるアプリケーション、たとえばモバイルペイメントが依存することができる機能とすることができる。オペレータおよび/またはアプリケーションサービスプロバイダは、トラフィックを搬送すること、修復、マネージメントオペレーション、または付加価値のあるアプリケーション機能など、特定のタスクに関するデバイスの信頼済みオペレーションのためにどの機能を使用することができるかを定義することができ、特定のネットワークオペレーションのためにどの機能を使用することができるかを示すポリシーをデバイス上に設定することができる。
ネットワーク機能のセットは、ネットワークオペレータおよび/またはアプリケーションサービスプロバイダから期待される能力の標準セットから生じることができる。機能は、無線テクノロジー、プロトコルスタックにおける層、ネットワークプロトコル、マネージメント能力、セキュリティーおよび信頼メカニズム、付加価値のあるアプリケーション機能などを含むことができる。
デバイスのポリシーマネージャーは、デバイスコンポーネントに従ってネットワーク機能の依存関係を示すことができる(本明細書に記載されているような)組み込まれたコンポーネントから機能へのテーブルまたはマップを使用することができる。インテグリティーチェックおよび/または報告の最中におけるそのようなコンポーネントから機能へのテーブルまたはマップの使用が、図9において示されている。図9において示されているように、デバイスは、コンポーネント902のインテグリティー測定値をそれらの対応するTRV904と照合することによって、910においてインテグリティーチェックを実行することができる。インテグリティーチェックが実行された後に、デバイスポリシーマネージメントエンティティー908は、916において、インテグリティーチェックされた1つまたは複数のコンポーネントのコンポーネント識別子(たとえば、コンポーネントアドレス)を、および918において、それぞれのコンポーネントがインテグリティーチェックに合格したかまたは不合格だったかの指示を受信することができる。ポリシーマネージメントエンティティー908は、ネットワークエンティティーへ送信するためのコンポーネントに関連付けられている対応する機能を判定することができる。たとえば、修復を必要とする障害の生じている機能を送信することができ、または妥当性を確認された機能の指示を送信することができる。たとえば、ポリシーマネージメントエンティティー908は、所与のコンポーネントに対応するコンポーネント識別子を922において取り出すために、920においてコンポーネントアドレスを使用することができる。図9において示されているように、コンポーネント識別子は、コンポーネントアドレスからコンポーネント識別子へのマッピングを含むテーブル906から取り出すことができる。ポリシーマネージメントエンティティー908は、所与のコンポーネントに対応するコンポーネント機能を926において取り出すために、924においてコンポーネント識別子を使用することができる。コンポーネント機能は、コンポーネント識別子からコンポーネント機能へのマッピングを含むテーブル912から取り出すことができる。ポリシーマネージメントエンティティー908は、判定された機能(たとえば、インテグリティーチェックに合格したかまたは不合格だった機能)を使用して、932においてネットワークエンティティーと対話することができる。たとえば、ポリシーマネージメントエンティティーは、インテグリティーの報告を実行すること、デバイスポリシーを受信すること、または、判定された機能のうちの1つもしくは複数に対応するアクションおよび/もしくは制限を受信することが可能である。それぞれの機能は、1つまたは複数のポリシー930に関連付けることができる。1つまたは複数の機能の集合は、共同でデバイス内の特定の能力を可能にすることができる。これらの能力は、階層化することができる。たとえば、ベース層の能力は、次なる能力層のサブセットであることが可能であり、次なる能力層は、その次の能力層のサブセットである、といった具合である。能力の階層化は、典型的な層および信頼の連鎖に基づくセキュアブートシーケンスを反映することができる。層は、特定の能力を可能にする機能の任意の組合せとすることができ、または機能の階層化および特定の組合せのハイブリッドな組合せとすることもできる。ポリシーマネージメントエンティティー908は、所与の能力に対応する1つまたは複数のポリシーを930において取り出すために、コンポーネントからマップされた機能を928において使用することができる。ポリシーは、能力からさまざまなポリシーへのマッピングを含むテーブル914から取り出すことができる。ポリシーは、932において示されているようにネットワークエンティティーから受信することができる。
障害の生じているコンポーネントは、結果として、1つまたは複数の障害の生じている機能につながる可能性がある。ソフトウェア開発/ビルドツールによって組み込まれているコンポーネントから機能へのマップの情報は、機能のインテグリティーチェック障害の測定を確認する際に、ひいては、デバイスおよび製造業者の点で実施態様から独立していることが可能である障害、たとえば、認証機能またはベースバンド無線プロトコルスタック(baseband radio protocol stack)の障害を、標準化された方法で報告する際に、ポリシーマネージャーをサポートすることができる。デバイス上では、この情報を修正から保護することができ、不変のRoT(root of trust)によって保証することができる。
ポリシーマネージメントプロセスは、この情報をブートおよびランタイム環境において利用することができる。デバイス上のポリシーマネージメントプロセスは、インテグリティーチェックプロセスの結果を使用して、どのネットワーク機能に障害が生じているかを判定することができる。コンポーネントは、コードがローダによってチェックされているときにブート時間中に利用可能である参照(たとえば、シンボルテーブルまたはメモリアドレス)によって識別することができる。チェックされているコードは、インテグリティーおよびソースの真正性が検証されるまで、実行可能なメモリにおける使用から隔離することができる。同様に、チェックされるコードは、ロードされた時点から、チェックされて、実行中に至るまで(たとえば、保護された実行および格納、ハードウェア保護、暗号保護、仮想化などによって)保護することができる。実行は、メモリマップ、アクセス特権などの修正によって防止することができる。図9におけるテーブル906および912において示されている一例として、アドレスロケーションxにおけるコードは、コンポーネントAに対応することができ、コンポーネントAは、ネットワーク機能F1、F5、およびF14にマップすることができる。このコードは、たとえば、複数の通信プロトコルが依存するプリミティブハッシング関数(primitive hashing function)とすることができる。インテグリティーの報告および修復は、障害が生じているプリミティブに依存する場合がある。したがって、これらのインテグリティーの報告および修復の機能は、基礎をなすサポート機能としてネットワーク標準化リスト内に含めることができる。
機能障害の標準化されたリストは、デバイスの能力に関するきめ細かい情報をネットワークに提供することができる。リモートデバイスに関しては、そのデバイスが依然として何を達成することができるかに関する信頼できる理解は、問題を修復するためにリソースを適用する際に有用である場合がある。障害のケースにおいては、ネットワークが障害指示自体のインテグリティーの妥当性を確認することができるように(たとえば、ソース、時間、および正確さ)、保護され保証された方法で障害を示す能力を有することは、誤ったアラームのもとでの高価なネットワークリソースの不必要な使用を防止することができる。
図10は、例示的なシステムコンポーネントを含む報告および修復システムの例示的な概観を提供する。図10において示されているように、1002において、デバイス1004のコンポーネント上で障害を検知することができる。障害は、ネットワークに示すことができる。たとえば、障害は、1008においてネットワークに報告されるデバイスレポート1006内に含めることができる。障害は、たとえば、障害の生じているコンポーネントに関連付けられている障害の生じているネットワーク機能として示すことができる。障害がネットワークに報告された場合には、ネットワークは、アクセス制御に関してきめ細かい決定を行うことができる。たとえば、ネットワークプラットフォーム妥当性確認エンティティー1010は、報告された機能チェックレポート1006に基づいて、アクセスを許可しないこと、部分的なアクセスを許可すること、または完全なアクセスを許可することが可能である。アクセス決定は、1016においてデバイス1004によって受信することができる。デバイスレポート1006において示されている障害がある場合には、ネットワークプラットフォーム妥当性確認エンティティーは、その機能レポートをデバイスマネージメントサーバ1012へ転送することができ、デバイスマネージメントサーバ1012は、機能からコンポーネントへのマッピング情報1014から、障害の生じている(1つまたは複数の)コンポーネントを判定することができる。この情報を使用して、デバイス1004を修復すること、および障害の生じているソフトウェアコンポーネントをデバイス1004内にリロードすることが可能である。たとえば、デバイスマネージメントサーバ1012は、障害の生じているコンポーネントに関連付けられている障害の生じている機能の範囲を絞り込むために、1018においてデバイス1004に問合せを行うことができる。インテグリティー障害が、効率的な修復のためにデバイス1004のあるセクションへ分離された後に、デバイスマネージメントサーバ1012は、1020において、たとえばコードビルドリリースエンティティー1022などから、ソフトウェアの更新(たとえば、置換コンポーネント)を要求することができる。デバイスマネージメントサーバ1012は、障害の生じているコンポーネントを修復するために、ソフトウェアの更新を1024においてデバイス1004に提供することができる。製造業者のデバイス上での特定の障害の生じているコードのこの形態の抽出は、オペレータが(自分が接続している先の)デバイスを詳細に知る負担を減らし、その一方で同時に、障害の生じている機能に基づいて、きめ細かいアクセス制御および修復の決定を可能にすることができる。
実行フロー障害とは、プロセスチェーンにおいて呼び出すことができるコンポーネントに対する障害であると言える。コンポーネントの実行は、高いレベルの保証を保持する一方で、デバイスの能力を拡張することができる。現在の検証されているプロセスが、次なるプロセスのコードのインテグリティー(および場合によってはデバイスの構成)をチェックして、障害が生じていると判明した場合に、実行フロー障害を検知することができる。その後のブートコードにおける障害は、現在の信頼済みプロセスが、現在の状態を最後の知られている良好な状態としてロックダウンすること、障害を示すこと、プロセスの制御を待機モードで保持すること、制御を障害プロセスに渡すこと、および/または制御を信頼できないプロセスに渡すことのうちの1つまたは複数を実行することができるということを意味する場合がある。障害の生じているステージに関する認証および識別キーは、さらなるプロセスから締め出すことができ、したがって、信頼できないプロセスが、報告(たとえば、署名されたステータス)または認証技術(たとえば、自律的な妥当性確認)を通じて有効な状態をネットワークに示せないようにすることができる。
効率のために、デバイスからネットワークへ送信される障害レポートは、きめ細かいゲートウェイアクセス制御を実行して、デバイス障害をネットワークのデバイスマネージメントエンティティーに示すための、オペレータネットワーク妥当性確認機能からのアクションを促すために使用される最小限の量の情報を含むことができる。マネージメントエンティティーは、製造業者固有の情報を参照して、障害の根本原因を判定すること、およびどのコードを修復できるかを判定することが可能である。マネージメントエンティティーは、そのエンティティーがアクセス制御および/または修復に関してさらなるポリシー決定を行うことを可能にするためのさらなる情報をネットワーク妥当性確認機能に返すことができる。
障害レポート内に含めることができる障害の生じている機能の例示的なセットが、下記のテーブル1に記載されている。
結果、すなわち合格または不合格の機能レポートを送信することができる。テーブル2は、そのようなリストの一例を提供している。
機能レポートは、ゲートウェイ認証のために使用されるものなど、代替チャネル上で認証中にペイロード内に含めて移送することができ、したがって、たとえゲートウェイ認証が不合格であっても、レポートは、認証シーケンス内のペイロードとして送信することができる。ペイロードには、デバイスの信頼済み実行環境によって署名することができる。
TrE(trusted execution environment)は、(たとえば、便宜上または予備の目的で)自分自身の機能フィールドを有することができる。しかし、機能または障害ペイロードのリストがTrEによって署名されているか、または認証キーがTrEによって保護されている場合には、TrEのインテグリティーは、ネットワークへの接触時に知られることが可能である。TrEの(1つまたは複数の)署名キーは、フェイルセキュアシーリング方法(fail−secure sealing method)によって保護することができる。すなわち、TrEが危うくされている場合には、TrEの(1つまたは複数の)キーが利用可能ではない(たとえば、デバイスまたはその内部の機能およびインターフェースにとって利用可能ではない、I/Oおよびテストポートにとって利用可能ではない、ならびに外部ネットワークエンティティーにとって利用可能ではない)場合がある。
障害またはアラームのイベントにおいては、サービングネットワークエンティティーは、障害中のデバイスが、障害を確実に報告する機能を有していること、および障害中のデバイスのメカニズムには障害が生じていないことを検証することができる。2つの形態の保証によって、報告メカニズムが信頼できることをネットワークに示すことができる。1つめは、特定のタイプのデバイスが、信頼できる報告能力の特定のセットに準拠している旨の証明書など、信頼済みサードパーティーによる保証という静的な形態で生じることができる。この保証は、アラームおよび障害状況のメッセージを処理および送信するためのデバイスの能力および堅牢性(または信頼性)のレベルに関する情報を提供することができる。ネットワークオペレータは、障害アラームのイベントにおいて適切に自動的に対応するための手続を確立する保証された能力を使用することができる。
別の形態の保証は、デバイスとのオンライントランザクションを通じて生じることができる。デバイス内のメカニズムは、障害イベントの時点で報告メカニズムのインテグリティーの指示を提供することができる。この内部の能力は、サードパーティーが準拠の証明書を提供することを可能にすることができるという点で、静的な形態の保証に関連していると言える。
さまざまなプロトコルフローが、本明細書においては、H(e)NBのコンテキストにおけるデバイス障害および修復に関して説明されているかもしれない。しかし、本明細書において説明されているコンセプトは、そのような実施形態に限定されるものではなく、いかなる通信デバイスにも適用することができる。図16において示されている例示的な一実施形態によれば、デバイスインテグリティー情報は、H(e)NBからSeGWを通じてマネージメントサーバ(H(e)MS)へ送信することができる。図17において示されている別の例示的な実施形態によれば、H(e)NBは、直接マネージメントサーバ(H(e)MS)に接続することができる。図18Aおよび図18Bにおいて示されている別の例示的な実施形態によれば、部分的な障害のイベントにおいてきめ細かいアクセス制御を可能にするようにデバイスインテグリティーチェックを補強することができる。それらの手続は、ネットワーク内の修復エンティティーから受信された修復データを使用してDRFによって変更することができるDRFの制御下でのコードまたはデータブロックの修復を可能にすることができる。これは、システムアーキテクチャーがそのような変更を可能にする場合には、ソフトウェア、およびまたソフトウェアまたはハードウェア構成データの変更を含むことができる。示されているフローは、ソフトウェア修復を対象としているかもしれないが、それに限定されるものではない。
ネットワークマネージメントエンティティーと、デバイス自体との間において問合せを実行することができ、その間に、デバイスの障害が生じているインテグリティーに関する詳細な情報が、はじめに報告されたよりもきめ細かな精度で抽出される。この情報は、障害の原因の発見につながることができ、コンポーネントのどの部分に障害が生じているかを示すことができ、また、ソフトウェアダウンロードのサイズを小さくすること、ひいては、ネットワーク帯域幅に対するニーズと、コードダウンロードのサイズとのバランスを取ることによる効率的なデバイスマネージメントのためのコードおよび/または構成のさらにきめ細かな修正を可能にすることができる。例示的な一実施形態によれば、IPインターネットプロトコルを使用している管理されているネットワークデバイスは、デバイスマネージメントの目的でTR−069(CPE WAN)を利用することができる。このプロトコルは、ACS(「auto configuration server」)へのアクセスを提供することができる。ACSアプリケーションは、テーブル3において示されているように、プロトコルスタックにおけるいくつかの能力を使用することができる。
このスタックは、RoTプロセスにとってアクセス可能とすることができ、RoTプロセスは、TR−069に接続されているマネージメントサーバに高い保証の障害指示を提供することができる。しかし、それぞれの層の機能の完全なリストは、障害状況において使用することができず、したがって、デバイスをセキュアにブートストラップして完全なマネージメントおよびデバイス機能へ戻すために使用される手続を実行するようにスタックを削って整えることができる。
図11は、実行することができるアクションを判定するためにデバイスにおける情報を収集するための例示的なコールフロー図を示している。インテグリティー障害が生じた場合には、図11において示されているシーケンスは、H(e)NB1102などのデバイス(たとえば、TR−069デバイス)と、H(e)MS1104などのネットワークエンティティーとの間において生じることができる。1106においては、H(e)NB1102と、H(e)MS1104との間において接続(たとえば、TR−069接続)を確立することができる。たとえば、H(e)NB1102は、その接続を、1106において自分のTrEまたはRoTを使用して確立することができる。1108においては、H(e)NB1102は、たとえば、Information Requestおよび/またはアラームを使用することによって、(1つまたは複数の)インテグリティー障害をH(e)MS1104に報告することができる。H(e)MS1104は、そのアラームを1108において受信することができ、1110においてInformation Responseメッセージ(たとえば、TR−069通知応答)を用いてH(e)NB1102に応答することができる。
大雑把に言って、デバイスのそれぞれのソフトウェアコンポーネントは、対応するTRVを有することができる。本明細書に記載されているように、あるコンポーネントが基準に一致しない場合には、そのコンポーネントはインテグリティー障害を有していると言える。いくつかのコンポーネントは、きわめて大きい場合がある。たとえば、オペレーティングシステムは、単一のTRVを有する単一のモノリシックなコードブロックとして供給することができる。
図12は、コンポーネント内の(1つまたは複数の)障害の(1つまたは複数の)ロケーションを分離するための問合せに関する例示的なコールフロー図を示している。問合せプロセス中に、ネットワークマネージメントエンティティー1204(たとえばH(e)MSなど)は、検知された障害を修復するために実行することができるアクションを判定するためのさらなる情報を収集するために、デバイス1202(たとえばH(e)NBなど)と対話することができる。例示的な一実施形態によれば、デバイス1202は、ネットワークマネージメントエンティティー1204と対話するためにTrEまたはRoTを使用することができる。
ネットワークマネージメントエンティティー1204は、コードイメージ全体のモノリシックなダウンロードを実行することを決定することができる。このダウンロードは、現在のコードイメージまたは更新されたコードイメージのリロードから構成することができる。イメージ全体をネットワークマネージメントエンティティー1204へダウンロードすることができるため、ダウンロードされるイメージ内にTRV(オリジナルまたは更新)を含めることができる。ネットワークマネージメントエンティティー1204は、コードイメージ全体のモノリシックなダウンロードを行うよりも、障害が生じているとして報告されたコンポーネントをダウンロードすることを決定することができる。コンポーネント全体(更新のケースにおいてはTRVを含む)をデバイス1202へダウンロードすることができるため、イメージは、現在のコンポーネントまたは更新されたコンポーネントのリロードとすることができる。更新されたコンポーネントのケースにおいては、クライアントマネージメントエンティティーは、既存のコードイメージを、イメージ全体のインテグリティーおよび構造が損なわれることが決してないように管理することができる。
図12において示されているように、1206においてインテグリティー障害を検知することができる。たとえば、デバイス1202のコンポーネントにおいてインテグリティー障害を検知することができ、本明細書に記載されているように、インテグリティーチェックレポートをネットワークマネージメントエンティティー1204へ送信することができる。1208においては、デバイス1202と、ネットワークマネージメントエンティティー1204との間において接続(たとえば、TR−069接続)を確立することができる。1210においては、ネットワークマネージメントエンティティー1204は、デバイス1202におけるインテグリティー障害に関連付けられているアラームに関連するパラメータを求める要求をデバイス1202へ送信することができる。デバイス1202は、アラームの詳細を含むパラメータ応答を1212においてネットワークマネージメントエンティティー1204へ送信することができる。1214においては、ネットワークマネージメントエンティティー1204は、修復のためにデバイス上のコンポーネントのインテグリティー障害を絞り込むことを決定することができる。インテグリティー障害を絞り込む目的で、ネットワークマネージメントエンティティー1204は、さらにきめ細かい測定を行うために1216においてパラメータ要求をデバイス1202へ送信することができる。1218においては、デバイス1202は、デバイス1202上のコンポーネントの測定を行うことができる。1220においては、ネットワークマネージメントエンティティー1204は、基準上での測定を行うことができる。たとえば、ネットワークマネージメントエンティティー1204は、基準値をオンザフライで生成することができる。なぜなら、コンポーネントの測定は、コンポーネントメーカーによって提供することはできず、デバイス1202によって動的なきめ細かさを伴って行うことができるためである。ネットワークエンティティー1204によって行われた基準上の測定は、たとえば、デバイス1202によって行われたコンポーネントの測定と比較することができる。デバイス1202は、自分がさらにきめ細かいインテグリティー測定を行った、または行うことになる旨をネットワークマネージメントエンティティー1204に示すパラメータ応答を1222において送信することができる。
1224においては、ネットワークマネージメントエンティティーは、(1つまたは複数の)第1のノード(たとえば、(1つまたは複数の)コンポーネント)のインテグリティー測定値を求めるパラメータ要求を送信することができる。1226においては、デバイス1202は、(1つまたは複数の)第1のノードのインテグリティー測定値を示すパラメータ応答をネットワークマネージメントエンティティー1204へ送信することができる。ネットワークマネージメントエンティティー1204は、(1つまたは複数の)次なるノード(たとえば、(1つまたは複数の)コンポーネント)の測定値をデバイス1202に求めるパラメータ要求を1228において送信することができる。たとえばデバイス1202から受信された(1つまたは複数の)第1のノードの測定値に基づいて、(1つまたは複数の)次なるノードの測定値を要求することができる。加えて、(1つまたは複数の)次なるノードは、(1つまたは複数の)第1のノードのうちの部分またはサブコンポーネントとすることができる。1230においては、デバイス1202は、(1つまたは複数の)次なるノードの要求された測定値を含むパラメータ応答をネットワークマネージメントエンティティー1204へ送信することができる。ネットワークマネージメントエンティティー1204からのパラメータ要求、およびデバイス1202からのパラメータ応答は、たとえば、インテグリティー障害が効率的な修復のためにデバイス1202のうちのセクション(たとえば、コンポーネント、機能、またはそのうちの部分)に分離されるまで、1232において示されているように繰り返すことができる。インテグリティー障害が識別されて分離された後に、デバイス1202と、ネットワークマネージメントエンティティー1204との間における接続(たとえば、TR−069接続)を1234において閉じることができる。
ネットワークマネージメントエンティティー1204は、障害を検知した後にさらにいっそう問合せを行うこと、およびモノリシックなブロックまたはコンポーネントの複数の測定を行うことを決定することができる。デバイス1202は、インテグリティー測定を実行すること、および/またはそれらの測定を迅速な参照のためのデータ構造、たとえば、バイナリーツリーにアレンジすることが可能である。ネットワークマネージメントエンティティー1204も、同じことを行うことができる。このような構造は、単一のブロックにおける複数の障害を明らかにすることができ、それによって、ネットワークマネージメントエンティティー1204は、モノリシックなブロックまたはコンポーネントのうちのどの部分がインテグリティーチェックに不合格になったかを迅速に判定することができ、これによって、影響の範囲を絞り込むことができ、ソフトウェアダウンロードトラフィックを潜在的に少なくすることができる。図12および図13において示されているように、修正されたブロックの詳細をチェックして、コンポーネントまたはモノリシックなブロックに関するTRVよりもきめ細かい精度で、悪くなった部分を分離することができる。
コンポーネント障害に関するレンジを絞り込むきめ細かい情報を用いて、ネットワークマネージメントエンティティーは、ブロック全体に関するよりも、コードのうちのそのセグメントに関するダウンロードイメージを作成することができる。たとえば、図13において示されているように、複数の機能をサポートする1つの大きなモノリシックなコンポーネント1302内で障害が生じる場合がある。全体的な測定値1304は、コンポーネント全体1302に関連付けることができる。なぜなら、コンポーネント全体1302が、インテグリティーチェックに不合格になる場合があるためである。デバイスと、ネットワークマネージメントエンティティーとの間における問合せを通じて、1306において、きめ細かい測定値を生成することができる。問合せは、よりきめ細かいインテグリティー測定値によって、大きなモノリシックなコンポーネント1302内の1つのセグメント、たとえばセグメント1308などの障害が見つかるようにすることができる。問合せの後に、インテグリティーチェックの結果として得られる全体的な測定値1310は、たとえば大きなモノリシックなコンポーネント全体1302に関連付けられている測定値1304よりも、セグメント1308の測定値7を含むことができる。セグメント1308において障害が識別された後に、修正パッチをこのセグメントに局在させることができる。修正パッチは、セグメント1308における障害を、インテグリティーチェックに合格した、大きなモノリシックなコンポーネント1302内のその他のセグメントを使用して修正することに関する命令を含むことができる。
生成されるインテグリティー測定値の数は、デバイスのタイプに基づいて制限することができる。ダウンロードされるサブコンポーネントが、現在のコンポーネントのリロードである場合には、そのリロードを実行するためにデバイスによってさらなる情報を使用することはできない。しかし、サブコンポーネントダウンロードが、既存のコンポーネントに対する更新である場合には、そのサブコンポーネントに関する更新されたTRVをダウンロード内に含めることができる。デバイスクライアントおよびネットワークマネージメントエンティティーを同期化して、同じ更新されたコンポーネントイメージを生成することができ、それによって、更新されたTRVは、更新されたコンポーネントイメージのハッシュと一致する。デバイスマネージメントクライアントは、既存のコードイメージを、イメージ全体のインテグリティーが損なわれることが決してないように管理することができる。
問合せプロセスによって、報告された障害が生じている機能のリストのネットワークのバージョンが修正される結果になる場合があり、その修正は、デバイス上のネットワークアクセス制御を修正するためにネットワーク妥当性確認、認証、および/またはゲートウェイエンティティーにフィードバックすることができる。
問合せプロセスは、反復測定アプローチを使用することによってコンポーネント障害を分離することができ、反復測定アプローチによって、ネットワークマネージメントエンティティーおよびデバイスは、測定値を漸進的に生成して、障害を示しているサブセクション上のイメージ上で視野を絞り込むことができる。この方法は、所与のレゾリューションのために使用される測定値の数を減らすことができ、それによって、メモリ上の制約があるデバイスに関して測定とレゾリューションとの間におけるトレードオフが可能になる。たとえば、この問合せプロセスの例示的な一実施形態を図14において示すことができる。図14において示されているように、コンポーネント1402において障害を見つけることができ、全体的な測定値1404をコンポーネント全体1402に関連付けることができる。デバイスおよびネットワークは、コンポーネント1402において障害が見つかった後に問合せを実行することができ、その問合せに基づいて、デバイスは、コンポーネント1402上で測定の第1の反復を実行することができる。たとえば、測定の第1の反復において、デバイスは、コンポーネント1402のサブセクション1406およびサブセクション1408上で独立した測定を実行することができる。結果として、デバイスは、サブセクション1406がインテグリティーチェックに合格し、その一方でサブセクション1408がインテグリティー障害の原因を含んでいると判定することができる。これは、サブセクション1406に関連付けられている測定値1と、サブセクション1408に関連付けられている測定値2とによって示すことができる。サブセクション1408が依然としてインテグリティーチェックに不合格であるため、全体的な測定値1404は、コンポーネント1402がインテグリティー障害を含んでいることを依然として示すことができる。
インテグリティー障害がサブセクション1408に絞り込まれる一方で、デバイスおよびネットワークは、修復のためにさらにきめ細かい測定値を漸進的に生成するためのさらなる問合せ手続を実行することができる。問合せの結果として、デバイスは、コンポーネント1402上で測定の第2の反復を実行することができる。図14において示されているように、測定の第2の反復は、サブセクション1408上で実行することができる。なぜなら、このサブセクション1408が、インテグリティー障害の原因であると判定されたサブセクションであったためである。デバイスは、第2の反復においてサブセクション1410および1412上で独立した測定を実行することができ、それらは、それぞれ測定値3および測定値4を生成することができる。サブセクション1410および1412は、サブセクション1408のサブセクションであると言える。測定値3は、サブセクション1408のサブセクション1410がインテグリティーチェックに合格であることを示すことができる。しかし測定値4は、サブセクション1412がインテグリティーチェックに不合格であり、コンポーネント1402のインテグリティーチェック障害の原因を含んでいることを示すことができる。
インテグリティー障害がサブセクション1412に絞り込まれる一方で、デバイスおよびネットワークは、修復のためにさらにきめ細かい測定値を漸進的に生成するためのさらなる問合せ手続を実行することができる。たとえば、デバイスは、測定の第3の反復を実行することができる。測定の第3の反復は、サブセクション1412上で実行することができる。なぜなら、サブセクション1412が、測定の第2の反復の後にインテグリティー障害の原因であると判定されたサブセクションであったためである。図14において示されているように、デバイスは、サブセクション1414および1416上で独立した測定を実行することができる。デバイスは、サブセクション1414がインテグリティー障害の原因を含んでいると判定することができる。これは、たとえば測定値5によって示すことができる。測定の第3の反復の後に、サブセクション1414に関連付けられている機能を、インテグリティー障害の原因を含むコンポーネント1402のきめ細かいサブセクションに対応するものとして、ネットワークへ送信することができる。問合せの結果として、ネットワークは、サブセクション1414に局在させることができる修正パッチ(たとえば、サブコンポーネントの置換または修正)を判定して、その修正パッチをサブセクション1414の置換または修正のためにデバイスへ送信することができる。図14は、ネットワークとデバイスとの間における問合せの結果としてデバイスにおいて実行される測定の3回の反復を示しているが、コンポーネントのうちでインテグリティー障害を含む部分を分離するために、測定の任意の回数の反復を実行することができる。例示的な一実施形態においては、反復の回数は、サービスプロバイダに基づく。別の例示的な実施形態においては、デバイスマネージメントサーバは、デバイス識別情報およびソフトウェアリリース番号を含むさまざまな基準に対応する障害のデータベースを保持する。この障害情報は、たとえば、デバイスマネージメントサーバが問合せ戦略を査定することを可能にすることができる。
ツリーの完全な生成などのその他のアルゴリズムと比べてこの漸進的なアプローチの価値を判定する際に、ネットワーク通信のコスト間の比較、測定値計算、および測定値計算のための値のローディングを重み付けすることができる。
この漸進的な方法においては、障害のフィールドが絞り込まれるにつれて測定を行うことができる。コード/データを繰り返し測定することができる。再測定される可能性があるコード/データの量を少なくするために、ハイブリッドなアプローチを使用することができ、このアプローチは、たとえば、はじめにイメージを何らかの最適な数のサブセクションへと分割することができる。何らかのファクタによってイメージを分割することによって、障害の生じている(1つまたは複数の)セクションを漸進的にさらにレゾルブすることができる。そのファクタは、最小の帯域幅および最小の消費電力を使用してネットワーク上での障害の分離および判定の度合いを最適化するために、反復ごとに、ならびにその他の時間遅延およびパフォーマンス上の考慮事項に基づいて決定することができる。障害分離プロセスを促進するために、ネットワークは、所与のコンポーネント障害に関するハッシュツリーなどのデータ構造での予測されたハッシュのセットを事前に生成して、サブTRV測定値(sub−TRV measurement)のこのツリーをデバイスへ送信することができる。これは、デバイスが、この漸進的なアプローチにおける比較をツリーの最も高いレゾリューションまで行うことを可能にすることができる。ネットワークは、(たとえば、修正する必要があるデバイスの数に基づいて)修復手続を最適化するために、より多くのレゾリューションが必要とされているかどうかを判定することができる。より多くのレゾリューションが必要とされている場合には、より正確なロケーションから開始する新たなツリーを生成して、ネットワークによって送信することができ、または、対話式に比較を行うことができる。
ソフトウェアまたはデータの更新のケースにおいては、ソフトウェアマネージメントサーバは、更新を実行するために、ファイル内の単純なバイナリー差分上でコード/データの更新を実行することができる。デバイスマネージメントクライアントは、バイナリー更新を受信し、完全なコードイメージへの修正を実行して、そのインテグリティーを確実にすることができる。バイナリー差分の同じ原理を、ソフトウェア更新中のトラフィックの量を少なくするためのソフトウェアマネージメントエンティティー用の問合せ技術を含むように拡張することができる。すなわち、ソフトウェア更新手続は、バイナリーツリー検索を含めて、本明細書に記載されている同じ修復技術のうちの多くを包含することができる。
図15は、障害アラームおよびモノリシックなコードの置換に関連する例示的なコールフロー図を示している。このコールフローについては、H(e)NBを使用して説明するが、その他のネットワークデバイスを使用することもできる。コールフローシーケンスは、本明細書に記載されているステップのうちの1つまたは複数を含むことができる。たとえば、図15において示されているように、H(e)NB1502は、1512においてセキュアブートシーケンスを実行することができる。インテグリティーチェックフェーズ1514中に、H(e)NB1502は、オペレーションのために使用されるコード内でインテグリティー障害を見つけ出すことができ、したがって、H(e)NBの1502 TrEは、SeGW1504の認証のための秘密キーを利用可能にすることはできない。しかしTrEは、H(e)NB1502がH(e)MS1506のオペレーションに関して合格であるということを認識することができる。たとえば、H(e)NB1502は、アラームをH(e)MS1506へ送信可能とすることができ、および/またはH(e)NB1502にとって可能である手続に関するH(e)MS1506の認証のための秘密キーを利用可能にすることができる。H(e)MS1506は、1516においてH(e)NB1502とのIP接続(たとえば、SSL/TLSイニシエーション)を確立することができる。1518においては、H(e)NB1502は、H(e)MS1506にインテグリティー障害を警告することができる。たとえば、H(e)MS1506は、障害アラームをH(e)NB1502から受信すること、および1520において(たとえば、リロードまたは更新を求める)コード修復要求をソフトウェア修復エンティティー1510へ送信することが可能である。ソフトウェア修復エンティティー1510は、1522においてソフトウェアビルドを実行することができる。1524においては、ソフトウェア修復エンティティー1510は、モノリシックなコンポーネントの代替品をH(e)MS1506に提供することができる。たとえば、ソフトウェア修復エンティティー1510は、モノリシックな修復イメージをH(e)MS1506に提供することができる。H(e)MS1506は、H(e)NB1502とのセキュアな接続を確立することができる。たとえば、H(e)MS1506は、1526においてH(e)NB1502との(たとえば、SSL/TLSイニシエーションを介した)セキュアなIP接続を確立することができる。H(e)NB1502およびH(e)MS1506は、H(e)NB1502を修正するためのソフトウェア/ファームウェアダウンロードを可能にするように認証を行うことができる。1528においては、H(e)MS1506は、H(e)NB1502のソフトウェア/ファームウェアを更新することができ、H(e)NB1502をリブートすることができる。H(e)NB1502は、1530において、リブートすること、および/またはインテグリティーチェックを再開することが可能である。
図16は、リモートソフトウェア障害/修復に関連する例示的なコールフロー図を示しており、ここでは、H(e)NB1602は、H(e)MS1606に障害を通知する。コールフローシーケンスは、本明細書に記載されているステップのうちの1つまたは複数を含むことができる。加えて、このコールフローについては、H(e)NBを使用して説明するが、その他のネットワークデバイスを使用することもできる。図16において示されているように、H(e)NB1602は、1612においてセキュアブートシーケンスを実行することができる。1614におけるインテグリティーチェックフェーズ中に、H(e)NBの1602 TrEは、通常のオペレーションのためのコード内で障害を見つけ出すことができ、したがって、H(e)NBの1602 TrEは、SeGW1604の認証のための秘密キーを利用可能にすることはできない。しかしTrEは、H(e)NB1602がH(e)MS1606にセキュアに接続可能とすることができることを認識することができ、したがってTrEは、H(e)NB1602にとって可能である手続に関するH(e)MS1606の認証のための秘密キーを利用可能にすることができる。H(e)NB1602は、SeGW1604に対する認証を試みない場合がある(またはいくつかの障害においては、試みることができない)。1616においては、H(e)NB1602は、H(e)MS1606とのIP接続(たとえば、セキュアなSSL/TLSセッション)を確立することができる。1618においては、H(e)NB1602は、H(e)MS1606にH(e)NB1602のインテグリティーチェックステータス(たとえば、インテグリティー障害)を警告することができる。H(e)MS1606は、H(e)NB1602のインテグリティー情報の真正性を、たとえば認証によって、またはTrEにより署名されたインテグリティーステータスペイロード情報の署名検証によって検証することができる。H(e)NB1602においてインテグリティー障害があるということをインテグリティーチェックステータスが示している場合には、H(e)MS1606は、1620において、示されている障害のためのソフトウェア修正を決定することができる。このソフトウェア修正は、インテグリティー障害のさらなる問合せを含むことができる。たとえば、1622においては、H(e)MS1606は、H(e)NB1602の診断および/または問合せを行うことができる。H(e)MS1606は、障害の原因(たとえば、ロケーション)を詳細に判定することができ、1624においては、H(e)MS1606は、リロードまたは更新のいずれかのためのものとすることができるコード修復要求をソフトウェア修復エンティティー1610へ送信することができる。ソフトウェア修復エンティティー1610は、1626においてソフトウェアビルドを実行すること、およびソフトウェア修正情報をH(e)MS1606へ送信することが可能である。たとえば、ソフトウェア修正情報は、修復イメージを含むことができる。H(e)MS1606は、1630においてH(e)NB1602との(たとえば、IP接続を介した)セキュアな接続を確立することができる。H(e)NB1602およびH(e)MS1606は、H(e)NB1602を修正するためのソフトウェア/ファームウェアダウンロードを可能にするように認証を行うことができる。1632においては、H(e)MS1606は、H(e)NB1602のソフトウェア/ファームウェアをダウンロードすること、および/またはH(e)NB1602を再始動することが可能である。1634においては、H(e)NB1602は、セキュアブートシーケンスを実行すること、および/またはインテグリティーチェックプロセスを再開することが可能である。1636におけるインテグリティーチェックフェーズ中に、H(e)NBの1602 TrEは、SeGW1604のオペレーションに関してインテグリティーチェックが合格であることを認識することができ、SeGW1604の認証のために使用される秘密キーを利用可能にすることができる。H(e)NB1602およびSeGW1604は、1638において互いに認証を行うことができ、SeGW1604は、認証が成功したことを1640においてH(e)NB1602に示すことができる。
図17は、SeGWの認証の試みを伴う、リモートソフトウェア障害/修復に関連する例示的なコールフロー図を示している。コールフローシーケンスは、本明細書に記載されているステップのうちの1つまたは複数を含むことができる。加えて、このコールフローについては、H(e)NBを使用して説明するが、その他のネットワークデバイスを使用することもできる。図17において示されているように、H(e)NB1702は、1712においてセキュアブートシーケンスを実行することができる。1714におけるインテグリティーチェックフェーズ中に、H(e)NB1702は、SeGW1704のオペレーションのために使用されるコード内でインテグリティー障害を見つけ出すことができ、したがって、H(e)NBの1702 TrEは、SeGW1704の認証のための秘密キーを利用可能にすることはできない。しかしTrEは、H(e)NB1702がH(e)MS1706にセキュアに接続可能とすることができることを認識することができ、H(e)NB1702にとって可能である手続に関するH(e)MS1706の認証のための(1つまたは複数の)秘密キーを利用可能にすることができる。H(e)NB1702は、たとえばIKEv2プロトコルを使用することなどによって、1716においてSeGW1704に対して認証を行うことを試みることができるが、(たとえば、秘密認証キーが利用可能ではないために)失敗する場合がある。1718においては、SeGW1704に対する認証が失敗した旨の指示をH(e)NB1702に提供することができる。H(e)NB1702は、1720においてH(e)MS1706との(たとえば、SSL/TLSイニシエーションを介した)セキュアなIP接続を確立することができる。たとえば、そのセキュアなIP接続は、H(e)NB1702と、SeGW1704との間における失敗した認証の試みに基づいて確立することができる。1722においては、H(e)NB1702は、H(e)MS1706にH(e)NB1702のインテグリティーチェックステータス(たとえば、インテグリティーの合格または不合格)を警告することができる。H(e)MS1706は、H(e)NB1702のインテグリティー情報の真正性を、認証によって、またはTrEにより署名されたインテグリティーステータスペイロード情報の署名検証によって検証することができる。H(e)NB1702においてコンポーネントのインテグリティー障害があるということをインテグリティーチェックステータスが示している場合には、H(e)MS1706は、1724において、示されている障害のためのソフトウェア修正を決定することができる。このソフトウェア修正は、インテグリティー障害のさらなる問合せを含むことができる。たとえば、H(e)MS1706は、H(e)NB1702の診断および/または問合せを1726において行うことができる。H(e)MS1706は、障害の原因を詳細に判定すること、および1728において(たとえば、リロードまたは更新のための)コード修復要求をソフトウェア修復エンティティー1710へ送信することが可能である。ソフトウェア修復エンティティー1710は、1730においてソフトウェアビルドを実行すること、および1732においてソフトウェア修正(たとえば、修復イメージ)をH(e)MS1706に提供することが可能である。1734においては、H(e)MS1706は、H(e)NB1702とのセキュアなIP接続(たとえば、SSL/TLSイニシエーション)を確立することができる。H(e)NB1702およびH(e)MS1706は、H(e)NB1702を修正するためのソフトウェア/ファームウェアダウンロードを可能にするように認証を行うことができる。H(e)MS1706は、1736においてH(e)NB1702のソフトウェア/ファームウェアをダウンロードすること、およびH(e)NB1702を再始動することが可能である。H(e)NB1702は、1738において、セキュアブートシーケンスを実行すること、および/またはインテグリティーチェックを再開することが可能である。1740におけるインテグリティーチェックフェーズ中に、H(e)NB1702は、インテグリティーチェックが合格であることを認識すること、およびSeGW1704の認証のための秘密キーを利用可能にすることができる。H(e)NB1702およびSeGW1704は、1742において互いに認証を行うことができ、SeGW1704は、認証が成功したことを1744において示すことができる。
図18Aは、ネットワークがSeGWを通じた認証を許可しないことが可能である、リモートソフトウェア障害/修復に関連する例示的なコールフロー図を示している。コールフローシーケンスは、本明細書に記載されているステップのうちの1つまたは複数を含むことができる。加えて、このコールフローについては、H(e)NBを使用して説明するが、その他のネットワークデバイスを使用することもできる。図18Aにおいて示されているように、H(e)NB1802は、1812においてセキュアブートシーケンスを実行することができる。1814におけるインテグリティーチェックフェーズ中に、H(e)NB1802は、オペレーションのために使用されるコード内で障害を見つけ出すことができ、したがって、H(e)NBの1802 TrEは、SeGW1804の認証のための秘密キーを利用可能にすることはできない。しかしTrEは、H(e)NB1802がH(e)MS1806にセキュアに接続可能とすることができることを認識することができ、したがって、H(e)NB1802にとって可能である手続に関するH(e)MS1806の認証のための(1つまたは複数の)秘密キーを利用可能にする。1816においては、H(e)NB1802は、(たとえば、IKEv2プロトコルを使用して)SeGW1804に対して認証を行うことを試みることができるが、(たとえば、秘密キーが利用不能であるために)失敗している。H(e)NB1802は、認証の試み中にH(e)NB1802のインテグリティーに関するTrEによって署名された情報を提供することができる。1818においては、SeGW1804は、インテグリティー情報(たとえば、障害レポート)をネットワーク妥当性確認エンティティー1808へ転送することができる。ネットワーク妥当性確認エンティティー1808は、自分が受信する情報に基づいて、SeGW1804を通じた一部のH(e)NB1802トラフィックを許可しないことを決定すること、およびH(e)NB1802トラフィックのうちの一部またはすべてがH(e)MS1806に限定されることを示すきめ細かいアクセス決定を1820において送信することが可能である。1822aにおいては、SeGW1804は、認証失敗の指示を送信することができる。1824においては、ネットワーク妥当性確認エンティティー1808は、修復の目的でH(e)NB1802のインテグリティー情報をH(e)MS1806へ送信することができる。H(e)MS1806は、1826においてH(e)NB1802との(たとえば、SSL/TLSイニシエーションを介した)セキュアなIP接続を確立することができる。1828においては、H(e)MS1806は、たとえば、認証失敗に基づいて、ソフトウェア修正を実行することを決定することができる。H(e)NB1802およびH(e)MS1806は、1830においてH(e)MS1806による診断および問合せを可能にするように認証を行うことができる。H(e)MS1806は、障害の原因を詳細に判定すること、および1832において(たとえば、リロードまたは更新のための)コード修復要求をソフトウェア修復エンティティー1810へ送信することが可能である。ソフトウェア修復エンティティー1810は、H(e)NB1802のための代替ソフトウェアコンポーネント(たとえば、またはその一部)をビルドするために、1834においてソフトウェアビルドを実行することができる。1836においては、ソフトウェア修復エンティティー1810は、ソフトウェア修正情報(たとえば、修復イメージ)をH(e)MS1806に提供することができる。H(e)MS1806は、1838においてH(e)NB1802との(たとえば、SSL/TLSイニシエーションを介した)セキュアなIP接続を確立することができる。H(e)NB1802およびH(e)MS1806は、H(e)NB1802を修正するためのソフトウェア/ファームウェアダウンロードを可能にするように認証を行うことができる。H(e)MS1806は、1840においてH(e)NB1802のソフトウェア/ファームウェアをダウンロードすることができる。1842においては、H(e)NB1802は、リブートすること、および/またはダウンロードされたコードをロードして実行することが可能である。
図18Bは、即時の限定されたアクセスおよび洗練されたアクセスの制御を伴う、リモートソフトウェア障害/修復に関連する例示的なコールフロー図を示している。このコールフローについては、H(e)NBを使用して説明するが、その他のネットワークデバイスを使用することもできる。図18Bのコールフローシーケンスは、図18Aにおいて示されているコールフローと同じ、または同様である多くのステップを含むことができる。しかし、図18Bにおいて示されているように、SeGW1804に対するH(e)NB1802の認証は、成功することができるが、SeGW1804は、H(e)NB1802に対するアクセスを限定することができる。たとえば、1814におけるインテグリティーチェックフェーズ中に、H(e)NB1802は、オペレーションのために使用されるコード内で障害を見つけ出すことができ、したがって、H(e)NBの1802 TrEは、SeGW1804の認証のための秘密キーを利用可能にすることはできない。しかしTrEは、H(e)NB1802がH(e)MS1806にセキュアに接続可能とすることができることを認識することができ、したがって、H(e)NB1802にとって可能である手続に関するH(e)MS1806の認証のための(1つまたは複数の)秘密キーを利用可能にする。1816においては、H(e)NB1802は、(たとえば、IKEv2プロトコルを使用して)SeGW1804に対して認証を行うことを試みることができる。H(e)NB1802は、認証の試み中にH(e)NB1802のインテグリティーに関するTrEによって署名された情報を提供することができる。1818においては、SeGW1804は、インテグリティー情報をネットワーク妥当性確認エンティティー1808へ転送することができる。ネットワーク妥当性確認エンティティー1808は、受信された情報に基づいて、H(e)NB1802に対する認証を決定することができ、これをSeGW1804へ送信することができる。SeGW1804は、ネットワーク妥当性確認エンティティー1808からの情報に基づいて、H(e)NB1802を認証することができるが、H(e)NB1802のアクセスを限定することができる。1822bにおいては、SeGW1804は、認証は成功したが、SeGW1804はアクセスを限定している旨の指示をH(e)NB1802へ送信することができる。図18Bのプロトコルフローにおいて示されているステップのうちの残りは、図18Aのプロトコルフローにおいて示されているステップと同じ、または同様とすることができる。
図19は、SeGWアクセスを伴うH(e)NBソフトウェアコンポーネントの修復に関連する例示的なコールフロー図を示している。コールフローシーケンスは、本明細書に記載されているステップのうちの1つまたは複数を含むことができる。加えて、このコールフローについては、H(e)NBを使用して説明するが、その他のネットワークデバイスを使用することもできる。図19において示されているように、H(e)NB1902は、1912においてセキュアブートシーケンスを実行することができる。1914におけるインテグリティーチェックフェーズ中に、H(e)NB1902は、デバイスコード内の障害を見つけ出すことはできないが、マップ内の障害、欠落しているコンポーネント、または構成の欠如を見つけ出すことができる。H(e)NBの1902 TrEは、SeGW1904の認証のための秘密キーを利用可能にすることができる。たとえば、H(e)NB1902は、SeGW1904に対する秘密キーを含むステータスレポートを(たとえば、IKEを使用して)1916において送信することができる。SeGW1904は、インテグリティー情報を1918においてネットワーク妥当性確認エンティティー1908へ転送することができる。ネットワーク妥当性確認エンティティー1908は、受信された情報に基づいて、H(e)NB1902に対する認証を決定することができ、これをSeGW1904へ送信することができる。たとえば、ネットワーク妥当性確認エンティティー1908は、オペレータポリシーに従ったきめ細かいアクセス決定を1920においてSeGW1904へ送信することができる。SeGW1904は、ネットワーク妥当性確認情報に基づいて、H(e)NB1902を認証すること、および/またはオペレータポリシーに従ったアクセス許可を設定することが可能である。1922においては、SeGW1904は、認証の成功の指示をH(e)NB1902へ送信することができる。ネットワーク妥当性確認エンティティー1908は、1924においてH(e)NBのインテグリティー情報をH(e)MS1906へ送信することができる。たとえば、インテグリティー情報を、再構成の目的で送信することができる。H(e)MS1906は、障害を修復するために使用することができる修復情報(たとえば、ソフトウェア/パラメータ)を1926において判定することができ、(たとえば、リロードまたは更新のための)修復要求を1928においてソフトウェア修復エンティティー1910へ送信することができる。ソフトウェア修復エンティティー1910は、H(e)NB1802のための代替ソフトウェアコンポーネント(たとえば、またはその一部)をビルドするために、1930においてソフトウェアビルドを実行することができる。1932においては、ソフトウェア修復エンティティー1910は、修復情報(たとえば、修復イメージまたはソフトウェア/構成更新)をH(e)MS1906に提供することができる。H(e)MS1906は、1934において修復情報をSeGW1904へ転送することができる。SeGW1904およびH(e)NB1902は、1936において(たとえば、IKEv2またはIPsecを使用して)セキュアなIP接続を認証して確立することができる。1938においては、SeGW1904は、修復情報(たとえば、修復イメージまたはソフトウェア/ファームウェアの更新)をH(e)NB1902へダウンロードすることができる。たとえば、SeGW1904は、障害の生じているクリティカルでないソフトウェア/パラメータの更新(たとえば、IKEおよび/またはIPsecの更新)を送信することができる。
デバイスは、レガシーの能力および進化した能力の両方を有する場合がある。レガシー能力のためのネットワークサービスは、一般に利用可能であると言える。進化した能力のためのネットワークサービスは、まばらであり、および/または完全にはサポートされていないと言える。展開の問題を緩和する目的で、オペレータは、進化した能力に徐々に慣れるためにレガシーの能力を活用することができる。そのような活用は、本明細書に記載されているように用いることができる。たとえば、あるデバイスを、あるロケーションにおいてレガシーデバイスとしてネットワークに接続することができる。ネットワークは、そのデバイスを認証することと、自分のサブスクリプションにおいて、そのデバイスが、進化した能力、および/または進化した能力をセキュアにサポートする能力を有する可能性があることを認識することとが可能である。そのロケーションに関するネットワークが、進化した能力をサポートしている場合には、ネットワークマネージメントエンティティーは、そのデバイスのアクセスポイントに、更新サーバへのきめ細かいアクセスを提供することができる。そのデバイスは、レガシーアクセスポイントを通じて更新サーバにアクセスすることができる。いくつかの実施態様においては、デバイスのサブスクリプションは、レガシーサービスではなく進化機能へのアクセスを制限することができ、したがって、アクセスポイントは、レガシーネットワーク全般ではなく更新サーバへのデバイスのアクセスを制限することができる。更新サーバおよびデバイスは、互いに認証を行うことができる。更新サーバは、デバイスの進化した能力の妥当性を(たとえば、認証を通じて黙示的に、もしくは明示的に)確認すること、ならびに/または、デバイスが新たなタイプのデバイスとして直接再接続することを可能にするために、アクセス証明書、構成情報、アクセスポイントアドレス、および/もしくはコードをデバイスに供給することが可能である。デバイスは、ネットワークアクセス認証のために、共有されたまたは非対称のキーペアを生成する能力を有することができる。ネットワークは、新たなデバイス証明書によってデバイスサブスクリプションデータベースを更新することができる。デバイスは、進化したネットワークのロケーションのためのアクセス証明書を、保護された領域内に組み込む能力を有することができる。オンライン証明書生成は、進化したネットワークへの事前に妥当性を確認されたその後の接続を可能にすることができる。ネットワークは、進化したネットワーク(進化した能力をサポートするネットワーク)へのアクセスポイントに、特定の証明書のデバイスが、進化したネットワークに接続することができるということを知らせることができる。デバイスは、更新された証明書を使用して、進化したネットワークにアクセスすることができる。進化したネットワークのエンティティーは、そのデバイスを、進化したデバイスとして認証することができる。
マネージメント認証のための手続には、少なくとも2つのステージが存在することができる。一方は構成のためのものであり、他方は修復のためのものであることが可能である。構成のケースにおいては、ネットワークマネージメントエンティティーは、中継ノードの能力を、オペレータのコアネットワークに対するその後の認証手続のために、オペレータ証明書を確信を持ってインストールするデバイスとして認証することができる。その中継器は、プラットフォーム認証を使用したプラットフォームの自律的な妥当性確認の手段を通じて、ネットワークエンティティーに暗示的な証明を提供することができる。マネージメントエンティティーは、デバイスを認証すること、および/またはRNの製造業者の証明書の妥当性を確認することによって、RNのインテグリティーが危うくされていないことを知ることができる(なぜなら、自律的な妥当性確認は、たとえばデバイスのインテグリティーに関する内部の検証が合格である場合には、秘密認証キーをリリースすることができるためである)。
修復のケースにおいては、RNは、何らかのクリティカルでない障害によって完全なデバイスインテグリティーチェックが不合格になったことに起因して、マネージメントエンティティーとともにリモート修正手続を実行することができる。このケースにおいては、RNのマネージメント能力が損なわれていない場合には、RNは、完全なデバイスインテグリティー証明書ではなく、マネージメント能力証明書を認証の目的でマネージメントエンティティーへ送信することができる。ネットワークマネージメントエンティティーは、デバイスを認証すること、および証明書を検証することが可能である。合格すると、ネットワークマネージメントエンティティーは、中継器の能力をブートストラップするためのリモート手続を実行することができる。
その手続は、最初の限定された範囲のケースにおいてRNの能力をブートストラップするために使用することができる。このケースにおいては、第1の証明書は、マネージメントエンティティーとともに基本的なオペレーションを実行する能力を表すことができる。第2の証明書は、マネージメントエンティティーとともにさらに広いオペレーションを実行する能力を表すことができる。このケースにおいては、中継器は、増大された機能の範囲を伴うインテグリティー障害を検知することができない。インテグリティーチェックの範囲は、強化された機能に対応するためにさらなる更新されたポリシーを提供することによっても増大させることができる。この方法においては、デバイスの能力は、インテグリティーチェックの程度とともに増大することができる。
この技術は、セキュリティーゲートウェイ認証全般に適用することができる。デバイスの限定された範囲を表す証明書は、コアネットワークに対するゲートウェイ認証のケースにおいて使用することができ、それによって、そのネットワークは、認証中に、その認証の特権を判定することができる。ゲートウェイ(たとえば、HeNB認証におけるSeGW、またはRN認証に関するDeNB)は、デバイスを認証すること、および証明書を検証することが可能である。証明書上の情報および特定のデバイスIDの認証の成功に基づいて、ゲートウェイは、修復または登録の目的でネットワークマネージメントエンティティーに対するアクセスを制限することができる。中継器が成功裏に構成、更新、および/または修復されると、認証キーを、認証ベースの機能強化のために利用可能とすることができる。
図20は、能力の中継ノードブートストラッピングに関連する例示的なコールフロー図を示している。コールフローシーケンスは、本明細書に記載されているステップのうちの1つまたは複数を含むことができる。たとえば、図20において示されているように、RN(Relay Node)2002は、2014においてセキュアブートシーケンスを実行することができる。2016においては、RN2002は、セキュアな環境を確立すること、および/または自律的な妥当性確認を実行することが可能である。自律的な妥当性確認の最中に、RN2002は、障害を見つけ出すことができない。2018においては、RN2002は、たとえばMME/HSS2012などにおいて、eNB2004を通じてUEとしてネットワークに接続することができる。MME2012は、2020において登録サーバ2008への限定されたアクセスをRN2002に割り当てることができる。図20において示されているように、その限定されたアクセスは、eNB2004を通じて割り当てることができる。RN2002および登録サーバ2008は、互いに認証を行うことができる。2022においては、RN2002は、登録要求を登録サーバ2008へ送信することができる。2024においては、登録サーバは、RN2002に対する妥当性確認、構成、および/または証明書の発行を行うことができる。登録サーバ2008は、RN2002のセキュアな環境によるRNの2002秘密登録サーバ認証キーの使用のリリースを通じて黙示的にRN2002の妥当性を確認することができ、または登録サーバ2008は、RNレポートの問合せによってRN2002の妥当性を確認することができる。登録サーバ2008は、妥当性を確認されたRN2002をDeNB2006の接続用に構成することができ、証明書を発行することができる。登録サーバ2008は、デバイス上のRNポリシーを更新して、その後のリブート上の登録ステップを迂回すること、および登録情報を自律的な妥当性確認プロセス内に含めること(たとえば、登録情報をカバーするTRVを加えること)が可能である。新たな秘密キーを、RN2002上にインストールすること、またはこのステージにおいてアクティブ化することが可能である。RN2002は、キー生成能力を有することができ、そのケースにおいては、キーペアをRN2002上で生成することができる。RN2002は、自分のセキュアな環境内に秘密キーをインストールすることができ、このキーのリリースを登録構成およびさらに低いレベルのセキュアブートステージに結び付けることができる。2026においては、登録サーバ2008は、登録が完了したことを中継ノード2002に示すことができる。2028においては、RN2002は、DeNB2006を通じてRNとしてネットワークに接続することができる。MME2012は、DeNB2006を通じた構成サーバ2010への限定されたアクセスを2030においてRN2002に割り当てることができる。2032においては、RN2002は、RN構成要求を構成サーバ2010へ送信することができる。構成サーバ2010は、2034においてRN2002に対する妥当性確認、構成、および/または証明書の発行を行うことができる。たとえば、構成サーバ2010は、妥当性を確認されたRN2002をオペレーション用に構成することができ、証明書を発行することができる。構成サーバ2010は、デバイス上のRNポリシーを更新して、その後のリブート上の構成ステップを迂回すること、および構成情報を自律的な妥当性確認プロセス内に含めること(たとえば、構成情報をカバーするTRVを加えること)が可能である。DeNB2006の認証のための新たな秘密キーを、このステージにおいてインストールまたはアクティブ化することができる。構成サーバ2010は、構成が完了したことを2036においてRN2002に示すことができる。2038においては、RN2002は、DeNB2006とのS1セットアップを開始することができる。2040においては、RN2002は、DeNB2006とのX2セットアップを開始することができる。RN2002は、2042において中継ノードとして機能することができる。
2044においては、RN2002上でリセットを行うことができる。このリセットは、たとえば、ネットワーク、デバイス、または停電によって開始されることがある。2046においては、RN2002は、セキュアブートシーケンスを実行することができる。2048におけるセキュアな環境の確立および/または自律的な妥当性確認の最中に、RN2002は、障害を見つけ出すことができない。登録サーバ2008の情報および/または構成サーバ2010の情報を2048において自律的な妥当性確認プロセス内に含めることができるため、RN2002は、サーバに関与する必要なく、S1インターフェースおよびX2インターフェースをそれぞれ2050および2052においてセットアップすることへ進むことができる。RN2002は、2054においてRNとして機能することもできる。登録サーバの情報または構成サーバの情報上で障害が生じている場合には、ポリシーは、再構成が行われるまで、秘密認証キーのリリース、またはその後のネットワークプロセスの実行を許可すること、または許可しないことが可能である。
図21は、認証されたマネージメント能力を用いた中継ノード修復に関連する例示的なコールフロー図を示している。コールフローシーケンスは、本明細書に記載されているステップのうちの1つまたは複数を含むことができる。たとえば、図21において示されているように、RN(Relay Node)2102は、2114においてセキュアブートシーケンスを実行することができる。2116においては、RN2102は、セキュアな環境を確立すること、および/または自律的な妥当性確認を実行することが可能である。2116における自律的な妥当性確認の最中に、RN2102は、デバイスのクリティカルでないコンポーネントに対する障害を見つけ出すことができる。2118においては、RN2102は、eNB2104を通じてUEとしてネットワーク(たとえば、MME/HSS2112)に接続することができる。2120においては、MME2112は、登録サーバ2106および/または修復サーバ2110への限定されたアクセスをRN2102に割り当てることができる。MME2112は、たとえばeNB2104を通じて、限定されたアクセスを割り当てることができる。RN2102および修復サーバ2110は、互いに認証を行うことができる。2122においては、RN2102は、アラーム(たとえば、修復要求)を修復サーバ2110へ送信することができる。修復サーバ2110は、2124においてRN2102のセキュアな環境によるRNの2102秘密修復サーバ認証キーの使用のリリースを通じて黙示的にRNマネージメント能力の妥当性を確認することができ、および/または、修復サーバ2110は、(1つまたは複数の)RN2102インテグリティーステータスレポートの問合せによってRN2102の妥当性を確認することができる。2126においては、RN2102および修復サーバ2110は、RN2102の問合せを(任意選択で)実行することができる。修復サーバ2110は、2128においてRN2102を修復すること(たとえば、再構成すること、修正すること、または再プログラムすること)、および障害を修繕するために修復情報を2130においてRN2102へ送信することが可能である。
修復サーバ2110は、2132においてセキュアにリブートするようにRN2102にリモートから命令することができ、または、RN2102が電源投入ステージの第1のフェーズを既に実行しており、デバイスインテグリティーチェックが、たとえば単なるマネージメント認証ではなく、今回はプラットフォーム認証に関して合格しているため、RN2102は、RN2102電源投入シーケンスにおける次なるステップへ直接進むことができる。たとえば、2134においては、RN2102は、セキュアな環境を確立すること、および/または自律的な妥当性確認を実行することが可能である。2136においては、RN2102は、eNB2104を通じてUEとしてネットワーク(たとえば、MME/HSS2112)に接続することができる。2138においては、MME2112は、登録サーバ2106および/または修復サーバ2110への限定されたアクセスをRN2102に割り当てることができる。RN2102は、2140において登録サーバ2106に登録要求を行うことができる。2142においては、登録サーバ2106は、RN2102に対する妥当性確認、構成、および/または証明書の発行を行うことができる。登録サーバ2106は、登録が完了したことを2144においてRN2102に示すことができる。
インテグリティーチェック、報告、および修復用として本明細書に記載されている手続、システム、および手段は、本明細書に記載されているようなソフトウェア障害、TR−069、ソフトウェア修復、H(e)NBなどに限定されるものではないと言える。さらに、記載されているアクションは、例示的であることを意図されている。その他のアクションを使用することもでき、使用しない場合には省略することもでき、および/またはアクションを追加することもできるということを理解されたい。
いくつかの実施態様においては、障害は、ソフトウェアではなく、構成データまたはデバイス上のその他の何らかの測定可能なコンポーネントである場合がある。そのような一実施態様においては、マネージメントエンティティーは、更新をソフトウェア修復エンティティーから受信することはできず、たとえばネットワークデバイス構成データベースから受信することができる。すべての障害シナリオが、問合せ的な手続を使用することができるわけではない。これらのケースにおいては、はじめにデバイスからのアラームまたはレポートとして送信された情報は、障害の原因を判定するのに十分であるか、または少なくとも、マネージメントエンティティーが問合せを伴わずに修復手続を開始することができる何らかのアクションを実行することができると判定するのに十分である場合がある。たとえば、マネージメントエンティティーは、同様のデバイスの以前の障害から障害の生じているコンポーネント測定値を認識することができ、したがって、すぐに更新をデバイスへ提示することができる。おそらくは小さなコンポーネントに起因する、問合せと更新との間の時間およびトラフィックロードにおけるトレードオフは、完全なコンポーネント更新をトリガーすることができる。
以降の例においては、デバイスアーキテクチャーおよび修復更新手続について説明する。この例示的なデバイスアーキテクチャーおよび修復更新手続は、限定された複雑さおよびリソースを有する小さなフットプリントのデバイスとともに使用することができる。この例に関連付けられている制約について、本明細書において説明することができる。たとえば、デバイスのアプリケーションコードベースおよび信頼済みコードベースは、それらの開発および/または展開ライフサイクル、ならびにそれらのオペレーションに関して別々のものとすることができる。これらの2つのコードベースは、別々の当事者によって開発および/または展開することができる。デバイスの生産性機能を提供することができるデバイスのアプリケーションコードベースは、単一のコードおよびデータブロックとしてデバイスの不揮発性メモリの一部分内に展開することができる。アプリケーションコードベースは、修復に最小限関与することが可能であり、および/またはインテグリティーの妥当性確認に関与しないことが可能である。サービスサイクル(たとえば、デバイスのアプリケーションによって使用することができる、デバイスのコードベースのうちの複数の部分の更新どうしの間におけるアップタイム)は、長くなる場合がある。これは、たとえば、修復のためのリブートは任意の時点において無差別に強制することはできないということを意味すると言える。デバイスの通常のオペレーションは、修復またはデバイス更新手続のために中断することはできない。インテグリティーの妥当性確認および修復のための通信は、デバイススタートアップの初期のステージにおいて行うことができ、その間は、デバイスの内部リソースの使用および通信帯域幅に関する厳しい制限を適用することができる。コンポーネント(たとえば、プログラムおよびデータ)を1つずつ別々にロードして始動することができる典型的なブートサイクルという意味で複雑なシステムスタートアップはないと言える。
例示的なシステムモデルは、上記の制限を考慮に入れて、システムをTrEおよび通常のコンポーネントへと一般的に分割した一バージョンとして説明することができる。システムアーキテクチャーの機能要素としては、下記のうちの1つまたは複数を含むことができる。
RoT(Root of Trust)、これは、信頼の連鎖においてデバイスインテグリティーの妥当性確認が依存する不変の要素であると言える。
SEE(Secure Execution Environment)、これは、システムのうちの残りの部分から分離された、実行可能なコードおよびデータのハードウェアおよび/またはソフトウェア保護を伴う特別な実行環境であると言える。可能な実現形態は、プロセッサのセキュアな実行モード、またはプロセッサ内の別個のカーネルとすることができる。SEE上の制限としては、ランタイムメモリおよび利用可能な(SEE専用の)NVS(non−volatile storage)上の制限を含むことができる。
Comm IF(Communications Interface)コンポーネント、これは、基本的な通信能力をSEEおよび/またはNEEに露出することができる。ならびに/あるいは
NEE(Normal Execution Environment)、これは、デバイス内のアプリケーションコード、たとえば、TrEに属していないコードの実行環境であると言える。NEEは、SEEの能力への、たとえばこの通信能力を再使用するためにComm IFへの特定のインターフェースを有することができる。
これらの機能要素は、デバイスの能力およびコンポーネントを含むいくつかのコードベースによって使用することができる。TrECB(TrE Code Base)およびDACB(Device Application Code Base)へと分割を行うことができる。TrECBは、SEEに割り当てることができ、DACBは、NEEに割り当てることができる。DACBコンポーネントがTrEの能力にアクセスする場合には、そのようなアクセスは、NEEとSEEとの間における言及したインターフェースを介して実行することができる。ランタイムにおいて、たとえば、セキュアスタートアップの後に、NEE上のSEEから実行制御を行わないことが可能であり、その逆もまた同様である。TrECBおよびDACBは、NVSの別々の部分に格納することができる。
図22は、機能コンポーネント2202(左側)およびコード/データストレージコンポーネント2204(右側)からなる例示的なシステムを示している。機能コンポーネント2202は、NEE2206およびSEE2208を含むことができる。SEE2208は、通信インターフェース2210および/またはROT2212を含むことができる。コード/データストレージコンポーネント2204は、NVSコンポーネントを含むことができる。NVSコンポーネントTRV_tmp2214は、NEE2206に関連付けられているTRVを含むことができる。NVSコンポーネントDACB2216は、DACBを含むことができる。NVSコンポーネントTRV NVS2218は、SEE2208に関連付けられているTRVを含むことができる。NVSコンポーネントTrECB NVS2220は、TrECBを含むことができる。別々のセキュリティー測定を複数のNVS区画に別々に適用することができる。矢印は、図22において示されているエンティティーどうしの間における読み取り/書き込みアクセスを示すことができる。TrECB NVS2220は、IVC(integrity validation capability)、DGC(device generic communication capability)、FB/DC(fall back/distress capability)、およびRC(remediation capability)などのさまざまな能力を提供することができる。これらの能力については、本明細書においては図22および図23に関連して論じる。
図22において示されているように、NEE2206は、SEE2208との間で通信状態にあること(たとえば、読み取りおよび/または書き込みを行うこと)が可能である。SEE2208は、通信インターフェース2210を使用して通信を行うことができる。SEE2208は、コード/データストレージコンポーネントを用いて実行されるインテグリティー妥当性確認のためにROT2212を使用することができる。NEE2206は、NVSコンポーネント2214への書き込み、およびNVSコンポーネント2216からの読み取りを行うことができる。SEE2208は、NVSコンポーネント2214からの読み取りを行うことができる。SEE2208は、NVSコンポーネント2216、2218、および2220との間で読み取りおよび書き込みを行うこともできる。
図23は、ブートシーケンスの諸ステージの例示的な一実施形態と、それぞれのステージにおいて実施されるさまざまなエンティティーどうしの間における対話とを示している。図23において示されているように、NEE2206およびSEE2208は、ブートシーケンスにおいて実施することができる。SEE2208は、ブートシーケンスの第1および第2のステージのために使用することができる。第1のステージは、ROT2212を組み込むことができる。第2のステージは、TrECB NVS2220を組み込むことができ、TrECB NVS2220は、IVC(integrity validation capability)2318、DGC(device generic communication capability)2314、FB/DC(fall back/distress capability)2320、RC(remediation capability)2324、および/またはTRV2326を含むことができる。IVC2318は、コンポーネントの測定値を取り、それらの測定値を、たとえばTRV2326などのTRVに含まれている基準値と比較するというタスクを負うことができる。DGC2314は、SEE2208に基本的な通信機能を提供することができる(その通信機能は、ひいてはNEE2206に露出することができる)。DGC2314は、FB/DC2320およびRC2324によって修復および/または障害指示のために使用することができる。DGC2314は、インターフェースを介してDAC2322に露出することもできる。FB/DC2320は、関連機能、すなわち、それぞれネットワークまたはデバイスユーザに障害状況を示す、フォールバックコードベースによるDACB2216の置換を実行するための特定の条件が満たされている場合に、アクティブ化することができる。RC2324は、コードベースの計画された変更および/または訂正のタスクを負ったオーソリティー(authority)とすることができる。RC2324は、TRV2326のマネージャーとすることもでき、RC2324は、TRV2326の真正性をチェック可能とすることができる。
NEE2206は、ブートシーケンスの第3のステージのために使用することができる。第3のステージは、DACB2216を組み込むことができ、DACB2216は、RAIF(remediation application IF)2316および/またはDAC(device application capabilities)2322を含む。RAIF2316は、ネットワークからの入ってくる新たなTRVのためのパススルーインターフェースとすることができる。RAIF2316は、入ってくる通信内のTRVを認識して、それらのTRVをTRV用の一時的な不揮発性ストレージに格納することができる。DAC2322は、デバイスのアプリケーション固有の機能を具体化することができる。DACがComm IFからの通信能力を使用したい場合には、Comm IFへのアクセスは、特別なNEE−SEE IFを通じて仲介されることが可能である。
TRV2326は、システム内の2つの異なる場所に格納することができる。TRV_tmp2214は、RAIF2316によって受信された新たなTRVのための一時的なストレージとすることができ、たとえば、TRV_tmp2214は、NEE2206から書き込み可能とすることができる。TRV_tmpは、SEE2208から読み取り可能とすることができ、SEE2208から、RC2324は、新たなTRVを読み取ることができ、それらのTRVが認証されると、それらのTRVをTRV NVS2218内に置くことができる。
図23において示されているスタートアップシーケンスは、簡略化されたシステムアーキテクチャーにおけるインテグリティーチェックを伴う通常のスタートアップ、たとえば、障害/フォールバックまたは修復アクションを必要とすることがある障害状況が生じていないスタートアップに関連することができる。セキュアスタートアップの第1のステージにおいては、RoT2212をアクティブ化することができる。セキュアスタートアップの第2のステージに関する前の説明とは異なり、RoT2212は、ロードされて始動されるコンポーネント上でさらなるインテグリティーチェックを実行することができる信頼済みブートローダを検証してアクティブ化することはできない。そのようなローダ/実行コントローラは、簡略化されたシステムアーキテクチャーにおいては利用可能ではない場合がある。その代わりに、RoT2212は、TrECB NVS2220においてIVC2318コードおよびデータブロックをチェックすることができる。この構造においては、IVC2318コードは不変とすることができる。なぜなら、RoT2212は、TRV2326を読み取る能力を有することができないためである。したがってRoT2212は、IVC2318を、固定された(RoT2212内に)組み込まれた基準値に照らしてチェックすることができる。
一実施形態においては、RoT2212は、固定されたルート証明書を使用して、IVC2318コードおよびデータブロックをチェックすることができる。このために、TrECB NVS2220のうちのIVC2318の部分は、TrECB NVS2220のうちのこの後者のIVC2318の部分に関する署名とともに格納することができる。RoT2212がその署名をチェックする際に使用することができるキーは、言及した固定されたルート証明書内に存在することができる。IVC2318コードの変更は、新たなIVC2318コードを、同じ固定されたキーを使用するその新たなコードに関する新たな署名とともにダウンロードすること、および後者のデータをTrECb NVS2220内に格納することによって実施することができる。IVC2318は、SEE2208内で実行することができる。IVC2318は、TRV_tmp NVS2214が空であることをチェックすることができる(これは、簡略化されたシステムアーキテクチャーにおけるインテグリティーチェックを伴う通常のスタートアップに関する前提とすることができる)。IVC2318は、DGC2314のコードに関する指定されたTRVをTRV NVS2218からロードすることができる。
IVC2318は、TRV基準値および任意のさらなるデータに関する署名を検証することによって、TRV2326のそれぞれのロードされたTRVのインテグリティーをチェックすることができる。この署名は、TRV内に存在することができ、IVC2318がその署名をチェックする際に使用することができるキーは、IVC2318コード/データブロック内に存在する。次いでIVC2318は、TrECB NVS2220からSEE2208内へロードされたDGC2314コードを測定して、その測定値を後者のTRV内の基準値と比較することができる。合格すると、DGC2314をアクティブ化することができる。アクティブ化とは、たとえば、SEE2304のうちでDGC2314が存在するランタイムメモリ部分上に「実行可能」というフラグを設定し、NEE2206コードがチェックされる場合は常にSEE2208プロセッサおよびNEE2206プロセッサがこのフラグを尊重することを前提とすることによって、DGC2314が実行のために利用可能にされることを意味することができる。
IVC2318は、RAIF2316のコードに関する指定されたTRVをTRV NVS2218からロードすることができる。IVC2318は、DACB NVS2216からNEE2206内へロードされたRAIF2316コードを測定して、その測定値を、後者のTRV内に含まれている基準値と比較することができる。合格すると、RAIF2316をアクティブ化することができる。
IVC2318は、事前に決定されたシーケンスでDACB2216の諸部分に関連付けられているそれぞれのTRVをロードすることができる。IVC2318は、DACB NVS2216からNEE2306内へロードされた、ロードされたTRVによって指定されているDAC2322のコードおよびデータの諸部分を測定して、その測定値を、後者のTRV内に含まれている基準値と比較することができる。
DACB2216におけるチェックが(たとえば、DACB2216のコードおよびデータに関する利用可能なTRVのシーケンスを使い果たすことによって)実行された場合には、IVC2318は、DAC2322をアクティブ化すること、および実行をNEE2206プロセッサに渡すことが可能である(または、SEE2208およびNEE2206プロセッサが同時に動作することが可能である場合には、NEE2206プロセッサを始動する)。FB/DC2320およびRC2324のコードおよびデータのブロックは、スタートアップ手続において特別な状況(たとえば、インテグリティーチェック障害)が生じていない場合には、チェックもアクティブ化もされないことが可能である。
セキュアブートなど、より複雑なシステムにおけるセキュアスタートアップに対する相違としては、IVC2318がTRVデータによって駆動されることが可能であることを含むことができる。すなわち、TRVは、さまざまなコードベースのコードおよびデータのどの断片をチェックすべきかに関する情報を有することができる。TRV2326は、IVC2318によって順次読み取ることができ、IVC2318は、それらのTRV2326を評価して、TRV基準インテグリティー値が当てはまるコードおよびデータの断片を見つけ出すこと、ならびに、このデータを読み取ることおよび/または測定すること、および照合された測定値を基準値と比較することが可能である。
単一のTRV基準値は、1つのコードベース内のコードおよびデータの複数の断片に対応することができるため、TRVは、マッピング、たとえば、そのコードベース内のそれらの断片のロケーションおよび長さのインジケータ、ならびに、それらの断片の測定値どうしをどのように結合して複合測定値にするかに関する指示を含むことができる。図24Aおよび図24Bは、TRVをコードベース内のコードおよび/またはデータの断片にマップする例示的な実施態様を示している。
図24Aは、TRVを作成するために線形に結合することができる部分的な測定値のシーケンスを示す図である。図24Aにおいて示されているように、DACBのコード測定値2402、2404、2406、2408、および2410は、TRV2412を作成するために線形に結合することができる。例示的な一実施形態によれば、コード測定値2402、2404、2406、2408、および2410は、TCGによって指定されたTrusted Platform ModuleのTPM−Extendコマンドを用いて実現されるようなハッシュチェイニングを適用することによって結合することができる。
図24Bは、TRVを作成するためにMerkleハッシュツリーを使用する値の組合せを示す図である。図24Bにおいて示されているように、DACBのコード測定値2416、2418、2420、2422、2424、および2426は、TRV2414を作成するためにMerkleハッシュツリーを使用して結合することができる。
修復および/または更新を実行するデバイスエンティティーと、対応するネットワークエンティティー(たとえば、H(e)MS)との間におけるインタラクティブな問合せ手続は、本明細書に記載されている、TRVからコード/データ断片へのマッピングを利用することができる。本明細書に記載されているようなそのような手続は、本明細書に記載されている一般的なデバイス問合せ手続の特別な例であると言える。
コードのそれぞれの断片を測定することができ、その測定値をネットワークエンティティーへ1つずつ送信することができ、ネットワークエンティティーでは、その測定値を、たとえば、断片基準値の順次的なリスト内の対応する断片基準値と比較することができ、その断片基準値から、TRV基準値が、たとえばハッシュチェイニングなどの何らかの方法によって、それまでに計算されていた可能性がある。
Merkleハッシュツリーを介する検知を通じた多数の断片のケースにおいては、効率を高めることができる。これは、ツリーのレベルを下ることによって、インタラクティブな問合せ手続の形態で実行することができる。ここでは、TRV内に含まれている基準値、およびコード/データから取られた測定値は両方とも、(グラフ理論的に)同じバイナリーツリーのルートを表すことができる。それらの値が一致しない場合には、デバイスは、2つの子ノード値をネットワークエンティティーへ送信することができ、ネットワークエンティティーは、どちらの子ノード値が不合格であるか、たとえば、ネットワークがTRV基準値をビルドするために使用した参照ツリー内の同じノード(それらのノードは、その参照ツリーのルートである可能性がある)と一致しないかを判定することができる。ネットワークは、どの(1つまたは複数の)分岐が不一致であるかを示すことができるメッセージをデバイスへ送信することができる。この手続は、測定ツリーのリーフを構成する測定値を有するコードの断片のうちで、参照(リーフ)値に対する不一致がある断片が判定されるまで、反復することができる。
再び図23を参照すると、デバイス修復のために使用されるTrECB2220の能力に基づいて、機能および手続を実行することができる。一実施形態においては、オペレーション中に1つまたは複数のTRV2326を更新すること、および次のスタートアップ時に実際のコード更新を実行することによって、計画されたコード更新を実行することができる。
下記の内容は、計画されたコード更新に関連することができる。デバイスが、本明細書に記載されているようにスタートアップを実行していると想定することができる。RAIF2316は、たとえばComm IF2210および/またはDGC2314を介して、外部の当事者、たとえばH(e)MSから新たなTRVを受信することができる。RAIF2316は、この新たに受信したTRVをTRV_tmp NVS2214内に格納することができる。その後に、デバイスは再始動することができる。IVC2318は、本明細書に記載されているようにSEE2208内でインテグリティーチェックされて始動されることが可能である。IVC2318は、TRV_tmp NVS2214をチェックして、TRV_tmp NVS2214が空ではないことを認識することができ、本明細書に記載されているように進むことができる。
TRV_tmp2214は、単一の新たなTRVを有することができる。第1の実施態様においては、TRV_tmp内の新たなTRVは、DACB2216内のコードおよび/またはデータを参照することができる。第2の実施態様においては、TRV_tmp内の新たなTRVは、TrECB2220内のコードおよび/またはデータ、たとえば、DGC2314、FB/DC2320、またはRC2324のコード/データを参照することができる。
第1の実施態様においては、IVC2318は、上述のようにTRVの真正性を検証することができる。合格すると、IVC2318は、新たなTRVをTRV NVS2218内に格納することができる。IVC2318は、新たなTRVによって取って代わられるべきものとみなすことができる、TRV NVS2218内の1つまたは複数の古いTRVを削除することができる。これらの破棄されるTRVがどのように判定されるかは、実施態様に応じて決めることができる。一意の識別子を、TRV内のさらなるデータの一部として、TRVに割り当てることができる。このパラグラフに記載されているプロセスは、たとえばTRVのインジェスチョン(ingestion)と呼ばれる場合がある。
IVC2318は、TrECB 2220 NVSからSEE2208内へロードされたDGC2314コードを測定して、その測定値を、後者のTRV内に含まれている基準値と比較することができる。合格すると、DGC2314をアクティブ化することができる。IVC2318は、TRV2326をTRV NVSからロードすることおよび/または検証することが可能であり、それらのTRV2326のそれぞれに関するコードおよびデータの指定された断片に関してIVを実行すること、たとえば、RAIF2316から開始して、DACB2216のその他の部分へ進むことが可能である。IVシーケンスにおいて、新たにインジェストされたTRVに遭遇した場合には、DACB2216のコードおよびデータの指定された部分の上で実行されたIVは、(たとえば、新たなTRVが、破棄される(1つまたは複数の)TRVとは異なる基準値を有していると想定して)必然的に不合格になることができる。
IVC2318は、RCのコードに関する指定されたTRVをTRV NVS2218からロードすることができる。次いでIVC2318は、TrECB 2220 NVSからSEE2208内へロードされたDGC2314コードを測定して、その測定値を後者のTRV内の基準値と比較することができる。合格すると、RCをアクティブ化することができる。
対応するネットワークエンティティー、たとえばH(e)MSに対する問合せ手続によって、RC2324は、新たにインジェストされたTRVの基準値を再生するために、更新を必要としている可能性がある、たとえば、インテグリティー測定の不合格の一因となる可能性があるコードおよび/またはデータの断片を判定することができる。この問合せ手続は、たとえば本明細書に記載されているように実行することができる。
新たなTRVとともに、デバイスは、コードおよび/またはデータのどの部分が置換を必要としている可能性があるかの詳細を受信していた可能性もある。これによって、RC2324とネットワークとの間における問合せ手続を回避することができる。問合せは、デバイスの通常のオペレーション中にダウンロードされるデバイスマネージメントおよび/または修復用のデータの量を最小限に抑えるように実行することができる。問合せは、デバイスが、その(1つの、新たな)TRVおよび/またはその指定されたコードの断片のいくつかの中間更新を「行っていない」という可能性を考慮するように実行することもできる。そのようなその後の更新が累積している場合には、それらの更新は、より多数のコード断片に影響を与える傾向を有する場合があり、それは、問合せ手続内で見つけることができる(しかし、デバイスによって行われなかった可能性がある、同じTRVの更新のシーケンスの後の、最新のTRVに限定された更新のために指定された断片のリスト内にあることを保証することはできない)。
RC2324は、対応するネットワークエンティティーから判定されたコードおよび/またはデータの判定された断片をダウンロードすることができる。一例によれば、ネットワークエンティティーは、TR−069の署名されたデータパッケージを集めること、および/またはそのデータパッケージをデバイスへ送信することが可能である。受信されたデータは、RC2324(または別法として、IVC2318)によって、たとえば、新たにインジェストされたTRV内の署名証明書、(たとえば、IVC2318によって)TRV2326をチェックするために使用されるルート証明書、または(たとえば、RC2324コード/データベース内の)修復目的のための専用の証明書を使用してパッケージ署名を検証することによって、真正性に関してチェックすることができる。
コードおよび/またはデータのダウンロードされた断片の認証後に、RC2324は、それらの断片をDACB2216 NVSに、それまでに判定された断片のロケーションに書き込むことができる。DGC2314は、実行をIVC2318へ返すことができ、IVC2318は、TRVシーケンス内の同じTRV、たとえば、新たにインジェストされたTRVにおいてIVを再開することができる。
上述の手続は、循環式になることができる。これは、少なくとも2つの理由のうちの1つから行うことができる。第1の理由としては、攻撃者が自分自身のコードを更新プロセス内に挿入した可能性があり、これは、TRV基準値に合致しない可能性がある。さらなる理由としては、たとえばネットワーク側のコードビルドの機能不良に起因して、TRV基準値および/またはダウンロードされたコードの不注意による不一致が存在する可能性がある。両方の実施態様においては、その状況を検知して、ネットワークに知らせることができる。これは、IVC2318によってTRVの使用に関するリピートカウンタを使用して達成することができる。高いセキュリティーのために、それらのカウンタは、TRV NVSへの読み取りアクセスによってインクリメントされることが可能であるモノトニックハードウェアカウンタとすることができる。単一のTRV上でIVのあまりに多くの繰り返しが検知された場合には(それが何回かは、ポリシーに応じて決めることができる)、IVC2318は、FB/DC2320をチェックしてアクティブ化すること、および/または、しかるべき信号をネットワークへ送信するために制御をその能力へ渡すことが可能である。
(TrECB2220内のコードおよび/またはデータを参照するTRV_tmp2214内の新たなTRVに関する)上述の第2の実施態様に関連して、(DACB2216内のコードおよび/またはデータを参照するTRV_tmp2214内の新たなTRVに関する)第1の実施態様を使用することはできない。なぜなら、更新/修復は、更新/修復に関与しているアクティブなコンポーネント自体に関して要求することができるためである。そのようなケースにおいては、下記の手続の1つまたは複数のステップを適用することができる。IVC2318は、新たなTRVをインジェストすることができ、その一方で、対応する古いTRVをTRV NVS2218内に保持することができる。新たなTRVは、それが新たなものであることを示す何らかのデータフラグ、たとえば「NEW_DGC_TRV」という文字列でマークすることができる。IVC2318は、古いTRVを使用して、RC2324をチェックすることおよび/またはアクティブ化することが可能である。RC2324は、第1の実施態様において説明したのと同じ方法で使用することができるTrECB2220部分の更新を実行することができるが、第2の実施態様においては、更新は、TrECB2220 NVS内に書き込むことができる。IVC2318は、新たなTRVを使用して、TrECB2220の更新された部分をチェックすることができる。合格すると、古いTRVをTRV NVS2218から削除することができ、新たなTRVに付けられているマークを外すことができる。これは、たとえばデバイスが次に再始動される後まで延期することができる。
RoT2212がIVC2318コードをチェックする場合に、インテグリティーチェックの第1の不合格状況が生じることがある。このチェックが不合格である場合には、RoT2212は、システムを停止することができ、さらに信号(たとえば、光信号)をユーザへ送信することができる。
一実施形態によれば、RoT2212は、FB/DC2320の不変の部分(または可変の部分、そのインテグリティーは、ICコードに関する類似した異形において記載されているような署名によって保護することができる)をチェックする能力、および/または障害/フォールバック手続のそのような限定された部分を呼び出す能力を有することができ、それは、この自律的にチェックされたコードを介して、たとえば、そのコードをSEE2208にロードして、そのコードをSEE2208において実行することによって、利用可能とすることができる。
不合格になる可能性がある次なるインテグリティーチェックは、DGC2314および/またはRAIF2316のインテグリティーチェックかもしれない。前者は、デバイスが、信頼できる通信能力を有していないことを意味することができる。このケースにおいては、IVC2318は、FB/DC2320を検証してアクティブ化するよう試みることができる。FB/DC2320は、信頼できる通信をある程度まで回復できること、および障害信号をネットワークへ送信できることが可能である。そうでない場合には、FB/DC2320は、ユーザに知らせてシステムを停止することができる。上述の修復手続においてRC2324のIVが不合格になった場合には、同じ手続を適用することができる。
上述の第2の実施態様において、RAIF2316のIVが不合格になった場合には、これは、デバイスが、TRV更新を受信する能力を失っている可能性があることを意味することができる。次いでデバイスは、まず上述のような状況を修復するよう試みることができる。これが成功しない場合には、IVC2318は、FB/DC2320を検証することおよび/またはアクティブ化することが可能であり、そしてFB/DC2320は、特定のアクションを行うこと、たとえば、何らかのデフォルトコードによってRAIF2316を置換することが可能である。
RAIF2316は、NEE2206において露出されているコードの部分、および通常のコードベースの部分として、デバイス修復における最も弱いリンクであると言えるということを前述の説明から理解することができる。これは、デバイスインテグリティーに対する直接の脅威を提示するものではないかもしれないが、RAIF2316は、インテグリティーチェックに関与することができないため、更新/修復を無効にすること、したがってデバイスを非推奨の(たとえば、不合格の)状態に保持することによって、間接的な攻撃およびサービス妨害攻撃へと進む道を開く可能性がある。一実施形態によれば、RAIF2316によって具体化される機能は、TrECB2220の一部として提供されること、およびSEE2208において実行されることが可能である。これは、システムアーキテクチャー上の進化した構成を提示することができる。なぜなら、これは、SEE2208の一部がアクティブであり、新たなTRVを受信する用意ができているということを意味することができるためである。SEEのそのような永続的なアクティビティーは、たとえばComm IF2210およびDGC2314において実現することができる。
上記では特徴および要素について特定の組合せで説明しているが、それぞれの特徴または要素は、単独で、または他の特徴および要素との任意の組合せで使用することができるということを当業者なら理解するであろう。加えて、本明細書に記載されている方法は、コンピュータまたはプロセッサによって実行するためにコンピュータ可読メディア内に組み込まれているコンピュータプログラム、ソフトウェア、またはファームウェアで実装することができる。コンピュータ可読メディアの例としては、(有線接続またはワイヤレス接続を介して伝送される)電子信号、およびコンピュータ可読ストレージメディアが含まれる。コンピュータ可読ストレージメディアの例としては、ROM(read only memory)、RAM(random access memory)、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび取り外し可能ディスクなどの磁気メディア、光磁気メディア、ならびにCD−ROMディスクおよびDVD(digital versatile disk)などの光メディアが含まれるが、それらには限定されない。ソフトウェアと関連付けられているプロセッサは、WTRU、UE、端末、基地局、RNC、または任意のホストコンピュータにおいて使用するための無線周波数トランシーバを実装するために使用することができる。