JP2022052514A - 情報処理装置 - Google Patents

Abstract

【課題】高いセキュリティと高い可用性とを備えた情報処理装置を提供する。【解決手段】ＲＯＭモニタは、モニタプログラムの第１の動作モードである試行モードにおいて、ファームウェアがそなえる機能の有効性を判定し、有効性が確認できない場合、既に検証済みのファームウェアを選択し代替実行を行う。有効性が確認できた場合、ファームウェア更新通知の検証を行い、ファームウェア更新通知の識別番号が、保持された最大識別番号より大きい場合、第２のモードに変更しファームウェアを実行する。ＲＯＭモニタの第２の動作モードにおいては、全ての検証に成功したときのみ実行ファームウェアを変更し、動作モードを第１の試行モードに変更し更新したファームウェアを実行する。いずれかの検証に失敗した場合には、ファームウェアを再度実行する。【選択図】図９

Description

本実施形態は、情報処理装置に関する。

近年、ファームウェアプログラム（以降、ファームウェア、またはFW、と表記）を持つ情報処理装置に対して通信により情報処理装置のFWを更新する、遠隔FM更新が採用される場合がある。遠隔FM更新が実行される情報処理装置は、高いセキュリティと高い可用性とを備えていることが望まれる。

国際公開第２０１８／１３９２９６号 特許第４５４８６０１号公報 特許第４９０１０９５号公報 特許第５０３８３９７号公報 特開２００４－３８９６８号公報

一つの実施形態は、高いセキュリティと高い可用性とを備えた情報処理装置を提供することを目的とする。

一つの実施形態によれば、情報処理装置は、プロセッサと、不揮発メモリと、を備える。プロセッサは、ファームウェアプログラムとモニタプログラムとを互いに排他的に実行することができる。プロセッサは、第１モードおよび第２モードを含む複数の動作モードの間の切り替えと、ファームウェアプログラムの起動と、をモニタプログラムに従って実行することができる。第１モードは、新たなファームウェアプログラムを取得するためのモードである。第２モードは、新たなファームウェアプログラムの取得が禁止され、かつファームウェアプログラムが正常に動作しているか否かを判定することができるモードである。不揮発メモリは、それぞれは取得済みのファームウェアプログラムである２以上のファームウェアプログラムが格納され得る。プロセッサは、２以上の第１ファームウェアプログラムのうちの第２ファームウェアプログラムに従って第２モードで動作しているときに第３ファームウェアプログラムへのファームウェア更新を指示する第１更新通知を取得した場合、モニタプログラムに従って第１更新通知を検証する。プロセッサは、第１更新通知の検証結果が合格である場合に、２以上の第１ファームウェアプログラムのうちの正常に動作することが既に確認された第４ファームウェアプログラムを第１モードで起動する。プロセッサは、第４ファームウェアプログラムに従って第１モードで動作しているときに第３ファームウェアプログラムを取得する。プロセッサは、第３ファームウェアプログラムの取得の後、モニタプログラムに従って第３ファームウェアプログラムを検証する。プロセッサは、第３ファームウェアプログラムの検証結果が不合格である場合に、２以上の第１ファームウェアプログラムのうちの正常に動作することが確認された第５ファームウェアプログラムを第２モードで起動する。プロセッサは、第３ファームウェアプログラムの検証結果が合格である場合に、第２モードで第３ファームウェアプログラムを起動する。プロセッサは、第３ファームウェアプログラムに従って第２モードで動作しているときに、第３ファームウェアプログラムが正常に動作していないと判定した場合、第５ファームウェアプログラムを前記第２モードで起動する。

第１の実施形態にかかるネットワーク構成の一例を示す模式的な図。 第１の実施形態にかかる端末装置のハードウェア構成の一例を示す模式的な図。 第１の実施形態にかかる端末装置に搭載されるCPUの内部構成の一例を示す模式的な図。 第１の実施形態にかかる端末装置においてCPUが実現する機能と不揮発メモリの概略構成とを説明するための模式的な図。 第１の実施形態にかかる更新通知のデータ構成例を示す模式的な図。 第１の実施形態にかかるROMモニタ専用ストレージに格納されるデータ群の一例を示す模式的な図。 第１の実施形態にかかるFW管理テーブルの構成の一例を示す模式的な図。 第１の実施形態にかかる端末装置の動作例を示すシーケンス図。 第１の実施形態にかかるROMモニタの動作の詳細を示すフローチャート。 第１の実施形態にかかる正常動作判定処理の詳細を示すフローチャート。 第１の実施形態にかかるロールバック処理の詳細を示すフローチャート。 第１の実施形態にかかる更新モード移行処理の詳細を示すフローチャート。 第１の実施形態にかかる試行モード移行処理の詳細を示すフローチャート。 第２の実施形態にかかる更新通知のデータ構成例を示す模式的な図。 第２の実施形態にかかる端末装置においてCPUが実現する機能と不揮発メモリの概略構成とを説明するための模式的な図。 第２の実施形態にかかる端末装置の動作例を示すシーケンス図。 第２の実施形態にかかるROMモニタの動作の詳細を示すフローチャート。 第２の実施形態にかかる更新モード移行処理の詳細を示すフローチャート。 第２の実施形態にかかる指定ファームウェア入手判定の詳細を示すフローチャート。 第２の実施形態にかかる試行モード移行処理の詳細を示すフローチャート。 第３の実施形態にかかる端末装置においてCPUが実現する機能と不揮発メモリの概略構成とを説明するための模式的な図。 第３の実施形態にかかる端末装置の動作例を示すシーケンス図。 第３の実施形態にかかるROMモニタの動作の詳細を示すフローチャートる。 第３の実施形態にかかる更新モード移行処理の詳細を示すフローチャート。 第２の実施形態にかかる指定ファームウェア入手判定の詳細を示すフローチャート。 第４の実施形態にかかる更新通知のデータ構成例を示す模式的な図。 第４の実施形態にかかる更新通知リストの一例を示す模式的な図。 第４の実施形態にかかる更新計画の一例を示す模式的な図。 第４の実施形態にかかる端末装置においてCPUが実現する機能と不揮発メモリの概略構成とを説明するための模式的な図。 第４の実施形態にかかるROMモニタ専用ストレージに格納されるデータ群の一例を示す模式的な図。 第４の実施形態にかかる端末装置の動作例を示すシーケンス図。 第４の実施形態にかかるROMモニタの動作の詳細を示すフローチャート。 第４の実施形態にかかる計画更新モード移行処理の詳細を示すフローチャート。 第４の実施形態にかかる更新計画検証処理の詳細を示すフローチャート。 第４の実施形態にかかる計画更新FW取得後処理の詳細を示すフローチャート。 第１の実施形態にかかる端末装置が動作停止期間の後にファームウェア更新を行う場合の手順を説明するための模式的な図。 第４の実施形態にかかる更新通知が適用された場合のファームウェア更新の手順を説明するための模式的な図。

前述されたように、遠隔FW更新が可能な情報処理装置は、高いセキュリティと高い可用性とを有することが要望される。

セキュリティに関しては、下記の課題がある。まず、情報処理装置が受信するファームウェアまたは更新通知の偽造を防止することが課題である。また、新しいファームウェアを取得する際に動作している古いファームウェアに脆弱性がある場合、情報処理装置のストレージ内の本来アクセスが禁止される領域に他者から不正にアクセスされてしまう可能性がある。このような不正なアクセスを防止することが別の課題である。また、近年の情報処理装置が有するリカバリ機能を利用して、古い脆弱性があるバージョンのファームウェアを情報処理装置に実行させて、その脆弱性を突いた攻撃を行う、いわゆるロールバック攻撃が知られている。このようなロールバック攻撃に対する対策も課題である。

可用性に関しては、下記の課題がある。例えば、遠隔から配布されたファームウェアが動作不良を起こしたことで情報処理装置が起動不能となった場合、さらなる通信ができないことから情報処理装置が動作不能となる故障モードがある。この故障モードに対しては、実行対象のファームウェアを現在のファームウェアから古いバージョンのファームウェアにロールバックする手法が一般に用いられる。しかしながら、ロールバック先のファームウェアに重大な欠陥があった場合、情報処理装置の可用性が損なわれる場合がある。つまり、ロールバック先のファームウェアでも情報処理装置が正常に動作できるようにすることが課題である。なお、ロールバック先のファームウェアに脆弱性があった場合、ファームウェアのロールバック後の情報処理装置のセキュリティが低下するという課題もある。

実施形態によれば、セキュリティに関する課題のうちの少なくとも一部と、可用性に関する課題のうちの少なくとも一部と、を解決することで、情報処理装置のセキュリティと可用性とをともに向上させた情報処理装置を提供する。

以下に添付図面を参照して、実施形態にかかる情報処理装置を詳細に説明する。なお、これらの実施形態により本発明が限定されるものではない。

（第１の実施形態）
図１は、第１の実施形態にかかるネットワーク構成の一例を示す模式的な図である。

本ネットワーク構成は、制御ネットワーク1と、管理サーバ2と、アプリケーションサーバ3と、無線アクセスポイント10と、１以上の端末装置100と、を備えている。１以上の端末装置100のそれぞれは、無線アクセスポイント10および制御ネットワーク1を介して、管理サーバ2およびアプリケーションサーバ3と通信を行うことができる。なお、ここでは１以上の端末装置100として、５つの端末装置100-1～100-5が描画されている。管理サーバ2およびアプリケーションサーバ3と通信を行うことができる端末装置100の数は５個に限定されない。１以上の端末装置100のそれぞれは情報処理装置の一例である。

各端末装置100は、無線アクセスポイント10に無線リンクを介して、接続されている。制御ネットワーク1は、インターネットプロトコルを利用するネットワークである。

管理サーバ2は、各端末装置100に新しいファームウェアを更新する際には、更新通知を発行し、ブロードキャストにより管理下にある端末装置100に更新通知を配布する。各端末装置100は、更新通知を受信すると、新しいファームウェアを管理サーバ2から取得することができる。即ち、管理サーバ2は、各端末装置100のファームウェアを遠隔で更新する、遠隔FW更新を実行することができる。更新通知およびファームウェアプログラムの取得の詳細については後述される。

アプリケーションサーバ3は、１以上の端末装置100のうちの所望する端末装置100にアプリケーションプログラムを配布したり、アプリケーションプログラムの動作に必要なデータを提供したりすることができる。

図２は、第１の実施形態にかかる端末装置100のハードウェア構成の一例を示す模式的な図である。

プロセッサの一例であるCPU（Central Processing Unit）200が、無線データリンク232を通じて、無線アンプ部181に接続されている。無線アンプ部181は、外部入出力端子183を介して、アンテナ182に接続されている。CPU200はUART（Universal Asynchronous Receiver Transmitter）接続223を通じて、計測・制御部191に接続されている。計測・制御部191は外部入出力端子192に接続されている。計測・制御部191は、たとえば外部入出力端子192を介して電力メータと通信して、機器の消費電力を計測し、CPU200に渡す。CPU200は、外部保守インタフェース111に接続されている。

図３は、第１の実施形態にかかる端末装置100に搭載されるCPU200の内部構成の一例を示す模式的な図である。

命令実行ユニット201は、メモリ保護ユニット202を経由して、内部バス208に接続されている。

メモリ保護ユニット202は、命令実行ユニット201に投入される命令が、不揮発メモリ203内のROM（Read Only Memory）モニタプログラム（図４のROMモニタプログラム650）に割り当てられたものかどうかを表す信号を出力する。この信号は、信号線211を介して、命令実行ユニット201に入力される。

不揮発メモリ203とRAM(Random Access Memory)204が、内部バス208に接続されている。

ウォッチドッグタイマ(WDT: Watch Dog Timer)210と制御レジスタ209も内部バス208に接続されている。制御レジスタ209の一の出力であるリセット信号、およびWDT２１０の出力（リセット信号）は、ワイヤードORでリセット信号線212を介して、命令実行ユニット201に入力される。また、制御レジスタ209の他の出力であるNMI(Non Maskerable Interrupt：マスク不能割り込み)信号は、NMI信号線213を介して、命令実行ユニット201に入力される。

暗号アクセラレータ205、および乱数発生器(RNG)206も、同様に内部バス208に接続されている。無線データリンク218およびUART（Universal Asynchronous Receiver Transmitter）207も、内部バス208に接続される。

デバッグ部220は、命令実行ユニット201に直接接続されるとともに、デバッグポート231を介して、外部（図２の保守用インタフェース111）に接続されている。

CPU200は、上記のように構成されたことで、端末装置100のファームウェアプログラムとROMモニタプログラムとを排他的に実行することができる。

図４は、第１の実施形態にかかる端末装置100においてCPU200が実現する機能と不揮発メモリ203の概略構成とを説明するための模式的な図である。

端末装置100において実行されるプログラムは、起動時に実行されるROMモニタプログラム650と、ROMモニタプログラム650によって起動されるファームウェアを含む。ROMモニタプログラム650は、図４に示される例では、不揮発メモリ203に格納されている。なお、ROMモニタプログラム650は、不図示のマスクROMに格納されていてもよい。

命令実行ユニット201は、ROMモニタプログラム650を実行することによって、ROMモニタ520として機能する。また、命令実行ユニット201は、ファームウェアを実行することによって、RTOS（Real-Time Operating System）510として機能する。なお、以降の説明では、RTOS510が実行する処理の説明の際に、主語をファームウェアとする場合がある。

不揮発メモリ203には、RTOS用ストレージ610、共有ストレージ620、FWストレージ630、およびROMモニタ専用ストレージ640がアロケートされている。RTOS用ストレージ610、共有ストレージ620、FWストレージ630、およびROMモニタ専用ストレージ640に格納された情報は、電源オフ状態でも失われない。

FWストレージ630は、複数のストレージ領域631を備える。ここでは一例として、FWストレージ630は、Ｎ個のストレージ領域631-1～631-Nを備える。ただし、Nは２以上の整数である。各ストレージ領域631には、１つのファームウェアが格納され得る。よって、FWストレージ630は、２以上のファームウェアが格納され得る。

ROMモニタ520は、RTOS510よりも強いストレージアクセス権限を持つ。ROMモニタ専用ストレージ640は、ROMモニタ520は参照できるがRTOS510からは参照できない。RTOS用ストレージ610および共有ストレージ620には、RTOS510、ROMモニタ520の両方が読み書きできる。ただし、ROMモニタ520はRTOS用ストレージ610に対する読み書きは行わない。ROMモニタ520は、FWストレージ630に対し、RTOS510からの書込みを制限するアクセス制御をストレージ領域単位で設定することができる。RTOS510からの書込みは、アクセス制御の設定にしたがう。

