JP5182445B1

JP5182445B1 - アプリケーションプログラムの改竄検知方法

Info

Publication number: JP5182445B1
Application number: JP2012204321A
Authority: JP
Inventors: 義博矢野; 亮彦吉田
Original assignee: Dai Nippon Printing Co Ltd
Current assignee: Dai Nippon Printing Co Ltd
Priority date: 2012-09-18
Filing date: 2012-09-18
Publication date: 2013-04-17
Anticipated expiration: 2032-09-18
Also published as: JP2014059724A

Abstract

【課題】電子署名付加ファイルに対する改竄が行われた場合にも、有効な改竄検知を行う。
【解決手段】アプリケーションプログラム１０は、パッケージ２１としてパッケージ化される。このパッケージ２１を署名対象データＤとして、プログラム提供者Ａの第１の鍵Ｋ（ａ１）を用いた電子署名処理が行われ、署名情報２２が作成される。更に、この署名情報２２を秘匿化対象データＣとして、第２の特定鍵Ｋ（ｓ２）を用いた秘匿化処理が行われ、秘匿情報２３が作成される。パッケージ２１，署名情報２２，秘匿情報２３を含む配布用ファイル２０Ａ（ＡＰＫファイル）の配布を受けた電子機器では、ＯＳによる署名情報２２の正当性確認処理と、第１の特定鍵Ｋ（ｓ１）を用いた改竄チェック機能を有する改竄チェックプログラム３０による秘匿情報２３の正当性確認処理と、の双方により改竄チェックが行われる。
【選択図】図５

Description

本発明は、アプリケーションプログラムの改竄検知方法に関し、特に、配布を受けたアプリケーションプログラムを実行するコンピュータにおいて、配布中や配布後に行われたアプリケーションプログラムの改竄を検知する技術に関する。

ここ数年来、電子機器は、パソコン、スマートフォン、電子タブレット等と様々な形態のものが普及してきており、これら様々な電子機器において多様なアプリケーションプログラムが利用されている。このため、実社会で利用されているアプリケーションプログラムの数は膨大な数にのぼり、今後も急激な勢いでその数を増してゆくものと予想される。一方、アプリケーションプログラムの配布形態も、光学的記録媒体やＩＣメモリに格納して提供する形態や、インターネットなどを介してオンラインでデータファイルのみを送信する形態が普及しており、一般ユーザは、様々なルートで入手した様々なアプリケーションプログラムを電子機器にインストールして利用することができる。

このように、膨大な数のアプリケーションプログラムが様々な配布形態で提供されている現状では、配布途中のアプリケーションプログラムは、悪意をもったクラッカーによる改竄の標的になりやすい。たとえば、クラッカーは、インターネット経由で任意のアプリケーションプログラムを入手することが可能であり、入手したアプリケーションプログラムに対して改竄を施した後、これを再びインターネット経由あるいは様々な記録媒体に格納して再配布することができる。

一般ユーザにとって、実社会に配布されているアプリケーションプログラムが、正規のコンテンツプロバイダから提供された純正のものであるのか、クラッカーによる改竄が施されたものであるのかを見分けることは困難である。特に、改竄されたアプリケーションプログラムが、正規のアプリケーションプログラムと同じファイル名をもつファイルとして配布されていると、一般ユーザが両者を区別することは非常に困難であり、両者を混同せざるを得ない。

改竄されたアプリケーションプログラムを実行することによって受ける被害は、改竄の内容によって様々である。たとえば、ウイルスを混入させる改竄が行われた場合には、ユーザの電子機器内のファイルが破壊されたり、個人情報が外部へ漏洩されたり、重大な被害が生じることになる。一方、画像データや文字データを差し替えるような改竄が行われた場合、ウイルスほどの被害は生じないにしても、提示される情報が本来のものではなくなってしまうため、ユーザに混乱を生じさせることになる。

しかも、このような改竄されたアプリケーションプログラムの流布による被害は、一般ユーザだけではなく、コンテンツプロバイダにまで及ぶことになる。たとえば、コンテンツプロバイダであるＡ社が配布した正規のアプリケーションプログラムが、クラッカーによる改竄を受け、改竄されたアプリケーションプログラムが、あたかもＡ社の正規の製品であるかのようにして再配布された場合を考えてみよう。この場合、改竄されたアプリケーションプログラムをインストールしたユーザが、当該プログラムをＡ社から提供された正規の製品であると信じて実行したとすれば、Ａ社は不当な評価を受けることになる。たとえば、改竄によってプログラムの動作に不具合が生じたり、公序良俗に反するような内容が表示されたりすれば、Ａ社の製品に対するユーザの評価は低下することになり、Ａ社は風評被害を受けることになる。

このように、コンテンツプロバイダがアプリケーションプログラムを配布し、一般ユーザの電子機器にインストールして実行してもらう上では、クラッカーによる改竄を防止することが不可欠である。通常、デジタルデータの改竄を防止するためには、電子署名の技術が利用されている。たとえば、下記の特許文献１には、携帯電話のメモリ内のデータに電子署名を施し、これをチェックすることにより改竄の有無を検出するシステムが開示されている。また、特許文献２には、情報処理装置内のアプリケーションプログラムの改竄の有無を、電子署名やハッシュ値を利用して監視するシステムが開示されている。

一方、下記の特許文献３および特許文献４には、予め実行対象となるアプリケーションプログラムを登録しておき、未登録のプログラムについては実行を許可しない処理を行う技術が開示されている。この技術を利用すれば、改竄のおそれがない安全なアプリケーションプログラムと判断できるもののみを予め登録しておくようにし、改竄のおそれがあるアプリケーションプログラムの実行を抑制することができるようになる。

特開２００７−２９３８４７号公報国際公開第ＷＯ２００８−０４７８３０号公報特開２００２−３０４３１８号公報特開２００５−１５７４２９号公報

上述したとおり、デジタルデータの改竄を防止するために、当該デジタルデータに対して電子署名を施すことは様々な産業分野で利用されており、前掲の特許文献１，２にも記載されているように、電子機器に配布するアプリケーションプログラムに対する改竄防止にも利用されている。たとえば、Android（登録商標）をＯＳとして採用するスマートフォンの場合、インストールするアプリケーションプログラムには、必ず電子署名が付加されていることが仕様によって定められており、電子署名が付加されていないアプリケーションプログラムや、付加されている電子署名に不整合が生じているアプリケーションプログラムは、ＯＳによって不正なプログラムと判断され、実行が許可されない。

しかしながら、Android（登録商標）における電子署名は、あくまでも署名対象データの内容を署名者が保証するものであり、署名者の身元まで保証するものではない。このため、クラッカーは、アプリケーションプログラムの内容を改竄した後、改竄後のアプリケーションプログラムを署名対象データとして自分自身を署名者とする電子署名を新たに行い、この新たな電子署名を付加して改竄後のアプリケーションプログラムを再配布することが可能である。このように、電子署名に対する改竄が行われた場合、上述したAndroid（登録商標）をＯＳとして利用している端末装置などでは、有効な改竄検知を行うことができない。

一方、前掲の特許文献３，４に記載されているように、予め登録されているアプリケーションプログラムだけについて、その実行を許可するような運用を行った場合、適切な登録作業が行われている限り、改竄されたプログラムの実行を阻止することができる。しかしながら、実際には、配布を受けたプログラムが改竄されたものであるか否かをユーザが正しく判断することは困難であり、また、仮に改竄されていないプログラムであることが判明した場合でも、ユーザがこれを個別に登録する作業を行う必要があるため、ユーザに煩雑な作業負担を課す結果になる。

そこで本発明は、電子署名に対する改竄が行われた場合にも、有効な改竄検知を行うことができるアプリケーションプログラムの改竄検知方法を提供することを目的とする。また、当該検知方法を利用することにより、改竄なしと判定されたアプリケーションプログラムについては、ユーザに登録作業の負担を課すことなしに、実行許可リストへの自動登録が行われるアプリケーションプログラムの実行方法を提供することを目的とする。

(1) 本発明の第１の態様は、改竄チェックの準備を行う準備プロセスと、アプリケーションプログラムを配布する配布プロセスと、配布されたアプリケーションプログラムに対する改竄チェックを行う改竄チェックプロセスと、を有するアプリケーションプログラムの改竄検知方法において、
準備プロセスでは、
アプリケーションプログラムを実行するためのアプリケーション実行用コンピュータが、第１の特定鍵を用いて改竄チェックを行う改竄チェックルーチンを含む改竄チェックプログラムをインストールする改竄チェックプログラム準備段階を行い、
配布プロセスでは、
コンピュータが、配布対象となるアプリケーションプログラムに対してパッケージ化処理を施し、アプリケーションパッケージを作成するパッケージ化段階と、
コンピュータが、アプリケーションパッケージを署名対象データとして、プログラム提供者の第１の鍵を用いた暗号化を利用した電子署名処理を行って署名値を生成し、この署名値とプログラム提供者の第２の鍵とを含む署名情報を作成する署名情報作成段階と、
コンピュータが、アプリケーションパッケージおよび署名情報を構成するデータの中から、プログラム提供者の第２の鍵を含む所定部分を秘匿化対象データとして抽出し、抽出した秘匿化対象データに対して第２の特定鍵を用いた秘匿化処理を施して秘匿情報を作成する秘匿情報作成段階と、
コンピュータが、アプリケーションパッケージと、署名情報と、秘匿情報もしくは秘匿情報の所在を示す所在情報と、を含む配布用ファイルを作成する配布用ファイル作成段階と、
コンピュータが、配布用ファイルを出力するファイル出力段階と、
を行い、
改竄チェックプロセスでは、
アプリケーション実行用コンピュータが、配布用ファイルを入力するファイル入力段階と、
アプリケーション実行用コンピュータが、入力した配布用ファイルについて、署名情報に含まれているプログラム提供者の第２の鍵を用いた復号を利用した署名確認処理を行って、アプリケーションパッケージに対する署名情報の正当性を確認する第１の確認段階と、
アプリケーション実行用コンピュータが、入力した配布用ファイルに基づいて秘匿化対象データおよび秘匿情報を入手し、秘匿化対象データに対する秘匿情報の正当性を、改竄チェックプログラムを実行することにより確認する第２の確認段階と、
アプリケーション実行用コンピュータが、入力した配布用ファイルについて、第１の確認段階および第２の確認段階の少なくとも一方において否定的な結果が得られた場合に改竄ありとの判定を行う改竄判定段階と、
を行い、
プログラム提供者の第１の鍵および第２の鍵として、一方の鍵を用いて暗号化したデータを他方の鍵を用いて復号できる性質をもった一対の鍵を用い、第１の特定鍵および第２の特定鍵として、一方の鍵を用いて秘匿化処理を施したデータの正当性を他方の鍵を用いて確認できる性質をもった一対もしくは同一の鍵を用いるようにしたものである。

(2) 本発明の第２の態様は、上述した第１の態様に係るアプリケーションプログラムの改竄検知方法において、
第１の特定鍵および第２の特定鍵として、一方の鍵を用いて暗号化したデータを他方の鍵を用いて復号できる性質をもった一対の鍵を用い、
秘匿情報作成段階で、第２の特定鍵を用いて、秘匿化対象データに対する暗号化処理を施して秘匿情報を作成し、
第２の確認段階で、第１の特定鍵を用いて秘匿情報を復号し、この復号によって得られた秘匿化対象データと、入力した配布用ファイルから抽出した秘匿化対象データとが一致していた場合に、秘匿情報が正当である旨の確認を行うようにしたものである。

(3) 本発明の第３の態様は、上述した第２の態様に係るアプリケーションプログラムの改竄検知方法において、
第１の特定鍵としてプログラム保証者の第１の鍵を用い、第２の特定鍵としてプログラム保証者の第２の鍵を用い、プログラム保証者の第２の鍵を用いて暗号化したデータをプログラム保証者の第１の鍵を用いて復号できるようにし、
改竄チェックプログラム準備段階で、プログラム保証者の第１の鍵を用いて改竄チェックを行う改竄チェックルーチンを含む改竄チェックプログラムのインストールを行い、
秘匿情報作成段階で、プログラム保証者の第２の鍵を用いて、秘匿化対象データに対する暗号化処理を施して秘匿情報を作成し、
第２の確認段階で、プログラム保証者の第１の鍵を用いて秘匿情報を復号し、この復号によって得られた秘匿化対象データと、入力した配布用ファイルから抽出した秘匿化対象データとが一致していた場合に、秘匿情報が正当である旨の確認を行うようにしたものである。

(4) 本発明の第４の態様は、上述した第１の態様に係るアプリケーションプログラムの改竄検知方法において、
第１の特定鍵および第２の特定鍵として同一の共通特定鍵を用い、
改竄チェックプログラム準備段階で、共通特定鍵を用いて改竄チェックを行う改竄チェックルーチンを含む改竄チェックプログラムのインストールを行い、
秘匿情報作成段階で、秘匿化対象データに対して、共通特定鍵をパラメータとして用いた一方向性関数を作用させるダイジェスト化処理を施して秘匿情報を作成し、
第２の確認段階で、入力した配布用ファイルから秘匿化対象データを抽出し、抽出した秘匿化対象データに対して、共通特定鍵を用いたダイジェスト化処理を施して得られる情報が、入力した配布用ファイルに基づいて入手した秘匿情報と一致していた場合に、秘匿情報が正当である旨の確認を行うようにしたものである。

(5) 本発明の第５の態様は、上述した第４の態様に係るアプリケーションプログラムの改竄検知方法において、
秘匿情報作成段階および第２の確認段階で、共通特定鍵をパラメータとして用いたハッシュ関数を作用させるダイジェスト化処理を施して得られるハッシュ値を秘匿情報とするようにしたものである。

(6) 本発明の第６の態様は、上述した第１〜第５の態様に係るアプリケーションプログラムの改竄検知方法において、
秘匿化対象データとして、署名情報を構成するデータ全体を用いるようにしたものである。

(7) 本発明の第７の態様は、上述した第１〜第５の態様に係るアプリケーションプログラムの改竄検知方法において、
秘匿化対象データとして、署名情報に含まれるプログラム提供者の第２の鍵を構成するデータを用いるようにしたものである。

(8) 本発明の第８の態様は、上述した第１〜第５の態様に係るアプリケーションプログラムの改竄検知方法において、
秘匿化対象データとして、アプリケーションパッケージと署名情報との双方を構成するデータ全体を用いるようにしたものである。

(9) 本発明の第９の態様は、上述した第１〜第８の態様に係るアプリケーションプログラムの改竄検知方法において、
改竄チェックプログラム内に第１の特定鍵が含まれているようにしたものである。

(10) 本発明の第１０の態様は、上述した第１〜第８の態様に係るアプリケーションプログラムの改竄検知方法において、
改竄チェックプログラム内に、改竄チェックルーチンと、この改竄チェックルーチンが改竄チェックを行うために必要な第１の特定鍵の格納場所を示す所在情報と、が含まれており、
第２の確認段階で、アプリケーション実行用コンピュータが、改竄チェックプログラムから所在情報を抽出し、この所在情報に基づいて格納場所を認識し、格納場所から取り出した第１の特定鍵を用いて改竄チェックルーチンを実行するようにしたものである。

(11) 本発明の第１１の態様は、上述した第１〜第８の態様に係るアプリケーションプログラムの改竄検知方法において、
改竄チェックプログラム内に、改竄チェックルーチンと、この改竄チェックルーチンが改竄チェックを行うために必要な第１の特定鍵の格納場所を示す所在情報と、が含まれており、
アプリケーション実行用コンピュータ内に、第１の特定鍵を保存する保存場所を設け、アプリケーション実行用コンピュータが第２の確認段階を実行する際に、保存場所に、第１の特定鍵が保存されていない場合には、改竄チェックプログラムから所在情報を抽出し、この所在情報に基づいて格納場所を認識し、格納場所から第１の特定鍵を取り出すことにより、第１の特定鍵の入手を行うとともに入手した第１の特定鍵を保存場所に保存する処理を行い、保存場所に、第１の特定鍵が保存されている場合には、保存場所から第１の特定鍵を取り出すことにより、当該第１の特定鍵の入手を行い、入手した第１の特定鍵を用いて改竄チェックルーチンを実行するようにしたものである。

(12) 本発明の第１２の態様は、上述した第１０または第１１の態様に係るアプリケーションプログラムの改竄検知方法において、
所定の認証用データを用いた認証機能が備わった格納場所に第１の特定鍵が格納されており、
改竄チェックプログラム内に、認証用データが含まれており、
アプリケーション実行用コンピュータが、格納場所から第１の特定鍵の取り出しを行う際に、認証用データを利用した認証を行うようにしたものである。

(13) 本発明の第１３の態様は、上述した第１０〜第１２の態様に係るアプリケーションプログラムの改竄検知方法において、
第１の特定鍵の格納場所には、第１の特定鍵とともに所定の暗号鍵が格納されており、
改竄チェックプログラム内に、暗号鍵に対応した復号鍵が含まれており、
アプリケーション実行用コンピュータが、格納場所から第１の特定鍵の取り出しを行う際に、通信路上を第１の特定鍵が暗号鍵によって暗号化された状態で送信されるようにし、受信後にこれを復号鍵で復号するようにしたものである。

(14) 本発明の第１４の態様は、上述した第１〜第１３の態様に係るアプリケーションプログラムの改竄検知方法において、
アプリケーション実行用コンピュータが、改竄ありとの判定が行われた配布用ファイルに含まれているアプリケーションプログラムについては、実行を中止する処理を行うようにしたものである。

(15) 本発明の第１５の態様は、上述した第１〜第１４の態様に係るアプリケーションプログラムの改竄検知方法において、
アプリケーション実行用コンピュータとして、ＯＳプログラムの管理下でアプリケーションプログラムの実行を行うコンピュータを用い、
第１の確認段階をＯＳプログラムに基づいて実行し、
第２の確認段階を改竄チェックプログラムに基づいて実行し、
改竄チェックプログラムを、改竄チェックの対象となるアプリケーションプログラムとは別のアプリケーションプログラムによって構成するか、もしくは、ＯＳプログラムの一部によって構成するようにしたものである。

(16) 本発明の第１６の態様は、上述した第１〜第１５の態様に係るアプリケーションプログラムの改竄検知方法において、
改竄チェックの対象となるアプリケーションプログラムが、プログラム本体部と、このプログラム本体部から呼び出されるサブルーチン群と、画像および文字列を含むリソースデータと、ＸＭＬ形式のデータからなるマニフェストファイルと、を含んでおり、
パッケージ化段階において、ＺＩＰ方式の圧縮処理を含むパッケージ化処理を実行し、配布用ファイル作成段階において、ＡＰＫ形式のフォーマットをもった配布用ファイルを作成するようにしたものである。

(17) 本発明の第１７の態様は、上述した第１６の態様に係るアプリケーションプログラムの改竄検知方法において、
配布用ファイル作成段階において、ＺＩＰ方式の圧縮フォーマットにおけるコメント領域に秘匿情報もしくは所在情報を記録することにより配布用ファイルを作成するようにしたものである。

(18) 本発明の第１８の態様は、上述した第１〜第１７の態様に係るアプリケーションプログラムの改竄検知方法において、
配布用ファイル作成段階で、コンピュータが、秘匿情報を含む配布用ファイルを作成し、
第２の確認段階で、アプリケーション実行用コンピュータが、入力した配布用ファイルから秘匿情報を抽出することにより、当該秘匿情報の入手を行うようにしたものである。

(19) 本発明の第１９の態様は、上述した第１〜第１７の態様に係るアプリケーションプログラムの改竄検知方法において、
配布用ファイル作成段階で、コンピュータが、秘匿情報を所定の格納場所に格納する処理を行うとともに、当該格納場所を示す所在情報を含む配布用ファイルを作成し、
第２の確認段階で、アプリケーション実行用コンピュータが、入力した配布用ファイルから所在情報を抽出し、この所在情報に基づいて格納場所を認識し、格納場所から秘匿情報を取り出すことにより、当該秘匿情報の入手を行うようにしたものである。

(20) 本発明の第２０の態様は、上述した第１〜第１７の態様に係るアプリケーションプログラムの改竄検知方法において、
配布用ファイル作成段階で、コンピュータが、秘匿情報を所定の格納場所に格納する処理を行うとともに、当該格納場所を示す所在情報を含む配布用ファイルを作成し、
アプリケーション実行用コンピュータ内に、入力した配布用ファイルについての秘匿情報を保存する保存場所を設け、アプリケーション実行用コンピュータが第２の確認段階を実行する際に、保存場所に、必要な秘匿情報が保存されていない場合には、配布用ファイルから所在情報を抽出し、この所在情報に基づいて格納場所を認識し、格納場所から秘匿情報を取り出すことにより、当該秘匿情報の入手を行うとともに、入手した秘匿情報を保存場所に保存する処理を行い、保存場所に、必要な秘匿情報が保存されている場合には、保存場所から秘匿情報を取り出すことにより、当該秘匿情報の入手を行うようにしたものである。

(21) 本発明の第２１の態様は、アプリケーションプログラムの改竄を検知するアプリケーションプログラムの改竄検知方法において、
コンピュータが、アプリケーションプログラムと、署名情報と、秘匿情報もしくはその所在を示す所在情報と、を含むデータファイルを入力する入力段階と、
コンピュータが、アプリケーションプログラムが改竄されているか否かを判定する判定段階と、
を有し、
署名情報は、アプリケーションプログラムを署名対象データとする電子署名処理によって得られた情報であり、
秘匿情報は、アプリケーションプログラムおよび署名情報を構成するデータの中の所定部分を秘匿化対象データとして抽出し、抽出した秘匿化対象データに対する秘匿化処理を施して得られた情報であり、
判定段階は、署名情報に基づいて改竄の有無を確認する第１の確認段階と、秘匿情報に基づいて改竄の有無を確認する第２の確認段階と、を有し、
コンピュータには、改竄チェックプログラムがインストールされており、改竄チェックプログラムには秘匿化処理で行われた処理プロセスを勘案して秘匿化対象データに対する秘匿情報の正当性を確認する改竄チェックルーチンが含まれており、改竄チェックルーチンを実行することにより第２の確認段階が行われるようにしたものである。

(22) 本発明の第２２の態様は、上述した第２１の態様に係るアプリケーションプログラムの改竄検知方法において、
一方の鍵を用いて暗号化したデータを他方の鍵を用いて復号できる性質をもった一対の鍵を用い、
秘匿情報が、秘匿化対象データを一方の鍵を用いて暗号化することにより得られた情報であり、
改竄チェックルーチンが、入力段階で入力したデータファイルに含まれている秘匿情報もしくは入力段階で入力したデータファイルに含まれている所在情報に基づいて入手した秘匿情報を他方の鍵を用いて復号し、この復号によって得られた秘匿化対象データと、入力段階で入力したデータファイルから抽出した秘匿化対象データとが一致していた場合に、第２の確認段階に関して改竄なしとの判定を行うようにしたものである。

(23) 本発明の第２３の態様は、上述した第２１の態様に係るアプリケーションプログラムの改竄検知方法において、
秘匿情報が、秘匿化対象データに対して、所定の特定鍵をパラメータとして用いた一方向性関数を作用させるダイジェスト化処理を施して作成された情報であり、
改竄チェックルーチンが、入力段階で入力したデータファイルから抽出した秘匿化対象データに対して、特定鍵を用いたダイジェスト化処理を施して得られる情報が、入力段階で入力したデータファイルに含まれている秘匿情報もしくは入力段階で入力したデータファイルに含まれている所在情報に基づいて入手した秘匿情報と一致していた場合に、第２の確認段階に関して改竄なしとの判定を行うようにしたものである。

(24) 本発明の第２４の態様は、アプリケーションプログラムの配布方法において、上述した第１〜第２０の態様に係るアプリケーションプログラムの改竄検知方法における配布プロセスを構成する各段階をコンピュータに実行させるようにしたものである。

(25) 本発明の第２５の態様は、アプリケーションプログラムの改竄チェック方法において、上述した第１〜第２０の態様に係るアプリケーションプログラムの改竄検知方法における改竄チェックプロセスを構成する各段階をコンピュータに実行させるようにしたものである。

(26) 本発明の第２６の態様は、上述した第１〜第２０の態様に係るアプリケーションプログラムの改竄検知方法における配布プロセスを構成する各段階を実行するために、コンピュータ用プログラムを用意したものである。

(27) 本発明の第２７の態様は、上述した第１〜第２０の態様に係るアプリケーションプログラムの改竄検知方法における改竄チェックプロセスを構成する各段階を実行するために、コンピュータ用プログラムを用意したものである。

(28) 本発明の第２８の態様は、上述した第１〜第２０の態様に係るアプリケーションプログラムの改竄検知方法を利用して、アプリケーション実行用コンピュータが、配布されたアプリケーションプログラムを実行するアプリケーションプログラムの実行方法において、
アプリケーション実行用コンピュータが、上記改竄検知方法により、入力したアプリケーションプログラムが改竄されているか否かを判定する改竄判定段階と、
アプリケーション実行用コンピュータが、上記改竄判定段階において改竄されていない旨の判定がなされたアプリケーションプログラムの識別情報を、実行許可リストに登録するリスト自動登録段階と、
アプリケーション実行用コンピュータが、起動状態にあるアプリケーションプログラムの識別情報を認識する起動アプリ認識段階と、
アプリケーション実行用コンピュータが、起動アプリ認識段階において認識した識別情報が実行許可リストに登録されているか否かを判定する登録有無判定段階と、
アプリケーション実行用コンピュータが、登録有無判定段階において未登録と判定された場合に、当該未登録アプリを登録するか否かをユーザに問い合わせる登録照会段階と、
アプリケーション実行用コンピュータが、問い合わせに対するユーザの回答として、登録する旨の回答があった場合には、未登録アプリの識別情報を実行許可リストに登録した上で当該アプリの実行を許可し、登録しない旨の回答があった場合には、当該未登録アプリの実行を中止させる回答処理段階と、
を行うようにしたものである。

(29) 本発明の第２９の態様は、上述した第２８の態様に係るアプリケーションプログラムの実行方法において、
アプリケーション実行用コンピュータに組み込まれたＯＳプログラムが、複数のアプリケーションプログラムを所定のタイミングで切り替えながら実行させるマルチタスク処理機能を有しており、
アプリケーション実行用コンピュータが、アプリケーションプログラムの１つとして用意された監視プログラムによって、リスト自動登録段階、起動アプリ認識段階、登録有無判定段階、登録照会段階、回答処理段階を実行するようにしたものである。

(30) 本発明の第３０の態様は、上述した第２９の態様に係るアプリケーションプログラムの実行方法において、
アプリケーション実行用コンピュータが、ＯＳプログラムによって、個々のアプリケーションプログラムについて、識別情報・起動時・終了時を示すログ情報を記録する処理を実行し、
アプリケーション実行用コンピュータが、監視プログラムによって起動アプリ認識段階を実行する際に、ログ情報を参照することにより起動状態にあるアプリケーションプログラムの識別情報を認識するようにしたものである。

(31) 本発明の第３１の態様は、上述した第２８〜第３０の態様に係るアプリケーションプログラムの実行方法において、
リスト自動登録段階、回答処理段階、および起動アプリ認識段階において、バージョンの異なるアプリケーションプログラムについては、それぞれ異なる識別情報を用いた処理を行うようにしたものである。

(32) 本発明の第３２の態様は、上述した第３１の態様に係るアプリケーションプログラムの実行方法において、
同一のファイル名をもったデータファイルに含まれるアプリケーションプログラムであっても、ハッシュ値が異なる場合は、異なるバージョンと認識するようにしたものである。

(33) 本発明の第３３の態様は、上述した第２８〜第３０の態様に係るアプリケーションプログラムの実行方法において、
バージョンの異なる同一のアプリケーションプログラムについては共通の識別情報を用いるようにし、
アプリケーション実行用コンピュータが、配布された２組のアプリケーションプログラムについて、その識別情報、署名値、第２の鍵を比較し、相互に署名値は異なるが、識別情報および第２の鍵が一致する場合には、当該２組のアプリケーションプログラムが同一のプログラム提供者によって提供されたバージョン違いのアプリケーションプログラムであると認識し、これら２組のアプリケーションプログラムに対して、予め定められた所定のバージョン更新処理を実行するようにしたものである。

(34) 本発明の第３４の態様は、上述した第２８〜第３３の態様に係るアプリケーションプログラムの実行方法において、
リスト自動登録段階もしくは回答処理段階で実行許可リストへの登録を行う際に、アプリケーション実行用コンピュータが外部の格納場所内に保存された実行許可リストに対する登録を行い、
登録有無判定段階で、アプリケーション実行用コンピュータが外部の格納場所に保存された実行許可リストを参照することにより判定を行うようにしたものである。

(35) 本発明の第３５の態様は、上述した第２８〜第３４の態様に係るアプリケーションプログラムの実行方法において、
リスト自動登録段階もしくは回答処理段階で実行許可リストへの登録を行う際に、アプリケーション実行用コンピュータが実行許可リストを暗号化する処理を行い、
登録有無判定段階で、アプリケーション実行用コンピュータが暗号化されている実行許可リストを復号して内容の参照を行うようにしたものである。

(36) 本発明の第３６の態様は、上述した第２８〜第３５の態様に係るアプリケーションプログラムの実行方法において、
リスト自動登録段階もしくは回答処理段階で実行許可リストへの登録を行う際に、アプリケーション実行用コンピュータが、識別情報とともに、ファイル入力段階で入力した配布用ファイルに含まれている所定のチェックコードを登録するようにし、
登録有無判定段階で、アプリケーション実行用コンピュータが、配布用ファイル内に含まれているチェックコードと実行許可リストに登録されているチェックコードとの一致を確認し、一致確認がなされることを条件として、実行許可リストに登録されている旨の判定を行うようにしたものである。

(37) 本発明の第３７の態様は、上述した第２８〜第３５の態様に係るアプリケーションプログラムの実行方法において、
リスト自動登録段階もしくは回答処理段階で実行許可リストへの登録を行う際に、アプリケーション実行用コンピュータが、識別情報とともに、ファイル入力段階で入力した配布用ファイルに含まれている所定の情報に対して一方向性関数を作用させるダイジェスト化処理を行うことにより得られるチェックコードを登録するようにし、
登録有無判定段階で、アプリケーション実行用コンピュータが、配布用ファイル内に含まれている所定の情報に対して一方向性関数を作用させるダイジェスト化処理を行うことにより得られるチェックコードと、実行許可リストに登録されているチェックコードとの一致を確認し、一致確認がなされることを条件として、実行許可リストに登録されている旨の判定を行うようにしたものである。

