JP4983521B2 - ソフトウェア更新検証装置、方法及びプログラム - Google Patents

Description

本発明は、ソフトウェア更新検証装置、方法及びプログラムに関し、特に、汎用ＯＳ上でのソフトウェアの更新をその更新の正当性を検証した上で実行するソフトウェア更新検証装置、方法及びプログラムに関する。

汎用のＯＳ（オペレーティングシステム）は、市販されるコンピュータに組み込まれる。汎用のＯＳは、当該ＯＳ上で動作するソフトウェア（即ち、プログラム）を更新するために、当該更新処理を実行するインタフェース（ソフトウェア更新インタフェース）を備えている。このインタフェースは、専用のソフトウェア更新モードで起動される。

なお、複数のノードにおいて速やかに新ＯＳへの更新及び正常性の確認作業を確認するソフトウェア更新検証装置が提案されている（特許文献１参照）。
特開２００６−１１３７５４号公報

汎用ＯＳは、それが汎用であるが故に、誰もが使用可能でなければならない。従って、汎用ＯＳの一部であるソフトウェア更新インタフェースの呼び出し自体を禁止することはできない。このため、悪意のある者は誰でも、ソフトウェア更新インタフェースを呼出して汎用ＯＳ上で不当にソフトウェアを更新することができる。

このような違法なソフトウェア更新を防止するために、以下の方法が考えられる。例えば、ソフトウェア更新インタフェースを呼び出す前にパスワードファイルを作成し、ソフトウェア更新インタフェースによりソフトウェア更新モードで再起動された後に、このパスワードファイルを参照し、これが無効な場合は、以降のソフトウェア更新処理を行わないようにする。

しかし、本発明者の検討によれば、この方法では、ソフトウェア更新モードに変更した後であって再起動する前のタイミングでコンピュータの電源を切断する等の方法でパスワードファイルを採取することができる。この不当に採取したパスワードファイルを利用して、ソフトウェア更新モードでコンピュータを再起動されると、コンピュータは、パスワードファイルを参照しても無効と判断できない。従って、これ以降、悪意のあるソフトウェアの更新処理が行われることを抑止することができない。

本発明は、汎用ＯＳ上でのソフトウェアの更新処理の正当性を検証して不当な利用を抑止するソフトウェア更新検証装置を提供することを目的とする。

また、本発明は、汎用ＯＳ上でのソフトウェアの更新処理の正当性を検証して不当な利用を抑止するソフトウェア更新検証方法を提供することを目的とする。

また、本発明は、汎用ＯＳ上でのソフトウェアの更新処理の正当性を検証して不当な利用を抑止するソフトウェア更新検証プログラムを提供することを目的とする。

本発明のソフトウェア更新検証装置は、動作モードとして、通常モードと、ソフトウェア更新インタフェース手段から起動された場合に検証手段を呼出すソフトウェア更新モードとを備えるＯＳと、前記通常モードの前記ＯＳ上で動作し、前記ソフトウェア更新インタフェース手段を呼出す呼出処理を含む生成処理を複数のプロセスにより実行する生成手段と、前記生成手段から呼出された場合に、前記ソフトウェア更新モードで前記ＯＳを起動するソフトウェア更新インタフェース手段と、前記ソフトウェア更新モードの前記ＯＳから呼出された場合に、前記複数のプロセスにより実行された前記生成処理を検証する検証処理を実行する検証手段とを備える。

好ましくは、本発明の一実施態様において、前記生成手段が、更に、前記生成処理として、前記複数のプロセスにより複数のチェックファイルの生成を実行し、前記検証手段が、前記検証処理として、前記ソフトウェア更新モードの前記ＯＳから呼出された場合に、前記複数のプロセスにより生成された前記複数のチェックファイルを検証する。

好ましくは、本発明の一実施態様において、当該ソフトウェア更新検証装置が、更に、前記ソフトウェア更新モードの前記ＯＳから起動された場合に、更新ファイルを用いて当該プログラムを更新するソフトウェア更新手段を備え、前記生成手段が、更に、更新すべきプログラムを格納する前記更新ファイルを獲得し、前記ソフトウェア更新モードの前記ＯＳが、前記検証手段から得た検証結果が有効である場合に、前記ソフトウェア更新手段を起動する。

好ましくは、本発明の一実施態様において、前記ソフトウェア更新モードの前記ＯＳが、前記検証手段から得た検証結果が無効である場合に、前記ソフトウェア更新手段を起動することなく、前記通常モードで前記ＯＳを起動する。

好ましくは、本発明の一実施態様において、前記チェックファイルの生成を行うプロセスが、前記複数のチェックファイルの各々にその生成時の時刻又はこれに基づくデータからなる時刻データを保存する。

好ましくは、本発明の一実施態様において、前記検証手段が、前記複数のチェックファイルの各々に保存された前記時刻データが１個の時系列を構成するか否かを検証し、前記時刻データが時系列を構成する場合に、当該検証結果を有効とする。

好ましくは、本発明の一実施態様において、前記検証手段が、前記複数のチェックファイルに保存された前記時刻データの各々と最も近接する他の時刻データとの差分が予め定められた第１の閾値よりも小さいか否かを検証し、前記差分が前記第１の閾値よりも小さい場合に、当該検証結果を有効とする。

好ましくは、本発明の一実施態様において、前記検証手段が、現在の時刻と前記複数のチェックファイルの各々に保存された前記時刻データの中の最も大きな値のデータとの差分が予め定められた第２の閾値よりも小さいか否かを検証し、前記差分が前記第２の閾値よりも小さい場合に、当該検証結果を有効とする。

本発明のソフトウェア更新検証方法は、ソフトウェア更新検証装置を実現するためにコンピュータで実行されるソフトウェア更新検証方法であって、通常モードのＯＳ上で動作する生成手段が、ソフトウェア更新インタフェース手段を呼出す呼出処理を複数のプロセスにより実行し、ソフトウェア更新インタフェース手段が、前記生成手段から呼出された場合に、ソフトウェア更新モードで前記ＯＳを起動し、前記ＯＳが、前記ソフトウェア更新モードで前記ソフトウェア更新インタフェースから起動された場合に、検証手段を呼出し、前記検証手段が、前記ソフトウェア更新モードの前記ＯＳから呼出された場合に、前記複数のプロセスにより実行された前記生成処理を検証する。