ROMモニタ520は、ストレージ領域631-1～631-Nのうち１つを選択し、選択されたストレージ領域631に格納されたファームウェアを起動することにより、RTOS510を起動する。RTOS510の起動後はRTOS510の再起動までROMモニタ520の動作は実行されない。つまり、ROMモニタプログラム650の実行と、ファームウェアプログラムの実行と、は排他的である。

端末装置100は、管理サーバ2から更新通知を受け取ることを契機として、ファームウェアの更新にかかる動作を開始することができる。

図５は、第１の実施形態にかかる更新通知701のデータ構成例を示す模式的な図である。更新通知701は、シーケンス番号710と、更新先のファームウェアのハッシュ値720と、署名730と、が連接されて構成されたデータ構成を有している。署名730は、シーケンス番号710およびハッシュ値720からなるメッセージに対して所定のアルゴリズムを用いて生成されたものである。署名730の生成に用いられる非対象鍵系の秘密鍵は、管理サーバ2のみに保持されている。よって、正規の更新通知701を発行できるのは管理サーバ2のみである。端末装置100のROMモニタ専用ストレージ640には、上記された秘密鍵の対である公開鍵が保存されている。端末装置100（より具体的にはROMモニタ520）は、当該公開鍵に基づいて、署名730の検証を実行することができる。

シーケンス番号710は、更新通知701が発行されたタイミングに対応する数値情報である。より詳しくは、管理サーバ2は、更新通知701を発行する毎に増加せしめられる数値重宝を、シーケンス番号710として各更新通知701に付す。端末装置100は、新しく更新通知701を受け取ったとき、当該新しく受け取った更新通知701のシーケンス番号710と、過去に受け取った全ての更新通知701のシーケンス番号710のうちの最大値と、を比較することによって、当該新しく受け取った更新通知701が最新の更新通知701であるか否かを判定することが可能である。RTOS510は、新しく受け取った更新通知701のシーケンス番号710が、過去に受け取った全更新通知701のシーケンス番号710の最大値よりも大きい場合、当該新しく受け取った更新通知701は最新の更新通知701であると判定する。RTOS510は、新しく受け取った更新通知701のシーケンス番号710が、過去に受け取った全更新通知701のシーケンス番号710の最大値以下である場合、当該新しく受け取った更新通知701は最新の更新通知701でないと判定する。

図６は、第１の実施形態にかかるROMモニタ専用ストレージ640に格納されるデータ群の一例を示す模式的な図である。

ROMモニタ専用ストレージ640には、主状態変数641、最大シーケンス番号642、アクティブFW格納先643、アクティブFW動作実績644、FW管理テーブル645、および次回FW取得要否646が記録されている。

主状態変数641は、複数の動作モードの何れかを示す変数である。第１の実施形態では、複数の動作モードとして、ファームウェアを取得することができる更新モードと、ファームウェアの取得が禁止されており、現在実行中のファームウェアが正常に動作しているか否かを判定することができる試行モードと、が用意されている。

最大シーケンス番号642は、過去に受信した全ての更新通知701に付されたシーケンス番号710のうちの最大値である。

アクティブFW格納先643は、ROMモニタ520が直前に動作していたファームウェアを特定するための変数である。FWストレージ630が備えるN個のストレージ領域631のうちの、直前に動作していたファームウェアが格納されている１つのストレージ領域631の識別情報がアクティブFW格納先643にセットされる。ここでは、N個のストレージ領域631のそれぞれは固有の領域番号によって特定されることとし、アクティブFW格納先643は１つのストレージ領域631を示す領域番号がセットされることとする。ROMモニタ520は、アクティブFW格納先643に領域番号をセットしたのち、アクティブFW格納先643としてセットされた領域番号が示すストレージ領域631に格納されたファームウェアを起動する。再起動の処理によって当該ファームウェアの実行が終了すると、ROMモニタ520が起動する。そのとき、ROMモニタ520は、アクティブFW格納先643を参照することで、再起動の前にどのファームウェアが実行されていたかを認識することができる。

アクティブFW動作実績644は、直前の動作においてファームウェアが正常に動作したか否かを示す変数である。ROMモニタ520は、直前に動作されたファームウェアと同一のファームウェアを起動する際、直前のファームウェアの動作においてファームウェアの正常動作を認識した場合に、アクティブFW動作実績644に「１」をセットする。ROMモニタ520は、直前のファームウェアの動作においてファームウェアの動作不良を認識した場合、または直前に動作されたファームウェアと異なるファームウェアを起動する場合、アクティブFW動作実績644に「０」をセットする。

FW管理テーブル645は、FWストレージ630に格納されたファームウェアを管理するための情報である。FW管理テーブル645の具体的なデータ構成は後述される。

次回FW取得要否646は、次にファームウェアを実行するときに、新たなファームウェアの取得の要否を示す変数である。ROMモニタ520は、自身の起動の前に動作したファームウェアが更新通知701を受信し、当該更新通知701に対応した新しいファームウェアの取得が必要な場合に、次回FW取得要否646に「１」をセットする。

図７は、第１の実施形態にかかるFW管理テーブル645の構成の一例を示す模式的な図である。FW管理テーブル645は、FWストレージ630が有するストレージ領域631の数と同数の領域管理情報655が記録されている。ここでは、FW管理テーブル645には、N個の領域管理情報655-1～655-Nが記録される。各領域管理情報655は、FWストレージ630が有するストレージ領域631の何れかと１対１に対応する。各領域管理情報655は、有効フラグがセットされ得るフラグフィールド656、優先順位がセットされ得る優先順位フィールド657、および対応するストレージ領域631に格納されたファームウェアにかかる更新通知701が記録され得る更新通知フィールド658を備える。

続いて、図８を参照して、第１の実施形態にかかる端末装置100の動作例を説明する。図８は、第１の実施形態にかかる端末装置100の動作例を示すシーケンス図である。

端末装置100の電源が投入されると、ROMモニタ520が動作を開始する。ROMモニタ520は、主状態変数641を参照することで、動作モードを取得する。また、前回に実行されたファームウェアは、共有ストレージ620にデータを残している場合がある。共有ストレージ620に残され得るデータは、例えば、動作結果情報、または更新通知701などである。ROMモニタ520は、共有ストレージ620に残されたデータに基づいて次の動作モードを決定することができる。

なお、図８において、ステップ番号が奇数の動作は電源投入後または再起動後のROMモニタ520の動作を表している。また、ステップ番号が偶数の動作は、RTOS510、つまりファームウェア、の動作を表している。

なお、RTOS510として動作中のファームウェアは、所定のハードウェアを操作することによってCPU200を自発的に再起動することができる。CPU200の再起動によってROMモニタ520に制御が移り、ROMモニタ520が再起動される。また、ROMモニタ520の再起動は、電源断からの復帰時にも行われる。

例えば電源投入後のステップX01では、ROMモニタ520は主状態変数641を参照し、ファームウェアの予定される動作モードが試行モードであることを知る。ROMモニタ520は、ファームウェアFW2を試行モードで起動する。

ステップX02においては、ファームウェアFW2は、自身が動作不良を起こしたこと自己診断によって発見して、動作不良が起こったことを動作結果情報として共有ストレージ620に保存する。そして、ファームウェアFW2は、CPU200を再起動する。

ステップX03では、ROMモニタ520が、共有ストレージ620に書き込まれた動作結果情報に基づいてファームウェアFW2の動作不良を知ると、既に正常に動作することが確認されたファームウェアFW1を代替のファームウェアとして選択する。つまり、ROMモニタ520は、ファームウェアFW1が格納されたストレージ領域631の領域番号をアクティブFW格納先643として記録する。そして、ROMモニタ520は、動作モードを試行モードに維持してファームウェアFW1を起動する。

ステップX04では、ファームウェアFW1は、自身が正常に動作していることを自己診断によって発見して、正常に動作していることを動作結果情報として共有ストレージ620に書き込む。そして、ファームウェアFW1は、管理サーバ2から新しいファームウェアFW3にかかる更新通知701を受信する。ファームウェアFW1は、更新通知701を共有ストレージ620に書き込み、CPU200の再起動を行う。

ステップX05では、ROMモニタ520は、ファームウェアFW2が正常に動作したことを共有ストレージ620に書き込まれた動作結果情報に基づいて知る。そして、ROMモニタ520は、アクティブFW動作実績644に正常動作を示す「１」をセットする。ROMモニタ520は、共有ストレージ620内の更新通知701の存在を確認すると、署名730に基づいた更新通知701の検証を実行する。つまり、ROMモニタ520は、署名730に基づき、更新通知701の真正性（Authenticity）を確認する。また、ROMモニタ520は、シーケンス番号710に基づいた更新通知701の検証を実行する。つまり、ROMモニタ520は、シーケンス番号710が最大シーケンス番号642よりも大きいか否かを判定する。両検証の結果が合格である場合、つまり、更新通知701の真正であり、かつ更新通知701が管理サーバ2から発行された最新の更新通知であることが判明した場合、ROMモニタ520は、次回FW取得要否646に「１」をセットし、主状態変数641を更新モードにセットする。これによって、動作モードが試行モードから更新モードに変更される。ROMモニタ520は、新しいファームウェアFW3をFWストレージ630に格納できるように、１つのストレージ領域631を書き込み可に設定する。ROMモニタ520は、共有ストレージ620にFW取得要求を書き込む。そして、ROMモニタ520は、正常に動作することが既に確認されたファームウェアFW1を起動する。ROMモニタ520は、ファームウェアFW1が正常に動作したことを、アクティブFW動作実績644を参照することによって知ることができる。

ステップX06では、更新モードで起動されたファームウェアFW1は、共有ストレージ620内のFW取得要求に応じて、管理サーバ2から新しいファームウェアFW3を取得する。ファームウェアFW1は、取得したファームウェアFW3を、FWストレージ630内の書き込み可に設定されているストレージ領域631に格納する。そして、ファームウェアFW1は、CPU200の再起動を行う。

ステップX07では、ROMモニタ520は、共有ストレージ620に保存されている更新通知701について、ステップX05と同様に、署名730を用いた検証と、シーケンス番号710を用いた検証と、を実行する。両検証の結果が合格である場合、さらに、ROMモニタ520は、更新通知701に含まれるハッシュ値720に基づいて、ストレージ領域631に格納されているファームウェアFW3の検証を実行する。つまり、ROMモニタ520は、ファームウェアFW3の完全性を検証する。完全性の検証の結果が合格である場合、ROMモニタ520は、共有ストレージ620内の更新通知701をFW管理テーブル645内の対応する領域管理情報655の更新通知フィールド658に記録し、その領域管理情報655のフラグフィールド656に有効ビットをセットする。有効ビットは、領域管理情報655に対応するストレージ領域631に格納されているファームウェアの真正性が担保されていることを示す。ROMモニタ520は、新規に取得したファームウェアFW3にかかる領域管理情報655と、正常に動作することが確認されたファームウェアFW1にかかる領域管理情報655と、がFW管理テーブル645内に存在することを確認する。そして、ROMモニタ520は、主状態変数641を試行モードにセットする。これによって、動作モードが更新モードから試行モードに変更される。また、ROMモニタ520は、FWストレージ630に含まれる全てのストレージ領域631を書き込み禁止に設定する。そして、ROMモニタ520は、ファームウェアFW3を起動する。

ステップX08では、試行モードで起動されたファームウェアFW3は、ファームウェアFW3が正常に動作しているか否かの自己診断を実行することができる。

試行モードにおいてファームウェアの動作不良が確認された場合、再起動の後、ROMモニタ520によって代替のファームウェアが起動される。代替のファームウェアは、正常に動作することが既に確認されたファームウェアから選択される。よって、動作が回復する可能性を高めることができ、確実なロールバックが可能となる。つまり、可用性が向上する。

また、一般に、ロールバックを実行できる情報処理装置では、ロールバックの結果、非常に古く、かつ多くの脆弱性を持ったファームウェアが起動されてしまう虞がある。本実施形態では、ロールバック先のファームウェアである代替ファームウェアは、既にFWストレージ630に取得済みのものに限定される。そして、新たに取得されるファームウェアは、シーケンス番号に基づく検証により、最新のファームウェアであることが保証される。試行モードにおいて実行されるファームウェアは、既にFWストレージ630に取得済みのファームウェアまたは最新のファームウェアに限定され、それ以外のファームウェアが実行対象に含まれることはない。古いファームウェアが偽装して配布されたとしても、当該古いファームウェアを実行することは、更新通知701の署名730に基づく検証、FWのハッシュ値720に基づく検証、およびシーケンス番号710に基づく検証の組み合わせで排除される。FWストレージ630に格納されたファームウェアは、動作不良が確認されたものおよび古いものから順に破棄され、新しいファームウェアによって置き換えられていくため、非常に古く多くの脆弱性を持ったファームウェアが代替ファームウェアとして選択される可能性が低減される。

また、例えばファームウェアFW2の場合のように、真正性が担保されていても正常に動作することが確認できない場合がある。よって、X07によって起動されたファームウェアFW3は、正常に動作しない可能性がある。ファームウェアが正常に動作しなかった場合、ROMモニタ520は、正常に動作することが既に確認できた代替ファームウェア（図８の例えばファームウェアFW1）を起動する。これによって、端末装置100は、新しいファームウェアWF3に動作不良が発生した場合であっても、正常な動作を継続して、次の更新通知701の受信を行うことが可能となる。

また、新しく配布されたファームウェアFW3には、深刻な脆弱性がある可能性がある。深刻な脆弱性としては、例えば、ネットワーク経由で不正プログラムを受信して実行してしまう、いわゆる任意プログラム実行が挙げられる。ファームウェアFW3に任意プログラム実行の脆弱性がある場合、攻撃者によって、不揮発メモリ203の内容の書き換え（消去を含む）が実行される虞がある。もし代替ファームウェアが格納されたストレージ領域631が書き込み可能となっていた場合、代替ファームウェアが消去されることが懸念される。代替ファームウェアの消去を防止するための策としては、全てのストレージ領域631を書き込み禁止に設定することが考えられる。しかしながら、全てのストレージ領域631を書き込み禁止に設定すると、新しいファームウェアの格納が不可能である。

第１の実施形態では、ROMモニタ520は、原則として、全てのストレージ領域631を書き込み禁止に設定する。試行モードでは、如何なるファームウェアが起動されたとしても、何れのストレージ領域631にも書き込みを実行することができない。ROMモニタ520は、受信した更新通知701が正規の通知、つまり真正かつ最新の通知、であることが確認できたときに限定して、１つのストレージ領域631を書き込み可能に設定し、更新モードでファームウェアを起動する。更新モードで起動されたファームウェアは、新しいファームウェアを取得して、書き込み可能に設定されたストレージ領域631に格納することができる。

このように、第１の実施形態では、新しいファームウェアを格納することが可能であるとともに、任意プログラム実行による代替のファームウェアの破壊を防止することが可能である。