(38) 本発明の第３８の態様は、上述した第１〜第２３の態様に係るアプリケーションプログラムの改竄検知方法を利用して、アプリケーション実行用コンピュータが、配布されたアプリケーションプログラムを実行するアプリケーションプログラムの実行方法において、
アプリケーション実行用コンピュータが、上記改竄検知方法により、入力したアプリケーションプログラムが改竄されているか否かを判定する改竄判定段階と、
アプリケーション実行用コンピュータが、上記改竄判定段階において改竄されていない旨の判定がなされたアプリケーションプログラムの識別情報を、実行許可リストに登録するリスト自動登録段階と、
アプリケーション実行用コンピュータが、実行許可リストを参照して、リストに登録されているアプリケーションプログラムと登録されていないアプリケーションプログラムとの間で異なる処理を実行する段階と、
を行うようにしたものである。

(39) 本発明の第３９の態様は、上述した第２９または第３０の態様に係るアプリケーションプログラムの実行方法における監視プログラムを用意したものである。

本発明に係るアプリケーションプログラムの改竄検知方法では、まず、配布プロセスにおいて、アプリケーションパッケージに対して、署名情報が付加されるとともに、特定のデータを秘匿化対象データとして秘匿化する処理が行われ、その結果として得られた秘匿情報も付加される。一方、改竄チェックプロセスでは、署名情報の正当性だけでなく、秘匿情報の正当性の確認も行われる。このため、アプリケーションパッケージ自体の改竄だけでなく、署名情報の改竄も検知することができるようになり、電子署名に対する改竄が行われた場合にも、有効な改竄検知が可能になる。

また、本発明に係るアプリケーションプログラムの実行方法では、上記改竄検知方法を実行することによって、改竄されていない旨の判定がなされた場合には、実行許可リストへの自動登録が行われる。このため、ユーザが登録作業を行う必要はなくなり、登録作業の負担が軽減される。

署名情報を付加した従来の一般的なアプリケーションプログラムの配布方法を示すブロック図である。図１に示す配布用ファイル２０の具体的な作成方法を示すブロック図である。図２に示す配布用ファイル２０について、署名情報２２の正当性を確認する処理を示すブロック図である。図１に示す従来の配布方法に対してクラッカーＸが試みる改竄プロセスを示すブロック図である。本発明に係るアプリケーションプログラムの改竄検知方法の基本原理を示すブロック図である。図５に示す配布用ファイル２０Ａについて、署名情報２２の正当性および秘匿情報２３の正当性を確認する改竄チェック処理を示すブロック図である。本発明に係るアプリケーションプログラムの改竄検知方法の基本手順を示す流れ図である。図５に示す本発明に係る配布用ファイル２０Ａに対してクラッカーＸが試みる改竄プロセスを示すブロック図である。図５に示す本発明の基本的な実施形態に係る配布プロセスのバリエーションを示すブロック図である。図５に示す本発明の基本的な実施形態に係る配布プロセスの別なバリエーションを示すブロック図である。図５に示す本発明に係る配布プロセスにおいて、秘匿情報２３として暗号化された情報を用いる具体的実施例を示すブロック図である。図１１に示す配布用ファイル２０Ａについて、署名情報２２の正当性および秘匿情報２３の正当性を確認する改竄チェック処理を示すブロック図である。図５に示す本発明に係る配布プロセスにおいて、秘匿情報２３としてダイジェスト化された情報を用いる具体的実施例を示すブロック図である。図１３に示す配布用ファイル２０Ａについて、署名情報２２の正当性および秘匿情報２３の正当性を確認する改竄チェック処理を示すブロック図である。本発明に係るアプリケーションプログラムの改竄検知方法の変形例を示すブロック図である。本発明に係るアプリケーションプログラムの改竄検知方法の別な変形例を示すブロック図である。本発明に係るアプリケーションプログラムの改竄検知方法をＯＳプログラムによって実行した場合の基本手順を示す流れ図である。本願発明者によって提案されている監視プログラムの処理手順を示す流れ図である。図１８に示す起動アプリ認識段階Ｓ３１で起動アプリの認識に利用されるログ情報の一例を示す図である。本発明に係るアプリケーションプログラムの実行方法で利用される実行許可リストの一例を示す図である。図１８に示す登録照会段階Ｓ３４でユーザに提示されるメッセージ画面の一例を示す図である。本発明の応用例において、通常アプリを起動したときのＯＳプログラム、改竄チェックプログラム、監視プログラムの処理手順を示す流れ図である。改竄チェックプログラムと監視プログラムの構成例のバリエーションを示すブロック図である。

以下、本発明を図示する実施形態に基づいて説明する。

＜＜＜ §１．署名情報を付加する一般的な配布方法＞＞＞
ここでは、説明の便宜上、署名情報を付加した従来の一般的なアプリケーションプログラムの配布方法を簡単に説明しておく。図１は、このような従来の配布方法を示すブロック図である。ここでは、具体的な例として、Android（登録商標）をＯＳとして採用するスマートフォンやタブレット型電子機器（いわゆる、Android端末）に対して、アプリケーションプログラムを配布する場合を例にとって説明する。

Android端末用のアプリケーションプログラムのデータ構造およびその配布形態については、世界的な標準仕様が定められており、一般的なアプリケーションプログラムは、いずれもこの標準仕様に基づいて作成され、配布されることになる。

具体的には、プログラム提供者Ａ（コンテンツプロバイダ）は、まず、図１の上段に示すようなデータ構造を有するアプリケーションプログラム１０を作成する。Androidの標準仕様では、アプリケーションプログラム１０は、基本的には、図示のとおり、プログラム本体部１１，リソースデータ１２，サブルーチン群１３，補助ファイル１４によって構成され、場合によっては、この他にもいくつかのファイルが付加されたり、いくつかが省略されたりする（たとえば、プログラム本体部１１がサブルーチンを利用しないケースでは、サブルーチン群１３は不要である）。

ここで、プログラム本体部１１はJava（登録商標）で記述されたプログラムのコンパイル後のファイルであり、アプリケーションプログラムの中枢を構成する要素になる。アプリケーションプログラム１０が起動されると、このプログラム本体部１１の先頭から命令コードが順次実行されることになる。

リソースデータ１２は、プログラム本体部１１が必要に応じて利用する画像や文字列のデータ群である。画像データは、JPEG形式、GIF形式、BMP形式、PNG形式など、様々なフォーマットで記述されたデータファイルとして用意され、文字列データも同様に、XML形式など、様々なフォーマットで記述されたデータファイルとして用意される。

一方、サブルーチン群１３は、「Shared Object」と呼ばれている汎用のサブルーチンプログラム群から構成される。個々のサブルーチンは、プログラム本体部１１からのサブルーチンコール命令によって呼び出され、それぞれの役割に応じた所定の処理を実行する。呼び出されたサブルーチンプログラムがその任務を完了すると、制御は再びプログラム本体部１１内のプログラムに戻ることになる。プログラム本体部１１は、サブルーチンコールを行う際に、必要に応じて何らかのデータを引数としてサブルーチンへ引き渡すことができ、各サブルーチンプログラムは、必要に応じて、その実行結果をプログラム本体部１１へ引き渡すことができる。

補助ファイル１４は、一般に「マニフェスト」と呼ばれている補助的な情報を記述したXML形式のファイルである。ここには、Android端末で当該アプリケーションプログラムを実行する際のパーミッション情報（たとえば、当該プログラムが、インターネット接続を行うか否か、GPS情報を参照するか否か、電話機能を利用するか否か、といった情報）などが記録される。このパーミッション情報は、当該アプリケーションプログラムのインストール時や起動時にユーザに提示され、ユーザがこれに納得する旨の確認入力を行った場合に限り、インストールや起動が行われることになる。

以上、Android端末用アプリケーションプログラム１０の基本データ構造を説明したが、アプリケーションプログラム１０は、このままの状態では配布することができない。Androidの標準仕様によると、このアプリケーションプログラム１０を配布する際には、パッケージ化処理および署名情報付加処理が必要である。

Androidの標準仕様によれば、パッケージ化処理は、主に、アプリケーションプログラム１０を構成する個々のファイルを圧縮して１つのパッケージにまとめる処理であり（その他、中間コンパイル処理なども併せて行われる）、図１の中段に示すように、このパッケージ化処理を施すことにより、アプリケーションプログラム１０は、１つのアプリケーションパッケージ２１にまとめられる。圧縮プロセスを経ることにより、アプリケーションパッケージ２１のデータ容量は元のアプリケーションプログラム１０の容量に比べて削減され、配布に適した形になる。

なお、上述したとおり、Androidの標準仕様では、パッケージ化処理には、少なくとも圧縮処理が含まれるため、以下の説明では、圧縮処理を含むパッケージ化処理の実施例を述べるが、一般にパッケージ化処理とは、配布やＯＳに応じたインストールを容易にするために、単一のファイルとして取り扱うことが可能な形式にまとめあげる処理を指し、必ずしも圧縮処理が必要になるものではない。たとえば、Windows（登録商標）ＯＳでは、Setup.exeファイルの実行によりインストール可能な形式となるようなパッケージ化処理が行われている。

一方、署名情報付加処理は、このアプリケーションパッケージ２１を署名対象データＤとして、プログラム提供者Ａが自己の署名を施す処理であり、この処理によって、Ａの署名情報２２が作成される。具体的には、公開鍵暗号方式を利用した電子署名処理が採用されており、プログラム提供者Ａの第１の鍵Ｋ（ａ１）を用いて、署名対象データＤ（すなわち、アプリケーションパッケージ２１）に対する署名値Ｓ（Ａ）を作成する処理が行われ、作成された署名値Ｓ（Ａ）と、プログラム提供者Ａの第２の鍵Ｋ（ａ２）とを含むＡの署名情報２２が作成される。図１において太線で囲って示す部分は、署名対象データＤとなる部分を示しており、署名情報２２は、この太線枠内のデータに対して、プログラム提供者Ａが署名したことを示す情報ということになる。

ここで、第１の鍵Ｋ（ａ１）と第２の鍵Ｋ（ａ２）とは、公開鍵暗号方式における秘密鍵と公開鍵との関係を有するデジタルデータであり、一方の鍵を用いて暗号化したデータを他方の鍵を用いて復号できる性質をもっている。通常、第１の鍵Ｋ（ａ１）として秘密鍵が、第２の鍵Ｋ（ａ２）として公開鍵が、それぞれ用いられ、Androidの標準仕様上では、前者を秘密にし、後者を公開する取り決めになっているが、本願では、単に、第１の鍵Ｋ（ａ１），第２の鍵Ｋ（ａ２）と呼ぶことにする。

こうして作成されたＡの署名情報２２は、署名対象となるアプリケーションパッケージ２１について、プログラム提供者Ａがその内容を保証するための情報であり、万一、アプリケーションパッケージ２１の内容が改竄されていた場合には、後述するように、Ａの署名情報２２との間に不整合が生じることになるので、このＡの署名情報２２を利用した改竄検知が可能になる。

配布用ファイル２０は、アプリケーションパッケージ２１にＡの署名情報２２を付加することによって構成されるファイルである。プログラム提供者Ａは、アプリケーションプログラム１０に対して、上述したパッケージ化処理および署名情報付加処理を施して配布用ファイル２０を作成し、インターネット等を介して多数のユーザＵ１，Ｕ２，Ｕ３へと配布することになる。もちろん、光学的記録媒体やＩＣメモリ等に格納した状態で配布することも可能である。

Androidの仕様では、このようなデータ構造を有する配布用ファイル２０は、ＡＰＫファイルと呼ばれており、Android端末に配布するアプリケーションプログラムは、すべてこのＡＰＫファイルの形式で配布する必要がある。別言すれば、Androidの仕様では、配布するすべてのアプリケーションプログラムに署名情報を付加することが義務づけられており、Android端末では、配布されたＡＰＫファイルを実行する際に、署名情報に基づく改竄検知が行われることになる。

図２は、図１に示す配布用ファイル２０の具体的な作成方法、特に、署名情報２２の具体的な作成方法を示すブロック図である。署名情報付加処理では、まず、署名対象データＤ（すなわち、アプリケーションパッケージ２１）に対してハッシュ関数ＨＡＳＨを作用させた不可逆変換が行われ、ハッシュ値Ｈ＝ＨＡＳＨ（Ｄ）が求められる。ハッシュ関数は代表的な一方向性関数であり、もとのデータＤに対しては常に一義的なハッシュ値Ｈが得られるが、逆に、ハッシュ値ＨからはもとのデータＤを復元することはできない性質をもっている。このため、ハッシュ値Ｈは、もとのデータＤ（図示の例の場合は、アプリケーションパッケージ２１を構成する全データ）に比べてデータ容量を極めて小さくできる。

次に、このハッシュ値Ｈを、プログラム提供者Ａの第１の鍵Ｋ（ａ１）を用いた公開鍵暗号方式の暗号化アルゴリズムを用いて暗号化し、署名値Ｓ（Ａ）を求める。すなわち、署名値Ｓ（Ａ）は、ハッシュ値Ｈを暗号化したデータであり、プログラム提供者Ａの第２の鍵Ｋ（ａ２）を用いた復号を行うことにより、元のハッシュ値Ｈが得られることになる。結局、アプリケーションパッケージ２１を署名対象データＤとして、プログラム提供者Ａの第１の鍵Ｋ（ａ１）を用いた暗号化を利用した電子署名処理を行って署名値Ｓ（Ａ）を生成し、この署名値Ｓ（Ａ）とプログラム提供者Ａの第２の鍵Ｋ（ａ２）とによって、Ａの署名情報２２が作成されることになる。

前述したとおり、配布用ファイル（ＡＰＫファイル）２０は、アプリケーションパッケージ２１にＡの署名情報２２を付加したファイルであり、Android端末に対しては、このような形式をもったファイルとして、アプリケーションプログラム１０が配布されることになる。ここでは、便宜上、この配布用ファイル２０が「PatGame.apk」なるファイル名をもったゲーム用アプリケーションファイルとして配布されたものとしよう（ファイル名の拡張子.apkは、このファイルがＡＰＫファイルであることを示している）。

この配布用ファイル２０の実行時には、上述したとおり、署名情報に基づく改竄検知（署名情報２２の正当性確認）が行われる。図３は、Android端末において実行される署名情報２２の正当性確認処理を示すブロック図である。

Android端末が入手した「PatGame.apk」なるファイル名をもった配布用ファイル２０には、アプリケーションパッケージ２１とＡの署名情報２２とが含まれている。ここで、署名情報２２には、署名値Ｓ（Ａ）とＡの第２の鍵Ｋ（ａ２）とが含まれており、前述したように、署名値Ｓ（Ａ）に対して、Ａの第２の鍵Ｋ（ａ２）を用いた復号処理を行うことにより、元のハッシュ値Ｈを得ることができる。図３では、このような署名値Ｓ（Ａ）の復号によって得られたハッシュ値をハッシュ値Ｈ１と呼ぶことにする。

一方、アプリケーションパッケージ２１（署名対象データＤ）に対して、図２に示すハッシュ関数ＨＡＳＨを作用させた不可逆変換を行い、ハッシュ値Ｈ＝ＨＡＳＨ（Ｄ）を求める処理も行う。図３では、このような不可逆変換によって得られたハッシュ値をハッシュ値Ｈ２と呼ぶことにする。もし、Android端末が入手した「PatGame.apk」なるファイル名をもった配布用ファイル２０に含まれているアプリケーションパッケージ２１の内容が、図２の上段に示すアプリケーションパッケージ２１の内容と完全に同一であれば、ハッシュ値Ｈ１，Ｈ２は一致するはずである。

そこで、ユーザＵが利用するAndroid端末において、ハッシュ値Ｈ１，Ｈ２の一致を確認する処理を実行すれば、アプリケーションパッケージ２１に対する改竄が行われているか否かを判定することができる。AndroidＯＳには、アプリケーションプログラムの実行前にこのような一致確認を行い、両者が不一致であった場合には、アプリケーションパッケージ２１に対して何らかの改竄が行われたものと判断し、当該アプリケーションプログラムの実行を中止する機能が備わっている。

＜＜＜ §２．従来の配布方法の具体的な問題点＞＞＞
§１で述べたとおり、Android端末用のアプリケーションプログラムは、図１に示すように、配布用ファイル（ＡＰＫファイル）２０の形式で広く配布されることになるので、一般ユーザＵ１，Ｕ２，Ｕ３は、インターネット等を介してこれをダウンロードすることにより容易に入手することができる。これは、悪意をもったクラッカーＸも、配布用ファイル２０を容易に入手できることを意味する。したがって、クラッカーＸが、入手した配布用ファイル２０に対して改竄を施し、これをインターネット等を介して再配布することも容易である。

しかも、ＡＰＫファイルの仕様は広く公開されているため、クラッカーＸの立場からすると、改竄も容易であり、かつ、再配布も容易であるという、不正行為が行いやすい環境が整っていることになる。特に、アプリケーションプログラム１０を構成する各要素のうち、リソースデータ１２や補助ファイル１４に対する改竄は非常に容易である。

たとえば、リソースデータ１２を構成する画像データファイルや文字列データファイルは、JPEG形式，GIF形式，BMP形式，PNG形式，XML形式など、ごく一般的なファイルフォーマットで記述されたデータであるため、ファイルの内容を書き換えたり、ファイルを入れ替えるだけで改竄が可能になる。このため、本来の画像を猥褻な画像に入れ替えたり、本来の文字列を不適切な文字列に入れ替えたりする改竄は容易に行い得る。また、「YESボタン」の画像と「NOボタン」の画像とを入れ替えるような改竄が行われると、一見したところ改竄の事実に気づかないが、ユーザの回答入力画面における「YES」と「NO」の表示だけが入れ替わってしまうという重大な支障が生じることになる。

一方、補助ファイル１４（マニフェストファイル）も、XML形式で記載された判読容易な文字列データによって構成されているため、改竄の対象になりやすい。具体的には、補助ファイル１４内には、当該アプリケーションプログラムが、インターネット接続を行うか否か、GPS情報を参照するか否か、電話機能を利用するか否か、といったパーミッション情報が含まれており、この情報が改竄されると、ユーザが許可していない動作が実行されることになる。たとえば、インターネット接続および電話機能の利用を「行う」旨のパーミッション情報をもつアプリケーションプログラムについて、更に、GPS情報の参照を「行う」旨のパーミッション情報を追加するような改竄が行われると、本来のパーミッション情報では許可していない「GPS情報の参照」という動作が実行されることになり、GPS情報が外部に流出するといった被害が発生するおそれがある。

このような改竄による被害は、ユーザだけではなく、コンテンツプロバイダにまで及ぶ。たとえば、プログラム提供者Ａが配布している「PatGame.apk」なるアプリケーションプログラムの評判を聞いたユーザＵが、当該プログラムの正規の配布用ファイルの代わりに、改竄されたファイルをダウンロードして実行してしまった場合を考えてみよう。クラッカーＸは、通常、元のファイルと同じファイル名で改竄したファイルを再配布するので、「PatGame.apk」というファイル名を確認しただけでは、それが純正のファイルであるのか、改竄されたファイルであるのかを識別することができない。

この場合、たとえば、プログラム提供者Ａの本来のロゴ画像が猥褻な画像に入れ替わっているような顕著な改竄が行われたケースであれば、ユーザは、実行しているアプリケーションプログラムが改竄されたものであると認識することができるであろう。しかしながら、ユーザが改竄に気づかないケースでは、当該アプリケーションプログラムの不具合の責任は、プログラム提供者Ａにあると考えるであろう。このような不当な評価がインターネット等を介して流布すると、プログラム提供者Ａは風評被害を受けることになる。

もちろん、Androidの仕様によれば、§１で述べたとおり、配布用ファイル２０には、アプリケーションパッケージ２１とともに署名情報２２が付加されており、Android端末では、図３に示す手順に従って、アプリケーションパッケージ２１に対する署名情報２２の正当性が確認される。したがって、クラッカーＸが、リソースデータ１２内の画像ファイルや文字列ファイルを別なファイルに差し替えたり、補助ファイル１４内のパーミッション情報を書き替えたりしただけでは、図３に示す確認処理において不一致が生じ、改竄の事実を検知することができる。

すなわち、図３に示す例において、クラッカーＸがアプリケーションパッケージ２１の内容を書き替えた場合、署名対象データＤがＤ′に変わってしまうため、得られるハッシュ値Ｈ２も変わってしまうことになる。その結果、署名対象データＤに基づいて作成された署名値Ｓ（Ａ）を復号して得られるハッシュ値Ｈ１と不一致が生じることになり、改竄の事実が検知される。

このように、§１で述べた従来の配布方法では、アプリケーションパッケージ２１のみに対して行われた改竄については検知が可能である。しかしながら、署名情報２２に対する改竄まで行われてしまうと、これを検知することはできない。以下にその理由を説明する。

ここでは、図１に示すように、プログラム提供者Ａが配布した正規の配布用ファイル２０を、クラッカーＸが入手したものとしよう。図４は、このようにして入手した正規の配布用ファイル２０に対して、クラッカーＸが試みる改竄プロセスを示すブロック図である。クラッカーＸは、まず、入手した配布用ファイル２０に含まれるアプリケーションパッケージ２１に対して伸張処理を実行し、元のアプリケーションプログラム１０を復元する。パッケージ化処理は、基本的にはファイルの圧縮処理であるため、この圧縮処理に応じた伸張処理を行うことにより、元のアプリケーションプログラム１０を容易に復元することができる。§１で述べたとおり、アプリケーションプログラム１０は、プログラム本体部１１，リソースデータ１２，サブルーチン群１３，補助ファイル１４という要素によって構成されている（この他にもいくつかの要素が付加される場合もある）。

クラッカーＸは、これらの各要素に対して改竄を施すことになるが、前述したとおり、リソースデータ１２や補助ファイル１４に対する改竄は非常に容易であり、データファイルの入れ替えや、テキストデータの書き替えという簡単な作業によって行うことができる。そこで、ここでは、クラッカーＸが、図示のとおり、リソースデータ１２をリソースデータ１２Ｘに改竄し、補助ファイル１４を補助ファイル１４Ｘに改竄したものとしよう。プログラム本体部１１およびサブルーチン群１３に対する改竄は行われていないが、改竄されたリソースデータ１２Ｘおよび改竄された補助ファイル１４Ｘを含むアプリケーションプログラム１０Ｘは、もはや正常動作を行わないものになっている（もちろん、クラッカーＸが、プログラミングに対して十分な知識を有していた場合は、プログラム本体部１１やサブルーチン群１３に対する改竄も可能である）。

続いて、クラッカーＸは、アプリケーションプログラム１０Ｘに対する再パッケージ化処理を行い、改竄されたアプリケーションパッケージ２１Ｘを生成する。こうして生成したアプリケーションパッケージ２１Ｘを、正規の配布用ファイル２０内の正規のアプリケーションパッケージ２１とすり替えただけでは、Android端末で行われる通常の改竄検知処理によって改竄の事実が検知されることになる。すなわち、Ａの署名情報２２の正当性を確認する処理で不一致が生じることになる。

ところが、クラッカーＸは、改竄されたアプリケーションパッケージ２１Ｘを署名対象データＤ′として、自分自身を署名者とする署名を行うことにより、Ｘの署名情報２２Ｘを作成することができる。具体的には、クラッカーＸの第１の鍵Ｋ（ｘ１）を用いて、署名対象データＤ′（すなわち、改竄されたアプリケーションパッケージ２１Ｘ）に対する署名値Ｓ（Ｘ）を作成する処理を行い、作成された署名値Ｓ（Ｘ）と、クラッカーＸの第２の鍵Ｋ（ｘ２）とを含むＸの署名情報２２Ｘを作成すればよい。

プログラム提供者Ａが、第１の鍵Ｋ（ａ１）を秘密鍵として管理していれば、クラッカーＸは、Ａの第１の鍵Ｋ（ａ１）を入手することができないので、クラッカーＸが、改竄された署名対象データＤ′に対して、署名者Ａとして署名を行うことはできない。しかしながら、クラッカーＸは、自分自身の第１の鍵Ｋ（ｘ１）を用いて、署名者Ｘとして署名を行うことは可能であり、そのようにして得られた署名値Ｓ（Ｘ）に、自分自身の第２の鍵Ｋ（ｘ２）を付加して、Ｘの署名情報２２Ｘを作成することはできる。こうして作成された署名情報２２Ｘは、いわばクラッカーＸによる再署名というべき情報であり、改竄されたアプリケーションパッケージ２１Ｘに対して正当性を有している。

こうして、クラッカーＸが、改竄されたアプリケーションパッケージ２１ＸにＸの署名情報２２Ｘを付加すれば、改竄された配布用ファイル２０Ｘを得ることができる。そして、この配布用ファイル２０Ｘを、「PatGame.apk」なるファイル名をもったＡＰＫファイルとして再配布すれば、一見したところ、正規のＡＰＫファイルと区別できない改竄されたファイルを流布させることができる。

Androidの仕様は広く公開されており、ＡＰＫファイルの作成作業を支援するための様々なツールも広く普及している。たとえば、アプリケーションプログラム１０をパッケージ化してアプリケーションパッケージ２１を作成するツール、アプリケーションパッケージ２１に任意の者の署名情報２２を付加してＡＰＫファイル２０を作成するツール、ＡＰＫファイル２０内のアプリケーションパッケージ２１を伸張して元のアプリケーションプログラム１０を復元するツールなどは、インターネット上の様々なサイトから入手可能であり、クラッカーＸは、これらのツールを利用して、図４に示す改竄プロセスを実行し、改竄されたＡＰＫファイル２０Ｘを作成することができる。

このように、アプリケーションパッケージ２１に対する改竄とともに、署名情報２２に対する改竄が行われた場合、図３に示す従来の改竄検知方法では、改竄の検知を行うことができない。すなわち、図４に示す配布用ファイル２０Ｘにおいて、Ｘの署名情報２２Ｘは、アプリケーションパッケージ２１Ｘを署名対象データＤ′としてクラッカーＸが署名を行うことによって得られた情報であるから、図３に示す従来の改竄検知方法では何ら支障なく一致確認が得られることになる。したがって、一般ユーザＵが、改竄された配布用ファイル２０ＸをAndroid端末にダウンロードして実行すれば、改竄されたアプリケーションプログラム１０Ｘは、正規のアプリケーションプログラムとして実行されてしまうことになる。

このように、改竄されたアプリケーションパッケージ２１に対してクラッカーＸによる再署名が行われ、この再署名によって得られた署名情報による差し替えが行われてしまうと、署名情報の正当性は確保されてしまうため、Android端末の一般的な改竄検知機能によっては改竄の検知を行うことができない。これは、Androidの仕様が、そもそも署名者の身元まで確認した改竄検知を行うようになっていないためである。すなわち、Android端末は、正規のコンテンツプロバイダであるプログラム提供者ＡとクラッカーＸとを区別することはできないので、署名者がＡであろうがＸであろうが、署名対象データと署名情報との間に整合性が確認できれば、改竄なしと判断せざるを得ない。

もちろん、認証サーバなどへ問い合わせを行えば、署名者の身元確認を行うことができる。官公庁への電子申請や電子商取引などを行う場合、通常、認証サーバなどへ問い合わせを行い、署名者の身元確認を行う処理が行われる。しかしながら、Android端末の場合、少なくともアプリケーションプログラムを実行する際の改竄判定処理では、署名者の身元確認まで行う仕様にはなっていない。これは、Android端末がオフライン状態（外部の認証サーバへの問い合わせができない状態）であっても、アプリケーションプログラムを支障なく実行できるようにするためだと思われる。

このように、署名情報の一致確認は行うものの、署名者の身元確認までは行わない端末装置に対してアプリケーションプログラムを配信する場合に、署名情報に対する改竄までが行われてしまうと、有効な改竄検知を行うことができない。本発明は、このような問題に対処するための新たなアプリケーションプログラムの効果的な改竄検知方法を提供するものである。

＜＜＜ §３．本発明の基本的な実施形態に係る改竄検知方法＞＞＞
ここに示す基本的な実施形態の原理は、図１に示す配布用ファイル２０において、配布前に、Ａの署名情報２２についての何らかのマーキングを行っておき、実行時には、このマーキングを利用して、Ａの署名情報２２に対する改竄の有無を検知する、というものである。クラッカーＸが、図４に示す方法で、Ａの署名情報２２をＸの署名情報２２Ｘにすり替えたとしても、Ａの署名情報２２に関する何らかの痕跡をマーキングしておけば、署名情報のすり替えを検知することができる。

もっとも、このマーキングの内容がクラッカーＸに察知されてしまうと、マーキングを含めた改竄が行われてしまうことになる。そこで、本発明では、マーキング対象を特定の方法で秘匿化するようにし、クラッカーＸにマーキングの内容が察知されないようにするとともに、秘匿化された情報に基づいてマーキングの内容の正当性を確認する改竄チェックルーチンＦを含む改竄チェックプログラム３０を別途用意する。以下、その基本原理を詳細に説明する。

図５は、本発明の基本的な実施形態に係るアプリケーションプログラムの改竄検知方法の基本原理を示すブロック図である。この方法では、プログラム提供者Ａは、§１で述べた従来方法と同様に、アプリケーションプログラム１０をパッケージ化することによって得られたアプリケーションパッケージ２１を署名対象データＤとして、プログラム提供者Ａの第１の鍵Ｋ（ａ１）を用いた暗号化を利用した電子署名処理を行って署名値Ｓ（Ａ）を生成し、この署名値Ｓ（Ａ）とプログラム提供者Ａの第２の鍵Ｋ（ａ２）とを含む署名情報２２を作成する。

一方、このアプリケーションプログラム１０とは別個に、図５の右下に示すように、改竄チェックプログラム３０を用意する。ここに示す基本的な実施形態の場合、この改竄チェックプログラム３０は、アプリケーションプログラム１０と同様に、Android端末で実行可能な１つの独立したアプリケーションプログラムであり、図示のとおり、改竄チェックルーチンＦと第１の特定鍵Ｋ（ｓ１）とを含んでいる。ここで、改竄チェックルーチンＦは、Ａの署名情報２２が改竄されているかどうかを確認するためのプログラムであり、第１の特定鍵Ｋ（ｓ１）を用いることにより、Ａの署名情報２２が改竄されているか否かをチェックする機能を有する。具体的なチェックアルゴリズムについては後述する。

この改竄チェックプログラム３０による改竄チェックを可能にするために、ここで述べる基本的な実施形態では、Ａの署名情報２２を秘匿化対象データＣとして抽出し（図５では、秘匿化対象データＣを太線枠で示す）、この秘匿化対象データＣに対して第２の特定鍵Ｋ（ｓ２）を用いた秘匿化処理を施して秘匿情報２３を作成する。秘匿化処理の具体的な方法は、§７で実例を挙げて説明するが、第２の特定鍵Ｋ（ｓ２）を用いた何らかの演算処理によって、元の秘匿化対象データＣに対して一義的に秘匿情報２３を決定することができる処理であって、この第２の特定鍵Ｋ（ｓ２）に対して特別な関係をもった第１の特定鍵Ｋ（ｓ１）（すなわち、改竄チェックプログラム３０に内蔵されている鍵）を用いることによってのみ、秘匿化対象データＣに対する秘匿情報２３の正当性が確認できる、という条件を満たす処理であれば、どのような処理を秘匿化処理として採用してもかまわない（後述するように、第１の特定鍵Ｋ（ｓ１）および第２の特定鍵Ｋ（ｓ２）として、同一の共通特定鍵Ｋ（ｓ０）を用いることも可能である）。

