JP6697038B2

JP6697038B2 - 情報処理装置、検証方法および検証プログラム

Info

Publication number: JP6697038B2
Application number: JP2018144329A
Authority: JP
Inventors: 剛永吉; 雄一小松; 亮太佐藤
Original assignee: Nippon Telegraph and Telephone Corp; NTT Inc USA
Current assignee: NTT Inc; NTT Inc USA
Priority date: 2018-07-31
Filing date: 2018-07-31
Publication date: 2020-05-20
Anticipated expiration: 2038-07-31
Also published as: CN112513849A; AU2019313886B2; WO2020027159A1; EP3812939A1; US12026258B2; US20210232689A1; EP3812939B1; EP3812939A4; JP2020021270A; CN112513849B; AU2019313886A1

Description

本発明は、情報処理装置、検証方法および検証プログラムに関する。

従来、アプリケーション（ＡＰ）プログラムが設定ファイルを利用する際に、その設定データの完全性を確認する技術が知られている。ここで完全性とは、対象データが改ざんされていないことである。また、改ざんとは、異なるバージョンに差し替えること（ロールバック攻撃など）を含むものとする。

例えば、設定データの完全性を確保するために、オペレーティングシステム（ＯＳ）によりアクセス制御を行うことが知られている。ＯＳは、ＡＰプログラムやファイルに対してアクセス制御の機構を提供する。設定ファイルに対して、権限を有するユーザまたはプログラムのみが更新できる権限を、ＯＳの機能によって付与することができる。つまり、ＯＳが適正に動作し、権限を付与されたＡＰプログラムが適切に動作し、ユーザが適切に権限を設定する限りにおいて、ＡＰプログラムが設定データを参照する際に、その設定データの完全性を保護されているとみなすことができる。

情報処理装置にＴＰＭ（Trusted Platform Module）などのセキュリティモジュールを用いた起動プログラムの完全性確認技術が知られている。この技術は、ＯＳが起動するまでのプロセスで実行されるファームウェア、カーネル等のプログラムの完全性を確認することができるが、ＯＳ起動前に実行されるプログラムに付与されるものであり、ＯＳ起動後に実行されるＡＰプログラムからは利用できない。すなわち、ＯＳ起動後に実行されるＡＰプログラムだけでは、設定ファイルの完全性確認に、セキュリティモジュールを利用することができない。

例えば、セキュリティモジュールは、ＯＳとは独立したアクセス制御機構を有し、プログラムのバージョン番号を記録し、バージョン番号を参照する機能と、アクセス制御機構で設定された権限のもとバージョン番号を増加（バージョンアップ）する機能を有する。また、セキュリティモジュールは耐タンパ性を有し、バージョン番号に対して上記以外の操作を実行することは物理的にきわめて困難である。

例えば、ＯＳが起動するまで、読取り専用領域のファームウェア（read-only firmware）、アップブレード可能なファームウェア（read-write firmware）、カーネル、ＯＳを構成するプログラムやサービスの順にプログラムを実行するものとする。先に実行したプログラムが次のプログラムのバージョンと、セキュリティチップに記録されたバージョン番号を確認し、バージョンが正しければ次のプログラムを実行する。セキュリティモジュールのアクセス制御機構は、情報処理装置のＯＳ起動前（pre-OS environment）に実行されるプログラムのアクセス権を判定する機構を有しており、そのようにアクセス権を判定された正当なプログラム（ＯＳ起動前のファームウェア）のみがバージョン番号の更新を実行できる。

"File and Folder Permissions"、［online］、［平成30年7月18日検索］、インターネット＜https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2000/bb727008(v=technet.10)＞ "TPM Usage"、［online］、［平成30年7月18日検索］、インターネット＜https://www.chromium.org/developers/design-documents/tpm-usage＞

しかしながら、従来の技術では、ＯＳに依存せずに、アプリケーションプログラムで設定データの完全性を適切に確認することができないという課題があった。例えば、従来のＯＳのアクセス制御に依存する技術では、ＯＳ上で動作するすべてのプログラムとファイルに対して適切に権限が設定されており、特権を付与されたすべてのプログラムやファイルが、改ざんなどにより想定外の動作を行わず、情報処理装置を利用するすべての特権ユーザが、権限を行使するためのパスワードなどが適切に管理しているという条件を満たす場合に限り、ＡＰプログラムが設定データを参照する際に、その設定データの完全性を保護されていると期待できる。

しかし、上記の条件は、管理対象（ユーザ、ファイル、プログラム）が多岐多数であり、完全な状態を維持することは多くのコストがかかり、それを確認することも難しい。言い換えれば現実には完全な状態を維持できていないことも多い。例えば、ユーザの不正操作や操作ミスによって、管理者権限でマルウェアが侵入できるルート（セキュリティホール）がシステム内に発生し、そこにマルウェアが侵入すれば、マルウェアはあらゆる設定ファイルを管理者権限で改ざんできる。ＯＳのアクセス制御のみに依存するＡＰプログラムは、このような設定ファイルの改ざんを検知することは困難である。