本発明のソフトウェア更新検証プログラムは、ソフトウェア更新検証装置を実現するためにコンピュータで実行されるソフトウェア更新検証プログラムであって、前記プログラムは、コンピュータに、通常モードのＯＳ上で動作する生成手段が、ソフトウェア更新インタフェース手段を呼出す呼出処理を予め定められた複数のプロセスにより実行するステップと、ソフトウェア更新インタフェース手段が、前記生成手段から呼出された場合に、ソフトウェア更新モードで前記ＯＳを起動するステップと、前記ＯＳが、前記ソフトウェア更新モードで前記ソフトウェア更新インタフェースから起動された場合に、検証手段を呼出するステップと、前記検証手段が、前記ソフトウェア更新モードの前記ＯＳから呼出された場合に、前記複数のプロセスにより実行された前記生成処理を検証するステップとを実行させる。

本発明のソフトウェア更新検証装置、方法及びプログラムによれば、ソフトウェア更新インタフェース手段を呼出す呼出処理を含む生成処理（前処理）が複数のプロセスにより実行され、当該ソフトウェア更新インタフェース手段によりソフトウェア更新モードでＯＳが起動され、当該ＯＳにより呼出された検証手段により前記生成処理が検証される。

これにより、例えば、ソフトウェア更新モードに変更した後であって再起動する前のタイミングでコンピュータの電源を切断して、ソフトウェア更新モードでコンピュータを再起動しても、ソフトウェアを更新することができ難い。これは、複数のプロセスにより実行された生成処理の結果（例えば、後述するチェックファイル）の全てを、正確に入手することができる確率は、極めて低いためである。この結果、生成処理の結果を偽造する等の不正が行われた場合、当該生成処理を検証しても、ソフトウェアの更新処理の正当性を示す結果が得られない。従って、悪意のあるソフトウェアの更新処理が行われることを抑止することができる。これにより、ソフトウェア更新インタフェースの呼出し自体を禁止することなく、事実上、悪意のある者がソフトウェア更新インタフェースを呼出して汎用ＯＳ上で不当にソフトウェアを更新することを防止することができる。

本発明の一実施態様によれば、複数のプロセスにより複数のチェックファイルが生成され、これらが検証される。前述のように、複数のプロセスにより生成されたチェックファイルの全てを、正確に入手することができる確率は、極めて低い。これにより、悪意のあるソフトウェアの更新処理が行われることを効果的に抑止し、事実上、悪意のある者が汎用ＯＳ上で不当にソフトウェアを更新することを防止することができる。

本発明の一実施態様によれば、前記検証結果が有効である場合に、ソフトウェア更新手段が起動される。これにより、検証結果が有効でない限り、ソフトウェアを更新することができないので、悪意のあるソフトウェアの更新処理が行われることを効果的に抑止することができる。

本発明の一実施態様によれば、前記検証結果が無効である場合に、ソフトウェア更新手段が起動されることなく、通常モードでＯＳが（再）起動される。これにより、検証結果が有効でない限り、強制的にＯＳが通常モードに復帰し、ソフトウェア更新手段を使用できなくなるので、悪意のあるソフトウェアの更新処理が行われることを効果的に抑止することができる。

本発明の一実施態様によれば、複数のチェックファイルの各々に、その生成時の時刻又はこれに基づくデータからなる時刻データが保存される。これにより、パスワードと異なり、複数のチェックファイルに有効期限を設けることができる。従って、例えば不正な処理を実行した場合に、当該実行のために時間を要するので、当該有効期限を経過してしまうであろうことを利用して、前記検証結果を無効とすることができる。

本発明の一実施態様によれば、複数の時刻データが時系列を構成するか否かが検証され、時刻データが時系列を構成する場合に当該検証結果が有効とされる。これにより、１個のパスワードと異なり、複数のチェックファイルの時刻データの相互の関係を定義することができる。従って、特に、複数のチェックファイルの生成の途中で不正な処理を実行した場合に、当該実行のために時間を要することを利用して、前記検証結果を無効とすることができる。

本発明の一実施態様によれば、複数の時刻データの各々について、最も近接する他の時刻データとの差分が第１の閾値よりも小さいか否かが検証され、前記差分が第１の閾値よりも小さい場合に当該検証結果が有効とされる。これにより、複数のチェックファイルの時刻データの相互の関係を定義することができる。従って、特に、複数のチェックファイルの生成の途中で不正な処理を実行した場合に、当該実行のために時間を要することを利用して、前記検証結果を無効とすることができる。

本発明の一実施態様によれば、現在の時刻と複数の時刻データの中の最も大きな値のデータとの差分が第２の閾値よりも小さいか否かが検証され、前記差分が第２の閾値よりも小さい場合に当該検証結果が有効とされる。これにより、複数のチェックファイルの時刻データの相互の関係を定義することができる。従って、特に、最後のチェックファイルの生成からソフトウェアの実際の更新処理の実行までの間において不正な処理を実行した場合に、当該実行のために時間を要することを利用して、前記検証結果を無効とすることができる。

図１は本発明のソフトウェア更新検証装置を示す構成図であり、図２〜図４は本発明のソフトウェア更新検証処理の説明図である。

ＯＳ２は、ＣＰＵ１上で動作し、その動作モードとして、通常モードと、ソフトウェア更新モードとを備える。通常モードとソフトウェア更新モードとは、いずれか一方が択一的に選択される。通常モードはソフトウェア更新インタフェース手段２５を備え、ソフトウェア更新モードはソフトウェア更新手段２６を備える。ソフトウェア更新モードは、ソフトウェア更新インタフェース手段２５から起動された場合に、検証手段７を呼出す。この検証手段７は、実際には、後述するように、マネージャ６を介して呼出される。

ＯＳ２の通常モード上で、生成手段３及び削除手段５が動作する。ＯＳ２のソフトウェア更新モード上で、マネージャ６及び検証手段７が動作する。記憶部４は、通常モード及びソフトウェア更新モードのＯＳ２の双方により使用される（書込み又は参照される）。一方、ＯＳ２は、そのＡＰＩとして、システム時刻取得手段２１を備える。