こうして、秘匿情報２３が作成できたら、プログラム提供者Ａは、アプリケーションパッケージ２１と、Ａの署名情報２２と、秘匿情報２３と、を含む配布用ファイル２０Ａを作成し、これをＡＰＫファイルとして配布すればよい。ここで、Ａの署名情報２２は、アプリケーションパッケージ２１が改竄されていないことを確認するために用いられるプログラム提供者Ａによる電子署名であり、秘匿情報２３は、このＡの署名情報２２が改竄されていないことを確認するために用いられるマーキング情報ということになる。Android端末では、Ａの署名情報２２の正当性を確認するとともに、秘匿情報２３の正当性を確認することにより、アプリケーションパッケージ２１に対する改竄のみならず、Ａの署名情報２２に対する改竄を検知することができる。

結局、本発明に係るアプリケーションプログラムの改竄検知方法を実行するためには、ユーザＵに対して、配布用ファイル２０Ａ（アプリケーションプログラム１０）を配布するとともに、改竄チェックプログラム３０を配布する必要がある。上述したとおり、改竄チェックプログラム３０も、アプリケーションプログラムの一種であるので、配布時には、図１に示すように、パッケージ化を行い、更に、Ａの署名情報２２を付加して配布用ファイル２０（ＡＰＫファイル）の形式にして配布することになる。図では、繁雑になるのを避けるため、改竄チェックプログラム３０のパッケージ化等の処理は図示を省略している。

ただ、この改竄チェックプログラム３０に対しては、秘匿情報２３を付加する処理は行われないので、この改竄チェックプログラム３０自身については、本発明に係る改竄検知方法を適用した改善検知を行うことはできない。このため、実用上は、この改竄チェックプログラム３０をユーザに配布する際には、クラッカーＸによる改竄が行われないような特別な配布ルートを経由して配布するようにするのが好ましい。具体的には、たとえば、特別な認証手続を必要とする特定のサイトからダウンロードさせたり、プログラムを格納した媒体を店頭で配布したりする方法を採るのが好ましい。また、改竄チェックルーチンＦ自身は、クラッカーＸの手に渡っても容易には解析できないような耐タンパ化処理を施しておくのが好ましい。

もちろん、Android端末を販売する際に、この改竄チェックプログラム３０をプリインストールソフトとして予め組み込んでおくようにすれば、改竄チェックプログラム３０を配布する段階で改竄を受ける危険を回避することができる。また、後に変形例として述べるように、改竄チェックプログラム３０をAndroid端末のＯＳプログラムに組み込み、ＯＳ（AndroidＯＳ）の一機能として改竄チェック処理を実行できるようにすれば、改竄チェックプログラム３０を単独で配布する必要はない。

なお、改竄チェックプログラム３０は、内蔵されている第１の特定鍵Ｋ（ｓ１）に対応した第２の特定鍵Ｋ（ｓ２）を用いて同一のアルゴリズムに基づく秘匿化処理が行われたアプリケーションプログラムであれば、どのようなアプリケーションプログラムに対しても改竄チェックを行うことができるので、１つの改竄チェックプログラム３０によって複数のアプリケーションプログラムに対する改竄チェックを行うことが可能である。たとえば、プログラム提供者Ａが複数のアプリケーションプログラム１０−１，１０−２，１０−３，... を提供している場合、いずれのアプリケーションプログラムについても、同一の第２の特定鍵Ｋ（ｓ２）を用いた同一のアルゴリズムに基づく秘匿化処理を行えば、当該第２の特定鍵Ｋ（ｓ２）に対応した第１の特定鍵Ｋ（ｓ１）を内蔵した改竄チェックプログラム３０によって、これら複数のアプリケーションプログラム１０−１，１０−２，１０−３，... に対する改竄チェックを行うことができる。

もちろん、プログラム提供者Ａとプログラム提供者Ｂとが、それぞれ異なる第２の特定鍵Ｋ（ｓ２ａ），Ｋ（ｓ２ｂ）を用いて秘匿化処理を行っていた場合には、提供者Ａから提供されたアプリケーションプログラムについては、第１の特定鍵（ｓ１ａ）を内蔵した改竄チェックプログラム３０Ａを用いた改竄チェックを行い、提供者Ｂから提供されたアプリケーションプログラムについては、第１の特定鍵（ｓ１ｂ）を内蔵した改竄チェックプログラム３０Ｂを用いた改竄チェックを行う必要がある。

したがって、実用上は、とりまとめ役としてのプログラム保証者Ｇが、個々のプログラム提供者Ａ，Ｂ，Ｃ，...に、同一の第２の特定鍵Ｋ（ｇ２）を提供し、このプログラム保証者Ｇが、上記第２の特定鍵Ｋ（ｇ２）に対応した第１の特定鍵Ｋ（ｇ１）を内蔵した改竄チェックプログラム３０Ｇを用意し、これを配布するようにするのが好ましい。個々のプログラム提供者Ａ，Ｂ，Ｃ，...が、それぞれプログラム保証者Ｇから提供された同一の第２の特定鍵Ｋ（ｇ２）を用いて、予め定められた同一のアルゴリズムに基づく秘匿化処理を行うようにすれば、いずれの提供者から提供されたアプリケーションプログラムに対しても、プログラム保証者Ｇが配布した改竄チェックプログラム３０Ｇによって改竄チェックが可能になる。

続いて、改竄チェックプログラム３０がインストールされたAndroid端末において、新たにダウンロードしたアプリケーションプログラム１０についての改竄チェックを行う処理の基本原理を説明する。図６は、図５に示す配布用ファイル２０Ａについて、署名情報２２の正当性および秘匿情報２３の正当性を確認する処理を示すブロック図である。図の左側に示す改竄チェックプログラム３０は、Android端末に予めインストールされているプログラムであり、この例の場合、「AppCheck.apk」なるファイル名が付されたアプリケーションプログラムである。

実際には、この改竄チェックプログラム３０も、パッケージ化された後、ＡＰＫファイルの形式でインストールされており、アプリケーションパッケージに署名情報が付加されたデータファイルを構成することになるが、ここでは、図が繁雑になるのを避けるため、アプリケーションパッケージの部分のみを図示することにする。前述したとおり、このアプリケーションパッケージ内には、改竄チェックルーチンＦと第１の特定鍵Ｋ（ｓ１）が含まれている。また、ここでは便宜上、このＡＰＫファイル全体を改竄チェックプログラム３０と呼ぶことにする。

ユーザＵが、Android端末に配布用ファイル２０Ａ（この例では、「PatGame.apk」なるファイル名をもったＡＰＫファイル）をインストールし、これを実行しようとすると、アプリケーションプログラム１０の実行前に、AndroidＯＳの基本機能により、Ａの署名情報２２の正当性を確認する処理が実行される。すなわち、§１でも述べたように、まず、署名情報２２から署名値Ｓ（Ａ）およびＡの第２の鍵Ｋ（ａ２）を抽出し、署名値Ｓ（Ａ）に対してＡの第２の鍵Ｋ（ａ２）を用いた復号処理を行うことにより、ハッシュ値Ｈ１を得る処理が行われる。続いて、アプリケーションパッケージ２１（署名対象データＤ）に対して、ハッシュ関数ＨＡＳＨを作用させた不可逆変換を行い、ハッシュ値Ｈ２を求める処理を行う。そして、ハッシュ値Ｈ１とハッシュ値Ｈ２とが一致するか否かを確認する処理を行う。ここでは、このような確認処理のプロセスを第１の確認段階と呼ぶことにする。この第１の確認段階では、アプリケーションパッケージ２１に対する署名情報２２の正当性を確認する処理が行われることになる。

AndroidＯＳは、この第１の確認段階によって、署名情報２２の正当性が確認できた場合、アプリケーションパッケージ２１は改竄されていないものと判断し、そこに含まれているアプリケーションプログラム１０を実行する。一方、署名情報２２の正当性が確認できなかった場合には、何らかの改竄が行われているものと判断し、アプリケーションプログラム１０の実行は中止される。したがって、クラッカーＸによって、アプリケーションパッケージ２１に対する改竄のみが行われていた場合には、このAndroidＯＳに備わっている第１の確認段階の処理機能によって改竄検知がなされ、改竄されたアプリケーションプログラムの実行は中止される。しかしながら、図４に示す例のように、クラッカーＸによる再署名が行われ、署名情報に対する改竄まで行われていた場合、この第１の確認段階では改竄の検知を行うことができない。

本発明に係る改竄検知方法では、ユーザＵは、改竄チェックプログラム３０を実行することにより、Ａの署名情報に対する正当性の確認を行うことができるようになる。前述したとおり、改竄チェックプログラム３０内の改竄チェックルーチンＦは、内蔵している第１の特定鍵Ｋ（ｓ１）を利用して、秘匿化対象データＣ（この例の場合は、Ａの署名情報２２）に対する秘匿情報２３の正当性を確認する処理を行う。ここでは、このような確認処理のプロセスを第２の確認段階と呼ぶことにする。前述したとおり、秘匿情報２３は、秘匿化対象データＣに対して第２の特定鍵Ｋ（ｓ２）を用いた秘匿化処理を施して得られた情報であり、秘匿化対象データＣ（Ａの署名情報２２）に対する秘匿情報２３の正当性は、第１の特定鍵Ｋ（ｓ１）を用いて確認することができる。正当性が確認できない場合、改竄チェックプログラム３０は、配布用ファイル２０Ａに対する改竄が行われているものと判断する。

かくして、Android端末では、第１の確認段階において、アプリケーションパッケージ２１に対する署名情報２２の正当性が確認され、かつ、第２の確認段階において、署名情報２２に対する秘匿情報２３の正当性が確認されることになり、両方の確認段階を実行すれば、アプリケーションパッケージ２１に対する改竄と、署名情報２２に対する改竄との双方を検知することができる。

＜＜＜ §４．本発明の基本的な実施形態に係る改竄検知の手順＞＞＞
続いて、本発明に係る改竄検知方法の基本手順を、図７の流れ図を参照しながら説明する。この基本手順は、改竄チェックの準備を行う準備プロセスと、アプリケーションプログラムを配布する配布プロセスと、配布されたアプリケーションプログラムに対する改竄チェックを行う改竄チェックプロセスと、によって構成されるアプリケーションプログラムの改竄検知方法の手順ということになる。図示のとおり、準備プロセスでは、ステップＳ０の段階が実行され、配布プロセスでは、ステップＳ１〜Ｓ５の各段階が実行され、改竄チェックプロセスでは、ステップＳ６〜Ｓ１５の各段階が実行される。以下、これら各ステップの内容を順に説明する。

ここでは、便宜上、配布プロセス（ステップＳ１〜Ｓ５）は、プログラム提供者Ａが利用するコンピュータによって実行され、準備プロセス（ステップＳ０）および改竄チェックプロセス（ステップＳ６〜Ｓ１５）は、ユーザＵが利用するアプリケーション実行用コンピュータ（スマートフォンなどのAndroid端末）によって実行されるものとして以下の説明を行うことにする。なお、配布プロセスを構成するステップＳ１〜Ｓ５は、必ずしも同一のコンピュータで実行する必要はないが、準備プロセスおよび改竄チェックプロセスを構成するステップＳ０，Ｓ６〜Ｓ１５は、ユーザＵが利用する同一のアプリケーション実行用コンピュータにおいて実行されることになる。

まず、準備プロセスを構成するステップＳ０の改竄チェックプログラム準備段階では、アプリケーションプログラムを実行するためのアプリケーション実行用コンピュータが、第１の特定鍵Ｋ（ｓ１）を用いて改竄チェックを行う改竄チェックルーチンＦを含む改竄チェックプログラム３０をインストールする処理が行われる。前述したように、実用上は、改竄チェックプログラム３０として、プログラム保証者Ｇが配布した改竄チェックプログラム３０Ｇをインストールしておけば、様々なプログラム提供者Ａ，Ｂ，Ｃ，...が配布するアプリケーションプログラムに対する改竄チェックが可能になる。この場合、改竄チェックプログラム準備段階Ｓ０は、１台のアプリケーション実行用コンピュータ（Android端末）に対して１回だけ行えば十分である。

なお、ここでは、改竄チェックプログラム３０が１つのアプリケーションプログラムとして配布され、ユーザＵの操作に基づいてアプリケーション実行用コンピュータ（Android端末）にインストールされる基本的な実施形態を述べるが、改竄チェックプログラム３０をアプリケーション実行用コンピュータ（Android端末）にプリインストールしておく実施形態を採る場合や、アプリケーション実行用コンピュータのＯＳ（AndroidＯＳ）の機能に組み込む実施形態を採る場合は、ステップＳ０の改竄チェックプログラム準備段階は、当該アプリケーション実行用コンピュータ（Android端末）の出荷前に、当該端末の提供者の元で実行される処理ということになる。

続いて、配布プロセスを構成するステップＳ１〜Ｓ５について説明する。この配布プロセスは、配布対象となるアプリケーションプログラムのそれぞれについて実行される。まず、ステップＳ１のパッケージ化段階では、図５に示すように、配布対象となるアプリケーションプログラム１０に対して、少なくとも圧縮処理を含むパッケージ化処理を施し、アプリケーションパッケージ２１を作成する処理が行われる。

§１で述べたように、アプリケーションプログラムをAndroid端末に配布する場合は、その仕様により、アプリケーションプログラム１０には、プログラム本体部１１と、このプログラム本体部１１から呼び出されるサブルーチン群１３と、画像および文字列を含むリソースデータ１２と、ＸＭＬ形式のデータからなる補助ファイル１４（マニフェストファイル）とが含まれることになり、ステップＳ１のパッケージ化段階では、ＺＩＰ方式の圧縮処理を含むパッケージ化処理が実行されることになる。

続くステップＳ２の署名情報作成段階では、図５に示すように、ステップＳ１で作成されたアプリケーションパッケージ２１を署名対象データＤとして、プログラム提供者Ａの第１の鍵Ｋ（ａ１）を用いた暗号化を利用した電子署名処理を行って署名値Ｓ（Ａ）を生成し、この署名値Ｓ（Ａ）とプログラム提供者Ａの第２の鍵Ｋ（ａ２）とを含むＡの署名情報２２を作成する処理が実行される。ここで、プログラム提供者Ａの第１の鍵Ｋ（ａ１）および第２の鍵Ｋ（ａ２）としては、公開鍵暗号方式に利用される一対の鍵、すなわち、一方の鍵を用いて暗号化したデータを他方の鍵を用いて復号できる性質をもった一対の鍵が用いられる。

次に、ステップＳ３の秘匿情報作成段階では、図５に示すように、Ａの署名情報２２を秘匿化対象データＣとして抽出し、抽出した秘匿化対象データＣに対して第２の特定鍵Ｋ（ｓ２）を用いた秘匿化処理を施して秘匿情報２３を作成する処理が実行される。ここで、秘匿化処理に利用される第２の特定鍵Ｋ（ｓ２）は、改竄チェックプログラム３０に含まれている第１の特定鍵Ｋ（ｓ１）に対応する鍵である。より具体的には、第１の特定鍵Ｋ（ｓ１）および第２の特定鍵Ｋ（ｓ２）としては、一方の鍵を用いて秘匿化処理を施したデータの正当性を他方の鍵を用いて確認できる性質をもった一対の鍵が用いられる（後述するように、両者は同一の共通鍵でもかまわない）。

このステップＳ３で実行する秘匿化処理としては、前述したとおり、第２の特定鍵Ｋ（ｓ２）を用いた何らかの演算処理によって、元の秘匿化対象データＣに対して一義的に秘匿情報２３を決定することができる処理であって、第１の特定鍵Ｋ（ｓ１）を用いることによってのみ、秘匿化対象データＣに対する秘匿情報２３の正当性が確認できる、という条件を満たす処理であれば、どのような処理であってもかまわない。秘匿化処理の具体例は§７で例示する。

一方、ステップＳ４の配布用ファイル作成段階では、図５に示すように、ステップＳ１で作成されたアプリケーションパッケージ２１と、ステップＳ２で作成された署名情報２２と、ステップＳ３で作成された秘匿情報２３と、をまとめることにより、配布用ファイル２０Ａが作成される。Android端末に配布する場合は、この配布用ファイル作成段階において、ＡＰＫ形式のフォーマットをもった配布用ファイル２０Ａ（拡張子.apkが付されたＡＰＫファイル）が作成されることになる。

なお、ＡＰＫファイルの実体は、ＺＩＰ方式の圧縮フォーマットで圧縮されたファイルであるので、ステップＳ４の配布用ファイル作成段階でＡＰＫファイルを作成する場合は、ＺＩＰ方式の圧縮フォーマットにおけるコメント領域に秘匿情報２３を記録することができる。このコメント領域は、本来、ＡＰＫファイルの作成者が、任意のコメント文を記載できるようにするために設けられた領域であるから、秘匿情報２３を構成するデータをコメント文の代わりに記録しても、何ら支障は生じない。別言すれば、コメント領域に秘匿情報２３を記録した本発明に係る配布用ファイル２０Ａは、Androidの仕様に合致したＡＰＫファイルとしての条件を満たしており、そのままAndroid端末に配布しても何ら支障はなく、AndroidＯＳによって、仕様通りのＡＰＫファイルとして取り扱われることになる。

配布プロセスの最後には、ステップＳ５のファイル出力段階が行われる。この段階では、ステップＳ４で作成された配布用ファイル２０Ａ（ここに示す例の場合、Androidの仕様通りのＡＰＫファイル）が配布のために出力されることになる。たとえば、配布用のＷｅｂサーバなどに出力すれば、配布用ファイル２０Ａはインタネットを介して一般ユーザへ配布されることになり、光学的記録媒体やＩＣメモリ等の物理的記録媒体に記録して出力すれば、配布用ファイル２０Ａは、このような物理的記録媒体に格納された状態で配布されることになる。

続いて、配布用ファイル２０Ａの配布を受けたアプリケーション実行用コンピュータ側で実行される改竄チェックプロセスについて説明する。まず、ステップＳ６のファイル入力段階では、ユーザＵが利用するアプリケーション実行用コンピュータに、上述した配布プロセスによって配布された配布用ファイル２０Ａが入力される。たとえば、ユーザＵがAndroid端末を利用している場合、ＡＰＫファイルの配布サイトからインターネット経由で配布用ファイル２０Ａをダウンロードする指示を与えることにより、当該Android端末に配布用ファイル２０Ａが取り込まれることになり、更に、ユーザＵの了承を得て、配布用ファイル２０Ａのインストールが行われることになる。Android端末の場合、このような処理は、ＯＳプログラムの基本機能によって実行される。

前述したとおり、このアプリケーション実行用コンピュータには、ステップＳ０の改竄チェックプログラム準備段階において、既に改竄チェックプログラム３０がインストールされている。すなわち、当該コンピュータには、ステップＳ６で入力したアプリケーションプログラムの他に、改竄チェックプログラム３０もインストールされていることになる。

図７の流れ図に示すステップＳ７以降の各段階は、ステップＳ６で入力したアプリケーションプログラムに対して改竄チェックを行う処理であるが、ステップＳ８〜S１１は、署名情報の正当性を確認するための第１の確認段階に関する処理であり、ステップＳ１２〜Ｓ１５は、秘匿情報の正当性を確認するための第２の確認段階に関する処理である。ここに示す実施例の場合、アプリケーション実行用コンピュータとしてAndroid端末を用いているため、第１の確認段階に関する処理はＯＳプログラム（AndroidＯＳ）によって実行される。一方、第２の確認段階に関する処理は、ステップＳ０でインストールした改竄チェックプログラム３０によって実行される。

ステップＳ７では、第１の確認段階に関する処理もしくは第２の確認段階に関する処理のいずれが選択されたかが判断される（このステップＳ７の判断自体は、ＯＳプログラムによって行われる）。そして、いずれかの処理が選択された場合、ステップＳ８もしくはＳ１２へと分岐する。すなわち、第１の確認段階に関する処理が選択された場合は、ステップＳ７からステップＳ８へと分岐し、第２の確認段階に関する処理が選択された場合は、ステップＳ７からステップＳ１２へと分岐する。

第１の確認段階と第２の確認段階とは、並列的な関係にあり、どちらを先に実行してもかまわないが、ここでは説明の便宜上、まず、第１の確認段階に関する処理が選択され、ステップＳ７からステップＳ８へと分岐した場合を説明しよう。ここで述べるAndroid端末を用いた実施例の場合、ステップＳ６で入力したアプリケーションプログラム（改竄チェックの対象となるプログラム）に対する起動指示が与えられた場合に、第１の確認段階に関する処理が選択されたものと判断され、ステップＳ７からステップＳ８への分岐が生じることになり、以下、ステップＳ８〜Ｓ１１に示す第１の確認段階に関する処理が実行される。より具体的には、Android端末を用いた実施例の場合、AndroidＯＳが当該アプリケーションプログラムを起動するための起動処理の一環として、ステップＳ８〜Ｓ１１の処理が実行されることになる。

なお、アプリケーション実行用コンピュータの中には、第１のアプリケーションプログラムが、第２のアプリケーションプログラムを起動できるような仕様を採用していたり、外部からアクセスしてきた何らかのサービスに基づいてアプリケーションプログラムが起動するような仕様を採用するものも少なくない（Android端末もそのような仕様を採用している）。したがって、図７におけるステップＳ７からステップＳ８への移行は、必ずしもユーザＵ自身が当該アプリケーションプログラムに対して直接的な起動指示を与えた場合に限定されるものではなく、他のアプリケーションからの起動指示や外部サービスからの起動指示に起因しても生じることになる。

まず、ステップＳ８では、図６に示す第１の確認段階が行われる。この第１の確認段階では、前述したとおり、アプリケーションパッケージ２１に対する署名情報２２の正当性を確認する処理が行われる。すなわち、ステップＳ６で入力した配布用ファイル２０Ａについて、Ａの署名情報２２に含まれているプログラム提供者Ａの第２の鍵Ｋ（ａ２）を用いた復号を利用した署名確認処理を行って、アプリケーションパッケージ２１に対する署名情報２２の正当性が確認される。

具体的には、図６を用いて説明したように、署名情報２２から署名値Ｓ（Ａ）およびＡの第２の鍵Ｋ（ａ２）を抽出し、署名値Ｓ（Ａ）に対してＡの第２の鍵Ｋ（ａ２）を用いた復号処理を行うことによりハッシュ値Ｈ１を求め、アプリケーションパッケージ２１（署名対象データＤ）に対して、ハッシュ関数ＨＡＳＨを作用させた不可逆変換を行いハッシュ値Ｈ２を求め、ハッシュ値Ｈ１とハッシュ値Ｈ２との一致確認が行われることになる。

ステップＳ８の第１の確認段階において否定的な結果が得られた場合、すなわち、アプリケーションパッケージ２１に対する署名情報２２の正当性が確認されなかった場合には、「改竄あり」との判定がなされ、ステップＳ９を経てステップＳ１０へと進み、当該アプリケーションの起動は中止される。具体的には、ＯＳプログラムによって、たとえば「このアプリケーションプログラムは改竄されているため、実行できません」のような警告メッセージを提示し、起動が中止されたことをユーザＵに報知する処理を行えばよい。

これに対して、ステップＳ８の第１の確認段階において肯定的な結果が得られた場合、すなわち、アプリケーションパッケージ２１に対する署名情報２２の正当性が確認された場合には、ステップＳ９を経てステップＳ１１へと進み、アプリケーション起動段階が実行される。すなわち、ＯＳプログラムによって、当該アプリケーションプログラムの起動が正常に行われることになり、ユーザＵは、起動したアプリケーションプログラムを利用することができる。

Android端末を用いた実施例の場合、ステップＳ７〜Ｓ１１の処理は、すべてＯＳプログラム（AndroidＯＳ）の基本機能によって実行され、上述した各処理は、いずれもAndroidＯＳの標準仕様に基づく処理である。これに対して、ステップＳ１２〜Ｓ１５の処理は、アプリケーションプログラムの１つとしてインストールされた改竄チェックプログラム３０によって実行される。図７の改竄チェックプロセスを構成する各ステップＳ６〜Ｓ１５に付記した括弧書きの内容は、個々のステップの実行主体が、ＯＳプログラムであるのか、改竄チェックプログラムであるのかを示すものである（後に変形例を示すように、本発明は、これらの実行主体に限定されるものではなく、たとえば、§９に示す実施例では、全ステップがＯＳプログラムにより実行される）。

ステップＳ７において、第２の確認段階に関する処理が選択されたものと判断される基本的なケースは、ユーザＵによって、改竄チェックプログラム３０に対する起動指示が与えられた場合である。この場合、ステップＳ７からステップＳ１２へと移行し、起動された改竄チェックプログラム３０によって、ステップＳ１２〜Ｓ１５の処理が実行される。

もっとも、ここで述べるAndroid端末を用いた実施例の場合、改竄チェックプログラム３０もAndroidＯＳの管理下で動作する１つのアプリケーションプログラムに違いないので、起動時には、AndroidＯＳによって、当該改竄チェックプログラム３０自身についての署名情報を確認する処理（すなわち、ステップＳ８〜Ｓ１１に相当する処理）が実行されることになる。したがって、改竄チェックプログラム３０に対する起動指示に基づいてステップＳ７からステップＳ１２への移行が行われた場合、実際には、ステップＳ１２が実行される前に、改竄チェックプログラム３０自身について署名情報を確認する処理が行われることになるが、この処理は、本発明におけるチェック対象となるアプリケーションプログラムに対する改竄チェックには直接関係しない処理であるため、ここでは説明を省略する。

したがって、図７に示すステップＳ１２の処理は、改竄チェックプログラム３０自身についての署名情報の確認が完了し、改竄チェックプログラム３０が支障なく起動した後の処理ということになる。前述したとおり、実用上は、改竄チェックルーチンＦに対しては、クラッカーＸの手に渡っても容易には解析できないような耐タンパ化処理を施しておくのが好ましく、また、可能であれば、Android端末を販売する際に、改竄チェックプログラム３０をプリインストールソフトとして組み込んでおくのが好ましい。このような手段を講じることにより、改竄チェックプログラム３０自身の改竄を防止することができ、ステップＳ７からステップＳ１２への移行が支障なく行われるようになる。

まず、ステップＳ１２では、チェック対象となるアプリケーションプログラムを決定する処理が行われる。ここでは、チェック対象となるアプリケーションプログラムをユーザＵに指定させる運用を採る場合を例にとって説明しよう。この場合は、Android端末等の画面上に、現在インストールされているアプリケーションプログラムのリストを提示し、ユーザＵにチェック対象となるアプリケーションプログラムを指定する指示操作を行ってもらえばよい。

ステップＳ１２では、こうしてチェック対象として指定されたアプリケーションプログラムに対して、図６に示す第２の確認段階が行われ、署名情報２２に対する秘匿情報２３の正当性が確認される。すなわち、ステップＳ６で入力した配布用ファイル２０Ａから、秘匿化対象データＣとなる署名情報２２および秘匿情報２３を抽出し、秘匿化対象データＣに対する秘匿情報２３の正当性を確認する処理が、改竄チェックプログラム３０によって実行される。図６に示すとおり、改竄チェックプログラム３０には、改竄チェックルーチンＦと第１の特定鍵Ｋ（ｓ１）とが含まれており、改竄チェックルーチンＦは、第１の特定鍵Ｋ（ｓ１）を用いて、秘匿化対象データＣに対する秘匿情報２３の正当性を確認する処理を行うことになる。正当性を確認するための具体的な処理については、§７において実例を挙げて説明する。

結局、このステップＳ１２では、アプリケーション実行用コンピュータ（Android端末）が、ステップＳ６で入力した配布用ファイル２０Ａに基づいて秘匿化対象データＣおよび秘匿情報２３を入手し、秘匿化対象データＣに対する秘匿情報２３の正当性を、改竄チェックプログラム３０を実行することにより確認する処理が行われることになる。

ステップＳ１２の第２の確認段階において否定的な結果が得られた場合、すなわち、秘匿化対象データＣに対する秘匿情報２３の正当性が確認されなかった場合には、「改竄あり」との判定がなされ、ステップＳ１３を経てステップＳ１４へと進み、改竄検知処理段階が実行される。具体的には、改竄チェックプログラム３０によって、たとえば「アプリケーションプログラム○○（チェック対象として指定されたアプリケーションプログラムの名前）は改竄されています」のような判定メッセージを提示し、「改竄あり」との検知結果をユーザＵに報知する処理を行えばよい。

これに対して、ステップＳ１２の第２の確認段階において肯定的な結果が得られた場合、すなわち、秘匿化対象データＣに対する秘匿情報２３の正当性が確認された場合には、ステップＳ１３を経てステップＳ１５へと進み、改竄検知処理段階が実行される。具体的には、改竄チェックプログラム３０によって、たとえば「アプリケーションプログラム○○（チェック対象として指定されたアプリケーションプログラムの名前）は改竄されていません」のような判定メッセージを提示し、「改竄なし」との検知結果をユーザＵに報知する処理を行えばよい。

もちろん、ステップＳ１２において、複数のアプリケーションプログラムをチェック対象として指定することも可能である。たとえば、現在インストールされているアプリケーションプログラムのリストの中から、ユーザＵに、複数のアプリケーションプログラムをチェック対象として指定する指示操作を行ってもらえばよい。このように、チェック対象となるアプリケーションプログラムが複数ある場合には、ステップＳ１２〜Ｓ１５の処理は、個々のチェック対象ごとに行われることになる。

また、改竄チェックプログラム３０が、チェック対象となるアプリケーションプログラムを自動的に決定するような運用を採ることも可能である。この場合、ユーザＵは、チェック対象を指定する操作を行う必要はない。改竄チェックプログラム３０は、たとえば、現在インストールされているすべてのアプリケーションプログラムを自動的にチェック対象とすることもできるし、現在インストールされているアプリケーションプログラムのうち、§１０で述べる実行許可リストに掲載されていないものを自動的にチェック対象とすることもできる。

結局、本発明における改竄チェックプロセスでは、アプリケーション実行用コンピュータ（Android端末）が、ステップＳ６で入力した配布用ファイル２０Ａについて、第１の確認段階（ステップＳ８）および第２の確認段階（ステップＳ１２）の少なくとも一方において否定的な結果が得られた場合に改竄ありとの判定を行うことができる。ここで、図７の流れ図におけるステップＳ９は、署名情報の正当性を確認する第１の確認段階に基づく改竄判定段階ということになり、ステップＳ１３は、秘匿情報の正当性を確認する第２の確認段階に基づく改竄判定段階ということになる。このように、本発明に係る改竄チェックプロセスでは、署名情報の正当性だけでなく、秘匿情報の正当性の確認も行われる。このため、本発明では、アプリケーションパッケージ自体の改竄だけでなく、署名情報の改竄も検知することができるようになり、電子署名に対する改竄が行われた場合にも、有効な改竄検知が可能になる。