また、セキュリティモジュールを用いた起動プログラムの完全性確認技術では、ＯＳ起動前プロセスの完全性確認においてバージョン情報等を更新する際のセキュリティチップのアクセス権（パーミッション）は、ＯＳ起動前に実行されるプログラムに付与されるものであり、ＯＳ起動後の一般的なＡＰプログラムからは利用できない。すなわち、ＯＳが起動後に実行される一般のＡＰプログラムだけでは、設定ファイルなどの完全性確認に、セキュリティチップを利用することができなかった。

上述した課題を解決し、目的を達成するために、本発明の情報処理装置は、耐タンパ性を備えたセキュリティモジュールの記憶部から設定ファイルのデジタル署名を検証するための検証鍵に関する情報および設定ファイルのＩＤ情報を取得し、取得した検証鍵に関する情報およびＩＤ情報を用いて、設定ファイルの設定データの完全性を検証する処理をアプリケーションプログラムによって実行する設定ファイル検証部と、前記セキュリティモジュールの記憶部から登録バージョン情報を取得し、取得した登録バージョン情報を用いて、前記設定ファイルの設定バージョンを検証する処理を前記アプリケーションプログラムによって実行する設定ファイルバージョン検証部と、前記設定ファイルの設定バージョンと前記登録バージョン情報とが所定の条件を満たす場合に、前記登録バージョン情報を前記設定バージョンのバージョンに更新する設定ファイルバージョン更新部とを有することを特徴とする。

また、本発明の検証方法は、情報処理装置によって実行される検証方法であって、耐タンパ性を備えたセキュリティモジュールの記憶部から設定ファイルのデジタル署名を検証するための検証鍵に関する情報および設定ファイルのＩＤ情報を取得し、取得した検証鍵に関する情報およびＩＤ情報を用いて、設定ファイルの設定データの完全性を検証する処理をアプリケーションプログラムによって実行する設定ファイル検証工程と、前記セキュリティモジュールの記憶部から登録バージョン情報を取得し、取得した登録バージョン情報を用いて、前記設定ファイルの設定バージョンを検証する処理を前記アプリケーションプログラムによって実行するバージョン検証工程と、前記設定ファイルの設定バージョンと前記登録バージョン情報とが所定の条件を満たす場合に、前記登録バージョン情報を前記設定バージョンのバージョンに更新する更新工程とを含んだことを特徴とする。

また、本発明の検証プログラムは、耐タンパ性を備えたセキュリティモジュールの記憶部から設定ファイルのデジタル署名を検証するための検証鍵に関する情報および設定ファイルのＩＤ情報を取得し、取得した検証鍵に関する情報およびＩＤ情報を用いて、設定ファイルの設定データの完全性を検証する処理をアプリケーションプログラムによって実行する設定ファイル検証ステップと、前記セキュリティモジュールの記憶部から登録バージョン情報を取得し、取得した登録バージョン情報を用いて、前記設定ファイルの設定バージョンを検証する処理を前記アプリケーションプログラムによって実行するバージョン検証ステップと、前記設定ファイルの設定バージョンと前記登録バージョン情報とが所定の条件を満たす場合に、前記登録バージョン情報を前記設定バージョンのバージョンに更新する更新ステップとをコンピュータに実行させることを特徴とする。

本発明によれば、ＯＳに依存せずに、アプリケーションプログラムで設定データの完全性を適切に確認することができるという効果を奏する。

図１は、第一の実施の形態に係るシステムの構成の一例を示す図である。図２は、設定ファイルに含まれる情報の一例を示す図である。図３は、公開鍵・ＩＤ情報に含まれる情報の一例を示す図である。図４は、第一の実施の形態に係る情報処理装置による設定ファイル利用処理を説明するフローチャートである。図５は、第一の実施の形態に係る情報処理装置による設定ファイル更新処理を説明するフローチャートである。図６は、第一の実施の形態に係る情報処理装置によるＡＰプログラム起動処理を説明するフローチャートである。図７は、第一の実施の形態に係る情報処理装置による設定ファイル記録処理を説明するフローチャートである。図８は、第一の実施の形態に係る情報処理装置による公開鍵・ＩＤ情報更新処理を説明するフローチャートである。図９は、第一の実施の形態に係る情報処理装置における運用サイクルを説明するための図である。図１０は、検証プログラムを実行するコンピュータを示す図である。

以下に、本願に係る情報処理装置、検証方法および検証プログラムの実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態により本願に係る情報処理装置、検証方法および検証プログラムが限定されるものではない。

［第一の実施の形態］
以下の実施の形態では、第一の実施の形態に係るシステムの構成、情報処理装置における処理の流れを順に説明し、最後に第一の実施の形態による効果を説明する。

［システムの構成］
まず、図１を用いて、第一の実施の形態に係るシステムについて説明する。図１は、第一の実施の形態に係るシステムの構成の一例を示す図である。第一の実施の形態に係るシステムは、情報処理装置１０および管理装置２０を有する。なお、図１に示す各装置の数は、あくまで一例であり、これに限られるものではない。例えば、情報処理装置１０および管理装置２０は、一つの装置で構成されていてもよい。

情報処理装置１０は、１つまたは複数のＡＰプログラム１１を搭載している。情報処理装置１０は、耐タンパ性を備えたセキュリティモジュール１２（例えば、ＴＰＭなど）を搭載している。また、情報処理装置１０は、ハードディスク等の装置記憶部１３およびオペレーティングシステム等の装置制御部１４を有する。