生成手段３は、通常モードのＯＳ２上で、ソフトウェア更新をしようとするユーザ（ユーザアプリケーションプログラム）により呼出される。この呼出しにおいて、当該更新しようとするソフトウェア（プログラム）の名前が指定される。生成手段３は、ソフトウェア更新インタフェース手段２５を介して、ソフトウェア更新モードでＯＳ２を再起動する。当該再起動されたＯＳ２は、マネージャ６を介して、検証手段７による検証の結果を得て、ソフトウェア更新手段２６を起動する。ソフトウェア更新手段２６は、当該ソフトウェアを更新した後、通常モードでＯＳ２を再起動する。

生成手段３が生成処理を実行するための生成補助手段として、通常モードのＯＳ２上で動作するアプリケーション（プログラム）３’が予め設けられる。アプリケーション３’は、後述するように、生成手段３を構成する複数のプロセス３１により呼出され、当該処理を依頼される。アプリケーション３’としては、更新ファイルダウンロード手段３２、システム時刻変換手段３３、システム時刻逆変換手段３４が設けられる。システム時刻変換手段３３及びシステム時刻逆変換手段３４における変換／逆変換は、例えば恒等変換である。

生成手段３はあるプログラムの更新処理における生成処理を実行する。生成処理は、ソフトウェア更新を行うためのインタフェースを呼出す更新準備処理である。生成手段３は、複数のプロセス３１（Ｐ１〜Ｐｎ）からなり、生成処理はこれらにより実行される。即ち、ソフトウェア即ちプログラムの更新処理における生成処理が複数のプロセス３１に分割して実行される。分割された生成処理は、各々、例えば更新ファイル４１の獲得、チェックファイル４２の生成、ソフトウェア更新インタフェース手段２５の呼出等からなる。各々のプロセス３１が実行すべき分割された生成処理は、予め定められる（割り当てられる）。各々のプロセス３１は、自己に予め割り当てられた１又は複数の分割された生成処理を実行する。

プロセスＰ１は、図２に示すように、更新ファイル４１の獲得と、チェックファイル４２の生成とを実行する。なお、プロセスＰ１が、１個の処理のみ即ち更新ファイル４１の獲得のみを実行するようにしても良い。

プロセスＰ１は、生成手段３が実行されると、アプリケーション３’の更新ファイルダウンロード手段３２に更新ファイル４１の取得を依頼して、その応答として更新ファイルダウンロード手段３２からダウンロードされた当該更新ファイル４１を受け取る。当該依頼は更新すべきプログラムのプログラム名を含む。更新ファイル４１は、当該プログラム名を持つプログラムの改版されたもの、即ち、更新すべきプログラムを含む。これにより、プロセスＰ１は、生成処理として、更新ファイル４１を獲得する。更新ファイル４１は、記憶部４に格納され、後述するように、ソフトウェア更新手段２６により使用される。

次に、プロセスＰ１は、ＯＳ２のＡＰＩであるシステム時刻取得手段２１にシステム時刻の取得を依頼して、その応答としてシステム時刻取得手段２１からシステム時刻Ｔ１を受け取る。システム時刻はＣＰＵ１のタイマ１１から得られる。プロセスＰ１は、アプリケーション３’のシステム時刻変換手段３３にシステム時刻Ｔ１の変換を依頼して、その応答としてシステム時刻変換手段３３から変換結果Ｆ１（Ｔ１）を受け取る。プロセスＰ１は、変換結果Ｆ１（Ｔ１）を格納するチェックファイル４２（ＦＩＬＥ１．ｄａｔ）を生成して保存する。チェックファイル４２は、記憶部４に格納され、後述するように、検証手段７により使用（検証）される。

ここで、システム時刻変換手段３３は、システム時刻をバイト列に１対１変換する変換アルゴリズムＦ１（図示せず）を備える。この変換により、システム時刻をそのままチェックファイル４２に保存するよりも、より有効に不当な（悪意のある）ソフトウェアの更新を抑止することができる。なお、プロセス３１毎に異なる変換アルゴリズムを用いるようにしても良い。この場合、事実上、不当なソフトウェアの更新を不可能とすることができる。

チェックファイルＦＩＬＥ１．ｄａｔに格納されたデータ（時刻データ）は、当該チェックファイル４２の生成時の時刻に基づくデータからなる。なお、システム時刻の変換処理は省略しても良い（他のプロセス３１においても同じ）。従って、時刻データは、当該チェックファイル４２の生成時の時刻（例えばＴ１）であっても良い。

チェックファイル４２に時刻データを格納することにより、当該時刻データに有効期限を設けることができる。特に、後述するように、閾値と併用することにより、コンピュータの電源を切断する等の不当な手段が用いられた場合、チェックファイルを無効とすることができる。また、複数のチェックファイル４２を生成することにより、それらの解析を複雑にして、事実上、ソフトウェアの不当な更新を不可能とすることができる。

以上の処理の後に、プロセスＰ１は、起動すべきプロセス（次のプロセス）Ｐ２を起動する。いずれのプロセス３１を起動するかは、予め定められる。

生成手段３における中間のプロセスＰｉ（ｉ＝２〜（ｎ−１））は、生成処理として、図３に示すように、チェックファイル４２の生成を実行する。即ち、プロセスＰｉは、プロセスＰ１と同様にして、システム時刻取得手段２１からシステム時刻Ｔｉを受け取り、システム時刻変換手段３３から変換結果Ｆｉ（Ｔｉ）を受け取り、これを格納するチェックファイル４２（ＦＩＬＥｉ．ｄａｔ）を生成して保存する。この後、プロセスＰｉは、次のプロセスＰ（ｉ＋１）を起動する。

なお、プロセスＰｉがチェックファイル４２の生成以外の当該プロセスに特有の処理（固有処理）を実行するようにしても良い。また、プロセスＰｉを省略し、プロセスＰ１及びＰｎのみを実行するようにしても良い。この場合、生成処理がプロセスＰ１及びＰｎの２つに分割されることになる。これは最小の分割の例である。