こうして、ステップＳ１４の改竄検知処理段階もしくはステップＳ１５の改竄非検知処理段階が完了すれば、改竄チェックプログラム３０はその役目を終えたことになるので、その時点で、改竄チェックプログラム３０を終了してもかまわない（この場合、改竄チェックプログラム３０が再び起動された時点で、ステップＳ７からステップＳ１２への移行が生じることになる）。ただ、実用上は、改竄チェックプログラム３０をいわゆる「常駐プログラム」として、常に起動状態に維持しておくのが好ましい。

Androidをはじめとする多くのＯＳは、複数のアプリケーションプログラムを並行して実行させるマルチタスク処理機能を有している。もちろん、一般的なＣＰＵは、同時には１つのアプリケーションプログラムを実行する機能しか有していないが、マルチタスク処理機能を有するＯＳプログラムは、複数のアプリケーションプログラムを所定のタイミングで順次切り替えながらＣＰＵに実行させる処理を行うことができる。したがって、複数のアプリケーションプログラムを同時に起動状態にして、これらを時分割で切り替えることにより、あたかも複数のアプリケーションプログラムが同時に実行されているような制御が可能になる。

そこで、改竄チェックプログラム３０をいわゆる「常駐プログラム」として常に起動状態に維持しておき、新たなアプリケーションプログラムが起動された場合に、当該アプリケーションプログラムに対する改竄チェックが自動的に実行されるようにしておけば、起動指示が与えられたアプリケーションプログラムについては、必ず、ステップＳ８の第１の確認段階とステップＳ１２の第２の確認段階との双方の確認処理が実行されることになり、理想的な改竄チェック環境が整うことになる。

上述したように、マルチタスク処理機能を有するＯＳ制御下では、複数のアプリケーションプログラムを同時に起動状態にすることができるので、改竄チェックプログラム３０を常に起動状態に維持したとしても、他のアプリケーションプログラムの起動に支障が生じることはない。したがって、改竄チェックプログラム３０が「常駐プログラム」として起動状態にあったとしても、別なアプリケーションプログラム（改竄チェックの対象となるアプリケーションプログラム）に起動指示が与えられると、ＯＳプログラムによって当該アプリケーションプログラムを起動するための処理が実行される。すなわち、ステップＳ７からステップＳ８への移行が生じ、当該チェック対象プログラムに対して第１の確認段階が実行される。ここで肯定的な結果が得られれば、上述したとおり、ステップＳ９からステップＳ１１へと進み、当該チェック対象プログラムの起動段階が実施され、当該チェック対象プログラムは起動状態になる。

この場合、チェック対象のアプリケーションプログラムは、改竄チェックプログラム３０とともに起動状態を維持することになり、両プログラムは、ＯＳのマルチタスク処理機能によって所定のタイミングで順次切り替えながら並行して実行されることになる。そこで、改竄チェックプログラム３０に、新たに起動されたアプリケーションプログラムを認識する機能をもたせておき（§１０で述べるように、ＯＳが作成するログ情報を利用すれば、どのアプリケーションプログラムがいつ起動したかを認識することが可能である）、実行順が改竄チェックプログラム３０に切り替わった時点で、新たに起動されたアプリケーションプログラムに対して第２の確認段階を実行するようにしておけばよい。そうすれば、実行順が改竄チェックプログラム３０に切り替わった時点で、ステップＳ７からステップＳ１２への移行が行われ、新たな起動が認識されたアプリケーションプログラムをチェック対象プログラムとして、ステップＳ１２〜Ｓ１５の処理が実行されることになる。

こうして、改竄チェックプログラム３０を「常駐プログラム」として常に起動状態にしておけば、新たなアプリケーションプログラムを起動するたびに、ＯＳプログラムによる第１の確認段階（ステップＳ８）が行われるとともに、改竄チェックプログラム３０による第２の確認段階（ステップＳ１２）も行われることになるので、各アプリケーションプログラムの起動時に、署名情報の正当性だけでなく、秘匿情報の正当性も含めた改竄チェックが可能になる。いわば改竄チェックプログラム３０は、「常駐プログラム」として、新たなアプリケーションプログラムの起動を監視し、新たなアプリケーションプログラムが起動された場合には、これに対して第２の確認段階（ステップＳ１２）を実行する機能を果たすことになる。

なお、ステップＳ１４の改竄検知処理段階で実行される具体的な処理内容として、上述した実施例では、「アプリケーションプログラム○○は改竄されています」のような判定メッセージを提示する例を示したが、当該プログラムが既に起動されていた場合には、改竄チェックプログラム３０により、当該プログラムの実行を中止する処理を行うようにしてもよい。Android端末をアプリケーション実行用コンピュータとして用いると、ステップＳ８の第１の確認段階によって改竄ありとの判定がなされた場合は、ステップＳ１０において起動中止段階が行われることになる。そこで、ステップＳ１２の第２の確認段階によって改竄ありとの判定がなされた場合にも、ステップＳ１４における改竄検知処理段階として、配布用ファイル２０Ａに含まれているアプリケーションプログラムについて実行を中止する処理が行われるようにすれば、いずれの確認段階で改竄が検知された場合も、改竄されたアプリケーションプログラムに対する実行中止が行われることになる。

上例のように、改竄チェックプログラム３０を「常駐プログラム」として常に起動状態にし、新たなアプリケーションプログラムの起動を監視する運用を採用した場合、新たなアプリケーションプログラムが起動されると、当該プログラムに対して自動的にステップＳ１２の第２の確認段階が実行されることになる。ここで、もし改竄が検知された場合、ステップＳ１４の改竄検知処理段階において、当該プログラムの実行が強制的に中止される処理を行うようにすればよい。

ここに示す実施例の場合、改竄チェックプログラム３０は、AndroidＯＳの管理下で動作する１つのアプリケーションプログラムであるが、AndroidＯＳの仕様によれば、第１のアプリケーションプログラムからAndroidＯＳに対して、現在起動状態にある第２のアプリケーションプログラムの実行を中止させる要請を行うことができる。そこで、第２の確認段階によって改竄が検知された場合、ステップＳ１４の改竄検知処理段階において、改竄チェックプログラム３０からAndroidＯＳに対して、改竄が検知されたアプリケーションプログラムの実行を中止させる要請を行えばよい。そうすれば、AndroidＯＳによって、当該改竄が検知されたアプリケーションプログラムを強制的に終了させることができる。

一方、ステップＳ１５の改竄非検知処理段階で実行される具体的な処理内容として、上述した実施例では、「アプリケーションプログラム○○は改竄されていません」のような判定メッセージを提示する例を示したが、改竄チェックプログラム３０を「常駐プログラム」として常に起動状態にし、新たなアプリケーションプログラムの起動を監視する運用を採用する場合は、ステップＳ１５の改竄非検知処理段階では何ら判定メーセージを提示しない運用を採ることもできる。改竄チェックプログラム３０を「常駐プログラム」として、新たに起動されたアプリケーションプログラムに対して第２の確認段階の処理を実行して自動的に改竄検知を行う運用を採用した場合、ユーザＵが意図的に改竄チェックの指示を与えたわけではないので、改竄が検知されなかった場合には、むしろ何らメッセージを提示しない方が好ましい。

図７に示す流れ図における改竄チェックプロセスは、このように、改竄チェックプログラム３０を「常駐プログラム」として常時動作させ、新たなアプリケーションプログラムの起動を監視させる運用を行う場合に適した処理手順を示しており、ステップＳ１０，Ｓ１１，Ｓ１４，Ｓ１５からステップＳ７へ戻るループが構成されている。ＯＳプログラムに対して新たなアプリケーションプログラムの起動指示が与えられると、ステップＳ７からステップＳ８への移行が行われ、ＯＳプログラムにより第１の確認段階の処理が行われる。ここで、改竄検知がなされなかった場合には、ステップＳ１１において当該アプリケーションプログラムの起動が行われ、改竄検知がなされた場合には、ステップＳ１０において当該アプリケーションプログラムの起動が中止される。

一方、マルチタスク処理の切り替えにより、「常駐プログラム」として動作している改竄チェックプログラム３０に動作が移ると、ステップＳ７からステップＳ１２への移行が行われ、改竄チェックプログラム３０により、新たな起動が認識されたアプリケーションプログラムについての第２の確認段階の処理が行われる。ここで、改竄検知がなされなかった場合には、ステップＳ１５において改竄非検知処理が行われる。上述したように、実際には、改竄検知がなされなかった場合には、検知結果を示すメッセージは何ら提示しないようにするのが好ましく、その場合、ステップＳ１５の改竄非検知処理は何もしない処理ということになる。これに対して、改竄検知がなされた場合には、ステップＳ１４において改竄検知処理が行われる。上述したように、このステップＳ１４の改竄検知処理では、改竄されたアプリケーションプログラムに対する実行中止を行うようにするのが好ましい。

かくして、ＯＳプログラムおよび改竄チェックプログラム３０が起動状態にある限り、ステップＳ７からの一連の処理が繰り返し実行されることになり、新たなアプリケーションプログラムを起動するたびに、当該アプリケーションプログラムが改竄されているか否かが、第１の確認段階の処理と第２の確認段階の処理との双方で判定されることになる。

なお、Andoroid端末の場合、ステップＳ７からステップＳ８への移行は、上述したとおり、ＯＳプログラムに対して、特定のアプリケーションプログラムを起動する指示が与えられた場合（前述したとおり、ユーザＵによる起動指示だけでなく、他のアプリケーションプログラムによる起動指示や、外部のサービスからのアクセスに基づく起動指示も含む）に生じることになるが、ステップＳ７からステップＳ１２への移行は、このような起動指示が与えられた場合に限定されるものではない。前述したように、ユーザＵが、改竄チェックプログラム３０に対して、特定のアプリケーションプログラム（起動されていなくてもよい）をチェック対象として指定した場合には、当該特定のアプリケーションプログラムに対して、第２の確認段階が実行されることになる。

あるいは、ステップＳ６において、新たなアプリケーションプログラム（配布用ファイル２０Ａ）を入力（ダウンロード）した直後や、ダウンロードしたプログラムに対してインストール作業を行った直後に、ステップＳ７からステップＳ１２への移行が自動的に行われるようにしてもよい。この場合、ダウンロードしたプログラムやインストールしたプログラムをチェック対象として、第２の確認段階が実行されることになる。別言すれば、「常駐プログラム」として動作している改竄チェックプログラム３０が、新たなアプリケーションプログラムのダウンロードやインストールを監視し、新たなアプリケーションプログラムがダウンロードされたりインストールされたりしたタイミングで、当該プログラムに対して第２の確認段階による改竄チェックを行うことになる。もちろん、その後、インストールした当該プログラムに対する起動指示を与えると、今度は、ＯＳプログラムによって第１の確認段階による改竄チェックが行われる。この場合、第２の確認段階が第１の確認段階に先行して行われることになる。

このように、ＯＳプログラムの管理下でアプリケーションプログラムの実行を行うアプリケーション実行用コンピュータを用いる場合、ステップＳ８の第１の確認段階をＯＳプログラムに基づいて実行し、ステップＳ１２の第２の確認段階を、改竄チェックの対象となるアプリケーションプログラムとは別のアプリケーションプログラムとして構成された改竄チェックプログラム３０に基づいて実行する、という役割分担を行うことができる。Android端末のように、もともとＯＳプログラムが第１の確認段階を行う機能を備えている場合には、このような役割分担を行えば、第１の確認段階を行うためのプログラムを別途用意する手間を省くことができる。

＜＜＜ §５．本発明の基本的な実施形態による改竄検知＞＞＞
ここでは、クラッカーＸが、図５に示す方法で作成された配布用ファイル２０Ａを入手し、これに改竄を加えて再配布した場合に、Android端末において、どのような方法で改竄検知が行われるかについて説明しよう。

図８は、図５に示す配布方法に対してクラッカーＸが試みる改竄プロセスを示すブロック図である。クラッカーＸは、まず、入手した配布用ファイル２０Ａ（図５参照）に含まれるアプリケーションパッケージ２１に対して伸張処理を実行し、元のアプリケーションプログラム１０を復元し、その中味について改竄を行う。

図８の上段の図は、このような改竄が行われた後のアプリケーションプログラム１０Ｘを示す図である。§２でも述べたとおり、Android端末用のアプリケーションプログラム１０の構成要素の中でも、リソースデータ１２や補助ファイル１４は、容易に改竄することができる。そこで、ここでも、クラッカーＸが、リソースデータ１２および補助ファイル１４に対して改竄を施したものとしよう（もちろん、プログラム本体部１１およびサブルーチン群１３に対して改竄を受けた場合も、以下に説明する改竄検知処理は有効である）。図８に示すリソースデータ１２Ｘおよび補助ファイル１４Ｘは、クラッカーＸによる改竄を受けたものである。続いて、クラッカーＸは、アプリケーションプログラム１０Ｘに対する再パッケージ化処理を行い、改竄されたアプリケーションパッケージ２１Ｘを生成する。

もし、クラッカーＸが、こうして生成したアプリケーションパッケージ２１Ｘを、図５に示す正規の配布用ファイル２０Ａ内の正規のアプリケーションパッケージ２１とすり替えて再配布した場合、Android端末で行われる通常の改竄検知処理によって改竄の事実が検知されることは、既に§２で述べたとおりである。すなわち、Ａの署名情報２２の正当性を確認する処理で不一致が生じることになる。本発明においても、図７に示す実行プロセスにおけるステップＳ８の第１の確認段階において、ＯＳプログラムによって当該改竄の検知が行われる。

そこで、ここでは、クラッカーＸが署名情報に対する改竄も行った場合を考えてみる。すなわち、図８の下段に示すように、クラッカーＸは、自分の第１の鍵Ｋ（ｘ１）を用いて、署名対象データＤ′（すなわち、改竄されたアプリケーションパッケージ２１Ｘ）に対する署名値Ｓ（Ｘ）を作成する処理を行い、作成された署名値Ｓ（Ｘ）と、自分の第２の鍵Ｋ（ｘ２）とを含むＸの署名情報２２Ｘを作成し、改竄されたアプリケーションパッケージ２１ＸにＸの署名情報２２Ｘを付加することにより、改竄された配布用ファイル２０Ｘを作成する。

このように署名情報に対する改竄も行われると、クラッカーＸによる再署名が行われたことになるので、Ｘの署名情報２２Ｘは署名対象データＤ′に対する正当性を有する。したがって、従来の方法では、このようにして作成された配布用ファイル２０Ｘについては、改竄検知を行うことができない。本発明においても、図７に示す改竄チェックプロセスにおけるステップＳ８の第１の確認段階では、このような改竄を検知することはできない。

しかしながら、本発明に係る方法で配布される配布用ファイル２０Ａには、更に、秘匿情報２３が付加されており、この秘匿情報２３についての正当性が、ステップＳ１２の第２の確認段階で確認される。秘匿情報２３は、図５の下段に示すとおり、秘匿化対象データＣ（この例では、Ａの署名情報２２）を第２の特定鍵Ｋ（ｓ２）を用いて秘匿化することによって得られる情報であるが、第２の特定鍵Ｋ（ｓ２）が秘密の状態で管理されていれば、クラッカーＸはこれを入手することができない。したがって、クラッカーＸは、自身で作成したＸの署名情報２２Ｘを秘匿化対象データＣ′として、第２の特定鍵Ｋ（ｓ２）を用いた秘匿化処理を行い、改竄された秘匿情報２３Ｘを作成することはできない。図８の下段において、×印が付された部分は、実際には、クラッカーＸが行うことができない処理やクラッカーＸが作成することができない情報を示している。

結局、クラッカーＸは、作成した配布用ファイル２０Ｘ内の秘匿情報については、元のままの状態（秘匿情報２３のまま）にしておくか、これを削除してしまうか、あるいは新たに作成した任意の秘匿情報に置き換えるしかない。いずれの方法を採っても、図７に示す改竄チェックプロセスにおけるステップＳ１２の第２の確認段階において、正当性の確認ができないため、改竄の検知が行われることになる。

すなわち、元のままの状態にしておいた場合、第２の確認段階において、Ｘの署名情報２２Ｘに対する秘匿情報２３の正当性を確認する処理が行われることになるが、秘匿情報２３は、Ａの署名情報２２に対して正当性を有する情報であるため、Ｘの署名情報２２Ｘに対する正当性は確認できない。一方、秘匿情報を削除してしまった場合は、Ｘの署名情報２２Ｘに対する正当性確認の対象物がないため、そもそも正当性確認の処理を行うことができない。また、新たに作成した任意の秘匿情報に置き換えた場合も、当該置換後の秘匿情報が、Ｘの署名情報２２Ｘを第２の特定鍵Ｋ（ｓ２）を用いて秘匿化することによって得られる情報（別言すれば、第１の特定鍵Ｋ（ｓ１）を用いて正当性確認がなされる情報）に偶然一致しない限り、第２の確認段階における正当性確認はなされない。

結局、クラッカーＸが、アプリケーションパッケージ２１および署名情報２２に対する改竄を行ったとしても、秘匿情報２３に対する改竄を行うことができなければ、第１の確認段階で改竄が見逃されたとしても、第２の確認段階において改竄が検知されることになる。このように、本発明に係るアプリケーションプログラムの改竄検知方法によれば、電子署名に対する改竄が行われた場合にも、有効な改竄検知を行うことが可能になり、改竄検知後は、必要に応じて、当該アプリケーションプログラムの実行を自動的に中止させることも可能になる。

もちろん、本発明に係るアプリケーションプログラムの改竄検知方法による改竄検知機能は、１００％完全なものではない。すなわち、クラッカーＸが、改竄チェックプログラム３０に対する改竄も行ってしまった場合、第２の確認段階は有効に機能しなくなる。たとえば、改竄チェックプログラム３０内の第１の特定鍵Ｋ（ｓ１）をクラッカーＸ自身の特定鍵に書き換えたり、改竄チェックルーチンＦ自身を無能なルーチンに書き換えてしまえば、第２の確認段階による改竄チェックは正常に機能しなくなる。

したがって、実用上は、前述したように、改竄チェックルーチンＦ自身は、クラッカーＸの手に渡っても容易には解析できないような耐タンパ化処理を施しておくのが好ましい。また、改竄チェックプログラム３０は、特別な認証手続を必要とする特定のサイトからダウンロードさせたり、Android端末等に予めプリインストールソフトとして組み込んでおくようにし、配布段階で改竄を受ける危険を回避するようにするのが好ましい。

＜＜＜ §６．秘匿化対象データのバリエーション＞＞＞
§３で説明した本発明の基本的な実施形態に係る改竄検知方法では、図５に太線枠で囲って示すように、Ａの署名情報２２全体（すなわち、署名値Ｓ（Ａ）とＡの第２の鍵Ｋ（ａ２））を秘匿化対象データＣとして、第２の特定鍵Ｋ（ｓ２）を用いた秘匿化処理を行い、秘匿情報２３を作成している。このようにして作成された秘匿情報２３は、Ａの署名情報２２の痕跡を残す情報というべきものであり、第１の特定鍵Ｋ（ｓ１）を用いた所定の確認方法により、Ａの署名情報２２に対する正当性の確認が可能になるという固有の性質を有している。

このような性質を有する秘匿情報２３を配布用ファイル２０Ａに含ませておけば、Ａの署名情報２２に対する秘匿情報２３の正当性を確認する処理（第２の確認段階）を行うことにより、Ａの署名情報２２に対する改竄の有無を確認することができるようになる。

もっとも、本発明を実施する上で用いる秘匿化対象データＣは、必ずしもＡの署名情報２２のみに限定されるものではない。ここでは、秘匿化対象データＣのバリエーションをいくつか述べておく。

図９は、図５に示す本発明の基本的な実施形態に係る配布方法のバリエーションを示すブロック図である。図５に示す実施形態との相違点は、秘匿化対象データＣの設定方法だけである。図５に示す例では、太線枠で囲って示すように、Ａの署名情報２２全体を秘匿化対象データＣに設定しているが、図９に示すバリエーションでは、太線枠で囲って示すように、Ａの署名情報２２に含まれるＡの第２の鍵Ｋ（ａ２）を構成するデータのみを秘匿化対象データＣに設定している。

したがって、図９に示すバリエーションの場合、図７のステップＳ３の秘匿情報作成段階において、第２の特定鍵Ｋ（ｓ２）を用いてＡの第２の鍵Ｋ（ａ２）を秘匿化することにより秘匿情報２３′を作成することになる。また、ステップＳ１２の第２の確認段階において、Ａの署名情報２２に対する秘匿情報２３の正当性を確認する代わりに、このバリエーションにおける秘匿化対象データＣであるＡの第２の鍵Ｋ（ａ２）に対する秘匿情報２３′の正当性が確認されることになる。

このように、秘匿化対象データＣとして、Ａの署名情報２２の代わりにＡの第２の鍵Ｋ（ａ２）を用いたとしても、署名情報に対する改竄が行われたか否かを検知する上では支障は生じない。そもそもＡの署名情報２２は、プログラム提供者Ａがアプリケーションパッケージ２１を署名対象データＤとして、その内容を保証することを示すものであり、プログラム提供者Ａの痕跡はＡの第２の鍵Ｋ（ａ２）として記録されていることになる。そして、クラッカーＸが、署名情報に対する改竄を行う場合、図８に示すように、Ａの署名情報２２をそっくりＸの署名情報２２Ｘに差し替えることになるので、当然、Ａの第２の鍵Ｋ（ａ２）もＸの第２の鍵Ｋ（ｘ２）に差し替えられることになる。

したがって、Ａの第２の鍵Ｋ（ａ２）を秘匿化対象データＣに設定し、これを秘匿化して秘匿情報２３′を作成し、第２の確認段階において、Ａの第２の鍵Ｋ（ａ２）に対する秘匿情報２３′の正当性を確認するようにしても、署名情報に対する改竄の有無を検知することができる。Ａの第２の鍵Ｋ（ａ２）がＸの第２の鍵Ｋ（ｘ２）に差し替えられていた場合、秘匿情報２３′は、Ａの第２の鍵Ｋ（ａ２）を秘匿化対象データＣとして作成された情報であるから、差し替えられたＸの第２の鍵Ｋ（ｘ２）に対しての正当性は確認できない。

結局、秘匿化対象データＣとして、少なくともプログラム提供者Ａの第２の鍵Ｋ（ａ２）を含むデータを用いるようにすれば、クラッカーＸが、署名情報に対する改竄を行ったとしても、第２の確認段階において、これを検知することができる。クラッカーＸは、第２の特定鍵Ｋ（ｓ２）を入手しない限り、改竄チェックルーチンＦ（第１の特定鍵Ｋ（ｓ１）によって正当性の確認を行うルーチン）によって正当性の確認が可能な秘匿情報２３Ｘを作成することはできないので、Ａの署名情報２２をそっくりＸの署名情報２２Ｘに差し替えたとしても、第２の確認段階における改竄検知を免れることはできない。

このように、図５に示す例のように、Ａの署名情報２２を秘匿化対象データＣとして設定することもできるし、図９に示すバリエーションのように、Ａの第２の鍵Ｋ（ａ２）を秘匿化対象データＣとして設定することもできるし、その他にも種々のバリエーションを採用することができる。

図１０は、別なバリエーションを示すブロック図である。このバリエーションでは、太線枠で囲って示すように、アプリケーションパッケージ２１とＡの署名情報２２との双方を構成するデータ全体を秘匿化対象データＣに設定している。したがって、このバリエーションの場合、第２の特定鍵Ｋ（ｓ２）を用いて、図に太線枠で囲った部分のデータ全体を秘匿化することにより秘匿情報２３''を作成することになる。そして第２の確認段階では、この太線枠で囲った部分のデータ全体に対する秘匿情報２３''の正当性が確認されることになる。

この図１０に示すバリエーションでも、秘匿化対象データＣにＡの第２の鍵Ｋ（ａ２）が含まれているため、クラッカーＸがＡの署名情報２２をＸの署名情報２２Ｘに差し替える改竄を行っても、第２の確認段階による改竄検知が有効に機能することになる。

結局、プログラム提供者Ａが署名した痕跡を何らかの形で配布用ファイル２０Ａに残しておくには、図７のステップＳ３の秘匿情報作成段階において、アプリケーションパッケージ２１および署名情報２２を構成するデータの中から、プログラム提供者の第２の鍵Ｋ（ａ２）を含む所定部分を秘匿化対象データＣとして抽出し、抽出した秘匿化対象データＣに対して第２の特定鍵Ｋ（ｓ２）を用いた秘匿化処理を施して秘匿情報を作成するようにすればよい。

図５に示す例は、署名情報２２を構成するデータ全体を秘匿化対象データＣに設定して秘匿情報２３を作成した例であり、図９に示す例は、署名情報２２に含まれるプログラム提供者の第２の鍵Ｋ（ａ２）を構成するデータを秘匿化対象データＣに設定して秘匿情報２３′を作成した例であり、図１０に示す例は、アプリケーションパッケージ２１と署名情報２２との双方を構成するデータ全体を秘匿化対象データＣに設定して秘匿情報２３''を作成した例ということになる。

プログラム提供者Ａが署名した痕跡を残しておく、という目的を達成する上では、図９に示す例のように、プログラム提供者の第２の鍵Ｋ（ａ２）のみを秘匿化対象データＣとする方法が最も簡便で直接的な方法である。このような観点からは、図５に示す例や図１０に示す例は、冗長な方法と言うことができる。しかしながら、プログラム提供者Ａが署名した痕跡に加えて、アプリケーションパッケージ２１に関する何らかの痕跡も残しておく、という観点では、図５に示す例や図１０に示す例は意味のある方法になる。

たとえば、図１０に示す例では、太線枠で囲ったアプリケーションパッケージ２１と署名情報２２との双方が秘匿化対象データＣに設定されており、第２の確認段階では、これらのデータ全体に対する秘匿情報２３''の正当性の確認が行われることになるので、アプリケーションパッケージ２１に対する改竄検知と署名情報２２に対する改竄検知との両方を行うことが可能である。

図５に示す基本的な実施形態では、アプリケーションパッケージ２１に対する改竄検知は、Ａの署名情報２２を用いた第１の確認段階で行い、署名情報２２に対する改竄検知は、秘匿情報２３を用いた第２の確認段階で行うことになるが、図１０に示すバリエーションの場合、アプリケーションパッケージ２１に対する改竄検知は、Ａの署名情報２２を用いた第１の確認段階で行われるとともに、秘匿情報２３''を用いた第２の確認段階でも重ねて行われることになる。

これまで述べてきた実施形態では、第２の確認段階の処理を、署名情報の改竄検知を行うための処理として捉えてきたが、第２の確認段階の処理は、上述したとおり、アプリケーションパッケージ２１に対する改竄検知にも利用することが可能である。

したがって、第２の確認段階の処理を、署名情報の改竄検知ではなく、アプリケーションパッケージ２１に対する改竄検知のみに利用するのであれば、秘匿化対象データＣには、必ずしもプログラム提供者Ａの第２の鍵Ｋ（ａ２）が含まれている必要はない。たとえば、アプリケーションパッケージ２１の部分のみを秘匿化対象データＣに設定して、秘匿情報２３'''を作成した場合、第２の確認段階では、Ａの署名情報２２に対する改竄検知を行うことはできないが、アプリケーションパッケージ２１に対する改竄検知を行うことは可能である。

結局、本発明の基本的な技術思想は、コンピュータが、アプリケーションプログラム１０（これまで述べてきた実施形態の場合は、パッケージ化された状態のアプリケーションパッケージ２１）と、署名情報２２と、秘匿情報２３（上述した各バリエーションの場合は、２３′，２３''，２３'''）とを含むデータファイルを入力する入力段階と、コンピュータが、当該アプリケーションプログラム１０が改竄されているか否かを判定する判定段階と、を有するアプリケーションプログラムの改竄検知方法ということになる。

ここで、署名情報２２は、アプリケーションプログラム１０（もしくは、アプリケーションパッケージ２１）を署名対象データＤとする電子署名処理によって得られた情報であり、秘匿情報２３（もしくは、２３′，２３''，２３'''）は、当該アプリケーションプログラム１０（もしくは、アプリケーションパッケージ２１）および署名情報２２を構成するデータの中の所定部分を秘匿化対象データＣとして抽出し、抽出した秘匿化対象データＣに対する秘匿化処理を施して得られた情報ということになる。

また、コンピュータによって実行される上記判定段階は、署名情報２２に基づいて改竄の有無を確認する第１の確認段階と、秘匿情報２３（もしくは、２３′，２３''，２３'''）に基づいて改竄の有無を確認する第２の確認段階と、を有している。そして、コンピュータには、改竄チェックプログラム３０がインストールされており、この改竄チェックプログラム３０には秘匿化処理で行われた処理プロセスを勘案して秘匿化対象データＣに対する秘匿情報の正当性を確認する改竄チェックルーチンＦが含まれており、この改竄チェックルーチンＦを実行することにより第２の確認段階が行われることになる。

これまで述べてきた実施例は、プログラム提供者の第２の鍵Ｋ（ａ２）を含む所定部分を秘匿化対象データＣとして用い、ＯＳプログラムの管理下でアプリケーションプログラムの実行を行うコンピュータによって、第１の確認段階をＯＳプログラムに基づいて実行し、第２の確認段階をアプリケーションプログラム３０内の改竄チェックルーチンＦに基づいて実行するようにした例ということになる。

＜＜＜ §７．秘匿化処理の具体的な実施形態＞＞＞
ここでは、本発明における秘匿情報作成段階（図７のステップＳ３）で行われる秘匿化処理の具体的な実施形態を述べる。図５に示すように、本発明における秘匿情報作成段階では、秘匿化対象データＣに対して、第２の特定鍵Ｋ（ｓ２）を用いた秘匿化処理が行われ、秘匿情報２３が作成される。ここで、秘匿情報２３は、秘匿化対象データＣおよび第２の特定鍵Ｋ（ｓ２）が与えられれば一義的に定まる何らかのデータであり、改竄チェックルーチンＦによって実行される第１の特定鍵Ｋ（ｓ１）を用いた所定のチェック処理によって、秘匿化対象データＣに対する秘匿情報２３の正当性が確認されることになる。

秘匿化対象データＣを秘匿化して秘匿情報２３を作成するには、第２の特定鍵Ｋ（ｓ２）が必要である。したがって、第２の特定鍵Ｋ（ｓ２）を秘密に管理していれば、クラッカーＸは秘匿情報２３を生成することができない。また、秘匿情報２３は、文字通り「元の秘匿化対象データＣを秘匿化」した情報になっており、秘匿情報２３だけを用いて、元の秘匿化対象データＣを復元することはできない。以下、このような性質を有する秘匿情報２３を作成するための具体的な秘匿化処理の方法を述べる。

なお、以下の説明は、§３で述べた基本的な実施形態と同様に、Ａの署名情報２２を秘匿化対象データＣに設定した例（図５の例）についてのものであるが、もちろん、以下に述べる秘匿化処理の具体的な処理方法は、§６で述べたように、秘匿化対象データＣについて様々な設定を行うバリエーション（たとえば、図９や図１０の例）についても有効である。