管理装置２０は、デジタル署名の権限を有するユーザがＡＰプログラム１１に入力する設定ファイルを、リモートから作成し、情報処理装置１０に送信する。また、管理装置２０は、公開鍵情報へのアクセス権を有するユーザがセキュリティモジュールの公開鍵情報をリモートから更新する。なお、装置構成としては、情報処理装置１０と同一の装置構成であってもよい。

まず、情報処理装置１０の各機能部について説明する。情報処理装置１０のアプリケーションプログラム１１は、設定ファイル入力部１１ａ、設定ファイル検証部１１ｂ、設定ファイルバージョン検証部１１ｃ、設定ファイルバージョン更新部１１ｄおよびＡＰ制御部１１ｅを有する。

設定ファイル入力部１１ａは、装置記憶部１３に記録されている設定ファイルを読込む。なお、本実施形態では、同一機器の記憶部から読込む場合を説明するがＮＷ経由で取得するようにしてもよい。

設定ファイル検証部１１ｂは、セキュリティモジュール記憶部１２ｄから設定ファイルのデジタル署名を検証するための公開鍵および設定ファイルのＩＤ情報を取得し、取得した公開鍵およびＩＤ情報を用いて、設定ファイルの設定データの完全性を検証する処理を実行する。

設定ファイルバージョン検証部１１ｃは、セキュリティモジュール記憶部１２ｄから登録バージョン情報を取得し、取得した登録バージョン情報を用いて、設定ファイルの設定バージョンを検証する処理を実行する。

設定ファイルバージョン更新部１１ｄは、設定ファイルの設定バージョンと登録バージョン情報とが所定の条件を満たす場合に、登録バージョン情報を設定バージョンのバージョンに更新する処理を実行する。例えば、所定の条件として、設定ファイルの設定バージョンが登録バージョン情報より一つ先のバージョンである場合に、登録バージョンを一つ先のバージョンに更新（インクリメント）すると設定されているものとして、以下説明する。なお、この所定の条件は、情報処理装置１０ごと、もしくはＡＰプログラム１１ごとに設定できるものとする。このように、情報処理装置１０ごと、もしくはＡＰプログラム１１ごとに、許容するアップデータの結果を指定することができ、オペレータが情報処理装置１０ごと、あるいはＡＰプログラム１１ごとのバージョン情報及び設定ファイルを作成して、ユニークなアップデートを実施することができる。また、所定の条件は、変更可能な情報である。例えば、所定の条件として、設定ファイルの設定バージョンが登録バージョン情報より２つ先のバージョンの場合、適正なアップデートの結果として許容し、登録バージョンを設定バージョンのバージョンに更新するというように設定変更してもよい。

ＡＰ制御部１１ｅは、ＡＰプログラム１１の上記各部を制御する。ＡＰ制御部１１ｅは、設定データの完全性がＯＫであり、設定バージョンが登録バージョンに等しいときに限り、設定ファイルの利用を許可する。また、ＡＰ制御部１１ｅは、装置制御部１４を経由して、セキュリティモジュール１２へのアクセスを行う。

セキュリティモジュール１２は、アクセス制御部１２ａ、公開鍵・ＩＤ情報管理部１２ｂ、登録バージョン管理部１２ｃ、セキュリティモジュール記憶部１２ｄおよびセキュリティモジュール制御部１２ｅを有する。

アクセス制御部１２ａは、セキュリティモジュール記憶部１２ｄのデータに対するアクセスを制御する。具体的には、アクセス制御部１２ａは、セキュリティモジュール記憶部１２ｄに記憶された公開鍵およびＩＤ情報に対する更新要求を受け付け、ユーザによって入力された認証用パスワードを検証し、検証結果に応じて更新を許可するか判定する。

例えば、アクセス制御部１２ａは、公開鍵およびＩＤ情報の更新操作に対してはＨＭＡＣ（Hash-based Message Authentication Code）等の認証によるアクセス制限を行う。つまり、アクセス制御部１２ａは、公開鍵・ＩＤ情報の更新をリモートから実施するにあたり、メッセージの改ざんチェックとＨＭＡＣ認証を行う。ここで、メッセージとは、公開鍵・ＩＤ情報の更新コマンド（コマンド引数に、更新対象の新しい公開鍵・ＩＤ情報を含む）である。なお、認証方法は、ＨＭＡＣ認証に限定されるものではない。また、アクセス制御部１２ａは、公開鍵およびＩＤ情報の参照、登録バージョン情報の参照、登録バージョン情報のインクリメントについては、アクセスを制限しない。

公開鍵・ＩＤ情報管理部１２ｂは、公開鍵およびＩＤ情報の参照、更新を行う。具体的には、公開鍵・ＩＤ情報管理部１２ｂは、アクセス制御部１２ａによって更新を許可すると判定された場合には、セキュリティモジュール記憶部１２ｄに記憶された公開鍵およびＩＤ情報を更新する。

登録バージョン管理部１２ｃは、登録バージョン情報の参照、更新（インクリメント）を行う。セキュリティモジュール記憶部１２ｄは、公開鍵およびＩＤ情報、登録バージョン情報を記憶する。また、セキュリティモジュール記憶部１２ｄは、公開鍵およびＩＤ情報を更新するための認証パスワードを記憶する。セキュリティモジュール制御部１２ｅは、セキュリティモジュール１２の上記各部を制御する。