生成手段３における最後のプロセスＰｎは、生成処理として、図４に示すように、チェックファイル４２の生成と、ソフトウェア更新インタフェース手段２５の呼出とを実行する。即ち、プロセスＰｎは、プロセスＰ１と同様にして、システム時刻取得手段２１からシステム時刻Ｔｎを受け取り、システム時刻変換手段３３から変換結果Ｆｎ（Ｔｎ）を受け取り、これを格納するチェックファイル４２（ＦＩＬＥｎ．ｄａｔ）を生成して保存する。

ここで、システム時刻Ｔ１からＴｎまでの時間間隔は、実測により予め知ることができ、例えば約３０秒である。また、システム時刻Ｔ１からＴｎまでの時間間隔も同様であり、例えば約１秒〜数秒である。システム時刻Ｔ１からＴｎまでの時間間隔は、通常、各々のプロセスの固有処理に要する時間に応じて、各々異なる。

この後、プロセスＰｎは、次のプロセスを起動する代わりに、ＯＳ２のソフトウェア更新インタフェース手段２５を呼出す。なお、従来は、複数のチェックファイル４２に相当する１個のパスワードファイルを生成した時点でコンピュータの電源を遮断されると、不正な更新を排除することができなかった。しかし、本発明によれば、複数のチェックファイル４２の全てを正確に獲得することが難しいので、事実上、不正なソフトウェアの更新を排除することができる。

以上のように、通常モードのＯＳ２上で動作する生成手段３が、生成処理を複数のプロセス３１により分割して実行することにより、複数のプロセス３１により複数のチェックファイル４２が生成される。なお、複数のチェックファイル４２の生成を省略し、複数のプロセス３１を順に呼出すようにしても良い。また、複数のチェックファイル４２として、内容が「空」のファイルを生成するようにしても良い。即ち、プログラムの更新処理における生成処理が、複数のプロセス３１により実行され、少なくともソフトウェア更新インタフェース手段２５を呼出す呼出処理を含めば良い。

ソフトウェア更新インタフェース手段２５は、呼び出された時点では通常モードのＯＳ２上で動作している。しかし、ソフトウェア更新インタフェース手段２５は、図４に示すように、生成手段３であるプロセスＰｎから呼出された場合に、通常モードのＯＳ２を一旦シャットダウンして、直ちにソフトウェア更新モードでＯＳ２を再起動する。

ソフトウェア更新モードでＯＳ２が再起動されると、これに続いてマネージャ６が直ちに起動される。起動されたマネージャ６は、図５に示すように、検証手段７を呼出して、プログラムの更新処理における生成処理の検証を依頼する。

呼出された検証手段７は、マネージャ６（即ち、ソフトウェア更新モードのＯＳ２）から呼出された場合に、複数のプロセス３１により実行された生成処理を検証する検証処理を実行する。検証処理は、例えば複数のプロセス３１により生成された複数のチェックファイル４２の検証からなる。

具体的には、検証手段７は、図５に示すように、システム時刻取得手段２１からシステム時刻Ｔ０を受け取る。システム時刻Ｔ０は、現在の時刻に相当する。また、検証手段７は、ｎ個のチェックファイルＦＩＬＥ１．ｄａｔ〜ＦＩＬＥｎ．ｄａｔから変換結果Ｆ１（Ｔ１）〜Ｆｎ（Ｔｎ）を読出し、アプリケーション３’のシステム時刻逆変換手段３４に変換結果Ｆ１（Ｔ１）〜Ｆｎ（Ｔｎ）と共にシステム時刻の逆変換を依頼して、その応答としてシステム時刻逆変換手段３４からシステム時刻Ｔ１〜Ｔｎを受け取る。

ここで、システム時刻逆変換手段３４は、変換アルゴリズムＦ１〜Ｆｎによりバイト列に変換されたシステム時刻を元のシステム時刻に１対１に逆変換する逆変換アルゴリズムｉｎｖ−Ｆ１〜Ｆｎ（図示せず）を備える。この逆変換により、元のシステム時刻Ｔ１〜Ｔｎが得られる。

このシステム時刻Ｔ１〜Ｔｎを用いて、検証手段７が以下の第１〜第４の検証処理の一部又は全部を実行する。実行される１又は複数の検証処理（及びその組合せ）は、処理時間及び処理のレベルを考慮して、予め定められる。

検証手段７は、複数のチェックファイルＦＩＬＥ１．ｄａｔ〜ＦＩＬＥｎ．ｄａｔが存在し、かつ、当該複数のチェックファイルＦＩＬＥ１．ｄａｔ〜ＦＩＬＥｎ．ｄａｔの各々からシステム時刻（時刻データ）Ｔ１〜Ｔｎを取得できたか否かを検証する（第１の検証処理）。チェックファイル４２の数はプロセス３１の数により予め定まるので、これに基づいてチェックファイル４２の数（即ち、存在）をチェックすることができる。システム時刻は、後述するように、当該チェックファイル４２の各々から正しいフォーマットの時刻が得られたことを確認すればよい。この場合、検証手段７は、複数のチェックファイル４２が存在し、かつ、その各々からシステム時刻が取得できた場合に、当該検証結果を有効とする。

なお、検証手段７が、複数のチェックファイルＦＩＬＥ１．ｄａｔ〜ＦＩＬＥｎ．ｄａｔが存在するか否かのみを検証するようにしても良い。

更に、検証手段７は、複数のチェックファイルＦＩＬＥ１．ｄａｔ〜ＦＩＬＥｎ．ｄａｔの各々に保存されたシステム時刻Ｔ１〜Ｔｎが１個の時系列を構成するか否かを検証する（第２の検証処理）。前述のように、プロセスＰ１〜Ｐｎがこの順にチェックファイルＦＩＬＥ１．ｄａｔ〜ＦＩＬＥｎ．ｄａｔを生成したのであるから、システム時刻Ｔ１〜Ｔｎは、必ずＴ１＜・・＜Ｔｉ＜・・＜Ｔｎ（Ｔ１が最も早い時刻であり、Ｔｎが最も遅い時刻である）という時系列を構成する。検証手段７は、システム時刻Ｔ１〜Ｔｎが時系列を構成する場合に、当該検証結果を有効とする。