続いて、第１の実施形態にかかる端末装置100のより詳細な動作を説明する。

図９は、第１の実施形態にかかるROMモニタ520の動作の詳細を示すフローチャートである。

S01においてROMモニタ520が起動されると、ROMモニタ520は、主状態変数641を参照する（S02）。主状態変数641が試行モードを示す場合、ROMモニタ520は、正常動作判定処理を実行する（S03）。S03では、ROMモニタ520は、共有ストレージ620内の動作結果情報を参照する。

S04においては、ROMモニタ520は、最後に動作していたファームウェア（即ちアクティブFW格納先643によって特定されるファームウェアであって最後に動作していたファームウェア）が正常に動作したか否かを判定する。以降、アクティブFW格納先643によって特定されるファームウェアを、アクティブファームウェア、と表記する。さらに、ROMモニタ520が起動された時点において最後に動作していたアクティブファームウェアを、前（previous）ファームウェア、と表記する。

前ファームウェアが正常動作していないと判定された場合、S05において、ROMモニタ520は、ロールバック処理を実行する。ロールバック処理では、ROMモニタ520は、FWストレージ630内のアクティブファームウェアを前ファームウェアから代替ファームウェアに切り替える。より詳細には、ROMモニタ520は、アクティブFW格納先643として記録されている領域番号を、代替ファームウェアが格納されているストレージ領域631を示す領域番号で上書きする。

S05の後、ROMモニタ520は、ファームウェアの起動を実行する（S13）。S13では、アクティブFW格納先643が示すストレージ領域631に格納されているファームウェアが起動される。

前ファームウェアが正常動作していたとS04において判定された場合、ROMモニタ520は、S06において、更新通知取得判定を実行する。前ファームウェアが更新通知701を取得している場合、当該更新通知701は、共有ストレージ620に保存されている。共有ストレージ620に更新通知701がなければ、ROMモニタ520は、更新通知が取得されていないと判定し、S13の処理を実行する。共有ストレージ620に更新通知701があれば、ROMモニタ520は、更新通知が取得されたと判定し、S07の処理を実行する。

S07では、ROMモニタ520は、更新通知署名検証を実行する。更新通知署名検証では、ROMモニタ520は、更新通知701に含まれる署名730と、ROMモニタ専用ストレージ640に格納されている公開鍵と、を用いて、更新通知701に対し、真正性の検証を実行する。これによって、ROMモニタ520は、改竄された可能性がある更新通知を以降の処理で使用することを防ぐ。真正性の検証の結果が不合格（fail）である場合、ROMモニタ520は、S13の処理を実行する。真正性の検証の結果が合格（pass）である場合、ROMモニタ520は、S08の処理を実行する。

S08では、ROMモニタ520は、更新通知シーケンス番号検証を実行する。更新通知シーケンス番号検証では、ROMモニタ520は、更新通知701に含まれるシーケンス番号710が最大シーケンス番号642より大きいか否かを判定する。これによって、更新通知701が最新の更新通知であるか否かを判定することができる。また、過去に配布された更新通知が再利用されることを防ぐことが可能となる。更新通知701に含まれるシーケンス番号710が最大シーケンス番号642より大きくない場合、即ちシーケンス番号710を用いた検証の結果が不合格である場合、ROMモニタ520は、S13の処理を実行する。更新通知701に含まれるシーケンス番号710が最大シーケンス番号642より大きい場合、即ちシーケンス番号710を用いた検証の結果が合格である場合、ROMモニタ520は、S09の処理を実行する。

S09では、ROMモニタ520は、更新モード移行処理を実行する。ROMモニタ520は、主状態変数641を試行モードから更新モードに切り替える。そして、ROMモニタ520は、S13の処理を実行する。

S13では、ファームウェアが起動される。起動されたファームウェアが自発的にCPU200を再起動すると、ROMモニタ520が起動され（S01）、ROMモニタ520は、起動後、再び主状態変数641の参照を行う（S02）。

主状態変数641が更新モードを示す場合、つまりS09の処理によって主状態変数641として更新モードがセットされた後にROMモニタ520が再起動された場合、ROMモニタ520は、更新通知シーケンス番号検証を実行する（S10）。なお、S10の処理はS08の処理と同様である。たとえ、更新モード起動前に起動したアクティブファームウェアが攻撃者に乗っ取られ、共有ストレージ620内の更新通知701が攻撃者によって別の更新通知にすり替えられた場合であって、S10の検証によってすり替えを検出することが可能である。シーケンス番号710を用いた検証の結果が不合格である場合、ROMモニタ520は、S13の処理を実行する。シーケンス番号710を用いた検証の結果が合格である場合、ROMモニタ520は、S11の処理を実行する。

S11では、ROMモニタ520は、最新FW完全性検証を実行する。更新通知701は、更新先のファームウェアのハッシュ値720を含んでいる。また、更新モードで起動された前アクティブファームウェアは、当該更新先のファームウェアの取得を完了している。ROMモニタ520は、前アクティブファームウェアによって取得された当該更新先のファームウェアの完全性を、ハッシュ値720を用いて検証する。この検証の結果が合格である場合、当該更新先のファームウェアは正規のファームウェアであることがわかる。よって、万が一、不正なファームウェアがFWストレージ630に書き込まれたとしても、当該不正なファームウェアを実行してしまうことを防止することができる。ハッシュ値720を用いた検証の結果が不合格である場合、ROMモニタ520は、S13の処理を実行する。ハッシュ値720を用いた検証の結果が合格である場合、ROMモニタ520は、S12の処理を実行する。

S12では、ROMモニタ520は、試行モード移行処理を実行する。ROMモニタ520は、主状態変数641を更新モードから試行モードに切り替える。そして、ROMモニタ520は、S13の処理を実行する。

図１０は、第１の実施形態にかかる正常動作判定処理（図９のS03）の詳細を示すフローチャートである。

第１の実施形態では、判定に使用されるエビデンスを選択することが可能に構成されている。選択可能なエビデンスとしては、前ファームウェア自身の動作と、前ファームウェアと外部機器（例えば管理サーバ2）との通信と、が用意されている。

正常動作判定処理では、まず、ROMモニタ520は、正常動作の判定をどのエビデンスに基づいて実行するかを判定する（S031）。

S031においてファームウェア動作を選択した場合、ROMモニタ520は、共有ストレージ620にファームウェア動作にかかるエビデンスがあるか否か確認する（S032）。例えば、前ファームウェアが、不具合によって動作しない場合、または動作を中断した場合、共有ストレージ620に、動作しないことを示す動作結果情報や、動作を中断したことを示す動作結果情報をエビデンスとして書き込む。S032では、ROMモニタ520は、これらの動作結果情報が存在するか否かを確認する。

続いて、S033では、ROMモニタ520は、前ファームウェアの動作にかかるエビデンス（動作結果情報）を収集する。

S031において通信を選択した場合、ROMモニタ520は、共有ストレージ620に通信のエビデンスがあるか否かを確認する（S034）。例えば、前ファームウェアは、所定の通信先と通信をすることができた場合、通信先からのメッセージを受信し、当該メッセージを共有ストレージ620にエビデンスとして書き込む。

S034の後、ROMモニタ520は、エビデンスに対して署名検証を実行する（S035）。ROMモニタ520は、署名検証の結果によって、前ファームウェアの通信状況を取得する。署名検証の結果が合格であれば、通信に成功していることがわかる。署名検証の結果が不合格であれば、通信に失敗していることがわかる。なお、メッセージのリプレイ攻撃については、第5543949号公報に開示されている技術を適用することで対策することが可能である。

S033またはS035によって得られた情報に基づき、ROMモニタ520は、前アクティブファームウェアが正常に動作したか否かを判定する（S036）。S031においてファームウェア動作が選択された場合、S036では、ROMモニタ520は、S033において取得したエビデンスを使用する。前ファームウェアが、不具合によって動作しなかったり、動作を中断したりしたエビデンスがあれば、ROMモニタ520は、前ファームウェアは正常に動作しなかったと判定する。前ファームウェアが、不具合によって動作しなかったエビデンスと、動作を中断したエビデンスと、の何れも存在していない場合、ROMモニタ520は、前ファームウェアは正常に動作したと判定する。S031において通信が選択された場合、S036では、ROMモニタ520は、S035の署名検証の結果を使用する。署名検証の結果が不合格であれば、ROMモニタ520は、前ファームウェアは正常に動作しなかったと判定する。署名検証の結果が合格であれば、ROMモニタ520は、前ファームウェアは正常に動作したと判定する。S036が完了すると、S03の正常動作判定処理が終了し、S04の正常動作判定に制御が移行する。

なお、選択可能なエビデンスは上記された２つの例に限定されない。また、上記された２つのエビデンスの両方が、正常動作判定処理で使用されてもよい。また、エビデンスの取得方法は上記に限定されない。

図１１は、第１の実施形態にかかるロールバック処理（図９のS05）の詳細を示すフローチャートである。

ロールバック処理では、ROMモニタ520は、まず、FW管理テーブル645に記録された領域管理情報655のうちの優先順位フィールド657に付された優先順位に基づき、優先順位が高い順に領域管理情報655を検索する。その際、ROMモニタ520は、アクティブファームウェアにかかる領域管理情報655の次に高い優先順位が与えられた領域管理情報655を特定し、特定した領域管理情報655に対応するファームウェアを代替ファームウェアとして選択する（S051）。

S051に続いて、ROMモニタ520は、選択した代替ファームウェアをアクティブファームウェアとして設定する（S052）。つまり、ROMモニタ520は、代替ファームウェアが格納されたストレージ領域631を示す領域番号をアクティブFW格納先643として設定する。これによって、ロールバック処理が完了し、制御がS13に移行する。

図１２は、第１の実施形態にかかる更新モード移行処理（図９のS09）の詳細を示すフローチャートである。

更新モード移行処理では、前ファームウェアが正常に動作することが既に確認されているため、ROMモニタ520は、アクティブFW動作実績644に「１」をセットする（S91）。これによって、前ファームウェアは正常に動作したことが記憶される。

続いて、S92では、ROMモニタ520は、主状態変数641を試行モードから更新モードに変更する。

続いて、S93では、ROMモニタ520は、N個のストレージ領域631のうちの１つのストレージ領域631のアクセス制限を開放する。つまり、ROMモニタ520は、ファームウェアからの当該１つのストレージ領域631への書き込みを可能に設定する。書き込み可に設定するストレージ領域631は、例えば各ファームウェアに与えられた優先順位に基づいて選択され得る。即ち、ROMモニタ520は、FW管理テーブル645に記録された領域管理情報655のうちの優先順位フィールド657を参照することによって、最も低い優先順位がセットされた領域管理情報655が示すストレージ領域631を、書き込み可に設定することができる。なお、書き込み可に設定されるストレージ領域631の選択の方法はこれに限定されない。

そして、S94では、ROMモニタ520は、共有ストレージ620にFW取得要求を書き込む。これによって、次にファームウェア（即ちアクティブFW格納先643によって特定されるファームウェア）が起動されたときに、当該ファームウェアがFW取得要求に基づいて新しいファームウェアを取得できるようにする。そして、更新モード移行処理が完了し、制御がS13に移行する。

図１３は、第１の実施形態にかかる試行モード移行処理（図９のS12）の詳細を示すフローチャートである。

試行モード移行処理では、ROMモニタ520は、共有ストレージ620に格納されている更新通知701をROMモニタ専用ストレージ640内のFW管理テーブル645に１つの領域管理情報655として保存する（S121）。

続いて、S122では、ROMモニタ520は、S121で保存された領域管理情報655のフラグフィールド656に、有効ビットをセットする。これによって、当該領域管理情報655は、前ファームウェアが更新モードで取得した新しいファームウェアが真正性を有することを示す状態になる。

続いて、S123では、ROMモニタ520は、FW管理テーブル645を参照することによって、S91で動作実績が付与されたファームウェアに対応する更新通知があるか確認する。

続いて、S124では、ROMモニタ520は、FWストレージ630に、更新先のファームウェアと、動作実績が付与されたアクティブファームウェア、つまりS91で正常に動作することが確認されたアクティブファームウェアと、２つが少なくとも存在するか否かを判定する。更新先のファームウェアと、動作実績が付与されたアクティブファームウェアと、の一方または両方が存在しない場合（S124:No）、試行モード移行処理が完了する。

更新先のファームウェアと、動作実績が付与されたアクティブファームウェアと、の両方が存在する場合（S124:Yes）、ROMモニタ520は、更新先のファームウェアが最も高く、動作実績が付与されたアクティブファームウェアが更新先のファームウェアの次に高くなるように、FWストレージ630内のファームウェアに優先順位を付与する（S125）。これによって、動作実績が付与されたアクティブファームウェアを代替ファームウェアとして選択できる状態となる。なお、ROMモニタ520は、ファームウェア毎の優先順位を、対応する領域管理情報655の優先順位フィールド657に記録する。

なお、更新先のファームウェアと、動作実績が付与されたアクティブファームウェアと、の他のファームウェアに対する優先順位の与え方は、特定の方法に限定されない。例えばROMモニタ520は、更新先のファームウェアと、動作実績が付与されたアクティブファームウェアと、の他に、正常に動作することが確認されたファームウェアが複数存在する場合には、正常に動作することが確認された複数のファームウェアに対し、対応する更新通知701に含まれるシーケンス番号710が大きいほど優先順位を高くすることができる。また、ROMモニタ520は、正常に動作することが確認されたファームウェアの優先順位が、正常に動作することが確認できなかったファームウェアの優先順位よりも高くなるように、各ファームウェアに優先順位を与えることができる。

S125に続くS126では、ROMモニタ520は、新しいファームウェアをアクティブファームウェアとして設定する。つまり、ROMモニタ520は、新しいファームウェアが格納されたストレージ領域631の領域番号をアクティブFW格納先643にセットする。

続いて、S127では、ROMモニタ520は、主状態変数641を更新モードから試行モードに変更する。

続いて、S128では、ROMモニタ520は、FWストレージ630全体を書き込み禁止に設定する。そして、試行モード移行処理が完了し、制御がS13に移行する。