装置記憶部１３は、設定ファイルを記憶する。設定ファイルには、ＯＳのアクセス権を設定することができる。装置制御部１４は、上記各部を制御し、管理装置２０との通信を行う。また、装置制御部１４は、各アプリケーションに対して、管理装置２０においてそれぞれ別個に作成された設定ファイルを装置記憶部１３に記録する。

このように、情報処理装置１０では、ＯＳとは独立なアクセス制御機能およびデータ保護機能を有するセキュリティモジュール１２を利用するので、ＯＳに対する権限設定に依存せず、設定ファイルの完全性を確認できる。

管理装置２０は、設定ファイル作成部２１、設定ファイル送信部２２、公開鍵・ＩＤ情報登録部２３および制御部２４を有する。

設定ファイル作成部２１は、１つ以上の情報処理装置１０の、１つ以上のＡＰプログラム１１に対して、それぞれ別個の設定ファイルを作成する機能とユーザインタフェースを備える。また、設定ファイル作成部２１は、デジタル署名を生成するための秘密鍵の管理やユーザ認証を行う機能も含む。また、設定ファイル作成部２１は、例えば、別個かつ複数の設定ファイルに対して、まとめて１回のデジタル署名を付与することもできる。

設定ファイル送信部２２は、設定ファイルを１つ以上の情報処理装置１０に送信する。公開鍵・ＩＤ情報登録部２３は、セキュリティモジュール１２の公開鍵・ＩＤ情報を情報処理装置１０の装置制御部１４経由で更新する。また、公開鍵・ＩＤ情報登録部２３は、ＨＭＡＣ認証のためのＨＭＡＣ作成機能も含む。制御部２４は、上記各部を制御し、情報処理装置１０との通信を行う。

［データの説明］
ここで、上記した設定ファイル、公開鍵・ＩＤ情報および登録バージョン情報についてそれぞれ説明する。まず、設定ファイルについて説明する。設定ファイルは、図２に例示するように、設定データ、設定ファイルＩＤ、設定バージョンおよびデジタル署名を構成要素として含むファイルである。

設定データは、ＡＰプログラムが読込むデータ（コンテンツ）である。設定ファイルＩＤと、設定バージョンで、設定データは一意に識別できる。設定ファイルＩＤは、情報処理装置１０およびＡＰプログラム１１に固有の、設定ファイルの種別である。なお、同一の設定ファイルＩＤの、複数バージョンの設定ファイルが存在しうる。

設定バージョンは、同一の設定ファイルＩＤを持つ設定ファイルのバージョンを識別する情報である。バージョン情報の形式は、登録バージョン情報の形式と一致する。デジタル署名は、設定データ、設定ファイルＩＤ、設定バージョンを含む情報に対する、公開鍵暗号方式（ＲＳＡアルゴリズムなど）によるデジタル署名である。

次に、公開鍵およびＩＤ情報（公開鍵・ＩＤ情報）について説明する。公開鍵・ＩＤ情報は、図３に例示するように、設定ファイルのデジタル署名を検証するために必要なデータであり、登録公開鍵情報と登録ＩＤ情報で構成される。このデータは秘匿する必要は無いが、セキュリティモジュール１２によって完全性は保護する必要がある。

例えば、登録公開鍵情報は、設定ファイルのデジタル署名の検証鍵（公開鍵）であり、登録ＩＤ情報は、設定ファイルの設定データＩＤである。この場合には、検証方法は、公開鍵情報で直接デジタル署名を検証し、設定データＩＤを照合すればよい。また、これに限定されるものではなく、例えば、登録公開鍵情報は、設定ファイルのデジタル署名の検証鍵（公開鍵）の証明書を検証するためのルート証明書であってもよく、登録ＩＤ情報は、設定ファイルのデータＩＤ、及び設定ファイルのデジタル署名の検証鍵（公開鍵）の証明書の識別ＩＤであってもよい。

この場合には、検証方法としては、設定ファイルのデジタル署名の検証鍵（公開鍵）の証明書を、情報処理装置１０の装置記憶部１３などに保管しておく。そして、まず、設定ファイルのデジタル署名を上記の証明書を用いて検証し、次に上記の証明書をセキュリティモジュールから取得したルート証明書で検証し、さらに設定データＩＤを照合する。

次に、登録バージョン情報について説明する。登録バージョン情報は、秘匿する必要は無いが、セキュリティモジュールによって完全性を保護する必要がある。また、登録バージョン情報は、一方向演算の算出結果を用いる。主な例としてはＴＰＭ２．０で規定されている以下の２種類を説明するが、これに限定されるものではない。

例えば、登録バージョン情報は、カウンタ値（整数値）、カウンタ値のメモリｉｎｄｅｘを含み、インクリメント方法は、新カウンタ値＝旧カウンタ値＋１とする。また、登録バージョン情報は、ｈａｓｈ値（ｓｈａ２５６など）、ｈａｓｈ値のメモリｉｎｄｅｘを含み、インクリメント方法は、新ｈａｓｈ値＝ｈａｓｈ（旧ｈａｓｈ値｜ｈａｓｈ（設定ファイル））としてもよい。この場合には、登録バージョン情報初期値は、旧ｈａｓｈ値として乱数値を設定し、新ｈａｓｈ値を登録する。なお、乱数値は秘密情報であり、その後利用しないため、ただちにメモリ等から消去する。