＜７−１：暗号化処理＞
本発明における秘匿化処理に適した第１の処理は、暗号化処理である。秘匿化処理として暗号化処理を利用する場合、秘匿化対象データＣと秘匿情報２３との関係は、前者を暗号化することにより後者が得られ、後者を復号することにより前者が得られる、という関係になる。

このような暗号化および復号を行うには、公開鍵暗号方式を利用するのが好ましい。公開鍵暗号方式では、一方の鍵を用いて暗号化したデータを他方の鍵を用いて復号できる性質をもった一対の鍵が用いられる。したがって、秘匿情報２３は、秘匿化対象データＣを一方の鍵を用いて暗号化することにより得られることになり、改竄チェックルーチンＦは、この秘匿情報２３を他方の鍵を用いて復号し、この復号によって得られた秘匿化対象データと、入力段階で入力したデータファイル２０Ａから抽出した秘匿化対象データＣとが一致していた場合に改竄なしとの確認を行うことになる。

図１１は、図５に示す配布方法における秘匿情報２３として、暗号化された情報を用いる具体的実施例を示すブロック図である。この実施例は、§３で述べたように、個々のプログラム提供者Ａ，Ｂ，Ｃ，...とは別個に、とりまとめ役としてのプログラム保証者Ｇが参画した例である。プログラム保証者Ｇは、Ｇの第１の鍵Ｋ（ｇ１）を内蔵した改竄チェックプログラム３０Ｇを用意し、個々のプログラム提供者Ａ，Ｂ，Ｃ，...には、Ｇの第２の鍵Ｋ（ｇ２）を提供する。プログラム保証者Ｇは、公的機関であってもよいし、民間企業であってもよいが、社会的に信用があり、安全に鍵を管理する能力をもった団体がその役割を担うようにするのが好ましい。

上述したとおり、秘匿化処理として、公開鍵暗号方式を利用した暗号化処理を採用する場合、図５に示す第１の特定鍵Ｋ（ｓ１）および第２の特定鍵Ｋ（ｓ２）として、一方の鍵を用いて暗号化したデータを他方の鍵を用いて復号できる性質をもった一対の鍵を用いることになる。図１１に示す例は、プログラム保証者Ｇの第１の鍵Ｋ（ｇ１）を第１の特定鍵Ｋ（ｓ１）として用い、プログラム保証者Ｇの第２の鍵Ｋ（ｇ２）を第２の特定鍵Ｋ（ｓ２）として用いた例である。より具体的には、第１の鍵Ｋ（ｇ１）としては、プログラム保証者Ｇの公開鍵を用い、第２の鍵Ｋ（ｇ２）としては、プログラム保証者Ｇの秘密鍵を用いればよい。もっとも、公開鍵と秘密鍵とを入れ替えて用いても、本発明を実施することは可能である。

プログラム保証者Ｇは、予め、自分（Ｇ）の第１の鍵Ｋ（ｇ１）を用いて改竄チェックを行う改竄チェックルーチンＦを用意し、この改竄チェックルーチンＦとＧの第１の鍵Ｋ（ｇ１）とを組み込んだ改竄チェックプログラム３０Ｇを配布するようにする。前述したとおり、この改竄チェックプログラム３０Ｇは、耐タンパ化を施しておき、できるだけ安全な配布経路を介してユーザの手元に配布されるようにするのが好ましい（認証手続を必要とするダウンロードやプリインストールなど）。

一方、プログラム保証者Ｇは、自分（Ｇ）の第２の鍵Ｋ（ｇ２）を記録した媒体を、個々のプログラム提供者Ａ，Ｂ，Ｃ，...に貸し与える。図示の例の場合、プログラム提供者Ａは、この媒体を利用して、配布用ファイル２０Ａを作成することができる。したがって、ここに示す実施形態では、Ａの署名情報２２は、プログラム提供者Ａが、自分自身の鍵を用いてアプリケーションパッケージ２１の内容を保証するために付加する情報としての役割を果たし、秘匿情報２３は、プログラム保証者Ｇが、自分自身の鍵を用いてＡの署名情報２２の内容を保証するために付加する情報としての役割を果たすことになる。

プログラム提供者Ａは、まず、従来と同様の方法で、図１１の上段に示すようなアプリケーションプログラム１０を作成し、これを従来の方法と同様にパッケージ化し（ＡＰＫファイル作成用の専用プログラムを用いればよい）、アプリケーションパッケージ２１を作成する（図７のステップＳ１のパッケージ化段階）。次に、プログラム提供者Ａは、このアプリケーションパッケージ２１を署名対象データＤとして、自分の第１の鍵Ｋ（ａ１）を用いた電子署名処理を行い、Ａの署名情報２２を作成する（図７のステップＳ２の署名情報作成段階）。

続いて、プログラム保証者Ｇから借り受けた媒体から、Ｇの第２の鍵Ｋ（ｇ２）を読み出し、Ａの署名情報２２を秘匿化対象データＣとして、Ｇの第２の鍵Ｋ（ｇ２）を用いた秘匿化処理を行い、秘匿情報２３を作成する（図７のステップＳ３の秘匿情報作成段階）。この図１１に示す実施例の場合、秘匿化処理として暗号化処理を採用しているため、秘匿情報作成段階では、第２の特定鍵（すなわち、プログラム保証者Ｇの第２の鍵Ｋ（ｇ２））を用いて、秘匿化対象データＣに対する暗号化処理を施して秘匿情報２３が作成される。

最後に、アプリケーションパッケージ２１、Ａの署名情報２２、秘匿情報２３をまとめれば、配布用ファイル２０Ａ（ＡＰＫファイル）を作成することができる（図７のステップＳ４の配布用ファイル作成段階）。そこで、これをＷｅｂサーバや物理的媒体に出力して（図７のステップＳ５のファイル出力段階）、任意の方法で配布すればよい。

一方、アプリケーション実行用コンピュータ（Android端末）は、このような方法で作成された配布用ファイル２０Ａ（ＡＰＫファイル）を入手することになるが（図７のステップＳ６のファイル入力段階）、このとき、このコンピュータ内には、既に、プログラム保証者Ｇから配布された改竄チェックプログラム３０Ｇがインストールされている（図７のステップＳ０）。したがって、新たに入手した配布用ファイル２０Ａをインストールして実行しようとすると、Android端末のＯＳプログラムの機能により署名情報２２の正当性が確認され（図７のステップＳ８の第１の確認段階）、改竄チェックプログラム３０Ｇを動作させれば、改竄チェックルーチンＦの機能により秘匿情報２３の正当性が確認される（図７のステップＳ１２の第２の確認段階）。

図１２は、図１１に示す配布用ファイル２０Ａについて、署名情報２２の正当性および秘匿情報２３の正当性を確認する処理を示すブロック図である。

まず、署名情報２２の正当性の確認（第１の確認段階）は、既に述べたように、次のようにして行われる。はじめに、署名情報２２から署名値Ｓ（Ａ）およびＡの第２の鍵Ｋ（ａ２）を抽出し、署名値Ｓ（Ａ）に対してＡの第２の鍵Ｋ（ａ２）を用いた復号処理を行うことにより、ハッシュ値Ｈ１を得る。次に、アプリケーションパッケージ２１（署名対象データＤ）に対して、ハッシュ関数ＨＡＳＨを作用させた不可逆変換を行い、ハッシュ値Ｈ２を求める処理を行う。そして、ハッシュ値Ｈ１とハッシュ値Ｈ２とが一致するか否かを確認する処理を行えば、第１の確認段階は終了する。

一方、秘匿情報２３の正当性の確認（第２の確認段階）は、公開鍵暗号方式の基本原理を利用することによって行われる。すなわち、ここに示す実施例では、プログラム保証者Ｇの第１の鍵Ｋ（ｇ１）と第２の鍵Ｋ（ｇ２）とは、公開鍵暗号方式における一対の鍵を構成しており、第２の鍵Ｋ（ｇ２）を用いて暗号化したデータは、第１の鍵Ｋ（ｇ１）を用いて復号することができる。そこで、改竄チェックルーチンＦは、次のような方法で第２の確認段階の処理を実行する。

はじめに、図１２に示すように、改竄チェックプログラム３０Ｇに内蔵されているプログラム保証者Ｇの第１の鍵Ｋ（ｇ１）を用いて、入力した配布用ファイル２０Ａから抽出した秘匿情報２３を復号し、元の秘匿化対象データＣを得る。続いて、この復号によって得られた秘匿化対象データＣと、入力した配布用ファイル２０Ａから抽出した秘匿化対象データＣ（この例の場合は、Ａの署名情報２２）とが一致していた場合に、秘匿情報２３が正当である旨の確認を行えばよい。

結局、ここで述べた方法は、秘匿化対象データＣを暗号化という手法で秘匿化して、秘匿情報２３という形で配布用ファイル２０Ａに付加して配布し、アプリケーション実行用コンピュータ（Android端末）では、秘匿情報２３を復号した結果が秘匿化対象データＣに一致することを確認することにより、改竄の有無を検知する方法ということができる。クラッカーＸは、暗号化に用いられたプログラム保証者Ｇの第２の鍵Ｋ（ｇ２）を入手することができないため、秘匿情報２３の改竄を行うことはできない。

＜７−２：ダイジェスト化処理＞
本発明における秘匿化処理に適した第２の処理は、ダイジェスト化処理である。秘匿化処理としてダイジェスト化処理を利用する場合、秘匿化対象データＣと秘匿情報２３との関係は、前者をダイジェスト化することにより後者が得られる、という関係になる。

ここで、ダイジェスト化とは、元の情報から情報量を減らす演算処理を行って、元の情報に基づいて一義的に決定できる別な情報を得る処理である。具体的には、元の情報を構成するデータに対して、何らかの一方向性関数を作用させる処理を行えばよい。この場合、秘匿情報２３は、秘匿化対象データＣに対して、所定の特定鍵をパラメータとして用いた一方向性関数を作用させるダイジェスト化処理を施して得られることになり、改竄チェックルーチンＦは、入力段階で入力したデータファイル２０Ａから抽出した秘匿化対象データＣに対して、上記特定鍵と同一の鍵を用いた上記ダイジェスト化処理と同一の処理を施して得られる情報が、入力段階で入力したデータファイル２０Ａに含まれている秘匿情報２０Ａと一致していた場合に改竄なしとの確認を行うことになる。

図１３は、図５に示す配布方法における秘匿情報２３として、ダイジェスト化された情報を用いる具体的実施例を示すブロック図である。この実施例でも、プログラム提供者Ａが配布用ファイル２０Ａを配布する際に、プログラム保証者Ｇの助力を受けることになる。ただ、第１の特定鍵Ｋ（ｓ１）および第２の特定鍵Ｋ（ｓ２）としては、同一の共通特定鍵Ｋ（ｓ０）を用いる。

プログラム保証者Ｇは、予め、自己が秘密状態で管理している共通特定鍵Ｋ（ｓ０）を用いて改竄チェックを行う改竄チェックルーチンＦを作成しておき、この改竄チェックルーチンＦと当該共通特定鍵Ｋ（ｓ０）とを組み込んだ改竄チェックプログラム３０Ｇを配布する。この改竄チェックプログラム３０Ｇも、耐タンパ化を施しておき、共通特定鍵Ｋ（ｓ０）が容易に読み出されないようにしておく。一方、プログラム保証者Ｇは、個々のプログラム提供者Ａ，Ｂ，Ｃ，...に対しては、当該共通特定鍵Ｋ（ｓ０）が記録された媒体を貸し与える。そうすれば、たとえば、プログラム提供者Ａは、この媒体を利用して、配布用ファイル２０Ａを作成することができる。

具体的には、プログラム提供者Ａは、上述した暗号化処理を採用する実施例と同様に、図１３の上段に示すようなアプリケーションプログラム１０を用意し、これをパッケージ化し、アプリケーションパッケージ２１を作成する。そして、プログラム提供者Ａは、このアプリケーションパッケージ２１を署名対象データＤとして、自分の第１の鍵Ｋ（ａ１）を用いた電子署名処理を行い、Ａの署名情報２２を作成する。

続いて、プログラム保証者Ｇから借り受けた媒体から、共通特定鍵Ｋ（ｓ０）を読み出し、Ａの署名情報２２を秘匿化対象データＣとして、共通特定鍵Ｋ（ｓ０）を用いた秘匿化処理を行い、秘匿情報２３を作成する。この図１３に示す実施例の場合、秘匿化処理としてダイジェスト化処理を採用しているため、秘匿情報作成段階では、共通特定鍵Ｋ（ｓ０）を用いて、秘匿化対象データＣに対するダイジェスト化処理を施して秘匿情報２３が作成される。

ダイジェスト化処理は、前述したように、秘匿化対象データＣに対して、共通特定鍵Ｋ（ｓ０）をパラメータとして用いた一方向性関数を作用させる処理である。具体的には、共通特定鍵Ｋ（ｓ０）をパラメータとして用いたハッシュ関数を作用させる処理を行い、得られるハッシュ値を秘匿情報２３とすればよい。

最後に、アプリケーションパッケージ２１、Ａの署名情報２２、秘匿情報２３をまとめて配布用ファイル２０Ａ（ＡＰＫファイル）を作成し、これを配布すればよい。

一方、アプリケーション実行用コンピュータ（Android端末）は、このような方法で作成された配布用ファイル２０Ａ（ＡＰＫファイル）について、図１４のブロック図に示す方法を行い、署名情報２２の正当性および秘匿情報２３の正当性を確認する処理を行う。

ここで、署名情報２２の正当性の確認（第１の確認段階）は、これまで述べてきた実施例と全く同様である。すなわち、署名値Ｓ（Ａ）に対してＡの第２の鍵Ｋ（ａ２）を用いた復号処理を行うことによりハッシュ値Ｈ１を得る処理を行うとともに、アプリケーションパッケージ２１（署名対象データＤ）に対して、ハッシュ関数ＨＡＳＨを作用させた不可逆変換を行ってハッシュ値Ｈ２を得る処理を行い、ハッシュ値Ｈ１とハッシュ値Ｈ２とが一致するか否かを確認する処理を行うことになる。

一方、秘匿情報２３の正当性の確認（第２の確認段階）は、プログラム提供者Ａが秘匿情報２３を作成する際に行った処理と全く同じ処理を実行し、同じ結果が得られるか否かを確認することによって行われる。もちろん、この場合、コンピュータ内には、既に、プログラム保証者Ｇから配布された改竄チェックプログラム３０Ｇ（共通特定鍵Ｋ（ｓ０）を用いて改竄チェックを行う改竄チェックルーチンＦを含むプログラム）がインストールされている必要があり（図７のステップＳ０）、以下の改竄チェック処理は、この改竄チェックルーチンＦによって実行される。

具体的には、図１４に示すように、まず、入力した配布用ファイル２０Ａから秘匿化対象データＣ（この例の場合、Ａの署名情報２２）を抽出する。そして、抽出した秘匿化対象データＣに対して、改竄チェックプログラム３０Ｇに内蔵されている共通特定鍵Ｋ（ｓ０）を用いたダイジェスト化処理（配布プロセスの秘匿情報作成段階で行われた処理と同一の処理）を実行する。すなわち、配布プロセスで行ったように、共通特定鍵Ｋ（ｓ０）をパラメータとして用いたハッシュ関数を作用させる処理を行い、ハッシュ値を得るようにすればよい。このダイジェスト化処理によって得られたハッシュ値が、入力した配布用ファイル２０Ａに含まれている秘匿情報２３と一致していた場合に、当該秘匿情報２３が正当である旨の確認を行うことになる。

結局、ここで述べた方法は、秘匿化対象データＣをダイジェスト化という手法で秘匿化して、秘匿情報２３という形で配布用ファイル２０Ａに付加して配布し、アプリケーション実行用コンピュータ（Android端末）では、同じ手法で秘匿化対象データＣをダイジェスト化して、付加されていた秘匿情報２３に一致することを確認することにより、改竄の有無を検知する方法ということができる。改竄チェックプログラム３０Ｇに対して十分な耐タンパ化が施されていれば、クラッカーＸは、ダイジェスト化に用いられたプログラム保証者Ｇの共通特定鍵Ｋ（ｓ０）を入手することができないため、秘匿情報２３の改竄を行うことはできない。

秘匿化処理として暗号化を採用した場合、得られる秘匿情報には、復号によって元の秘匿化対象データＣを復元するために必要な情報がそのまま含まれている。したがって、元の秘匿化対象データＣの情報量が多ければ、得られる秘匿情報の情報量も多くなる。このため、たとえば、図１０に示す例のように、アプリケーションパッケージ２１およびＡの署名情報２２をそっくり含むデータを秘匿化対象データＣとして用いる場合は、得られる秘匿情報２３''のデータ容量はかなり大きくなり、配布用ファイル２０Ａ''の肥大化を招くことになる。

これに対して、秘匿化処理としてダイジェスト化を採用した場合、得られる秘匿情報から元の秘匿化対象データＣを復元する必要はないため、秘匿情報の情報量を大幅に削減することが可能である。このため、たとえば、図１０に示す例のように、かなり大きなデータ容量をもつ秘匿化対象データＣを設定した場合でも、ダイジェスト化を採用すれば、得られる秘匿情報２３''のデータ容量を低く抑えることができ、配布用ファイル２０Ａ''の肥大化を防ぐことができる。

＜７−３：その他の秘匿化処理＞
以上、本発明における秘匿化処理の具体的な実施形態として、暗号化処理とダイジェスト化処理を例示したが、本発明を実施するにあたり、秘匿化処理の具体的な形態は、これら２つの処理に限定されるものではない。

本発明における秘匿化処理は、互いに特別な関係をもった第１の特定鍵Ｋ（ｓ１）と第２の特定鍵Ｋ（ｓ２）とを用いることを前提とした処理であり、第２の特定鍵Ｋ（ｓ２）を用いた何らかの演算処理によって、元の秘匿化対象データＣに対して一義的に秘匿情報２３を決定することができ、しかも第１の特定鍵Ｋ（ｓ１）を用いることによって、秘匿化対象データＣに対する秘匿情報２３の正当性が確認できる（すなわち、改竄を受けていないことを確認できる）、という条件を満たす処理であれば、どのような処理を秘匿化処理として採用してもかまわない。

前述した暗号化処理では、第１の特定鍵Ｋ（ｓ１）および第２の特定鍵Ｋ（ｓ２）として、「公開鍵暗号方式に用いる一対の鍵」という互いに特別な関係をもった鍵がが採用されることになる。また、前述したダイジェスト化処理では、第１の特定鍵Ｋ（ｓ１）および第２の特定鍵Ｋ（ｓ２）として、「同一の共通特定鍵Ｋ（ｓ０）である」という互いに特別な関係をもった鍵が採用されることになる。

＜＜＜ §８．秘匿情報および特定鍵の引き渡し方法の変形例＞＞＞
これまで述べてきた実施形態では、秘匿情報２３を配布用ファイル２０Ａに組み込み、第１の特定鍵Ｋ（ｓ１）を改竄チェックプログラム３０に組み込む方式を採用している。したがって、ユーザＵが利用するアプリケーションプログラム実行用コンピュータ（Android端末）には、秘匿情報は配布用ファイルの一部として引き渡され、第１の特定鍵Ｋ（ｓ１）は改竄チェックプログラムの一部として引き渡される。しかしながら、秘匿情報および特定鍵をアプリケーションプログラム実行用コンピュータに引き渡す方法は、上記方法に限定されるものではない。以下、この点に関する変形例を述べておく。

＜８−１：秘匿情報の引き渡し方法の変形例＞
本発明に係るアプリケーションプログラムの改竄検知方法では、まず、配布プロセスにおいて秘匿情報を作成し、続いて、改竄チェックプロセスにおいて、この秘匿情報を利用した改竄有無の判定を行うことになる。したがって、配布プロセスで作成した秘匿情報を、何らかの方法で改竄チェックプロセスに引き渡す必要がある。これまで述べてきた実施形態は、配布用ファイル作成段階において作成する配布用ファイル内に、作成した秘匿情報を組み込むことにより、配布用ファイルとともに秘匿情報の引き渡しが行われるようにしていた。

たとえば、図５に示す実施形態の場合、秘匿情報２３は配布用ファイル２０Ａ内に組み込まれた状態で配布されることになり、図９に示す実施形態の場合、秘匿情報２３′は配布用ファイル２０Ａ′内に組み込まれた状態で配布されることになり、図１０に示す実施形態の場合、秘匿情報２３''は配布用ファイル２０Ａ''内に組み込まれた状態で配布されることになる。このように、秘匿情報を配布用ファイル内に組み込んでしまえば、アプリケーション実行用コンピュータは、配布用ファイルを入手した時点で、秘匿情報も併せて入手することが可能になる。

ただ、秘匿情報の引き渡し方法は、必ずしも配布用ファイル内に組み込む方法に限定されるものではない。ここでは、秘匿情報の引き渡し方法の変形例を述べておく。図１５は、図５に示す基本的な実施形態について、秘匿情報の引き渡し方法を変えた変形例を示すブロック図である。図の上段はプログラム提供者Ａによって実行される配布プロセスを示し、下段はユーザＵによって実行される改竄チェックプロセスを示している。この変形例の特徴は、配布プロセスで作成した秘匿情報２３を、サーバ１００を介して改竄チェックプロセスに引き渡す方法を採る点である。

すなわち、図５に示す基本的な実施形態の場合、秘匿情報２３は配布用ファイル２０Ａに組み込まれて配布されることになるが、図１５に示す変形例の場合、秘匿情報２３はサーバ１００に格納され、その代わりに、この秘匿情報２３の所在を示す所在情報２４が配布用ファイル２０αに組み込まれて配布されることになる。図５に示す配布用ファイル２０Ａと図１５に示す配布用ファイル２０αとの相違は、前者の秘匿情報２３が後者では所在情報２４になっている点のみである。一般に、秘匿情報２３のデータ容量が嵩むケースでは、秘匿情報２３を配布用ファイル２０Ａに組み込んでしまうと、配布用ファイル２０Ａのデータ容量も嵩むことになる。このようなケースでは、図１５に示す変形例を採れば、秘匿情報２３に比べてデータ容量の小さい所在情報２４を組み込んて配布用ファイル２０αを作成することができるので、配布用ファイル２０αのデータ容量を抑えることができ便利である。

サーバ１００は、アプリケーション実行用コンピュータがネットワークを介してアクセス可能なサーバであれば、どのようなサーバであってもかまわない。ここに示す例では、インターネットに接続された任意のファイルサーバをサーバ１００として利用している。所在情報２４は、サーバ１００およびその中における秘匿情報２３の格納場所を特定する情報であり、具体的には、秘匿情報２３の格納場所を示すＵＲＬを所在情報２４として用いればよい。結局、図１５に示す変形例の場合、プログラム提供者Ａは、所在情報２４が組み込まれた配布用ファイル２０αを配布することになる。一方、ユーザＵが利用するアプリケーション実行用コンピュータは、この配布用ファイル２０αを入手することにより、所在情報２４（この例の場合は、秘匿情報２３の格納場所を示すＵＲＬ）を入手することができるので、この所在情報２４を用いてインターネットにアクセスし、秘匿情報２３を入手することが可能になる。

このように、この変形例においても、プログラム提供者ＡからユーザＵに対して、秘匿情報２３が引き渡される点は、これまで述べてきた実施形態と変わりはないので、秘匿情報２３を用いた改竄有無判定処理も、これまで述べてきた実施形態と同様の処理を行えばよいことになる。要するに、本発明の配布プロセスにおける配布用ファイル作成段階では、アプリケーションパッケージと、署名情報と、秘匿情報もしくは秘匿情報の所在を示す所在情報と、を含む配布用ファイルを作成すればよく、改竄チェックプロセスにおける第２の確認段階では、入力した配布用ファイルに基づいて秘匿化対象データおよび秘匿情報を入手し、秘匿化対象データに対する秘匿情報の正当性を確認すればよい。

配布用ファイル作成段階で、秘匿情報２３を含む配布用ファイル２０Ａを作成した場合（図５に示す実施形態の場合）は、第２の確認段階で、配布用ファイル２０Ａから秘匿情報２３を直接抽出することにより、秘匿情報２３の入手を行うことができる。これに対して、配布用ファイル作成段階で、秘匿情報２３を所定の格納場所（サーバ１００）に格納する処理を行うとともに、当該格納場所を示す所在情報２４を含む配布用ファイル２０αを作成した場合（図１５に示す変形例の場合）は、第２の確認段階で、配布用ファイル２０αから所在情報２４を抽出し、この所在情報２４に基づいて格納場所（サーバ１００）を認識し、格納場所（サーバ１００）から秘匿情報２３を取り出すことにより、当該秘匿情報の入手を行うことができる。

なお、サーバ１００から秘匿情報２３を入手する処理は、アプリケーション実行用コンピュータが、配布用ファイル２０αに含まれているアプリケーションについての第２の確認段階を実行するたびに毎回行うようにしてもよいが、実用上は、アプリケーション実行用コンピュータ内に、入力した個々の配布用ファイルについて、それぞれ秘匿情報を保存する保存場所（たとえば、アプリケーション実行用コンピュータ内の不揮発性メモリ内の、当該アプリケーションに割り当てられた領域）を設けておき、秘匿情報２３を一度入手したら、これをその保存場所に保存するようにし、次回からは、この保存場所に保存されている秘匿情報２３を利用するようにするのが好ましい。そうすれば、保存場所に秘匿情報２３を保存した後は、インターネットに接続できない状態でも、当該アプリケーションを起動させることができる。

すなわち、アプリケーション実行用コンピュータが、改竄チェックルーチンＦによって第２の確認段階を実行する際に、所定の保存場所に、必要な秘匿情報２３が保存されていない場合には、配布用ファイル２０αから所在情報２４を抽出し、この所在情報２４に基づいて格納場所（サーバ１００）を認識し、この格納場所（サーバ１００）から秘匿情報２３を取り出すことにより、当該秘匿情報の入手を行うとともに、入手した秘匿情報２３をアプリケーション実行用コンピュータ内の保存場所に保存する処理を行うようにすればよい。そして、アプリケーション実行用コンピュータが第２の確認段階を実行する際に、当該コンピュータ内の保存場所に、必要な秘匿情報２３が保存されている場合には、この保存場所から秘匿情報２３を取り出すことにより、当該秘匿情報の入手を行うようにすればよい。

もちろん、ここで述べる変形例は、図５に示す基本的な実施形態だけでなく、その他の実施形態に対しても適用可能である。また、配布プロセスにおいて、秘匿情報２３を任意のサーバに格納する際には、必ずしも１箇所のサーバ１００に格納しておく必要はなく、複数箇所に分散して格納するようにしてもよい。たとえば、秘匿情報２３を３つのファイルに分割し、第１の分割ファイルを第１のサーバ１０１に格納し、第２の分割ファイルを第２のサーバ１０２に格納し、第３の分割ファイルを第３のサーバ１０３に格納する、という格納方法を採ってもかまわない。この場合、所在情報２４は、これら３箇所の格納場所を示す情報ということになる。また、この場合、所在情報２４に、分割方法を示す情報も含ませておけば、改竄チェックプロセスにおいて、３箇所から入手した個々の分割ファイルに対して、分割方法を参照した合成処理を行い、元の秘匿情報２３を復元することができる。

ここで述べた変形例を採用する場合、改竄チェックルーチンＦは、配布用ファイル２０αから所在情報２４を抽出し、この所在情報２４に基づいて格納場所（たとえば、図１５のサーバ１００）を認識し、認識した格納場所から秘匿情報２３を取り出すことにより、当該秘匿情報の入手を行う必要がある。

また、アプリケーション実行用コンピュータ内に秘匿情報２３の保存場所を確保するようにする場合は、改竄チェックルーチンＦは、コンピュータ内に設けられた秘匿情報の保存場所に秘匿情報２３が保存されていない場合には、配布用ファイル２０αから所在情報２４を抽出し、この所在情報２４に基づいて格納場所を認識し、この格納場所から秘匿情報２３を取り出すことにより、当該秘匿情報の入手を行うとともに、入手した秘匿情報２３を保存場所に保存する処理を行い、この保存場所に秘匿情報２３が保存されている場合には、この保存場所から秘匿情報２３を取り出すことにより、当該秘匿情報の入手を行うようにすればよい。

なお、所在情報２４に基づいてサーバ１００から秘匿情報を入手する処理プロセスは、改竄チェックルーチンＦによって行ってもよいが、改竄チェックプログラム３０内に設けられた別なルーチンによって行ってもかまわない。また、図１５では、秘匿情報２３を格納する場所として、インターネットを介して接続されたサーバ１００を利用した例を示したが、秘匿情報２３を格納する外部の格納場所は、必ずしもサーバ装置である必要はない。たとえば、アプリケーション実行用コンピュータに接続可能なＩＣカードやＵＳＢメモリなどの記憶媒体を格納場所として、秘匿情報２３を格納するようにしてもかまわない。この場合、所在情報２４は、当該記憶媒体内の格納場所を示すことになる。

＜８−２：第１の特定鍵の引き渡し方法の変形例＞
続いて、第１の特定鍵Ｋ（ｓ１）（共通特定鍵Ｋ（ｓ０）を第１の特定鍵Ｋ（ｓ１）として利用する場合も含む）の引き渡し方法を述べる。本発明に係るアプリケーションプログラムの改竄検知方法では、改竄チェックルーチンＦが、第１の特定鍵Ｋ（ｓ１）を用いて秘匿化対象データＣに対する秘匿情報の正当性を確認する第２の確認段階を実行することになる。そして、たとえば、図５に示す実施形態では、改竄チェックプログラム３０内に改竄チェックルーチンＦと第１の特定鍵Ｋ（ｓ１）とを組み込み、これをユーザＵに配布することにより、アプリケーションプログラム実行用コンピュータへの引き渡しが行われるようにしていた。このように、第１の特定鍵Ｋ（ｓ１）を改竄チェックプログラム３０内に組み込んでしまえば、アプリケーション実行用コンピュータは、改竄チェックプログラム３０を入手した時点で、第１の特定鍵Ｋ（ｓ１）も併せて入手することが可能になる。

ただ、第１の特定鍵Ｋ（ｓ１）の引き渡し方法は、必ずしも改竄チェックプログラム３０内に組み込む方法に限定されるものではない。ここでは、第１の特定鍵Ｋ（ｓ１）の引き渡し方法の変形例を述べておく。図１６は、図５に示す基本的な実施形態について、第１の特定鍵Ｋ（ｓ１）の引き渡し方法を変えた変形例を示すブロック図である。図の上段はプログラム保証者Ｇによって実行される改竄チェックプログラムの配布プロセスを示し、下段はユーザＵによって実行される改竄チェックプロセスを示している。この変形例の特徴は、改竄チェック処理に必要な第１の特定鍵Ｋ（ｓ１）を、サーバ１００を介して引き渡す方法を採る点である。