以上述べたように、第１の実施形態によれば、以下の動作が実行される。
ROMモニタ520の第１の動作モードである試行モードにおいては、直前に実行された第１のFWの実行結果を保持する第１の記憶手段の内容に基づいて、第１のFWがそなえる機能の有効性が判定される。前記第１のFW機能の有効性が確認できない場合には、第３の記憶手段に保持された識別番号に関わらず、既に検証済みであるFW格納領域に格納済みのひとつもしくは複数のFWから、所定の優先順位にしたがって一つのFWを選択して実行する代替FW実行を行う。第１のFW機能の有効性が確認できた場合において、第１のFWが取得した第２の記憶手段に保存されたFW更新通知の検証を行う。FW更新通知の識別番号が、第３の記憶手段に保持された最大識別番号より大きい場合に、動作モードを第２のモードに変更して第１のFWを実行する。
ROMモニタの第２の動作モードにおいては、第２の記憶手段に保存されたFW更新通知の検証ならびに、直前の第１のFW実行により取得され、FW格納領域に格納済み第３のFWについて、FW更新通知に基づく検証に成功し、なおかつ第３の更新通知の識別番号が第３の記憶手段に記憶された識別番号より大きいとき、第２の記憶手段に保存されたFW更新通知を、第３のFWの格納領域に対応する署名テーブルのエントリに格納する。第２の動作モードにおける全ての検証に成功したときのみ実行FWを第３のFWに、動作モードを第１の試行モードにそれぞれ変更してFWを実行する。前記前記第２の動作モードにおける全ての検証のいずれかに失敗した場合、前記第１のFWを再度実行する。

これにより、以下の３点の障害および攻撃への耐性が得られる。第１に格納領域に保存されたFWが実行可能となるためには、必ずモニタプログラムによる署名検証が行われる。このため偽造されたFWを取得した場合およびFWの取得後にFWが内包するセキュリティ脆弱性に起因したサイバー攻撃を受け、取得したFWが改ざんを受けた場合のいずれの場合であっても不正を検出し、偽造FWの実行を未然に防止できる。
第２に更新FWに配布前に見過ごされた不具合があった場合でも、モニタプログラムが更新FWの有効性を確認し、有効性が確認できない場合に限ってより古い識別番号を持つFWによる代替実行を行うことで、更新FWに不具合があった場合でも情報装置の機能が維持される。このとき代替実行の対象となるのは過去に検証を行ったうえで格納されたFWであるため、やはり偽造FWの実行は防止される。
第３に、いったんより古い識別番号を持つFWが実行された場合であっても、当該FWが新たに取得する更新通知および更新FWについては、既に実行した最大識別番号より大きいもののみを検証成功の条件とすることにより、より世代が古くしたがって多くのセキュリティ脆弱性を内包しているであろうFWの新規実行を防止できる。
この可用性および完全性に関わる３点の効果は、相互にトレードオフがあり、すべてを成立させる仕組みは自明ではないが、本発明にかかるメカニズムにより全てを満たすことができる。

また、第１の実施形態によれば、FWストレージ630は、複数のストレージ領域631を備えている。試行モードでは、複数のストレージ領域631の全ては書き込み禁止に設定される。更新モードでは、複数のストレージ領域631のうちの選択された１つのストレージ領域631のみが書き込み可に設定される。更新モードで起動された第４のファームウェアは、取得した第３のファームウェアを、書き込み可に設定されたストレージ領域631に書き込む。

よって、FWストレージ630への書き込みが可能な状況は、正常に動作することが既に確認されたファームウェアが更新モードで起動された場合のみに限定される。よって、不正なファームウェアがFWストレージ630の内容を書き換えたり消去したりすることを防止することが可能となる。

（第２の実施形態）
第１の実施形態によれば、前ファームウェアが正常に動作するかぎり、前ファームウェアが致命的な脆弱性を有する場合であっても、前ファームウェアがロールバック先として選択されてしまう。

第２の実施形態では、更新通知にロールバック先のファームウェアの情報が含められる。これによって、管理サーバは、脆弱性を有しない（あるいは脆弱性が少ない）ファームウェアをロールバック先として指定することが可能である。

なお、第１の実施形態と同じ構成については説明を省略するか、または簡略的に説明する。以降では、第２の実施形態にかかる端末装置を端末装置100aと表記する。

図１４は、第２の実施形態にかかる更新通知702のデータ構成例を示す模式的な図である。更新通知702は、シーケンス番号711と、更新先のファームウェアのハッシュ値712と、ロールバック先のファームウェアが配布されたときの更新通知702のシーケンス番号713と、署名714と、が連接されて構成されたデータ構成を有している。署名714は、シーケンス番号711と、ハッシュ値712と、シーケンス番号713と、からなるメッセージに対して所定のアルゴリズムを用いて生成されたものである。第２の実施形態にかかる更新通知702は、シーケンス番号713が含まれている点で、第１の実施形態にかかる更新通知701と異なっている。

更新通知702が上記のようなデータ構成を備えているため、管理サーバ2は、ロールバック先のファームウェアを指定することが可能である。例えば、管理サーバ2は、多数の端末装置100aの動作実績を定期的に収集することで、過去に配布したファームウェアのうちの、安全なファームウェア、つまり正常に動作しかつ脆弱性が出来るだけ少ないファームウェア、を特定する。管理サーバ2は、新しいファームウェアを配布する際には、安全なファームウェアに対応した過去の更新通知のシーケンス番号711を新しいファームウェアのための更新通知702にシーケンス番号713として付すことで、正常に動作することが既に確認された安全なファームウェアをロールバック先として指定することができる。

なお、ロールバック先のファームウェアの指定方法は、シーケンス番号713を用いた方法だけに限定されない。例えば、更新通知702は、シーケンス番号713に替えて、ロールバック先のファームウェアのハッシュ値を含むデータ構成を備えていてもよい。

図１５は、第２の実施形態にかかる端末装置100aにおいてCPU200が実現する機能と不揮発メモリ203の概略構成とを説明するための模式的な図である。

命令実行ユニット201は、ROMモニタプログラム650aを実行することによって、ROMモニタ520aとして機能する。また、命令実行ユニット201は、ファームウェアを実行することによって、RTOS510として機能する。

不揮発メモリ203には、RTOS用ストレージ610、共有ストレージ620、FWストレージ630a、およびROMモニタ専用ストレージ640がアロケートされている。

FWストレージ630aは、２つのストレージ領域631、つまりストレージ領域631-1と、ストレージ領域631-2と、を備える。２つのストレージ領域631のそれぞれには、１つのファームウェアが格納され得る。第２の実施形態のFWストレージ630aは、ストレージ領域631を２つしか備えていない点で、第１の実施形態と異なる。

続いて、図１６を参照して、第２の実施形態にかかる端末装置100aの動作例を説明する。図１６は、第２の実施形態にかかる端末装置100aの動作例を示すシーケンス図である。

電源投入後のステップX09では、ROMモニタ520aは主状態変数641を参照し、ファームウェアの予定される動作モードが試行モードであることを知る。ROMモニタ520aは、ファームウェアFW3を試行モードで起動する。

ステップX10においては、ファームウェアFW3は、新しいファームウェアFW4にかかる更新通知702を受信する。ステップX10において受信した更新通知702は、ロールバック先のファームウェアとしてファームウェアFW1を指定している。なお、更新先のファームウェアFWiにかかる更新通知702であって、ファームウェアFWjをロールバック先のファームウェアとして指定する更新通知702を、更新通知（FWj,FWi）と表記する。ステップX10では、ファームウェアFW3は、更新通知（FW1,FW4）を受信する。ファームウェアFW3は、更新通知（FW1,FW4）を共有ストレージ620に保存する。そして、ファームウェアFW3は、CPU200を再起動する。

ステップX11では、ROMモニタ520aが、共有ストレージ620に書き込まれた動作結果情報に基づいてファームウェアFW3が正常に動作したことを確認する。また、ROMモニタ520aは、更新通知（FW1,FW4）に対し、署名714を用いた検証と、シーケンス番号を用いた検証を行う。両検証の結果が合格である場合、ROMモニタ520aは、更新先のファームウェアFW4と、ロールバック先のファームウェアFW1と、がFWストレージ630に保存されているか否かを確認する。そして、FWストレージ630にはアクティブファームウェアであるファームウェアFW3と、ファームウェアFW3の直前に配布されたファームウェアFW2と、しか保存されておらず、ファームウェアFW1、FW4はともに保存されていないことが判明する。そこで、ROMモニタ520aは、ロールバック先として指定されたファームウェアFW1の取得を試みる。ファームウェアFW3は正常に動作することが確認済みであるため、ファームウェアFW1の取得のために、ファームウェアFW3を利用できる。ROMモニタ520aは、２つのストレージ領域631のうちのファームウェアFW3が格納されたストレージ領域631でないストレージ領域631（即ちファームウェアFW2が格納されているストレージ領域631）を、書き込み可に設定する。そして、ROMモニタ520aは、次回FW取得要否646に「１」をセットする。このとき、ROMモニタ520aは、次回の取得対象が更新通知で指定された更新FWとロールバックFWのいずれかであるかを示す情報を次回FW取得要否646に含める。そして、ROMモニタ520aは、主状態変数641を更新モードにセットする。これによって、動作モードが試行モードから更新モードに変更される。ROMモニタ520aは、共有ストレージ620にFW取得要求を書き込む。FW取得要求は、取得対象のファームウェア（即ちここではロールバック先のファームウェアFW1）を示す情報を含んでいてもよい。そして、ROMモニタ520aは、正常に動作することが既に確認されたファームウェアFW3を起動する。

ステップX12では、更新モードで起動されたファームウェアFW3は、共有ストレージ620内のFW取得要求に応じて、管理サーバ2からファームウェアFW1を取得する。もし、ファームウェアFW1が発行されたときの更新通知702を端末装置100aが有さない場合には、ファームウェアFW3は、ファームウェアFW1が発行されたときの更新通知702（つまりシーケンス番号713が示す更新通知702）も取得する。ファームウェアFW3は、取得したファームウェアFW1を、FWストレージ630内の書き込み可に設定されているストレージ領域631に格納する。そして、ファームウェアFW3は、CPU200の再起動を行う。

ステップX13では、ROMモニタ520aは、ファームウェアFW3が正常に動作したことを確認する。また、ROMモニタ520aは、ステップX11における動作と同様に、ファームウェアFW1およびファームウェアFW4がFWストレージ630に保存されているか否かを確認する。この確認によって、ロールバック先のファームウェアFW1が保存されているが、更新先のファームウェアFW4がまだ保存されていないことが判明する。ROMモニタ520aは、ファームウェアFW1の検証を実行し、当該検証に成功する。ROMモニタ520aは、ファームウェアFW1が格納されたストレージ領域631を示す領域番号をアクティブFW格納先643にセットして、FW取得要否646に、ファームウェアFW4を示す情報を含める。また、ROMモニタ520aは、共有ストレージ620にFW取得要求を書き込む。FW取得要求は、取得の対象のファームウェア（即ちここではファームウェアFW4）を示す情報を含んでいてもよい。そして、ROMモニタ520aは、ファームウェアFW3が格納されているストレージ領域631を書き込み禁止から書き込み可に設定し、ファームウェアFW1が格納されているストレージ領域631を書き込み禁止に設定し、ファームウェアFW1を起動する。引き続きファームウェアの取得を実行するために、動作モードは、更新モードに維持される。

ステップX14では、更新モードで起動されたファームウェアFW1は、共有ストレージ620内のFW取得要求に応じて、管理サーバ2から新しいファームウェアFW4を取得する。ファームウェアFW1は、取得したファームウェアFW4を、FWストレージ630内の書き込み可に設定されているストレージ領域631に格納する。そして、ファームウェアFW1は、CPU200の再起動を行う。

ステップX15では、ROMモニタ520aは、ファームウェアFW1が正常に動作したことを確認する。また、ROMモニタ520aは、ステップX11における動作と同様に、新しいファームウェアFW4と、ロールバック先のファームウェアFW1がFWストレージ630に保存されているか否かを確認する。この確認によって、ロールバック先のファームウェアFW1および新しいファームウェアFW4がともに保存されていることが判明する。ROMモニタ520aは、ファームウェアFW4の検証を実行し、当該検証に成功する。ROMモニタ520aは、ステップX10において取得された更新通知702を、FW管理テーブル645に領域管理情報655として記録して、当該領域管理情報655のフラグフィールド656に有効ビットをセットする。そして、ROMモニタ520aは、ステップX10において取得された更新通知702に基づき、ファームウェアFW1を代替ファームウェアとして使用できるようにする。そして、ROMモニタ520aは、主状態変数641を試行モードにセットする。これによって、動作モードが更新モードから試行モードに変更される。また、ROMモニタ520aは、FWストレージ630に含まれる全てのストレージ領域631を書き込み禁止に設定する。そして、ROMモニタ520aは、ファームウェアFW4を起動する。

ステップX16では、試行モードで起動されたファームウェアFW4が動作を開始する。

上記シーケンスが想定する状況は、以下の通りである。ファームウェアFW3およびファームウェアFW3の前に配布されたファームウェアFW2は、ファームウェアFW1に対して機能的にいくつかの改良がなされており正常動作はするものの、深刻なセキュリティ脆弱性があることが判明している。つまり、ファームウェアFW2、FW3を動作させ続けると攻撃を受ける恐れがある。よって、ファームウェアFW3が動作している時点において、管理サーバ2は、ファームウェアFW1をロールバック先に指定したうえで、脆弱性を修正したファームウェアFW4への更新を行う。しかしながら、端末装置100aは、ストレージ領域631を２つしか有していないため、ファームウェアFW2からファームウェアFW3への更新の過程でファームウェアFW1は消去されてしまっている。よって、ファームウェアFW4への更新の際には、端末装置100aは、ファームウェアFW4に加えて、ロールバック先のファームウェアFW1を取得する。

なお、ファームウェアFW1,FW2,FW3の機能および脆弱性に関する想定は、第１の実施形態におけるものとは異なる。第１の実施形態においては、ファームウェアFW2は正常に動作せず、ファームウェアFW1とファームウェアFW3とが試行モードにおいて実行せしめられた。これに対し、第２の実施形態ではファームウェアFW2が正常に動作して、その後にファームウェアFW3への更新が行われているため、ファームウェアFW3への更新の際に、ファームウェアFW1は消去される。

上述のように第２の実施形態では、ROMモニタ520aは、更新通知702に記載されている新しいファームウェアの情報とロールバック先のファームウェアの情報とをもとに、ファームウェアの優先順位を決定する。第１の実施形態と異なり、直前まで動作したファームウェアが必ずしもロールバック先のファームウェアとして設定されるとは限らない。よって、新しいファームウェアに加えてロールバック先のファームウェアの取得が必要になる場合がある。更新通知702にロールバック先のファームウェアを指定する情報として、ロールバック先のファームウェアにかかる更新通知702を示すシーケンス番号713が含まれているため、シーケンス番号713が示す更新通知702に含まれたハッシュ値712を用いることで、ロールバック先のファームウェアの検証が可能である。

続いて、第２の実施形態にかかる端末装置100のより詳細な動作を説明する。

図１７は、第２の実施形態にかかるROMモニタ520aの動作の詳細を示すフローチャートである。

第２の実施形態のROMモニタ520aの動作は、S09の処理に代えてS109が実行され、S11に代えてS111が実行され、S12に代えてS112が実行される点で、図９に示された第１の実施形態のROMモニタ520の動作と異なる。以下に、第１の実施形態と異なる動作について説明する。