［情報処理装置の処理の流れ］
次に、図４〜図８を用いて、第一の実施の形態に係る情報処理装置１０の処理の流れを説明する。図４は、第一の実施の形態に係る情報処理装置による設定ファイル利用処理を説明するフローチャートである。図５は、第一の実施の形態に係る情報処理装置による設定ファイル更新処理を説明するフローチャートである。図６は、第一の実施の形態に係る情報処理装置によるＡＰプログラム起動処理を説明するフローチャートである。図７は、第一の実施の形態に係る情報処理装置による設定ファイル記録処理を説明するフローチャートである。図８は、第一の実施の形態に係る情報処理装置による公開鍵・ＩＤ情報更新処理を説明するフローチャートである。

まず、図４を用いて、情報処理装置１０による設定ファイル利用時の処理を説明する。図４に示すように、まず、情報処理装置１０のＡＰプログラム１１の設定ファイル入力部１１ａが、装置記憶部１３から設定ファイルを読み込む（ステップＳ１０１）。そして、ＡＰプログラム１１の設定ファイル検証部１１ｂが、セキュリティモジュール記憶部１２ｄから公開鍵・ＩＤ情報を取得する（ステップＳ１０２）。

続いて、ＡＰプログラム１１の設定ファイル検証部１１ｂが、登録公開鍵情報と登録ＩＤ情報を用いて、設定ファイルのデジタル署名と設定データＩＤを検証する（ステップＳ１０３）。そして、設定ファイル検証部１１ｂが、検証を行った結果、検証結果がＮＧである場合には（ステップＳ１０４否定）、そのまま処理を終了する。また、設定ファイル検証部１１ｂが、検証を行った結果、検証結果がＯＫである場合には（ステップＳ１０４肯定）、ＡＰプログラム１１の設定ファイルバージョン検証部１１ｃは、セキュリティモジュール記憶部１２ｄから登録バージョン情報を取得する（ステップＳ１０５）。

続いて、ＡＰプログラム１１の設定ファイルバージョン検証部１１ｃが、登録バージョン情報を用いて、設定ファイルの設定バージョンを検証する（ステップＳ１０６）。そして、ＡＰプログラム１１の設定ファイルバージョン検証部１１ｃが、検証を行った結果、設定バージョンと登録バージョンが一致しなかった場合には（ステップＳ１０７否定）、そのまま処理を終了する。

また、ＡＰプログラム１１の設定ファイルバージョン検証部１１ｃが、検証を行った結果、設定バージョンと登録バージョンが一致した場合には（ステップＳ１０７肯定）、ＡＰプログラム１１のＡＰ制御部１１ｅは、読込んだ設定ファイルは完全性を備えていると判定し、読込んだ設定ファイルの利用を許可する（ステップＳ１０８）。

次に、図５を用いて、情報処理装置１０による設定ファイル更新時の処理を説明する。図５に示すように、まず、情報処理装置１０のＡＰプログラム１１の設定ファイル入力部１１ａが、装置記憶部１３から設定ファイルを読み込む（ステップＳ２０１）。そして、ＡＰプログラム１１の設定ファイル検証部１１ｂが、セキュリティモジュール記憶部１２ｄから公開鍵・ＩＤ情報を取得する（ステップＳ２０２）。

続いて、ＡＰプログラム１１の設定ファイル検証部１１ｂが、登録公開鍵情報と登録ＩＤ情報を用いて、設定ファイルのデジタル署名と設定データＩＤを検証する（ステップＳ２０３）。そして、設定ファイル検証部１１ｂが、検証を行った結果、検証結果がＮＧである場合には（ステップＳ２０４否定）、そのまま処理を終了する。また、設定ファイル検証部１１ｂが、検証を行った結果、検証結果がＯＫである場合には（ステップＳ２０４肯定）、ＡＰプログラム１１の設定ファイルバージョン検証部１１ｃは、セキュリティモジュール記憶部１２ｄから登録バージョン情報を取得する（ステップＳ２０５）。

続いて、ＡＰプログラム１１の設定ファイルバージョン検証部１１ｃが、登録バージョン情報を用いて、設定ファイルの設定バージョンを検証する（ステップＳ２０６）。そして、ＡＰプログラム１１の設定ファイルバージョン検証部１１ｃが、検証を行った結果、設定バージョンと登録バージョン＋１が一致しなかった場合（ステップＳ２０７否定）、つまり、設定バージョンが登録バージョンよりも一つ先のバージョンでない場合には、そのまま処理を終了する。

また、ＡＰプログラム１１の設定ファイルバージョン検証部１１ｃが、検証を行った結果、設定バージョンと登録バージョン＋１が一致した場合（ステップＳ２０７肯定）、ＡＰプログラム１１の設定ファイルバージョン更新部１１ｄは、セキュリティモジュールの登録バージョン管理部に指示して登録バージョン情報をインクリメントする（ステップＳ２０８）。