更に、検証手段７は、複数のチェックファイルＦＩＬＥ１．ｄａｔ〜ＦＩＬＥｎ．ｄａｔに保存されたシステム時刻Ｔ１〜Ｔｎの各々と、最も近接する他のシステム時刻との差分が、予め定められた第１の閾値ｄｉよりも小さいか否かを検証する（第３の検証処理）。例えば、Ｔ（ｉ＋１）−Ｔｉを算出して、当該差分が閾値ｄｉよりも小さいか否かが調べられる。これは全てのシステム時刻について同様である。差分Ｔ（ｉ＋１）−Ｔｉは、あるチェックファイルＦＩＬＥｉ．ｄａｔを生成してから、次のチェックファイルＦＩＬＥ（ｉ＋１）．ｄａｔを生成するまでの時間に相当する。

第１の閾値ｄｉは、複数のチェックファイルＦＩＬＥ１．ｄａｔ〜ＦＩＬＥｎ．ｄａｔの各々の生成に要する時間の実測に基づいて得られる値である。前述のように、各々のシステム時刻の時間間隔は例えば約１秒〜数秒であるので、第１の閾値ｄｉは、当該値より大きな値、例えば１０秒とされる。検証手段７は、差分が第１の閾値ｄｉよりも小さい場合に、当該検証結果を有効とする。

更に、検証手段７は、現在の時刻Ｔ０と、複数のチェックファイルＦＩＬＥ１．ｄａｔ〜ＦＩＬＥｎ．ｄａｔの各々に保存されたシステム時刻の中の最も大きな値（この場合は、Ｔｎである）のデータとの差分Ｔ０−Ｔｎが予め定められた第２の閾値ｄ０よりも小さいか否かを検証する（第４の検証処理）。差分Ｔ０−Ｔｎは、最後のチェックファイルＦＩＬＥｎ．ｄａｔを生成してから現在までの時間に相当する。

第２の閾値ｄ０は、複数のチェックファイルＦＩＬＥ１．ｄａｔ〜ＦＩＬＥｎ．ｄａｔの生成の終了から検証手段７による検証までに要する時間の実測に基づいて得られる値である。前述のように、システム時刻Ｔ１からＴｎまでの時間間隔は例えば約３０秒であるので、第２の閾値ｄ０は、当該値より大きな値、例えば４０秒とされる。検証手段７は、差分が第２の閾値ｄ０よりも小さい場合に、当該検証結果を有効とする。

ソフトウェア更新モードのＯＳ２（のマネージャ６）は、図５に示すように、前述の検証依頼に対する応答として、検証手段７から当該検証結果を通知される。検証手段７から得た検証結果が有効である場合に、ソフトウェア更新モードのＯＳ２（のマネージャ６）は、ソフトウェア更新手段２６を起動する。一方、検証手段７から得た検証結果が無効である場合に、ソフトウェア更新モードのＯＳ２は、ソフトウェア更新手段２６を起動することなく、通常モードでＯＳ２を再起動する。

これにより、何らかの不正に基づいて検証結果が無効を示す場合、それ以降ソフトウェア更新モードでのＯＳ２の動作を継続不能として、不正なソフトウェアの更新を防止することができる。また、複数のプロセス３１の実行を経ることなく、ソフトウェア更新手段２６を起動したとしても、検証結果を無効として、それ以降ソフトウェア更新モードでのＯＳ２の動作を継続不能とすることができる。

ソフトウェア更新手段２６は、ソフトウェア更新モードのＯＳ２から起動された場合に、図５に示すように、更新ファイル４１を用いて、当該プログラムを更新する。例えば、当該プログラムに更新ファイル４１に格納された新しいプログラムを適用する（上書きする）ことにより、プログラムが更新される。この後、ソフトウェア更新手段２６は、通常モードでＯＳ２を再起動する。

ＯＳ２は、通常モードで起動された場合に、図６に示すように、複数のチェックファイル４２を削除する。このために、ＯＳ２は、通常モードで起動された場合、削除手段５を呼出す。従って、ＯＳ２は、ソフトウェア更新手段２６による当該プログラムの更新の後に通常モードで起動された場合、複数のプロセスＰ１〜Ｐｎにより生成された複数のチェックファイルＦＩＬＥ１．ｄａｔ〜ＦＩＬＥｎ．ｄａｔを削除する。これにより、チェックファイル４２が悪用されることを防止することができる。

図７〜図１４は、本発明のソフトウェア更新検証処理フローである。

図７は、本発明のソフトウェア更新検証処理の全体の処理フローを示す。図７において、ＯＳ２の通常モードで前処理（生成処理）が実行され（ステップＳ１１）、ＯＳ２のソフトウェア更新モードで検証処理及びソフトウェアの更新処理が実行され（ステップＳ１２）、ＯＳ２の通常モードで後処理（削除処理）が実行される（ステップＳ１３）。

図８は、図７のステップＳ１１において実行される生成処理の処理フローを示す。図８において、最初のプロセスＰ１がその固有の処理を実行し（ステップＳ２１）、中間のプロセスＰｉがその固有の処理を実行し（ステップＳ２２）、プロセスＰｎがその固有の処理を実行する（ステップＳ２３）。

図９は、図８のステップＳ２１においてプロセスＰ１により実行される処理フローを示す。図９において、最初のプロセスＰ１が、更新ファイルダウンロード手段３２を用いて更新ファイル４１をダウンロードし（ステップＳ３１）、システム時刻取得手段２１を用いてその時点での現在時刻をシステム時刻Ｔ１として取得し（ステップＳ３２）、変換アルゴリズムＦ１を備えるシステム時刻変換手段３３を用いてシステム時刻Ｔ１を変換して（ステップＳ３３）、変換結果Ｆ１（Ｔ１）をチェックファイル４２ＦＩＬＥ１．ｄａｔに保存する（ステップＳ３４）。この後、プロセスＰ１は、次のプロセスＰ２を起動する（ステップＳ３５）。