S109、即ち更新モード移行処理では、ロールバック先のファームウェアがFWストレージ630に保存されているか否かに応じて、新しいファームウェアを取得するか、当該新しいファームウェアに先立ってロールバック先のファームウェアを取得するか、が決定される。

図１８は、第２の実施形態にかかる更新モード移行処理（図１７のS109）の詳細を示すフローチャートである。

更新モード移行処理では、ROMモニタ520aは、まず、更新通知702に含まれるシーケンス番号713に基づいてロールバック先のファームウェアを特定し、当該ロールバック先のファームウェアがFWストレージ630に保存されているか否かを判定する（S1091）。

ロールバック先のファームウェアがFWストレージ630に保存されている場合には（S1091:Yes）、ROMモニタ520aは、ロールバック先のファームウェアをアクティブファームウェアとして設定し、新しいファームウェアを取得対象として設定する（S1092）。

続いて、S1093では、ROMモニタ520aは、２つのストレージ領域631のうちのアクティブファームウェアでないファームウェア（即ち非アクティブファームウェア）が格納されているストレージ領域631のアクセス制限を開放する。つまり、ROMモニタ520aは、非アクティブファームウェアが格納されているストレージ領域631を書き込み可に設定する。

続いて、S1094では、ROMモニタ520aは、主状態変数641を試行モードから更新モードに変更する。

続いて、S1095では、ROMモニタ520aは、共有ストレージ620にFW取得要求を書き込む。FW取得要求は、取得対象のファームウェアを示す情報を含みうる。これによって、次にファームウェア（即ちアクティブファームウェア）が起動されたときに、当該ファームウェアがFW取得要求に基づいて取得対象のファームウェアを取得できるようにする。そして、更新モード移行処理が完了し、S13に制御が移行する。

ロールバック先のファームウェアがFWストレージ630に保存されてない場合には（S1091:No）、ROMモニタ520aは、ロールバック先のファームウェアを取得対象として設定する（S1096）。そして制御がS1093に移行する。

ロールバック先のファームウェアが指定された更新の際には、指定されたロールバック先のファームウェア以外の既存のファームウェアになんらかの不具合があることが想定される。第２の実施形態の端末装置100aは、ロールバック先のファームウェアがFWストレージ630に保存されていない場合、更新先のファームウェアに先んじてロールバック先のファームウェアを取得し、ロールバック先のファームウェアに従って更新先のファームウェアを取得するように構成されている。よって、ロールバック先のファームウェア以外のファームウェアに不具合があったとしても、不具合があるファームウェアを用いることなく更新先のファームウェアを取得することが可能である。

図１７に示されたS111では、指定ファームウェア入手判定が実行される。
図１９は、第２の実施形態にかかる指定ファームウェア入手判定（図１７のS111）の詳細を示すフローチャートである。

指定ファームウェア入手判定では、まず、ROMモニタ520aは、前ファームウェアはロールバック先のファームウェアであるか否かの判定を実行する（S1111）。

前ファームウェアがロールバック先のファームウェアでない場合（S1111:No）、ROMモニタ520aは、ロールバック先のファームウェアがFWストレージ630に保存されているか否かを判定する（S1112）。

ロールバック先のファームウェアがFWストレージ630に保存されていない場合（S1112:No）、ROMモニタ520aは、ロールバック先のファームウェアを取得対象として設定してFW取得要求を共有ストレージ620に書き込む（S1113）。そして、指定ファームウェア入手判定が完了して、S13に制御が移行する。

ロールバック先のファームウェアがFWストレージ630に保存されている場合（S1112:Yes）、ROMモニタ520aは、ロールバック先のファームウェアが格納されているストレージ領域631を書き込み禁止に設定し（S1114）、ロールバック先のファームウェアをアクティブファームウェアとして設定する（S1115）。

続いて、S1116では、ROMモニタ520aは、非アクティブファームウェアが格納されているストレージ領域631のアクセス制限を開放する。

続いて、S1117では、ROMモニタ520aは、更新先のファームウェアを取得対象として設定してFW取得要求を共有ストレージ620に書き込む。そして、動作モードが更新モードに維持された状態で、指定ファームウェア入手判定が完了して、S13に制御が移行する。

前ファームウェアがロールバック先のファームウェアである場合（S1111:Yes）、ROMモニタ520aは、更新先のファームウェアがFWストレージ630に保存されているか否かを判定する（S1118）。

更新先のファームウェアがFWストレージ630に保存されてない場合（S1118:No）、更新先のファームウェアが取得対象として維持され、かつ動作モードが更新モードに維持された状態で、指定ファームウェア入手判定が完了して、S13に制御が移行する。

更新先のファームウェアがFWストレージ630に保存されている場合（S1118:Yes）、試行モード移行処理（図１７のS112）に制御が移行する。

このように、ROMモニタ520aは、更新先のファームウェアとロールバック先のファームウェアとがFWストレージ630に保存されているか否かを判定する。そして、これらのうち未だ保存されていないファームウェアがある場合には、ROMモニタ520aは、更新モードを維持して当該ファームウェアの取得を行う。

なお、S1112では、ROMモニタ520aは、ロールバック先のファームウェアの完全性の検証を実行することができる。ロールバック先のファームウェアがFWストレージ630に保存されていたとしても、ロールバック先のファームウェアの完全性の検証の結果が不合格であれば、S1113に制御が移行する。ロールバック先のファームウェアの完全性の検証の結果が合格であれば、S1114に制御が移行する。

ロールバック先のファームウェアの完全性の検証には、ロールバック先のファームウェアにかかる更新通知702、即ちシーケンス番号713が示す更新通知702、に含まれるハッシュ値を使用することができる。

また、S1118では、ROMモニタ520aは、更新先のファームウェアの完全性の検証を実行することができる。更新先のファームウェアがFWストレージ630に保存されていたとしても、更新先のファームウェアの検証の結果が不合格であれば、更新先のファームウェアが取得対象として維持され、かつ動作モードが更新モードに維持された状態で、S13に制御が移行する。更新先のファームウェアの完全性の検証の結果が合格であれば、試行モード移行処理（図１７のS112）に制御が移行する。

なお、更新先のファームウェアの完全性の検証には、更新通知702に含まれるハッシュ値を使用することができる。

図２０は、第２の実施形態にかかる試行モード移行処理（図１７のS112）の詳細を示すフローチャートである。

試行モード移行処理では、ROMモニタ520aは、共有ストレージ620に格納されている更新通知702をROMモニタ専用ストレージ640内のFW管理テーブル645に１つの領域管理情報655として保存する（S1121）。

S1122では、ROMモニタ520aは、S1121で保存された領域管理情報655のフラグフィールド656に、有効ビットをセットする。これによって、当該領域管理情報655は、前ファームウェアが更新モードで取得した更新先のファームウェアが真正性を有することを示す状態になる。

S1123では、ROMモニタ520aは、更新先のファームウェアをアクティブファームウェアとして設定する。つまり、ROMモニタ520aは、更新先のファームウェアが格納されたストレージ領域631の領域番号をアクティブFW格納先643にセットする。

S1124では、ROMモニタ520aは、主状態変数641を更新モードから試行モードに変更する。

S1125では、ROMモニタ520aは、FWストレージ630全体を書き込み禁止に設定する。そして、試行モード移行処理が完了する。

第２の実施形態によれば、試行モード移行処理のスタートの時点においては、FWストレージ630には、更新先のファームウェアと、ロールバック先のファームウェアと、のみが格納されている。よって、各ファームウェアの優先順位は一意に定まる。つまり、更新先のファームウェアの優先順位が最も高く、ロールバック先のファームウェアの優先順位は新しいファームウェアの次に高い。ROMモニタ520aは、優先順位フィールド657に順位を記録してもよいし、記録しなくてもよい。

このように、第２の実施形態によれば、更新通知702は、更新先のファームウェアに加えて、ロールバック先のファームウェアである第５のファームウェアの明示的な指定を含む。

管理サーバ2は、脆弱性を有しない（あるいは脆弱性が少ない）ファームウェアをロールバック先として指定することで、脆弱性を有しない（あるいは脆弱性が少ない）ファームウェアの動作によって更新先のファームウェアを取得することが可能となる。

より具体的には、第２の実施形態によれば、ROMモニタ520aは、ロールバック先のファームウェア（第５のファームウェア）がFWストレージ630aに保存されていない場合、正常に動作することが既に確認された前ファームウェアである第２のファームウェアを更新モードで起動する。更新モードで起動された第２のファームウェアは、第５のファームウェアを取得する。ROMモニタ520aは、取得した第５のファームウェアを検証し、検証の結果が合格である場合に、正常に動作することが既に確認された第４のファームウェアとして第５のファームウェアを更新モードで起動する。更新モードで起動された第４のファームウェアは、更新先のファームウェアである第３のファームウェアを取得する。

よって、管理サーバ2は、脆弱性を有しない（あるいは脆弱性が少ない）ファームウェアをロールバック先として指定することで、脆弱性を有しない（あるいは脆弱性が少ない）ファームウェアの動作によって更新先のファームウェアを取得することが可能となる。
代替FWは更新FWの直前に配布されたその時点での最新FWとすることが一般的と考えられるが、明示的に代替FWを指定することにより、最新の識別番号を持つFWにセキュリティ脆弱性が含まれていたとしても、それに代わる代替FWを取得実行することが可能となる。

（第３の実施形態）
第２の実施形態では、FWストレージ630aは、２つのストレージ領域631のみを備えた。２つのストレージ領域631のうち、１つのストレージ領域631は実行中のファームウェアで占有されているため、他の１つのストレージ領域631しか空けることができない。よって、端末装置100aがロールバック先のファームウェアを保持していない場合には、ロールバック先のファームウェアおよび更新先のファームウェアのそれぞれを取得する毎に再起動が必要である。

第３の実施形態では、FWストレージ630は、３以上のストレージ領域631を有する。これによって、端末装置は、２以上のストレージ領域631を空けることができる。端末装置は、ロールバック先のファームウェアを保持していない場合、ロールバック先のファームウェアおよび更新先のファームウェアの両方を取得して、それぞれをストレージ領域631に格納する。これによって、第２の実施形態に比べて、再起動の回数を抑制することができる。

なお、第３の実施形態によれば、第２の実施形態と比較して、ストレージ領域631を多く必要とするが、更新に要する手順を簡略化し、２世代以上前にさかのぼるロールバックにおける通信量を削減することができる。

以降、他の実施形態（第１の実施形態または第２の実施形態）と同じ構成については説明を省略するか、または簡略的に説明する。以降では、第３の実施形態にかかる端末装置を端末装置100bと表記する。端末装置100bは、第２の実施形態と同じデータ構成を有する更新通知702（図１４参照）を管理サーバ2から受信する。

図２１は、第３の実施形態にかかる端末装置100bにおいてCPU200が実現する機能と不揮発メモリ203の概略構成とを説明するための模式的な図である。

命令実行ユニット201は、ROMモニタプログラム650bを実行することによって、ROMモニタ520bとして機能する。また、命令実行ユニット201は、ファームウェアを実行することによって、RTOS510として機能する。

不揮発メモリ203には、RTOS用ストレージ610、共有ストレージ620、FWストレージ630、およびROMモニタ専用ストレージ640がアロケートされている。

FWストレージ630は、複数のストレージ領域631、ここでは例えばN個のストレージ領域631-1～631-Nを備える。つまり、FWストレージ630は、第１の実施形態と同様の構成を備える。

続いて、図２２を参照して、第３の実施形態にかかる端末装置100bの動作例を説明する。図２２は、第３の実施形態にかかる端末装置100bの動作例を示すシーケンス図である。

電源投入後のステップX09では、ROMモニタ520bは主状態変数641を参照し、ファームウェアの予定される動作モードが試行モードであることを知る。ROMモニタ520bは、ファームウェアFW5を試行モードで起動する。

ステップX18では、試行モードで起動されたファームウェアFW5は、更新先のファームウェアFW6にかかる更新通知702である更新通知（FW1,FW6）を受信する。この更新通知702は、ロールバック先のファームウェアとしてファームウェアFW1を指定している。ファームウェアFW5は、この更新通知702を共有ストレージ620に保存する。そして、ファームウェアFW5は、CPU200を再起動する。

ステップX19では、ROMモニタ520bは、共有ストレージ620に書き込まれた動作結果情報に基づいてファームウェアFW5が正常に動作したことを確認する。また、ROMモニタ520bは、更新通知（FW1,FW6）に対し、署名714を用いた検証と、シーケンス番号711を用いた検証を行う。両検証の結果が合格である場合、２つのストレージ領域631を書き込み可に設定したり、ファームウェアFW1とファームウェアFW5とを取得対象として設定したりし、動作モードを試行モードから更新モードに変更する。そして、ROMモニタ520bは、正常に動作することが既に確認されたファームウェアFW5を起動する。

ステップX20では、更新モードで起動されたファームウェアFW5は、管理サーバ2からファームウェアFW1とファームウェアFW6とを取得する。ファームウェアFW5は、取得したファームウェアFW1およびファームウェアFW6をFWストレージ630に保存する。そして、ファームウェアFW5は、CPU200の再起動を行う。

ステップX21では、ROMモニタ520bは、取得したファームウェアFW1およびファームウェアFW6の検証を実行する。そして、ROMモニタ520bは、動作モードを更新モードから試行モードに変更する。そして、ROMモニタ520bは、ファームウェアFW1を代替ファームウェアとして設定し、ファームウェアFW6を起動する。

ステップX22では、試行モードで起動されたファームウェアFW6が動作を開始する。

上記シーケンスが想定する状況は、以下の通りである。端末装置100bは、ステップX17までは、ファームウェアFW4がロールバック先のファームウェアとして設定され、ファームウェアFW5がアクティブファームウェアとして設定された状態で動作している。そして、ファームウェアFW2～FW5には深刻なセキュリティ脆弱性があることが判明したことで、ファームウェアFW1をロールバック先のファームウェアとし、かつ脆弱性を修正したファームウェアFW6を更新先のファームウェアとした更新が計画された。その結果、管理サーバ2は、更新通知（FW1,FW6）を発行した。しかしながら、端末装置100bは、ファームウェアFW3,FW4,FW5を保持しているが、ファームウェアFW1を保持していなかった。よって、端末装置100bは、ファームウェアFW6の取得とともにファームウェアFW1の再取得を行った。

なお、ファームウェアFW3,FW4の機能および脆弱性に関する想定は、第２の実施形態におけるものとは異なる。第２の実施形態では、ファームウェアFW3は脆弱性があると見なされ、ファームウェアFW1,FW4が試行モードにおいて実行された。第３の実施形態では、ファームウェアFW3が正常に動作し、その後、ファームウェアFW4、FW5への更新が行われたため、ファームウェアFW1が消去されたことが想定されている。

