<第1の実施形態>
<情報処理システム1>
図1に、第1の実施形態に係る情報処理システム1のブロック図を例示する。図1の例によれば、情報処理システム1は、情報処理装置2と、外部記憶媒体3と、情報供給手段4とを含んでいる。ここでは、情報処理装置2が1つの場合を例示するが、情報処理システム1は複数の情報処理装置2を含むことも可能である。なお、図面では各種要素の名称を略記する場合がある。
情報処理装置2は、プログラムに記述された手順に従って、情報を処理する装置である。プログラムは、処理目的、使用目的等に応じて、例えばアプリケーション・ソフトウェア、システム・ソフトウェア、ファームウェア、等に分類される。また、プログラムは、1つのファイルで構成される場合もあるし、複数のファイルの集合体として構成される場合もある。なお、ファイルには、プログラムだけが含まれる場合、データだけが含まれる場合、プログラムとデータの両方が含まれる場合がある。
ここでは、情報処理装置2が例えば、汎用の情報処理装置(パーソナルコンピュータ(PC)等)、特定用途向けの情報処理装置(例えば家庭用ゲーム機)、等である場合を例示する。かかる例にならって、以下、情報処理装置2をユーザ端末装置2、端末装置2、ユーザ端末2等と称する場合もある。
但し、情報処理装置2は例えば、他の装置に組み込まれる部品であっても構わない。そのような利用形態であっても、後述の各種効果が得られる。
外部記憶媒体3は、端末装置2に対して外部接続される記憶手段であり、ここでは端末装置2に着脱自在な(換言すれば交換可能な)メモリカードを例示する。かかる例にならって、以下、外部記憶媒体3をメモリカード3と称する場合もある。なお、メモリカードと同様に利用される媒体であれば、カード状に限定されるものではなく、例えばスティック状であってもよい。外部接続によれば、メモリカード3を容易に交換できる。
但し、外部記憶媒体3は、メモリカードに限定されるものではない。例えば、ハードディスク装置、磁気ディスク、光ディスク、等の記憶手段によって外部記憶媒体3を構成することも可能である。また、一般にメモリカードは可搬型の媒体であるが、非可搬型の媒体を外部記憶媒体3に利用してもよい。
また、ここでは外部記憶媒体3が1個のメモリカードで構成される場合を例示するが、同種又は異種の複数の手段で外部記憶媒体3を構成することも可能である。そのような例では、上記の同種又は異種の複数の手段の総称が外部記憶媒体3にあたる。
なお、端末装置2とメモリカード3をまとめて、情報処理装置セット5、端末装置セット5、端末セット5等と称する場合もある。
情報供給手段4は、端末装置2へ供給する各種情報(後に例示される)を格納するために利用される。ここでは、情報供給手段4として、端末装置2に対して外部接続されるサーバコンピュータを例示する。このため、以下では、情報供給手段4をサーバコンピュータ4、サーバ4等と称する場合もある。
また、ここでは、サーバ4が、WAN(Wide Area Network)の一例であるインターネットを介して(あるいは更にLAN(Local Area Network)を介して)端末装置2に接続される場合を例示する。サーバ4と端末装置2との間のネットワークは有線通信、無線通信又はそれらの混在によって構築される。図1には、端末装置2が、無線通信を介してインターネットに接続され、更にインターネット上のサーバ4に接続される例を模式的に図示している。
なお、サーバ4は、非公開の特定のLAN上に存在するサーバであっても構わない。また、サーバ4と端末装置2とがネットワークを介さず直接的に通信を行う構成が適用されても構わない。
なお、情報供給手段4は、サーバコンピュータに限定されるものではない。例えば、メモリカード、ハードディスク装置、磁気ディスク、光ディスク、等の記憶媒体によって情報供給手段4を構成することも可能である。
また、ここでは情報供給手段4が1台のサーバで構成される場合を例示するが、同種又は異種の複数の手段で情報供給手段4を構成することも可能である。そのような例では、上記の同種又は異種の複数の手段の総称が情報供給手段4にあたる。
以下に、端末装置2とメモリカード3をより具体的に例示する。
<端末装置2(情報処理装置2)>
図1の例によれば、端末装置2は、プロセッサ21と、第1記憶手段22と、アクセスコントローラ23と、無線モジュール24と、リアルタイムクロック(RTC)25とを含んでいる。なお、これらの要素21〜25の接続形態は、図1に例示のバス型に限定されるものではない。
プロセッサ21は、プログラムに記述された処理手順(換言すれば処理ステップ)を実行する。それにより、プロセッサ21は、各種手順に応じた各種処理手段として機能する。換言すれば、プロセッサ21によって、各種手順に応じた各種機能が実現される。
プロセッサ21は、図1の例では、CPU(Central Processing Unit)41と、RAM(Random Access Memory)42とを含んでいる。CPU41はシングルコアであってもよいし、マルチコアであってもよい。RAM42は、CPU41がプログラムを実行する際の作業領域を提供する。
ここでは、プロセッサ21によって実現される各種手段及び各種機能が、CPU41がプログラムに記述された手順を実行することにより、ソフトウェア的に実現される場合を例示する。
但し、CPU41によって実行される処理の一部又は全部を、その処理専用に構成された回路(換言すればハードウェア)によって実現することも可能である。そのような場合、プロセッサ21はそのような専用回路も含む。なお、専用回路として例えばDSP(Digital Signal Processor)、GPU(Graphics Processing Unit)等が知られている。専用回路はプログラムに記述された手順に応じて適宜利用される点に鑑みれば、専用回路によってハードウェア的に実現される各種手段及び各種機能も、プログラムに従って提供される。
すなわち、プロセッサ21は、ソフトウェア又はハードウェア又は両者の組み合わせによって、各種手段及び各種機能を実現する。
第1記憶手段22は、プロセッサ21がアクセス可能に設けられている。上記RAM42は揮発性であるのに対し、第1記憶手段22は不揮発的に情報を記憶する手段である。図1の例では、第1記憶手段22は、取得情報記憶手段61,62と、ファームウェア(F/W)記憶手段63と、ID記憶手段64と、取得回数記憶手段65とを含んでいる。
取得情報記憶手段61,62は、サーバ4から取得した(換言すれば、ダウンロードした)各種情報を格納する手段である。取得情報記憶手段61,62に格納される情報の具体例については後述する。なお、以下では、取得情報記憶手段61,62をダウンロード情報記憶手段61,62、D/L情報記憶手段61,62等と称する場合もある。ここでは、D/L情報記憶手段61,62のそれぞれが、不揮発性且つ書き換え可能な半導体記憶装置(例えばフラッシュメモリ)で構成される場合を例示する。
F/W記憶手段63は、端末装置2のF/W(プロセッサ21によって実行される)を格納する手段である。ここでは、F/W記憶手段63が不揮発性且つ書き換え可能な半導体記憶装置(例えばフラッシュメモリ)で構成される場合を例示する。
ID記憶手段64は、端末装置2の識別情報(いわゆるID)を格納する手段である。IDとして、端末装置2間に互いに重複しない固有の情報、例えば製造シリアル番号等を利用可能である。ここでは、ID記憶手段64が不揮発性且つ書き換え不能な半導体記憶装置(例えばOTP ROM(One Time Programmable Read Only Memory))で構成される場合を例示する。なお、装置IDは端末装置2の製造工程においてID記憶手段64に書き込まれる。
取得回数記憶手段65は、サーバ4から情報を取得した回数(換言すれば、ダウンロード回数)を格納する手段である。なお、以下では、取得回数記憶手段65をD/L回数記憶手段65、D/Lカウンタ65等と称する場合もある。ここでは、D/Lカウンタ65が不揮発性且つ書き換え可能な半導体記憶装置(例えばフラッシュメモリ)で構成される場合を例示する。
なお、ここでは上記記憶手段61,62,63,65のそれぞれが別々の装置(換言すれば別々の部品)で構成される場合を例示するが、これらの記憶手段61,62,63,65のうちの2つ以上を単一の部品で構成することも可能である。例えば、D/L情報記憶手段61,62を1つのフラッシュメモリ内に混在させることも可能である。そのような場合、単一のフラッシュメモリ内の異なる記憶領域によって、D/L情報記憶手段61,62のそれぞれが構成されることになる。
アクセスコントローラ23は、端末装置2(より具体的にはプロセッサ21等)とメモリカード3との間での情報伝送を制御するインターフェース(I/F)手段である。
無線モジュール24は、端末装置2(より具体的にはプロセッサ21等)とサーバ4との間での情報伝送を制御するI/F手段である。ここでは、無線モジュール24が、インターネットに接続された他の無線モジュール(図示略)と無線接続されることによって、無線モジュール24がインターネット上のサーバ4に接続される。なお、無線モジュール24に代えて、有線通信用のモジュールを採用することも可能である。
リアルタイムクロック(RTC)25は、現在時刻の情報(例えば、年、月、日、時、分、秒、曜日等の一部又は全部)を提供する手段である。
なお、ユーザが情報を入力するための入力手段、ユーザに情報を提供するための出力手段等の、いわゆるマン・マシン・インターフェースを、端末装置2に設けることも可能である。そのようなマン・マシン・インターフェースは、情報処理装置2に対して内蔵型、外付け型のいずれであってもよい。
<メモリカード3(外部記憶媒体3)>
図1の例によれば、メモリカード3は、メモリコントローラ81と、第2記憶手段82と、第3記憶手段83とを含んでいる。
メモリコントローラ81は、メモリカード3と端末装置2との間での情報伝送を制御するI/F手段である。図1の例では、メモリコントローラ81は、ホストインターフェース(I/F)101と、メモリインターフェース(I/F)102とを含んでいる。ホストI/F101は、端末装置2のアクセスコントローラ23とメモリカード3のメモリI/F102との間の情報伝送を制御する手段である。メモリI/F102は、ホストI/F101と第2記憶手段82との間の情報伝送、及び、ホストI/F101と第3記憶手段83との間の情報伝を制御する手段である。
第2記憶手段82は、端末装置2(より具体的にはプロセッサ21)を各種処理手段として機能させるためのプログラムを格納する手段である。なお、当該プログラムは、アプリケーション・ソフトウェア、システム・ソフトウェア、ファームウェア、等のいずれであっても構わない。ここでは、第2記憶手段82が不揮発性且つ書き換え不能な半導体記憶装置(例えばOTP ROM)で構成される場合を例示する。
第3記憶手段83は、サーバ4から取得した(換言すれば、ダウンロードした)各種情報を格納する手段である。第3記憶手段83に格納される情報の具体例については後述する。ここでは、第3記憶手段83が不揮発性且つ書き換え可能な半導体記憶装置(例えばシリアル・フラッシュメモリ)で構成される場合を例示する。
なお、第1記憶手段22と第3記憶手段83を総称して、情報保存手段120と称する場合もある。
<情報処理システム1におけるセキュリティ>
以下に、ファイルの改ざんに対抗すべく、情報処理システム1に搭載されているセキュリティ技術を説明する。ここでは、メモリカード3の第2記憶手段82に格納されているプログラムに不具合部分が見つかり、その不具合部分を修正するためのファイルを端末装置2がサーバ4からダウンロードする状況を例示する。
図2に、かかる状況下において修正用のファイル(以下、修正ファイルとも称する)が利用可能になるまでのフローを概略的に示す。図2に例示のフローは、修正ファイルを準備するステップ141と、修正ファイルのダウンロード状況を確認するステップ142と、修正ファイルをダウンロードするステップ143と、装置内認証ファイルを作成するステップ144と、修正ファイルを認証するステップ145と、修正ファイルを有効化する(換言すれば、活性化する)ステップ146とを含んでいる。以下に、各ステップ141〜146及び全体のフローを、より具体的に説明する。
<修正ファイル準備ステップ141>
本ステップ141は、サーバ4の運営者側によって、実行される。具体的には、サーバ運営者側において、不具合修正のための基本的なファイルである第1ファイル及び第2ファイルが作成される。
第1ファイルは、ここでは、いわゆるパッチファイルとする。パッチファイルは、不具合部分を修正した内容を有するファイルである。以下では、第1ファイルをパッチファイル、パッチ等と称する場合もある。
第2ファイルは、ここでは、いわゆるパッチライブラリファイルとする。パッチライブラリファイルは、パッチファイルを第2記憶手段82内のプログラムに対して有効化するための内容を有している。以下では、第2ファイルをパッチライブラリファイル、パッチLIB等と称する場合もある。パッチLIBについては、例えば修正対象となるプログラムの種類、当該パッチLIBの適用範囲等に応じて、複数のバージョンが存在する場合がある。
更に、サーバ4の運営者側によって、パッチファイルの認証ファイル(以下、第1認証ファイルとも称する)が作成される。当該認証ファイルは、端末装置2において、ダウンロードしたパッチファイル(ここでは更にパッチLIB)が本物であること、換言すれば改ざんされていないことを検証するために利用される。
図3に、当該認証ファイルの作成手法を模式的に示す。図3の例によれば、パッチファイル161を予め定められた情報加工手法(第1情報加工手法)171に従って加工することにより、第1認証ファイル163が作成される。
ここでは、情報加工手法171として、パッチファイル161にパッチLIB162を結合し(より具体的には、パッチファイル161を構成するデータ列と、パッチLIB162を構成するデータ列とを結合し)、結合したファイル(すなわち、結合したデータ列)を予め定められた情報加工手法(第4情報加工手法)172に従って加工することにより、認証ファイル163を作成する手法が例示される。なお、ファイル161,162の結合順序等は情報加工手法171において予め定められている。
また、ここでは、情報加工手法172として、ダイジェストアルゴリズム173(例えばハッシュアルゴリズム)が例示される。ダイジェストアルゴリズム173の例にならい、以下、認証ファイル163をダイジェストファイル163と称する場合もある。
なお、情報加工手法171,172として、他の処理内容を採用しても構わない。
サーバ運営者は、図4に模式的に示すように、パッチファイル161とパッチLIB162と認証ファイル163とを、パッチファイル161を適用するプログラムを特定するための情報164と共に、サーバ4へ格納する。ここでは、情報164として、パッチファイルを適用するプログラムのタイトル(以下、パッチ適用タイトルとも称する)を例示するが、この例に限定されるものではない。サーバ4において、これらの情報161,162,163,164はワンセットで管理される。
<D/L状況確認ステップ142>
本ステップ142(図2参照)は、端末装置2において実行される。具体的には、図5に模式的に示すようにF/W記憶手段63に修正ファイル取得状況管理プログラム181が予め格納されており、当該プログラム181を実行することにより、換言すれば当該プログラム181によってプロセッサ21が修正ファイル取得状況管理手段として機能することにより、本ステップ142が行われる。
修正ファイル取得状況管理プログラム181によれば、サーバ4に準備される複数種類のパッチファイル161のそれぞれの取得状況が、端末装置2の第1記憶手段22において管理される。
修正ファイル取得状況管理プログラム181は、サーバ4においてパッチファイル161等が追加又は更新されたか否かをチェックするために、所定のタイミングで実行される。当該プログラム181の実行タイミングとして、例えば、端末装置2のF/Wのアップデート時、予め設定された時間の経過時、等が例示される。また、パッチファイル161等が準備されたことをサーバ4が通知する構成の場合、その通知を受け取ったタイミングで当該プログラム181を実行してもよい。また、ユーザが起動指示を入力したタイミングで、プログラム181を実行してもよい。プログラム181の実行タイミングは、複数種類のタイミング(例えばサーバ4からの通知受信時とユーザ指示時との組み合わせ)を含んでもよい。
修正ファイル取得状況管理プログラム181によれば、修正ファイル取得状況情報、例えば、サーバ4にどのタイトルのパッチファイル161が準備されているのかに関する情報、サーバ4に未取得のパッチファイル161等が在るかの否かに関する情報、等が管理される。
図6に例示のファイル取得状況情報182は、サーバ4にパッチファイル161が準備されているプログラムのタイトル(すなわちパッチ適用タイトル164)と、使用するパッチLIB162のバージョンと、パッチファイル161等を本端末装置2がダウンロード済みであるか否かに関する情報(以下、D/L履歴とも称する)とを含んでいる。なお、これらの情報は図6に例示されるテーブル形式以外の形式で管理されてもよい。
ファイル取得状況情報182においてパッチ適用タイトル164と、パッチLIBバージョンと、D/L履歴とは直接的又は間接的に関連付けられており、データベース(DB)が構築されている。このため、例えばパッチ適用タイトル164を検索キーに設定して当該データベースを検索することにより、その検索キーに関連付けられた情報(すなわちパッチLIB162のバージョンとD/L履歴)を抽出可能である。なお、以下では、修正ファイル取得状況情報182を、パッチ適用タイトルDB182と称する場合もある。
図7に示すように、パッチ適用タイトルDB182は、端末装置2のD/L情報記憶手段61内(従って第1記憶手段22内)に設けられている。図7は記憶手段61,62,82,83に格納される各種情報を例示する模式図である。図7には後述の各種情報も図示している。なお、図7は、記憶手段61,62,82,83の記憶容量、各種情報のデータサイズ、格納位置、等を限定するものではない。
ここで、修正ファイル取得状況管理プログラム181は(換言すれば、D/L状況確認ステップ142は)、パッチ適用タイトルDB182の管理を行うのみであり、パッチファイル161等の実体ファイルは次のD/Lステップ143(図2参照)においてダウンロードされる。
図8に、修正ファイル取得状況管理プログラム181のフローチャートを例示する。図8の例では、当該プログラム181はステップ183〜185を含んでおり、ステップ183〜185がこの順序で実行される。
ステップ183では、プロセッサ21が無線モジュール24を介して、サーバ4に格納されているパッチ適用タイトル164を取得する。そして、プロセッサ21は、取得したパッチ適用タイトル164をパッチ適用タイトルDB182に登録する。
次に、ステップ184では、プロセッサ21が無線モジュール24を介して、サーバ4に格納されているパッチLIB162のバージョンを取得する。なお、この際、パッチLIB162自体はダウンロードしない。プロセッサ21は、取得したパッチLIBバージョンを、パッチ適用タイトル164に関連付けて、パッチ適用タイトルDB182に登録する。
次に、ステップ185では、新しいパッチファイル161が存在するパッチ適用タイトル164に対して、パッチ適用タイトルDB182のD/L履歴を“未取得”に設定する。新しいパッチファイル161の存在は、例えば上記ステップ184で取得したパッチLIB164のバージョンが更新されることによって判断可能である。あるいは、パッチファイル161がサーバ4に格納された日時等をサーバ4から取得することによって、新しいパッチファイル161の存在を判断してもよい。
なお、ステップ184,185の実行順序を入れ替えても構わない。
<D/Lステップ143>
本ステップ143(図2参照)は、メモリカード3が接続された状態の端末装置2において実行される。具体的には、メモリカード3の第2記憶手段82内のプログラムが起動することにより、本ステップ143が実行される。
図9に模式的に示すようにメモリカード3の第2記憶手段82には、本体プログラム201と、修正ファイル管理プログラム202とが予め格納されている。本体プログラム201は、アプリケーション・ソフトウェア等の本体部分のプログラム(換言すれば、メインプログラム)であり、ここではパッチファイル161が適用されるプログラムである。
修正ファイル管理プログラム202は、本体プログラム201に付随して設けられたプログラムであり、本体プログラム201に対して起動指示が発生する度に、本体プログラム201の実行に先立って実行される。なお、プログラムの起動指示は、例えばユーザによって端末装置2へ入力される。あるいは、端末装置2がメモリカード3の接続を検出することによって、端末装置2内で自動的に本体プログラム201の起動指示を生成する構成を採用してもよい。
修正ファイル管理プログラム202を端末装置2のプロセッサ21が実行することによって、プロセッサ21が修正ファイル管理手段として機能する。
修正ファイル管理プログラム202は、図9に例示するように、修正ファイル取得プログラム203を含んでいる。当該プログラム203を端末装置2のプロセッサ21が実行することにより、換言すれば当該プログラム203によってプロセッサ21が修正ファイル取得手段として機能することにより、本D/Lステップ143(図2参照)が行われる。
なお、図9に例示するように、修正ファイル管理プログラム202は更に、装置内認証ファイル作成プログラム204と、認証プログラム205と、修正ファイル有効化プログラム206と含んでいる。これらのプログラム204〜206については後述する。
図10に、修正ファイル取得プログラム203のフローチャートを例示する。なお、図10には参考のため、プログラム204〜206の実行も併記している。図10に示すように、修正ファイル取得プログラム203は、本体プログラム201の起動指示の発生に伴って、且つ、他のプログラム201,204,205,206に先立って、実行される。図10の例によれば、修正ファイル取得プログラム203はステップ221〜224を含んでおり、ステップ221〜224がこの順序で実行される。
ステップ221では、プロセッサ21が、起動しようとする本体プログラム201がパッチ適用対象であるか否かを調べる。具体的には、起動しようとする本体プログラム201のタイトルを検索キーに設定してD/L情報記憶手段61内のパッチ適用タイトルDB182を検索する。検索の結果、本体プログラム201のタイトルがDB182に登録されていなければ、適用するパッチが存在しないので、修正ファイル管理プログラム202を終了し、本体プログラム201を開始する。一方、起動しようとする本体プログラム201のタイトルがパッチ適用タイトルDB182に登録されていれば、ステップ222が実行される。
ステップ222では、プロセッサ21が、本体プログラム201のパッチファイル161等がダウンロード済みか否かを調べる。具体的には、パッチ適用タイトルDB182において、上記ステップ221でヒットしたパッチ適用タイトルに関連付けられているD/L履歴を参照する。D/L履歴に“取得済み”が登録されている場合、修正ファイル取得プログラム203を終了して認証プログラム205を開始する。一方、D/L履歴に“未取得”が登録されている場合、ステップ223が実行される。
ステップ223では、プロセッサ21がサーバ4からパッチファイル161等をダウンロードする。当該ステップ223は、パッチファイル161の取得ステップと、パッチLIB162の取得ステップと、認証ファイル163(すなわちダイジェストファイル163)の取得ステップとを含む。
より具体的には、パッチ取得ステップでは、パッチファイル161をサーバ4からメモリカード3の第3記憶手段83へ転送する(図7参照)。なお、第2記憶手段82内のプログラムが第3記憶手段83を利用する場合、そのような利用領域を避けてパッチファイル161が格納される。
パッチLIB取得ステップでは、パッチLIB162をサーバ4から端末装置2のD/L情報記憶手段61へ転送する(従って、パッチLIB162は第1記憶手段22へ転送される。図7参照)。なお、ここでは、パッチLIB162が、パッチLIB実体とパッチLIB管理情報に分けて、D/L情報記憶手段61に格納される場合を例示する。パッチLIB管理情報については後述する。
認証ファイル取得ステップでは、認証ファイル163をサーバ4から端末装置2のD/L情報記憶手段62へ転送する(従って、認証ファイル163は第1記憶手段22へ転送される。図7参照)。なお、D/L情報記憶手段62への情報書き込みは所定位置からダウンロード順に行われる。
なお、3つのファイル161〜163は、どの順番でダウンロードしても構わない。また、各ファイル161〜163は、例えば、無線モジュール24を介してプロセッサ21(より具体的にはRAM42)へ取り込まれた後に、所定の記憶手段へ格納される。あるいは、各ファイル161〜163を、プロセッサ21を介さずに、無線モジュール24から所定の記憶手段へ格納するようにしてもよい。後者のファイル転送は、例えば、プロセッサ21が無線モジュール24に対して、受信ファイル161〜163の転送先を指示することによって、実行可能である。
このように、ステップ221〜223によれば、パッチ適用タイトルDB182を参照して、パッチファイル161等がサーバ4から取得される。
また、ステップ223では、パッチファイル161等のダウンロードに関連した処理を行う。かかるD/L関連処理は、ここでは、パッチ管理情報更新ステップと、パッチLIB管理情報更新ステップとを含む。
パッチ管理情報更新ステップでは、プロセッサ21が、メモリカード3の第3記憶手段83に格納されているパッチ管理情報227(図7参照)を更新する。
図11に、パッチ管理情報227の一例を示す。図11に例示のパッチ管理情報227は、端末装置2のIDと、パッチ適用タイトルと、パッチLIBのバージョンと、メモリカード3の第2記憶手段82のページアドレスと、メモリカード3の第3記憶手段83のページアドレスと、D/Lカウント値と、D/L時刻とを含んでいる。パッチ管理情報更新ステップでは、今回ダウンロードしたパッチファイル161等に関して、これらの項目の情報の追加、修正、削除等を行う。なお、各項目は図11に例示されるテーブル形式以外の形式で管理されてもよい。
装置IDは、パッチファイル161等のダウンロードを担当した端末装置2のIDであり、その端末装置2のID記憶手段64から取得して記録される。図11の例では“MCC0020000”というIDを有する端末装置2と、“MCC0041235”というIDを有する端末装置2とによって、パッチファイル161等がダウンロードされたことが記録されている。
パッチ適用タイトルは、パッチファイル161が適用される本体プログラム201のタイトルである。図11の例によれば、“MCC_BATTEL”、“MCC_DAYS”、“MCC_TRAVEL”というタイトルの3つのプログラムに対して、パッチファイル161がメモリカード3に格納されている。
パッチLIBのバージョンは、利用するパッチLIBのバージョンである。図11の例によれば、“1.00”、“1.01”、“2.00”という3つのバージョンが存在することが記録されている。
第2記憶手段82のページアドレスは、第2記憶手段82内の不具合部分の開始アドレスである。一方、第3記憶手段83のページアドレスは、パッチファイル161が格納されている開始アドレスである。
D/Lカウント値は、ダウンロードを担当した端末装置2によって行われた累計D/L回数である。D/Lカウント値には、端末装置2のD/Lカウンタ65が、その時点で保持している累計カウント値が記録される。なお、プロセッサ21は、D/Lカウンタ65から累計カウント値を取得した後又は取得前に、D/Lカウンタ65に保持しているD/L回数をインクリメントする。
D/L時刻は、パッチファイル161等のダウンロード完了時刻であり、RTC25(図1参照)から取得して記録される。
図11の例によれば、“MCC_BATTEL”用のパッチファイル161が、“MCC0020000”というIDの端末装置2によって、時刻“19:30”にダウンロードされたこと、が記録されている。また、そのダウンロード時にその端末装置2のD/Lカウンタ65の値が“1”であったこと、が記録されている。また、“MCC_BATTEL”用のパッチファイル161にはバージョン“1.00”のパッチLIB162が利用されること、が記録されている。また、図11の例によれば、“MCC_DAYS”用に2つのパッチファイル161が同時刻に一括してダウンロードされたこと、が記録されている。また、図11の例によれば、“MCC_TRAVEL”用の同じパッチファイル161が2つの端末装置2によってダウンロードされたこと、が記録されている。なお、当該2つの端末装置2間でD/Lカウンタ65は独立であるため、D/Lカウント欄には端末装置ごとの値が記録されている。
装置IDと、パッチ適用タイトルと、パッチLIBバージョンと、第2記憶手段82のページアドレスと、第3記憶手段83のページアドレスと、D/Lカウント値と、D/L時刻とは直接的又は間接的に関連付けられており、データベース(DB)が構築されている。このため、例えば装置IDとパッチ適用タイトルとの組み合わせを検索キーに設定して当該データベースを検索することにより、その検索キーに関連付けられた情報(すなわち、パッチLIBバージョンと、第2記憶手段82のページアドレスと、第3記憶手段83のページアドレスと、D/Lカウント値と、D/L時刻)を抽出可能である。特に、第2記憶手段82のページアドレスと、第3記憶手段83のページアドレスとの対応を取得可能である。
ここで、パッチ適用タイトルの代わりに、各タイトルに関連付けたID等を採用してもよい。また、ページアドレス単位ではなく、バイト単位で、パッチ管理情報227を構成することも可能である。なお、バイト単位の管理では、パッチを適用する部分のサイズも管理される。
また、図11の例では第2記憶手段82内の不具合部分をページアドレスで特定するが、これに代えて、本体プログラム201を構成するファイル単位で(あるいはファイルのバイト単位で)、パッチ管理情報227を形成することも可能である。そのようなパッチ管理情報227を図12に例示する。なお、図12の例では、各ファイルのサイズも管理される。
パッチLIB管理情報更新ステップに関し、上記のように、パッチLIB162は、パッチLIB実体とパッチLIB管理情報に分けて、D/L情報記憶手段61に格納される。パッチLIB管理情報更新ステップでは、プロセッサ21が、そのパッチLIB管理情報を更新する。
図13に、パッチLIB管理情報228の一例を示す。図13に例示のパッチLIB管理情報228は、パッチLIB162のバージョンと、パッチLIB162の実体を格納している領域の開始アドレスと、パッチLIB162の実体のサイズとを含んでいる。パッチLIB管理情報更新ステップでは、今回ダウンロードしたパッチファイル161等に関して、これらの項目の情報の追加、修正、削除等を行う。なお、各項目は図13に例示されるテーブル形式以外の形式で管理されてもよい。
図13の例では、パッチLIBバージョンと、パッチLIB実体の格納領域の開始アドレスと、パッチLIB実体のサイズとが直接的又は間接的に関連付けられており、データベース(DB)が構築されている。このため、例えばパッチLIBバージョンを検索キーに設定して当該データベースを検索することにより、その検索キーに関連付けられた情報(すなわち、パッチLIB実体の格納領域の開始アドレスと、パッチLIB実体のサイズ)を抽出可能である。
なお、パッチ管理情報更新ステップと、パッチLIB管理情報更新ステップは、いずれを先に実行しても構わない。また、上記では説明のために2つの更新ステップを分けたが、例えばパッチLIBバージョンは管理情報227,228で共通の項目であるため、同じタイミングで更新してもよい。
その後、ステップ224(図10参照)では、プロセッサ21がパッチ適用タイトルDB182において、上記ステップ223を実行したパッチ適用タイトル164に対応する、D/L履歴を“取得済み”に更新する。
<装置内認証ファイル作成ステップ144>
本ステップ144(図2参照)は、メモリカード3が接続された状態の端末装置2において、上記D/Lステップ143に引き続いて実行される。具体的には、修正ファイル管理プログラム202(図9参照)に含まれる装置内認証ファイル作成プログラム204を実行することにより、換言すれば当該プログラム204によってプロセッサ21が装置内認証ファイル作成手段として機能することにより、本ステップ144が行われる。
本ステップ144では、パッチファイル161等をダウンロードした時点で、換言すればパッチファイル161等のダウンロードに伴って、認証ファイル163とは別の新しい認証ファイル245(図7参照)を端末装置2において作成する。以下では、サーバ4の運営者側で作成された第1認証ファイル163(すなわちダイジェストファイル163)に対し、端末装置2で新たに作成する認証ファイル245を、第2認証ファイル245、装置内認証ファイル245等と称する場合もある。第2認証ファイル245は、端末装置2のD/L情報記憶手段62に格納される(従って、第2認証ファイル245は第1記憶手段22に格納される。図7参照)。
図14に、第2認証ファイル245の作成手法を模式的に示す。図14の例によれば、第1認証ファイル163(すなわちダイジェストファイル163)を予め定められた情報加工手法(第2情報加工手法)231に従って加工することにより、第2認証ファイル245が作成される。
ここでは、情報加工手法231として、第1認証ファイル163に補助ファイル246を結合し、結合したファイルを予め定められた情報加工手法(第3情報加工手法)232に従って加工することにより、第2認証ファイル245を作成する手法が例示される。補助ファイル246は、パッチファイル161等の取得に関連してユニークに定まる内容を有する。以下では、第2認証ファイル245の作成に用いる補助ファイル246を、第3認証ファイル246、装置内認証ファイル246等と称する場合もある。
図14に加え、図15及び図16を参照して、認証ファイル245,246の作成手法をより具体的に例示する。なお、図15は装置内認証ファイル作成プログラム204を例示するフローチャートであり、図15には参考のためプログラム203,205,206の実行も併記している。また、図16は、第3認証ファイル246の作成手法を例示する模式図である。
図15に示すように、装置内認証ファイル作成プログラム204は、修正ファイル取得プログラム203の後に、且つ、残余のプログラム205,206に先立って、実行される。図15の例によれば、装置内認証ファイル作成プログラム204はステップ241,242を含んでおり、ステップ241,242がこの順序で実行される。
ステップ241では、プロセッサ21が、予め定められたユニークファイル作成手法(第1ユニークファイル作成手法)233(図16参照)に従って第3認証ファイル246を作成する。第3認証ファイル246は、端末装置2のD/L情報記憶手段62へ(従って、第1記憶手段22へ)格納される(図7参照)。
図16の例示のユニークファイル作成手法233によれば、直前にダウンロードしたパッチファイル161等に関連する、D/Lカウント値と、D/L時刻と、パッチLIBバージョンと、パッチ適用タイトルとを収集し、収集したこれらの情報(換言すれば、そのデータ列)を結合したデータ列を第3認証ファイル246に設定する。
ここで、第3認証ファイルを構成する上記各情報は、種々の手法で収集可能である。例えば、上記各情報はパッチ管理情報227(図12参照)に含まれるので、パッチ管理情報更新ステップの際にRAM42等にも上記各情報を一時保存しておき、そこから上記各情報を収集してもよい。あるいは、パッチ管理情報更新ステップの際に第3認証ファイル246の格納領域にも上記各情報を書き込むようにしてもよい。この例によれば、それらの格納領域の情報を一括して読み出せば、情報の収集と結合を一括で行うことが可能である。あるいは、更新後のパッチ管理情報227から上記各情報を収集してもよい。あるいは、例えばパッチLIBバージョン及びパッチ適用タイトルは、パッチ適用タイトルDB182から取得してもよい。
第3認証ファイル246を構成する上記各情報の種類、個数、収集先、結合順序等は、ユニークファイル作成手法233において予め定められている。また、上記例示の情報に加えて又は代えて、ダウンロードしたパッチファイル161等に関連する他の情報を利用してもよい。なお、ユニークファイル作成手法233を他の処理内容で以て定義してもよい。
その後、ステップ242において、プロセッサ21が、第3認証ファイル246を利用して、第2認証ファイル245を作成する。図14の例では上記のように、第1認証ファイル163に第3認証ファイル246を結合し、結合したファイルを予め定められた情報加工手法232に従って加工することにより、第2認証ファイル245が作成される。
図14に例示の情報加工手法232によれば、第1認証ファイル163と第3認証ファイル246とを結合した結合ファイルを、所定のAESアルゴリズム249で暗号化することによって、第2認証ファイル245を作成する。
この際、図14の例では、AESアルゴリズム249で利用する暗号鍵250は、次のようにして生成される。すなわち、第3認証ファイル246と装置IDとを結合し、得られた結合ファイル(換言すれば、結合したデータ列)をシードとして擬似乱数生成手段251へ入力し、得られた乱数値の先頭128ビットを暗号鍵250に採用する。
なお、AESアルゴリズム249以外の暗号化手法(例えばハッシュアルゴリズム)を用いてもよい。また、擬似乱数生成手段251へ入力するシードは上記の例に限定されないし、更に暗号鍵250の生成手法は上記の例に限定されるものではない。
ここでは、説明を分かりやすくするために、装置内認証ファイル作成プログラム204が、修正ファイル取得プログラム203の後に、実行される場合を例示した(図10、図15、図2参照)。これに対し、例えば、修正ファイル取得プログラム203のステップ223,224(図10参照)の間に、装置内認証ファイル作成プログラム204を呼び出す割り込みステップを設けてもよい。いずれの例においても、装置内認証ファイル作成プログラム204は、修正ファイル取得プログラム203に付随し、パッチファイル161等をダウンロードした時点で(換言すればパッチファイル161等のダウンロードに伴って)実行される。
<修正ファイル認証ステップ145>
本ステップ145(図2参照)は、メモリカード3が接続された状態の端末装置2において実行される。具体的には、図10に示されるように、パッチファイル161等の修正ファイルをダウンロード済みの状態、且つ、ダウンロード済みの修正ファイルに対して装置内認証ファイル245,246が作成済みの状態において、本ステップ145が実行される。
本ステップ145は、修正ファイル管理プログラム202(図9参照)に含まれる認証プログラム205を実行することにより、換言すれば当該プログラム205によってプロセッサ21が認証手段として機能することにより、行われる。
本ステップ145では、これから実行しようとする本体プログラム201(ここでは“MCC_BATTEL”(図11参照)を例示する)用のパッチファイル161及びパッチLIB162が、サーバ4からダウンロードした後に改ざんされていないかが検証される。すなわち、メモリカード3に格納されているパッチファイル161及びD/L情報記憶手段61に格納されているパッチLIB162が、サーバ4から取得した時点と同じものである場合には、肯定的な判断(すなわち、改ざんされていない旨の判断)が下される。逆に、それらのファイル161,162が、サーバ4から取得した時点とは異なる場合には、否定的な判断(すなわち、改ざんされている可能性がある旨の判断)が下される。
図17に、認証プログラム205のフローチャートを例示する。なお、図17には参考のため、修正ファイル有効化プログラム206の実行も併記している。図17の例では、認証プログラム205はステップ261〜266を含んでおり、ステップ261〜266この順序で実行される。
ステップ261では、第1認証ファイル163(すなわちダイジェストファイル163)に対応する評価ファイル(以下、第1評価ファイルとも称する)を作成する。
具体的には、これから実行しようとする本体プログラム201に関連して、第3記憶手段83に格納されているパッチファイル161(すなわち第1ファイル161)と、D/L情報記憶手段61(換言すれば第1記憶手段22)に格納されているパッチLIB162(すなわち第2ファイル162)と、を読み出す。そして、読み出したファイル161,162を、図18の模式図に示すように、第1認証ファイル163の作成手法(図3参照)と同じ情報加工手法171,172,173に従って加工することにより、第1評価ファイル281を作成する。すなわち、読み出したファイル161,162を結合し、結合したファイルをダイジェストアルゴリズム173で処理することにより、第1評価ファイル281が作成される。
ステップ262では、第3認証ファイル246に対応する評価ファイル(以下、第3評価ファイルとも称する)を作成する。
具体的には、図19の模式図に示すように、予め定められたユニークファイル作成手法(第2ユニークファイル作成手法)234に従って第3評価ファイル283を作成する。すなわち、これから実行しようとする本体プログラム201に関連して、D/Lカウント値と、D/L時刻と、パッチLIBバージョンと、パッチ適用タイトルとを収集し、収集したこれらの情報を結合したデータ列を第3評価ファイル283に設定する。
第3評価ファイル283の作成手法234は、第3認証ファイル246の作成手法(図16参照)に対応して定義されている。具体的には、両手法234,233は、ファイル283,246を構成する情報の種類、個数、結合順序等において同じであるが、当該各情報の収集先が異なる。すなわち、第3評価ファイル283の作成手法234には、上記各情報をメモリカード3に格納されているパッチ管理情報227(図7及び図11参照)から取得するように定義されている。
なお、第3認証ファイル246の作成手法233がパッチ管理情報227から上記各情報を収集するように定義されている場合には、当該ファイル作成手法233を第3評価ファイル283の作成に流用可能である。
ステップ263では、第2認証ファイル245に対応する評価ファイル(以下、第2評価ファイルとも称する)を作成する。
具体的には、図20の模式図に示すように、上記ステップ261で作成した第1評価ファイル281を、第2認証ファイル245の作成と同じ情報加工手法231,232に従って加工することにより、第2評価ファイル282を作成する。すなわち、第1評価ファイル281を補助ファイル(ここでは上記ステップ262で作成した第3評価ファイル283)と結合し、結合したファイルをAESアルゴリズム249(図14参照)で処理することにより、第2評価ファイル282が作成される。
この際、AESアルゴリズム249で利用する暗号鍵250は、次のようにして生成される。すなわち、ID記憶手段64に格納されている装置IDを読み出し、当該装置IDと第3評価ファイル283とを結合し、得られた結合ファイルをシードとして擬似乱数生成手段251へ入力し、得られた乱数値の先頭128ビットを暗号鍵250に採用する。
ステップ264では、上記ステップ261で作成した第1評価ファイル281を、D/L情報記憶手段61(換言すれば第1記憶手段22)に格納されている第1認証ファイル163(すなわちダイジェストファイル163)と比較する。比較の結果、第1評価ファイル281が第1認証ファイル163と同じである場合は、次のステップ265を実行する。これに対し、第1評価ファイル281が第1認証ファイル163と異なる場合は、認証プログラム205及び修正ファイル管理プログラム202(図10参照)を終了し、しかも本体プログラム201を開始させない。
ステップ265では、上記ステップ262で作成した第3評価ファイル283を、D/L情報記憶手段61(換言すれば第1記憶手段22)に格納されている第3認証ファイル246と比較する。比較の結果、第3評価ファイル283が第3認証ファイル246と同じである場合は、次のステップ266を実行する。これに対し、第3評価ファイル283が第3認証ファイル246と異なる場合は、認証プログラム205及び修正ファイル管理プログラム202(図10参照)を終了し、しかも本体プログラム201を開始させない。
ステップ266では、上記ステップ263で作成した第2評価ファイル282を、D/L情報記憶手段61(換言すれば第1記憶手段22)に格納されている第2認証ファイル245と比較する。比較の結果、第2評価ファイル282が第2認証ファイル245と同じである場合は、認証プログラム205を終了して、修正ファイル有効化プログラム206を実行する。これに対し、第2評価ファイル282が第2認証ファイル245と異なる場合は、認証プログラム205及び修正ファイル管理プログラム202(図10参照)を終了し、しかも本体プログラム201を開始させない。
つまり、第1評価ファイル281が第1認証ファイル163と同じであり、且つ、第2評価ファイル282が第2認証ファイル245と同じであり、且つ、第3評価ファイル283が第3認証ファイル246と同じである場合にのみ、パッチファイル161及びパッチLIB162はダウンロード後に改ざんされていない旨の判断(すなわち肯定的な判断)が下される。そして、次の修正ファイル有効化プログラム206が実行される。
これに対し、第1評価ファイル281は第1認証ファイル163と異なる旨の比較結果と、第2評価ファイル282は第2認証ファイル245と異なる旨の比較結果と、第3評価ファイル283は第3認証ファイル246と異なる旨の比較結果とのうちの少なくとも1つが得られた場合、パッチファイル161及びパッチLIB162はダウンロード後に改ざんされた可能性がある旨の判断(すなわち否定的な判断)が下される。このため、本体プログラム201を開始させない。
なお、上記ステップ261〜266の実行順序は図17の例に限定されるものではない。例えば、図21に例示のフローチャートのように、ステップ261、ステップ264、ステップ262、ステップ265、ステップ263、ステップ266の順序を採用してもよい。また、例えば、比較ステップ264〜266を並列的に実行してもよい。
<修正ファイル有効化ステップ146>
本ステップ146(図2参照)は、メモリカード3が接続された状態の端末装置2において実行される。具体的には、図17に示されるように、認証ステップ145において肯定的な判断(すなわち、パッチファイル161及びパッチLIB162はダウンロード後に改ざんされていない旨の判断)が下された場合に、本ステップ146が実行される。
本ステップ146は、修正ファイル管理プログラム202(図9参照)に含まれる修正ファイル有効化プログラム206を実行することにより、換言すれば当該プログラム206によってプロセッサ21が修正ファイル有効化手段として機能することにより、行われる。
本ステップ146では、D/L情報記憶手段61(換言すれば第1記憶手段22)に格納されているパッチLIB162を起動することにより、メモリカード3の第3記憶手段83に格納されているパッチファイル161を有効化する。
具体的には、パッチLIB162の実行により、パッチ適用タイトル(すなわち、これから実行しようとする本体プログラム201のタイトル)と装置IDとが検索キーに設定されて、メモリカード3の第3記憶手段83内のパッチ管理情報227(図11参照)が検索される。そして、その検索キーに関連付けられた情報が抽出される。図11の例の場合、第2記憶手段82内の本体プログラム201中の不具合部分のページアドレスと、第3記憶手段83内のパッチファイル161のページアドレスとが抽出される。
抽出された情報は、RAM42上に展開され、プロセッサ21によって本体プログラム201の実行中に利用される。具体的には、プロセッサ21は、本体プログラム201中の不具合部分のページアドレスに対するアクセス命令が発生した場合、その不具合部分アドレスに関連付けられている、第3記憶手段83内のページアドレスへアクセスする。これにより、不具合部分にパッチファイル161が適用される(換言すれば、組み込まれる)。
なお、図17の例では、修正ファイル認証ステップ145で否定的な判断が下された場合、修正ファイル有効化ステップ146だけでなく、本体プログラム201も実行しない。更に、改ざんの可能性があるパッチファイル161等を削除するようにしてもよい。あるいは、パッチファイル161等をサーバ4から再度、ダウンロードするようにしてもよい。
<効果>
上記構成によれば、サーバ4から供給される第1認証ファイル163だけでなく、端末装置2内で作成する第2認証ファイル245及び第3認証ファイル246も使って、取得済みのパッチファイル161等の認証を行う。このため、第1認証ファイル163だけで認証を行う場合に比べて、セキュリティが向上する。
特に、第2認証ファイル245及び第3認証ファイル246は端末装置2の内部で作成され利用される。すなわち、これらの装置内認証ファイル245,246の存在及び用途、並びに、装置内認証ファイル245,246を作成するための情報加工手法231,232,233(図14及び図16参照)は、端末装置2の外部に対して公開性を有していない。このため、装置内認証ファイル245,246によれば、第1認証ファイル163よりも高いセキュリティを提供することができる。
例えばパッチファイル161が、ダウンロード後に改ざんされた場合を想定する。パッチファイル161はダイジェストファイル163(すなわち第1認証ファイル163)の作成に利用されているので、ダイジェストファイル163とその評価ファイル(すなわち第1評価ファイル)281との比較によって、パッチファイル161の改ざんを検出可能である。
より具体的には、認証処理(図17参照)において、第1評価ファイル281は、改ざんされたパッチファイル161を使って作成されることになる(ステップ261参照)。端末装置2に格納されている第1認証ファイル163は改ざんされていないとすると、第1評価ファイル281は第1認証ファイル163と一致せず(ステップ264参照)、否定的な判断が下される。
また、第1評価ファイル281を使って作成される第2評価ファイル282と、第2認証ファイル245との比較においても(ステップ266参照)、同様に、否定的な判断が下される。
したがって、パッチファイル161の改ざんを検出でき、改ざんされたパッチファイル161の利用、及び、改ざんに起因した悪影響の発生を防止できる。
次に、例えばパッチLIB162が、ダウンロード後に改ざんされた場合を想定する。パッチLIB162はダイジェストファイル163の作成に利用されているので、パッチファイル161についての上記認証と同様にして、パッチLIB162の改ざんを検出可能である。よって、改ざんされたパッチLIB162の利用、及び、改ざんに起因した悪影響の発生を防止できる。
次に、例えば、ダイジェストファイル163の作成手法(図3参照)がクラッカーに知られ、パッチファイル161及びパッチLIB162と共に、ダイジェストファイル163も、ダウンロード後に改ざんされた場合を想定する。この場合、改ざんしたパッチファイル161及びパッチLIB162に整合するように、ダイジェストファイル163を改ざんすることが可能になる。そうすると、第1評価ファイル281は、改ざんされたダイジェストファイル163と一致するので、第1評価ファイル281を利用してもファイル161〜163の改ざんを検出困難な状況が発生しうる。
ここで、第2評価ファイル282は、改ざんされたダイジェストファイル163と一致する第1評価ファイル281から作成されることになる。一方、端末装置2に格納されている第2認証ファイル245は改ざんされていないとすると、第2評価ファイル282は第2認証ファイル245と一致せず、否定的な判断が下される。したがって、ファイル161〜163のいずれかに改ざんがあることを検出可能であり、改ざんされたパッチファイル161等の利用、及び、改ざんに起因した悪影響の発生を防止できる。
次に、例えば、第2認証ファイル245が改ざんされた場合を想定する。この場合、第2認証ファイル245と第2評価ファイル282との比較によって(図17のステップ266参照)、第2認証ファイル245の改ざんを検出可能である。
上記のように第2認証ファイル245の存在、用途、作成手法等は非公開である。このため、第2認証ファイル245の存在等がクラッカーに知られなければ、第2認証ファイル245と第2評価ファイル282との比較による認証が破られる可能性は低いと考えられる。
かかる点は、第3認証ファイル246の改ざんについても同様である。すなわち、仮に第3認証ファイル246が改ざんされた場合であっても、第3認証ファイル246と第3評価ファイル283との比較によって(図17のステップ265参照)、第3認証ファイル246の改ざんを検出可能である。また、第3認証ファイル246の存在、用途、作成手法等は非公開であるため、第3認証ファイル246と第3評価ファイル283との比較による認証が破られる可能性は低いと考えられる。
なお、装置内認証ファイル245,246の改ざんが検出された場合、パッチファイル161及びパッチLIB162は改ざんされていない状況もあり得るが、クラッカーの侵入が疑われる。このため、装置内認証ファイル245,246に改ざんが検出されたことを条件にして、パッチファイル161の利用を中止することは好ましい。
このように、第2認証ファイル245及び第3認証ファイル246の採用により、高いセキュリティを提供できる。
ここで、図14の例によれば、第3認証ファイル246は第2認証ファイル245の作成に利用されるので、第2認証ファイル245と第2評価ファイル282との比較によっても(図17のステップ266参照)、第3認証ファイル246の改ざんを検出可能である。かかる点に鑑みれば、第3認証ファイル246と第3評価ファイル283との比較処理(図17のステップ265参照)を省略することも可能である。なお、その場合、第3認証ファイル246をD/L情報記憶手段62に格納しなくても構わない。
また、第3認証ファイル246を使わずに、第2認証ファイル245を作成することも可能である。例えば、図14の例を、第1認証ファイル163を第3認証ファイル246と結合せずにAESアルゴリズム249へ入力するように変形してもよい。更に、装置IDを第3認証ファイル246と結合せずに擬似乱数生成手段251へ入力するように、図14の例を変形してもよい。
これに対し、図14の例のように第3認証ファイル246を使って第2認証ファイル245を作成する場合、第3認証ファイル246はパッチファイル161等の取得時点でユニークに定まる内容を有する点にも鑑み、第2認証ファイル245の作成手法を複雑化して解析されにくくすることが可能である。その結果、第2認証ファイル245によるセキュリティが向上する。
また、図14の例とは違えて、暗号化を利用せずに第2認証ファイル245を作成することも可能である。例えば、第1認証ファイル163と第3認証ファイル246とを結合したファイルをそのまま第2認証ファイル245に採用してもよい。また、暗号化手法を利用する場合であっても、図14の例とは異なる暗号鍵を採用することも可能である。
これに対し、図14の例のように暗号化手法を利用することにより、第2認証ファイル245の作成手法を複雑化して解析されにくくすることが可能である。その結果、第2認証ファイル245によるセキュリティが向上する。この際、第3認証ファイル246と装置IDといういずれもユニークな内容を有するファイルから暗号鍵250を作成する点も、セキュリティ向上に貢献する。
また、図3の例とは違えて、パッチLIB162を使わずに、パッチファイル161から第1認証ファイル163を作成することも可能である。例えば、パッチLIB162をサーバ4から供給するのではなく、パッチLIB162をメモリカード3の第2記憶手段82に予め格納しておく場合、サーバ4の運営者側ではパッチLIB162を使わずに第1認証ファイル163が作成される。
これに対し、図3の例のようにパッチファイル161とパッチLIB162とを結合したファイルから第1認証ファイル163を作成することにより、第1認証ファイル163の作成手法を複雑化して解析されにくくすることが可能である。その結果、第1認証ファイル163によるセキュリティが向上する。
また、上記構成によれば、認証プログラム205が、本体プログラム201に先立って、実行される。しかも、認証プログラム205は、本体プログラム201の起動指示が発生する度に、実行される。このため、本体プログラム201が改ざんされたパッチファイル161等を利用するのを、より確実に防ぐことができる。
なお、上記の構成では修正ファイル管理プログラム202を、端末装置2の電源投入時のIPL(Initial Program Loader)によって起動しない。したがって、IPLが解析されたとしても、修正ファイル管理プログラム202の存在が知られることはない。仮に修正ファイル管理プログラム202の存在がクラッカーに知られ、当該プログラム202が起動するようにIPLが改ざんされた場合であっても、修正ファイル管理プログラム202が起動するだけである。つまり、当該プログラム202が起動すれば、上記のように、改ざんされたパッチファイル161等の利用は阻止される。
ここで、認証プログラム205は、暗号化した状態でメモリカード3の第2記憶手段82に格納しておき、実行時に復号化するようにしてもよい。この例によれば、認証プログラム205が解析されにくくなり、セキュリティを向上させることができる。なお、その他のプログラム203,204,206の1つ以上又はファイル管理プログラム202全体を暗号化してもよい。
上記では1つの端末装置2を例示したが、複数の端末装置2がサーバ4を利用してもよい。この場合、例えば各端末装置2が内容の異なる情報加工手法231,232,233(図14及び図16参照)を採用することにより、クラッカーの攻撃がシステム全体に蔓延してしまうのを防ぐことができる。
ところで、上記構成によれば、サーバ4に準備されるパッチファイル161の種類、及び、それらの取得状況が、パッチ適用タイトルDB182(すなわち修正ファイル取得状況情報182)として、第1記憶手段22において(従って、端末装置2において)一元的に管理される。このため、パッチ適用タイトルDB182を参照することにより、取得済みのパッチファイル161等については、再度のダウンロード処理を行わずに済む。これにより、処理効率が上がる。
また、上記構成によれば、パッチ適用タイトルDB182と、当該DB182を管理する修正ファイル取得状況管理プログラム181(図5参照)との両方が第1記憶手段22に格納されている。このため、例えばメモリカード3が接続されていない状態であっても、パッチ適用タイトルDB182を管理することができる。
<第2の実施形態>
図22に、第2の実施形態に係る端末装置2Bのブロック図を例示する。端末装置2Bは、図1に例示した端末装置2にアクセス監視手段301を追加した構成を有している。図22の例では、アクセス監視手段301は、D/L情報記憶手段62の前段に設けられている。このため、D/L情報記憶手段62へのアクセスは、アクセス監視手段301を介して行われる。
特にD/L情報記憶手段62にはアクセス禁止領域が設定されており、アクセス監視手段301は当該禁止領域へのアクセスを監視する。更に、上記の各種プログラムは当該禁止領域にアクセスしないように作成されている。これにより、禁止領域へのアクセスを不正アクセスとして検出することが可能である。
仮にクラッカーが侵入した場合、プログラム等の解析のために、端末装置2B及びメモリカード3の記憶手段にアクセスすると考えられる。しかも、クラッカーは、どのような情報がどこの記憶領域に格納されているかを知らないので、全ての記憶領域にアクセスすると考えられる。すなわち、アクセス禁止領域にもアクセスすると考えられるこのため、アクセス禁止領域へのアクセスを監視することにより、クラッカーによる不正アクセスを検出可能である。
かかるアクセス監視手段301は、例えば、D/L情報記憶手段62内のアクセス禁止領域のアドレスが登録された記憶手段と、D/L情報記憶手段62に対するアクセス要求が記憶手段に登録されたアドレスを含むか否かを照合する処理手段とによって、構成可能である。
禁止領域に対するアクセスの監視という上記手法に代えて又は加えて、次の監視手法を採用してもよい。すなわち、所定のアクセス条件を満足しなければ、D/L情報記憶手段62へアクセスできないようにしてもよい。例えば、所定のアクセス順序規則に従ってアクセス要求(換言すれば、アドレス指定)が行われなければ、D/L情報記憶手段62へのアクセスが許可されないようにする(特許文献2参照)。かかる例によれば、所定のアクセス条件を満足しないアクセス要求を不正アクセスとして検出可能である。
かかる例の場合、アクセス監視手段301は、例えば、所定のアクセス条件が登録された記憶手段と、D/L情報記憶手段62に対するアクセス要求を記憶手段に登録されたアクセス条件と照合する処理手段とによって、構成可能である。
いずれのアクセス監視手法においても、不正アクセス要求が検出された場合、処理手段はその不正アクセス要求を破棄する。あるいは、処理手段が不正アクセス要求に対して任意のダミーデータを返信するように構成してもよい。あるいは、処理手段が不図示の出力手段(ランプ等)を制御して不正アクセス要求があったことをユーザに通知するように構成してもよい。あるいは、処理手段が、意図的なシステム異常(例えば全ての処理を中断させる処理)を起こさせる割り込み処理を、プロセッサ21に対して強制的に要求するようにしてもよい。
このようにアクセス監視手段301によれば、不正アクセスを防止することができ、セキュリティを更に向上させることができる。
なお、上記ではD/L情報記憶手段62に対してアクセス監視手段301を設ける場合を例示したが、この例に限定されるものではない。例えば、第1記憶手段22に含まれる他のいずれかの記憶手段61,63〜65に対して、アクセス監視手段301を設けてもよい。あるいは、記憶手段61〜65のうちの2つ以上のそれぞれに対して、アクセス監視手段301を設けてもよい。あるいは、記憶手段61〜65のうちの2つ以上でアクセス監視手段301を共有してもよい。
また、上記では端末装置2Bの第1記憶手段22に対してアクセス監視手段301を設ける場合を例示したが、この例に代えて又は加えて、メモリカード3にアクセス監視手段301を設けてもよい。例えば、第2記憶手段82と第3記憶手段83とのうちの少なくとも一方に対して、アクセス監視手段301を設けてもよい。あるいは、2つの記憶手段82,83でアクセス監視手段301を共有してもよく、この場合、アクセス監視手段301は、例えばメモリI/F102の後段(換言すれば、記憶手段82,83の前段)に設けられる。あるいは、共有のアクセス監視手段301を、ホストI/F101とメモリI/F102との間に(従って、記憶手段82,83の前段に)に設けてもよい。
<第3の実施形態>
上記では第2記憶手段82と第3記憶手段83が同じメモリカード3内に設けられる構成を例示した。これに対し、これらの記憶手段82,83を別々の外部記憶媒体(メモリカードに限られない)に設けて端末装置2に接続しても構わない。
また、上記では第2記憶手段82及び第3記憶手段83がメモリカード3内に設けられる構成、すなわち記憶手段82,83が端末装置2に対して外部接続される構成を例示した。これに対し、これらの記憶手段82,83の一方又は両方を、端末装置2に内蔵しても構わない。図23に、記憶手段82,83の両方を内蔵した端末装置2Cを例示する。
また、上記では第2記憶手段82が書き換え不能なOTP ROMで構成される場合を例示したが、書き換え可能な記憶手段で構成しても構わない。そのような例によれば、記憶手段記憶手段82,83を、単一の記憶装置(例えばフラッシュメモリ、ハードディスク装置等)内に混在させることも可能である。この場合、単一の記憶装置内の異なる記憶領域によって、記憶手段82,83のそれぞれが構成されることになる。
なお、第3の実施形態の上記各種の例は、第2の実施形態に係る端末装置2B(図22参照)にも適用可能である。
<第4の実施形態>
上記各種形態を、パッチLIB162(すなわち第2ファイル162)を利用しない修正手法、例えば不具合部分をパッチファイル161で上書きしてしまう修正手法に変形することも可能である。そのような例の場合、上記説明においてパッチLIB162に関連する処理が省略される。
また、既に説明したように、上記各種形態を、第3認証ファイル246を利用しない修正手法に変形することも可能である。
また、上記では第1ファイル161がパッチファイルであり、第2ファイル162がパッチLIBである場合を例示したが、これらのファイル161,162は修正以外の用途のファイルであってもよい。また、ファイル161,162は、特定のプログラムに組み込むためのファイルでなくてもよい。例えば、第1ファイルが音楽ファイルであり、第2ファイルがその関連情報のファイルである場合が挙げられる。ファイル161,162が修正以外の用途のファイルである場合も、第2ファイル162の存在は任意である。
本発明は詳細に説明されたが、上記した説明は、すべての局面において、例示であって、本発明がそれに限定されるものではない。例示されていない無数の変形例が、本発明の範囲から外れることなく想定され得るものと解される。