すなわち、図５に示す基本的な実施形態の場合、第１の特定鍵Ｋ（ｓ１）は改竄チェックプログラム３０に組み込まれて配布されることになるが、図１６に示す変形例の場合、第１の特定鍵Ｋ（ｓ１）はサーバ１００に格納され、その代わりに、この第１の特定鍵Ｋ（ｓ１）の所在を示す所在情報３１が改竄チェックプログラム３０αに組み込まれて配布されることになる。なお、ここに示す改竄チェックプログラム３０αには、図示のとおり、改竄チェックルーチンＦおよび第１の特定鍵Ｋ（ｓ１）の所在を示す所在情報３１の他に、認証用データＤ（Ａ）および復号鍵Ｋ（ｄ）も組み込まれている。

この変形例においても、サーバ１００は、アプリケーション実行用コンピュータがネットワークを介してアクセス可能なサーバであれば、どのようなサーバであってもかまわないが、ここでは、インターネットに接続された任意のファイルサーバをサーバ１００として利用している。所在情報３１は、サーバ１００およびその中における第１の特定鍵Ｋ（ｓ１）の格納場所を特定する情報であり、具体的には、第１の特定鍵Ｋ（ｓ１）の格納場所を示すＵＲＬを所在情報３１として用いればよい。

なお、ここに示すサーバ１００には、図示のとおり、第１の特定鍵Ｋ（ｓ１）の他に、認証用データＤ（Ａ）および暗号鍵Ｋ（ｅ）も格納されている。このサーバ１００内の認証用データＤ（Ａ）は、改竄チェックプログラム３０α内に組み込まれている認証用データＤ（Ａ）と同一のデータである。また、サーバ１００内の暗号鍵Ｋ（ｅ）は、改竄チェックプログラム３０α内に組み込まれている復号鍵Ｋ（ｄ）に対応した鍵であり、暗号鍵Ｋ（ｅ）を用いて暗号化したデータは、復号鍵Ｋ（ｄ）を用いて復号することができる。逆に、復号鍵Ｋ（ｄ）を用いて暗号化したデータを、暗号鍵Ｋ（ｅ）を用いて復号することもできる。

このように、図１６に示す変形例の場合、プログラム保証者Ｇからは、所在情報３１が組み込まれた改竄チェックプログラム３０αが配布されるので、ユーザＵが利用するアプリケーション実行用コンピュータは、この所在情報３１（この例の場合は、第１の特定鍵Ｋ（ｓ１）の格納場所を示すＵＲＬ）を用いてインターネットにアクセスし、第１の特定鍵Ｋ（ｓ１）を入手することが可能になる。したがって、改竄チェックルーチンＦは、こうして入手した第１の特定鍵Ｋ（ｓ１）を用いて、これまで述べてきた実施形態と同様の第２の確認段階を実行することができる。

ところで、既に述べたとおり、第１の特定鍵Ｋ（ｓ１）がクラッカーＸの手に渡ると、クラッカーＸによる秘匿情報２３の改竄の可能性が高まることになるので好ましくない。そこで、図１６に示す変形例では、サーバ１００から第１の特定鍵Ｋ（ｓ１）を取り出す際に、認証プロセスおよび暗号化プロセスを行い、サーバ１００に対する直接攻撃により、第１の特定鍵Ｋ（ｓ１）が不正取得されることを防ぐようにしている。

すなわち、ここに示す例の場合、第１の特定鍵Ｋ（ｓ１）は、所定の認証用データＤ（Ａ）を用いた認証機能が備わった格納場所として機能するサーバ１００内に安全に保管されている。一方、改竄チェックプログラム３０α内にも、同一の認証用データＤ（Ａ）が含まれているので、改竄チェックプログラム３０αがインストールされたアプリケーション実行用コンピュータは、サーバ１００から第１の特定鍵Ｋ（ｓ１）の取り出しを行う際に、この認証用データＤ（Ａ）を利用した認証を行うことができる。サーバ１００は、外部からのアクセスがあった場合、所定の認証プロセスを実行し、正しい認証結果が得られた場合にのみ、第１の特定鍵Ｋ（ｓ１）の取り出しが行われるようにする。

上述したような認証プロセスの手続自体は公知の技術であるため、ここでは詳しい説明は省略するが、たとえば、図示の例の場合、改竄チェックプログラム３０α側に含まれている復号鍵Ｋ（ｄ）と、サーバ１００側に格納されている暗号鍵Ｋ（ｅ）を利用すれば、公開鍵暗号方式を利用した認証処理が可能である。ここで、暗号鍵Ｋ（ｅ）および復号鍵Ｋ（ｄ）は、公開鍵暗号方式による一対の鍵となるようにしておく。なお、ここでは、後述する第１の特定鍵Ｋ（ｓ１）の暗号化プロセスに準じて、便宜上、サーバ１００側の鍵を暗号鍵Ｋ（ｅ）と呼び、改竄チェックプログラム３０α側の鍵を復号鍵Ｋ（ｄ）と呼んでいるため、認証プロセスにおける暗号化／復号で果たす各鍵の役割は逆になる。すなわち、改竄チェックプログラム３０αがサーバ１００に対して第１の特定鍵Ｋ（ｓ１）の取出要求を行う際には、認証用データＤ（Ａ）を復号鍵Ｋ（ｄ）で暗号化してサーバ１００に送信し、サーバ１００側では、これを暗号鍵Ｋ（ｅ）を用いて復号した上で、格納されている認証用データＤ（Ａ）と一致するか否かのチェックを行う。そして、両者が一致すれば、正しい認証結果が得られたものとして、第１の特定鍵Ｋ（ｓ１）を返信する処理を行えばよい。

一方、第１の特定鍵Ｋ（ｓ１）を返信する経路上で、クラッカーＸが、これを不正取得することを防ぐためには、第１の特定鍵Ｋ（ｓ１）に対する暗号化プロセスが有効である。そこで、図１６に示す例の場合、アプリケーション実行用コンピュータが、サーバ１００から第１の特定鍵Ｋ（ｓ１）の取り出しを行う際に、通信路上を第１の特定鍵Ｋ（ｓ１）が暗号鍵Ｋ（ｅ）によって暗号化された状態で送信されるようにしている。すなわち、サーバ１００は、要求元となるアプリケーション実行用コンピュータに対して第１の特定鍵Ｋ（ｓ１）を送信する際に、暗号鍵Ｋ（ｅ）によって暗号化してから送信する。アプリケーション実行用コンピュータは、受信後に、これを復号鍵Ｋ（ｄ）で復号すれば、第１の特定鍵Ｋ（ｓ１）を取得することができる。

もちろん、上述した認証プロセスと暗号化プロセスのいずれか一方だけを実施してもかまわないが、実用上は、これら双方を実施することにより、クラッカーＸがサーバ１００から第１の特定鍵Ｋ（ｓ１）を不正入手することを効果的に防止することが可能になる。

このように、改竄チェックプログラム３０α内に、改竄チェックルーチンＦと、この改竄チェックルーチンＦが改竄チェックを行うために必要な第１の特定鍵Ｋ（ｓ１）の格納場所を示す所在情報３１と、を含ませておくようにすれば、第２の確認段階で、アプリケーション実行用コンピュータが、改竄チェックプログラム３０αから所在情報３１を抽出し、この所在情報３１に基づいて第１の特定鍵Ｋ（ｓ１）の格納場所を認識し、当該格納場所から取り出した第１の特定鍵Ｋ（ｓ１）を用いて改竄チェックルーチンＦを実行することができる。

なお、サーバ１００から第１の特定鍵Ｋ（ｓ１）を入手する処理は、アプリケーション実行用コンピュータが、改竄チェックルーチンＦに基づいて第２の確認段階を実行するたびに毎回行うようにしてもよいが、実用上は、アプリケーション実行用コンピュータ内に、入手した第１の特定鍵Ｋ（ｓ１）を保存する保存場所（たとえば、アプリケーション実行用コンピュータ内の不揮発性メモリ内の、改竄チェックプログラムに割り当てられた領域）を設けておき、第１の特定鍵Ｋ（ｓ１）を一度入手したら、これをその保存場所に保存するようにし、次回からは、この保存場所に保存されている第１の特定鍵Ｋ（ｓ１）を利用するようにするのが好ましい。そうすれば、保存場所に第１の特定鍵Ｋ（ｓ１）を保存した後は、インターネットに接続できない状態でも改竄チェックを行うことができる。

すなわち、アプリケーション実行用コンピュータが、改竄チェックルーチンＦによって第２の確認段階を実行する際に、所定の保存場所に、第１の特定鍵Ｋ（ｓ１）が保存されていない場合には、改竄チェックプログラム３０αに含まれている所在情報３１を抽出し、この所在情報３１に基づいて格納場所（サーバ１００）を認識し、この格納場所（サーバ１００）から第１の特定鍵Ｋ（ｓ１）を取り出すことにより、第１の特定鍵Ｋ（ｓ１）の入手を行うとともにこれをアプリケーション実行用コンピュータ内の保存場所に保存する処理を行うようにすればよい。そして、アプリケーション実行用コンピュータが第２の確認段階を実行する際に、当該コンピュータ内の保存場所に、第１の特定鍵Ｋ（ｓ１）が保存されている場合には、この保存場所から第１の特定鍵Ｋ（ｓ１）を取り出すことにより、当該第１の特定鍵Ｋ（ｓ１）の入手を行うようにすればよい。入手した第１の特定鍵Ｋ（ｓ１）を用いて改竄チェックルーチンを実行する点は、これまで述べてきた基本的実施形態と同様である。

なお、所在情報３１に基づいてサーバ１００から第１の特定鍵Ｋ（ｓ１）を入手する処理プロセスは、改竄チェックルーチンＦによって行ってもよいが、改竄チェックプログラム３０α内に設けられた別なルーチンによって行ってもかまわない。また、図１６では、第１の特定鍵Ｋ（ｓ１）を格納する場所として、インターネットを介して接続されたサーバ１００を利用した例を示したが、第１の特定鍵Ｋ（ｓ１）を格納する外部の格納場所は、必ずしもサーバ装置である必要はない。たとえば、アプリケーション実行用コンピュータに接続可能なＩＣカードやＵＳＢメモリなどの記憶媒体を格納場所として、第１の特定鍵Ｋ（ｓ１）を格納するようにしてもかまわない。この場合、所在情報３１は、当該記憶媒体内の格納場所を示すことになる。

第１の特定鍵Ｋ（ｓ１）をサーバ１００に格納する形態をとる変形例では、プログラム保証者Ｇが改竄チェックプログラム３０αを配布した後も、第１の特定鍵Ｋ（ｓ１）を変更する柔軟な対応が可能になる。すなわち、ユーザに配布した改竄チェックプログラム３０α内には、所在情報３１しか含まれていないため、プログラム保証者Ｇは、サーバ１００に格納する第１の特定鍵Ｋ（ｓ１）を変更することにより、改竄チェックルーチンＦが実際に利用する第１の特定鍵Ｋ（ｓ１）を変更することが可能になる。

もちろん、サーバ１００内の複数箇所にそれぞれ異なる第１の特定鍵Ｋ（ｓ１）を格納しておき、所在情報３１によって、実際に取得される鍵を変えるようにすることもできる。たとえば、改竄チェックの対象となるアプリケーションプログラムごとに、それぞれ異なる鍵を用いてチェックを行うような運用を採るのであれば、改竄チェックプログラム３０α内にキーテーブルを用意し、このキーテーブル内に、個々のアプリケーションプログラムごとに異なる所在情報を収容しておくようにすればよい。サーバ１００から第１の特定鍵Ｋ（ｓ１）を入手する際には、このキーテーブルを参照して、チェックの対象となるアプリケーションプログラムに応じた格納場所から鍵の入手を行うようにすればよい。

＜＜＜ §９．ＯＳプログラムへの組み込み＞＞＞
これまで述べてきた実施形態は、アプリケーションパッケージ２１に対する署名情報２２の正当性を確認する第１の確認段階（アプリケーションパッケージ２１が改竄されていないことを、署名情報２２を利用して確認する段階）を、アプリケーション実行用のコンピュータのＯＳプログラムによって実行し、秘匿化対象データＣに対する秘匿情報２３の正当性を確認する第２の確認段階（署名情報２２が改竄されていないことを、秘匿情報２３を利用して確認する段階）を、改竄チェックプログラム３０，３０Ｇ，３０αに含まれる改竄チェックルーチンＦによって実行する、という役割分担を行っている。図７の流れ図における改竄チェックプロセスは、正に、このような役割分担に基づいて行われるものであり、ステップＳ６〜Ｓ１５の各ブロックの脇に記載された「ＯＳプログラム」なる括弧書きの処理は当該処理がＯＳプログラムによって実行されることを示し、「改竄チェックプログラム」なる括弧書きの処理は当該処理が改竄チェックプログラムによって実行されることを示している。

このような役割分担は、Android仕様のアプリケーションを配布して、Android端末においてこれを実行する環境では極めて有効である。すなわち、上記役割分担を行えば、本発明を実施する上で、Android端末側には何ら改変を加える必要はなく、Android端末には、改竄チェックの対象となるアプリケーションプログラムとともに、改竄チェックプログラムをＡＰＫファイルとして配布すればよい。いずれもAndroid端末から見れば１つのアプリケーションプログラムであるので、本発明に係る改竄検知方法を実行するにあたって、AndroidＯＳに対する改変は不要である。

しかしながら、本発明に係るアプリケーションプログラムの改竄検知方法は、現在のAndroid仕様の端末を想定したものに限定されるものではないので、上記役割分担は、本発明に必須のものではない。

たとえば、将来、Android仕様が変更になり、AndroidＯＳ自身に改竄チェックプログラム３０の機能が組み込まれるようになれば、第２の確認段階はＯＳプログラムによって実行されることになる。この場合、第１の確認段階と第２の確認段階との双方が、ＯＳプログラムによって行われることになる。逆に、将来、Android仕様が変更になり、現AndroidＯＳの機能から、第１の確認段階を行う処理機能が除外された場合には、第１の確認段階と第２の確認段階との双方を、改竄チェックプログラム３０側で行うようにすることも可能である。

ここでは、AndroidＯＳ自身に改竄チェックプログラム３０の機能を組み込んだ場合の本発明の処理手順を、図１７の流れ図を参照して説明する。この図１７の流れ図に示す手順も、準備プロセス、配布プロセス、改竄チェックプロセスによって構成されている。そして、準備プロセスのステップＳ０では、アプリケーションプログラムを実行するためのアプリケーション実行用コンピュータ（Android端末）が、第１の特定鍵Ｋ（ｓ１）を用いて改竄チェックを行う改竄チェックルーチンＦを含む改竄チェックプログラムをインストールする改竄チェックプログラム準備段階が行われる。

但し、これまで述べてきた実施形態の場合、改竄チェックプログラムは、改竄チェックの対象となるアプリケーションプログラムとは別のアプリケーションプログラムによって構成されており、ステップＳ０の改竄チェックプログラム準備段階では、この１アプリケーションプログラムとして与えられた改竄チェックプログラムをインストールする処理が行われる。これに対して、図１７に示す例の場合、改竄チェックプログラムは、ＯＳプログラム（AndroidＯＳ）の一部によって構成されるため、ステップＳ０の改竄チェックプログラム準備段階とは、アプリケーションプログラム実行用コンピュータ（Android端末）にＯＳプログラム（AndroidＯＳ）をインストールする処理として行われることになる。したがって、このステップＳ０は、通常は、Android端末の供給元が出荷前に行う作業ということになる（もちろん、ユーザ自身がバージョンアップなどの目的でAndroidＯＳをインストールする場合は、そのときにステップＳ０の処理が行われる）。

一方、ステップＳ１〜Ｓ５の配布プロセスは、改竄チェックの対象となるアプリケーションプログラムを配布するためのプロセスであり、プログラム提供者Ａによって行われる処理である。この配布プロセスを構成するステップＳ１〜Ｓ５の処理は、図７の流れ図におけるステップＳ１〜Ｓ５の処理と全く同一であり、詳細は§４で述べたとおりである。

これに対して、ステップＳ１６〜Ｓ２２の改竄チェックプロセスは、アプリケーションプログラム実行用コンピュータ（Android端末）で実行される処理ということになる。図７の流れ図におけるステップＳ６〜Ｓ１５の処理と、図１７の流れ図におけるステップＳ１６〜Ｓ２２の処理とは、改竄チェックを行う基本原理に関しては全く同じであるが、前者では、ＯＳプログラムと改竄チェックプログラムとの役割分担によって改竄チェックが行われていたのに対して、後者では、すべての改竄チェックがＯＳプログラムによって実行されることになる。

すなわち、まずステップＳ１６のファイル入力段階では、アプリケーション実行用コンピュータ（Android端末）に、上述した配布プロセスによって配布された配布用ファイル２０Ａが入力される。具体的には、ユーザＵが、ＡＰＫファイルの配布サイトからインターネット経由で配布用ファイル２０Ａをダウンロードし、これをインストールことにより、ステップＳ１６のファイル入力段階が行われる。Android端末の場合、このような処理は、ＯＳプログラムの基本機能によって実行される。

続くステップＳ１７以降の処理は、ステップＳ１６で入力したアプリケーションプログラムについての起動指示が与えられた場合に実行される。前述したとおり、Android端末の場合、個々のアプリケーションプログラムに対する起動指示は、ユーザＵがアイコンをタップするなどの操作を行うことにより与えられる場合もあれば、別なアプリケーションプログラムからの要請により与えられる場合もあるし、外部からアクセスしてきた何らかのサービスに基づいて与えられる場合もある。いずれの場合も、AndroidＯＳが当該起動指示を認識し、対象となるアプリケーションプログラムを起動する処理を行うことになる。

この起動処理の一環として、AndroidＯＳが第１の確認段階の処理を実行することは、既に述べたとおりである。すなわち、特定のアプリケーションプログラムに対する起動指示が与えられると、AndroidＯＳにより、まず、ステップＳ１７における第１の確認段階の処理が行われる。この第１の確認段階では、前述したとおり、アプリケーションパッケージ２１に対する署名情報２２の正当性を確認する処理が行われる。すなわち、起動指示が与えられたアプリケーションプログラムの配布用ファイル２０Ａについて、Ａの署名情報２２に含まれているプログラム提供者Ａの第２の鍵Ｋ（ａ２）を用いた復号を利用した署名確認処理を行って、アプリケーションパッケージ２１に対する署名情報２２の正当性が確認される。

ステップＳ１７の第１の確認段階において肯定的な結果が得られた場合、すなわち、アプリケーションパッケージ２１に対する署名情報２２の正当性が確認された場合には、ステップＳ１８を経てステップＳ１９へと進み、第２の確認段階が実行される。この、第２の確認段階は、AndroidＯＳに組み込まれることになった改竄チェックプログラムによって実行される処理であり、既に述べたとおり、署名情報２２に対する秘匿情報２３の正当性を確認する処理である。改竄チェックプログラムがAndroidＯＳに組み込まれているため、ステップＳ１７の第１の確認段階に引き続いて、ステップＳ１９の第２の確認段階を行うことができるようになる。

ステップＳ２０では、ステップＳ１９の第２の確認段階の結果に応じて、否定的な結果が得られた場合にはステップＳ２１へ進み、肯定的な結果が得られた場合にはステップＳ２２へ進む分岐処理が行われる。また、ステップＳ１７の第１の確認段階において否定的な結果が得られた場合には、ステップＳ１８を経てステップＳ２１へ進む分岐処理が行われる。

このように、ステップＳ１７の第１の確認段階で否定的な結果が得られた場合には、ステップＳ１８からステップＳ２１へと進むことになり、ステップＳ１９の第２の確認段階で否定的な結果が得られた場合には、ステップＳ２０からステップＳ２１へと進むことになる。いずれの場合も改竄ありとの判定がなされたことになるので、ステップＳ２１では、当該アプリケーションプログラムの実行を中止する処理が行われる。一方、第１の確認段階および第２の確認段階の双方において肯定的な結果が得られた場合には、改竄なしとの判定の下にステップＳ２０からステップＳ２２へと進み、当該アプリケーションプログラムの実行段階が行われる。すなわち、制御がＯＳから当該アプリケーションプログラムへと移り、当該アプリケーションプログラムを構成するルーチンの処理が開始される。別言すれば、ＯＳプログラムによって、当該アプリケーションプログラムの起動が正常に行われることになり、ユーザＵは、起動したアプリケーションプログラムを利用することができる。

ステップＳ１６〜Ｓ２２の各ブロックの脇に記載された「ＯＳプログラム」なる括弧書きの処理は当該処理がＯＳプログラムによって実行されることを示している。特に、「ＯＳプログラム（改竄チェック）」なる括弧書きの処理は当該処理がＯＳプログラムに組み込まれることになった改竄チェックプログラムによって実行されることを示している。なお、ステップＳ２１の実行中止処理は、ＯＳプログラムによって実行される処理であるが、ステップＳ２２の実行段階の処理は、当該アプリケーションプログラムによって実行される処理であり、脇の「ＯＳプログラムアプリケーションプログラム」なる括弧書きは、これを示すものである。

なお、ステップＳ２１の実行中止を行う場合は、たとえば「アプリケーションプログラム○○（改竄ありと判定されたアプリケーションプログラムの名前）は改竄されているため起動できません」のような判定メッセージを提示し、「改竄あり」との検知結果に基づいて実行が中止されたことをユーザＵに報知するようにするのが好ましい。

このように、改竄チェックプログラムの機能をＯＳプログラムに組み込んだ場合のメリットは、第１の確認段階および第２の確認段階の双方の処理をＯＳプログラムに担当させることができるため、アプリケーションプログラムの起動時に第１の確認段階および第２の確認段階の双方を実施することができるようになり、更に、その結果、改竄ありとの判定がなされた場合には、ＯＳプログラムの権限に基づいて、当該アプリケーションプログラムの実行を中止する措置を採ることができる点である。すなわち、ステップＳ２１では、制御をアプリケーションプログラムに移行することなしに、当該アプリケーションプログラムの実行を中止してしまうため、改竄されたアプリケーションプログラムは、その一部たりとも実行されることはなく、十分な安全性が確保されることになる。また、ＯＳプログラムの権限により、改竄ありと判定されたアプリケーションプログラムについては、強制的なアンインストール処理を行ったり、実行権剥奪処理などを行ったりすることも可能である。

以上、アプリケーションプログラムに対して起動指示が与えられた場合に、第１の確認段階および第２の確認段階を実行して、改竄チェックが行われる例を説明したが、改竄チェックを行うタイミングは、必ずしも起動指示が与えられた場合に限定されるものではない。たとえば、ファイル入力段階Ｓ１６によってアプリケーションプログラムがダウンロードされた直後やインストールされた直後に、第１の確認段階および第２の確認段階を実行して改竄チェックを行うようにしてもかまわない。

アプリケーションプログラムのダウンロードやインストールは、ＯＳプログラムの管理下で行われるので、ＯＳプログラムは、アプリケーションプログラムのダウンロードやインストールが行われた時点で、上記改竄チェックを行うことが可能である。この場合、必要なら「いまダウンロードしたアプリは改竄されています」や「いまインストールしたアプリについては改竄検知はされませんでした」といったメッセージにより、チェック結果をユーザに報知するようにしてもよい。

＜＜＜ §１０．実行許可リストに基く実行制御＞＞＞
ここでは、本発明に係るアプリケーションプログラムの改竄検知方法の好適な応用例を述べる。この応用例の特徴は、アプリケーションプログラムの実行プロセスにおいて、実行許可リストに予め登録されているアプリケーションプログラムについてのみ、その実行を許可するという実行制御方法を採用しつつ、§１〜§９において述べた改竄検知方法を実行し、改竄が検知されなかったアプリケーションプログラムについては、リストへの自動登録を行うようにする点にある。そこで、まず、実行許可リストに基いてアプリケーションプログラムの実行制御を行う具体的な方法を説明する。

ここでは、これまで述べてきた例と同様に、AndroidＯＳを採用したスマートフォンやタブレット型電子機器（いわゆる、Android端末）への適用例を述べることにする。この場合、Android端末に与えられるアプリケーションプログラムのデータファイルは、たとえば、図５に示すような配布用ファイル２０Ａ（ＡＰＫファイル）の形式で配布されることになる。また、ここでは、§１〜§８において述べたように、改竄チェックプログラムが、１つのアプリケーションプログラムとして用意されている場合についての実施例を述べることにする。

ここで述べる実行許可リストに基く実行制御方法それ自体は、本願発明者が従来から提案している方法である。この実行制御方法では、アプリケーションプログラムの実行端末において、実行許可リストに基づく制御を行うために、専用のプログラムが用意される。このプログラムは、ＯＳの管理下で動作するアプリケーションプログラムの１つであるが、その役割は、専ら他のアプリケーションプログラムの動作を監視し、その制御を行うことにある。そこで、ここでは、このプログラムのことを、他のアプリケーションプログラムとは区別して「監視プログラム」と呼ぶことにする。

既に述べたとおり、Androidをはじめとする多くのＯＳは、複数のアプリケーションプログラムを並行して実行させるマルチタスク処理機能を有しており、複数のアプリケーションプログラムを所定のタイミングで順次切り替えながらＣＰＵに実行させる処理を行うことができる。これにより、複数のアプリケーションプログラムを同時に起動状態にして、これらを時分割で切り替えることにより、あたかも複数のアプリケーションプログラムが同時に実行されているような制御が可能になる。

そこで、§４では、改竄チェックプログラム３０を、いわゆる「常駐プログラム」として常に起動状態に維持しておき、新たに起動されたアプリケーションプログラムに対する改竄チェックを実行させるような実施形態を述べた。ここで述べる監視プログラムも、「常駐プログラム」として常に起動状態に維持するようにして、他のアプリケーションプログラムの監視が行えるようにする。上述したように、マルチタスク処理機能を有するＯＳ制御下では、複数のアプリケーションプログラムを同時に起動状態にすることができるので、監視プログラムを常に起動状態に維持したとしても、他のアプリケーションプログラムの起動に支障が生じることはない。なお、この監視プログラムそれ自体が攻撃されて改竄されてしまうことを防ぐために、実用上は、何らかの耐タンパ化処理が施された監視プログラムを用いるのが好ましい。

図１８は、アプリケーションプログラム実行用コンピュータ（Android端末）に組み込まれた監視プログラムによって実行される監視ルーチンの手順を示す流れ図である。このような監視ルーチンをもつ監視プログラム自体は、本願発明者によって従来から提案されているものである。標題部に「監視プログラム(1)」と記載されているのは、ここに示す監視プログラムの手順が、従来提案型の手順であることを示すものである。この§１０で述べる本発明の応用例の特徴は、この図１８の「監視プログラム(1)」として示す従来の監視プログラムにおける手順を簡略化することにある（簡略化した手順は、図２２において「監視プログラム(2)」として後述する）。

ここでは、まず、図１８に「監視プログラム(1)」として示す従来提案型の監視プログラムの機能を説明する。この監視プログラムの役割は、常時、アプリケーションプログラムの起動を監視し、新たなアプリケーションプログラムの起動が検知された場合に、当該アプリケーションプログラムが実行許可リストに掲載されているか否かを判断し、掲載されていた場合にはそのまま実行を許可するが、掲載されていなかった場合には、実行を一時中止してリストに登録するか否かをユーザに尋ねることにある。

はじめに、ステップＳ３１において、現在、起動状態にあるアプリケーションプログラムの識別コードを認識する起動アプリ認識段階が実行される。Androidをはじめとする一般的なＯＳには、個々のアプリケーションプログラムについて、識別コード・起動時・終了時を示すログ情報を記録する処理機能が備わっている。したがって、監視プログラムによって起動アプリ認識段階Ｓ３１を実行する際には、このログ情報を参照することにより、現時点で起動状態にあるアプリケーションプログラムの識別コードを認識することができる。

図１９は、AndroidＯＳによって作成されたログ情報の一例を示す図である。この例では、ＡＰ３，ＡＰ１，ＡＰ６といったアプリケーションプログラムのファイル名を個々のアプリケーションを特定する識別コードとして用いている。もちろん、識別コードとしては、アプリケーションプログラムを特定することができれば、どのような情報を用いてもかまわない。以下の実施例では、便宜上、識別コードという文言を用いているが、ここで言う「識別コード」とは、「識別情報」とも言うべき広義のコードを意味するものである。そして、この識別コードと、起動もしくは終了のいずれか一方の動作と、日時と、を並べた１行分のデータが単位ログを構成しており、このような単位ログを時系列で複数組並べた集合体によってログ情報が構成されている。

具体的には、１行目の単位ログは、識別コード「ＡＰ３」で特定されるアプリケーションＡＰ３が、２０１２年７月２１日１６時５１分に起動されたことを示し、２行目の単位ログは、識別コード「ＡＰ１」で特定されるアプリケーションＡＰ１が、２０１２年７月２１日１６時５８分に起動されたことを示し、３行目の単位ログは、識別コード「ＡＰ１」で特定されるアプリケーションＡＰ１が、２０１２年７月２１日１７時１４分に終了されたことを示し、４行目の単位ログは、識別コード「ＡＰ６」で特定されるアプリケーションＡＰ６が、２０１２年７月２１日１７時３３分に起動されたことを示し、５行目の単位ログは、識別コード「ＡＰ３」で特定されるアプリケーションＡＰ３が、２０１２年７月２１日１７時５３分に終了されたことを示している。結局、図示のようなログ情報が得られた時点では、アプリケーションＡＰ６のみが起動状態であるとの認識がなされる。

AndroidＯＳは、インストールされているアプリケーションプログラムが起動されたり、終了されたりするたびに、図示のようなログ情報をＯＳ用の記録領域に記録してゆくことになる。もちろん、監視プログラムもアプリケーションプログラムの１つであるので、監視プログラム自身の起動や終了を示すログも、ログ情報として記録されることになる。

一方、監視プログラム用の記録領域には、図２０に例示するような実行許可リストが用意されている。この実行許可リストは、実行が許可されているアプリケーションプログラムの識別コードを記録したリストであり、いわば「ホワイトリスト」と呼ぶべきリストである。図２０(a) に示す例は、ＡＰ１，ＡＰ２，ＡＰ３といったアプリケーションプログラムのファイル名を個々のアプリケーションを特定する識別コードとして用い、これら識別コードを列挙することにより実行許可リストが構成されている。

これに対して、図２０(b) に示す例は、アプリケーションプログラムのファイル名にそのバージョン番号を括弧書きで付加したものを識別コードとして用いたものであり、バージョンが異なるアプリケーションプログラムには、それぞれ異なる識別コードが付与され、相互に区別されることになる。たとえば、同一のファイル名ＡＰ１をもったアプリケーションプログラムであっても、バージョン１．０のプログラムには識別コードＡＰ１（１．０）が付与され、バージョン２．０のプログラムには識別コードＡＰ１（２．０）が付与され、相互に異なるアプリケーションプログラムとして取り扱われることになる。なお、バージョンを区別して取り扱う場合は、図１９に示すログ情報にも、ＡＰ１（１．０）のようにバージョン番号を付加した識別コードを用いるようにする。