第２の実施形態においては、ロールバック先のファームウェアの取得の際と、更新先のファームウェアの取得の際と、のそれぞれにおいて１回ずつ、更新モードでのファームウェアの起動が必要であった（図１６のX11およびX13参照）。これに対し、第３の実施形態では、更新モードでのファームウェアの起動は１回で済む（図２２のX19参照）。

図２３は、第３の実施形態にかかるROMモニタ520bの動作の詳細を示すフローチャートである。

第３の実施形態のROMモニタ520bの動作は、S109の処理に代えてS209が実行され、S111に代えてS211が実行される点で、図１７に示された第２の実施形態のROMモニタ520bの動作と異なる。以下に、第２の実施形態と異なる動作について説明する。

図２４は、第３の実施形態にかかる更新モード移行処理（図２３のS209）の詳細を示すフローチャートである。

更新モード移行処理では、ROMモニタ520bは、まず、更新通知702に含まれるシーケンス番号713に基づいてロールバック先のファームウェアを特定し、当該ロールバック先のファームウェアがFWストレージ630に保存されているか否かを判定する（S2091）。

ロールバック先のファームウェアがFWストレージ630に保存されている場合には（S2091:Yes）、ROMモニタ520bは、ロールバック先のファームウェアをアクティブFWとして設定する（S2092）。

続いて、S2093では、ROMモニタ520bは、１つのストレージ領域631のアクセス制限を開放する。ROMモニタ520bは、N個のストレージ領域631のうちの例えば優先順位が最も低いファームウェアが格納されたストレージ領域631を選択して、選択したストレージ領域631を書き込み可に設定する。

ロールバック先のファームウェアがFWストレージ630に保存されていない場合には（S2091:No）、ROMモニタ520bは、２つのストレージ領域631のアクセス制限を開放する。ROMモニタ520bは、N個のストレージ領域631のうちの例えば優先順位が最も低い２つのファームウェアが格納された２つのストレージ領域631を選択して、選択した２つのストレージ領域631を書き込み可に設定する。

S2093またはS2094の後、ROMモニタ520bは、主状態変数641を試行モードから更新モードに変更する（S2095）。

S2095では、ROMモニタ520bは、共有ストレージ620にFW取得要求を書き込む。そして、更新モード移行処理が完了し、S13に制御が移行する。

なお、第２の実施形態と同様、FW取得要求は、取得対象のファームウェアを示す情報を含んでいてもよい。例えばS2093を経由してS2095が実行された場合、ROMモニタ520bは、新しいファームウェアを示す情報をFW取得要求に与える。S2094を経由してS2095が実行された場合、ROMモニタ520bは、ロールバック先のファームウェアを示す情報と新しいファームウェアを示す情報とをFW取得要求に与える。後に更新モードで起動されたファームウェアは、取得対象のファームウェアをFW取得要求に基づいて特定することができる。

図２５は、第２の実施形態にかかる指定ファームウェア入手判定（図２３のS211）の詳細を示すフローチャートである。

指定ファームウェア入手判定では、ROMモニタ520bは、更新通知702に含められた更新先のファームウェアの情報およびロールバック先のファームウェアの情報に基づいて、更新先のファームウェアおよびロールバック先のファームウェアがともにFWストレージ630に保存されているか否かを判定する（S2111）。

更新先のファームウェアおよびロールバック先のファームウェアのうち、まだ保存されていないファームウェアがある場合（S2111:No）、ROMモニタ520bは、まだ保存されていないファームウェアを取得対象として設定してFW取得要求を共有ストレージ620に書き込む（S2112）。そして、指定ファームウェア入手判定が完了して、S13に制御が移行する。

更新先のファームウェアおよびロールバック先のファームウェアがともにFWストレージ630に保存されている場合（S2111:Yes）、指定ファームウェア入手判定が完了して、S112に制御が移行する。

なお、S2111では、ROMモニタ520bは、更新先のファームウェアの完全性の検証およびロールバック先のファームウェアの完全性の検証を実行することができる。ロールバック先のファームウェアがFWストレージ630に保存されていたとしても、ロールバック先のファームウェアの完全性の検証の結果が不合格であれば、S2112に制御が移行して、ロールバック先のファームウェアが取得対象とされる。また、更新先のファームウェアがFWストレージ630に保存されていたとしても、更新先のファームウェアの検証の結果が不合格であれば、S2112に制御が移行して、更新先のファームウェアが取得対象とされる。ロールバック先のファームウェアの完全性の検証の結果および更新先のファームウェアの完全性の検証の結果がともに合格であれば、S112に制御が移行する。

端末装置100bでは、通信の不具合や、攻撃者によるすり替えによって、正規のファームウェアFW1,FW6を取得できない可能性がある。端末装置100bは、更新通知（FW1,FW6）に基づき、それぞれのファームウェアに対して完全性の検証を行い、完全性の検証の結果が合格になるまで、ファームウェアFW1,FW6の取得を繰り返す。

このように、第３の実施形態によれば、ROMモニタ520bは、ロールバック先のファームウェア（第５のファームウェア）がFWストレージ630に保存されていない場合、正常に動作することが既に確認された前ファームウェアである第２のファームウェアを更新モードで起動する。更新モードで起動された第２のファームウェアは、更新先の第３のファームウェアと、第５のファームウェアとを取得する。

よって、管理サーバ2は、脆弱性を有しない（あるいは脆弱性が少ない）ファームウェアをロールバック先として指定することで、脆弱性を有しない（あるいは脆弱性が少ない）ファームウェアの動作によって更新先のファームウェアを取得することが可能となる。

また、第２の実施形態に比べて必要な再起動の回数を低減することが可能となる。

（第４の実施形態）
第１～第３の実施形態では、常に端末装置100、100a、100bが動作し続けネットワークに接続されている状態を想定していた。第４の実施形態では、端末装置が一定期間動作を停止した後、改めてネットワークに接続した状態における更新を想定する。その際、端末装置のファームウェアは、動作停止期間に行われた更新が反映されない状態から、最新のファームウェアに更新する必要がある。その際、動作停止期間に発行された１以上の更新通知に対応する１以上のファームウェア更新をそのまま連続して行うと、失敗したファームウェア更新も行うことになる。そこで、第４の実施形態では、失敗したファームウェア更新を行わず迂回した更新手順を適用することができる端末装置の構成について説明する。過去の更新ステップをすべて提供する場合に比べ、ファームウェア更新に必要な動作の短縮を行うことが可能になる。

一方、中間の更新ステップを省略することは、更新手順に迂回路を設けることになり、可能な更新手順の組み合わせは増加する。増えた更新手順の組み合わせの中に深刻な脆弱性を持つファームウェア同士の組み合わせなどがある場合、端末装置は著しく脆弱な状態に陥る懸念がある。また、利用者の都合により動作停止期間はそれぞれ異なるため、更新開始時点の状態は端末装置ごとに異なり、ファームウェア更新を逐次行う場合と比較して多数のバリエーションを考えなければならない。

加えて、以下に説明するように端末装置の応用先により必要な更新ステップが応用に応じて異なることを勘案すれば、さらにバリエーションは増え複雑度は増す。これら複雑性に起因する障害は端末装置の利用目的に関わることから根本的に排除することは難しいが、端末装置のROMモニタでチェックを施すことにより、応用に依存したオペレーションに起因する不用意な障害を排除することができる。実現の手段として本実施形態では、端末装置のベンダから端末装置共通に発行された過去の更新通知のリストと、応用に依存して指定される更新の中間ステップのリストと、に基づいて、安全に計画更新を行う計画を作成し実行する手順を開示する。

第４の実施形態が想定する典型的な動作状況を説明する。第４の実施形態においては、端末装置が例えばコンシューマ機器である場合のように、端末装置が接続されるネットワークの管理の厳密性が弱いか、または端末装置の運用の継続性が弱い、条件で使用されることを想定する。端末装置が動作停止期間から復帰した直後の状態からファームウェア更新を行うため、過去に発行された更新通知およびファームウェアの取得が必要となるが、コスト低減のため専用ネットワークが使用されず、端末装置は、P2Pのファイル転送などの手段を利用して取得する。P2P転送のため、複数のファームウェアを取得する際の取得順序は、保証されない。入手した過去に発行されたファームウェアの中には正規のファームウェアであっても著しい不具合を含むものが潜在的に含まれる。たとえ第１の実施形態のシーケンス番号によるチェックを行っていたとしても、入手したファームウェアを場当たり的に適用した場合、端末装置が長時間利用不能な状態に陥りかねない。このような不具合を含むファームウェアに更新することを回避するためのチェックが第４の実施形態の第１の課題である。

また、動作停止状態から動作を再開した端末装置のファームウェア更新において、可能であれば不要な中間ステップを省略して最新のファームウェアに更新することが効率的である。しかしながら、連携動作する他の端末装置のデータや設定、または連携動作するサービスのデータや設定、を移行するため、最新のファームウェアに移行する前に、いくつかの中間ステップとなるファームウェアの動作が必要となることが考えられる。これは、端末装置と他の装置やサービスとの連携状況、すなわち利用形態によって変わり、サービスの継続性を保ち利便性を向上させるうえで重要である。中間ステップをスキップしてしまった場合、サービス連携の再設定などが必要となり利便性が低下するおそれがある。応用によって異なる中間ステップの適切な適用が、第４の実施形態の第２の課題である。

図３６を参照して、想定状況をより具体的に説明する。図３６は、第１の実施形態にかかる端末装置100aが動作停止期間の後にファームウェア更新を行う場合のファームウェア更新の手順を説明するための模式的な図である。動作停止期間において、#101～#105のシーケンス番号が与えられた5個の更新通知701に対応した5回のファームウェア更新が実行されている。バージョンａのファームウェアが稼働している状態において、5回のファームウェア更新がシーケンス番号の順番で実行されると、端末装置100aのファームウェアは、バージョンｂのファームウェア、バージョンｃのファームウェア、バージョンｄのファームウェア、バージョンｅのファームウェア、バージョンｆのファームウェア、にこの順番で更新される。以降では、シーケンス番号811として「x」が与えられた更新通知701を、更新通知#xと表記する。ただし、xは0以上の整数である。

図３６において、正常に動作することが確認されたバージョンには、（ＯＫ）が付されている。深刻な脆弱性を持っていることが確認されたバージョンには、（Ｖｕｌ）が付されている。起動不能であることが確認されたバージョンには、（ＮＧ）が付されている。

５つの矢印は、ファームウェア更新を表している。各矢印の終点は、ファームウェア更新の際に配布される新しいファームウェアを表す。各矢印の始点は、更新通知によって指定されたロールバック先のファームウェアを表す。なお、第１の実施形態では、ロールバック先のファームウェアは更新通知によって指定されないため、各矢印の始点は何れのバージョンのファームウェアにも接続されていない。

バージョンａのファームウェアが稼働している状態において端末装置100aが動作停止状態になり、最新のファームウェアがバージョンfのファームウェアであるときに端末装置100aが動作を再開した場合を考える。以降では、端末装置100aにおいてバージョンａのファームウェアが稼働している状態を、初期状態と表記する。

第１の実施形態にかかる端末装置100aでは、ファームウェア更新を実行するファームウェアは、正常に動作する限り、任意のファームウェアとすることが可能である。つまり、ファームウェア更新の順序についての制限はない。よって、初期状態の端末装置100aは、更新通知#105を取得して更新通知#105に対応したファームウェア更新を実行すれば、最も効率よくバージョンfへのファームウェア更新が可能である。

ここで、中間ステップとしてバージョンbのファームウェアの実行が必要であると仮定する。そのような場合において、初期状態から更新通知#105に対応したファームウェア更新を実行すると、後からバージョンbのファームウェアが必要になる。しかしながら、更新通知#105に対応したファームウェア更新の後には、バージョンbのファームウェアを取得するためのファームウェア更新である更新通知#101に対応したファームウェア更新は、実行されない。シーケンス番号811による検証に合格しないためである。よって、アプリ連携の再設定が必要となってしまう。

端末装置100aが、動作停止期間に発行された更新通知#101、更新通知#102、更新通知#103、更新通知#104、および更新通知#105をこの順番で取得して、この順番に対応する順番でファームウェア更新を実行した場合、端末装置100aは、必要な中間ステップ（即ちバージョンbのファームウェアの実行）を経由することができる。その反面、端末装置100aが、脆弱性があるバージョンcのファームウェア、または起動不能なバージョンdのファームウェアを持つ期間が生じ、これによって端末装置100aが非常に脆弱な状態に陥る。

このように、中間ステップを迂回した更新を許す場合、ロールバック先が指定されない第１の実施形態のファームウェア更新の手順は、第１の課題について改良の余地がある。

第４の実施形態では、更新通知は、ファームウェア更新の適用前のバージョンを明示することができる。図３７は、第４の実施形態の更新通知が適用された場合のファームウェア更新の手順を説明するための模式的な図である。第４の実施形態にかかる更新通知を、更新通知802と表記する。

更新通知802によれば、ロールバック先のファームウェアのバージョンが明示される。ここでは、動作停止期間に、更新通知#1～更新通知#8の8個の更新通知802が発行されたこととする。図３７において、更新通知#x(y,z)は、シーケンス番号が「x」であり、ロールバック先のファームウェアのバージョンが「y」であり、新しいファームウェアのバージョンが「z」であることを表す。また、矢印の終点は、更新先のファームウェアのバージョンを示し、矢印の始点は、ロールバック先のバージョンを示す。

第４の実施形態では、脆弱なバージョンcから古いバージョンbにファームウェア更新を行うための更新通知802として、更新通知#4(c,b)が例示されている。この更新通知802の詳細は後述する。

そして、更新通知#5によってバージョンbからバージョンeへのファームウェア更新が適用され、更新通知#6によってバージョンeからバージョンfへのファームウェア更新が適用される。さらに、更新通知#6の発行後に、バージョンaのファームウェアを持つ端末装置を効率的に更新することを目的として、更新通知#7(a,f)が発行されている。

シーケンス番号順の経路に沿ってファームウェア更新が実行された場合、端末装置は、脆弱なバージョンcと動作不良を持つバージョンdを持つ状態に陥るが、その後の更新通知#4に対応したファームウェア更新により、端末装置を、より安全なバージョンbが動作した状態に戻すことが可能である。

更新通知#5に対応したファームウェア更新は、端末装置がバージョンbのファームウェアを持っていなければ適用できない。しかしながら、上述のようにバージョンbのファームウェアの実行が不要な端末装置のファームウェア更新を効率化するために更新通知#7が追加で発行されているため、バージョンaのファームウェアを持つ端末装置は即座に更新通知#7に対応したファームウェア更新を実行することで、最新のファームウェアであるバージョンfのファームウェアを持つ状態に到達できる。バージョンbのファームウェアを経由せずバージョンaからバージョンfにファームウェア更新する操作について、共通のデータ構造互換性の問題がある場合には、更新通知#7は発行されない。