図１０は、図８のステップＳ２２においてプロセスＰｉにより実行される処理フローを示す。図１０において、中間のプロセスＰｉが、当該プロセスＰｉに固有の処理を実行し（ステップＳ４１）、この後、システム時刻取得手段２１を用いてその時点での現在時刻をシステム時刻Ｔｉとして取得し（ステップＳ４２）、変換アルゴリズムＦｉを備えるシステム時刻変換手段３３を用いてシステム時刻Ｔｉを変換して（ステップＳ４３）、変換結果Ｆｉ（Ｔｉ）をチェックファイル４２ＦＩＬＥｉ．ｄａｔに保存する（ステップＳ４４）。この後、プロセスＰｉは、次のプロセスＰ（ｉ＋１）を起動する（ステップＳ４５）。

図１１は、図８のステップＳ２３においてプロセスＰｎにより実行される処理フローを示す。図１１において、最後のプロセスＰｎが、当該プロセスＰｎに固有の処理を実行し（ステップＳ５１）、この後、システム時刻取得手段２１を用いてその時点での現在時刻をシステム時刻Ｔｎとして取得し（ステップＳ５２）、変換アルゴリズムＦｎを備えるシステム時刻変換手段３３を用いてシステム時刻Ｔｎを変換して（ステップＳ５３）、変換結果Ｆｎ（Ｔｎ）をチェックファイル４２ＦＩＬＥｎ．ｄａｔに保存する（ステップＳ５４）。この後、プロセスＰｎは、次のプロセスを起動することなく、ソフトウェア更新インタフェース手段２５を呼び出して、ソフトウェア更新モードでＯＳ２を再起動する（ステップＳ５５）。

図１２は、図７のステップＳ１２において実行される検証処理及び更新処理の処理フローを示す。図１２において、ソフトウェア更新モードで再起動されたＯＳ２がマネージャ６を起動すると（ステップＳ６１）、マネージャ６はソフトウェア更新のシーケンスが正しいか否かを検証手段７により検証し（ステップＳ６２）、検証手段７から得た検証結果が有効であるか否かを調べる（ステップＳ６３）。検証結果が有効である場合、マネージャ６はソフトウェア更新手段２６を呼出して、当該プログラムに更新ファイル４１を適用して（ステップＳ６４）、通常モードでＯＳ２を再起動する（ステップＳ６５）。検証結果が有効でない（無効である）場合、マネージャ６は、ステップＳ６４を省略して、ステップＳ６５を実行する。

図１３は、図１２のステップＳ６２において実行される検証処理の処理フローを示す。図１３において、検証手段７は、マネージャ６から呼出されると（ステップＳ７１）、システム時刻取得手段２１を用いてその時点での現在時刻をシステム時刻Ｔ０として取得し（ステップＳ７２）、複数のチェックファイル４２ＦＩＬＥ１．ｄａｔ〜ＦＩＬＥｎ．ｄａｔから変換結果Ｆ１（Ｔ１）〜Ｆｎ（Ｔｎ）を読出し（ステップＳ７３）、当該読出しに成功したか否かを調べる（ステップＳ７４）。

読出しに失敗した場合、検証手段７は、検証結果は無効である旨をマネージャ６に応答として返す（ステップＳ７５）。読出しに成功した場合、検証手段７は、逆変換アルゴリズムｉｎｖ−Ｆ１〜ｉｎｖ−Ｆｎを備えるシステム時刻逆変換手段３４を用いて、変換結果Ｆ１（Ｔ１）〜Ｆｎ（Ｔｎ）をシステム時刻Ｔ１〜Ｔｎに逆変換し（ステップＳ７６）、当該逆変換に成功したか否かを調べる（ステップＳ７７）。

逆変換に失敗した場合、検証手段７は、ステップＳ７５を実行する。逆変換に成功した場合、検証手段７は、システム時刻Ｔ１〜Ｔｎが時系列Ｔ１＜・・＜Ｔｉ＜・・＜Ｔｎを構成するか否かを調べる（ステップＳ７８）。システム時刻が時系列を構成しない場合、検証手段７は、ステップＳ７５を実行する。

システム時刻が時系列を構成する場合、検証手段７は、システム時刻Ｔ１〜Ｔｎの各々について、最も近接する他のシステム時刻との差分（例えば、Ｔ（ｉ＋１）−Ｔｉ）が、第１の閾値ｄｉよりも小さいか否かを検証する（ステップＳ７９）。当該差分が閾値ｄｉよりも小さくない場合、検証手段７は、ステップＳ７５を実行する。

当該差分が閾値ｄｉよりも小さい場合、検証手段７は、現在の時刻Ｔ０と、システム時刻の中の最も大きな値Ｔｎとの差分Ｔ０−Ｔｎが第２の閾値ｄ０よりも小さいか否かを検証する（ステップＳ７１０）。当該差分が閾値ｄ０よりも小さくない場合、検証手段７は、ステップＳ７５を実行する。当該差分が閾値ｄ０よりも小さい場合、検証手段７は、検証結果は有効である旨をマネージャ６に応答として返す（ステップＳ７１１）。

図１４は、図７のステップＳ１３において実行される削除処理の処理フローを示す。図１４において、通常モードで再起動されたＯＳ２が後処理手段を起動すると（ステップＳ８１）、後処理手段が、複数のチェックファイル４２ＦＩＬＥ１．ｄａｔ〜ＦＩＬＥｎ．ｄａｔを削除する（ステップＳ８２）。

以上から判るように、本発明の実施形態の特徴が以下のように把握される。

（付記１） 動作モードとして、通常モードと、ソフトウェア更新インタフェース手段から起動された場合に検証手段を呼出すソフトウェア更新モードとを備えるＯＳ２と、
前記通常モードの前記ＯＳ上で動作し、前記ソフトウェア更新インタフェース手段を呼出す呼出処理を含む生成処理を複数のプロセスにより実行する生成手段と、
前記生成手段から呼出された場合に、前記ソフトウェア更新モードで前記ＯＳを起動するソフトウェア更新インタフェース手段と、
前記ソフトウェア更新モードの前記ＯＳから呼出された場合に、前記複数のプロセスにより実行された前記生成処理を検証する検証処理を実行する検証手段とを備える
ことを特徴とするソフトウェア更新検証装置。

（付記２） 前記生成手段が、更に、前記生成処理として、前記複数のプロセスにより複数のチェックファイルの生成を実行し、
前記検証手段が、前記検証処理として、前記ソフトウェア更新モードの前記ＯＳから呼出された場合に、前記複数のプロセスにより生成された前記複数のチェックファイルを検証する
ことを特徴とする付記１に記載のソフトウェア更新検証装置。