次に、図６を用いて、情報処理装置１０によるＡＰプログラム１１起動時の処理を説明する。図６の例では、ＡＰプログラム１１の起動時に、「設定ファイル利用」処理と「設定ファイル更新」処理を一つの処理手順として実現する場合を説明する。図６に示すように、まず、情報処理装置１０のＡＰプログラム１１の設定ファイル入力部１１ａが、装置記憶部１３から設定ファイルを読み込む（ステップＳ３０１）。そして、ＡＰプログラム１１の設定ファイル検証部１１ｂが、セキュリティモジュール記憶部１２ｄから公開鍵・ＩＤ情報を取得する（ステップＳ３０２）。

続いて、ＡＰプログラム１１の設定ファイル検証部１１ｂが、登録公開鍵情報と登録ＩＤ情報を用いて、設定ファイルのデジタル署名と設定データＩＤを検証する（ステップＳ３０３）。そして、設定ファイル検証部１１ｂが、検証を行った結果、検証結果がＮＧである場合には（ステップＳ３０４否定）、そのまま処理を終了する。また、設定ファイル検証部１１ｂが、検証を行った結果、検証結果がＯＫである場合には（ステップＳ３０４肯定）、ＡＰプログラム１１の設定ファイルバージョン検証部１１ｃは、セキュリティモジュール記憶部１２ｄから登録バージョン情報を取得する（ステップＳ３０５）。

続いて、ＡＰプログラム１１の設定ファイルバージョン検証部１１ｃが、登録バージョン情報を用いて、設定ファイルの設定バージョンを検証する（ステップＳ３０６）。そして、ＡＰプログラム１１の設定ファイルバージョン検証部１１ｃが、検証を行った結果、設定バージョンと登録バージョンが一致した場合には（ステップＳ３０７肯定）、ＡＰプログラム１１のＡＰ制御部１１ｅは、読込んだ設定ファイルは完全性を備えていると判定し、読込んだ設定ファイルの利用を許可する（ステップＳ３０８）。

また、ＡＰプログラム１１の設定ファイルバージョン検証部１１ｃが、検証を行った結果、設定バージョンと登録バージョンが一致しなかった場合（ステップＳ３０７否定）、かつ、設定バージョンと登録バージョン＋１が一致した場合（ステップＳ３０９肯定）、ＡＰプログラム１１の設定ファイルバージョン更新部１１ｄは、セキュリティモジュールの登録バージョン管理部に指示して登録バージョン情報をインクリメントする（ステップＳ３１０）。

また、ＡＰプログラム１１の設定ファイルバージョン検証部１１ｃが、検証を行った結果、設定バージョンと登録バージョンが一致しなかった場合（ステップＳ３０７否定）、かつ、ＡＰプログラム１１の設定ファイルバージョン検証部１１ｃが、検証を行った結果、設定バージョンと登録バージョン＋１が一致しなかった場合（ステップＳ３０９否定）、そのまま処理を終了する。

次に、図７を用いて、情報処理装置１０および管理装置２０による設定ファイルの作成・記録処理を説明する。図７に示すように、まず、管理装置２０の設定ファイル作成部２１は、１つ以上の情報処理装置１０の、１つ以上のＡＰプログラム１１に対して、それぞれ別個の設定ファイルを作成する（ステップＳ４０１）。なお、この際、設定ファイル作成部２１は、デジタル署名作成にあたりユーザ認証を実施する。

続いて、設定ファイル送信部２２が、１つ以上の情報処理装置１０に対して、設定ファイルを送信する（ステップＳ４０２）。そして、装置制御部１４は、設定ファイルを装置記憶部１３に記録する（ステップＳ４０３）。

次に、図８を用いて、情報処理装置１０および管理装置２０による公開鍵・ＩＤ情報の更新時の処理を説明する。図８に示すように、まず、公開鍵・ＩＤ情報登録部２３が、公開鍵・ＩＤ情報を更新するコマンドを、装置制御部１４経由でセキュリティモジュール１２に送信する（ステップＳ５０１）。このコマンドには、認証用のＨＭＡＣを含み、ＨＭＡＣ作成のためユーザは認証パスワードを入力しているものとする。

そして、セキュリティモジュール１２のアクセス制御部１２ａは、セキュリティモジュール記憶部１２ｄに保管している公開鍵・ＩＤ情報の認証パスワードを用いてＨＭＡＣを検証する（ステップＳ５０２）。セキュリティモジュール１２のアクセス制御部１２ａが、検証を行った結果、検証結果がＮＧである場合には（ステップＳ５０３否定）、そのまま処理を終了する。

セキュリティモジュール１２のアクセス制御部１２ａが、検証を行った結果、検証結果がＯＫである場合には（ステップＳ５０３肯定）、セキュリティモジュールの公開鍵・ＩＤ情報管理部１２ｂは、セキュリティモジュール記憶部１２ｄに保管している公開鍵・ＩＤ情報を更新する（ステップＳ５０４）。

上述したように、例えば、ユーザが、バージョン情報が付与されたに設定ファイルに対して、デジタル署名を付与し、ＡＰプログラム１１はセキュリティモジュール１２に保管した公開鍵・ＩＤ情報によって、署名を検証する。そして、ＡＰプログラム１１は、上記の検証結果に基づきバージョン情報及び設定ファイルの完全性を確認する。さらに、セキュリティモジュール１２で保管する認証パスワードによってユーザを認証することによって、上記の公開鍵・ＩＤ情報の登録更新を行う。