一方で、端末装置の応用目的に依存して更新の中間ステップとしてバージョンbのファームウェアの実行が必要な場合と不要な場合とがあるときには、更新通知#8が発行される。

更新通知#7のような迂回を含む更新通知の提供は、端末装置の基本機能を提供する機器ベンダが行う。迂回を含む更新を利用するかどうかは、個々の端末装置の利用形態に応じて運用者が判断する機能分担が第４の実施形態の想定である。

図３７に示された例において、初期状態、つまりバージョンaのファームウェアが動作している状態において、更新通知#1、更新通知#5、および更新通知#6に対応した3つのファームウェア更新を逐次実行するか、それとも中間ステップを迂回して更新通知#7に対応したファームウェア更新を実行するかは、端末装置の応用に依存する。一方で、バージョンfに至る更新経路を持たないファームウェア更新、例えばバージョンcへのファームウェア更新およびバージョンdへのファームウェア更新、は、実行が不要であり排除されることが望まれる。

運用者は、応用に依存した必須の中間ステップを指定し、ROMモニタが中間ステップを正しく経由する更新計画を作成する機能を持つことで、迂回を含む効率的な更新を安全に行い第１、第２の課題を解決することが、第４の実施形態のゴールである。

第４の実施形態では、動作モードとして、試行モードおよび更新モードに加えて、計画更新モードが追加されている。計画更新モードは、更新通知リストおよび必須中間ステップリストを取得するためのモードである。さらに、計画更新モードでは、ROMモニタは、更新計画を作成したり更新計画をチェックしたりすることができる。更新通知リストは、これまでに発行された２以上の更新通知をまとめたものであり、端末装置のベンダが供給する。ROMモニタは、更新通知リストに基づき、署名検証により改ざんの有無を検証することができる。加えて、端末装置に更新を適用する際に必要な中間ステップの情報（必須中間ステップリスト）が運用者から供給される。ある端末装置が、最新の更新通知を入手後に現在の状態と最新の更新にギャップがあると判定した場合、必要な中間ステップを経由しつつ、脆弱な状態を避けた更新計画を作成し、端末装置を最新の状態まで更新する。計画更新モードが追加されることで、古い状態の端末装置の更新を補助する更新通知リストを取得することができ、古い状態の端末装置が効率的なアップデートを行うことができる。

以降、第４の実施形態について説明する。第４の実施形態にかかる端末装置を、端末装置100cと表記する。なお、以降では、第３の実施形態と同じ事項については説明を省略するか、または簡略的に説明する。

図２６は、第４の実施形態にかかる更新通知802のデータ構成例を示す模式的な図である。

図２６の（Ａ)に示されるように、更新通知802は、シーケンス番号811と、更新先のファームウェア識別情報812-1と、ロールバック先のファームウェア識別情報812-2と、署名813と、が連接されて構成されたデータ構成を有している。署名813は、シーケンス番号811と、更新先のファームウェア識別情報812-1と、ロールバック先のファームウェア識別情報812-2と、からなるメッセージに対して所定のアルゴリズムを用いて生成されたものである。署名813の生成に用いられる非対象鍵系の秘密鍵は、管理サーバ2のみに保持されている。よって、正規の更新通知802を発行できるのは管理サーバ2のみである。端末装置100cのROMモニタ専用ストレージ640cには、上記された秘密鍵の対である公開鍵が保存されている。

各ファームウェア識別情報812-1、812-2は、図２６の（Ｂ)に示されるように、ファームウェアのバージョン番号911、ファームウェアのハッシュ値912、および署名913を含む。署名913は、バージョン番号911およびハッシュ値912からなる情報に対して所定のアルゴリズムを用いて生成されたものである。署名913の生成に用いられる非対象鍵系の秘密鍵は、管理サーバ2のみに保持されている。端末装置100cのROMモニタ専用ストレージ640cには、上記された秘密鍵の対である公開鍵が保存されている。

第２の実施形態および第３の実施形態との相違点は、更新先とロールバック先が同一の形式で指定されることである。この形式により、端末装置100cのベンダが意図した場合は脆弱性のある新しいバージョンのロールバック先、古いバージョンのFWを更新先として指定することが可能になる。図３７に示される更新通知#4は、このケースに該当する。

連続的にファームウェア更新が実行される際には、端末装置100cは複数の更新通知802から更新計画を作成する。更新計画の作成に使用する更新通知リストは致命的な脆弱性のあるファームウェアや起動しなかったファームウェアに更新する更新通知802を除外したすべての更新通知が含まれる。更新通知リスト全体には、端末装置100cのベンダの署名が付与されてもよい。

図２７は、第４の実施形態にかかる更新通知リストの一例を示す模式的な図である。本図に示される例では、図３７に示された8個の更新通知802のうちの、脆弱性を有するバージョンcまたは動作不良が確認されたバージョンdを更新先またはロールバック先として指定する更新通知#2～#4を除く5個の更新通知802が、更新通知リストに含まれている。なお、本図では、各更新通知802に含まれる署名813の図示が省略されている。

図２８は、第４の実施形態にかかる更新計画の一例を示す模式的な図である。更新計画は、更新通知リストから選択された２以上の更新通知802によって構成される。２以上の更新通知802は、中間ステップとして指定されたバージョンを経由して端末装置100cが持つファームウェアのバージョンから最新の更新通知802で指定されたバージョンまで段階的にファームウェア更新を実行できるように選択される。

より具体的には、更新計画を構成する２以上の更新通知802のそれぞれは、更新計画に含まれる２以上の更新通知802のうちの連続して実行される２つのファームウェア更新を示す任意の２つの更新通知802が、下記の関係を満たすように選択される。即ち、あるファームウェア更新にかかる更新通知802（第１の更新通知802と表記する）と、次に実行されるファームウェア更新にかかる更新通知802（第２の更新通知802と表記する）と、は、第１の更新通知802によって取得先のファームウェアとして指定されたファームウェアが、第２の更新通知802によってロールバック先のファームウェアとして指定されている。つまり、更新計画は、２以上のファームウェアの更新順を表している。なお、上記された連続して実行される２つのファームウェア更新の条件を、連続条件、と表記する。

なお、第２の更新通知802によって更新先のファームウェアとして指定されたファームウェアは、第１の更新通知802によって更新先のファームウェアとして指定されたファームウェア（即ち第２の更新通知802によってロールバック先のファームウェアとして指定されたファームウェア）が動作しているときに、取得される。よって、各更新通知802によってロールバック先のファームウェアとして指定されたファームウェアは、更新元のファームウェアとして指定されたファームウェアと考えることができる。

なお、図２８に示された更新計画は、初期状態で稼働するバージョンbのファームウェアからバージョンeのファームウェアへのファームウェア更新にかかる更新通知#5と、バージョンeのファームウェアからバージョンfのファームウェアへのファームウェア更新にかかる更新通知#6と、から構成されている。

図２９は、第４の実施形態にかかる端末装置100cにおいてCPU200が実現する機能と不揮発メモリ203の概略構成とを説明するための模式的な図である。

命令実行ユニット201は、ROMモニタプログラム650ｃを実行することによって、ROMモニタ520cとして機能する。また、命令実行ユニット201は、ファームウェアを実行することによって、RTOS510として機能する。

不揮発メモリ203には、RTOS用ストレージ610、共有ストレージ620、FWストレージ630、およびROMモニタ専用ストレージ640cがアロケートされている。

図３０は、第４の実施形態にかかるROMモニタ専用ストレージ640cに格納されるデータ群の一例を示す模式的な図である。

ROMモニタ専用ストレージ640cには、第１の実施形態と同様に、主状態変数641、最大シーケンス番号642、アクティブFW格納先643、アクティブFW動作実績644、FW管理テーブル645、および次回FW取得要否646が格納される。

第４の実施形態では、ROMモニタ専用ストレージ640cには、さらに、更新通知リスト取得要否647、計画更新実行要否649、必須中間ステップリスト660、および計画更新フラグ661が格納される。また、ROMモニタ専用ストレージ640cには、更新計画が保存される更新計画保存領域648がアロケートされている。

図３１は、第４の実施形態にかかる端末装置100cの動作例を示すシーケンス図である。なお、本図にかかる説明では、バージョンxのファームウェアを、ファームウェアFW:xと表記している。

端末装置100cの電源が投入されると、ステップX23では、ROMモニタ520cは、バージョンbのファームウェアを試行モードで起動する。

ステップX24では、試行モードで起動されたバージョンbのファームウェアは、最新の更新通知（FW:e,FW:f）を取得し、CPU200の再起動を実行する。なお、更新通知（FW:e,FW:f）は、バージョンeのファームウェアをロールバック先のファームウェアとして指定し、バージョンfのファームウェアを更新先のファームウェアとして指定する更新通知802である。

ステップX25では、ROMモニタ520cは、前ファームウェアであるバージョンbのファームウェアの正常動作を確認する。そして、ROMモニタ520cは、更新通知（FW:e,FW:f）に対し、シーケンス番号811および署名813を用いた検証を実行する。そして、ROMモニタ520cは、端末装置100cが更新通知（FW:e,FW:f）で指定された各ファームウェア、即ちバージョンeのファームウェアおよびバージョンfのファームウェアのそれぞれ、を保持しているか否かを判定する。ROMモニタ520cは、端末装置100cはロールバック先に指定されたバージョンeのファームウェアを保持していないことを確認すると、更新通知リスト取得要否647にフラグをセットし、主状態変数641を計画更新モードに変更する。そして、ROMモニタ520cは、主状態変数641を計画更新モードに変更し、バージョンbのファームウェアを再度起動する。

ステップX26では、計画更新モードで起動されたバージョンbのファームウェアは、更新通知リストと必須中間ステップリストとを取得して共有ストレージ620に保存し、CPU200の再起動を実行する。

ステップX27では、ROMモニタ520cは、前ファームウェアであるバージョンbのファームウェアの正常動作を確認する。そして、ROMモニタ520cは、ステップX26で入手した更新通知リスト、および更新通知リストを構成する更新通知、の真正性を確認する。そして、ROMモニタ520cは、更新通知リストと必須中間ステップリストとに基づいて、更新計画を作成する。そして、ROMモニタ520cは、更新計画の妥当性を評価する。妥当性の評価に成功すれば、ROMモニタ520cは更新計画をROMモニタ専用ストレージ640cの更新計画保存領域648に書き込み、必須ステップリストをROMモニタ専用ストレージ640cに書き込み、計画更新フラグ661をセットする。

計画更新フラグ661がセットされている場合、ROMモニタ520cは、更新計画に保持された更新通知を順次読み出して、読み出した更新通知に従ってファームウェア更新を行う。計画更新フラグ661は、更新計画に保持された全ての更新通知にかかるファームウェア更新が完了したときにクリアされる。

なお、ステップX27では、中間ステップとして、バージョンeのファームウェアが指定されていることとする。また、更新計画によって、バージョンbからバージョンeにファームウェアを更新し、続いて、バージョンeからバージョンfにファームウェアを更新するよう、計画されていることとする。つまり、更新計画には、更新通知（FW:b,FW:e）と、更新通知（FW:e,FW:f）と、がこの順番で記録されていることとする。

ステップX27では、ROMモニタ520cは、更新計画から更新通知（FW:b,FW:e）を選択し、１つのストレージ領域631を書き込み可に設定する。そして、ROMモニタ520cは、FW取得要求フラグ666をセットし、主状態変数641を更新モードにセットしたうえで、バージョンbのファームウェアを起動する。

以降、更新計画に基づき、更新モードで起動されたバージョンbのファームウェアによるバージョンeのファームウェアの取得（ステップX28）、試行モードでのバージョンeのファームウェアの起動（ステップX29）、試行モードで起動されたバージョンeのファームウェアの動作確認（ステップX30）、更新計画から更新通知（FW:e,FW:f）を取得し、更新モードでのバージョンeのファームウェアの起動（ステップX31）、更新モードで起動されたバージョンeのファームウェアによるバージョンfのファームウェアの取得（ステップX32）、試行モードでのバージョンfのファームウェアの起動（ステップX33）が実行される。そして、ステップX34では、試行モードで起動されたバージョンfのファームウェアの動作が開始する。

例えば、端末装置100cは、センシングデータを収集する機能をファームウェアに基づいて実現する応用を考える。当該応用では、バージョンeのファームウェアは、バージョンeよりも前のバージョンのファームウェアに従って取得したセンシングデータの形式を、バージョンe以降のファームウェア（例えばバージョンfのファームウェア）でも利用可能な形式に変換することができる。仮に、バージョンeのファームウェアを経由しないでバージョンbからバージョンfへのファームウェア更新が実行された場合、運用者は、バージョンfのファームウェアが稼働している端末装置100cにおいて、センシングデータの形式の変更を手動で実行する必要が生じる。第４の実施形態によれば、図３１に示されたように、バージョンeへのファームウェア更新が必須の中間ステップとして指定されれば、バージョンeを経由してバージョンfへのファームウェア更新が実行される。バージョンeのファームウェアは、自動でセンシングデータの形式の変換を実行するので、運用者による形式の変換は不要となる。

第４の実施形態では、端末装置100cを一気に最新の状態へと計画更新を行うために計画更新モードおよび補助状態変数として計画更新フラグ661が用意されている。ROMモニタ520cは計画更新モードに入ったとき、計画更新に必要な更新通知リストの取得と更新計画の作成を行い、計画更新フラグ661をセットする。計画更新フラグ661がセットされている場合、端末装置100cは、ファームウェア（換言するとRTOS510）による更新通知802の取得に代えて、あらかじめ作成した更新計画に保持された更新通知を用いて逐次FW更新を行い、更新計画の適用がすべて完了すると計画更新フラグ661をクリアする。

図３２は、第４の実施形態にかかるROMモニタ520cの動作の詳細を示すフローチャートである。

第４の実施形態のROMモニタ520cの動作は、S312およびS313の処理が追加されている点と、S323～S325からなる計画更新モードでの処理が追加されている点と、S316およびS317の処理が追加されている点と、S307およびS308の処理が追加されている点と、で図２３に示された第３の実施形態のROMモニタ520cの動作と相違する。以下に、第３の実施形態と異なる動作について説明する。なお、上記された第３の実施形態と第４の実施形態との相違点以外の事項は、第２の実施形態と同じであってもよい。