さて、図１８に示す起動アプリ認識段階Ｓ３１において、現時点で起動状態にあるアプリケーションプログラム（以下、単に、起動アプリという）の識別コードが認識できたら、続いて、認識した識別コードが実行許可リストに登録されているか否かを判定する登録有無判定段階が実行される。すなわち、ステップＳ３２において、図２０(a) に示すような実行許可リストが参照され、ステップＳ３３において、認識された起動アプリの識別コードがリストに掲載されているか否かが判定される。なお、ステップＳ３１において起動アプリが複数認識された場合は、ステップＳ３２以下の処理は、ステップＳ３８を経て、個々の起動アプリごとにそれぞれ繰り返し実行されることになる。

前述したように、図１９に示すようなログ情報が得られた場合は、アプリケーションＡＰ６が起動アプリとして認識されるので、ステップＳ３２において、実行許可リストを参照することにより、識別コードＡＰ６が掲載されているか否かが判定される。ここで、図２０(a) に示すような実行許可リストが用意されていたとすると、識別コードＡＰ６は掲載されているため、起動アプリＡＰ６は登録済みのアプリケーションプログラムと判定されることになる。その結果、ステップＳ３３からステップＳ３８へ進むことになる。

これに対して、登録有無判定段階において未登録と判定された場合、すなわち、ステップＳ３３においてリストに掲載されていないと判定された場合は、ステップＳ３４へ進み登録照会段階が行われる。たとえば、ログ情報から、アプリケーションプログラムＡＰ７が起動アプリとして認識された場合は、識別コードＡＰ７は図２０(a) に示す実行許可リストには掲載されていないので、未登録アプリと判定される。その結果、ステップＳ３３からステップＳ３４へと進み、登録照会段階が実行される。

ステップＳ３４の登録照会段階では、当該未登録アプリＡＰ７を実行許可リストに登録するか否かをユーザに問い合わせる処理が行われる。たとえば、Android端末のディスプレイ画面上に、図２１に示すようなメッセージ画面を提示する処理を行えばよい。ユーザは、このようなメッセージ画面による問い合わせに対して、「登録する」ボタンまたは「登録しない」ボタンをタップすることにより回答を行う。「登録する」旨の回答は、未登録アプリＡＰ７を登録して実行する指示に相当し、「登録しない」旨の回答は、未登録アプリＡＰ７を登録せず、実行もしない指示に相当する。

ユーザがいずれかのボタンをタップして、問い合わせに対する回答を行うと、当該回答に基づいて回答処理段階が行われる。すなわち、「登録する」ボタンのタップによって登録する旨の回答があった場合には、ステップＳ３５からステップＳ３６へと進み、当該未登録アプリＡＰ７の識別コードを新たに実行許可リストに登録する処理が行われる。この場合、起動状態にある当該アプリＡＰ７は、正式に実行が許可されたことになり、そのまま実行し続けることになる。一方、「登録しない」ボタンのタップによって登録しない旨の回答があった場合には、ステップＳ３５からステップＳ３７へと進み、当該未登録アプリＡＰ７の実行を中止させる処理が行われる。

以上述べたステップＳ３２〜Ｓ３７の処理が、全起動アプリについて完了するまで、ステップＳ３８を介して繰り返し実行されることになる。そして、全起動アプリについて処理が完了したら、ステップＳ３８からステップＳ３９へ進み、監視プログラムに対する終了指示が与えられていない限り、再び、ステップＳ３１からの処理が繰り返されることになる。前述したとおり、この監視プログラムは、本来、「常駐プログラム」として常に起動状態に維持され、他のアプリケーションプログラムの監視を行うべきものである。したがって、通常は、ユーザによって監視プログラムに対する終了指示が与えられることはなく、ステップＳ３９からステップＳ３１へ戻る処理が繰り返されることになる。

マルチタスク処理機能を有するＯＳ制御下では、ＯＳプログラムおよび同時に起動状態となっている複数のアプリケーションプログラムが所定のタイミングで切り替えられながら順番に実行されることになる。したがって、図１８に示す監視プログラム(1) の手順においても、ある時点で中断され、別なアプリケーションプログラムの実行に制御が移り、再び監視プログラムに制御が戻ってきた時点で中断されていた手順が再開される、という処理が繰り返されることになる。§４で述べたように、改竄チェックプログラム３０を「常駐プログラム」として常に起動状態に維持した場合は、マルチタスク処理機能を有するＯＳの切替制御により順番がまわってきたときに、起動状態にあるアプリケーションプログラムに対する改竄チェックが実行されることになる。

もっとも、マルチタスク処理によるアプリケーションプログラムの切替期間は、ｍｓｅｃ程度のオーダーであるため、ユーザの立場からは、監視プログラムや改竄チェックプログラムを含めた複数のアプリケーションプログラムが同時に動作しているように見える。たとえば、新たなアプリケーションプログラムＡＰ７を起動させると、監視プログラムに制御が移った段階で、アプリＡＰ７が起動アプリとして認識され、ステップＳ３４の登録照会段階が行われる。したがって、ユーザから見ると、アプリＡＰ７を起動させる操作を行ったら、直ちに図２１に示すようなメッセージ画面が表示された状態になるので、監視プログラムの処理動作に切り替わったという違和感は生じない。

なお、監視プログラムもアプリＡＰ７も、アプリケーションプログラムという点では対等であり、いずれもＯＳプログラムの制御下で動作するプログラムであるが、ＯＳの機能を利用して、一方のアプリケーションプログラムから他方のアプリケーションプログラムを強制終了させることが可能である。ステップＳ３７の実行中止処理も、このようなＯＳの機能を利用して、監視プログラムからアプリＡＰ７を強制終了させる方法を採ればよい。具体的には、監視プログラムからＯＳに対して、アプリＡＰ７を強制終了させるコマンドを引き渡すようにすれば、ＯＳの制御機能により、アプリＡＰ７を強制終了させ、実行を中止させることができる。

結局、監視プログラムは、図１８に示す手順を継続的に実行することにより、実行許可リストに登録されていない未登録アプリが起動状態になったか否かを常に監視する処理を行い、もし未登録アプリが起動状態になっていた場合には、ステップＳ３４の登録照会段階を実行し、ユーザの回答に応じて、当該未登録アプリを登録して実行を許可するか、登録せずに実行を中止させるか、いずれかの処理を採ることになる。かくして、実行許可リストに登録されているアプリケーションプログラムのみが実行を許可されるような制御が可能になる。

以上、図１８の流れ図を参照しながら、従来提案型の監視プログラム(1) の手順を説明した。この手順によれば、ユーザがホーム画面やアプリ画面からアイコンをタップして未登録の「通常アプリ」を起動したり、他のアプリケーションプログラムからの指示に基づいて未登録の「通常アプリ」が起動したりした場合、図２１のようなメッセージが提示され、実行許可リストに登録するか否かの選択を迫られることになる。Android端末の場合、本発明に係る改竄チェックプログラムの有無に拘らず、「通常アプリ」を起動した場合、ＯＳプログラムによる署名情報の正当性確認（第１の確認段階）は必ず実施されるので、ユーザは、当該「通常アプリ」の安全性をある程度認識することができる。ただ、前述したとおり、署名情報自体が改竄されているケースもあるので、安全性はそれほど高いものではない。したがって、ユーザは、当該アプリの実行により得られるであろうメリットと、改竄されていた場合に被るであろう損害のデメリットとを天秤にかけ、「登録する」／「登録しない」のいずれかを選択することになる。

しかしながら、実際には、上記運用は必ずしも奏功していない。その第１の理由は、一般ユーザにとって、個々のアプリケーションプログラムが改竄されているか否かを判定することが難しいためである。一般ユーザにとって、アプリケーションプログラムの信頼性を評価する手掛かりは、著名なソフトウエアであるとか、信頼性あるベンダーから供給されたソフトウエアであるとか、信頼性あるサイトからダウンロードしたソフトウエアであるといった情報であるが、クラッカーによって改竄されたソフトウエアが流通した場合、これらの手掛かりは役に立たない。したがって、実用上、一般ユーザが、個々のアプリケーションプログラムについて、改竄されているか否かを判定することは極めて困難である。

そして、第２の理由は、一般ユーザにとって、図２１に示すようなメッセージに応じて、未登録アプリを実行許可リストに手動登録する作業は煩雑であり、事実上、どのようなアプリケーションプログラムであっても「登録する」ボタンをタップすることが習慣化してしまうためである。もちろん、Android端末の工場出荷時にプリインストールされているアプリケーションプログラム（安全性が保証されているプログラム）については、当初から実行許可リストに掲載しておくようにすれば、初回起動時にユーザが手動登録の操作を行うことを省くことができるが、端末購入後にユーザがダウンロードした「通常アプリ」については、初回起動時にユーザが手動登録せざるを得ない。

この§１０で述べる応用例は、この監視プログラムと、§１〜§８で述べた改竄チェックプログラムと、ＯＳプログラムとを協働させ、改竄なしと判定されたアプリケーションプログラムについては、実行許可リストに自動登録する処理を行うようにしたものである。これにより、客観的な判定手法により改竄なしと判定されたアプリケーションプログラムについては、ユーザに登録作業の負担を課すことなしに、実行許可リストへの自動登録を行うことが可能になる。

そのため、ここで述べる実施形態における監視プログラムでは、図１８に示す「監視プログラム(1)」の手順に代えて、より簡潔な「監視プログラム(2)」の手順を採用する。ここで述べる「監視プログラム(2)」の手順は、ＯＳプログラムおよび改竄チェックプログラムによる改竄チェックの結果を利用して実現されるものである。そこで、以下、この「監視プログラム(2)」の手順を、ＯＳプログラムの手順および改竄チェックプログラムの手順と連携させた一連の流れとして説明する。

図２２は、通常アプリを起動したときの、ＯＳプログラム、改竄チェックプログラム、監視プログラムの連携した処理手順を示す流れ図である。ここでいう「通常アプリ」とは、「監視プログラム」および「改竄チェックプログラム」を除いたアプリケーションプログラム（たとえば、図１に示すアプリケーションプログラム１０）を指し、改竄チェックの対象となるプログラムを意味する。

一般に、アプリケーションプログラムは、ＯＳの制御下で起動される。すなわち、特定のアプリケーションプログラムを起動する旨の指示が与えられると、ＯＳが当該特定のアプリケーションプログラムを実行するための環境を整える作業を行う。そして、準備が完了した時点で、当該特定のアプリケーションプログラムのルーチンが実行されることになる。

図２２の流れ図は、「通常アプリ」に対して起動指示が与えられた場合の処理手順を示している。起動指示は、たとえば、ユーザによる起動操作によって与えられる。Android端末の場合、ユーザがホーム画面上で特定のアプリケーションプログラムのアイコンをタップする操作を行うと、当該プログラムに対する起動指示が与えられる。なお、既に述べたとおり、起動指示は、必ずしもユーザから与えられるとは限らず、場合によっては、ＯＳや別なアプリケーションプログラムによって与えられる場合もある。

もちろん、「監視プログラム」および「改竄チェックプログラム」も、ＯＳプログラムの制御下で動作する１つのアプリケーションプログラムであることに変わりはない。したがって、これらのプログラムを起動したときの処理手順も図２２に示す手順に準じたものになるが、ステップＳ４４，Ｓ４５は「改竄チェックプログラム」が他のアプリケーションプログラムに対する改竄チェックを行う手順であり、ステップＳ４６，Ｓ４７は「監視プログラム」が他のアプリケーションプログラムをリストに登録する手順であるため、「監視プログラム」および「改竄チェックプログラム」を起動した場合の処理手順は、図２２に示す手順とは若干異なってくる。

この図２２に示されているステップＳ４１，Ｓ４２，Ｓ４４，Ｓ４５の手順は、図７の流れ図に改竄チェックプロセスとして示されているステップＳ８，Ｓ９，Ｓ１２，Ｓ１３の各手順とそれぞれ同じものであり、各ステップの右脇に記載した括弧書きは、個々の手順の実行主体となるプログラムを示している。

まず、ステップＳ４１では、ＯＳプログラムによって、図６に示す第１の確認段階が行われる。この第１の確認段階は、アプリケーションパッケージ２１に対する署名情報２２の正当性を確認する処理であり、その詳細は§３で述べたとおりである。第１の確認段階において否定的な結果が得られた場合、すなわち、署名情報の正当性が確認されなかった場合には、「改竄あり」との判定がなされ、ステップＳ４２を経てステップＳ４３へと進み、当該アプリケーションの実行は中止される。すなわち、当該アプリケーションプログラムに含まれるルーチンが実行される前に、ＯＳによって、実行が阻止されることになる。

一方、第１の確認段階において肯定的な結果が得られた場合は、ステップＳ４２を経てステップＳ４４へと進み、第２の確認段階が行われる。この第２の確認段階は、署名情報２２に対する秘匿情報２３の正当性を確認する処理であり、その詳細は§３で述べたとおりである。第２の確認段階において否定的な結果が得られた場合、すなわち、秘匿情報の正当性が確認されなかった場合には、「改竄あり」との判定がなされ、ステップＳ４５を経てステップＳ４３へと進み、やはり当該アプリケーションの実行は中止される。

もっとも、ステップＳ４４，Ｓ４５の処理は、ＯＳプログラムではなく、改竄チェックプログラムによって実行される処理である。したがって、ステップＳ４２からＳ４４への移行は、制御がＯＳプログラムから改竄チェックプログラムへ移行することを示している。前述したとおり、マルチタスク処理機能を有するＯＳ制御下では、ＯＳプログラムおよび同時に起動状態となっている複数のアプリケーションプログラムが所定のタイミングで切り替えられながら順番に実行されるので、ステップＳ４２からＳ４４への移行は、改竄チェックプログラムへの切替タイミングで行われることになる。

なお、ステップＳ４５で否定的な判定がなされてステップＳ４３に移行する際には、改竄チェックプログラムからＯＳプログラムに対して、改竄ありと判定されたアプリケーションプログラムについての実行を中止させる要請を行えばよい。そうすれば、ＯＳプログラムに制御が移った段階で、ステップＳ４３を実行し、当該改竄が検知されたアプリケーションプログラムを強制的に終了させることができる。

かくして、通常アプリを起動した際には、ＯＳプログラムによる第１の確認段階の処理と、改竄チェックプログラムによる第２の確認段階の処理とが実行され、いずれかの段階において改竄ありと判定された場合には、ステップＳ４３において、当該通常アプリの実行は強制的に中止されることになる。

一方、第１の確認段階の処理と第２の確認段階の処理との双方において肯定的な判定がなされた場合には、当該通常アプリについては改竄なしと判定されたことになり、ステップＳ４５からステップＳ４６へ移行する。ここで、ステップＳ４６，Ｓ４７の処理は、監視プログラムが、図１８に示す監視プログラム(1) の手順の代わりに実行する監視プログラム(2) の手順である。結局、ステップＳ４５からＳ４６への移行は、改竄チェックプログラムから監視プログラムへの切替タイミングで行われることになる。

ステップＳ４６，Ｓ４７の手順は、改竄なしとの判定がなされたアプリケーションプログラムの識別コードを、実行許可リストに登録するリスト自動登録段階の手順である。すなわち、ステップＳ４６において、当該「通常アプリ」の識別コードが既に実行許可リストに登録されているか否かの判定が行われ、登録済みであった場合には、ステップＳ４６からステップＳ４８へと進むが、未登録であった場合には、ステップＳ４７において、当該識別コードを実行許可リストに登録した上で、ステップＳ４８へと進む処理が行われる。いずれの場合も、ステップＳ４８において、当該アプリが実行されることになり、しかも当該アプリの識別コードが実行許可リストに登録された状態になる。

なお、図２２の流れ図では、改竄なしの場合には、説明の便宜上、ステップＳ４１→Ｓ４２→Ｓ４４→Ｓ４５→Ｓ４６→S４７→Ｓ４８のような順序で各手順が実行される様子が示されているが、実際には、ＯＳプログラム、改竄チェックプログラム、監視プログラムは、マルチタスク処理機能により並行して動作していることになり、上記手順は、適宜、実行主体となるプログラムを切り替えることにより実行される。

続いて、この図２２を参照しながら、ある１つの「通常アプリ」を初めて起動した場合に、ＯＳプログラム、改竄チェックプログラム、監視プログラムによってどのような連携処理が行われるかを考えてみよう。この場合、当該「通常アプリ」が改竄がなされていなければ、図２２の流れ図に示すように、ステップＳ４１→Ｓ４２→Ｓ４４→Ｓ４５→Ｓ４６と進み、監視プログラムによるリスト自動登録段階が実行される。具体的には、まず、ステップＳ４６において、当該アプリが登録済みか否かが判断される。初めて起動したアプリであれば、未登録の状態であるのでステップＳ４７へと進み、当該「通常アプリ」は実行許可リストに自動的に登録され、その後、ステップＳ４８へと進み、当該「通常アプリ」が実行される（制御が、監視プログラムからＯＳプログラムを経て当該「通常アプリ」に切り替えられる）。

なお、図２２に示す「通常アプリ」の起動手順は、改竄チェックプログラムが起動状態にあることを前提とした手順であり、改竄チェックプログラムが動作していない場合には、監視プログラムは、図１８に示す監視プログラム(1) の手順を実行することになる。この場合は、前述したとおり、「通常アプリ」を初めて起動した場合、ステップＳ３１→Ｓ３２→Ｓ３３→Ｓ３４と進み、ユーザに対して図２１に例示するようなメッセージが提示され、登録するか否かの選択が行われることになる。

換言すれば、改竄チェックプログラムが起動状態にある場合は、監視プログラムは、図１８に示す監視プログラム(1) に代えて、図２２に示す監視プログラム(2) の簡略化された手順を実行することになる。したがって、ユーザは、改竄チェックプログラムを「常駐プログラム」として常時起動状態に維持しておくようにすれば、監視プログラム(2) によるリスト自動登録の恩恵を受けることができる。もちろん、改竄チェックプログラムも１つのアプリケーションプログラムであるので、ユーザは、これを停止することができる。その場合、監視プログラムは、図１８に示す監視プログラム(1) を実行することになるが、監視プログラムが、図１８に示す監視プログラム(1) のモードで動作していようが、図２２に示す監視プログラム(2) のモードで動作していようが、利用する実行許可リストは同一なので、監視プログラム(2) のモードにおいて実行許可リストに自動登録されたアプリケーションプログラムについては、監視プログラム(1) のモードにおいても既にリストに掲載されているアプリケーションプログラムとなり、起動時に、ユーザに対して図２１に示すようなメッセージが提示されることはない。

このように、改竄チェックプログラムと監視プログラムとを同時に起動状態にしておくと、監視プログラムは、図２２に示す監視プログラム(2) のモードで動作することになり、初めて起動した「通常アプリ」が改竄なしと判定されれば、ステップＳ４７において自動的に実行許可リストに登録されることになる。もちろん、改竄ありと判定された場合は、監視プログラムに制御が引き渡される前に、ステップＳ４３で実行中止となる。したがって、ユーザは、リストに登録するか否かという判断を全く行う必要がない。しかも、実行許可リストは図１８に示す監視プログラム(1) のモードでも共通して利用されるため、改竄チェックプログラムを停止して、監視プログラムが監視プログラム(1) のモードで動作していたとしても、リストへの自動登録の結果は反映されることになる。

結局、図２２に示す手順は、監視プログラムが、監視プログラム(2) のモードで動作中のとき（改竄チェックプログラムが協働して動作中のとき）に、本発明に係るアプリケーションプログラムの改竄検知方法を利用して、アプリケーション実行用コンピュータが、配布されたアプリケーションプログラムを実行するアプリケーションプログラムの実行方法を示す手順ということなる。ここで、ステップＳ４１〜Ｓ４５の手順は、当該コンピュータが本発明に係る改竄検知方法により、入力したアプリケーションプログラムが改竄されているか否かを判定する改竄判定段階を構成し、ステップＳ４６，S４７の手順は、当該コンピュータが、改竄判定段階において改竄されていない旨の判定がなされたアプリケーションプログラムの識別コードを、実行許可リストに登録するリスト自動登録段階を構成する。

一方、図１８に示す手順は、監視プログラムが、監視プログラム(1) のモードで動作中のとき（改竄チェックプログラムが動作していないとき）の実行方法を示す手順であり、アプリケーション実行用コンピュータが、起動状態にあるアプリケーションプログラムの識別コードを認識する起動アプリ認識段階と、この起動アプリ認識段階において認識した識別コードが実行許可リストに登録されているか否かを判定する登録有無判定段階と、この登録有無判定段階において未登録と判定された場合に、当該未登録アプリを登録するか否かをユーザに問い合わせる登録照会段階と、この問い合わせに対するユーザの回答として、登録する旨の回答があった場合には、未登録アプリの識別コードを実行許可リストに登録した上で当該アプリの実行を許可し、登録しない旨の回答があった場合には、当該未登録アプリの実行を中止させる回答処理段階と、が行われることになる。

＜＜＜ §１１．実行許可リストに基く実行制御の変形例＞＞＞
最後に、§１０で述べた実行許可リストに基く実行制御を行う上でのいくつかの変形例を述べておく。

＜１１−１：アプリケーションプログラムのバーションの区別＞
§１０で述べた実行許可リストは、実行が許可されたアプリケーションプログラムを特定する識別コードを掲載した「ホワイトリスト」というべきものである。図２０(a) には、識別コードとして、各アプリケーションプログラムのファイル名を用いた例を示し、図２０(b) には、ファイル名にバージョン番号を付加したコードを用いた例を示した。

一般に、アプリケーションプログラムのバージョンアップ版を提供する場合、差分データファイルだけを配布する形態が採られたり、新バージョンのデータファイルをそっくり配布する形態が採られたりする。後者の場合は、新バージョンのプログラムは旧バージョンのプログラムとは全く別の独立したプログラムになるため、実行許可リスト上でも別個のアプリケーションプログラムとして取り扱うのが好ましい。したがって、実用上は、図２０(b) に示す例のように、バージョンごとにそれぞれ異なる識別コードを付与するようにし、リスト自動登録段階、回答処理段階、および起動アプリ認識段階において、バージョンの異なるアプリケーションプログラムについては、それぞれ異なる識別コードを用いた処理を行うようにするのが好ましい。

なお、バージョンの異なるアプリケーションプログラムを確実に区別するには、同一のファイル名をもったデータファイルに含まれるアプリケーションプログラムであっても、ハッシュ値が異なる場合は、異なるバージョンと認識するようにすればよい。一般に、アプリケーションプログラムを構成するデータの内容が完全に同一でなければ、ハッシュ値も同一にはならない。したがって、たとえば、アプリケーションプログラムを構成するデータ（ＡＰＫファイル全体でもよいし、その一部でもよい）のハッシュ値を、当該アプリケーションプログラムの識別コードとして利用するようにすれば、バージョンの異なるアプリケーションプログラムの識別コードを確実に区別することができる。

相互にバージョンが異なる複数組のアプリケーションプログラムは、署名対象となるデータが異なるため、当然、その署名値も異なる。ただ、通常は、バージョンが異なってもプログラム提供者は共通するため、署名値を得るために用いる第１の鍵および署名情報に含ませる第２の鍵は同じになる。たとえば、図５に示す例の場合、アプリケーションプログラム１０のバージョンが異なれば、署名対象データＤが異なるため、署名値Ｓ（Ａ）は相互に異なるが、Ａの署名情報２２に含まれるＡの第２の鍵Ｋ（ａ２）は共通する。したがって、互いに署名値は異なるが、アプリケーションの識別コードと第２の鍵とが共通するプログラムは、同じプログラム提供者によって作成されたバージョン違いのアプリケーションプログラムであると判断することができる。

この点に着目すれば、配布するアプリケーションプログラムの識別コードとして、同一のアプリケーションプログラムについては、バージョンの違いにかかわらず共通の識別コードを用いるようにしても、アプリケーション実行用コンピュータは、配布された２組のアプリケーションプログラムについて、その識別情報、署名値、第２の鍵を比較し、相互に署名値は異なるが、識別情報および第２の鍵が一致する場合には、当該２組のアプリケーションプログラムが同一のプログラム提供者によって正規に提供されたバージョン違いのアプリケーションプログラムであると認識することができる。したがって、そのような認識がなされた２組のアプリケーションプログラムに対しては、予め定められた所定のバージョン更新処理（たとえば、旧バージョンのプログラムを自動的に削除して、新バージョンに置き換える処理や、ユーザに新旧両バージョンが存在することを通知し、ユーザの指示に応じて、いずれか一方もしくは双方を残す処理など）を実行することが可能になる。

より具体的には、たとえば、実行許可リストに、既存のアプリケーションプログラム（既存アプリ）の「アプリケーション識別コード、署名値、第２の鍵」を登録しておくようにすれば、新たなアプリケーションプログラム（新アプリ）がダウンロードされた場合、当該新アプリから取得した「アプリケーション識別コード、署名値、第２の鍵」を、実行許可リストに登録されている既存アプリの「アプリケーション識別コード、署名値、第２の鍵」と比較し、署名値は異なるが、アプリケーション識別コードおよび第２の鍵が一致した場合、当該新アプリは当該既存アプリと同一の正規のプログラム提供者によって提供されたバージョン違いのアプリケーションプログラムであることが認識できる。

このように、バージョン違いのアプリケーションプログラムであることが認識されたら、たとえば、実行許可リストから旧バージョンの登録を削除して新バージョンの内容に自動的に更新し、バージョンアップがなされたことをユーザに通知するようなバージョン更新処理が可能になる。更に、メモリから旧バージョンのアプリケーションプログラムを自動的に削除することも可能である。もちろん、新旧両バーションのプログラムをそのまま残すようにしてもよいし、ユーザに、旧バージョン／新バージョン／新旧両バージョンのいずれかを選択させて、実行許可リストやメモリには、選択されたバージョンについてのデータが残るようなバージョン更新処理を行うようにしてもよい。

＜１１−２：実行許可リストの格納場所＞
上述したAndroid端末を用いた実施形態の場合、実行許可リストは、Android端末内で「常駐プログラム」として動作する監視プログラムによってアクセスされる情報であるので、Android端末内の記憶装置内に格納するのが最も一般的である。ただ、実行許可リストの格納場所は、必ずしもAndroid端末内に限定されるわけではなく、たとえば、Android端末に接続される外部の記憶装置や、Android端末からネットワークを介してアクセスされるサーバ装置に実行許可リストを格納してもかまわない。

この場合、リスト自動登録段階および回答処理段階で実行許可リストへの登録を行う際に、Android端末等のコンピュータは、外部の記憶装置もしくはサーバ装置内に保存された実行許可リストに対する登録を行い、登録有無判定段階では、当該外部の記憶装置もしくはサーバ装置内に保存された実行許可リストを参照することになる。

＜１１−３：実行許可リストの暗号化＞
§１０で述べたアプリケーションプログラムの実行方法では、実行許可リストが重要な役割を果たすことになり、この実行許可リストが何らかの不正操作によって改竄されてしまうと、監視プログラムによる本来の実行制御機能は失われてしまう。そこで、より信頼性の高い制御を行うためには、実行許可リストに対して暗号化対策を施すようにすればよい。

具体的には、リスト自動登録段階もしくは回答処理段階で実行許可リストへの登録を行う際に、実行許可リストを暗号化する処理を行うようにすればよい。たとえば、実行許可リストに登録する識別コードや後述するチェックコードを個別に暗号化した上で登録するようにしてもよいし、実行許可リストを復号した状態で新たな識別コードやチェックコードを登録し、登録後の実行許可リストを再び暗号化するようにしてもよい。登録有無判定段階では、暗号化されている実行許可リストを復号して内容の参照を行うことになる。なお、暗号化および復号には、監視プログラム内に含まれている専用鍵を用いるようにすればよい。

＜１１−４：チェックコードの付加＞
実行許可リストの信頼性を高める別な方法は、識別コードの他に何らかのチェックコードを登録しておく方法である。すなわち、リスト自動登録段階もしくは回答処理段階で実行許可リストへの登録を行う際に、識別コードとともに、入力段階で入力したデータファイル内に含まれている何らかのデータをチェックコードとして登録するようにし、登録有無判定段階で、データファイル内に含まれているチェックコードと実行許可リストに登録されているチェックコードとの一致を確認し、一致確認がなされることを条件として、実行許可リストに登録されている旨の判定を行うようにすればよい。

たとえば、図５に示すＡＰＫファイル２０Ａの場合、「Ａの第２の鍵Ｋ（ａ２）」（プログラム提供者の公開鍵）をチェックコードとして用い、当該アプリケーションプログラムを実行許可リストに登録する際には、識別コードとともに、「Ａの第２の鍵Ｋ（ａ２）」をチェックコードとして登録しておくようにする。そして、登録有無判定段階（図１８のステップＳ３２，Ｓ３３）では、実行許可リストに当該識別コードと当該チェックコードの双方が登録されていることが確認された場合に、「登録されている」との判定を行うようにすればよい。

もし、識別コードは掲載されているものの、チェックコードが不一致ということになった場合は、実行許可リストに対して何らかの不正行為（たとえば、不正な方法で、実行許可リストに掲載されている識別コードを別なアプリの識別コードに書き換えるような行為）が行われた可能性があると判断することができる。

もちろん、チェックコードは、プログラム提供者の公開鍵に限定されるものではなく、この他にも様々な情報をチェックコードとして用いることができる。たとえば、図５に示すＡＰＫファイル２０Ａの場合、「Ａの第２の鍵Ｋ（ａ２）」（プログラム提供者の公開鍵）の他、Ａの署名情報２２全体やＡＰＫファイル２０Ａ全体をチェックコードとして用いてもかまわない。

もっとも、Ａの署名情報２２全体やＡＰＫファイル２０Ａ全体を、そのままチェックコードとして用いると、チェックコードのデータ容量が膨大なものになり、チェックコードを登録する実行許可リストのデータ容量も膨大なものになってしまう。そこで、実用上は、入力段階で入力したデータファイル内に含まれている所定の情報（たとえば、図５に示すＡの署名情報２２全体やＡＰＫファイル２０Ａ全体）に対してハッシュ関数のような一方向性関数を作用させるダイジェスト化処理を行い、その結果得られたデータをチェックコードとして登録すればよい。

この場合、登録有無判定段階では、データファイル内に含まれている上記所定の情報に対して、上記一方向性関数を作用させるダイジェスト化処理を行うことにより得られるチェックコードと、実行許可リストに登録されているチェックコードとの一致を確認し、一致確認がなされることを条件として、実行許可リストに登録されている旨の判定を行うことになる。なお、ダイジェスト化には、監視プログラム内に含まれている専用鍵を用いるようにすればよい。