（付記３） 前記生成手段が、更に、前記生成処理として、更新すべきプログラムを格納する更新ファイルを獲得する
ことを特徴とする付記２に記載のソフトウェア更新検証装置。

（付記４） 当該ソフトウェア更新検証装置が、更に、
前記ソフトウェア更新モードの前記ＯＳから起動された場合に、当該プログラムを更新するソフトウェア更新手段を備え、
前記生成手段が、更に、更新すべきプログラムを格納する更新ファイルを獲得し、
前記ソフトウェア更新モードの前記ＯＳが、前記検証手段から得た検証結果が有効である場合に、前記更新ファイルを用いて前記ソフトウェア更新手段を起動する
ことを特徴とする付記２記載のソフトウェア更新検証装置。

（付記５） 前記ＯＳが、前記ソフトウェア更新手段による当該プログラムの更新の後に前記通常モードで起動された場合に、前記複数のプロセスにより生成された複数のチェックファイルを削除する
ことを特徴とする付記４記載のソフトウェア更新検証装置。

（付記６） 前記ソフトウェア更新モードの前記ＯＳが、前記検証手段から得た検証結果が無効である場合に、前記ソフトウェア更新手段を起動することなく、前記通常モードで前記ＯＳを起動する
ことを特徴とする付記２記載のソフトウェア更新検証装置。

（付記７） 前記チェックファイルの生成を行うプロセスが、前記複数のチェックファイルの各々にその生成時の時刻又はこれに基づくデータからなる時刻データを保存する
ことを特徴とする付記２記載のソフトウェア更新検証装置。

（付記８） 前記時刻は、ＣＰＵのタイマから得られるシステム時刻である
ことを特徴とする付記７記載のソフトウェア更新検証装置。

（付記９） 前記検証手段が、前記複数のチェックファイルが存在するか否かを検証し、存在する場合に、当該検証結果を有効とする
ことを特徴とした付記７記載のソフトウェア更新検証装置。

（付記１０） 前記検証手段が、前記複数のチェックファイルが存在し、当該複数のチェックファイルの各々から前記時刻データを取得できたか否かを検証し、取得できた場合に、当該検証結果を有効とする
ことを特徴とした付記７記載のソフトウェア更新検証装置。

（付記１１） 前記検証手段が、前記複数のチェックファイルの各々に保存された前記時刻データが１個の時系列を構成するか否かを検証し、前記時刻データが時系列を構成する場合に、当該検証結果を有効とする
ことを特徴とした付記７記載のソフトウェア更新検証装置。

（付記１２） 前記検証手段が、前記複数のチェックファイルに保存された前記時刻データの各々と最も近接する他の時刻データとの差分が予め定められた第１の閾値よりも小さいか否かを検証し、前記差分が前記第１の閾値よりも小さい場合に、当該検証結果を有効とする
ことを特徴とする付記７記載のソフトウェア更新検証装置。

（付記１３） 前記第１の閾値は、前記複数のチェックファイルの各々の生成に要する時間の実測に基づいて得られる値である
ことを特徴とする付記１２記載のソフトウェア更新検証装置。

（付記１４） 前記検証手段が、現在の時刻と前記複数のチェックファイルの各々に保存された前記時刻データの中の最も大きな値のデータとの差分が予め定められた第２の閾値よりも小さいか否かを検証し、前記差分が前記第２の閾値よりも小さい場合に、当該検証結果を有効とする
ことを特徴とする付記７記載のソフトウェア更新検証装置。

（付記１５） 前記第２の閾値は、前記複数のチェックファイルの生成の終了から前記検証手段による検証までに要する時間の実測に基づいて得られる値である
ことを特徴とする付記１４記載のソフトウェア更新検証装置。

（付記１６） ソフトウェア更新検証装置を実現するためにコンピュータで実行されるソフトウェア更新方法であって、
通常モードのＯＳ上で動作する生成手段が、ソフトウェア更新インタフェース手段を呼出す呼出処理を複数のプロセスにより実行し、
ソフトウェア更新インタフェース手段が、前記生成手段から呼出された場合に、ソフトウェア更新モードで前記ＯＳを起動し、
前記ＯＳが、前記ソフトウェア更新モードで前記ソフトウェア更新インタフェースから起動された場合に、検証手段を呼出し、
前記検証手段が、前記ソフトウェア更新モードの前記ＯＳから呼出された場合に、前記複数のプロセスにより実行された前記生成処理を検証する
ことを特徴とするソフトウェア更新方法。

（付記１７） ソフトウェア更新検証装置を実現するためにコンピュータで実行されるソフトウェア更新プログラムであって、
前記プログラムは、コンピュータに、
通常モードのＯＳ上で動作する生成手段が、ソフトウェア更新インタフェース手段を呼出す呼出処理を予め定められた複数のプロセスにより実行するステップと、
ソフトウェア更新インタフェース手段が、前記生成手段から呼出された場合に、ソフトウェア更新モードで前記ＯＳを起動するステップと、
前記ＯＳが、前記ソフトウェア更新モードで前記ソフトウェア更新インタフェースから起動された場合に、検証手段を呼出するステップと、
前記検証手段が、前記ソフトウェア更新モードの前記ＯＳから呼出された場合に、前記複数のプロセスにより実行された前記生成処理を検証するステップとを実行させる
ことを特徴とするソフトウェアプログラム。

以上、説明したように、本発明によれば、ソフトウェア更新検証装置、方法及びプログラムにおいて、何らかの不正な方法によっても、複数のプロセスにより実行された生成処理の結果の全てを正確に入手することは殆ど不可能として、生成処理の結果を偽造する等の不正によってはソフトウェアの更新処理の正当性を示す結果を得られなくすることができる。これにより、ソフトウェア更新インタフェースの呼出し自体を禁止することなく、事実上、悪意のある者が汎用ＯＳ上で不当にソフトウェアを更新することを防止することができる。