［運用サイクル］
ここで、図９を用いて、第一の実施の形態に係る情報処理装置１０における運用サイクルについて説明する。図９は、第一の実施の形態に係る情報処理装置における運用サイクルを説明するための図である。図９に示すように、情報処理装置１０における運用は、包含関係にある運用サイクル１〜３の３つのサイクルで構成される。運用サイクル１では、ＡＰプログラム１１の起動、停止サイクルであり、最も頻度が高い。起動時にＡＰプログラム１１は自動的に設定ファイルの完全性とバージョンをチェックする。また、ユーザ操作（認証操作など）を伴わず、自動的に実行できる。

また、運用サイクル２は、ＡＰプログラム１１の設定ファイル変更サイクルであり、運用サイクル１より頻度が低い。設定ファイルの作成にはデジタル署名を付与するためユーザ認証操作を伴う。１つ以上の情報処理装置１０の、１つ以上のＡＰプログラム１１に対して、非同期に、また１回の操作で実施することが可能である。非同期とは、ユーザにとっての設定ファイル作成タイミングと、ＡＰプログラム１１にとっての設定ファイル更新タイミング（セキュリティチップの登録バージョン情報のインクリメント）が、非同期であることを意味する。

また、運用サイクル３は、公開鍵・ＩＤ情報の変更であり、運用サイクル２より頻度が低い（例えば、数年周期）。ここでは、セキュリティモジュール・ＩＤ情報更新のためのユーザ認証操作を伴う。安全に実施するためには同期処理が望ましい。

以上のように、頻度の高い運用はユーザ操作が少なく、ユーザ操作が多い運用は頻度が低いものにできる。このため、トータルのオペレーションコストを十分下げることができ、多数の装置、および多数のＡＰプログラムを対象とする場合でも、効率的な運用が可能である。

また、上記の構成にすることにより、運用サイクルのように、頻度の高い運用はユーザ操作が少なく、ユーザ操作が多い運用は頻度が低いものにできる。上記により、バージョン情報のアップデートはＯＳ起動前に実行されるプログラムに限定されることなく、一般的なＡＰプログラム１１だけで設定ファイルなどの完全性確認を低コストで実施できる。

［第一の実施の形態の効果］
このように、第一の実施の形態に係る情報処理装置１０は、耐タンパ性を備えたセキュリティモジュール記憶部１２ｄから設定ファイルのデジタル署名を検証するための公開鍵および設定ファイルのＩＤ情報を取得し、取得した公開鍵およびＩＤ情報を用いて、設定ファイルの設定データの完全性を検証する処理をアプリケーションプログラム１１によって実行する。そして、情報処理装置１０は、セキュリティモジュール記憶部１２ｄから登録バージョン情報を取得し、取得した登録バージョン情報を用いて、設定ファイルの設定バージョンを検証する処理をアプリケーションプログラム１１によって実行する。また、情報処理装置１０は、設定ファイルの設定バージョンと登録バージョン情報とが所定の条件を満たす場合に、登録バージョン情報を設定バージョンのバージョンに更新する。

また、第一の実施の形態に係る情報処理装置１０では、設定ファイルの完全性・バージョンの判定にあたり、ＯＳのアクセス制御だけに依存せず、ＯＳ機能とは独立な、セキュリティモジュール１２のアクセス制御と耐タンパ性を判定の根拠としており、ＯＳに依存せずに、アプリケーションプログラムで設定データの完全性を適切に確認することが可能である。

また、例えば、ユーザの不正操作や操作ミスによって、管理者権限でマルウェアが侵入できるルート（セキュリティホール）がシステム内に発生し、そこにマルウェアが進入すれば、マルウェアはあらゆる設定ファイルを管理者権限で改ざんできる。このような場合でも、情報処理装置１０のＡＰプログラ１１ムは、設定ファイルの改ざんを検知することができる。つまり、マルウェアにとって、セキュリティモジュール記憶部１２ｄのデータや、セキュリティモジュール１２の機能を改ざんすることは、ＯＳ上のファイルや機能を改ざんするより遥かに困難なためである。

また、本願の検証方法は、セキュリティモジュール１２を搭載した情報処理装置１０のＯＳ上で実行される、あらゆるＡＰプログラム１１で利用できる。また、情報処理装置１０は、例えば、ユーザが指定した唯一の設定ファイルバージョンへのバージョンアップを確認できる。これは設定ファイルに記載した「設定ファイルＩＤ」と、「設定バージョン」で、設定データは一意に識別し、「設定ファイルＩＤ」は情報処理装置１０およびＡＰプログラム１１に固有の、設定ファイルの種別としているからである。

［システム構成等］
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行われる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、本実施の形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

［プログラム］
図１０は、検証プログラムを実行するコンピュータを示す図である。コンピュータ１０００は、例えば、メモリ１０１０、ＣＰＵ１０２０を有する。また、コンピュータ１０００は、ハードディスクドライブインタフェース１０３０、ディスクドライブインタフェース１０４０、シリアルポートインタフェース１０５０、ビデオアダプタ１０６０、ネットワークインタフェース１０７０を有する。これらの各部は、バス１０８０によって接続される。