＜１１−５：実行許可リストの活用＞
§１０で述べた監視プログラムは、監視プログラム(1) のモードで動作している場合は、ユーザの登録指示に基づいてアプリケーションプログラムを実行許可リストへ登録する処理を行い（ステップＳ３６）、監視プログラム(2) のモードで動作している場合は、改竄なしと判定されたアプリケーションプログラムを実行許可リストへ自動登録する処理を行う（ステップＳ４７）。こうして作成された実行許可リストは、監視プログラム以外のプログラムにも利用させることができる。

たとえば、図７に示す改竄チェックプロセスにおいて、ＯＳプログラムに実行許可リストを活用させるようにし、改竄チェックの対象となるアプリケーションプログラムが実行許可リストに掲載されている場合には、ステップＳ８の第１の確認段階の実質的な処理を省略して、常に、肯定的な判定が行われたものとして取り扱うようにしてもよい。そうすれば、第１の確認段階に必要な様々な演算処理を省くことができる。

同様に、改竄チェックプログラムに実行許可リストを活用させるようにし、改竄チェックの対象となるアプリケーションプログラムが実行許可リストに掲載されている場合には、ステップＳ１２の第２の確認段階の実質的な処理を省略して、常に、肯定的な判定が行われたものとして取り扱うようにしてもよい。そうすれば、第２の確認段階に必要な様々な演算処理を省くことができる。

もちろん、実行許可リストをその他のアプリケーションプログラムに活用させることも可能である。たとえば、第１のアプリケーションプログラムと第２のアプリケーションプログラムとが協力して、相互にデータの受け渡しを行いながらそれぞれの処理作業を行う連携機能を有している場合、相手方のアプリケーションプログラムが実行許可リストに掲載されていることを条件として、そのような連携機能を有効にする、というような運用も可能になる。

要するに、アプリケーションプログラム実行用コンピュータが、本発明に係る改竄検知方法により、入力したアプリケーションプログラムが改竄されているか否かを判定し、改竄されていない旨の判定がなされたアプリケーションプログラムの識別コードを、実行許可リストに登録する処理を行うようにすれば、この実行許可リストを参照して、リストに登録されているアプリケーションプログラムと登録されていないアプリケーションプログラムとの間で異なる処理を実行することができるようになる。たとえば、リストに登録されていないアプリケーションプログラムについては、起動指示を拒否したり、起動していた場合は強制終了させたり、警告メッセージを提示した後に起動を許可したり、といった対応をとることができる。

＜１１−６：改竄チェックプログラムと監視プログラムの関係＞
これまで述べた実施例は、図２３(a) に示すように、改竄チェックプログラム３０と監視プログラム４０とを、それぞれ独立したアプリケーションプログラムとして用意した例であるが、これらのプログラムは、必ずしも別個のアプリケーションプログラムとして用意する必要はない。

たとえば、図２３(b) に示すように、改竄チェックプログラム３０と監視プログラム４０とを、統合管理プログラム５０に組み込み、１つのアプリケーションプログラムとして統合してもかまわない。もちろん、この統合管理プログラム５０には、更に、ウィルスチェック機能などを備えたマルウエア対策プログラムなどを組み込むようにしてもよい。この統合管理プログラム５０も「常駐プログラム」として常に起動状態におくようにすればよい。このように、改竄チェックプログラム３０と監視プログラム４０とを、１つの統合管理プログラム５０に組み込めば、両者の連携がよりスムーズに行われるようになる。

あるいは、図２３(c) に示すように、改竄チェックプログラム３０と監視プログラム４０とを、ＯＳプログラム６０に組み込むこともできる。§９では、改竄チェックプログラム３０をＯＳプログラムに組み込んだ実施形態を述べたが、図２３(c) に示す例は、更に、監視プログラム４０もＯＳプログラム６０に組み込んだ例ということになる。このように、改竄チェックプログラム３０と監視プログラム４０とを、ＯＳプログラム６０に組み込めば、改竄チェックプログラム３０および監視プログラム４０の機能は、ＯＳプログラムの一機能として実現されることになる。したがって、図２２の手順はＯＳプログラムによって実行されるようになり、三者の連携がよりスムーズに行われるようになる。

ただ、現在提供されているAndroidＯＳには、改竄チェックプログラム３０や監視プログラム４０の機能は備わっていないので、現在のAndroid端末を利用して本発明を実施する場合には、図２３(a) ，(b) に示す形態が実用的な実施形態といえる。端末装置のＯＳプログラムが、複数のアプリケーションプログラムを所定のタイミングで切り替えながら実行させるマルチタスク処理機能を有していれば、アプリケーションプログラムの１つとして用意された改竄チェックプログラムによって第２の確認段階の処理を実行することができ、同様に、アプリケーションプログラムの１つとして用意された監視プログラムによって、リスト自動登録段階、起動アプリ認識段階、登録有無判定段階、登録照会段階、回答処理段階を実行することができる。

１０：アプリケーションプログラム
１０Ｘ：改竄されたアプリケーションプログラム
１１：プログラム本体部
１２：リソースデータ
１２Ｘ：改竄されたリソースデータ
１３：サブルーチン群
１４：補助ファイル
１４Ｘ：改竄された補助ファイル
２０：配布用ファイル
２０Ａ，２０Ａ′，２０Ａ''，２０α：配布用ファイル
２０Ｘ：改竄された配布用ファイル
２１：アプリケーションパッケージ
２１Ｘ：改竄されたアプリケーションパッケージ
２２：Ａの署名情報
２２Ｘ：Ｘの署名情報
２３，２３′，２３''：秘匿情報
２３Ｘ：改竄された秘匿情報
２４：秘匿情報の所在情報
３０，３０Ｇ，３０α：改竄チェックプログラム
３１：第１の特定鍵の所在情報
４０：監視プログラム
５０：統合管理プログラム
６０：ＯＳプログラム
１００：サーバ
Ａ：プログラム提供者
ＡＰ１〜ＡＰ７：アプリケーションプログラムのファイル名
Ｃ，Ｃ′：秘匿化対象データ
Ｄ，Ｄ′：署名対象データ
Ｄ（Ａ）：認証用データ
Ｆ：改竄チェックルーチン
Ｇ：プログラム保証者
Ｈ，Ｈ１，Ｈ２：ハッシュ値
Ｋ（ａ１）：Ａの第１の鍵
Ｋ（ａ２）：Ａの第２の鍵
Ｋ（ｄ）：復号鍵
Ｋ（ｅ）：暗号鍵
Ｋ（ｇ１）：Ｇの第１の鍵
Ｋ（ｇ２）：Ｇの第２の鍵
Ｋ（ｓ０）：共通特定鍵
Ｋ（ｓ１）：第１の特定鍵
Ｋ（ｓ２）：第２の特定鍵
Ｋ（ｘ１）：Ｘの第１の鍵
Ｋ（ｘ２）：Ｘの第２の鍵
Ｓ（Ａ）：署名値
Ｓ（Ｘ）：署名値
Ｓ０〜Ｓ４８：流れ図の各ステップ
Ｕ，Ｕ１〜Ｕ３：ユーザ
Ｘ：クラッカー

Claims

改竄チェックの準備を行う準備プロセスと、アプリケーションプログラムを配布する配布プロセスと、配布されたアプリケーションプログラムに対する改竄チェックを行う改竄チェックプロセスと、を有するアプリケーションプログラムの改竄検知方法であって、
前記準備プロセスでは、
アプリケーションプログラムを実行するためのアプリケーション実行用コンピュータが、第１の特定鍵を用いて改竄チェックを行う改竄チェックルーチンを含む改竄チェックプログラムをインストールする改竄チェックプログラム準備段階を行い、
前記配布プロセスでは、
コンピュータが、配布対象となるアプリケーションプログラムに対してパッケージ化処理を施し、アプリケーションパッケージを作成するパッケージ化段階と、
コンピュータが、前記アプリケーションパッケージを署名対象データとして、プログラム提供者の第１の鍵を用いた暗号化を利用した電子署名処理を行って署名値を生成し、この署名値と前記プログラム提供者の第２の鍵とを含む署名情報を作成する署名情報作成段階と、
コンピュータが、前記アプリケーションパッケージおよび前記署名情報を構成するデータの中から、前記プログラム提供者の第２の鍵を含む所定部分を秘匿化対象データとして抽出し、抽出した前記秘匿化対象データに対して第２の特定鍵を用いた秘匿化処理を施して秘匿情報を作成する秘匿情報作成段階と、
コンピュータが、前記アプリケーションパッケージと、前記署名情報と、前記秘匿情報もしくは前記秘匿情報の所在を示す所在情報と、を含む配布用ファイルを作成する配布用ファイル作成段階と、
コンピュータが、前記配布用ファイルを出力するファイル出力段階と、
を行い、
前記改竄チェックプロセスでは、
前記アプリケーション実行用コンピュータが、前記配布用ファイルを入力するファイル入力段階と、
前記アプリケーション実行用コンピュータが、入力した配布用ファイルについて、前記署名情報に含まれている前記プログラム提供者の第２の鍵を用いた復号を利用した署名確認処理を行って、前記アプリケーションパッケージに対する前記署名情報の正当性を確認する第１の確認段階と、
前記アプリケーション実行用コンピュータが、入力した配布用ファイルに基づいて前記秘匿化対象データおよび前記秘匿情報を入手し、前記秘匿化対象データに対する前記秘匿情報の正当性を、前記改竄チェックプログラムを実行することにより確認する第２の確認段階と、
前記アプリケーション実行用コンピュータが、入力した配布用ファイルについて、前記第１の確認段階および前記第２の確認段階の少なくとも一方において否定的な結果が得られた場合に改竄ありとの判定を行う改竄判定段階と、
を行い、
前記プログラム提供者の第１の鍵および第２の鍵として、一方の鍵を用いて暗号化したデータを他方の鍵を用いて復号できる性質をもった一対の鍵を用い、前記第１の特定鍵および前記第２の特定鍵として、一方の鍵を用いて秘匿化処理を施したデータの正当性を他方の鍵を用いて確認できる性質をもった一対もしくは同一の鍵を用いることを特徴とするアプリケーションプログラムの改竄検知方法。
請求項１に記載のアプリケーションプログラムの改竄検知方法において、
第１の特定鍵および第２の特定鍵として、一方の鍵を用いて暗号化したデータを他方の鍵を用いて復号できる性質をもった一対の鍵を用い、
秘匿情報作成段階で、前記第２の特定鍵を用いて、秘匿化対象データに対する暗号化処理を施して秘匿情報を作成し、
第２の確認段階で、前記第１の特定鍵を用いて秘匿情報を復号し、この復号によって得られた秘匿化対象データと、入力した配布用ファイルから抽出した秘匿化対象データとが一致していた場合に、秘匿情報が正当である旨の確認を行うことを特徴とするアプリケーションプログラムの改竄検知方法。
請求項２に記載のアプリケーションプログラムの改竄検知方法において、
第１の特定鍵としてプログラム保証者の第１の鍵を用い、第２の特定鍵として前記プログラム保証者の第２の鍵を用い、前記プログラム保証者の第２の鍵を用いて暗号化したデータを前記プログラム保証者の第１の鍵を用いて復号できるようにし、
改竄チェックプログラム準備段階で、前記プログラム保証者の第１の鍵を用いて改竄チェックを行う改竄チェックルーチンを含む改竄チェックプログラムのインストールを行い、
秘匿情報作成段階で、前記プログラム保証者の第２の鍵を用いて、秘匿化対象データに対する暗号化処理を施して秘匿情報を作成し、
第２の確認段階で、前記プログラム保証者の第１の鍵を用いて秘匿情報を復号し、この復号によって得られた秘匿化対象データと、入力した配布用ファイルから抽出した秘匿化対象データとが一致していた場合に、秘匿情報が正当である旨の確認を行うことを特徴とするアプリケーションプログラムの改竄検知方法。
請求項１に記載のアプリケーションプログラムの改竄検知方法において、
第１の特定鍵および第２の特定鍵として同一の共通特定鍵を用い、
改竄チェックプログラム準備段階で、前記共通特定鍵を用いて改竄チェックを行う改竄チェックルーチンを含む改竄チェックプログラムのインストールを行い、
秘匿情報作成段階で、秘匿化対象データに対して、前記共通特定鍵をパラメータとして用いた一方向性関数を作用させるダイジェスト化処理を施して秘匿情報を作成し、
第２の確認段階で、入力した配布用ファイルから前記秘匿化対象データを抽出し、抽出した秘匿化対象データに対して、前記共通特定鍵を用いた前記ダイジェスト化処理を施して得られる情報が、入力した配布用ファイルに基づいて入手した前記秘匿情報と一致していた場合に、秘匿情報が正当である旨の確認を行うことを特徴とするアプリケーションプログラムの改竄検知方法。
請求項４に記載のアプリケーションプログラムの改竄検知方法において、
秘匿情報作成段階および第２の確認段階で、共通特定鍵をパラメータとして用いたハッシュ関数を作用させるダイジェスト化処理を施して得られるハッシュ値を秘匿情報とすることを特徴とするアプリケーションプログラムの改竄検知方法。
請求項１〜５のいずれかに記載のアプリケーションプログラムの改竄検知方法において、
秘匿化対象データとして、署名情報を構成するデータ全体を用いることを特徴とするアプリケーションプログラムの改竄検知方法。
請求項１〜５のいずれかに記載のアプリケーションプログラムの改竄検知方法において、
秘匿化対象データとして、署名情報に含まれるプログラム提供者の第２の鍵を構成するデータを用いることを特徴とするアプリケーションプログラムの改竄検知方法。
請求項１〜５のいずれかに記載のアプリケーションプログラムの改竄検知方法において、
秘匿化対象データとして、アプリケーションパッケージと署名情報との双方を構成するデータ全体を用いることを特徴とするアプリケーションプログラムの改竄検知方法。
請求項１〜８のいずれかに記載のアプリケーションプログラムの改竄検知方法において、
改竄チェックプログラム内に第１の特定鍵が含まれていることを特徴とするアプリケーションプログラムの改竄検知方法。
請求項１〜８のいずれかに記載のアプリケーションプログラムの改竄検知方法において、
改竄チェックプログラム内に、改竄チェックルーチンと、この改竄チェックルーチンが改竄チェックを行うために必要な第１の特定鍵の格納場所を示す所在情報と、が含まれており、
第２の確認段階で、アプリケーション実行用コンピュータが、前記改竄チェックプログラムから前記所在情報を抽出し、この所在情報に基づいて前記格納場所を認識し、前記格納場所から取り出した前記第１の特定鍵を用いて前記改竄チェックルーチンを実行することを特徴とするアプリケーションプログラムの改竄検知方法。
請求項１〜８のいずれかに記載のアプリケーションプログラムの改竄検知方法において、
改竄チェックプログラム内に、改竄チェックルーチンと、この改竄チェックルーチンが改竄チェックを行うために必要な第１の特定鍵の格納場所を示す所在情報と、が含まれており、
アプリケーション実行用コンピュータ内に、前記第１の特定鍵を保存する保存場所を設け、前記アプリケーション実行用コンピュータが第２の確認段階を実行する際に、前記保存場所に、前記第１の特定鍵が保存されていない場合には、前記改竄チェックプログラムから前記所在情報を抽出し、この所在情報に基づいて前記格納場所を認識し、前記格納場所から前記第１の特定鍵を取り出すことにより、前記第１の特定鍵の入手を行うとともに入手した前記第１の特定鍵を前記保存場所に保存する処理を行い、前記保存場所に、前記第１の特定鍵が保存されている場合には、前記保存場所から前記第１の特定鍵を取り出すことにより、前記第１の特定鍵の入手を行い、入手した前記第１の特定鍵を用いて前記改竄チェックルーチンを実行することを特徴とするアプリケーションプログラムの改竄検知方法。
請求項１０または１１に記載のアプリケーションプログラムの改竄検知方法において、
所定の認証用データを用いた認証機能が備わった格納場所に第１の特定鍵が格納されており、
改竄チェックプログラム内に、前記認証用データが含まれており、
アプリケーション実行用コンピュータが、前記格納場所から前記第１の特定鍵の取り出しを行う際に、前記認証用データを利用した認証を行うことを特徴とするアプリケーションプログラムの改竄検知方法。
請求項１０〜１２のいずれかに記載のアプリケーションプログラムの改竄検知方法において、
第１の特定鍵の格納場所には、前記第１の特定鍵とともに所定の暗号鍵が格納されており、
改竄チェックプログラム内に、前記暗号鍵に対応した復号鍵が含まれており、
アプリケーション実行用コンピュータが、前記格納場所から前記第１の特定鍵の取り出しを行う際に、通信路上を前記第１の特定鍵が前記暗号鍵によって暗号化された状態で送信されるようにし、受信後にこれを前記復号鍵で復号することを特徴とするアプリケーションプログラムの改竄検知方法。
請求項１〜１３のいずれかに記載のアプリケーションプログラムの改竄検知方法において、
アプリケーション実行用コンピュータが、改竄ありとの判定が行われた配布用ファイルに含まれているアプリケーションプログラムについては、実行を中止する処理を行うことを特徴とするアプリケーションプログラムの改竄検知方法。
請求項１〜１４のいずれかに記載のアプリケーションプログラムの改竄検知方法において、
アプリケーション実行用コンピュータとして、ＯＳプログラムの管理下でアプリケーションプログラムの実行を行うコンピュータを用い、
第１の確認段階を前記ＯＳプログラムに基づいて実行し、
第２の確認段階を改竄チェックプログラムに基づいて実行し、
前記改竄チェックプログラムを、改竄チェックの対象となるアプリケーションプログラムとは別のアプリケーションプログラムによって構成するか、もしくは、前記ＯＳプログラムの一部によって構成することを特徴とするアプリケーションプログラムの改竄検知方法。
請求項１〜１５のいずれかに記載のアプリケーションプログラムの改竄検知方法であって、
改竄チェックの対象となるアプリケーションプログラムが、プログラム本体部と、このプログラム本体部から呼び出されるサブルーチン群と、画像および文字列を含むリソースデータと、ＸＭＬ形式のデータからなるマニフェストファイルと、を含んでおり、
パッケージ化段階において、ＺＩＰ方式の圧縮処理を含むパッケージ化処理を実行し、配布用ファイル作成段階において、ＡＰＫ形式のフォーマットをもった配布用ファイルを作成することを特徴とするアプリケーションプログラムの改竄検知方法。
請求項１６に記載のアプリケーションプログラムの改竄検知方法であって、
配布用ファイル作成段階において、ＺＩＰ方式の圧縮フォーマットにおけるコメント領域に秘匿情報もしくは所在情報を記録することにより配布用ファイルを作成することを特徴とするアプリケーションプログラムの改竄検知方法。
請求項１〜１７のいずれかに記載のアプリケーションプログラムの改竄検知方法において、
配布用ファイル作成段階で、コンピュータが、秘匿情報を含む配布用ファイルを作成し、
第２の確認段階で、アプリケーション実行用コンピュータが、入力した配布用ファイルから秘匿情報を抽出することにより、当該秘匿情報の入手を行うことを特徴とするアプリケーションプログラムの改竄検知方法。
請求項１〜１７のいずれかに記載のアプリケーションプログラムの改竄検知方法において、
配布用ファイル作成段階で、コンピュータが、秘匿情報を所定の格納場所に格納する処理を行うとともに、当該格納場所を示す所在情報を含む配布用ファイルを作成し、
第２の確認段階で、アプリケーション実行用コンピュータが、入力した配布用ファイルから前記所在情報を抽出し、この所在情報に基づいて前記格納場所を認識し、前記格納場所から秘匿情報を取り出すことにより、当該秘匿情報の入手を行うことを特徴とするアプリケーションプログラムの改竄検知方法。
請求項１〜１７のいずれかに記載のアプリケーションプログラムの改竄検知方法において、
配布用ファイル作成段階で、コンピュータが、秘匿情報を所定の格納場所に格納する処理を行うとともに、当該格納場所を示す所在情報を含む配布用ファイルを作成し、
アプリケーション実行用コンピュータ内に、入力した配布用ファイルについての秘匿情報を保存する保存場所を設け、前記アプリケーション実行用コンピュータが第２の確認段階を実行する際に、前記保存場所に、必要な秘匿情報が保存されていない場合には、前記配布用ファイルから前記所在情報を抽出し、この所在情報に基づいて前記格納場所を認識し、前記格納場所から秘匿情報を取り出すことにより、当該秘匿情報の入手を行うとともに、入手した秘匿情報を前記保存場所に保存する処理を行い、前記保存場所に、必要な秘匿情報が保存されている場合には、前記保存場所から秘匿情報を取り出すことにより、当該秘匿情報の入手を行うことを特徴とするアプリケーションプログラムの改竄検知方法。
アプリケーションプログラムの改竄を検知する方法であって、
コンピュータが、アプリケーションプログラムと、署名情報と、秘匿情報もしくはその所在を示す所在情報と、を含むデータファイルを入力する入力段階と、
前記コンピュータが、前記アプリケーションプログラムが改竄されているか否かを判定する判定段階と、
を有し、
前記署名情報は、前記アプリケーションプログラムを署名対象データとする電子署名処理によって得られた情報であり、
前記秘匿情報は、前記アプリケーションプログラムおよび前記署名情報を構成するデータの中の所定部分を秘匿化対象データとして抽出し、抽出した前記秘匿化対象データに対する秘匿化処理を施して得られた情報であり、
前記判定段階は、前記署名情報に基づいて改竄の有無を確認する第１の確認段階と、前記秘匿情報に基づいて改竄の有無を確認する第２の確認段階と、を有し、
前記コンピュータには、改竄チェックプログラムがインストールされており、前記改竄チェックプログラムには前記秘匿化処理で行われた処理プロセスを勘案して前記秘匿化対象データに対する前記秘匿情報の正当性を確認する改竄チェックルーチンが含まれており、前記改竄チェックルーチンを実行することにより前記第２の確認段階が行われることを特徴とするアプリケーションプログラムの改竄検知方法。
請求項２１に記載のアプリケーションプログラムの改竄検知方法において、
一方の鍵を用いて暗号化したデータを他方の鍵を用いて復号できる性質をもった一対の鍵を用い、
秘匿情報が、秘匿化対象データを前記一方の鍵を用いて暗号化することにより得られた情報であり、
改竄チェックルーチンが、入力段階で入力したデータファイルに含まれている秘匿情報もしくは入力段階で入力したデータファイルに含まれている所在情報に基づいて入手した秘匿情報を前記他方の鍵を用いて復号し、この復号によって得られた秘匿化対象データと、入力段階で入力したデータファイルから抽出した秘匿化対象データとが一致していた場合に、第２の確認段階に関して改竄なしとの判定を行うことを特徴とするアプリケーションプログラムの改竄検知方法。
請求項２１に記載のアプリケーションプログラムの改竄検知方法において、
秘匿情報が、秘匿化対象データに対して、所定の特定鍵をパラメータとして用いた一方向性関数を作用させるダイジェスト化処理を施して作成された情報であり、
改竄チェックルーチンが、入力段階で入力したデータファイルから抽出した秘匿化対象データに対して、前記特定鍵を用いた前記ダイジェスト化処理を施して得られる情報が、入力段階で入力したデータファイルに含まれている秘匿情報もしくは入力段階で入力したデータファイルに含まれている所在情報に基づいて入手した秘匿情報と一致していた場合に、第２の確認段階に関して改竄なしとの判定を行うことを特徴とするアプリケーションプログラムの改竄検知方法。
請求項１〜２０のいずれかに記載されたアプリケーションプログラムの改竄検知方法における配布プロセスを構成する各段階を有することを特徴とするアプリケーションプログラムの配布方法。
請求項１〜２０のいずれかに記載されたアプリケーションプログラムの改竄検知方法における改竄チェックプロセスを構成する各段階を有することを特徴とするアプリケーションプログラムの改竄チェック方法。
請求項１〜２０のいずれかに記載されたアプリケーションプログラムの改竄検知方法における配布プロセスを構成する各段階をコンピュータに実行させるプログラム。
請求項１〜２０のいずれかに記載されたアプリケーションプログラムの改竄検知方法における改竄チェックプロセスを構成する各段階をコンピュータに実行させるプログラム。
請求項１〜２０のいずれかに記載されたアプリケーションプログラムの改竄検知方法を利用して、アプリケーション実行用コンピュータが、配布されたアプリケーションプログラムを実行する方法であって、
前記アプリケーション実行用コンピュータが、前記改竄検知方法により、入力したアプリケーションプログラムが改竄されているか否かを判定する改竄判定段階と、
前記アプリケーション実行用コンピュータが、前記改竄判定段階において改竄されていない旨の判定がなされたアプリケーションプログラムの識別情報を、実行許可リストに登録するリスト自動登録段階と、
前記アプリケーション実行用コンピュータが、起動状態にあるアプリケーションプログラムの識別情報を認識する起動アプリ認識段階と、
前記アプリケーション実行用コンピュータが、前記起動アプリ認識段階において認識した識別情報が前記実行許可リストに登録されているか否かを判定する登録有無判定段階と、
前記アプリケーション実行用コンピュータが、前記登録有無判定段階において未登録と判定された場合に、当該未登録アプリを登録するか否かをユーザに問い合わせる登録照会段階と、
前記アプリケーション実行用コンピュータが、前記問い合わせに対するユーザの回答として、登録する旨の回答があった場合には、前記未登録アプリの識別情報を前記実行許可リストに登録した上で当該アプリの実行を許可し、登録しない旨の回答があった場合には、当該未登録アプリの実行を中止させる回答処理段階と、
を実行することを特徴とするアプリケーションプログラムの実行方法。
請求項２８に記載のアプリケーションプログラムの実行方法において、
アプリケーション実行用コンピュータに組み込まれたＯＳプログラムが、複数のアプリケーションプログラムを所定のタイミングで切り替えながら実行させるマルチタスク処理機能を有しており、
前記アプリケーション実行用コンピュータが、アプリケーションプログラムの１つとして用意された監視プログラムによって、リスト自動登録段階、起動アプリ認識段階、登録有無判定段階、登録照会段階、回答処理段階を実行することを特徴とするアプリケーションプログラムの実行方法。
請求項２９に記載のアプリケーションプログラムの実行方法において、
アプリケーション実行用コンピュータが、ＯＳプログラムによって、個々のアプリケーションプログラムについて、識別情報・起動時・終了時を示すログ情報を記録する処理を実行し、
前記アプリケーション実行用コンピュータが、監視プログラムによって起動アプリ認識段階を実行する際に、前記ログ情報を参照することにより起動状態にあるアプリケーションプログラムの識別情報を認識することを特徴とするアプリケーションプログラムの実行方法。
請求項２８〜３０のいずれかに記載のアプリケーションプログラムの実行方法において、
リスト自動登録段階、回答処理段階、および起動アプリ認識段階において、バージョンの異なるアプリケーションプログラムについては、それぞれ異なる識別情報を用いた処理を行うことを特徴とするアプリケーションプログラムの実行方法。
請求項３１に記載のアプリケーションプログラムの実行方法において、
同一のファイル名をもったデータファイルに含まれるアプリケーションプログラムであっても、ハッシュ値が異なる場合は、異なるバージョンと認識することを特徴とするアプリケーションプログラムの実行方法。
請求項２８〜３０のいずれかに記載のアプリケーションプログラムの実行方法において、
バージョンの異なる同一のアプリケーションプログラムについては共通の識別情報を用いるようにし、
アプリケーション実行用コンピュータが、配布された２組のアプリケーションプログラムについて、その識別情報、署名値、第２の鍵を比較し、相互に署名値は異なるが、識別情報および第２の鍵が一致する場合には、当該２組のアプリケーションプログラムが同一のプログラム提供者によって提供されたバージョン違いのアプリケーションプログラムであると認識し、これら２組のアプリケーションプログラムに対して、予め定められた所定のバージョン更新処理を実行することを特徴とするアプリケーションプログラムの実行方法。
請求項２８〜３３のいずれかに記載のアプリケーションプログラムの実行方法において、
リスト自動登録段階もしくは回答処理段階で実行許可リストへの登録を行う際に、アプリケーション実行用コンピュータが外部の格納場所内に保存された実行許可リストに対する登録を行い、
登録有無判定段階で、前記アプリケーション実行用コンピュータが前記外部の格納場所に保存された実行許可リストを参照することにより判定を行うことを特徴とするアプリケーションプログラムの実行方法。
請求項２８〜３４のいずれかに記載のアプリケーションプログラムの実行方法において、
リスト自動登録段階もしくは回答処理段階で実行許可リストへの登録を行う際に、アプリケーション実行用コンピュータが実行許可リストを暗号化する処理を行い、
登録有無判定段階で、前記アプリケーション実行用コンピュータが暗号化されている実行許可リストを復号して内容の参照を行うことを特徴とするアプリケーションプログラムの実行方法。
請求項２８〜３５のいずれかに記載のアプリケーションプログラムの実行方法において、
リスト自動登録段階もしくは回答処理段階で実行許可リストへの登録を行う際に、アプリケーション実行用コンピュータが、識別情報とともに、ファイル入力段階で入力した配布用ファイルに含まれている所定のチェックコードを登録するようにし、
登録有無判定段階で、前記アプリケーション実行用コンピュータが、前記配布用ファイル内に含まれているチェックコードと実行許可リストに登録されているチェックコードとの一致を確認し、一致確認がなされることを条件として、実行許可リストに登録されている旨の判定を行うことを特徴とするアプリケーションプログラムの実行方法。
請求項２８〜３５のいずれかに記載のアプリケーションプログラムの実行方法において、
リスト自動登録段階もしくは回答処理段階で実行許可リストへの登録を行う際に、アプリケーション実行用コンピュータが、識別情報とともに、ファイル入力段階で入力した配布用ファイルに含まれている所定の情報に対して一方向性関数を作用させるダイジェスト化処理を行うことにより得られるチェックコードを登録するようにし、
登録有無判定段階で、前記アプリケーション実行用コンピュータが、前記配布用ファイル内に含まれている前記所定の情報に対して前記一方向性関数を作用させるダイジェスト化処理を行うことにより得られるチェックコードと、実行許可リストに登録されているチェックコードとの一致を確認し、一致確認がなされることを条件として、実行許可リストに登録されている旨の判定を行うことを特徴とするアプリケーションプログラムの実行方法。
請求項１〜２３のいずれかに記載されたアプリケーションプログラムの改竄検知方法を利用して、アプリケーション実行用コンピュータが、配布されたアプリケーションプログラムを実行する方法であって、
前記アプリケーション実行用コンピュータが、前記改竄検知方法により、入力したアプリケーションプログラムが改竄されているか否かを判定する改竄判定段階と、
前記アプリケーション実行用コンピュータが、前記改竄判定段階において改竄されていない旨の判定がなされたアプリケーションプログラムの識別情報を、実行許可リストに登録するリスト自動登録段階と、
前記アプリケーション実行用コンピュータが、前記実行許可リストを参照して、リストに登録されているアプリケーションプログラムと登録されていないアプリケーションプログラムとの間で異なる処理を実行する段階と、
を実行することを特徴とするアプリケーションプログラムの実行方法。
請求項２９または３０に記載のアプリケーションプログラムの実行方法に用いる監視プログラム。