本発明のソフトウェア更新検証装置を示す構成図である。 本発明のソフトウェア更新検証処理の説明図である。 本発明のソフトウェア更新検証処理の説明図である。 本発明のソフトウェア更新検証処理の説明図である。 本発明のソフトウェア更新検証処理の説明図である。 本発明のソフトウェア更新検証処理の説明図である。 本発明のソフトウェア更新検証処理フローである。 本発明のソフトウェア更新検証処理フローである。 本発明のソフトウェア更新検証処理フローである。 本発明のソフトウェア更新検証処理フローである。 本発明のソフトウェア更新検証処理フローである。 本発明のソフトウェア更新検証処理フローである。 本発明のソフトウェア更新検証処理フローである。 本発明のソフトウェア更新検証処理フローである。

符号の説明

１ ＣＰＵ
２ ＯＳ
３ 生成手段
４ 記憶部
５ 削除手段
６ マネージャ
７ 検証手段
２１ システム時刻取得手段
２５ ソフトウェア更新インタフェース手段
２６ ソフトウェア更新手段
３１ プロセス（Ｐ１〜Ｐｎ）
３２ 更新ファイルダウンロード手段
３３ システム時刻変換手段
３４ システム時刻逆変換手段
４１ 更新ファイル（ＦＩＬＥ１．ｄａｔ〜ＦＩＬＥｎ．ｄａｔ）
４２ チェックファイル

Claims (10)

1. 動作モードとして、通常モードと、ソフトウェア更新インタフェース手段から起動された場合に検証手段を呼出すソフトウェア更新モードとを備えるＯＳと、
   前記通常モードの前記ＯＳ上で動作し、前記ソフトウェア更新インタフェース手段を呼出す呼出処理を含む生成処理を複数のプロセスにより実行する生成手段と、
   前記生成手段から呼出された場合に、前記ソフトウェア更新モードで前記ＯＳを起動するソフトウェア更新インタフェース手段と、
   前記ソフトウェア更新モードの前記ＯＳから呼出された場合に、前記複数のプロセスにより実行された前記生成処理を検証する検証処理を実行する検証手段とを備える
   ことを特徴とするソフトウェア更新検証装置。
2. 前記生成手段が、更に、前記生成処理として、前記複数のプロセスにより複数のチェックファイルの生成を実行し、
   前記検証手段が、前記検証処理として、前記ソフトウェア更新モードの前記ＯＳから呼出された場合に、前記複数のプロセスにより生成された前記複数のチェックファイルを検証する
   ことを特徴とする請求項１に記載のソフトウェア更新検証装置。
3. 当該ソフトウェア更新検証装置が、更に、
   前記ソフトウェア更新モードの前記ＯＳから起動された場合に、更新ファイルを用いて当該プログラムを更新するソフトウェア更新手段を備え、
   前記生成手段が、更新すべきプログラムを格納する前記更新ファイルを獲得し、
   前記ソフトウェア更新モードの前記ＯＳが、前記検証手段から得た検証結果が有効である場合に、前記ソフトウェア更新手段を起動する
   ことを特徴とする請求項２記載のソフトウェア更新検証装置。
4. 前記ソフトウェア更新モードの前記ＯＳが、前記検証手段から得た検証結果が無効である場合に、前記ソフトウェア更新手段を起動することなく、前記通常モードで前記ＯＳを起動する
   ことを特徴とする請求項２記載のソフトウェア更新検証装置。
5. 前記チェックファイルの生成を行うプロセスが、前記複数のチェックファイルの各々にその生成時の時刻又はこれに基づくデータからなる時刻データを保存する
   ことを特徴とする請求項２記載のソフトウェア更新検証装置。
6. 前記検証手段が、前記複数のチェックファイルの各々に保存された前記時刻データが１個の時系列を構成するか否かを検証し、前記時刻データが時系列を構成する場合に、当該検証結果を有効とする
   ことを特徴とした請求項５記載のソフトウェア更新検証装置。
7. 前記検証手段が、前記複数のチェックファイルに保存された前記時刻データの各々と最も近接する他の時刻データとの差分が予め定められた第１の閾値よりも小さいか否かを検証し、前記差分が前記第１の閾値よりも小さい場合に、当該検証結果を有効とする
   ことを特徴とする請求項５記載のソフトウェア更新検証装置。
8. 前記検証手段が、現在の時刻と前記複数のチェックファイルの各々に保存された前記時刻データの中の最も大きな値のデータとの差分が予め定められた第２の閾値よりも小さいか否かを検証し、前記差分が前記第２の閾値よりも小さい場合に、当該検証結果を有効とする
   ことを特徴とする請求項５記載のソフトウェア更新検証装置。
9. ソフトウェア更新検証装置を実現するためにコンピュータで実行されるソフトウェア更新検証方法であって、
   通常モードのＯＳ上で動作する生成手段が、ソフトウェア更新インタフェース手段を呼出す呼出処理を複数のプロセスにより実行し、
   ソフトウェア更新インタフェース手段が、前記生成手段から呼出された場合に、ソフトウェア更新モードで前記ＯＳを起動し、
   前記ＯＳが、前記ソフトウェア更新モードで前記ソフトウェア更新インタフェースから起動された場合に、検証手段を呼出し、
   前記検証手段が、前記ソフトウェア更新モードの前記ＯＳから呼出された場合に、前記複数のプロセスにより実行された前記生成処理を検証する
   ことを特徴とするソフトウェア更新検証方法。
10. ソフトウェア更新検証装置を実現するためにコンピュータで実行されるソフトウェア更新検証プログラムであって、
    前記プログラムは、コンピュータに、
    通常モードのＯＳ上で動作する生成手段が、ソフトウェア更新インタフェース手段を呼出す呼出処理を予め定められた複数のプロセスにより実行するステップと、
    ソフトウェア更新インタフェース手段が、前記生成手段から呼出された場合に、ソフトウェア更新モードで前記ＯＳを起動するステップと、
    前記ＯＳが、前記ソフトウェア更新モードで前記ソフトウェア更新インタフェースから起動された場合に、検証手段を呼出するステップと、
    前記検証手段が、前記ソフトウェア更新モードの前記ＯＳから呼出された場合に、前記複数のプロセスにより実行された前記生成処理を検証するステップとを実行させる
    ことを特徴とするソフトウェア更新検証プログラム。

Images