メモリ１０１０は、ＲＯＭ（Read Only Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１１００に挿入される。シリアルポートインタフェース１０５０は、例えばマウス１０５１、キーボード１０５２に接続される。ビデオアダプタ１０６０は、例えばディスプレイ１０６１に接続される。

ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、情報処理装置１０の各処理を規定するプログラムは、コンピュータにより実行可能なコードが記述されたプログラムモジュール１０９３として実装される。プログラムモジュール１０９３は、例えばハードディスクドライブ１０９０に記憶される。例えば、装置における機能構成と同様の処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０９０に記憶される。なお、ハードディスクドライブ１０９０は、ＳＳＤ（Solid State Drive）により代替されてもよい。

また、上述した実施の形態の処理で用いられるデータは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して実行する。

なお、プログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムモジュール１０９３及びプログラムデータ１０９４は、ネットワーク、ＷＡＮを介して接続された他のコンピュータに記憶されてもよい。そして、プログラムモジュール１０９３及びプログラムデータ１０９４は、他のコンピュータから、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

１０情報処理装置
１１ＡＰプログラム
１１ａ設定ファイル入力部
１１ｂ設定ファイル検証部
１１ｃ設定ファイルバージョン検証部
１１ｄ設定ファイルバージョン更新部
１１ｅＡＰ制御部
１２セキュリティモジュール
１２ａアクセス制御部
１２ｂ公開鍵・ＩＤ情報管理部
１２ｃ登録バージョン管理部
１２ｄセキュリティモジュール記憶部
１２ｅセキュリティモジュール制御部
１３装置記憶部
１４装置制御部
２０管理装置
２１設定ファイル作成部
２２設定ファイル送信部
２３公開鍵・ＩＤ情報登録部
２４制御部

Claims

耐タンパ性を備えたセキュリティモジュールの記憶部から設定ファイルのデジタル署名を検証するための検証鍵に関する情報および設定ファイルのＩＤ情報を取得し、取得した検証鍵に関する情報およびＩＤ情報を用いて、設定ファイルの設定データの完全性を検証する処理をアプリケーションプログラムによって実行する設定ファイル検証部と、
前記セキュリティモジュールの記憶部から登録バージョン情報を取得し、取得した登録バージョン情報を用いて、前記設定ファイルの設定バージョンを検証する処理を前記アプリケーションプログラムによって実行する設定ファイルバージョン検証部と、
前記設定ファイルの設定バージョンと前記登録バージョン情報とが所定の条件を満たす場合に、前記登録バージョン情報を前記設定バージョンのバージョンに更新する設定ファイルバージョン更新部と
を有することを特徴とする情報処理装置。
各アプリケーションに対して、それぞれ別個に作成された設定ファイルを記憶部に記録する装置制御部をさらに有することを特徴とする請求項１に記載の情報処理装置。
前記セキュリティモジュールの記憶部に記憶された検証鍵に関する情報およびＩＤ情報に対する更新要求を受け付け、ユーザによって入力された認証用パスワードを検証し、検証結果に応じて更新を許可するか判定するアクセス制御部と、
前記アクセス制御部によって更新を許可すると判定された場合には、前記セキュリティモジュールの記憶部に記憶された検証鍵に関する情報およびＩＤ情報の更新する管理部とをさらに有することを特徴とする請求項１に記載の情報処理装置。
前記所定の条件は、設定変更可能であることを特徴とする請求項１に記載の情報処理装置。
情報処理装置によって実行される検証方法であって、
耐タンパ性を備えたセキュリティモジュールの記憶部から設定ファイルのデジタル署名を検証するための検証鍵に関する情報および設定ファイルのＩＤ情報を取得し、取得した検証鍵に関する情報およびＩＤ情報を用いて、設定ファイルの設定データの完全性を検証する処理をアプリケーションプログラムによって実行する設定ファイル検証工程と、
前記セキュリティモジュールの記憶部から登録バージョン情報を取得し、取得した登録バージョン情報を用いて、前記設定ファイルの設定バージョンを検証する処理を前記アプリケーションプログラムによって実行するバージョン検証工程と、
前記設定ファイルの設定バージョンと前記登録バージョン情報とが所定の条件を満たす場合に、前記登録バージョン情報を前記設定バージョンのバージョンに更新する更新工程と
を含んだことを特徴とする検証方法。
耐タンパ性を備えたセキュリティモジュールの記憶部から設定ファイルのデジタル署名を検証するための検証鍵に関する情報および設定ファイルのＩＤ情報を取得し、取得した検証鍵に関する情報およびＩＤ情報を用いて、設定ファイルの設定データの完全性を検証する処理をアプリケーションプログラムによって実行する設定ファイル検証ステップと、
前記セキュリティモジュールの記憶部から登録バージョン情報を取得し、取得した登録バージョン情報を用いて、前記設定ファイルの設定バージョンを検証する処理を前記アプリケーションプログラムによって実行するバージョン検証ステップと、
前記設定ファイルの設定バージョンと前記登録バージョン情報とが所定の条件を満たす場合に、前記登録バージョン情報を前記設定バージョンのバージョンに更新する更新ステップと
をコンピュータに実行させることを特徴とする検証プログラム。