s312およびs313の処理は、更新モードにおいて実行される。S08の更新通知シーケンス番号検証の結果が合格である場合、S312の指定ファームウェア保持判定が実行される。S312では、ROMモニタ520cは、更新通知802に基づいて、動作モードの切り替えに関する判定を行う。より具体的には、ROMモニタ520cは、更新通知802によって指定された、ロールバック先のファームウェアおよび更新先のファームウェアのそれぞれを保持しているか否かを判定する。端末装置100cがロールバック先のファームウェアを保持している場合、動作モードを更新モードに切り替えるために制御がS209に移行する。端末装置100cがロールバック先のファームウェアを保持していない場合、計画更新モードに切り替えために、S313の計画更新モード移行処理に制御が移行する。また、端末装置100cが更新通知で指定された更新先のファームウェアを既に保持している場合、動作モードの切り替えが行われずにS13に制御が移行する。

図３３は、第４の実施形態にかかる計画更新モード移行処理（図３２のS313）の詳細を示すフローチャートである。

計画更新モード移行処理では、ROMモニタ520cは、まず、主状態変数641を試行モードから計画更新モードに変更する（S3131）。

続いて、S3132では、ROMモニタ520cは、共有ストレージ620に更新通知リスト取得要求を書き込む。そして、計画更新モード移行処理が完了する。計画更新モード移行処理が完了と、制御がS13に移行する。

図３１に示されたステップX25では、端末装置100cがロールバック先として指定されたバージョンeのファームウェアを保持していなかったため、図３３に示された計画更新モード移行処理によって動作モードが試行モードから計画更新モードに変更された。

このように、第４の実施形態では、ROMモニタ520cは、端末装置100cの状態を判定し、現在保持するファームウェアに最新の更新通知802にかかるファームウェア更新が適用できない場合、計画更新モードに遷移する。

図３２に示されるように、計画更新モードでは、ROMモニタ520cは、まず、更新計画検証処理（s323）を実行する。

図３４は、第４の実施形態にかかる更新計画検証処理（図３２のs323）の詳細を示すフローチャートである。

更新計画検証処理では、ROMモニタ520は、まず、更新通知署名検証を実行する（S3231）。ROMモニタ520cは前ファームウェアが取得した更新通知リストもしくは更新通知リストに含まれる更新通知802について、署名813を用いた検証を行うことによって、更新通知リストもしくは更新通知リストに含まれる更新通知の真正性を確認する。

更新通知署名検証の結果が不合格であった場合（S3231:不合格）、ROMモニタ520cは、ストレージ領域631に、再度、更新通知リスト取得要求を書き込み（S3232）、S13に制御が移行する。

更新通知署名検証の結果が合格であった場合（S3231:合格）、ROMモニタ520cは、更新通知リストとファームウェアが取得もしくは指定した必須中間ステップリストとに基づいて、端末装置100cが今の状態から中間ステップを経由して最新の状態になるような更新計画を作成する（S3233）。

S3234では、ROMモニタ520cは、更新計画に従った一連のファームウェア更新の順番が連続条件を満たしているか否かを判定する（S3234）。連続条件が満たされている場合（S3234:Yes）、ROMモニタ520cは、更新計画に従った一連のファームウェア更新は、必須中間ステップを経由しているか否かを判定する（S3235）。更新計画に従った一連のファームウェア更新が必須中間ステップを経由している場合（S3235:Yes）、ROMモニタ520cは、ROMモニタ専用ストレージ640cの更新計画保存領域648に更新計画を書き込む（S3236）。そして、更新計画検証処理が完了し、制御がS324に移行する。

連続条件が満たされていない場合（S3234:No）、または更新計画に従った一連のファームウェア更新が必須中間ステップを経由していない場合（S3235:No）、制御がS3232に移行する。

図３２に示されるS324では、ROMモニタ520cは、計画更新フラグ661をセットする。そして、ROMモニタ520cは、計画更新開始処理を実行する（S325）。計画更新開始処理では、ROMモニタ520cは、主状態変数641を計画更新モードから更新モードに変更する。これによって、動作モードが更新モードに移行する。そして、制御がS13に移行する。

更新モードにおいて、ROMモニタ520cは、指定ファームウェア入手判定を実行し（S211）、前ファームウェアをロールバック先のファームウェアとして指定する更新通知802が指定する更新先のファームウェアの完全性の検証を実行する。完全性の検証の結果が合格であれば、ROMモニタ520cは、計画更新フラグ661が有るか否かを判定する（S316）。つまり、計画更新フラグ661がセットされているか否かを判定する。計画更新フラグ661がない場合（S316:No）、ROMモニタ520cは、試行モード移行処理を実行する（S112）。計画更新フラグ661が有る場合（S316:Yes）、ROMモニタ520cは、計画更新FW取得後処理を実行する（S317）。

図３５は、第４の実施形態にかかる計画更新FW取得後処理（図３２のS317）の詳細を示すフローチャートである。

計画更新FW取得後処理では、ROMモニタ520cは、共有ストレージ620内の更新通知802が更新計画に含まれる何れかの更新通知802と一致するか否かを判定する（S3171）。共有ストレージ620には、後述されるS307の処理によって、更新計画から選択された更新通知802が共有ストレージ620に書き込まれる。S3171は、ROMモニタ520cは、共有ストレージ620内の更新通知802が更新計画から選択されたものであるか否かを確認する。

共有ストレージ620内の更新通知802が更新計画に含まれる何れの更新通知802とも一致しない場合（S3171:No）、ROMモニタ520cは、所定のエラー処理を実行する。

共有ストレージ620内の更新通知802が更新計画に含まれる何れかの更新通知802と一致する場合（S3171:Yes）、ROMモニタ520cは、更新計画の最後の更新通知によって指定されたファームウェアの取得が完了しているか否かを判定する（S3172）。更新計画の最後の更新通知によって指定されたファームウェアの取得が完了している場合（S3172:Yes）、ROMモニタ520cは、計画更新フラグ661をクリアする（S3173）。そして、計画更新FW取得後処理が完了して、制御がS13に移行する。

更新計画の最後の更新通知によって指定されたファームウェアの取得が完了していない場合（S3172:No）、S3173がスキップされる。

このように、更新計画によって定められた全てのファームウェア更新が完了した場合、計画更新フラグ661がクリアされて、計画更新が完了する。

図３２に説明を戻す。試行モードにおいては、ROMモニタ520cは、前ファームウェアが正常に動作したことを確認後（S04:正常に動作している）、計画更新フラグ661が有るか否かを判定する（S307）。計画更新フラグ661が有る場合（S307:Yes）、ROMモニタ520cは、更新計画に含まれる更新通知802のうちの次に取得すべきFWに対応する更新通知802を選択して、選択された更新通知802を共有ストレージ620に書き込む（S308）。そして、ROMモニタ520cは、更新モード移行処理を実行する（S209）。

このように、第４の実施形態によれば、ROMモニタ520cは、更新通知802によって指定されたファームウェアを端末装置100cが保持していない場合、正常に動作することが既に確認されたファームウェア（第２ファームウェア）を計画更新モードで起動する。そして、計画更新モードで起動された第２ファームウェアは、発行済みの２以上の更新通知のリストである更新通知リストを取得する。そして、ROMモニタ520cは、更新通知リストに基づいて２以上のファームウェアの更新順を示す更新計画を生成する。そして、ROMモニタ520cは、更新計画に従った順にファームウェアを選択する。選択されたファームウェアを端末装置100cが保持していない場合には、正常に動作することが既に確認されたファームウェアプログラムをROMモニタ520cが更新モードで起動する処理と、更新モードで起動されたファームウェアが選択されたファームウェアを取得する処理と、選択されたファームウェアをROMモニタ520cが試行モードで起動する処理と、を実行する。

よって、端末装置100cが動作停止している期間に更新通知802が発行され、動作停止期間後に端末装置100cが起動された場合であっても、不具合を含むファームウェアへの更新を回避しながらファームウェアを最新の状態にすることが可能である。

また、第４の実施形態によれば、計画更新モードで起動された第２ファームウェアは、必須中間ステップを取得する。そして、ROMモニタ520cは、必須中間ステップを含むように更新計画を作成する。

よって、必須なファームウェアへの更新を含む一連のファームウェア更新を行うことが可能となる。

なお、第４の実施形態によれば、更新計画から選択された更新通知802によって指定された更新先のファームウェアの取得は、当該更新通知802によってロールバック先のファームウェアとして指定されたファームウェアが更新モードで起動されたときに実行される。

以上述べたように、第１～第４の実施形態によれば、端末装置100，100a，100b，100cは、更新通知701，702，801および更新先のファームウェアの何れかが偽造された場合、偽造されていることを検出できる。また、端末装置100，100a，100b，100cは、正常に動作することが確認されたファームウェアに従って更新先のファームウェアを取得することができる。また、更新後のファームウェアが正常に動作しない場合、端末装置100，100a，100b，100cは、正常に動作することが既に確認されたファームウェアにロールバックすることができる。従って、第１～第４の実施形態によれば、端末装置100，100a，100b，100cは、高いセキュリティと高い可用性とを備えている。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

1 制御ネットワーク、2 管理サーバ、3 アプリケーションサーバ、10 無線アクセスポイント、100，100a，100b，100c 端末装置、200 CPU、201 命令実行ユニット、203 不揮発メモリ、510 RTOS、520，520a，520b，520c ROMモニタ、610 RTOS用ストレージ、620 共有ストレージ、630，630a FWストレージ、631 ストレージ領域、640，640c モニタ専用ストレージ、641 主状態変数、642 最大シーケンス番号、643 アクティブFW格納先、644 アクティブFW動作実績、645 FW管理テーブル、646 次回FW取得要否、647 更新通知リスト取得要否、648 更新計画保存領域、649 計画更新実行要否、650，650a，650b，650c モニタプログラム、655 領域管理情報、656 フラグフィールド、657 優先順位フィールド、658 更新通知フィールド、660 必須中間ステップリスト、661 計画更新フラグ、666 取得要求フラグ、701，702，802 更新通知、710，711，713，720，811 シーケンス番号、712，912 ハッシュ値、714，730，813，913 署名、812，812-1，812-2 ファームウェア識別情報、911 バージョン番号。

Claims (6)

1. ファームウェアプログラムとモニタプログラムとを互いに排他的に実行し、第１モードおよび第２モードを含む複数の動作モードの間の切り替えと前記ファームウェアプログラムの起動をモニタプログラムに従って実行することができるプロセッサと、
   複数のファームウェアプログラムを格納する格納領域を持つ格納領域セットと、
   前記格納領域毎に格納されるファームウェアプログラムもしくは更新に用いられた更新通知の識別番号を含むファームウェアプログラムの署名を保持する署名テーブルと、
   前記モニタプログラムに続いて実行されるファームウェアプログラムを記憶する実行ファームウェアプログラム記憶手段と
   ブートローダによる選択に基づいて実行されるファームウェアプログラムの実行結果を保持する第１の記憶手段と、
   ファームウェアプログラム実行の結果取得した更新通知を一時的に保持する第２の記憶手段と、
   これまでに実行したファームウェアプログラムについて最大識別番号を保持する第３の記憶手段
   をそなえ、
   前記ブートローダの第１の動作モードにおいては、直前に実行されたファームウェアプログラムの実行結果に基づいて、ファームウェアプログラムがそなえる機能の有効性を判定する判定手段と、
   前記ファームウェアプログラム機能の有効性が確認できない場合には、第３の記憶手段に保持された前記識別番号に関わらず、前記格納領域に格納済みのひとつもしくは複数のファームウェアプログラムから、所定の優先順位にしたがって一つのファームウェアプログラムを選択して実行する代替ファームウェアプログラム実行手段と
   前記ファームウェアプログラム機能の有効性が確認できた場合には、前記ファームウェアプログラムが取得した前記第２の記憶手段に保存された前記ファームウェアプログラム更新通知の検証を行い、
   前記ファームウェアプログラム更新通知の識別番号が、前記最大識別番号より大きい場合に、動作モードを第２のモードに変更してファームウェアプログラムを実行するモード変更手段をそなえ、
   前記ブートローダの第２の動作モードにおいては、前記第２の記憶手段に保存されたファームウェアプログラム更新通知の検証ならびに、直前のファームウェアプログラム実行により取得され、前記格納領域に格納済みファームウェアプログラムについて、前記ファームウェアプログラム更新通知に基づく検証に成功し、なおかつ、識別番号が前記最大識別番号より大きいとき、前記第２の記憶手段に保存されたファームウェアプログラム更新通知を、前記第３のファームウェアプログラムの格納領域に対応する前記署名テーブルのエントリに格納し、全ての検証に成功したときのみ、実行ファームウェアプログラムおよび、動作モードを変更してファームウェアプログラムを実行するモード変更手段と、
   全ての検証のいずれかに失敗した場合、前記ファームウェアプログラムを再度実行する再実行手段とを
   そなえることを特徴とする情報処理装置。
2. 前記更新通知の識別番号が、更新通知のシーケンス番号であることを
   特徴とする、請求項１の情報処理装置。
3. 前記不揮発メモリは、それぞれは前記２以上のファームウェアプログラムのうちの１つが格納され得る複数の第１領域を備え、前記第２モードでは前記複数の第１領域への書き込みが禁止され、前記第１モードでは前記複数の第１領域のうちの選択された第１領域である第２領域のみへの書き込みが許可され、
   前記プロセッサは、
   前記第１更新通知の検証結果が合格である場合に、前記モニタプログラムに従って前記複数の第１領域のうちの１つの第１領域を前記第２領域として選択し、取得した前記更新ファームウェアプログラムを前記第２領域に新たなファームウェアプログラムとして格納する、
   請求項１に記載の情報処理装置。
4. 前記更新通知が更新ファームウェアプログラムのハッシュ値に加えて代替実行ファームウェアプログラムを指定する識別番号を含み、
   前記代替実行の対象となるファームウェアプログラムを限定する、
   請求項２の情報処理装置。
5. 更新通知において指定された前記代替実行ファームウェアプログラムの識別番号に対応するファームウェアプログラムを保持していないとき、更新ファームウェアプログラムの取得に先立って第２のモードにおいて代替実行ファームウェアプログラムを取得する、
   請求項４の情報処理装置。
6. 前記複数の動作モードのひとつとして、第３モードを含み、
   前回のファームウェアプログラム処理において取得された更新通知をモニタプログラムが前記第１のモードにおいて処理するとき、代替ファームウェアプログラムとして指定された識別番号を持つファームウェアプログラムが前記ファームウェアプログラム格納領域に存在しないとき、第３のモードに変更を行い、
   第３のモードにおいてモニタプログラムが起動したとき、ファームウェアプログラム処理において取得された発行済みの２以上の更新通知のリストを取得し、
   更新通知のリストから最新ファームウェアプログラムまでの逐次更新を可能とする更新通知を選択し、更新計画リストとして保存し、
   最新ファームウェアプログラムまでの更新が完了するまで、第１の動作モードにおける更新通知を、前記更新計画リストから取得する
   請求項４の情報処理装置。

Images